System and method for resolving a trouble ticket

Abstract

Disclosed is a system (200) and a method (400) for resolving a trouble ticket. The method comprises receiving, via a User Interface (UI) (130) of a User Equipment (UE) (104), the trouble ticket including one or more attributes. The method further comprises performing a similarity matching process to identify one or more previously resolved trouble tickets from a historical ticket database (120) similar to the received trouble ticket. The method further comprises retrieving, from the historical ticket database (120), one or more Method of Procedures (MOPs) corresponding to the identified one or more previously resolved trouble tickets. The method further comprises displaying an auto-resolution option on the UI based on the retrieved one or more MOPs and executing, based on a selection of an MOP among the one or more MOPs, one or more steps defined in the selected MOP to resolve the trouble ticket.

Description

SYSTEM AND METHOD FOR RESOLVING A TROUBLE TICKETTECHNICAL FIELD

[0001] The embodiments of the present disclosure generally relate to the field of information processing systems. More particularly, the present disclosure relates to a system and a method for resolving a trouble ticket.BACKGROUND OF THE INVENTION

[0002] The subject matter disclosed in the background section should not be assumed or construed to be prior art merely because of its mention in the background section. Similarly, any problem statement mentioned in the background section or its association with the subject matter of the background section should not be assumed or construed to have been previously recognized in the prior art.

[0003] In Information Technology (IT) service management, resolution of trouble tickets is a core operational activity. The trouble tickets typically report technical issues or service disruptions and are processed by support agents or automated systems. Traditionally, the resolution process involves analyzing ticket contents, identifying a root cause, determining a suitable solution, and executing necessary steps to close the trouble ticket.

[0004] Many existing solutions maintain historical records of previously resolved trouble tickets. However, the existing solutions do not fully utilize this historical data to guide or automate the resolution of new tickets. These solutions often lack an ability to identify meaningful correlations between ticket attributes such as problem types or closure codes and associated resolution steps. As a result, support personnel must frequently resolve similar issues from scratch, resulting in redundant efforts and delayed resolution timelines.

[0005] Further challenge is inconsistency in the resolution process. Manual intervention introduces variability, as different support personnel apply different procedures or make errors in execution of known solutions. Such inconsistencyresults in prolonged resolution times, reduced service quality, and user dissatisfaction. Furthermore, standardized resolution processes lead to errors, with support personnels potentially overlooking critical steps or applying incorrect solutions.

[0006] Additionally, the existing solutions typically do not offer dynamic interaction models where the system recommends the resolution based on past cases and allows a user to either accept or bypass the suggested resolution. Additionally, when the suggested resolution is not applied, the existing solutions do not have provisions for capturing and storing the user’s resolution steps for future reference or automation.

[0007] In light of the above-mentioned challenges associated with the traditional and the existing solutions, there lies a need for an improved system and a method for resolving the trouble tickets.SUMMARY

[0008] The following embodiments present a simplified summary to provide a basic understanding of some aspects of the present disclosure. This summary is not an extensive overview, and it is not intended to identify key / critical elements or to delineate the scope thereof. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

[0009] According to an aspect of the present disclosure, a method for resolving a trouble ticket is disclosed. The method comprises receiving, by a receiving engine via a User Interface (UI) of a User Equipment (UE), the trouble ticket including one or more attributes. The method further comprises performing, by a ticket processing engine, a similarity matching process to identify one or more previously resolved trouble tickets from a historical ticket database similar to the received trouble ticket. The method further comprises retrieving, by a retrieving engine from the historical ticket database, one or more Method of Procedures (MOPs) corresponding to the identified one or more previously resolved trouble tickets. The method furthercomprises displaying, by a suggestion engine, an auto-resolution option on the UI based on the retrieved one or more MOPs and executing, by an auto resolution execution engine based on a selection of an MOP among the one or more MOPs, one or more steps defined in the selected MOP to resolve the trouble ticket.

[0010] In one or more implementations, to perform the similarity matching process to identify the one or more previously resolved trouble tickets, the method further comprises comparing the one or more attributes of the received trouble ticket with one or more attributes of a plurality of previously resolved trouble tickets stored in the historical ticket database and identifying, for each of the plurality of previously resolved trouble tickets based on the comparison, a similarity score between the received trouble ticket and the plurality of previously resolved trouble tickets. The method further comprises identifying the one or more previously resolved trouble tickets among the plurality of previously resolved trouble tickets that have the similarity score greater than a threshold.

[0011] In one or more implementations, the one or more attributes of the received trouble ticket include a description of a problem, one or more information associated with a user, information of trouble environment and related resources, characteristic issues associated with the trouble ticket, and operating conditions associated with the trouble environment.

[0012] In one or more implementations, the one or more attributes of each of the plurality of previously resolved trouble tickets include at least one of a closure code, a problem type, and a cause code associated with a corresponding trouble ticket among the plurality of previously resolved trouble tickets.

[0013] In one or more implementations, the displaying the auto-resolution option includes displaying the one or more MOPs and one or more information associated with each MOP of the one or more MOPs, the one or more information includes metadata and a success resolution ratio of each MOP.

[0014] In one or more implementations, the method further comprises displaying, along with the auto-resolution option, a manual option to select manual resolution of the trouble ticket.

[0015] In one or more implementations, the method further comprises receiving, by the receiving engine upon completion of the manual resolution of the trouble ticket, information of a closure code, a cause code and a problem type selected by a user and capturing, by an MOP capturing engine based on the received information, the one or more steps performed by the user to resolve the trouble ticket. The method further comprises storing, by the MOP capturing engine, the captured one or more steps as a new MOP in the historical ticket database.

[0016] In one or more implementations, the method further comprises capturing, by a MOP capturing engine, the one or more steps executed to resolve the trouble ticket and storing, by the MOP capturing engine, the one or more steps as a new MOP in the historical ticket database based on a closure code of the trouble ticket indicating that the trouble ticket is resolved.

[0017] In one or more implementations, the method further comprises analyzing, by a data analysis engine, a plurality of previously resolved trouble tickets to identify a closure code, a cause code, and a problem type for each of the plurality of previously resolved trouble tickets and grouping, by the data analysis engine, the plurality of previously resolved trouble tickets in one or more groups based on the analysis, the one or more previously resolved trouble tickets are identified from a same group among the one or more groups.

[0018] According to another aspect of the present disclosure, a system for resolving a trouble ticket is disclosed, the system comprises a receiving engine, a ticket processing engine, a retrieving engine, a suggestion engine and an auto resolution execution engine. The receiving engine is configured to receive via a User Interface (UI) of a User Equipment (UE), the trouble ticket including one or more attributes. The ticket processing engine is configured to perform a similarity matching process to identify one or more previously resolved trouble tickets from a historical ticketdatabase similar to the received trouble ticket. The retrieving engine is configured to retrieve from the historical ticket database, one or more Method of Procedures (MOPs) corresponding to the identified one or more previously resolved trouble tickets. The suggestion engine is configured to display an auto-resolution option on the UI based on the retrieved one or more MOPs; and the auto resolution execution engine is configured to execute based on a selection of an MOP among the one or more MOPs, one or more steps defined in the selected MOP to resolve the trouble ticket.BRIEF DESCRIPTION OF DRAWINGS

[0019] Various embodiments disclosed herein will become better understood from the following detailed description when read with the accompanying drawings. The accompanying drawings constitute a part of the present disclosure and illustrate certain non-limiting embodiments of inventive concepts. Further, components and elements shown in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. For consistency and ease of understanding, similar components and elements are annotated by reference numerals in the exemplary drawings.

[0020] FIG. 1 illustrates an exemplary environment of a communication system for resolving a trouble ticket, in accordance with an exemplary embodiment of the present disclosure.

[0021] FIG. 2 illustrates a block diagram of a system for resolving the trouble ticket, in accordance with an exemplary embodiment of the present disclosure.

[0022] FIG. 3 illustrates a system workflow for trouble ticket handling, in accordance with an exemplary embodiment of the present disclosure.

[0023] FIG. 4 illustrates a flowchart depicting a method for resolving the trouble ticket, in accordance with an embodiment of the present disclosure.

[0024] FIG. 5 illustrates a schematic block diagram depicting an architecture of a computing system, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION OF THE INVENTION

[0025] Inventive concepts of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of one or more embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Further, the one or more embodiments disclosed herein are provided to describe the inventive concept thoroughly and completely, and to fully convey the scope of each of the present inventive concepts to those skilled in the art. Furthermore, it should be noted that the embodiments disclosed herein are not mutually exclusive concepts. Accordingly, one or more components from one embodiment may be tacitly assumed to be present or used in any other embodiment.

[0026] The following description presents various embodiments of the present disclosure. The embodiments disclosed herein are presented as teaching examples and are not to be construed as limiting the scope of the present disclosure. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified, omitted, or expanded upon without departing from the scope of the present disclosure.

[0027] The following description contains specific information pertaining to embodiments in the present disclosure. The detailed description uses the phrases “in some embodiments” or “some implementations” which may each refer to one or more or all of the same or different embodiments or implementations. The term “some” as used herein is defined as “one, or more than one, or all.” Accordingly, the terms “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” In view of the same, the terms, for example, “in an embodiment” or “in an implementation” refers to one embodiment or oneimplementation and the term, for example, “in one or more embodiments” refers to “at least one embodiment, or more than one embodiment, or all embodiments”. Further, the term, for example, “in one or more implementations” refers to “at least one implementation, or more than one implementation, or all implementations.

[0028] The term “comprising,” when utilized, means “including, but not necessarily limited to;” it specifically indicates open-ended inclusion in the so-described one or more listed features, elements in a combination, unless otherwise stated with limiting language. Furthermore, to the extent that the terms “includes,” “has,” “have,” “contains,” and other similar words are used in either the detailed description, such terms are intended to be inclusive in a manner similar to the term “comprising.”

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

[0030] The description provided herein discloses exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing any of the exemplary embodiments. Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it may be understood by one of the ordinary skilled in the art that the embodiments disclosed herein may be practiced without these specific details.

[0031] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein the description, the singular forms "a", "an", and "the" include plural forms unless the context of the present disclosure indicates otherwise.

[0032] The terminology and structure employed herein are for describing, teaching, and illuminating some embodiments and their specific features and elements and do not limit, restrict, or reduce the scope of the present disclosure. Accordingly, unless otherwise defined, all terms, and especially any technical and / or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having ordinary skill in the art.

[0033] The present disclosure relates to a system and a method for resolving a trouble ticket. More specifically, the disclosure provides a mechanism for identifying previously resolved issues based on historical ticket data, retrieving associated resolution procedures, and facilitating automated or user-guided resolution of new trouble tickets. The system further supports storing executed resolution steps as reusable procedures to assist in handling future occurrences of similar issues.

[0034] An aspect of the present disclosure is to provide a system and a method for providing intelligent resolution of the trouble tickets using historical resolution data.

[0035] Another aspect of the present disclosure is to provide a system and a method for retrieving and recommending structured resolution steps, such as a Method of Procedure (MOP), associated with previously resolved trouble tickets to resolve the trouble ticket.

[0036] Yet another aspect of the present disclosure is to provide a system and a method that enables a continuous learning mechanism by feeding an outcome of each resolution back into the system, thereby making trouble ticket resolution more robust.

[0037] Several key terms used in the description play pivotal roles in facilitating the system functionality. In order to facilitate an understanding of the description, the key terms are defined below.

[0038] The trouble ticket- The trouble ticket may refer to a record generated within the system that captures details of a reported technical issue, fault, or service request.

[0039] The MOP- The MOP may refer to a predefined, structured set of executable steps that outlines a technical resolution process for a specific type of the issue or the fault.

[0040] Cause code- The term cause code may refer to an underlying reason why a problem occurred. In a non-limiting example, cause codes may include software mismatch, hardware failure, configuration error, power outage or IP connectivity loss. The cause code may also be defined as a set of codified terms representing different problems. The codified terms may be in a form of, but not limited to, alphanumeric strings, numeric values, alphabetic identifiers, or descriptive phrases.

[0041] Closure code- The term closure code may refer to a classification or tag assigned to a resolved trouble ticket, indicating a nature of the resolution applied. In a non-limiting example, closure codes may include fixed software bug, replaced hardware, or reconfigured parameters. The closure code may also be defined as a set of codified terms representing different problems. The codified terms may be in a form of, but not limited to, alphanumeric strings, numeric values, alphabetic identifiers, or descriptive phrases.

[0042] Resolution status- The term resolution status may refer to a state indicator maintained for the trouble ticket that reflects the progress or outcome of the resolution process. The resolution status may include values such as “pending,” “inprogress,” “partially resolved”, “resolved via auto-resolution,” or “resolved via user-initiated resolution.”

[0043] Problem Type- A descriptor or label used to categorize technical nature of the issue reported in the trouble ticket. Examples of problem types may include “network failure,” “authentication error,” or “service degradation”. The problem type is used in correlation with other attributes, such as the closure code, to identify relevant MOPs. The problem type may further include additional informationrelated to trouble environment, a pre-trouble situation or other contextual aspects of the trouble.

[0044] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings. FIG. 1 through FIG. 5, discussed below, and the one or more embodiments used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

[0045] FIG. 1 illustrates an exemplary environment of a communication system 100 for resolving the trouble ticket, in accordance with an exemplary embodiment of the present disclosure, in accordance with an exemplary embodiment of the present disclosure. The embodiment of the communication system 100 shown in FIG. 1 is for illustration only. Other embodiments of the communication system 100 may be used without departing from the scope of this disclosure.

[0046] As shown in FIG. 1, the communication system 100 includes a server 110 and a User Interface (UI) 130. The server 110 is configured to communicate with the UI 130. The server 110 is further connected with a historical ticket database 120 (hereinafter also referred to as “database 120”).

[0047] In an embodiment, the server 110 may be configured as an application server and may be communicably operational or may be integrated with the UI 130 via a network 140. The network 140 may provide a path for the exchange of information between the server 110 and the UI 130.

[0048] The UI 130 is capable of providing options to the user for raising or creating the trouble ticket. The options within the UI 130 may be displayed on a ticket interface. The ticket interface may allow users to submit new trouble tickets with one or more attributes, but not limited to, description of the problem, one or more information associated with the user, information of trouble environment. The ticketinterface also supports displaying the status of submitted tickets and the resolution status of the submitted ticket.

[0049] Upon submission and internal analysis of the trouble ticket, the UI 130 further enables the display of an option to apply the auto-resolution or manual resolution, when the system determines that a previously resolved trouble ticket closely matches the newly submitted trouble ticket. The user is presented with both the options and may choose to proceed with system-executed resolution steps retrieved from a corresponding MOP. After resolution (whether via automated execution or alternative resolution paths), the UI 130 supports selection or display of one or more attributes (described below in detail) associated with the resolved trouble ticket, which may be used to classify the resolution that was applied.

[0050] Although FIG. 1 illustrates one example of the communication system 100, various changes may be made to FIG. 1. Further, various components in FIG. 1 may be combined, further subdivided, or omitted and additional components may be added according to particular needs.

[0051] FIG. 2 illustrates a block diagram of a system 200 for resolving the trouble ticket, in accordance with an exemplary embodiment of the present disclosure.

[0052] The system 200 comprises a server 110 which may include a processor 202, a memory 204, a communication interface 206, an Input-Output (I / O) interface 208 and processing engines 210. Each of the components of the server 110 is communicatively coupled to each other via a first communication bus 290-2.

[0053] The processor 202 may include various processing circuitry and communicate with the memory 204, and the communication interface 206 via the first communication bus 290-2. The processor 202 is configured to execute instructions or a set of instructions stored in the memory 204 to perform various processes. In an implementation, the processor 202 may also include the processing engines 210. Components of the processing engines 210 are coupled to each other via a second communication bus 290-4.

[0054] The processor 202 may include a general-purpose processor, such as, for example, and without limitation, a Central Processing Unit (CPU), an Application Processor (AP), a dedicated processor, a Graphics-only Processing Unit such as a Graphics Processing Unit (GPU) or the like, a programmable logic device, or any combination thereof.

[0055] The memory 204 stores the set of instructions required by the processor 202 of the server 110 for controlling its overall operations. The memory 204 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of Electrically Programmable Memories (EPROM) or Electrically Erasable and Programmable (EEPROM) memories. In addition, the memory 204 may, in some examples, be considered a non-transitory storage medium. The "non-transitory" storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted as the memory 204 is nonmovable. In some examples, the memory 204 may be configured to store larger amounts of information. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 204 may be an internal storage unit or an external storage unit of the server 110, cloud storage, or any other type of external storage.

[0056] The communication interface 206 may include an electronic circuit specific to a standard that enables wired or wireless communication. The communication interface 206 is configured for communicating with external devices via networks.

[0057] The I / O interface 208 may include suitable logic, circuitry, interfaces, and / or codes that may be configured to receive input(s) and present (or display) output(s) on the server 110. For example, the I / O interface 208 may have an input interface (not shown) and an output interface (not shown). The input interface may be configured to enable a user to provide input(s) to trigger (or configure) the server 110 for performing data processing operation(s). Examples of the input interface may include, but are not limited to, a touch interface, a mouse, a keyboard, a motionrecognition unit, a gesture recognition unit, a voice recognition unit, or the like. Examples of the output interface may include, but are not limited to, a digital display, an analog display, a touch screen display, an appearance of a desktop, and / or illuminated characters. Aspects of the present disclosure are intended to include or otherwise cover any type of the input interface and output interface in the VO interface 208, including known, related art, and / or later developed technologies without deviating from the scope of the present disclosure.

[0058] The processing engines 210 may include a receiving engine 220, a ticket processing engine 230, a retrieving engine 240, a suggestion engine 250 and an auto resolution execution engine 260. The receiving engine 220 is configured to receive via the UI 130 of a User Equipment (UE) 104, the trouble ticket including the one or more attributes. The ticket processing engine 230 is configured to perform a similarity matching process to identify one or more previously resolved trouble tickets from the historical ticket database 120 similar to the received trouble ticket. The retrieving engine 240 is configured to retrieve from the historical ticket database 120, one or more MOPs corresponding to the identified one or more previously resolved trouble tickets. The suggestion engine 250 is configured to display the auto-resolution option on the UI 130 based on the retrieved one or more MOPs and the auto resolution execution engine 260 is configured to execute based on the selection of the MOP among the one or more MOPs, one or more steps defined in the selected MOP to resolve the trouble ticket.

[0059] Further, to perform the similarity matching process for identifying the one or more previously resolved trouble tickets, the ticket processing engine 230 is configured to compare the one or more attributes of the received trouble ticket with the one or more attributes of a plurality of previously resolved trouble tickets stored in the historical ticket database 120 and identify, for each of the plurality of previously resolved trouble tickets based on the comparison, a similarity score between the received trouble ticket and the plurality of previously resolved trouble tickets. The ticket processing engine 230 is further configured to identify the one ormore previously resolved trouble tickets among the plurality of previously resolved trouble tickets that have the similarity score greater than a threshold.

[0060] Further, to display the auto-resolution option, the suggestion engine 250 is configured to display the one or more MOPs and one or more information associated with each MOP of the one or more MOPs. The one or more information includes metadata and a success resolution ratio of each MOP. In one or more implementations, the suggestion engine 250 is configured to display, along with the auto-resolution option, a manual option to select the manual resolution of the trouble ticket.

[0061] In one or more implementations, the receiving engine 220 is configured to receive, upon completion of the manual resolution of the trouble ticket, information of the closure code, the cause code and the problem type selected by the user.

[0062] The processing engines 210 may further include an MOP capturing engine 270 which, based on the received information, is configured to capture the one or more steps performed by the user to resolve the trouble ticket. The MOP capturing engine 270 is further configured to store the captured one or more steps as a new MOP in the historical ticket database 120.

[0063] In one or more implementations, to cover the scenarios where the autoresolution is applied, the MOP capturing engine 270 is configured to capture the one or more steps executed to resolve the trouble ticket and store the one or more steps as the new MOP in the historical ticket database 120 based on the closure code, the cause code and the problem type of the trouble ticket indicating that the trouble ticket is resolved.

[0064] The processing engines 210 may further include a data analysis engine 280 which is configured to analyze the plurality of previously resolved trouble tickets to identify the closure code, the cause code, and the problem type for each of the plurality of previously resolved trouble tickets and group the plurality of previously resolved trouble tickets in one or more groups, based on the analysis. The one ormore previously resolved trouble tickets are identified from a same group among the one or more groups.

[0065] Although FIG. 2 illustrates one example of the server 110, various changes may be made to FIG. 2. Further, various components in FIG. 2 may be combined, further subdivided, or omitted, and additional components may be added according to particular needs.

[0066] FIG. 3 illustrates a system workflow 300 for trouble ticket handling, in accordance with an exemplary embodiment of the present disclosure.

[0067] Referring now to FIG. 3, at step 302, the new trouble ticket is received by the receiving engine 220 via the UI 130 of the UE 104. The trouble ticket includes the one or more attributes such as, but not limited to, the description of the problem, user information, details of the trouble environment, operating conditions associated with the trouble environment, priority field which indicates criticality of the trouble ticket (for example, “critical,” “major,” or “minor”), and other context information relevant to the trouble ticket. In a non-limiting example, the trouble ticket may be raised for 5G service degradation in Mumbai circle during an event. The trouble ticket description may indicate that the users are experiencing frequent call drops. The user information associated with the trouble ticket may identify affected user group present in the event, including their device types. The details of the trouble environment may specify that two specific cell towers serving the event are reporting abnormal congestion. The operating conditions associated with the trouble environment may include real-time metrics such as high traffic load exceeding 85% utilization, and reduced signal-to-noise ratio. In one or more embodiments, the one or more attributes may further include priority level, time of occurrence and other affected services such as voice and data.

[0068] At step 304, the ticket processing engine 230 may perform the similarity matching process by comparing the one or more attributes of the received trouble ticket with attributes of the plurality of previously resolved trouble tickets (similar historical tickets) stored in the historical ticket database 120. In one or moreembodiments, the similarity matching may be based on a Natural Language Processing (NLP) analysis of the problem description in combination with structured attribute comparison. Similarity may be calculated using various algorithms, but not limited to, cosine similarity, Euclidean distance, Manhattan distance, Jaccard similarity, or other vector-based similarity algorithms. In one or more embodiments, the ticket processing engine 230 may compute a similarity score using a combination of text-based similarity (the problem description) and structured-field matching (the problem type, the cause code, the closure code).

[0069] At step 306, a determination is made as to whether one or more previously resolved trouble tickets similar to the received ticket are found based on the similarity scores. If the similarity score for any previously resolved ticket exceeds a defined threshold, such trouble tickets are identified as similar. If no similar tickets are found, the process moves to step 310. At step 310, the trouble ticket is resolved manually by the user and then the process moves to step 318, where the resolution outcome is recorded. The resolved ticket, along with its associated attributes and applied resolution details, is then stored in the database 120 for use in future similarity matching and recommendation processes. In a non-limiting example, when the new trouble ticket relates to a software mismatch on Router Rl, the ticket processing engine 230 may identify the previously resolved trouble tickets involving similar mismatches on Router Rl even if the problem description differ.

[0070] In another non-limiting example, the received trouble ticket indicating 5G data session failures in Delhi Circle may be compared against previously resolved trouble tickets. Using the cosine similarity on the problem description together with the structured field matching on the attributes such as the problem type (session failure) and the cause code (software mismatch), the ticket processing engine 230 may compute a similarity score of 0.87, which exceeds the predefined threshold and therefore identifies a matching previously resolved trouble ticket.

[0071] At step 308, if similar trouble tickets are identified, the retrieving engine 240 may fetch the one or more corresponding MOPs from the historical ticket database120. The suggestion engine 250 may then display, on the UI 130, the auto-resolution option based on the retrieved MOPs. In one or more embodiments, each suggested MOP may include metadata such as device compatibility, vendor information, software version, and the success resolution ratio of each MOP. In a non-limiting example, for a 5G degradation trouble ticket, the suggestion engine 250 may display two MOPs: (i) restart service process, and (ii) apply a configuration patch, and the MOPs may be ranked in order of the success resolution ratio. The success resolution ratio here may refer to a performance metric calculated by the system 200 based on a number of times a particular MOP (or set of MOPs) has successfully resolved similar trouble tickets in the past, relative to the total number of times that MOP has been applied. If the success resolution ratio of the suggested MOP is high (for example, above a configurable threshold such as 90%), the system 200 may classify the MOP as low-risk and safe for the automatic resolution. Conversely, if the ratio is low or the MOP has a mixed history (e.g., partial resolutions or frequent failures), the system 200 may default to manual resolution mode, requiring the user confirmation before execution. In yet another embodiment, the system 200 may allow the user to select the mode of execution for the given MOPs. The user may still, select “NO” to the auto-resolution option, and the solution move to manual resolution option. In a non-limiting example, say, the system 200 suggests three MOPs for the trouble ticket reporting of 5G service degradation in Delhi Circle. The highest-ranked MOP involves restarting the network node, which the system 200 suggests for the automatic resolution. However, the user may consider this action too risky in a live traffic scenario and therefore selects manual resolution mode.

[0072] At step 312, upon user confirmation, the auto resolution execution engine 260 may apply the suggested auto-resolution by selecting one of the displayed MOPs. The chosen MOP is prepared for the execution. In one or more embodiments, risk-sensitive MOPs (such as shutting down or restarting a network element) may require explicit confirmation from the user before the execution. In an alternative embodiment, for one or more metadata / criteria, user’s confirmation is not necessary, the MOP is automatically selected and executed. In yet another embodiment, theuser is displayed options to select whether to automatically execute any specific one or more MOPs or click for auto execution bases user’s choice / decision.

[0073] At step 314, the auto resolution execution engine 260 may execute the selected MOP among the displayed MOPs. In one or more embodiments, the execution may include executing the one or more steps defined in the selected MOP such as applying predefined commands, configuration changes, or automated workflows required to resolve the trouble ticket. In a non-limiting example, the auto resolution execution engine 260 may send an automated command to restart a 5G process on a base station.

[0074] At step 316, the ticket processing engine 230 may evaluate whether the execution of the selected MOP successfully resolved the trouble ticket. In one or more embodiments, success check may involve validation routines, test results, or confirmation feedback. If successful, the process proceeds to step 318; otherwise, the process continues to step 320.

[0075] At step 318, when the resolution is successful, the ticket processing engine 230 may update the status of the trouble ticket to “resolved” (ticket close) and logs the resolution activity. In one or more embodiments, the information including the closure code, the problem type, the cause code, the resolution status, and an indication of the auto-resolution is stored in the historical ticket database 120 by the ticket processing engine 230. In a non-limiting example, for the trouble ticket reporting Voice over Internet Protocol (VoIP) call drops in the Mumbai circle, the ticket processing engine 230 may automatically apply the suggested MOP such as increase session timeout in VoIP server. If the execution is validated as the successful (for example, improved call setup success rate), the ticket processing engine 230 may automatically update the trouble ticket status to “resolved” with an appropriate closure code (“configuration updated”) and logs all relevant details in the historical ticket database 120 without further operator intervention.

[0076] At step 320, if the trouble ticket is not resolved automatically, the operator may proceed with the manual resolution. The MOP capturing engine 270 maycapture the manual resolution steps perform by the user as the new MOP and stores them in the historical ticket database 120 for future use. In a non-limiting example, if restarting the service fails, the operator may identify a faulty configuration file, apply corrective changes, and these manual steps are captured by the MOP capturing engine 270 and stored as the new MOP in the historical ticket database 120. In an embodiment, the selection of manual steps may also be guided by Artificial intelligence (Al) and Machine Learning (AI / ML) analytics of older records, wherein the suggestion engine 250 may suggests likely corrective actions based on the previously resolved trouble tickets but leaves the final resolution to an operator’s choice.

[0077] In one or more embodiments, the data analysis engine 280 may periodically groups the trouble tickets into categories based on the closure codes, the resolution status, the cause codes, and the problem types. Such groupings may be dynamically updated using machine learning models to improve future similarity matching accuracy. In one or more embodiments, the cause code may also be generated as the outcome of learning by the analysis of the previously resolved trouble tickets and the generated cause code may be suggested to the user, where the user may accept as it is or may change to finalize and save the cause code to the associated trouble ticket in the database for the future use. The closure code may also be generated as the outcome of the learning by the analysis of the previously resolved trouble tickets and the generated closure code may be suggested to the user, where user can accept as it is or can change to finalize and save the closure code to the associated trouble ticket, in the database 120 for the future use.

[0078] FIG. 4 illustrates a flowchart depicting a method 400 for resolving the trouble ticket, in accordance with an embodiment of the present disclosure. The method 400 comprises a series of operation steps performed by the system 200. The series of operation steps are indicated by blocks 402 through 410 in FIG. 4. The method 400 starts at step 402.

[0079] Referring now to Figure 4, at step 402, the receiving engine 220 may receive the trouble ticket via the UI 130 of the UE 104, the trouble ticket including the one or more attributes such as the description of a problem, the one or more information associated with the user, information of the trouble environment and related resources, characteristic issues associated with the trouble ticket, and the operating conditions associated with the trouble environment.

[0080] At step 404, the ticket processing engine 230 may perform the similarity matching process to identify one or more previously resolved trouble tickets from the historical ticket database 120 similar to the received trouble ticket.

[0081] At step 406, the retrieving engine 240 may retrieve the one or more MOPs corresponding to the identified one or more previously resolved trouble tickets. Each MOP may include step-by-step procedures previously executed to resolve similar trouble tickets.

[0082] At step 408, the retrieved MOPs are displayed, by the suggestion engine 250, on the UI 130 as the auto-resolution options. Each MOP may be accompanied by the metadata such as device compatibility, software version, the vendor, and risk level. The metadata may influence ranking and selection of the MOPs, since certain MOPs may only be applicable to specific device models or software versions, while risk assessment may guide whether the MOP is to be prioritized, suggested with caution, or requires the user confirmation before the execution. Displaying the metadata enables the operator to select the most appropriate MOP when multiple alternatives exist. In one or more embodiments, the UI 130 may provide an edit option allowing the user to modify the suggested MOP before the execution. The user may add, delete, or reorder the steps of the MOP to tailor it for the specific trouble ticket raised. Once the edited MOP is executed, the updated MOP is stored in the database 120 as the new MOP associated with that problem type for future reference and recommendations.In a non-limiting example, if the MOP for the service degradation includes 10 steps. The user determines that steps 3 and 4 are not relevant for a specific vendor’s routerand deletes them, while adding a new diagnostic step before step 5. The edited MOP is executed, and this updated procedure is saved as the new MOP for similar future incidents.

[0083] At step 410, the auto resolution execution engine 260, upon the user confirmation, executes the one or more steps of the selected MOP. The execution may include, but not limited to, running automated scripts, restarting processes, or updating parameters given in the selected MOP. In a non-limiting example, for the VoIP call drop trouble ticket, the retrieved MOPs may include solutions such as: (i) increase session timeout in the VoIP server, and (ii) restart the VoIP application service. The operator may select the MOP which says increase the session timeout, and the auto resolution execution engine 260 may further execute the corresponding configuration changes and verifies resolution of the trouble ticket.

[0084] In a further non-limiting example, the one or more steps in the retrieved MOP for resolving the 5G service degradation issue in a dense urban cluster may include ten sequential steps. These steps may involve actions such as verifying congestion alarms, rerouting traffic to adjacent cells, restarting specific vendor modules, or performing a controlled reboot of selected network elements. Upon suggestion of this retrieved MOP to the operator, the suggestion engine 250 may request the user confirmation for each of the steps before the execution, especially for those steps involving risky actions such as node reboot or parameter rollback. The operator may provide confirmation for seven steps while withholding confirmation for three steps supposed to be unnecessary or potentially troublesome. The auto resolution execution engine 260 may then execute the seven confirmed steps and skips the remaining three. The outcome of this partial execution is logged along with the trouble ticket, and the resolution status is updated to indicate the partial resolution. This may enable the system 200 to refine future recommendations, since skipping few steps may indicate that certain steps are frequently avoided under similar operating conditions.

[0085] Further, to resolve the partially resolved trouble ticket, the suggestion engine 250 may further suggest alternative MOPs to fully resolve the trouble ticket or the operator may proceed with the manual resolution, where the additional corrective steps performed manually may be captured and stored as a part of the new MOP or a modified MOP for future use.

[0086] FIG. 5 illustrates a schematic block diagram depicting an architecture of a computing system 500, in accordance with an embodiment of the present disclosure.

[0087] The computing system 500 includes a network 502, a network interface 504, a processor 506, an Input / Output (I / O) interface 508 and a non-transitory computer readable storage medium 510 (hereinafter may also be referred to as the “storage medium 510” or the “storage media 510”).

[0088] The network interface 504 includes wireless network interfaces such as Bluetooth, Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), General Packet Radio Service (GPRS), or Wideband Code Division Multiple Access (WCDMA) or wired network interfaces such as Ethernet, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers-864 (IEEE-864).

[0089] The processor 506 may include various processing circuitry / modules and communicate with the storage medium 510 and the I / O interface 508. The processor 506 is configured to execute instructions stored in the storage medium 510 and to perform various processes. The processor 506 may include an intelligent hardware device including a general-purpose processor, such as, for example, and without limitation, a Central Processing Unit (CPU), a dedicated processor, or the like, a Graphics-only Processing Unit such as a GPU, a microcontroller, a programmable logic device, a discrete hardware component, or any combination thereof. The processor 506 may be configured to execute computer-readable instructions 510-2 stored in the storage medium 510 to cause the system 500 to perform various functions.

[0090] The storage medium 510 stores a set of instructions i.e., computer program instructions 510-1 (hereinafter may also be referred to as instructions 510-2) required by the processor 506 for controlling its overall operations.

[0091] The storage media 510 may include an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, or the like. For example, the storage media 510 may include, but are not limited to, hard drives, floppy diskettes, optical disks, flash memory, magnetic or optical cards, solid-state memory devices, or other types of physical media suitable for storing electronic instructions. In one or more embodiments, the storage media 510 includes a Compact Disk-Read Only Memory (CD-ROM), a Compact Disk-Read / Write (CD-R / W), and / or a Digital Video Disc (DVD).

[0092] In one or more implementations, the storage medium 510 stores computer program code configured to cause the computing system 500 to perform at least a portion of the processes and / or methods. Accordingly, in at least one implementation, the computing system 500 performs the method for resolving the trouble ticket.

[0093] Embodiments of the present disclosure have been described above with reference to flowchart illustrations of methods and systems according to embodiments of the disclosure, and / or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and / or steps) in the flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and / or software including one or more computer program instructions embodied in computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including without limitation a general -purpose computer or special purpose computer, or other programmable processing apparatusto perform a group of operations comprising the operations or blocks described in connection with the disclosed method.

[0094] Further, these computer program instructions, such as embodied in computer-readable program code, may also be stored in one or more computer- readable memory or memory devices (ex. the storage medium 510) that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions 510-2 stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s).

[0095] It will further be appreciated that the term “computer program instructions” as used herein refer to one or more instructions that can be executed by the one or more processors (for example, the processor 506) to perform one or more functions as described herein. The instructions 510-2 may also be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely.

[0096] Separate instances of these methods / processes may be executed on or distributed across any number of separate computer systems. A variety of alternative implementations will be understood by those having ordinary skill in the art.

[0097] Now, referring to the technical abilities and advantageous effect of the present disclosure, operational advantages that may be provided by one or more embodiments may include providing the system and the method that improves resolution time through automated identification and execution of predefined resolution steps for recurring issues. Further a manual effort is reduced by enabling system-driven resolution wherever appropriate.

[0098] The system and the method provide dynamic adaptability by capturing alternate resolution paths when automated resolution is not applied and enhanced consistency and standardization of ticket handling across the system using structured MOPs. Furthermore, the continuous system learning through a feedback loop monitors outcomes and enriches the resolution repository over time.

[0099] Those skilled in the art will appreciate that the methodology described herein in the present disclosure may be carried out in other specific ways than those set forth herein in the above disclosed embodiments without departing from essential characteristics and features of the present invention. The above-described embodiments are therefore to be construed in all aspects as illustrative and not restrictive.

[0100] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Any combination of the above features and functionalities may be used in accordance with one or more embodiments.

[0101] In the present disclosure, each of the embodiments has been described with reference to numerous specific details which may vary from embodiment to embodiment. The foregoing description of the specific embodiments disclosed herein may reveal the general nature of the embodiments herein that others may, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications are intended to be comprehended within the meaning of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limited in scope.LIST OF REFERENCE NUMERALS

[0102] The following list is provided for convenience and in support of the drawing figures and as part of the text of the specification, which describe innovations by reference to multiple items. Items not listed here may nonetheless be part of a given embodiment. For better legibility of the text, a given referencenumber is recited near some, but not all, recitations of the referenced item in the text. The same reference number may be used with reference to different examples or different instances of a given item. The list of reference numerals is:100- Communication system104- User Equipment110- Server120- Historical ticket database / database130- User Interface (UI)200- System202- Processor204- Memory206- Communication Interface208- Input / Output interface210- Processing engines220- Receiving engine230- Ticket processing engine240- Retrieving engine250- Suggestion engine260- Auto resolution execution engine270- MOP capturing engine280- Data analysis engine290-2- First communication bus290-4- Second communication bus300- System workflow for trouble ticket handling 302-320- Steps to perform the system workflow 300 400- Method for resolving the trouble ticket 402-410- Steps to perform the method 400500- Computing System502- Network504- Network Interface- Processor - I / O interface - Non transitory computer readable storage medium-2- Instructions

Claims

We Claim:

1. A method (400) for resolving a trouble ticket, the method comprising: receiving, by a receiving engine (220) via a User Interface (UI) (130) of aUser Equipment (UE) (104), the trouble ticket including one or more attributes; performing, by a ticket processing engine (230), a similarity matching process to identify one or more previously resolved trouble tickets from a historical ticket database similar to the received trouble ticket; retrieving, by a retrieving engine (240) from the historical ticket database, one or more Method of Procedures (MOPs) corresponding to the identified one or more previously resolved trouble tickets; displaying, by a suggestion engine (250), an auto-resolution option on the UI based on the retrieved one or more MOPs; and executing, by an auto resolution execution engine (260) based on a selection of an MOP among the one or more MOPs, one or more steps defined in the selected MOP to resolve the trouble ticket.

2. The method (400) as claimed in claim 1, wherein performing the similarity matching process to identify the one or more previously resolved trouble tickets comprises: comparing the one or more attributes of the received trouble ticket with one or more attributes of a plurality of previously resolved trouble tickets stored in the historical ticket database (120); identifying, for each of the plurality of previously resolved trouble tickets based on the comparison, a similarity score between the received trouble ticket and the plurality of previously resolved trouble tickets; and identifying the one or more previously resolved trouble tickets among the plurality of previously resolved trouble tickets that have the similarity score greater than a threshold.

3. The method (400) as claimed in claim 1, wherein the one or more attributes of the received trouble ticket include a description of a problem, one or moreinformation associated with a user, information of trouble environment and related resources, characteristic issues associated with the trouble ticket, and operating conditions associated with the trouble environment.

4. The method (400) as claimed in claim 2, wherein the one or more attributes of each of the plurality of previously resolved trouble tickets include at least one of a closure code, a problem type, and a cause code associated with a corresponding trouble ticket among the plurality of previously resolved trouble tickets.

5. The method (400) as claimed in claim 1, wherein the displaying the autoresolution option includes displaying the one or more MOPs and one or more information associated with each MOP of the one or more MOPs, wherein the one or more information includes metadata and a success resolution ratio of each MOP.

6. The method (400) as claimed in claim 1, comprising displaying, along with the auto-resolution option, a manual option to select manual resolution of the trouble ticket.

7. The method (400) as claimed in claim 6, comprising: receiving, by the receiving engine (220) upon completion of the manual resolution of the trouble ticket, information of a closure code, a cause code and a problem type selected by a user; capturing, by an MOP capturing engine (270) based on the received information, the one or more steps performed by the user to resolve the trouble ticket; and storing, by the MOP capturing engine (270), the captured one or more steps as a new MOP in the historical ticket database (120).

8. The method (400) as claimed in claim 1, comprising: capturing, by a MOP capturing engine (270), the one or more steps executed to resolve the trouble ticket; andstoring, by the MOP capturing engine (270), the one or more steps as a new MOP in the historical ticket database based on a closure code of the trouble ticket indicating that the trouble ticket is resolved.

9. The method (400) as claimed in claim 1, comprising: analyzing, by a data analysis engine (280), a plurality of previously resolved trouble tickets to identify a closure code, a cause code, and a problem type for each of the plurality of previously resolved trouble tickets; and grouping, by the data analysis engine (280), the plurality of previously resolved trouble tickets in one or more groups based on the analysis, wherein the one or more previously resolved trouble tickets are identified from a same group among the one or more groups.

10. A system (200) for resolving a trouble ticket, the system (200) comprising: a receiving engine (220) configured to receive via a User Interface (UI) (130) of a User Equipment (UE) (104), the trouble ticket including one or more attributes; a ticket processing engine (230) configured to: perform a similarity matching process to identify one or more previously resolved trouble tickets from a historical ticket database similar to the received trouble ticket; a retrieving engine (240) configured to retrieve from the historical ticket database (120), one or more Method of Procedures (MOPs) corresponding to the identified one or more previously resolved trouble tickets; a suggestion engine (250) configured to display an auto-resolution option on the UI (130) based on the retrieved one or more MOPs; and an auto resolution execution engine (260) configured to execute based on a selection of an MOP among the one or more MOPs, one or more steps defined in the selected MOP to resolve the trouble ticket.

11. The system (200) as claimed in claim 10, wherein, to perform the similarity matching process to identify the one or more previously resolved trouble tickets, the ticket processing engine (230) is configured to:compare the one or more attributes of the received trouble ticket with one or more attributes of a plurality of previously resolved trouble tickets stored in the historical ticket database (120); identify, for each of the plurality of previously resolved trouble tickets based on the comparison, a similarity score between the received trouble ticket and the plurality of previously resolved trouble tickets; and identify the one or more previously resolved trouble tickets among the plurality of previously resolved trouble tickets that have the similarity score greater than a threshold.

12. The system (200) as claimed in claim 10, wherein the one or more attributes of the received trouble ticket include a description of a problem, one or more information associated with a user, information of trouble environment and related resources, characteristic issues associated with the trouble ticket, and operating conditions associated with the trouble environment.

13. The system (200) as claimed in claim 11, wherein the one or more attributes of each of the plurality of previously resolved trouble tickets include at least one of a closure code, a problem type, and a cause code associated with a corresponding trouble ticket among the plurality of previously resolved trouble tickets.

14. The system (200) as claimed in claim 10, wherein, to display the autoresolution option, the suggestion engine (250) is configured to display the one or more MOPs and one or more information associated with each MOP of the one or more MOPs, wherein the one or more information includes metadata and a success resolution ratio of each MOP.

15. The system (200) as claimed in claim 10, comprising displaying, along with the auto-resolution option, a manual option to select manual resolution of the trouble ticket.

16. The system (200) as claimed in claim 15, wherein:the receiving engine (220) is configured to receive, upon completion of the manual resolution of the trouble ticket, information of a closure code, a cause code, and a problem type selected by a user; and an MOP capturing engine (270) is configured to: capture, based on the received information, the one or more steps performed by the user to resolve the trouble ticket; and store the captured one or more steps as a new MOP in the historical ticket database.

17. The system (200) as claimed in claim 10, comprising an MOP capturing engine (270) configured to: capture the one or more steps executed to resolve the trouble ticket; and store the one or more steps as a new MOP in the historical ticket database based on a closure code of the trouble ticket indicating that the trouble ticket is resolved.

18. The system (200) as claimed in claim 10, comprising a data analysis engine (280) configured to: analyze a plurality of previously resolved trouble tickets to identify a closure code, a cause code, and a problem type for each of the plurality of previously resolved trouble tickets; and group the plurality of previously resolved trouble tickets in one or more groups based on the analysis, wherein the one or more previously resolved trouble tickets are identified from a same group among the one or more groups.

19. A computer program product comprising computer-executable instructions that are stored on a non-transitory computer-readable medium and that, when executed by at least one processor performs operations comprising: receiving, via a User Interface (UI) (130) of a User Equipment (UE) (104), trouble ticket including one or more attributes;performing a similarity matching process to identify one or more previously resolved trouble tickets from a historical ticket database (120) similar to the received trouble ticket; retrieving, from the historical ticket database (120), one or more Method of Procedures (MOPs) corresponding to the identified one or more previously resolved trouble tickets; displaying an auto-resolution option on the UI (130) based on the retrieved one or more MOPs; and executing, based on a selection of an MOP among the one or more MOPs, one or more steps defined in the selected MOP to resolve the trouble ticket.

Images