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 CONFERENCE CALLS
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 generally to wireless communication system, and in particular, to method and system for creating an Application Programming Interface (API)-driven conference call.
BACKGROUND OF THE INVENTION
[0002] There are two types of conferences calls – scheduled conference calls and ad-hoc conference calls. Scheduled conference calls are scheduled for a particular time and allow participants to join the call as per a set schedule. Ad-hoc conference calls, on the other hand, allow the users to be added or removed during the call or terminate the call.
[0003] However, there is no Application Programming Interface (API)-driven ad-hoc conference option available that allows users to add the functionality of the ad-hoc conferences in their applications (i.e. Software applications).
[0004] Thus, there is a need of a solution which addresses the above mentioned shortcoming.

SUMMARY OF THE INVENTION
[0005] One or more embodiments of the present disclosure provide a system and method of managing conference calls.
[0006] In one aspect of the present invention, a system for managing conference calls is disclosed. The system includes a platform configured to provide means for creating an ad-hoc conference call. The system further includes a validating unit configured to validate a user request associated with the ad-hoc conference call based on validation of an API key and a token for the ad-hoc conference call. The system further includes an access management unit configured to check a user plan and an access control policy based on the validated API key and forward the user request associated with the ad-hoc conference call to a Business Telephony Application Server (BTAS) network element. The BTAS network element is configured to create the ad-hoc conference call for the two or more participants. The BTAS is an API provider hosting APIs for the ad-hoc conference calls and managing flow of the ad-hoc conference call.
[0007] In one aspect, the platform is further configured to provide means for adding participants into the ad-hoc conference call and removing participants from the ad-hoc conference call. The means includes a plurality of APIs, and the platform offers the plurality of APIs for exploration and purchase by a user. The system further comprises a subscription engine provided as a backend application of the platform for storing user-related data along with subscription details. The system further comprises a common API gateway for performing a token and Transport Layer Security (TLS) hand-shake for the ad-hoc conference call. The validating unit verifies whether at least two participants are requested to be added in the ad-hoc conference call, validates the API key using a customer API key extracted from the token, and sends notifications to the user when the two or more participants join the ad-hoc conference call. The system provides a User Interface (UI) for the validating unit for visualizing data and performing configuration of the ad-hoc conference call. The access management unit performs enrichment of the user request when the user plan and the API key are identified to be correct. The common API gateway provides a session identity (ID) for removing a participant from the ad-hoc conference call. The BTAS network element selects a destination using round-robin fashion based on an available BTAS instance. The system further comprises an Edge Load Balancer (ELB) configured to route the user request to a destination application based on a rule selected from a group consisting of round-robin, context-based routing, header-based routing, and TCP-based routing.
[0008] In another aspect of the present invention, a method of managing conference calls is described. The method includes receiving a user request for creating an ad-hoc conference call for two or more participants. The method further includes validating the user request associated with the ad-hoc conference call based on validation of an Application Programming Interface (API) key and a token for the ad-hoc conference call. The method further includes checking a user plan and an access control policy based on the validated API key, and forwarding the user request associated with the ad-hoc conference call to a Business Telephony Application Server (BTAS) network element. The method further includes creating the ad-hoc conference call for the two or more participants.
[0009] In one aspect, the user request is received from one of an application, an application developer, and an enterprise. The method further comprises performing a token and Transport Layer Security (TLS) hand-shake for the conference call. The method further comprises verifying whether at least two participants are requested to be added in the ad-hoc conference call. The API key is validated using a customer API key extracted from the token. The method further comprises sending notifications to the user when the two or more participants join the ad-hoc conference call. The method further comprises providing session identity (ID) for removing a participant from the ad-hoc conference call. The method further comprises routing the user request to a destination application based on a rule selected from a group consisting of round-robin, context-based routing, header-based routing, and Transmission Control Protocol (TCP)-based routing. The user request allows selection of one or more APIs, the one or more APIs are Representational State Transfer (REST) APIs. The method further comprises receiving the user request for at least one of adding participants into the ad-hoc conference call and removing participants from the ad-hoc conference call. The method further comprises authenticating the user request through a common API gateway.
[0010] 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
[0011] 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.
[0012] FIG. 1 illustrates a network architecture of a system for managing conference calls, according to one or more embodiments of the present disclosure;
[0013] FIG. 2 illustrates a block diagram of a system for managing conference calls, according to various embodiments of the present system;
[0014] FIG. 3 illustrates a block diagram of the system communicating with a User Equipment for managing conference calls, according to various embodiments of the present system;
[0015] FIG. 4 illustrates a system architecture for managing conference calls, according to one or more embodiments of the present disclosure;
[0016] FIG. 5 illustrates an information flow diagram for managing conference calls, according to one or more embodiments of the present disclosure;
[0017] FIGS. 6A and 6B collectively illustrate a timing diagram for managing conference calls, according to one or more embodiments of the present disclosure; and
[0018] FIG. 7 illustrates a flow chart of a method for managing conference calls, according to one or more embodiments of the present disclosure.
[0019] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0020] 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.
[0021] 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.
[0022] 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.
[0023] The present disclosure is about a method and system for creating API-driven ad-hoc conference call. The method and system of the present disclosure allows for integrating API-based ad-hoc conference call facility in an application. As such, based on inputs received from users, the callees can be added or removed from the conference call. Once the participants are added, the participants start getting call from the system, and they can join the call.
[0024] FIG. 1 illustrates a network architecture of a system for managing conference calls. The network architecture comprises a plurality of User Equipment (UEs) 102-1, 102-2,……,102-n. At least one of the UEs 102-1 through 102-n (henceforth referred as a UE 102) may be configured to connect to a server 105..
[0025] The UE 102 may comprise a memory such as a volatile memory (e.g., RAM), a non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, etc.), an unalterable memory, and/or other types of memory. In one implementation, the memory might be configured or designed to store data. The UE 102 may connect with the server 105 through a communication network 110. The communication network 110 may use one or more communication interfaces/protocols such as, for example, VoIP, 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as CDMA, CDMA2000, WCDMA, Radio Frequency (e.g., RFID), Infrared, laser, Near Field Magnetics, etc.
[0026] The server 105 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 business telephony application server (BTAS), 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 defence facility, or any other facility that provides content.
[0027] Further, the server 105 may be communicably connected to a system 125, via the communication network 110. The system 125 may be configured to access services subscribed by enterprises, and additional services as mentioned above.
[0028] A person skilled in the art will appreciate that the plurality of UEs 102 may include end devices and intermediary devices. The end devices serve as originator of data or information flowing through the communication network 110. For example, the end devices may include workstations, laptops, desktop computers, printers, scanners, servers (file servers, web Servers), mobile phones, tablets, and smart phones. The intermediary devices are configured to forward data from one point to another in the communication network 110. For example, the intermediary devices may include hubs, modems, switches, routers, bridges, repeaters, security firewalls, and wireless access points.
[0029] The communication network 110 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 communication network 110 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.
[0030] The communication network 110 may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network may also include, 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, a VOIP or some combination thereof.
[0031] The system 125 is communicably coupled to the server 105 and each of the first UE 102-1, the second UE 102-2, and the third UE 102-n via the communication network 110. The system 125 is configured to manage conference calls. The system 125 is adapted to be embedded within the server 105 or is embedded as an individual entity. However, for the purpose of description, the system 125 is described as an integral part of the server 105, without deviating from the scope of the present disclosure.
[0032] In various embodiments, the system 125 may be generic in nature and may be integrated with any application including a System Management Facility (SMF), an Access and Mobility Management Function (AMF), a Business Telephony Application Server (BTAS), a Converged Telephony Application Server (CTAS), any SIP (Session Initiation Protocol) Application Server which interacts with core Internet Protocol Multimedia Subsystem (IMS) on Industrial Control System (ISC) interface as defined by Third Generation Partnership Project (3GPP) to host a wide array of cloud telephony enterprise services, a System Information Blocks (SIB)/ and a Mobility Management Entity (MME).
[0033] Session Management Function (SMF) is a control function that manages user sessions including establishment, modification and release of sessions, and allocates IP addresses for IP PDU sessions. The SMF communicates indirectly with the UE through the AMF that relays session-related messages between the devices and the SMF.
[0034] Access and Mobility Management Function (AMF) is a key component in 5G mobile networks, responsible for managing access to the network and handling mobility-related functions for user equipment (UE), such as smartphones, tablets, and IoT devices. AMF works closely with other network functions to facilitate seamless connectivity, mobility, and quality of service for mobile users.
[0035] Business Telephony Application Server (BTAS) is a server-based system that provides telephony services and applications for businesses. It serves as a central platform for managing and delivering various voice communication services, such as voice calls, voicemail, conferencing, and interactive voice response (IVR) systems.
[0036] Converged Telephony Application Server (CTAS) is a server-based system that integrates various telephony and communication services into a single platform, enabling businesses to streamline their communication infrastructure and offer a wide range of communication features. CTAS combines traditional telephony services with advanced IP-based communication capabilities to provide a unified and cohesive communication experience.
[0037] SIP (Session Initiation Protocol) application server is a server-based system that facilitates the establishment, management, and termination of communication sessions using the SIP protocol. SIP application servers play a central role in IP-based telecommunications networks, enabling a wide range of real-time communication services, including voice calls, video calls, instant messaging, presence, and multimedia conferencing.
[0038] Internet Protocol Multimedia Subsystem (IMS) is a standardized architecture that enables the delivery of multimedia communication services over IP networks, including voice, video, messaging, and presence services. IMS is designed to provide a framework for delivering real-time communication services in a flexible, scalable, and interoperable manner.
[0039] Cloud telephony enterprise services refer to communication solutions delivered over the cloud that cater specifically to the needs of businesses and organizations. These services leverage cloud technology to provide scalable, flexible, and cost-effective communication solutions, including voice calls, messaging, collaboration tools, and contact center capabilities.
[0040] System Information Blocks (SIBs) are messages broadcasted by a base station (eNodeB in LTE, NodeB in UMTS, or eNB in 5G) to provide essential information to mobile devices (UEs) in a cellular network. SIBs contain network-related information necessary for UEs to access and operate within the network efficiently. These blocks are periodically transmitted over broadcast channels, allowing UEs to receive and decode them even when they are not actively engaged in communication.
[0041] In the context of mobile networks, specifically in the LTE (Long-Term Evolution) and 5G architectures, the Mobility Management Entity (MME) is a key network element responsible for managing mobility-related functions for user equipment (UE) or mobile devices. The MME is part of the Evolved Packet Core (EPC) network in LTE and the 5G Core (5GC) network in 5G, serving as a control plane entity that handles signaling and control procedures for mobility management.
[0042] Operational and construction features of the system 125 will be explained in detail successively with respect to different figures. FIG. 2 illustrates a block diagram of the system 125 for managing conference calls, according to one or more embodiments of the present disclosure.
[0043] As per the illustrated embodiment, the system 125 includes one or more processors 205, a memory 210, and an input/output interface unit 215. The one or more processors 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. As per the illustrated embodiment, the system 125 includes the processor 205. However, it is to be noted that the system 125 may include multiple processors as per the requirement and without deviating from the scope of the present disclosure. Among other capabilities, 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.
[0044] In an embodiment, the input/output (I/O) interface unit 215 includes a variety of interfaces, for example, interfaces for data input and output devices, referred to as Input/Output (I/O) devices, storage devices, and the like. The I/O interface unit 215 facilitates communication of the system 125. In one embodiment, the I/O interface unit 215 provides a communication pathway for one or more components of the system 125. Examples of such components include, but are not limited to, the UE 102, a database 220, and a distributed cache 225.
[0045] The database 220 is one of, but is 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 database, and so forth. The foregoing examples of the database 220 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.
[0046] The distributed cache 225 is a pool of Random-Access Memory (RAM) of multiple networked computers into a single in-memory data store for use as a data cache to provide fast access to data. The distributed cache 225 is essential for applications that need to scale across multiple servers or are distributed geographically. The distributed cache 225 ensures that data is available close to where it’s needed, even if the original data source is remote or under heavy load. The distributed cache 225 is an in-memory data structure store, that can be used as a database, cache, and message broker. The distributed cache 225 supports all types of data structures, to store data.
[0047] 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 the 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 125 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 125 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.
[0048] For the system 125 to manage conference calls, the processor 205 implements a platform 228 communicably coupled to each of the first UE 102-1, the second UE 102-2, and the third UE 102-n via the communication network 110. Accordingly, the platform 228 is configured to provide means for creating an ad-hoc conference call for the two or more participants. The platform 228, also known as an API marketplace, is also configured to provide means for adding participants into the ad-hoc conference call and removing participants from the ad-hoc conference call. The means includes a plurality of APIs, and the platform 228 offers the plurality of APIs for exploration and purchase by users accessing the UEs 102. Specifically, the platform 228 i.e. API marketplace is a platform where developers can discover, explore, and consume APIs provided by various organizations or third-party developers. It serves as a central repository or marketplace where APIs are published, categorized, and made available for integration into applications, services, or platforms. Over the platform 228, users can view and purchase required APIs.
[0049] The processor 205 further implements a validating unit 230 communicably coupled to the platform 228 for validating a user request associated with the ad-hoc conference call based on validation of an API key and a token (generated by an Identity and Access Management (IAM) component 412) for the ad-hoc conference call. The validating unit 230 may validate the API key using a customer API key extracted from the token. The API key and the token serve different roles in API authentication and authorization. The API key primarily identifies an application or service accessing the API, while the token authenticates and authorizes the user to perform action securely. Together, the API key and the token help ensure secure and controlled access to the APIs and the conference call service. In one implementation, the validating unit 230 may be a Common Application Programming Interface (API) Framework (CAPIF) for 3rd Generation Partnership Project (3GPP) northbound APIs.
[0050] The processor 205 further implements an access management unit 235 communicably coupled to the validating unit 230 for checking a user plan and an access control policy based on the validated API key and forward the user request associated with the ad-hoc conference call to a Business Telephony Application Server (BTAS) network element. The user plan refers to a subscription or service arrangement defining features, capabilities, and limits available to the user for managing conference calls. The user plan may also define the access control policy, such as participant limit for a conference call, HD/4K audio and video support, screen sharing facility, and recording and playback feature.
[0051] In one implementation, the access management unit 235 may perform enrichment of the user request when the user plan and the API key are identified to be correct. Enrichment of the user request refers to enhancing the information or context associated with a user's request to improve accuracy, relevance, or completeness of the response or action taken. For example, the user request may be enriched by augmenting with contextual information, such as a location of the user or type of device accessed by the user.
[0052] The BTAS network element is configured to create the ad-hoc conference call for the two or more participants. Specifically, the BTAS is an API provider hosting APIs for the ad-hoc conference calls and managing flow of the ad-hoc conference call. The BTAS network element selects a destination (participant of the ad-hoc conference call) using round-robin fashion based on an available BTAS instance. After the ad-hoc conference call is created and the two or more participants have joined the ad-hoc conference call, the validating unit 230 may send notifications to a user who had got the ad-hoc conference call created. A User Interface (UI) of the validating unit 230 may be provided for visualizing data and performing configuration of the ad-hoc conference call. Visualizing the data refers to presenting names of the participants, content shared by a participant, and providing details of participants joining or leaving the conference call, etc. Performing configuration refers to changing setting of the conference call, such as providing screen sharing rights, call hosting rights, limiting number of participants, naming the participants, and ending the conference call.
[0053] The processor 205 further implements a subscription engine 240 communicably coupled to the access management unit 235. The subscription engine 240 is provided as a backend application of the platform 228 for storing user-related data along with subscription details. The user-related data may include user name, Internet Protocol (IP) address of device used by the user, and registered location of the user. The subscription details would outline the terms, conditions, and benefits associated with the subscription. For example, the subscription details may include name of plan, features of services availed through the plan, and payment schedule and mode.
[0054] The processor 205 further implements a common API gateway 245 communicably coupled to the subscription engine 240 for performing a token and Transport Layer Security (TLS) hand-shake for the ad-hoc conference call. The TLS hand-shake is used for establishing a secure connection between a client (such as a web browser) and a server (such as a website server) over the Internet. TLS is used to encrypt data transmitted over a network to protect it from eavesdropping and tampering. Further, the common API gateway 245 provides a session identity (ID) for removing a participant from the ad-hoc conference call.
[0055] The processor 205 further implements an Edge Load Balancer (ELB) 250 communicably coupled to the validating unit 230 for routing the user request to a destination application based on a rule such as round-robin, context-based routing, header-based routing, and TCP-based routing. The destination application may be hosted on a web server or a gateway point for even distribution of network load over multiple backend servers.
[0056] Referring to FIG. 3 illustrating a block diagram of the system 125 communicating with a first UE 102-1 for managing conference calls, a preferred embodiment of the system 125 is described. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE 102-1 for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0057] The first UE 102-1 includes one or more primary processors 305 communicably coupled to the processor 205 of the system 125. The one or more primary processors 305 are coupled with a memory unit 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 102-1 to send a request to the system 125 to create an ad-hoc conference call. The first UE 102-1 further includes a kernel 315 which is a core component serving as the primary interface between hardware components of the first UE 102-1 and the plurality of services hosted by the system 125. The kernel 315 is configured to provide the plurality of services on the first UE 102-1 to resources available in the communication network 110. The resources include one of a Central Processing Unit (CPU), memory components such as Random Access Memory (RAM) and Read Only Memory (ROM).
[0058] In the preferred embodiment, the platform 228 of the processor 205 is communicably connected to the kernel 315 of the first UE 102-1. The platform 228 is configured to provide means for creating an ad-hoc conference call for the two or more participants. The platform 228 is also configured to provide means for adding participants into the ad-hoc conference call and removing participants from the ad-hoc conference call. The means includes a plurality of APIs, and the platform 228 offers the plurality of APIs for exploration and purchase by users accessing the UEs 102. The platform 228 i.e. API marketplace is a platform where developers can discover, explore, and consume APIs provided by various organizations or third-party developers. It serves as a central repository or marketplace where APIs are published, categorized, and made available for integration into applications, services, or platforms. Over the platform 228, users can view and purchase required APIs.
[0059] The processor 205 further implements a validating unit 230 configured to validate a user request associated with the ad-hoc conference call based on validation of an API key and a token for the ad-hoc conference call. The validating unit 230 may validate the API key using a customer API key extracted from the token. In one implementation, the validating unit 230 may be a Common Application Programming Interface (API) Framework (CAPIF) for 3rd Generation Partnership Project (3GPP) northbound APIs.
[0060] CAPIF is a standardized framework designed to facilitate interoperability and ease of integration across different network elements and services within 3GPP ecosystem. CAPIF aims to define common interfaces and protocols that enable seamless interaction between different components of a telecommunications network, particularly focusing on northbound APIs. Northbound APIs are those that expose network functionalities and data to higher layers or external entities such as applications, management systems, or other networks. CAPIF provides standardized specifications for APIs, ensuring that different network equipment vendors and service providers can develop compatible solutions. This standardization helps reduce integration efforts and accelerates the deployment of new services.
[0061] The processor 205 further implements an access management unit 235 configured to check a user plan and an access control policy based on the API key and forward the user request associated with the ad-hoc conference call to a Business Telephony Application Server (BTAS) network element. The user plan refers to a subscription or service arrangement defining features, capabilities, and limits available to the user for managing conference calls. The user plan may also define the access control policy, such as participant limit for a conference call, HD/4K audio and video support, screen sharing facility, and recording and playback feature.
[0062] In one implementation, the access management unit 235 may perform enrichment of the user request when the user plan and the API key are identified to be correct. Enrichment of the user request refers to enhancing the information or context associated with a user's request to improve accuracy, relevance, or completeness of the response or action taken. For example, the user request may be enriched by augmenting with contextual information, such as a location of the user or type of device accessed by the user.
[0063] The BTAS network element is configured to create the ad-hoc conference call for the two or more participants. Specifically, the BTAS is an API provider hosting APIs for the ad-hoc conference calls and managing flow of the ad-hoc conference call. The BTAS network element selects a destination (participant of the ad-hoc conference call) using round-robin fashion based on an available BTAS instance. After the ad-hoc conference call is created and the two or more participants have joined the ad-hoc conference call, the validating unit 230 may send notifications to a user who had got the ad-hoc conference call created. A User Interface (UI) of the validating unit 230 may be provided for visualizing data and performing configuration of the ad-hoc conference call. Visualizing the data refers to presenting names of the participants, content shared by a participant, and providing details of participants joining or leaving the conference call, etc. Performing configuration refers to changing setting of the conference call, such as providing screen sharing rights, call hosting rights, limiting number of participants, naming the participants, and ending the conference call.
[0064] BTAS is a specialized server or software platform designed to handle and manage various telephony applications and services within a business environment. BTAS serves as a platform for deploying and managing telephony applications such as interactive voice response (IVR) systems, call queuing, call recording, conferencing, voicemail, call routing, and other related services. These applications are essential for managing inbound and outbound calls effectively. BTAS integrates with existing telephony infrastructure, including Private Branch Exchange (PBX) systems, IP telephony systems (VoIP), and Unified Communications (UC) platforms. It provides APIs and interfaces for seamless integration with business applications, customer relationship management (CRM) systems, and other third-party services.
[0065] The processor 205 further implements a subscription engine 240. The subscription engine 240 is provided as a backend application of the platform 228 for storing user-related data along with subscription details.
[0066] The processor 205 further implements a common API gateway 245 configured to perform a token and Transport Layer Security (TLS) hand-shake for the ad-hoc conference call. TLS handshake is a critical process that occurs at the beginning of a TLS session between a client (such as a web browser) and a server (such as a web server). It establishes the parameters of the secure connection before any actual data transmission takes place. Further, the common API gateway 245 provides a session identity (ID) for removing a participant from the ad-hoc conference call.
[0067] The processor 205 further implements an Edge Load Balancer (ELB) 250 configured to route the user request to a destination application based on a rule such as round-robin, context-based routing, header-based routing, and TCP-based routing. The destination application may be hosted on a web server or a gateway point for even distribution of network load over multiple backend servers.
[0068] The ELB, also known as an Application Delivery Controller (ADC) or simply a load balancer, is a specialized device or software that distributes incoming network traffic across multiple servers or backend resources. The ELB operates at the edge of a network, typically between clients (such as web browsers or mobile devices) and servers (like web servers or application servers). The key function of an ELB is to evenly distribute incoming client requests across a pool of backend servers. This distribution prevents any single server from becoming overwhelmed, thereby improving overall performance and responsiveness of applications.
[0069] FIG. 4 illustrates a system architecture for managing conference calls, according to one or more embodiments of the present disclosure. The system 125 may offer multiple APIs, for example an API for creating a conference call, an API for adding participants to the conference call, and an API for removing participants from the conference call. A user wanting to create a conference call can create an account and log in using credentials. In one embodiment, the account is created at an application or a web portal of at least one of, but not limited to, the service provider. Details of the user, plan subscribed by the user, and other account related details such as credentials for allowing login may be stored in the database 220 of the system 125. After login, the user is provided with an option to choose from multiple APIs available on a marketplace 402 (similar to the platform 228) and purchase one or more APIs. The marketplace 402 may be a software platform available in public domain. The subscription engine 240 may be provided as a backend application of the marketplace 402 where all user-related data along with subscription details is stored.
[0070] The user’s request for creating the conference call for two or more participants may be received by the common API gateway 245 for authentication. Post authentication by the common API gateway 245, token and Transport Layer Security (TLS) hand-shake may be performed for the requested conference call.
[0071] Further, various checks may be performed by a Common API Framework (CAPIF) for 3GPP northbound APIs 404 (similar to the validating unit 230). The CAPIF 404 validates whether at least two participants are requested to be joined in the conference call that is an ad-hoc call. As such, the CAPIF 404 may validate request for each ad-hoc conference call request, and validate an API key and token for each call. If the token is valid, the CAPIF 404 may allow the user’s request. A customer API key may be extracted from a token (generated by the IAM component 412) and an API key validation may be performed. The API key and the token serve different roles in API authentication and authorization. The API key primarily identifies an application or service accessing the API, while the token authenticates and authorizes the user to perform action securely. Together, the API key and the token help ensure secure and controlled access to the APIs and the conference call service.
[0072] An Access Management System (AMS) 406 (similar to the access management unit 235) may perform a user’s plan check, an access control policy check, and an enrichment of an API call. Further, the AMS 406 may be configured to perform user and token related authentication. If the token and a Transport Layer Security (TLS) handshake is OK, then the request reaches a Business Telephony Application Server (BTAS) 408 (alternatively referred as a BTAS cluster). Otherwise, the request may be rejected. Further, if consumer/customer API key and plan are found to be OK, request enrichment may be performed. Enrichment of the user request refers to enhancing the information or context associated with a user's request to improve accuracy, relevance, or completeness of the response or action taken. For example, the user request may be enriched by augmenting with contextual information, such as a location of the user or type of device accessed by the user. Based on an available BTAS instance, a destination (participant of the ad-hoc conference call) may be picked using round-robin fashion. It should be noted that an API consumer 410 may be any application, developer, or enterprise that wants to use this API.
[0073] The BTAS 408 is a network element that deals with voice related use cases. The BTAS 408 may act as an API provider that hosts ad-hoc conference API and manages call flow of ad-hoc conference. The BTAS 408 may be configured to manage all the conference requests. For example, if there are 5 participants, the BTAS 408 may initiate a call for the 5 participants. Once the call reaches the BTAS 408, the BTAS 408 may create a conference call with indicated participants. Further, once the call is joined by the 5 members, the BTAS 408 may further send a notification to the user informing that the 5 participants have joined.
[0074] For the user to add a participant, a dedicated API may be provided that may be used to add the members. The BTAS 408 will therefore facilitate adding new participants as well. Further, in order to remove one or more participants from the call, a ‘remove’ API may be used. It should be noted that all the above functions are performed on-demand, i.e. these are application-driven and called by the user. If a participant is to be removed, a request may be received at a gateway. The gateway may forward the request along with other information like ‘session ID’. Thereafter, the participants are removed from the conference.
[0075] The system 125 further includes the Edge Load Balancer (ELB) 250 for routing the request to a destination application based on rules like round-robin, context-based routing, header-based routing, or TCP-based routing. The system 125 may include the Identity and Access Management (IAM) component 412 for performing identity and access management. The system 125 may further include an elastic search database 414 i.e. a database for storing all persistent records. The elastic search database 414 is scalable, document-oriented, and schema free database.
[0076] The system 125 may provide a user interface (UI) API dashboard 416 acting as a UI of the CAPIF 404 for visualizing data and perform configuration.
[0077] FIG. 5 illustrates an information flow diagram for managing conference calls, according to one or more embodiments of the present disclosure. At step 502, a consumer/user requests the ELB 250 to provide an open authentication (OATH) token. At step 504, the ELB 250 forwards the request to provide the token to the CAPIF 404. At step 506, the CAPIF 404 requests the IAM component 412 to provide the token. At step 508, the IAM component 412 validates the user and generates a token. Post successful authentication, the IAM component 412 provides the token to the CAPIF 404, at step 510. At step 512, the token is forwarded to the user via the ELB 250.
[0078] After receiving the token, the user sends a request, to the ELB 250, for creating an ad-hoc conference call, at step 514. At step 516, the ELB 250 initiates validation of the request of the user. At step 518, the ELB 250 communicates with the AMS 406 for checking user account and plan/subscription. At step 520, the AMS 406 may provide a positive response and a session ID to the ELB 250, upon successful validation of the request. At step 522, ELB 250 makes an API call with data and the session ID to the BTAS 408. At step 524, the BTAS 408 sends a response to the ELB 250, which is then provided to the user. Successively, the BTAS 408 provides a call status to the user via the ELB 250, at step 526.
[0079] FIGS. 6A and 6B collectively illustrate a timing diagram for managing conference calls, according to one or more embodiments of the present disclosure. At step 612, the CAPIF 404 may send an API request for creating an ad-hoc conference call to the BTAS 408. In one implementation, the API request may indicate inclusion of participant A 604, participant B 606, and participant C 608 into the conference call. Thereafter, a control dialog may be initiated with a Multimedia Resource Function (MRF) for initiating a Media Server Markup Language (MSML) session, at step 614.
[0080] MRF is a network element or component within telecommunications networks that plays a crucial role in handling and processing multimedia services and resources. An MRF is responsible for providing multimedia services such as voice and video conferencing, multimedia streaming (both live and on-demand), Interactive Voice Response (IVR) systems, and multimedia messaging (including instant messaging and multimedia email). An MRF performs various media processing functions, including codec transcoding (converting media between different audio and video formats), media mixing (combining multiple media streams into a single stream), media segmentation (breaking down media streams into manageable parts), and media packetization (formatting media into packets suitable for transmission over IP networks).
[0081] MSML is an XML-based markup language used in telecommunications and multimedia applications to control and manage interactions with media servers. A session involving MSML typically revolves around defining and controlling multimedia interactions between clients and media servers.
[0082] At step 616, the BTAS 408 may start inviting the participant A 604, the participant B 606, and the participant C 608 into the conference call. Once an invitation reaches the participant A 604, a device of the participant A 604 starts ringing, at step 618. Upon acceptance of the invitation, the participant A 604 is added to the conference call and an audio/video theme is played until the participant B 606 joins, at step 620. When the participant A 604 is added to the conference call, a media session is initiated between the participant A 604 and the MRF 602, at step 622.
[0083] Similar to the above described manner, the participant B 606 and the participant C 608 are also added into the conference call, at steps 624 through 636. Further, notifications may be provided for different activities including participant connected in the conference call, participant left the conference call, etc.
[0084] The above described method provides for an API-driven and REST-based solution for ad-hoc conference call creation. The API-based solution of the present disclosure can be integrated on the phone to equip the phone with a conferencing feature. As such, the method allows for secure onboarding of consumers and safe journey of API call. Moreover, provision of notification is provided that may notify the users about different events, such as conference created successfully with participants and addition or removal of a participant. Further, there is a provision for call back URL mapping for the consumer.
[0085] FIG. 7 illustrates a flow chart of a method 700 for managing conference calls, according to one or more embodiments of the present disclosure. For the purpose of description, the method 700 is described with the embodiments as illustrated in FIGS. 1 and 4 and should nowhere be construed as limiting the scope of the present disclosure.
[0086] At step 702, a user request for creating an ad-hoc conference API call is received. At step 704, a process of validation of a token is initiated. At step 706, if the token is determined to be invalid, a negative response is provided to the user, at step 708. When the token is determined to be valid, process of validation of an API key is determined, at step 710. At step 712, it is determined whether the API key is valid or not. At step 714, when the API key is determined to be invalid, a negative response is provided to the user, at step 708. Alternatively, when the API key is determined to be valid, process of validating user plan and access policy is initiated, at step 716. At step 718, API call logs are maintained.
[0087] At step 720, it is determined whether the user plan and access policy are valid. At step 722, when the user plan is determined to be invalid and/or the access policy check fails, a negative response is provided to the user. At step 724, enrichment of the user request is performed and a session ID is generated for creating a conference call. At step 726, a request is sent to the BTAS for initiating the conference call.
[0088] 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 user request for creating an ad-hoc conference call for two or more participants. The processor 205 is further configured to validate the user request associated with the ad-hoc conference call based on validation of an Application Programming Interface (API) key and a token for the ad-hoc conference call. The processor 205 is further configured to check a user plan and an access control policy based on the API key, and forwarding the user request associated with the ad-hoc conference call to a Business Telephony Application Server (BTAS). The processor 205 is further configured to create the ad-hoc conference call for the two or more participants.
[0089] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIGS.1-7) 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.
[0090] The above described techniques (of managing conference calls) of the present disclosure provide multiple advantages, including providing an API-driven and REST-based easy to integrate ad-hoc conference solution. The ad-hoc conference API can be implemented on any application for user to create a conference call. Further, the ad-hoc conference API allows users to create a conference call with a maximum duration, i.e. after the duration, the call is cut automatically. Moreover, maximum number of participants in a conference call can be defined by the users. Further, notifications for all activities performed on call are generated and shared with the participants. The ad-hoc conference API further provides for activities, such as addition or deletion of a participant, connecting, call ended, call failed, subscription expired, etc. Furthermore, each API call is monitored and logged
[0091] 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.
[0092] Server: A server may include or comprise, 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 defence facility, or any other facility that provides content.
[0093] Network: A network may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network may also include, 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.
[0094] UE/ Wireless Device: A wireless device or a user equipment (UE) may include, but are not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UEs may communicate with the system via set of executable instructions residing on any operating system. In an embodiment, the UEs may include, but are not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen and the like. It may be appreciated that the UEs may not be restricted to the mentioned devices and various other devices may be used.
[0095] System (for example, computing system): A system may include one or more processors coupled with a memory, wherein the memory may store instructions which when executed by the one or more processors may cause the system to perform offloading/onloading of broadcasting or multicasting content in networks. An exemplary representation of the system for such purpose, in accordance with embodiments of the present disclosure. In an embodiment, the system may include one or more processor(s). The one or more processor(s) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) may be configured to fetch and execute computer-readable instructions stored in a memory of the system. The memory 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 may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like. In an embodiment, the system may include an interface(s). The interface(s) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as input/output (I/O) devices, storage devices, and the like. The interface(s) may facilitate communication for the system. The interface(s) may also provide a communication pathway for one or more components of the system. Examples of such components include, but are not limited to, processing unit/engine(s) and a database. The processing unit/engine(s) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s). In such examples, the system may include the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the processing resource. In other examples, the processing engine(s) may be implemented by electronic circuitry. In an aspect, the database may comprise data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor or the processing engines.
[0096] Computer System: A computer system may include an external storage device, a bus, a main memory, a read-only memory, a mass storage device, communication port(s), and a processor. A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The communication port(s) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects. The main memory may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory may be any static storage device(s) including, but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor. The mass storage device may be any current or future mass storage solution, which may be used to store information and/or instructions. The bus communicatively couples the processor with the other memory, storage, and communication blocks. The bus can be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), universal serial bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor to the computer system. Optionally, operator and administrative interfaces, e.g. a display, keyboard, and a cursor control device, may also be coupled to the bus to support direct operator interaction with the computer system. Other operator and administrative interfaces may be provided through network connections connected through the communication port(s). In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.

REFERENCE NUMERALS
[0097] User Equipment – 102;
[0098] Server – 105;
[0099] Communication network - 110;
[00100] System - 125;
[00101] One or more processors -205;
[00102] Memory – 210;
[00103] Input/output interface unit – 215;
[00104] Database – 220;
[00105] Distributed cache – 225;
[00106] Platform – 228;
[00107] Validating unit – 230;
[00108] Access management unit – 235;
[00109] Subscription engine – 240;
[00110] Common API gateway – 245;
[00111] Edge load balancer – 250;
[00112] Primary processor of first UE - 305;
[00113] Memory unit of first UE – 310;
[00114] Kernel of the first UE – 315;
[00115] Marketplace – 402;
[00116] CAPIF – 404;
[00117] AMS – 406;
[00118] BTAS – 408;
[00119] API consumer – 410;
[00120] IAM component – 412;
[00121] Elastic search database – 414;
[00122] UI API dashboard – 416;
[00123] MRF – 602;
[00124] Participant A – 604;
[00125] Participant B – 606; and
[00126] Participant C – 608.

,CLAIMS:CLAIMS
We Claim:
1. A method of managing conference calls, the method comprising the steps of:
receiving, by one or more processors (205), a user request for creating an ad-hoc conference call for two or more participants (604, 606, 608);
validating, by the one or more processors (205), the user request associated with the ad-hoc conference call based on validation of an Application Programming Interface (API) key and a token for the ad-hoc conference call;
checking, by the one or more processors (205), a user plan and an access control policy based on the validated API key, and forwarding the user request associated with the ad-hoc conference call to a Business Telephony Application Server (BTAS) network element; and
creating, by the one or more processors (205), the ad-hoc conference call for the two or more participants.

2. The method as claimed in claim 1, the user request is received from one of an application, an application developer, and an enterprise.

3. The method as claimed in claim 1, comprising performing, by the one or more processors (205), a token and Transport Layer Security (TLS) hand-shake for the conference call.

4. The method as claimed in claim 1, comprising verifying, by the one or more processors (205), whether at least two participants (604, 606, 608) are requested to be added in the ad-hoc conference call.

5. The method as claimed in claim 1, the API key is validated using a customer API key extracted from the token.

6. The method as claimed in claim 1, comprising sending, by the one or more processors (205), notifications to the user when the two or more participants (604, 606, 608) join the ad-hoc conference call.

7. The method as claimed in claim 1, comprising providing, by the one or more processors (205), session identity (ID) for removing a participant from the ad-hoc conference call.

8. The method as claimed in claim 1, comprising routing, by the one or more processors (205), the user request to a destination application based on a rule selected from a group consisting of round-robin, context-based routing, header-based routing, and Transmission Control Protocol (TCP)-based routing.

9. The method as claimed in claim 1, the user request allows selection of one or more APIs, the one or more APIs are Representational State Transfer (REST) APIs.

10. The method as claimed in claim 1, comprising receiving the user request for at least one of adding participants into the ad-hoc conference call and removing participants from the ad-hoc conference call.

11. The method as claimed in claim 1, comprising authenticating, by the one or more processors (205), the user request through a common API gateway (245).

12. A system (125) for managing conference calls, the system (125) comprising:
a platform (228) configured to provide means for creating an ad-hoc conference call for two or more participants (604, 606, 608);
a validating unit (230) configured to validate a user request associated with the ad-hoc conference call based on validation of an API key and a token for the ad-hoc conference call; and
an access management unit (235) configured to check user plan and access control policy based on the validated API key and forward the user request associated with the ad-hoc conference call to a Business Telephony Application Server (BTAS) network element,
wherein the BTAS network element is configured to create the ad-hoc conference call for the two or more participants, and wherein the BTAS (408) is an API provider hosting APIs for the ad-hoc conference calls and managing flow of the ad-hoc conference call.

13. The system (125) as claimed in claim 12, wherein the platform (228) is further configured to provide means for adding participants into the ad-hoc conference call and removing participants from the ad-hoc conference call.

14. The system (125) as claimed in claim 13, wherein the means includes a plurality of APIs, and the platform (228) offers the plurality of APIs for exploration and purchase by a user.

15. The system (125) as claimed in claim 12, comprises a subscription engine (240) provided as a backend application of the platform (228) for storing user-related data along with subscription details.

16. The system (125) as claimed in claim 12, comprises a common API gateway (245) for performing a token and Transport Layer Security (TLS) hand-shake for the ad-hoc conference call.

17. The system (125) as claimed in claim 12, wherein the validating unit (230) verifies whether at least two participants are requested to be added in the ad-hoc conference call.

18. The system (125) as claimed in claim 12, wherein the validating unit (230) validates the API key using a customer API key extracted from the token.

19. The system (125) as claimed in claim 12, wherein the access management unit (235) performs enrichment of the user request when the user plan and the API key are identified to be correct.

20. The system (125) as claimed in claim 12, wherein the validating unit (230) sends notifications to the user when the two or more participants join the ad-hoc conference call.

21. The system (125) as claimed in claim 16, wherein the common API gateway (245) provides a session identity (ID) for removing a participant from the ad-hoc conference call.

22. The system (125) as claimed in claim 12, wherein the BTAS network element selects a destination using round-robin fashion based on an available BTAS instance.

23. The system (125) as claimed in claim 12, comprises an Edge Load Balancer (ELB) (250) configured to route the user request to a destination application based on a rule selected from a group consisting of round-robin, context-based routing, header-based routing, and TCP-based routing.

24. The system (125) as claimed in claim 12, wherein the system (125) provides a User Interface (UI) of the validating unit (230) for visualizing data and performing configuration of the ad-hoc conference call.

25. A User Equipment (UE) (102) comprising:
one or more processors (305) coupled with a memory (310), wherein said memory (310) stores instructions which when executed by the one or more processors (305) causes the UE (102) to:
send a user request for creating an ad-hoc conference call for two or more participants (604, 606, 608),
wherein the one or more processors (305) is configured to perform the steps as claimed in claim 1.