US9432467B2 - Systems and methods for location management and emergency support for a voice over internet protocol device - Google Patents

Systems and methods for location management and emergency support for a voice over internet protocol device Download PDF

Info

Publication number
US9432467B2
US9432467B2 US14/697,328 US201514697328A US9432467B2 US 9432467 B2 US9432467 B2 US 9432467B2 US 201514697328 A US201514697328 A US 201514697328A US 9432467 B2 US9432467 B2 US 9432467B2
Authority
US
United States
Prior art keywords
operating mode
service
internet protocol
public user
designator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US14/697,328
Other versions
US20150312357A1 (en
Inventor
Richard L. Khan
Chaoxin Qiu
Robert F. Dailey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
RingCentral Inc
Original Assignee
AT&T Intellectual Property I LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US14/697,328 priority Critical patent/US9432467B2/en
Application filed by AT&T Intellectual Property I LP filed Critical AT&T Intellectual Property I LP
Assigned to SBC KNOWLEDGE VENTURES, L.P. reassignment SBC KNOWLEDGE VENTURES, L.P. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DAILEY, ROBERT F, KHAN, RICHARD L, QIU, CHAOXIN
Assigned to AT&T KNOWLEDGE VENTURES, L.P. reassignment AT&T KNOWLEDGE VENTURES, L.P. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: SBC KNOWLEDGE VENTURES, L.P.
Assigned to AT&T INTELLECTUAL PROPERTY I, L.P. reassignment AT&T INTELLECTUAL PROPERTY I, L.P. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: AT&T KNOWLEDGE VENTURES, L.P.
Publication of US20150312357A1 publication Critical patent/US20150312357A1/en
Publication of US9432467B2 publication Critical patent/US9432467B2/en
Application granted granted Critical
Assigned to AT&T INTELLECTUAL PROPERTY I, L.P. reassignment AT&T INTELLECTUAL PROPERTY I, L.P. CORRECTIVE ASSIGNMENT TO CORRECT THE CONVEYING PARTY NAME ALSO RECEIVING PARTY NAME PREVIOUSLY RECORDED AT REEL: 38723 FRAME: 894. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: AT&T KNOWLEDGE VENTURES, L.P.
Assigned to AT&T KNOWLEDGE VENTURES, L.P. reassignment AT&T KNOWLEDGE VENTURES, L.P. CORRECTIVE ASSIGNMENT TO CORRECT THE CORRECT ASSIGNEE AND SUPPORTING ASSIGNMENT PREVIOUSLY RECORDED AT REEL: 036005 FRAME: 0142. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: DAILEY, ROBERT F., KHAN, RICHARD L., QIU, CHAOXIN
Assigned to RINGCENTRAL, INC. reassignment RINGCENTRAL, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AT&T INTELLECTUAL PROPERTY I, L.P.
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: RINGCENTRAL, INC.
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal
    • H04L67/18
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H04L29/08657
    • H04L61/1529
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4535Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1096Supplementary features, e.g. call forwarding or call holding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/029Location-based management or tracking services
    • H04W4/22
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W64/00Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/02Access restriction performed under specific conditions
    • H04W48/04Access restriction performed under specific conditions based on user or terminal location or mobility data, e.g. moving direction, speed

Definitions

  • the present disclosure relates generally to communication systems and, more particularly, to systems and methods for location management and emergency support for a voice over internet protocol device.
  • E911 Internet protocol-enabled telecommunication providers in the United States are required by the Federal Communications Commission (“FCC”) to support enhanced 911 (“E911”) emergency call services. That is, when a telephone user dials 9-1-1, the telecommunication carrier must be able to process the call to determine the geographic location from where the call is originated to enable dispatching emergency personnel to the location of the 911 caller.
  • Enhanced 911 service differs from traditional (non-enhanced) 911 service in that E911 service routes an emergency call to a 911 dispatcher and provides the dispatcher with the geographic location (e.g., street address) from which the call originated, while traditional 911 service routes an emergency call to a 911 dispatcher without providing the dispatcher with geographic location information indicating where the call originated.
  • PSTN public switched telephony networks
  • the geographic information retrieval support for E911 is implemented by fixing associations between wireline telephone numbers and geographic street addresses.
  • Telecommunication providers usually store a subscriber's location (e.g., a street address) in a database associated with an assigned telephone number (e.g., a call back number (“CBN”)) during the service activation.
  • CBN call back number
  • the calling telephone number (i.e., the CBN) of the incoming 911 call can be used to look up the geographic location of the caller, and the retrieved location information can be used to dispatch emergency personnel to the caller.
  • VoIP voice over IP
  • a nomadic service i.e., a service allowing subscribers to connect VoIP telephones at various network locations
  • a VoIP subscriber can easily disconnect a VoIP telephone from one location (e.g., the subscriber's home or workplace), connect the VoIP telephone in another location (e.g., a visited local area network (“LAN”), a coffee shop, a vacation spot, etc.), and register the VoIP telephone with the VoIP service provider to place telephone calls from the other location.
  • LAN visited local area network
  • VoIP service provider e.g., a visited local area network (“LAN”), a coffee shop, a vacation spot, etc.
  • FIG. 1 is a schematic diagram depicting an example network system.
  • FIG. 2 illustrates an example implementation of the site gateway of FIG. 1 .
  • FIG. 3 is an example data structure showing account information associated with a VoIP service subscription.
  • FIG. 4 is a block diagram of an example system to provide E911 service to VoIP devices.
  • FIG. 5 is a flowchart representative of example machine readable instructions that may be executed to determine whether a VoIP device may have been moved to another geographic location.
  • FIGS. 6A and 6B depict a flowchart representative of example machine readable instructions that may be executed to process a VoIP call initiated by a VoIP device.
  • FIG. 7 is a flowchart representative of example machine readable instructions that may be executed to update a registered geographic location associated with a VoIP device.
  • FIG. 8 is a block diagram of an example processor system that may be used to execute the example machine readable instructions of FIGS. 5, 6A, 6B , and/or 7 to implement the example system of FIG. 4 .
  • the example methods and apparatus described herein may be used to manage location information associated with voice over internet protocol (“VoIP”) devices to support E911 services for those VoIP devices.
  • VoIP voice over internet protocol
  • Traditional E911 services based on the plain old telephone system (“POTS”) provide POTS telephone service subscribers with emergency assistance service that is capable of pinpointing the geographic calling location of a caller for emergency personnel (e.g., firemen, policemen, paramedics, etc.).
  • emergency personnel e.g., firemen, policemen, paramedics, etc.
  • the receiving 911 dispatcher can obtain a physical address or geographic location from which the caller is calling and dispatch emergency personnel to that location.
  • IP-enabled communication services e.g., VoIP services
  • VoIP services do not always restrict an IP telephone number to being permanently associated with or assigned to (e.g., located at) a particular geographic location. Instead, some VoIP service providers enable a VoIP device associated with a particular telephone number to nomadically move or roam through a service provider network or through various service provider networks.
  • a subscriber may disconnect a VoIP device from a service provider network at a first location (e.g., the subscriber's home) and reconnect the VoIP device into the same service provider network or a different service provider network at a second location (e.g., a work place).
  • the example systems and methods described herein enable service provider networks to provide E911 services to subscribers even though these subscribers move their VoIP devices between various locations.
  • the example systems and methods determine when a VoIP device has been moved between two network locations and prompt a user of the moved VoIP device to confirm a geographic location change and/or provide updated geographic location information (e.g., a current street address) associated with the current network location of the VoIP device.
  • Some example implementations determine when a VoIP device is not eligible for nomadic use and deny VoIP services to nomadic-disabled devices when they identify an attempt to operate the VoIP device in a network location different from the VoIP devices registered location.
  • the example systems and methods can be used to deny service to VoIP devices connected to networks or portions of a network for which a VoIP service provider cannot provide E911 service.
  • a VoIP service provider may be a telephone company, a cable company, a satellite company, an Internet service provider, a utility (e.g., electricity) service provider, etc.
  • Some disclosed example methods of managing location information for emergency support of a VoIP communication device involve determining a geographic location change status associated with the internet protocol device.
  • a message e.g., an audio message, a text message, a video message, etc.
  • a message is then presented via the VoIP device based on the geographic location change status requesting a user to confirm whether a registered geographic location (e.g., a street address) associated with the VoIP device is a current geographic location of the VoIP device.
  • a current IP address associated with the VoIP device e.g., a registration public IP address used by the VoIP device to register with a VoIP network
  • the current IP address can be compared to a previous IP address (e.g., a registered IP address) registered in associated with the VoIP device. If the current IP address and the previous IP address differ, the geographic location change status is updated to indicate that the geographic location of the VoIP device may have changed from a geographic location previously registered in association with the VoIP device.
  • a network server may assign the current IP address to the VoIP device or to a network access device (e.g., a residential gateway) connected to the VoIP device and through which the VoIP device accesses network services.
  • a network access device e.g., a residential gateway
  • a service provider network may use the geographic location change status to set an operating mode of the VoIP device.
  • a geographic location change status indicating that the VoIP device has not moved to another geographic location corresponds to an unrestricted operating mode (S 0 mode) that enables the VoIP device to access substantially all subscribed to communication services provided by a service provider associated with the VoIP device.
  • Another geographic location change status of the illustrated example indicating that the VoIP device may have moved to another geographic location corresponds to a suspended operating mode (S 1 mode) that restricts the VoIP device to accessing a subset of all otherwise available communication services provided by a service provider.
  • the VoIP device may be allowed to receive VoIP calls and make VoIP calls to one or more telephone numbers (e.g., a customer service telephone number, a 911 operator) pre-selected by a VoIP service provider.
  • a geographic location change status of the illustrated example indicating that the IP device is located within a geographic location at which a VoIP service provider cannot provide emergency service (e.g., E911 service) corresponds to a restricted operating mode (S 2 ) that may allow access to the same or less (e.g., none) services than the suspended (S 1 ) operating mode.
  • the operating mode may be selected by a service provider network based on a user's response to a message presented via the VoIP device. For example, the service provider network may select a particular operating mode if the user confirms that the registered geographic location is the same as the currently logged geographic location. Additionally or alternatively, the service provider network may determine whether the IP device is eligible to roam (i.e., the VoIP device is nomadic-enabled) between different network locations of the service provider network. The service provider network can then select an operating mode that denies access to at least some services if the VoIP device is not eligible to roam. (i.e., the VoIP device is nomadic-blocked). After setting the operating mode of the VoIP device, another message (e.g., an audio message, a text message, a video message, etc.) may be presented via the VoIP device to inform a user of the operating mode change and/or the reason for the change.
  • another message e.g., an audio message, a text message, a video message, etc.
  • Some disclosed example systems to manage location information for emergency support of a VoIP communication device include an interface configured to receive a current IP address (i.e., a registration IP address) associated with the VoIP device. These example systems also include a comparator configured to compare the current IP address with a registered IP address. The comparison indicates that the VoIP device may have been moved (e.g., a suspected location change) or that the VoIP device has not been moved. If a suspected location change is indicated, the system may interact with the user to confirm and/or update records to reflect the current geographic location.
  • a current IP address i.e., a registration IP address
  • a comparator configured to compare the current IP address with a registered IP address. The comparison indicates that the VoIP device may have been moved (e.g., a suspected location change) or that the VoIP device has not been moved. If a suspected location change is indicated, the system may interact with the user to confirm and/or update records to reflect the current geographic location.
  • the example system includes a user interface (e.g., an interactive voice response (“IVR”) interface) configured to present a message (e.g., an audio message, a text message, a video message, etc.) via the VoIP device based on the comparison requesting a user to confirm whether a registered geographic location (e.g., a street address) associated with the VoIP device is the same as a current geographic location of the VoIP device and/or to identify the current geographic location of the VoIP device.
  • IVR interactive voice response
  • the response may indicate that the VoIP device has been moved or has not been moved from a first geographic location to a second geographic location.
  • the user interface may be further configured to instruct the user to navigate to an internet location (e.g., a webpage) to update the registered geographic location when, for example, the response indicates that the VoIP device has been moved from a first geographic location to a second geographic location.
  • an internet location e.g., a webpage
  • the current IP address (i.e., the registration IP address) may be assigned to the VoIP device or to a network access device (e.g., a residential gateway, a site gateway, etc.) connected to the VoIP device and through which the VoIP device accesses network services.
  • the current IP address is different from the registered IP address.
  • the registered IP address may be associated with a geographic location within which the VoIP device was located prior to being associated with the current IP address.
  • the system includes a data structure configured to store the registered IP address associated the VoIP device.
  • some example systems are provided with a mode selector.
  • the mode selector may also select the operating mode based the user's response to the message.
  • the mode selector is configured to set the operating mode to restrict the VoIP device to access a subset of all communication services associated with a service subscription corresponding to the VoIP device.
  • the system may also be provided with a services interface configured to determine whether the VoIP device is eligible for nomadic use and configured to cause the mode selector to set the operating mode to deny access to at least some services if the VoIP device is not eligible for nomadic use.
  • the example methods, apparatus, and systems described herein may be implemented using instructions stored on one or more machine accessible media (e.g., a CD-ROM, a magnetic storage device, an optical storage device, a solid-state storage device, etc.) associated with one or more network system devices.
  • machine accessible media e.g., a CD-ROM, a magnetic storage device, an optical storage device, a solid-state storage device, etc.
  • the machine accessible media may be used to enable network system devices to retrieve and execute the instructions to implement the example methods, apparatus, and systems described herein.
  • FIG. 1 An example network system 100 is shown in FIG. 1 .
  • the example system 100 of FIG. 1 includes subscriber sites 102 a and 102 b .
  • Each of the subscriber sites 102 a and 102 b includes a respective subscriber site gateway 104 a and 104 b (e.g., a residential gateway).
  • the subscriber sites 102 a - b may be residential dwellings and/or business sites (e.g., a coffee shop, an education facility, an office, an industrial building, etc.), and may have separate respective LAN's and/or PBX's located therein which are communicatively coupled to a respective one of the site gateways 104 a - b .
  • the site gateways 104 a and 104 b are used to provide user equipment (e.g., VoIP devices, computers, etc.) network access to the example network system 100 and may be implemented using wire-interface gateways (e.g., wired Ethernet, IEEE-802.3, Universal Serial Bus (“USB”), etc.) or wireless gateways (e.g., wireless Ethernet, IEEE-802.11, Wi-Fi®, Bluetooth®, etc.).
  • wire-interface gateways e.g., wired Ethernet, IEEE-802.3, Universal Serial Bus (“USB”), etc.
  • wireless gateways e.g., wireless Ethernet, IEEE-802.11, Wi-Fi®, Bluetooth®, etc.
  • a VoIP device 106 e.g., a wired or wireless VoIP telephone, a plain old telephone system (“POTS”) analog telephone connected to an analog telephone adapter (“ATA”), a wired or wireless IP data/voice communicator, a personal desktop, laptop, or tablet computer having VoIP capabilities, etc.
  • the site gateway 104 a provides the VoIP device 106 network access to an Internet protocol (“IP”) network 108 , which may include one or more Internet service provider (“ISP”) networks.
  • IP Internet protocol
  • ISP Internet service provider
  • the VoIP device 106 is capable of making VoIP calls via the example IP network 108 .
  • the IP network 108 includes a function that assigns public IP addresses to the site gateways 104 a - b .
  • the function to assign public IP addresses may be implemented using, for example, a dynamic host configuration protocol (“DHCP”) server 110 .
  • DHCP dynamic host configuration protocol
  • the first site gateway 104 a is assigned a public IP address A
  • the second site gateway 104 b is assigned a public IP address B.
  • two subscriber sites i.e., the subscriber sites 102 a - b
  • two site gateways i.e., the site gateways 104 a - b
  • any number of subscriber sites and site gateways may be used in connection with the examples described herein.
  • the VoIP device 106 can be associated with a non-nomadic service (i.e., a nomadic-blocked service) or a nomadic service (i.e., a nomadic-enabled service).
  • a non-nomadic service limits the VoIP device 106 to making VoIP calls from only a pre-selected network location (e.g., from only the subscriber site 102 a ).
  • the VoIP device 106 may be used to make VoIP calls from, for example, the subscriber site 102 a , but not from the subscriber site 102 b .
  • a nomadic service allows the VoIP device 106 to make calls from a plurality of network locations.
  • the VoIP device 106 can be used to make VoIP calls from both of the subscriber sites 102 a - b .
  • a subscriber or user can change the nomadic option for the VoIP device 106 via the user's account.
  • the VoIP device 106 may be associated with a plurality of telephone numbers. For each telephone number, a user can select a different nomadic option. In this manner, when the VoIP device 106 is used from a home location (e.g., the subscriber site 102 a ), any of a plurality of telephone numbers associated with the VoIP device 106 can be used to make VoIP calls. However, when the VoIP device 106 is connected to a visiting site (e.g., the subscriber site 102 b ), only those telephone numbers associated with a nomadic option can be used to make VoIP calls.
  • the example network system 100 is provided with an internet protocol multimedia subsystem (“IMS”) 112 .
  • the IMS 112 enables different communication technologies (e.g., features, services, communication software and equipment, etc.) to work together to deliver enriched communications (e.g., VoIP communications) to subscribers.
  • the IMS 112 of the illustrated example is implemented according to one or more industry standard specifications.
  • the example systems and methods described herein may be used in connection with IP multimedia and telephony core network architectures other than the IMS 112 .
  • IP multimedia and telephony core network architectures other than the IMS 112 may be used to enable VoIP services in the example network system 100 .
  • the IMS 112 is provided with a network management system (“NMS”) 114 that is communicatively coupled to a home subscriber services (“HSS”) database 116 .
  • the NMS 114 is used to manage and track which subscribers have subscribed to which features or services and to enable access to those features by subscribers.
  • the NMS 114 stores records in the HSS database 116 indicative of subscriber's respective features and services.
  • a service change e.g., provisioning, a device registration, an upgrade, an update, etc.
  • the NMS 114 is notified of the service change, and the NMS 114 stores information in the HSS database 116 indicative of the service change.
  • the NMS 114 is also configured to receive and process the initial geographic location information (e.g., street addresses) associated with a VoIP device (e.g., the VoIP device 106 ) when VoIP service is initially provisioned.
  • the NMS 114 is coupled to a customer service center 118 .
  • a subscriber can interact with a customer service representative at the customer service center 118 to change a nomadic option associated with the VoIP device 106 .
  • the VoIP device 106 is moved to a different geographic location, the subscriber can interact with the customer service representative to provide the street address of the new geographic location.
  • the IMS 112 is provided with a web server 122 .
  • the IMS 112 is provided with an interactive voice response (“IVR”) system 124 .
  • IVR interactive voice response
  • the IVR system 124 is configured to playback an audio message via the VoIP device 106 when a VoIP service provider detects that the VoIP device 106 may have been moved to a different geographic location (e.g. moved from the subscriber site 102 a to the subscriber site 102 b ).
  • the IVR system 124 may include a sound file player and/or a text-to-speech converter (e.g., a speech synthesizer) to present one or more audio messages.
  • the IVR message plays back a previously registered street address or last known registered street address of the VoIP device 106 and requests the subscriber of the VoIP device 106 to confirm whether the registered street address is the same as the current street address at which the VoIP device 106 is located. The subscriber can then confirm that the street addresses are the same or, if the street addresses are different, the subscriber can change the registered street address via the IVR 124 , a customer service representative, or an account web page served by the web server 122 . Additionally or alternatively, the subscriber can contact the customer service center 118 to change the registered street address.
  • the IMS 112 is provided with a call session controller (“CSC”) 128 .
  • the call session controller 128 implements a call session control function (“CSCF”) that determines whether a call should be established and which features or services should be used to establish the call based on subscribed features or services (e.g., nomadic-enabled service, calls to a PSTN allowed, etc.) of a subscriber.
  • CSCF call session control function
  • the IMS 112 is also provided with a feature server 130 .
  • the feature server 130 stores the registration (current) public IP addresses (e.g., the public IP address A of the site gateway 104 a ) used by VoIP devices (e.g., the VoIP device 106 ) to register with the IMS 112 . That is, when the VoIP device 106 registers with the IMS 112 , the HSS 116 receives the public IP address A (i.e., a registration public IP address) used by the VoIP device 106 to register. The HSS 116 then forwards a notification including the public IP address A to the feature server 130 , and the feature server 130 stores the public IP address A for future comparisons with other registration IP addresses that the VoIP device 106 may use to register.
  • the public IP address A i.e., a registration public IP address
  • the feature server 130 In addition to storing the public IP address A, the feature server 130 also associates itself with the VoIP device 106 for the duration of its registration. In the illustrated example, the feature server 130 also compares each registration public IP address with a corresponding registered public IP address (i.e., a public IP address used previously by the VoIP device 106 to register with the IMS 112 ) to determine a location change status (e.g., determine whether the VoIP device 106 may have moved from one geographic location to another).
  • a location change status e.g., determine whether the VoIP device 106 may have moved from one geographic location to another.
  • the feature server 130 also stores the current operating mode (e.g., the unrestricted operating mode (S 0 mode), the suspended operating mode (S 1 mode), or the restricted mode (S 2 mode)) associated with each VoIP device registered with the IMS 112 .
  • the feature server 130 is configured to change operating modes from the unrestricted operating mode (S 0 mode) to the suspended operating mode (S 1 mode) based on comparisons of registration public IP addresses with registered public IP addresses. For example, if the feature server 130 determines that the registration public IP address A associated with the VoIP device 106 is different from a registered public IP address associated with the VoIP device 106 , the feature server 130 determines that the VoIP device 106 may have been moved from one geographic location to another.
  • the registration public IP address A associated with the VoIP device 106 is different from a registered public IP address associated with the VoIP device 106
  • the feature server 130 determines that the VoIP device 106 may have been moved from one geographic location to another.
  • the feature server 130 changes the operating mode associated with the VoIP device 106 to the suspended operating mode (S 1 mode) to allow the VoIP device 106 to receive calls and/or to make calls to phone numbers pre-selected by a VoIP service provider such as, for example, a customer service phone number, but to block calls to other (non-preselected) phone numbers.
  • a VoIP service provider such as, for example, a customer service phone number
  • the feature server 130 is also configured to change operating modes to the suspended operating mode (S 1 mode) or the restricted mode (S 2 mode) at the direction of the NMS 114 .
  • the NMS 114 can instruct the feature server 130 to change the operating mode associated with the VoIP device 106 to the restricted mode (S 2 mode).
  • the NMS 114 can also instruct the feature server 130 to change the operating mode associated with a VoIP device 106 from the restricted operating mode (S 2 ) to the suspended operating mode (S 1 ).
  • the feature server 130 is configured to determine the type of message to be presented to a user by the IVR 124 based on, for example, the operating mode associated with the VoIP device 106 .
  • the feature server 130 routes the call to the IVR 124 and instructs the IVR 124 to present a message (e.g., playback an audio announcement) and/or obtain a confirmation response (e.g., a response confirming the correctness of a registered geographic address) from a user.
  • a message e.g., playback an audio announcement
  • a confirmation response e.g., a response confirming the correctness of a registered geographic address
  • the feature server 130 may instruct the IVR 124 to present a message requesting a user to confirm whether the registered geographic location of the VoIP device 106 is correct and, if not, requesting the user to provide an updated geographic street address of the new location.
  • the feature server 130 is also configured to change operating modes associated with the VoIP device 106 from the restricted operating mode (S 1 ) to the unrestricted operating mode (S 0 ) based on the confirmation response.
  • the feature server 130 can change the operating mode of the VoIP device 106 from S 1 to S 0 when the user confirms that the registered geographic location presented by the IVR 124 is correct.
  • the feature server 130 informs the IVR 124 from where to obtain the registered geographic address of the VoIP device 106 .
  • the feature server 130 is configured to store uniform resource locator (URL) addresses corresponding to network locations (e.g., servers, network directories, etc.) in which the audio files are stored.
  • URL uniform resource locator
  • the IMS 112 is provided with an emergency services gateway (“ESGW”) 132 .
  • the emergency services gateway 132 uses information received via an emergency call's call setup signaling to determine a path (e.g., a trunk) via which to route the emergency call for E911 handling.
  • the example network system 100 is provided with a public safety answering point (“PSAP”) 134 .
  • PSAP 134 corresponds to a particular geographic area, and dispatchers at the PSAP 134 handle emergency calls originating from VoIP devices within that geographic area. In this manner, dispatchers can dispatch emergency services personnel from a location nearest the geographic location of a 911 caller.
  • PSAP public safety answering point
  • the example network system 100 may be implemented using any number of PSAP's, each corresponding to one or more respective geographic area(s).
  • the example network system 100 is provided with a 911 selective router 136 .
  • the 911 selective router 136 routes emergency calls to the correct PSAP based on information received from the emergency services gateway 132 and a selective routing database (“SRDB”) 138 .
  • SRDB selective routing database
  • the emergency services gateway 132 communicates an emergency services query key (“ESQK”) to the 911 selective router 136 .
  • ESQK is a call identifier that represents an emergency call for the duration of the call and is used by the selective router 136 to route an emergency call to the correct PSAP (e.g., the PSAP 134 ).
  • the 911 selective router 136 After the 911 selective router 136 receives the ESQK from the emergency services gateway 132 , the 911 selective router 136 forwards the ESQK to the SRDB 138 to obtain an emergency service number (“ESN”) identifying a PSAP to which to route the emergency call.
  • ESN emergency service number
  • the SRDB 138 stores ESQK's in association with respective ESN's.
  • An ESN is a number used to indicate a particular group of emergency service agencies (e.g., police department, fire department, medical agency) that serves a particular geographic area and facilitates routing an emergency call to the PSAP that serves that geographic area.
  • the example network system 100 is provided with an i2 E911 system 140 .
  • the i2 E911 system 140 To store street addresses in association with respective telephone numbers of VoIP devices and to determine whether a call is originating from a geographic area in which a corresponding VoIP service provider can provide E911 services, the i2 E911 system 140 is provided with a location identification server (“LIS”) database 142 .
  • the LIS database 142 stores a record for each telephone number of the VoIP device 106 , and each record is used to store the geographic location (e.g., the street address) of the subscriber site 102 a in association with the telephone number in that record.
  • the NMS 114 communicates initial geographic location information (e.g., initial street addresses) to the LIS database 142 during initial VoIP subscription enrollments.
  • initial geographic location information e.g., initial street addresses
  • the IMS 112 communicates the updated street address to the LIS database 142 .
  • the i2 E911 system 140 is also provided with an emergency services zone (“ESZ”) routing database (“ERDB”) 146 .
  • Each ESZ corresponds to a particular emergency service number (“ESN”) that uniquely identifies the ESZ.
  • ESN emergency service number
  • the ERDB 146 stores an emergency services routing number (“ESRN”) corresponding to an E911 selective router that serves that ESZ and a respective ESN.
  • ESRN emergency services routing number
  • an ESRN is used to route an emergency call to an E911 selective router serving the ESZ corresponding to the geographic area within which the emergency call originated.
  • the LIS database 142 uses the ESRN's stored in the ERDB 146 to determine whether the provided street address is located within an area in which a corresponding VoIP service provider can provide E911 service. For example, the LIS database 142 accesses the ERDB 146 to retrieve an ESRN corresponding to the provided street address and determines whether the VoIP service provider can provide E911 service to the provided street address based on the ESRN. Regardless of whether the LIS database 142 determines that the VoIP service provider can or cannot provide E911 service to the provided street address, the LIS database 142 updates the registered geographic location of the VoIP device 106 with the provided street address.
  • the LIS database 142 determines that the VoIP service provider cannot provide E911 service to the provided street address, the LIS database 142 informs the NMS 114 that the VoIP device 106 is in a location at which E911 service is not available. In this manner, the NMS 114 can instruct the feature server 130 to set the operating mode associated with the VoIP device 106 to a restricted mode (S 2 mode) so that the VoIP device 106 can access only a subset of services (e.g., receive calls only, connect to a 911 dispatcher without the location-identification services of E911) that are, for example, associated with a service subscription corresponding to the VoIP device 106 .
  • S 2 mode restricted mode
  • the i2 E911 system 140 To validate geographic location information (street addresses) to be stored in the LIS database 142 , the i2 E911 system 140 is provided with a validation database (“VDB”) 144 .
  • the VDB 144 stores a plurality of street addresses in a format compliant with the master street address guide (“MSAG”) standard.
  • MSAG master street address guide
  • the i2 E911 system 140 compares the user-provided street addresses with known street addresses in the VDB 144 to determine whether the provided street address is MSAG-compliant.
  • the i2 E911 system 140 validates the provided street address and updates a corresponding registered street address in the LIS database 142 . Otherwise, if the provided street address is not MSAG-compliant (e.g., the address includes a typographical error, an incorrect zip code, etc.), the i2 E911 system 140 indicates that the provided street address is invalid, and the IMS 112 informs the subscriber of the invalidity and requests the user to provide a compliant street address.
  • MSAG-compliant e.g., the address includes a typographical error, an incorrect zip code, etc.
  • the i2 E911 system 140 is provided with a VoIP positioning center (“VPC”) 148 communicatively coupled to the CSC 128 .
  • VPC VoIP positioning center
  • the CSC 128 queries the VPC 148 to determine the E911 selective router to which the emergency services gateway 132 should route the emergency call.
  • the PSAP 134 is coupled to an automatic location identification (“ALI”) database 150 to enable the PSAP 134 to retrieve geographic street addresses from which emergency calls originate.
  • the ALI database 150 stores geographic street addresses corresponding to the locations of telephones connected to a traditional publicly switched telephone network (“PSTN”) 152 .
  • PSTN publicly switched telephone network
  • the VPC 148 stores geographic street addresses associated with VoIP devices that it retrieves from the LIS database 142 .
  • the PSAP 134 requires a street address of a VoIP device 106
  • the ALI 150 queries the VPC 148 for the street address.
  • the VPC 148 forwards the street address associated with the VoIP device 106 to the ALI database 150 .
  • the ALI database 150 then provides the street address to the PSAP 134 .
  • FIG. 2 illustrates an example implementation of the site gateway 104 a .
  • a plurality of plain old telephone system (“POTS”) analog telephones 202 and/or the VoIP device 106 are communicatively coupled to the site gateway 104 a of FIG. 2 .
  • POTS plain old telephone system
  • the site gateway 104 a is provided with a plurality of RJ-11 ports 208 to which the analog telephones 202 are communicatively coupled.
  • the site gateway 104 a is provided with analog telephone adapters (“ATA's”) 210 .
  • ATA's analog telephone adapters
  • the site gateway 104 a is provided with a wide area network (“WAN”) port 204 .
  • the DHCP server 110 of the IP network 108 assigns a public IP address (e.g., the public IP address A) to the site gateway 104 a to enable the site gateway 104 a to access Internet services via the IP network 108 .
  • the site gateway 104 a associates a unique private IP address with each of the ATA's 210 .
  • the site gateway 104 a associates a private IP address with the device 106 .
  • the site gateway 104 a is provided with a network address translator (“NAT”) 206 to translate between the private IP addresses and the public IP address A of the site gateway whenever any of the devices 202 and 106 exchange, send, and/or receive information with, to, and/or from the IP network 108 via the site gateway 104 a.
  • NAT network address translator
  • each of the ATA's 210 integrated in the gateway 104 a is provided with a gateway-integrated SIP user agent (“SIP UA”) 212 .
  • SIP UA gateway-integrated SIP user agent
  • the SIP UA's 212 register with the IMS 112 to enable the analog telephones 202 to make VoIP calls.
  • the SIP UA's 212 re-register with the IMS 112 .
  • the DHCP server 110 of the IP network 108 may assign the same or a different public IP address to the site gateway 104 a.
  • the VoIP device 106 includes a SIP UA 214 and is capable of exchanging digital information network packets with the site gateway 104 a . Accordingly, it is not necessary to use another SIP UA (e.g., one of the SIP UA's 212 ) or an ATA (e.g., the ATA 210 ) in the site gateway 104 a for communications with the VoIP device 106 .
  • the site gateway 104 a is provided with an RJ-45 port 216 to which the VoIP device 106 is communicatively coupled.
  • the site gateway 104 a is provided with a router 218 for routing the network traffic corresponding to the VoIP device 106 .
  • the site gateway 104 a assigns a unique private IP address to the SIP UA 214 of the VoIP device 106 .
  • the SIP UA 214 registers the VoIP device 106 with the IMS 112 to enable the VoIP device 106 to make VoIP calls.
  • the SIP UA 214 re-registers with the IMS 112 .
  • the VoIP device 106 can be associated with one or more telephone numbers used to implement public user ID's (“PUID's”).
  • a PUID is used to establish a VoIP call with a VoIP device 106 .
  • a conventional (XXX) YYY-ZZZZ type phone number can be used as the PUID.
  • the PUID may be implemented using any other format instead of a telephone number format (e.g., an e-mail address format).
  • the NMS 114 FIG.
  • a VoIP service provider allocates a PUID (e.g., a telephone number) to the user and stores geographic location information (e.g., a street address) in the LIS database 142 in association with the PUID.
  • the NMS 114 identifies a plurality of features (e.g., nomadic-enabled or nomadic-blocked) associated with the PUID and stores the features in the HSS database 116 ( FIG. 1 ). For example, if the user expects to operate the VoIP device 106 at a single location (e.g., the subscriber site 102 a ), the user may elect to block nomadic operation of the VoIP device.
  • the VoIP service provider will deny the VoIP device 106 access to VoIP services because it is designated as nomadic-blocked. However, if the user expects to move the VoIP device 106 between different sites (e.g., between the subscriber sites 102 a - b ), the user may elect to allow nomadic operation of the VoIP device 106 . In this manner, when the VoIP device 106 is moved to a different location, the VoIP service provider will allow operation of the VoIP device 106 because it is designated as nomadic-allowed.
  • FIG. 3 is an example data structure 300 showing associations between corresponding account information associated with a VoIP service subscription.
  • the account information e.g., features, network identifications, etc.
  • the account information shown in the data structure 300 can be stored in different network entities of the IMS 112 ( FIG. 1 ).
  • information shown in a particular column of the data structure 300 can be stored in the home subscriber services (“HSS”) database 116 of FIG. 1 , while other information in another column can be stored in the feature server 130 of FIG. 1 or any other network entity.
  • HSS home subscriber services
  • particular columns of information shown in the data structure 300 may be stored throughout the example network system 100 in one or more network locations using a plurality of data structures and can be associated with one another using index keys (e.g., PUID's). However, for purposes of discussion, the information is shown in the data structure 300 .
  • index keys e.g., PUID's
  • the data structure 300 includes a site gateway ID column 302 that is used to store site gateway identification numbers 304 that uniquely identify the site gateway 104 a of FIGS. 1 and 2 .
  • site gateway ID column 302 that is used to store site gateway identification numbers 304 that uniquely identify the site gateway 104 a of FIGS. 1 and 2 .
  • the data structure 300 includes a gateway-internal ATA column 306 .
  • the gateway-internal ATA column 306 can be used to indicate that the ATA's 210 of FIG. 2 are gateway-internal ATA's.
  • the data structure 300 is provided with a public user ID (PUID) column 308 that is used to store a plurality of PUID's (e.g., telephone numbers) 310 assigned to a subscriber account.
  • the PUID's 310 may be used with gateway-internal ATA's (e.g. the ATA's 210 of FIG. 2 ) and/or with VoIP telephones (e.g., the VoIP device 106 ).
  • a public IP address e.g., the public IP addresses A and B of FIG. 1
  • the data structure 300 is provided with a registered public IP address column 312 having a plurality of registered public IP addresses 314 .
  • the registered public IP addresses 314 are used to detect when a VoIP device associated with one of the PUID's 310 may have been moved to another geographic location.
  • the data structure 300 is provided with a nomadic block column 316 that stores a plurality of nomadic service designators 317 .
  • Each of the nomadic service designators 317 corresponds to one of the PUID's 310 and indicates whether the corresponding PUID's 310 is nomadic-blocked (Y) or nomadic-enabled (N).
  • a nomadic-enabled (N) designator indicates a PUID and its associated VoIP device (e.g., the VoIP device 106 ) are allowed to access VoIP services when the associated VoIP device is moved away from a primary or pre-designated geographic location.
  • the data structure 300 is provided with an operating mode column 318 that stores operating mode designators 320 (e.g., the operating mode designators S 0 , S 1 , and S 2 ).
  • the operating mode designators 320 in the operating mode column are stored in the feature server 130 of FIG. 1 .
  • the S 0 operating mode is an unrestricted operating mode in which a VoIP device can access substantially all VoIP services associated with a service subscription corresponding to the VoIP device (or corresponding to the PUID(s) used with that VoIP device).
  • the S 1 operating mode is a suspended operating mode that restricts the VoIP device to use of a subset of the VoIP services associated with a service subscription corresponding to the VoIP device (or PUID(s) used with the VoIP device).
  • the S 2 operating mode of the illustrated example allows the VoIP device to access the same or less VoIP services as those allowed in the S 1 (suspended) operating mode.
  • additional operating modes may be implemented (e.g., an operating mode that disallows any incoming or outgoing calls).
  • FIG. 4 is a block diagram of an example system 400 configured to provide support functions for E911 services to VoIP devices associated with nomadic usage.
  • the example system 400 includes an IP address interface 402 , an IP address comparator 404 , a user interface 406 , a geographic location information interface 408 , a validator 410 , a geographic location change status updater 412 , an operating mode interface 414 , an operating mode selector 416 , an operating mode identifier 418 , a call type identifier 420 , an E911 service verifier 422 , and a subscription services interface 424 , all of which may be implemented using any desired combination of hardware, firmware, and/or software.
  • one or more integrated circuits, discrete semiconductor components, or passive electronic components may be used.
  • some or all of the blocks of the example system 400 , or parts thereof, may be implemented using instructions, code, and/or other software and/or firmware, etc. stored on a machine accessible medium that, when executed by, for example, a processor system (e.g., the example processor system 810 of FIG. 8 ), perform the operations represented in the flow diagrams of FIGS. 5, 6A, 6B, and 7 .
  • the blocks of the example system 400 are distributed among various network entities in the example network system 100 of FIG. 1 .
  • the blocks of the example system 400 may be implemented using network entities other than those indicated below.
  • a network entity of the example network system 100 implements one of the blocks of the example system 400
  • that network entity may be configured to implement two or more blocks of the example system 400 or none of the blocks.
  • an example apparatus may be used to implement all of the blocks of the example system 400 and may be communicatively coupled to the example network system 100 .
  • the example system 400 to retrieve and store IP addresses (e.g., the public IP address A and B of FIG. 1 , the public IP addresses 314 of FIG. 3 , etc.), the example system 400 is provided with an IP address interface 402 .
  • the IP address interface 402 is implemented using the feature server 130 of FIG. 1 .
  • the IP address interface 402 is configured to receive public IP addresses (e.g., registration public IP addresses) via notifications from the HSS database 116 when VoIP devices register with the IMS 112 .
  • the IP address interface 402 also stores the public IP addresses in the feature server 130 . In this manner, the feature server 130 can compare the received public IP addresses with future registration public IP addresses.
  • the example system 400 is provided with an IP address comparator 404 .
  • the example system 400 compares registration public IP addresses (e.g., the public IP addresses A and B of FIG. 1 ) with registered public IP addresses (e.g., the registered public IP addresses 314 of FIG. 3 ) to determine whether VoIP devices may have been moved between geographic locations.
  • the IP address comparator 404 may be implemented using the HSS database 116 and an IP address comparator substantially similar or identical to the IP address comparator 404 may be implemented using the feature server 130 .
  • the IP address comparator 404 in the HSS database 116 can compare the public IP address A (a registration public IP address) of the site gateway 104 a with a registered public IP address that was previously registered in association with the VoIP device 106 .
  • the HSS database 116 can then determine a geographic location change status based on the comparison and allow the VoIP device 106 to register based on the geographic location change status.
  • an IP address comparator in the feature server 130 can compare registration and registered public IP addresses to determine if the feature server 130 should change VoIP device operating modes from the S 0 mode to the S 1 mode.
  • the example system 400 is provided with a user interface 406 .
  • the user interface 406 is implemented using the IVR system 124 of FIG. 1 and is configured to playback audio messages to a user via the VoIP device 106 .
  • the user interface 406 may have an audio file player or a text-to-speech converter (e.g., a speech synthesizer).
  • Example audio messages include registered street addresses associated with the VoIP device 106 and requests for user to confirm whether a registered street address is the same as a current street address of the VoIP device 106 .
  • Other example audio messages include informing a user via the VoIP device 106 of operating modes of the VoIP device 106 and information on how to update registered street addresses.
  • the user interface 406 may also be configured to communicate and/or exchange text messages and/or other messages (e.g., video messages) with the VoIP device 106 so that some or all messages described above can be presented via a display of the VoIP device 106 .
  • the functionality described in connection with the user interface 406 may be implemented using an external media server having a standard control interface, and the user interface 406 can be provided with a media server control interface to exchange information with the external media server.
  • the example system 400 is provided with a geographic location interface 408 .
  • the geographic location interface 408 is implemented using the IVR 124 of FIG. 1 and is configured to access the LIS database 142 to retrieve registered geographic location information associated with corresponding PUID's of VoIP devices.
  • a user may provide geographic location information via a web page served by the web server 122 or via a customer service representative in the customer service center 118 .
  • the web server 122 or the customer service center 118 then communicate the user-provided geographic location information to the LIS database 142 .
  • the LIS database 142 then updates registered geographic location information stored therein using the user-provided geographic location information if the validation database (“VDB”) 144 of FIG. 1 determines that the user-provided geographic location information is valid (e.g., compliant with the master street address guide (“MSAG”) standard).
  • VDB validation database
  • MSAG master street address guide
  • the example system 400 is provided with a validator 410 .
  • the validator 410 is implemented using the VDB 144 of FIG. 1 and is configured to determine whether user-provided geographic location information is MSAG-compliant. For example, if the validator 410 finds a street address stored in the VDB 144 to match the user-provided geographic location information, then the validator 410 indicates the user-provided geographic location information is valid.
  • the example system 400 is provided with a geographic location change status updater 412 .
  • the geographic location change status updater 412 is implemented using the feature server 130 of FIG. 1 and is configured to update the location change status (e.g., geographic location has not changed, geographic location may have changed, etc.) associated with a VoIP device when the IP address comparator 404 determines that a registered public IP address associated with the VoIP device 106 and a current public IP address used by the VoIP device 106 (during, for example, registration) do not match.
  • the example system 400 is provided with an operating mode interface 414 .
  • the operating mode interface 414 is implemented using the feature server 130 of FIG. 1 and is configured to store operating mode designators (e.g., the operating mode designators 320 of FIG. 3 ) in the feature server 130 and retrieve operating mode designators from the feature server 130 .
  • operating mode designators e.g., the operating mode designators 320 of FIG. 3
  • the example system 400 of FIG. 4 is provided with an operating mode selector 416 .
  • the operating mode selector 416 is implemented using the feature server 130 of FIG. 1 and is configured to select operating modes (e.g., the operating modes S 0 , S 1 , or S 2 ) based on location change statuses associated with VoIP devices, based on whether registered geographic location information is up to date, and/or based on whether VoIP devices are in locations for which VoIP service providers can provide E911 service.
  • the example system 400 of FIG. 4 is provided with an operating mode identifier 418 .
  • the operating mode identifier 418 is implemented using the feature server 130 of FIG. 1 .
  • the example system 400 is provided with a call type identifier 420 .
  • the call type identifier 420 is implemented using the feature server 130 and is configured to determine whether calls are being made to 911 or to a PUID authorized by a VoIP service provider. For example, when the VoIP device 106 is associated with the S 1 (suspended) mode, a VoIP service provider allows the VoIP device 106 to make calls only to 911 or to pre-selected, authorized numbers (e.g., a customer service number). To enable the allowed calls, the call type identifier 420 extracts information from a call initiation signal communicated by the VoIP device 106 and identifies the call type.
  • the example system 400 is provided with an E911 service verifier 422 .
  • the E911 service verifier 422 is implemented using the LIS database 142 of FIG. 1 .
  • the feature server 130 is configured to forward any 911 calls made from the VoIP device 106 to a 911 operator that will handle or process the 911 call without the location-identifying features of E911 service.
  • the example system 400 is provided with a subscription services interface 424 .
  • the subscription services interface 424 is implemented using the HSS database 116 of FIG. 1 and is configured to retrieve service options (e.g., the nomadic service designators 317 of FIG. 3 ) from subscriber accounts stored in the HSS database 116 to determine the services to which users are subscribed.
  • service options e.g., the nomadic service designators 317 of FIG. 3
  • FIGS. 5, 6A, 6B, and 7 are flowcharts representative of example machine readable instructions that may be executed to detect geographic location changes of VoIP devices, process VoIP calls initiated by VoIP devices, and update registered geographic location information associated with VoIP devices to implement the example system 400 of FIG. 4 .
  • the example machine readable instructions are described with reference to the flowcharts of FIGS. 5, 6A, 6B, and 7 , persons of ordinary skill in the art will readily appreciate that other methods of detecting geographic location changes, processing VoIP calls, updating geographic location changes and, generally, implementing the example system 400 of FIG. 4 may additionally or alternatively be used.
  • the order of execution of the blocks depicted in the flowcharts of FIGS. 5, 6A, 6B, and 7 may be changed, and/or some of the blocks described may be rearranged, eliminated, or combined.
  • FIG. 5 is a flowchart representative of example machine readable instructions that may be executed to determine whether the VoIP device 106 may have been moved to another geographic location.
  • the VoIP device 106 of FIGS. 1 and 2 registers with the IMS 112 (block 502 ).
  • the HSS database 116 can prevent the VoIP device 106 from registering if the subscription services interface 424 ( FIG. 4 ) determines that the VoIP device 106 is not nomadic-enabled.
  • the HSS database 116 does allow the VoIP device 106 to register, but registration is not complete (block 504 )
  • the process of FIG. 5 waits at block 504 until registration is complete.
  • the IP address comparator 404 determines whether the public IP address (e.g., the public IP address A of FIG. 1 ) associated with the VoIP device 106 has changed (i.e., if the registration public IP address used to register the VoIP device is different from the previously registered public IP address stored in the feature server 130 of FIG. 1 ) (block 506 ).
  • the public IP address e.g., the public IP address A of FIG. 1
  • the registration public IP address used to register the VoIP device is different from the previously registered public IP address stored in the feature server 130 of FIG. 1
  • the IP address interface 402 stores the registration public IP address of the VoIP device 106 in the feature server 130 .
  • the IP address comparator 404 retrieves the registered public IP address and the registration public IP address from the feature server 130 and compares the IP addresses to determine whether they are identical (block 506 ).
  • the public IP addresses can be identical if the VoIP device 106 registers or attempts to register from the same network location (e.g., the subscriber site 102 a of FIG.
  • the VoIP operating mode may be set to the S 1 (suspended) mode if the user of the VoIP device 106 does not confirm or update the registered geographic location information.
  • the example system 400 will limit operation of the VoIP device 106 to the S 1 (suspended) mode until the user confirms or updates the registered geographic location information.
  • the operating mode identifier 418 determines whether the operating mode associated with the VoIP device 106 is set to the S 0 (unrestricted) mode (block 508 ).
  • the operating mode interface 414 retrieves the current operating mode designator (e.g., one of the operating mode designators 320 of FIG. 3 ) associated with the VoIP device 106 from the feature server 130 of FIG. 1 and the operating mode identifier 418 determines whether the operating mode designator indicates the S 0 (unrestricted) operating mode (block 508 ).
  • the operating mode identifier 418 determines if the VoIP device operating mode is set to the S 2 (restricted) operating mode (block 510 ).
  • the geographic location change status updater 412 updates the location change status associated with the VoIP device 106 to “suspected location change” (block 512 ) to indicate that the VoIP device 106 may have been moved to a different geographic location.
  • the operating mode selector 416 sets the operating mode associated with the VoIP device 106 to the S 1 (suspended) mode (block 514 ).
  • the operating mode selector 416 may be configured to confirm at block 514 that the operating mode associated with the VoIP device 106 is set to the S 1 (suspended) mode.
  • the operating mode interface 414 then stores the current operating mode associated with the VoIP device (block 516 ) in, for example, the feature server 130 of FIG. 1 (e.g., in the operating mode column 318 of FIG. 3 ). Also, the IP address interface 402 updates the registered public IP address associated with the VoIP device 106 (block 518 ) in, for example, the feature server 130 of FIG. 1 (e.g., in the public IP address column 312 of FIG. 3 ) by replacing the previously registered public IP address with the registration public IP address received at block 502 .
  • the example system 400 determines whether it should continue monitoring VoIP device registration events (block 520 ). For example, the example system 400 may determine not to continue monitoring if the monitoring operation of the example system 400 is disabled by a VoIP service provider or if the monitoring operation of the example system 400 is interrupt driven and monitors only upon detection of particular events (e.g., a VoIP device plugged into the network). In an example implementation, the example system 400 is preferably, but not necessarily, configured to continuously monitor VoIP device registration events, and block 520 always returns control to block 502 .
  • control returns to block 502 for a subsequent registration of the VoIP device 106 or any other VoIP device. Otherwise, if the example system 400 determines that it should not continue monitoring for an IP address change (block 502 ), then the process of FIG. 5 is ended and/or control is returned to a calling function or process.
  • the example process of FIG. 5 uses the registered public IP address and the current public IP address (the registration public IP address) associated with the VoIP device 106 to determine whether the VoIP device 106 may have changed geographic locations, in alternative example implementations, other example methods may be used to detect geographic location changes of the VoIP device 106 .
  • FIGS. 6A and 6B are a flowchart representative of example machine readable instructions that may be executed to process a VoIP call initiated by an example VoIP device 106 .
  • the VoIP device 106 initiates a call (block 602 ).
  • the VoIP device 106 communicates a call initiation request to the CSC 128 of FIG. 1 and the CSC 128 uses the feature server 130 to initiate and process the call.
  • the operating mode identifier 418 ( FIG. 4 ) then determines whether the operating mode associated with the VoIP device 106 is set to an S 0 (unrestricted) operating mode (block 604 ).
  • the operating mode interface 414 retrieves the operating mode designator (e.g., one of the operating mode designators 320 of FIG. 3 ) associated with the VoIP device 106 from the feature server 130 and the operating mode identifier 418 determines whether the retrieved operating mode designator indicates the S 0 (unrestricted) mode (block 604 ).
  • the operating mode designator e.g., one of the operating mode designators 320 of FIG. 3
  • the call type identifier 420 determines whether the call being initiated is a call to 911 or a call to an authorized telephone number (block 606 ) (e.g., a customer service telephone number authorized by the VoIP service provider).
  • the CSC 128 completes initiation of the call (block 608 ).
  • the operating mode identifier 418 determines whether the VoIP device operating mode is set to an S 1 (suspended) operating mode (block 610 ). If the operating mode identifier 418 determines that the VoIP device operating mode is not set to an S 1 (suspended) operating mode (block 610 ) (i.e., the operating mode is instead set to the S 2 (restricted) mode), the user interface 406 presents a message via the VoIP device 106 to inform a user of the VoIP device 106 that the VoIP device 106 is within a location in which the VoIP service provider of the VoIP device 106 cannot provide E911 service (block 612 ). In the illustrated example, the message is an audio message presented by, for example, the IVR system 124 of FIG. 1 , but any other desired messaging medium may be employed.
  • the geographic location information interface 408 retrieves registered geographic location information (e.g., a street address) associated with the VoIP device 106 (block 614 ).
  • the geographic location information interface 408 accesses the LIS database 142 to retrieve the registered street address stored in association with the PUID of the VoIP device 106 .
  • the user interface 406 then presents the registered geographic location information via the VoIP device 106 (block 616 ) and requests the user of the VoIP device 106 to confirm whether the registered geographic location is the same as the current geographic location of the VoIP device 106 (block 618 ).
  • the IVR system 124 of FIG. 1 implements the user interface 406 and performs a text-to-speech conversion of the registered street address to present an audio message via the VoIP device 106 .
  • the LIS database 142 may store audio files (e.g., WAV files) of registered street addresses and the IVR system 124 may play back the audio files via the VoIP device 106 .
  • the registered geographic location information may be presented (block 616 ) via text or video on a display screen of the VoIP device 106 and/or other user interface screens may be used to request the user to confirm the location of the VoIP device 106 (block 618 ).
  • the NMS 114 then stores the user response regarding whether the registered geographic location is the same as the current geographic location of the VoIP device 106 (block 620 ).
  • the user interface 406 communicates the user response to the NMS 114 along with the user's PUID and a date and time stamp of when the user responded, and the NMS 114 stores the user's PUID in association with the date and time stamp. In this manner, the VoIP service provider can keep records of whether and when users confirmed their geographic location.
  • the geographic location change status updater 412 determines whether the user confirmed that the registered geographic location of the VoIP device 106 is the same as the current geographic location of the VoIP device 106 (block 622 ) ( FIG. 6B ) based on, for example, the user response requested at block 618 . For example, the geographic location change status updater 412 determines that the registered geographic location of the VoIP device 106 is the same as the current geographic location if the user response confirmed (e.g., “Yes”) that the registered geographic location of the VoIP device 106 is the same as the current geographic location.
  • the user interface 406 determines that the geographic locations are not the same or after the user interface 406 informs the user that the VoIP device is within a location in which the VoIP service provider cannot provide E911 service (block 612 ), the user interface 406 presents a website uniform resource locator (“URL”) address via the VoIP device (block 632 ) that the user can visit to provide updated geographic location information and/or to obtain more information on the messages presented by the user interface 406 . Additionally or alternatively, the user interface 406 offers to connect the user to a customer service agent (block 634 ) at the customer service center 118 of FIG. 1 . If the user elects to be connected to a customer service agent (block 636 ), then the user interface 406 connects the call to a customer service agent (block 638 ).
  • a customer service agent block 634
  • the geographic location change status updater 412 determines that the user confirmed that the geographic locations are the same, the operating mode selector 416 changes the VoIP device operating mode to the S 0 (unrestricted) mode and the operating mode interface 414 stores the operating mode (block 640 ) in, for example, the feature server 130 of FIG. 1 .
  • the CSC 128 of FIG. 1 then completes the call (block 642 ).
  • the example process of FIGS. 6A and 6B then returns control to a calling function or process and/or ends.
  • FIG. 7 is a flowchart representative of example machine readable instructions that may be executed to update a registered geographic location associated with the VoIP device 106 .
  • the web server 122 of FIG. 1 receives the user-provided geographic location information (block 704 ) such as, for example, a user-provided street address.
  • the web server 122 then communicates the user-provided geographic location information to the LIS database 142 of FIG. 1 .
  • a customer service representative at the customer service center 118 receives the user-provided geographic location information (block 708 ) from the user of the VoIP device 106 , the customer service representative communicates the user-provided geographic location information to the LIS database 142 (block 710 ).
  • the validator 410 determines whether the user-provided geographic location information is MSAG-compliant (i.e., valid) (block 712 ).
  • the user-provided geographic location information is a street address that the validator 410 compares with addresses stored in the validation database (“VDB”) 144 of FIG. 1 to determine if the user-provided street address is MSAG-compliant. If the user-provided geographic location information is MSAG-compliant (block 712 ), the geographic location information interface 408 updates the registered geographic location information in the LIS database 142 with the user-provided geographic location information (block 714 ).
  • the E911 service verifier 422 determines whether the VoIP service provider of the VoIP device 106 can provide E911 service at the user-provided geographic location (block 716 ). If the VoIP service provider cannot provide E911 service at the user-provided geographic location (block 716 ), the NMS 114 instructs the operating mode selector 416 ( FIG. 4 ) to change the operating mode associated with the VoIP device 106 to the S 2 (restricted) mode and stores the restricted mode designator (block 720 ) in, for example, the feature server 130 .
  • the validator 410 determines that the user-provided geographic location information is not MSAG-compliant (block 712 )
  • the web server 122 or the customer service representative assisting the user of the VoIP device 106 informs the user that the user-provided geographic location information (e.g., the street address) is not valid (block 724 ).
  • the user must then provide another geographic location.
  • the geographic location information may not be MSAG-compliant due to a typographical error, a missing zip code, or some other trivial mistake, and the user need merely re-type the geographic location information.
  • the web server 122 or the customer service representative assisting the user of the VoIP device 106 determines whether to end the geographic address update process (block 726 ). For example, the web server 122 may determine that it should end the process if the user of the VoIP device 106 has closed or logged out of the web page used to update the geographic location information, and/or the customer service representative may determine to end the process if the user has elected to end the call with the customer service representative. If the web server 122 or the customer service representative determines that the geographic location information update process should not end, then control is passed back to block 702 . Otherwise, the process of FIG. 7 ends.
  • FIG. 8 is a block diagram of an example processor system 810 that may be used to implement the example apparatus, methods, and articles of manufacture described herein.
  • processor systems substantially similar or identical to the example processor system 810 may be used to implement the site gateways 104 a - b , the network management system 114 , the HSS database 116 , the web server 122 , the IVR system 124 , the emergency services gateway 132 , the call session controller 128 , the feature server 130 , the LIS database 142 , the validation database 144 , and/or the VPC 148 , all shown in FIG. 1 .
  • processor systems substantially similar or identical to the example processor system 810 may be used to implement the IP address interface 402 , the IP address comparator 404 , the user interface 406 , the geographic location information interface 408 , the validator 410 , the geographic location change status updater 412 , the operating mode interface 414 , the operating mode selector 416 , the operating mode identifier 418 , the call type identifier 420 , the E911 service verifier 422 , and/or the subscription services interface 424 of the example system 400 of FIG. 4 .
  • the processor system 810 includes a processor 812 that is coupled to an interconnection bus 814 .
  • the processor 812 includes a register set or register space 816 , which is depicted in FIG. 8 as being entirely on-chip, but which could alternatively be located entirely or partially off-chip and directly coupled to the processor 812 via dedicated electrical connections and/or via the interconnection bus 814 .
  • the processor 812 may be any suitable processor, processing unit or microprocessor.
  • the system 810 may be a multi-processor system and, thus, may include one or more additional processors that are identical or similar to the processor 812 and that are communicatively coupled to the interconnection bus 814 .
  • the processor 812 of FIG. 8 is coupled to a chipset 818 , which includes a memory controller 820 and an input/output (I/O) controller 822 .
  • a chipset provides I/O and memory management functions as well as a plurality of general purpose and/or special purpose registers, timers, etc. that are accessible or used by one or more processors coupled to the chipset 818 .
  • the memory controller 820 performs functions that enable the processor 812 (or processors if there are multiple processors) to access a system memory 824 and a mass storage memory 825 .
  • the system memory 824 may include any desired type of volatile and/or non-volatile memory such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc.
  • the mass storage memory 825 may include any desired type of mass storage device including hard disk drives, optical drives, tape storage devices, etc.
  • the I/O controller 822 performs functions that enable the processor 812 to communicate with peripheral input/output (I/O) devices 826 and 828 and a network interface 830 via an I/O bus 832 .
  • the I/O devices 826 and 828 may be any desired type of I/O device such as, for example, a keyboard, a video display or monitor, a mouse, etc.
  • the network interface 830 may be, for example, an Ethernet device, an asynchronous transfer mode (ATM) device, an 802.11 device, a digital subscriber line (DSL) modem, a cable modem, a cellular modem, etc. that enables the processor system 810 to communicate with another processor system.
  • ATM asynchronous transfer mode
  • 802.11 802.11
  • DSL digital subscriber line
  • memory controller 820 and the I/O controller 822 are depicted in FIG. 8 as separate functional blocks within the chipset 818 , the functions performed by these blocks may be integrated within a single semiconductor circuit or may be implemented using two or more separate integrated circuits.
  • At least some of the above described example methods and/or apparatus are implemented by one or more software and/or firmware programs running on a computer processor.
  • dedicated hardware implementations including, but not limited to, an ASIC, programmable logic arrays and other hardware devices can likewise be constructed to implement some or all of the example methods and/or apparatus described herein, either in whole or in part.
  • alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the example methods and/or apparatus described herein.
  • example software and/or firmware implementations described herein are optionally stored on a tangible storage medium, such as: (1) a magnetic medium (e.g., a disk or tape); (2) a magneto-optical or optical medium such as a disk; or (3) a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories. Accordingly, the example software and/or firmware described herein can be stored on a tangible storage medium such as those described above or equivalents and successor media.

Abstract

An example apparatus includes a memory and a call session controller. The memory is to store a first public user identifier in association with a first nomadic service designator and a first operating mode designator, and to store a second public user identifier in association with a second nomadic service designator and a second operating mode designator. The call session controller is to determine whether a first call using the first public user identifier is eligible to be established based on the first nomadic service designator and the first operating mode designator, and determine whether a second call using the second public user identifier is eligible to be established based on the second nomadic service designator and based on the second operating mode designator.

Description

PRIORITY APPLICATION
This patent arises from a continuation of U.S. patent application Ser. No. 14/021,828, filed Sep. 9, 2013, which is a continuation of U.S. patent application Ser. No. 11/555,569, filed Nov. 1, 2006, now U.S. Pat. No. 8,531,995, all of which are hereby incorporated herein by reference in their entireties.
FIELD OF THE DISCLOSURE
The present disclosure relates generally to communication systems and, more particularly, to systems and methods for location management and emergency support for a voice over internet protocol device.
BACKGROUND
Internet protocol-enabled telecommunication providers in the United States are required by the Federal Communications Commission (“FCC”) to support enhanced 911 (“E911”) emergency call services. That is, when a telephone user dials 9-1-1, the telecommunication carrier must be able to process the call to determine the geographic location from where the call is originated to enable dispatching emergency personnel to the location of the 911 caller. Enhanced 911 service differs from traditional (non-enhanced) 911 service in that E911 service routes an emergency call to a 911 dispatcher and provides the dispatcher with the geographic location (e.g., street address) from which the call originated, while traditional 911 service routes an emergency call to a 911 dispatcher without providing the dispatcher with geographic location information indicating where the call originated.
In traditional public switched telephony networks (“PSTN”), the geographic information retrieval support for E911 is implemented by fixing associations between wireline telephone numbers and geographic street addresses. Telecommunication providers usually store a subscriber's location (e.g., a street address) in a database associated with an assigned telephone number (e.g., a call back number (“CBN”)) during the service activation. When a PSTN user makes a 911 call, the calling telephone number (i.e., the CBN) of the incoming 911 call can be used to look up the geographic location of the caller, and the retrieved location information can be used to dispatch emergency personnel to the caller.
The introduction of voice over IP (“VoIP”) technology introduces various challenges to service providers seeking to support E911 services. In particular, under a nomadic service (i.e., a service allowing subscribers to connect VoIP telephones at various network locations), a VoIP subscriber can easily disconnect a VoIP telephone from one location (e.g., the subscriber's home or workplace), connect the VoIP telephone in another location (e.g., a visited local area network (“LAN”), a coffee shop, a vacation spot, etc.), and register the VoIP telephone with the VoIP service provider to place telephone calls from the other location. This nomadic capability of VoIP phones introduces the potential for inaccurate associations between telephone numbers and physical or geographic locations.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic diagram depicting an example network system.
FIG. 2 illustrates an example implementation of the site gateway of FIG. 1.
FIG. 3 is an example data structure showing account information associated with a VoIP service subscription.
FIG. 4 is a block diagram of an example system to provide E911 service to VoIP devices.
FIG. 5 is a flowchart representative of example machine readable instructions that may be executed to determine whether a VoIP device may have been moved to another geographic location.
FIGS. 6A and 6B depict a flowchart representative of example machine readable instructions that may be executed to process a VoIP call initiated by a VoIP device.
FIG. 7 is a flowchart representative of example machine readable instructions that may be executed to update a registered geographic location associated with a VoIP device.
FIG. 8 is a block diagram of an example processor system that may be used to execute the example machine readable instructions of FIGS. 5, 6A, 6B, and/or 7 to implement the example system of FIG. 4.
DETAILED DESCRIPTION
The example methods and apparatus described herein may be used to manage location information associated with voice over internet protocol (“VoIP”) devices to support E911 services for those VoIP devices. Traditional E911 services based on the plain old telephone system (“POTS”) provide POTS telephone service subscribers with emergency assistance service that is capable of pinpointing the geographic calling location of a caller for emergency personnel (e.g., firemen, policemen, paramedics, etc.). In this manner, although a caller may be unable to speak into the telephone due to, for example, illness or injury, the receiving 911 dispatcher can obtain a physical address or geographic location from which the caller is calling and dispatch emergency personnel to that location. Unlike traditional POTS telephone service, which is implemented in connection with traditional wireline telephone numbers that are associated with corresponding fixed geographic locations (e.g., a subscriber's home street address), IP-enabled communication services (e.g., VoIP services) do not always restrict an IP telephone number to being permanently associated with or assigned to (e.g., located at) a particular geographic location. Instead, some VoIP service providers enable a VoIP device associated with a particular telephone number to nomadically move or roam through a service provider network or through various service provider networks. That is, a subscriber may disconnect a VoIP device from a service provider network at a first location (e.g., the subscriber's home) and reconnect the VoIP device into the same service provider network or a different service provider network at a second location (e.g., a work place). The example systems and methods described herein enable service provider networks to provide E911 services to subscribers even though these subscribers move their VoIP devices between various locations. As described in greater detail below, the example systems and methods determine when a VoIP device has been moved between two network locations and prompt a user of the moved VoIP device to confirm a geographic location change and/or provide updated geographic location information (e.g., a current street address) associated with the current network location of the VoIP device. Some example implementations determine when a VoIP device is not eligible for nomadic use and deny VoIP services to nomadic-disabled devices when they identify an attempt to operate the VoIP device in a network location different from the VoIP devices registered location. Alternatively or additionally, the example systems and methods can be used to deny service to VoIP devices connected to networks or portions of a network for which a VoIP service provider cannot provide E911 service. A VoIP service provider may be a telephone company, a cable company, a satellite company, an Internet service provider, a utility (e.g., electricity) service provider, etc.
Some disclosed example methods of managing location information for emergency support of a VoIP communication device involve determining a geographic location change status associated with the internet protocol device. A message (e.g., an audio message, a text message, a video message, etc.) is then presented via the VoIP device based on the geographic location change status requesting a user to confirm whether a registered geographic location (e.g., a street address) associated with the VoIP device is a current geographic location of the VoIP device.
In some example implementations, a current IP address associated with the VoIP device (e.g., a registration public IP address used by the VoIP device to register with a VoIP network) is used to determine the geographic location change status of the VoIP device. For example, the current IP address can be compared to a previous IP address (e.g., a registered IP address) registered in associated with the VoIP device. If the current IP address and the previous IP address differ, the geographic location change status is updated to indicate that the geographic location of the VoIP device may have changed from a geographic location previously registered in association with the VoIP device. A network server (e.g., a dynamic host configuration protocol (“DHCP”) server) may assign the current IP address to the VoIP device or to a network access device (e.g., a residential gateway) connected to the VoIP device and through which the VoIP device accesses network services.
A service provider network may use the geographic location change status to set an operating mode of the VoIP device. In an example implementation, a geographic location change status indicating that the VoIP device has not moved to another geographic location corresponds to an unrestricted operating mode (S0 mode) that enables the VoIP device to access substantially all subscribed to communication services provided by a service provider associated with the VoIP device. Another geographic location change status of the illustrated example indicating that the VoIP device may have moved to another geographic location corresponds to a suspended operating mode (S1 mode) that restricts the VoIP device to accessing a subset of all otherwise available communication services provided by a service provider. For example, in the suspended operating mode, the VoIP device may be allowed to receive VoIP calls and make VoIP calls to one or more telephone numbers (e.g., a customer service telephone number, a 911 operator) pre-selected by a VoIP service provider. Yet another geographic location change status of the illustrated example indicating that the IP device is located within a geographic location at which a VoIP service provider cannot provide emergency service (e.g., E911 service) corresponds to a restricted operating mode (S2) that may allow access to the same or less (e.g., none) services than the suspended (S1) operating mode.
In some example implementations, the operating mode may be selected by a service provider network based on a user's response to a message presented via the VoIP device. For example, the service provider network may select a particular operating mode if the user confirms that the registered geographic location is the same as the currently logged geographic location. Additionally or alternatively, the service provider network may determine whether the IP device is eligible to roam (i.e., the VoIP device is nomadic-enabled) between different network locations of the service provider network. The service provider network can then select an operating mode that denies access to at least some services if the VoIP device is not eligible to roam. (i.e., the VoIP device is nomadic-blocked). After setting the operating mode of the VoIP device, another message (e.g., an audio message, a text message, a video message, etc.) may be presented via the VoIP device to inform a user of the operating mode change and/or the reason for the change.
Some disclosed example systems to manage location information for emergency support of a VoIP communication device include an interface configured to receive a current IP address (i.e., a registration IP address) associated with the VoIP device. These example systems also include a comparator configured to compare the current IP address with a registered IP address. The comparison indicates that the VoIP device may have been moved (e.g., a suspected location change) or that the VoIP device has not been moved. If a suspected location change is indicated, the system may interact with the user to confirm and/or update records to reflect the current geographic location. For instance, the example system includes a user interface (e.g., an interactive voice response (“IVR”) interface) configured to present a message (e.g., an audio message, a text message, a video message, etc.) via the VoIP device based on the comparison requesting a user to confirm whether a registered geographic location (e.g., a street address) associated with the VoIP device is the same as a current geographic location of the VoIP device and/or to identify the current geographic location of the VoIP device.
The response may indicate that the VoIP device has been moved or has not been moved from a first geographic location to a second geographic location. The user interface may be further configured to instruct the user to navigate to an internet location (e.g., a webpage) to update the registered geographic location when, for example, the response indicates that the VoIP device has been moved from a first geographic location to a second geographic location.
The current IP address (i.e., the registration IP address) may be assigned to the VoIP device or to a network access device (e.g., a residential gateway, a site gateway, etc.) connected to the VoIP device and through which the VoIP device accesses network services. In some example implementations, the current IP address is different from the registered IP address. For example, the registered IP address may be associated with a geographic location within which the VoIP device was located prior to being associated with the current IP address. In some example implementations, the system includes a data structure configured to store the registered IP address associated the VoIP device.
To select an operating mode associated with the VoIP device based on the comparison of the current IP address and the registered IP address, some example systems are provided with a mode selector. The mode selector may also select the operating mode based the user's response to the message. In an example implementation, the mode selector is configured to set the operating mode to restrict the VoIP device to access a subset of all communication services associated with a service subscription corresponding to the VoIP device. The system may also be provided with a services interface configured to determine whether the VoIP device is eligible for nomadic use and configured to cause the mode selector to set the operating mode to deny access to at least some services if the VoIP device is not eligible for nomadic use.
As will be readily apparent to persons of ordinary skill in the art, the example methods, apparatus, and systems described herein may be implemented using instructions stored on one or more machine accessible media (e.g., a CD-ROM, a magnetic storage device, an optical storage device, a solid-state storage device, etc.) associated with one or more network system devices. In this manner, the machine accessible media may be used to enable network system devices to retrieve and execute the instructions to implement the example methods, apparatus, and systems described herein.
An example network system 100 is shown in FIG. 1. The example system 100 of FIG. 1 includes subscriber sites 102 a and 102 b. Each of the subscriber sites 102 a and 102 b includes a respective subscriber site gateway 104 a and 104 b (e.g., a residential gateway). The subscriber sites 102 a-b may be residential dwellings and/or business sites (e.g., a coffee shop, an education facility, an office, an industrial building, etc.), and may have separate respective LAN's and/or PBX's located therein which are communicatively coupled to a respective one of the site gateways 104 a-b. In the illustrated example, the site gateways 104 a and 104 b are used to provide user equipment (e.g., VoIP devices, computers, etc.) network access to the example network system 100 and may be implemented using wire-interface gateways (e.g., wired Ethernet, IEEE-802.3, Universal Serial Bus (“USB”), etc.) or wireless gateways (e.g., wireless Ethernet, IEEE-802.11, Wi-Fi®, Bluetooth®, etc.).
In the illustrated example, a VoIP device 106 (e.g., a wired or wireless VoIP telephone, a plain old telephone system (“POTS”) analog telephone connected to an analog telephone adapter (“ATA”), a wired or wireless IP data/voice communicator, a personal desktop, laptop, or tablet computer having VoIP capabilities, etc.) is communicatively coupled to the subscriber site gateway 104 a. The site gateway 104 a provides the VoIP device 106 network access to an Internet protocol (“IP”) network 108, which may include one or more Internet service provider (“ISP”) networks. The VoIP device 106 is capable of making VoIP calls via the example IP network 108. The IP network 108 includes a function that assigns public IP addresses to the site gateways 104 a-b. In the illustrated example, the function to assign public IP addresses may be implemented using, for example, a dynamic host configuration protocol (“DHCP”) server 110. As shown in the illustrated example of FIG. 1, the first site gateway 104 a is assigned a public IP address A and the second site gateway 104 b is assigned a public IP address B. Although two subscriber sites (i.e., the subscriber sites 102 a-b) and two site gateways (i.e., the site gateways 104 a-b) are shown in FIG. 1, any number of subscriber sites and site gateways may be used in connection with the examples described herein.
In the illustrated example, the VoIP device 106 can be associated with a non-nomadic service (i.e., a nomadic-blocked service) or a nomadic service (i.e., a nomadic-enabled service). A non-nomadic service limits the VoIP device 106 to making VoIP calls from only a pre-selected network location (e.g., from only the subscriber site 102 a). Under a non-nomadic service, the VoIP device 106 may be used to make VoIP calls from, for example, the subscriber site 102 a, but not from the subscriber site 102 b. In contrast, a nomadic service allows the VoIP device 106 to make calls from a plurality of network locations. That is, in the illustrated example, the VoIP device 106 can be used to make VoIP calls from both of the subscriber sites 102 a-b. A subscriber or user can change the nomadic option for the VoIP device 106 via the user's account. In some example implementations, the VoIP device 106 may be associated with a plurality of telephone numbers. For each telephone number, a user can select a different nomadic option. In this manner, when the VoIP device 106 is used from a home location (e.g., the subscriber site 102 a), any of a plurality of telephone numbers associated with the VoIP device 106 can be used to make VoIP calls. However, when the VoIP device 106 is connected to a visiting site (e.g., the subscriber site 102 b), only those telephone numbers associated with a nomadic option can be used to make VoIP calls.
To enable VoIP services, the example network system 100 is provided with an internet protocol multimedia subsystem (“IMS”) 112. The IMS 112 enables different communication technologies (e.g., features, services, communication software and equipment, etc.) to work together to deliver enriched communications (e.g., VoIP communications) to subscribers. The IMS 112 of the illustrated example is implemented according to one or more industry standard specifications. Although the IMS 112 is used in the illustrated example, the example systems and methods described herein may be used in connection with IP multimedia and telephony core network architectures other than the IMS 112. For example, IP multimedia and telephony core network architectures other than the IMS 112 may be used to enable VoIP services in the example network system 100.
To manage subscriber services, the IMS 112 is provided with a network management system (“NMS”) 114 that is communicatively coupled to a home subscriber services (“HSS”) database 116. In the illustrated example, the NMS 114 is used to manage and track which subscribers have subscribed to which features or services and to enable access to those features by subscribers. The NMS 114 stores records in the HSS database 116 indicative of subscriber's respective features and services. To implement a service change (e.g., provisioning, a device registration, an upgrade, an update, etc.), the NMS 114 is notified of the service change, and the NMS 114 stores information in the HSS database 116 indicative of the service change. In the illustrated example, the NMS 114 is also configured to receive and process the initial geographic location information (e.g., street addresses) associated with a VoIP device (e.g., the VoIP device 106) when VoIP service is initially provisioned.
To allow subscribers to interact with customer service representatives, the NMS 114 is coupled to a customer service center 118. In the illustrated example, a subscriber can interact with a customer service representative at the customer service center 118 to change a nomadic option associated with the VoIP device 106. In addition, when the VoIP device 106 is moved to a different geographic location, the subscriber can interact with the customer service representative to provide the street address of the new geographic location. In addition, to enable a subscriber to access a web page to change nomadic options and/or to provide the street address of current geographic location, the IMS 112 is provided with a web server 122.
To inform a subscriber of a suspected geographic location change, the IMS 112 is provided with an interactive voice response (“IVR”) system 124. When a subscriber initiates a VoIP call via the VoIP device 106, the IVR system 124 is configured to playback an audio message via the VoIP device 106 when a VoIP service provider detects that the VoIP device 106 may have been moved to a different geographic location (e.g. moved from the subscriber site 102 a to the subscriber site 102 b). The IVR system 124 may include a sound file player and/or a text-to-speech converter (e.g., a speech synthesizer) to present one or more audio messages.
In the illustrated example, the IVR message plays back a previously registered street address or last known registered street address of the VoIP device 106 and requests the subscriber of the VoIP device 106 to confirm whether the registered street address is the same as the current street address at which the VoIP device 106 is located. The subscriber can then confirm that the street addresses are the same or, if the street addresses are different, the subscriber can change the registered street address via the IVR 124, a customer service representative, or an account web page served by the web server 122. Additionally or alternatively, the subscriber can contact the customer service center 118 to change the registered street address.
To control and process call sessions of VoIP devices (e.g., the VoIP device 106), the IMS 112 is provided with a call session controller (“CSC”) 128. The call session controller 128 implements a call session control function (“CSCF”) that determines whether a call should be established and which features or services should be used to establish the call based on subscribed features or services (e.g., nomadic-enabled service, calls to a PSTN allowed, etc.) of a subscriber.
The IMS 112 is also provided with a feature server 130. The feature server 130 stores the registration (current) public IP addresses (e.g., the public IP address A of the site gateway 104 a) used by VoIP devices (e.g., the VoIP device 106) to register with the IMS 112. That is, when the VoIP device 106 registers with the IMS 112, the HSS 116 receives the public IP address A (i.e., a registration public IP address) used by the VoIP device 106 to register. The HSS 116 then forwards a notification including the public IP address A to the feature server 130, and the feature server 130 stores the public IP address A for future comparisons with other registration IP addresses that the VoIP device 106 may use to register. In addition to storing the public IP address A, the feature server 130 also associates itself with the VoIP device 106 for the duration of its registration. In the illustrated example, the feature server 130 also compares each registration public IP address with a corresponding registered public IP address (i.e., a public IP address used previously by the VoIP device 106 to register with the IMS 112) to determine a location change status (e.g., determine whether the VoIP device 106 may have moved from one geographic location to another).
The feature server 130 also stores the current operating mode (e.g., the unrestricted operating mode (S0 mode), the suspended operating mode (S1 mode), or the restricted mode (S2 mode)) associated with each VoIP device registered with the IMS 112. In the illustrated example, the feature server 130 is configured to change operating modes from the unrestricted operating mode (S0 mode) to the suspended operating mode (S1 mode) based on comparisons of registration public IP addresses with registered public IP addresses. For example, if the feature server 130 determines that the registration public IP address A associated with the VoIP device 106 is different from a registered public IP address associated with the VoIP device 106, the feature server 130 determines that the VoIP device 106 may have been moved from one geographic location to another. In response, the feature server 130 changes the operating mode associated with the VoIP device 106 to the suspended operating mode (S1 mode) to allow the VoIP device 106 to receive calls and/or to make calls to phone numbers pre-selected by a VoIP service provider such as, for example, a customer service phone number, but to block calls to other (non-preselected) phone numbers.
The feature server 130 is also configured to change operating modes to the suspended operating mode (S1 mode) or the restricted mode (S2 mode) at the direction of the NMS 114. For example, if the user of the VoIP device 106 registers a geographic address that is in a location for which E911 services cannot be provided, the NMS 114 can instruct the feature server 130 to change the operating mode associated with the VoIP device 106 to the restricted mode (S2 mode). The NMS 114 can also instruct the feature server 130 to change the operating mode associated with a VoIP device 106 from the restricted operating mode (S2) to the suspended operating mode (S1).
The feature server 130 is configured to determine the type of message to be presented to a user by the IVR 124 based on, for example, the operating mode associated with the VoIP device 106. In the illustrated example, when the IMS 112 processes a call from the VoIP device 106 while the operating mode of the VoIP device 106 is set to the S1 mode or the S2 mode, the feature server 130 routes the call to the IVR 124 and instructs the IVR 124 to present a message (e.g., playback an audio announcement) and/or obtain a confirmation response (e.g., a response confirming the correctness of a registered geographic address) from a user. For example, the feature server 130 may instruct the IVR 124 to present a message requesting a user to confirm whether the registered geographic location of the VoIP device 106 is correct and, if not, requesting the user to provide an updated geographic street address of the new location. In the illustrated example, the feature server 130 is also configured to change operating modes associated with the VoIP device 106 from the restricted operating mode (S1) to the unrestricted operating mode (S0) based on the confirmation response. For example, the feature server 130 can change the operating mode of the VoIP device 106 from S1 to S0 when the user confirms that the registered geographic location presented by the IVR 124 is correct.
Also, the feature server 130 informs the IVR 124 from where to obtain the registered geographic address of the VoIP device 106. In example implementations in which audio files (e.g., .wav files) are used by the IVR 124 to playback registered geographic addresses to users, the feature server 130 is configured to store uniform resource locator (URL) addresses corresponding to network locations (e.g., servers, network directories, etc.) in which the audio files are stored.
To route emergency calls, the IMS 112 is provided with an emergency services gateway (“ESGW”) 132. The emergency services gateway 132 uses information received via an emergency call's call setup signaling to determine a path (e.g., a trunk) via which to route the emergency call for E911 handling.
To handle emergency calls, the example network system 100 is provided with a public safety answering point (“PSAP”) 134. The PSAP 134 corresponds to a particular geographic area, and dispatchers at the PSAP 134 handle emergency calls originating from VoIP devices within that geographic area. In this manner, dispatchers can dispatch emergency services personnel from a location nearest the geographic location of a 911 caller. Although one PSAP is shown, the example network system 100 may be implemented using any number of PSAP's, each corresponding to one or more respective geographic area(s).
To route emergency calls to the PSAP 134, the example network system 100 is provided with a 911 selective router 136. The 911 selective router 136 routes emergency calls to the correct PSAP based on information received from the emergency services gateway 132 and a selective routing database (“SRDB”) 138. For example, during an emergency call, the emergency services gateway 132 communicates an emergency services query key (“ESQK”) to the 911 selective router 136. The ESQK is a call identifier that represents an emergency call for the duration of the call and is used by the selective router 136 to route an emergency call to the correct PSAP (e.g., the PSAP 134).
After the 911 selective router 136 receives the ESQK from the emergency services gateway 132, the 911 selective router 136 forwards the ESQK to the SRDB 138 to obtain an emergency service number (“ESN”) identifying a PSAP to which to route the emergency call. The SRDB 138 stores ESQK's in association with respective ESN's. An ESN is a number used to indicate a particular group of emergency service agencies (e.g., police department, fire department, medical agency) that serves a particular geographic area and facilitates routing an emergency call to the PSAP that serves that geographic area.
To enable the example network system 100 to implement operations associated with receiving and processing emergency calls made from VoIP devices (e.g., the VoIP device 106), the example network system 100 is provided with an i2 E911 system 140. To store street addresses in association with respective telephone numbers of VoIP devices and to determine whether a call is originating from a geographic area in which a corresponding VoIP service provider can provide E911 services, the i2 E911 system 140 is provided with a location identification server (“LIS”) database 142. In the illustrated example, the LIS database 142 stores a record for each telephone number of the VoIP device 106, and each record is used to store the geographic location (e.g., the street address) of the subscriber site 102 a in association with the telephone number in that record. The NMS 114 communicates initial geographic location information (e.g., initial street addresses) to the LIS database 142 during initial VoIP subscription enrollments. In addition, any time the VoIP device 106 moves to another geographic location and a corresponding subscriber provides an updated street address via, for example, the customer service center 118 or the web server 122, the IMS 112 communicates the updated street address to the LIS database 142.
The i2 E911 system 140 is also provided with an emergency services zone (“ESZ”) routing database (“ERDB”) 146. Each ESZ corresponds to a particular emergency service number (“ESN”) that uniquely identifies the ESZ. For each ESZ, the ERDB 146 stores an emergency services routing number (“ESRN”) corresponding to an E911 selective router that serves that ESZ and a respective ESN. In the illustrated example, an ESRN is used to route an emergency call to an E911 selective router serving the ESZ corresponding to the geographic area within which the emergency call originated.
During registration of a street address or when a subscriber provides an updated street address, the LIS database 142 uses the ESRN's stored in the ERDB 146 to determine whether the provided street address is located within an area in which a corresponding VoIP service provider can provide E911 service. For example, the LIS database 142 accesses the ERDB 146 to retrieve an ESRN corresponding to the provided street address and determines whether the VoIP service provider can provide E911 service to the provided street address based on the ESRN. Regardless of whether the LIS database 142 determines that the VoIP service provider can or cannot provide E911 service to the provided street address, the LIS database 142 updates the registered geographic location of the VoIP device 106 with the provided street address. However, if the LIS database 142 determines that the VoIP service provider cannot provide E911 service to the provided street address, the LIS database 142 informs the NMS 114 that the VoIP device 106 is in a location at which E911 service is not available. In this manner, the NMS 114 can instruct the feature server 130 to set the operating mode associated with the VoIP device 106 to a restricted mode (S2 mode) so that the VoIP device 106 can access only a subset of services (e.g., receive calls only, connect to a 911 dispatcher without the location-identification services of E911) that are, for example, associated with a service subscription corresponding to the VoIP device 106.
To validate geographic location information (street addresses) to be stored in the LIS database 142, the i2 E911 system 140 is provided with a validation database (“VDB”) 144. The VDB 144 stores a plurality of street addresses in a format compliant with the master street address guide (“MSAG”) standard. In the illustrated example, when a subscriber provides a street address, and before the street address is stored in the LIS database 142, the i2 E911 system 140 compares the user-provided street addresses with known street addresses in the VDB 144 to determine whether the provided street address is MSAG-compliant. If the provided street address is MSAG-compliant, then the i2 E911 system 140 validates the provided street address and updates a corresponding registered street address in the LIS database 142. Otherwise, if the provided street address is not MSAG-compliant (e.g., the address includes a typographical error, an incorrect zip code, etc.), the i2 E911 system 140 indicates that the provided street address is invalid, and the IMS 112 informs the subscriber of the invalidity and requests the user to provide a compliant street address.
To retrieve emergency call routing information from the ERDB 146 and street addresses from the LIS database 142 to process an emergency call, the i2 E911 system 140 is provided with a VoIP positioning center (“VPC”) 148 communicatively coupled to the CSC 128. When the CSC 128 receives an emergency call, the CSC 128 queries the VPC 148 to determine the E911 selective router to which the emergency services gateway 132 should route the emergency call.
The PSAP 134 is coupled to an automatic location identification (“ALI”) database 150 to enable the PSAP 134 to retrieve geographic street addresses from which emergency calls originate. The ALI database 150 stores geographic street addresses corresponding to the locations of telephones connected to a traditional publicly switched telephone network (“PSTN”) 152. The VPC 148 stores geographic street addresses associated with VoIP devices that it retrieves from the LIS database 142. When the PSAP 134 requires a street address of a VoIP device 106, the ALI 150 queries the VPC 148 for the street address. In response, the VPC 148 forwards the street address associated with the VoIP device 106 to the ALI database 150. The ALI database 150 then provides the street address to the PSAP 134.
FIG. 2 illustrates an example implementation of the site gateway 104 a. To make VoIP calls via the site gateway 104 a, a plurality of plain old telephone system (“POTS”) analog telephones 202 and/or the VoIP device 106 are communicatively coupled to the site gateway 104 a of FIG. 2. The site gateway 104 a is provided with a plurality of RJ-11 ports 208 to which the analog telephones 202 are communicatively coupled. In addition, to convert between analog and digital communications for the analog telephones 202, the site gateway 104 a is provided with analog telephone adapters (“ATA's”) 210. To communicatively couple the site gateway 104 a to the IP network 108, the site gateway 104 a is provided with a wide area network (“WAN”) port 204. In the illustrated example, the DHCP server 110 of the IP network 108 assigns a public IP address (e.g., the public IP address A) to the site gateway 104 a to enable the site gateway 104 a to access Internet services via the IP network 108. To enable the devices 202 to access Internet services via the site gateway 104 a, the site gateway 104 a associates a unique private IP address with each of the ATA's 210. To enable the device 106 to access Internet services via the site gateway 104 a, the site gateway 104 a associates a private IP address with the device 106. The site gateway 104 a is provided with a network address translator (“NAT”) 206 to translate between the private IP addresses and the public IP address A of the site gateway whenever any of the devices 202 and 106 exchange, send, and/or receive information with, to, and/or from the IP network 108 via the site gateway 104 a.
To enable each of the analog telephones 202 to communicate information via a session initiation protocol (“SIP”), each of the ATA's 210 integrated in the gateway 104 a is provided with a gateway-integrated SIP user agent (“SIP UA”) 212. When the site gateway 104 a is powered, the SIP UA's 212 register with the IMS 112 to enable the analog telephones 202 to make VoIP calls. Each time the site gateway 104 a is booted (e.g., each time power is cycled), the SIP UA's 212 re-register with the IMS 112. Also, each time the site gateway 104 a is booted, the DHCP server 110 of the IP network 108 may assign the same or a different public IP address to the site gateway 104 a.
In the illustrated example, the VoIP device 106 includes a SIP UA 214 and is capable of exchanging digital information network packets with the site gateway 104 a. Accordingly, it is not necessary to use another SIP UA (e.g., one of the SIP UA's 212) or an ATA (e.g., the ATA 210) in the site gateway 104 a for communications with the VoIP device 106. As shown, the site gateway 104 a is provided with an RJ-45 port 216 to which the VoIP device 106 is communicatively coupled. In addition, the site gateway 104 a is provided with a router 218 for routing the network traffic corresponding to the VoIP device 106. In the illustrated example, the site gateway 104 a assigns a unique private IP address to the SIP UA 214 of the VoIP device 106. After the site gateway 104 a is powered and the VoIP device 106 is connected to the RJ-45 port 216, the SIP UA 214 registers the VoIP device 106 with the IMS 112 to enable the VoIP device 106 to make VoIP calls. Each time the VoIP device 106 is re-connected to the site gateway 104 a or is connected to a different site gateway (e.g., the site gateway 104 b of FIG. 1), the SIP UA 214 re-registers with the IMS 112.
The VoIP device 106 can be associated with one or more telephone numbers used to implement public user ID's (“PUID's”). In the illustrated example, a PUID is used to establish a VoIP call with a VoIP device 106. A conventional (XXX) YYY-ZZZZ type phone number can be used as the PUID. Alternatively or additionally, the PUID may be implemented using any other format instead of a telephone number format (e.g., an e-mail address format). When a user subscribes to a VoIP telephony service or adds a VoIP telephone line, the NMS 114 (FIG. 1) of a VoIP service provider allocates a PUID (e.g., a telephone number) to the user and stores geographic location information (e.g., a street address) in the LIS database 142 in association with the PUID. In addition, the NMS 114 identifies a plurality of features (e.g., nomadic-enabled or nomadic-blocked) associated with the PUID and stores the features in the HSS database 116 (FIG. 1). For example, if the user expects to operate the VoIP device 106 at a single location (e.g., the subscriber site 102 a), the user may elect to block nomadic operation of the VoIP device. If the VoIP device 106 is moved to another geographic location, the VoIP service provider will deny the VoIP device 106 access to VoIP services because it is designated as nomadic-blocked. However, if the user expects to move the VoIP device 106 between different sites (e.g., between the subscriber sites 102 a-b), the user may elect to allow nomadic operation of the VoIP device 106. In this manner, when the VoIP device 106 is moved to a different location, the VoIP service provider will allow operation of the VoIP device 106 because it is designated as nomadic-allowed.
FIG. 3 is an example data structure 300 showing associations between corresponding account information associated with a VoIP service subscription. The account information (e.g., features, network identifications, etc.) is associated with each PUID of a subscriber. In the illustrated example, the account information shown in the data structure 300 can be stored in different network entities of the IMS 112 (FIG. 1). For example, information shown in a particular column of the data structure 300 can be stored in the home subscriber services (“HSS”) database 116 of FIG. 1, while other information in another column can be stored in the feature server 130 of FIG. 1 or any other network entity. Accordingly, particular columns of information shown in the data structure 300 may be stored throughout the example network system 100 in one or more network locations using a plurality of data structures and can be associated with one another using index keys (e.g., PUID's). However, for purposes of discussion, the information is shown in the data structure 300.
As shown in FIG. 3, the data structure 300 includes a site gateway ID column 302 that is used to store site gateway identification numbers 304 that uniquely identify the site gateway 104 a of FIGS. 1 and 2. To indicate whether an ATA (e.g., one of the ATA's 210) is implemented within a gateway (e.g., the gateway 104 a of FIGS. 1 and 2), the data structure 300 includes a gateway-internal ATA column 306. In the illustrated example, the gateway-internal ATA column 306 can be used to indicate that the ATA's 210 of FIG. 2 are gateway-internal ATA's.
The data structure 300 is provided with a public user ID (PUID) column 308 that is used to store a plurality of PUID's (e.g., telephone numbers) 310 assigned to a subscriber account. The PUID's 310 may be used with gateway-internal ATA's (e.g. the ATA's 210 of FIG. 2) and/or with VoIP telephones (e.g., the VoIP device 106). To associate a public IP address (e.g., the public IP addresses A and B of FIG. 1) with respective PUID's, the data structure 300 is provided with a registered public IP address column 312 having a plurality of registered public IP addresses 314. In the illustrated example, the registered public IP addresses 314 are used to detect when a VoIP device associated with one of the PUID's 310 may have been moved to another geographic location.
To indicate whether telephone numbers have been assigned a nomadic-allowed or a nomadic-blocked feature, the data structure 300 is provided with a nomadic block column 316 that stores a plurality of nomadic service designators 317. Each of the nomadic service designators 317 corresponds to one of the PUID's 310 and indicates whether the corresponding PUID's 310 is nomadic-blocked (Y) or nomadic-enabled (N). A nomadic-enabled (N) designator indicates a PUID and its associated VoIP device (e.g., the VoIP device 106) are allowed to access VoIP services when the associated VoIP device is moved away from a primary or pre-designated geographic location.
To store operating modes associated with the PUID's 310 used in combination with VoIP devices, the data structure 300 is provided with an operating mode column 318 that stores operating mode designators 320 (e.g., the operating mode designators S0, S1, and S2). In the illustrated example, the operating mode designators 320 in the operating mode column are stored in the feature server 130 of FIG. 1. In the example of FIG. 3, the S0 operating mode is an unrestricted operating mode in which a VoIP device can access substantially all VoIP services associated with a service subscription corresponding to the VoIP device (or corresponding to the PUID(s) used with that VoIP device). In contrast, the S1 operating mode is a suspended operating mode that restricts the VoIP device to use of a subset of the VoIP services associated with a service subscription corresponding to the VoIP device (or PUID(s) used with the VoIP device). The S2 operating mode of the illustrated example allows the VoIP device to access the same or less VoIP services as those allowed in the S1 (suspended) operating mode. In some example implementations, additional operating modes may be implemented (e.g., an operating mode that disallows any incoming or outgoing calls).
FIG. 4 is a block diagram of an example system 400 configured to provide support functions for E911 services to VoIP devices associated with nomadic usage. The example system 400 includes an IP address interface 402, an IP address comparator 404, a user interface 406, a geographic location information interface 408, a validator 410, a geographic location change status updater 412, an operating mode interface 414, an operating mode selector 416, an operating mode identifier 418, a call type identifier 420, an E911 service verifier 422, and a subscription services interface 424, all of which may be implemented using any desired combination of hardware, firmware, and/or software. For example, one or more integrated circuits, discrete semiconductor components, or passive electronic components may be used. Additionally or alternatively, some or all of the blocks of the example system 400, or parts thereof, may be implemented using instructions, code, and/or other software and/or firmware, etc. stored on a machine accessible medium that, when executed by, for example, a processor system (e.g., the example processor system 810 of FIG. 8), perform the operations represented in the flow diagrams of FIGS. 5, 6A, 6B, and 7. In the illustrated example, the blocks of the example system 400 are distributed among various network entities in the example network system 100 of FIG. 1. However, in alternative example implementations, the blocks of the example system 400 may be implemented using network entities other than those indicated below. For example, although the below description may indicate that a network entity of the example network system 100 implements one of the blocks of the example system 400, in one or more alternative example implementations, that network entity may be configured to implement two or more blocks of the example system 400 or none of the blocks. In addition, an example apparatus may be used to implement all of the blocks of the example system 400 and may be communicatively coupled to the example network system 100.
Turning in detail to the example system 400, to retrieve and store IP addresses (e.g., the public IP address A and B of FIG. 1, the public IP addresses 314 of FIG. 3, etc.), the example system 400 is provided with an IP address interface 402. In the illustrated example, the IP address interface 402 is implemented using the feature server 130 of FIG. 1. The IP address interface 402 is configured to receive public IP addresses (e.g., registration public IP addresses) via notifications from the HSS database 116 when VoIP devices register with the IMS 112. The IP address interface 402 also stores the public IP addresses in the feature server 130. In this manner, the feature server 130 can compare the received public IP addresses with future registration public IP addresses.
To compare registration public IP addresses used by VoIP devices with registered public IP address stored in association with VoIP devices (or PUID's used in combination with the VoIP devices) within the feature server 130 of FIG. 1, the example system 400 is provided with an IP address comparator 404. The example system 400 compares registration public IP addresses (e.g., the public IP addresses A and B of FIG. 1) with registered public IP addresses (e.g., the registered public IP addresses 314 of FIG. 3) to determine whether VoIP devices may have been moved between geographic locations. In the illustrated example, the IP address comparator 404 may be implemented using the HSS database 116 and an IP address comparator substantially similar or identical to the IP address comparator 404 may be implemented using the feature server 130. In this manner, when the VoIP device 106 (FIGS. 1 and 2) registers with the IMS 112, the IP address comparator 404 in the HSS database 116 can compare the public IP address A (a registration public IP address) of the site gateway 104 a with a registered public IP address that was previously registered in association with the VoIP device 106. The HSS database 116 can then determine a geographic location change status based on the comparison and allow the VoIP device 106 to register based on the geographic location change status. In addition, an IP address comparator in the feature server 130 can compare registration and registered public IP addresses to determine if the feature server 130 should change VoIP device operating modes from the S0 mode to the S1 mode.
To present messages to a user via the VoIP device 106, the example system 400 is provided with a user interface 406. In the illustrated example, the user interface 406 is implemented using the IVR system 124 of FIG. 1 and is configured to playback audio messages to a user via the VoIP device 106. For example, the user interface 406 may have an audio file player or a text-to-speech converter (e.g., a speech synthesizer). Example audio messages include registered street addresses associated with the VoIP device 106 and requests for user to confirm whether a registered street address is the same as a current street address of the VoIP device 106. Other example audio messages include informing a user via the VoIP device 106 of operating modes of the VoIP device 106 and information on how to update registered street addresses. In other example implementations, the user interface 406 may also be configured to communicate and/or exchange text messages and/or other messages (e.g., video messages) with the VoIP device 106 so that some or all messages described above can be presented via a display of the VoIP device 106. In some example implementations, the functionality described in connection with the user interface 406 may be implemented using an external media server having a standard control interface, and the user interface 406 can be provided with a media server control interface to exchange information with the external media server.
To retrieve and/or store registered and/or user-provided geographic location information (e.g., registered street addresses), the example system 400 is provided with a geographic location interface 408. In the illustrated example, the geographic location interface 408 is implemented using the IVR 124 of FIG. 1 and is configured to access the LIS database 142 to retrieve registered geographic location information associated with corresponding PUID's of VoIP devices. As discussed above, a user may provide geographic location information via a web page served by the web server 122 or via a customer service representative in the customer service center 118. The web server 122 or the customer service center 118 then communicate the user-provided geographic location information to the LIS database 142. The LIS database 142 then updates registered geographic location information stored therein using the user-provided geographic location information if the validation database (“VDB”) 144 of FIG. 1 determines that the user-provided geographic location information is valid (e.g., compliant with the master street address guide (“MSAG”) standard).
To validate user-provided geographic location information, the example system 400 is provided with a validator 410. In the illustrated example, the validator 410 is implemented using the VDB 144 of FIG. 1 and is configured to determine whether user-provided geographic location information is MSAG-compliant. For example, if the validator 410 finds a street address stored in the VDB 144 to match the user-provided geographic location information, then the validator 410 indicates the user-provided geographic location information is valid.
To update geographic location change statuses associated with VoIP devices (e.g., the VoIP device 106 of FIGS. 1 and 2) and their respective PUID's (e.g., the PUID's 310 of FIG. 3), the example system 400 is provided with a geographic location change status updater 412. In the illustrated example, the geographic location change status updater 412 is implemented using the feature server 130 of FIG. 1 and is configured to update the location change status (e.g., geographic location has not changed, geographic location may have changed, etc.) associated with a VoIP device when the IP address comparator 404 determines that a registered public IP address associated with the VoIP device 106 and a current public IP address used by the VoIP device 106 (during, for example, registration) do not match.
To retrieve and store operating modes associated with VoIP devices, the example system 400 is provided with an operating mode interface 414. In the illustrated example, the operating mode interface 414 is implemented using the feature server 130 of FIG. 1 and is configured to store operating mode designators (e.g., the operating mode designators 320 of FIG. 3) in the feature server 130 and retrieve operating mode designators from the feature server 130.
To select operating modes for association with VoIP devices, the example system 400 of FIG. 4 is provided with an operating mode selector 416. In the illustrated example, the operating mode selector 416 is implemented using the feature server 130 of FIG. 1 and is configured to select operating modes (e.g., the operating modes S0, S1, or S2) based on location change statuses associated with VoIP devices, based on whether registered geographic location information is up to date, and/or based on whether VoIP devices are in locations for which VoIP service providers can provide E911 service. To detect which operating modes are associated with VoIP devices, the example system 400 of FIG. 4 is provided with an operating mode identifier 418. In the illustrated example, the operating mode identifier 418 is implemented using the feature server 130 of FIG. 1.
To identify the type of calls initiated by VoIP devices, the example system 400 is provided with a call type identifier 420. In the illustrated example, the call type identifier 420 is implemented using the feature server 130 and is configured to determine whether calls are being made to 911 or to a PUID authorized by a VoIP service provider. For example, when the VoIP device 106 is associated with the S1 (suspended) mode, a VoIP service provider allows the VoIP device 106 to make calls only to 911 or to pre-selected, authorized numbers (e.g., a customer service number). To enable the allowed calls, the call type identifier 420 extracts information from a call initiation signal communicated by the VoIP device 106 and identifies the call type.
To determine whether a VoIP service provider of the VoIP device 106 can provide E911 service at a location within which the VoIP device 106 is located, the example system 400 is provided with an E911 service verifier 422. In the illustrated example, the E911 service verifier 422 is implemented using the LIS database 142 of FIG. 1. Also in the illustrated example, if the E911 service verifier 422 determines that the VoIP service provider of the VoIP device 106 cannot offer E911 service, the feature server 130 is configured to forward any 911 calls made from the VoIP device 106 to a 911 operator that will handle or process the 911 call without the location-identifying features of E911 service.
To determine the service subscriptions associated with a particular VoIP device, the example system 400 is provided with a subscription services interface 424. In the illustrated example, the subscription services interface 424 is implemented using the HSS database 116 of FIG. 1 and is configured to retrieve service options (e.g., the nomadic service designators 317 of FIG. 3) from subscriber accounts stored in the HSS database 116 to determine the services to which users are subscribed.
FIGS. 5, 6A, 6B, and 7 are flowcharts representative of example machine readable instructions that may be executed to detect geographic location changes of VoIP devices, process VoIP calls initiated by VoIP devices, and update registered geographic location information associated with VoIP devices to implement the example system 400 of FIG. 4. Although the example machine readable instructions are described with reference to the flowcharts of FIGS. 5, 6A, 6B, and 7, persons of ordinary skill in the art will readily appreciate that other methods of detecting geographic location changes, processing VoIP calls, updating geographic location changes and, generally, implementing the example system 400 of FIG. 4 may additionally or alternatively be used. For example, the order of execution of the blocks depicted in the flowcharts of FIGS. 5, 6A, 6B, and 7 may be changed, and/or some of the blocks described may be rearranged, eliminated, or combined.
FIG. 5 is a flowchart representative of example machine readable instructions that may be executed to determine whether the VoIP device 106 may have been moved to another geographic location. Initially, the VoIP device 106 of FIGS. 1 and 2 registers with the IMS 112 (block 502). During the VoIP device registration process (block 502), the HSS database 116 can prevent the VoIP device 106 from registering if the subscription services interface 424 (FIG. 4) determines that the VoIP device 106 is not nomadic-enabled. However, if the HSS database 116 does allow the VoIP device 106 to register, but registration is not complete (block 504), the process of FIG. 5 waits at block 504 until registration is complete. Otherwise, if registration is complete (block 504), the IP address comparator 404 (FIG. 4) determines whether the public IP address (e.g., the public IP address A of FIG. 1) associated with the VoIP device 106 has changed (i.e., if the registration public IP address used to register the VoIP device is different from the previously registered public IP address stored in the feature server 130 of FIG. 1) (block 506).
During the registration process of block 502, the IP address interface 402 stores the registration public IP address of the VoIP device 106 in the feature server 130. At block 506, to determine whether the registration public IP address associated with the VoIP device 106 is different from the registered public IP address associated with the VoIP device 106, the IP address comparator 404 retrieves the registered public IP address and the registration public IP address from the feature server 130 and compares the IP addresses to determine whether they are identical (block 506). In the illustrated example, the public IP addresses can be identical if the VoIP device 106 registers or attempts to register from the same network location (e.g., the subscriber site 102 a of FIG. 1) two or more consecutive times because the public IP address of the network location gateway (e.g., the public IP address A of the site gateway 104 a of FIG. 1) is stored in the feature server 130 during each registration process. In some cases, during a first registration process, the VoIP operating mode may be set to the S1 (suspended) mode if the user of the VoIP device 106 does not confirm or update the registered geographic location information. Thus, during subsequent registration attempts, although the registered public IP address and the public IP address used to register the VoIP device 106 may be the same, the example system 400 will limit operation of the VoIP device 106 to the S1 (suspended) mode until the user confirms or updates the registered geographic location information.
If the public IP addresses are the same (i.e., no IP address change has occurred) (block 506), the operating mode identifier 418 (FIG. 4) determines whether the operating mode associated with the VoIP device 106 is set to the S0 (unrestricted) mode (block 508). In the illustrated example, the operating mode interface 414 retrieves the current operating mode designator (e.g., one of the operating mode designators 320 of FIG. 3) associated with the VoIP device 106 from the feature server 130 of FIG. 1 and the operating mode identifier 418 determines whether the operating mode designator indicates the S0 (unrestricted) operating mode (block 508). If the operating mode identifier 418 determines that the VoIP device operating mode is not set to the S0 (unrestricted) operating mode, the operating mode identifier 418 determines if the VoIP device operating mode is set to the S2 (restricted) operating mode (block 510).
If the operating mode identifier 418 determines that the operating mode is not set to the S2 (restricted) mode (block 510) or if the IP address comparator 404 determines that the public IP address associated with the VoIP device 106 has changed (block 506), the geographic location change status updater 412 (FIG. 4) updates the location change status associated with the VoIP device 106 to “suspected location change” (block 512) to indicate that the VoIP device 106 may have been moved to a different geographic location. Also, the operating mode selector 416 (FIG. 4) sets the operating mode associated with the VoIP device 106 to the S1 (suspended) mode (block 514). For cases in which the operating mode selector 416 has previously set the operating mode associated with the VoIP device 106 to the S1 (suspended) mode, the operating mode selector 416 may be configured to confirm at block 514 that the operating mode associated with the VoIP device 106 is set to the S1 (suspended) mode.
The operating mode interface 414 then stores the current operating mode associated with the VoIP device (block 516) in, for example, the feature server 130 of FIG. 1 (e.g., in the operating mode column 318 of FIG. 3). Also, the IP address interface 402 updates the registered public IP address associated with the VoIP device 106 (block 518) in, for example, the feature server 130 of FIG. 1 (e.g., in the public IP address column 312 of FIG. 3) by replacing the previously registered public IP address with the registration public IP address received at block 502.
The example system 400 then determines whether it should continue monitoring VoIP device registration events (block 520). For example, the example system 400 may determine not to continue monitoring if the monitoring operation of the example system 400 is disabled by a VoIP service provider or if the monitoring operation of the example system 400 is interrupt driven and monitors only upon detection of particular events (e.g., a VoIP device plugged into the network). In an example implementation, the example system 400 is preferably, but not necessarily, configured to continuously monitor VoIP device registration events, and block 520 always returns control to block 502.
If the example system 400 determines that it should continue monitoring for an IP address change (block 520) or if the operating mode identifier 418 determines that the VoIP device 106 is associated with the S2 (restricted) mode (block 510) or the S0 (unrestricted) mode (block 508), control returns to block 502 for a subsequent registration of the VoIP device 106 or any other VoIP device. Otherwise, if the example system 400 determines that it should not continue monitoring for an IP address change (block 502), then the process of FIG. 5 is ended and/or control is returned to a calling function or process.
Although the example process of FIG. 5 uses the registered public IP address and the current public IP address (the registration public IP address) associated with the VoIP device 106 to determine whether the VoIP device 106 may have changed geographic locations, in alternative example implementations, other example methods may be used to detect geographic location changes of the VoIP device 106.
FIGS. 6A and 6B are a flowchart representative of example machine readable instructions that may be executed to process a VoIP call initiated by an example VoIP device 106. Initially, the VoIP device 106 initiates a call (block 602). In the illustrated example, the VoIP device 106 communicates a call initiation request to the CSC 128 of FIG. 1 and the CSC 128 uses the feature server 130 to initiate and process the call. The operating mode identifier 418 (FIG. 4) then determines whether the operating mode associated with the VoIP device 106 is set to an S0 (unrestricted) operating mode (block 604). In the illustrated example, to determine whether the VoIP device operating mode is set to the S0 (unrestricted) mode, the operating mode interface 414 retrieves the operating mode designator (e.g., one of the operating mode designators 320 of FIG. 3) associated with the VoIP device 106 from the feature server 130 and the operating mode identifier 418 determines whether the retrieved operating mode designator indicates the S0 (unrestricted) mode (block 604). If the operating mode identifier 418 determines that the VoIP device operating mode is not set to the S0 (unrestricted) operating mode (block 604) (i.e., the operating mode is instead set to the S1 (suspended) mode or S2 (restricted) mode), then the call type identifier 420 (FIG. 4) determines whether the call being initiated is a call to 911 or a call to an authorized telephone number (block 606) (e.g., a customer service telephone number authorized by the VoIP service provider). If the call type identifier 420 determines that the call is to 911 or to another authorized PUID (block 606), or if the operating mode identifier 418 determines that the VoIP device operating mode is set to the S0 (unrestricted) mode, the CSC 128 completes initiation of the call (block 608).
If the call type identifier 420 determines that the call is not to 911 or to another authorized telephone number (block 606), the operating mode identifier 418 determines whether the VoIP device operating mode is set to an S1 (suspended) operating mode (block 610). If the operating mode identifier 418 determines that the VoIP device operating mode is not set to an S1 (suspended) operating mode (block 610) (i.e., the operating mode is instead set to the S2 (restricted) mode), the user interface 406 presents a message via the VoIP device 106 to inform a user of the VoIP device 106 that the VoIP device 106 is within a location in which the VoIP service provider of the VoIP device 106 cannot provide E911 service (block 612). In the illustrated example, the message is an audio message presented by, for example, the IVR system 124 of FIG. 1, but any other desired messaging medium may be employed.
If the operating mode identifier 418 determines that the VoIP device operating mode is set to an S1 (suspended) operating mode (block 610), the geographic location information interface 408 (FIG. 4) retrieves registered geographic location information (e.g., a street address) associated with the VoIP device 106 (block 614). In the illustrated example, the geographic location information interface 408 accesses the LIS database 142 to retrieve the registered street address stored in association with the PUID of the VoIP device 106. The user interface 406 then presents the registered geographic location information via the VoIP device 106 (block 616) and requests the user of the VoIP device 106 to confirm whether the registered geographic location is the same as the current geographic location of the VoIP device 106 (block 618). In the illustrated example, the IVR system 124 of FIG. 1 implements the user interface 406 and performs a text-to-speech conversion of the registered street address to present an audio message via the VoIP device 106. In other example implementations, the LIS database 142 may store audio files (e.g., WAV files) of registered street addresses and the IVR system 124 may play back the audio files via the VoIP device 106. In addition, in other example implementations, the registered geographic location information may be presented (block 616) via text or video on a display screen of the VoIP device 106 and/or other user interface screens may be used to request the user to confirm the location of the VoIP device 106 (block 618). The NMS 114 then stores the user response regarding whether the registered geographic location is the same as the current geographic location of the VoIP device 106 (block 620). In the illustrated example, the user interface 406 communicates the user response to the NMS 114 along with the user's PUID and a date and time stamp of when the user responded, and the NMS 114 stores the user's PUID in association with the date and time stamp. In this manner, the VoIP service provider can keep records of whether and when users confirmed their geographic location.
After the NMS 114 stores the user response (block 620), the geographic location change status updater 412 (FIG. 4) determines whether the user confirmed that the registered geographic location of the VoIP device 106 is the same as the current geographic location of the VoIP device 106 (block 622) (FIG. 6B) based on, for example, the user response requested at block 618. For example, the geographic location change status updater 412 determines that the registered geographic location of the VoIP device 106 is the same as the current geographic location if the user response confirmed (e.g., “Yes”) that the registered geographic location of the VoIP device 106 is the same as the current geographic location. If the geographic location change status updater 412 determines that the geographic locations are not the same or after the user interface 406 informs the user that the VoIP device is within a location in which the VoIP service provider cannot provide E911 service (block 612), the user interface 406 presents a website uniform resource locator (“URL”) address via the VoIP device (block 632) that the user can visit to provide updated geographic location information and/or to obtain more information on the messages presented by the user interface 406. Additionally or alternatively, the user interface 406 offers to connect the user to a customer service agent (block 634) at the customer service center 118 of FIG. 1. If the user elects to be connected to a customer service agent (block 636), then the user interface 406 connects the call to a customer service agent (block 638).
If at block 622, the geographic location change status updater 412 determines that the user confirmed that the geographic locations are the same, the operating mode selector 416 changes the VoIP device operating mode to the S0 (unrestricted) mode and the operating mode interface 414 stores the operating mode (block 640) in, for example, the feature server 130 of FIG. 1. The CSC 128 of FIG. 1 then completes the call (block 642). The example process of FIGS. 6A and 6B then returns control to a calling function or process and/or ends.
FIG. 7 is a flowchart representative of example machine readable instructions that may be executed to update a registered geographic location associated with the VoIP device 106. Initially, if the user of the VoIP device 106 updates the registered geographic location via a web page (block 702), the web server 122 of FIG. 1 receives the user-provided geographic location information (block 704) such as, for example, a user-provided street address. The web server 122 then communicates the user-provided geographic location information to the LIS database 142 of FIG. 1.
If the user of the VoIP device 106 does not update the registered geographic location via a web page (block 702), and a customer service representative at the customer service center 118 receives the user-provided geographic location information (block 708) from the user of the VoIP device 106, the customer service representative communicates the user-provided geographic location information to the LIS database 142 (block 710).
After the LIS database 142 receives the user-provided geographic location information (block 706 or block 710), the validator 410 (FIG. 4) determines whether the user-provided geographic location information is MSAG-compliant (i.e., valid) (block 712). In the illustrated example, the user-provided geographic location information is a street address that the validator 410 compares with addresses stored in the validation database (“VDB”) 144 of FIG. 1 to determine if the user-provided street address is MSAG-compliant. If the user-provided geographic location information is MSAG-compliant (block 712), the geographic location information interface 408 updates the registered geographic location information in the LIS database 142 with the user-provided geographic location information (block 714).
The E911 service verifier 422 (FIG. 4) then determines whether the VoIP service provider of the VoIP device 106 can provide E911 service at the user-provided geographic location (block 716). If the VoIP service provider cannot provide E911 service at the user-provided geographic location (block 716), the NMS 114 instructs the operating mode selector 416 (FIG. 4) to change the operating mode associated with the VoIP device 106 to the S2 (restricted) mode and stores the restricted mode designator (block 720) in, for example, the feature server 130.
If the validator 410 determines that the user-provided geographic location information is not MSAG-compliant (block 712), the web server 122 or the customer service representative assisting the user of the VoIP device 106 informs the user that the user-provided geographic location information (e.g., the street address) is not valid (block 724). The user must then provide another geographic location. In some cases, the geographic location information may not be MSAG-compliant due to a typographical error, a missing zip code, or some other trivial mistake, and the user need merely re-type the geographic location information.
After informing the user that the user-provided geographic location information is invalid or after changing the operating mode associated with the VoIP device 106 to the S2 (restricted) mode and storing the restricted mode designator (block 720) or if the VoIP service provider can provide E911 service at the user-provided geographic location (block 716), the web server 122 or the customer service representative assisting the user of the VoIP device 106 then determines whether to end the geographic address update process (block 726). For example, the web server 122 may determine that it should end the process if the user of the VoIP device 106 has closed or logged out of the web page used to update the geographic location information, and/or the customer service representative may determine to end the process if the user has elected to end the call with the customer service representative. If the web server 122 or the customer service representative determines that the geographic location information update process should not end, then control is passed back to block 702. Otherwise, the process of FIG. 7 ends.
FIG. 8 is a block diagram of an example processor system 810 that may be used to implement the example apparatus, methods, and articles of manufacture described herein. For example, processor systems substantially similar or identical to the example processor system 810 may be used to implement the site gateways 104 a-b, the network management system 114, the HSS database 116, the web server 122, the IVR system 124, the emergency services gateway 132, the call session controller 128, the feature server 130, the LIS database 142, the validation database 144, and/or the VPC 148, all shown in FIG. 1. In addition, processor systems substantially similar or identical to the example processor system 810 may be used to implement the IP address interface 402, the IP address comparator 404, the user interface 406, the geographic location information interface 408, the validator 410, the geographic location change status updater 412, the operating mode interface 414, the operating mode selector 416, the operating mode identifier 418, the call type identifier 420, the E911 service verifier 422, and/or the subscription services interface 424 of the example system 400 of FIG. 4.
As shown in FIG. 8, the processor system 810 includes a processor 812 that is coupled to an interconnection bus 814. The processor 812 includes a register set or register space 816, which is depicted in FIG. 8 as being entirely on-chip, but which could alternatively be located entirely or partially off-chip and directly coupled to the processor 812 via dedicated electrical connections and/or via the interconnection bus 814. The processor 812 may be any suitable processor, processing unit or microprocessor. Although not shown in FIG. 8, the system 810 may be a multi-processor system and, thus, may include one or more additional processors that are identical or similar to the processor 812 and that are communicatively coupled to the interconnection bus 814.
The processor 812 of FIG. 8 is coupled to a chipset 818, which includes a memory controller 820 and an input/output (I/O) controller 822. A chipset provides I/O and memory management functions as well as a plurality of general purpose and/or special purpose registers, timers, etc. that are accessible or used by one or more processors coupled to the chipset 818. The memory controller 820 performs functions that enable the processor 812 (or processors if there are multiple processors) to access a system memory 824 and a mass storage memory 825.
The system memory 824 may include any desired type of volatile and/or non-volatile memory such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc. The mass storage memory 825 may include any desired type of mass storage device including hard disk drives, optical drives, tape storage devices, etc.
The I/O controller 822 performs functions that enable the processor 812 to communicate with peripheral input/output (I/O) devices 826 and 828 and a network interface 830 via an I/O bus 832. The I/ O devices 826 and 828 may be any desired type of I/O device such as, for example, a keyboard, a video display or monitor, a mouse, etc. The network interface 830 may be, for example, an Ethernet device, an asynchronous transfer mode (ATM) device, an 802.11 device, a digital subscriber line (DSL) modem, a cable modem, a cellular modem, etc. that enables the processor system 810 to communicate with another processor system.
While the memory controller 820 and the I/O controller 822 are depicted in FIG. 8 as separate functional blocks within the chipset 818, the functions performed by these blocks may be integrated within a single semiconductor circuit or may be implemented using two or more separate integrated circuits.
Of course, persons of ordinary skill in the art will recognize that the order, size, and proportions of the memory illustrated in the example systems may vary. Additionally, although this patent discloses example systems including, among other components, software or firmware executed on hardware, it will be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware and software components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware or in some combination of hardware, firmware and/or software. Accordingly, persons of ordinary skill in the art will readily appreciate that the above-described examples are not the only way to implement such systems.
At least some of the above described example methods and/or apparatus are implemented by one or more software and/or firmware programs running on a computer processor. However, dedicated hardware implementations including, but not limited to, an ASIC, programmable logic arrays and other hardware devices can likewise be constructed to implement some or all of the example methods and/or apparatus described herein, either in whole or in part. Furthermore, alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the example methods and/or apparatus described herein.
It should also be noted that the example software and/or firmware implementations described herein are optionally stored on a tangible storage medium, such as: (1) a magnetic medium (e.g., a disk or tape); (2) a magneto-optical or optical medium such as a disk; or (3) a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories. Accordingly, the example software and/or firmware described herein can be stored on a tangible storage medium such as those described above or equivalents and successor media.
To the extent the above specification describes example components and functions with reference to particular devices, standards and/or protocols, it is understood that the teachings of the invention are not limited to such devices, standards and/or protocols. Such devices are periodically superseded by different, faster, and/or more efficient systems having the same general purpose. Accordingly, replacement devices, standards and/or protocols having the same general functions are equivalents which are intended to be included within the scope of the accompanying claims.
Further, although certain methods, apparatus, systems, and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. To the contrary, this patent covers all methods, apparatus, systems, and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.

Claims (20)

What is claimed is:
1. An apparatus comprising:
memory to:
store a first public user identifier in association with a first nomadic service designator and a first operating mode designator, the first public user identifier associated with a device, the first nomadic service designator to indicate whether the first public user identifier is eligible for use with a nomadic service to access a voice over internet protocol service from different network locations, and the first operating mode designator to indicate whether the first public user identifier is eligible for use with voice over internet protocol calls to or from telephone numbers not selected by a voice over internet protocol service provider; and
store a second public user identifier in association with a second nomadic service designator and a second operating mode designator, the second public user identifier associated with the device, the second nomadic service designator to indicate whether the second public user identifier is eligible for use with the nomadic service to access the voice over internet protocol service from the different network locations, and the second operating mode designator to indicate whether the second public user identifier is eligible for use with the voice over internet protocol calls to or from the telephone numbers not selected by the voice over internet protocol service provider; and
a call session controller to:
determine whether a first call using the first public user identifier is eligible to be established based on the first nomadic service designator and the first operating mode designator, and determine whether a second call using the second public user identifier is eligible to be established based on the second nomadic service designator and based on the second operating mode designator, the first and second nomadic service designators configurable to respectively different nomadic permissions for the first and second public user identifiers, and the first and second operating mode designators configurable to respectively different operating modes for the first and second public user identifiers.
2. An apparatus as defined in claim 1, wherein an operating mode of at least one of the first operating mode designator or the second operating mode designator is based on a registered geographic location associated with the device being a current geographic location of the device.
3. An apparatus as defined in claim 1, wherein the memory is further to store a public internet protocol address in association with the first and second public user identifiers, the public internet protocol address associated with the device, wherein the public internet protocol address is registered to a gateway providing Internet access to the device.
4. An apparatus as defined in claim 1, wherein the first public user identifier is a telephone number or an email address.
5. An apparatus as defined in claim 1, wherein the first nomadic service designator is stored in association with the first public user identifier in a first data structure, the first operating mode designator is stored in association with the first public user identifier in a second data structure, the first nomadic service designator and the first operating mode designator being in association with one another across the first and second data structures based on the same first public user identifier.
6. An apparatus as defined in claim 1, wherein the first and second operating mode designators indicate that the device is eligible for the voice over internet protocol calls with the telephone numbers not selected by the voice over internet protocol service provider based on whether a registered geographic location associated with the device is a current geographic location of the device.
7. An apparatus as defined in claim 1, wherein the telephone numbers not selected by the voice over internet protocol service provider are different from second telephone numbers selected by the voice over internet protocol service provider, the second telephone numbers including at least one of a customer service telephone number or an emergency service telephone number.
8. A tangible machine readable storage device comprising instructions which, when executed, cause a processor to at least:
after receiving a first call initiated by a device using a first public user identifier, determine whether the first call is eligible to be established using a nomadic service based on whether the first public user identifier is stored in association with a first nomadic service designator indicating that the device is eligible to use the nomadic service to access a voice over internet protocol service from different network locations, and based on whether the first public user identifier is stored in association with a first operating mode designator indicating that the device is eligible for voice over internet protocol calls to or from telephone numbers not selected by a voice over internet protocol service provider; and
after receiving a second call initiated by the device using a second public user identifier, determine whether the second call is eligible to be established using the nomadic service based on whether the second public user identifier is stored in association with a second nomadic service designator indicating whether the device is eligible to use the nomadic service to access the voice over internet protocol service from the different network locations, and based on whether the second public user identifier is stored in association with a second operating mode designator indicating that the device is eligible for the voice over internet protocol calls to or from the telephone numbers not selected by the voice over internet protocol service provider,
the first and second nomadic service designators configurable to respectively different nomadic permissions for the first and second public user identifiers, and the first and second operating mode designators configurable to respectively different operating modes for the first and second public user identifiers.
9. A tangible machine readable storage device as defined in claim 8, wherein an operating mode of at least one of the first operating mode designator or the second operating mode designator is based on a registered geographic location associated with the device being a current geographic location of the device.
10. A tangible machine readable storage device as defined in claim 8, wherein the first public user identifier is a telephone number or an email address.
11. A tangible machine readable storage device as defined in claim 8, wherein the first nomadic service designator is stored in association with the first public user identifier in a first data structure, the first operating mode designator is stored in association with the first public user identifier in a second data structure, wherein the instructions cause the processor to associate the first nomadic service designator and the first operating mode designator across the first and second data structures based on the same first public user identifier.
12. A tangible machine readable storage device as defined in claim 8, wherein the first and second operating mode designators indicate that the device is eligible for the voice over internet protocol calls with the telephone numbers not selected by the voice over internet protocol service provider based on whether a registered geographic location associated with the device is a current geographic location of the device.
13. A tangible machine readable storage device as defined in claim 8, wherein the telephone numbers not selected by the voice over internet protocol service provider are different from second telephone numbers selected by the voice over internet protocol service provider, the second telephone numbers including at least one of a customer service telephone number or an emergency service telephone number.
14. A method comprising:
after receiving a first call initiated by a device using a first public user identifier, operating a call session controller to determine whether the first call is eligible to be established using a nomadic service based on whether the first public user identifier is stored in association with a first nomadic service designator indicating that the device is eligible to use the nomadic service to access a voice over internet protocol service from different network locations, and based on whether the first public user identifier is stored in association with a first operating mode designator indicating that the device is eligible for voice over internet protocol calls to or from telephone numbers not selected by a voice over internet protocol service provider; and
after receiving a second call initiated by the device using a second public user identifier, operating the call session controller to determine whether the second call is eligible to be established using the nomadic service based on whether the second public user identifier is stored in association with a second nomadic service designator indicating whether the device is eligible to use the nomadic service to access the voice over internet protocol service from the different network locations, and based on whether the second public user identifier is stored in association with a second operating mode designator indicating that the device is eligible for the voice over internet protocol calls to or from the telephone numbers not selected by the voice over internet protocol service provider,
the first and second nomadic service designators configurable to respectively different nomadic permissions for the first and second public user identifiers, and the first and second operating mode designators configurable to respectively different operating modes for the first and second public user identifiers.
15. A method as defined in claim 14, wherein an operating mode of at least one of the first operating mode designator or the second operating mode designator is based on a registered geographic location associated with the device being a current geographic location of the device.
16. A method as defined in claim 14, further including storing a public internet protocol address in association with the first and second public user identifiers, the public internet protocol address associated with the device, wherein the public internet protocol address is registered to a gateway providing Internet access to the device.
17. A method as defined in claim 14, wherein the device is a voice over internet protocol telephone.
18. A method as defined in claim 14, wherein the first nomadic service designator is stored in association with the first public user identifier in a first data structure, the first operating mode designator is stored in association with the first public user identifier in a second data structure, the first nomadic service designator and the first operating mode designator being in association with one another across the first and second data structures based on the same first public user identifier.
19. A method as defined in claim 14, wherein the first and second operating mode designators indicate that the device is eligible for the voice over internet protocol calls with the telephone numbers not selected by the voice over internet protocol service provider based on whether a registered geographic location associated with the device is a current geographic location of the device.
20. A method as defined in claim 14, wherein the telephone numbers not selected by the voice over internet protocol service provider are different from second telephone numbers selected by the voice over internet protocol service provider, the second telephone numbers including at least one of a customer service telephone number or an emergency service telephone number.
US14/697,328 2006-11-01 2015-04-27 Systems and methods for location management and emergency support for a voice over internet protocol device Active US9432467B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/697,328 US9432467B2 (en) 2006-11-01 2015-04-27 Systems and methods for location management and emergency support for a voice over internet protocol device

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/555,569 US8531995B2 (en) 2006-11-01 2006-11-01 Systems and methods for location management and emergency support for a voice over internet protocol device
US14/021,828 US9019870B2 (en) 2006-11-01 2013-09-09 Systems and methods for location management and emergency support for a voice over internet protocol device
US14/697,328 US9432467B2 (en) 2006-11-01 2015-04-27 Systems and methods for location management and emergency support for a voice over internet protocol device

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US14/021,828 Continuation US9019870B2 (en) 2006-11-01 2013-09-09 Systems and methods for location management and emergency support for a voice over internet protocol device

Publications (2)

Publication Number Publication Date
US20150312357A1 US20150312357A1 (en) 2015-10-29
US9432467B2 true US9432467B2 (en) 2016-08-30

Family

ID=39330162

Family Applications (3)

Application Number Title Priority Date Filing Date
US11/555,569 Active 2030-10-03 US8531995B2 (en) 2006-11-01 2006-11-01 Systems and methods for location management and emergency support for a voice over internet protocol device
US14/021,828 Active US9019870B2 (en) 2006-11-01 2013-09-09 Systems and methods for location management and emergency support for a voice over internet protocol device
US14/697,328 Active US9432467B2 (en) 2006-11-01 2015-04-27 Systems and methods for location management and emergency support for a voice over internet protocol device

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US11/555,569 Active 2030-10-03 US8531995B2 (en) 2006-11-01 2006-11-01 Systems and methods for location management and emergency support for a voice over internet protocol device
US14/021,828 Active US9019870B2 (en) 2006-11-01 2013-09-09 Systems and methods for location management and emergency support for a voice over internet protocol device

Country Status (1)

Country Link
US (3) US8531995B2 (en)

Families Citing this family (105)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7003571B1 (en) 2000-01-31 2006-02-21 Telecommunication Systems Corporation Of Maryland System and method for re-directing requests from browsers for communication over non-IP based networks
US8370435B1 (en) 2000-01-31 2013-02-05 Telecommunication Systems, Inc. System and method for servers to send alerts to connectionless devices
US6435164B1 (en) 2000-12-07 2002-08-20 Ford Global Technologies, Inc. Fuel weathering method for vehicle evaporative emission system
US7483983B1 (en) 2000-11-13 2009-01-27 Telecommunication Systems, Inc. Method and system for deploying content to wireless devices
US8917717B2 (en) * 2007-02-13 2014-12-23 Vonage Network Llc Method and system for multi-modal communications
DE102006013218A1 (en) * 2006-03-22 2007-10-04 Siemens Ag A method for locating and placing a mobile voice-over-IP subscriber in a local area to an emergency call center
US8077701B2 (en) * 2006-07-20 2011-12-13 At&T Intellectual Property I, Lp Systems, methods, and apparatus to prioritize communications in IP multimedia subsystem networks
US8064875B2 (en) * 2006-08-04 2011-11-22 At&T Intellectual Property I, L.P. Methods and apparatus to update geographic location information associated with internet protocol devices for E-911 emergency services
US8531995B2 (en) 2006-11-01 2013-09-10 At&T Intellectual Property I, L.P. Systems and methods for location management and emergency support for a voice over internet protocol device
US8818344B2 (en) * 2006-11-14 2014-08-26 Microsoft Corporation Secured communication via location awareness
US8620257B2 (en) * 2007-02-20 2013-12-31 At&T Intellectual Property I, L.P. Systems and methods for location management and emergency support for a voice over internet protocol device
US9379914B2 (en) * 2007-05-11 2016-06-28 At&T Intellectual Property I, L.P. Method and system for implementing aggregate endpoints on IMS networks
US7986914B1 (en) * 2007-06-01 2011-07-26 At&T Mobility Ii Llc Vehicle-based message control using cellular IP
US20090094270A1 (en) * 2007-10-08 2009-04-09 Alirez Baldomero J Method of building a validation database
US8125999B2 (en) * 2008-05-30 2012-02-28 At&T Intellectual Property I, L.P. Systems and methods to minimize customer equipment downtime in a voice over internet protocol (VOIP) service network
US8223631B2 (en) 2008-05-30 2012-07-17 At&T Intellectual Property I, L.P. Systems and methods to monitor and analyze customer equipment downtime in a voice over internet protocol (VoIP) service network
US8589541B2 (en) 2009-01-28 2013-11-19 Headwater Partners I Llc Device-assisted services for protecting network capacity
US8346225B2 (en) 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US8331901B2 (en) 2009-01-28 2012-12-11 Headwater Partners I, Llc Device assisted ambient services
US8406748B2 (en) 2009-01-28 2013-03-26 Headwater Partners I Llc Adaptive ambient services
US8340634B2 (en) * 2009-01-28 2012-12-25 Headwater Partners I, Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US8402111B2 (en) 2009-01-28 2013-03-19 Headwater Partners I, Llc Device assisted services install
US8275830B2 (en) 2009-01-28 2012-09-25 Headwater Partners I Llc Device assisted CDR creation, aggregation, mediation and billing
US8548428B2 (en) 2009-01-28 2013-10-01 Headwater Partners I Llc Device group partitions and settlement platform
US8832777B2 (en) 2009-03-02 2014-09-09 Headwater Partners I Llc Adapting network policies based on device service processor configuration
KR101005853B1 (en) * 2008-08-07 2011-01-05 한국전자통신연구원 Method and apparatus for providing home contents
US8068587B2 (en) * 2008-08-22 2011-11-29 Telecommunication Systems, Inc. Nationwide table routing of voice over internet protocol (VOIP) emergency calls
US8812012B2 (en) 2008-12-16 2014-08-19 The Nielsen Company (Us), Llc Methods and apparatus for associating media devices with a demographic composition of a geographic area
US9954975B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Enhanced curfew and protection associated with a device group
US10783581B2 (en) 2009-01-28 2020-09-22 Headwater Research Llc Wireless end-user device providing ambient or sponsored services
US9270559B2 (en) 2009-01-28 2016-02-23 Headwater Partners I Llc Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow
US10841839B2 (en) 2009-01-28 2020-11-17 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9609510B2 (en) 2009-01-28 2017-03-28 Headwater Research Llc Automated credential porting for mobile devices
US10200541B2 (en) 2009-01-28 2019-02-05 Headwater Research Llc Wireless end-user device with divided user space/kernel space traffic policy system
US9565707B2 (en) 2009-01-28 2017-02-07 Headwater Partners I Llc Wireless end-user device with wireless data attribution to multiple personas
US10715342B2 (en) 2009-01-28 2020-07-14 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US9392462B2 (en) 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US10248996B2 (en) 2009-01-28 2019-04-02 Headwater Research Llc Method for operating a wireless end-user device mobile payment agent
US10492102B2 (en) 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US10064055B2 (en) 2009-01-28 2018-08-28 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US11218854B2 (en) 2009-01-28 2022-01-04 Headwater Research Llc Service plan design, user interfaces, application programming interfaces, and device management
US9572019B2 (en) 2009-01-28 2017-02-14 Headwater Partners LLC Service selection set published to device agent with on-device service selection
US9980146B2 (en) 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US9955332B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Method for child wireless device activation to subscriber account of a master wireless device
US10484858B2 (en) 2009-01-28 2019-11-19 Headwater Research Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US10779177B2 (en) 2009-01-28 2020-09-15 Headwater Research Llc Device group partitions and settlement platform
US10798252B2 (en) 2009-01-28 2020-10-06 Headwater Research Llc System and method for providing user notifications
US10264138B2 (en) 2009-01-28 2019-04-16 Headwater Research Llc Mobile device and service management
US10237757B2 (en) 2009-01-28 2019-03-19 Headwater Research Llc System and method for wireless network offloading
US9706061B2 (en) 2009-01-28 2017-07-11 Headwater Partners I Llc Service design center for device assisted services
US10326800B2 (en) 2009-01-28 2019-06-18 Headwater Research Llc Wireless network service interfaces
US20100269162A1 (en) 2009-04-15 2010-10-21 Jose Bravo Website authentication
CN102460431B (en) 2009-05-08 2018-01-19 佐科姆有限公司 Behavior and the system and method for context data analysis
CN102474523B (en) * 2009-07-09 2014-11-26 瑞典爱立信有限公司 Methods and apparatuses for initiating provisioning of subscriber data in a hss of an IP multimedia subsystem network
US8594738B2 (en) 2009-09-01 2013-11-26 Qwest Communications International Inc. System, method and apparatus for automatic location-based silencing of wireless transceivers
US8731538B2 (en) 2009-09-01 2014-05-20 Qwest Communications International Inc. System, method, and apparatus for automatic scheduled silencing of wireless transmitters
US20110206036A1 (en) * 2010-02-25 2011-08-25 West Corporation System and method for method for providing an indication of certainty of location of origin of an internet protocol emergency call
US8406730B1 (en) 2010-06-10 2013-03-26 Sprint Communications Company L.P. Possession confidence metric for a wireless communication device
CA2803661C (en) 2010-06-24 2018-11-27 Arbitron Mobile Oy Network server arrangement for processing non-parametric, multi-dimensional, spatial and temporal human behavior or technical observations measured pervasively, and related method for the same
US8340685B2 (en) 2010-08-25 2012-12-25 The Nielsen Company (Us), Llc Methods, systems and apparatus to generate market segmentation data with anonymous location data
US8504401B2 (en) * 2010-12-08 2013-08-06 Verizon Patent And Licensing Inc. Address request and correction system
WO2012141762A1 (en) * 2011-02-25 2012-10-18 Telecommunication Systems, Inc. Mobile internet protocol (ip) location
US20120246303A1 (en) * 2011-03-23 2012-09-27 LogRhythm Inc. Log collection, structuring and processing
US8838988B2 (en) 2011-04-12 2014-09-16 International Business Machines Corporation Verification of transactional integrity
US8917826B2 (en) * 2012-07-31 2014-12-23 International Business Machines Corporation Detecting man-in-the-middle attacks in electronic transactions using prompts
CN102833677B (en) * 2012-08-31 2017-12-19 厦门雅迅网络股份有限公司 A kind of implementation method for emergency relief
TWI483122B (en) * 2013-03-11 2015-05-01 Hon Hai Prec Ind Co Ltd Network device discovery system and method
US9408067B1 (en) * 2013-12-02 2016-08-02 Taqua, Llc Selectively disallowing use of media over data calling in a segment based on segment characteristics
US9357369B2 (en) 2014-07-03 2016-05-31 At&T Intellectual Property I, L.P. Reducing provider costs related to E911 service
US9838858B2 (en) 2014-07-08 2017-12-05 Rapidsos, Inc. System and method for call management
WO2016044540A1 (en) 2014-09-19 2016-03-24 Rapidsos, Inc. Method and system for emergency call management
JP6038092B2 (en) * 2014-10-14 2016-12-07 三菱重工業株式会社 Surge judgment device, surge judgment method and program
US9247052B1 (en) * 2014-11-14 2016-01-26 Captioncall, Llc Apparatuses and methods for routing digital voice data in a communication system for hearing-impaired users
CN108476260A (en) 2015-11-02 2018-08-31 快速求救公司 The method and system of Situation Awareness for emergency response
WO2017106775A1 (en) 2015-12-17 2017-06-22 Rapidsos, Inc. Devices and methods for efficient emergency calling
US9998507B2 (en) 2015-12-22 2018-06-12 Rapidsos, Inc. Systems and methods for robust and persistent emergency communications
CN105472091B (en) * 2016-01-29 2018-07-27 腾讯科技(深圳)有限公司 A kind of information processing method and mobile terminal
US9986404B2 (en) 2016-02-26 2018-05-29 Rapidsos, Inc. Systems and methods for emergency communications amongst groups of devices based on shared data
CA3021803A1 (en) 2016-04-26 2017-11-02 Rapidsos, Inc. Systems and methods for emergency communications
US11076051B1 (en) 2016-05-04 2021-07-27 8X8, Inc. Endpoint location update control for call routing decisions
US10530934B1 (en) 2016-05-04 2020-01-07 8X8, Inc. Endpoint location determination for call routing decisions
US10542150B1 (en) 2016-05-04 2020-01-21 8X8, Inc. Server generated timing of location updates for call routing decisions
US10326888B1 (en) * 2016-05-04 2019-06-18 8X8, Inc. Location updates for call routing decisions
AU2017262647A1 (en) 2016-05-09 2018-12-20 Rapidsos, Inc. Systems and methods for emergency communications
US10861320B2 (en) 2016-08-22 2020-12-08 Rapidsos, Inc. Predictive analytics for emergency detection and response management
WO2018200418A1 (en) 2017-04-24 2018-11-01 Rapidsos, Inc. Modular emergency communication flow management system
US10165495B1 (en) 2017-06-22 2018-12-25 Microsoft Technology Licensing, Llc Connectivity using a geographic phone number
US10524086B2 (en) 2017-06-23 2019-12-31 Microsoft Technology Licensing, Llc Use condition for a geographic phone number
US10368225B2 (en) 2017-06-30 2019-07-30 Microsoft Technology Licensing, Llc Location determination for a service request
US10602562B2 (en) * 2017-07-06 2020-03-24 T-Mobile Usa, Inc. Establishing communication sessions by downgrading
EP3721402A4 (en) 2017-12-05 2021-08-04 Rapidsos Inc. Social media content for emergency management
US10820181B2 (en) 2018-02-09 2020-10-27 Rapidsos, Inc. Emergency location analysis system
US20190320310A1 (en) 2018-04-16 2019-10-17 Rapidsos, Inc. Emergency data management and access system
US10805786B2 (en) 2018-06-11 2020-10-13 Rapidsos, Inc. Systems and user interfaces for emergency data integration
US11917514B2 (en) 2018-08-14 2024-02-27 Rapidsos, Inc. Systems and methods for intelligently managing multimedia for emergency response
CN109241389A (en) * 2018-08-31 2019-01-18 北京云迹科技有限公司 The login state querying method and device of voice gateways
US10977927B2 (en) 2018-10-24 2021-04-13 Rapidsos, Inc. Emergency communication flow management and notification system
WO2020172612A1 (en) 2019-02-22 2020-08-27 Rapidsos, Inc. Systems & methods for automated emergency response
EP3949467A4 (en) 2019-03-29 2023-01-25 Rapidsos Inc. Systems and methods for emergency data integration
US11146680B2 (en) 2019-03-29 2021-10-12 Rapidsos, Inc. Systems and methods for emergency data integration
US11228891B2 (en) 2019-07-03 2022-01-18 Rapidsos, Inc. Systems and methods for emergency medical communications
US11330664B1 (en) 2020-12-31 2022-05-10 Rapidsos, Inc. Apparatus and method for obtaining emergency data and providing a map view
EP4272393A1 (en) * 2020-12-31 2023-11-08 Level 3 Communications, LLC Customer activation on edge computing environment
JP7134535B1 (en) * 2022-03-18 2022-09-12 アイティオール株式会社 Communication management device, communication management method, communication management program and communication management system
JP7315270B1 (en) 2022-06-28 2023-07-26 アイティオール株式会社 Communication management device, communication management method, communication management program and communication management system

Citations (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5161180A (en) 1990-10-19 1992-11-03 Chavous Robert O Call interceptor for emergency systems
US5235630A (en) 1991-04-17 1993-08-10 Telident, Incorporated Emergency call station identification system and method
US5479482A (en) 1993-08-30 1995-12-26 At&T Corp. Cellular terminal for providing public emergency call location information
US20010022558A1 (en) 1996-09-09 2001-09-20 Tracbeam Llc Wireless location using signal fingerprinting
US6415019B1 (en) 2000-08-21 2002-07-02 Ameritech Corporation Method of providing 911 service to a private branch exchange
US6421009B2 (en) 1998-05-08 2002-07-16 Peter Suprunov Mobile station position tracking system for public safety
US20030146871A1 (en) 1998-11-24 2003-08-07 Tracbeam Llc Wireless location using signal direction and time difference of arrival
EP1337089A2 (en) 2002-02-19 2003-08-20 Mitel Knowledge Corporation System and method for maintaining the physical location association of an IP telephone
US6650901B1 (en) 2000-02-29 2003-11-18 3Com Corporation System and method for providing user-configured telephone service in a data network telephony system
US20030217122A1 (en) 2002-03-01 2003-11-20 Roese John J. Location-based access control in a data network
US20030222819A1 (en) 1996-09-09 2003-12-04 Tracbeam Llc. Locating a mobile station using a plurality of wireless networks and applications therefor
US6678357B2 (en) 2001-09-26 2004-01-13 Siemens Information And Communication Networks, Inc. Internet protocol (IP) emergency connections (ITEC) telephony
US6707888B1 (en) 2002-05-06 2004-03-16 Sprint Communications Company, L.P. Location evaluation for callers that place emergency telephone calls over packet networks
US20040057425A1 (en) 2002-09-25 2004-03-25 Brouwer Wim L. Location identification for IP telephony to support emergency services
US20040125923A1 (en) 2002-12-31 2004-07-01 Michael See Automated voice over IP device VLAN-association setup
US6771742B2 (en) 2001-11-05 2004-08-03 Intrado Inc. Geographic routing of emergency service call center emergency calls
US20040151283A1 (en) 2003-02-03 2004-08-05 Lazoff David Michael Poll scheduling for emergency calls
US6799049B1 (en) 2000-12-19 2004-09-28 Bellsouth Intellectual Property Corporation System and method for tracking movement of a wireless device
US20040198386A1 (en) 2002-01-16 2004-10-07 Dupray Dennis J. Applications for a wireless location gateway
US6807483B1 (en) 2002-10-11 2004-10-19 Televigation, Inc. Method and system for prediction-based distributed navigation
US20040266457A1 (en) 1997-08-20 2004-12-30 Dupray Dennis J. Wireless location gateway and applications therefor
US20050026650A1 (en) 2003-07-30 2005-02-03 Sbc Knowledge Ventures, L.P. Provisioning of wireless private access subscribers for location based services
US20050063519A1 (en) 2003-09-22 2005-03-24 Foundry Networks, Inc. System, method and apparatus for supporting E911 emergency services in a data communications network
US20050074008A1 (en) 2003-09-23 2005-04-07 France Telecom Method and an associated device for setting up a transfer of data between two communications devices
US20050083911A1 (en) 2003-10-21 2005-04-21 3Com Corporation, A Corporation Of The State Of Delaware IP-based enhanced emergency services using intelligent client devices
US20050090225A1 (en) 2004-11-16 2005-04-28 Om2 Technology Inc. A Simplified Second Generation Enhanced Emergency Communications System SSGE-911
US20050135569A1 (en) 2003-12-19 2005-06-23 Richard Dickinson Enhanced E911 location information using voice over internet protocol (VoIP)
US20050141431A1 (en) 2003-08-06 2005-06-30 Caveney Jack E. Network managed device installation and provisioning technique
US20050153681A1 (en) 2000-03-30 2005-07-14 Mci, Inc. Mobile data device and method of locating mobile data service
US6927727B2 (en) 2003-01-21 2005-08-09 Monica Cleghorn Internet protocol based 911 system
US20050175166A1 (en) 2004-02-10 2005-08-11 Welenson Gregory L. Emergency call completion for VoIP based on location of call originator
US20050190892A1 (en) 2004-02-27 2005-09-01 Dawson Martin C. Determining the geographical location from which an emergency call originates in a packet-based communications network
US20050213716A1 (en) 2004-03-23 2005-09-29 Yinjun Zhu Solutions for voice over internet protocol (VoIP) 911 location services
US20050232164A1 (en) 2004-04-19 2005-10-20 Mitel Networks Corporation Method for recognizing location move of VoIP phones
US20050232253A1 (en) * 2004-03-31 2005-10-20 International Business Machines Corporation Multiple virtual telephones sharing a single physical address
US20050265326A1 (en) 2004-05-27 2005-12-01 Laliberte Donald R Method and system for routing emergency data communications
US20060039539A1 (en) 2004-08-17 2006-02-23 Goldman Stuart O Optimized routing of VOIP emergency calls
WO2006023190A1 (en) 2004-08-24 2006-03-02 Comcast Cable Holdings, Llc Method and system for locating a voice over internet protocol (voip) device connected to a network
US20060068753A1 (en) 2004-09-22 2006-03-30 Jim Karpen Emergency call handling system
US7042985B1 (en) 2003-08-27 2006-05-09 Bellsouth Intellectual Property Corporation Method, system and computer program product for providing a regional E911 network
US20060120517A1 (en) 2004-03-05 2006-06-08 Avaya Technology Corp. Advanced port-based E911 strategy for IP telephony
US20060133354A1 (en) 2004-12-20 2006-06-22 Jin-Suk Lee Apparatus and method for automatically updating address book in an SIP-based VoIP terminal
US7079627B2 (en) 2004-10-13 2006-07-18 Bce Inc. Emergency call handling in a voice-over-packet environment
US7103034B1 (en) 2002-05-09 2006-09-05 Cisco Technology, Inc. Approach for tracking internet protocol telephony devices in networks
US20060201622A1 (en) 2001-03-27 2006-09-14 Ralf Sehr Method and device for attaching support sections for rubber seals to automobile body parts and corresponding support section
US20070058615A1 (en) 2005-08-05 2007-03-15 Hasenfang Dennis J Emergency services for voice over IP telephony (E-VoIP)
US20070104183A1 (en) 2005-11-04 2007-05-10 Tekelec Methods, systems, and computer program products for emergency 911 (E911) registration assistance for subscribers using portable internet protocol (IP) communications devices
US20070115935A1 (en) 2005-11-23 2007-05-24 Sbc Knowledge Ventures L.P. System and method for location management and emergency support for a voice over internet protocol device
US20070127452A1 (en) 2005-11-18 2007-06-07 Jon Croy Voice over Internet protocol (VoIP) mobility detection
US20070147345A1 (en) 2005-12-22 2007-06-28 Robert Lowmaster VoIP 911 address locator service
US20070183396A1 (en) * 2006-02-07 2007-08-09 Bennett James D Set top box supporting bridging between a packet switched network and the public switched telephone network
US20070189469A1 (en) 2006-01-31 2007-08-16 Marian Croak Method and apparatus for providing location information for an emergency service
US20070201622A1 (en) 2006-02-28 2007-08-30 Marian Croak Method and apparatus for providing E911 services for nomadic users
US20070230440A1 (en) 2006-04-03 2007-10-04 Donald Joong Geographical restriction of services in a packet data telecommunications network
US20070280213A1 (en) 2006-05-31 2007-12-06 Texas Instruments Inc. Location verification for VOIP service provider
US20080008179A1 (en) 2006-07-07 2008-01-10 Liren Chen Geolocation-based addressing method for IPv6 addresses
US20080096504A1 (en) 2006-10-23 2008-04-24 Janne Linkola Maintenance of subscriber history for service support applications in an ip-based telecommunications system
US20080125077A1 (en) 2006-08-04 2008-05-29 Leonardo Velazquez Methods and apparatus to update geographic location information associated with internet protocol devices for e-911 emergency services
US20080200143A1 (en) 2007-02-20 2008-08-21 Chaoxin Charles Qiu Systems and methods for location management and emergency support for a voice over internet protocol device
US20080276305A1 (en) 2005-12-22 2008-11-06 Bce Inc. Systems, Methods and Computer-Readable Media for Regulating Remote Access to a Data Network
US20080285544A1 (en) 2007-05-17 2008-11-20 Chaoxin Qiu Method and apparatus for providing mobility for a voice over internet protocol service
US20090003312A1 (en) 2007-06-26 2009-01-01 Leonardo Velazquez Methods and apparatus to provide enhanced 911 (e911) services for nomadic users
US7480933B2 (en) 2002-05-07 2009-01-20 Nokia Corporation Method and apparatus for ensuring address information of a wireless terminal device in communications network
US7773975B2 (en) 2006-07-28 2010-08-10 West Corporation Providing an indication of network capabilities to a user for special number calls
US8401003B1 (en) 2006-03-20 2013-03-19 8X8, Inc. Method and system for updating physical location information
US8531995B2 (en) 2006-11-01 2013-09-10 At&T Intellectual Property I, L.P. Systems and methods for location management and emergency support for a voice over internet protocol device

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8933166B2 (en) * 2004-09-01 2015-01-13 Ppg Industries Ohio, Inc. Poly(ureaurethane)s, articles and coatings prepared therefrom and methods of making the same

Patent Citations (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5161180A (en) 1990-10-19 1992-11-03 Chavous Robert O Call interceptor for emergency systems
US5235630A (en) 1991-04-17 1993-08-10 Telident, Incorporated Emergency call station identification system and method
US5347568A (en) 1991-04-17 1994-09-13 Telident, Incorporated Emergency call station identification system
US5479482A (en) 1993-08-30 1995-12-26 At&T Corp. Cellular terminal for providing public emergency call location information
US20030222820A1 (en) 1996-09-09 2003-12-04 Tracbeam Llc Wireless location using hybrid techniques
US20010022558A1 (en) 1996-09-09 2001-09-20 Tracbeam Llc Wireless location using signal fingerprinting
US20030222819A1 (en) 1996-09-09 2003-12-04 Tracbeam Llc. Locating a mobile station using a plurality of wireless networks and applications therefor
US20040266457A1 (en) 1997-08-20 2004-12-30 Dupray Dennis J. Wireless location gateway and applications therefor
US6421009B2 (en) 1998-05-08 2002-07-16 Peter Suprunov Mobile station position tracking system for public safety
US20030146871A1 (en) 1998-11-24 2003-08-07 Tracbeam Llc Wireless location using signal direction and time difference of arrival
US6650901B1 (en) 2000-02-29 2003-11-18 3Com Corporation System and method for providing user-configured telephone service in a data network telephony system
US20050153681A1 (en) 2000-03-30 2005-07-14 Mci, Inc. Mobile data device and method of locating mobile data service
US6415019B1 (en) 2000-08-21 2002-07-02 Ameritech Corporation Method of providing 911 service to a private branch exchange
US6799049B1 (en) 2000-12-19 2004-09-28 Bellsouth Intellectual Property Corporation System and method for tracking movement of a wireless device
US20060201622A1 (en) 2001-03-27 2006-09-14 Ralf Sehr Method and device for attaching support sections for rubber seals to automobile body parts and corresponding support section
US6678357B2 (en) 2001-09-26 2004-01-13 Siemens Information And Communication Networks, Inc. Internet protocol (IP) emergency connections (ITEC) telephony
US6771742B2 (en) 2001-11-05 2004-08-03 Intrado Inc. Geographic routing of emergency service call center emergency calls
US20040198386A1 (en) 2002-01-16 2004-10-07 Dupray Dennis J. Applications for a wireless location gateway
EP1337089A2 (en) 2002-02-19 2003-08-20 Mitel Knowledge Corporation System and method for maintaining the physical location association of an IP telephone
US20030217122A1 (en) 2002-03-01 2003-11-20 Roese John J. Location-based access control in a data network
US6707888B1 (en) 2002-05-06 2004-03-16 Sprint Communications Company, L.P. Location evaluation for callers that place emergency telephone calls over packet networks
US7480933B2 (en) 2002-05-07 2009-01-20 Nokia Corporation Method and apparatus for ensuring address information of a wireless terminal device in communications network
US7103034B1 (en) 2002-05-09 2006-09-05 Cisco Technology, Inc. Approach for tracking internet protocol telephony devices in networks
US20040057425A1 (en) 2002-09-25 2004-03-25 Brouwer Wim L. Location identification for IP telephony to support emergency services
US6807483B1 (en) 2002-10-11 2004-10-19 Televigation, Inc. Method and system for prediction-based distributed navigation
US20040125923A1 (en) 2002-12-31 2004-07-01 Michael See Automated voice over IP device VLAN-association setup
US6927727B2 (en) 2003-01-21 2005-08-09 Monica Cleghorn Internet protocol based 911 system
US20040151283A1 (en) 2003-02-03 2004-08-05 Lazoff David Michael Poll scheduling for emergency calls
US20050026650A1 (en) 2003-07-30 2005-02-03 Sbc Knowledge Ventures, L.P. Provisioning of wireless private access subscribers for location based services
US20050141431A1 (en) 2003-08-06 2005-06-30 Caveney Jack E. Network managed device installation and provisioning technique
US7042985B1 (en) 2003-08-27 2006-05-09 Bellsouth Intellectual Property Corporation Method, system and computer program product for providing a regional E911 network
US20050063519A1 (en) 2003-09-22 2005-03-24 Foundry Networks, Inc. System, method and apparatus for supporting E911 emergency services in a data communications network
US7027564B2 (en) 2003-09-22 2006-04-11 Foundry Networks, Inc. System, method and apparatus for supporting E911 emergency services in a data communications network
US20050074008A1 (en) 2003-09-23 2005-04-07 France Telecom Method and an associated device for setting up a transfer of data between two communications devices
US8027333B2 (en) 2003-10-21 2011-09-27 Hewlett-Packard Company IP-based enhanced emergency services using intelligent client devices
US20050083911A1 (en) 2003-10-21 2005-04-21 3Com Corporation, A Corporation Of The State Of Delaware IP-based enhanced emergency services using intelligent client devices
US20050135569A1 (en) 2003-12-19 2005-06-23 Richard Dickinson Enhanced E911 location information using voice over internet protocol (VoIP)
US6940950B2 (en) 2003-12-19 2005-09-06 Telecommunication Systems, Inc. Enhanced E911 location information using voice over internet protocol (VoIP)
US20050175166A1 (en) 2004-02-10 2005-08-11 Welenson Gregory L. Emergency call completion for VoIP based on location of call originator
US20050190892A1 (en) 2004-02-27 2005-09-01 Dawson Martin C. Determining the geographical location from which an emergency call originates in a packet-based communications network
US7130385B1 (en) 2004-03-05 2006-10-31 Avaya Technology Corp. Advanced port-based E911 strategy for IP telephony
US20060120517A1 (en) 2004-03-05 2006-06-08 Avaya Technology Corp. Advanced port-based E911 strategy for IP telephony
WO2005104518A2 (en) 2004-03-23 2005-11-03 Telecommunication Services Inc. SOLUTIONS FOR VOICE OVER INTERNET PROTOCOL (VoIP) 911 LOCATION SERVICES
US7260186B2 (en) 2004-03-23 2007-08-21 Telecommunication Systems, Inc. Solutions for voice over internet protocol (VoIP) 911 location services
US20050213716A1 (en) 2004-03-23 2005-09-29 Yinjun Zhu Solutions for voice over internet protocol (VoIP) 911 location services
US20050232253A1 (en) * 2004-03-31 2005-10-20 International Business Machines Corporation Multiple virtual telephones sharing a single physical address
EP1589721A2 (en) 2004-04-19 2005-10-26 Mitel Networks Corporation A method of recognizing location move of VOIP phones and IP devices
US20050232164A1 (en) 2004-04-19 2005-10-20 Mitel Networks Corporation Method for recognizing location move of VoIP phones
US20050265326A1 (en) 2004-05-27 2005-12-01 Laliberte Donald R Method and system for routing emergency data communications
US20060039539A1 (en) 2004-08-17 2006-02-23 Goldman Stuart O Optimized routing of VOIP emergency calls
WO2006023190A1 (en) 2004-08-24 2006-03-02 Comcast Cable Holdings, Llc Method and system for locating a voice over internet protocol (voip) device connected to a network
US20060056388A1 (en) 2004-08-24 2006-03-16 Comcast Cable Holdings, Llc Method and system for locating a voice over internet protocol (VoIP) device connected to a network
US20060068753A1 (en) 2004-09-22 2006-03-30 Jim Karpen Emergency call handling system
US7079627B2 (en) 2004-10-13 2006-07-18 Bce Inc. Emergency call handling in a voice-over-packet environment
US20050090225A1 (en) 2004-11-16 2005-04-28 Om2 Technology Inc. A Simplified Second Generation Enhanced Emergency Communications System SSGE-911
US20060133354A1 (en) 2004-12-20 2006-06-22 Jin-Suk Lee Apparatus and method for automatically updating address book in an SIP-based VoIP terminal
US20070058615A1 (en) 2005-08-05 2007-03-15 Hasenfang Dennis J Emergency services for voice over IP telephony (E-VoIP)
US20070104183A1 (en) 2005-11-04 2007-05-10 Tekelec Methods, systems, and computer program products for emergency 911 (E911) registration assistance for subscribers using portable internet protocol (IP) communications devices
WO2007056186A2 (en) 2005-11-04 2007-05-18 Tekelec Emergency services directory number registartion assistance for subscribers using portable internet protocol (ip) communications devices
US20070127452A1 (en) 2005-11-18 2007-06-07 Jon Croy Voice over Internet protocol (VoIP) mobility detection
US7639792B2 (en) 2005-11-23 2009-12-29 Att Knowledge Ventures, L.P. System and method for location management and emergency support for a voice over internet protocol device
US8189568B2 (en) 2005-11-23 2012-05-29 At&T Intellectual Property I, Lp System and method for location management and emergency support for a voice over internet protocol device
US20070115935A1 (en) 2005-11-23 2007-05-24 Sbc Knowledge Ventures L.P. System and method for location management and emergency support for a voice over internet protocol device
US20070147345A1 (en) 2005-12-22 2007-06-28 Robert Lowmaster VoIP 911 address locator service
US20080276305A1 (en) 2005-12-22 2008-11-06 Bce Inc. Systems, Methods and Computer-Readable Media for Regulating Remote Access to a Data Network
US20070189469A1 (en) 2006-01-31 2007-08-16 Marian Croak Method and apparatus for providing location information for an emergency service
US20070183396A1 (en) * 2006-02-07 2007-08-09 Bennett James D Set top box supporting bridging between a packet switched network and the public switched telephone network
US20070201622A1 (en) 2006-02-28 2007-08-30 Marian Croak Method and apparatus for providing E911 services for nomadic users
US8401003B1 (en) 2006-03-20 2013-03-19 8X8, Inc. Method and system for updating physical location information
US20070230440A1 (en) 2006-04-03 2007-10-04 Donald Joong Geographical restriction of services in a packet data telecommunications network
US20070280213A1 (en) 2006-05-31 2007-12-06 Texas Instruments Inc. Location verification for VOIP service provider
US20080008179A1 (en) 2006-07-07 2008-01-10 Liren Chen Geolocation-based addressing method for IPv6 addresses
US7773975B2 (en) 2006-07-28 2010-08-10 West Corporation Providing an indication of network capabilities to a user for special number calls
US8064875B2 (en) 2006-08-04 2011-11-22 At&T Intellectual Property I, L.P. Methods and apparatus to update geographic location information associated with internet protocol devices for E-911 emergency services
US20080125077A1 (en) 2006-08-04 2008-05-29 Leonardo Velazquez Methods and apparatus to update geographic location information associated with internet protocol devices for e-911 emergency services
US20080096504A1 (en) 2006-10-23 2008-04-24 Janne Linkola Maintenance of subscriber history for service support applications in an ip-based telecommunications system
US8531995B2 (en) 2006-11-01 2013-09-10 At&T Intellectual Property I, L.P. Systems and methods for location management and emergency support for a voice over internet protocol device
US9019870B2 (en) 2006-11-01 2015-04-28 At&T Intellectual Property I, L.P. Systems and methods for location management and emergency support for a voice over internet protocol device
US20080200143A1 (en) 2007-02-20 2008-08-21 Chaoxin Charles Qiu Systems and methods for location management and emergency support for a voice over internet protocol device
US8620257B2 (en) 2007-02-20 2013-12-31 At&T Intellectual Property I, L.P. Systems and methods for location management and emergency support for a voice over internet protocol device
US20080285544A1 (en) 2007-05-17 2008-11-20 Chaoxin Qiu Method and apparatus for providing mobility for a voice over internet protocol service
US20090003312A1 (en) 2007-06-26 2009-01-01 Leonardo Velazquez Methods and apparatus to provide enhanced 911 (e911) services for nomadic users

Non-Patent Citations (22)

* Cited by examiner, † Cited by third party
Title
"CCS/SS7 Generic Requirements in Support of E9-1-1 Service Contents," GR-2956-Core, Dec. 2002 (3 pages).
"CCS/SS7 Generic Requirements in Support of E9-1-1 Service," Telecordia, Dec. 2002 (3 pages) [Retrieved via Internet at http://telecom-info.telcordia.com/site-cgi/ido/docs.cgi?ID=SEARCH&DOCUMENT=GR-2956&].
Akundi et al., "i2 Solution Overview," Nortel Networks, Mar. 2005 (15 pages).
AT&T, "AT&T Business Service Guide," AT&T Business Voice over IP (BVoIP) Services, Oct. 31, 2006, (40 pages).
Cauley, "AT&T Solves VoIP's 911 Issue," USA Today, Oct. 10, 2005 (2 pages) [Retrieved via Internet at http://www.usatoday.com/tech/news/techinnovations/2005-10-10-voip-att-x.htm].
Frost & Sullivan, "U.S. E9-1-1 Market Insight 6847-63," www.frost.com, 2003, (61 pages).
Gabber et al., "On Location-Restricted Services," IEEE Network, Nov./Dec. 1999, pp. 44-52, (9 pages).
International Bureau, "International Preliminary Report on Patentability," issued in connection with PCT application Serial No. PCT/US2008/051141 on Aug. 26, 2009 (13 pages).
International Bureau, "Invitation to Pay Additional Fees and Partial International Search," issued in connection with PCT application Serial No. PCT/US2008/051141 on Jan. 27, 2009 (5 pages).
National Emergency Number Association (NENA) Technical Committee Chairs, "Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)," NENA Template for Creating or Updating E9-1-1 Standards Documents, Issue 1 Draft, Aug. 5, 2005, (196 pages).
Patent Cooperation Treaty, "International Search Report," issued by the International Searching Authority in connection with related PCT application No. PCT/US2008/051141, mailed Mar. 27, 2009 (6 pages).
Patent Cooperation Treaty, "Written Opinion of the International Searching Authority," issued by the International Searching Authority in connection with related PCT application No. PCT/US2008/051141, mailed Mar. 27, 2009 (11 pages).
Rosenberg et al., "An Offer/Answer Model with the Session Description Protocol (SDP)," Network Working Group, RFC 3264, Jun. 2002 (25 pages).
Rosenberg et al., "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)," RFC 3262, Network Working Group, Jun. 2002 (14 pages).
Rosenberg et al., "Session Initiation Protocol (SIP): Locating SIP Servers," Network Working Group, RFC 3263, Jun. 2002 (17 pages).
Rosenberg et al., "SIP: Session Initiation Protocol," Network Working Group, RFC 3261, Jun. 2002 (269 pages).
Telecordia, "CCS/SS7 Generic Requirements in Support of E9-1-1 Service," Dec. 2002 (3 pages) [Retrieved via Internet at http://telecom--info.tekordia.com/silecgi/ido/docs.cgi9ID=SEARCH&DOCUMENT=GR-2956&].
United States Patent and Trademark Office, "Final Office Action," issued in connection with U.S. Appl. No. 11/555,569, on May 24, 2011 (24 pages).
United States Patent and Trademark Office, "Non-Final Office Action," issued in connection with U.S. Appl. No. 11/555,569, on Jan. 12, 2011 (21 pages).
United States Patent and Trademark Office, "Non-Final Office Action," issued in connection with U.S. Appl. No. 11/555,569, on Nov. 7, 2012 (25 pages).
United States Patent and Trademark Office, "Notice of Allowance," issued in connection with U.S. Appl. No. 11/555,569, on May 10, 2013 (15 pages).
United States Patent and Trademark Office, "Notice of Allowance," issued in connection with U.S. Appl. No. 14/021,828, on Jan. 2, 2015 (17 pages).

Also Published As

Publication number Publication date
US20080101552A1 (en) 2008-05-01
US20140016634A1 (en) 2014-01-16
US20150312357A1 (en) 2015-10-29
US8531995B2 (en) 2013-09-10
US9019870B2 (en) 2015-04-28

Similar Documents

Publication Publication Date Title
US9432467B2 (en) Systems and methods for location management and emergency support for a voice over internet protocol device
US8620257B2 (en) Systems and methods for location management and emergency support for a voice over internet protocol device
US11252779B2 (en) Physical location management for voice over packet communication
US8064875B2 (en) Methods and apparatus to update geographic location information associated with internet protocol devices for E-911 emergency services
US8599718B2 (en) Methods and apparatus to provide enhanced 911 (E911) services for nomadic users
US7123693B2 (en) Method and apparatus for increasing the reliability of an emergency call communication network
US9264290B2 (en) System and method for location management and emergency support for a voice over internet protocol device
US7496182B2 (en) Handling emergency service calls originating from internet telephony
US8149269B2 (en) Emergency services call delivery from a legacy communications device to a VoIP PSAP
US8289958B1 (en) Using a clearinghouse to determine caller location for VoIP calls
US20080153455A1 (en) System, method and program for managing voip calls such as 911 calls from mobile devices
US20050201359A1 (en) Dynamically establishing media channels between resources of an emergency services network and conforming emergency systems
CN102598645B (en) Urgent signaling in IP Multimedia System network
US9072074B1 (en) Method and apparatus for determining the location of a terminal adaptor

Legal Events

Date Code Title Description
AS Assignment

Owner name: SBC KNOWLEDGE VENTURES, L.P., NEVADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KHAN, RICHARD L;QIU, CHAOXIN;DAILEY, ROBERT F;REEL/FRAME:036005/0142

Effective date: 20061031

AS Assignment

Owner name: AT&T INTELLECTUAL PROPERTY I, L.P., GEORGIA

Free format text: CHANGE OF NAME;ASSIGNOR:AT&T KNOWLEDGE VENTURES, L.P.;REEL/FRAME:036723/0740

Effective date: 20071001

Owner name: AT&T KNOWLEDGE VENTURES, L.P., GEORGIA

Free format text: CHANGE OF NAME;ASSIGNOR:SBC KNOWLEDGE VENTURES, L.P.;REEL/FRAME:036723/0894

Effective date: 20060224

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: AT&T KNOWLEDGE VENTURES, L.P., NEVADA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE CORRECT ASSIGNEE AND SUPPORTING ASSIGNMENT PREVIOUSLY RECORDED AT REEL: 036005 FRAME: 0142. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNORS:KHAN, RICHARD L.;QIU, CHAOXIN;DAILEY, ROBERT F.;REEL/FRAME:050711/0884

Effective date: 20061110

Owner name: AT&T INTELLECTUAL PROPERTY I, L.P., GEORGIA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE CONVEYING PARTY NAME ALSO RECEIVING PARTY NAME PREVIOUSLY RECORDED AT REEL: 38723 FRAME: 894. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:AT&T KNOWLEDGE VENTURES, L.P.;REEL/FRAME:050711/0983

Effective date: 20071001

AS Assignment

Owner name: RINGCENTRAL, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AT&T INTELLECTUAL PROPERTY I, L.P.;REEL/FRAME:050824/0312

Effective date: 20190930

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA

Free format text: SECURITY INTEREST;ASSIGNOR:RINGCENTRAL, INC.;REEL/FRAME:062973/0194

Effective date: 20230214