Source: http://www.google.com/patents/US20050190721?dq=6,654,957
Timestamp: 2017-07-23 23:24:36
Document Index: 331532836

Matched Legal Cases: ['arty 106', 'arty 110', 'arty 106', 'arty 110', 'arty 106', 'arty 108']

Patent US20050190721 - Methods and apparatus for transferring from a PSTN to a VOIP telephone network - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsAIN based methods and apparatus for transitioning telephone numbers and customers from the PSTN to a VOIP network are described. AIN line number portability features are used to allow a few gateway switches that interconnect the PSTN and VOIP networks to service customers whose telephone numbers were...http://www.google.com/patents/US20050190721?utm_source=gb-gplus-sharePatent US20050190721 - Methods and apparatus for transferring from a PSTN to a VOIP telephone networkAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20050190721 A1Publication typeApplicationApplication numberUS 11/042,989Publication dateSep 1, 2005Filing dateJan 25, 2005Priority dateJan 16, 2002Also published asUS6865266, US7693135Publication number042989, 11042989, US 2005/0190721 A1, US 2005/190721 A1, US 20050190721 A1, US 20050190721A1, US 2005190721 A1, US 2005190721A1, US-A1-20050190721, US-A1-2005190721, US2005/0190721A1, US2005/190721A1, US20050190721 A1, US20050190721A1, US2005190721 A1, US2005190721A1InventorsBarry PershanOriginal AssigneePershan Barry P.Export CitationBiBTeX, EndNote, RefManPatent Citations (23), Referenced by (73), Classifications (25), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetMethods and apparatus for transferring from a PSTN to a VOIP telephone network
DETAILED DESCRIPTION [0046] The present invention is directed to methods and apparatus for migrating from the Public Switched Telephone Network (PSTN) to a Voice Over Internet Protocol (VOIP) network, while keeping the transition relatively transparent to end users. Various methods and apparatus of the invention are directed to allowing for a gradual transition of subscribers from the PSTN to VOIP environment, and to minimizing the need to upgrade and/or replace PSTN hardware, e.g., telephone switches, during the transition process. [0047] FIG. 1 illustrates a communications system 100 implemented in accordance with the present invention. The system 100 comprises a plurality of telephones 106, 108, 110, 154, a PSTN 102, and a VOIP network 104. Telephones 108, 110 are conventional telephones, while telephones 106, 154 are IP (Internet Protocol) phones. End users, e.g., telephone service subscribers, may use any one of the telephones 106, 108, 110, 154 to initiate or receive a call. A telephone service subscriber initiating a call id often referred to as the calling party, while a telephone service subscriber to whom a call is directed is known as the called party. [0048] The PSTN 102 comprises a plurality of telephone switches 116, 118, 120, coupled together as shown in FIG. 1. The switches (SSPs) 116, 118, 120 are responsible for routing calls to/from end user devices, e.g., telephones 110, 108 corresponding to calling or called parties. The switches 116, 118, 120 support AIN functionality including AIN triggers thereby allowing them to provide AIN based enhanced telephone services. [0049] In addition to conventional switches 116, 118, 120 the PSTN 102 includes, a set of control and signaling connections 114 including one or more signal transfer points (STPs) 150. The connections 114 allow the various elements of the PSTN to exchange call control related messages and data. [0050] The PSTN further includes one or more intelligent peripherals (IPs) 124, a service control point (SCP) 126 and an integrated service control point (ISCP) 128. Intelligent peripherals 124 are used to provide various services to callers including the playing of message prompts, speech recognition, and the collection of information, e.g., digits, from a caller in response to prompts. An SCP can instruct an SSP to connect a call to an IP and to have the IP play a message and/or collect information from the caller. Collected information may then be used to complete the call. SCP 126 and ISCP 128 serve the same general function in regard to responding to messages for call processing instructions. The ISCP includes an SCP in addition to various other components, e.g., AIN service setup and components. Accordingly, ISCPs provide greater functionality than SCPs. However, traditionally, SCPs 126 have been implemented with greater memory then ISCPs but this is not a requirement. The exemplary PSTN 102 includes SCPs 126 and ISCPs 128. However, the functions of these two elements could easily be combined into a single device 112. SCPs 126 because of their larger memory have often been used to provide LNP services. ISCPs 128, have been commonly used to provide a wide variety of Centrex services, call forwarding services, call screening services as well as other AIN based services: [0051] For purposes of explaining the invention in later call flows, it will be assumed that SCP 126 is responsible for responding to messages resulting from activation of LNP triggers while ISCP 128 is responsible for responding to messages resulting from the activation of services to which individuals or corporate telephone users subscribe such as the aforementioned Centrex and call forwarding services. [0052] In addition to the above discussed elements, the PSTN 102 includes an IP gateway switch 122. The IP gateway switch 122 couples the PSTN 102 to the VOIP network 104 and servers to interface between the PSTN and IP networks by performing any necessary signaling, packetization, and protocol conversions. IP gateway switch functionality can be incorporated into switches which also provide complete PSTN functionality. Such multiprotocol telephone switches may include links to both the PSTN 102 and VOIP network 104. Given the cost of telephone switches, it is desirable that the need to replace existing PSTN switches or to upgrade PSTN switches to include VOIP connection and functionality be limited until the demand for VOIP services at a given switch justifies the cost associated with such an upgrade. Thus, from a cost standpoint, during the initial transition to VOIP it is desirable to minimize the number of telephone switched required to have VOIP functionality and direct links to the VOIP network 104. [0053] In accordance with one feature of the present invention, AIN LNP functionality is used to support the porting of telephone numbers from switches which do not have direct connections to the VOIP network to a switch, e.g., gateway switch 122, which does support VOIP functionality and has connections to the VOIP network 104. The switch to which the call is ported will then, in accordance with the present invention, service the call and perform billing operations as if the call were serviced by the switch from which the call was ported. In this manner, telephone customers can be provided with VOIP service from virtually any switch in the network without the need to replace or upgrade existing switches to interface directly with the VOIP network 104. [0054] In accordance with the present invention, the SCP 126 includes a Local Number Portability (LNP) database 127 that includes a list of telephone numbers that have been ported from the PSTN 102 to a VOIP network 104, and the Local Routing Number (LRN) of the IP gateway switch assigned to service the particular ported number. LNP triggers are set on the ported lines at the switches 116, 118, 120 so that calls originating from the ported telephone lines or directed to the ported telephone lines will be re-routed via AIN LNP functionality to the assigned IP gateway switch. [0055] The use of AIN LNP functionality to port VOIP calls to a non-local VOIP switch permits users to keep their existing telephone numbers while being ported from the PSTN to a VOIP network. The technique also allows users to continue to receive their existing PSTN based telephone services. In addition, from a cost standpoint has the significant advantage of allowing for a gradual transition from a PSTN to a VOIP network without requiring network wide hardware upgrades to the current switches. [0056] The VOIP network 104, which is an IP based network, includes first and second soft switches 130, 154, first and second media/proxy servers 132, 156, an ENUM database 158. Soft switch 130 includes trunk call agent 136, and line call agent 138. VOIP network 104 may be implemented as part of the Internet, or as a part of a separate IP network which may or may not include links to the Internet. In the VOIP network 104, telephone calls comprise a stream of IP packets which may include call related data in addition to audio, e.g., voice, information. To complete a call in the IP network 104, IP packets are routed to from a calling party's IP telephony device, e.g., device 106, to the called party's IP telephony device, e.g., IP telephone 154. [0057] Soft switches 130 include routing information and other control information associated with providing VOIP service, e.g., telephone service, to VOIP service customers, e.g., customers represented by VOIP telephone devices 106, 154. Depending on the implementation, the control and/or routing information and function may be implemented in the soft switch using one or more devices such as a trunk call agent 136 and a line call agent 138. The trunk call agent 136 includes control and routing information associated with various call trunks while the line call agent 138 includes routing and service information associated with individual user lines, e.g. telephones 106, for which soft switch 130 is responsible for, e.g., routing and billing functions. Media/proxy servers 132, 156 interact with the soft switches 130 and route IP telephone calls under direction of the soft switches 130, 152. Thus, IP calls and/or call related data are transmitted through these servers to their respective destinations. Soft switches 130, 152 provide calling and called information to the servers, then the servers determine routing and move the call to its ultimate destination, e.g., they determine the routing instructions for called numbers. [0058] IP telephone calls can be routed under the direction of soft switches 130, 152 to the PSTN via the IP gateway switch 122 which interconnects the VOIP network 104 and PSTN 102. Similarly, soft switches can control the routing of calls received from the PSTN 102 via IP gateway switch 122 so that they are properly routed to an IP telephony device 106, 154. Thus, it is possible for calls to pass between the PSTN and IP domains with soft switches controlling call routing in the VOIP environment and PSTN switches controlling routing in the PSTN domain. [0059] With regard to IP based telephony users, customer information may be stored in the VOIP network, e.g., at the soft switches 130 or in databases accessible to the soft switches 130 or via media/proxy servers 132, 156. Such information may include call screening information, call forwarding information, telephony device status information, customer name/address information and a wide variety of other types of information such as bandwidth capability. Such information can be useful in a wide variety of telephone call situations and, in many cases, can be used to determine whether a call directed to a VOIP telephone number can be successfully completed to the called number, will be redirected to another number (which may be a PSTN based telephone number) and/or if the call will not be able to be completed, e.g., because the called party's telephony device is not active or because the called party is unable to support the bandwidth required to accept the incoming call. [0060] In accordance with various features of the present invention, as will be discussed below, prior to routing a call from the PSTN 102 to the VOIP network 104, information corresponding to a VOIP subscriber is accessed from the PSTN prior to the call being routed to the VOIP network 104. In this manner, the routing of calls from the PSTN to the VOIP network for calls which can not be completed, e.g., due to the called party's telephony device being inactive or because of called party call screening settings, is reduced or avoided. In addition, calls which would result in the call being redirected, e.g., forwarded, to a telephone number corresponding to the PSTN 102, can be routed in the PSTN domain without having to route the call to the VOIP network and then back to the PSTN 102 for call completion. [0061] In accordance with the present invention, VOIP customer information may be accessed from the PSTN 102 in one of two ways. The first way of obtaining VOIP information involves the use of, Session Initiation Protocol, (SIP), to retrieve the desired information from the VOIP network 104. In the FIG. 1 illustrated ISCP 128 includes a link 113 to media/proxy server 132 through which SIP messages and communications can be exchanged. In this manner, the ISCP 128 and SCP included therein, can obtain VOIP telephone service subscriber information and use that information in making PSTN call routing/completion decisions. The second way of accessing VOIP customer information from the PSTN network 102, is through the use of ENUM and an ENUM database. ENUM allows a telephone number to be provided, like a world wide website domain name, to an Internet Domain Name Server (DNS). The DNS returns, in response, telephone number related information such as an IP address corresponding to the supplied telephone number. The supplied telephone number may be an E.164 number which includes, e.g., telephone country code values. [0062] The ENUM database can be used to facilitate users moving from location to location since such users can update the information in the ENUM database with a temporary IP address so that calls are directed to the user's current location at any given time. [0063] In response to entry of a telephone number, the DNS returns information from an ENUM database. The ENUM database includes IP telephony information associated with a particular number. The telephone number associated information may include, e.g., IP address information to be used when routing IP calls to the entered telephone number, an E-mail address, and other information relating to or associated with the telephone number or service subscriber-assigned to use the telephone number. Some of the information obtained using ENUM may be the same as, or similar to, information which could be obtained using SIP. However, SIP currently provides for a broader range of information to be stored and returned than does ENUM. Accordingly, while some embodiments involve the use of ENUM or SIP, other embodiments of the invention involve the use of both SIP and ENUM. In this manner, more information may be obtained than when only one of the two protocols is used to retrieve information associated with a telephone number. [0064] The SIP and ENUM databases may include telephone number and other information corresponding to multiple parties, i.e., IP telephone device users. [0065] A plurality of scenarios arises when migrating from a PSTN 102 to a VOIP network 104. FIGS. 2-5 illustrate process steps and the transfer of messages, data and other signals between components of the system 100 during different call/signal flows, which will be used to explain various features of the present invention. [0066] The top row in each of FIGS. 2-5 illustrate system components which may be used during the exemplary flows in accordance with the present invention, e.g., to service a telephone call. The system components shown in FIGS. 2-5 are identified using the same reference numbers as used in FIG. 1. System components shown at the top of each of FIGS. 2-5 are grouped into two separate boxes 202, 204, with the left box 202 being used to indicate elements in the PSTN domain, which includes elements corresponding to PSTN 102, while the right box 204 is used to indicate system components in the VOIP domain which includes elements corresponding to VOIP network 104. [0067] While the IP gateway switch 122 is shown as an element of the PSTN domain, it is to be understood that this network element 122 bridges the two domains and therefore, arguable belongs at least in part, in each of the PSTN and VOIP domains. [0068] In the figures, the term calling party is used to identify the device 110 (and thus party) from which an exemplary call originates. The originating SSP 116 is the exemplary local SSP to which the calling party's telephone line is connected. The LNP SCP 126 is the SCP which is used to respond to activation of LNP triggers and includes the LNP database 127. The Centrex (CTX) SSP 120 is the exemplary SSP which provides Centrex services to a telephone device coupled there to via a telephone line for which Centrex services are being provided. The term CTX line is used to indicate the device or line associated with a Centrex service subscriber which receives service from the CTX SSP 120. The term AIN ISCP 128 is used to identify the ISCP 128, which for purposes of explaining the invention, is used to provide AIN services, including e.g., call forwarding and AIN based Centrex services. Thus, for purposes of the examples discussed in FIGS. 2-5 it is assumed that LNP triggers are serviced by SCP 126 while other AIN triggers result in servicing by the SCP included in ISCP 128. The second SSP is an SSP through which a call can be routed to, or received from the VOIP network 104. In various examples, the second SSP is the IP gateway switch 122. VOIP elements 132, 130, 152, 156, 154 correspond directly to the similarly named elements of FIG. 1 and therefore will not be discussed further at this point. [0069] Solid arrows are used in FIGS. 2-5 to illustrate the routing of a call, while dashed arrows represent call processing signals, data, and/or messages passed between system components as part of servicing a call. [0070] FIG. 2 is a call flow diagram illustrating call processing steps associated with an exemplary call originating from a device 110 coupled to the PSTN 102, that is directed to a telephone number (corresponding to called party 106) that has been ported to the VOIP network 104. The phone number has remained the same to maintain transparency despite the transition from the PSTN domain 202 to the VOIP domain 204. [0071] The exemplary call begins in step 202 with the calling party 110 dialing a phone number, e.g., 301-774-4244, corresponding to, e.g., the called party using IP telephone device 106. In step 204 the call initiated in step 202 is transmitted to originating switch 116 which is connected to the calling party's customer premises. [0072] In step 206, an LNP trigger set using digits of the called party's telephone number as part of the telephone number porting process of the invention is activated and the call processing is paused. In step 208, a call processing message, e.g., a TCAP message, is sent to Service Control Point (SCP) 126 in order to obtain call processing instructions. In response to the call processing message received in response to activation of the LNP trigger, the SCP 126 retrieves the Local Routing Number (LRN) associated in the LNP database 127 with the called telephone number. This may be done by accessing the database 127 using the called telephone number as an index thereto. [0073] In addition, in step 210 the SCP 126 generates a call control message, e.g., a TCAP response message with the retrieved LRN, e.g., 301-520-6607, of the IP gateway switch 122. This LRN is placed in the called party field and the original called party's telephone number, e.g., 301-774-4244, in a spare field of the call control message. In step 212, the call control message, which includes the LRN, is returned to the originating switch 116. In step 214, the originating switch receives the response message and resumes call processing. Then, in step 216, the switch 116 routes the call using the number in the called party field, which is now the LRN of the gateway switch 122. [0074] In step 218, IP gateway switch 122 recognizes the incoming call as being directed to its own LRN number used for receiving LNP forwarded calls. In response to detecting the LRN in the called party field, the switch 122 retrieves the real called party number from the spare field and then proceeds to process the call using the real called party number. As a result of the use of the real called party number, in step 218, one or more AIN triggers set on the called party's line may be activated. This is because the called party may subscribe to one or more AIN services, e.g., call forwarding services. These AIN services may be identical to AIN services which the called party was receiving prior to having his/her telephone number and service ported to the VOIP network 104. In such a case, an AIN terminating attempt trigger (TAT) or other AIN trigger would be set on the called party's line at the IP gateway switch 122. The flow diagram of FIG. 2 assumes a TAT is set on the called party's line at the gateway switch 122 and that the trigger is activated in step 218. [0075] As a result of activating the AIN trigger set on the called party's line, the IP gateway switch 122 pauses the call and generates a call processing message. In step 220, the switch 122 sends the call processing message to the ISCP 128 used to provide the called party with the AIN based services to which he or she subscribes. In response to the call processing message, in step 222 the ISCP 128 performs the functions associated with the AIN services to which the called party subscribes. This may include call screening and/or AIN based services such as call forwarding. As part of the call processing performed in step 222, the ISCP will access the appropriate CPR, e.g., the CPR corresponding to the called party and determine what further call processing, if any, should be performed. In this manner, the called party whose telephone number has been ported to the IP domain, can receive the same type of AIN services, e.g., call screening services, etc., as telephone service subscribers who have remained in the PSTN domain. In fact, if the called party was receiving AIN services prior to the number being ported to the VOIP domain, the called party can continue to receive those very same AIN services. [0076] The exemplary call flow diagram of FIG. 2 assumes that the AIN processing results in the call ultimately being directed to the called party. This may be the case where, e.g., an AIN call screening service has determined that the call should be allowed to complete to the called party number. In other cases, the call might be forwarded and not allowed to complete to the original called party number. [0077] In step 224, a call control message is returned to the IP gateway switch 122 which instructs the switch to complete the call to the called party number. In step 226, the IP gateway switch 122 determines that the called party number is in the VOIP domain and forwards the call to the soft switch 130, e.g., via a telephone trunk which connects the gateway switch 122 to the softswitch 130. [0078] In step 230, the soft switch 130 looks at the called party number and proceeds to determine the IP address corresponding to the called party number to which the call should be routed. At this point the soft switch 130 can use a plurality of methods to determine the IP address to which the call is to be routed based on the called number 106. One method for determining the IP address is to consult proxy server functionality supported by media/proxy server 132. [0079] In one embodiment of the present invention, the media/proxy servers include a database used for correlating phone numbers with IP addresses. In such embodiment in step 230 the trunk call agent 136 transmits a query to the proxy server functionality included in server 132 to determine the IP addressed to be used to route the call. [0080] With the IP address of the called party determined, in step 232, the soft switch packetizes the call (voice and data portions) into IP packets with the necessary formatting and heading information added. In addition to packetizing the call, the soft switch instructs the proxy sever 132 to route the call using the called party's IP address. In step 236, the call, in the form of a plurality of IP packets, is directed to the called party's IP telephone 106 by the proxy server 132. [0081] From the call flow of FIG. 2, it can be seen how a call can be directed to a called party whose telephone number has been ported to the VOIP network without the called party losing the use of AIN services which are provided via PSTN functionality. As the number of subscribers to AIN services who move to the VOIP network 104 increases, the services currently implemented in the PSTN domain, e.g., AIN services, may be implemented in the VOIP domain. However, by using the methods of the present invention, existing AIN functionality can be used until such time that it becomes more cost effective to implement the services in the VOIP domain. [0082] In various embodiments, the LNP call forwarding feature of the present invention is used in conjunction with various other features such as the use of information obtained using SIP and/or ENUM in processing various calls placed from a telephone 110 located in the PSTN domain 204. Additional examples of call flows in which LNP forwarding is used in accordance with the invention are shown in FIGS. 3, 4, and 6. Each of these figures illustrate the use of one or more other call processing features of the invention in addition to the use of SIP. However in each of these additional call processing examples, the initial call processing steps, i.e., steps 202 through 222 are the same as the steps already discussed with regard to the the FIG. 2 example. Accordingly, for purposes of brevity, the discussion of steps 202 through 220 will not be repeated with regard to the discussions of the call flows shown in FIGS. 3, 4, and 6. [0083] The use of SIP in conjunction with the LNP features of the present invention will now be explained by way of the example illustrated in FIG. 3. In the FIG. 3 example, SIP is used in accordance with the present invention when processing a telephone call originating from the PSTN that is directed to a called party in the VOIP network 104. In the FIG. 3 example, the Session Initiation Protocol (SIP) communications link between the ISCP 128 and the media/proxy server 132 is utilized to obtain called party information from the VOIP network prior to the call being transferred from the PSTN network 102 to the VOIP network 104. In the particular example, information obtained through the use of SIP, e.g. call forwarding information set in the VOIP network by the called party, is used to route the call to a different telephone number than the original called party number. The call forwarding number may correspond to, e.g., a remote location where the called party is working form on a temporary basis. [0084] As in the FIG. 2 example, in the FIG. 3 example, the end user 110 serves as the exemplary calling party while end user 106 corresponds to the exemplary called party. End user device 154 corresponds to the call forwarding telephone number set by the end user 106. [0085] Referring to the example of FIG. 3, call processing steps 202 through 220 are the same as steps 202 through step 220 of the FIG. 2 example. Accordingly, the discussion of the call processing steps of FIG. 3 will begin with step 322 wherein the ISCP 128 responds to a TCAP message in response to activation of an AIN trigger on set on the called party's line at the IP gateway switch 122 to which the call was forward via the use of LNP functionality. [0086] In accordance with the invention a call processing record (CPR) associated with the called party number (a VOIP number), includes instructions to use SIP to obtain called party information from the VOIP network 104. For purposes of explanation, a CPR including such SIP instructions will be called a SIP CPR. [0087] In the FIG. 3 example, the CPR associated with the called party at the ISCP 128 is a SIP CPR. In response to activation of the SIP CPR in step 322 the ISCP 128 generates a SIP message to obtain the desired called party information. In step 324, the ISCP 128 transmits SIP message, via the SIP communications link 113, to the media/proxy server 132. [0088] In response to the SIP message, in step 326 the media/proxy server 132 accesses and/otherwise compiles information on the called party's 106 number and/or information relating to the VOIP network as part of a SIP response. [0089] SIP information, e.g., instructions and/or other information, which can be returned to the ISCP 128 may include, 1) an instruction to route the call to a different number within the PSTN, 2) an instruction to route the call to a different number within the VOIP network 104, 3) call screening information, e.g., information indicating that the called party a) only accepts calls from specific identified callers, b) only accepts calls in specific languages, e.g., English or Spanish, c) only accepts calls that do not exceed a specific data rate. Thus, SIP information can include routing information, bandwidth information, security/screening information, etc. In addition, SIP allows for a host of other types of restrictions and/or information to be conveyed to the ISCP 128 and used in accordance with the invention for call processing and route determination purposes. [0090] The routing information, which can be obtained through the use of SIP, may include call forwarding information set by the called party, e.g., as part of a call forwarding service. The ISCP 128 can redirect the call using forwarding telephone number or other routing information, if any, received from the server 132. Bandwidth availability information can be used to indicate how much bandwidth is available to the called party for purposes of the incoming call. If insufficient bandwidth is available, the ISCP 128 may, in accordance with the present invention, instruct the gateway switch 122 to terminate the call without transferring it to VOIP network 104 for delivery. Security information may include, e.g., call screening information. If a call is to be blocked because of call screening settings, the gateway switch may be instructed by the ISCP 128 to terminate the call without forwarding it to the VOIP network 104. In cases where a call is terminated without it being forwarded to the VOIP network, the ISCP may instruct the SSP 122 to send the call to an IP and for the IP to play the calling party a message indicating the reason the call can not, or is not, being completed. [0091] In step 328, the server 132 returns information relating to the called party to the ISCP 128. The returned information sent to the ISCP 128 by the media/proxy server 132 gives the VOIP network 104 more information that can be used to control how calls will be routed and/or terminated than is available directly from the PSTN 102. [0092] In the FIG. 3 example, call forwarding information is returned to the ISCP 128 in response to the SIP message. The information is used in step 330 to generate a call control message which will cause gateway switch 122 to redirect the call originally directed to called party 106 to the called party number corresponding to the telephone line corresponding to device 154. [0093] In step 332, the ISCP 128 instructs the gateway switch 122 to complete the call to the call forwarding telephone number corresponding to device 154. If the call forwarding number corresponds to a PSTN telephone number, the call will be completed without being transmitted to the VOIP network 104 despite the fact that the original called party number was a VOIP network telephone number. [0094] In the FIG. 3 example, the forward to telephone number corresponds to a VOIP telephone device 154. In such a case, the ISCP may receive an IP address corresponding to the device 154 as part of the SIP response. The received IP address and/or forward to telephone number may be supplied as part of the call completion message received by the IP gateway switch 122 from the ISCP 128. [0095] In step 334 the IP gateway switch 122 receives and processes the call completion information provided by ISCP 128. In response to receiving the call completion information from the ISCP 128, in step 336 the gateway switch 122 routes the call to the VOIP network 104 for routing to the VOIP device 154. Thus, in step 336, the call is routed to the VOIP network 104, and more specifically to soft switch 152, e.g., through media/proxy server 132. [0096] In step 338, soft switch 152 receives the call and uses one of a plurality of techniques to identify routing instructions, e.g., an IP address. Then in step 340 the soft switch 152 transmits a query to server 156, i.e., the server responsible for servicing calls to user device 154. Next, in step 342 the server 156 receives the query and determines the IP address that correlates with the called number. In step 344 the determined IP address is transmitted to the soft switch 152. Then in step 346 the soft switch 152 forwards the IP address to first media/proxy server 132. In step 350, the call is completed to end user device 154 to which the called party indicated calls were to be forwarded to. [0097] FIG. 4 illustrates an example where a call originating in the PSTN 102 is directed to a called telephone number which has been ported to the VOIP network 104 from a telephone switch, SSP 120 (CTX SSP) which was used to provide Centrex service to the called telephone number prior to the telephone number being ported to the VOIP network. In accordance with the invention, despite LNP functionality being used to forward the call to the called party to the IP gateway switch 122 instead of to CTX SSP 120, the called party is still able to receive Centrex service. However, the service is triggered at the gateway switch 122 through the use of an AIN trigger rather than by a trigger set the CTX switch 120 from which the number was ported to the VOIP network. In the FIG. 4 example, the a Centrex service, e.g., a call forwarding service, causes the incoming call to be redirected from the called party's line to another Centrex line, i.e., a telephone line 108 coupled to and serviced by SSP 108. As will be noted, since the line to which the call is forwarded is in the PSTN 102, the call is never forwarded in the FIG. 4 example to the VOIP network despite the ported telephone number to which the call was originally directed being serviced by soft switch 130. [0098] As in the FIG. 2 and FIG. 3 examples, the FIG. 4 example begins in step 202 with calling party 110 dialing the called party's phone number, e.g., 301-774-4244. Call processing then proceeds from step 202 through 220 as previously discussed with regard to the FIG. 2 example. When the call processing message arrives at the ISCP, in step 422, an active Centrex CPR is encountered and a call completion message is generated. The encountered call processing record (CPR) may be the same, or a CPR that is similar to, the Centrex call processing record that would have been encountered by a call directed to the called party prior to the telephone number being ported to the VOIP network 104. [0099] In the FIG. 4 example, the active Centrex CPR includes instructions to forward call directed to the called party to another Centrex telephone line, i.e., the line corresponding to telephony device 108 identified by the exemplary telephone number 301-774-5200. In step 424, the call completion message generated in step 422, including the telephone number to which the call is to be completed in accordance with the Centrex forwarding operation, is sent back to the IP gateway switch 122. [0100] In step 426, the IP gateway switch 122 receives the call completion message. Then in step 428 the IP routes the call using the call forwarding number supplied by the ISCP 128 resulting in the call being directed to CTX SSP 120 which serves as the terminating switch for the CTX line corresponding to device 108. In step 430, switch 120 receives the forward call and completes, in step 432, the connection to device 108 to which the call was forwarded. [0101] Thus, in accordance with the present invention, a subscriber to an AIN service, e.g., an AIN based Centrex service, can continue to receive AIN based telephone services despite having been ported to the VOIP network 104. [0102] As discussed above, ENUM is a protocol which, like SIP can be used to provide information relating to an VOIP telephone customer's capabilities, preferences, call forwarding settings, etc. In accordance some embodiments of the present invention ENUM is used as an alternative to, or in conjunction with, SIP as a way for a PSTN based device, e.g., ISCP 128, to obtain called party information from the VOIP network 104. In accordance with the present invention, the called party information obtained using ENUM may be used to make call routing and call completion information the same way that called party information obtained using SIP can be used. [0103] FIG. 5 illustrates a fourth example of a call placed from device 110 is directed to the telephone number corresponding to a telephone number which was ported to the VOIP network 104. The call processing shown in FIG. 5 is similar to the call processing previously described with regard to the FIG. 3 example. However, in the FIG. 5 example, rather than using SIP to obtain called party information and/or call processing instruction from the VOIP network 104 ENUM is used and the desired called party information is obtained from a database, ENUM database 158 in the VOIP network which includes the desired called party information, e.g., IP address informaiton. [0104] Much like the Internet's Domain Naming System (DNS), where domain names such as www.yahoo.com are stored with correlating IP addresses. In accordance with ENUM, telephone numbers are stored in an ENUM database 158 with correlating IP addresses and related information, e.g., E-mail addresses, call forwarding information, etc. The ENUM database 158 may be incorporated into the existing Internet DNS. [0105] In the FIG. 5 example, call flow steps 102 through 220 are the same as discussed in regard to the FIG. 3 example. Accordingly, the discussion of the call processing steps of FIG. 5 will begin with step 522 wherein the ISCP 128 responds to a TCAP message in response to activation of an AIN trigger on set on the called party's line at the IP gateway switch 122 to which the call was forward via the use of LNP functionality. [0106] In step 524 the ISCP 128 uses a Get_Data function to establish a communication link to the ENUM database 158 in an attempt to retrieve called party information from the VOIP network 104. In step 526 the ENUM database 158 is accessed and called party information, e.g., IP address, is retrieved using the called party's telephone number as an index into the ENUM database 158. In step 528, the called party information which is retrieved using ENUM may be the same as or similar to the above discussed information which could be retrieved using SIP. In the FIG. 5 example, as in the FIG. 3 example, for purposes of explaining the invention the returned called party information indicates that calls to the called party should be redirected, e.g., forward to the telephone number or IP address corresponding to user device 154. In step 530 the information received from the ENUM database access operation is used to generate a call completion message in the same manner as the information obtained using SIP was used in the FIG. 3 example. [0107] The call is then completed to the telephony device 154 to which the called party directed incoming calls to be forwarded to by performing steps 332 through 350 in the same manner as discussed previously in regard to the FIG. 3 example. [0108] In the above described manner ENUM can be used in accordance with the present invention as an alternative to SIP to retrieve called party information from the VOIP network 104. [0109] The pervious call flow examples have all addressed processing a call from the PSTN-directed to a telephone number which has been ported to the VOIP network. Exemplary processing of a call from a VOIP telephony device to a PSTN telephone number will now be discussed with reference to FIG. 6. [0110] There is a greater variety of AIN triggers which can be activated based on the information included in the called party information field of a call then there are types of triggers that are responsive to information included in the calling party field of a call. Accordingly, it is often easier to design and implement AIN based services using triggers that are responsive to information in the called party field than it is to implement services based on information present in the calling party information field of a call. [0111] In accordance with one feature of the present invention, calling party information is inserted into the called party information field of calls directed to the gateway switch 122 from the VOIP network 104. This allows the use of AIN triggers responsive to information in a call's called party information field, to be triggered by calling party information, e.g., the calling party's telephone number. [0112] The insertion of calling party information into the called party field of a call may be performed by the softswitch used to forward the call to the gateway switch 122. To preserve the called party information, the soft switch, in accordance with the invention places the actual called party number into a spare field, e.g., an alternate billing information field of the call. As will be discussed below, a service control point or other network device can be used to recover the called party information after activation of an AIN trigger based on the information included in the called party field. [0113] Rather than have the softswitch insert the called party information into the called party field of a call, the portion of the IP gateway switch 122 which is responsible for interfacing between the IP and PSTN networks 104, may place the calling party information in the called party field and the called party information in a spare field prior to the call being processed by the AIN trigger functionality included in the gateway switch 122. [0114] Thus, in accordance with the invention, at the point AIN triggers may be triggered in the gateway switch 122 by calls from the VOIP network, the information included in the called party field will be the calling party ID, e.g., calling party's telephone number. Meanwhile the called party number will be included in a spare field such as an alternate billing field. [0115] Furthermore, in accordance with the present invention, the ISCP 128 includes or can access a VOIP telephone number information database, e.g., a database including a list of VOIP telephone numbers from which calls may originate from the VOIP network 104. Billing to the calling party for such calls may be performed in accordance with the invention by the IP gateway switch 122 or a remote switch, e.g., switch 120. Billing is performed by the gateway switch 122 when the calling party number is local to the switch 122, e.g., corresponds to a PSTN line which was local to the gateway switch 122 before being converted to a VOIP number. [0116] Billing is performed by a remote switch, e.g., Centrex switch 122, when the remote switch was responsible for serving as the terminating switch for the calling party telephone number prior to it being converted to an VOIP number. For VOIP telephone numbers which are to be billed by switches which are remote from the gateway switch 122, the VOIP telephone number information database includes information identifying the remote switch which is to perform the billing for calls from the listed VOIP number, and code which is to be included in an AMA slip ID to insure that correct billing to the called party number by the remote switch will occur. Each switch logs billing information including AMAslpID's which include the telephone number to be billed and the billing code which determines the billing to be performed. By transmitting AMAslpIDs from the gateway switch to the remote switch which previously serviced the calling party before the number was ported to the VOIP network 104, the calling party can be billed as if the transition to the VOIP network did not occur and/or by the same switch which previously performed the billing but at a different rate. [0117] In the FIG. 6 example a calling party 106 whose number was ported from the PSTN to the VOIP domain originates a call from the VOIP network 104. The exemplary call is directed to a called party 108 located in the PSTN 102. As discussed above, from a billing perspective, it may be desirable to have the call billed as if it originated from the Centrex SSP 120 used to service the originating (calling party) telephone number before it was ported to the VOIP network 104. In this manner, changes in customer billing procedures as perceived by the customer, which may be important for business clients, can be minimized despite a telephone number being ported to the VOIP network. [0118] For purposes of the example, the calling party's telephone number is (301-774-4244) while the called party's telephone number is 301-774-5200. For purposes of the example, the terminating switch for the exemplary called party has been selected to be CTX switch 120. This same switch also served the calling party before the calling party's telephone number was ported to the VOIP domain. Accordingly, CTX switch 120 will be used to perform calling party billing operations in accordance with the invention. [0119] Gateway switch 122 serves as the link between the VOIP soft switch 130 and the CTX SSP 120 through which the called party in the PSTN 102 can be reached by the calling party in the IP network 104. [0120] The FIG. 6 example begins in step 602 with the calling party dialing the called party's telephone number, e.g., 301-774-5200 into the IP telephone device 106. In step 604, the IP call which is received by the media/proxy server 132 and is routed to soft switch 130. [0121] In step 606 the call is received at soft switch 130. Next, in step 608, the soft switch 130 sends a query to media/proxy server 132 seeking routing instructions for called number 301-774-5200. [0122] In step 610, the media/proxy server 132 locates the called party's number in its database and finds that the number is a PSTN number. Since the number being called is in the PSTN 102, the proxy server will information the softswitch 132 to route the call to the local STP for SS-7 routing. [0123] In step 612, the media/proxy server sends the routing information back to the soft switch 130 informing it to route the call to a local Signal Transfer Point (STP) 150 for SS7 routing. The soft switch 130 receives the instructions in step 614 and, in step 616, contacts its local media/proxy server 132 which has SS-7 connectivity. Next, in step 618, the media/proxy server 132 uses SS7 messaging to contact the local PSTN STP 150. In step 620, the STP 150 verifies that the requested call can be completed, e.g., the STP 150 checks to see if the called line is busy or if a no answer condition exists. If either of these conditions is detected by the STP 150, the STP 150 will inform the media/proxy server 132, and the calling party would hear a busy signal or a no answer condition indication under the direction of server 132 or softswitch 130. [0124] In the FIG. 6 example, for purposes of the illustrated call flow, it is assumed that the called party is available to answer the call. In step 621 the called party status information, determined by the STP 150, is transmitted to the softswitch 130 via server 132. [0125] In response to receiving an indication that the called party is available, the call is routed, in step 622 to the IP gateway switch 122 through media/proxy server 132. As part of this routing, the called party number is placed in a spare information field, e.g., alternate billing field and the calling party number is inserted into the called party field. This swapping of data in call information fields may be performed by the softswitch 130, server 132, or at the IP gateway switch 122 prior to the call being subject to AIN trigger processing. [0126] In accordance with the present invention, an AIN Public Office Dialing Plan Trigger (PODP), which is a type of specific digit string (SDS) trigger, is set to be activated at the IP gateway switch 122 based on calling party numbers which may correspond to the VOIP domain. Thus, calls from the VOIP domain, received by the IP gateway switch, will cause an AIN trigger to be activated. For purposes of the example, the activated SDS trigger may be a six digit trigger set so that calls from a number starting with 301-774 will activate the trigger. The use of a six digit AIN trigger allows a single trigger to be used at the switch 122 for numerous telephone numbers. While some of the telephone numbers which activate the trigger may not be VOIP originating calls, it is often easier to have the SCP distinguish between VOIP and non-VOIP calls rather then set thousands of separate triggers on trunk lines, e.g., one per 10 digit VOIP calling party number. [0127] In step 624 the IP gateway switch 122 receives the call originating from VOIP phone 106, the Specific Digit String (SDS) trigger is activated and call processing is paused. Next, in step 626 the IP gateway switch 122 sends a call processing message to the ISCP 128 seeking call processing instructions. [0128] In step 628, the ISCP 128 scans the ten-digit phone number in the calling party field of the received TCAP message, e.g., 301-774-4244, and compares it to the telephone numbers in the VOIP information database. If the scanned calling party number is not a number that was ported to the VOIP network or a number originating from the VOIP network, it will not be listed in the VOIP number information database 129 in such a case, a continue instruction is returned to the switch 122 and the call is routed normally. Thus, telephone numbers which have not been ported to the VOIP network but which activate the trigger set at the gateway switch 122 will be completed in a manner that does not significantly interfere with call processing and is transparent to the called and calling parties. [0129] However, in the FIG. 6 example the calling party number which has been inserted into the called party field is a VOIP number which will be listed in the VOIP number information database 129. Once the number in the called party field has been determined to be a VOIP number, the ISCP 128, in step 628, pulls the real called number, e.g., 301-774-5200, out of the alternate billing field. It then sends a message to the gateway switch to complete the call to the actual called number with the extracted called number being inserted into the called party field of the call completion message. If the calling party VOIP number is served locally by the gateway switch 122, the gateway switch will performing the call billing operations. [0130] However, in the FIG. 6 embodiment, the remote 2 b switch 120 is indicated by the VOIP information database 129 to be responsible for call billing operations. Accordingly, in step 628, the ISCP generates billing instructions, e.g., AMAslpID, along with the call completion message so the call will be charged to the calling party from the switch 120, i.e., the switch from which the calling party telephone number was ported to the VOIP domain. In some embodiments the IP gateway switch may be the same switch that services the calling party number, i.e., the PSTN switch from which the number calling party number was ported to the VOIP domain. In such a case, the billing instructions to be provided to the remote switch 120 are not necessary and the call will be billed to the calling party from gateway switch 122. [0131] In step 630, a call control information, correcting billing and including the correct called number in the called number field, is sent back to the IP gateway switch 122. In step 532, the IP gateway switch 122 resumes the call, and looks in the called party field for the called party's number to be used for routing purposes. The IP gateway switch 122 finds the correct called party number 301-774-5200 which was placed in the called party field by the SCP, and routes the call to switch 120 in step 534. [0132] In step 636, the call is received at switch 120, where it incurs a TAT trigger since the called party is a Centrex subscriber. Call processing is paused and in step 638, a call processing message is sent to the ISCP 128. If a CPR associated with the called number, included special routing or an active service, the call would be routed or processed in according with the CPR instructions. In the FIG. 6 example, we assume that no routing or AIN services are active and therefore, the call should be completed to the called party's line. In step 542 the ISCP returns an instruction to the SSP 120 to complete the call to the called party, i.e., telephony device 108 which is on the called line. [0133] In step 646 the call processing instructions are received from the ISCP and, in the call is completed to the telephony device by the SSP 120 in step 648. [0134] Using the above described methods and apparatus of the present invention telephone users can gradually be moved from the PSTN 102 to VOIP network 104 in a relatively transparent manner. Significantly, in accordance with the invention large companies with multiple phone lines can be allowed convert a few lines at a time to the VOIP network without the need to make significant upgrades to the existing PSTN switches serving as terminating switches for the lines being moved to the VOIP network. [0135] Numerous variations on the above described methods and apparatus are possible without departing from the scope of the invention. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5524145 *Apr 6, 1995Jun 4, 1996Bell Atlantic Network Services, Inc.Incoming call completion threshold restrictionUS5539884 *May 28, 1993Jul 23, 1996Bell Communications Research, Inc.Intelligent broadband communication system and method employing fast-packet switchesUS5812639 *Nov 13, 1995Sep 22, 1998Bell Atlantic Network Services, Inc.Message communication via common signaling channelUS5956391 *Feb 10, 1997Sep 21, 1999Telefonaktiebolaget Lm EricssonBilling in the internetUS5991364 *Mar 27, 1997Nov 23, 1999Bell Atlantic Network Services, Inc.Phonetic voice activated dialingUS6263056 *Apr 16, 1998Jul 17, 2001Ameritech CorporationCalling-party-pays call processing for cellular and pagingUS6324269 *Aug 25, 1998Nov 27, 2001Bellsouth CorporationMethod and system for billing remote calls as if made from a primary lineUS6490345 *Jan 17, 2001Dec 3, 2002Sbc Technology Resources, Inc.Dialing plan service including outgoing call screening, remote tie-line routing, call data reporting and billingUS6546238 *Dec 20, 1999Apr 8, 2003Bell Atlantic Mobile, Inc.Calling party pays system bypassUS6556818 *Apr 24, 2000Apr 29, 2003Bell Atlantic Mobile, Inc.Fixed calling party pays chargesUS6597686 *Apr 21, 1998Jul 22, 2003Telcordia Technologies, Inc.Apparatus and method for internet telephony routingUS6622016 *Oct 4, 1999Sep 16, 2003Sprint Spectrum L.P.System for controlled provisioning of telecommunications servicesUS6697469 *Aug 20, 1998Feb 24, 2004Bellsouth Intellectual Property CorporationMethod and system for implementing calling-party-pays telecommunication servicesUS6842447 *Jun 14, 1999Jan 11, 2005Mci, Inc.Internet protocol transport of PSTN-to-PSTN telephony servicesUS6931107 *Dec 12, 2000Aug 16, 2005Bellsouth Intellectual Property CorporationSystems and methods for per use busy messageUS6968050 *Mar 27, 2002Nov 22, 2005Verizon Services Corp.Methods and apparatus for authenticating and authorizing ENUM registrantsUS7099652 *Dec 17, 2001Aug 29, 2006International Business Machines CorporationOriginating a billed transaction for an origin telephony deviceUS7215663 *Sep 6, 2000May 8, 2007C2 Global Technologies, Inc.Private IP communication network architectureUS7251317 *Dec 12, 2002Jul 31, 2007Verizon Laboratories Inc.Methods and systems for making telephone callsUS7260385 *Sep 8, 2003Aug 21, 2007Sbc Properties, L.P.Method of providing caller identification for calls placed over an internetUS7310418 *Jul 9, 2003Dec 18, 2007Sbc Properties, L.P.Method of routing interLATA network trafficUS7580514 *Jun 7, 2006Aug 25, 2009At&T Intellectual Property 1, L.P.Method, system, and articles for providing a family telecommunication serviceUS20040090954 *Nov 10, 2003May 13, 2004Li ZhangMethod and apparatus for providing internet call waiting with voice over internet protocol* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7471627 *Nov 13, 2003Dec 30, 2008AlcatelNetwork level admission control apparatus for a communications network having a sub-IP level protocolUS7630485Jul 6, 2006Dec 8, 2009At&T Intellectual Property I, L.P.Method and system to bypass ENUM to reach a callee via a PSTN or a PLMNUS7920549 *Dec 30, 2005Apr 5, 2011Verizon Business Global LlcMethod and system for providing secure media gateways to support interdomain traversalUS8027658 *Dec 10, 2004Sep 27, 2011At&T Intellectual Property I, L.P.Enhanced emergency service providerUS8031856Dec 27, 2005Oct 4, 2011Level 3 Communications, LlcCustomer owned telephone numbersUS8107461 *Mar 1, 2007Jan 31, 2012Hitachi Communication Technologies, Ltd.SIP exchange systemUS8116302Sep 22, 2006Feb 14, 2012Verizon Patent And Licensing Inc.Method and system for providing call screening in a packet-switched networkUS8130639Sep 22, 2006Mar 6, 2012Verizon Patent And Licensing Inc.Method and system for providing distinctive announcements in a SIP-based networkUS8144693Sep 22, 2006Mar 27, 2012Verizon Services Organization Inc.Method and system for providing telemetry, verification and/or other access in a SIP-based networkUS8165280Sep 22, 2006Apr 24, 2012Verizon Services Organization Inc.Method and system for providing busy override service in a SIP-based networkUS8175251Oct 23, 2009May 8, 2012At&T Intellectual Property I, L.P.Method and system to bypass ENUM to reach a callee via a PSTN or a PLMNUS8194628Dec 3, 2007Jun 5, 2012At&T Intellectual Property I, L.P.Methods and apparatus to enable call completion in internet protocol communication networksUS8320532Sep 22, 2006Nov 27, 2012Verizon Patent And Licensing Inc.Method and system for providing voice dialing service in a SIP-based networkUS8363812Sep 22, 2006Jan 29, 2013Verizon Patent And Licensing Inc.Method and system for providing call parking in a SIP-based networkUS8374166Sep 22, 2006Feb 12, 2013Verizon Patent And Licensing Inc.Method and system for providing call waiting features in a SIP-based networkUS8447019Mar 3, 2011May 21, 2013Verizon Patent And Licensing Inc.Method and system for providing call screening in a packet-switched networkUS8462772Sep 22, 2006Jun 11, 2013Verizon Patent And Licensing Inc.Method and system for providing party line emulation in a SIP-based networkUS8498222 *Apr 11, 2008Jul 30, 2013Verizon Patent And Licensing Inc.VoIP-based invocation of PSTN-based AIN/IN servicesUS8548151 *Apr 13, 2006Oct 1, 2013Sprint Communications Company L.P.Method for migrating from an old communication switch to a new communication switchUS8565413 *Apr 5, 2005Oct 22, 2013Alpine Access, Inc.SoftphoneUS8570906 *Jul 26, 2005Oct 29, 2013At&T Intellectual Property Ii, L.P.Method and apparatus for assigning a virtual number during porting of a primary numberUS8611522Mar 3, 2008Dec 17, 2013Metaswitch Networks LtdTelephone call processing method and apparatusUS8625578 *Oct 29, 2007Jan 7, 2014At&T Intellectual Property Ii, L.P.Access independent common architecture for real-time communications services for networking environmentsUS8705518Feb 24, 2004Apr 22, 2014At&T Intellectual Property Ii, L.P.Apparatus and method for controlling services and operations in converged communications networksUS8718258 *Jan 24, 2005May 6, 2014Sprint Communication Company L.P.System and method for jurisdictional routingUS8731162 *Mar 15, 2013May 20, 2014Vonage Network, LlcSystems and methods for matching call detail records for the same communication generated by different elements of an IP telephony systemUS8873548 *Sep 22, 2006Oct 28, 2014Verizon Patent And Licensing Inc.Method and system for providing call-forwarding status indications in a packet-switched networkUS8879442May 24, 2012Nov 4, 2014At&T Intellectual Property I, L.P.Methods and apparatus to enable call completion in internet protocol communication networksUS8885639Sep 22, 2006Nov 11, 2014Verizon Patent And Licensing Inc.Method and system for providing talking call waiting in a SIP-based networkUS8908835Sep 22, 2006Dec 9, 2014Verizon Patent And Licensing Inc.Method and system for providing forced hold behavior in a SIP-based networkUS8942709 *Dec 29, 2009Jan 27, 2015Shoretel, Inc.Call redirection for enterprise hosted dual mode serviceUS8948160 *Dec 20, 2007Feb 3, 2015Genband Us LlcControlling services in a circuit-switched network from a packet networkUS9031219May 8, 2007May 12, 2015Level 3 Communications, LlcCustomer owned telephone numbersUS9179482 *Mar 15, 2013Nov 3, 2015Vonage Network, LlcSystems and methods for rapid setup of telephony communicationsUS9191521Jan 28, 2013Nov 17, 2015Verizon Patent And Licensing Inc.Method and system for providing call waiting features in a SIP-based networkUS9198091Mar 15, 2013Nov 24, 2015Vonage Network, LlcSystems and methods for rapid setup of telephony communicationsUS9241074Sep 22, 2006Jan 19, 2016Verizon Patent And Licensing Inc.Method and system for providing variable dial pattern provisioning in a SIP-based networkUS9319530Apr 4, 2011Apr 19, 2016Verizon Patent And Licensing Inc.Method and system for providing telemetry, verification and/or other access in a SIP-based networkUS9363370 *Apr 6, 2005Jun 7, 2016Qwest Communications International Inc.Methods of delivering calls on dual-mode wireless handsetsUS9363384 *Apr 6, 2005Jun 7, 2016Qwest Communications International Inc.Systems for delivering calls on dual-mode wireless handsetsUS9420117Jul 22, 2013Aug 16, 2016Vonage America Inc.Systems and methods for matching call detail records for the same communication generated by different elements of an IP telephony systemUS9668175Feb 11, 2015May 30, 2017Qwest Communications International Inc.Handset transitions in a dual-mode environmentUS20040170183 *Nov 13, 2003Sep 2, 2004AlcatelNetwork level admission control apparatus for a communications network having a sub-IP level protocolUS20060128357 *Dec 10, 2004Jun 15, 2006Lalitha SuryanarayanaEnhanced emergency service providerUS20060177035 *Jan 24, 2005Aug 10, 2006Sprint Communications Company L.P.System and method for jurisdictional routingUS20060187904 *Sep 2, 2005Aug 24, 2006Makoto OouchiVoIP gateway apparatusUS20060222168 *Apr 5, 2005Oct 5, 2006Sean CurleySoftphoneUS20060229101 *Apr 6, 2005Oct 12, 2006Qwest Communications International Inc.Systems for delivering calls on dual-mode wireless handsetsUS20070019623 *Dec 30, 2005Jan 25, 2007Mci, Inc.Method and system for providing secure media gateways to support interdomain traversalUS20070147358 *Dec 27, 2005Jun 28, 2007Level 3 Communications, Inc.Customer owned telephone numbersUS20070183412 *Feb 22, 2007Aug 9, 2007Broadcom Corporation, A California CorporationFacsimile servicing via peer-to-peer internet protocol telephony networkUS20070189484 *Jan 30, 2006Aug 16, 2007Lucent Technologies Inc.System and method for enabling external service logic for calls involving number portability LRNsUS20070211706 *Jan 9, 2007Sep 13, 2007Inventec Appliances Corp.Communication exchange method between a public switched telephone network and an internet telephone networkUS20070258442 *May 8, 2007Nov 8, 2007Level 3 Communications, LlcCustomer Owned Telephone NumbersUS20070274294 *Mar 1, 2007Nov 29, 2007Hitachi Communication Technologies, Ltd.Sip exchange systemUS20080056243 *Oct 29, 2007Mar 6, 2008Roy Radhika RAccess independent common architecture for real-time communications services for networking environmentsUS20080130856 *Jul 6, 2006Jun 5, 2008Sbc Knowledge Ventures, LpMethod and system to bypass ENUM to reach a callee via a PSTN or a PLMNUS20080151879 *Dec 26, 2006Jun 26, 2008Utstarcom, Inc.Method and Apparatus to Facilitate Substituting a Standard Telephone for an Internet Protocol-Compatible Telephone Using a Same Telephone NumberUS20080159273 *Dec 29, 2006Jul 3, 2008Brugman David LMethod and apparatus for facilitating migration from an analog network to a voice over internet protocol networkUS20080159274 *Mar 28, 2007Jul 3, 2008Brugman David LMethod and apparatus for improved routing necessitated by network element replacementUS20080159504 *Dec 29, 2006Jul 3, 2008Brugman David LMethod and apparatus for improved analog line migration to accommodate customer premise equipment changesUS20080227450 *Jan 29, 2008Sep 18, 2008Hitachi Communication Technologies, Ltd.Indoor call control apparatus associated with public mobile networkUS20080240400 *Mar 3, 2008Oct 2, 2008Data Connection LimitedTelephone call processing method and apparatusUS20080293427 *May 22, 2007Nov 27, 2008Colin Shong Chin QuonSystem and method for mobile originated optimal call routingUS20090161661 *Oct 11, 2005Jun 25, 2009Roman ScharfMethod, system and software for establishing a communication channel over a communications networkUS20090161666 *Dec 3, 2007Jun 25, 2009Bernard KuMethods and apparatus to enable call completion in internet protocol communication networksUS20090257428 *Apr 11, 2008Oct 15, 2009Verizon Corporate Services Group Inc.VoIP-BASED INVOCATION OF PSTN-BASED AIN/IN SERVICESUS20100040052 *Oct 23, 2009Feb 18, 2010At&T Intellectual Property I, L.P.Method and System to Bypass ENUM to Reach a Callee via a PSTN or a PLMNUS20100105379 *Dec 29, 2009Apr 29, 2010Thomas Wayne BonnerCall redirection for enterprise hosted dual mode serviceUS20110096771 *Dec 1, 2008Apr 28, 2011Sami SaruVoice over internet protocol (voip) systems, methods, network elements and applicationsUS20110150193 *Dec 15, 2010Jun 23, 2011Nelson CainSystem and method for monetizing telephone calls to disconnected business listingsUS20110158132 *Mar 3, 2011Jun 30, 2011Verizon Services Organization, Inc.Method and system for providing call screening in a packet-switched networkWO2007075219A1Oct 31, 2006Jul 5, 2007Level 3 Communications, Inc.Customer owned telephone numbers* Cited by examinerClassifications U.S. Classification370/328International ClassificationH04Q3/00, H04M15/06, H04M7/00, H04M3/42, H04M15/00Cooperative ClassificationH04M15/56, H04M7/128, H04M3/42297, H04M15/00, H04M15/90, H04Q2213/13034, H04Q2213/13389, H04Q3/0045, H04M2215/016, H04M2207/12, H04M2215/202, H04M15/06European ClassificationH04M15/90, H04M15/56, H04Q3/00D3H, H04M15/00, H04M15/06, H04M3/42N5, H04M7/12H16Legal EventsDateCodeEventDescriptionSep 4, 2013FPAYFee paymentYear of fee payment: 4Jul 28, 2014ASAssignmentOwner name: VERIZON PATENT AND LICENSING INC., NEW JERSEYFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VERIZON SERVICES CORP.;REEL/FRAME:033428/0605Effective date: 20140409Sep 8, 2015ASAssignmentOwner name: VERIZON SERVICES CORP., MARYLANDFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PERSHAN, BARRY PAUL;REEL/FRAME:036505/0582Effective date: 20020115RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services