System and method for managing delivery reports in a messaging environment

Abstract

Disclosed herein is a system (200) and a method (500) for managing delivery reports in a messaging environment. The method comprises receiving, by a receiving module (220) from a messaging server (106), one or more delivery reports corresponding to one or more message submission requests initiated. The method further comprises determining, by a processing module (230) for each received delivery report among the one or more delivery reports, whether cache data corresponding to an associated message submission request is available in a cache storage. The method further comprises retrieving, by a processing module (230) upon the determination that the cache data is available, the cache data from the cache storage; and transmitting, by a transmitting module (240) based on the retrieved cache data, the one or more delivery reports to a user device.

Description

SYSTEM AND METHOD FOR MANAGING DELIVERY REPORTS IN A MESSAGING ENVIRONMENTTECHNICAL FIELD

[0001] The embodiments of the present disclosure generally relate to the field of communication networks and systems. More particularly, the present disclosure relates to a system and a method for managing delivery reports in a messaging environment.BACKGROUND OF THE INVENTION

[0002] The subject matter disclosed in the background section should not be assumed or construed to be prior art merely because of its mention in the background section. Similarly, any problem statement mentioned in the background section or its association with the subject matter of the background section should not be assumed or construed to have been previously recognized in the prior art.

[0003] In modem communication systems, an efficient and a reliable delivery of messages to a recipient is important. The systems, which include Short Message Service (SMS), email, and other data transmission protocols, often rely on a successful exchange of multiple messages or packets between various network entities to ensure that an intended content reaches to the recipient. One aspect of communication processes is a generation and handling of delivery reports, which serve as confirmations that a transmitted message has successfully reached the recipient.

[0004] The delivery reports are typically generated in response to a message submission request commonly referred to as a "submit request" or "submit sm request" in a context of SMS communication by a network infrastructure or a receiving device. The delivery reports provide a sender with important feedback, indicating whether a message was delivered, failed, or remains pending. Such delivery reports are crucial for applications and services that rely on guaranteedmessage delivery, such as financial transaction alerts, authentication codes, and emergency notifications.

[0005] However, in many existing communication systems, an issue arises when the delivery report is received before the corresponding submit request has been fully processed by a sending or an intermediate system. This sequence anomaly occurs due to various reasons, such as network latency, out-of-order processing of messages, or system faults. When this happens, the delivery report arrives without sufficient contextual information to correctly associate it with an original message request.

[0006] In particular, in the existing communication systems, when a submission response (submit sm resp) is received from a Distributed Ledger Technology (DLT) or messaging server, the submission response is typically delegated to a new processing thread for handling. At higher Transactions Per Second (TPS), this delegation leads to a thread delay problem, where the submit sm resp is not processed in time. As a result, the delivery report may be received before the submit sm resp has been processed, leaving the system without necessary correlation information to identify the associated submit sm request. This leads to a failure in delivering accurate delivery reports back to the user or application.

[0007] Thus, there exists a need for improved methods and systems that can effectively manage a timing and association of the delivery reports with the corresponding message submission requests, regardless of the communication medium, to overcome the aforementioned challenges of the existing communication systems.SUMMARY

[0008] The following embodiments present a simplified summary to provide a basic understanding of some aspects of the disclosed invention. This summary is not an extensive overview, and it is not intended to identify key / critical elements or todelineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0009] According to an aspect of the present disclosure, disclosed herein is a method for managing delivery reports in a messaging environment. The method comprises receiving, from a messaging server by a receiving module of an application server, one or more delivery reports corresponding to one or more message submission requests. The method further comprises determining, by a processing module of the application server, for each received delivery report among the one or more delivery reports, whether cache data corresponding to an associated message submission request is available in a cache storage. The method further comprises retrieving, by the processing module upon the determination that the cache data is available, the cache data from the cache storage and transmitting, by a transmitting module of the application server based on the retrieved cache data, the one or more delivery reports to the user device.

[0010] In one or more implementations, the cache data corresponding to the associated message submission request is generated by receiving, by the receiving module from the messaging server, one or more message submission responses corresponding to each message submission request among the one or more message submission requests from the user device and storing, by a storage module of the application server, the one or more message submission responses in a response queue. Further, the method comprises polling, by a processing module, the response queue at regular intervals using at least one processing thread and processing, by a processing module based on the polling, each message submission response among the one or more message submission responses to generate the cache data corresponding to message identifiers of a corresponding message submission request.

[0011] In one or more implementations, the method comprises deleting, by the processing module from the cache storage, the cache data corresponding to the oneor more message submission requests after the transmission of the one or more delivery reports.

[0012] In one or more implementations, the method comprises invalidating, by the processing module, the cache data in the cache storage based on a determination that the cache data is unused for a predefined time threshold.

[0013] In one or more implementations, the one or more message submission responses comprise unique message identifiers to correlate the one or more delivery reports with corresponding message submission requests.

[0014] In one or more implementations, the polling the response queue comprises checking the response queue at regular intervals to identify new message submission responses.

[0015] In one or more implementations, the cache data comprises at least one of unique message identifiers, information related to a message recipient and a timestamp of corresponding message submission request.

[0016] According to another aspect of the present disclosure, a system for managing delivery reports in a messaging environment is described. The system comprises an application server. The application server comprises a receiving module, a transmitting module, a storage module, and a processing module. The receiving module is configured to receive, by a receiving module from a messaging server, one or more delivery reports corresponding to one or more message submission requests. The processing module is configured to determine, for each received delivery report among the one or more delivery reports, whether cache data corresponding to an associated message submission request is available in a cache storage. The processing module is configured to retrieve, upon the determination that the cache data is available, the cache data from the cache storage. The transmitting module is configured to transmit, based on the retrieved cache data, the one or more delivery reports to a user device.

[0017] According to yet another aspect of the present disclosure, a computerprogram product for managing delivery reports in a messaging environment is provided. The computer-program product comprises computer-executable instructions that are stored on a non-transitory computer-readable medium and that, when executed by at least one processor performs operations. The operations include receiving, from a messaging server, one or more delivery reports corresponding to one or more message submission requests and determining, for each received delivery report among the one or more delivery reports, whether cache data corresponding to an associated message submission request is available in a cache storage. The operations further include retrieving, upon the determination that the cache data is available, the cache data from the cache storage and transmitting, based on the retrieved cache data, the one or more delivery reports to a user device.BRIEF DESCRIPTION OF DRAWINGS

[0018] Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. The accompanying drawings constitute a part of the present disclosure and illustrate certain non-limiting embodiments of inventive concepts. Further, components and elements shown in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. For consistency and ease of understanding, similar components and elements are annotated by reference numerals in the exemplary drawings.

[0019] FIG. 1 illustrates an exemplary messaging environment, in accordance with an embodiment of the present disclosure.

[0020] FIG. 2 illustrates a block diagram of a system for managing delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure.

[0021] FIG. 3 illustrates a flow diagram for processing message submission responses and delivery reports, in accordance with an embodiment of the present disclosure.

[0022] FIG. 4 illustrates a line diagram for managing the delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure.

[0023] FIG. 5 illustrates a flowchart depicting a method for managing the delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure.

[0024] FIG. 6 illustrates a schematic block diagram of a computing system for managing the delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION OF THE INVENTION

[0025] Inventive concepts of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Further, the one or more embodiments disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more components from one embodiment may be tacitly assumed to be present or used in any other embodiment.

[0026] The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure.

[0027] The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” or “some implementations” which may each refer to one or more or all of the same or different embodiments or implementations. The term “some” as used herein is defined as “one, or more than one, or all.” Accordingly, the terms “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in an embodiment” or “in an implementation” refers to one embodiment or one implementation and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments.” Further, the term, for example, “in one or more implementations” refers to “at least one implementation, or more than one implementation, or all implementations.

[0028] The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise stated with limiting language. Furthermore, to the extent that the terms “includes,” “has,” “have,” “contains,” and other similar words are used in either the detailed description, such terms are intended to be inclusive in a manner similar to the term “comprising.”

[0029] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features.

[0030] The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing anyof the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details.

[0031] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein the description, the singular forms "a", "an", and "the" include plural forms unless the context of the invention indicates otherwise.

[0032] The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the scope of the present disclosure. Accordingly, unless otherwise defined, all terms, and especially any technical and / or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

[0033] An object of the present disclosure is to provide a system and a method for managing a receipt and processing of delivery reports in a messaging environment, ensuring that each delivery report is correctly associated with corresponding message submission request.

[0034] Another object of the present disclosure is to provide a system and a method that facilitate a timely and an accurate transfer of the delivery reports to end users by using cached data.

[0035] Another object of the present disclosure is to provide a system and a method that uses a queue-based approach for processing message submission responses, thereby reducing delays caused by thread delegation.

[0036] Several key terms used in the description play pivotal roles in facilitating the system functionality. In order to facilitate an understanding of the description, the key terms are defined below.

[0037] Messaging server- The term messaging server may refer to a server configured to manage submission, routing, delivery, and the reporting of the messages. In one embodiment, the messaging server implements Short Message Peer-to-Peer (SMPP) protocol or an equivalent communication protocol.

[0038] Message submission request (may also be referred as “submit sm”)- The term message submission request (submit sm) may refer to the request initiated by an application or client (e.g., client application) towards the messaging server in the messaging environment. The message submission request generally contains message-related information such as, but not limited to, destination address (recipient identifier), source address (originator identifier), message content or protocol identifiers.

[0039] Message submission response (may also be referred as “submit_sm_resp”)- The term message submission response (or submit sm resp) may refer to an acknowledgment returned by the messaging server in response to the message submission request, typically containing identifiers such as a message ID and status information.

[0040] Delivery report - The term delivery report may refer to a status notification generated by the messaging server and transmitted to the application or the client, indicating whether a previously submitted message was successfully delivered, failed, expired, or remains pending.

[0041] Cache data- The term cache data may refer to intermediate data derived from message submission responses (submit sm resp), stored temporarily in memory or dual data storage, and is utilized to correlate incoming delivery reports with the corresponding message submission requests.

[0042] Dual data storage- The term dual data storage (may also be referred as “cache storage” interchangeably in the description) may refer to a storage architecture that stores delivery report correlation data ie, the cache data generated from the message submission responses stored in the response queue while simultaneously trackingthe cache data for expiration management. The storage architecture has a dual functionality i.e., providing reliable storage of the cache data and performing expiration management (invalidation of unused cache data periodically).

[0043] Response queue- The term response queue may refer to a memory structure or a processing queue in which incoming message submission responses (submit sm resp) are temporarily stored prior to polling and processing.

[0044] Fallback implementation-The term fallback implementation may refer to an alternative handling mechanism invoked when the cache data for the delivery report is unavailable in the dual data storage.

[0045] Invalidation- The term invalidation may refer to a removal or marking of the cache data as obsolete based on a comparison between a storage duration of the cache data and a predefined time threshold.

[0046] The present disclosure provides the system and the method for managing a delivery of the messages and corresponding delivery reports in high-throughput messaging environments utilizing a Short Message Peer-to-Peer (SMPP) protocol. The present disclosure addresses a common challenge in which the delivery reports received from a Short Message Peer-to-Peer (SMPP) server are not reliably matched with an original message submission request due to delays in processing the message submission responses under high Transactions Per Second (TPS) conditions. Specifically, the present disclosure improves upon traditional thread delegation methods by utilizing a queue-based system to temporarily store the message submission responses, thereby allowing matching of the delivery reports with the corresponding message submission requests.

[0047] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. FIG. 1 - FIG. 6, discussed below, and the one or more embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that theprinciples of the present disclosure may be implemented in any suitably arranged system or device.

[0048] FIG. 1 illustrates an exemplary messaging environment 100, in accordance with an embodiment of the present disclosure. The messaging environment 100 includes a client application 102, a communication network 104, a messaging server 106 and an application server 108. The client application 102 may be a messaging application operating on, or accessible via, a user device communicatively coupled with the communications network 104 and may include a Short Message Service (SMS) gateway functionality. The user device may correspond to a mobile device, a tablet, a desktop or laptop computer capable of running the client application 102. In some embodiments, a portion of link between the client application 102 and the messaging server 106 may be a leased line and / or the internet. The link may optionally include a Virtual Private Network (VPN) or other means of securing communication of data. The messaging server 106 may be a Short Message Peer-to-Peer (SMPP) server configured to store and deliver messages such as context-enriched SMS messages and the like.

[0049] The messaging server 106 acts as a gateway for receiving message submissions from the client application 102. The message may include a message header and a message body. In some embodiments, the contents of the message may be sent using multiple messages (e.g. concatenated SMS, multipart, segmented SMS and / or “Long SMS”) if the message is greater than an allowed size. It should be noted that in some embodiments, the messaging environment 100 may be modified to implement other transport protocols beyond the SMPP.

[0050] Once the message is submitted, the messaging server 106 responds with the message submission response indicating whether the message has been successfully received or failed. The messaging server 106 may also interfaces with downstream systems to handle the delivery reports. The application server 108 processes the message submission responses received from the messaging server 106. The application server is further responsible for managing the cache (not depicted inFIG. 1) to facilitate delivery report processing. Once the delivery report is generated, the application server 108 relays the report back to the client application or an end user.

[0051] In one or more embodiments, the application server 108 may operate as or be part of a Messaging-as-a- Service (MaaS) aggregator platform. The MaaS aggregator platform may refer to a cloud-based or hosted messaging infrastructure that may be implemented as the application, the application server, or a distributed infrastructure, that manages the message submission responses and relays the delivery reports.

[0052] FIG. 2 illustrates a block diagram of a system 200 for managing the delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure.

[0053] The system 200 may comprises the application server 108 (may also be referred as the server 108) which may include a processor 202, a memory 204, a communication interface 206, an Input-Output (I / O) interface 208 and an aggregator module 210. Each of the components of the server 108 is communicatively coupled to each other via a first communication bus 200-2.

[0054] The processor 202 may include various processing circuitry and communicate with the memory 204, and the communication interface 206 via the first communication bus 200-2. The processor 202 is configured to execute instructions or a set of instructions stored in the memory 204 to perform various processes. In an implementation, the processor 202 may also include the aggregator module 210. Components of the aggregator module 210 are coupled to each other via a second communication bus 200-4.

[0055] The processor 202 may include a general-purpose processor, such as, for example, and without limitation, a Central Processing Unit (CPU), an Application Processor (AP), a dedicated processor, a Graphics-only Processing Unit such as aGraphics Processing Unit (GPU) or the like, a programmable logic device, or any combination thereof.

[0056] The memory 204 stores the set of instructions required by the processor 202 of the server 108 for controlling its overall operations. The memory 204 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of Electrically Programmable Memories (EPROM) or Electrically Erasable and Programmable (EEPROM) memories. In addition, the memory 204 may, in some examples, be considered a non-transitory storage medium. The "non-transitory" storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted as the memory 204 is nonmovable. In some examples, the memory 204 may be configured to store larger amounts of information. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 204 may be an internal storage unit or an external storage unit of the server 108, cloud storage, or any other type of external storage.

[0057] The communication interface 206 may include an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 206 is configured for communicating with external devices via networks.

[0058] The I / O interface 208 may include suitable logic, circuitry, interfaces, and / or codes that may be configured to receive input(s) and present (or display) output(s) on the server 108. For example, the I / O interface 208 may have an input interface (not shown) and an output interface (not shown). The input interface may be configured to enable a user to provide input(s) to trigger (or configure) the server 108 for performing data processing operation(s). Examples of the input interface may include, but are not limited to, a touch interface, a mouse, a keyboard, a motion recognition unit, a gesture recognition unit, a voice recognition unit, or the like. Examples of the output interface may include, but are not limited to, a digital display, an analog display, a touch screen display, an appearance of a desktop, and / orilluminated characters. Aspects of the present disclosure are intended to include or otherwise cover any type of the input interface and output interface in the I / O interface 208, including known, related art, and / or later developed technologies without deviating from the scope of the present disclosure.

[0059] The aggregator module 210 may include a receiving module 220, a processing module 230, a transmitting module 240, and a storage module 250. The receiving module 220 is configured to receive one or more delivery reports corresponding to one or more message submission requests from the messaging server 106. The processing module 230 is configured to determine whether the cache data corresponding to the associated message submission request is available in the cache storage for each received delivery report among the one or more delivery reports. The processing module 230 is configured to retrieve the cache data from the cache storage upon the determination that the cache data is available in the cache storage. The transmitting module 240 is configured to transmit the one or more delivery reports to the user device based on the retrieved cache data.

[0060] The receiving module 220 is further configured to receive the one or more message submission responses corresponding to each message submission request among the one or more message submission requests from the user device. The storage module 250 is configured to store the one or more message submission responses in the response queue. The processing module 230 is further configured to poll the response queue at regular intervals using at least one processing thread and process, based on the polling, each message submission response among the one or more message submission responses to generate the cache data corresponding to the message identifiers of the corresponding message submission request.

[0061] The processing module 230 is further configured to delete, from the cache storage, the cache data corresponding to the one or more message submission requests after the transmission of the one or more delivery reports and invalidate the cache data in the dual data storage based on the determination that the cache data is unused for the predefined time threshold.

[0062] Although FIG. 2 illustrates one example of the system 200, various changes may be made to FIG. 2. Further, various components in FIG. 2 may be combined, further subdivided, or omitted, and additional components may be added according to particular needs.

[0063] FIG. 3 illustrates a flow diagram 300 for processing the message submission responses and the delivery reports, in accordance with an embodiment of the present disclosure.

[0064] At step 302, the submit_sm response is received from the messaging server 106 and is stored into the response queue. In one non-limiting example, a banking application submits a One-Time Password (OTP) message request to the messaging server 106. The messaging server 106 acknowledges the submit sm request by returning the submit sm resp including a unique message identifier. The submit sm response is captured by the receiving module 220 of the application server 108 and is temporarily stored in the response queue.

[0065] At step 304, the application server 108 may extract the submit sm response from the response queue and adds data corresponding to the submit sm response into the dual data storage. For instance, the message ID, destination Mobile Station International Subscriber Directory Number (MSISDN), and the timestamp may be stored as the cache data in the dual data storage for later correlation. Once the submit sm response is stored in the response queue, the processing module 230 may poll the response queue at regular intervals using the processing thread and process each submit sm response to generate the cache data corresponding to message identifiers of the corresponding message submission request. In an implementation, a separate thread is used which continuously polls the response queue.

[0066] At step 306, the delivery report corresponding to the earlier submitted message request is received from the messaging server 106. The delivery report indicates the delivery status of the message (e.g., delivered, failed, expired).

[0067] At step 308, the determination is made whether the cache data corresponding to the received delivery report is present in the dual data storage. In one non-limiting example, the delivery report may include the same message identifier returned in the submit sm response. The processing module 230 may query the dual data storage to check whether the message identifier is stored. In one embodiment, if the data is present in the dual data storage (Yes, then branch at step 308), the application server 108 may retrieve the cache data and relays the delivery report to the user (at step 312). For instance, if the OTP submitted earlier was successfully delivered to an end user’s handset, the delivery report is correlated with the cached data information and transmitted to the banking application for logging or user notification.

[0068] In another embodiment, if the data is not present in the cache, the process moves to step 310 where an alternate implementation is invoked to handle the missing data scenario.

[0069] At step 312, the delivery report is relayed to the end user, providing information about the delivery status of the original submit sm request, which ensures that the end user is promptly informed about the delivery status of the message.

[0070] FIG. 4 illustrates a line diagram 400 for managing the delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure.

[0071] At step 402, the client application 102 operating on the user device may initiate the message submission request (submit sm) towards the messaging server 106 through the application server 108. The submit sm request contains information about the message that needs to be sent to the recipient. For example, a ride application may initiate the message to notify a passenger that their cab has arrived.

[0072] At step 404, the messaging server 106 may respond with the submit sm resp, indicating acceptance of the message for processing and including the unique message identifier.

[0073] At step 406, the application server 108 may store the submit sm resp in the response queue and generates corresponding cache data. In one example, the cache data includes the message identifier, sender ID, recipient MSISDN, and submission timestamp. Further, storing in the response queue may ensure that the message submission responses are buffered and not lost due to processing delays. The response queue serves as a temporary storage structure, holding incoming responses until they are ready for further processing by the system.

[0074] At step 408, the messaging server 106 may send the delivery report corresponding to the submitted message. The delivery report provides the status (e.g., delivered, failed, pending) and is forwarded to the application server 108.

[0075] At step 410, the application server 108 may check whether the cache data corresponding to the delivery report is available. The processing module 230 in the application server 108 queries the dual data storage using the message identifier as the key. If the cache data is available, then at step 412 the application server 108 may transmit the delivery report, based on the cached data, to the client application. For example, the ride application backend may receive confirmation that message notification was successfully delivered to the passenger. If the cache data is not available, then at step 414 the application server 108 may attempt to retrieve the cache data after a short delay. As a result, even when the cache data is initially unavailable, the delayed retrieval allows the cache data to be refreshed from the response queue with minimal misses, thereby improving the accuracy of the delivery report correlation at higher TPS. Thus, by using queue-driven dual data storage, the application server 108 avoids the earlier problem of delegating the submit sm response processing to separate threads, which introduced latency at the higher TPS.

[0076] At step 416, the unused cache data is invalidated periodically by comparing the storage duration of the cache data against the predefined threshold. For example, cache data entries older than 24 hours that are not associated with any delivery report are invalidated from the storage to optimize memory utilization.

[0077] FIG. 5 illustrates a flowchart depicting a method 500 for managing the delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure. The method 500 comprises a series of operation steps indicated by steps 502 through 508. The method 500 starts at step 502.

[0078] The method 500 begins when the message submission request is sent from the end user to the messaging server 106. The request contains information about the message that needs to be sent to the recipient. The messaging server 106 may respond with the message submission response, which contains information such as the message ID or other metadata associated with the message submission request.

[0079] At step 502, the receiving module 220 is configured to receive from the messaging server 106, the one or more delivery reports corresponding to the one or more message submission requests. The delivery reports contain information regarding the status of submitted messages, such as whether the message has been successfully delivered to a recipient, is pending, or has failed. In one non-limiting example, the client application 102 (e.g., a mobile banking app) may initiate a transaction alert SMS. The messaging server 106 may deliver the SMS to the intended recipient and generates the delivery report.

[0080] At step 504, the processing module 230 is configured to determine, for each received delivery report among the one or more delivery reports, whether the cache data corresponding to the associated message submission request is available in the dual data storage. The dual data storage is the storage structure designed to store message submission responses (submit sm resp) along with related identifiers, timestamps, and the message metadata. The processing module 230 may query this dual data storage to check whether the message identifier in the delivery report matches the previously stored submission record.

[0081] At step 506, the processing module 230 is configured to retrieve, upon the determination that the cache data is available, the cache data from the dual data storage The retrieved cache data may include the original message identifier, recipient details, and the message metadata that can be correlated with the delivery report. In one non-limiting example, if the banking alert message had message ID “12345,” the processing module 230 may retrieve the cached entry for “12345” containing details such as the recipient MSISDN and the submission timestamp.

[0082] At step 508, the transmitting module 240 is configured to transmit, based on the retrieved cache data, the one or more delivery reports to the user device. This ensures that the delivery reports relayed to the client application 102 operating on the user device are correlated with the correct submission requests. For example, the banking application receives confirmation that the alert SMS for message ID “12345” was successfully delivered to the recipient. This confirmation is displayed to the bank’s backend monitoring system.

[0083] FIG. 6 illustrates a schematic block diagram of a computing system 600 for managing the delivery reports in the messaging environment, in accordance with an embodiment of the present disclosure.

[0084] The computing system 600 includes a network 610, a network interface 620, a processor 630, an Input / Output (I / O) interface 640 and a non-transitory computer readable storage medium 650 (hereinafter may also be referred to as the “storage medium 650” or the “storage media 650”).

[0085] The network interface 620 includes wireless network interfaces such as Bluetooth, Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA) or wired network interfaces such as Ethernet, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers-864 (IEEE-864).

[0086] The processor 630 may include various processing circuitry and communicate with the storage medium 650 and the I / O interface 540. The processor 630 is configured to execute instructions stored in the storage medium 650 and to perform various processes. The processor 630 may include an intelligent hardware device including a general-purpose processor, such as, for example, and without limitation, the CPU, the AP, the dedicated processor, or the like, the graphics-only processing unit such as the GPU, a microcontroller, a Field-Programmable Gate Array (FPGA), a programmable logic device, a discrete hardware component, or any combination thereof. The processor 630 may be configured to execute computer-readable instructions 652 stored in the storage medium 650 to cause the server 108 to perform various functions.

[0087] The storage medium 650 stores a set of instructions 652 required by the processor 630 for controlling its overall operations.

[0088] The storage media 650 may include an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, or the like. For example, the storage media 650 may include, but are not limited to, hard drives, floppy diskettes, optical disks, ROMs, RAMs, EPROMs, EEPROMs, flash memory, magnetic or optical cards, solid-state memory devices, or other types of physical media suitable for storing electronic instructions. In one or more implementations, the storage media 550 includes a Compact Disk-Read Only Memory (CD-ROM), a Compact Disk-Read / Write (CD-R / W), and / or a Digital Video Disc (DVD).

[0089] In one or more implementations, the storage medium 650 stores computer program code configured to cause the computing system 600 to perform at least a portion of the processes and / or methods. Accordingly, in at least one embodiment, the computing system 600 performs the method for managing the delivery reports in the messaging environment.

[0090] Now, referring to the technical abilities and advantageous effect of the present disclosure, operational advantages that may be provided by one or moreembodiments may include providing the system and the method that optimizes the processing of the message submission responses by utilizing separate threads for the queue polling, thereby reducing the processing delays and improving overall system efficiency. Further, by implementing the queue-based system for handling the message submission responses, the method significantly reduces a risk of mismatches between the delivery reports and the corresponding message submission requests, thus increasing a reliability of the communication system. Furthermore, the dual data collection ensures that necessary cache data for the delivery reports is accurately maintained and invalidated when no longer needed, thus preserving the integrity of the system's operation.

[0091] Additionally, the use of the cached data may enable the delivery reports to be managed without repeatedly querying the messaging server, thereby reducing server load and network congestion. By invalidating the unused cache data at regular intervals, memory and storage resources are conserved, improving the scalability of the system. The end users or the client applications receive accurate and timely delivery status updates, which is particularly beneficial for applications such as OTPs, banking alerts, and time-sensitive notifications.

[0092] Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present invention. The above-described embodiments are therefore to be construed in all aspects as illustrative and not restrictive.

[0093] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the mannerdescribed herein. Any combination of the above features and functionalities may be used in accordance with one or more embodiments.

[0094] In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary from embodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limited in scope.LIST OF REFERENCE NUMERALS

[0095] The following list is provided for convenience and in support of the drawing figures and as part of the text of the specification, which describe innovations by reference to multiple items. Items not listed here may nonetheless be part of a given embodiment. For better legibility of the text, a given reference number is recited near some, but not all, recitations of the referenced item in the text. The same reference number may be used with reference to different examples or different instances of a given item. The list of reference numerals is:100- Messaging environment102- Client application104- Communication network106- Messaging server108- Application server / server200- System202- Processor204- Memory206- Communication Interface208- Input / Output interface210- Aggregator module220- Receiving module230- Processing module240- Transmitting module250- Storage module200-2- First communication bus200-4- Second communication bus300- Flow diagram for processing message submission responses and delivery reports302-312- Steps to perform the flow diagram 300400- Line diagram for managing the delivery reports in the messaging environment402-416- Steps to perform the line diagram 400500- Flowchart depicting a method for managing the delivery reports in the messaging environment502-508- Steps to perform the method 500600- Computing System602- Network604- Network Interface606- Processor608- I / O interface610- Non transitory computer readable storage medium610-2- Instructions

Claims

We Claim:

1. A method (500) for managing delivery reports in a messaging environment, the method comprising: receiving, from a messaging server (106) by a receiving module (220) of an application server (108), one or more delivery reports corresponding to one or more message submission requests; determining, by a processing module (230) of the application server (108), for each received delivery report among the one or more delivery reports, whether cache data corresponding to an associated message submission request is available in a cache storage; retrieving, by the processing module (230) upon the determination that the cache data is available, the cache data from the cache storage; and transmitting, by a transmitting module (240) of the application server (108), based on the retrieved cache data, the one or more delivery reports to a user device.

2. The method (500) as claimed in claim 1, wherein the cache data corresponding to the associated message submission request is generated by: receiving, by the receiving module (220) from the messaging server (106), one or more message submission responses corresponding to each message submission request among the one or more message submission requests from the user device; storing, by a storage module (250) of the application server (108), the one or more message submission responses in a response queue; polling, by the processing module (230), the response queue at regular intervals using at least one processing thread; and processing, by the processing module (230) based on the polling, each message submission response among the one or more message submission responses to generate the cache data corresponding to message identifiers of a corresponding message submission request.

3. The method (500) as claimed in claim 1, comprising deleting, by the processing module (230) from the cache storage, the cache data corresponding to the one or more message submission requests after the transmission of the one or more delivery reports.

4. The method (500) as claimed in claim 1, comprising invalidating, by the processing module (230), the cache data in the cache storage based on a determination that the cache data is unused for a predefined time threshold.

5. The method (500) as claimed in claim 1, wherein one or more message submission responses comprise unique message identifiers to correlate the one or more delivery reports with corresponding message submission requests.

6. The method (500) as claimed in claim 2, wherein the polling the response queue comprises checking the response queue at regular intervals to identify new message submission responses.

7. The method (500) as claimed in claim 1, wherein the cache data comprises at least one of unique message identifiers, information related to a message recipient and a timestamp of corresponding message submission request.

8. A system (200) for managing delivery reports in a messaging environment, the system comprising an application server (108), the application server (108) comprising: a receiving module (220) configured to receive, from a messaging server (106), one or more delivery reports corresponding to one or more message submission requests; a processing module (230) configured to: determine, for each received delivery report among the one or more delivery reports, whether cache data corresponding to an associated message submission request is available in a cache storage; retrieve, upon the determination that the cache data is available, the cache data from the cache storage; anda transmitting module (240) configured to transmit, based on the retrieved cache data, the one or more delivery reports to a user device.

9. The system (200) as claimed in claim 8, wherein to generate the cache data corresponding to the associated message submission request: the receiving module (220) is configured to receive, from the messaging server (106), one or more message submission responses corresponding to each message submission request among the one or more message submission requests from the user device; a storage module (250) is configured to store the one or more message submission responses in a response queue; the processing module (230) is configured to: poll the response queue at regular intervals using at least one processing thread; and process, based on the polling, each message submission response among the one or more message submission responses to generate the cache data corresponding to message identifiers of a corresponding message submission request.

10. The system (200) as claimed in claim 8, wherein the processing module (230) is configured to delete, from the cache storage, the cache data corresponding to the one or more message submission requests after the transmission of the one or more delivery reports.

11. The system (200) as claimed in claim 8, wherein the processing module (230) is configured to invalidate the cache data in the cache storage based on a determination that the cache data is unused for a predefined time threshold.

12. The system (200) as claimed in claim 8, wherein one or more message submission responses comprise unique message identifiers to correlate the one or more delivery reports with corresponding message submission requests.

113. The system (200) as claimed in claim 9, wherein, to poll the response queue, the processing module (230) is configured to check the response queue at regular intervals to identify new message submission responses.

14. The system (200) as claimed in claim 8, wherein the cache data comprises at least one of unique message identifiers, information related to a message recipient and a timestamp of corresponding message submission request.

15. A computer program product comprising computer-executable instructions that are stored on a non-transitory computer-readable medium and that, when executed by at least one processor performs operations comprising: receiving, from a messaging server (106), one or more delivery reports corresponding to one or more message submission requests initiated by; determining, for each received delivery report among the one or more delivery reports, whether cache data corresponding to an associated message submission request is available in a cache storage; retrieving, upon the determination that the cache data is available, the cache data from the cache storage; and transmitting, based on the retrieved cache data, the one or more delivery reports to a user device.

Images