DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION

METHOD AND SYSTEM FOR MANAGING TRACE DATA OF USERS

2. APPLICANT(S)
Name Nationality Address
JIO PLATFORMS LIMITED INDIAN Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India
3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to JIO PLATFORMS LIMITED or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.
TECHNICAL FIELD
[0002] The present disclosure relates generally to the field of wireless communications. More particularly, the present disclosure relates to a method and a system for managing trace data of users.
DEFINITION
[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.
[0004] The expression ‘Event Routing Manager (ERM)’ used hereinafter in the specification refers to a component within an event-based architecture responsible for generating trace data records for event requests and routing the event requests from a source microservice to a destination microservice or another microservice within the event-based architecture.
[0005] The expression ‘event-based architecture’ used hereinafter in the specification refers to an architecture where various microservices (e.g., the source microservice and the destination microservice) communicate with each other to generate a response corresponding to each event request.
[0006] The expression ‘source microservice’ used hereinafter in the specification refers to a microservice that originates or initiates an event request corresponding to an event associated with a User Equipment (UE).
[0007] The expression ‘destination microservice’ used hereinafter in the specification refers to a microservice that receives and processes the event request received from the source microservice or from other microservices to generate the response corresponding to the event request.
[0008] The expression ‘event request’ used hereinafter in the specification refers to a message or a signal generated by the source microservice to indicate an occurrence of an event (or a specific action).
[0009] The expression ‘trace data’ used hereinafter in the specification refers to details of a user's interactions with applications and network services associated with the UE, including actions taken, navigation patterns, and timestamps. The trace data is used to monitor user behavior, troubleshoot issues (also referred to as anomalies), and for meeting compliance requirements and ensuring robust security.
[0010] The expression ‘trace data record’ used hereinafter in the specification refers to a structured entry stored in a database of a system. The trace data record includes detailed information corresponding to the event request, such as an event name, an event type, a username, an associated timestamp, and other relevant information (such as user actions, and any associated metadata) associated with the event request. The trace data record is used for performing auditing and compliance check, and security checks.
BACKGROUND
[0011] 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.
[0012] In modern digital architectures, user tracing is crucial for meeting compliance requirements and ensuring robust security. User tracing involves monitoring and recording user interactions with a system to verify adherence to regulatory standards and protect against potential security threats. Furthermore, user tracing plays a crucial role in identifying and preventing security breaches. By monitoring user behavior and tracking interactions, organizations can detect unusual patterns or suspicious activities that may indicate potential security threats. Further, the compliance requirements refer to adhering to laws, regulations, and industry standards that govern how the organizations handle the user interactions and conduct their operations. Additionally, the regulatory standards often mandate maintaining detailed records of the user interactions to ensure transparency, accountability, and adherence to legal standards. For example, regulations such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA) require detailed tracking of the user interactions to ensure data integrity and protect sensitive information. These regulatory standards necessitate that the need for the organizations to maintain comprehensive logs of user activities such as login attempts, data access, modifications, and other interactions, to facilitate audits and prove compliance.
[0013] By maintaining detailed records of the user interactions, the organizations can ensure transparency, facilitate audits, detect and prevent fraudulent activities, and enhance their overall security posture. Currently, various techniques have been implemented for performing the user tracing to ensure compliance and security. Examples of these techniques include a log management and analysis technique, a user behavior analytics technique, a session recording technique, a network traffic analysis technique, an identity and access management technique, and the like. However, each existing technique comes with drawbacks related to data volume, privacy concerns, system performance, and implementation complexity. Addressing these drawbacks requires careful planning, the use of advanced technologies, and adherence to best practices in data management and privacy protection. Hence, with the usage of currently existing techniques, the need for comprehensive monitoring with the need to respect user privacy and the system performance remains a critical challenge in the evolving landscape of digital security and compliance.
[0014] There is, therefore, a need in the art to provide a method and a system that can mitigate the disadvantages of the prior art.
SUMMARY
[0015] In an exemplary embodiment, a method for managing trace data of users. The method includes receiving an event request from a User Equipment (UE) associated with a user. The method includes processing the event request to extract a set of event parameters from the event request. The method includes storing the set of event parameters along with an associated timestamp in a database as a trace data record corresponding to the user associated with the UE. The method includes retrieving the trace data record associated with the user from the database for performing one or more actions.
[0016] In an embodiment, the set of event parameters includes an event name, an event type, and a username of the user associated with the UE.
[0017] In an embodiment, the set of event parameters along with the associated timestamp is stored based on a unique trace Identifier (ID) associated with the event request.
[0018] In an embodiment, the database stores a plurality of trace data records associated with a plurality of event requests received from the UE.
[0019] In an embodiment, the method further includes deleting each of the plurality of trace data records associated with the UE after an expiry of a configured time period.
[0020] In an embodiment, to perform the one or more actions, the method is further configured to analyze each trace data record to identify one or more anomalies in one or more trace data records associated with the user of the UE.
[0021] In another exemplary embodiment, a system for managing trace data of users is disclosed. The system includes a processing engine, and a memory coupled to the processing engine and configured to store instructions executable by the processing engine, causing the processing engine to receive an event request from a User Equipment (UE) associated with a user. The processing engine is further configured to process the event request to extract a set of event parameters from the event request. The processing engine is further configured to store the set of event parameters along with an associated timestamp in a database as a trace data record corresponding to the user associated with the UE. The processing engine is further configured to retrieve the trace data record associated with the user from the database for performing one or more actions.
[0022] In an embodiment, the set of event parameters includes an event name, an event type, and a username of the user associated with the UE.
[0023] In an embodiment, the set of event parameters along with the associated timestamp is stored based on a unique trace Identifier (ID) associated with the event request.
[0024] In an embodiment, the database stores a plurality of trace data records associated with a plurality of event requests received from the UE.
[0025] In an embodiment, the processing engine is further configured to delete each of the plurality of trace data records associated with the UE after an expiry of a configured time period.
[0026] In an embodiment, to perform the one or more actions, the processing engine is further configured to analyze each trace data record to identify one or more anomalies in one or more trace data records associated with the user of the UE.
[0027] The present disclosure discloses a User Equipment (UE) communicatively coupled with a network. The coupling includes a step of receiving, by the network, a connection request from the UE. The coupling includes a step of sending, by the network, an acknowledgment of the connection request to the UE. The coupling includes a step of transmitting a plurality of signals in response to the connection request. Based on the connection request, a management of trace data of a user is performed.
[0028] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
OBJECTIVES
[0029] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:
[0030] An objective of the present disclosure is to provide a system and a method for managing trace data of users to identify security breaches, unauthorized access, or suspicious activities within an event-based architecture.
[0031] Another objective of the present disclosure is to efficiently debug and troubleshoot issues (also referred to as anomalies) by performing trace data monitoring for the users within the event-based architecture.
[0032] Another objective of the present disclosure is to provide a clear and detailed view of a flow of events as the events move through the event-based architecture.
[0033] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
[0034] 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 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 electrical components, electronic components or circuitry commonly used to implement such components.
[0035] FIG. 1 illustrates an exemplary network architecture for implementing a system for managing trace data of users, in accordance with an embodiment of the present disclosure.
[0036] FIG. 2 illustrates an exemplary block diagram of the system configured for managing the trace data of the users, in accordance with an embodiment of the present disclosure
[0037] FIG. 3 illustrates an exemplary connection diagram depicting communication between an Event Routing Manager (ERM), a source microservice, and a destination microservice, in accordance with an embodiment of the present disclosure.
[0038] FIG. 4 illustrates an exemplary process flow for managing the trace data of the users, in accordance with an embodiment of the present disclosure.
[0039] FIG. 5 illustrates an exemplary flow diagram for a method for managing the trace data of the users, in accordance with an embodiment of the present disclosure.
[0040] FIG. 6 illustrates an exemplary computer system in which or with which the embodiments of the present disclosure may be implemented.
[0041] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100 – Network architecture
102-1, 102-2…102-N – Plurality of Users
104-1, 104-2…104-N – Plurality of User Equipments
106 – Network
108 – System
200 – Block Diagram
202 – Processor(s)
204 - Memory
206 – Plurality of Interfaces
208 – Processing Engine
210, 308 – Database
212, 302 - Event Routing Manager (ERM)
300 – Exemplary connection diagram
304 – Source Microservice
306 – Destination Microservice
400 – Process Flow Diagram
500 – Flow Diagram
600 – Computer System
610 – External Storage Device
620 – Bus
630 – Main Memory
640 – Read Only Memory
650 – Mass Storage Device
660 – Communication Port
670 – Processor
DETAILED DESCRIPTION
[0042] 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. 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 which like reference numerals refer to the same parts throughout the different drawings.
[0043] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in 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.
[0044] 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 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.
[0045] Also, it is noted that individual embodiments may be described as a process that 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 is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0046] The word “exemplary” and/or “demonstrative” is used herein to mean 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 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 like the term “comprising” as an open transition word without precluding any additional or other elements.
[0047] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0048] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. 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 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.
[0049] 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 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 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 the art for implementation of the features of the present disclosure.
[0050] 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 special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital Signal Processor (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, 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.
[0051] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), and now fifth generation (5G), and more such generations are expected to continue in the forthcoming time.
[0052] Radio Access Technology (RAT) refers to the technology used by mobile devices/ User Equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include Global System for Mobile Communications (GSM), a Code Division Multiple Access (CDMA), a Universal Mobile Telecommunications System (UMTS), a Long-Term Evolution (LTE), and Fifth Generation (5G) network. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
[0053] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when a Second Generation (2G) technology was introduced. Third Generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. A Fourth Generation (4G) technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, a Fifth generation (5G) technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (IoT) connectivity, and more efficient use of network resources. A Sixth Generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way we connect and interact with technology.
[0054] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0055] Embodiments herein relate to a method for managing trace data of users is disclosed. The management of the trace data for the users is performed using an Event Routing Manager (ERM). In particular, the method includes receiving an event request from a User Equipment (UE) associated with a user. Upon receiving the event request, the event request is processed to extract a set of event parameters from the event request. Once the set of event parameters are extracted, the set of event parameters along with an associated timestamp is stored in a database as a trace data record corresponding to the user associated with the UE. In an embodiment, the associated timestamp may be extracted from the event request. For example, in this embodiment, the associated timestamp may correspond to a timestamp at which the event request is initiated. In some embodiments, the associated timestamp may be determined by the ERM upon receiving the event request. For example, in this embodiment, the associated timestamp may correspond to a timestamp at which the event request is received by the ERM. Once the set of event parameters, along with the associated timestamp, is stored in the database as the trace data record, the trace data record associated with the user may be retrieved from the database for performing one or more actions. In an embodiment, the trace data record may be retrieved based on an end-user requirement. The end-user may correspond to a network administrator, a team member of regulatory agencies, a compliance officer, a network security professional, and the like.
[0056] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0057] FIG. 1 illustrates an exemplary network architecture 100 for implementing a system 108 for managing trace data of users, in accordance with an embodiment of the present disclosure. In order to manage the trace data for the users, the system 108 may include the ERM. In an example, the trace data refers to the detailed record of a user's interactions with applications and network services on a User Equipment (UE). The trace data includes data on user actions, navigation patterns, and timestamps. The trace data is utilized for monitoring user behavior and diagnosing issues (often referred to as anomalies).
[0058] As illustrated in FIG. 1, the network architecture 100 may include one or more computing devices or UEs 104-1, 104-2…104-N associated with one or more users 102-1, 102-2…102-N. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2…102-N may be individually referred to as the user 102 and collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2…104-N may be individually referred to as the UE 104 and collectively referred to as the UEs 104. A person of ordinary skill in the art will appreciate that the terms “computing device(s)” and “user equipment” may be used interchangeably throughout the disclosure. Although three UEs 104 are depicted in FIG. 1, however, any number of the UEs 104 may be included without departing from the scope of the ongoing description.
[0059] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UE 104 may include, but is not limited to, smart phones, smart watches, smart sensors (e.g., a mechanical sensor, a thermal sensor, an electrical sensor, a magnetic sensor, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart televisions (TVs), computers, smart security systems, smart home systems, other devices for monitoring or interacting with or for the user 102 and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but is not limited to, intelligent, multi-sensing, network-connected devices, that can integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0060] In an embodiment, the UE 104 may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but is not limited to, any electrical, electronic, electro-mechanical, or an equipment, or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, the UE 104 may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user 102 or an entity such as a touch pad, a touch enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.
[0061] In FIG. 1, the UE 104 may communicate with the system 108 through a network 106. In particular, the UE 104 may be communicatively coupled with the network 106. The coupling including steps of receiving, by the network 106, a connection request from the UE 104. Upon receiving the connection request, the coupling includes steps of sending, by the network 106, an acknowledgment of the connection request to the UE 104. Further, the coupling includes steps of transmitting a plurality of signals in response to the connection request. The plurality of signals is responsible for communicating with the system 108 to manage the trace data for the users (i.e., the user 102) in the network 106.
[0062] In an embodiment, the network 106 may include at least one of a 4G network, a 5G network, a 6G network, or the like. The network 106 may enable the UE 104 to communicate with other devices in the network architecture 100 and/or with the system 108. The network 106 may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network 106 may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. In another embodiment, the network 106 includes, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth.
[0063] In another exemplary embodiment, the network architecture 100 may include a centralized server (not shown) may include or comprise, by way of example but not limitation, one or more of: a stand-alone server, a server blade, a server rack, a bank of servers, a server farm, a hardware supporting a part of a cloud service or a system, a home server, a hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof.
[0064] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture 100 may perform functions described as being performed by one or more other components of the network architecture 100.
[0065] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for managing the trace data of the users (e.g., the users 102), in accordance with an embodiment of the disclosure. FIG. 2 is explained in conjunction with FIG. 1.
[0066] In an embodiment, the system 108 may include one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 108. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.
[0067] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (I/O), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, a processing engine 208 and a database 210. In an embodiment, the processing engine 208 may include an ERM 212. The ERM 212 may be configured to communicate with a plurality of microservices associated with a UE (i.e., the UE 104) corresponding to the user (e.g., the user 102). The plurality of microservices is running on the UE may correspond to a modular software component designed to perform a specific function within the UE. The microservice may correspond to a source microservice, a destination microservice, or other associated microservices in between the source microservice and the destination microservice. The microservice is independently deployable, scalable, and interacts with other microservices or components associated with the UE to support applications (e.g., e-commerce applications, mobile banking applications, health monitoring applications, etc.) and a network (i.e., the network 106) functionalities. Further, examples of the plurality of microservices may include an authentication microservice, a transaction processing microservice, a notification microservice, a user behavior analytics microservice, a session management microservice, and the like.
[0068] In an embodiment, the processing engine 208 is configured for managing the trace data for the users in a telecommunication network (e.g., the network 106). The trace data may correspond to details of a user's interactions with the applications (e.g., mobile applications or web applications) or a network service (e.g., File Transfer Protocol (FTP) service, email services etc.), including actions taken, navigation patterns, and timestamps. In order to manage the trace data for the users, the processing engine 208 includes the ERM 212. Initially, the ERM 212 is configured to receive an event request from the UE (e.g., the UE 104) associated with the user (e.g., the user 102). The event request, for example, may be a user login request indicating a request for a login attempted by the user of the UE into an application or a network service, a data access request indicating a request to access specific data or resources within an application or the network, an application usage request indicating usage of an application or a specific feature within the application, a navigation request representing a user's navigation between different pages or sections within an application or a website, a transaction request and the like. In an embodiment, the event request may be received in a Hypertext Transfer Protocol (HTTP) format.
[0069] Upon receiving the event request, the ERM 212 is configured to process the event request. The processing of the event request is performed to extract a set of event parameters from the event request. The set of event parameters includes, but is not limited to, an event name, an event type, and a username of the user associated with the UE. Once the set of event parameters is extracted, the ERM 212 is configured to store the set of event parameters along with an associated timestamp in a database (e.g., the database 210) associated with the UE. The set of event parameters, along with the associated timestamp, may be stored as a trace data record corresponding to the user of the UE. In an embodiment, the associated timestamp may be extracted from the event request. For example, in this embodiment, the associated timestamp may correspond to a timestamp at which the event request is initiated. In some embodiments, the associated timestamp may be determined by the ERM 212 upon receiving the event request. For example, in this embodiment, the associated timestamp may correspond to a timestamp at which the event request is received by the ERM 212.
[0070] Further, the set of event parameters along with the associated time stamp may be stored based on a unique trace Identifier (ID) associated with the event request. In other words, each event request that is generated upon detecting an event corresponding to the UE is assigned with the unique trace ID. Further, based on the unique trace ID, the set of event parameters along with the associated time stamp may be stored as the trace data record. In particular, each trace data record may be stored based on a corresponding unique trace ID assigned to each event request. Once the trace data record is stored in the database, an end-user (e.g., a network administrator, a team member of regulatory agencies, a compliance officer, a network security professional, and the like) may retrieve the trace data record associated with the user from the database for performing one or more actions. Examples of the one or more actions may include, but are not limited to, an audit or compliance check, a security check, an unauthorized access check, and a suspicious activity check. In an embodiment, the end-user may retrieve the trace data record based on his requirement. In particular, the ERM 212 may retrieve the trace data record based on the end-user requirement. Further, to perform the one or more actions, the ERM 212 is configured to analyze the trace data record to identify one or more anomalies (e.g., security breaches, unauthorized access, suspicious activities, or fraudulent behaviour). In an embodiment, the end-user may retrieve the trace data record to perform an audit and compliance check or a security check.
[0071] In an embodiment, the processing engine 208 that may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine 208. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine 208 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine 208 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine 208. In such examples, the system 108 may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system 108 and the processing resource. In other examples, the processing engine 208 may be implemented by electronic circuitry.
[0072] In an embodiment, the database 210 includes data (e.g., the event request, the plurality of trace data records associated with a plurality of UEs of a plurality of users, etc.) that may be either stored or generated as a result of functionalities implemented by any of the components of the processor 202 or the processing engine 208. In an embodiment, the database 210 may be a distributed database. The distributed database is a database where the data (i.e., the event request, the plurality of trace data records associated with the plurality of UEs of the plurality of users, etc.) is stored across multiple physical locations or servers, which can be spread over various geographic regions.
[0073] FIG. 3 illustrates an exemplary connection diagram 300 depicting communication between an ERM 302, a source microservice 304 and a destination microservice 306, in accordance with an embodiment of the present disclosure. The ERM 302 may correspond to the ERM 212. FIG. 3 is explained in conjunction with FIGS. 1 and 2.
[0074] As depicted in FIG. 3, the ERM 302 may be in communication with the source microservice 304 and destination microservice 306 and vice versa. The source microservice 304 may communicate with destination microservice 306 via the ERM 302. The source microservice 304 may be a publisher or a subscriber. In other words, the source microservice 304 corresponds to a microservice that originates or initiates the event request corresponding to an event associated with the UE (e.g., the UE 104). The source microservice 304 generates and sends the event request to other microservices (e.g., the destination microservice 306) or systems (e.g., an application server) for further processing. For example, consider a scenario where the user of the UE attempts to log in to a mobile banking application. In this scenario, when the user enters login credentials (such as a username and a password) to attempt login, then an authentication microservice within the mobile banking application may be the source microservice 304 that is configured to process the login credentials to verify an identity of the user associated with the UE. Further, in this scenario, upon receiving the user’s login credentials, the authentication microservice is configured to generate the event request (e.g., a user login request) corresponding to the login attempted by the user of the UE. The event request may include the set of event parameters, such as the event name (e.g., user login), an event type (e.g., user authentication successful), and the username (e.g., XYZ). In an embodiment, the event request may also include a timestamp associated with the event request, i.e., the timestamp at which the event request was generated by the source microservice 304. The source microservice 304 is configured to send the event request to the ERM 302.
[0075] Upon receiving the event request, the ERM 302 is configured to process the event request received from the source microservice 304 to extract the set of event parameters from the event request. In other words, the ERM 302 may extract the event name (e.g., the user login), the event type (e.g., the user authentication successful), and the username (e.g., the XYZ) from the event request. In addition, the ERM 302 may extract the timestamp associated with the event request. In an embodiment, the timestamp associated with the event request may correspond to the timestamp at which the event request was generated by the source microservice 304. In some embodiment, the timestamp may correspond to the timestamp at which the ERM 302 receives the event request from the source microservice 304. Once the set of event parameters and the associated timestamp are extracted, the ERM 302 is configured to store the set of event parameters along with the associated timestamp in a database 308 (same as the database 210). The ERM 302 may store the set of event parameters and the associated timestamp in the database 308 as the trace data record corresponding to the user of the UE. To store the set of event parameters along with the associated timestamp as the trace data record, the ERM 302 is configured to assign the unique trace ID associated with the event request to the trace data record. In other words, whenever the source microservice 304 generates and sends the event request, then the source microservice 304 is configured to assign the unique trace ID to each event request to uniquely identify the event request. Further, the unique trace ID is further allocated to the trace data record generated for that event request.
[0076] In addition to storing the set of event parameters and the associated timestamp in the database 308, the ERM 302 is configured to send the event request to the destination microservice 306 for further processing. The destination microservice 306 may be a publisher or a subscriber. The publisher is an entity that produces and sends event requests or messages to the application or the network service, signaling state changes or new data. The subscriber is an entity that consumes and processes the event requests, or the messages received from the application or the network service, reacting to the state change or the new data provided by the publisher. The destination microservice may refer to a microservice that receives and processes the event request received from the source microservice 304 or from other microservices to generate a response corresponding to the event request. In particular, the destination microservice 306 is configured to receive the event request from the source microservice 304 via the ERM 302. Upon receiving the event request, the destination microservice 306 is configured to process the event request to generate the response. In continuation to the above example, the destination microservice 306 may correspond to a logging microservice within the mobile banking application. Further, upon receiving the event request, i.e., the user login request, the destination microservice 306 is configured to process the user login request to enable the user to access the mobile banking application.
[0077] The destination microservice 306 is configured to process the event request based on the set of event parameters to generate the response. For example, when an event parameter, e.g., the event type, is determined as ‘the user authentication successful’, the destination microservice 306 is configured to generate the response as ‘user login successful’ to enable the user to login in the mobile banking application to perform one or more user actions (check available balance, perform transactions, etc.). Further, the destination microservice 306, i.e., the logging service, is configured to maintain and manage a user login session corresponding to the mobile banking application. In some embodiments, when the event parameter, i.e., the event type is determined as ‘user authentication unsuccessful’, the destination microservice 306 is configured to generate the response as ‘user login unsuccessful’. Further, the response generated by the destination microservice 306 is rendered to the user of the UE.
[0078] In an embodiment, once the trace data record corresponding to the event request is stored in the database 308, the end-user (e.g., the network administrator, the team member of regulatory agencies, the compliance officer, the network security professional, and the like) may retrieve the trace data record associated with the event request corresponding to the user from the database 308 to perform the one or more actions. Examples of the one or more actions may include, but are not limited to, the audit or compliance check, the security check, the unauthorized access check, and the suspicious activity check. In an embodiment, the end-user may retrieve the trace data record based on his requirement. For example, the end-user may retrieve the trace data record to identify one or more anomalies associated with the user of the UE. In particular, the ERM 302 may retrieve one or more trace data records associated with the user of the UE from the database 308 based on the end-user requirement. Further, the ERM 302 is configured to analyze the one or more trace data records to identify the one or more anomalies in the one or more trace data records. Once the one or more anomalies are identified, the end-user may perform the one or more actions corresponding to the one or more trace data records. The one or more anomalies may be multiple failed login attempts, user credentials not verified, detection of an unusual transaction, and the like. In other words, the end-user may perform the audit and compliance check or the security check to identify the security breaches, the unauthorized access, or the suspicious activities associated with the user of the UE. For example, in case of multiple failed login attempts, the trace data record corresponding to each event request generated for each login attempt may be saved by the ERM 302 in the database 308. Further, the end-user (e.g., a security professional of a bank with which the mobile banking application is associated) may retrieve the trace data record to identify a security breach or the unauthorized access to the mobile banking application. In an embodiment, the trace data record corresponding to each event request may be stored in the database 308 for a configured time period (e.g., 90 days). Further, after the expiry of the configured time period, the trace data record may be deleted from the database 308.
[0079] In an aspect, a large system is divided into multiple small microservices (i.e., the plurality of microservices) in the event-based architecture. Every microservice is responsible for doing a specific task. Each microservice is configured to communicate with a chain of microservices to serve the event request. Further, each microservice is categorized based on a type of the event request (e.g., the user login request, the data access request, the application usage request, etc.) and a functionality associated with each microservice. In other words, the source microservice 304 may call another microservice to fulfill the event request. The event request is routed from a first microservice (e.g., the source microservice 304) to a 2nd microservice, and from the second microservice to a third microservice and so on. Once the processing of the event request reaches the destination microservice 306, the destination microservice 306 generates the response depicting whether the event request is fulfilled or not. Further, the destination microservice 306 sends and renders the response to the user of the UE. In some embodiment, the destination microservice 306 sends the response to the source microservice 304. Further, the source microservice 304 renders the response to the user of the UE. During all those traversals through the chain of the microservices, data (i.e., the set of event parameters and the associated timestamp) associated with each event request is traced and stored in the database 308.
[0080] According to an aspect of the present disclosure, every time the event request (for example, an HTTP request) is generated and received, the ERM 302 may extract the set of event parameters from the event request. Further, the ERM 302 stores the set of event parameters along with the associated timestamp as the trace data record by employing an indexing (i.e., by assigning the unique trace ID) of the trace data records into the database 308. Every event request has a corresponding unique trace ID. Using the unique trace ID, the end-user may directly retrieve the trace data record that the ERM 302 is recording to determine a flow of the event request from one microservice to another microservice. In this way, the end-user is able to determine how the event request is routed from the first microservice to the second microservice, and from the second microservice to the second microservice, and so on. This helps the end-user to easily analyze trace data records stored for the UE in the database 308 faster, as compared to any traditional method used to identify any security breaches, the unauthorized access, or the suspicious activities (e.g., multiple login attempts, anomalous data, unusual transaction amount, etc.) corresponding to the user of the UE.
[0081] In an implementation, the data (i.e., the set of event parameters) of the event request is useful for analysis purposes or for tracking user behavior and user activities as well as for tracking a specific event request in the event-based architecture. In addition to the trace data record, the database 308 may include other relevant information, such as, what activity user is trying to keep, which Application Programming Interface (API) the user is calling, etc.). The end-user (for example, the security professional) can download and analyze the trace data records to identify the one or more anomalies corresponding to the user of the UE.
[0082] FIG. 4 illustrates an exemplary process flow 400 for managing the trace data of the users, in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1, 2, and 3. Each step of the process 400 may be performed by the ERM 302 (same as the ERM 212).
[0083] To manage the trace data for the users, initially, the ERM 302 is configured to receive the event request from the UE (e.g., the UE 104) associated with the user (e.g., the user 102). In particular, the ERM 302 is configured to receive the event request from a source microservice (e.g., the source microservice 304) associated with the application, the website, or the network service running on the UE of the user. The source microservice may be the publisher or the subscriber. In particular, the source microservice may correspond to the microservice that originates or initiates the event request (e.g., a transaction request) corresponding to an event (e.g., a transaction) associated with the UE. The event request, for example, may be the user login request, the data access request, the application usage request, the navigation request, the transaction request and the like
[0084] Upon receiving the event request from the source microservice, at step 402, the ERM 302 is configured to accept the event request received from the source microservice associated with the UE. Further, at step 404, the ERM 302 is configured to process the event request to extract the set of event parameters from the event request. The set of event parameters may include, but are not limited to, the event name, the event type, and the username of the user associated with the UE. In an embodiment, in addition to extracting the set of event parameters, the ERM 302 is configured to determine the associated timestamp at which the event request is initiated. Upon extracting the set of event parameters and the associated timestamp, at step 406, the ERM 302 is configured to determine the event type (e.g., a successful event or a failed event). Based on the check performed, the ERM 302 is configured to generate an event acknowledgement, e.g., a successful event acknowledgement or an unsuccessful event acknowledgement. The successful event acknowledgement may depict that the event request has been successfully validated. Further, the unsuccessful event acknowledgement may depict that the event request has not been successfully validated.
[0085] Upon determining the event type, in one embodiment, at step 408, the ERM 302 is configured to route the event request to a destination microservice (e.g., the destination microservice 306). In some embodiment, the ERM 302 may route the event request to another microservice associated with the application, the website, the network service, or the application server for further processing. The ERM 302 may route the event request to another microservice based on one or more event parameters of the set of event parameters and other parameters such as an event category (e.g., browsing, login, transaction, etc.), event attributes (e.g., an associated link for browsing, the user credentials, etc.), routing rules (e.g., business logic rules, microservice service capabilities, etc.), and the like. Further, the destination microservice 306 is configured to generate the response (e.g., a success response or a failed response) corresponding to the event request. The success response may depict that the event request is successfully executed, and the user is able to access a service (e.g., a transaction page of the application) based on the event request. The failed response may depict that the event request is not successfully executed, and the user is not able to access the service (e.g., the transaction page of the application) based on the event request.
[0086] In another embodiment, at step 410, the ERM 302 is configured to store the set of event parameters along with the associated timestamp in a database (e.g., the database 308) depicted in step 412. The ERM 302 may store the set of event parameters along with the associated timestamp as the trace data record in the database. The ERM 302 may store the set of event parameters along with the associated timestamp as the trace data record by assigning the unique trace ID associated with the event request to the trace data record. In an embodiment, the associated timestamp may correspond to the timestamp at which the source microservice generates the event request. In some embodiments, the associated timestamp may correspond to the timestamp at which the ERM 302 received the event request from the source microservice.
[0087] Once the trace data record is stored in the database, at step 414, the end-user (e.g., the network administrator, the team member of regulatory agencies, the compliance officer, the network security professional, and the like) is configured to retrieve the trace data record for performing the one or more actions. Examples of the one or more actions may include, but are not limited to, the audit or compliance check, the security check, the unauthorized access check, and the suspicious activity check. In an embodiment, the end-user may retrieve the trace data record based on his requirement. The trace data record may be referred to as user trace. The database is configured to store the plurality of trace data records corresponding to the plurality of event requests received from the UE. As will be appreciated, the database may store the plurality of trace data records corresponding to the plurality of event requests associated with a plurality of UEs. Further, each trace data record stored in the database may be deleted after the expiry of the configured time period (e.g., 90 days) to update the database. The configured time period can be defined by the end-user based on their requirement. Further, the end-user may retrieve one or more trace data records corresponding to the UE by specifying a time range, e.g., for 5 days, by entering a start date and an end date based on their requirement (i.e., the end-user requirement) to identify the one or more anomalies (e.g., any security breach, unauthorized access, etc.) in the one or more trace data records associated with the user of the UE. In particular, based on the time range defined by the end user, the ERM 302 is configured to retrieve the one or more trace data records associated with the user of the UE. Further, the ERM 302 is configured to analyze the one or more trace data records to identify the one or more anomalies in the one or more trace data records. Once the one or more anomalies are identified, the end-user may be able to perform the one or more actions corresponding to the one or more trace data records. In an embodiment, the end-user can retrieve the one or more trace data records to perform the audit or compliance check or the security check. In some embodiments, the trace data record may be used by the destination microservice to generate the response corresponding to the event request. By way of an example, consider a scenario where the end-user may perform the audit and complains check or the security check. In this scenario, suppose the end-user (e.g., the security professional) receives an event trigger corresponding to about a suspicious activity, such as multiple failed login attempts on sensitive areas (i.e., multiple logins to the transaction page) of the application. In this case, the end-user may identify a timeframe of the suspicious activity. Once the timeframe is identified, the end-user may specify a time range, e.g., for 5 hours, by entering a start date and an end date based on their requirement to retrieve the data associated with the suspicious activity to examine the data to identify anomalies such as repeated failed login attempts, access from unusual geographic locations, and the like. Further, the end-user may prepare a report detailing the anomalies associated with the suspicious activity, discovered security breaches, unauthorized access, and non-compliance with access policies associated with the application.
[0088] FIG. 5 illustrates an exemplary flow diagram of a method 500 for managing the trace data of the user, in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1, 2, 3, and 4. Each step of the method 500 may be performed by the ERM 302 (same as the ERM 212 present within the processing engine 208 of the system 108).
[0089] At step 502, the event request may be received from the UE (e.g., the UE 104) associated with the user (e.g., the user 102). In particular, the event request may be received from the source microservice (e.g., the source microservice 304) associated with an application running on the UE of the user. In an embodiment, the event request may be received in the HTTP format. Further, the event request, for example, may be the user login request indicating the request for the login attempted by the user of the UE into the application or the network service, the data access request indicating the request to access specific data or resources within the application or the network, the application usage request indicating usage of the application or the specific feature within the application, the navigation request representing the user's navigation between different pages or sections within the application or the website, the transaction request and the like.
[0090] Upon receiving the event request, at step 504, the received event request may be processed to extract the set of event parameters from the event request. The set of event parameters includes, but is not limited to, the event name, the event type, and the username of the user associated with the UE. Once the set of event parameters is extracted, at step 506, the set of event parameters along with the associated timestamp is stored in the database (e.g., the database 308). In an embodiment, the associated timestamp may be extracted from the event request. For example, in this embodiment, the associated timestamp may correspond to the timestamp at which the event request is initiated by the source microservice. In some embodiments, the associated timestamp may be determined upon receiving the event request. For example, in this embodiment, the associated timestamp may correspond to the timestamp at which the event request is received. Further, the set of event parameters along with the associated timestamp may be stored as the trace data record corresponding to the user of the UE. The trace data record corresponding to the event request may be stored in the database for the configured time period (e.g., 90 days). The database is configured to store the plurality of trace data records corresponding to the plurality of event requests received from the UE. As will be appreciated, the database may store the plurality of trace data records corresponding to the plurality of event requests associated with the plurality of UEs. Further, each of the plurality of trace data records stored within the database may be deleted after the expiry of the configured time period. For instance, the trace data records stored within the database may be deleted after the expiry of the configured time period, i.e., 90 days from the date on which the trace data record is stored in the database.
[0091] Further, the set of event parameters along with the associated time stamp may be stored as the trace data record based on the unique trace ID associated with the event request. In other words, each event request may be assigned the unique trace ID when an event is detected, and the event request is generated. Further, based on the unique trace ID, the set of event parameters along with the associated timestamp may be stored as the trace data record. In particular, each trace data record may be assigned the unique trace ID associated with the event request to store the trace data record in the database. Once the trace data record is stored in the database, at step 508, the end-user may retrieve the trace data record associated with the user from the database for performing the one or more actions. Examples of the one or more actions may include, but are not limited to, the audit or compliance check, the security check, the unauthorized access check, and the suspicious activity check. In an embodiment, the end-user may retrieve the trace data record based on their requirement. Examples of the end-user may include, but are not limited to, the network administrator, the team member of regulatory agencies, the compliance officer, the network security professional, and the like. The end-user may retrieve one or more trace data records from the plurality of trace data records corresponding to the UE for a given time range by specifying a time range, e.g., for 7 days. The end-user may retrieve the one or more trace data records associated with the UE for the given time range by entering the start date and the end date based on their requirement. Further, the end-user may utilize the one or more trace data records to identify the one or more anomalies (e.g., any security breach, the unauthorized access, the suspicious activities etc.) in the one or more trace data records associated with the user of the UE. In particular, based on the time range defined by the end user, the one or more trace data records associated with the user of the UE may be retrieved from the database. Further, the one or more trace data records may be analyzed to identify the one or more anomalies in the one or more trace data records. Once the one or more anomalies are identified, the end-user may perform the one or more actions corresponding to the one or more trace data records. In other words, the end-user can retrieve the one or more trace data records to perform the audit or compliance check or the security check to identifying the security breaches, the unauthorized access, or the suspicious activities associated with the user of the UE.
[0092] FIG. 6 illustrates an exemplary computer system 600 in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 6, the computer system 600 may include an external storage device 610, a bus 620, a main memory 630, a read-only memory 640, a mass storage device 650, communication port(s) 660, and a processor 670. A person skilled in the art will appreciate that the computer system 600 may include more than one processor and communication ports. The processor 670 may include various modules associated with embodiments of the present disclosure. The communication port(s) 660 may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 660 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 600 connects.
[0093] The main memory 630 may be Random-Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 640 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor 670. The mass storage device 650 may be any current or future mass storage solution, which can be used to store information and/or instructions. The mass storage device 650 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, a Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.
[0094] The bus 620 communicatively couples the processor 670 with the other memory, storage, and communication blocks. The bus 620 may be, e.g. a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 670 to the computer system 600.
[0095] Optionally, operator and administrative interfaces, e.g. a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus 620 to support direct operator interaction with the computer system 600. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 660. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 600 limit the scope of the present disclosure.
[0096] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.
[0097] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
[0098] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.
[0099] The present disclosure provides technical advancement related to management of trace data for users. This advancement addresses the limitations of existing solutions by facilitating the trace data monitoring using the ERM. The trace data monitoring is performed for auditing, efficient debugging, or identifying security breaches. The present disclosure facilitates the trace data monitoring by generating and storing the trace data record for each event request received from the UEs associated with the users. The trace data records stored for the users provide a clear and detailed view of a flow of events to the end-user in the event-based architecture. The end-user can access the one or more trace data records based on their requirements, e.g., for a given time range (e.g., 10 days). Further, the trace data records stored corresponding to the event requests associated with the users help to perform efficient debugging and troubleshooting of anomalies (e.g., the security breach, the unauthorized access, etc.) within the event-based architecture.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00100] The present disclosure provides a method and a system for managing trace data for users to identify security breaches, unauthorized access, or suspicious activities within an event-based architecture.
[00101] The present disclosure provides a technique to efficiently debug and troubleshoot issues (also referred to as anomalies) by performing trace data monitoring for the users within the event-based architecture.
[00102] The present disclosure provides a clear and detailed view of a flow of events as they move through the event-based architecture.
,CLAIMS:CLAIMS
We claim:
1. A method (500) for managing trace data of users, the method (500) comprising:
receiving (502), by a processing engine (208), an event request from a User Equipment (UE) (104) associated with a user (102);
processing (504), by the processing engine (208), the event request to extract a set of event parameters from the event request;
storing (506), by the processing engine (208), the set of event parameters along with an associated timestamp in a database (210) as a trace data record corresponding to the user (102) associated with the UE (104); and
retrieving (508), by the processing engine (208), the trace data record associated with the user (102) from the database (210) for performing one or more actions.

2. The method (500) as claimed in claim 1, wherein the set of event parameters comprises an event name, an event type, and a username of the user (102) associated with the UE (104).

3. The method (500) as claimed in claim 1, wherein the set of event parameters along with the associated time stamp is stored based on a unique trace Identifier (ID) associated with the event request.

4. The method (500) as claimed in claim 1, wherein the database (210) stores a plurality of trace data records associated with a plurality of event requests received from the UE (104).

5. The method (500) as claimed in claim 4, further comprising:
deleting, by the processing engine (208), each of the plurality of trace data records associated with the UE (104) after an expiry of a configured time period.

6. The method (500) as claimed in claim 1, wherein performing the one or more actions comprises:
analyzing, by the processing engine (208), each trace data record to identify one or more anomalies in one or more trace data records associated with the user of the UE (104).

7. A system (108) for managing trace data of users, the system (108) comprising:
a memory (204); and
a processing engine (208) coupled to the memory (204), configured to:
receive (502) an event request from a User Equipment (UE) (104) associated with a user (102);
process (504) the event request to extract a set of event parameters from the event request;
store (506) the set of event parameters along with an associated timestamp in a database as a trace data record corresponding to the user (102) associated with the UE (104); and
retrieve (508) the trace data record associated with the user (102) from the database for performing one or more actions.

8. The system (108) as claimed in claim 7, wherein the set of event parameters comprises an event name, an event type, and a username of the user (102) associated with the UE (104).

9. The system (108) as claimed in claim 7, wherein the set of event parameters along with the associated time stamp is stored based on a unique trace Identifier (ID) associated with the event request.

10. The system (108) as claimed in claim 7, wherein the database (210) stores a plurality of trace data records associated with a plurality of event requests received from the UE (104).

11. The system (108) as claimed in claim 10, wherein the processing engine (208) is further configured to:
delete each of the plurality of trace data records associated with the UE (104) after an expiry of a configured time period.

12. The system (108) as claimed in claim 7, wherein, to perform the one or more actions, the processing engine (208) is further configured to:
analyze each trace data record to identify one or more anomalies in one or more trace data records associated with the user (102) of the UE (104).

13. A user equipment (UE) (104) communicatively coupled with a network (106), the coupling comprises steps of:
receiving, by the network (106), a connection request from the UE (104);
sending, by the network (106), an acknowledgment of the connection request to the UE (104); and
transmitting a plurality of signals in response to the connection request, wherein based on the connection request, trace data of a user (102) is managed by the method (500) as claimed in claim 1.