Systems and methods for processing call-back requests

Abstract

A system (108) and a method (500) for processing call-back requests are disclosed The method (500) comprises maintaining (502) a queue for each time slot of a plurality of time slots and receiving (504) a call-back request from a user (102). The call-back request comprises call-back data indicative of a preferred time for call-back. The method (500) further comprises storing (506) the call-back request in queue maintained for corresponding time slot that matches the preferred time, executing (508) system cyclic timer to scan each queue according to time slots, retrieving (510) call-back request from corresponding queue based on time slot, executing (512) call for user (102) with an agent responsive to call-back request at the preferred time, processing (514) call to determine whether the call was successfully executed, and after determining that call was not successfully executed, executing (516) retry cyclic timer to re-attempt call after a pre-determined time interval.

Description

SYSTEM AND METHOD FOR PROCESSING CALL-BACK REQUESTSRESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to JIO PLATFORMS LIMITED (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.FIELD OF THE DISCLOSURE

[0002] The present disclosure relates generally to the field of wireless communication systems. More particularly, the present disclosure relates to a system and a method for processing call-back requests.DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] The expression “call-back request” refers to a service where a user can register a request to get a call-back from a service provider (for example, a call center) at the user's preferred time.

[0005] The expression “call-back” refers to a process of scheduling a return call to a user instead of having the user wait on hold.

[0006] The expression “call-back data” refers to information collected and managed regarding call-back requests and interactions. The call-back data is used to optimize service providers’ operations, improve user satisfaction, and ensure adequate follow-up. In an example, call-back data may include a preferred time of the user for a call-back.

[0007] The expression “system restart” refers to a process in which a system is completely turned off and then turned back on again.

[0008] The expression “process failover” refers to a mechanism designed to maintain the uninterrupted operation of a system by shifting the workload or process management to a standby or backup process when the primary method fails.

[0009] The expression “queues” refers to one or more lists where call-back requests from users are logged and managed. The queues ensure that each call-back request is processed systematically and prioritized based on urgency or user priority.

[0010] The expression “time slot” refers to a specific, pre-defined interval or segment of time within a schedule or timeline used to organize and manage activities or tasks. For example, a time slot refers to a designated period during which a particular action, such as placing a call-back to a user, is scheduled to occur. Each time slot typically has a start and end time and can be configurable according to specific requirements, such as service provider or user preferences.

[0011] The expression “system cyclic timer” refers to a software or hardware mechanism that generates periodic interrupts or events at regular, pre -defined intervals.

[0012] The expression “retry cyclic timer” refers to a type of cyclic timer used to repeatedly attempt an action or operation at regular intervals, particularly when an initial attempt has failed.

[0013] The expression “failed calls” refers to instances where attempts to return a user's call or fulfill a call-back request fail. The reasons for failed calls include technical issues (e.g., network problems, telephony failures, timeouts, network connection errors, server downtime), configuration errors (incorrect settings, expired credentials), and customer unavailability (no response, busy lines, etc.).

[0014] The expression “re-attempt the call” refers to attempting to contact the user after an initial call has failed or been unsuccessful.

[0015] The expression “pre-configured number of retries” refers to a specific, predetermined limit on the number of times an action or process will be attempted before considering it a failure. The limit may be established based on system settings or configuration parameters.

[0016] The expression “pre-determined frequency” refers to a specific, established rate at which an action or event is scheduled to occur.

[0017] The expression “user-defined criteria” refers to specific rules, parameters, or standards the user sets that guide a system or process. These criteria are customizable according to the user's needs or preferences, allowing for personalized or tailored functionality.

[0018] The expression “check-point the call-back data” refers to creating a saved state of the data at a specific point in time. This process ensures that the data can be recovered or restored from that saved state in case of system failures, restarts, or crashes.

[0019] The expression “mate process” refers to storing the call-back data in a duplicate or secondary system, ensuring that the call-data is preserved and accessible even if the primary process encounters issues.

[0020] The expression “pre-determined time interval” refers to a specific duration set or established in advance for a particular action or process.

[0021] The expression “agent” refers to a person responsible for answering the call initiated by the system in response to a user's request. The agent engages with the user to address their inquiries, resolve issues, provide information, or assist with transactions. In some examples, the agent may refer to an automated system or software, such as a chatbot, virtual assistant, or interactive voice response (IVR) system, that interacts with the users without human intervention. The agent may handle tasks such as answering queries, processing transactions, or providing user support based on predefined rules, artificial intelligence, or machine learning algorithms.

[0022] The expression “one or more service provider requirements” refers to the specific criteria, conditions, or preferences established by the service provider that dictate how the system should be configured and operated.

[0023] The expression “Session Initiation Protocol (SIP)” refers to a signaling protocol used to establish, maintain, and terminate real-time communication sessions over Internet protocol (IP) networks. The SIP is widely utilized in voice-over IP (VoIP), video conferencing, and other multimedia communication applications.

[0024] The expression “Internet protocol (IP) Multimedia Subsystem (IMS)” refers to a standardized architecture used to deliver IP -based multimedia services, such as voice, video, and messaging, over broadband networks.

[0025] The expression “Online Charging System (OCS)” refers to a real-time system that manages and processes billing, charging, and account balances for telecommunications services as they are used.

[0026] The expression “Common API Framework (CAPIF)” refers to a standardized framework for developing and managing APIs that facilitate integration between different systems and components. The CAPIF ensures seamless interoperability and communication among diverse software systems and hardware components.

[0027] The expression “Diameter” refers to a protocol used for authentication, authorization, and accounting (AAA) in network environments.

[0028] The expression “Diameter Routing Agent (DRA) refers to a network component used in Diameter-based systems to manage and route Diameter messages between nodes in a telecommunications network.

[0029] The expression “Caller Ring back Tones (CRBT)” refers to personalized audio tones that callers hear while waiting for their call to be answered, replacing the standard ringing sound with music, messages, or other content chosen by the call recipient.

[0030] The expression “Media Resource Function (MRF)” refers to a network component providing media processing capabilities within multimedia communication systems, such as conferencing, playback, and recording.

[0031] The expression “Element Management System (EMS)” refers to a network management system that focuses on configuring, monitoring, and maintaining individual network elements or devices.

[0032] The expression “Operational Support System (OSS)” refers to a comprehensive framework used for managing, controlling, and optimizing telecommunications network operations and services, including provisioning, fault management, and performance monitoring.

[0033] The expression “Business Support System (BSS)” refers to a set of software applications and tools used for managing and supporting business processes in telecommunications, such as billing, customer relationship management, and service provisioning.

[0034] The expression “Load Balancer” refers to a device or software application that distributes network or application traffic across multiple servers to ensure no single server becomes overwhelmed.

[0035] The expression “Telephony Application Server (TAS)” refers to a platform that provides telephony services and application support, enabling advanced call processing, messaging, and integration with communication networks.

[0036] The expression “Hypertext Transfer Protocol (HTTP)” refers to a protocol, a set of rules and conventions for communication between computers over the network. It is the foundation of data communication on the World Wide Web. It is designed to facilitate the exchange of information between clients (such as web browsers) and servers (where websites and web applications reside).

[0037] The expression “Adaptive Troubleshooting and Operations Management (ATOM)” refers to a platform designed to improve how organizations handle operational issues and manage ongoing processes.

[0038] The expression “Request Callback application programming interface (API) (HTTP)” refers to an interface that allows applications to request a call-back or to schedule a call-back operation over HTTP. The API involves making HTTP requests to a server to initiate a call-back process, which can be used in various scenarios such as customer support, notifications, or service integration.

[0039] The expression “INVITE (w / o session description protocol (SDP))” refers to an invite used to initiate a communication session or invite participants to a session without the SDP. The SDP format describes multimedia communication sessions, including details like media types (audio, video), codecs, network information, and session attributes.

[0040] These definitions are in addition to those expressed in the art.BACKGROUND

[0041] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance theunderstanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0042] “Request- a-call back” is a standard service provided by service providers such as call centers and customer support departments. A user can register a request to receive a call-back at a convenient time rather than waiting on hold. For instance, the user can specify a preferred time for the call-back. The “Request-a-call back” service aims to improve customer satisfaction and reduce wait times. However, this service has implementation challenges, such as registering multiple call-backs and triggering calls as per the requested time, as it requires multiple timers to be started at the application end. For example, each call must be scheduled so that the timer is required to be started at the exact time so that a user gets a call. Additionally, callback data retention is one of the challenges faced, especially in system restart or process failover.

[0043] Accordingly, there is a need for an efficient request-a-call-back architecture or design.SUMMARY

[0044] In an exemplary embodiment, a system for processing a call-back request is described. The system comprises an execution unit configured to maintain a queue for each time slot of a plurality of time slots and receive the call-back request from a user. The call-back request comprises call-back data indicative of a preferred time for a call-back. The execution unit is further configured to store the call-back request in the queue maintained for a corresponding time slot that matches the preferred time and execute a system cyclic timer to scan each queue according to time slots. A determination unit coupled with the execution unit is configured to retrieve the callback request from the corresponding queue based on the time slot, execute a call for the user with an agent responsive to the call-back request at the preferred time of the user, process the call to determine whether the call was successfully executed. In response to determining that the call was not successfully executed, the determinationunit is configured to execute a retry cyclic timer to re-attempt the call after a predetermined time interval.

[0045] In some embodiments, the execution unit is configured to store the callback request in a database.

[0046] In some embodiments, in response to determining that the call was unsuccessful, the determination unit is configured to retrieve the call-back request from the database and re-attempt the call after the predetermined time interval.

[0047] In some embodiments, the execution unit is configured to check-point the call-back data to a mate process.

[0048] In some embodiments, the determination unit is configured to notify the user if a call-back attempt fails after a pre-configured number of retries.

[0049] In some embodiments, the determination unit is configured to execute the retry cyclic timer to scan a list of failed calls and re-attempt the failed calls at a predetermined frequency.

[0050] In some embodiments, each time slot is configurable according to one or more service provider requirements.

[0051] In another exemplary embodiment, a method for processing a call-back request. The method includes maintaining, by an execution unit, a queue for each time slot of a plurality of time slots. The method includes receiving, by the execution unit, the call-back request from a user, where the call-back request comprises callback data indicative of a preferred time for a call-back. The method includes storing, by the execution unit, the call-back request in the queue maintained for a corresponding time slot that matches the preferred time. The method includes executing, by the execution unit, a system cyclic timer to scan each queue according to time slots. The method includes retrieving, by the determination unit, the call-back request from the corresponding queue based on the time slot. The method includesexecuting, by the determination unit, a call for the user with an agent responsive to the call-back request at the preferred time of the user. The method includes processing, by the determination unit, the call to determine whether the call was successfully executed. The method includes, in response to determining that the call was not successfully executed, executing, by the determination unit, a retry cyclic timer to re-attempt the call after a pre-determined time interval.

[0052] In some embodiments, the method further comprises storing, by the execution unit, the call-back request in a database.

[0053] In some embodiments, in response to determining that the call was unsuccessful, retrieving, by the determination unit, the call-back request from the database and re-attempt the call after the predetermined time interval.

[0054] In some embodiments, the method further comprises check-pointing, by the execution unit, the call-back data to a mate process.

[0055] In some embodiments, the method further comprises notifying, by the determination unit, the user if a call-back attempt fails after a pre-configured number of retries.

[0056] In some embodiments, the method further comprises executing, by the determination unit, the retry cyclic timer to scan a list of failed calls and reattempting, by the determination unit, the failed calls at a pre-determined frequency.

[0057] In some embodiments, each time slot is configurable according to one or more service provider requirements.

[0058] In yet another exemplary embodiment, a user equipment (UE) communicatively coupled with a network. The coupling comprises receiving, by the network, a connection request from UE, sending, by the network, an acknowledgment of the connection request to the UE, and transmitting a plurality of signals in response to the connection request. The network is configured for performing a method forprocessing a call-back request. The method comprises maintaining a queue for each time slot of a plurality of time slots and receiving the call-back request from a user. The call-back request comprises call-back data indicative of a preferred time for a call-back. The method further comprises storing the call-back request in the queue maintained for a corresponding time slot that matches the preferred time, executing a system cyclic timer to scan each queue according to time slots, retrieving the callback request from the corresponding queue based on the time slot, executing a call for the user with an agent responsive to the call-back request at the preferred time of the user, processing the call to determine whether the call was successfully executed, and in response to determining that the call was not successfully executed, executing a retry cyclic timer to re-attempt the call after a pre-determined time interval.

[0059] In yet another exemplary embodiment, a computer program product is described. The computer program product comprises a non-transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for processing a call-back request. The method comprises maintaining a queue for each time slot of a plurality of time slots and receiving the call-back request from a user. The call-back request comprises call-back data indicative of a preferred time for a call-back. The method further comprises storing the call-back request in the queue maintained for a corresponding time slot that matches the preferred time, executing a system cyclic timer to scan each queue according to time slots, retrieving the call-back request from the corresponding queue based on the time slot, executing a call for the user with an agent responsive to the call-back request at the preferred time of the user, processing the call to determine whether the call was successfully executed, and in response to determining that the call was not successfully executed, executing a retry cyclic timer to re-attempt the call after a pre -determined time interval.OBJECTIVES

[0060] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0061] An objective of the present disclosure is to provide an efficient request-a- call-back architecture or design.

[0062] Another objective of the present disclosure is to maintain queues for callback requests received from users for each time slot.

[0063] Another objective of the present disclosure is to store call-back data in a database and check-point the call-back data to mate process.

[0064] Yet another objective of the present disclosure is to run a system cyclic timer continuously to scan each time slot as per current time.

[0065] Yet another object of the present disclosure is to run a retry cyclic timer to scan a list of failed calls.

[0066] Yet another object of the present disclosure is to re-attempt the failed calls for a configured number of times before marking the calls as failed.

[0067] Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

[0068] 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.

[0069] FIG. 1 illustrates an exemplary network architecture for implementing a system for processing a call-back request, in accordance with an embodiment of the present disclosure.

[0070] FIG. 2 illustrates an exemplary block diagram of the system for processing the call-back request, in accordance with an embodiment of the present disclosure.

[0071] FIG. 3A illustrates an exemplary system architecture of the system, in accordance with an embodiment of the present disclosure.

[0072] FIG. 3B illustrates another exemplary system architecture for implementing the system, in accordance with an embodiment of the present disclosure.

[0073] FIG. 4 illustrates an exemplary flow diagram describing “request-a-call- back” service, in accordance with an embodiment of the present disclosure.

[0074] FIG. 5 illustrates an exemplary flow diagram of a method for processing a call-back request, in accordance with an embodiment of the present disclosure.

[0075] FIG. 6 illustrates an exemplary computer system in which or with which the embodiments of the present disclosure may be implemented.

[0076] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 Network architecture102 User(s)104 User Equipments (UEs)106 NetworkSystemBlock diagramProcessor(s)MemoryInterface(s)DatabaseExecution unitDetermination unit A System architectureInternet protocol (IP) multimedia subsystem (IMS)Mobile number portability (MNP)Online charging system (OCS)Diameter routing agent (DRA)Caller ring back tone (CRBT)Media resource function (MRF)Element management system (EMS)Operations support system / business support system (OSS / BSS)Load Balancer B System ArchitectureEvolved Packet System (EPS)Provisioning serverTelephony Application Server (TAS) unitCommon API framework (CAPIF)Adaptive troubleshooting and operations management (ATOM) platformCharging function (CHF)Subscription engineFulfilment management system (FMS)Unified inventory manager (UIM)Market place and self-care portalFlow DiagramCustomer CareInterconnection border control function (IBCF)Flow DiagramComputer systemExternal Storage DeviceBusMain MemoryRead Only MemoryMass Storage DeviceCommunication Port670 ProcessorDETAILED DESCRIPTION

[0077] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0078] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0079] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0080] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0081] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0082] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0083] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0084] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and / or transmitting one or parameters, performing function / s, communicating with other user devices and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and / or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.

[0085] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general -purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.

[0086] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G), sixth generation (6G), and more such generations are expected to continue in the forthcoming time.

[0087] Radio Access Technology (RAT) refers to the technology used by mobile devices / user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Universal MobileTelecommunications System (UMTS), Long-Term Evolution (LTE), 5G, and 6G. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's / device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.

[0088] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0089] “Request- a-call back” is a standard service provided by service providers such as call centers and customer support departments. A user can register a request to receive a call-back at a convenient time rather than waiting on hold. For instance, the user can specify a preferred time for the call-back. The “Request-a-call back” service aims to improve customer satisfaction and reduce wait times. However, this service has implementation challenges, such as registering multiple call-backs and triggering calls as per the requested time, as it requires multiple timers to be started at the application end. For example, each call must be scheduled so that the timer is required to be started at the exact time so that a user gets a call. Additionally, callback data retention is one of the challenges faced, especially in system restart or process failover.

[0090] Accordingly, there is a need for systems and methods for processing callback requests from users.

[0091] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings FIGs 1-6.

[0092] FIG. 1 illustrates an exemplary network architecture (100) for implementing a system (108) for processing a call -back request, in accordance with an embodiment of the present disclosure.

[0093] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2... 104-N) associated with one or more users (102-1, 102-2... 102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2... 102-N) may collectively be referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2... 104-N) may collectively be referred to as the UE (104). Although only three UE (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.

[0094] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE (104) may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not limited to, intelligent, multisensing, network-connected devices, which may integrate seamlessly with each other and / or with a central server or a cloud-computing system or any other device that is network-connected.

[0095] Additionally, in some embodiments, the UE (104) may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but are not limited to, any electrical, electronic, electromechanical, or 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 UE (104) may include one or more inbuilt or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.

[0096] Referring to FIG. 1, the UE (104) may communicate with the system (108) through a network (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one of a 5G network, 6G network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and / or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0097] In an embodiment, the network (106) 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 (106) may also include, by way of example but not limitation, one or more of a radio access network (RAN), 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.

[0098] In an embodiment, the UE (104) is communicatively coupled with the system (108). The system (108) may receive a connection request from the UE (104). The system (108) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request. The system (108) may be configured for processing a call back request.

[0099] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0100] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for processing the call-back request, in accordance with an embodiment of the present disclosure.

[0101] Referring to FIG. 2, in an embodiment, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implementedas one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer -readable instructions stored in a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non- transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.

[0102] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a database (210), an execution unit (214) and a determination unit (216).

[0103] The system includes the execution unit (214) and the determination unit (216).

[0104] In an aspect, the execution unit (214) is configured to maintain a queue for each time slot of a plurality of time slots. The queue is maintained for each time slot to store a plurality of call -back requests from the plurality of users (102) (interchangeably referred to as customers). In an implementation, the execution unit (214) is configured to receive a call-back request from a user (102). The call-back request includes call-back data indicative of a preferred time for a call-back. The preferred time for a call-back refers to a specific time or a time slot when the user (102) would like to be contacted or receive a return call.

[0105] The execution unit (214) is further configured to store the call -back request in the queue maintained for a corresponding time slot that matches the preferred time or in which the preferred time falls. In an aspect, the request will be stored in the queue that matches with time slot preferred by the customer. For example, if the customer prefers to be called back between 2 PM and 3 PM, the callback request will be stored in the queue for that specific time slot (i.e., 2 PM to 3 PM).

[0106] The execution unit (214) further stores the call -back request and associated call-back data in the memory (204) and / or the database (210). The callback data is used to manage and track the call-back request. Furthermore, the execution unit (214) is further configured to check-point the call -back data to a mate process. The call-back data is check-pointed to ensure the call-back is performed at the preferred time.

[0107] The execution unit (214) is configured to periodically or continuously execute a system cyclic timer to scan each queue according to time slots. The system cyclic timer is used to manage and schedule the call-back to the user (102). The system cyclic timer assists in handling the call-backs promptly and improves customer satisfaction. Each time slot is configurable according to one or more service provider requirements, such as operational hours, resource availability, and compliance and service level agreements (SLAs).

[0108] The determination unit (216) is configured to retrieve the call -back request of the user (102) from the corresponding queue based on the time slot. The determination unit (216) executes a call for the user (102) with an agent responsive to the call-back request at the preferred time of the user (102). For example, if the customer's preferred time for a callback is between 2 PM and 3 PM, the agent responsible for the callback request may perform the callback within that time period (i.e., 2 PM to 3 PM). The determination unit (216) is configured to process the call to determine whether the call was successfully executed. In response to determining that the call was not successfully executed, the determination unit (216) may retrieve thecall-back request and associated call-back data from the memory (204) and / or the database (210).

[0109] In an implementation, the determination unit (216) may retrieve the callback request and associated call-back data from the memory (204) and / or the database (210) based at least on one of system restart and process failover. The system restart includes, but is not limited to, software updates, performance issues, configuration changes, system error, security measures, resource management, network changes, scheduled maintenance. The process failover includes, but is not limited to, server crash, network outage, software bug, overload, high traffic, system updates, scheduled maintenance, power outages, connectivity loss, security incidents, etc.

[0110] The determination unit (216) may execute a retry cyclic timer to reattempt the call after a pre-determined time interval. For example, the pre-determined time interval may be a 10-minute period set between retries for a failed call attempt. The pre-determined time interval may indicate that the determination unit (216) waits for 10 minutes before attempting to make the call again. In an implementation, the determination unit (216) is configured to re-attempt (call -back attempt) the failed call for a pre-configured number of retries before marking the call as failed. The preconfigured number of retries refers to a specific, predetermined limit on the number of times the system will attempt to perform an action, such as making a call-back, after an initial failure. For example, if a call attempt fails, the system (108) may be set to automatically retry the making the call up to three times before stopping or marking the call as failed. In an implementation, the determination unit (216) is configured to notify the user (102) if the call-back attempt fails after the preconfigured number of retries. After making three attempts, the user will be informed about the callback attempts and the fact that three callbacks were made.

[0111] Although the above description is provided with respect to a single call -back request, in some embodiments, the determination unit (216) may process a plurality of call -back requests received from a plurality of users (102) in a similarmanner as described above. The call-back requests and associated call-back data may be stored in the memory (204) and / or the database (210). In an implementation, the determination unit (216) may execute the retry cyclic timer to scan a list of failed calls and re-attempt the failed calls at a pre -determined frequency. The predetermined frequency may specify that retry attempts should occur every 20 minutes. For instance, the determination unit (216) will wait 20 minutes after a failed attempt before making another retry attempt based on the preconfigured settings. The list of failed calls may also be stored in the memory (204) and / or the database (210).

[0112] The determination unit (216) may retrieve the list of failed calls and associated call-back data from the memory (204) and / or the database (210). The list of failed calls is retrieved to identify the calls that didn’t succeed. The list of failed calls and associated call-back data is used to manage the call-back process.

[0113] In an aspect, the determination unit (216) may then prioritize the failed calls based on user-defined criteria. The user-defined criteria include, but are not limited to, time of the failed calls, type of caller, reason for the failure, frequency of calls, etc. The time of the failed calls is a criterion that considers when the call attempt was made. The calls that occurred more recently may be given higher priority for callbacks. The type of caller is a criterion that categorizes callers based on predefined classifications. Certain types of callers can be given priority over others. For example, high-value clients or clients with a history of significant transactions may be prioritized to maintain customer satisfaction and loyalty. Calls from business clients might be prioritized over regular consumers. The reason for the failure is a criterion that assesses why the call failed. The failure reasons can indicate varying levels of urgency. For example, a call that resulted in no answer might be treated as less urgent than the call that encountered a busy signal or was intentionally dropped. The calls that failed due to technical problems might also be prioritized differently, especially if the caller reported an ongoing issue. The frequency of calls is a criterion that tracks how many times a particular number has attempted to reach out. Frequent callers might indicate a more pressing need for assistance.

[0114] In an aspect, the retry cyclic timer is triggered at the predetermined frequency to reattempt the call-back execution for the failed calls. The call-back execution is reattempted at the predetermined frequency (i.e., predefined time intervals) for the failed calls. By reattempting failed calls at the predefined time intervals, the chances of reaching out to customers who may need assistance or have important inquiries are enhanced. This helps in reducing response times and ensures that failed calls are not overlooked.

[0115] FIG. 3A illustrates an exemplary system architecture (300A) of the system (108), in accordance with an embodiment of the present disclosure.

[0116] As shown in FIG. 3A, the system architecture (300A) includes user equipment (UE) (104) and an internet protocol (IP) multimedia subsystem (IMS) (306). The system architecture (300A) may include a number of components (modules) such as a mobile number portability (MNP) (308), online charging system (OCS) (310), diameter routing agent (DRA) (312), caller ring back tone (CRBT) (314), media resource function (MRF) (316), element management system (EMS) (318), operations support system / business support system (OSS / BSS) (320), load balancer (322), provisioning server (324), and a telephony application server (TAS) unit (330). The system architecture (300A) may be 4G, 5G, or 6G network architecture. The UE (104) is connected to the IMS (306) via the Session Initiation Protocol (SIP) to manage and control multimedia communication sessions.

[0117] In an implementation, the TAS unit (330) may be a collaborative framework to rapidly develop and fulfill the service needs of enterprise and residential customers. The TAS unit (330) may be a SIP application server interacting with core IMS to host a wide array of cloud telephony enterprise services. In an implementation, the execution unit (214) of the system (108) may be implemented within the TAS unit (330). The UE (104) may be a Voice over LTE (VoLTE) device that a user may use to register a request to receive a call-back at a preferred time. The IMS (306) is a standard-based architectural framework for delivering multimedia communications services such as voice, video, and text messaging over IP networks.In an implementation, the IMS (306) may be an architecture that works with 4G, 5G, or 6G mobile core networks to deliver voice calls, messages, and other potential realtime services. The MNP (308) allows a telecom service user to move from one operator to another operator, irrespective of geographical area. The OCS (310) is a system that allows communications service providers to charge their customers in real-time based on service usage. The DRA (312) is a functional element that provides real-time routing capabilities to ensure that messages are routed among the correct elements in a network.

[0118] In an implementation, the CRBT (314) is a value-added service that allows customization of the ring back tone. When a call is placed, the caller may hear an audible alert through his or her device. The MRF (316) is a carrier-class product for service providers virtualizing their networks. The MRF (316) provides media services like announcements, tones, and conferencing for VoLTE, Wi-Fi calling, and fixed voice-over Internet protocol (VoIP) solutions. The EMS (318) may manage specific types of one or more network elements within a telecommunication management network. The OSS / BSS (320) may be a collection of hardware and software tools designed to help organizations monitor, analyze, and manage telecom networks. For example, the OSS / BSS (320) may include components that a telecommunications service provider uses to run its business operations toward customers. The load balancer (322) provides service providers with comprehensive 5G security solutions to protect networks from core to far edge, defending against sophisticated fraud and abuse. The EMS (318) connects users, computers, and related devices across departments, facilitating access to data and business insights.

[0119] According to an implementation, the system components of the system architecture (300A) may communicate via different protocols including, but not limited to, a diameter protocol, a SIP protocol, a representational state transfer (REST) protocol, and a media sessions markup language (MSML) protocol. The diameter protocol is a next-generation industry-standard protocol that exchanges authentication, authorization, and accounting (AAA) information in long-termevolution (LTE) and IMS networks. The SIP protocol is a signaling protocol that enables VoIP by defining the messages sent between endpoints and managing the actual elements of a call. The SIP protocol supports voice calls, video conferencing, instant / messaging, and media distribution. The REST protocol is a protocol that imposes certain constraints to be satisfied by an API. The MSML protocol controls and invokes many different types of services on IP media servers.

[0120] Although FIG. 3A shows exemplary components of the system architecture (300A), in other embodiments, the system architecture (300A) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 3A. Additionally, or alternatively, one or more components of the system architecture (300A) may perform functions described as being performed by one or more other components of the system architecture (300A).

[0121] FIG. 3B illustrates another exemplary system architecture (300B) for implementing for implementing the system (108), in accordance with an embodiment of the present disclosure.

[0122] Referring to FIG. 3B, the TAS unit (330) is configured to perform a “request-a-call-back” service.

[0123] As shown in FIG. 3B, the system architecture (300B) includes the TAS unit (330), an Evolved Packet System (EPS) (323), common API framework (CAPIF) (350), an adaptive troubleshooting and operations management (ATOM) platform (352), charging function (CHF) (354), subscription engine (356), fulfillment management system (FMS) (358), unified inventory manager (360), and market place and self-care portal (362). The system architecture (300B) may also include an EDGE load balancer (not shown).

[0124] In an implementation, the CAPIF (350) is a network layer API, enabling abstraction and orchestration capability. It is a platform that exposes network capabilities as Restful APIs. The ATOM platform (352) is a cloud-native data lakeplatform tailored for carriers to enable smarter operations through machine learning (ML). The ATOM platform (352) leverages machine learning to detect anomalous network patterns and create reports and alerts based on these patterns for proactive root cause analysis and resolution before the network symptoms start affecting operations. The CHF (354) is responsible for completing the billing function. The subscription engine (356) is an e-commerce portal that manages digital offer catalog and pricing, subscription management, billing, revenue recognition and quoting. The FMS (358) is a workflow orchestration, provisioning and activation platform that simplifies operations by replacing a traditional, high-touch management model with a next-generation, programmable and virtualized model. The unified inventory manager (360) stores the logical and physical inventory data of every asset, device, node, and application, including active and passive devices. All touch points in the network that need to provision or query the inventory data for enrichment have an interaction with the unified inventory manager (360).

[0125] According to an implementation, the TAS unit (330) may maintain a queue for each time slot as per service provider requirements. In an example, there may be N number of time slots. For instance, a day may be divided into 15-minute time slots. For example, for time slot 11 AM to 11:15 AM, the TAS unit (330) may maintain one queue (referred to as the first queue), and for time slot 11: 15 AM to 11:30 AM, the TAS unit (330) may maintain another queue (referred to as second queue). In an implementation, the time slots may be configurable as per service provider requirements.

[0126] In an implementation, the TAS unit (330) may receive a call-back request from a user (102). For example, the call-back request may include call-back data. For example, the call-back data may include a preferred time or preferred time slot provided by the user (102) for call-back. In an example, the preferred time provided by the user (102) may be 11:20 AM. According to an implementation, the TAS unit (330) may store the call-back request in a queue maintained for a time slot in which the preferred time falls. For instance, if the preferred time provided by the user (102)is 11:20 AM, then the TAS unit (330) may store the call-back request received from the user (102) in the second queue. Further, the call-back data is stored in the database (210) (e.g., system-shared memory).

[0127] In an aspect, the call-back data is check-pointed to the mate process. The call-back data corresponding to the call-back request is checkpointed to store the status of the call-back request, ensuring that the call-back is performed within the preferred time. This ensures the call-back happens during the time period that the user (102) prefers. Accordingly, in case of system restart or process failover, the call-back data is not lost (i.e., there is call-back data retention). The call-back data can be retrieved from the database (210) in case of system restart or process failover. This ensures continuity and consistency of the call-back operations even if the any interruptions or failures occur.

[0128] In an implementation, the TAS unit (330) may continuously execute a system cyclic timer to scan each queue as per the current time. For instance, the system cyclic timer may be triggered after each 15 minutes. According to an implementation, if the current time is 10:55 AM, the system cyclic timer will be triggered at 11:00 AM and then at 11: 15 AM if the configured time slot is 15 minutes. For instance, the TAS unit (330) may scan the first queue that is scheduled for 11:00 AM to 11:15 AM time period and pick out all the calls scheduled between 11:00 AM to 11:15 AM time period. The TAS unit (330) may then scan the second queue that is scheduled for 11:15 AM to 11:30 AM time period and pick out all the calls scheduled between 11:15 AM to 11:30 AM time period. In an implementation, the TAS unit (330) will start picking out or popping out calls one by one from each queue and will try to patch the call to the respective users.

[0129] According to an implementation, the TAS unit (330) may obtain or pick out the call-back request from the second queue and patch a call for the user (102) with an agent as per the preferred time of the user (102). Accordingly, multiple system cyclic timers are not required to be executed (i.e., it is not required to run a system cyclic timer for each user (102)). In an implementation, there may be somefailed calls. According to an implementation, the TAS unit (330) may execute a retry cyclic timer to scan a list of failed calls and re-attempt the failed calls for a configured number of times before marking the calls as failed. Execution of the retry cyclic time provides a maximum call completion rate.

[0130] In an aspect, the TAS unit (330) executes the call-back based on the preferred time provided in the call-back request. If the call-back fails due to network issues, system errors, or other transient problems, the retry cyclic timer initiates a retry process. The TAS unit (330) schedules retry attempts using the retry cyclic timer. The retry cyclic timer triggers at regular intervals to reattempt the call -back execution. The call-back request is scheduled for 3:00 PM. At that time, the TAS unit (330) attempts to make the call but encounters an error (e.g., the line is busy, or the call fails due to a network issue). The TAS unit (330) sets a retry cyclic timer to attempt the call-back again in 5 minutes. If the retry also fails, the TAS unit (330) schedules additional retries at 5-minute intervals. The system (108) may be configured with a retry limit, such as a maximum of 10 retries.

[0131] Although FIG. 3B shows exemplary components of the system architecture (300B), in other embodiments, the system architecture (300B) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 3B. Additionally, or alternatively, one or more components of the system architecture (300B) may perform functions described as being performed by one or more other components of the system architecture (300B).

[0132] FIG. 4 illustrates an exemplary flow diagram (400) describing “request-a- call-back” service, in accordance with an embodiment of the present disclosure.

[0133] In an implementation, the entities that carry out the flow diagram (400) include the CAPIF (350), the TAS unit (330), the MRF (316), the customer care (402), an interconnection border control function (IBCF) (404), the customer (102),and the CHF (354). In an example, the customer (102) may be a user of the user equipment (104).

[0134] At step (408) of the flow diagram (400), the CAPIF (350) sends “Request A Callback application programming interface (API) hypertext transfer protocol (HTTP)” to the TAS unit (330). The “Request A Callback API (HTTP)” allows applications to request the call-back or to schedule the call-back operation over HTTP.

[0135] At step (410) of the flow diagram (400), the TAS unit (330) sends “200 OK (HTTP)” to the CAPIF (350). Upon receiving the “Request A Callback API (HTTP)” from the CAPIF (350), the TAS unit (330) sends the “200 OK (HTTP)” to the CAPIF (350) to confirm reception of the “Request A Callback API (HTTP)”.

[0136] Block (411) describes time -based trigger information. In an aspect, the time-based trigger information comprises call-back time preference (e.g., date (DD- MM-YYYY) and time (HH-MM-SS), etc.). The “200 OK (HTTP)” is an HTTP status code that indicates that the server has successfully processed the call-back request.

[0137] At step (412) of the flow diagram (400), the TAS unit (330) sends “INVITE (w / o SDP)” to the MRF (316). The INVITE request without (session description protocol) SDP is an initial INVITE message that does not include SDP information. The INVITE is used to initiate a communication session or invite participants to a session. The SDP includes multimedia communication sessions, including details like media types (audio, video), codecs, network information, and session attributes.

[0138] At step (414) of the flow diagram (400), the MRF (316) sends “200 OK (SDP-MRF)” to the TAS unit (330). The 200 OK (SDP-MRF) refers to an HTTP response indicating that a request involving SDP (Session Description Protocol) has been successfully processed by the server with the media resource functions (MRF). The response includes SDP information relevant to media handling.

[0139] A customer contact record (CCR) / a customer contact archive (CCA) (Service-Specific-Info AVP:<API key) is used to manage and store information about customer interactions between the TAS unit (330), the MRF (316), the customer care (402), the IBCF (404), the customer (102), the CHF (354). The CCR is a detailed log or record of a customer's interaction with a call center or customer service system. The CCR may include, but is not limited to, customer ID, name, contact information, call transcript, agent or representative information (e.g., agent name or ID), etc. The CCA is a long-term storage repository for historical customer contact records. The CCA retains past interactions for future reference, compliance, and auditing purposes. The CCA may include, but is not limited to, archived records (e.g., comprehensive collection of CCRs, search and retrieval of records, etc.

[0140] At step (416) of the flow diagram (400), the TAS unit (330) sends “INVITE (SDP-MRF)” to the customer care (402). The INVITE (SDP-MRF) is an INVITE request that includes Session Description Protocol (SDP) information specifically related to the Media Resource Function (MRF). The INVITE request with SDP will include information to configure media resources, such as setting up a conference call, connecting to a media server, or enabling media mixing.

[0141] At step (418) of the flow diagram (400), the customer care (402) sends “183 (SDP-A)” to the TAS unit (330). The “183 (SDP-A) indicates” Session Initiation Protocol (SIP) status code. The 183 (SDP-A) includes a SIP response with SDP information related to early media or session progress with various attributes or specifics related to the SDP.

[0142] At step (420) of the flow diagram (400), the TAS unit (330) sends “ACK (SDP-A)” to the MRF (316). The ACK (SDP-A) is an acknowledge of the receipt of the INVITE request. The ACK (SDP-A) may include updated or confirming SDP information.

[0143] At step (424) of the flow diagram (400), the TAS unit (330) sends “PRACK” to the customer care (402). In an aspect, the provisional responseacknowledgment (PRACK) refers to an acknowledgment of the receipt of provisional responses. The PRACK is used in the SIP to acknowledge provisional responses (e.g., 180 Ringing) that are part of the call setup process.

[0144] At step (426) of the flow diagram (400), the customer care (402) sends “200 OK (PRACK)” to the TAS unit (330). In response to receiving the PRACK from the TAS unit (330), the customer care (402) sends 200 OK to indicate the TAS unit (330) that the PRACK has been received successfully.

[0145] At step (428) of the flow diagram (400), the customer care (402) sends “180 Ringing” to the TAS unit (330). In an aspect, the “180 Ringing” is a provisional response sent by the session initiation protocol (SIP) server to indicate that the recipient’s phone is ringing, or the call is being processed but hasn't been answered yet. The “180 ringing” is used to inform the caller that the call setup process is underway.

[0146] Block (429) describes that the agent is ringing. The “Agent is Ringing” at the customer care (402). In an aspect, the “Agent is ringing” typically refers to a situation where the call center's system is in the process of notifying or connecting the agent (e.g., customer service representative) to an incoming call. Further, “Agent is ringing” signifies that the agent is being alerted to an incoming call or contact request. This phase occurs after a call is routed to an agent before the agent answers the call.

[0147] At step (430) of the flow diagram (400), the customer care (402) sends “200 OK (INVITE) (SDP-A1)” to the TAS unit (330). In an aspect, “200 OK (INVITE) (SDP-A1)” response indicates that the INVITE request was successfully processed, and the SDP-A1 part of the response contains the media parameters for the session as agreed upon by both parties (i.e., caller and recipient).

[0148] At step (432) of the flow diagram (400), the TAS unit (330) sends “UPDATE (SDP-A1)” to the MRF (316). In an aspect, the UPDATE (SDP-A1) refers to a SIP UPDATE request that contains an SDP body (SDP-A1) with new ormodified media parameters. The UPDATE (SDP-A1) is used to adjust the ongoing SIP session without initiating a new call setup. The SDP-A1 denotes the SDP content included in the UPDATE request. The SDP includes the new media parameters or changes from the original session setup.

[0149] At step (434) of the flow diagram (400), the MRF (316) sends “200 OK” to the TAS unit (330). On receiving the UPDATE (SDP-A1) from the TAS unit (330), the MRF (316) sends “200 OK” to the TAS unit (330). The 200 OK is used to indicate that the requested updates have been accepted and processed.

[0150] At step (436) of the flow diagram (400), the TAS unit (330) sends “ACK” to the customer care (402). After receiving “200 OK”, the TAS unit (330) sends an acknowledgment (e.g., ACK) to the customer care (402).

[0151] Block (437) describes a media session between the agent and the MRF (316). The media session involves interactions in which the MRF is responsible for managing media streams related to the call. The interaction between the call center agent and the MRF includes handling media streams, such as playing announcements, recording calls, or providing interactive voice response (IVR) services etc.

[0152] At step (438) of the flow diagram (400), the TAS unit (330) sends “INFO (Waiting for Customer to pick” to the MRF (316). In an aspect, the INFO is a message to provide status updates or additional context about the call. The “Waiting for Customer to Pick" is used to indicate a call state that involves waiting for the recipient (e.g., customer) to answer or pick up the call.

[0153] At step (440) of the flow diagram (400), the MRF (316) sends “200 OK” to the TAS unit (330). In an aspect, on receiving “INFO (Waiting for Customer to pick) from the TAS unit (330), the MRF (316) sends “200 OK” to acknowledge that the INFO request was successfully received and processed.

[0154] At step (442) of the flow diagram (400), the TAS unit (330) sends “INVITE (SDP-A)” to the IBCF (404). In an aspect, the TAS unit (330) sends the INVITE (SDP-A) to the IBCF (404) to initiate a session.

[0155] Block (443) describes connection with the customer (102). In an aspect, connecting with customer includes establishing a communication link between the customer and the customer care agent or representative.

[0156] At step (444) of the flow diagram (400), the IBCF (404) sends “INVITE (SDP A)” to the customer (102). In an aspect, IBCF (404) sends an INVITE request with an SDP payload (denoted as SDP-A) to the customer or end-user (102). The IBCF initiates a SIP session or call on behalf of the network or a service provider. The IBCF acts as an intermediary between different networks or service providers and manages and secures SIP traffic.

[0157] At step (446) of the flow diagram (400), the customer (102) sends “183 (SDP B)” to the IBCF (404). In an aspect, the “183 (SDP B)” indicates the session progress response (i.e., indicating that it has received the INVITE request and is processing the call) to the IBCF. The “183 response” may include an SDP payload (SDP-B) to describe the media parameters for early media (e.g., such as a ring back tone).

[0158] At step (448) of the flow diagram (400), the IBCF (404) sends “183 (SDP B)” to the TAS unit (330). In an aspect, the IBCF (404) transmits the received 183 (SDP B) to the TAS unit (330).

[0159] At step (450) of the flow diagram (400), the TAS unit (330) sends “PRACK” to the IBCF (404). On receiving “183 (SDP B) from the IBCF (404), the TAS unit (330) sends “PRACK” to the IBCF (404). The PRACK is used to acknowledge receipt of a provisional response (e.g., 183 Session Progress (183(SDP B)).

[0160] At step (452) of the flow diagram (400), the IBCF (404) sends “PRACK” to the customer (102). The IBCF (404) sends the received PRACK to the customer (102).

[0161] At step (454) of the flow diagram (400), the customer (102) sends “200 OK (PRACK)” to the IBCF (404). On receiving the PRACK from the IBCF (404), the customer sends “200 OK (PRACK)” to the IBCF (404). The “200 OK (PRACK)” confirms receipt and processing of the PRACK.

[0162] At step (456) of the flow diagram (400), the IBCF (404) sends “200 OK (PRACK)” to the TAS unit (330). The IBCF sends the received “200 OK (PRACK) received from the customer (102) to the TAS unit (330).

[0163] At step (458) of the flow diagram (400), the customer (102) sends “180 Ringing” to the IBCF (404).

[0164] At step (460) of the flow diagram (400), the IBCF (404) sends “180 Ringing” to the TAS unit (330).

[0165] Block (461) describes the customer (102) picking up the call. When the customer (102) picks up the call, a connection is established between the customer (102) and the customer care agent.

[0166] At step (462) of the flow diagram (400), the customer (102) sends “200 OK” to the IBCF (404). When the customer picks up the call, the customer (102) sends “200 OK” to the IBCF (404) to indicate that the call setup has been completed and the connection is established.

[0167] At step (464) of the flow diagram (400), the IBCF (404) sends “200 OK” to the TAS unit (330). On receiving “200 OK” from the customer (102), the IBCF (404) sends the “200 OK” to the TAS unit (330).

[0168] At step (466) of the flow diagram (400), the TAS unit (330) sends “ACK” to the IBCF (404). Upon receiving the '200 OK' response from the IBCF (404), theTAS unit (330) sends an acknowledgment (ACK) of the '200 OK' reception to the IBCF (404).

[0169] At step (467) of the flow diagram (400), the IBCF (404) sends “ACK” to the customer (102). The IBCF (404) forwards the received “ACK” to the customer (102).

[0170] At step (468) of the flow diagram (400), the TAS unit (330) sends “UPDATE (SDP-B)” to the customer care (402). In an aspect, the TAS unit (330) sends “UPDATE (SDP-B)” including SDP information as part of the session where parameters or media descriptions are updated without modifying the overall session state.

[0171] At step (470) of the flow diagram (400), the customer care (402) sends “200 OK” to the TAS unit (330). On receiving the UPDATE (SDP-B), the customer care (402) sends “200 OK” to the TAS unit (330).

[0172] At step (472) of the flow diagram (400), the TAS unit (330) sends a “Call connected” to the CAPIF (350). In an aspect, the TAS unit (330) sends the “Call connected” to the CAPIF (350) to inform that the call has been successfully established between the customer care agent and the customer.

[0173] At step (474) of the flow diagram (400), the CAPIF (350) sends “200 OK (HTTP)” to the TAS unit (330). Upon receiving the “Call connected” from the TAS unit (330), the CAPIF (350) sends “200 OK (HTTP)” to the TAS unit (330).

[0174] At step (476) of the flow diagram (400), the TAS unit (330) sends “BYE” to the MRF (316). In an aspect, the “BYE” request is used to terminate the ongoing call or the session. The TAS unit (330) sends the “BYE” to the MRF (316) to terminate the media resources or media streams associated with that session.

[0175] At step (478) of the flow diagram (400), the MRF (316) sends “200 OK” to the TAS unit (330). Upon receiving the “BYE” from the TAS unit (330), the MRF (316) sends “200 OK” to the TAS unit (330).

[0176] Block (479) describes that real-time transmission protocol (RTP) is established between the customer (102) and agents of customer care (402). The RTP is established between the customer (102) and agents of the customer care (402) to set up and manage the media streams for real-time communication.

[0177] At step (480) of the flow diagram (400), the customer (102) sends “BYE” to the IBCF (404). In an aspect, the customer (102) sends the “BYE” to the IBCF to terminate the ongoing call.

[0178] At step (482) of the flow diagram (400), the IBCF (404) sends “BYE” to the TAS unit (330). Upon receiving the “BYE” from the customer (102), the IBCF (404) sends “BYE” to the TAS unit (330).

[0179] At step (484) of the flow diagram (400), the IBCF (404) sends “200 OK (BYE)” to the customer (102). In an aspect, the IBCF (404) sends “200 OK (BYE)” to the customer (102) to confirm the termination of the ongoing call.

[0180] At step (486) of the flow diagram (400), the TAS unit (330) sends “200 OK (BYE)” to the IBCF (404). Upon receiving the “BYE” from the IBCF (404), the TAS unit (330) sends “200 OK (BYE)” to the IBCF (404).

[0181] At step (488) of the flow diagram (400), the TAS unit (330) sends “BYE” to the customer care (402). In an aspect, the TAS unit (330) sends “BYE” to the customer care (402) to terminate the call.

[0182] At step (490) of the flow diagram (400), the customer care (402) sends “200 OK (BYE)” to the TAS unit (330). Upon receiving the “BYE” from the TAS unit (330), the customer sends “200 OK (BYE)” to the customer care (402) to acknowledge the reception of the “200 OK”.

[0183] At step (492) of the flow diagram (400), the TAS unit (330) sends “Call ended” to the CAPIF (350). Upon receiving “200 OK (BYE)” from the customer care (402), the TAS unit (330) sends the “Call ended” to the CAPIF (350).

[0184] At step (494) of the flow diagram (400), the CAPIF (350) sends “200 OK (HTTP)” to the TAS unit (330). Upon receiving the “Call ended” from the TAS unit (330), the CAPIF (350) sends “200 OK (HTTP)” to the TAS unit (330) to confirm the call termination.

[0185] FIG. 5 illustrates an exemplary flow diagram of a method (500) for processing a call-back request, in accordance with an embodiment of the present disclosure.

[0186] At step (502), the method (500) includes maintaining, by the execution unit (214), a queue for each time slot of a plurality of time slots. In an example, each time slot is configurable according to one or more service provider requirements. The service provider requirements include, but are not limited to, specific rules established by the service provider regarding when calls can be made and the optimal times for reaching customers, regulatory restrictions on call times (e.g., no calls after certain hours), and policies that dictate the best times for customer outreach based on historical data or customer preferences.

[0187] At step (504), the method (500) includes receiving, by the execution unit (214), the call -back request from a user (102). The call-back request comprises callback data indicative of a preferred time for a call-back. The execution unit (214) is configured to check-point the call-back data to a mate process. The mate process is used to ensure that the call-back is performed within the preferred time provided by the user.

[0188] At step (506), the method (500) includes storing, by the execution unit (214), the call-back request in the queue maintained for a corresponding time slot that matches the preferred time. The execution unit (214) may store the call-back request in the database (210). For example, if the customer's preferred time for a callback isbetween 2 PM and 3 PM, the callback request is stored in the queue for that time period (i.e., 2 PM to 3 PM).

[0189] At step (508), the method (500) includes executing, by the execution unit (214), a system cyclic timer to scan each queue according to time slots. In an aspect, the system cyclic timer periodically checks the queue of callback requests based on the predefined time intervals. For example, the system cyclic timer scans each queue after every 5 minutes.

[0190] At step (510), the method (500) includes retrieving, by the determination unit (216), the call-back request from the corresponding queue based on the time slot. For example, the queue has multiple time slots, including 1 PM to 2 PM, 2 PM to 3 PM, and 3 PM to 4 PM. If the current time is 2:30 PM, then the callback requests corresponding to the time slot (i.e., 2 PM to 3 PM) are retrieved. At step (512), the method (500) includes executing, by the determination unit (216), a call for the user with an agent responsive to the call-back request at the preferred time of the user. For example, if the customer's preferred time for a callback is between 10 AM and 11 AM, the agent responsible for the callback request may perform the callback within that the time period (i.e., 10 AM and 11 AM).

[0191] At step (514), the method (500) includes, processing, by the determination unit (216), the call to determine whether the call was successfully executed. In an aspect, the call is processed to determine the status of the call (i.e., call successful or call unsuccessful). The call is processed to track performance metrics (e.g., connection rates and customer engagement), identify issues or patterns in call failures to improve future calling strategies, and ensure follow-up actions, if necessary, can be taken promptly (e.g., scheduling another attempt or escalating the issue).

[0192] At step (516), the method (500) includes, in response to determining that the call was not successfully executed, executing, by the determination unit (216), a retry cyclic timer to re-attempt the call after a pre-determined time interval. Inexamples, in response to determining that the call was unsuccessful, the determination unit (216) is configured retrieve the call-back request from the database (210) and re-attempt the call after the pre-determined time interval. In examples, the call-back data is retrieved from the database (210) based at least on one of system restart and process failover. In an implementation, the determination unit (216) is configured to notify the user if a call-back attempt fails after a pre -configured number of retries. The determination unit (216) is configured to execute the retry cyclic timer to scan a list of failed calls and re-attempt the failed calls at a predetermined frequency. In an aspect, the determination unit (216) is configured to prioritize the failed calls based on user-defined criteria.

[0193] In an exemplary embodiment, the present invention discloses a user equipment (UE) (104) communicatively coupled with a network (106). The coupling comprises steps of receiving, by the network (106), a connection request from the UE (104), sending, by the network, an acknowledgment of the connection request to the UE (104) and transmitting a plurality of signals in response to the connection request. The network (106) is configured to perform a method (500) for processing a call-back request. The method (500) includes maintaining (502), by the execution unit (214), a queue for each time slot of a plurality of time slots. The method (500) includes receiving (504), by the execution unit (214), the call-back request from a user, where the call-back request comprises call-back data indicative of a preferred time for a call -back. The method (500) includes storing (506), by the execution unit (214), the call-back request in the queue maintained for a corresponding time slot that matches the preferred time. The method (500) includes executing (508), by the execution unit (214), a system cyclic timer to scan each queue according to time slots. The method (500) includes retrieving (510), by the determination unit (216), the call-back request from the corresponding queue based on the time slot. The method (500) includes executing (512), by the determination unit (216), a call for the user with an agent responsive to the call-back request at the preferred time of the user. The method (500) includes processing (514), by the determination unit (216), the call to determine whether the call was successfully executed. The method (500) includes, in responseto determining that the call was not successfully executed, executing (516), by the determination unit (216), a retry cyclic timer to re-attempt the call after a predetermined time interval.

[0194] FIG. 6 illustrates an exemplary computer system (600) in which or with which embodiments of the present disclosure may be implemented.

[0195] As shown in FIG. 6, the computer system may include an external storage device (610), a bus (620), a main memory (630), a read-only memory (640), a mass storage device (650), communication port(s) (660), and a processor (670). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The processor (670) may include various modules associated with embodiments of the present disclosure. The communication port(s) (660) may be any of an RS -232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) (660) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects.

[0196] The main memory (630) may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor (670). The mass storage device (650) may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage device (650) includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks.

[0197] The bus (620) communicatively couples the processor (670) with the other memory, storage, and communication blocks. The bus (620) may be, e.g., a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 670 to the computer system.

[0198] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (620) to support direct operator interaction with the computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.

[0199] The exemplary computer system (600) is configured to execute a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for processing a call-back request. The method includes maintaining, by an execution unit, a queue for each time slot of a plurality of time slots. The method includes receiving, by the execution unit, the callback request from a user, where the call-back request comprises call-back data indicative of a preferred time for a call-back. The method includes storing, by the execution unit, the call-back request in the queue maintained for a corresponding time slot that matches the preferred time. The method includes executing, by the execution unit, a system cyclic timer to scan each queue according to time slots. The method includes retrieving, by the determination unit, the call-back request from the corresponding queue based on the time slot. The method includes executing, by the determination unit, a call for the user with an agent responsive to the call-back request at the preferred time of the user. The method includes processing, by the determination unit, the call to determine whether the call was successfully executed.The method includes, in response to determining that the call was not successfully executed, executing, by the determination unit, a retry cyclic timer to re-attempt the call after a pre-determined time interval.

[0200] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

[0201] The present disclosure provides technical advancement related to request- call-back service. This advancement addresses the limitations of existing solutions by providing an efficient request-a-call-back architecture. The disclosure involves storing call-back requests received from users in the queue maintained per time slot. The call-back data is also stored in the database and check-pointed to the mate process. The system cyclic timer is executed continuously to scan each time slot as per the current time. The call-back request is retrieved from the queue and patch call of the user with the agent. The system cyclic timer assists in triggering the call-back to be executed at the preferred time specified in the call-back request. The retry cyclic timer is also run to scan the list of failed calls and re-attempt these calls for the configured number of times before marking the call as failed. This ensures continuity and consistency of the call-back operations even if any interruptions or failures occur.TECHNICAL ADVANTAGES OF THE PRESENT DISCLOSURE

[0202] As is evident from the above, the present disclosure provides a technically advanced solution by providing an efficient request-a-call-back architecture. According to aspects of the present disclosure, queues are maintained for each time slot as per service provider requirements such that call-back requests received from the users are stored in a queue maintained per time slot. The time slots areconfigurable. The call-back data is stored in the database. Accordingly, there is callback data retention. The data is not lost in case of system restart or process failover. Further, a system cyclic timer runs continuously to scan each time slot as per the current time, pops a request from the queue, and patches a call of a user with an agent as per the time slot required by the user without running multiple system timers. Additionally, a retry cyclic timer runs to scan a list of failed calls and re-attempt the failed calls for a configured number of times before marking the calls as failed. The retry mechanism provides a maximum call completion rate.

Claims

CLAIMSWe claim:

1. A system (108) for processing a call -back request, the system (108) comprising: an execution unit (214) configured to: maintain a queue for each time slot of a plurality of time slots; receive the call-back request from a user, wherein the call-back request comprises call-back data indicative of a preferred time for a call-back; store the call-back request in the queue maintained for a corresponding time slot that matches the preferred time; execute a system cyclic timer to scan each queue according to time slots; and a determination unit (216) coupled with the execution unit (214) configured to: retrieve the call-back request from the corresponding queue based on the time slot; execute a call for the user with an agent responsive to the call-back request at the preferred time of the user; process the call to determine whether the call was successfully executed; and in response to determining that the call was not successfully executed, execute a retry cyclic timer to re-attempt the call after a predetermined time interval.

2. The system (108) as claimed in claim 1, wherein the execution unit (214) is configured to store the call-back request in a database (210).

3. The system (108) as claimed in claim 2, wherein in response to determining that the call was unsuccessful, the determination unit (216) is configured toretrieve the call-back request from the database (210) and re-attempt the call after the pre-determined time interval.

4. The system (108) as claimed in claim 1, wherein the execution unit (214) is configured to check-point the call-back data to a mate process.

5. The system (108) as claimed in claim 1, wherein the determination unit (216) is configured to notify the user if a call-back attempt fails after a preconfigured number of retries.

6. The system (108) as claimed in claim 1, wherein the determination unit (216) is configured to execute the retry cyclic timer to scan a list of failed calls and re-attempt the failed calls at a pre-determined frequency.

7. The system (108) as claimed in claim 1, wherein each time slot is configurable according to one or more service provider requirements.

8. A method (500) for processing a call-back request, the method (500) comprising: maintaining (502), by an execution unit (214), a queue for each time slot of a plurality of time slots; receiving (504), by the execution unit (214), the call-back request from a user, wherein the call-back request comprises call-back data indicative of a preferred time for a call-back; storing (506), by the execution unit (214), the call-back request in the queue maintained for a corresponding time slot that matches the preferred time; executing (508), by the execution unit (214), a system cyclic timer to scan each queue according to time slots;retrieving (510), by a determination unit (216), the call -back request from the corresponding queue based on the time slot; executing (512), by the determination unit (216), a call for the user with an agent responsive to the call -back request at the preferred time of the user; processing (514), by the determination unit (216), the call to determine whether the call was successfully executed; and in response to determining that the call was not successfully executed, executing (516), by the determination unit (216), a retry cyclic timer to re-attempt the call after a pre-determined time interval.

9. The method (500) as claimed in claim 8 further comprising storing, by the execution unit (214), the call-back request in a database (210).

10. The method (500) as claimed in claim 9, wherein in response to determining that the call was unsuccessful, retrieving, by the determination unit (216), the call-back request from the database (210) and re-attempting, by the determination unit (216), the call after the pre-determined time interval.

11. The method (500) as claimed in claim 8 further comprising check-pointing, by the execution unit (214), the call-back data to a mate process.

12. The method (500) as claimed in claim 8 further comprising notifying, by the determination unit (216), the user if a call -back attempt fails after a preconfigured number of retries.

13. The method (500) as claimed in claim 8 further comprising executing, by the determination unit (216), the retry cyclic timer to scan a list of failed calls; and re-attempting, by the determination unit (216), the failed calls at a predetermined frequency.

14. The method (500) as claimed in claim 8, wherein each time slot is configurable according to one or more service provider requirements.

15. A user equipment (UE) (104) communicatively coupled with a network (106), the coupling comprises of: receiving, by the network (106), a connection request from UE (104); sending, by the network (106), an acknowledgment of the connection request to the UE (104); and transmitting a plurality of signals in response to the connection request, wherein the network (106) is configured for performing a method (500) for processing a call-back request as claimed in claim 8.

16. A computer program product comprising a non -transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method (500) for processing a call-back request, the method (500) comprising steps of: maintaining (502) a queue for each time slot of a plurality of time slots; receiving (504) the call-back request from a user, wherein the callback request comprises call-back data indicative of a preferred time for a callback; storing (506) the call-back request in the queue maintained for a corresponding time slot that matches the preferred time; executing (508) a system cyclic timer to scan each queue according to time slots; retrieving (510) the call-back request from the corresponding queue based on the time slot; executing (512) a call for the user with an agent responsive to the callback request at the preferred time of the user;processing (514) the call to determine whether the call was successfully executed; and in response to determining that the call was not successfully executed, executing (516) a retry cyclic timer to re-attempt the call after a predetermined time interval.

Images