Telecommunication Systems, Inc.

Telecommunications Systems, Inc.

Gerhard Geldenbott

Victor C Burton

Gordon John Hines

Yinjun Zhu

John Gordon Hines

Bhavesh Goswami

Salman Ali

Arpita Saha

Yi-Min Flora Chua

Andy Hazzard

Jeffrey Thomas Martin

Jeff Martin

Ed Day

Abe Backus

An emergency services key (e.g., ESQK or ESRK) is guaranteed to be available from a limited size ESQK pool. A plurality of ESQKs are grouped into a pool of emergency service keys 'ESQK Pool ID', each including anywhere from 1 to N number of ESQKs. Each ESQK preferably has a 'Timestamp', information relating to the specific emergency E911 call (&#x201c;Call Data ID&#x201d;), a guard timer, and an optional hold timer. The ESQK having a Call Data ID=&#x201c;NULL&#x201d;, and having the oldest Timestamp, is chosen for selection. If no such ESQK has both Call Data ID=NULL and the oldest Timestamp is found, then the ESQK with merely the oldest Timestamp is selected. The timestamp is reset to a current time plus a guard timer, or hold timer if desired.

Extended efficient usage of emergency services keys

A logic history can be provided for every request or call instance through a distributed computing system that uniquely traces its entire path, end-to-end, in-band within the messaging for the system. The end result is a single true representation of what occurred with no post computational inference. Accordingly, unique logic history codes are not forced across the system. Rather sub-components that are logic history enabled can use codes that have meaning and applicability to itself. Unique logic history codes are not forced across the system, which in practice would be brittle. Rather each sub-component that is logic history enabled can use codes that have meaning and applicability only to itself. This allows the system to be flexible and lets sub-components change and redefine their logic and logic history traces without impacting the rest of the system.

End-to-end logic tracing of complex call flows in a distributed call system

A technique and apparatus to allow a determination of an MSAG-valid address by use of normalized house numbers included in address entries in an MSAG Address data store, to facilitate the simple match of an input civic/postal address against entries in a MSAG data store based on the use of a normalization of the house numbers. The house number normalization allows for an easy lexicographical determination as to whether or not the input civic/postal house number falls with the range of house numbers in the MSAG data store. The inventive process and apparatus pre-stores normalized house number fields in an MSAG address data store, and then normalizes house numbers in a civic/postal address associated with an emergency call. The normalized numbers in the input civic/postal address associated with the emergency call are then lexicographically matched with normalized entries in an MSAG address data store.

House number normalization for master street address guide (MSAG) address matching

A prank call server that performs 911 prank call filtering over a 911 emergency call system, prior to routing a 911 call to a PSAP. The inventive prank call server identifies prank calling devices, regardless of current service subscription, by retrieving and analyzing emergency call data pertaining to detected prank 911 calls. The prank call server assigns a unique global identifier to each 911 call detected on the 911 emergency call system. Unique global identifiers enable a PSAP to uniquely identify prank 911 calls that are identified thereon. A PSAP transmits a prank call signal and a relevant unique global identifier to the prank call server, for each prank 911 call that is detected. A prank call signal/unique global identifier combination triggers the prank call server to store all available call data for a referenced prank 911 call in to a prank call database, for subsequent prank call filtering analysis.

Unique global identifier header for minimizing prank emergency 911 calls

Unique global identifier header for minimizing prank 911 calls

An emergency services key (e.g., ESQK or ESRK) is guaranteed to be available from a limited size ESQK pool, such that an available ESQK is always selected and associated with an ongoing emergency call with no measurable impact to existing calls, even if all ESQK pool members are marked as unavailable. A plurality of ESQKs are grouped into a pool of emergency service keys 'ESQK Pool ID', each including anywhere from 1 to N number of ESQKs. Each ESQK preferably has a 'Timestamp', and information relating to the specific emergency E911 call (&#x201c;Call Data ID&#x201d;). The ESQK having a Call Data ID=&#x201c;NULL&#x201d;, and having the oldest Timestamp, is chosen for selection. If no such ESQK has both Call Data ID=NULL and the oldest Timestamp is found, then the ESQK with merely the oldest Timestamp is selected.

Efficient usage of emergency services keys

The present invention is used in an emergency network to identify and provide the correct public safety access point (PSAP) to service an emergency call originating from a Voice Over Internet Protocol (VoIP) subscriber. Data stores in an emergency services network associate PSAPs to an input ZIP code obtained from a street address returned from an MSAG relating to a VoIP call, and PSAPs to an input ESN. An emergency caller's civic street address is matched against a nationwide MSAG data store to result in a MSAG ESN. From the street address, the emergency caller's ZIP code is matched to a PSAP in an appropriate ZIP/PSAP data store. A matching PSAP from both the ZIP/PSAP and PSAP/ESN data stores determines with great reliability the identity of the proper PSAP for that emergency caller.

Growing community of inventors

Seattle, WA, United States of America

Gerhard Geldenbott