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 TRANSFORMING EVENTS IN A NETWORK
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 NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to the field of wireless communication networks, more particularly relates to a method and a system for transforming events in the wireless communication networks.
BACKGROUND OF THE INVENTION
[0002] Currently, where two different integrated systems communicate, Common Application Programming Interface Frameworks (CAPIF) face unexpected issues when events occur. Usually, integration of systems is a one-time activity. However, when some changes in data and information occur, such as data format changes occur on one of the integrated systems, a data mismatch between the two different integrated systems occurs. Existing systems are unable to handle such unexpected situations. In an instance, where such data mismatch occurs during an Application Programming Interface (API) call, then the system fails to work as expected. In such a scenario, it is difficult to identify whether the system failure is related to data, multiple API calls or a single API call.
[0003] Hence, there is a need for a method and system that can identify such events occurring between two different integrated systems, that communicate with each other via the CAPIF. Further, the improved method and system should also identify the events that perform actions on those events on the basis of a rule engine configuration.
SUMMARY OF THE INVENTION
[0004] One or more embodiments of the present disclosure provide a method and a system for transforming events in a network.
[0005] In one aspect of the present invention, the method for transforming the events in the network is disclosed. The method includes the step of receiving, by one or more processors, a request from a consumer. The method includes the step of identifying, by the one or more processors, based on the request, one or more destination entities to which the request is addressed. The method includes the step of checking, by the one or more processors, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities. The method includes the step of determining, by the one or more processors, one or more actions to perform on the one or more asymmetric events if the one or more asymmetric events are present in the request. The method includes the step of implementing, by the one or more processors, the one or more actions to the one or more asymmetric events to transform the request from the consumer to the one or more destination entities.
[0006] In one embodiment, the request is at least one of, an Application Programming Interface (API) call, the request is transmitted from the consumer to the one or more destination entities to availing one or more services.
[0007] In another embodiment, the one or more destination entities includes at least one of, an application in the network.
[0008] In yet another embodiment, the step of, checking, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities, includes the steps of identifying, by the one or more processors, one or more events based on information extracted from the request. The step of, checking, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities, includes the steps of retrieving, by the one or more processors, data pertaining to one or more attributes from the one or more events. The step of, checking, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities, includes the steps of comparing, by the one or more processors, the retrieved one or more attributes with pre-stored attributes pertaining to the one or more destination entities. The step of, checking, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities, includes the steps of inferring, by the one or more processors, that the one or more events are asymmetric when the one or more attributes of the one or more events do not match with the pre-stored attributes in the storage unit.
[0009] In yet another embodiment, the attributes include at least one of, rules and policies.
[0010] In yet another embodiment, the step of, determining, one or more actions to perform on the one or more asymmetric events, includes the steps of identifying, by the one or more processors, one or more non-compatible attributes of the one or more asymmetric events when compared to the pre-stored attributes. The step of, determining, one or more actions to perform on the one or more asymmetric events, includes the steps of identifying, by the one or more processors, from a storage unit, one or more corresponding actions required to be performed based on the identified one or more non-compatible attributes.
[0011] In yet another embodiment, the one or more actions include at least one of, changing one or more rules or one or more policies of the one or more asymmetric events to transform the request from the consumer to the one or more destination entities.
[0012] In yet another embodiment, the method further comprises the steps of receiving, by the one or more processors, a response in relation to the request received from the consumer, wherein configuration of the response is transformed to comply with configuration acceptable by the consumer.
[0013] In another aspect of the present invention, the system for transforming events in a network is disclosed. The system includes a transceiver, configured to, receive, a request from a consumer. The system includes an identification unit, configured to, identify, based on the request, one or more destination entities to which the request is addressed. The system includes a checking unit, configured to, check, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities. The system includes a determining unit, configured to, determine, one or more actions to perform on the one or more asymmetric events if the one or more asymmetric events are present in the request. The system includes an implementation unit, configured to, implement, the one or more actions on the one or more asymmetric events to transform the request from the consumer to the one or more destination entities.
[0014] In yet another aspect of the present invention, a User Equipment (UE) is disclosed. One or more primary processors communicatively coupled to one or more processors. The one or more primary processors coupled with a memory. The memory stores instructions which when executed by the one or more primary processors causes the UE to transmit a request to the one or more processors for availing one or more services from the one or more destination entities.
[0015] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] 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.
[0017] FIG. 1 is an exemplary block diagram of an environment for transforming events in a network, according to one or more embodiments of the present disclosure;
[0018] FIG. 2 is an exemplary block diagram of a system for transforming the events in the network, according to one or more embodiments of the present disclosure;
[0019] FIG. 3 is a schematic representation of a workflow of the system of FIG. 2 communicably coupled with a User Equipment (UE), according to one or more embodiments of the present disclosure;
[0020] FIG. 4 is a block diagram of an architecture of Common Application Programming Interface Frameworks (CAPIF), according to one or more embodiments of the present disclosure;
[0021] FIG. 5 is a flow diagram illustrating a method for transforming the events in the network, according to one or more embodiments of the present disclosure; and
[0022] FIG. 6 is a flow diagram illustrating the method for transforming the events in the network, according to one or more embodiments of the present disclosure.
[0023] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0024] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0025] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0026] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0027] The present invention relates to a system and a method for transforming asymmetric events occurring between different environments. The optimized solution includes an Artificial Intelligence/Machine Learning (AI/ML) based algorithms that are used to identify the asymmetric events and perform one or more actions on the events on basis of an Application Programming Interface (API) events and action rule configuration. The API events and action rule configuration utilize the AI/ML based algorithms to decide and implement the one or more rules and the one or more policies changes to obtain smooth API access, audit all API inbound request, API provider validation, API provider response, and error detection. Further, an API events and action rule engine take all decisions at runtime with the help of the API events and action rule configuration. In this regard, service APIs can be configured at run time without the occurrence of unexpected errors due to asymmetric event.
[0028] Referring to FIG. 1, FIG. 1 illustrates an exemplary block diagram of an environment 100 for transforming events in a network 105, according to one or more embodiments of the present invention. The events refer to any occurrence or change in the state of a network component or system that can be detected and logged. These events are essential for monitoring, managing, and troubleshooting network operations. In an embodiment, the events include, but not limited to, asymmetric events and symmetric events. The asymmetric events refer to inconsistencies, anomalies, or irregular conditions within the request that may not align with the expected state of one or more destination entities. Transforming the asymmetric events to the symmetric events in the network 105 refers to the process of capturing network activities, processing the data to extract meaningful information, and converting the events into a different format or structure that can be analyzed, correlated, or acted upon. The transformation of the events aids in monitoring, managing, and optimizing network performance, security, and operations.
[0029] The environment 100 includes the network 105, a User Equipment (UE) 110, a server 115, and a system 120. The UE 110 aids a consumer to interact with the system 120 for transmitting a request to one or more processors 205 (shown in FIG.2) for availing one or more services from one or more destination entities. In an embodiment, the consumer is one of, but not limited to, user or any application or Application Programming Interface (API) invoker sending API requests. . In an embodiment, the request is at least one of, an Application Programming Interface (API) call.
[0030] The request pertains to availing the one or more services from the one or more destination entities. In an embodiment, the one or more services include, but not limited to, data management services, communication services, transaction services, user authentication and security services. In an embodiment, the one or more destination entities includes at least one of, an application in the network 105. In an embodiment, the application in the network 105 includes, but not limited to, web applications, enterprise applications, telecommunication applications, AR/VR/XR applications, IOT applications, and database applications.
[0031] For the purpose of description and explanation, the description will be explained with respect to the UE 110, or to be more specific will be explained with respect to a first UE 110a, a second UE 110b, and a third UE 110c, and should nowhere be construed as limiting the scope of the present disclosure. Each of the UE 110 from the first UE 110a, the second UE 110b, and the third UE 110c is configured to connect to the server 115 via the network 105. In an embodiment, each of the first UE 110a, the second UE 110b, and the third UE 110c is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as smartphones, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device.
[0032] The network 105 includes, by way of example but not limitation, one or more of a wireless network, a wired network, 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. The network 105 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0033] The server 115 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, 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. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise, a defense facility, or any other facility that provides content.
[0034] The environment 100 further includes the system 120 communicably coupled to the server 115 and each of the first UE 110a, the second UE 110b, and the third UE 110c via the network 105. The system 120 is configured for transforming the events in the network 105. The system 120 is adapted to be embedded within the server 115 or is embedded as the individual entity, as per multiple embodiments of the present invention. Operational and construction features of the system 120 will be explained in detail with respect to the following figures.
[0035] FIG. 2 is an exemplary block diagram of a system 120 for transforming the events in the network 105, according to one or more embodiments of the present disclosure.
[0036] The system 120 includes a processor 205, a memory 210, a user interface 215, and a database 245. For the purpose of description and explanation, the description will be explained with respect to one or more processors 205, or to be more specific will be explained with respect to the processor 205 and should nowhere be construed as limiting the scope of the present disclosure. The one or more processor 205, hereinafter referred to as the processor 205 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions.
[0037] As per the illustrated embodiment, the processor 205 is configured to fetch and execute computer-readable instructions stored in the memory 210. The memory 210 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 210 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.
[0038] The user interface 215 includes a variety of interfaces, for example, interfaces for a Graphical User Interface (GUI), a web user interface, a Command Line Interface (CLI), and the like. The user interface 215 facilitates communication of the system 120. In one embodiment, the user interface 215 provides a communication pathway for one or more components of the system 120. Examples of the one or more components include, but are not limited to, the UE 110, and the storage unit 245. The term “storage unit” and “database” are used interchangeably hereinafter, without limiting the scope of the disclosure.
[0039] The database 245 is one of, but not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 245 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0040] Further, the processor 205, in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 205. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 205 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for processor 205 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor 205. In such examples, the system 120 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 120 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.
[0041] In order for the system 120 to transform the events in the network 105, the processor 205 includes a transceiver 220, an identification unit 225, a checking unit 230, a determining unit 235, and an implementation unit 240 communicably coupled to each other. In an embodiment, operations and functionalities of the transceiver 220, the identification unit 225, the checking unit 230, the determining unit 235, and the implementation unit 240 can be used in combination or interchangeably.
[0042] The transceiver 220 is configured to receive the request from the consumer. In an embodiment, the request is at least one of, an Application Programming Interface (API) call. The API call is a communication request made by the consumer to the one or more services via the API. The API call is processed by the transceiver 220, which acts as an intermediary between the consumer and the one or more destination entities. The API call is the communication request sent from the consumer to the server 115 or the one or more services via the API. The API call is used to access or manipulate data, invoke specific functionalities, or request services provided by the server 115. In an embodiment, the one or more destination entities as defined as service providers, providing one or more services. In an embodiment, the one or more destination entities referred as an API producer or an API provider. The request pertains to availing the one or more services from the one or more destination entities. In an embodiment, the one or more services include, but not limited to, data management services, communication services, transaction services, consumer authentication and security services. In an exemplary embodiment, the one or more services include, but not limited to, Network Slice Selection Function (NSSF), Policy Control Function (PCF), Unified Data Management (UDM), Session Management Function (SMF), and Access and Mobility Management (AMF). In an embodiment, the consumer is one of, but not limited to, the network operator or the service provider. In an embodiment, the one or more destination entities includes at least one of the applications in the network 105. Upon receiving the request from the consumer by the transceiver 220, the transceiver 220 transmits the request to the identification unit 225.
[0043] The identification unit 225 is configured to identify the one or more destination entities to which the request is addressed by analyzing relevant information contained within the request. In an embodiment, the one or more destination entities includes at least one of the applications in the network 105. The identification unit 225 is configured to parse the request to extract the relevant information, such as destination addresses, entity identifiers, query parameters or other metadata. Upon extracting the relevant information from the request, the identification unit 225 is configured to map the extracted information to the one or more destination entities. The mapping of the extracted information to the one or more destination entities involves looking up the database 245, using an internal mapping table, or consulting a directory service such as API service repository 455 (as shown in FIG. 4) that correlates request data with the corresponding one or more destination entities.
[0044] Upon identification of the one or more destination entities, the request is transmitted to the checking unit 230. The checking unit 230 is configured to check whether the one or more asymmetric events are present in the request in relation to the identified one or more destination entities. The one or more asymmetric events refer to inconsistencies, anomalies, or irregular conditions within the request that may not align with the expected state of the one or more destination entities. In an example, the request contains the information that doesn’t match a current state or configuration of the one or more destination entities. The checking unit 230 extracts relevant information from the incoming request. In an embodiment, the information may include parameters, data fields, or context details pertinent to the request. In an example, if the request is the API call to update consumer data, the information extracted includes a consumer ID, new data values, and the type of update operation.
[0045] Furthermore, the checking unit 230 is configured to identify the one or more events based on the information extracted from the request. The one or more events are related to system changes, status updates, or operational triggers. The checking unit 230 is further configured to retrieve the data pertaining to one or more attributes from the one or more events. In an embodiment, the one or more attributes include at least one of, one or more rules and one or more policies. In an embodiment, the one or more rules and the one or more policies are defined and stored in the database 245. The information extracted from the request is automatically processed with the one or more rules and the one or more policies stored in an API event and action rule engine 445 (as shown in FIG. 4). In another embodiment, the one or more rules and the one or more policies are defined by the consumer. The one or more attributes includes various properties or characteristics of the one or more events, such as the type of action, resource demand, time of request, or security credentials. The data for the one or more attributes is obtained from the one or more sources. In an embodiment, the one or more sources include, but not limited to, consumer inputs, system logs, APIs, and databases.
[0046] Upon retrieving the data pertaining to the one or more attributes from the one or more events, the checking unit 230 is further configured to compare the retrieved one or more attributes with pre-stored attributes pertaining to the one or more destination entities. The retrieved one or more attributes of the identified one or more events are compared against the pre-stored attributes. The pre-stored attributes are stored in the database 245 within the system 120 and represent predefined values for the one or more destination entities. The pre-stored attributes include acceptable ranges for resource usage, valid actions, permitted access levels, and other operational parameters.
[0047] Upon comparing the retrieved one or more attributes with the pre-stored attributes, the checking unit 230 is further configured to infer that the one or more events are asymmetric when the one or more attributes of the one or more events do not match with the pre-stored attributes in the storage unit 245. The one or more asymmetric events signifies the anomaly, such as an unauthorized access attempt, the request for excessive resources, changing in an input path, or the request and the response that conflicts with the current state of the one or more destination entities.
[0048] Upon inferring that the one or more events are asymmetric, the determining unit 235 is configured to determine one or more actions to perform on the one or more asymmetric events to transform the request and the response from an API provider . The determining unit 235 is configured to detect variations or inconsistencies, such as differences in data patterns, timing discrepancies, rule violations, or policy mismatches, that cause the events to be classified as asymmetric. In an embodiment, the one or more actions include at least one of, changing one or more rules or one or more policies of the one or more asymmetric events to transform the request and the response from the API provider. The determining unit 235 implements the one or more actions by directly changing the one or more rules, one or more policies, and one or more parameters associated with the one or more asymmetric events.
[0049] Upon determining the one or more actions to perform on the one or more asymmetric events, the determining unit 235 is configured to identify one or more non-compatible attributes of the one or more asymmetric events when compared to the pre-stored attributes. If the one or more attributes of the one or more asymmetric events deviate from the expected or predefined attributes, the deviated one or more attributes is flagged as non-compatible. In an example, if an event processing time exceeds pre-stored maximum allowed time, timing attributes would be identified as non-compatible attribute. In an exemplary embodiment, the system 120 is designed to handle the one or more attributes of the one or more asymmetric events, and the pre-stored maximum allowed time for processing the one or more attributes of the one or more asymmetric events is set to 200 milliseconds. If the one or more attributes of the one or more asymmetric events takes 250 milliseconds, the system 120 identifies as exceeding the pre-stored maximum allowed time. Once the non-compatible attributes are identified, the determining unit 235 is configured to identify the one or more corresponding actions required to be performed based on the identified one or more non-compatible attributes from the storage unit 245. In an embodiment, the one or more corresponding actions include, but not limited to, alert generation, event logging, re-routing or load balancing, and resource allocation. In an exemplary embodiment, if the non-compatible one or more attributes are detected, such as an event's processing time exceeding the pre-stored maximum allowed time, the system 120 generates an alert to notify the network operator or relevant personnel about the issue.
[0050] Upon determination of the one or more corresponding actions, the implementation unit 240 is configured to implement the one or more corresponding actions to the one or more asymmetric events to transform the request from the consumer to the one or more destination entities. The implementation unit 240 proceeds to execute or apply the determined one or more corresponding actions directly to the identified asymmetric events. The one or more actions include, but is not limited to, changing the one or more rules and the one or more policies of the one or more asymmetric events, altering event attributes, and modifying data. In one exemplary embodiment, if the one or more actions involves changing of the one or more rules, the implementation unit 240 updates the event’s processing sequence or timing parameters. In another exemplary embodiment, if the one or more actions require changing of the one or more policies, the implementation unit 240 enforces a new security protocol or compliance measure on the event. After implementing the one or more actions, the implementation unit 240 successfully transforms the request from the consumer to the API provider and ensures that the one or more events are now compliant with the pre-stored attributes.
[0051] Upon successfully transforming the one or more asymmetric events based on the request received from the consumer to the one or more destination entities, the transceiver 220 is further configured to receive the response in relation to the request received from the consumer. In an embodiment, configuration of the response is transformed to comply with configuration acceptable by the consumer. Once the response is transformed to meet the consumer acceptable configuration, the transceiver 220 transmits the response back to the consumer, ensuring seamless communication and compatibility.
[0052] By doing transformation of the request and response from the API provider, the system 120 is able to, advantageously, configure the service APIs, changing the one or more rules and the one or more policies at run time in a dynamic way without the occurrence of unexpected errors due to the one or more asymmetric events. Further, the system 120 ensures transformation of the request and response from the API provider, which improves processing speed, and reduces memory space requirement by taking the corrective one or more actions.
[0053] FIG. 3 is a schematic representation of a workflow of the system 120 of FIG. 2 communicably coupled with a User Equipment (UE), according to one or more embodiments of the present disclosure. More specifically, FIG. 3 illustrates the system 120 configured for transforming the events in the network 105. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE 110a for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0054] As mentioned earlier in FIG.1, in an embodiment, the first UE 110a may encompass electronic apparatuses. These devices are illustrative of, but not restricted to, modems, routers, switches, laptops, tablets, smartphones (including phones), or other devices enabled for web connectivity. The scope of the first UE 110a explicitly extends to a broad spectrum of electronic devices capable of executing computing operations and accessing networked resources, thereby providing users with a versatile range of functionalities for both personal and professional applications. This embodiment acknowledges the evolving nature of electronic devices and their integral role in facilitating access to digital services and platforms. In an embodiment, the first UE 110a can be associated with multiple users. Each of the first UE 110a is communicatively coupled with the processor 205.
[0055] The first UE 110a includes one or more primary processors 305 communicably coupled to the one or more processors 205 of the system 120. The one or more primary processors 305 are coupled with a memory 310 storing instructions which are executed by the one or more primary processors 305. Execution of the stored instructions by the one or more primary processors 305 enables the first UE 110a to transmit the request to the one or more processors 205 for availing the services from the one or more destination entities.
[0056] Furthermore, the one or more primary processors 305 within the first UE 110a are uniquely configured to execute a series of steps as described herein. This configuration underscores the processor 205 capability to transform the events in the network 105. The coordinated functioning of the one or more primary processors 305 and the additional processors, is directed by the executable instructions stored in the memory 310. The executable instructions facilitate seamless communication and compatibility among the one or more primary processors 305, optimizing performance and resource use.
[0057] As mentioned earlier in FIG.2, the system 120 includes the one or more processors 205, the memory 210, the user interface 215, and the database 245. The operations and functions of the one or more processors 205, the memory 210, the user interface 215, and the database 245 are already explained in FIG. 2. For the sake of brevity, a similar description related to the working and operation of the system 120 as illustrated in FIG. 2 has been omitted to avoid repetition.
[0058] Further, the processor 205 includes the transceiver 220, the identification unit 225, the checking unit 230, the determining unit 235, and the implementation unit 240. The operations and functions of the transceiver 220, the identification unit 225, the checking unit 230, the determining unit 235, and the implementation unit 240 are already explained in FIG. 2. Hence, for the sake of brevity, a similar description related to the working and operation of the system 120 as illustrated in FIG. 2 has been omitted to avoid repetition. The limited description provided for the system 120 in FIG. 3, should be read with the description provided for the system 120 in the FIG. 2 above, and should not be construed as limiting the scope of the present disclosure.
[0059] FIG. 4 is a block diagram of an architecture 400Common Application Programming Interface Frameworks (CAPIF) , according to one or more embodiments of the present disclosure.
[0060] The CAPIF is a standardized framework designed to facilitate and manage interactions between different network functions and services via one or more APIs. The CAPIF provides a common platform for integrating and automating the services, enabling seamless communication and orchestration within a network environment. The CAPIF manages API access, usage, and performance, including rate limiting, authentication, and authorization, to ensure secure and efficient interactions between the services. The CAPIF supports automation and orchestration of network functions and services by allowing predefined actions to be triggered based on API events. The architecture 400 of the CAPIF includes an API consumer 405, an Edge Load Balancer (ELB) 410, an Identity and access Management (IAM) 415, an API gateway 420, and an API service repository 455.
[0061] The architecture 400 of the CAPIF includes an API consumer 405. In an embodiment, the API consumer 405 develops applications or web sites using the APIs. In an embodiment, the API consumer 405 are the consumers of APIs. The API consumer 405 is communicably connected to the ELB 410. The ELB 410 is configured to route the API call request from the API consumer 405 to the destination application based on rules like round robin, context-based routing, header-based routing, or TCP based routing. The ELB 410 is configured to automatically distribute the incoming API traffic from entities such as the API consumer 405 across multiple targets, such as servers 115. In the present invention, the request may be sent from the API consumer 405 to the server 115 requesting network resources from the server 115.
[0062] The architecture 400 further includes the IAM 415. In an embodiment, the IAM 415 is a web service that facilitates securely control access to system resources. The IAM 415 is configured to centrally manage permissions or provides authentication to the API consumer 405.
[0063] The ELB 410 transmits the API traffic to the API gateway 420. The API gateway 420 is a data-plane entry point for API calls that represent consumer requests to target applications and services. The API gateway 420 typically performs request processing based on one or more predefined policies, including authentication, authorization, access control, Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) offloading, routing, and load balancing.
[0064] The API gateway 420 further includes an API orchestration configuration 425, an API events and action rule configuration 430, an API sync call 435, an API response collection 440, an API events and action rule engine 445, and an API async call 450.
[0065] The API orchestration configuration 425 allows multiple ways of routing east bound API calls to multiple west bound API calls. The API events and action rule configuration 430, includes configuration files inbuilt that enable transforming the request as per the one or more destination entities and also transforming the response as required by the API consumer 405. In an embodiment, the one or more rules and the one or more policies include, but not limited to, inbound request data transformation rule, API request definition, API request validation rule and action, API response definition, API response validation rule and action, and outbound response data transformation rule. The dynamic transformation and manipulation of API data facilitates body to body transformation and manipulation, query parameters transformation and manipulation, and header transformation and manipulation.
[0066] The Template-Based API Provisioning is a process of creating, deploying, and managing APIs (Application Programming Interfaces) using predefined templates. In an embodiment, the predefined templates include standardized configurations, structures, and settings that define the API's behavior, endpoints, security policies, and other essential components, which ensures streamlining of the API development process, allowing for rapid, consistent, and efficient API deployment. API architects create the predefined templates that define the structure and behavior of the APIs. In an embodiment, the predefined templates include details such as endpoints, HTTP methods (GET, POST, etc.), data formats (JSON, XML), security policies (authentication, authorization), rate limiting, and other configurations. When there is a need for a new API, the request is made to create the API based on one of the predefined templates. The request is triggered manually by API architects or automatically based on certain conditions or triggers in the system. Once provisioned, the API is managed through the API gateway 420, which handles traffic routing, load balancing, monitoring, and logging. The API gateway 420 ensures that the API operates efficiently and securely. Furthermore, the template-based service API provisioning allows the consumer to create and manage the APIs on-demand. The template-based service API provisioning is done using the API gateway 420, as it improves the agility, flexibility, and cost-efficiency of API development and management process as the API is integrated dynamically.
[0067] In an embodiment, the API events and action rule configuration 430 utilizes an Artificial Intelligence/Machine Learning (AI/ML) based algorithms to decide and implement the one or more rules and the one or more policies changes to obtain smooth API access, audit all API inbound request, API provider validation, API provider response, and error detection. The API events and action rule engine 445 takes all decisions at runtime with the help of the API events and action rule configuration 430.
[0068] Further, the API sync call 435, provide synchronous APIs. The synchronous APIs provide the response with minimal elapsed time. Conversely, the API asynchronous call 450 performs an asynchronous operation, which ensures when the API consumer 405 sends the request to the server 115, the API consumer 405 does not wait for an immediate response. Instead, the API consumer 405 continues with other tasks, and the server 115 processes the request in a backend. Further, the consumer transmits the request for the availing services and is prepared to receive the system’s response later.
[0069] The API response collection 440 may include the location where the data or information that is returned from the server 115 is stored when the API request is transmitted. Further, when the API call is made to the one or more API providers in the asynchronous mode, the service may allow the consumer to conduct multiple requests at the same time without waiting for the previous request to be executed. In this regard, the server 115 may process multiple requests at the same time, decreasing the APIs overall response time.
[0070] The architecture 400 of the system 120 further includes API service repository 455. The API service repository 455 includes, but not limited to, databases, data lakes, data containers, persistence cache and distributed cache, etc. The API service repository 455 may be a catalogue in which all the services available on the network 105 are stored.
[0071] FIG. 5 is a flow diagram illustrating a method 500 for transforming the events in the network 105, according to one or more embodiments of the present disclosure. For the purpose of description, the method 500 is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0072] At step 505, the method 500 includes the step of receiving the request from the consumer by the transceiver 220. In an embodiment, the request is at least one of, the Application Programming Interface (API) call. The request is transmitted from the consumer to the one or more destination entities. The request pertains to availing one or more services from the one or more destination entities. In an embodiment, the one or more destination entities as defined as service providers, providing one or more services. In an embodiment, the one or more destination entities referred as the API producer or the API provider. In an embodiment, the one or more services include, but not limited to, data management services, communication services, transaction services, consumer authentication and security services. In an embodiment, the consumer is one of, but not limited to, the network operator or the service provider. In an embodiment, the one or more destination entities includes at least one of the applications in the network 105.
[0073] At step 510, the method 500 includes the step of identifying the one or more destination entities to which the request is addressed by analyzing relevant information contained within the request by the identification unit 225. In an embodiment, the one or more destination entities includes at least one of the applications in the network 105. The identification unit 225 is configured to parse the request to extract the relevant information, such as destination addresses, entity identifiers, or other metadata. Upon extracting the relevant information from the request, the identification unit 225 is configured to map the extracted information to the one or more destination entities.
[0074] At step 515, the method 500 includes the step of checking whether the one or more asymmetric events are present in the request in relation to the identified one or more destination entities by the checking unit 230. The one or more asymmetric events refer to inconsistencies, anomalies, or irregular conditions within the request that may not align with the expected state of the one or more destination entities. In an example, the request contains the data that doesn’t match a current state or configuration of the one or more destination entities.
[0075] At step 520, the method 500 includes the step of determining the one or more actions to perform on the one or more asymmetric events by the determining unit 235. The determining unit 235 is configured to detect variations or inconsistencies, such as differences in data patterns, timing discrepancies, rule violations, or policy mismatches, that cause the events to be classified as asymmetric. In an embodiment, the one or more actions include at least one of, changing one or more rules or one or more policies of the one or more asymmetric events to transform the request and response from the API provider.
[0076] At step 525, the method 500 includes the step of implementing the one or more actions on the one or more asymmetric events to transform the request from the consumer to the one or more destination entities by the implementation unit 240. The implementation unit 240 proceeds to execute or apply the determined one or more corresponding actions directly to the identified asymmetric events. The one or more actions include, but are not limited to, changing the one or more rules and the one or more policies of the one or more asymmetric events, altering event attributes, and modifying data. After implementing the one or more actions, the implementation unit 240 successfully transforms the one or more asymmetric events to the one or more symmetric events and ensures that the one or more events are now compliant with the pre-stored attributes.
[0077] FIG. 6 is a flow diagram illustrating a method 600 for transforming the events in the network 105, according to one or more embodiments of the present disclosure.
[0078] At step 605, the method 600 includes the step of identifying the one or more events based on the information extracted from the request.
[0079] At step 610, the method 600 includes the step of retrieving the data pertaining to one or more attributes from the one or more events by the checking unit 230. In an embodiment, the one or more attributes include at least one of, one or more rules and one or more policies. In an embodiment, the one or more rules and the one or more policies are defined and stored in the database 245.
[0080] At step 615, the method 600 includes the step of comparing the retrieved one or more attributes with pre-stored attributes pertaining to the one or more destination entities by the checking unit 230. The retrieved one or more attributes of the identified one or more events are compared against the pre-stored attributes. The pre-stored attributes are stored in the database 245 within the system 120 and represent predefined values for the one or more destination entities.
[0081] At step 620, the method 600 includes the step of inferring that the one or more events are asymmetric when the one or more attributes of the one or more events do not match with the pre-stored attributes in the storage unit 245 by the checking unit 230. The one or more asymmetric events signifies the anomaly, such as an unauthorized access attempt, the request for excessive resources, or the request that conflicts with the current state of the one or more destination entities.
[0082] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-6) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0083] The present disclosure provides technical advancement for transforming the one or more asymmetric events to the one or more symmetric events by taking the one or more actions. The present invention configures the service APIs, ensures changing the one or more rules and the one or more policies at run time in a dynamic way without the occurrence of unexpected errors due to the one or more asymmetric events. Further, the system ensures transformation of the one or more asymmetric events to the one or more symmetric events, which improves processing speed, and reduces memory space requirement by taking the corrective one or more actions.
[0084] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS

[0085] Environment - 100
[0086] Network-105
[0087] User equipment- 110
[0088] Server - 115
[0089] System -120
[0090] Processor - 205
[0091] Memory - 210
[0092] User interface-215
[0093] Transceiver – 220
[0094] Identification unit– 225
[0095] Checking unit – 230
[0096] Determining unit- 235
[0097] Implementation unit- 240
[0098] Database– 245
[0099] Primary processor- 305
[00100] Memory– 310
[00101] Architecture- 400
[00102] API consumer- 405
[00103] Edge Load Balancer- 410
[00104] Identity and Access Management- 415
[00105] API gateway- 420
[00106] API orchestration configuration- 425
[00107] API events and action rule configuration - 430
[00108] API sync call- 435
[00109] API response collection- 440
[00110] API events and action rule engine - 445
[00111] API async call- 450
[00112] API service repository- 455
,CLAIMS:CLAIMS
We Claim:
1. A method (500) to transform events in a network (105), the method (500) comprises the steps of:
receiving, by one or more processors (205), a request from a consumer;
identifying, by the one or more processors (205), based on the request, one or more destination entities to which the request is addressed;
checking, by the one or more processors (205), whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities; and
if the one or more asymmetric events are present in the request, determining, by the one or more processors (205), one or more actions to perform on the one or more asymmetric events; and
implementing, by the one or more processors (205), the one or more actions on the one or more asymmetric events to transform the request from the consumer to the one or more destination entities.

2. The method (500) as claimed in claim 1, wherein the request is at least one of, an Application Programming Interface (API) call, the request is transmitted from the consumer to the one or more destination entities to availing one or more services.

3. The method (500) as claimed in claim 1, wherein the one or more destination entities includes at least one of, an application in the network (105).

4. The method (500) as claimed in claim 1, wherein the step of, checking, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities, includes the steps of:
identifying, by the one or more processors (205), one or more events based on information extracted from the request;
retrieving, by the one or more processors (205), data pertaining to one or more attributes from the one or more events;
comparing, by the one or more processors (205), the retrieved one or more attributes with pre-stored attributes pertaining to the one or more destination entities; and
inferring, by the one or more processors (205), that the one or more events are asymmetric when the one or more attributes of the one or more events do not match with the pre-stored attributes in a storage unit (245).

5. The method (500) as claimed in claim 4, wherein the attributes include at least one of, rules and policies.

6. The method (500) as claimed in claim 1, wherein the step of, determining, one or more actions to perform on the one or more asymmetric events, includes the steps of:
identifying, by the one or more processors (205), one or more non-compatible attributes of the one or more asymmetric events when compared to the pre-stored attributes; and
identifying, by the one or more processors (205), from the storage unit (245), one or more corresponding actions required to be performed based on the identified one or more non-compatible attributes.

7. The method (500) as claimed in claim 6, wherein the one or more actions include at least one of, changing one or more rules or one or more policies of the one or more asymmetric events to transform the request from the consumer to the one or more destination entities.

8. The method (500) as claimed in claim 1, wherein the method (500) further comprises the steps of:
receiving, by the one or more processors (205), a response in relation to the request received from the consumer, wherein configuration of the response is transformed to comply with configuration acceptable by the consumer.

9. A system (120) to transform events in a network (105), the system (120) comprising:
a transceiver (220), configured to, receive, a request from a consumer;
an identification unit (225), configured to, identify, based on the request, one or more destination entities to which the request is addressed;
a checking unit (230), configured to, check, whether one or more asymmetric events are present in the request in relation to the identified one or more destination entities; and
if the one or more asymmetric events are present in the request, a determining unit (235), configured to, determine, one or more actions to perform on the one or more asymmetric events; and
an implementation unit (240), configured to, implement, the one or more actions on the one or more asymmetric events to transform the request from the consumer to the one or more destination entities.

10. The system (120) as claimed in claim 9, wherein the request is at least one of, an Application Programming Interface (API) call, the request is transmitted from the consumer to the one or more destination entities to availing one or more services.

11. The system (120) as claimed in claim 9, wherein the one or more destination entities includes at least one of, an application in the network (105).

12. The system (120) as claimed in claim 9, wherein the checking unit (225), checks, whether the one or more asymmetric events are present in the request in relation to the identified one or more destination entities, by:
identifying, one or more events based on information extracted from the request;
retrieving, data pertaining to one or more attributes from the one or more events;
comparing, the retrieved one or more attributes with pre-stored attributes pertaining to the one or more destination entities; and
inferring, that the one or more events are asymmetric when the one or more attributes of the one or more events do not match with the pre-stored attributes in a storage unit (245).

13. The system (120) as claimed in claim 12, wherein the attributes include at least one of, rules and policies.

14. The system (120) as claimed in claim 9, wherein the determining unit (235), determines, the one or more actions to perform on the one or more asymmetric events, by:
identifying, one or more non-compatible attributes of the one or more asymmetric events when compared to the pre-stored attributes; and
identifying, from the storage unit (245), one or more corresponding actions required to be performed based on the identified one or more non-compatible attributes.

15. The system (120) as claimed in claim 9, wherein the one or more actions include at least one of, changing one or more rules or one or more policies of the one or more asymmetric events to transform the request from the consumer to the one or more destination entities.

16. The system (120) as claimed in claim 9, wherein the transceiver (220) is further configured to:
receive, a response in relation to the request received from the consumer, wherein configuration of the response is transformed to comply with configuration acceptable by the consumer.

17. A User Equipment (UE) (110), comprising:
one or more primary processors (305) communicatively coupled to one or more processors (205), the one or more primary processors (305) coupled with a memory (310), wherein said memory (310) stores instructions which when executed by the one or more primary processors (305) causes the UE (110) to:
transmit, a request to the one or more processors (205) for availing one or more services from the one or more destination entities;
wherein the one or more processors (205) is configured to perform the steps as claimed in claim 1.