FORM 2
THE PATENTS ACT, 1970 (39 OF 1970) & THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR SYNCHRONIZING ACCOUNT INFORMATION BETWEEN PRIMARY SITE AND DISASTER
RECOVERY SITE”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

METHOD AND SYSTEM FOR SYNCHRONIZING ACCOUNT INFORMATION BETWEEN PRIMARY SITE AND DISASTER
RECOVERY SITE
FIELD OF INVENTION
[0001] The present disclosure relates generally to the field of wireless communication systems. More particularly, the present disclosure relates to systems and methods for synchronisation of account information between primary site and disaster recovery (DR) site.
BACKGROUND
[0002] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0003] Wireless communication technology has rapidly evolved over the past few decades, with each generation bringing significant improvements and advancements. The first generation of wireless communication technology was based on analog technology and offered only voice services. However, with the advent of the second-generation (2G) technology, digital communication and data services became possible, and text messaging was introduced. 3G technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth-generation (4G) technology revolutionized wireless communication with faster data speeds, better network coverage, and improved security. Currently, the fifth-generation (5G) technology is being

deployed, promising even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users.
[0004] In the current existing solutions, synchronizing account information data adds complexity to the overall system architecture. It requires implementing mechanisms to replicate and keep data consistent between two separate systems (primary and DR sites) and ensuring their consistent state requires additional operational overhead, increasing the complexity of system management. This complexity can make the system more challenging to design, deploy, and maintain. It may also introduce additional points of failure and increase the risk of data inconsistencies or synchronization errors. Also, the existing process of synchronizing account information data between primary and DR sites introduces additional latency. The time it takes to replicate data and ensure consistency can impact system performance, especially for real-time applications or time-sensitive operations. The latency introduced by synchronization can result in delays and reduced responsiveness, affecting the overall user experience. Further, for existing techniques synchronization processes are not immune to errors or failures. In scenarios where data corruption occurs at the primary site, the corrupted data can potentially be replicated at the DR sites, rendering the failover ineffective. Further, primary and DR sites require additional network bandwidth and computational resources. The continuous synchronization of data can consume significant resources, impacting the performance and scalability of the system. Organizations need to allocate sufficient resources to support the synchronization process effectively, ensuring that it does not degrade the overall system performance. Further, the existing solution, synchronization of account information data relies on stable and reliable network connectivity between primary and redundant sites. If the network connection experiences disruptions or failures, synchronization may be delayed or disrupted, impacting the failover capabilities. Organizations must have

robust networking infrastructure and backup measures in place to ensure continuous synchronization even in the event of network issues.
[0005] Therefore, considering the foregoing discussion, there exists a need to overcome the aforementioned drawbacks. Thus, there exists an imperative need in the art to provide a method and system for synchronisation of account information between primary site and disaster recovery (DR) site.
OBJECTS OF THE INVENTION
[0006] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.
[0007] It is an object of the present disclosure to provide system and method for synchronizing account information between a primary site and a disaster recovery (DR) site.
[0008] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that automates the process of updating account modifications, thereby reducing manual intervention and the risk of human errors.
[0009] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that ensures real-time or near-real-time synchronization, enabling swift response to operational requirements or customer needs.
[0010] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster

recovery (DR) site that enhances the reliability of the service by minimizing service disruptions during the failover process from the primary site to the DR site.
[0011] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that simplifies the management of the system by automating the synchronization process, thereby reducing operational overhead and complexity.
[0012] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that supports a seamless failover process by ensuring that the DR site has up-to-date account information, thus maintaining service availability and reliability during primary site outages.
[0013] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that facilitates efficient handling of SMS service account modifications in an IP Multimedia Subsystem (IMS) network, thereby ensuring the integrity and consistency of the service.
[0014] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that utilizes a communication channel for transmitting account modification data, thereby enabling secure and reliable data transfer between the two sites.
[0015] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that employs a synchronization application to monitor and

process account modification requests, thereby ensuring efficient and accurate synchronization of account information.
SUMMARY OF THE DISCLOSURE
[0016] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0017] An aspect of the present disclosure relates to a method for synchronizing account information between a primary site and a disaster recovery (DR) site. The method includes receiving, by a receiving unit via a Front-End module of the primary site, an account modification request from an originating management system. Further, the method includes, storing, by a storage unit, a set of data associated with the received account modification request into a first database. The method further encompasses, continuously monitoring, by a processor using a primary site synchronization application, the first database for the set of data to process the account modification request. The method further includes, transmitting, by a transmitting unit, the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel. The method further encompasses storing, by the storage unit via the DR site synchronization application, the set of data associated with the account modification request into a second database for processing and synchronization at the DR site.
[0018] In an aspect of the present disclosure, the method further includes acknowledging, by the processor, the account modification request by sending a success response to the originating management system.

[0019] In an aspect of the present disclosure, the account modification request includes at least one of addition of a new account or deletion of an existing account.
[0020] In an aspect of the present disclosure, the originating management system includes but is not limited to a group consisting of an Element Management System (EMS), a Network Management System (NMS), a Command Line Interface (CLI), a web interface, and an Application Programming Interface (API).
[0021] In an aspect of the present disclosure, the account modification request is stored into the first database along with a zone name identifier.
[0022] In an aspect of the present disclosure, the DR site synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.
[0023] In an aspect of the present disclosure, the method further includes processing, by the processor, the account modification request data by an Application to Peer- IP short message gateway (A2P-IPSMGW) module at the primary site upon the set of data associated with the account modification request is stored into the first database.
[0024] In an aspect of the present disclosure includes processing, by the processor, the account modification request data by an A2P-IPSMGW module at the DR site upon the set of data associated with the account modification request is stored into the second database.
[0025] In an aspect of the present disclosure, the account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.

[0026] In an aspect of the present disclosure, the originating management system communicates with the front-end module via a RESTful interface.
[0027] Another aspect of the present disclosure relates to a system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network. The system includes a receiving unit configured to receive, via a front-end module at the primary site, an account modification request from an originating management system. The system further includes a storage unit, configured to store a set of data associated with the received account modification request into a first database. Furthermore, the system includes a processor, configured to continuously monitor, using a primary site sync application, the first database for the set of data to process the account modification request. The system further includes a transmitting unit, configured to transmit the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel. Further, the system includes a storage unit, configured to store, via the DR site synchronization application, the set of data associated with the account modification request into a second database for processing and synchronization at the DR site.
[0028] Yet another aspect of the present disclosure relates to a non-transitory computer-readable storage medium storing instructions for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network. The instructions include an executable code which when executed by a processor, may cause the processor to receive an account modification request from an originating management system; store a set of data associated with the received account modification request into a first database; continuously monitor the first database for the set of data to process the account modification request; transmit the set of data associated with the account modification request from the primary site synchronization application to a DR site

synchronization application via a communication channel; and store the set of data associated with the account modification request into a second database for processing and synchronization at the DR site.
5 BRIEF DESCRIPTION OF DRAWINGS
[0029] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the
10 different drawings. Components in the drawings are not necessarily to scale,
emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of
15 electrical components, electronic components or circuitry commonly used to
implement such components.
[0030] FIG. 1 illustrates an exemplary architecture for implementing of a system
for synchronizing account information between a primary site and a disaster
20 recovery (DR) site in a communication network, in accordance with exemplary
embodiments of the present disclosure.
[0031] FIG. 2 illustrates a block diagram of the system for synchronizing account
information between a primary site and a disaster recovery (DR) site in a
25 communication network, in accordance with exemplary embodiments of the present
disclosure.
[0032] FIG. 3 illustrates an exemplary sequence diagram for synchronizing account
information between a primary site and a disaster recovery (DR) site, in accordance
30 with exemplary embodiments of the present disclosure.
9

[0033] FIG. 4 illustrates an exemplary method flow chart for synchronizing account information between a primary site and a disaster recovery (DR) site, in accordance with exemplary embodiments of the present disclosure. 5
[0034] FIG. 5 illustrates an exemplary block diagram of a computing device upon which an embodiment of the present disclosure may be implemented, in accordance with exemplary embodiments of the present disclosure.
10 [0035] The foregoing shall be more apparent from the following more detailed
description of the disclosure.
DESCRIPTION
15 [0036] 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
20 another or with any combination of other features. An individual feature may not
address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in
25 which like reference numerals refer to the same parts throughout the different
drawings.
[0037] The ensuing description provides exemplary embodiments only, and is not
intended to limit the scope, applicability, or configuration of the disclosure. Rather,
30 the ensuing description of the exemplary embodiments will provide those skilled in
10

the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth. 5
[0038] It should be noted that the terms "mobile device", "user equipment", "user device", “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or
10 limitations on the described embodiments. The use of these terms is solely for
convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
15
[0039] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other
20 components may be shown as components in block diagram form in order not to
obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
25 [0040] Also, it is noted that individual embodiments may be described as a process
which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process
11

is terminated when its operations are completed but could have additional steps not included in a figure.
[0041] The word “exemplary” and/or “demonstrative” is used herein to mean
5 serving as an example, instance, or illustration. For the avoidance of doubt, the
subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques
10 known to those of ordinary skill in the art. Furthermore, to the extent that the terms
“includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
15
[0042] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing
20 function/s, communicating with other user devices and transmitting data to the
other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low
25 Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For
instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in
30 the art for implementation of the features of the present disclosure.
12

[0043] Further, the user device may also comprise a “processor” or “processing
unit” includes processing unit, wherein processor refers to any logic circuitry for
processing instructions. The processor may be a general-purpose processor, a
5 special purpose processor, a conventional processor, a digital signal processor, a
plurality of microprocessors, one or more microprocessors in association with a
DSP core, a controller, a microcontroller, Application Specific Integrated Circuits,
Field Programmable Gate Array circuits, any other type of integrated circuits, etc.
The processor may perform signal coding data processing, input/output processing,
10 and/or any other functionality that enables the working of the system according to
the present disclosure. More specifically, the processor is a hardware processor.
[0044] IP Short Message Gateway (IPSMGW) plays a crucial role in modern communication networks by enabling the seamless exchange of short messages
15 over IP protocols. Unlike traditional SMS gateways that rely on circuit-switched
networks, IPSMGW leverages the flexibility and efficiency of IP-based communication. By converting Short Message Service (SMS) into IP packets, IPSMGW facilitates the transmission of text messages over the internet or private IP networks. This technology not only enhances the speed and reliability of message
20 delivery but also opens up opportunities for innovative messaging applications and
services.
[0045] One of the key advantages of IPSMGW is its ability to bridge the gap between different types of networks. It acts as a bridge between the circuit-switched
25 SMS networks and IP networks, ensuring interoperability between legacy systems
and modern IP-based communication platforms. This seamless integration is essential for global communication, allowing users on various networks and devices to exchange messages effortlessly. IPSMGW serves as a vital component in enabling cross-network messaging services, enhancing connectivity and
30 communication experiences for users worldwide. Furthermore, IPSMGW enhances
13

the security and privacy of SMS messages transmitted over IP networks. By
employing encryption techniques and secure protocols, IPSMGW ensures that
sensitive information remains protected during transmission. This heightened
security is crucial, especially in business and enterprise communication, where
5 confidentiality is paramount. IPSMGW's ability to provide a secure channel for
SMS messages contributes to the overall integrity of communication networks, instilling confidence in users regarding the confidentiality and privacy of their messages.
10 [0046] As discussed in background section, in the current existing solutions,
synchronizing account information data adds complexity to the overall system architecture. It requires implementing mechanisms to replicate and keep data consistent between two separate systems (primary and DR sites) and ensuring their consistent state requires additional operational overhead, increasing the complexity
15 of system management. This complexity can make the system more challenging to
design, deploy, and maintain. It may also introduce additional points of failure and increase the risk of data inconsistencies or synchronization errors. Also, the existing process of synchronizing account information data between primary and DR sites introduces additional latency. The time it takes to replicate data and ensure
20 consistency can impact system performance, especially for real-time applications
or time-sensitive operations. The latency introduced by synchronization can result in delays and reduced responsiveness, affecting the overall user experience. Further, for existing techniques synchronization processes are not immune to errors or failures. In scenarios where data corruption occurs at the primary site, the corrupted
25 data can potentially be replicated at the DR sites, rendering the failover ineffective.
Further, primary and DR sites require additional network bandwidth and computational resources. The continuous synchronization of data can consume significant resources, impacting the performance and scalability of the system. Organizations need to allocate sufficient resources to support the synchronization
30 process effectively, ensuring that it does not degrade the overall system
14

performance. Further, the existing solution, synchronization of account information
data relies on stable and reliable network connectivity between primary and
redundant sites. If the network connection experiences disruptions or failures,
synchronization may be delayed or disrupted, impacting the failover capabilities.
5 Organizations must have robust networking infrastructure and backup measures in
place to ensure continuous synchronization even in the event of network issues.
[0047] To overcome these and other inherent problems in the art, the present disclosure proposes a solution of automating the synchronization process between
10 a primary site and a disaster recovery (DR) site in a communication network. The
proposed method and system streamline the process of updating account information, such as adding a new account or deleting an existing account, by automatically replicating changes from the primary site to the DR site. This automation reduces the complexity of the overall system architecture, as it
15 eliminates the need for manual intervention and the associated operational
overhead. Furthermore, the present disclosure addresses the issue of latency in synchronization by continuously monitoring the primary site's database for changes and promptly transmitting the relevant data to the DR site. This real-time or near-real-time synchronization ensures that the DR site is always up-to-date, minimizing
20 delays and improving the responsiveness of the system during failover scenarios.
To overcome the problem of potential data corruption and synchronization errors, the proposed solution includes a mechanism for acknowledging successful data transmission. The DR synchronization application sends an acknowledgment response upon successfully receiving the account modification request data,
25 ensuring the integrity of the data replicated at the DR site. Regarding resource
consumption, the present disclosure introduces an efficient synchronization mechanism that reduces the need for excessive network bandwidth and computational resources. By optimizing the data transmission process and employing a selective synchronization approach, the system ensures that only
30 necessary data is replicated, thereby minimizing the impact on system performance
15

and scalability. Lastly, the solution addresses the issue of network dependency by
employing a robust communication channel for data transmission. The use of a
reliable communication channel, such as an HTTP2 channel, ensures that
synchronization can continue even in the face of network disruptions, enhancing
5 the failover capabilities of the system.
[0048] It would be appreciated by the person skilled in the art that the present
disclosure offers a comprehensive solution to the problems identified in the existing
art by automating and optimizing the synchronization process between primary and
10 DR sites, thereby improving system reliability, performance, and resilience.
[0049] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
15 [0050] FIG. 1 illustrates an exemplary architecture [100] for implementing of a
system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, in accordance with exemplary implementations of the present disclosure. The architecture [100] comprises A2P-IPSMGW [102] comprising an Element Management System (EMS) [104], a
20 Signalling Transfer Point (STP) [106], a Diameter Routing Agent (DRA) [108], a
Home Subscriber Server (HSS) [110], a database 1 [112], a database 2 [114], a Mobile Number Portability Database (MNPDB) [116], and an internal short messaging entity (Internal ESMEs) [118]. Also, all of the components/ units of the architecture [100] are assumed to be connected to each other unless otherwise
25 indicated below.
[0051] A2P-IPSMGW (Application to Peer IP Short Message gateway) [102]:
Unlike traditional SMS gateways that rely on circuit-switched networks, IPSMGW
leverages the flexibility and efficiency of IP-based communication. By converting
30 Short Message Service (SMS) into IP packets, IPSMGW facilitates the transmission
16

of text messages over the internet or private IP networks. This technology not only
enhances the speed and reliability of message delivery but also opens up
opportunities for innovative messaging applications and services. A2P -IPSMGW
is a term used to describe an SMS message sent from a software application (run
5 by an enterprise or business) to a person's phone.
[0052] EMS (Element Management System) [104]: A software system used for managing and monitoring network elements or devices within a telecommunications network. 10
[0053] STP (Signalling Transfer Point) [106]: A network node used in the SS7 (Signalling System No. 7) telecommunications protocol to route signalling messages between signalling endpoints.
15 [0054] DRA (Diameter Routing Agent) [108]: A network element responsible for
routing Diameter protocol messages within telecommunications networks, often used in IMS and LTE networks.
[0055] HSS (Home Subscriber Server) [110]: A core component in LTE and IMS
20 networks that stores subscriber-related information, such as user profiles,
authentication data, and service subscriptions.
[0056] Database 1 [112]: A database such as but not limited to Cassandra database, manages large amounts of data across servers.
25
[0057] Database 2 [114]: A database that streams data, such as but not limited to Redis, is a data structure that, among other functions, can effectively manage data consumption, persist data when consumers are offline with a data fail-safe, and create a data channel between many producers and consumers.
30
17

[0058] MNP DB (Mobile Number Portability Database) [116]: A database service that allows mobile phone users to retain their phone numbers when switching between different service providers.
5 [0059] Internal External Short Messaging Entity (ESME) [118]: An external
application that connects to a Short Message Service Centre (SMSC) to engage in the sending or receiving of SMS messages.
[0060] SMPP (Short Message Peer-to-Peer): A protocol used in the
10 telecommunications industry for exchanging SMS messages between Short
Message Service Centres (SMSCs) and SMS application systems.
[0061] REST (Representational State Transfer): An architectural style for designing networked applications, commonly used in web services development.
15
[0062] SIP (Session Initiation Protocol): SIP is a signalling protocol used for initiating, maintaining, and terminating real-time sessions in IP-based communication networks. It is commonly used for voice and video calls, instant messaging, and multimedia conferencing over the Internet. SIP allows devices to
20 establish communication sessions and negotiate the parameters of the session, such
as codecs, media types, and session duration.
[0063] Referring to FIG. 2, an exemplary block diagram of a system [200] is shown, in accordance with the exemplary embodiments of the present invention. The
25 system [200] comprises at least one receiving unit [202], at least one storage unit
[204], at least one first database [206], at least one processor [208], at least one transmitting unit [210] and at least one second database [212]. Also, all of the components/ units of the system [200] are assumed to be connected to each other unless otherwise indicated below. Also, in FIG. 2 only a few units are shown,
30 however, the system [200] may comprise multiple such units or the system [200]
18

may comprise any such numbers of said units, as required to implement the features
of the present disclosure. Further, in an implementation, the system [200] may be
present in a user device to implement the features of the present invention. The
system [200] may be a part of the server device / or may be independent of but in
5 communication with the server device. In another implementation, the system [200]
may be a part of the exemplary system architecture as shown in FIG. 1, in
accordance with exemplary embodiments of the present disclosure. In another
implementation, the system [200] may be a part of the exemplary sequence diagram
for synchronizing account information between a primary site and a disaster
10 recovery (DR) site as shown is FIG. 3. Therefore, description of FIG. 2 and
description of FIG. 3 compliments each other and should be read together.
[0064] The system [200] for synchronization of account information between the primary site and disaster recovery (DR) site comprises a receiving unit [202]. The
15 receiving unit [202] is configured to receive, via a front-end module [304] at the
primary site, an account modification request from an originating management system. In an exemplary aspect, Application to Peer IP Short Message gateway (A2P-IPSMGW) and Short Message Service Centre (SMSC) are integrated to form an integrated unit, and in the integrated unit the SMSC acts as a front-end module
20 [304] to receive message or account info from EMS over MAP interface. In an
exemplary aspect, element management system (EMS) acts like a user interface (UI) to receive account information, add account information, update account information from external short messaging entity (ESME). In an exemplary aspect, the front-end module [304] is configured to receive a command from command line
25 interface (CLI) for account info/update/add.
[0065] The account modification request could involve actions such as the addition
of a new account or the deletion of an existing account within the communication
network. The originating management system from which the account modification
30 request is received may include systems such as an Element Management System
19

(EMS), a Network Management System (NMS), a Command Line Interface (CLI),
a web interface, or an Application Programming Interface (API). The receiving unit
[202] serves as the initial entry point for the request and is responsible for triggering
a series of processes that will ensure the account modification is reflected not only
5 at the primary site but also synchronized with the DR site to maintain consistency
across the network's operational databases.
[0066] The storage unit [204] is communicatively coupled to the receiving unit [202]. The storage unit [204] is configured to store a set of data associated with the
10 received account modification request into a first database [206] such as but not
limited to Redis stream. Upon receiving an account modification request, the storage unit [204] captures and secures all the relevant data pertaining to this request, including any details necessary for the modification of the account such as the account number, user information, and the specific changes to be implemented.
15 The first database [206], which could be a system like Redis Stream, is then used
as a repository for the data.
[0067] The processor [208] is communicatively coupled to the storage unit [204]. The processor [208] is configured to continuously monitor, using a primary site
20 sync application, the first database [206], for the set of data to process the account
modification request. In an exemplary aspect, sync applications are present in their respective A2P-IPSMGW. The sync applications communicate between each other to keep the respective A2P IPSMGW updated. As soon as a new account modification request is stored in the first database [206], the processor [208],
25 through the primary site sync application, initiates the synchronization procedure.
This involves preparing the data for transmission to the disaster recovery (DR) site to ensure that both the primary and DR sites maintain up-to-date and consistent account information.
20

[0068] The transmitting unit [210] is communicatively coupled to the processor
[208]. The transmitting unit [210] is configured to transmit the set of data associated
with the account modification request from the primary site synchronization
application to a DR site synchronization application via a communication channel.
5 The transmitting unit [210] serves as the bridge for secure data transfer, ensuring
that the modifications made at the primary site are accurately and promptly reflected
at the DR site. The use of a communication channel in this process is designed to
guarantee a reliable and efficient exchange of data, which is critical for the integrity
and availability of account information, especially during failover scenarios when
10 the DR site is required to take over operations seamlessly. The DR site
synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.
[0069] A communication channel refers to a medium used for the transmission of
15 information from one point to another. This can encompass a variety of physical
and logical pathways that facilitate data exchange, that include but not limited only to copper wires and Fiber optic cables to wireless connections like Wi-Fi or satellite links. The communication channel is further defined by its ability to carry signals, which can be in the form of electrical voltages, radio waves, or light pulses,
20 depending on the technology in use. These signals represent the information being
communicated, which can include voice, video, text, or other types of data. The choice of a communication channel is influenced by factors such as the volume of data to be transferred, the speed at which the transfer must occur, the required reliability, and the distance over which the communication must happen.
25
[0070] Communication channels can be simple, involving direct and point-to-point connections, or highly complex, incorporating numerous interconnected networks and nodes that allow for the global exchange of data. In digital networks, the term also applies to logical channels created through software, which can route data over
30 various physical mediums and across different network layers. The nature of the
21

communication channel can vary; it might be a network connection using standard
internet protocols such as TCP/IP, which are foundational for both internal and
external network communications. In scenarios where web services are involved,
HTTP or HTTP2 protocols are often utilized due to their stateless nature and
5 efficiency, particularly when the system employs RESTful APIs for interactions.
[0071] The storage unit [204] is further configured to store, via the DR site synchronization application, the set of data associated with the account modification request into a second database [212] for processing and
10 synchronization at the DR site. The DR site synchronization application facilitates
in managing the data transfer and storage process, ensuring that the data received is accurately stored in the second database [212] thus, the DR site have an up-to-date copy of the account information, ready to be used in case the primary site becomes unavailable. The synchronization process is designed to be seamless, with the
15 storage unit [204] at the DR site automatically updating its database (such as the
second database [212]) whenever changes are made at the primary site, thereby ensuring continuous synchronization and data integrity.
[0072] Further, the storage unit [204] is configured to store the received account
20 modification request data and a zone name associated with the request into a first
database [206]. In a preferred implementation, the first database [206] is a Redis database.
[0073] The processor [208] is further configured to process the account
25 modification request data by an application to peer - IP short message gateway
(A2P-IPSMGW) module at the primary site upon the set of data associated with the
account modification request is stored into the first database [206]. Once the
account modification request data is securely stored in the first database [206]. The
A2P-IPSMGW [102] facilitates in handling the SMS service-related decisions and
30 operations within the IP Multimedia Subsystem (IMS) network at the primary site.
22

The processing by the A2P-IPSMGW module ensures that the account
modifications are accurately reflected in the system, maintaining the integrity and
up-to-datedness of the account information within the primary site's IMS network.
the processor [208] is configured to process the account modification request data
5 by an A2P-IPSMGW module at the DR site upon the set of data associated with the
account modification request is stored into the second database [212].
[0074] The processor [208] is further configured to acknowledge the account
modification request by sending a success response to the originating management
10 system.
[0075] The account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.
15 [0076] The originating management system communicates with the front-end
module [304] via a RESTful interface.
[0077] A person skilled in the art would appreciate that the above listed features
are only exemplary and do not restrict the present disclosure in any possible manner.
20 In an exemplary implementation, the features listed above may be considered to be
in the order of their importance.
[0078] FIG. 3 illustrates an exemplary sequence diagram for synchronizing account
information between a primary site and a disaster recovery (DR) site, in accordance
25 with exemplary embodiments of the present disclosure.
[0079] At step S1, the Element Management System (EMS) [302] initiates an add
or update operation for an ESME (External Short Messaging Entity) account,
transmitting this request to the front-end module [304]. In an exemplary aspect,
30 element management system (EMS) acts like a user interface (UI) to receive
23

account information, add account information, update account information from external short messaging entity (ESME). In an exemplary aspect, the front-end module [304] is configured to receive a command from command line interface (CLI) for account info/update/add. 5
[0080] Moving on to step S2, the front-End module [304] processes this request
and consequently stores the ESME details within the database Cluster (such as the
first database [206]), which represents the first point of data entry in the system,
functioning as the initial database. The first database [206] includes such as but not
10 limited to remote dictionary server (Redis) that also acts like a cache. In an
exemplary aspect, the primary database cluster such as Redis acts as a publishing/subscribing system for streaming.
[0081] At step S3, following the receipt and processing of the account modification
15 details, the front-End module [304] sends back a confirmation in the form of a 200
OK response to the EMS [302], indicating the successful reception and handling of the request.
[0082] Then at step S4, the A2P-IPSMGW [102] interacts with the first database
20 [206], for retrieving the details of the ESME account modification from the first
database [206].
[0083] In step S5, the A2P-IPSMGW [102] takes further action based on the
retrieved information to add or update the ESME Configuration [312] accordingly,
25 implementing the changes within the network's operational parameters.
[0084] At step S6, the process involves the first database [206], interacting with the
DR Sync Application [310]. The data is read from the first database [206] and
shared with the primary sync application [308], ensuring the details are queued for
30 synchronization.
24

[0085] Proceeding to step S7, the Primary Sync Application [308] uses an HTTP2
communication protocol to securely transmit the ESME account details to the DR
Sync Application [310]. The step facilitates in ensuring that the disaster recovery
5 site has the most up-to-date information, maintaining consistency across the
network's nodes.
[0086] Thereafter, at step S8, the DR Sync Application [310] confirms the successful reception of the transmitted data by sending back a 200 OK response to
10 the Primary Sync Application [308]. In an exemplary aspect, disaster recovery (DR)
(A2PIPSMGW) listens to disaster recovery (DR) database cluster such as but not limited to Redis Cluster for processing the received data. Further, in an exemplary aspect, Application to Peer IP Short Message gateway (A2P-IPSMGW) and Short Message Service Centre (SMSC) are integrated to form an integrated unit, and in
15 the integrated unit the SMSC acts as a front-end module [304] to receive message
or account info from EMS over MAP interface.
[0087] Lastly at step S9, the DR Sync Application [310] stores the added/updated
ESME account data into a second database [212] for processing and
20 synchronization at the DR site.
[0088] Referring to FIG. 4 an exemplary method flow diagram [400], for
synchronizing account information between a primary site and a disaster recovery
(DR) site, in accordance with exemplary embodiments of the present disclosure is
25 shown. In an implementation the method is performed by the system [200]. Further,
in an implementation, the system [200] (partially or as a whole) may be present in a server device or in a user device to implement the features of the present disclosure.
25

[0089] At step [404], the method comprises receiving, by a receiving unit [202] via
a front-end module [304] at the primary site, an account modification request from
an originating management system. The account modification request could involve
actions such as the addition of a new account or the deletion of an existing account
5 within the communication network. The originating management system from
which the account modification request is received may include systems such as an
Element Management System (EMS), a Network Management System (NMS), a
Command Line Interface (CLI), a web interface, or an Application Programming
Interface (API). The receiving unit [202] serves as the initial entry point for the
10 request and is responsible for triggering a series of processes that will ensure the
account modification is reflected not only at the primary site but also synchronized with the DR site to maintain consistency across the network's operational databases.
[0090] Next, at step [406], the method encompasses storing, by a storage unit [204],
15 a set of data associated with the received account modification request into a first
database [206]. Upon receiving an account modification request, the storage unit
[204] captures and secures all the relevant data pertaining to this request, including
any details necessary for the modification of the account such as the account
number, user information, and the specific changes to be implemented. The first
20 database [206], which could be a system like Redis Stream, is then used as a
repository for the data.
[0091] Now, at step [408], the method comprises continuously monitoring, by a processor [208] using a primary site synchronization application, the first database
25 [206], for the set of data to process the account modification request. As soon as a
new account modification request is stored in the first database [206], the processor [208], through the primary site sync application, initiates the synchronization procedure. This involves preparing the data for transmission to the disaster recovery (DR) site to ensure that both the primary and DR sites maintain up-to-date and
30 consistent account information.
26

[0092] Further, at step [410], the method encompasses transmitting, by a
transmitting unit [210], the set of data associated with the account modification
request from the primary site synchronization application to a DR site
5 synchronization application via a communication channel. The transmitting unit
[210] serves as the bridge for secure data transfer, ensuring that the modifications
made at the primary site are accurately and promptly reflected at the DR site. The
use of a communication channel in this process is designed to guarantee a reliable
and efficient exchange of data, which is critical for the integrity and availability of
10 account information, especially during failover scenarios when the DR site is
required to take over operations seamlessly. The DR site synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.
15 [0093] Furthermore, at step [412], the method comprising storing, by the storage
unit [204] via the DR synchronization application, the set of data associated with the account modification request into a second database [212] for processing and synchronization at the DR site. The DR site synchronization application facilitates in managing the data transfer and storage process, ensuring that the data received is
20 accurately stored in the second database [212] thus, the DR site have an up-to-date
copy of the account information, ready to be used in case the primary site becomes unavailable. The synchronization process is designed to be seamless, with the storage unit [204] at the DR site automatically updating its database (such as the second database [212]) whenever changes are made at the primary site, thereby
25 ensuring continuous synchronization and data integrity.
[0094] Thereafter, the process terminates at step [414]
[0095] FIG. 5 illustrates an exemplary block diagram of a computing device [500]
30 (also referred to herein as a computer system [500]) upon which an embodiment of
27

the present disclosure may be implemented. In an implementation, the computing
device implements the method for synchronizing account information between a
primary site and a disaster recovery (DR) site in a communication network using
the system [200]. In another implementation, the computing device itself
5 implements the method for synchronizing account information between a primary
site and a disaster recovery (DR) site in a communication network by using one or more units configured within the computing device, wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
10 [0096] The computing device [500] may include a bus [502] or other
communication mechanism for communicating information, and a processor [504] coupled with bus [502] for processing information. The processor [504] may be, for example, a general-purpose microprocessor. The computing device [500] may also include a main memory [506], such as a random-access memory (RAM), or other
15 dynamic storage device, coupled to the bus [502] for storing information and
instructions to be executed by the processor [504]. The main memory [506] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the processor [504]. Such instructions, when stored in non-transitory storage media accessible to the processor
20 [504], render the computing device [500] into a special-purpose machine that is
customized to perform the operations specified in the instructions. The computing device [500] further includes a read only memory (ROM) [508] or other static storage device coupled to the bus [502] for storing static information and instructions for the processor [504].
25
[0097] A storage device [510], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [502] for storing information and instructions. The computing device [500] may be coupled via the bus [502] to a display [512], such as a cathode ray tube (CRT), for displaying information to a
30 computer user. An input device [514], including alphanumeric and other keys, may
28

be coupled to the bus [502] for communicating information and command
selections to the processor [504]. Another type of user input device may be a cursor
controller [516], such as a mouse, a trackball, or cursor direction keys, for
communicating direction information and command selections to the processor
5 [504], and for controlling cursor movement on the display [512]. This inputs device
typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.
[0098] The computing device [500] may implement the techniques described
10 herein using customized hard-wired logic, one or more Application-Specific
Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs),
firmware and/or program logic which in combination with the computing device
[500] causes or programs the computing device [500] to be a special-purpose
machine. According to one embodiment, the techniques herein are performed by
15 the computing device [500] in response to the processor [504] executing one or
more sequences of one or more instructions contained in the main memory [506].
Such instructions may be read into the main memory [506] from another storage
medium, such as the storage device [510]. Execution of the sequences of
instructions contained in the main memory [506] causes the processor [504] to
20 perform the process steps described herein. In alternative embodiments, hard-wired
circuitry may be used in place of or in combination with software instructions.
[0099] The computing device [500] also may include a communication interface
[518] coupled to the bus [502]. The communication interface [518] provides a two-
25 way data communication coupling to a network link [520] that is connected to a
local network [522]. For example, the communication interface [518] may be an
integrated services digital network (ISDN) card, cable modem, satellite modem, or
a modem to provide a data communication connection to a corresponding type of
telephone line. As another example, the communication interface [518] may be a
30 local area network (LAN) card to provide a data communication connection to a
29

compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [518] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. 5
[0100] The computing device[500] can send messages and receive data, including
program code, through the network(s), the network link [520] and the
communication interface 518. In the Internet example, a server [530] might transmit
a requested code for an application program through the Internet [528], the Internet
10 Service Provider (ISP) [526], the local network [522], host [524] and the
communication interface [518]. The received code may be executed by the processor [504] as it is received, and/or stored in the storage device [510], or other non-volatile storage for later execution.
15 [0101] The computing device [500] encompasses a wide range of electronic
devices capable of processing data and performing computations. Examples of computing device [500] include, but are not limited only to, personal computers, laptops, tablets, smartphones, servers, and embedded systems. The devices may operate independently or as part of a network and can perform a variety of tasks
20 such as data storage, retrieval, and analysis. Additionally, computing device [500]
may include peripheral devices, such as monitors, keyboards, and printers, as well as integrated components within larger electronic systems, showcasing their versatility in various technological applications.
25 [0102] Yet another aspect of the present disclosure relates to a non-transitory
computer-readable storage medium storing instructions for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network. The instructions include an executable code which when executed by a processor, may cause the processor to receive an account
30 modification request from an originating management system; store a set of data
30

associated with the received account modification request into a first database such
as but not limited to Redis stream; continuously monitor the first database for the
set of data to process the account modification request; transmit the set of data
associated with the account modification request from the primary site
5 synchronization application to a DR site synchronization application via a
communication channel; and store the set of data associated with the account modification request into a second database for processing and synchronization at the DR site.
10 [0103] As is evident from the above, the present disclosure provides a technically
advanced solution by using the Synchronization Client process communication to add any account in primary site along with an update in the DR site.
[0104] It should be noted that the terms "first", "second", "primary", "secondary",
15 "target" and the like, herein do not denote any order, ranking, quantity, or
importance, but rather are used to distinguish one element from another.
[0105] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various the components/units can be
20 implemented interchangeably. While specific embodiments may disclose a
particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative
25 arrangements and substitutions of units, provided they achieve the intended
functionality described herein, are considered to be encompassed within the scope of the present disclosure.
[0106] While considerable emphasis has been placed herein on the disclosed
30 embodiments, it will be appreciated that many embodiments can be made and that
31

many changes can be made to the embodiments without departing from the principles of the present disclosure. These and other changes in the embodiments of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

I/We Claim:
1. A method for synchronizing account information between a primary site and
a disaster recovery (DR) site in a communication network, the method
comprising:
receiving, by a receiving unit [202] via a front-end module [304] at the primary site, an account modification request from an originating management system;
storing, by a storage unit [204], a set of data associated with the received account modification request into a first database [206];
continuously monitoring, by a processor [208] using a primary site synchronization application, the first database [206] for the set of data to process the account modification request;
transmitting, by a transmitting unit [210], the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel; and
storing, by the storage unit [204] via the DR synchronization application, the set of data associated with the account modification request into a second database [212] for processing and synchronization at the DR site.
2. The method as claimed in claim 1, further comprises acknowledging, by the
processor [208], the account modification request by sending a success
response to the originating management system.

3. The method as claimed in claim 1, wherein the account modification request comprises at least one of addition of a new account or deletion of an existing account.
4. The method as claimed in claim 1, wherein the originating management system is selected from a group consisting of an Element Management System (EMS), a Network Management System (NMS), a Command Line Interface (CLI), a web interface, and an Application Programming Interface (API).
5. The method as claimed in claim 1, wherein the account modification request is stored into the first database [206] along with a zone name identifier.
6. The method as claimed in claim 1, wherein the DR site synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.
7. The method as claimed in claim 1, further comprising processing, by the processor [208], the account modification request data by an A2P- IP short message gateway (IPSMGW) module at the primary site upon the set of data associated with the account modification request is stored into the first database [206].
8. The method as claimed in claim 1, further comprising processing, by the processor [208], the account modification request data by an A2P-IPSMGW module at the DR site upon the set of data associated with the account modification request is stored into the second database [212].

9. The method as claimed in claim 1, wherein the account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.
10. The method as claimed in claim 1, wherein the originating management system communicates with the front-end module [304] via a RESTful interface.
11. A system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, the system comprising:
a receiving unit [202] configured to receive, via a front-end module [304] at the primary site, an account modification request from an originating management system;
a storage unit [204], configured to store a set of data associated with the received account modification request into a first database [206];
a processor [208], configured to continuously monitor, using a primary site sync application, the first database [206] for the set of data to process the account modification request;
a transmitting unit [210], configured to transmit the set of data associated with the account modification request from the primary synchronization application to a DR synchronization application via a communication channel; and
the storage unit [204], configured to store, via the DR synchronization application, the set of data associated with the account

modification request into a second database [212] for processing and synchronization at the DR site.
12. The system as claimed in claim 11, wherein the processor [208] is further configured to acknowledge the account modification request by sending a success response to the originating management system.
13. The system as claimed in claim 11, wherein the account modification request comprises at least one of addition of a new account or deletion of an existing account.
14. The system as claimed in claim 11, wherein the originating management system is selected from a group consisting of Element Management System (EMS), Network Management System (NMS), Command Line Interface (CLI), web interface, and an Application Programming Interface (API).
15. The system as claimed in claim 11, wherein the account modification request is stored into the first database [206] along with a zone name identifier.
16. The system as claimed in claim 11, wherein the DR synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.
17. The system as claimed in claim 11, wherein the processor [208] is configured to process the account modification request data by an application to peer -IP short message gateway (A2P-IPSMGW) module at the primary site upon

the set of data associated with the account modification request is stored into the first database [206].
18. The system as claimed in claim 11, wherein the processor [208] is configured to process the account modification request data by an A2P-IPSMGW module at the DR site upon the set of data associated with the account modification request is stored into the second database [212].
19. The system as claimed in claim 11, wherein the account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.
20. The system as claimed in claim 11, wherein the originating management system communicates with the front-end module [304] via a RESTful interface.