FORM 2
THE PATENTS ACT, 1970 (39 OF 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“SYSTEM AND METHOD FOR ORCHESTRATING INTERFACE REQUESTS IN A CONFIGURABLE AND ADAPTIVE FULFILMENT MANAGEMENT SYSTEM”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.
2
SYSTEM AND METHOD FOR ORCHESTRATING INTERFACE REQUESTS IN A CONFIGURABLE AND ADAPTIVE FULFILMENT MANAGEMENT SYSTEM
FIELD OF THE DISCLOSURE
5
[0001]
Embodiments of the present disclosure relates generally to the field of wireless communication systems. More particularly, embodiments of the present disclosure relate to method and system for orchestration of interface requests in a configurable and adaptive fulfilment management system (FMS).
10
BACKGROUND
[0002]
The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the 15 present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0003]
Wireless communication technology has rapidly evolved over the past 20 few decades, with each generation bringing significant improvements and advancements. The first generation of wireless communication technology was based on analog technology and offered only voice services. However, with the advent of the second-generation (2G) technology, digital communication and data services became possible, and text messaging was introduced. The third-25 generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth-generation (4G) technology revolutionized wireless communication with faster data speeds,
3
better network coverage, and improved security. Currently, the fifth
-generation (5G) technology is being deployed, promising even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users. 5
[0004]
Many traditional systems (such as a system configured in a wireless communication network for providing communication facilities) do not have the capability to adapt to changes in the request or response formats of integrated systems without making code-level changes, which could require additional 10 development efforts and potentially introduce system downtime. Existing systems often struggle to support complex workflows, including sequential, parallel, conditional, and looped execution patterns. This inflexibility can limit the complexity and variety of processes that can be effectively managed. Further, traditional systems often lack the ability to configure field details such as name, 15 type, and optional/mandatory flag etc. This lack of configurability requires additional coding efforts each time these attributes need to be altered. Further, existing systems often lack efficient and configurable routing capabilities, especially based on specific attributes of the requests. This can limit the performance and flexibility of the system when dealing with multiple interface 20 endpoints.
[0005]
Thus, there exists an imperative need in the art for a configurable and adaptive fulfilment management system for interface request orchestration and method thereof, and that aims to address these issues, offering a more flexible, 25 adaptable, and efficient approach to managing the fulfilment of requests from various systems.
4
OBJECTS OF THE DISCLOSURE
[0006]
Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.
5
[0007]
It is another object of the present disclosure to provide a configurable and adaptive fulfilment management system for interface request orchestration and method thereof.
[0008]
It is another object of the present disclosure to provide a configurable 10 and adaptive fulfilment management system for interface request orchestration and method thereof that can adapt to changes in the request or response formats of integrated systems without needing to make code-level changes.
[0009]
It is another object of the present disclosure to provide a configurable 15 and adaptive fulfilment management system for interface request orchestration and method thereof that support complex workflows, including sequential, parallel, conditional, and loop execution patterns, all configurable as per the requirements of the integrated system.
20
[00010]
It is another object of the present disclosure to provide a configurable and adaptive fulfilment management system for interface request orchestration and method thereof to enable configurable field details such as name, type, and optional/mandatory flag for rapid and flexible modification of these attributes as needed. 25
[00011]
It is another object of the present disclosure to provide a configurable and adaptive fulfilment management system for interface request orchestration
5
and method thereof
that allows easy management of the endpoints or URLs for the southbound interfaces to handle changes in these URLs via configurations, eliminating the need for code-level alterations.
[00012]
It is another object of the present disclosure to provide a configurable 5 and adaptive fulfilment management system for interface request orchestration and method thereof to enable efficient routing of requests to appropriate interface endpoints based on specific attributes of the requests.
[00013]
It is another object of the present disclosure to provide a configurable 10 and adaptive fulfilment management system for interface request orchestration and method thereof to simplify and speed up a process of integrating external systems for reducing both the time and complexity involved in this task.
[00014]
It is another object of the present disclosure to provide a configurable 15 and adaptive fulfilment management system for interface request orchestration and method thereof for making the process more configurable and less dependent on hard-coded changes.
[00015]
It is another object of the present disclosure to significantly reduce the 20 need for development efforts when making changes to the system.
[00016]
It is yet another object of the present disclosure to provide a configurable and adaptive fulfilment management system for interface request orchestration and method thereof for eliminating the need for system downtime 25 during changes, as the disclosure aims to increase the overall uptime and availability of the integrated systems.
6
[00017]
It is yet another object of the present disclosure to provide a solution that enhances scalability, resilience, and fault tolerance, ensuring smooth operation even under high loads or in the event of system failures.
SUMMARY 5
[00018]
This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
10
[00019]
A first aspect of the present disclosure is related to a method for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS). The method comprises: receiving, by a transceiver unit, a request from a northbound interface (NBI) associated with the FMS; adapting, by an adapting unit, a set of attributes from the request to a predefined 15 format by using a configurable framework of the FMS; translating, by a translating unit, the adapted request into a sequence of predefined application programming interface (API) calls; and executing, by an authentication unit, the sequence of predefined API calls to fulfil the received request.
20
[00020]
Further, according to another aspect of the present disclosure, the request received from the NBI is an Application Programming Interface (API) request that comprises an extensive set of attributes for a plurality of southbound interface (SBI) APIs.
25
[00021]
Further, according to another aspect of the present disclosure, the step of executing further comprises routing, by a routing unit, the executed request to one or more network nodes based on at least one attribute associated
7
with the request, wherein the one or more network nodes are associated with a
southbound interface (SBI) of the FMS.
[00022]
Further, according to another aspect of the present disclosure, the set of attributes further comprises configuring an endpoint or Uniform Resource 5 Locator (URL) associated with the one or more network nodes associated with the southbound interface (SBI) of the FMS, and wherein the endpoint or URL is configurable through the FMS's configurable framework.
[00023]
Furthermore, according to another aspect of the present disclosure, 10 the step of adapting the set of attributes comprises configuring at least one field of the received request comprising at least one of a name field, a type field, and a flag field.
[00024]
Further, according to another aspect of the present disclosure, the 15 request is received from a user equipment (UE) associated with a user.
[00025]
Also, according to another aspect of the present disclosure, the method comprises dynamically managing, by an adapting unit, changes in the one or more network nodes based on an activation of configuration changes in the 20 FMS.
[00026]
Another aspect of the present disclosure relates to a system for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS), the system comprises: a transceiver unit configured 25 to receive a request from a northbound interface (NBI) associated with the FMS; an adapting unit connected at least to the transceiver unit, wherein the adapting unit is configured to adapt a set of attributes from the request to a predefined
8
format by using a configurable framework
of the FMS; a translating unit connected at least to the adapting unit, wherein the translating unit is configured to translate the adapted request into a sequence of predefined application programming interface (API) calls; and an authentication unit connected at least to the translating unit, wherein the authentication unit is configured to execute the 5 sequence of predefined API calls to fulfil the received request.
[00027]
Another aspect of the present disclosure relates to a user equipment (UE). The UE comprises a transceiver unit, wherein the transceiver unit is configured to: 1) transmit a request to a system, wherein request comprises a set 10 of attributes; and 2) receive a response from the system. The response is generated by the system based on: 1) adaptation of the set of attributes from the request to a predefined format, 2) translation of the adapted request into a sequence of predefined application programming interface (API) calls, and 3) execution of the sequence of predefined API calls to fulfil the received request. 15
[00028]
Yet another aspect of the present disclosure relates to a non-transitory computer readable storage medium storing instruction for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS). The instructions when executed by one or more units of a system, causes: a transceiver 20 unit of the system to receive a request from a northbound interface (NBI) associated with the FMS; an adapting unit of the system to adapt a set of attributes from the request to a predefined format by using a configurable framework of the FMS; a translating unit of the system to translate the adapted request into a sequence of predefined application programming interface (API) calls; and an 25 authentication unit of the system to execute the predefined sequence of the API calls to fulfil the received request.
9
BRIEF DESCRIPTION OF DRAWINGS
[00029]
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 5 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 10 drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[00030]
FIG.1 illustrates an exemplary diagram depicting an environment for orchestrating interface requests in a configurable and adaptive fulfilment 15 management system (FMS) [102], in accordance with exemplary embodiments of the present disclosure.
[00031]
FIG.1a illustrates an exemplary block diagram of a system [100] for orchestrating interface requests in a configurable and adaptive fulfilment 20 management system (FMS [102]), in accordance with exemplary embodiments of the present disclosure.
[00032]
FIG.2 illustrates an exemplary method [200] flow diagram indicating a process for orchestrating interface requests in a configurable and adaptive 25 fulfilment management system (FMS [102]), in accordance with exemplary embodiments of the present disclosure.
10
[00033]
FIG.3 illustrates an exemplary block diagram of a computing device upon which an embodiment of the present disclosure may be implemented, in accordance with exemplary embodiments of the present disclosure.
[00034]
The foregoing shall be more apparent from the following more 5 detailed description of the disclosure.
DETAILED DESCRIPTION
[00035]
In the following description, for the purposes of explanation, various 10 specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may 15 not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different 20 drawings.
[00036]
The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those 25 skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the
11
function and arrangement of elements without departing from the spirit and
scope of the disclosure as set forth.
[00037]
It should be noted that the terms "mobile device", "user equipment", "user device", “communication device”, “device” and similar terms are used 5 interchangeably for the purpose of describing the disclosure. These terms are not intended to limit the scope of the disclosure or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The disclosure is not limited to any particular type of device or equipment, and it should be understood that other 10 equivalent terms or variations thereof may be used interchangeably without departing from the scope of the disclosure as defined herein.
[00038]
Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by 15 one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown 20 without unnecessary detail in order to avoid obscuring the embodiments.
[00039]
Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the 25 operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-
12
arranged. A process is terminated when its operations are completed but could
have additional steps not included in a figure.
[00040]
The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the 5 subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent 10 that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
15
[00041]
As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices and 20 transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field 25 Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer,
13
desktop, personal digital assistant, tablet computer, mainframe computer, or any
other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.
[00042]
Further, the user device may also comprise a “processor” 5 or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific 10 Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor. 15
[00043]
All modules, units, components used herein (such as units/components of system [100] depicted in FIG. 1a), unless explicitly excluded herein, may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional 20 processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc. 25
[00044]
As used herein the transceiver unit include at least one receiver and at least one transmitter configured respectively for receiving and transmitting data,
14
signals, information or a combination thereof between units/components within
the system and/or connected with the system.
[00045]
Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various the 5 components/units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. 10 Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.
[00046]
As used herein an application programming interface (API) is a set of 15 protocols, rules, and tools that specifies how software components should interact and communicate with each other. APIs are used in all kinds of digital environments (such as Web APIs, for example, HTTP APIs (Hypertext transfer Protocol Application Programming Interfaces) or REST APIs (Representational State transfer Application Programming Interfaces); Operating System APIs etc.) 20 to define how different software applications interact with the operating system. For example, if a software program needs to display a window on a digital screen, it uses an API provided by the operating system to do so.. For example, if an application needs to retrieve some data from a database, it uses a database API to send a query to the database and receive the results. In the context of the 25 Fulfilment Management System, APIs would be used to send requests between different systems or interfaces (northbound and southbound interfaces), allowing them to communicate and share data.
15
[00047]
Also, as discussed in the background section, the current known solutions of providing fulfilment management system for interface request orchestration have several limitations in adapting to changes in request or response formats, often requiring code-level modifications and causing potential 5 system downtime. These systems struggle to support complex workflows, including sequential, parallel, conditional, and looped execution patterns, limiting their capability to manage diverse processes effectively. Additionally, they lack configurability in field details such as name, type, and mandatory/optional flags, necessitating additional coding efforts for any alterations. Routing capabilities in 10 existing systems are often inefficient and not easily configurable, particularly concerning specific attributes of requests. This deficiency hampers system performance and flexibility, especially when dealing with multiple interface endpoints.
15
[00048]
The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by significantly simplifying the orchestration of interface requests, making it more adaptable, efficient, and easier to manage, while reducing development efforts and system downtime.
20
[00049]
In the present disclosure a fulfilment management system (FMS) is disclosed that supports translation of any kind of incoming request from a northbound interface to a plurality of outgoing predefined sequence of calls from application program interface (API) to southbound API. The fulfilment management system can take a single request containing superset of all attributes 25 (of all the southbound APIs) and then execute the sequence of n southbound API calls (workflow) and provides final response after completion of APIs. The Northbound Interface is a Higher-level component communicating with lower-
16
level components and the Southbound Interface is a Lower
-level component communicating with higher-level components.
[00050]
Mainly, the fulfilment management system (FMS) is a robust and flexible solution for managing complex inter-system communications, translating 5 requests into actionable tasks, and ensuring efficient execution of these tasks based on predefined workflows. The FMS orchestrates and manages requests and responses between different systems or interfaces. The key functions performed by the FMS may include:
10
[00051]
Translation of Requests: The FMS accepts any incoming request from a northbound interface. This request can then be translated into multiple outgoing API calls to one or more southbound interfaces.
[00052]
Superset of Attributes: The FMS can handle a single request that 15 contains a superset of all possible attributes of all the southbound APIs. This enables it to understand and manage complex requests that might cover multiple aspects of the system's functions.
[00053]
Sequential Execution of API Calls: After translating the incoming 20 request, the FMS can execute a sequence of API calls to the southbound interfaces. The sequence and number of these calls (n) can vary based on the requirements of the incoming request.
[00054]
Response Generation: The FMS provides milestone or final responses 25 after the completion of the individual or all API calls. This ensures the northbound interface is kept informed of the progress and outcomes of its requests.
17
[00055]
Workflow Pattern Support: The FMS is designed to support various workflow patterns. This includes sequential execution (one step after another), parallel execution (multiple steps at the same time), conditional execution (based on certain conditions), and loop execution (repeated steps). The choice of pattern depends on the specific needs of the process or request being handled. 5
[00056]
Therefore, the present disclosure provides a technical solution for interface request orchestration in a configurable and adaptive fulfilment management system that facilitates in reduction in time and complexity associated with external system integration by managing changes at a 10 configuration level to avoid system downtime or code-level modifications when modifying the request or response schema of external integrating systems.
[00057]
Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings. 15
[00058]
Referring to FIG.1 that illustrates an exemplary diagram depicting an environment for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS) [102], in accordance with exemplary embodiments of the present disclosure. The environment for orchestrating 20 interface requests in the configurable and adaptive fulfilment management system (FMS [102]) depicts at least one Fulfilment Management System [102], a plurality of network nodes (104A, 104B, 104C…104N) (alternatively referred to collectively as network nodes [104] or network node [104] hereinafter) and at least one northbound interface (NBI) [106]. Also, all of the components/ units 25 depicted in FIG. 1 are assumed to be connected to each other unless otherwise indicated below. Also, in Fig. 1 only a few units are shown, however, the environment may comprise multiple such units or a number of units as required
18
to implement the features of the present disclosure. Further, in an
implementation, the Fulfilment Management system [102] may partially or wholly reside in a server or a network entity. In yet another implementation, the Fulfilment Management system [102] may be in communication with the server/ network entity and reside outside the server/network entity. 5
[00059]
In an implementation the Fulfilment Management system [102] is configured for interface request orchestration, with the help of the interconnection between the components/units of the environment as depicted in FIG.1 and a system [100] as depicted in FIG. 1a. Also, the components/ units of 10 the system [100] may be present at the same location or may be distributed at different locations.
[00060]
In an embodiment, the fulfilment management system (FMS) [102] is configured to streamline and manage the process of receiving and fulfilling 15 requests, particularly in the context of network interfaces, however the present disclosure is not limited thereto and the FMS [102] may be configured in any environment that may be obvious to a person skilled in the art in light of the technical solution as claimed in the present solution.
20
[00061]
Furthermore, to streamline and manage the process of receiving and fulfilling requests, firstly, the fulfilment management system [102] receives an incoming request from a northbound interface [106]. This could be any kind of request that comes from a client application or a system that is designed to interact with the fulfilment management system [102]. The received request may 25 come in various formats, and it may change over time. Instead of requiring time-consuming and error-prone code modifications to adapt to these changes, the fulfilment management system [102] is capable of adapting to these changes by
19
configuring all fields of the received request. This means the
FMS [102] is flexible and adaptive, able to accommodate changes in the request format without necessitating any changes at the code level.
[00062]
Once the request is received and adapted to, the fulfilment 5 management system [102] translates it into a sequence of predefined API calls for a southbound interface.
[00063]
As used herein the "southbound interface" typically refers to the interface that communicates downstream, or away from the application, toward 10 the lower-level components of a system or network. This is where the system interacts with other services or subsystems to fulfil the incoming request.
[00064]
Further, the process of translation depends on a specific workflow and takes into account all attributes included in the request for the southbound APIs. 15 Following the translation, the fulfilment management system [102] executes the sequence of API calls. Once a single API call or all of them are completed, the FMS [102] provides an output response. This might be a milestone (intermediate) or final response, depending on the nature of the APIs and the completion status.
20
[00065]
Another significant aspect of the fulfilment management system [102] is its ability to dynamically manage changes in network nodes [104]. Instead of altering the system's code whenever a node changes, the fulfilment management system [102] can manage these changes simply by adjusting configurations. This adds a layer of flexibility and adaptability to the FMS [102], minimizing the 25 downtime and complexity often associated with changes in network nodes.
20
[00066]
Also, the fulfilment management system [102] routes requests to network nodes [104] based on at least one attribute associated with the request. This means the system fulfilment management [102] may decide where to send a request based on specific characteristics or conditions outlined in the request itself. 5
[00067]
It would be appreciated by the person skilled in the art that the fulfilment management system [102] with the help on the system [100] significantly reduces the time and complexity associated with integrating external systems by managing changes at the configuration level, rather than at the code 10 level. This approach eliminates the need for system downtime or code-level modifications when modifying the request or response schema of any existing integrating systems. In essence, the fulfilment management system [102] makes the process of integrating and coordinating with external systems much more efficient and adaptable. 15
[00068]
Referring to FIG. 1a that illustrates an exemplary block diagram of a system [100] for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS) [102], in accordance with exemplary embodiments of the present disclosure. The system [100] include at least one 20 transceiver unit [101], at least one adapting unit [103], at least one translating unit [105], at least one authentication unit [107], at least one routing unit [109], and at least one memory device or at least one database for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS) [102]. Also, a component of the system [100] may comprise one or more general 25 purpose sub-components or circuitry which together be referred to as that particular component. Also, all of the components/ units of the system [100] are assumed to be connected to each other unless otherwise indicated below. As
21
shown in the
Fig. 1a all units shown within the system [100] should also be assumed to be connected to each other. Also, in Fig. 1a only a few units are shown, however, the system [100] may comprise multiple such units or the system [100] may comprise any such numbers of said units, as required to implement the features of the present disclosure. Further, in an implementation, the system 5 [100] may be present in the fulfilment management system (FMS) [102] to implement the features of the present disclosure. The system [100] may be a part of the FMS [102] / or may be independent of but in communication with the FMS [102].
10
[00069]
Initially, for orchestrating interface requests in the configurable and adaptive fulfilment management system (FMS) [102], the transceiver unit [101] is configured to receive a request from a northbound interface (NBI) [106] associated with the FMS [102]. Further, the request received from the NBI [106] is an Application Programming Interface (API) request that comprises an extensive 15 set of attributes for a plurality of southbound interface (SBI) APIs.
[00070]
Mainly, initially the transceiver unit [101] of the system [100] is configured to receive a request from a northbound interface (NBI) [106] associated with the fulfilment management system (FMS) [102]. The incoming 20 request is received from at least one of a user equipment (UE) associated with a user, an external application and an external network node. The transceiver unit [101] provides both transmission and reception functions, allowing it to send and receive data, signals and/or information. The transceiver unit [101] acts as the entry point for incoming requests, capturing data from the NBI [106] and passing 25 it to subsequent units for processing within the system [100]. In other words, the incoming request can be any instruction or call made by a user device or another system that intends to utilize the services provided by the fulfilment management
22
system. This request can be for a variety of purposes, including data retrieval,
status updates, performing a specific operation, or any other function provided by the FMS [102].
[00071]
The northbound interface [106] is essentially the entry point for such 5 requests into the Fulfilment Management System [102]. The NBI [106] can be structured to receive requests in a certain format or protocol and could be part of a service application programming interface (API), a user interface, or other forms of higher-level system interfaces. These interfaces essentially communicate with the Fulfilment Management System [102] to convey the requests to it. Once the 10 request is received through the northbound interface [106], the Fulfilment Management System [102] can then process this request with the help of system [100] in subsequent steps of the operation. This process may include interpreting the request, determining the appropriate response or action, and executing the required tasks to fulfil the request. 15
[00072]
As used herein the API(s) define the methods and data formats that applications can use to request and exchange information. APIs provide a structured way for different software components or systems to communicate and interact with each other. 20
[00073]
The extensive set of attributes for the plurality of southbound interface (SBI) APIs refers to a group of attributes associated with the southbound interface. These attributes may include parameters such as endpoints, URLs, authentication credentials, and/or other configuration settings necessary for the 25 proper functioning of the southbound interface within the FMS. In other words, the technical solution as disclosed in the present disclosure provides an ability to handle complex API requests with detailed attributes, facilitating interaction with
23
multiple SBI APIs and enabling comprehensive functionality within the fulfilment
management system.
[00074]
Further, the adapting unit [103] is connected to at least the transceiver unit [101], wherein the adapting unit [103] is configured to adapt a set of 5 attributes from the request to a predefined format by using a configurable framework of the FMS [102]. The configurable framework is a framework that enables one or more configurable field details such as name, type, and optional/mandatory flag for rapid and flexible modification of the set of attributes to the predefined format. The set of attributes comprises configuring one of an 10 endpoint and a Uniform Resource Locator (URL) associated with the one or more network nodes associated with the southbound interface (SBI) of the FMS [102], and wherein the one of the endpoint and the URL is configurable through the configurable framework of the FMS [102].
15
[00075]
Further, the adaption of the set of attributes in the request format comprises configuration of at least one field of the received request comprising at least one of a name field, a type field, and a flag field.
[00076]
In other words, the present disclosure encompasses that a set of 20 attributes from the request are adapted to a predefined format by using a configurable framework enabling efficient management and orchestration of interface requests without requiring code-level modifications in the request format, wherein such adaption comprises configuring each field of the external system request, including its name, type, and/or a flag etc. An adapting unit [103] 25 ensures that incoming requests are transformed into a standardized format that can be effectively processed by the FMS [102], enhancing interoperability and flexibility. This is achieved by making all fields of the request configurable. The
24
ability to configure all fields of the incoming request provides a significant
advantage. The variety of requests that the system might receive can be diverse and complex. Requests may have different structures or may contain different types or amounts of information. When a new type of request is introduced or an existing request format is altered, traditional systems often require a change in 5 the code to parse and understand the new request format, which can be a time-consuming and complex task, potentially leading to errors and system downtime. The adaption of the set of attributes as disclosed in the present disclosure deals with such limitations.
10
[00077]
In the described FMS [102], the fields of the request may all be configurable. This means that the FMS [102] may be set up to understand different request formats by simply reconfiguring these fields. No changes to the system's code are necessary. This allows for a high degree of flexibility and responsiveness to changes in the requests being handled by the FMS [102]. For example, suppose 15 the FMS [102] is initially set up to handle requests where the user's personal details are provided in a "FirstName" and "LastName" field. If the format changes, and personal details are now provided in a single "FullName" field, the FMS [102] may be easily reconfigured to understand this new format, rather than having to be recoded. This configuration could be accomplished through an administrative 20 interface or configuration files, depending on the specifics of the fulfilment management system's implementation.
[00078]
Furthermore, the translating unit [105] is connected at least to the adapting unit [103], wherein the translating unit [105] is configured to translate 25 the adapted request into a sequence of predefined application programming interface (API) calls.
25
[00079]
The "sequence" of API calls is determined based on a predefined "workflow". A workflow is a set of rules or procedures specifying the order in which tasks or operations are to be executed. This workflow might specify, for example, that certain API calls should be made in a specific order, or that some calls should only be made under certain conditions. 5
[00080]
The incoming request contains a "superset of all attributes” for the southbound APIs. This means that the request contains all the information necessary for making all the API calls in the sequence, even though some of this information might not be used in every call. This simplifies the process of handling 10 the request, as all the necessary information is available upfront.
[00081]
The translating unit [101] translates the adapted request into the sequence of predefined application programming interface (API) calls. This conversion enables the FMS [102] to process the request effectively through its 15 internal APIs. The translating unit [105] facilitates the integration of external requests with the system's internal processes by converting them into a format compatible with the system's APIs, enabling seamless execution of requested actions based on a workflow associated with the adapted incoming request. Further, the sequence is determined based on a workflow and the request 20 comprises a superset of all attributes for the southbound APIs.
[00082]
In an example, the FMS system [102] is part of a web-based order fulfilment service, and an incoming request asks to place an order for a certain product. The workflow for handling this request might involve several API calls to 25 different subsystems: one to check the product's availability, one to charge the customer's credit card, and another to initiate shipping of the product. The original request contains all the necessary information (product ID, customer's credit card
26
information, shipping address) for all these API calls, and the
FMS [102] with the help of system [100] would execute these calls in the appropriate order as per the predefined workflow.
[00083]
Considering another non-limiting example where a customer requests 5 a network entity to upgrade their existing service plan. This request triggers a series of backend processes within an operations support system (OSS) and a business support system (BSS) at the network entity, to provision the upgraded services seamlessly. The workflow associated with this request might involve multiple API calls to various subsystems of the network entity: one to verify the 10 availability of the upgraded service in the network, another to update the customer's billing information, and additional calls to provision the new services on network elements. The system [100] as disclosed in the present disclosure facilitates the integration of these external requests with the OSS/BSS system's internal processes. The request contains essential attributes such as the 15 customer's account details, the requested service plan upgrade, and any relevant billing information. Also, the system [100] orchestrates the API calls associated with this request in the predefined workflow, ensuring the seamless execution of the order fulfilment process in the telecom environment.
20
[00084]
Subsequently, the authentication unit [107] is connected at least to the translating unit [105], wherein the authentication unit [107] is configured to execute the sequence of the predefined API calls to fulfil the received request.
[00085]
In other words, the present disclosure encompasses that the 25 authentication unit [107] verifies the validity of incoming requests and executes the sequence of predefined API calls to fulfil them. It ensures that the request is authorized before proceeding with the execution. The authentication unit [107]
27
ensures the security and integrity of the system by validating the authenticity of
incoming requests and executing the necessary actions only for authorized requests, thereby preventing unauthorized access and potential security breaches. The FMS [102] may be configured to execute the sequence of API calls to provide an output response based on completion of a single API call or all API 5 calls. The FMS [102] executes the sequence of API calls that were defined and organized in the previous step. The execution of these calls is done in an ordered manner, according to the prescribed workflow. The output response is generated based on the completion of either a single API call or all API calls, depending on the requirements and the workflow defined. This means that an intermediate 10 response may be generated after each API call, or a final response might be provided after the execution of all API calls in the sequence. Moreover, in an implementation the authentication unit [107] also authenticates an identity of at least one of one or more incoming requests, one or more the output responses and one or more outgoing requests sent towards network node(s). For instance, 15 said authentication of the identity may be based on an API key provided in at least one of said one or more incoming requests, said one or more the output responses and said one or more outgoing requests sent towards network node(s).
[00086]
For example, consider the web-based order fulfilment service 20 mentioned earlier. The FMS [102] with the help of the system [100] provides an intermediate response to the user’s request after each API call. After the product availability check, the user might receive a response saying that the product is in stock. After the credit card charging process, the user might receive a confirmation of payment. Finally, after the shipping initiation, the user might receive a final 25 response containing the expected delivery date of the product. Alternatively, the FMS [102] is configured to provide a single response after all the API calls have been completed, summarizing all the results of the operation.
28
[00087]
Further it is pertinent to note that the adapting unit [103] of the system [100] is configured to dynamically manage one or more changes in the one or more network nodes based on an activation of one or more configuration changes in the FMS [102]. In other words, the adapting unit [103] helps in 5 maintaining the stability and functionality of the FMS [102] by orchestrating changes in response to evolving requirements or configurations, thereby ensuring seamless operation and adaptability of the system over time.
[00088]
In an example, a network consisting of several nodes (Node A, Node B, 10 Node C) and each node communicates with the FMS through a specific API. Now, suppose there's a change in the API or endpoint of Node B. Instead of adjusting the source code of the FMS [102] (which would typically require considerable development effort, testing, and downtime), the system [100] allows these changes to be addressed directly within the system's configuration settings. This 15 could involve updating the endpoint URL, adjusting request/response parameters, or altering other aspects relevant to the interaction between the FMS [102] and Node B.
[00089]
The dynamic management of changes significantly enhances the 20 fulfilment management system's flexibility, adaptability, and overall uptime by reducing the need for intensive development work and downtime associated with hard-code adjustments. It also ensures that the FMS [102] can quickly and efficiently adapt to alterations in the external system's network infrastructure or data communication methods. 25
[00090]
Thereafter, the routing unit [109] is connected at least to the authentication unit [107] and is configured to route the executed request to one
29
or more network nodes based on at least one attribute associated with the
request, wherein the one or more network nodes are associated with southbound interface (SBI) of the FMS. In other words, the routing unit [109] routes the executed request to one or more network nodes based on specific attributes associated with the request. These network nodes are related to the southbound 5 interface (SBI) of the FMS, ensuring proper distribution and handling of the request. The fulfilment management system [102] is designed to route incoming requests to the appropriate network nodes [104] based on one or more attributes associated with each request.
10
[00091]
For instance, consider a scenario where the FMS [102] receives a multitude of different requests from various northbound interfaces [106]. Each of these requests might contain distinct attributes or data, such as a specific user ID, service type, geographic region, or other metadata. The FMS [102] with the help of system [100] is programmed to examine these attributes and use them as a 15 basis for routing the request to the appropriate network node.
[00092]
Let's take an example where requests are associated with specific geographical regions (e.g., Region A, Region B, Region C), and each region corresponds to a different network node. When the FMS [102] receives a request 20 with the attributes of the "Region B," the system [100] routes that request to the network node responsible for handling "Region B" requests. By using request attributes for routing decisions, the FMS [102] can effectively distribute workload across multiple network nodes, enhance response times, and ensure that each request is processed by the most relevant and capable node. This feature also 25 enhances the fulfilment management system's flexibility and adaptability, allowing it to efficiently handle changes or expansion in the network infrastructure.
30
[00093]
Referring to FIG. 2 an exemplary method flow diagram, depicting method [200] for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS) [102], in accordance with exemplary embodiments of the present disclosure is shown. In an implementation the 5 method [200] is performed by the system [100] associated with the fulfilment management system [102]. As shown in FIG. 2, the method [200] begins at step 202.
[00094]
At step 204, the method [200] encompasses receiving, by a transceiver 10 unit [101], a request from a northbound interface (NBI) [106] associated with the FMS [102]. as disclosed by the present disclosure pertains to the action where the system, identified as the Fulfilment Management System [102]. Further, the request received from the NBI [106] is an Application Programming Interface (API) request that comprises an extensive set of attributes for a plurality of southbound 15 interface (SBI) APIs.
[00095]
Mainly, initially the transceiver unit [101] of the system [100] receives a request from a northbound interface (NBI) [106] associated with the fulfilment management system (FMS) [102]. The incoming request is received from at least 20 one of a user equipment (UE) associated with a user, an external application and an external network node. The transceiver unit [101] provides both transmission and reception functions, allowing it to send and receive data, signals and/or information. The transceiver unit [101] acts as the entry point for incoming requests, capturing data from the NBI [106] and passing it to subsequent units for 25 processing within the system [100]. In other words, the incoming request can be any instruction or call made by a user device or another system that intends to utilize the services provided by the fulfilment management system. This request
31
can be for a variety of purposes, including data retrieval, status updates,
performing a specific operation, or any other function provided by the FMS [102].
[00096]
The northbound interface [106] is essentially the entry point for such requests into the Fulfilment Management System [102]. The NBI [106] can be 5 structured to receive requests in a certain format or protocol and could be part of a service application programming interface (API), a user interface, or other forms of higher-level system interfaces. These interfaces essentially communicate with the Fulfilment Management System [102] to convey the requests to it. Once the request is received through the northbound interface [106], the Fulfilment 10 Management System [102] can then process this request with the help of system [100] in subsequent steps of the operation. This process may include interpreting the request, determining the appropriate response or action, and executing the required tasks to fulfil the request.
15
[00097]
As used herein the API(s)define the methods and data formats that applications can use to request and exchange information. APIs provide a structured way for different software components or systems to communicate and interact with each other.
20
[00098]
The extensive set of attributes for the plurality of southbound interface (SBI) APIs refers to a group of attributes associated with the southbound interface. These attributes may include parameters such as endpoints, URLs, authentication credentials, and/or other configuration settings necessary for the proper functioning of the southbound interface within the FMS. In other words, 25 technical solution as disclosed in the present disclosure provides an ability to handle complex API requests with detailed attributes, facilitating interaction with
32
multiple SBI APIs and enabling comprehensive functionality within the fulfilment
management system.
[00099]
At step 206, the method [200] encompasses adapting, by an adapting unit [103], a set of attributes from the request to a predefined format by using a 5 configurable framework of the FMS [102]. The configurable framework is a framework that enables one or more configurable field details such as name, type, and optional/mandatory flag for rapid and flexible modification of the set of attributes to the predefined format. The set of attributes comprises configuring one of an endpoint and a Uniform Resource Locator (URL) associated with the one 10 or more network nodes associated with the southbound interface (SBI) of the FMS [102], and wherein the one of the endpoint and the URL is configurable through the configurable framework of the FMS [102].
[000100]
Further, the adaption of the set of attributes in the request format 15 comprises configuration of at least one field of the received request comprising at least one of a name field, a type field, and a flag field.
[000101]
In other words, the present disclosure encompasses that a set of attributes from the request are adapted to a predefined format by using a 20 configurable framework enabling efficient management and orchestration of interface requests without requiring code-level modifications in the request format, wherein such adaption comprises configuring each field of the external system request, including its name, type, and/or a flag etc. An adapting unit [103]ensures that incoming requests are transformed into a standardized format 25 that can be effectively processed by the FMS [102], enhancing interoperability and flexibility. This is achieved by making all fields of the request configurable. The ability to configure all fields of the incoming request provides a significant
33
advantage. The variety of requests that the system might receive can be diverse
and complex. Requests may have different structures or may contain different types or amounts of information. When a new type of request is introduced or an existing request format is altered, traditional systems often require a change in the code to parse and understand the new request format, which can be a time-5 consuming and complex task, potentially leading to errors and system downtime. The adaption of the set of attributes as disclosed in the present disclosure deals with such limitations.
[000102]
In the described FMS [102], the fields of the request may all be 10 configurable. This means that the FMS [102] may be set up to understand different request formats by simply reconfiguring these fields. No changes to the system's code are necessary. This allows for a high degree of flexibility and responsiveness to changes in the requests being handled by the FMS [102]. For example, suppose the FMS [102] is initially set up to handle requests where the user's personal 15 details are provided in a "FirstName" and "LastName" field. If the format changes, and personal details are now provided in a single "FullName" field, the FMS [102] with the help of system [100] may be easily reconfigured to understand this new format, rather than having to be recoded. This configuration could be accomplished through an administrative interface or configuration files, 20 depending on the specifics of the fulfilment management system's implementation.
[000103]
At step 208, the method [200] comprises translating, by a translating unit [105], the adapted request into a sequence of predefined application 25 programming interface (API) calls.
34
[000104]
The "sequence" of API calls is determined based on a predefined "workflow". A workflow is a set of rules or procedures specifying the order in which tasks or operations are to be executed. This workflow might specify, for example, that certain API calls should be made in a specific order, or that some calls should only be made under certain conditions. The incoming request contains 5 a "superset of all attributes" for the southbound APIs. This means that the request contains all the information necessary for making all the API calls in the sequence, even though some of this information might not be used in every call. This simplifies the process of handling the request, as all the necessary information is available upfront. 10
[000105]
The translating unit [101] translates the adapted request into the sequence of predefined application programming interface (API) calls. This conversion enables the FMS [101] to process the request effectively through its internal APIs. The translating unit facilitates the integration of external requests 15 with the system's internal processes by converting them into a format compatible with the system's APIs, enabling seamless execution of requested actions based on a workflow associated with the adapted incoming request. Further, the sequence is determined based on a workflow and the request comprises a superset of all attributes for the southbound APIs. 20
[000106]
In an example, the FMS system [102] is part of a web-based order fulfilment service, and an incoming request asks to place an order for a certain product. The workflow for handling this request might involve several API calls to different subsystems: one to check the product's availability, one to charge the 25 customer's credit card, and another to initiate shipping of the product. The original request contains all the necessary information (product ID, customer's credit card information, shipping address) for all these API calls, and the FMS [102] with the
35
help of system [100]
would execute these calls in the appropriate order as per the predefined workflow.
[000107]
Considering another non-limiting example where a customer requests a network entity to upgrade their existing service plan. This request triggers a 5 series of backend processes within an operations support system (OSS) and a business support system (BSS) at the network entity, to provision the upgraded services seamlessly. The workflow associated with this request might involve multiple API calls to various subsystems of the network entity: one to verify the availability of the upgraded service in the network, another to update the 10 customer's billing information, and additional calls to provision the new services on network elements. The system [100] as disclosed in the present disclosure facilitates the integration of these external requests with the OSS/BSS system's internal processes. The request contains essential attributes such as the customer's account details, the requested service plan upgrade, and any relevant 15 billing information. Also, the system [100] orchestrates the API calls associated with this request in the predefined workflow, ensuring the seamless execution of the order fulfilment process in the telecom environment.
[000108]
At step 210, the method [200] encompasses executing, by an 20 authentication unit [107], the sequence of predefined API calls to fulfil the received request.
[000109]
In other words, the present disclosure encompasses that the authentication unit [107] verifies the validity of incoming requests and executes 25 the sequence of predefined API calls to fulfill them. It ensures that the request is authorized before proceeding with the execution. The authentication unit [102] ensures the security and integrity of the system by validating the authenticity of
36
incoming requests and executing the necessary actions only for authorized
requests, thereby preventing unauthorized access and potential security breaches. The FMS [102] may execute the sequence of API calls to provide an output response based on completion of a single API call or all API calls. The FMS [102] executes the sequence of API calls that were defined and organized in the 5 previous step.
[000110]
The execution of these calls is done in an ordered manner, according to the prescribed workflow. The output response is generated based on the completion of either a single API call or all API calls, depending on the 10 requirements and the workflow defined. This means that an intermediate response may be generated after each API call, or a final response might be provided after the execution of all API calls in the sequence. Moreover, in an implementation the authentication unit [107] also authenticates an identity of at least one of one or more incoming requests, one or more the output responses 15 and one or more outgoing requests sent towards network node(s). For instance, said authentication of the identity may be based on an API key provided in at least one of said one or more incoming requests, said one or more the output responses and said one or more outgoing requests sent towards network node(s).
20
[000111]
For example, consider the web-based order fulfilment service mentioned earlier. The FMS [102] with the help of the system [100] provides an intermediate response to the user’s request after each API call. After the product availability check, the user might receive a response saying that the product is in stock. After the credit card charging process, the user might receive a confirmation 25 of payment. Finally, after the shipping initiation, the user might receive a final response containing the expected delivery date of the product. Alternatively, the
37
FMS [102]
configured to provide a single response after all the API calls have been completed, summarizing all the results of the operation.
[000112]
Further, it is pertinent to note that the adapting unit [103] of the system [100] dynamically manages one or more changes in the one or more 5 network nodes based on an activation of one or more configuration changes in the FMS [102]. In other words, the adapting unit [103] helps in maintaining the stability and functionality of the FMS [102] by orchestrating changes in response to evolving requirements or configurations, thereby ensuring seamless operation and adaptability of the system over time. 10
[000113]
In an example, a network consisting of several nodes (Node A, Node B, Node C) and each node communicates with the FMS through a specific API. Now, suppose there's a change in the API or endpoint of Node B. Instead of adjusting the source code of the FMS [102] (which would typically require considerable 15 development effort, testing, and downtime), the system [100] allows these changes to be addressed directly within the system's configuration settings. This could involve updating the endpoint URL, adjusting request/response parameters, or altering other aspects relevant to the interaction between the FMS [102] and Node B. 20
[000114]
The dynamic management of changes significantly enhances the fulfilment management system's flexibility, adaptability, and overall uptime by reducing the need for intensive development work and downtime associated with hard-code adjustments. It also ensures that the FMS [102] can quickly and 25 efficiently adapt to alterations in the external system's network infrastructure or data communication methods.
38
[000115]
Thereafter, the routing unit [109] routes the executed request to one or more network nodes based on at least one attribute associated with the request, wherein the one or more network nodes are associated with southbound interface (SBI) of the FMS. In other words, the routing unit [109] routes the executed request to one or more network nodes based on specific attributes 5 associated with the request. These network nodes are related to the southbound interface (SBI) of the FMS [102], ensuring proper distribution and handling of the request. The fulfilment management system [102] is designed to route incoming requests to the appropriate network nodes [104] based on one or more attributes associated with each request. 10
[000116]
For instance, consider a scenario where the FMS [102] receives a multitude of different requests from various northbound interfaces [106]. Each of these requests might contain distinct attributes or data, such as a specific user ID, service type, geographic region, or other metadata. The FMS [102] with the help 15 of system [102] is programmed to examine these attributes and use them as a basis for routing the request to the appropriate network node.
[000117]
Let's take an example where requests are associated with specific geographical regions (e.g., Region A, Region B, Region C), and each region 20 corresponds to a different network node. When the FMS [102] receives a request with the attributes of the "Region B," the system [100] routes that request to the network node responsible for handling "Region B" requests. By using request attributes for routing decisions, the FMS [102] can effectively distribute workload across multiple network nodes, enhance response times, and ensure that each 25 request is processed by the most relevant and capable node. This feature also enhances the fulfilment management system's flexibility and adaptability,
39
allowing it to efficiently handle changes or expansion in the network
infrastructure.
[000118]
Thereafter, the method terminates at step 212.
5
[000119]
Fig. 3 illustrates an exemplary block diagram of a computing device [1000] (or also referred herein as computer system [1000]) upon which an embodiment of the present disclosure may be implemented. In an implementation, the computing device [1000] implements the method [200] for orchestrating interface requests in a configurable and adaptive fulfilment 10 management system [100]. In another implementation, the computing device [1000] itself implements the method [200] for orchestrating interface requests in a configurable and adaptive fulfilment management system using one or more units configured within the computing device [1000], wherein said one or more units are capable of implementing the features as disclosed in the present 15 disclosure.
[000120]
The computing device [1000] may include a bus [1002] or other communication mechanism for communicating information, and a hardware processor [1004] coupled with bus [1002] for processing information. The 20 hardware processor [1004] may be, for example, a general purpose microprocessor. The computer system [1000] may also include a main memory [1006], such as a random access memory (RAM), or other dynamic storage device, coupled to the bus [1002] for storing information and instructions to be executed by the processor [1004]. The main memory [1006] also may be used for storing 25 temporary variables or other intermediate information during execution of the instructions to be executed by the processor [1004]. Such instructions, when stored in non-transitory storage media accessible to the processor [1004], render
40
the computer system [1000] into a special
-purpose machine that is customized to perform the operations specified in the instructions. The computer system [1000] further includes a read only memory (ROM) [1008] or other static storage device coupled to the bus [1002] for storing static information and instructions for the processor [1004]. 5
[000121]
A storage device [1010], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [1002] for storing information and instructions. The computer system [1000] may be coupled via the bus [1002] to a display [1012], such as a cathode ray tube (CRT), for displaying information to a 10 computer user. An input device [1014], including alphanumeric and other keys, may be coupled to the bus [1002] for communicating information and command selections to the processor [1004]. Another type of user input device may be a cursor controller [1016], such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor 15 [1004], and for controlling cursor movement on the display [1012]. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.
[000122]
The computer system [1000] may implement the techniques described 20 herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system [1000] causes or programs the computer system [1000] to be a special-purpose machine. According to one embodiment, the techniques herein are performed by the computer system [1000] in response to the processor [1004] executing one or 25 more sequences of one or more instructions contained in the main memory [1006]. Such instructions may be read into the main memory [1006] from another storage medium, such as the storage device [1010]. Execution of the sequences of
41
instructions contained in the main memory [1006] causes the processor [1004] to
perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.
5
[000123]
The computer system [1000] also may include a communication interface [1018] coupled to the bus [1002]. The communication interface [1018] provides a two-way data communication coupling to a network link [1020] that is connected to a local network [1022]. For example, the communication interface [1018] may be an integrated services digital network (ISDN) card, cable modem, 10 satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface [1018] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [1018] 15 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
[000124]
The computer system [1000] can send messages and receive data, including program code, through the network(s), the network link [1020] and the 20 communication interface [1018]. In the Internet example, a server [1030] might transmit a requested code for an application program through the Internet [1028], the ISP [1026], the local network [1022], the host [1024] and the communication interface [1018]. The received code may be executed by the processor [1004] as it is received, and/or stored in the storage device [1010], or other non-volatile 25 storage for later execution.
42
[000125]
Furthermore, an aspect of the present disclosure relates to a user equipment (UE). The UE comprises a transceiver unit, wherein the transceiver unit is configured to: 1) transmit a request to a system [100], wherein request comprises a set of attributes; and 2) receive a response from the system [100]. The response is generated by the system [100] based on: 1) adaptation of the set of 5 attributes from the request to a predefined format, 2) translation of the adapted request into a sequence of predefined application programming interface (API) calls, and 3) execution of the sequence of predefined API calls to fulfil the received request.
10
[000126]
Further, an aspect of the present disclosure relates to a non-transitory computer readable storage medium storing instruction for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS) [102]. The instructions when executed by one or more units of a system [100], causes: a transceiver unit [101] of the system [100] to receive a request from a 15 northbound interface (NBI) [106] associated with the FMS [102]; an adapting unit [103] of the system [100] to adapt a set of attributes from the request to a predefined format by using a configurable framework of the FMS [102]; a translating unit [105] of the system [100] to translate the adapted request into a sequence of predefined application programming interface (API) calls; and an 20 authentication unit [107] of the system [100] to execute the predefined sequence of the API calls to fulfil the received request.
[000127]
As is evident from the above, the present disclosure provides a technically advanced solution for interface request orchestration by providing a 25 configurable and adaptive fulfilment management system for interface request orchestration and method thereof.
43
[000128]
Also, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method thereof that can adapt to changes in the request or response formats of integrated systems without needing to make code-level changes.
5
[000129]
Additionally, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method thereof that support complex workflows, including sequential, parallel, conditional, and loop execution patterns, all configurable as per the requirements of the integrated system. 10
[000130]
Further, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method thereof that enable configurable field details such as name, type, and optional/mandatory flag. This allows for rapid and flexible modification of these 15 attributes as needed.
[000131]
Also, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method thereof that allows easy management of the endpoints or URLs for the 20 southbound interfaces. Changes in these URLs are handled via configurations, eliminating the need for code-level alterations.
[000132]
Further, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method 25 thereof that enable efficient routing of requests to appropriate interface endpoints based on specific attributes of the requests.
44
[000133]
Also, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method thereof that simplify and speed up the process of integrating external systems, reducing both the time and complexity involved in this task.
5
[000134]
Further, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method thereof that by making the process more configurable and less dependent on hard-coded changes as the disclosure aims to significantly reduce the need for development efforts when making changes to the FMS. 10
[000135]
Also, the present disclosure provides a configurable and adaptive fulfilment management system for interface request orchestration and method thereof that by eliminating the need for system downtime during changes, the disclosure aims to increase the overall uptime and availability of the integrated 15 systems.
[000136]
Moreover, the disclosure provides a solution that enhances scalability, resilience, and fault tolerance, ensuring smooth operation even under high loads or in the event of system failures. 20
[000137]
While considerable emphasis has been placed herein on the disclosed embodiments, it will be appreciated that many embodiments can be made and that many changes can be made to the embodiments without departing from the principles of the present disclosure. These and other changes in the embodiments 25 of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.
I/We Claim:
1. A method for orchestrating interface requests in a configurable and adaptive
fulfilment management system (FMS) [102], the method comprises:
receiving, by a transceiver unit [101], a request from a northbound interface (NBI) [106] associated with the FMS [102];
adapting, by an adapting unit [103], a set of attributes from the request to a predefined format by using a configurable framework of the FMS [102];
translating, by a translating unit [105], the adapted request into a sequence of predefined application programming interface (API) calls; and
executing, by an authentication unit [107], the sequence of predefined API calls to fulfil the received request.
2. The method as claimed in claim 1, wherein the request received from the NBI [106] is an Application Programming Interface (API) request that comprises an extensive set of attributes for a plurality of southbound interface (SBI) APIs.
3. The method as claimed in claim 2, wherein the executing further comprises routing, by a routing unit [109], the executed request to one or more network nodes based on at least one attribute associated with the request, and wherein the one or more network nodes are associated with a southbound interface (SBI) of the FMS [102].
4. The method as claimed in claim 3, wherein the set of attributes further comprises configuring one of an endpoint and a Uniform Resource Locator (URL) associated with the one or more network nodes associated with the southbound interface (SBI) of the FMS [102], and wherein the one of the endpoint and the URL is configurable through the configurable framework of the FMS [102].

5. The method as claimed in claim 1, wherein the adapting the set of attributes comprises configuring at least one field of the received request comprising at least one of a name field, a type field, and a flag field.
6. The method as claimed in claim 1, wherein the request is received from a user equipment (UE) associated with a user.
7. The method as claimed in claim 1, wherein the method comprises dynamically managing, by an adapting unit [103], one or more changes in the one or more network nodes based on an activation of one or more configuration changes in the FMS [102].
8. A system for orchestrating interface requests in a configurable and adaptive fulfilment management system (FMS) [102], the system comprises:
a transceiver unit [101] configured to receive a request from a northbound interface (NBI) [106] associated with the FMS [102];
an adapting unit [103] connected at least to the transceiver unit [101], wherein the adapting unit [103] is configured to adapt a set of attributes from the request to a predefined format by using a configurable framework of the FMS [102];
a translating unit [105] connected at least to the adapting unit [103], wherein the translating unit [105] is configured to translate the adapted request into a sequence of predefined application programming interface (API) calls; and
an authentication unit [107] connected at least to the translating unit [105], wherein the authentication unit [107] is configured to execute the sequence of predefined API calls to fulfil the received request.
9. The system as claimed in claim 8, wherein the request received from the NBI
[106] is an Application Programming Interface (API) request that comprises

an extensive set of attributes for a plurality of southbound interface (SBI) APIs.
10. The system as claimed in claim 9, the system comprises a routing unit [109] connected at least to the authentication unit [107] and is configured to route the executed request to one or more network nodes based on at least one attribute associated with the request, and wherein the one or more network nodes are associated with a southbound interface (SBI) of the FMS [102].
11. The system as claimed in claim 10, wherein the set of attributes further comprises configuring one of an endpoint and a Uniform Resource Locator (URL) associated with the one or more network nodes associated with the southbound interface (SBI) of the FMS [102], and wherein the one of the endpoint and the URL is configurable through the configurable framework of the FMS [102].
12. The system as claimed in claim 8, wherein the adaption of the set of attributes in the request format comprises configuration of at least one field of the received request comprising at least one of a name field, a type field, and a flag field.
13. The system as claimed in claim 8, wherein the request is received from a user equipment (UE) associated with a user.
14. The system as claimed in claim 8, wherein the system comprises an adapting unit [103] connected at least to the routing unit [109] and is configured to dynamically manage one or more changes in the one or more network nodes based on an activation of configuration changes in the FMS [102].
15. A user equipment (UE) comprises:
a transceiver unit configured to:

transmit a request to a system [100], wherein request comprises a set of attributes, and
receive a response from the system [100], wherein the response is generated by the system [100] based on:
adaptation of the set of attributes from the request to a predefined format,
translation of the adapted request into a sequence of predefined application programming interface (API) calls, and
execution of the sequence of predefined API calls to fulfil the received request.