Sign In to Follow Application
View All Documents & Correspondence

System And Method For Notifying Trouble Tickets In An Enterprise Social Network

Abstract: System and method for notifying incident/service/trouble tickets in an enterprise social network is described. The system and method comprises of registering at least one application and at least one agent on the enterprise social network, subscribing the at least one agent to the at least one application and/or to the at least one agent, assigning and notifying incident/service ticket/trouble ticket of the at least one application to the at least one agent by an administrator, analyzing and altering status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent subscribed to the at least one application in the enterprise social network, updating the altered status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent to the administrator, and viewing the updates by the at least one agent subscribed to the at least one application and/or to the at least one agent.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
19 April 2010
Publication Number
25/2010
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application

Applicants

HCL Technologies Ltd.
184 NSK Salai (Arcot Road) Vadapalani,  Chennai.

Inventors

1. Joseph CT
No. 8  MTH Road,  Ambattur Industrial Estate,  Chennai- 58.
2. Deepa Masilamani
No. 8  MTH Road  Ambattur Industrial Estate  Chennai- 58

Specification

FORM-2
THE PATENTS ACT, 1970
(39 OF 1970)
AND
THE PATENTS RULES, 2003
(As Amended)
COMPLETE SPECIFICATION (See section 10; rule 13)
"System and Method for Notifying Trouble Tickets in an Enterprise Social Network"
HCL Technologies Ltd., a corporation organized and existing under the laws of India, of 184 NSK Salai (Arcot Road) Vadapalani, Chennai - 600 026 Tamil Nadu India.
The following specification particularly describes the invention and the manner in which it is to be performed :

Technical Field
The present invention relates to system and method for notifying incident/service/trouble tickets and more particularly for notifying trouble tickets using enterprise social network platform in service organizations.
Background
Telecommunications companies are typically run under tight regulation by federal and state agencies. These regulations affect many details of the telecommunications business, from inventory to customer service. Typically the regulations relate to taxes, competition, repairs, etc. and are punishable by fines and other penalties.
One area of regulation in customer service relates to trouble ticket handling. Ticket Life cycle management (TLCM) process is applicable to any service industry. Traditionally trouble/incident ticket or service request notifications are given to service desk teams whenever a trouble ticket is raised though E-mail or SMS. Trouble tickets typically occur when a customer calls in to a business repair center (BRC) and places a service request. In particular the federal communication commission and state public service commissions typically require these trouble tickets to be closed within a certain period of time. Typically, the agencies require a telecommunication company to report the resolution of these trouble tickets as an average period of pendency for open trouble tickets. This average is typically calculated monthly, and fines can be levied by federal and state agencies when the average pendency of trouble tickets exceeds a certain threshold. The thresholds and fines are typically set by each state's public service commission.

Further, the trouble tickets in a business critical environment can be effectively handled using an enterprise social network platform that can be used to post the status of an applications and incidents related to them to respective users (Agents) and also helps in collaboration.
There are various systems and methods devised for handling trouble tickets in telecommunication companies and service organizations.
US 7366731 disclose a trouble ticket handling system. The system typically includes a login logic, a monitoring device, and a user interface logic. The login logic typically operates to log a user into several trouble ticket systems. The monitoring device typically polls the trouble ticket systems for open trouble tickets. The user interface logic enables the user to automatically load a proper trouble ticket from any of the open trouble tickets in the trouble ticket systems. Methods and other systems are also provided.
US 2006/0149729 discloses a system and method for monitoring availability of applications. According to an embodiment of the invention, a method includes providing a set of monitoring instructions to an agent, with the set of monitoring instructions including a time stamp and the set of monitoring instructions regarding monitoring of the availability of applications. The method includes receiving a status inquiry from the agent, the inquiry including the time stamp, comparing the time stamp received from the agent to a time stamp for up-to-date monitoring instructions, and sending the up-to-date monitoring instructions to the agent if the time stamp of the up-to-date monitoring instructions is later than the time stamp received from the agent.

Above-mentioned system and method do not provide social networks for handling trouble tickets.
However, there is a solution provided for handling trouble tickets in a social networking community which is explained below.
Vertical Solutions integrates with Palantiri, Bringing Social Collaboration to Powerhelp Service Management Software. The Palantiri solution is a web-based solution, which enable it to integrate with any existing enterprise application.
Palantiri solution enables intelligent devices to participate directly in a social networking-style community. The integration of PowerHelp system with Palantiri help the companies or enterprises to enhance their device blogs to forward information on service and maintenance requirements and to automatically initiate trouble tickets. The integration enables companies to gather valuable data on devices, including usage statistics and maintenance information, directly into their PowerHelp knowledgebase without human data entiy. The customers are benefited from community style social networking, real time device interaction, and integration with enterprise applications such as PowerHelp to provide context-based knowledge sharing in order to improve their service operations and truly engage their customer base.
The integration of PowerHelp and Palantiri operate as follows:
A device submits a blog post about a fault condition, which can be forwarded on to those participating in the collaborative network, with that post automatically generating a trouble ticket in PowerHelp. A service technician can access the device information, bring up its history via PowerHelp, and even start a direct chat session with the device to remotely diagnose and potentially resolve the call, all

within a single view in the Palantiri dashboard. Service techs can also use the Palantiri dashboard to view all calls assigned to them, service managers can use the software to create a "tag cloud" of expertise, which helps to identify the service technicians that are experts on a particular product or platform.
The above-mentioned prior art focuses more on device centric community as opposed on agents collaboration. It is through blog that devices share their status, history and knowledge. A service technician continuously chats with the device to check status and run diagnostic routines and not with the other agents. There is no automatic post from device and there is no administrator that posts the ticket on the application. The service managers can use the software to create a tag cloud of expertise which helps to identify the agents that are experts as there is no collaboration between service technicians. The agents use the Palantiri dashboard to view all calls assigned to them as they do not get updates from an application since they are not subscribed to the application. The solution provided by Palantiri system is something that can be integrated with a trouble ticket system and not a trouble ticket system itself. The logic of identifying the Right agents is out of scope in said Palantiri system.
Hence, there is a need of a system and method that employs enterprise social network since it offers collaborative environment where users can participate to handle trouble tickets in a business critical environments.
Objects and Summary
The object of the present invention is to provide a system and method for notifying trouble tickets in service organizations.

It is an object of the present invention to provide a system and method for notifying trouble tickets using enterprise social network in service organizations.
It is another object of the present invention to facilitate the collaboration of agents/agents using enterprise social network to handle the trouble tickets running in a business critical environment.
Further object of the present invention is to provide regular updates of the trouble tickets to the agents subscribed to an application and to the other agents in the enterprise social network.
Yet another object of the present invention is to ensure faster response in addressing the trouble tickets.
It is also an object of the present invention to ensure better coordination and communication between all agents and administrator in a service organization.
To achieve the aforementioned objects, the present invention provides a method for notification of trouble tickets in an enterprise social network comprising the steps of:
• registering at least one application and at least one agent on the enterprise social network;
• subscribing the at least one agent to the at least one application and/or to the at least one agent;
• assigning and notifying incident/service ticket/trouble ticket of the at least one application to the at least one agent by an administrator;
• analyzing and altering status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent subscribed to the at least one application in the enterprise social network;

• updating the altered status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent to the administrator; and
• viewing the updates by the at least one agent subscribed to the at least one application and/or to the at least one agent.
The present invention further provides a system for notifying trouble tickets in an enterprise social network comprising:
• means (102) for registering at least one application and at least one agent on the enterprise social network (106);
• means (202) for subscribing the at least one agent to the at least one application and/or to the at least one agent;
• means (102) for assigning and notifying incident/service ticket/trouble ticket of the at least one application to the at least one agent by an administrator;
• means (212) for analyzing and altering status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent subscribed to the at least one application in the enterprise social network;
• means (202) for updating the altered status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent to the administrator; and
• means (206) for viewing the updates by the at least one agent subscribed to the at least one application and/or to the at least one agent.
Brief Description of the Drawings
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in

which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
Fig. 1 is an exemplary system illustrating the components of trouble ticket notification system in an enterprise social network according to the present invention.
Fig. 2 is a block diagram illustrating the architecture of a computer system of the agents according to the present invention.
Fig. 3 is an exemplary sequence diagram illustrating two different scenarios where the updates on the trouble tickets are viewed by all the agents subscribe to the application according to the present invention.
Fig. 4 is an exemplary flow chart illustrating the method of notifying trouble tickets in the enterprise social network according to the present invention.
Detailed Description
System and method for notifying incident/service/trouble tickets in an enterprise social network is described. The system and method is not intended to be restricted to any particular form or arrangement, or any specific embodiment, or any specific use, disclosed herein, since the same may be modified in various particulars or relations without departing from the spirit or scope of the claimed invention herein shown and described of which the system and/or method shown is intended only for illustration and disclosure of an operative embodiment and not to show all of the various forms or modifications in which this invention might be embodied or operated.

A trouble ticket (sometimes called a trouble report) is a mechanism used in an organization to track the detection, reporting, and resolution of some type of problem. The trouble ticket consists of one or more messages arranged in chronological order. Each message represents a note posted by a customer or service desk personnel.
The instant invention provides a system and method for notifying trouble tickets using enterprise social network platform in service organizations. The instant invention provides for incident ticket/service request notifications for application self status and delivering to service desk teams on to their social network clients, through an enterprise social network platform in a service model. There is an administrator on the enterprise social network who can create/raise incident/service ticket for a particular application. Whenever a ticket is created by the administrator it is updated on the particular application. The administrator uses some business logic to choose the right agents to work on the incident/service ticket or can assign to a group who handle all the tickets of application. Each application and service desk personnel create a dedicated account on the enterprise social network. The service desk personnel subscribe to the application for which they need to see the status and can also subscribe to the other agents in the social network. The agents collaborate using the enterprise network on the analysis of the incident ticket. The application transmits its status/incident status to all the agents subscribed to that application, as short messages. The updates are refreshed when new update is created. The agents who have subscribed to the respective application and the other agents get the update. The agents can change the status of the incident ticket when are sent as updates. The administrator receives all the messages posted by agents and updates the status accordingly. The status change can be pending, closed, analysis etc. Once the ticket is closed it also gets updated. These updates are stored in the backend ticket server database.

The techniques described herein may be used in many different operating environments and systems. An exemplary environment that is suitable for practicing various implementations is discussed in the following section with respect to the accompanying figures.
EXEMPLARY SYSTEM
Fig. 1 is an exemplary system 100 illustrating the components of trouble ticket notification system in an enterprise social network 106 according to the present invention.
System 100 comprises of an administrator 102, trouble tickets server comprising a database 104, an enterprise social network 106, pluralities of applications and agents. The administrator 102 maintains and operates the computer systems assigned to agent and/or enterprise social network 106. The administrator creates/raises trouble tickets for the applications in the enterprise social network 106. The administrator 102 uses business logic to choose the right agents to act or work on the trouble ticket or can assign to a group of agents who handles all the tickets of the application. The administrator 102 is also responsible to update the status of trouble ticket of the applications and to refresh the updates whenever new update is created or received from the agents.
The administrator is connected to a ticket server database 104 where all the trouble tickets updates are stored. The database 104 resides on storage media which can be secondary storage, magnetic storage and tertiary storage. The enterprise social network 106 comprises of social software as used in "enterprise" (business/commercial) contexts. It includes social and networked modifications to corporate intranets and other classic software platforms used by large companies

to organize their communication. The enterprise social software tends to encourage use prior to providing structure.
The system 100 also comprises pluralities of applications and agents wherein at least one application is assigned to one or more agents. The agent can also subscribe to one or more other agents. The figure illustrates different scenarios where one agent can subscribe to single application, multiple agents can subscribe to single application, one agent can subscribe to multiple applications or multiple agents can subscribe to multiple applications. The agents who have subscribed to a particular application and other agents get regular updates from that application and the other agents.
Fig. 2 is a block diagram illustrating the architecture of a computer system of a agents according to the present invention. The computer 200 includes a processor 202, memory 204, and one or more input and/or output (I/O) devices 206 (or peripherals) that are communicatively coupled via a local interface 208. The local interface 208 can be, for example one or more buses or other wired or wireless connections, as is known in the art. The local interface 208 can have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface can include address, control, and/or data connections to enable appropriate communications among the aforementioned components.
The processor 202 is a hardware device for executing software, particularly that stored in memory 204. The processor 202 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the host computer 200, a semiconductor based microprocessor (in the form of a microchip or chip set), a microprocessor, or generally any device for executing software instructions.

The memory 204 includes any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory 204 may incorporate electronic, magnetic, optical, and/or other types of storage media.
The software in memory 204 includes one or more separate programs 210, 212, each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 2, the software in the memory 204 includes a trouble ticket analysis system 212 and a suitable operating system (O/S) 210. The operating system 210 essentially controls the execution of other computer programs, such as the trouble ticket analysis system 212, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.
The trouble ticket analysis system 212 include, in various embodiments, source programs, executable program (object code), script, or any other entity comprising a set of instructions to be performed. The trouble ticket analysis systems 212 can be stored on any computer readable medium for use by or in connection with any computer related system or method. Moreover, the trouble ticket analysis system 212 can interact with a storage device 214 to store and retrieve information used in conjunction with the system 210. The GUI for the trouble ticket analysis system 212 includes a button representation (not shown) allowing the technician to select the button representation to automatically load a trouble ticket.
The I/O devices 206 preferably include input devices, for example, a keyboard, mouse, scanner, microphone, etc. Furthermore, the I/O devices 220 preferably include output devices, for example, a printer, display, etc. Finally, the I/O devices

220 further preferably include devices that communicate both inputs and outputs, for instance, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc.
Fig. 3 is an exemplary sequence diagram illustrating two different scenarios where the updates on the trouble tickets are viewed by all the agents subscribe to the application.
The first scenario is when a trouble ticket is raised on an application X. The update of the ticket is viewed by agents A and B who have subscribed to it and also to the administrator. The enterprise social network 106 comprises an administrator 102, ticket server database 104, application X and two agents A and B. The administrator 102 subscribes to application X and agents A and B. Agent B subscribes to both application X and agent A. The administrator 102 creates a trouble ticket for A and it is sent as update to agents A and B. The ticket is analyzed by both agents A and B and agent A change the status of the trouble ticket (of application X) to pending that is sent as an update and is viewed as update by the administrator 102 and by agent B. Similarly, when the agent A change the status of the trouble ticket (of application X) to completed, it is sent as an updates and is viewed by the administrator 102 and agent B.
The second scenario is when a critical event occurs in the application X, it is sent as update to the administrator 102, agents A and B who have subscribed to the application.
EXEMPLARY METHOD

Fig. 4 is an exemplary flow chart illustrating the method of notifying trouble tickets in the enterprise social network. The method is illustrated as a collection of steps in a logical flow graph, which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. The order in which the process is described is not intended to be construed as a limitation, and any number of the described steps can be combined in any order to implement the process, or an alternate process. Additionally, individual steps may be deleted from the process without departing from the spirit and scope of the subject matter described herein.
At block 402, at least one application and at least one agent register on the
enterprise social network by creating a dedicated account on the network.
At block 404, the agents subscribes to the application and to at least one agent
which comprises of multiple options wherein one agent can subscribe to single
application, multiple agents can subscribe to single application, one agent can
subscribe to multiple applications and multiple agents can subscribe to multiple
applications.
At block 406, the trouble tickets on the at least one application is assigned and
notified to at least one agent.
At block 408, the agents analyze and alter the status of the trouble tickets.
At block 410, the altered status of the trouble ticket is sent as updates to the
administrator in the enterprise social network.
At block 412, the updates are also viewed by the other agents who have subscribed
to the at least one application and to the at least one agent.
The embodiments described above and illustrated in the figures are presented by way of example only and are not intended as a limitation upon the concepts and principles of the present invention. Elements and components described herein may be further divided into additional components or joined together to form

fewer components for performing the same functions. As such, it will be appreciated by one having ordinary skill in the art that various changes in the elements and their configuration and arrangement are possible without departing from the spirit and scope of the present invention as set forth in the appended claims.

Claim:
1. A method for notification of trouble tickets in an enterprise social network
comprising the steps of:
• registering at least one application and at least one agent on the enterprise social network;
• subscribing the at least one agent to the at least one application and/or to the at least one agent;
• assigning and notifying incident/service ticket/trouble ticket of the at least one application to the at least one agent by an administrator;
• analyzing and altering status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent subscribed to the at least one application in the enterprise social network;
• updating the altered status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent to the administrator; and
• viewing the updates by the at least one agent subscribed to the at least one application and/or to the at least one agent.
2. The method as claimed in claim 1, wherein the step of subscribing
comprises one or more of the following:
i. One agent subscribe to single application ii. Multiple agents subscribe to single application iii. One agent subscribe to multiple applications iv. Multiple agents subscribe to multiple applications
3. The method as claimed in claim 1, wherein the agents collaborate and
communicate using the enterprise social network for analyzing
incident/service ticket/trouble ticket.

4. The method as claimed in claim 1, wherein the status change of the incident/service ticket/trouble ticket is pending or open or closed or resolved.
5. The method as claimed in claim 1, wherein the administrator update the status of the incident/service ticket/trouble ticket in a database on receiving the updated status from the at least one agent.
6. A system for notifying trouble tickets in an enterprise social network comprising:

• means (102) for registering at least one application and at least one agent on the enterprise social network (106);
• means (202) for subscribing the at least one agent to the at least one application and/or to the at least one agent;
• means (102) for assigning and notifying incident/service ticket/trouble ticket of the at least one application to the at least one agent by an administrator;
• means (212) for analyzing and altering status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent subscribed to the at least one application in the enterprise social network;
• means (202) for updating the altered status of the incident/service ticket/trouble ticket of the at least one application by the at least one agent to the administrator; and
• means (206) for viewing the updates by the at least one agent subscribed to the at least one application and/or to the at least one agent.
7. The system as claimed in claim 6, wherein the subscribing means
comprises one or more of the following:
i. One agent subscribe to single application

ii. Multiple agents subscribe to single application iii. One agent subscribe to multiple applications iv. Multiple agents subscribe to multiple applications
8. The system as claimed in claim 6, wherein the agents collaborate and communicate using the enterprise social network for analyzing incident/service ticket/trouble ticket.
9. The system as claimed in claim 6, wherein the status change of the incident/service ticket/trouble ticket is pending or open or closed or resolved.
10. The system as claimed in claim 6, wherein the administrator update the status of the incident/service ticket/trouble ticket in a database on receiving the updated status from the at least one agent.
11. A computer program product for notifying trouble tickets in an enterprise social network, comprising one or more computer readable media configured to perform said method.

Dated this 19f!l day of April 2010

Of Anand and Anand Advocates Agents for the Applicant

Documents

Application Documents

# Name Date
1 1096-CHE-2010 POWER OF ATTORNEY 19-05-2010.pdf 2010-05-19
1 1096-CHE-2010-AbandonedLetter.pdf 2017-09-01
2 1096-CHE-2010-FER.pdf 2017-02-27
2 1096-CHE-2010 FORM-9 21-05-2010.pdf 2010-05-21
3 1096-CHE-2010 FORM-18 18-08-2010.pdf 2010-08-18
3 1096-CHE-2010 CORRESPONDENCE OTHERS 28-12-2011.pdf 2011-12-28
4 Form-3.pdf 2011-09-03
4 1096-CHE-2010 OTHER PATENT DOCUMET 28-12-2011.pdf 2011-12-28
5 1096-CHE-2010 CORRESPONDENCE OTHERS 14-12-2011.pdf 2011-12-14
5 Form-1.pdf 2011-09-03
6 1096-CHE-2010 FORM-1 14-12-2011.pdf 2011-12-14
6 1096-CHE-2010 POWER OF ATTORNEY 14-12-2011.pdf 2011-12-14
7 1096-CHE-2010 FORM-1 14-12-2011.pdf 2011-12-14
7 1096-CHE-2010 POWER OF ATTORNEY 14-12-2011.pdf 2011-12-14
8 1096-CHE-2010 CORRESPONDENCE OTHERS 14-12-2011.pdf 2011-12-14
8 Form-1.pdf 2011-09-03
9 1096-CHE-2010 OTHER PATENT DOCUMET 28-12-2011.pdf 2011-12-28
9 Form-3.pdf 2011-09-03
10 1096-CHE-2010 FORM-18 18-08-2010.pdf 2010-08-18
10 1096-CHE-2010 CORRESPONDENCE OTHERS 28-12-2011.pdf 2011-12-28
11 1096-CHE-2010-FER.pdf 2017-02-27
11 1096-CHE-2010 FORM-9 21-05-2010.pdf 2010-05-21
12 1096-CHE-2010-AbandonedLetter.pdf 2017-09-01
12 1096-CHE-2010 POWER OF ATTORNEY 19-05-2010.pdf 2010-05-19

Search Strategy

1 1096-CHE-2010___14-02-2017.pdf