Method of reconciling orphan A2P messaging delivery receipts

A method of delivering an orphan delivery receipt for a mobile-terminated message to a messaging platform from which the mobile-terminated message originated. A network of data exchange connectors is deployed, wherein each data exchange connector is associated with a messaging platform. When one of the messaging platforms receives a delivery receipt it cannot reconcile, the delivery receipt is replicated to all data exchange connectors. The data exchange connector associated with the messaging platform from which the mobile-terminated message originated identifies and consumes the delivery receipt based on predefined filtering criteria. The data exchange connector publishes the delivery receipt to the originator messaging platform. The originator messaging platform correlates the delivery receipt with the mobile-terminated message and posts the delivery receipt to a corresponding enterprise customer.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to the field of telecommunication networks. More specifically, the invention pertains to a method of reconciling orphan Application-to-Person (A2P) messaging delivery receipts.

2. Brief Description of the Related Art

Application-to-Person (A2P) messaging systems commonly have multiple messaging platforms with redundant capabilities for message delivery. Each A2P messaging system normally has one account with one or more suppliers—i.e., Operator/Aggregator for Short Message Service (SMS) delivery. For example, SYNIVERSE A2P messaging system uses IMN and BARRACUDA messaging platforms, both of which need to deliver A2P messages through the same supplier. The A2P messaging system account with a supplier may have a ceiling on throughput and number of connections (binds). For every mobile-terminated message (MT) delivered via a particular supplier, one or more delivery receipts (DR) are generated, which subsequently must be relayed back to the content originator or enterprise customer that requested transmission of the A2P MT message.

From a supplier perspective, it may be difficult to distinguish between various A2P platforms because these A2P messaging platforms are connected on the same account. Because a supplier may not be able to distinguish between multiple A2P messaging platforms, the supplier may send a delivery receipt to an incorrect bind. For example, a delivery receipt for a MT-message sent from BARRACUDA messaging platform may arrive at IMN messaging platform, and vice-versa. In the A2P messaging industry, delivery receipts sent to an incorrect messaging platform are termed “orphan delivery receipts.” Messaging platforms in receipt of orphan delivery receipts cannot correctly process them because orphan delivery receipts do not correlate to an originating MT-message sent via their platform.

Thus, what is needed is an effective, scalable, low-latency method for reconciling orphan delivery receipts for successfully delivered A2P MT-messages.

SUMMARY OF THE INVENTION

In an embodiment, the invention pertains to a method of reconciling an orphan delivery receipt for an Application-to-Person (A2P) mobile-terminated message. A network of data exchange connectors is provided, wherein each data exchange connector is associated with a messaging platform. Multiple messaging platforms may be associated with a single messaging supplier—i.e., Short Message Service (SMS) operator or aggregator. Upon successful delivery of a mobile-terminated message, the supplier sends a corresponding delivery receipt to one of the messaging platforms associated with the supplier account.

Upon receiving the delivery receipt from the messaging supplier, the messaging platform in possession of the delivery receipt attempts to correlate the delivery receipt with a mobile-terminated message to which that delivery receipt pertains. If the messaging platform fails to correlate the delivery receipt with the mobile-terminated message, the messaging platform publishes this delivery receipt to a data exchange connector. The delivery receipt may be published to a predefined topic in a KAFKA cluster. The delivery receipt is then replicated to all data exchange connectors within the network.

The data exchange connector associated with the messaging platform from which the mobile-terminated message originated consumes the delivery receipt based on a set of predefined filtering criteria. Then, the data exchange connector publishes the delivery receipt to the corresponding messaging platform associated with the data exchange connector. The messaging platform correlates the delivery receipt with the corresponding mobile-terminated message and posts the delivery receipt to an enterprise customer that requested the messaging platform to send the mobile-terminated message.

In an embodiment of the invention, the data exchange connectors can be implemented as Java Virtual Machine (JVM) applications. The data exchange connectors may be built on top of a reactive streams or a container-native technology, such as AKKA or ALPAKKA KAFKA.

In an embodiment, each data exchange connector is communicatively coupled to a global configuration store, such that setting adjustments entered via the global configuration store automatically propagate to all data exchange connectors within the network in real-time.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Embodiments of the present invention pertain to a method of reconciling orphan A2P messaging delivery receipts.FIG. 1depicts an exemplary architecture of an embodiment of an invention, referred to herein as Orphan Delivery Receipt Exchange (ODRE) Network10.FIG. 1depicts a plurality of data exchange connectors12deployed at multiple data centers14, wherein each data center14is associated with a particular messaging platform. Data exchange connectors12may be deployed in multiple data centers14, which may be located within the same geographic region or across multiple geographic regions, for the same messaging platform and/or multiple platforms.

Data exchange connectors12are configured to import/export data streams. In an embodiment, data exchange connectors12are configured to consume (read) or publish (write) streams of events from and to external systems and applications so that these external system and application can integrate with a data streaming technology, such as APACHE KAFKA. More detailed explanation of data exchange connectors12and other terminology used herein is provided in APACHE KAFKA documentation, available at the following URL: https://kafka.apache.org/documentation, which is incorporated herein by reference.

Data exchange connectors12can be deployed across various geographic regions and messaging platforms. In an embodiment, each data exchange connector12can be a self-contained Java Virtual Machine (JVM) application and may be built on top of reactive streams and container-native technologies, such as AKKA STREAMS and ALPAKKA KAFKA. Data exchange connectors12can be deployed as horizontally scalable containers in each data center14and/or geographic region where an orphan delivery receipt exchange is needed.

FIG. 1further depicts a Global Configuration Store16. Data exchange connectors12are configured to maintain live connections to Global Configuration Store16. Global Configuration Store16is a highly available key-value data store. Global Configuration Store16can be replicated in multiple regions. Global Configuration Store16can be configured to contain configuration values for all data exchange connectors12across the entire fleet. In an embodiment, Global Configuration Store16can be managed via an Administrator Graphic User Interface (GUI)18, which may be hosted using a cloud service, such as AMAZON WEB SERVICES (AWS) DynamoDB, or on an on-premise solution, for example FoundationDB. Global Configuration Store16provides consistent reads and a low latency change feed.

Data exchange connectors12maintain live connections to the Global Configuration Store16and monitor Global Configuration Store16for changes. Each data exchange connector12is configured to detect configuration changes at Global Configuration Store16. Thus, when an administrator makes a configuration change via Administrator GUI18, configuration changes automatically propagate to the entire fleet of data exchange connectors12, in real-time. When needed, each data exchange connector12is configured to self-reload, thereby minimizing disruption to the service. In this manner, ORDE Network10provides a highly scalable publish/subscribe mesh on top of KAFKA, which enables exchanging orphan delivery receipts with the highest possible aggregated throughput (hundreds of thousands of TPS), while maintaining low latency.

FIG. 2depicts an exemplary signalling flow diagram for reconciling orphan delivery receipts according to an embodiment of the invention. InFIG. 2, Messaging Platform20and Messaging Platform22are two distinct messaging platforms connected to a common messaging Supplier24. Because Messaging Platform20and Messaging Platform22are connected to a common messaging Supplier24, they need to share connections (binds) associated with Supplier24. From a perspective of Supplier24, there is no distinction between Messaging Platforms20and22because they are connected on the same A2P messaging system account. This means that, upon successful delivery of an A2P MT-message, Supplier24may send the delivery receipt to any of the binds, rather than to the bind associated with the specific messaging platform from which the A2P MT-message originated. Thus, a delivery receipt for a MT-message sent from Messaging Platform20may arrive at Messaging Platform22and vice-versa.

A delivery receipts that arrives to a messaging platform that did not originate the MT-message is termed an “orphan delivery receipt” because such delivery receipt cannot be reconciled by the receiving messaging platform. For example, Messaging Platform20cannot reconcile a delivery receipt for a MT-message that originated from Messaging Platform22, and Messaging Platform22cannot reconcile a delivery receipt for an MT-message that originated from Messaging Platform20. Thus, when Supplier24sends a delivery receipt to a wrong messaging platform, the messaging platform in possession of the delivery receipt cannot reconcile it with the MT-message to which it pertains. This problem is resolved by the present invention, as explained in more detail below.

FIG. 2depicts that, in step102, Enterprise Customer26requests Messaging Platform20to send an A2P MT-message to a target recipient. In step104, Messaging Platform20transmits the MT-message to messaging Supplier24. In step106, Supplier24delivers the MT-message to the target recipient. Upon successful delivery of the MT-message message to its target recipient, Supplier24provides a delivery receipt to Messaging Platform22in step108.

In this example, the MT-message originated from Messaging Platform20, and, therefore, the delivery receipt can only be processed by Messaging Platform20. Thus,FIG. 2depicts that, in step110, Messaging Platform22fails to correlate the delivery receipt with the corresponding MT-message because the MT-message associated with the delivery receipt did not originate from Messaging Platform22. At this point, the delivery receipt is considered an “orphan.” Every massaging platform upon receipt of a delivery receipt attempts to find a record of a corresponding MT-message. If the correlation fails, such delivery receipt is published to a specific topic in a Kafka cluster. ODRE Network10picks up such orphan delivery receipts and delivers them to Kafka topics where data exchange connectors12from other messaging platform are listening.

In step112, Messaging Platform22uses its co-located exchange network connector12to publish the orphan delivery receipt to ODRE Network10. Next, in step114, ORDE Network10replicates the orphan delivery receipt to all data exchange connectors12. In step116, data exchange connector12associated with Messaging Platform20identifies the orphan delivery receipt based on predefined filtering criteria and consumes that orphan delivery receipt. In step118, data exchange connector12associated with Messaging Platform20publishes the orphan delivery receipt to Messaging Platform20in the native format (file-queue or topic).

In step120, Messaging Platform20—which is the messaging platform that originated the MT-message associated with the orphan delivery receipt—successfully correlates the orphan delivery receipt with the corresponding record of an outgoing MT-message. At this point, the delivery receipt is no longer an orphan. After reconciling the delivery receipt, Messaging Platform20posts the delivery receipt to Enterprise Customer26in step122, thereby enabling the Messaging Platform20to collect the fee associated with successfully sending the MT-message and providing a confirmation to Enterprise Customer26that the MT-message was successfully delivered to its target recipient.

FIG. 3depicts a flowchart illustrating an embodiment of the invention. In step202, Enterprise Customer26requests Messaging Platform20to send an A2P MT-message to the target recipient. In step204, Messaging Platform20sends the A2P MT-message to the target recipient via a messaging Supplier24. In step206, Supplier24delivers the MT-message to the target recipient and generates a delivery receipt. In this example, multiple messaging platforms share binds and use the same messaging Supplier24for sending A2P MT-messages. Thus, as explained above, Supplier24may be unable to correctly determine the messaging platform from which the MT-message originated.

In step208, Supplier24submits the delivery receipt for the delivered MT-message to one of the messaging platforms associated with Supplier24. If Supplier24submits the delivery receipt to Messaging Platform20, then in step210, Messaging Platform20will confirm that it was the originator of the MT-message and will proceed to step212, in which Messaging Platform20will reconcile the delivery receipt with the corresponding MT-message. Finally, in step214, Messaging Platform20will post the delivery receipt to Enterprise Customer26.

On the other hand, if it is determined in step210that Supplier24submitted the delivery receipt to Messaging Platform22, which did not originate the MT-message, the method will proceed to step216. In step216, Messaging Platform22will use its corresponding data exchange connector12to publish the delivery receipt to ORDE Network10. In step218, the delivery receipt will be replicated to all instances of data exchange connectors12. Then in step220, data exchange connector12associated with Messaging Platform20will consume the delivery receipt based on a set if predefined filtering criteria. In step222, data exchange connector12will publish the delivery receipt to Messaging Platform20in its native format. At this point, Messaging Platform20, from which the MT-message was sent, is now in possession of the corresponding delivery receipt confirming successful delivery of the MT-message to its target recipient. Next, the method proceeds to step212, in which Messaging Platform20will reconcile the delivery receipt with the MT-message. Finally, in step214, Messaging Platform20will post the delivery receipt to Enterprise Customer26.

Hardware and Software Infrastructure Examples

The various techniques described herein can be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and system described herein, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as hard drives, solid state drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computing device, the machine becomes an apparatus for practicing the invention. In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations.

The invention can also be practiced via communications embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, or the like, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to invoke the functionality of the invention. Additionally, any storage techniques used in connection with the invention can be a combination of hardware and software.

The advantages set forth above, and those made apparent from the foregoing disclosure, are efficiently attained. Since certain changes may be made in the above construction without departing from the scope of the invention, it is intended that all matters contained in the foregoing disclosure or shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.