Patent Grant
10070251
The subject matter described herein relates to enhancing telecommunications network security. More particularly, the subject matter described herein relates to validating UE location as a condition to allowing processing of location update signaling messages.
Telecommunications signaling networks, like most computer networks, have certain attack vulnerabilities. For example, in a mobile communications network, if an attacker gains access to subscriber information maintained by a home location register (HLR) or a home subscriber server (HSS), the attacker can use the information to eavesdrop on text messages and voice conversations involving the subscriber. Accordingly, it is desirable to protect subscriber information maintained by an HLR or HSS.
Protecting subscriber information maintained by an HLR or HSS can be difficult because subscriber information is transmitted over the network in response to location update procedures and there is no authentication or verification of the initiator of such procedures. For example, when a UE attaches to a network, the attachment point (the mobile switching center/visitor location register (MSC/VLR) in SS7 networks or the mobility management entity (MME) in Diameter networks) sends messaging to the HLR or HSS to update the location of the UE with the HLR or HSS. The HLR or HSS responds with subscription information concerning the subscriber. It is the subscription information that could possibly be used to eavesdrop or otherwise affect communications to and from the UE.
If an attacker masquerades as a valid network element serving the UE but is instead acting as an interception point for subscription information, the attacker can use the update location procedure to obtain the subscription information. For example, the attacker can send a fake update location message to the HLR or HSS network of the subscriber. The HLR or HSS may respond to the attacker with subscription information for the subscriber as if the attacker is a valid MSC/VLR or MME where the UE is currently registered. The subscription information is transmitted to the attacker in a location update response message. Once the attacker has the subscription information, the attacker can eavesdrop on communications involving the subscriber.
Credit card companies have used location information from mobile communications networks to validate credit card transactions. For example, a credit card company or an issuing bank can use location information from mobile communications networks to verify that the location of a credit card transaction corresponds to a location of the user. If the two locations do not match, the credit card company may request transaction verification from the subscriber. However, while such verification protects against fraudulent credit card purchase transactions, location update transactions in the underlying mobile communications network are not policed or otherwise affected.
Accordingly, there exists a need for methods, systems, and computer readable media for validating user equipment location.
Methods, systems, and computer readable media for validating UE location are disclosed. One method for validating user equipment (UE) location includes receiving, by a network gateway, a signaling message for updating a location of a UE with a mobile communications network. The method further includes extracting a first indication of location of the UE from the signaling message. The method further includes obtaining, by querying one of a cloud-based UE location database containing UE location information obtained from a UE location reporting application resident on the UE, a cloud-based loyalty card transaction database containing loyalty card transaction records indexed by UE identifiers, and a mobile location center (MLC) that obtains UE location information by requesting or receiving the UE location information from a mobility management entity (MME), a second indication of location of the UE. The method further includes determining, from a relationship between the first and second indications of location of the UE, that the signaling message is suspicious. The method further includes, in response to determining that the signaling message is suspicious, applying a policy rule to processing of the signaling message.
According to one aspect of the subject matter described herein, the signaling message from which the first indication of location of the UE is extracted comprises one of a Diameter update location request (ULR) message and an SS7 location update message.
According to another aspect of the subject matter described herein, the first indication of location of the UE comprises a network identity extracted from the signaling message. In one example, the network identity may be a visited public land mobile network (PLMN) identifier. The visited PLMN identifier may include a mobile network code (MNC) and a mobile country code (MCC), which can be compared against other location information to validate UE location.
According to yet another aspect of the subject matter described herein, the second indication of location of the UE that is compared with the information extracted from the signaling message may include global positioning system (GPS) coordinates of the UE. In such an implementation, determining, from a relationship between the first and second indications of location of the UE, that the signaling message is suspicious may include determining that a location indicated by the GPS coordinates does not match the first indication of location of the UE extracted from the signaling message. In one example, the GPS coordinates of the UE may be obtained from the cloud-based UE location database containing UE location information populated by the UE location reporting application on the UE.
According to yet another aspect of the subject matter described herein, the second indication of location of the UE to be compared with the location information extracted from the signaling message may include a loyalty card transaction location obtained from the cloud-based loyalty card transaction database. In such an implementation, determining, from a relationship between the first and second indications of location of the UE, that the signaling message is suspicious includes determining that the loyalty card transaction location does not match the first indication of location of the UE.
According to yet another aspect of the subject matter described herein, the second indication of location of the UE that is compared with the information extracted from the signaling message is a location obtained from the cloud-based loyalty card transaction database. In such a case, determining that the signaling message is suspicious includes determining that the loyalty card transaction location does not match the first indication of location of the UE.
As used herein, the term “loyalty card transaction” includes credit card transactions, debit card transactions, or other electronic transactions involving a plastic or software-implemented card of a telecommunication network subscriber for which transaction location information is stored.
According to yet another aspect of the subject matter described herein, applying the policy rule in response to the locations not matching includes blocking the signaling message from being forwarded to a home subscriber server (HSS) or a home location register (HLR), marking the signaling message as suspicious, and forwarding a copy of the message to fraud analytics platform.
According to yet another aspect of the subject matter described herein, a system for validating user equipment (UE) location is disclosed. The system includes a network gateway. The network gateway includes a message processor located in the network gateway for receiving a signaling message for updating a location of a UE with a mobile communications network. The system further includes a UE location validation module operatively associated with the network gateway for extracting a first indication of location of the UE from the signaling message, obtaining, by querying one of a cloud-based UE location database containing UE location information obtained from a UE location reporting application resident on the UE, a cloud-based loyalty card transaction database containing loyalty card transaction records indexed by UE identifiers, and a mobile location center (MLC) that obtains UE location information by requesting or receiving the UE location information from a mobility management entity (MME), a second indication of location of the UE, and determining, from a relationship between the first and second indications of location of the UE, that the signaling message is suspicious. In response to determining that the signaling message is suspicious, the network gateway applies a policy rule to processing of the signaling message.
As used herein, the term “location update message” refers to a message for updating a location and other mobile subscriber in a telecommunications network. “Location update message” is intended to cover Diameter update location request messages, SS7 mobile application part (MAP) update location messages, or other message for updating the location of a telecommunications network subscriber with the network.
The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms “function” “node” or “module” as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
The subject matter described herein will now be explained with reference to the accompanying drawings of which:
The subject matter described herein relates to methods, systems, and non-transitory computer readable media for validating UE location and reducing signaling network attack vulnerability using such validation.
In the illustrated example, UE 114 is roaming in a network external to the home network and is attached to a real MME 116. Location reporting application 112 may interface with a GPS transceiver on UE 114 to determine the UE's GPS location. UE location reporting application 112 may either periodically push GPS location data to cloud UE GPS database 110 or provide the GPS location data to cloud UE GPS database in response to queries from cloud UE GPS database 110. Either implementation is intended to be within the scope of the subject matter described herein.
Another network illustrated in
In the illustrated example, attacker 118 generates a Diameter update location request (ULR) message and sends the message to network gateway 100. The ULR message contains the identifier of UE 114 but directs a response back to attacker 118 instead of to MME 116 where UE 114 is actually registered. Network gateway 100 receives the ULR message and, without the UE location validation procedures described herein, would simply forward the message to HSS 104. HSS 104 would then formulate and send an update location answer (ULA) message with the subscription information. Network gateway 100 would then route the ULA message to attacker 118. Attacker 118 would then extract the subscription information from the ULA message and use the information to intercept calls or other communications to or from UE 114.
However, rather than simply passing the ULR message to HSS 104, UE location validation module 102 queries a source separate from the update location request message to obtain UE location information and uses that information to perform a location validation. In
Cloud UE GPS database 110 may obtain the GPS location of UE 114 by first checking to see whether database 110 contains a current GPS location for UE 114. If the location for UE 114 in database 110 is current (e.g., updated within a predetermined time period from the current time, where the time period is configurable by the network operator), cloud UE GPS database 110 may provide the stored GPS location as the current location of the UE. If cloud UE GPS database 110 does not contain a current GPS location of a UE, cloud UE GPS database 110 may query UE 114 for its current location. In response to the query, location reporting application 112 may respond with the current GPS, coordinates of UE 114. Cloud UE GPS database 110 may receive the GPS location from UE location reporting application 112 and forward the location information to UE location validation module 102.
Upon receiving GPS location data of UE 114, UE location validation module 102 performs a location validation check by comparing the UE location information in the ULR with the GPS coordinates provided by cloud UE GPS database 110. If the ULR location information matches the GPS location information, gateway 100 will forward the ULR to a HSS 104 for further update location processing. However, if the GPS location data does not match the location data in the ULR, the location validation fails and UE location validation module 102 blocks the ULR from being forwarded to HSS 104.
In response to unsuccessful validation of a UE location, UE location validation module 102 may mark the ULR message as suspicious and forward a copy of the suspicious message to fraud analytics platform 106. Fraud analytics platform 106 may analyze the ULR message, extract information identifying attacker 118, and use that information to populate an access control list in network gateway 100 to block subsequent messages from attacker 118.
Thus, in
As stated above, UE location validation module 102 compares location information extracted from ULR messages with GPS coordinates obtained from cloud GPS database 110. Because ULR messages do not contain GPS coordinates, some mapping may be required. Table 1 shown below includes mandatory and optional fields that may be included in a Diameter ULR message.
In Table 1, the update location request message includes a visited public land mobile network (PLMN) ID field. The visited PLMN ID identifies the mobile country code (MCC) and mobile network code (MNC) to which the UE is currently attached. The country and network information can be compared with the GPS coordinates obtained from cloud UE GPS database 110 to determine whether the ULR is suspicious or not. For example, if the GPS coordinates obtained from cloud UE GPS database 110 indicate that the UE is in a country that does not match the country code extracted from the ULR message, the ULR message may be identified as suspicious. Similarly, if the GPS coordinates extracted from database 110 do not match a location within the coverage area of the network indicated by the mobile network code in the visited PLMN ID field, the ULR message may be marked as suspicious. If the GPS coordinates obtained from cloud GPS database 110 match the country and network obtained from the ULR message, the UE location validation passes and UE location validation module 102 may forward the ULR message to HSS 104 for further location update processing.
In
In Table 2, loyalty card transaction records for a particular day for UE identifier 9194938000 are illustrated. The UE identifier can be provisioned in database 200 by the operator of database 200, for example, when the mobile subscriber signs up for a new loyalty card. Alternatively, database 200 can be dynamically provisioned when the UE is used to conduct loyalty card transactions. In the illustrated example, the record includes the loyalty card identifier which may be a PAN number, the transaction location, and the transaction time. The transaction location may be any indication of location that is stored for a loyalty card transaction. To facilitate illustration, the city and state of the transaction are shown. However, it is understood that more precise locations, such as retail store locations or GPS locations of transactions, may be stored. The record also includes a transaction time, which is illustrated as a time of day and a date.
In order to validate a UE's location using loyalty card transaction information maintained in loyalty card transaction database 200, when UE location validation module 102 receives a ULR message from MME or an attacker masquerading as an MME, UE location validation module 102 may query loyalty card transaction database 200. Loyalty card transaction database 200 may respond by providing records, such as those illustrated in Table 2, that show the location of loyalty card transactions involving the subscriber on a given day. UE location validation module 102 may compare the location information extracted from the ULR message with the transaction location information obtained from loyalty card transaction database 200 and determine whether there is a match. If the ULR-message-obtained location information matches the location information obtained or derived from loyalty card transaction database 200, UE location validation module 102 may forward the ULR message to HSS 104 without further UE location validation processing. However, if the location information extracted from the ULR message does not match the information obtained or derived from loyalty card transaction database 200, location validation module 102 may block the sending of the ULR message to HSS 104, mark the ULR message as suspicious, and forward a copy of the ULR message to fraud analytics platform 106
Fraud analytics platform 106 may analyze the message and possibly populate an access control database on network gateway 100 to block further messages from the attacker masquerading as a real MME. For example, using the data in Table 1, if the ULR message contains data that indicates that the UE is registered at an MME in Los Angeles, Calif. on 6/7/17, that data does not match the transaction location information obtained from database 200 because all of the entries for the subscriber in database 200 indicate that the subscriber is in North Carolina on Jun. 7, 2017. Accordingly, in such a case, UE location validation module 102 would block the ULR message and send the message to fraud analytics platform 106.
In yet another alternate implementation of the subject matter described herein, UE location validation module 102 may query a mobile location center, such as a gateway mobile location center (GMLC), to obtain UE location information for location validation.
In Table 3, the mandatory fields in the provide subscriber location information request include either the IMSI, MSISDN, or the IMEI and the location type requested. Other mandatory fields include the name of the location services client issuing the request and the client type.
In response to receiving the subscriber location information request message, MME 302 responds with a provide subscriber location response. Table 4 shown below illustrates mandatory and optional fields of a provide subscriber location response message.
As illustrated in Table 4, optional fields in the provide subscriber location response include location information, such as an estimate of the location of the UE in universal coordinates, an indication of the accuracy of the location information, age of location information, velocity estimate, server node, etc. Any one more or more of these optional information fields may be used by UE location validation module 102 to validate UE location information extracted from an update location request message. For example, UE location validation module 102 may obtain a location estimate from GMLC 300. UE location validation module 102 may compare the location estimate obtained from GMLC 300 to the mobile network and mobile country code extracted from the ULR message. If the location estimate indicates the UE is in a different location than the location corresponding to the country and network obtained from the ULR message, UE location validation module 102 may block the ULR message from being forwarded to HSS 104. If the location estimate matches the mobile network and country code obtained from the ULR message, UE location validation module 102 may allow the ULR message forwarded to HSS 104 for further location update processing.
GMLC 300 may also obtain subscriber location information from MME 302 without sending a provide subscriber location request message. This procedure is illustrated in
As illustrated in Table 5 above, the subscriber location report message includes the IMSI, MSISDN, or IMEI of the subscriber. The subscriber location report message also includes various fields that specify subscriber location, location accuracy, and location time. As will be described in further detail below, UE location validation module 102 may use this location information to validate location information extracted from a Diameter ULR message. In
Returning to
As stated above with regard to Table 1, the location information from the ULR that is of interest for validation may include the visited PLMN ID field. The visited PLMN ID field contains the mobile country code and the mobile network code. The mobile country code and the mobile network code may be compared to the location information obtained from GMLC 300. For example, the mobile country code and mobile network call can be compared to the data extracted from the location estimate field of the subscriber location report message and stored by GMLC 300. If the information matches, UE location validation module 102 may forward the ULR message to HSS 104 without further UE location validation processing. If the information in the ULR message does not match the information obtained from GMLC 300, UE location validation 102 may block the ULR message from being forwarded to HSS 104, mark the message as suspicious, and send a copy of the message to fraud analytics platform 106. Fraud analytics platform 106 may process the ULR message to identify attacker 118 masquerading as an MME and possibly populate an access control database in network gateway 100 to block further messages from attacker 118.
The examples in
In an illustrated example, UE 114 is roaming in a visited network and is currently attached to MSC/VLR 404 in the visited network. Attacker 406 is located in an attacker network separate from the visited network and masquerades as an MSC/VLR. In the illustrated example, attacker 406 sends a MAP location update message to HLR 400. The location update message includes an identifier, such as an IMSI, MSISDN and/or IMEI identifying UE 114. The location update message is an (Interim Standard-41) IS-41 message carried in a mobile application part of an SS7 message and contains an identifier of the MSC/VLR serving the subscriber and also the SS7 point code of the MSC/VLR. In response to receiving the MAP location update message, UE location validation module 102 may query UE location database 110, 200 or 300 with a subscriber or UE identifier and obtain a location response with UE location data from database 110, 200 or 300. UE location validation module 102 then performs a UE location validation by comparing the location information extracted from the MAP location update message with the UE location information obtained from UE location database 110, 200 or 300. If the locations do not match, UE location validation module 102 may mark the location update message as suspicious, block the location update message from being sent to HLR 400, and forward a copy of the suspicious location update message to fraud analytics platform 106 for further processing. Fraud analytics platform 106 may extract the MSC/VLR address and use that information to populate an access control database in STP 100 to block further messages from attacker 118. If UE location validation module 102 determines that the location in the MAP location update message matches the UE location obtained from database 110, 200 or 300, UE location validation module 102 may forward the location update message to HLR 400 without further location validation processing. Thus, UE location validation module 102 performs UE location validation for SS7 location update messages.
Network gateway 100 may perform UE location validation for SS7 location update messages and Diameter update location request messages originating from attackers masquerading as MMEs in long term evolution networks or as MSC/VLRs in SS7 networks. If network gateway 100 implements STP functionality, location validation module 102 can validate location information in SS7 MAP location update messages and block the forwarding of such messages to an HLR upon failed UE location validations. If network gateway 100 implements DSR functionality, location validation module 102 can block the forwarding of Diameter ULR messages to an HSS upon failed UE location validations.
Referring to the architecture of
Each message processor 500, 502, 504, and 506 may be configured with software to perform a particular function or functions. In the illustrated example, message processor 500 is configured with software that implements Diameter connection and routing functionality. Message processor 500 therefore includes a Diameter connection layer (DCL) 512 that maintains Diameter connections with other Diameter nodes and a Diameter routing layer (DRL) 514 that routes Diameter messages to other nodes and to message processors 504 and 506 for application processing.
Message processor 502 is configured with software that implements SS7 connection and routing functionality. Accordingly, message processor 502 includes a signaling transport (SIGTRAN) protocol stack 516 that allows SS7 messages to be transported over IP networks and SS7 protocol stack 518 (minus MTP layers 1 and 2) that carries SS7 information, such as MTP3, signaling connection control part (SCCP), transaction capabilities application part (TCAP), and MAP information.
Message processor 504 includes UE location validation module 102 for performing UE location validation as described above. Message processor 506 may include other applications 520 for processing Diameter and/or SS7 messages. Examples of other applications that may be implemented include number portability, global title translation, HLR or HSS location caching, etc.
Thus, when a location update message, such as a Diameter ULR or an SS7 MAP location update message, arrives at one of message processors 500 and 502, the receiving message processor forwards the message to message processor 504 for UE location validation processing. UE location validation module 102 validates the message by querying the appropriate location information source, obtaining the external location information, and using that information to compare with the information extracted from the location update message. If the message passes the UE location validation, UE location validation module 102 forwards the message to the HLR or the HSS via the appropriate egress message processor 500 or 502. If the message does not pass UE location validation, UE location validation module 102 marks the message as suspicious and sends a copy of the message to fraud analytics platform 106 via one of message processors 500 or 502.
In step 606, it is determined whether the first and second indications of location of the UE match. Determining whether the indications of UE location match may include comparing the location obtained from the cloud-based UE location database, the cloud-based loyalty card transaction database or the MLC to the location extracted from the signaling message for updating the location of the subscriber. If the external location source is cloud GPS database 110, the comparing may include determining whether the mobile network specified by the MNC extracted from the update location message has radio coverage at the location specified by the GPS coordinates. Similarly, if the external location source is loyalty card transaction database 200, determining whether the indications of location match may include determining whether the transaction locations obtained from loyalty card transaction database 200 correspond to locations where the mobile network specified by the MNC specified by the mobile network code in the location update message has radio coverage. If the external location source is GMLC 300, determining whether the first and second indications of location of the UE match may include determining whether the network specified by the MNC in the update location message has radio coverage at the coordinates specified by the location estimate obtained from GMLC 300. It should be understood that these location comparisons are given for example purposes only and any field from a Diameter update location request or an SS7 location update message that specifies UE location or from which UE location can be derived can be compared with any of the parameters listed herein that specify UE location or from which UE location can be derived without departing from the scope of the subject matter described herein.
If the first and second indications of location of the UE match, control proceeds to step 608 where the UE location update request is routed to the HLR or HSS and UE location validation processing ends. If however, in step 606, it is determined that the UE location information does not match, control proceeds to step 610 where the UE update location request is blocked or prevented from being forwarded from to the HLR or HSS. Control then proceeds to step 612 where the UE update location request is marked as suspicious and forwarded to fraud analytics platform 106. Fraud analytics platform 106 many analyze the suspicious update location request message, create data for an access control list entry for blocking future communications from the attacker, and forward the data to network gateway 100 for installation in an access control list maintained by network gateway 100.
Instead of creating an access control list entry, fraud analytics platform 106 may flag the MSISDN, IMSI, and/or IMEI associated with the location update messages and create data for populating a screening database maintained by network gateway 100 and forward the screening data to network gateway 100. Network gateway 100 may install the screening data in a screening database so that any message received by network gateway 100 that includes the MSISDN, IMSI, and/or IMEI is copied, and the message copy is sent to fraud analytics platform 106 for further fraud analysis. If the further analysis indicates that the message originated from an attacker, fraud analytics platform 106 may notify the network operator and/or generate data for a screening database rule that blocks future messages involving the MSISN, IMSI, and/or IMEI.
In the examples described above, UE location validation is performed by UE location validation module 102 residing on network gateway 100. However, the subject matter described herein is not limited to such an implementation. In an alternate implementation, UE location validation module 102 may be located on a computing platform separate from network gateway 100 but operatively associated with network gateway 100. In such an implementation, network gateway 100 may receive the location update message, and forward the message or a copy of the message from the message and forward the UE to UE location validation module 102. UE location validation module 102 may extract the location information from the message, obtain the location message from the location source, such as database 110, 200, or 300. UE location validation module 102 may then perform the validation and send a validation result to network gateway 100. If the validation result indicates that the message passes the UE location validation, then the validation result indicates such passing, and gateway 100 forwards the update location message to the HLR or the HSS. If the validation result indicates that the message fails the UE location validation, UE location validation module 102 may forward a policy rule to gateway 100 where the policy rule indicates that the update location message should not be forwarded to the HLR or HSS. Network gateway 100 may install the policy rule and use the policy rule to block forwarding of the update location message to the HLR or HSS.
In the examples described above, databases 110, 200, and 300 are located on computing platforms separate from network gateway 100. In an alternate embodiment, any one or more of databases 110, 200, or 300 or a local copy of any one or more of databases 110, 200, or 300 may reside on network gateway 100. In such an implementation, network traffic may be reduced over the implementations described above because the need to forward location queries and responses across a network is obviated.
It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7043754 | Arnouse | May 2006 | B2 |
| 8045956 | Sun et al. | Oct 2011 | B2 |
| 8615217 | Ravishankar et al. | Dec 2013 | B2 |
| 8879431 | Ridel et al. | Nov 2014 | B2 |
| 9191803 | Patel et al. | Nov 2015 | B2 |
| 9240946 | Cai et al. | Jan 2016 | B2 |
| 9374840 | Monedero Recuero | Jun 2016 | B2 |
| 9628994 | Gunyel | Apr 2017 | B1 |
| 20040140908 | Gladwin et al. | Jul 2004 | A1 |
| 20070174082 | Singh | Jul 2007 | A1 |
| 20080222038 | Eden | Sep 2008 | A1 |
| 20090045251 | Jaiswal et al. | Feb 2009 | A1 |
| 20090195349 | Frader-Thompson et al. | Aug 2009 | A1 |
| 20110014939 | Ravishankar et al. | Jan 2011 | A1 |
| 20110029655 | Forbes, Jr. et al. | Feb 2011 | A1 |
| 20110063126 | Kennedy et al. | Mar 2011 | A1 |
| 20110124317 | Joo | May 2011 | A1 |
| 20110173122 | Singhal | Jul 2011 | A1 |
| 20110225091 | Plastina | Sep 2011 | A1 |
| 20110307381 | Kim et al. | Dec 2011 | A1 |
| 20120099715 | Ravishankar et al. | Apr 2012 | A1 |
| 20120131121 | Snyder | May 2012 | A1 |
| 20120203663 | Sinclair | Aug 2012 | A1 |
| 20140280645 | Shuman | Sep 2014 | A1 |
| 20160088461 | Jiang | Mar 2016 | A1 |
| 20160269566 | Gundamaraju et al. | Sep 2016 | A1 |
| 20160292687 | Kruglick | Oct 2016 | A1 |
| 20170345006 | Kohli | Nov 2017 | A1 |
| 20180020324 | Beauford | Jan 2018 | A1 |
| Number | Date | Country |
|---|---|---|
| 1 067 492 | Jan 2001 | EP |
| Entry |
|---|
| Non-Final Office Action for U.S. Appl. No. 15/376,631 (dated Jun. 16, 2017). |
| Final Office Action for U.S. Appl. No. 13/047,287 (dated Mar. 10, 2017). |
| Commonly-assigned, co-pending U.S. Appl. No. 15/408,155 for “Methods, Systems, and Computer Readable Media for Validating a Redirect Address in a Diameter Message,” (Unpublished, filed Jan. 17, 2017). |
| Commonly-assigned, co-pending U.S. Appl. No. 15/376,631 for “Methods, Systems, and Computer Readable Media for Validating Subscriber Location Information,” (Unpublished, filed Dec. 12, 2016). |
| Non-Final Office Action for U.S. Appl. No. 13/047,287 (dated Aug. 25, 2016). |
| Advisory Action Before the Filing of an Appeal Brief for U.S. Appl. No. 13/047,287 (dated Oct. 16, 2015). |
| Final Office Action for U.S. Appl. No. 13/047,287 (dated Jun. 4, 2015). |
| “Digitial cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Location Services (LCS); Evolved Packet Core (EPC) LCS Protocol (ELP) between the Gateway Mobile Location Centre (GMLC) and the Mobile Management Entity (MME); SLg interface (3GPP TS 29.172 version 9.6.0 Release 9),” ETSI TS 129 172, V9.6.0, pp. 1-27 (Apr. 2015). |
| Non-Final Office Action for U.S. Appl. No. 13/047,287 (dated Sep. 25, 2014). |
| Supplemental Notice of Allowance and Fee(s) Due for U.S. Appl. No. 12/823,559 (dated Aug. 23, 2013). |
| Notice of Allowance and Fee(s) Due for U.S. Appl. No. 12/823,559 (dated Aug. 1, 2013). |
| Email to U.S. Patent and Trademark Office dated Jun. 28, 2013. |
| Final Office Action for U.S. Appl. No. 12/823,559 (dated Apr. 11, 2013). |
| Final Office Action for U.S. Appl. No. 13/047,287 (dated Jan. 31, 2013). |
| Non-Final Office Action for U.S. Appl. No. 12/823,559 (dated Nov. 14, 2012). |
| Restriction and/or Election Requirement for U.S. Appl. No. 12/823,559 (dated Aug. 27, 2012). |
| Non-Final Office Action for U.S. Appl. No. 13/047,287 (dated Jun. 6, 2012). |
| “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; Diameter charging applications (Release 11),” 3GPP TS 32.299, V11.3.0, pp. 1-150 (Mar. 2012). |
| “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control (PCC) over Gx/Sd reference point (Release 11),” 3GPP TS 29.212, V11.3.0, pp. 1-171 (Dec. 2011). |
| Press Release, “SmartSynch SmartMeters Communicate Using the Larges and Most Available Wireless Networks in the World,” http://www.smartsynch.com/SmartSynch_gprs.htm (Downloaded from the Internet on Jul. 5, 2011). |
| “Solution: Itron CENTRON GPRS,” Data Sheet, http://www.smartsynch.com/SmartSynch_itron_centron.htm (Downloaded from the Internet on Jul. 5, 2011). |
| Myers, “SmartSynch Introduces Innovative ‘DCX’ Smart Grid Solution at DistribuTECH,” SmartSynch News, http://www.appmesh.com/news/020309.htm Feb. 3, 2009 (Downloaded from the Internet on Jul. 5, 2011). |
| “NES System Architecture,” Data Sheet, Copyright 2009 (Downloaded from the Internet on Jul. 5, 2011). |
| “Wireless M-Bus and ZigBee®-enabled GSM/GPRS/ EDG Gateway for Smart Metering Introduced,” Metering.com, http://www.metering.com/node/13550 Sep. 19, 2008 (Downloaded from the Internet on Jul. 5, 2011). |
| Press Release, “Echelon and T-Mobile Announce Alliance to Reduce the Cost of a Secure Smart Grid Network for Utilities,” Echelon Corp., http://www.3gamericas.org/index.cfm?fuseaction=pressreleasedisplay&pressreleaseid=2201, 3 pgs. (Apr. 23, 2009). |
| “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 8),” 3GPP TS 29.272, V8.1.1, pp. 1-57 (Jan. 2009). |
| Hakala et al., “Diameter Credit-Control Application,” RFC 4006, pp. 1-115 (Aug. 2005). |
| Non-Final Office Action for U.S. Appl. No. 15/408,155 (dated Jan. 9, 2018). |
| Final Office Action for U.S. Appl. No. 15/376,631 (dated Nov. 28, 2017). |
| Commonly-assigned, co-pending U.S. Appl. No. 15/666,300 for “Methods, Systems, and Computer Readable Media for Mobility Mangement Entity (MME) Authentication for Outbound Roaming Subscribers Using Diameter Edge Agent (DEA),” (Unpublished, filed Aug. 1, 2017). |
| “LTE International Roaming Whitepaper,” http://carrier.huawei.com/en/technical-topics/core-network/lte-roaming-whitepaper, pp. 1-16, (Downloaded May 12, 2017). |
| “Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Universal Georgraphical Area Description (GAD) (3GPP TS 23.032 V 14.0.0 Release 14),” ETSI TS 123 032 V14.0.0, pp. 1-30 (May 2017). |
| “Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Cx and Dx interfaces based on the Diameter protocol; Protocol details (3GPP TS 29.229 V 13.1.0 Release 13),” ETSI TS 129 229 V13.1.0, pp. 1-42 (Jan. 2017). |
| “Edge Roputer (DEA),” http://www.mavenir.com/our-products/mobile/edge-router-dea, pp. 1-7 (Copyright 2017). |
| “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Numbering, addressing and identification (3GPP TS 23.003 V 12.9.0 Release 12),” ETSI TS 1 23 003 V12.9.0, pp. 1-93 (Mar. 2016). |
| “Snyiverse Guide to LTE Roaming and Interoperability,” https://www.syniverse.com/assets/files/custom_content/lte-roaming-interoperability-guide.pdf, pp. 1-11 (Jan. 8, 2016). |
| “Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Location Services (LCS); LCS Application Protocol (LCS-AP) between the Mobile Management Entity (MME) and Evolved Serving Mobile Location Centre (E-SMLC); SLs interface (3GPP TS 29.171 V 11.4.0 Release 11),” ETSI TS 129 171 V11.4.0, pp. 1-52 (Jan. 2016). |
| “Diameter Signaling Control (DSC),” https://www.extent.com/diameter-signaling-control-dsc/, pp. 1-3 (Copyright 2016). |
| Kotte, “Analysis and Experimental Verification of Diameter Attacks in Long Term Evolution Networks,” http://www.diva-portal.org/smash/get/diva2:951619/FULLTEXT01.pdf, pp. 1-72 (2016). |
| “The Dialogic® Helix™ Signaling Controller,” https://www.dialogic.com/-/media/products/docs/brochures/14090-helix-br.pdf, pp. 1-5 (Aug. 2015). |
| “Digital cellular telecommunications system (Phase 2+); Universal Monile Telecommunications System (UMTS); LTE; Location Services (LCS); Service description; Stagel (3GPP TS 22.071 V 11.0.0 Release 11,” ETSI TS 122 071 V11.0.0, pp. 1-50 (Oct. 2012). |
| “Net-Net Diameter Director,” http://www.oracle.com/us/industries/communications/net-net-diameter-director-ds-1985034.pdf, pp. 1-9 (Copyright 2012). |
| “Digitall cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2 (3GPP TS 23.272 V 8.0.0 Release 8),” ETSI TS 123 272 V8.0.0, pp. 1-42 (Nov. 2008). |
| Examiner's Answer for U.S. Appl. No. 13/047,287 (dated Feb. 26, 2018). |
| Advisory Action Before the Filing of an Appeal Brief and AFCP 2.0 Decision for U.S. Appl. No. 15/376,631 (dated Feb. 2, 2018). |
| “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional stage 2 description of Location Services (LCS) (Release 14),” 3GPP TS 23.271 V14.1.0, pp. 1-181 (Mar. 2017). |
