WO2023126685A1

WO2023126685A1 - Systems and methods for centralized application-to-person (a2p) messaging

Info

Publication number: WO2023126685A1
Application number: PCT/IB2022/050023
Authority: WO
Inventors: Charbel Fawaz EL-LITANI
Original assignee: Inmobiles-Fzco
Priority date: 2022-01-03
Filing date: 2022-01-03
Publication date: 2023-07-06

Abstract

The present disclosure relates to systems and methods for centralized A2P messaging. According to one aspect, a method can include configuring, by a central system including one or more processors in communication with a plurality of local mobile network operators (MNOs), for each local MNO, a respective local firewall with rules configured to cause the respective local firewall to block international A2P messages that satisfy the rules configured by the central system. The method can include receiving, by a central short message service center (SMSC) of the central system, an international A2P message. The method can include forwarding, by the system, the international A2P message to a local MNO of the plurality of local MNOs to cause the local MNO to forward the message to a destination device responsive to the international A2P message satisfying the rules of a local firewall of the local MNO.

Description

SYSTEMS AND METHODS FOR CENTRALIZED APPLICATION-TO-PERSON (A2P) MESSAGING

BACKGROUND

[0001] A2P messaging is a communication technique in which the sender doesn’t expect a reply from the recipient. However, implementing A2P is difficult because of spam, spoofing, phishing, and/or regulations.

SUMMARY

[0002] As a platform overview, A2P messaging is a way of communication in which the sender doesn’t expect a reply from the recipient, which differs from regular person-to-person (P2P) messaging where both parties expect to send and receive messages. A2P messages can include marketing messages, verification codes, appointment reminders, or notifications. A2P Messaging can be utilized for emergency services, marketing, social networking, entertainment, or business administration.

[0003] A2P messages can include vulnerabilities. One vulnerability is spamming, which is an action where marketers send promotional messages to a list of numbers in an attempt to increase their sales without verifying that the number supplied to them by a customer is correct or without obtaining explicit consent from the recipients to receive the marketing messages. Another vulnerability is short message service (SMS) originator spoofing: when the sending party’s true identity is deliberately hidden in order to trick a consumer into thinking that a message is from someone familiar to them— by using the sender name of a trusted company to pretend to be the trusted company, for example. Another vulnerability is SMS Phishing (SMS Phishing), which combines the other vulnerabilities with social engineering to persuade a recipient to disclose their personal details. Another vulnerability is flooding, which is when a large number of messages that are either valid or invalid are sent to one or more destinations. Flooding can be defined when a huge number of messages are sent. Another vulnerability is grey routes, which is when scammers exploit the absence of commercial agreements, for example, AA.19 & AA.70 as a way to avoid paying regular fees for message termination when sending A2P messages. Another vulnerability is Mobile Application Part (MAP) global title (GT) faking, which is when an address used in the Signaling Connection Control Part (SCCP) protocol for routing messages is altered by fraudsters to avoid detection. Another vulnerability is SCCP GT faking, which is implemented by sending a message from a sender that doesn’t own the GT or has leased it from a third party and then faked the SCCP address. Another vulnerability is GT scanning, which is the action of sending an SMS MO to all GT address from one mobile operator to find unsecured short message service center (SMSC) (SMSC that are not controlling the A number). Another approach is to send mass number of SRI-SM to discover subscriber’s location and international mobile subscriber identity (IMSI). Another vulnerability is SMSC compromise fraud, which is relaying and sending SMS without paying for them such that the SMSC owner ends up having to pay the message termination charges. [0004] To address these and other vulnerabilities, the A2P platform will be accompanied by an SMS firewall to avoid any suspicious or revenue leakage actions by the SMS service provider. Each mobile operator can have its own SMS firewall to reduce the traffic load that goes unpaid on the network, block and filter out unwanted messages, and protect the end-user.

[0005] The present disclosure can include a central firewall installed at the regulator (or another authority) to detect all international A2P SMS terminating in the country (at a country level). The central firewall can be capable of blocking all illegal or grey SMS from getting delivered to subscribers. The central firewall can apply blocking rules to ensure that all leakages are blocked, and provide the regulator full control over this type of traffic.

[0006] In view of the foregoing, it should be appreciated that the systems and methods described herein can provide various technical improvements. In particular, one technical improvement provided by the centralized firewall system includes communication to a single operator that can be replicated to all operators in the country. The replication can be instant— for example, a sender ID (A2P SMS sender) that is identified as fraud by one operator can be automatically blocked by other ones. Another technical improvement provided by the centralized firewall system is that international A2P providers can connect to a single point (central system) instead of connecting to multiple operators. Another technical improvement provided by the centralized firewall system is that the regulator of the centralized firewall system can have visibility of the international A2P SMS traffic without the need to request it from the operator.

[0007] The present disclosure relates to systems and methods for managing centralized A2P messages. According to one aspect, a method can include configuring, by a central system including one or more processors in communication with a plurality of local mobile network operators (MNOs), for each local MNO, a respective local firewall with one or more rules configured to cause the respective local firewall to cause blocking of international A2P messages that satisfy the one or more rules configured by the central system. The method can include receiving, by a central SMSO of the central system, an international A2P message. The method can include forwarding, by the system, the international A2P message to a local MNO of the plurality of local MNOs to cause the local MNO to forward the message to a destination device responsive to the international A2P message satisfying the one or more rules of a local firewall of the local MNO.

[0008] In some implementations, the method can include providing, by the central system, a user interface via which the one or more rules can be received. The method can include storing, by the central system, the one or more rules received via the user interface. Configuring the respective local firewall of each local MNO includes configuring the respective local firewall with the stored one or more rules. [0009] In some implementations, the method can include determining, by the central system, for the international A2P message, a charge to be assessed for the international A2P message in accordance with one or more pricing tables. In some implementations, the method can include determining, by the central system, that an A2P provider from which the international A2P message was received has a sufficient balance or has paid for the international A2P message. The method can include determining, by the central system, responsive to determining that the A2P provider has a sufficient balance or has paid for the international A2P message, to forward the international A2P message to the local MNO.

[0010] In some implementations, the method can include maintaining, by the central system, in a central database, i) a first list comprising at least one of a first application identifier, a first network identifier, a first content type, or a first destination device identifier associated with A2P messages permanently allowed to be forwarded, and ii) a second list including at least of one of a second application identifier, a second network identifier, a second content type, or a second destination device identifier associated with A2P messages permanently blocked from being forwarded. The method can include transmitting, by the central system, via a connection maintained between the central system and each local database in communication with a respective local firewall of the plurality of local firewalls, one or more updates to at least one of the first list or the second list to synchronize the first list and the second list stored in each local database with the first list and the second list stored in the central database.

[0011] In some implementations, the method can include maintaining, by the central system, a central database including data corresponding to at least of one of an application identifier, a network identifier, or a destination device identifier. The method can include receiving, by the central system, additional data stored in a first local database in communication with a first local firewall of the plurality of local firewalls. The method can include storing the additional data in the central database. The method can include transmitting, by the system, for storage in a second local database in communication with a second local firewall of the plurality of local firewalls, the additional data to synchronize the data included in the central database, the first local database and the second local database.

[0012] In some implementations, forwarding the international A2P message includes forwarding, by the central SMSC, the international A2P message to a local SMSC of the local MNO to cause the corresponding local SMSC to forward the message to the destination device responsive to the international A2P message satisfying the one or more rules of the local firewall. In some implementations, forwarding the international A2P message includes forwarding, by the central SMSC, the international A2P message to a local firewall of the local MNO and responsive to the international A2P message satisfying the one or more rules of the local firewall, the local firewall configured to cause the corresponding local SMSC to forward the message to the destination device.

[0013] In some implementations, receiving the international A2P message includes receiving the international A2P message from an A2P provider via an application programming interface (API). In some implementations, the method can include detecting, by the central system, that at least one of the forwarded international A2P messages satisfies an alert policy. The method can include generating, by the central system, for each of the forwarded international A2P messages that satisfy the alert policy, an alert for display in the user interface.

[0014] The present disclosure further relates to a system including one or more processors in communication with a plurality of local MNOs. The one or more processors can be configured by machine- readable instructions. The one or more processors can configure, for each local MNO, a respective local firewall with one or more rules configured to cause the respective local firewall to cause blocking of international A2P messages that satisfy the one or more rules configured by the central system. The one or more processors can receive, from a central (SMSC), an international A2P message. The one or more processors can forward the international A2P message to a local MNO of the plurality of local MNOs to cause the local MNO to forward the message to a destination device responsive to the international A2P message satisfying the one or more rules of a local firewall of the local MNO.

[0015] In some implementations, the one or more processors can provide, a user interface via which the one or more rules can be received. The one or more processors can store, the one or more rules received via the user interface. Configuring the respective local firewall of each local MNO includes configuring the respective local firewall with the stored one or more rules.

[0016] In some implementations, the one or more processors are further configured to determine for the international A2P message, a charge to be assessed for the international A2P message in accordance with one or more pricing tables. In some implementations, the one or more processors are further configured to determine that an A2P provider from which the international A2P message was received has a sufficient balance or has paid for the international A2P message. The one or more processors can determine, responsive to determining that the A2P provider has a sufficient balance or has paid for the international A2P message, to forward the international A2P message to the local MNO.

[0017] In some implementations, the one or more processors are further configured to maintain in a central database, i) a first list comprising at least one of a first application identifier, a first network identifier, a first message text, or a first destination device identifier associated with A2P messages permanently allowed to be forwarded, and ii) a second list including at least of one of a second application identifier, a second network identifier, a second message text, or a second destination device identifier associated with A2P messages permanently blocked from being forwarded. The one or more processors can transmit, via a connection maintained between the central system and each local database in communication with a respective local firewall of the plurality of local firewalls, one or more updates to at least one of the first list or the second list to synchronize the first list and the second list stored in each local database with the first list and the second list stored in the central database.

[0018] In some implementations, wherein the one or more processors are further configured to maintain, a central database including data corresponding to at least of one of an application identifier, a network identifier, or a destination device identifier. The one or more processors can receive, additional data stored in a first local database in communication with a first local firewall of the plurality of local firewalls. The one or more processors can store the additional data in the central database. The one or more processors can transmit, for storage in a second local database in communication with a second local firewall of the plurality of local firewalls, the additional data to synchronize the data included in the central database, the first local database and the second local database.

[0019] In some implementations, wherein forwarding the international A2P message includes forwarding the international A2P message to a local SMSC of the local MNO to cause the corresponding local SMSC to forward the message to the destination device responsive to the international A2P message satisfying the one or more rules of the local firewall.

[0020] In some implementations, wherein forwarding the international A2P message includes forwarding the international A2P message to a local firewall of the local MNO and responsive to the international A2P message satisfying the one or more rules of the local firewall, the local firewall configured to cause the corresponding local SMSC to forward the message to the destination device.

[0021] In some implementations, the international A2P message is received from an A2P provider via an API.

[0022] In some implementations, wherein the one or more processors are further configured to detect that at least one of the forwarded international A2P messages satisfies an alert policy. The one or more processors can generate, for each of the forwarded international A2P messages that satisfy the alert policy, an alert for display in the user interface. BRIEF DESCRIPTIONS OF THE DRAWINGS

[0023] FIG. 1A displays an overview of the centralized firewall management system for forwarding A2P messages according to implementations of the present disclosure.

[0024] FIG. 1B displays an overview of the centralized firewall management system for blocking A2P messages according to implementations of the present disclosure.

[0025] FIG. 2 illustrates a hardware architecture of the centralized firewall management system according to implementations of the present disclosure.

[0026] FIG. 3 illustrates a network architecture of the centralized firewall management system according to implementations of the present disclosure.

[0027] FIG. 4 illustrates an architecture of MNOs communicatively coupled to the centralized firewall management system according to implementations of the present disclosure.

[0028] FIG. 5 illustrates a method for managing centralized A2P messages according to implementations of the present disclosure.

[0029] FIG. 6 illustrates an operational flow for validating messages corresponding to the method of FIG. 5.

[0030] FIG. 7 illustrates a simplified block diagram of a representative server system and client computer system usable to implement certain implementations of the present disclosure.

DETAILED DESCRIPTION

[0031] For purposes of reading the description of the various implementations of the present invention below, the following descriptions of the sections of the specification and their respective contents may be helpful:

Section A describes systems and methods for centralized A2P messaging;

Section B describes details of an architecture for implementing the systems and methods for centralized A2P messaging;

Section 0 describes a network environment and computing environment useful for practicing an embodiment of the present disclosure; A. Systems And Methods For Centralized A2P Messaging

[0032] Existing A2P messaging services enable message providers to contact many different users. In such services, message providers use an application of the message provider to transmit A2P messages to the user devices of the users without expecting to receive a response from the user devices. This implementation enables the message providers to send marketing messages, verification codes, appointment reminders, or notifications to many users.

[0033] There are a few problems that arise with such messaging services. First, the messaging service may end up spamming user devices by sending excessive amounts of messages to user devices without their explicit permission. For instance, the messaging service might be unaware of whether the user device opted out of marketing messages. Second, the messaging service might not be able to verify the message provider asking to send the A2P messages. For instance, the message provider might be unaware if the message provider is spoofing their identity to appear as a trusted company (e.g., bank) to trick the recipients into divulging their personal information. Since such messaging services are limited in their ability to manage which senders can send which messages to which recipients, they are prone to other problems such as sending excessively large numbers of messages (e.g., flooding), sending unregulated messages (e.g., grey routes), sending disguised messages to avoid detection (e.g., MAP GT faking), sending messages with faked addresses (e.g., SCOP GT faking), sending messages for malicious reasons (e.g., GT scanning or to identify IMSI), or sending messages without being paid by the sender (e.g., SMSO compromise fraud).

[0034] The present solution addresses the technical challenges faced by existing technological solutions by implementing a central A2P firewall management system that can configure a respective local firewall for each local MNO, receive an A2P message, and forward the A2P messages to the local MNO if the A2P messages satisfy rules of the local MNO. For example, a regulator can define the rules. Because the central A2P firewall management system can maintain and configure rules to cause the respective local firewall to cause blocking of international A2P messages that satisfy the rules associated with the message sender, message contents, and message recipient, the central A2P firewall management system can enable a regulator or authority that installs the central A2P firewall management system to reduce the traffic load that goes unpaid on the network, block and filter out unwanted messages, and protect the end-user.

[0035] For example, when a user device connected to a MNO attempts to register for a social networking service, the user device will transmit, via the MNO, a request to the servers of the social networking service for a one-time password (OTP). The social network service will use A2P providers to transmit the OTP to the MNO, which will then forward the OTP to the user device. Unlike generic messages among user devices, the central A2P firewall management system can bill or charge the social networking service for transmitting the OTP to the user device. Moreover, if the social networking service and the MNO are located in different countries, then the central A2P firewall management system can intercept the messages before they are sent to the MNO. The central A2P firewall management system can monitor and regulate the flow of A2P messages among the A2P providers and the destination devices to verify that the destination devices should receive the A2P message and to charge A2P providers for sending the A2P messages.

[0036] According to one aspect, the present disclosure is directed to methods and systems for managing centralized A2P messages. The system can include one or more processors configured by machine- readable instructions. The one or more processors can configure, for each local MNO, a respective local firewall with one or more rules configured to cause the respective local firewall to cause blocking of international A2P messages that satisfy the one or more rules configured by the central system. The one or more processors can receive, from a central SMSO, an international A2P message. The one or more processors can forward the international A2P message to a local MNO of the plurality of local MNOs to cause the local MNO to forward the message to a destination device responsive to the international A2P message satisfying the one or more rules of a local firewall of the local MNO.

[0037] Referring now to FIG. 1A, FIG. 1A illustrates an environment 100 for managing A2P messages. The environment 100 can be configured to include various subsystems or components. The environment 100 can include A2P providers 102, a central system 104, and a MNO 106. The central system 104 can include a SMSO 108, a central firewall 110, a central database 112, and a usage manager 114. The MNO 106 can be a provider of communications services. The MNO 106 can include a local firewall 116, a local SMSO 118, and a local database 120. The central SMSO 108 can receive messages from A2P providers 102. The central firewall 110 can accept or block A2P messages, and can configure the local firewalls 116 to accept or block A2P messages. The central database 112 can maintain configurations for accepting or blocking messages. The usage manager 114 can monitor the requests from A2P providers 102 to send A2P messages. The local firewall 116 can accept or block A2P messages. The local SMSO 118 can forward A2P messages to recipients. The local database 120 can maintain configurations (e.g., rules and SMS data) for accepting or blocking messages. In some implementations, the MNO 106 can receive updates to its respective local firewall 116 or local database 120 via an offline synchronization process, for instance, by using a flash or hard drive update process. The local firewall 116 and the local database 120 can be communicatively coupled to the central firewall 110 and the central database 112. In some implementations, the local firewall 116 and the local database 120 receives data from the central firewall 110 and the central database 112 via a network connection in real time. In some implementations, the local database 120 can store the retrieved data. In certain implementations, the local database 120 updates the stored data at predetermined intervals with data from the central database 112.

Additional details relating to each of the components described above are provided below.

[0038] The A2P providers 102 can be a telecommunications service that can request to transmit A2P messages to recipients via the central system 104. The A2P provides can be content providers, advertising servers, security verification services, or any other entities that provide A2P messages to destination devices. The A2P providers 102 can connect to the central system 104. For example, the A2P providers can connect via SMPP interfaces. In another example, the A2P providers 102 can be connected to the floating IP of the LBs of the central SMSC 108.

[0039] The destination devices can be any device capable of receiving A2P messages. The destination devices can be user devices of MNO subscribers. The destination devices can be devices that can be configured to receive cellular data via a cellular data connection, such as a smartphone. The destination devices can be devices that are not capable of receiving cellular data or data via a Wi-Fi connection, such as a feature phone or dumbphone. The destination devices can include a device identifier assigned by the MNO 106. The device identifier can be a MSISDN or a phone number.

[0040] The central system 104 can be a central data center of an A2P message regulator. For example, the central system 104 can be an A2P SMS hub for all the operators. However, the central system 104 can be a geographically redundant platform that can be installed in more than one data center to enable full availability without a single point of failure. In addition, any configuration in the functionality of the system can be performed without A2P service interruption. The central system 104 can be in communication with the A2P providers 102 and the MNO 106. The central system 104 can manage the allowing and blocking of A2P messages sent by the A2P providers to the destination devices of the MNO 106. For example, the central system 104 can receive international A2P terminated messages from the A2P providers and send the A2P messages to each MNO 106 based on the destination MSISDN of each A2P message. The central system 104 can be any script, file, program, application, and set of instructions, or computer-executable code that is configured to perform the functionality described herein. The central system 104 can also include one or more processors configured to execute the script, file, program, application, and set of instructions, or computerexecutable code that is configured to perform the functionality described herein.

[0041] The central system 104 can manage or provide interfaces via which an administrator can configure rules. In some implementations, the central system 104 can provide, a management or client interface via which the one or more rules can be received. In some implementations, the central system 104 can store, the one or more rules received via the user interface. The central system 104 can store the one or more rules in the central database 112.

[0042] The central SMSC 108 of the central system 104 can handle the flow of A2P Messages from the A2P providers 102 to the MNOs 106. The central SMSC 108 of the central system 104 can receive the A2P messages from the A2P providers 102 and forward the A2P messages to the MNOs 106. The central SMSC 108 of the central system 104 can be a SMSC or any other network server. The central SMSC 108 can include an SMS load balancer (LB) or SMSC application to manage the forwarding of the A2P messages. The LB can ensure adequate distribution of A2P messages over the various components of the central system 104 and ensure redundancy in the central system 104.

[0043] In some implementations, the central SMSC 108 can receive A2P messages. The central SMSC 108 can receive the A2P messages from the A2P providers 102. The A2P message can be an international message. For example, the central SMSC 108 can collect or receive terminated international A2P messages from international carriers. The A2P message can include message traffic in which a person is receiving messages from an application rather than another individual. The A2P message can be a one-way message because the recipient is not expected to directly reply. Examples of the A2P messages include marketing communications, appointment reminders, chat bots, notifications, and OTP, or PIN codes. The A2P messages can include graphical object, button, or icon presented on a display screen of the recipients. In some implementations, the graphical object, button, or icon can be displayed within a mobile application executing on the devices of the recipients.

[0044] The central SMSC 108 can forward the A2P messages to the central firewall 110. Responsive to the A2P messages satisfying the rules of the central firewall 110, the central SMSC 108 can forward the A2P message to the local firewall 116 or the local SMSC 118 of the MNO 106. In some implementations, the central SMSC 108 can forward the international A2P message to a local MNO 106 to cause the local SMSC 118 of the local MNO 106 to forward the message to a destination device responsive to the international A2P message satisfying the one or more rules of a local firewall 116 of the local MNO 106. The central SMSC 108 can transmit or forward the A2P messages via a SMPP protocol, Signaling System No. 7 (SS7) protocol, USSD push, smart push, or push SMS.

[0045] The central firewall 110 can determine whether the central SMSC 108 can transmit the A2P messages to the MNO 106. The central firewall 110 can monitor, intercept, and filter incoming and outgoing A2P messages to determine whether to allow or block the A2P messages. For example, the central firewall 110 can filter the received A2P messages. The central firewall 110 can forward the filtered messages to the MNOs 106. For example, the central firewall 110 can forward the A2P messages based on number planning. In another example, the central firewall 110 can block unauthorized, unpaid, spammed, fraudulent, and unwanted traffic. In another example, the central firewall 110 can block the A2P messages to prevent the A2P message from being sent.

[0046] The central firewall 110 can include direct integration with the MNO 106 to allow or block the A2P messages (e.g., A2P SMS traffic) from being forwarded to the MNO 106 or to configure the local firewall 116 of the MNO 106. In some implementations, the central firewall 110 can allow the international A2P message to be forwarded from the central SMSC 108 to the local SMSC 118 of the local MNO 106. In some implementations, the central firewall 110 can allow the international A2P message to be forwarded from the central SMSC 108 to the local firewall 116 of the local MNO 106. Conversely, the central firewall 110 can block the international A2P message from being forwarded from the central SMSC 108 to the local firewall 116 or the local SMSC 118 of the local MNO 106.

[0047] The central firewall 110 of the central system 104 can manage or maintain lists for determining whether the A2P messages are allowed or blocked. The central firewall 110 can create or generate custom filtration rules to whitelist or blacklist messages based on the sender identifier, GT addresses, or A2P message content. The whitelist of identifiers associated with A2P messages can be permanently allowed to be forwarded. The whitelist can include sender identifiers, network identifiers, destination device identifiers, or message content associated with A2P messages permanently allowed to be forwarded. For example, the central firewall 110 can maintain a whitelist with sender identifiers related to a specific network identifier. The blacklist of identifiers associated with A2P messages can be permanently blocked from being forwarded. The blacklist can include sender identifiers, network identifiers, destination device identifiers, or message content associated with A2P messages permanently blocked from being forwarded. For example, the central firewall 110 can block messages by providing either a specific GT or by blocking a range of GTs. The central firewall 110 can block sender identifiers based on a specific sender identifier. The central firewall 110 can store the lists in the central database 112.

[0048] The central firewall 110 of the central system 104 can manage or maintain rules for determining whether the A2P messages are allowed or blocked. The central firewall 110 can define or configure blocking rules, artificial intelligence generated rules, or international A2P message validation rules. The central firewall 110 can define the rules based on geography (e.g., country level) or for each MNO 106 (e.g., operator). For example, the central firewall 110 can configure or define rules to block A2P messages from certain countries. The central firewall 110 can filter different SMS traffic types from A2P to P2P as well as from local and international networks. The central firewall 110 can filter MAP originating address to identify the sender based on type of number “TON” “ex: numeric or alphanumeric sender”. In yet another example, the central firewall 110 can receive (e. g. , from a user via the management interfaces) SMSO global titles (GTs) to be excluded from analysis and filtering by the central system. The central system can identify A2P messages that have the SMSO GTs to be excluded. The central system can exclude the A2P messages from analysis. For example, the exclusion can specify “local SMSCs”. The central system would exclude A2P messages associated with local SMSCs from being analyzed. By excluding the A2P messages from analysis and filtering, the A2P messages can proceed to be sent to their destinations. For example, the A2P messages associated with the local SMSCs can be sent to their destination.

[0049] The central firewall 110 can configure the local firewalls 116 to block or forward the A2P messages. The central firewall 110 can configure the local firewalls 116 with the rules or lists. In some implementations, the central firewall 110 can configure, for each local MNO 106, a respective local firewall 116 with rules configured to cause the respective local firewall 116 to cause blocking of A2P messages that satisfy the rules configured by the central firewall 110. In some implementations, the central firewall 110 can configure the respective local firewall 116 of each local MNO 106 with the stored rules (e.g., rules stored in the database 112). For example, the central firewall 110 can configure the local firewalls 116 with a rule to block A2P messages that were not received from the central system 104. The central firewall 110 can configure the local firewalls 116 with the lists (e.g., whitelist or blacklist). For example, the central firewall 110 can configure the local firewalls 116 to block international A2P messages by providing a blacklist with network identifiers of international A2P providers 102.

[0050] The central firewall 110 can determine whether to forward or block the A2P messages by applying the rules and the lists to the sender identifiers of the A2P providers that are attempting to send the A2P messages to the destination devices. For example, the central firewall 110 can identify the sender address parameter (e.g., source_subaddress) to identify the sender operator or A2P providers that are associated with the MSISDN sending the A2P message. For example, if the sender identifier matches a network identifier on the whitelist, then the central firewall 110 can determine to allow the A2P message. In another example, if the sender identifier matches a network identifier on the blacklist, then the central firewall 110 can determine to block the A2P message. In yet another example, if the sender identifier is unavailable, then the central firewall 110 can allow or block the A2P messages and analyze another identifier or content of the A2P messages.

[0051] Based on the sender identifiers, the central firewall 110 can detect spoofing of A2P messages and block those A2P messages. For example, the central firewall 110 can detect spoofing when MO A2P messages arrive from a foreign MSG. The central firewall 110 can query the HLR about the subscriber location and compare the VLR ID registered in the HLR with the calling MSG. If the VLR ID and the calling MSG are not identical, the central firewall 110 can identify the MO SMS as a spoofing case and block the A2P message. The central firewall 110 can block A2P messages from A2P providers that simulate home SMSO GTs or home subscribers.

[0052] Based on the sender identifiers, the central firewall 110 can detect MT messages and allow those A2P messages. The central firewall 110 can correlate each MT-FSM with a SRI-request. The central firewall 110 can detect and block MT traffic from certain A2P providers 102 (e.g., international senders) without any correlation with the SRI-SM request. For example, the central firewall 110 can utilize a default online rule to handle A2P messages for which the message is received but no SRI request was sent. In another example, the central firewall 110 can apply default online rules that can be predefined system built-in rules applied to each A2P message passing through the central firewall 110. The central firewall 110 can block those A2P messages and mark them as spam.

[0053] Based on the sender identifiers, the central firewall 110 can track how many A2P messages a sender is attempting to send, and allow or block the A2P messages based on the number of A2P messages. Based on the number of A2P messages, the central firewall 110 can detect an abnormal spike traffic for a certain time duration in reference to the traffic of previous times. For example, the central firewall 110 can identify that an A2P provider 102 is sending more messages than a predetermined threshold, which can indicate that the A2P provider 102 is sending spam (e.g., was hacked). The central firewall 110 can block A2P messages from A2P providers 102 suspected of sending spam.

[0054] The central firewall 110 can parse or analyze the A2P messages to identify the network to which they are being sent. The central firewall 110 can identify the network identifier of the MNO 106 to which the A2P messages are addressed. The central firewall 110 can use the network identifier to differentiate between the types of traffic. The central firewall 110 can identify or extract network identifiers from the A2P messages. The central firewall 110 can identify network identifiers such as MSISDN, SCOP calling and called GTs, MAP SM- OA or SM-DA, or calling number address (e.g., MSISDN). The central firewall 110 can utilize the network address parameter (e.g., dest_subaddress) to identify the MNO 106 that is associated with the MSISDN of the A2P message. For example, to identify the MNO 106, the central firewall 110 can identify a 7-digit MCC+MNC value that represents the MNO 106.

[0055] To analyze and then allow or block the A2P messages, the central firewall 110 does not need to change the network identifier of the A2P message. For example, address length increase due to MAP or SCOP address manipulation can cause TCAP segmentation. The central firewall 110 can maintain message transparency. Transparency can be consistent and standard among the MNOs 106 and SMS hubs. The SCOP and MAP addresses can remain consistent. For example, the SCOP and the MAP can belong to the same MNO 106 and can be seen by entities readily as belonging to the same entity. In some long-term installations, transparency is a mandatory requirement of the MNO 106 or the regulator of the central system 104. For example, the receiving MNO 106 can identify the A2P provider 102 regardless of how many hubs (e.g., central system 104) or MNOs 106 the A2P message may have transited through.

[0056] Based on the network identifiers, the central firewall 110 can determine whether to allow or block the A2P messages. For example, the central firewall 110 can use the network identifier for fraud detection and management procedures. The central firewall 110 can determine whether to forward or block the A2P messages by using the rules and the lists to analyze the network identifiers of the MNO 106 via which the A2P messages are to be sent.

[0057] The central firewall 110 can determine whether the network identifier is on the blacklist or the whitelist. For example, if the network identifier matches a network identifier on the whitelist, then the central firewall 110 can determine to allow the A2P message. In another example, if the network identifier matches a network identifier on the blacklist, then the central firewall 110 can determine to block the A2P message. In yet another example, if the network identifier is unavailable, then the central firewall 110 can allow or block the A2P messages and analyze another identifier or content of the A2P messages.

[0058] Based on the network identifiers, the central firewall 110 can track how many A2P messages are being sent to particular MNOs 106, and allow or block the A2P messages based on the number of A2P messages. Based on the number of A2P messages, the central firewall 110 can detect an abnormal spike traffic for a certain time duration in reference to the traffic of previous times. For example, the central firewall 110 can identify that more A2P messages are being sent to a MNO 106 than a predetermined threshold, which can indicate that the MNO 106 is being spammed (e.g., denial of service attack against an MNO 106). The central firewall 110 can block A2P messages suspected of sending spam to MNOs 106.

[0059] The central firewall 110 can parse or analyze the A2P messages to identify the destination device to which they are being sent. For example, the central firewall 110 can identify or extract destination identifiers from the A2P messages such as a calling number address (e.g., MSISDN). To analyze and then allow or block the A2P messages, the central firewall 110 does not need to change the destination device identifier or calling number of the A2P message.

[0060] Based on the destination identifiers (e.g., MNO or MNO MSG), the central firewall 110 can determine whether to allow or block the A2P messages. For example, the central firewall 110 can use the destination identifier for fraud detection and management procedures. The central firewall 110 can determine whether to forward or block the A2P messages by using the rules and the lists to analyze the destination identifiers of the MNO 106 via which the A2P messages are to be sent to the destination devices.

[0061] Based on the destination identifiers, the central firewall 110 can determine whether the destination identifier is on the blacklist or the whitelist. For example, if the destination identifier matches a destination identifier on the whitelist, then the central firewall 110 can determine to allow the A2P message. In another example, if the destination identifier matches a destination identifier on the blacklist, then the central firewall 110 can determine to block the A2P message. In yet another example, if the destination identifier is unavailable, then the central firewall 110 can allow or block the A2P messages and analyze another identifier or content of the A2P messages.

[0062] Based on the destination identifiers, the central firewall 110 can track how many A2P messages are being sent to particular MNOs 106 or destination devices, and allow or block the A2P messages based on the number of A2P messages. Based on the number of A2P messages, the central firewall 110 can detect an abnormal spike traffic for a certain time duration in reference to the traffic of previous times. For example, the central firewall 110 can identify that more A2P messages are being sent to a destination than a predetermined threshold, which can indicate that the destination is being spammed (e.g., denial of service attack). The central firewall 110 can block A2P messages suspected of sending spam to destinations.

[0063] The central firewall 110 can determine whether to forward or block the A2P messages by applying the rules and the lists to the message content of the A2P messages. The central firewall 110 can block A2P messages that include certain message content (e.g., message includes an inappropriate word or sentence). For example, the central firewall 110 can identify or extract the message content in the A2P message. The central firewall 110 can compare the message content to predetermined message content defined by the rules or lists. For example, if the message content matches restricted message content, then the central firewall 110 can determine to block the A2P message.

[0064] The central firewall 110 can analyze identifiers in combination with other identifiers to determine whether the A2P messages should be allowed or blocked. For example, if the network identifier is whitelisted, then the central firewall 110 does not apply the rules while allowing the A2P message to be forwarded. Conversely, if the network identifier is not whitelisted, then the central firewall 110 can determine whether the combination of the network identifier and the sender identifier is whitelisted. For example, central firewall 110 can determine that only a particular A2P provider 102 having a sender identifier is allowed to send A2P messages. In this case, the central firewall 110 can allow the message to be forwarded to the MNO 106. [0065] If the central firewall 110 fails to identify the combination of the network identifier and the sender identifier in the whitelist, then the central firewall 110 can determine whether a combination of the sender identifier and the message content is available. For example, the identifier or the content is unavailable if the central firewall 110 cannot extract or identify the identifier or content from the A2P message. Conversely, the identifier or the content is available if the central firewall 110 can extract or identify the identifier or content from the A2P message. If the central firewall 110 identifies a preconfigured rule for blocking this combination, then the central firewall 110 can block the message. Otherwise the central firewall 110 can allow the A2P message to be forwarded to the MNO 106. If the central firewall 110 fails to identify the combination of the sender identifier and the message content, the central firewall 110 can determine separately whether the sender identifier, the network identifier, or the message content is blacklisted. If the combination is blacklisted, the central firewall 110 can block the message. Otherwise, the central firewall 110 can forward the A2P message to the MNO 106.

[0066] The central firewall 110 can determine whether the network identifier of the A2P messages is included in the whitelist of network identifiers. The central firewall 110 can query or lookup the network identifier in the whitelist. If the network identifier is included in the whitelist, then the central firewall 110 can forward the A2P message to the local MNO 106. For example, central firewall 110 can identify the network identifier in the whitelist. The central firewall of the central system can allow the A2P messages to be forwarded. For example, the network identifier can be associated with an MNO that is allowed to receive all A2P messages.

[0067] If the network identifier is not included in the whitelist, then the central firewall 110 can determine whether the combination of the network identifier and the sender identifier is whitelisted. For example, the central firewall 110 can fail to find the network identifier in the whitelist. However, A2P messages might still be allowed to be forwarded to the MNO 106 having the network identifier if the A2P messages are from a particular A2P provider 102 (e.g. , trusted entity such as a school or weather service) having the sender identifier. The central firewall 110 can extract or identify the sender identifier from the A2P messages. The central firewall 110 can query or lookup the sender identifier and the network identifier in the whitelist.

[0068] If the combination of the network identifier and the sender identifier is included in the whitelist, then the central firewall 110 can forward the message to the local MNO 106. For example, the central firewall 110 can identify that the combination of the sender identifier and the network identifier are in the whitelist. The central firewall of the central firewall 110 can allow the A2P messages to be forwarded. For example, the central firewall 110 can allow A2P messages that are sent from a particular A2P provider 102 having the sender identifier to a particular MNO 106 having the network identifier. [0069] If the combination of the sender identifier and the network identifier are not in the whitelist, then the central firewall 110 can determine whether a combination of the message content and the sender identifier is available. For example, the central firewall 110 can fail to find the network identifier and the sender identifier in the whitelist. However, A2P messages might still be allowed to be forwarded to the MNO 106 having the network identifier if the A2P messages include particular message content (e.g., an emergency alert). The central firewall 110 can extract or identify the message content from the A2P messages. The central firewall 110 can query or lookup the message content and the sender identifier in the central database.

[0070] If the combination of the message content and the sender identifier is available, then the central firewall 110 can determine whether a corresponding rule is satisfied. The central firewall 110 can query the message content and the sender identifier against predetermined rules. For example, a rule can allow A2P messages if the message content includes an emergency alert and the A2P message is addressed to an MNO 106 that can receive emergency alerts. If the rule is not satisfied, then the central firewall 110 can block the message. For example, if the message content of the A2P messages does not include emergency alerts, then the A2P message would not satisfy the rule. The central firewall 110 can block A2P messages that fail to satisfy the rule from being forwarded to the MNO 106. If the rule is satisfied, then the central firewall 110 can allow the A2P messages to be forwarded to the local MNO 106. For example, A2P messages that include the emergency alert addressed to the MNO 106 would satisfy the rule. The central firewall 110 can allow A2P messages that satisfy the rule to be forwarded to the MNO 106.

[0071] If the combination of the message content and the sender identifier is unavailable, then the central firewall 110 can determine whether the sender identifier is available and blacklisted. For example, the central firewall 110 can fail to identify the message content and the sender identifier in the whitelist. However, either the sender identifier or the message content might be available. For example, the central firewall 110 might be able to extract or identify the sender identifier but not the message content. The central firewall 110 can determine whether the sender identifier is available. For example, the central firewall 110 can identify whether the sender identifier can be extracted from the A2P messages. The central firewall 110 can extract the sender identifier and lookup the sender identifier in the blacklist maintained by the central database. If the sender identifier is available and blacklisted, then the central firewall 110 can block the A2P message. For example, the central firewall 110 can match the sender identifier (e.g., A2P provider 102 sending the A2P messages) to a sender identifier in the blacklist (e.g., A2P provider 102 blocked from sending the A2P messages). The central firewall 110 can block the A2P messages to prevent them from being forwarded to the MNO 106. For example, the central firewall 110 can block A2P messages from certain A2P providers 102 by blocking A2P messages having sender identifiers of those A2P providers 102. [0072] If the sender identifier is unavailable, then the central firewall 110 can determine whether the message content is available and blacklisted. For example, the central firewall 110 can fail to identify the sender identifier from the A2P message. However, the message content might be available even if the sender identifier is unavailable. For example, the central firewall 110 might be able to extract or identify the message content but not the sender identifier. The central firewall 110 can query or lookup the message content in the blacklist maintained by the database of the central firewall 110. For example, the central firewall 110 can query or lookup words or objects included in the A2P message. If the message content is available and blacklisted, then the central firewall 110 can block the message. For example, the central firewall 110 can match the message content (e.g., inappropriate words or fraudulent links) to message content (e.g., known inappropriate words or known fraudulent links) in the blacklist. The central firewall 110 can block the A2P messages to prevent them from being forwarded to the MNO 106. For example, the central firewall 110 can block A2P messages having inappropriate words or fraudulent links by blocking A2P messages having such message content.

[0073] If the message content is unavailable, then the central firewall 110 can determine whether the network identifier is available. For example, the central firewall 110 can fail to identify the message content in the A2P message. However, the network identifier might be available even if the message content is unavailable. For example, the central firewall 110 might be able to extract or identify the network identifier but not the message content. The central firewall 110 can query or lookup the network identifier in the blacklist maintained by the database of the central firewall 110. For example, the central firewall 110 can query or lookup the network identifier to which the A2P message is addressed. If the network identifier is available and blacklisted, then the central firewall 110 can block the message. For example, the central firewall 110 can match the network identifier (e.g., MNO 106 to which the A2P messages are addressed) to a network identifier in the blacklist (e.g., MNO 106 to which A2P messages are blocked). The central firewall 110 can block the A2P messages to prevent them from being forwarded to the MNO 106. For example, the central firewall 110 can block A2P messages from being sent to certain MNOs 106 by blocking A2P messages having the network identifiers of such MNOs 106.

[0074] If the network identifier is not blacklisted, then the central firewall 110 can forward the message to the local MNO 106. For example, the central firewall 110 can fail to find the network identifier in the blacklist. However, A2P messages might still be allowed to be forwarded. The central firewall 110 can be setup to allow A2P messages with sender identifiers, message content, or network identifiers that are neither on the whitelist nor the blacklist to be forwarded. For example, the network identifier might be associated with a new MNO 106 that cannot be identified or has not yet been added to the whitelist or the blacklist. In another example, the message content might be unknown or has not yet been analyzed and added to the whitelist or the blacklist. In yet another example, the sender identifier might be associated with a new A2P provider that cannot be identified or has not yet been added to the whitelist or the blacklist. It is contemplated that the central firewall of the central firewall 110 can be setup to block A2P messages with identifiers that are neither on the blacklist or the whitelist. For example, the central firewall 110 can be setup to block unclassified A2P messages.

[0075] The central firewall 110 can allow the central SMSC 108 to forward the A2P messages to the local firewall 116 or the local SMSC 118 of the MNO 106. In some implementations, the central firewall 110 can allow the international A2P message to be forwarded to the local SMSC 118 to cause the local SMSC 118 to forward the message to the destination device. In some implementations, the local SMSC 118 can forward the message responsive to the international A2P message satisfying the rules of the local firewall 116. In some implementations, the central firewall 110 can forward the international A2P message from the central SMSC 108 to the local firewall 116. The local firewall 116 can use its local rules to determine whether to forward or block the A2P message. In some implementations, responsive to the international A2P message satisfying the rules of the local firewall 116, the local firewall 116 can cause the local SMSC 118 to forward the message to the destination device.

[0076] The central firewall 110 can ensure traffic security and avoid revenue leakage. For example, the central firewall 110 can verify that A2P providers 102 pay for the A2P messages and that the A2P messages are addressed to destination devices that can receive the A2P messages from the A2P providers 102. In another example, when a destination device subscribed to the MNO 106 attempts to register for a social networking service, the user device will transmit, via the MNO 106, a request to the servers of the social networking service for an OTP. The social network service can be the A2P provider 102 that transmits the OTP (example of an A2P message) to the MNO 106, which will then forward the OTP to the destination device. Unlike generic messaging among destination devices, the MNO 106 needs to bill or charge the social networking service (example of the A2P providers 102) for transmitting the OTP to the destination device. Prior to forwarding the A2P messages of the A2P providers 102, the central firewall 110 can verify that the A2P providers 102 paid for the A2P messages.

[0077] The central firewall 110 can provide home routing. For example, the central firewall 110 can protect local subscribers and outbound roamers. While MNOs 106 typically control messages sent from their own network, incoming MT text messages from other MNOs 106 or networks can be delivered directly to roaming subscribers in the visited PLMN. The central firewall 110 can use the home routing functionality to provide MNOs 106 with a point of control for incoming messages for maximum threat protection. The central firewall 110 can change the flow of MT messages by controlling the MT messages rather than directly sending them to the destination device or subscriber. [0078] The central database 112 can be the repository of the lists and rules. For example, the central database 112 can store or maintain international A2P Identifiers (sender identifiers, network identifiers, destination identifiers, permitted # of messages, allowed or blocked content), defined rules, or automatic generated rules. The central database 112 of the central system 104 can store or maintain the rules for the central firewall 110 to determine whether to forward or block the A2P messages. The central database 112 can maintain or manage identifiers used by the rules to determine whether to forward or block the A2P messages. In some implementations, the central firewall 110 can maintain in the central database 112, a list comprising at least one of a first application identifier, a first network identifier, a first message text, or a first destination device identifier associated with A2P messages permanently allowed to be forwarded. For example, the central database 112 can maintain a list (e.g., whitelist) of identifiers associated with A2P messages that can be permanently allowed to be forwarded. In some implementations, the central firewall 110 can maintain, in the central database 112, a list including at least of one of a second application identifier, a second network identifier, a second message text, or a second destination device identifier associated with A2P messages permanently blocked from being forwarded. For example, the central database 112 can maintain a list (e.g., blacklist) of identifiers associated with A2P messages that can be permanently blocked from being forwarded.

[0079] The central database 112 can maintain or store identifiers associated with the A2P messages. In some implementations, the central database 112 can maintain or update data corresponding to at least of one of an application identifier, a network identifier, or a destination device identifier. For example, the central firewall 110 can add, update, or remove identifiers to the whitelist or the blacklist. In some implementations, the central firewall 110 can receive, additional data stored in a local database 120 in communication with a local firewall 116. For example, the central firewall 110 can receive updated destination device identifiers or rules defining which destination devices can receive A2P messages. In some implementations, the central firewall 110 can store the additional data in the central database 112. For example, the central firewall 110 can save or overwrite existing information. In some implementations, the central firewall 110 can transmit, for storage in a local database 120 in communication with the local firewall 116, the additional data to synchronize the data included in the central database 112. For example, the central firewall 110 can provide the updated identifiers or rules to the local database 120. In some implementations, the central firewall 110 can receive the additional data from a first local database and transmit the additional data to the second local database to synchronize the first and second local databases. For example, the central firewall 110 can receive identifiers or rules from one MNO 106 and provide those identifiers and rules to the other MNO 106.

[0080] The central firewall 110 can synchronize the central database 112 with each local database 120 to share information among the MNOs 106. For example, the central firewall 110 can share the data stored on the central database 112 with the local database 120. The central firewall 110 can synchronize data with any data source or database of any service or application. For example, the central firewall 110 can be integrated with the MNO 106 and the NTP servers of the central system 104 for real-time synchronization. The central firewall 110 can transmit the lists stored by the central database 112 to the local databases 120. The central firewall 110 can update the lists stored by the local database 120. In some implementations, the central firewall 110 can transmit one or more updates to at least one of the first list or the second list to synchronize the first list and the second list stored in each local database 120 with the first list and the second list stored in the central database. In some implementations, the central firewall 110 can transmit the one or more updates via a connection maintained between the central system 104 and each local database 120 in communication with a respective local firewall of the plurality of local firewalls.

[0081] The usage manager 114 can be a centralized billing and charging component. For example, when a destination device subscribed to the MNO 106 attempts to register for a social networking service, the user device will transmit, via the MNO 106, a request to the servers of the social networking service for an OTP. The social network service can be the A2P provider 102 that transmits the OTP (example of an A2P message) to the MNO 106, which will then forward the OTP to the destination device. The usage manager 114 can bill or charge the social networking service for transmitting the OTP to the destination device.

[0082] The usage manager 114 can control the charging and billing of A2P messages (such as those terminating in a particular country). The usage manager 114 of the central system 104 can identify or monitor the forwarding of A2P messages from the A2P providers 102 to the MNOs 106. For example, the central firewall 110 can provide reporting and alerting of A2P messages to the usage manager 114. In some implementations, the usage manager 114 can maintain a listing of each forwarded international A2P message. In some implementations, the usage manager 114 can provide a user interface via which each forwarded international A2P message can be displayed. The usage manager 114 can set pricing tables and rules for the international A2P providers 102 and for the MNOs 106. In some implementations, the usage manager 114 can determine for the international A2P message, a charge to be assessed for the international A2P message in accordance with one or more pricing tables. In some implementations, the usage manager 114 can determine that an A2P provider 102 from which the international A2P message was received has a sufficient balance or has paid for the international A2P message. In some implementations, the central firewall 110 can determine, responsive to the usage manager 114 determining that the A2P provider has a sufficient balance or has paid for the international A2P message, to forward the international A2P message to the local MNO 106.

[0083] The usage manager 114 can include alarms integration with network monitoring applications. The usage manager 114 can implements internal alarming tools to generate or provide an alert in case of potential threats. In some implementations, the usage manager 114 can detect that at least one of the forwarded international A2P messages satisfies an alert policy. In some implementations, the usage manager 114 can generate, for each of the forwarded international A2P messages that satisfy the alert policy, an alert for display in the user interface. Some examples for events that can cause alarms are when an A2P provider 102 that is local (e.g., local bank) sends international A2P messages, if there is a traffic outage for more than a predetermined amount of time (e.g., one minute), or if there is a disconnection among any of the components described herein (e.g., disconnection between the local firewall 116 and the central firewall 110).

[0084] The usage manager 114 can perform SMS trend analysis through Al and machine learning platforms. The usage manager 114 can analyze data. Based on the analysis, the usage manager 114 can identify clients (e.g., MNO 106 or A2P providers 102) that are experiencing a behavior that is different from average behavior. An example of a behavioral difference can be lost or leaked revenue, or some suspicious activity being performed. The analysis can rely on data from all operators to create a more robust central platform that can generate or provide relevant alerts and notifications.

[0085] The local firewall 116 of the MNO 106 can determine whether to forward or block A2P messages. The local firewall 116 can analyze A2P messages received from the central SMSO 108 or messages that did not pass through the central firewall 110. The local firewall 116 can block A2P messages that do not pass through or were not received from the central firewall 110. The local firewall 116 can be similar to a SMS firewall or can incorporate the functionality of the central firewall 110. The local firewall 116 can control the forwarding or delivery of various types of messages (e.g., A2P SMS) to ensure traffic security and avoid revenue leakage. For example, the local firewall 116 can verify that A2P providers 102 paid for the A2P messages and that the A2P messages are addressed to destination devices that are subscribed to receive the A2P messages from the A2P providers 102.

[0086] The local firewall 116 can be a local platform of the central system 104 that is installed on each of the MNOs 106. For example, the local firewall 116 can be deployed within the core and IT network of the MNO 106. The local firewall 116 can be a modular application or system that it can be easily scalable to accommodate more operators and functions. The local firewall 116 can support or utilize communication protocols such as SMPP and SS7 MAP to interface with MNOs 106 any network elements such as MSG, SMSO, HLR, or STP.

[0087] The local SMSO 118 of the MNO 106 can forward or transmit the A2P messages from the central system 104 to the destination devices. The local SMSO 118 can receive the A2P messages from the central system 104. The local SMSO 118 can forward or transmit the A2P messages that are allowed by the local firewall 116. For example, responsive to the local firewall 116 allowing the A2P messages, the local SMSC 118 can transmit the A2P messages to the destination devices.

[0088] The local database 120 of the MNO 106 can be specific to each MNO 106. The local database 120 can store the rules for the local firewall 116 and SMS details data. The local database 120 can receive the lists from the central firewall 110 to synchronize with from the central database 112.

[0089] At flow 152, the A2P providers 102 can submit the A2P message to the central SMSC 108. At flow 154, the central SMSC 108 can submit a response to the A2P providers 102 to acknowledge receiving the A2P messages from the A2P providers 102. At flow 156, the central SMSC 108 can submit the A2P message to the central firewall 110.

[0090] At flow 158, the central firewall 110 can allow the A2P messages from the central SMSC 108 to be forwarded to the local firewall 116 if the A2P message satisfies the rules of the central firewall 110. In some implementations, the central firewall 110 can allow the A2P messages from the central SMSC 108 to be forwarded to the local SMSC 118 if the A2P message satisfies the rules of the central firewall 110. At flow 160, the local firewall 116 can submit a response to the central firewall 110 to acknowledge receiving the A2P messages from the central firewall 110. At 162, the central firewall 110 can submit a response to the central SMSC 108 to acknowledge the local firewall 116 receiving the A2P messages.

[0091] At flow 164, the local SMSC 118 can notify the central firewall 110 that the A2P messages were delivered to the destination devices. At flow 166, the central firewall 110 can transmit a response to the local SMSC 118 to acknowledge receiving the notification. At flow 168, the central firewall 110 can notify the central SMSC 108 that the A2P messages were delivered to the destination devices. At flow 170, the central SMSC 108 can notify the A2P providers 102 that the A2P messages were delivered to the destination devices. At flow 172, the A2P providers can transmit a response to the central SMSC 108 to acknowledge receiving the notification.

[0092] Now referring to FIG. 1 B, FIG. 1 B displays an overview of the centralized firewall management system for blocking A2P messages according to implementations of the present disclosure. As previously discussed with reference to flow 152, the A2P providers 102 can submit to the central SMSC 108. As previously discussed with reference to flow 154, the central SMSC 108 can submit to the A2P providers 102. As previously discussed with reference to flow 156, the A2P providers 102 can submit to the central SMSC 108. However, in contrast to flow 158 of FIG. 1A, FIG. 1 B depicts the central firewall 110 blocking the A2P message. When the A2P message is blocked, the A2P message will be prevented from reaching the local SMSC 118. Responsive to blocking the A2P message, the central firewall 110 can transmit a report (e.g., CDR) to the MNO 106 (e.g., Operator FTP to be shared by operator team). The central firewall 110 can provide the report to the usage manager 114, which can store the report.

[0093] Now referring to FIG. 2, FIG. 2 illustrates a system 200 of a hardware architecture of the central system 104 according to implementations of the present disclosure. The central system 104 can include clustered database server. The central system 104 can be virtual machines (VM) 202A-202N (generally referred to as VM 202). The VM 202 can include redundant application and business processing servers. The VM 202 can include Management Servers such as Vcenter, PRT G, or Jumpbox. The VM 202 can include HPE Nimble AF40 All Flash Storage. The VM 202 can maintain 30 G8 connectivity. The VM 202 can communicate with the central firewall 110. The central firewall 110 can establish or maintain a secure site to sec tunnel with the MNO 106A and the MNO 106B. For example, the MNO 106A can be an operator network and the MNO 106B can be another network. The MNO 106A can include a local firewall 116A. The MNO 106B can include a local firewall 116B.

[0094] Now referring to FIG. 3, FIG. 3 illustrates a system 300 of a network architecture of the centralized firewall management system according to implementations of the present disclosure. The central database 112 can synchronize data with one or more local databases 120a-120n of one or more MNOs 106a- 106n (generally referred to as mobile network operator 106). In some implementations, the central system 104 provides data to the local database 120 via a network connection in real time or at predetermined intervals. The A2P aggregators’ 302A-302N can aggregate A2P messages. The A2P aggregators 302A-302N can be the A2P providers 102. The A2P aggregators 302A can establish a SMPP public IP port 304A with the LB 306A. The A2P aggregators 302A can establish a SMPP public IP port 304B with the LB 306B. The LB 306A and LB 306B can each include a respective floating IP address. The LB 306A and 306B can communicate with the central SMSO 108A-108C. The central SMSO 108 can communicate via SS7 with the LB SMPP 308A and 308B (generally referred to as LB SMPP 308). The LB SMPP 308 can communicate via SMPP with the central firewalls 110A-110C (generally referred to as central firewalls 110). The central firewalls 110 can be applications. The central firewalls 110 can maintain respective IP addresses. The central firewalls 110 can communicate with the VM 202. The central firewalls 110 can communicate with the end user management refill portal 310, which can track the activity (e.g., blocking or allowing A2P messages) of the central firewalls 110. The end user management refill portal 310 can include WEB-DMZ Public IP 312A and 312B, which can be communicatively coupled to web applications 314A and 314B. The central firewalls 110 and the components of the end user management refill portal 310 can be communicatively coupled to central databases 112A-112N. The central system 104 can communicate via connection 316 to the MNOs 106A-106D (e.g., Vodacom, MTN, Orange, Zain, etc.) The connection 316 can include SMPP or SMPP over IP sec tunnel. [0095] Now referring to FIG. 4, FIG. 4 illustrates an architecture of the MNOs 106 communicatively coupled to the centralized firewall management system according to implementations of the present disclosure. The central system 104 can output traffic or communicate via the connection 316 to the MNOs 106A-106D (e.g., Vodacom, MTN, Orange, Zain, etc.) . The connection 316 can include SMPP or SMPP over IP sec tunnel. Each MNO 106 can include the local firewall 116 and the local SMSC 118. Each MNO 106 can include a MSG or TSP component 402A-402D. Each MNO 106 can include a Mediation/FTP component 404A-404D.

[0096] Referring now to FIG. 5, FIG. 5 illustrates a flow for managing centralized A2P messages according to implementations of the present disclosure. The method 500 can be performed by the central system 104 shown in FIGs. 1A and 1B. The central system can configure a local firewall of a local MNO with rules (step 502). The central system receive A2P messages (step 504). The central system can evaluate the A2P messages (step 506). The central system can forward the A2P messages to the local MNO (step 508). Additional details regarding FIG. 5 are provided in conjunction with the description of FIG. 6.

[0097] The central system can configure a local firewall of a local MNO with rules (step 502). The central system can configure the local firewall to block A2P messages that did not pass through or were not received from the central system. The CMFS can manage the rules and definitions of the local firewalls. The central system can configure the local firewall with other rules for the local firewall to determine whether to allow or block A2P messages. The central system can configure the MNO to store the rules for the local firewall of the MNO. The central system can provide the MNO with lists of approved A2P messages and associated identifiers. In some implementations, the CMFS can configure, for each local MNO, a respective local firewall with rules configured to cause the respective local firewall to cause blocking of A2P messages that satisfy the rules configured by the central firewall. The central system can define or configure blocking rules, artificial intelligence generated rules, or international A2P message validation rules. The central system can define the rules based on geography (e.g., country level) or for each MNO (e.g., operator). In some implementations, the central system can configure the respective local firewall of each local MNO with the stored rules.

[0098] The local firewall can be a local platform that is installed on each of the MNOs. For example, the local firewall can be deployed within the core and IT network of the MNO. The local firewall can be a modular application or system that it can be easily scalable to accommodate more operators and functions. The local firewall can support or utilize communication protocols such as SMPP and SS7 MAP to interface with MNOs 106 any network elements such as MSG, SMSC, HLT, or STP.

[0099] The central system can include direct integration with the MNO to allow or block the A2P messages (e.g., A2P SMS traffic) from being forwarded to the MNO or to configure the local firewall 116 of the MNO. In some implementations, the central system can allow the international A2P message to be forwarded from the central system to the local SMSC of the local MNO. In some implementations, the central system can allow the international A2P message to be forwarded from the central system to the local firewall of the local MNO. Conversely, the central system can block the international A2P message from being forwarded from the central SMSC to the local firewall or the local SMSC of the local MNO.

[0100] The central system can manage or maintain lists for determining whether the A2P messages are allowed or blocked. The central system can create or generate custom filtration rules to whitelist or blacklist messages based on the sender identifier, GT addresses, or A2P message content. The whitelist of identifiers associated with A2P messages can be permanently allowed to be forwarded. The whitelist can include sender identifiers, network identifiers, destination device identifiers, or message content associated with A2P messages permanently allowed to be forwarded. For example, the central system can maintain a whitelist with sender identifiers related to a specific network identifier. The blacklist of identifiers associated with A2P messages can be permanently blocked from being forwarded. The blacklist can include sender identifiers, network identifiers, destination device identifiers, or message content associated with A2P messages permanently blocked from being forwarded. For example, the central system can block messages by providing either a specific GT or by blocking a range of GTs. The central system can block sender identifiers based on a specific sender identifier.

[0101] The central system can manage or maintain rules for determining whether the A2P messages are allowed or blocked. The central system can define or configure blocking rules, artificial intelligence generated rules, or international A2P message validation rules. The central system can define the rules based on geography (e.g., country level) or for each MNO (e.g., operator). For example, the central system can configure or define rules to block A2P messages from certain countries. The central system can filter different SMS traffic types from A2P to P2P as well as from local and international networks. The central system can filter MAP originating address to identify the sender based on type of number “TON” “ex: numeric or alphanumeric sender”. In yet another example, the central system can receive (e.g., from a user via the management interfaces) SMSC global titles (GTs) to be excluded from analysis and filtering by the central system. The central system can identify A2P messages that have the SMSC GTs to be excluded. The central system can exclude the A2P messages from analysis. For example, the exclusion can specify “local SMSCs”. The central system would exclude A2P messages associated with local SMSCs from being analyzed. By excluding the A2P messages from analysis and filtering, the A2P messages can proceed to be sent to their destinations. For example, the A2P messages associated with the local SMSCs can be sent to their destination.

[0102] The central system can store the lists and rules in a central database (e.g., central database 112). For example, the central system can store or maintain international A2P Identifiers (sender identifiers, network identifiers, destination identifiers, permitted # of messages, allowed or blocked content), defined rules, or automatic generated rules. The central system can store or maintain the rules for the central system to determine whether to forward or block the A2P messages. The central system can maintain or manage identifiers used by the rules to determine whether to forward or block the A2P messages. In some implementations, the central system can maintain, in a central database, a list comprising at least one of a first application identifier, a first network identifier, a first message text, or a first destination device identifier associated with A2P messages permanently allowed to be forwarded. For example, the central system can maintain a list (e.g., whitelist) of identifiers associated with A2P messages that can be permanently allowed to be forwarded. In some implementations, the central system can maintain, in the central database, a list including at least of one of a second application identifier, a second network identifier, a second message text, or a second destination device identifier associated with A2P messages permanently blocked from being forwarded. For example, the central system can maintain a list (e.g., blacklist) of identifiers associated with A2P messages that can be permanently blocked from being forwarded.

[0103] The central database of the central system can maintain or store identifiers associated with the A2P messages. In some implementations, the central system can maintain or update data corresponding to at least of one of an application identifier, a network identifier, or a destination device identifier. For example, the central system can add, update, or remove identifiers to the whitelist or the blacklist. In some implementations, the central system can receive, additional data stored in a local database (e.g., local database 116) in communication with a local firewall (e.g., local firewall 118). For example, the central system can receive updated destination device identifiers or rules defining which destination devices can receive A2P messages. In some implementations, the central system can store the additional data in the central database. For example, the central system can save or overwrite existing information. In some implementations, the central system can transmit, for storage in a local database in communication with the local firewall, the additional data to synchronize the data included in the central database. For example, the central system can provide the updated identifiers or rules to the local database. In some implementations, the central system can receive the additional data from a first local database and transmit the additional data to the second local database to synchronize the first and second local databases. For example, the central system can receive identifiers or rules from one MNO and provide those identifiers and rules to the other MNO.

[0104] The central system can synchronize its central database with each local database (e.g., local database 120) to share information among the MNOs. For example, the central system can share the data stored on the central database with the local database. The central system can synchronize data with any data source or database of any service or application. For example, the central system can be integrated with the MNO and the NTP servers of the central system for real-time synchronization. The central system can transmit the lists stored by the central database to the local databases. The central system can update the lists stored by the local database. In some implementations, the central system can transmit one or more updates to at least one of the first list or the second list to synchronize the first list and the second list stored in each local database with the first list and the second list stored in the central database. In some implementations, the central system can transmit the one or more updates via a connection maintained between the central system and each local database in communication with a respective local firewall of the plurality of local firewalls.

[0105] The central system can receive messages (step 504). The central system can handle the flow of A2P messages from the A2P providers (e.g., A2P providers 102) to the MNOs. The central system can receive the A2P messages from the A2P providers and forward the A2P messages to the MNOs. The central system can submit a response to the A2P providers to acknowledge receiving the A2P messages from the A2P providers. The A2P message can be an international message. For example, the central system can collect or receive terminated international A2P messages from international carriers. The A2P message can include message traffic in which a person is receiving messages from an application rather than another individual. The A2P message can be a one-way message because the recipient is not expected to directly reply. Examples of the A2P messages include marketing communications, appointment reminders, chat bots, notifications, and OTPs, or PIN codes. The A2P messages can include graphical object, button, or icon presented on a display screen of the recipients. In some implementations, the graphical object, button, or icon can be displayed within a mobile application executing on the devices of the recipients.

[0106] The central system can evaluate messages (step 506). The central system can determine whether to transmit the A2P messages to the MNO. The central system can monitor, intercept, and filter incoming and outgoing A2P messages to determine whether to allow or block the A2P messages. For example, the central system can filter the received A2P messages. The central system can forward the filtered messages to the MNOs. For example, the central system can forward the A2P messages based on number planning. In another example, the central system can block unauthorized, unpaid, spammed, fraudulent, and unwanted traffic. In another example, the central system can block the A2P messages to prevent the A2P message from being sent.

[0107] The central system can determine whether to forward or block the A2P messages by applying the rules and the lists to the sender identifiers of the A2P providers that are attempting to send the A2P messages to the destination devices. For example, the central system can identify the sender address parameter (e.g., source_subaddress) to identify the sender operator or A2P providers that are associated with the MSISDN sending the A2P message. For example, if the sender identifier matches a network identifier on the whitelist, then the central system can determine to allow the A2P message. In another example, if the sender identifier matches a network identifier on the blacklist, then the central system can determine to block the A2P message. In yet another example, if the sender identifier is unavailable, then the central system can allow or block the A2P messages and analyze another identifier or content of the A2P messages.

[0108] Based on the sender identifiers, the central system can detect spoofing of A2P messages and block those A2P messages. For example, the central system can detect spoofing when MO A2P messages arrive from a foreign MSG. The central system can query the HLR about the subscriber location and compare the VLR ID registered in the HLR with the calling MSG. If the VLR ID and the calling MSG are not identical, the central system can identify the MO SMS as a spoofing case and block the A2P message. The central system can block A2P messages from A2P providers that simulate home SMSC GTs or home subscribers.

[0109] Based on the sender identifiers, the central system can detect MT messages and allow those A2P messages. The central system can correlate each MT-FSM with a SRI-request. The central system can detect and block MT traffic from certain A2P providers 102 (e.g., international senders) without any correlation with the SRI-SM request. For example, the central system can utilize a default online rule to handle A2P messages for which an SRI response is received but no SRI request was sent. In another example, the central system can apply default online rules that can be predefined system built-in rules applied to each A2P message passing through the central system. The central system can block those A2P messages and mark them as spam.

[0110] Based on the sender identifiers, the central system can track how many A2P messages a sender is attempting to send, and allow or block the A2P messages based on the number of A2P messages. Based on the number of A2P messages, the central system can detect an abnormal spike traffic for a certain time duration in reference to the traffic of previous times. For example, the central system can identify that an A2P provider is sending more messages than a predetermined threshold, which can indicate that the A2P provider is sending spam (e.g., was hacked). The central system can block A2P messages from A2P providers suspected of sending spam.

[0111] The central system can parse or analyze the A2P messages to identify the network to which they are being sent. The central system can identify the network identifier of the MNO to which the A2P messages are addressed. The central system can use the network identifier to differentiate between the types of traffic. The central system can identify or extract network identifiers from the A2P messages. The central system can identify network identifiers such as MSISDN, SCCP calling and called GTs, MAP SM-OA or SM-DA, or calling number address (e.g., MSISDN). The central system can utilize the network address parameter (e.g., dest_subaddress) to identify the MNO that is associated with the MSISDN of the A2P message. For example, to identify the MNO, the central system can identify a 7-digit MCC+MNO value that represents the MNO.

[0112] To analyze and then allow or block the A2P messages, the central system does not need to change the network identifier of the A2P message. For example, address length increase due to MAP or SCOP address manipulation can cause TCAP segmentation. The central system can maintain message transparency. Transparency can be consistent and standard among the MNOs and SMS hubs. The SCOP and MAP addresses can remain consistent. For example, the SCOP and the MAP can belong to the same MNO and can be seen by entities readily as belonging to the same entity. In some long-term installations, transparency is a mandatory requirement of the MNO or the regulator of the central system. For example, the receiving MNO can identify the A2P provider regardless of how many hubs (e.g., central system 104) or MNOs the A2P message may have transited through.

[0113] Based on the network identifiers, the central system can determine whether to allow or block the A2P messages. For example, the central system can use the network identifier for fraud detection and management procedures. The central system can determine whether to forward or block the A2P messages by using the rules and the lists to analyze the network identifiers of the MNO via which the A2P messages are to be sent.

[0114] The central system can determine whether the network identifier is on the blacklist or the whitelist. For example, if the network identifier matches a network identifier on the whitelist, then the central system can determine to allow the A2P message. In another example, if the network identifier matches a network identifier on the blacklist, then the central system can determine to block the A2P message. In yet another example, if the network identifier is unavailable, then the central system can allow or block the A2P messages and analyze another identifier or content of the A2P messages.

[0115] Based on the network identifiers, the central system can track how many A2P messages are being sent to particular MNOs, and allow or block the A2P messages based on the number of A2P messages. Based on the number of A2P messages, the central system can detect an abnormal spike traffic for a certain time duration in reference to the traffic of previous times. For example, the central system can identify that more A2P messages are being sent to a MNO than a predetermined threshold, which can indicate that the MNO is being spammed (e.g., denial of service attack against an MNO). The central system can block A2P messages suspected of sending spam to MNOs.

[0116] The central system can parse or analyze the A2P messages to identify the destination device to which they are being sent. For example, the central system can identify or extract destination identifiers from the A2P messages such as a calling number address (e.g., MSISDN). To analyze and then allow or block the A2P messages, the central system does not need to change the destination device identifier or calling number of the A2P message.

[0117] Based on the destination identifiers, the central system can determine whether to allow or block the A2P messages. For example, the central system can use the destination identifier for fraud detection and management procedures. The central system can determine whether to forward or block the A2P messages by using the rules and the lists to analyze the destination identifiers of the MNO via which the A2P messages are to be sent to the destination devices.

[0118] Based on the destination identifiers, the central system can determine whether the destination identifier is on the blacklist or the whitelist. For example, if the destination identifier matches a destination identifier on the whitelist, then the central system can determine to allow the A2P message. In another example, if the destination identifier matches a destination identifier on the blacklist, then the central system can determine to block the A2P message. In yet another example, if the destination identifier is unavailable, then the central system can allow or block the A2P messages and analyze another identifier or content of the A2P messages.

[0119] Based on the destination identifiers, the central system can track how many A2P messages are being sent to particular MNOs or destination devices, and allow or block the A2P messages based on the number of A2P messages. Based on the number of A2P messages, the central system can detect an abnormal spike traffic for a certain time duration in reference to the traffic of previous times. For example, the central system can identify that more A2P messages are being sent to a destination than a predetermined threshold, which can indicate that the destination is being spammed (e.g., denial of service attack). The central system can block A2P messages suspected of sending spam to destinations.

[0120] The central system can determine whether to forward or block the A2P messages by applying the rules and the lists to the message content of the A2P messages. The central system can block A2P messages that include certain message content (e.g., message includes an inappropriate word or sentence). For example, the central system can identify or extract the message content in the A2P message. The central system can compare the message content to predetermined message content defined by the rules or lists. For example, if the message content matches restricted message content, then the central system can determine to block the A2P message.

[0121] Now referring to FIG. 6 in conjunction with FIG. 5, FIG. 6 illustrates an operational flow for validating messages corresponding to the method of FIG. 5. As described herein, the central system can receive messages (step 602). For example, the central system can receive A2P messages from the A2P providers. The central system can extract or identify identifiers from the A2P messages. For example, the central system can extract or identify the network identifier from the A2P messages.

[0122] The central system can determine whether the network identifier of the A2P messages is included in the whitelist of network identifiers (step 604). The central system can query or lookup the network identifier in the whitelist. If the network identifier is included in the whitelist, then the central system can forward the A2P message to the local MNO (step 606). For example, central system can identify the network identifier in the whitelist. The central firewall of the central system can allow the A2P messages to be forwarded. For example, the network identifier can be associated with an MNO that is allowed to receive all A2P messages.

[0123] If the network identifier is not included in the whitelist, then the central system can determine whether the combination of the network identifier and the sender identifier is whitelisted (step 608). For example, the central system can fail to find the network identifier in the whitelist. However, A2P messages might still be allowed to be forwarded to the MNO having the network identifier if the A2P messages are from a particular A2P provider (e.g., trusted entity such as a school or weather service) having the sender identifier. The central system can extract or identify the sender identifier from the A2P messages. The central system can query or lookup the sender identifier and the network identifier in the whitelist.

[0124] If the combination of the network identifier and the sender identifier is included in the whitelist, then the central system can forward the message to the local MNO (step 610). For example, the central system can identify that the combination of the sender identifier and the network identifier are in the whitelist. The central firewall of the central system can allow the A2P messages to be forwarded. For example, the central firewall can allow A2P messages that are sent from a particular A2P provider having the sender identifier to a particular MNO having the network identifier.

[0125] If the combination of the sender identifier and the network identifier are not in the whitelist, then the central system can determine whether a combination of the message content and the sender identifier is available (step 612). For example, the central system can fail to find the network identifier and the sender identifier in the whitelist. However, A2P messages might still be allowed to be forwarded to the MNO having the network identifier if the A2P messages include particular message content (e.g., an emergency alert). The central system can extract or identify the message content from the A2P messages. The central system can query or lookup the message content and the sender identifier in the central database.

[0126] If the combination of the message content and the sender identifier is available, then the central system can determine whether a corresponding rule is satisfied (step 614). The central system can query the message content and the sender identifier against predetermined rules. For example, a rule can allow A2P messages if the message content includes an emergency alert and the A2P message is addressed to an MNO that can receive emergency alerts. If the rule is not satisfied, then the central system can block the message (step 616). For example, if the message content of the A2P messages does not include emergency alerts, then the A2P message would not satisfy the rule. The central system can block A2P messages that fail to satisfy the rule from being forwarded to the MNO. If the rule is satisfied, then the central system can allow the A2P messages to be forwarded to the local MNO (step 618). For example, A2P messages that include the emergency alert addressed to the MNO would satisfy the rule. The central system can allow A2P messages that satisfy the rule to be forwarded to the MNO.

[0127] If the combination of the message content and the sender identifier is unavailable, then the central system can determine whether the sender identifier is available and blacklisted (step 620). For example, the central system can fail to identify the message content and the sender identifier in the whitelist. However, either the sender identifier or the message content might be available. For example, the central system might be able to extract or identify the sender identifier but not the message content. The central system can determine whether the sender identifier is available. For example, the central system can identify whether the sender identifier can be extracted from the A2P messages. The central system can extract the sender identifier and lookup the sender identifier in the blacklist maintained by the central database. If the sender identifier is available and blacklisted, then the central system can block the A2P message (step 622). For example, the central system can match the sender identifier (e.g., A2P provider sending the A2P messages) to a sender identifier in the blacklist (e.g., A2P provider blocked from sending the A2P messages). The central system can block the A2P messages to prevent them from being forwarded to the MNO. For example, the central system can block A2P messages from certain A2P providers by blocking A2P messages having sender identifiers of such A2P providers.

[0128] If the sender identifier is unavailable, then the central system can determine whether the message content is available and blacklisted (step 624). For example, the central system can fail to identify the sender identifier from the A2P message. However, the message content might be available even if the sender identifier is unavailable. For example, the central system might be able to extract or identify the message content but not the sender identifier. The central system can query or lookup the message content in the blacklist maintained by the database of the central system. For example, the central system can query or lookup words or objects included in the A2P message. If the message content is available and blacklisted, then the central system can block the message (step 622). For example, the central system can match the message content (e.g., inappropriate words or fraudulent links) to message content (e.g., known inappropriate words or known fraudulent links) in the blacklist. The central system can block the A2P messages to prevent them from being forwarded to the MNO. For example, the central system can block A2P messages having inappropriate words or fraudulent links by blocking A2P messages having such message content.

[0129] If the message content is unavailable, then the central system can determine whether the network identifier is available (step 626). For example, the central system can fail to identify the message content in the A2P message. However, the network identifier might be available even if the message content is unavailable. For example, the central system might be able to extract or identify the network identifier but not the message content. The central system can query or lookup the network identifier in the blacklist maintained by the database of the central system. For example, the central system can query or lookup the network identifier to which the A2P message is addressed. If the network identifier is available and blacklisted, then the central system can block the message (step 622). For example, the central system can match the network identifier (e.g., MNO to which the A2P messages are addressed) to a network identifier in the blacklist (e.g., MNO to which A2P messages are blocked). The central system can block the A2P messages to prevent them from being forwarded to the MNO. For example, the central system can block A2P messages from being sent to certain MNOs by blocking A2P messages having the network identifiers of such MNOs.

[0130] If the network identifier is not blacklisted, then the central system can forward the message to the local MNO (step 628). For example, the central system can fail to find the network identifier in the blacklist. However, A2P messages might still be allowed to be forwarded. The central firewall of the central system can be setup to allow A2P messages with sender identifiers, message content, or network identifiers that are neither on the whitelist nor the blacklist to be forwarded. For example, the network identifier might be associated with a new MNO that cannot be identified or has not yet been added to the whitelist or the blacklist. In another example, the message content might be unknown or has not yet been analyzed and added to the whitelist or the blacklist. In yet another example, the sender identifier might be associated with a new A2P provider that cannot be identified or has not yet been added to the whitelist or the blacklist. It is contemplated that the central firewall of the central system can be setup to block A2P messages with identifiers that are neither on the blacklist or the whitelist. For example, the central system can be setup to block unclassified A2P messages.

[0131] The central system can ensure traffic security and avoid revenue leakage. For example, the central system can verify that A2P providers paid for the A2P messages and that the A2P messages are addressed to destination devices that are subscribed to receive the A2P messages from the A2P providers. In particular, when a destination device subscribed to the MNO attempts to register for a social networking service, the user device will transmit, via the MNO, a request to the servers of the social networking service for an OTP. The social network service can be the A2P provider that transmits the OTP (example of an A2P message) to the MNO, which will then forward the OTP to the destination device. Unlike generic messages among user devices, the MNO needs to bill or charge the social networking service (example of the A2P providers) for transmitting the OTP to the destination device. Prior to allowing the A2P messages of the A2P providers, the central system can verify that the A2P providers paid for the A2P messages.

[0132] The central system can forward the messages to the local MNO (step 508). The central system can include direct integration with the MNO to forward the A2P messages (e.g., A2P SMS traffic). In some implementations, the central system forward the international A2P message to the local MNO. The central system can forward the A2P message responsive to the A2P messages satisfying the rules of the central system. In some implementations, the central system can allow the international A2P message to be forwarded to the local MNO to cause the corresponding local MNO to forward the message to the destination device. The central system can transmit or forward the A2P messages via a SMPP protocol, USSD push, smart push, or push SMS. In some implementations, the central system can forward the international A2P message to the MNO to cause the MNO to forward the message to a destination device responsive to the international A2P message satisfying the one or more rules the local MNO. In some implementations, the local MNO can forward the message responsive to the international A2P message satisfying the rules of the local firewall of the MNO. The MNO can transmit a response to the central system to acknowledge receiving the A2P messages from the central system. The central system can generate an acknowledgement of the MNO receiving the A2P messages.

[0133] The MNO can forward or transmit A2P messages to the destination devices. The MNO can forward or transmit the A2P messages that are allowed by the MNO and the central system. The local firewall can analyze A2P messages received from the central system. The local firewall can be similar to a SMS firewall or can incorporate the functionality of a firewall of the central system. The local firewall can use its local rules to determine whether to allow or block the A2P message. The local firewall can control the forwarding or delivery of various types of messages (e.g., A2P SMS) to ensure traffic security and avoid revenue leakage. For example, the local firewall can verify that A2P providers paid for the A2P messages and that the A2P messages are addressed to destination devices that allow receipt of A2P messages from the A2P providers. In some implementations, responsive to the international A2P message satisfying the rules of the local firewall, the local firewall can enable the MNO to forward the message to the destination device.

[0134] The MNO can notify the central system that the A2P messages were delivered to the destination devices. The central system can transmit a response to the MNO to acknowledge receiving the notification. The central system can receive the notification indicating that the A2P messages were delivered to the destination devices. The central system can notify the A2P providers that the A2P messages were delivered to the destination devices. The A2P providers can transmit a response to the central system to acknowledge receiving the notification. [0135] The central system can identify or monitor the forwarding of A2P messages from the A2P providers to the MNOs. In some implementations, the central system can maintain a listing of each forwarded international A2P message. In some implementations, the central system can provide a user interface via which each forwarded international A2P message can be displayed.

[0136] The central system can be a centralized billing and charging component. For example, when a destination device subscribed to the MNO attempts to register for a social networking service, the user device will transmit, via the MNO, a request to the servers of the social networking service for an OTP. The social network service can be the A2P provider that transmits the OTP to the MNO, which will then forward the OTP to the destination device. The usage manager can bill or charge the social networking service for transmitting the OTP to the destination device.

[0137] The central system can control the charging and billing of A2P messages (such as those terminating in a particular country). The central system can set pricing tables and rules for the international A2P providers and for the MNOs. In some implementations, the central system can determine for the international A2P message, a charge to be assessed for the international A2P message in accordance with one or more pricing tables. In some implementations, the central system can determine that an A2P provider from which the international A2P message was received has a sufficient balance or has paid for the international A2P message. In some implementations, the central system can determine, responsive to the central system determining that the A2P provider has a sufficient balance or has paid for the international A2P message, to forward the international A2P message to the local MNO.

[0138] The central system can include alarms integration with network monitoring applications. The central system can implement internal alarming tools to generate or provide an alert in case of potential threats. In some implementations, the central system can detect that at least one of the forwarded international A2P messages satisfies an alert policy. In some implementations, the central system can generate, for each of the forwarded international A2P messages that satisfy the alert policy, an alert for display in the user interface. Some examples for events that can cause alarms are when an A2P provider that is local (e.g., local bank) sends international A2P messages, if there is a traffic outage for more than a predetermined amount of time (e.g., one minute), or if there is a disconnection among any of the components described herein (e.g., disconnection between the local firewall 116 and the central firewall 110).

[0139] The central system can perform messaging trend analysis through Al and machine learning platforms. The central system can analyze data. Based on the analysis, the central system can identify clients (e.g., MNO 106 orA2P providers 102) that are experiencing a behavior that is different from average behavior. An example of a behavioral difference can be lost or leaked revenue, or some suspicious activity being performed. The analysis can rely on data from all operators to create a more robust central platform that can generate or provide relevant alerts and notifications.

[0140] In view of the foregoing, it should be appreciated that the systems and methods described herein can provide various technical improvements. In particular, one technical improvement provided by the centralized firewall management system includes enabling a central regulator to communicate with and configure many different MNOs. The central regulator can utilize data and synchronize with all of the MNOs. For example, the central regulator can synchronize device information such that if a sender identifier (A2P SMS sender) is identified as fraud by one MNO, the central regulator can configure the other MNOs to also block this device information.

[0141] Another technical improvement provided by the centralized firewall management system is that international A2P providers can connect to a single point (central system) instead of connecting to multiple operators. For example, the A2P providers can just provide the A2P messages to the central system, which can then filter and forward the A2P messages to the appropriate MNOs.

[0142] Another technical improvement provided by the centralized firewall management system is that the centralized firewall management system can intercept the A2P messages before they are provided to the MNOs and the destination devices. For example, when a user device connected to a MNO attempts to register for a social networking service, the user device will transmit, via the MNO, a request to the servers of the social networking service for an OTP. The social network service will use A2P providers to transmit the OTP to the MNO, which will then forward the OTP to the user device. Unlike generic messages among user devices, the central A2P firewall management system can intercept the A2P messages to bill or charge the social networking service for transmitting the OTP to the user device. Moreover, if the social networking service and the MNO are located in different countries, then the central A2P firewall management system can intercept the messages before they are sent to the MNO. The central A2P firewall management system can monitor and regulate the flow of A2P messages among the A2P providers and the destination devices to verify that the destination devices should receive the A2P message and to charge A2P providers for sending the A2P messages.

[0143] Another technical improvement provided by the centralized firewall system is that the regulator of the centralized firewall management system can have visibility of the international A2P traffic without the need to request it from each operator. Since the centralized firewall management system configures the firewalls and receives the A2P messages from the A2P providers, the centralized firewall management system can monitor which A2P providers are sending which A2P messages to which destination devices. B. Architecture Overview

[0144] Architecture

[0145] The present disclosure includes a central platform located in the central data center of the regulator (or any other official site) and local platforms installed in each of the operators. The central platform can be an A2P SMS hub for all the operators. The central platform can collect international A2P terminated SMS and send it to each operator based on the destination mobile station integrated services digital network (MSISDN) such as a phone number.

[0146] Each operator platform can have an embedded SMS Firewall to ensure traffic security and avoid revenue leakage that is in direct and real-time communication with the central firewall management system (central system).

[0147] The local firewalls can block any international A2P SMS traffic that bypass the central system. One of the objectives of the local system is to detect bypasses or leakages of messages and block them.

[0148] The solution architecture of the present disclosure is designed to be modular so that it can be easily scalable to accommodate more operators and functions.

[0149] The centralized SMS firewall management system can be a fully geographically redundant platform that can be installed in more than one data center to enable full availability without a single point of failure. In addition, any configuration in the functionality of the system can be performed without A2P service interruption.

[0150] The Centralized Firewall Management System Architecture

[0151] The System can collect or receive terminated international A2P messages from international carriers. The system can filter the received messages. The system can then forward the filtered messages to their operator destination based on number planning.

[0152] The platform can be designed in a modular architecture. For example, the platform can include six components at each central site:

SMS Load Balancer (LB)

SMSC

SMS Firewall Billing and Charging Module

Central Database

User interfaces

[0153] Operators Platform Architecture

[0154] The operator A2P platform can be based on an SMS Firewall deployed within the core and IT network of each mobile operator. The operator A2P platform can be responsible for controlling the delivery of all types of SMS to ensure traffic security and to avoid revenue leakage.

[0155] The local SMS Firewall can support multiple communication protocols such as Short Message Peer-to-Peer (SMPP) and SS7 MAP to interface with any network element such as MSC, SMSC, HLT, or STP.

[0156] Technical Overview - Technical Requirements - Integration Overview

[0157] A2P Providers can connect to the central A2P firewall system. For example, the A2P providers can connect via SMPP interface.

[0158] In some implementations, the system can include six components:

Load Balancer (LB): The LB can ensure adequate distribution of traffic over the various components of the system and ensure redundancy in the system.

MSG Gateway (SMSC): The SMSC can accept and forward the traffic among the various A2P providers.

SMS firewall: The SMS firewall can have an important role in ensuring traffic security and avoiding revenue leakage. The SMS firewall can monitor, intercept, and filter incoming and outgoing messaging traffic to enable mobile operators to block unauthorized, unpaid, spammed, fraudulent, and unwanted traffic. The SMS firewall can include direct integration with the mobile network operator (MNO) to forward the A2P SMS traffic.

Billing and Charging Module: This component can control the charging and billing of A2P messages (such as those terminating in a particular country).

Central Database: The central database can maintain configurations for accepting or blocking A2P messages.

User Interfaces: The user interfaces can enable an administrator to configure the rules for blocking or allowing the A2P messages. [0159] The A2P platforms can be integrated with the operators and the Network Time Protocol (NTP) servers of the regulator for real-time synchronization.

[0160] Address Manipulation

[0161] The short message can include three levels of addresses:

SCOP Calling and Called Global Titles

MAP SM-OAor SM-DA

Calling number address (e.g., MSISDN)

[0162] Modification of sender information

[0163] The addresses can be used for fraud detection and management procedures. The SCCP and MAP addresses can remain consistent. For example, the SCCP and the MAP can belong to the same operator and can be seen by entities readily as belonging to the same entity.

[0164] The calling number does not need to be changed. The originating MSISDN can be visible to the terminating hub and operator.

[0165] Segmentation

[0166] Address length increase due to MAP or SCCP address manipulation can cause additional TCAP segmentation.

[0167] Transparency

[0168] The architecture of the SMS hub can provide message transparency. For example, the receiving operator can identify the sending operator regardless of how many hubs the message may have transited through.

[0169] The source address ‘source_subaddress’ parameter can be utilized to identify the source operator that is associated with the MSISDN issuing the SMS message.

[0170] The destination address ‘dest_subaddress’ parameter can be utilized to identify the destination operator that is associated with the MSISDN receiving the SMS message.

[0171] For Operator Identification, a 7-digit MCC+MNC value can represent the source or destination operator. [0172] Transparency can be a feature of the system architecture. Transparency can be consistent and standard among the SMS hubs. In some long-term implementations of the system, transparency is a mandatory requirement.

[0173] Black and Whitelisting

[0174] The central system can apply blacklist and whitelist rules for filtering messages. Among the possible applications are:

1. Blocking SMS Content based on a specific message content whether a single word or sentence.

2. Creating custom filtration rules to Whitelist/Blacklist SMS based on two or more of: a. Sender ID b. GT c. SMS Content.

3. Blacklisting or whitelisting an entire network ID from sending SMS by providing its value through the firewall portal.

4. Whitelisting a sender ID related to a specific network ID.

5. Blocking messages by providing either a specific GT or by blocking a range of GTs.

6. Blocking Sender ID based on a specific sender ID.

7. Detecting spoofing traffic and blocking it from sources that simulate home SMSC GT or home subscribers. The spoofing detection mechanism can work when an MO SMS reaches the network from a foreign MSC. The system can inquire the HLR about the subscriber location and compare VLR ID registered in the HLR with the calling MSC. If the VLR ID and the calling MSC are not identical, the system can identify the MO SMS as a spoofing case and drop the message.

8. Detecting and Whitelist lonely MT messages. System can correlate each MT-FSM with a SRI- request. The user can add an SMSC GT to be excluded from checking “example: local SMSCs”.

9. Filtering different SMS traffic types from A2P to P2P as well as from local and international networks.

10. Filtering MAP originating address to identify the sender based on Type of Number “TON” “ex: numeric or alphanumeric sender”. 11. Detecting abnormal spike traffic for a certain time duration in reference to the traffic of previous times.

12. Displaying user friendly reporting and alerting system to satisfy regulatory (e.g., Regulator) needs.

13. Detecting and blocking MT traffic from international senders without any correlation with SRI- SM request. The message can be marked as spam and blocked.

14. Applying default online rules that can be predefined system built-in rules performed on each message passing through the system platform. Action can be taken immediately on the message to prevent the transaction from being completed. As an example of default online rule is receiving an SRI response, but for that no SRI request was sent.

15. Home routing, the system can provide full protection to local subscribers and outbound roamers. Operators can normally only control messages sent from their own network, while incoming MT text messages from other networks can be delivered directly to roaming subscribers in the public visited land mobile network (PLMN). The system with SMS Home Routing functionality can provide operators with a point of control for incoming messages to ensure maximum fidelity of threat protection. The flow of MT messages is changed by directing the MT messages to the system rather than straight to the destination subscriber.

[0175] System Deployment

[0176] International A2P Providers can be connected to the central A2P System SMSCs’ LBs floating IP. The central SMSCs can forward the received traffic to the firewall, which can filter it and route it to the operators.

[0177] The SMS flows can be between the provider, central SMSC, firewall (FW), and the operator’s SMSC. The system can validate SMS messages to accept some messages while blocking other messages.

[0178] Once the system receives the SMS, the central system can start a validation process to check if the SMS should be forwarded to the operator or blocked.

1. The received SMS can be assigned to a specific origin through a network ID, which can be an identifier that differentiates between traffic types. If the network ID is whitelisted, then the system does not apply the rules while allowing the message to be processed or forwarded.

2. If the network ID is not whitelisted, then the system can check if the combination of the network ID and the sender ID is whitelisted. For example, only a particular client is allowed to send SMS using this sender ID. In this case, the system can forward the message to the operator for normal processing.

3. If the above case was not applicable, the system can check if the combination of the sender ID and message (content) is available. If the system identifies a created rule for blacklisting this combination, then the system can block the message. Otherwise the system can forward the message to the operator.

4. If the combination of the sender ID and content was not available, the platform can check separately whether the sender ID or Network ID or Content is blacklisted. If the combination is blacklisted, the system can block the message. Otherwise the message will be forwarded to the operator.

[0179] Alarms Integration

[0180] The system can include alarms integration with network monitoring applications. The system can implement internal alarming tools to send an alert to the stakeholders in case of any potential threat. Some examples for alarms include:

• Local provider sending international A2P

• Traffic outage for more than 1 minute

• Disconnection between the local platform and the central platform or system

[0181] SMS Trend Analysis

[0182] The system can perform SMS trend analysis through Al and machine learning platforms. The system can analyze data. Based on the analysis, the system can identify clients that are experiencing a behavior that is different from average behavior. An example of a behavioral difference can be lost or leaked revenue, or some suspicious activity being performed. The analysis can rely on data from all operators to create a more robust central platform that includes accurate alerts and notifications.

[0183] The system can include a centralized SMSO that can control the flow of A2P messages from the International A2P providers to the local mobile operators. A local A2P firewall can block international A2P SMS that do not pass through the centralized system.

[0184] The system can include a central firewall that controls the rules definition and management of the local A2P firewalls. It can define blocking rules, artificial intelligence automatic rules, international A2P validation rules.... etc. on a country level or by operator. [0185] The system can include a centralized billing and charging component: This component can control the charging and billing of international A2P messages terminating in a country. The component can set pricing tables and rules for the international A2P message providers and for the local operators.

[0186] The system can include a central database: This can be the repository of data and rules: For example, the central database can include international A2P Identifiers (sender IDs, Network IDs, permitted # of SMS, allowed or blocked content), defined rules, or Al automatic rules definition. The central database can communicate with local databases of each of the local operators to synchronize and replicate information among the databases.

C. Computer System

[0187] Various operations described herein can be implemented on computer systems, which can be of generally conventional design. FIG. 7 shows a simplified block diagram of a representative server system 700 and client computer system 714 usable to implement certain implementations of the present disclosure. In various implementations, server system 700 or similar systems can implement services or servers described herein or portions thereof. Client computer system 714 or similar systems can implement clients described herein. The centralized A2P messaging system 100 and others described herein can be similar to the server system 700.

[0188] Server system 700 can have a modular design that incorporates a number of modules 702 (e.g., blades in a blade server embodiment); while two modules 702 are shown, any number can be provided. Each module 702 can include one or more processors 704 and local storage 706.

[0189] One or more processors 704 can include a single processor, which can have one or more cores, or multiple processors. In some implementations, one or more processors 704 can include a general- purpose primary processor as well as one or more special-purpose co-processors such as graphics processors, digital signal processors, or the like. In some implementations, some or all processing units 704 can be implemented using customized circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions that are stored on the circuit itself. In other implementations, one or more processors 704 can execute instructions stored in local storage 706. Any type of processors in any combination can be included in one or more processors 704.

[0190] Local storage 706 can include volatile storage media (e.g., conventional DRAM, SRAM, SDRAM, or the like) and/or non-volatile storage media (e.g., magnetic or optical disk, flash memory, or the like). Storage media incorporated in local storage 706 can be fixed, removable or upgradeable as desired. Local storage 706 can be physically or logically divided into various subunits such as a system memory, a read-only memory (ROM), and a permanent storage device. The system memory can be a read-and-write memory device or a volatile read-and-write memory, such as dynamic random-access memory. The system memory can store some or all of the instructions and data that one or more processors 704 need at runtime. The ROM can store static data and instructions that are needed by one or more processors 704. The permanent storage device can be a non-volatile read-and-write memory device that can store instructions and data even when module 702 is powered down. The term “storage medium” as used herein includes any medium in which data can be stored indefinitely (subject to overwriting, electrical disturbance, power loss, or the like) and does not include carrier waves and transitory electronic signals propagating wirelessly or over wired connections.

[0191] In some implementations, local storage 706 can store one or more software programs to be executed by one or more processors 704, such as an operating system and/or programs implementing various server functions such as functions of the centralized A2P messaging system 100 of FIGs. 1A and 1B or any other system described herein, or any other servers or system associated with the centralized A2P messaging system 100 of FIGs. 1A and 1B.

[0192] Software” refers generally to sequences of instructions that, when executed by one or more processors 704 cause server system 700 (or portions thereof) to perform various operations, thus defining one or more specific machine implementations that execute and perform the operations of the software programs. The instructions can be stored as firmware residing in read-only memory and/or program code stored in non-volatile storage media that can be read into volatile working memory for execution by one or more processors 704. Software can be implemented as a single program or a collection of separate programs or program modules that interact as desired. From local storage 706 (or non-local storage described below), one or more processors 704 can retrieve program instructions to execute and data to process in order to execute various operations described above.

[0193] In some server systems 700, multiple modules 702 can be interconnected via a bus or other interconnect 708, forming a local area network that supports communication between modules 702 and other components of server system 700. Interconnect 708 can be implemented using various technologies including server racks, hubs, routers, etc.

[0194] A wide area network (WAN) interface 710 can provide data communication capability between the local area network (interconnect 708) and a larger network, such as the Internet. Conventional or other activities technologies can be used, including wired (e.g., Ethernet, IEEE 802.3 standards) and/or wireless technologies (e.g., Wi-Fi, IEEE 802.11 standards).

[0195] In some implementations, local storage 706 is intended to provide working memory for one or more processors 704, providing fast access to programs and/or data to be processed while reducing traffic on interconnect 708. Storage for larger quantities of data can be provided on the local area network by one or more mass storage subsystems 712 that can be connected to interconnect 708. Mass storage subsystem 712 can be based on magnetic, optical, semiconductor, or other data storage media. Direct attached storage, storage area networks, network-attached storage, and the like can be used. Any data stores or other collections of data described herein as being produced, consumed, or maintained by a service or server can be stored in mass storage subsystem 712. In some implementations, additional data storage resources may be accessible via WAN interface 710 (potentially with increased latency).

[0196] Server system 700 can operate in response to requests received via WAN interface 710. For example, one of modules 702 can implement a supervisory function and assign discrete tasks to other modules 702 in response to received requests. Conventional work allocation techniques can be used. As requests are processed, results can be returned to the requester via WAN interface 710. Such operation can generally be automated. Further, in some implementations, WAN interface 710 can connect multiple server systems 700 to each other, providing scalable systems capable of managing high volumes of activity. Conventional or other techniques for managing server systems and server farms (collections of server systems that cooperate) can be used, including dynamic resource allocation and reallocation.

[0197] Server system 700 can interact with various user-owned or user-operated devices via a wide- area network such as the Internet. An example of a user-operated device is shown in FIG. 7 as client computing system 714. Client computing system 714 can be implemented, for example, as a consumer device such as a smartphone, other mobile phone, tablet computer, wearable computing device (e.g., smart watch, eyeglasses), desktop computer, laptop computer, and so on.

[0198] For example, client computing system 714 can communicate via WAN interface 710. Client computing system 714 can include conventional computer components such as one or more processors 717, storage device 718, network interface 720, user input device 722, and user output device 724. Client computing system 714 can be a computing device implemented in a variety of form factors, such as a desktop computer, laptop computer, tablet computer, smartphone, other mobile computing device, wearable computing device, or the like. [0199] Processor 717 and storage device 718 can be similar to one or more processors 704 and local storage 706 described above. Suitable devices can be selected based on the demands to be placed on client computing system 714; for example, client computing system 714 can be implemented as a “thin” client with limited processing capability or as a high-powered computing device. Client computing system 714 can be provisioned with program code executable by one or more processors 717 to enable various interactions with server system 700 of a message management service such as accessing messages, performing actions on messages, and other interactions described above. Some client computing systems 714 can also interact with a messaging service independently of the message management service.

[0200] Network interface 720 can provide a connection to a wide area network (e.g., the Internet) to which WAN interface 710 of server system 700 is also connected. In various implementations, network interface 720 can include a wired interface (e.g., Ethernet) and/or a wireless interface implementing various RF data communication standards such as Wi-Fi, Bluetooth, or cellular data network standards (e.g., 3G, 4G, LTE, etc.).

[0201] User input device 722 can include any device (or devices) via which a user can provide signals to client computing system 714; client computing system 714 can interpret the signals as indicative of particular user requests or data. In various implementations, user input device 722 can include any or all of a keyboard, touch pad, touch screen, mouse or other pointing device, scroll wheel, click wheel, dial, button, switch, keypad, microphone, and so on.

[0202] User output device 724 can include any device via which client computing system 714 can provide data to a user. For example, user output device 724 can include a display to display images generated by or delivered to client computing system 714. The display can incorporate various image generation technologies, e.g., a liquid crystal display (LCD), light-emitting diode (LED) including organic light-emitting diodes (OLED), projection system, cathode ray tube (CRT), or the like, together with supporting electronics (e.g., digital- to-analog or analog-to-digital converters, signal processors, or the like). Some implementations can include a device such as a touchscreen that function as both input and output device. In some implementations, other user output devices 724 can be provided in addition to or instead of a display. Examples include indicator lights, speakers, tactile “display” devices, printers, and so on.

[0203] Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a computer readable storage medium. Many of the features described in this specification can be implemented as processes that are specified as a set of program instructions encoded on a computer readable storage medium. When these program instructions are executed by one or more processing units, they cause the one or more processors to perform various operation indicated in the program instructions. Examples of program instructions or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter. Through suitable programming, one or more processors 704 and 717 can provide various functionality for server system 700 and client computing system 714, including any of the functionality described herein as being performed by a server or client, or other functionality associated with message management services.

[0204] It will be appreciated that server system 700 and client computing system 714 are illustrative and that variations and modifications are possible. Computer systems used in connection with implementations of the present disclosure can have other capabilities not specifically described here. Further, while server system 700 and client computing system 714 are described with reference to particular blocks, it is to be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. For instance, different blocks can be but need not be located in the same facility, in the same server rack, or on the same motherboard. Further, the blocks need not correspond to physically distinct components. Blocks can be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry, and various blocks might or might not be reconfigurable depending on how the initial configuration is obtained. Implementations of the present disclosure can be realized in a variety of apparatus including electronic devices implemented using any combination of circuitry and software.

[0205] While the disclosure has been described with respect to specific implementations, one skilled in the art will recognize that numerous modifications are possible. For instance, although specific examples of rules (including triggering conditions and/or resulting actions) and processes for generating suggested rules are described, other rules and processes can be implemented. Implementations of the disclosure can be realized using a variety of computer systems and communication technologies including but not limited to specific examples described herein.

[0206] Implementations of the present disclosure can be realized using any combination of dedicated components and/or programmable processors and/or other programmable devices. The various processes described herein can be implemented on the same processor or different processors in any combination. Where components are described as being configured to perform certain operations, such configuration can be accomplished, e.g., by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or any combination thereof. Further, while the implementations described above may make reference to specific hardware and software components, those skilled in the art will appreciate that different combinations of hardware and/or software components may also be used and that particular operations described as being implemented in hardware might also be implemented in software or vice versa.

[0207] Computer programs incorporating various features of the present disclosure may be encoded and stored on various computer readable storage media; suitable media include magnetic disk or tape, optical storage media such as compact disk (CD) or DVD (digital versatile disk), flash memory, and other non-transitory media. Computer readable media encoded with the program code may be packaged with a compatible electronic device, or the program code may be provided separately from electronic devices (e.g., via Internet download or as a separately packaged computer-readable storage medium).

[0208] Thus, although the disclosure has been described with respect to specific implementations, it will be appreciated that the disclosure is intended to cover all modifications and equivalents within the scope of the following claims.

Claims

CLAIMS What is claimed is:

1. A method comprising: configuring, by a central system including one or more processors in communication with a plurality of local mobile network operators (MNOs), for each local MNO, a respective local firewall with one or more rules configured to cause the respective local firewall to cause blocking of international application-to-person (A2P) messages that satisfy the one or more rules configured by the central system; receiving, by a central short message service center (SMSC) of the central system, an international A2P message; and forwarding, by the system, the international A2P message to a local MNO of the plurality of local MNOs to cause the local MNO to forward the message to a destination device responsive to the international A2P message satisfying the one or more rules of a local firewall of the local MNO.

2. The method of claim 1 , further comprising: providing, by the central system, a user interface via which the one or more rules can be received; storing, by the central system, the one or more rules received via the user interface; and wherein configuring the respective local firewall of each local MNO includes configuring the respective local firewall with the stored one or more rules.

3. The method of claim 1 , further comprising determining, by the central system, for the international A2P message, a charge to be assessed for the international A2P message in accordance with one or more pricing tables.

4. The method of claim 3, further comprising: determining, by the central system, that an A2P provider from which the international A2P message was received has a sufficient balance or has paid for the international A2P message; and determining, by the central system, responsive to determining that the A2P provider has a sufficient balance or has paid for the international A2P message, to forward the international A2P message to the local MNO.

5. The method of claim 1 , further comprising: maintaining, by the central system, in a central database, i) a first list comprising at least one of a first application identifier, a first network identifier, a first content type, or a first destination device identifier associated with A2P messages permanently allowed to be forwarded, and ii) a second list including at least of one of a second application identifier, a second network identifier, a second content type, or a second destination device identifier associated with A2P messages permanently blocked from being forwarded; and transmitting, by the central system, via a connection maintained between the central system and each local database in communication with a respective local firewall of the plurality of local firewalls, one or more updates to at least one of the first list or the second list to synchronize the first list and the second list stored in each local database with the first list and the second list stored in the central database.

6. The method of claim 1 , further comprising: maintaining, by the central system, a central database including data corresponding to at least of one of an application identifier, a network identifier, or a destination device identifier; receiving, by the central system, additional data stored in a first local database in communication with a first local firewall of the plurality of local firewalls; storing, the additional data in the central database; and transmitting, by the system, for storage in a second local database in communication with a second local firewall of the plurality of local firewalls, the additional data to synchronize the data included in the central database, the first local database and the second local database.

7. The method of claim 1 , wherein forwarding the international A2P message includes forwarding, by the central SMSC, the international A2P message to a local SMSC of the local MNO to cause the corresponding local SMSC to forward the message to the destination device responsive to the international A2P message satisfying the one or more rules of the local firewall.

8. The method of claim 1 , wherein forwarding the international A2P message includes forwarding, by the central SMSC, the international A2P message to a local firewall of the local MNO and responsive to the international A2P message satisfying the one or more rules of the local firewall, the local firewall configured to cause the corresponding local SMSC to forward the message to the destination device.

9. The method of claim 1 , wherein receiving the international A2P message includes receiving the international A2P message from an A2P provider via an application programming interface (API).

10. The method of claim 1, further comprising: detecting, by the central system, that at least one of the forwarded international A2P messages satisfies an alert policy; and generating, by the central system, for each of the forwarded international A2P messages that satisfy the alert policy, an alert for display in a user interface.

11. A system comprising: one or more processors in communication with a plurality of local mobile network operators (MNOs), the one or more processors configured by machine-readable instructions to: configure, for each local MNO, a respective local firewall with one or more rules configured to cause the respective local firewall to cause blocking of international application-to-person (A2P) messages that satisfy the one or more rules configured by the central system; receive, from a central short message service center (SMSC), an international A2P message; and forward the international A2P message to a local MNO of the plurality of local MNOs to cause the local MNO to forward the message to a destination device responsive to the international A2P message satisfying the one or more rules of a local firewall of the local MNO.

12. The system of claim 11, wherein the one or more processors are further configured to: provide, a user interface via which the one or more rules can be received; store, the one or more rules received via the user interface; and wherein configuring the respective local firewall of each local MNO includes configuring the respective local firewall with the stored one or more rules.

13. The system of claim 11, wherein the one or more processors are further configured to determine for the international A2P message, a charge to be assessed for the international A2P message in accordance with one or more pricing tables.

14. The system of claim 11, wherein the one or more processors are further configured to: determine that an A2P provider from which the international A2P message was received has a sufficient balance or has paid for the international A2P message; and determine, responsive to determining that the A2P provider has a sufficient balance or has paid for the international A2P message, whether to forward the international A2P message to the local MNO.

15. The system of claim 11, wherein the one or more processors are further configured to: maintain in a central database, i) a first list comprising at least one of a first application identifier, a first network identifier, a first message text, or a first destination device identifier associated with A2P messages permanently allowed to be forwarded, and ii) a second list including at least of one of a second application identifier, a second network identifier, a second message text, or a second destination device identifier associated with A2P messages permanently blocked from being forwarded; and transmit, via a connection maintained between the central system and each local database in communication with a respective local firewall of the plurality of local firewalls, one or more updates to at least one of the first list or the second list to synchronize the first list and the second list stored in each local database with the first list and the second list stored in the central database.

16. The system of claim 11, wherein the one or more processors are further configured to: maintain a central database including data corresponding to at least of one of an application identifier, a network identifier, or a destination device identifier; receive additional data stored in a first local database in communication with a first local firewall of the plurality of local firewalls; store the additional data in the central database; and transmit, for storage in a second local database in communication with a second local firewall of the plurality of local firewalls, the additional data to synchronize the data included in the central database, the first local database and the second local database.

17. The system of claim 11 , wherein forwarding the international A2P message includes forwarding the international A2P message to a local SMSC of the local MNO to cause the corresponding local SMSC to forward the message to the destination device responsive to the international A2P message satisfying the one or more rules of the local firewall.

18. The system of claim 11 , wherein forwarding the international A2P message includes forwarding the international A2P message to a local firewall of the local MNO and, responsive to the international A2P message satisfying the one or more rules of the local firewall, the local firewall configured to cause the corresponding local SMSC to forward the message to the destination device.

19. The system of claim 11, wherein the international A2P message is received from an A2P provider via an application programming interface (API).

20. The system of claim 11 , wherein the one or more processors are further configured to: detect that at least one of the forwarded international A2P messages satisfies an alert policy; and generate, for each of the forwarded international A2P messages that satisfy the alert policy, an alert for display in a user interface.