FORM 2
THE PATENTS ACT, 1970 (39 OF 1970) & THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR AUTOMATING A RESOLUTION OF A
TROUBLE TICKET”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

METHOD AND SYSTEM FOR AUTOMATING A RESOLUTION OF A
TROUBLE TICKET
FIELD OF THE DISCLOSURE
[0001] Embodiments of the present disclosure generally relate to the field of customer relationship management/ customer engagement management in a network. More particularly, embodiments of the present disclosure relate to automating a resolution of a trouble ticket.
BACKGROUND
[0002] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0003] Wireless communication technology has rapidly evolved over the past few decades, with each generation bringing significant improvements and advancements. The first generation of wireless communication technology was based on analog technology and offered only voice services. However, with the advent of the second-generation (2G) technology, digital communication and data services became possible, and text messaging was introduced. The third-generation (3G) technology marked the introduction of high¬speed internet access, mobile video calling, and location-based services. The fourth-generation (4G) technology revolutionized wireless communication with faster data speeds, better network coverage, and improved security. Currently, the fifth-generation (5G) technology is being deployed, promising even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users.

[0004] In the current scenario it is a challenge meeting customer expectation for quick problem resolution and maintaining strong customer loyalty. In today's competitive business landscape, responsiveness to customer needs is crucial for sustaining a thriving business and building lasting relationships. Customers have come to rely on customer relationship systems for swift issue resolution, expecting a quick turnaround. However, the existing challenge lies in the customer relationship systems’ limited capacity to simultaneously address the queries and problems of all customers. Even when these systems strive to address all concerns promptly, it can still take time to accurately identify and understand the specific problems faced by customers. Consequently, extended waiting times can lead customers to feel neglected and perceive themselves as lacking priority. Therefore, the problem statement revolves around finding innovative solutions to enhance the ability of customer relationship systems to efficiently and effectively resolve customer issues, ensuring they consistently receive prompt and satisfactory support.
[0005] Trouble ticketing provides an avenue for fielding customer concerns quickly and in methodical fashion. And while the customer relationship systems may not be able to solve the problem right away, these systems can still communicate with the customers to keep them informed about how close these systems are to a resolution. This eliminates the uncertainty and wondering. Hence, trouble ticket represents a record, or an issue raised by requestor that needs to be solved, used for reporting and managing the resolution of problems, incidents or request.
[0006] Problems that need to be addressed by technical or business teams are assigned to the corresponding team by raising a trouble ticket. The basis for these non-technical complaints is related to a customer’s dissatisfaction with a product, over-charging, response and resolution times for installation, request or complaint handling, behavioral issues, and more that may require a Trouble Ticket to be generated.
[0007] Further, over the period of time various solutions have been developed to improve the performance of communication devices and of microservices based trouble ticket processing. Microservice refers to the services such as but not limited to small independent services pertaining to handling specific functions like account management, billing, customer support, and service provisioning. The microservices often communicate via

Application Programming Interfaces (APIs). However, there are certain challenges with existing solutions. Firstly, existing systems often lack the capability to handle a large volume of customer queries simultaneously, resulting in delays and extended waiting times for issue resolution. This limitation arises from the inability to effectively prioritize and allocate resources based on the urgency and complexity of each problem. Secondly, prior art systems may struggle with accurately identifying and understanding the specific problems faced by customers, leading to inefficient troubleshooting processes and potential misdiagnosis. This can further escalate customer frustration and dissatisfaction. Additionally, the prior art may lack sophisticated mechanisms for tracking and monitoring customer issues, making it challenging to provide real-time updates and progress reports to customers. These limitations collectively hinder the ability to meet customer expectations for quick problem resolution and build strong customer loyalty.
[0008] Hence, in view of these and other existing limitations, there arises an imperative need to overcome the above-mentioned limitations and to provide a method and system to automate resolution(s) of trouble ticket(s).
OBJECTS OF THE DISCLOSURE
[0009] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.
[0010] It is an object of the present disclosure to provide a system and a method for microservices based trouble ticket processing, where the entire call flow between the microservices is asynchronous.
[0011] It is an object of the present disclosure to provide an event streaming platform as a messaging system which provides bidirectional communication and helps to avoid latency in resolving trouble tickets.
[0012] It is another object of the present disclosure to provide a solution that assigns a target workflow from the set of pre-stored workflows based on at least one of the event and the one or more parameters.

[0013] It is yet another object of the present disclosure to provide a solution to assign a target technician from the set of technicians to the trouble ticket.
SUMMARY
[0014] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0015] The aspect of the present disclosure may relate to a method for automating a resolution of a trouble ticket. The method comprises receiving, by a data ingestion module, the trouble ticket comprising a set of ticket parameters. The method further comprises assigning, by a processing unit via a workflow manager, a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters. The method further comprises assigning, by the processing unit via a trouble ticket assignment engine, a target assignment group to the trouble ticket based on a set of predefined routing rules. The method further comprises assigning, by the processing unit via the trouble ticket assignment engine, a technician to the trouble ticket from the target assignment group. The method further comprises assigning, by the processing unit via a service-level agreement (SLA) manager, a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters. And the method further comprises transmitting, by the transceiver unit via a Notification Engine, a set of notifications to the user associated with the trouble ticket.
[0016] In an exemplary aspect of the present disclosure, the method further comprises detecting, by the processing unit, a trouble ticket progress associated with the trouble ticket from the technician based on a predefined trouble ticket progress condition. The method further comprises automating, by the processing unit, the resolution of the trouble ticket based on detecting the trouble ticket progress associated with the trouble ticket from the technician and the predefined trouble ticket progress condition.

[0017] In an exemplary aspect of the present disclosure, the method further comprises detecting via the data ingestion module the trouble ticket as one of a valid trouble ticket and an invalid trouble ticket, wherein the valid trouble ticket is detected based on the set of ticket parameters.
[0018] In an exemplary aspect of the present disclosure, the method further comprises detecting the valid trouble ticket further comprises storing the valid trouble ticket in a database (DB) of a storage unit.
[0019] In an exemplary aspect of the present disclosure, the method further comprises, detecting the trouble ticket progress associated with the trouble ticket from the technician, by the processing unit, further comprises transmitting a progress notification associated with the trouble ticket progress to the target assignment group, wherein the progress notification is based on at least the one or more predefined SLA conditions.
[0020] In an exemplary aspect of the present disclosure, the set of ticket parameters facilitates identifying one or more problems, determining the priority level of the trouble ticket, and identifying impact of the one or more problems on an entity.
[0021] Another aspect of the present disclosure may relate to a system for automating a resolution of a trouble ticket. The system comprises a data ingestion module configured to receive, the trouble ticket comprising a set of ticket parameters. The system further comprises a processing unit configured to assign, via a workflow manager, a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters. The processing unit is further configured to assign, via a trouble ticket assignment engine, a target assignment group to the trouble ticket based on a set of predefined routing rules. The processing unit is further configured to assign, via the trouble ticket assignment engine, a technician to the trouble ticket from the target assignment group. The processing unit is further configured to assign, via a service-level agreement (SLA) manager, a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters. Also, the transceiver unit of the system is further configured to transmit, via a Notification Engine, a set of notifications to the technician associated with the trouble ticket.

[0022] Another aspect of the present disclosure may relate to a non-transitory computer readable storage medium, storing instructions for automating a resolution of a trouble ticket, the instructions include executable code which, when executed by a one or more units of a system, causes: a data ingestion module to receive, the trouble ticket comprising a set of ticket parameters. Further, the instructions include executable code, which when executed causes a processing unit to: assign, via a workflow manager, a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters; assign, via a trouble ticket assignment engine, a target assignment group to the trouble ticket based on a set of predefined routing rules; assign, via the trouble ticket assignment engine, a technician to the trouble ticket from the target assignment group; assign, via a service-level agreement (SLA) manager, a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters. Further, the instructions include executable code, which when executed causes the transceiver unit to transmit, via a Notification Engine, a set of notifications to the technician associated with the trouble ticket.
[0023] Yet another aspect of the present disclosure may relate to a user equipment (UE). The UE comprises a processor configured to send a trouble ticket comprising a set of ticket parameters. The processor is further configured to receive a notification associated with a resolution of the trouble ticket, wherein the trouble ticket is assigned to a target workflow, a target assignment group, a technician, and a target service level agreement (SLA) for the resolution of the trouble ticket.
DESCRIPTION OF DRAWINGS
[0024] 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.
[0025] FIG. 1 illustrates an exemplary block diagram of a computing device [100] upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.
[0026] FIG. 2 illustrates an exemplary block diagram of a system [200] for automating a resolution of a trouble ticket, in accordance with exemplary implementations of the present disclosure.
[0027] FIG. 3 illustrates an exemplary method [300] flow diagram for automating a resolution of a trouble ticket, in accordance with the exemplary embodiments of the present disclosure.
[0028] FIG. 4 illustrates an exemplary scenario method [400], for trouble ticket call flow which depicts the manner in which the present disclosure is performed, in accordance with the exemplary embodiments of the present disclosure.
[0029] FIG. 5 illustrates an exemplary Service Management Platform (SMP) architecture [500], in accordance with the exemplary embodiments of the present disclosure.
[0030] The foregoing shall be more apparent from the following more detailed description of the disclosure.
DETAILED DESCRIPTION
[0031] 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.
[0032] 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.
[0033] 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 disclosure. These terms are not intended to limit the scope of the disclosure or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The disclosure is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the disclosure as defined herein.
[0034] 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.
[0035] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the 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.
[0036] 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 in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.
[0037] 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.
[0038] Further, the user device and/or a system as described herein to implement technical features as disclosed in the present disclosure may also comprise a “processor” or “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 Digital Signal Processor (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.
[0039] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smart-device”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a mobile communication device”, “a communication device” may be any electrical, electronic and/or computing device or equipment, capable of implementing the features of the present disclosure. The user equipment/device may include, but is not limited to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any other computing device which is capable of implementing the features of the present disclosure. Also, the user device may contain at least one input means configured to receive an input from at least one of a transceiver unit, a processing unit, a storage unit, a detection unit and any other such unit(s) which are required to implement the features of the present disclosure.
[0040] As used herein, “storage unit” or “memory unit” refers to a machine or computer-readable medium including any mechanism for storing information in a form readable by a computer or similar machine. For example, a computer-readable medium includes read¬only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices or other types of machine-accessible storage media. The storage unit stores at least the data that may be required by one or more units of the system to perform their respective functions.
[0041] As used herein “interface” or “user interface” refers to a shared boundary across which two or more separate components of a system exchange information or data. The interface may also be referred to a set of rules or protocols that define communication or

interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.
[0042] All modules, units, components used herein, unless explicitly excluded herein, may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc.
[0043] As used herein the transceiver unit includes at least one receiver and at least one transmitter configured respectively for receiving and transmitting data, signals, information or a combination thereof between units/components within the system and/or connected with the system.
[0044] As discussed in the background section, the current known solutions for microservices based trouble ticket processing have several shortcomings such as they hinder their ability to meet customer expectations and provide efficient support. One major drawback is the lack of scalability, as these systems often struggle to handle a large influx of customer queries simultaneously. This leads to longer response times and delays in issue resolution, causing customer frustration and a negative impact on customer satisfaction. Moreover, present systems may lack advanced mechanisms for accurately identifying and understanding the specific problems faced by customers, resulting in inefficient troubleshooting processes and potential misdiagnosis. Furthermore, there is often a dearth of real-time tracking and monitoring capabilities, making it challenging to provide timely updates to customers regarding the progress of their issues.
[0045] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing method and system of automating a resolution of a trouble ticket. The present disclosure discloses a microservices based trouble ticket processing to overcome the problems associated with the conventional technology.

[0046] The present disclosure can be implemented on a computing device [100] as shown in FIG. 1. The FIG. 1 illustrates an exemplary block diagram of the computing device [100] upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure. In an implementation, the computing device [100] may also implement a method for automating a resolution of a trouble ticket utilising the system [200]. In another implementation, the computing device [100] itself implements the method for automating a resolution of a trouble ticket using one or more units configured within the computing device [100], wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
[0047] The computing device [100] may include a bus [102] or other communication mechanism for communicating information, and a hardware processor [104] coupled with bus [102] for processing information. The hardware processor [104] may be, for example, a general-purpose microprocessor. The computing device [100] may also include a main memory [106], such as a random-access memory (RAM), or other dynamic storage device, coupled to the bus [102] for storing information and instructions to be executed by the processor [104]. The main memory [106] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the processor [104]. Such instructions, when stored in non-transitory storage media accessible to the processor [104], render the computing device [100] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device [100] further includes a read only memory (ROM) [108] or other static storage device coupled to the bus [102] for storing static information and instructions for the processor [104].
[0048] A storage device [110], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [102] for storing information and instructions. The computing device [100] may be coupled via the bus [102] to a display [112], such as a cathode ray tube (CRT), Liquid crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying information to a computer user. An input device [114], including alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus [102] for communicating information and command selections to the processor [104]. Another type of user input device may be a cursor

controller [116], such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor [104], and for controlling cursor movement on the display [112]. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.
[0049] The computing device [100] may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computing device [100] causes or programs the computing device [100] to be a special-purpose machine. According to one implementation, the techniques herein are performed by the computing device [100] in response to the processor [104] executing one or more sequences of one or more instructions contained in the main memory [106]. Such instructions may be read into the main memory [106] from another storage medium, such as the storage device [110]. Execution of the sequences of instructions contained in the main memory [106] causes the processor [104] to perform the process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.
[0050] The computing device [100] also may include a communication interface [118] coupled to the bus [102]. The communication interface [118] provides a two-way data communication coupling to a network link [120] that is connected to a local network [122]. For example, the communication interface [118] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface [118] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [118] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
[0051] The computing device [100] can send messages and receive data, including program code, through the network(s), the network link [120] and the communication interface [118]. In the Internet example, a server [130] might transmit a requested code for

an application program through the Internet [128], the ISP [126], the host [124], the local network [122] and the communication interface [118]. The received code may be executed by the processor [104] as it is received, and/or stored in the storage device [110], or other non-volatile storage for later execution.
[0052] The present disclosure is implemented by a system [200] as shown in FIG. 2. The computing device [100] may reside in/ be connected to the system [200] to perform the present disclosure. Referring to FIG. 2, an exemplary block diagram of the system [200] for automating a resolution of a trouble ticket, is shown, in accordance with the exemplary implementations of the present disclosure. The system [200] comprises at least one transceiver unit [201], at least one data ingestion module [202], at least one processing unit [203], at least one workflow manager [204], at least one trouble ticket assignment engine [205], at least one service level agreement (SLA) manager [206], at least one notification engine [207] and at least one storage unit [208] comprising a database (DB) [208db]. Also, all of the components/ units of the system [200] are assumed to be connected to each other unless otherwise indicated below. As shown in the FIG.2, all units shown within the system should also be assumed to be connected to each other. Also, in FIG. 2 only a few units are shown, however, the system [200] may comprise multiple such units or the system [200] may comprise any such number of said units, as required to implement the features of the present disclosure. Further, in an implementation, the system [200] may be present in a user device to implement the features of the present disclosure. The system [200] may be in communication with the user equipment [220]. In another implementation, the system [200] may reside in a server or a network entity.
[0053] The system [200] is configured for automating a resolution of trouble ticket, with the help of the interconnection between the components/units of the system [200].
[0054] Trouble ticket systems are built to capture information directly from a service request, regardless of how the request is sent, helping eliminate human error. To achieve all these functionalities, the system [200] provides a framework for collecting the most relevant information from the ticket to help in identifying customer issues. The system [200] uses the information to classify tickets by priority and the likely impact of the problem on the organization. The system [200] also provides an automated as well as

manual assignment of trouble ticket to appropriate technicians based upon the business rules.
[0055] The data ingestion module [202], receives the trouble ticket comprising a set of ticket parameters. It is to be noted that the set of ticket parameters facilitates identification of one or more problems faced by one or more users, a determination of the priority level of the trouble ticket, and an identification of the impact of the one or more problems on an entity. Further, the data ingestion module [202] may receive the trouble ticket from multiple sources such as but not limited to user (UI), app, CRM, JCP, IPM, NMS.
[0056] The processing unit [203] is configured to assign, via a workflow manager [204], a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters. The processing unit [203] is further configured to assign, via a trouble ticket assignment engine [205], a target assignment group to the trouble ticket based on a set of predefined routing rules. The processing unit [203] is further configured to assign, via the trouble ticket assignment engine [205], a technician to the trouble ticket from the target assignment group. The processing unit [203] is further configured to assign, via a service-level agreement (SLA) manager [206], a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters. Furthermore, the one or more predefined SLA conditions may include pre¬defined as well as dynamic conditions. For instance, the users can define the SLA condition as “Resolve High Priority Tickets in 30 Minutes”. Since, the Service Management Platform (SMP) [500] (as shown in FIG. 5) attaches the SLA(s) on basis of the parameters of the trouble ticket, the SMP [500] assigns, as per the above-mentioned SLA condition, to the trouble ticket a “High” priority and thus the technician will receive notification for the same. SLAs get attached to the trouble ticket based upon trouble ticket parameters, where SLAs are agreements over the quality of service and the reasonable amount of time it will take to resolve a problem. When an SLA breach deadline approaches, the system [200] sends alerts to relevant personnel (technician, Manager etc.) ensuring the trouble ticket is resolved in time.
[0057] In an exemplary aspect of the present disclosure, the processing unit [303] is further configured to detect, a trouble ticket progress associated with the trouble ticket from the

technician based on a predefined trouble ticket progress condition. The processing unit [303] is further configured to automate the resolution of the trouble ticket based on detecting the trouble ticket progress associated with the trouble ticket from the technician and the predefined trouble ticket progress conditions. It is to be noted that, for detecting the trouble ticket progress associated with the trouble ticket from the technician, the processing unit [303] is further configured to transmit a progress notification associated with the trouble ticket progress to the target assignment group, wherein the progress notification is based on at least the one or more predefined SLA conditions. For instance, the progress notification may include notification hub service for Email / SMS. This progress notification may provide alerts such as:
- Email alert to assignee on trouble ticket assignment.
- SMS alert to assignee on trouble ticket assignment.
- Email alert on assignee & team lead on SLA violation.
- Email alert to level-2 OC on SLA violation i.e. escalation group level 2 which means that if level-1 group fails to resolve the ticket then it automatically gets assigned to level 2 group or ‘Level 2 Operation Context (OC)’.
[0058] The progress notification may also include notification on creation of event, notification about ticket parameters value change event, status change event notification, ticket delete event notification, and resolved event notification.
[0059] In an exemplary aspect of the present disclosure, the processing unit [203] is further configured to detect via the data ingestion module [202] the trouble ticket as one of a valid trouble ticket and an invalid trouble ticket, wherein the valid trouble ticket is detected based on the set of ticket parameters. It is further noted that the valid trouble ticket detected is further stored in a database (DB) [208db] of a storage unit [208].
[0060] The transceiver unit [201] of the system [200] is further configured to transmit, via a Notification Engine [207], a set of notifications to the technician associated with the trouble ticket.
[0061] Referring to FIG. 3, an exemplary method flow diagram [300] for automating a resolution of a trouble ticket, in accordance with exemplary implementations of the present

disclosure is shown. In an implementation the method [300] is performed by the system [200]. Further, in an implementation, the system [300] may be present in a server/ network entity to implement the features of the present disclosure. Also, as shown in FIG. 3, the method [300] starts at step [302].
[0062] At step [304], the method [300] comprises receiving, by a transceiver unit [201] via a data ingestion module [202], the trouble ticket comprising a set of ticket parameters. In an exemplary aspect of the present disclosure, in the disclosed method [300], the set of ticket parameters facilitates identifying one or more problems, determining the priority level of the trouble ticket, and identifying impact of the one or more problems on an entity.
[0063] At step [306], the method [300] comprises assigning, by a processing unit [203] via a workflow manager [204], a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters.
[0064] At step [308], the method [300] comprises assigning, by the processing unit [203] via a trouble ticket assignment engine [205], a target assignment group to the trouble ticket based on a set of predefined routing rules.
[0065] At step [310], the method [300] comprises assigning, by the processing unit [203] via the trouble ticket assignment engine [205], a technician to the trouble ticket from the target assignment group.
[0066] At step [312], the method [300] comprises assigning, by the processing unit [203] via a service-level agreement (SLA) manager [206], a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters. Furthermore, the one or more predefined SLA conditions may include pre¬defined as well as dynamic conditions. For instance, the users can define the SLA condition as “Resolve High Priority Tickets in 30 Minutes”. Since, the Service Management Platform (SMP) [500] (as shown in FIG. 5) attaches the SLA(s) on basis of the attributes of the ticket, the SMP[500] assigns, as per the above-mentioned SLA condition, to the trouble ticket a “High” priority and thus the technician will receive notification for the same. SLAs get attached to the trouble ticket based upon trouble ticket parameters, where SLAs are

agreements over the quality of service and the reasonable amount of time it will take to resolve a problem. When an SLA breach deadline approaches, the system [200] sends alerts to relevant personnel (technician, Manager etc.) ensuring the trouble ticket is resolved in time. For instance, the progress notification may include notification hub service for Email / SMS. This progress notification may provide alerts such as:
- Email alert to assignee on trouble ticket assignment.
- SMS alert to assignee on trouble ticket assignment.
- Email alert on assignee & team lead on SLA violation.
- Email alert to level-2 operation context (OC) on SLA violation i.e. escalation group level 2 which means that if level-1 group fails to resolve the ticket then it automatically gets assigned to level 2 group.
[0067] The progress notification may also include notification on creation of event; notification about ticket attribute value change event; status change event notification; ticket delete event notification; and resolved event notification.
[0068] At step [314], the method [300] comprises transmitting, by the transceiver unit [201] via a Notification Engine [207], a set of notifications to the user associated with the trouble ticket.
[0069] Thereafter, the method [300] terminates at step [316].
[0070] In an exemplary aspect of the present disclosure, the method [300] further comprises detecting, by the processing unit [203], a trouble ticket progress associated with the trouble ticket from the technician based on a predefined trouble ticket progress condition. The method [300] further comprises automating, by the processing unit [203], the resolution of the trouble ticket based on detecting the trouble ticket progress associated with the trouble ticket from the technician and the predefined trouble ticket progress condition. In an exemplary aspect of the present disclosure, in the disclosed method [300], detecting the trouble ticket progress associated with the trouble ticket from the technician, by the processing unit [203], further comprises transmitting a progress notification associated with the trouble ticket progress to the target assignment group, wherein the progress notification is based on at least the one or more predefined SLA conditions.

[0071] In an exemplary aspect of the present disclosure, the method [300] further comprises detecting via the data ingestion module [202] the trouble ticket as one of a valid trouble ticket and an invalid trouble ticket, wherein the valid trouble ticket is detected based on the set of ticket parameters. In an exemplary aspect of the present disclosure, in the disclosed method [300], detecting the valid trouble ticket further comprises storing the valid trouble ticket in a database (DB) [208db] of a storage unit [208].
[0072] Referring to FIG. 4, an exemplary scenario method flow [400] is shown for trouble ticket call flow which depicts the manner in which the present disclosure is performed, in accordance with the exemplary embodiments of the present disclosure. The method [400] depicts microservices based trouble ticket processing, in accordance with the exemplary embodiments of the present disclosure. In an implementation of the present disclosure, the method [400] is performed by the system [200] (as shown in FIG. 2). The method [400] is performed in the following steps:
- Step 1 (S1) where a communication channel initiates a trouble ticket creation request to data ingestion module [202] (as shown in FIG. 2).
- Step 2 (S2) where the data ingestion module [202] streams the event to a Workflow Manager [204] (as shown in FIG. 2) to assign workflow to the trouble ticket based upon the ticket parameters.
- Step 3 (S3) where the data ingestion module [202] then streams the event to Trouble Ticket Assignment Engine [205] (as shown in FIG. 2) to assign the assignment group based upon the self-defined routing rules. The technician is then auto assigned to the trouble ticket from the assigned group.
- Step 4 (S4) where the data ingestion module [202] also streams the event to Service Level Agreement (SLA) Manager [206] (as shown in FIG. 2) to auto- assign SLAs to trouble ticket based upon the SLA conditions and trouble ticket.
- Step 5 (S5) where a trouble ticket which was created is ingested to a database (DB) [308db] (as shown in FIG. 2) of a storage unit [208] (as shown in FIG. 2).
- Step 6 (S6) where an appropriate notification(s) is sent to the engineer assigned to trouble ticket using a notification engine [207] (as shown in FIG. 2).
- Step 7 (S7) where the notifications are then published to registered listener/ user/ customer on every milestone.

- Step 8 (S8) where the engineer then helps the customer to resolve the issue and
when the issue is fully resolved, the engineer closes the ticket.
[0073] Referring to FIG. 5, an exemplary Service Management Platform (SMP)SMP [500] architecture is shown, in accordance with the exemplary embodiments of the present disclosure. As shown in FIG. 5, the SMP [500] architecture includes a user interface (UI)[510]; workflow design service (WFD) [540]; workflow assign service (WFA) [528]; workflow execution engine (WFEE) [530]; application programming interface (API) Gateway [514]; a lightweight directory access protocol (LDAP) [524]; customer assurance (CA) [534]; resource assurance (RA) [536]; service assurance (SA) [538]; data ingestion module (DI) [516]; data aggregator service (DA) [518]; workflow manager (SCM) [560]; Identity and Access Management (IAM) [522]; an asynchronous (ASYNC) streaming engine [520]: an persistent data store engine [544a]: and a SMP cache store [544b].
[0074] The SMP [500] has a microservices based architecture which improvises scalability and resiliency. The services of SMP [500] work in tandem to provide workflow management, customer assurance, resource assurance and service assurance functions. The SMP [500] integrates with operations support systems (OSS)/ business support systems (BSS) platforms like customer relationship management (CRM) [504], network management system (NMS) [502], cognitive platform (JCP) [506] and integrated performance management (IPM) [508]. The integration with the CRM [504] provides customer assurance to manage all customer related trouble tickets and service requests. The integration with the NMS [502], the JCP [506] and the IPM [508] provides resource, service assurance respectively. The UI [510] and Applications [512] are also used for ticket creation. The Applications [512] may include a process running inside a workflow engine; a CRM [504] application issuing trouble tickets; the NMS [502] automatically generating trouble tickets; a fault management system allowing operators to merge several alerts into a trouble ticket; an operator-initiated trouble ticket from web app etc. However, the NMS [502], JCP [506], IPM [508] and the CRM [504] can also raise the trouble ticket. The trouble tickets are also streamed from DI [516] and DA [518] to the ASYNC streaming engine [520] when the DI [516] and the DA [518] operates in conjunction with persistent data store [544a] and the SMP cache store [544b] respectively of the database [544].

[0075] The UI [510] lets the user to explore available options to create, and manage with trouble tickets, work orders etc. The UI [510] has all the options which are available on SMP platform.
[0076] The WFD [540] is responsible for providing mechanism to design and create workflow from the UI [510] for the generated trouble ticket and service request related to the service assurance, customer assurance and resource assurance. The WFD [540] shares the designed workflow with the SCM [560] for provisioning.
[0077] The WFA Service [528] shall provide mechanism to assign Operation Contexts (OCs) based on circle and job role provided by LDAP service [524]. The WFA Service also has mechanism to manage SLA and Escalation Matrix.
[0078] The WFEE [530] shall provide mechanism to manage execution of generated workflow. The WFEE [530] is responsible for archiving all completed workflow. The WFEE [530] shall provide mechanism to manage workflow in case of SLA breach.
[0079] The API Gateway [514] provides a runtime and a backend component (an API proxy) for API calls. The API Gateway [514] secures, protects, manages, and scales API calls by intercepting API requests and applying policies, such as throttling and security, using handlers and managing API statistics.
[0080] The LDAP [524] is an open and cross platform protocol used for directory services authentication. The directory services store the users, passwords, and computer accounts, and share that information with other entities on the network.
[0081] The CA [534] provides mechanism to manage all trouble tickets and service request related to the CRM [504].
[0082] The RA [536] provides mechanism to manage all trouble tickets and service request related to the NMS [502].

[0083] The service assurance provides mechanism to manage all trouble tickets and service request related to the JCP [506] and the IPM [508].
[0084] The data ingestion module (DI) service [516] and the data aggregator service (DA) [518] provides mechanism to ingest data the ASYNC streaming engine [520] related to trouble ticket management and workflow management. Thus, the DI [516] and the DA [518] collect the trouble tickets from various sources.
[0085] The SCM [560] provides mechanism to manage, and provide workflow created against the trouble ticket or service request for service assurance, customer assurance, and resource assurance.
[0086] The IAM [522] act as Authorization and Authentication Application Tool for the SMP [500]. When a user logs in from the UI, the IAM [522] provides a token to be used in the subsequent Requests. The token contains information about the user, user-agent, internet protocol (IP), last access time and policy. This information helps to separate authorized requests from unauthorized requests.
[0087] The ASYNC streaming engine [520] is focused on streaming data, which is a messaging system providing bidirectional communication.
[0088] The persistent data store is a search engine based on the Lucene library. It provides a distributed, multitenant-capable full-text search engine with an HTTP web interface and schema-free JSON documents.
[0089] The SMP cache store [544b] is an in-memory data structure store, used as cache service in the SMP [500].
[0090] Another aspect of the present disclosure may relate to a non-transitory computer readable storage medium, storing instructions for automating a resolution of a trouble ticket, the instructions include executable code which, when executed by a one or more units of a system, causes: a data ingestion module [202] to receive, the trouble ticket comprising a set of ticket parameters. Further, the instructions include executable code,

which when executed causes a processing unit [203] to: assign, via a workflow manager [204], a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters; assign, via a trouble ticket assignment engine [205], a target assignment group to the trouble ticket based on a set of predefined routing rules; assign, via the trouble ticket assignment engine [205], a technician to the trouble ticket from the target assignment group; assign, via a service-level agreement (SLA) manager [206], a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters. Further, the instructions include executable code, which when executed causes the transceiver unit [201] to transmit, via a Notification Engine [207], a set of notifications to the technician associated with the trouble ticket.
[0091] Another aspect of the present disclosure may relate toa user equipment (UE) [220]. The UE [220] comprises a processor [221] configured to send a trouble ticket comprising a set of ticket parameters. The processor [221] is further configured to receive a notification associated with a resolution of the trouble ticket, wherein the trouble ticket is assigned with a target workflow, a target assignment group, a technician, and a target service level agreement (SLA) for the resolution of the trouble ticket.
[0092] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various the components/units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.
[0093] As is evident from the above, the present disclosure provides a technically advanced solution for automating a resolution of a trouble ticket. The present disclosure provides a technically advanced solution for microservices based trouble ticket based on asynchronous processing of method flow, by providing a standardized client interface to

Trouble Ticket Management Systems. The present disclosure thus enables seamless creation, tracking, and management of trouble tickets in response to customer or system-identified issues or problems. The present disclosure efficiently captures service requests from customers and automatically generates corresponding tickets, thereby eliminating the need for manual sifting through incoming requests. This streamlined approach of the present disclosure significantly enhances the efficiency of IT desks (preferably those involved in telecom services) by ensuring that clients/ customers/ users receive prompt and effective solutions to their problems. With the provision of automated tracking, the present disclosure facilitates end-to-end visibility of the ticket resolution process, thereby also allowing efficient monitoring and management of service tickets until they are successfully resolved. By leveraging the above-mentioned technical advantages of the present disclosure, one is able to optimizes workflow, reduces response times, and enhances overall customer satisfaction in customer management.
[0094] While considerable emphasis has been placed herein on the disclosed implementations, it will be appreciated that many implementations can be made and that many changes can be made to the implementations without departing from the principles of the present disclosure. These and other changes in the implementations of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.
[0095] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various components/units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.

We Claim:
1. A method [300] for automating a resolution of a trouble ticket, the method comprising:
receiving, by a data ingestion module [202], the trouble ticket comprising a set of ticket parameters;
assigning, by a processing unit [203] via a workflow manager [204], a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters;
assigning, by the processing unit [203] via a trouble ticket assignment engine [205], a target assignment group to the trouble ticket based on a set of predefined routing rules;
assigning, by the processing unit [203] via the trouble ticket assignment engine [205], a technician to the trouble ticket from the target assignment group;
assigning, by the processing unit [203] via a service-level agreement (SLA) manager [206], a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters; and
transmitting, by a transceiver unit [201] via a Notification Engine [207], a set of notifications to a user associated with the trouble ticket.
2. The method [300] as claimed in claim 1, wherein the method [300] further comprises:
detecting, by the processing unit [203], a trouble ticket progress associated with the trouble ticket from the technician based on a predefined trouble ticket progress condition; and
automating, by the processing unit [203], the resolution of the trouble ticket based on detecting the trouble ticket progress associated with the trouble ticket from the technician and the predefined trouble ticket progress condition.
3. The method [300] as claimed in claim 1, wherein the method [300] further comprises
detecting via the data ingestion module [202] the trouble ticket as one of a valid trouble
ticket and an invalid trouble ticket, wherein the valid trouble ticket is detected based
on the set of ticket parameters.

4. The method [300] as claimed in claim 3, wherein detecting the valid trouble ticket further comprises storing the valid trouble ticket in a database (DB) [208db] of a storage unit [208].
5. The method [300] as claimed in claim 3, wherein detecting a trouble ticket progress associated with the trouble ticket from the technician, by the processing unit [203], further comprises transmitting a progress notification associated with the trouble ticket progress to the target assignment group, wherein the progress notification is based on at least the one or more predefined SLA conditions.
6. The method [300] as claimed in claim 1, wherein the set of ticket parameters facilitates identifying one or more problems, determining a priority level of the trouble ticket, and identifying impact of the one or more problems on an entity.
7. A system [200] for automating a resolution of a trouble ticket, the system [200] comprises:

- a data ingestion module [202] configured to receive, the trouble ticket comprising a set of ticket parameters; and
- a processing unit [203] connected to at least the data ingestion module [202], wherein the processing unit [203] is configured to:
o assign, via a workflow manager [204], a target workflow to the trouble ticket based on one or more ticket parameters from the set of ticket parameters;
o assign, via a trouble ticket assignment engine [205], a target assignment group to the trouble ticket based on a set of predefined routing rules;
o assign, via the trouble ticket assignment engine [205], a technician to the trouble ticket from the target assignment group;
o assign, via a service-level agreement (SLA) manager [206], a target SLA to the trouble ticket based on at least one of one or more predefined SLA conditions and the set of trouble ticket parameters; and
- a transceiver unit [201] is configured to:
transmit, via a Notification Engine [207], a set of notifications to the technician associated with the trouble ticket.

8. The system [200] as claimed in claim 7, wherein the processing unit [203] is further
configured to:
- detect, a trouble ticket progress associated with the trouble ticket from the technician based on a predefined trouble ticket progress condition; and
- automate the resolution of the trouble ticket based on detecting the trouble ticket progress associated with the trouble ticket from the technician and the predefined trouble ticket progress conditions.

9. The system [200] as claimed in claim 7, wherein the processing unit [203] is further configured to detect via the data ingestion module [202] the trouble ticket as one of a valid trouble ticket and an invalid trouble ticket, wherein the valid trouble ticket is detected based on the set of ticket parameters.
10. The system [200] as claimed in claim 9, wherein the valid trouble ticket detected is further stored in a database (DB) [208db] of a storage unit [208].
11. The system [200] as claimed in claim 9, wherein to detect a trouble ticket progress associated with the trouble ticket from the technician, the processing unit [203] is further configured to transmit a progress notification associated with the trouble ticket progress to the target assignment group, wherein the progress notification is based on at least the one or more predefined SLA conditions.
12. The system [200] as claimed in claim 7, wherein the set of ticket parameters facilitates identification of one or more problems faced by one or more users, a determination of a priority level of the trouble ticket, and an identification of an impact of the one or more problems on an entity.
13. A user equipment (UE) [220] comprising:
a processor [221], the processor [221] is configured to:
o send a trouble ticket comprising a set of ticket parameters; and o receive a notification associated with a resolution of the trouble ticket, wherein the trouble ticket is assigned with a target workflow, a target

assignment group, a technician, and a target service level agreement (SLA) for the resolution of the trouble ticket.