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 ONE OR MORE REQUESTS 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 managing one or more requests in the wireless communication networks.
BACKGROUND OF THE INVENTION
[0002] Applications and services rely heavily on Application Programming Interface (API) call flows to communicate with each other. These APIs, which enable different software systems to communicate and interact with one another, are essential for modern software applications, but they also introduce potential security vulnerabilities.
[0003] Further telecommunications service providers rely extensively on the APIs to facilitate the exchange of data and services between various network elements, applications, and devices. Ensuring the security, integrity, and compliance of the APIs is crucial to maintaining the reliability and confidentiality of telecommunications services.
[0004] API auditing, a fundamental aspect of telecommunications security, involves monitoring and analyzing the behavior of APIs to detect and prevent unauthorized access, data breaches, or security vulnerabilities. Effective auditing is essential for ensuring regulatory compliance, safeguarding customer data, and preventing cyberattacks.
[0005] Traditionally, the API auditing relies on the use of auditor's rules, and a predefined set of conditions, criteria, and policies that dictate what aspects of API interactions should be monitored, logged, and assessed. These rules are configured in advance based on known security risks and compliance requirements.
[0006] However, the telecommunications industry faces unique challenges due to its dynamic and ever-evolving nature. The introduction of new services, network elements, and devices, as well as emerging cybersecurity threats, necessitates a more adaptive and responsive approach to the API auditing.
[0007] The dynamic configuration of the auditor's rules for the API auditing in telecommunications seeks to address these challenges. It involves the development of a system or methodology that can automatically adapt and adjust auditing criteria based on real-time data, network conditions, threat intelligence, and regulatory changes. This innovation aims to create a dynamic and proactive auditing system tailored to the specific needs of telecommunications providers.
[0008] Another challenge with shared and integrated API is at times that an API provider is not accessible to consumers due to some technical reason, or API response is not received, API response is not as expected, API subscriber or consumer is not sending proper request as mentioned in an API document shared by the API Provider.
SUMMARY OF THE INVENTION
[0009] One or more embodiments of the present disclosure provide a method and a system for managing one or more requests in a network.
[0010] In one aspect of the present invention, the method for managing the one or more requests in the network is disclosed. The method includes the step of receiving, by one or more processors, a request from a user. 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 extracting, by the one or more processors, one or more rules and parameters from the request. The method includes the step of locating, by the one or more processors, from a rule and configuration engine, at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities. The method includes the step of checking, by the one or more processor, whether the extracted one or more rules and parameters from the request match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities from the rule and configuration engine. The method includes the step of detecting, by the one or more processors, an anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities based on the extraction of the one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities. The method further includes the steps of implementing, by the one or more processors, one or more actions based on the detected anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities.
[0011] In one embodiment, the request is at least one of, an Application Programming Interface (API) call and the request pertains to availing one or more services from the one or more destination entities.
[0012] In another embodiment, the one or more destination entities includes at least one of, an application in the network.
[0013] In yet another embodiment, the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, include data pertaining to at least one of, API user, accessibility of an API provider, nature of response received from the API provider, expected API response time, reception of an API response, API provider being in a working condition.
[0014] In yet another embodiment, the rule and configuration engine configured to decide and implement the one or more runtime configurable parameters or rules based on a training model.
[0015] In yet another embodiment, receiving, by the one or more processors, one or more parameters or rules from a User Equipment (UE) in real-time.
[0016] In yet another embodiment, the one or more actions include, at least one of, sending alerts or notifications, dynamically configuring the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, and generating a report.
[0017] In yet another embodiment, the method further includes the steps of generating, by the one or more processors, the report pertaining to at least one of detection of the anomaly of the extracted one or more rules and parameters from the request with respect to, the located one or more runtime configurable parameters or rules. the method further includes the steps of generating, by the one or more processors, a report pertaining to at least one of displaying, by the one or more processors, the generated report to an administrator on a user interface.
[0018] In another aspect of the present invention, the system for managing the one or more requests in the network is disclosed. The system includes a transceiver, configured to receive a request from a user. 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 an extraction unit configured to extract one or more rules and parameters from the request. The system includes a locating unit configured to locate from a rule and configuration engine, at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities. The system includes a checking unit configured to check whether the extracted one or more rules and parameters from the request match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities from the rule and configuration engine. The system includes, a detecting unit configured to detect, an anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities, when the extracted one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules. The system further includes an implementing unit configured to implement one or more actions based on the detected anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities.
[0019] In 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 said 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 services from the one or more destination entities.
[0020] In another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor. The processor is configured to receive a request from a user. The processor is configured to identify, based on the request, one or more destination entities to which the request is addressed. The processor is configured to extract one or more rules and parameters from the request. The processor is configured to locate, from a rule and configuration engine, at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities. The processor is configured to check whether the extracted one or more rules and parameters from the request match with the located one or more runtime configurable parameters or rules from the rule and configuration engine. The processor is configured to detect, an anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities, when the extracted one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules. The processor is configured to implement one or more actions based on the detected anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities.
[0021] 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
[0022] 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.
[0023] FIG. 1 is an exemplary block diagram of an environment for managing one or more requests in a network, according to one or more embodiments of the present disclosure;
[0024] FIG. 2 is an exemplary block diagram of a system for managing the one or more requests in the network, according to one or more embodiments of the present disclosure;
[0025] 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;
[0026] FIG. 4 is a block diagram of an architecture that can be implemented in the system of FIG.2, according to one or more embodiments of the present disclosure; and
[0027] FIG. 5 is a flow diagram illustrating a method for managing the one or more requests in the network, according to one or more embodiments of the present disclosure.
[0028] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0029] 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.
[0030] 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.
[0031] 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.
[0032] The present disclosure of the invention provides a system and a method to manage one or more requests in a network. The present invention is directed towards dynamically configuring an Application Programming Interface (API) auditor’s service and action rule engine, which performs API auditing to check if the API is working as expected, end point accessibility of the API, response from the API as per API document provided by the API Provider. In an aspect of the exemplary embodiment, the system may be deployed in a framework. The framework may be a form of a Common API Framework (CAPIF) configured to provide unified and standardized access to the API for northbound API calls. The framework deployed as the system comprises the auditor’s service and action rule engine. The auditor’s service and action rule engine enabled to manage or configure the one or more requests, during start-up time or run-time, at least one parameter, from API subscriber or customer request data, or accessibility to the API Provider, or response from the API Provider, or response time of the API, or response received from the API, or working status of the API provider.
[0033] Referring to FIG. 1, FIG. 1 illustrates an exemplary block diagram of an environment 100 for managing one or more requests in a network 105, according to one or more embodiments of the present invention. The environment 100 includes the network 105, a User Equipment (UE) 110, a server 115, and a system 120. The UE 110 aids a user to interact with the system 120 for transmitting the one or more requests to one or more processors 205 (as shown in FIG.2) for availing one or more services from one or more destination entities. In an embodiment, the user is one of, but not limited to, a network operator or a service provider. In an embodiment, the one or more requests is at least one of, but not limited to, an Application Programming Interface (API) call. The API call refers to a specific type of request made by the UE 110 to interact with the system 120 for accessing or utilizing the one or more services provided by the one or more destination entities. The API call is a way for the UE 110 to communicate with the one or more processors 205, requesting certain operations or data. The one or more requests 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 is 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, but not limited to, an application in the network 105. In an embodiment, the application in the network 105 includes, but not limited to, web applications, enterprise applications, communication applications, and database applications.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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 managing the one or more requests 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.
[0038] Operational and construction features of the system 120 will be explained in detail with respect to the following figures.
[0039] FIG. 2 is an exemplary block diagram of a system 120 for managing the one or more requests in the network 105, according to one or more embodiments of the present disclosure.
[0040] The system 120 includes a processor 205, a memory 210, a user interface 215, and a database 260. 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.
[0041] 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.
[0042] 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 database 260.
[0043] The database 260 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 260 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.
[0044] 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.
[0045] In order for the system 120 to manage the one or more requests in the network 105, the processor 205 includes a transceiver 220, an identification unit 225, an extraction unit 230, a locating unit 235, a checking unit 240, a detecting unit 245, a report generating unit 250, a displaying unit 255, and an implementing unit 265 communicably coupled to each other. In an embodiment, operations and functionalities of the transceiver 220, the identification unit 225, the extraction unit 230, the locating unit 235, the checking unit 240, the detecting unit 245, the report generating unit 250, the displaying unit 255, and the implementing unit 265 can be used in combination or interchangeably.
[0046] The transceiver 220 is configured to receive the one or more requests from the user. The one or more requests are transmitted to the processor 205 via the UE 110 from the one or more destination entities. In an embodiment, the one or more requests is at least one of, an Application Programming Interface (API) call. The one or more requests 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 user is one of, but not limited to, the network operator or the service provider. In an embodiment, one or more parameters or rules are extracted from the UE 110 in real-time. In an embodiment, the one or more destination entities includes at least one of the applications in the network 105. Upon receiving the one or more requests from the user by the transceiver 220, the transceiver 220 transmits the request to the identification unit 225.
[0047] The identification unit 225 is configured to identify the one or more destination entities that are intended to process or respond to the request by analyzing the information included in the one or more requests. 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 one or more requests to identify information of the one or more destination entities. In an embodiment, the information of the one or more destination entities, include, but not limited to, the servers 115, the databases 260, APIs or specific services. The one or more requests involve analyzing headers, payloads, metadata, or any identifiers within the request. The identification unit 225 is configured to map the parsed one or more requests to the one or more destination entities. The mapping of the parsed one or more requests to the one or more destination entities involves looking up the routing tables, configuration files, or the database 260.
[0048] Upon identification of the one or more destination entities, the one or more requests is transmitted to the extraction unit 230. Thereafter, the extraction unit 230 is configured to extract one or more rules and parameters from the one or more requests. In an embodiment, the one or more rules include instructions or conditions that dictate how the one or more requests are to be processed or to be handled. In an exemplary embodiment, the one or more rules specifies whether certain data should be logged, which security protocols to apply, or how to prioritize the one or more requests. The extraction unit 230 further extracts the one or more parameters needed to process the one or more requests. In an exemplary embodiment, if the one or more requests are querying information about a specific user, a user ID would be the one or more parameters extracted.
[0049] Upon extracting the one or more rules and parameters from the one or more requests, the locating unit 235 is configured to locate at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities. In an embodiment, the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, include data pertaining to at least one of, API user, accessibility of an API provider, nature of response received from the API provider, expected API response time, reception of an API response, the API provider being in a working condition. The one or more runtime configurable parameters are adjusted or configured while the system 120 is running. The one or more runtime configurable parameters are changed based on the one or more requests. The locating unit 235 is configured to adjust the one or more runtime configurable parameters and rules based on the incoming requests, which helps in optimizing the processing of the one or more requests and maintaining the overall efficiency and reliability of the system 120. In an exemplary embodiment, the locating unit 235 identifies the expected API response time from the extracted data and configures a timeout setting to ensure that the system 120 waits an adequate interval for the API response before taking further action.
[0050] Upon locating the one or more runtime configurable parameters or rules, the checking unit 240 is configured to check whether the extracted one or more rules and parameters from the one or more requests match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities from a rule and configuration engine. In an embodiment, the rule and configuration engine refer to API auditor’s service and action rule configuration 430 (as shown in FIG.4). The rule and configuration engine are configured to decide and implement the one or more runtime configurable parameters or rules based on a training model. In an embodiment, the training model includes, but is not limited to, Artificial Intelligence/Machine Learning (AI/ML) model. The one or more rules and parameters such as API keys, user IDs, expected response formats, or timeout values extracted from the one or more requests are validated against the located one or more runtime configurable parameters to ensure they match. When the extracted one or more rules and parameters match the located one or more runtime configurable parameters and rules pertaining to the one or more destination entities, the system 120 proceeds with processing the one or more requests.
[0051] The detecting unit 245 is configured to detect an anomaly on the located one or more runtime configurable parameters or rules when the extracted one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules. The anomaly is detected when there is a mismatch between the extracted one or more rules and parameters from the request and the one or more runtime configurable parameters. If the system 120 encounters the one or more rules or parameters that doesn't align with the expected configuration, it flags this as the anomaly for further taking one or more actions.
[0052] Upon dynamically configuring the extracted one or more rules and parameters, the implementing unit 260 is configured to implement one or more actions based on the detected anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities. In an embodiment, the one or more actions include, but are not limited to one or more rules adjustments, and one or more rules modifications. The one or more rules adjustments, and one or more rules modifications are intended to align with the one or more runtime configurable parameters or rules that pertain to the one or more destination entities. In another embodiment, the one or more actions include, but are not limited to, sending alerts or notifications, dynamically configuring the one or more runtime configurable parameters, and generating a report. The extracted one or more rules and parameters are dynamically configured to ensure it aligns with the system's operational requirements. Dynamic adjustments are made in real-time, as the system 120 processes the one or more requests without requiring manual intervention or system downtime.
[0053] Upon implementing the one or more actions, the report generating unit 250 is configured to generate the report pertaining to at least one of detection of the anomaly the extracted one or more rules and parameters from the one or more requests with respect to the located one or more runtime configurable parameters or rules. In an embodiment, the report includes, but not limited to, details of the mismatch, contextual information, action taken, and timestamp. In an exemplary embodiment, the one or more requests specifies a transaction limit that does not align with the configured transaction limits (e.g., the request asks for a $10,000 limit, but the system’s limit is $5,000). The report generating unit 250 is configured to generate the report pertaining to at least one of detection of the mismatch. The report notes that the configuring unit 245 adjusted the transaction limit to $5,000 to match the system's configuration. The report can be crucial for audit trials, ensuring that the one or more actions taken by the system 120 are well-documented and can be reviewed for compliance purposes. If issues arise, the reports provide a clear record of what changes were made, making it easier to trace back and resolve problems.
[0054] Upon generating the report, the displaying unit 255 is configured to display the generated report to the administrator on the user interface 215. The report is formatted for readability, possibly including tables, charts, or highlighted sections.
[0055] By managing the one or more requests in the network 105, the system 120 is able to, advantageously, configure the one or more rules and parameters and perform API auditing to check if the API is working as expected, whether the end point of the API is accessible, the API is giving proper response as per API document provided by the API provider based on the dynamic configuration of an API auditor’s service and action rule engine.
[0056] 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 managing the one or more requests 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.
[0057] 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.
[0058] 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.
[0059] 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 manage the one or more requests 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.
[0060] 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 260. The operations and functions of the one or more processors 205, the memory 210, the user interface 215, and the database 260 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.
[0061] Further, the processor 205 includes the transceiver 220, the identification unit 225, the extraction unit 230, the locating unit 235, the checking unit 240, the detecting unit 245, the report generating unit 250, the displaying unit 255, and the implementing unit 265. The operations and functions of the transceiver 220, the identification unit 225, the extraction unit 230, the locating unit 235, the checking unit 240, the detecting unit 245, the report generating unit 250, the displaying unit 255, and the implementing unit 265 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.
[0062] FIG. 4 is a block diagram of an architecture 400 that can be implemented in the system of FIG.2, according to one or more embodiments of the present disclosure. The architecture 400 of the system 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.
[0063] The architecture 400 of the system 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 users 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 route the one or more requests 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.
[0064] The architecture 405 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.
[0065] The ELB 410 transmits the one or more requests 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.
[0066] The API gateway 420 further includes an API orchestration configuration 425, an API auditor’s service and action rule configuration 430, an API sync call 435, an API response collection 440, an API auditor’s service and action rule engine 445, and an API async call 450.
[0067] The API orchestration configuration 425 allows multiple ways of routing east bound API calls to multiple west bound API calls. The API auditor’s service and action rule configuration 430, includes configuration files inbuilt that enable managing the one or more requests as per the one or more destination entities and also managing the response as required by the API consumer 405. In an embodiment, the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, include data pertaining to at least one of, API user, accessibility of the API provider, nature of response received from the API provider, expected API response time, reception of the API response, the API provider being in the working condition. The dynamic transformation and manipulation of API data facilitates body to body transformation and manipulation, query param transformation and manipulation, and header transformation and manipulation. The template-based service API provisioning allows us 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.
[0068] In an embodiment, the API auditor’s service and action rule configuration 430 utilizes the training model to decide and implement the one or more runtime configurable parameters or rules changes to obtain smooth API access, audit all API inbound request, API provider validation, API provider response, and error detection. The API auditor’s service and action rule engine 445 take all decisions at runtime with the help of the API auditor’s service and action rule configuration 430.
[0069] The data pertaining to at least one of, API user, accessibility of an API provider, nature of response received from the API provider, expected API response time, reception of an API response, API provider being in a working condition associated with the ML model is logged in an audit record. The audit record includes but not limited to, the one or more requests data, the response data, or contextual data (e.g., time, client, ML model identifier, etc.). The audit record is used, for example, as new training data to further train the ML model, for post-analysis of the output scores produced by different instances of the ML model, or as preload cached data that can be subsequently used as part of the input data provided to the ML model during future prediction.
[0070] Further, the API sync call 435 and the API async call 450, provide synchronous APIs. The synchronous APIs provide the response with minimal elapsed time. Conversely, in an asynchronous operation, the user transmits the request for the availing services and is prepared to receive the system’s response later.
[0071] The API response collection 440 may be 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 APIs in the asynchronous mode, the web service may allow the users 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.
[0072] 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.
[0073] FIG. 5 is a flow diagram illustrating a method 500 for managing the one or more requests 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.
[0074] At step 505, the method 500 includes the step of receiving the one or more requests from the user by the transceiver 220. The one or more requests are transmitted to the processor 205 via the UE 110 from the one or more destination entities. In an embodiment, the one or more requests is at least one of, the Application Programming Interface (API) call. The one or more requests 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 user 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. In an embodiment, the one or more parameters or rules are received from the UE 110 in real-time.
[0075] At step 510, the method 500 includes the step of identifying the one or more destination entities are intended to process or respond to the request by analyzing the information included in the one or more requests 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 one or more requests to identify the information of the one or more destination entities. In an embodiment, the information of the one or more destination entities includes, but not limited to, the servers 115, the databases 260, APIs or specific services. The one or more requests involve analyzing headers, payloads, metadata, or any identifiers within the request. The identification unit 225 is configured to map the parsed data to the one or more destination entities. The identification unit 225 is configured to map the parsed one or more requests to the one or more destination entities. The mapping of the parsed one or more requests to the one or more destination entities involves looking up the routing tables, configuration files, or the database 260.
[0076] At step 515, the method 500 includes the step of extracting the one or more rules and parameters from the one or more requests by the extraction unit 230. In an embodiment, the one or more rules include instructions or conditions that dictate how the one or more requests are to be processed or to be handled. In an exemplary embodiment, the one or more rules specifies whether certain data should be logged, which security protocols to apply, or how to prioritize the one or more requests. The extraction unit 230 also extracts the one or more parameters needed to process the one or more requests. In an exemplary embodiment, if the one or more requests are querying information about a specific user, a user ID would be the one or more parameters extracted.
[0077] At step 520, the method 500 includes the step of locating at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities by the locating unit 235. In an embodiment, the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, include data pertaining to at least one of, API user, accessibility of an API provider, nature of response received from the API provider, expected API response time, reception of an API response, API provider being in a working condition. The one or more runtime configurable parameters are adjusted or configured while the system 120 is running. The one or more runtime configurable parameters are changed based on the one or more requests. The locating unit 235 is configured to adjust the one or more runtime configurable parameters and rules based on the incoming requests, which helps in optimizing the processing of those requests and maintaining the overall efficiency and reliability of the system 120. In an exemplary embodiment, the locating unit 235 identifies the expected API response time from the extracted data and configures a timeout setting to ensure that the system 120 waits an adequate interval for the API response before taking further action.
[0078] At step 525, the method 500 includes the step of checking whether the extracted one or more rules and parameters from the one or more requests match with the located one or more runtime configurable parameters or rules from the rule and configuration engine by the checking unit 240. The one or more rules and parameters such as API keys, user IDs, expected response formats, or timeout values extracted from the one or more requests are validated against the located one or more runtime configurable parameters to ensure they match. When the extracted one or more rules and parameters match the located one or more runtime configurable parameters and rules, the system 120 proceeds with processing the one or more requests.
[0079] At step 530, the method 500 includes the step of detecting the anomaly on the located one or more runtime configurable parameters or rules the extracted one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules by the detecting unit 245. The anomaly is detected when there is a mismatch between the extracted one or more rules and parameters from the request and the one or more runtime configurable parameters. If the system 120 encounters the one or more rules or parameters that don’t align with the expected configuration, it flags this as the anomaly for further taking one or more actions.
[0080] At step 535, the method 500 includes the step of implementing the one or more actions pertaining to dynamically configuring the extracted one or more rules and parameters from the one or more requests to match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities. In an embodiment, the one or more actions include, but are not limited to one or more rules adjustments, and one or more rules modifications. The one or more rules adjustments, and one or more rules modifications are intended to align with the one or more runtime configurable parameters or rules that pertain to the one or more destination entities. In another embodiment, the one or more actions include, but not limited to, sending alerts or notifications, dynamically configuring the one or more runtime configurable parameters from the one or more destination entities. The extracted one or more rules and parameters are dynamically configured or adjusted to ensure it aligns with the system's operational requirements. Dynamic adjustments are made in real-time, as the system 120 processes the one or more requests without requiring manual intervention or system downtime.
[0081] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 205. The processor 205 is configured to receive a request from a user. The processor 205 is configured to identify, based on the request, one or more destination entities to which the request is addressed. The processor 205 is configured to extract one or more rules and parameters from the request. The processor 205 is configured to locate, from a rule and configuration engine, at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities. The processor 205 is configured to check whether the extracted one or more rules and parameters from the request match with the located one or more runtime configurable parameters or rules from the rule and configuration engine. The processor 205 is configured to check dynamically detect, an anomaly on the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities, the extracted one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules. The processor 205 is configured to implement one or more actions based on the detected anomaly on the located one or more runtime configurable parameters or rules pertaining to 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-5) 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 dynamically configuring the extracted one or more rules and parameters from the request to match with the located one or more runtime configurable parameters or rules based on the CAPIF auditor. The API auditor’s service and action rule engine performs API auditing to check if the API is working as expected, an end point of the API is accessible, the API is giving proper response as per the API document provided by the API provider. Further, the template-based service API provisioning allows to create and manage APIs on-demand. The APIs on-demand improves the agility, flexibility, and cost-efficiency of API development and management process as the API is integrated dynamically.
[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] Extraction unit – 230
[0096] Locating unit- 235
[0097] Checking unit- 240
[0098] Detecting unit- 245
[0099] Report generating unit- 250
[00100] Displaying unit- 255
[00101] Database– 260
[00102] Implementing unit- 265
[00103] Primary processor- 305
[00104] Memory– 310
[00105] Architecture- 400
[00106] API consumer- 405
[00107] Edge Load Balancer- 410
[00108] Identity and Access Management- 415
[00109] API gateway- 420
[00110] API orchestration configuration- 425
[00111] API auditor’s service and action rule configuration - 430
[00112] API sync call- 435s
[00113] API response collection- 440
[00114] API auditor’s service and action rule engine - 445
[00115] API async call- 450
[00116] API service repository- 455
,CLAIMS:CLAIMS
We Claim:
1. A method (500) to manage one or more requests in a network (105), the method (500) comprises the steps of:
receiving, by one or more processors (205), a request from a user;
identifying, by the one or more processors (205), based on the request, one or more destination entities to which the request is addressed;
extracting, by the one or more processors (205), one or more rules and parameters from the request;
locating, by the one or more processors (205), from a rule and configuration engine, at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities;
checking, by the one or more processors (205), whether the extracted one or more rules and parameters from the request match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities from the rule and configuration engine;
detecting, by the one or more processors (205), an anomaly on the located one or more runtime configurable parameters or rules when the extracted one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities; and
implementing, by the one or more processors (205), one or more actions based on the detected anomaly on the located one or more runtime configurable parameters or rules.

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

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 one or more runtime configurable parameters or rules pertaining to the one or more destination entities, include data pertaining to at least one of, API user, accessibility of an API provider, nature of response received from the API provider, expected API response time, reception of an API response, API provider being in a working condition.

5. The method (500) as claimed in claim 1, wherein the rule and configuration engine are configured to decide and implement the one or more runtime configurable parameters or rules based on a training model.

6. The method (500) as claimed in claim 1, comprising receiving, by the one or more processors, one or more parameters or rules from a User Equipment (UE) in real-time.

7. The method (500) as claimed in claim 1, wherein the one or more actions include, at least one of, sending alerts and or notifications, dynamically configuring the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, and generating a report.

8. The method (500) as claimed in claim 7, wherein the method (500) further comprises the steps of:
generating, by the one or more processors (205), the report pertaining to at least one of:
detection of the anomaly of the extracted one or more rules and parameters from the request with respect to, the located one or more runtime configurable parameters or rules;

displaying, by the one or more processors (205), the generated report to an administrator on a user interface (215).

9. A system (120) to manage one or more requests in a network, the system (120) comprising:
a transceiver (220), configured to, receive, a request from a user;
an identification unit (225), configured to, identify, based on the request, one or more destination entities to which the request is addressed;
an extraction unit (230), configured to, extract, one or more rules and parameters from the request;
a locating unit (235), configured to, locate, from a rule and configuration engine, at least one of, one or more runtime configurable parameters or rules pertaining to the one or more destination entities;
a checking unit (240), configured to, check, whether the extracted one or more rules and parameters from the request match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities from the rule and configuration engine; and
a detecting unit (245), configured to, detect an anomaly in the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities, when the extracted one or more rules and parameters from the request do not match with the located one or more runtime configurable parameters or rules pertaining to the one or more destination entities.
an implementing unit (265), configured to implement the one or more actions based on the detected anomaly on the located one or more runtime configurable parameters or rules.

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 pertains to availing one or more services from the one or more destination entities.

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.

12. The system (120) as claimed in claim 9, wherein the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, include data pertaining to at least one of, API user, accessibility of an API provider, nature of response received from the API provider, expected API response time, reception of an API response, API provider being in a working condition.

13. The system (120) as claimed in claim 9, wherein the rule and configuration engine configured to decide and implement the one or more runtime configurable parameters or rules based on a training model.

14. The system (120) as claimed in claim 9, comprises receiving, by the one or more processors, one or more parameters or rules from a User Equipment (UE) in real-time.

15. The system (120) as claimed in claim 9, wherein the one or more actions include, at least one of, sending alerts or notifications, dynamically configuring the one or more runtime configurable parameters or rules pertaining to the one or more destination entities, and generating a report.

16. The system (120) as claimed in claim 15, further comprising:
a report generating unit (250), configured to, generate, the report pertaining to at least one of:
detection of the anomaly of the extracted one or more rules and parameters from the request with respect to, the located one or more runtime configurable parameters or rules; and
a displaying unit (255), configured to display, the generated report to an administrator on a user interface (215).

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 coupled (305) 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 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.