DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is a non-final rejection in response to amendments/remarks filed on 01/20/2026. Claims 1-3, 5-6, 12, 14, 16, 17 and 20 are amended. New claims 21-24 have been added. Claims 1-3, 5-14, and 16-24 are currently pending and are examined herein.
Priority
The effective priority date of the claims is the filing date of the present disclosure, 05/04/2023.
Claim Rejections – 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5-14, and 16-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Is the claim to a Process, Machine, Manufacture, or Composition of Matter?
Claims 1-3, 5-11, 21-23: A method comprising
Claims 12-14, 16-19: A system comprising: one or more processors; and a memory coupled to the one or more processors, wherein the memory is configured to provide the one or more processors with instructions which when executed cause the one or more processors to:
Claim 20: A computer program product, the computer program product being embodied in a non- transitory computer readable storage medium and comprising computer instructions for:
Claim 24: A method comprising:
Step 2a Prong 1: Is the claim reciting a Judicial Exception (A Law of Nature, a Natural Phenomenon (Product of Nature), or An Abstract Idea?)
The claims under the broadest reasonable interpretation in light of the specification are analyzed herein. Representative claims 1, 12, 20, and 24 are marked up, isolating the abstract idea from additional elements, wherein the abstract idea is set in bold and the additional elements have been italicized as follows:
Claims 1: A method comprising
Claims 12: A system comprising: one or more processors; and a memory coupled to the one or more processors, wherein the memory is configured to provide the one or more processors with instructions which when executed cause the one or more processors to:
Claim 20: A computer program product, the computer program product being embodied in a non- transitory computer readable storage medium and comprising computer instructions for:
Claim 1 Body (also representative of claims 12, 20) :
Providing, to an analysis service in communication with a network, a user interface to manage an information technology incident detected in the network and identified with an incident ticket;
Retrieving performance data related to at least one device identified as part of the incident ticket, wherein the at least one device was impacted by the information technology incident
Identifying, by the analysis service, one or more candidate factors based on performance data and a first candidate factor of the one or more candidate factors provided via the user interface, wherein the one or more candidate factors correspond to a potential cause of the incident or tasks related to the incident;
Receiving, by the analysis service, a request to perform a root cause analysis associated with the incident;
And in response to receiving the request, providing, by the user interface of the analysis service, at least one of the one or more candidate factors as a cause and effect element of the root cause analysis
Generating, by the analysis service, an incident timeline as part of a visual representation of the incident, wherein the incident timeline includes at least one event leading up to the information technology incident, and wherein the visual representation specifies one or more nodes corresponding to the cause and effect element associated with the at least one device impacted by the information technology incident.
(New) Claim 24: A method comprising:
receiving, at an analysis service, an incident ticket reflecting an information technology incident detected in a network;
retrieving, by the analysis service, performance data related to a device impacted by the information technology incident and identified in the incident ticket;
identifying, by the analysis service utilizing the performance data, a plurality of candidate factors including a first candidate factor of the plurality of candidate factors, wherein each of the plurality of candidate factors corresponds to a potential cause of the information technology incident;
generating, by the analysis service, an incident timeline as part of a visual representation of the incident, wherein the incident timeline includes at least one event leading up to the information technology incident, and wherein the visual representation specifies one or more nodes corresponding to a cause and effect element associated with the device impacted by the information technology incident; and
establishing, by the analysis service, a workspace for collaboration based on the cause and effect element, wherein the workspace incorporates at least one member identified as part of the incident timeline.
When evaluating the bolded limitations of the claims under the broadest reasonable interpretation in light of the specification, it is clear that representative claims 1, 12, and 20 recite an abstract idea under the category of “certain methods of organizing human activity,” as outlined in MPEP 2106.04(a)(2)(II). More specifically, the claims in bold recite “managing personal behavior or relationships or interactions between people,” including social activities, teaching and following rules or instructions. In this case, the claims are data collection, data processing, and data output steps which result in the teaching and following rules or instructions to manage a user’s personal behavior. For example, in the current scope of the plain claim language, the claims provide an analysis service, which identifies candidate factors based on performance data, and outputs the candidate factors to the user to help manage the incident. The scope of analysis service is not merely limited to “computer based” embodiments and merely describes the intended result of generating potential causes related to an incident. Even when read in the context of the specification, the claims do not reasonably exclude “management of personal behavior, relationships or interactions between people,” especially when reading [0022] of the specification which states,
“[0022] The disclosed incident root cause analysis platform and service provide an
integrated workflow that allows the ITSM group to seamlessly transition from an incident workflow focused on resolving an incident to a root cause analysis workflow for analyzing and resolving the root cause of the incident. For example, as part of the incident workflow, a collaborative root cause analysis workspace is created that is automatically populated with the relevant context of the incident such as an automatically generated timeline of the incident (as well as related tasks), potential cause and effect elements related to the incident, and/or previously determined root cause analysis results, among other helpful contextual information. Additional members can be further invited to the workspace to collaborate in the root cause analysis including by automatically identifying members from previously related incident records. For example, other service members that addressed similar incidents can be invited to join the root cause analysis workflow.”
Therefore, the claims are seemingly a collaborative workspace to facilitate interactions between people towards solving an incident. The fact that the incident is a “information technology incident detected in a network” is merely nonfunctional descriptive material as it merely conveys meaning to the human reader rather than towards establishing a functional relationship between recorded data and the computer. (See MPEP 2111.05). Since there is no positively recited step pertaining to how an information technology incident is detected in the network, it is merely describing the type of data being displayed to the user in order to be managed. MPEP 2111.05 states: “However, where the claim as a whole is directed to conveying a message or meaning to a human reader independent of the intended computer system, and/or the computer-readable medium merely serves as a support for information or data, no functional relationship exists.”
Therefore, the manage an information technology incident detected in the network is merely part of the abstract idea, because the claims do not positively recite the detection of the incident, but merely indicate that the type of data being reviewed is information technology incidents that have been detected in the network. In summary, the claims recite the abstract idea steps of “managing an incident ticket, retrieving performance data related to the incident, identifying candidate factors based on the performance data, performing a root cause analysis, generating an incident timeline of events leading up to the incident, and (in claim 24) establishing a workspace for collaboration” wherein the steps are recited with such generality that they are no more than mere instructions to manage personal behavior, and facilitate interactions between users in the form of a collaborative workspace. The fact that the interactions occur between an individual and a computer does not preclude them from reciting “certain methods of organizing human activity,” as MPEP 2106.04(a)(2)(II) explicitly states, “Finally, the sub-groupings encompass both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the "certain methods of organizing human activity" grouping.” Therefore, the claims recite at least one abstract idea under “certain methods of organizing human activity.”
Therefore, the claims recite at least one abstract idea and are to be further analyzed under Step 2A prong 2.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application?
The claims include the additional elements:
(a)-processors, in claim 12
(b)-memory, in claim 12
(c)-a computer program product in claim 20
(d)-non-transitory computer readable storage medium in claim 20
(e)-user interface in claims 1, 12, 20
(f)-information technology in claims 1, 12, 20, 24
(g)- network in claims 1, 12, 20, 24
(h)-at least one device in claims 1, 12, 20, 24
The additional elements (a)-(d) are no more than a recitation of the words “apply it” (or an equivalent) or mere instructions to implement an abstract idea or other exception using generic computing components as outlined in MPEP 2106.05(f). In this case the abstract idea of “managing an incident, identifying potential factors related to the incident, performing a root cause analysis, and providing the factors as a cause and effect element” is being limited to software functions performed on generic computing components such as processors, memory, network, at least one device, computer program product, and non-transitory computer readable storage medium.
The functions stated above can be carried out on existing computer long in use, with no new machinery being necessary to implement the functions as evident in the specification which states,
“[0068] As will be apparent, other computer system architectures and configurations can be utilized for performing root cause analysis for an incident. [0074] the computer-readable medium is any data storage device that can store data which can thereafter be read by a computer system.”
Therefore, no specific computing infrastructure is required to perform the functions, and the “certain method of organizing human activity” can be carried out on any generic computing device. Furthermore, the claims generally link the abstract idea to a technological environment or field of use as outlined in MPEP 2105.06(h). The claims generally link user interface technology and information technology to the abstract idea in a way that does not meaningfully limit the claim. These claims are brought in a way that amounts to merely indicating that information technology is the field in which to apply a judicial exception, by simply categorizing the “incident” as an information technology incident. Furthermore, user interfaces are implemented in a way that simply limits the abstract idea to be performed on a user interface but does not provide any improvements or innovations to the field of user interface technology itself. Please see MPEP 2106.05(a) for more information. Therefore, even when considering the claims individually, or as an ordered combination, the claims do integrate the abstract idea into a practical application.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
The same additional elements set forth in the Prong 2 rejection are also analyzed for whether they recite an inventive concept, the additional elements being repeated as follows:
(a)-processors, in claim 12
(b)-memory, in claim 12
(c)-a computer program product in claim 20
(d)-non-transitory computer readable storage medium in claim 20
(e)-user interface in claims 1, 12, 20
(f)-information technology in claims 1, 12, 20, 24
(g)- network in claims 1, 12, 20, 24
(h)-at least one device in claims 1, 12, 20, 24
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using additional elements (a-h)) amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept(See MPEP 2106.05(f)). The claims are also generally linking the abstract idea to a technological environment or field of use.(See MPEP 2106.05(g)).
Furthermore, no improvements to the processing resources have been purported, because neither the claims nor the specification provide an improved computing component performing the functions. In addition, the claims do not purport an improvement to the field of information technology, or to the field of interface technology, since they are simply being generally linked to an abstract idea. Please review MPEP 2106.05(a) for more information regarding improvements to computing devices(Section I), or technological fields(Section II). Even, when viewing the claims as a whole, nothing in the claims meaningfully limits the abstract idea in order to provide significantly more to the claims.
The dependent claims 2, 3, 5-11, and 13, 14, 16-19, and 21-24 are also given the full two-part analysis, individually and in combination with the claims they depend on, in the following analysis:
Claims 2, 3, 13, and 14 add the additional step of specifying the particular arrangement of the user interface, to include a visual representation(claims 2, 13), of the incident(claims 3, 14). Since these features further limit the additional element (user interface), then the claims recite the same abstract idea of “managing an incident, identifying potential factors related to the incident, performing a root cause analysis, and providing the factors as a cause and effect element.” As for reanalyzing these additional limitations, it is still a general link to user interface technology because it is simply using the interface as a tool to carry out economic or other tasks related to the abstract idea(an interface for displaying information). Presenting such data whether in a visual representation, or with cause and effect elements is not an improvement to the technology. Therefore, the claims are still directed to an abstract idea without integration into a practical application or significantly more.
Claims 5-7 and 16-18 further limit the claims by adding a visual representation with nodes indicating the cause and effect element that can be dragged and dropped(claim 5, 16) and where each of the nodes has a specific node type. Since drag and droppable nodes in a flowchart are still further limitations to the additional element of user interface technology, the claims recite more of the same abstract idea of “managing an incident, identifying potential factors related to the incident, performing a root cause analysis, and providing the factors as a cause and effect element.” As for reanalyzing these additional limitations, it is still a general link to user interface technology because it is simply implementing nodes as the format in which to display the abstract idea data (which is using devices in their ordinary capacity such as a display device to display data). Nodes are still a general link to user interface technology because they are known to be a feature of user interfaces, and are not an improvement to user interface technology. (Please see MPEP 2106.05(a)). Therefore, even when considering the claims as a whole, the claims are still directed to an abstract idea without integration into a practical application or significantly more.
Claims 8-10 and 19 add the additional steps of identifying collaborators associated with the incident(claim 8), providing the collaborators with access to manage the incident(claim 9), and where the interface is accessible by two or more collaborates(claim 19). When analyzed individually these claims recite an abstract idea within the category of “certain methods of organizing human activity,” particularly the subcategory “managing personal behavior or interactions between people” as outlined in MPEP 2106.04(a)(2)(II)(c). Identifying personnel and assigning them to tasks is just workforce management, widely considered to be an abstract idea. In combination with the claims they depend on, the claims recite an abstract with the steps of, “managing an incident, identifying potential factors related to the incident, performing a root cause analysis, providing the factors as a cause and effect element, identifying personnel related to the incident, and giving them permission to access the incident.” The claims repeat more of the same additional element of “user interfaces” which are still a general link to user interface technology because it merely uses known interface features to perform the abstract idea. Therefore, even when considering the claims as a whole, the claims are still directed to an abstract idea without integration into a practical application or significantly more.
Claim 11 further limits the abstract idea by adding a step of providing a timeline of the incident, and claim 21 limits the incident timeline to reflect events leading up to the incident as a time-based display. Whether analyzed individually, or in combination, this is more of the same abstract idea as the independent claim because it is merely indicating the format of the data to be displayed, whilst still performing a data analysis that is merely “managing personal behavior, interactions, or relationships.” Furthermore, there are no additional elements to consider therefore the claims are directed to an abstract idea without integration into a practical application or significantly more.
Claims 22 and 23 further limit the abstract idea because by tagging events to identify a relevant party, identify a collaborator based on the tagged events, and invite the relevant party to access the analysis service. This is more of the same abstract idea because it merely reciting “managing personal behavior, interactions, or relationships” between people, such as “identifying, and inviting” the relevant parties (individuals). The additional element of the relevant party “associated with the at least one device” is still an “apply it” level element because it is merely determining the user associated with a particular device, which cannot possibly add any improvements to computer functionality or technology. Finally, even when considered in combination with the additional elements in the independent claim, the claims fail to integrate the abstract idea into a practical application because the entire claimed computing infrastructure is no more than a general purpose computer added after the fact to the abstract idea. Even when viewed as a whole, nothing in the claims meaningfully limits the abstract idea to include significantly more.
Claim Rejections – 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 6-14, and 17-24 are rejected under 35 U.S.C. 103 as being unpatentable over Basu et al. (US 20200241949 A1) hereinafter Basu, in view of Jividen et al. (US 20230016199 A1) hereinafter Jividen.
Regarding Claims 1, 12, 20:
Basu discloses a collaborative evidence-based problem investigation and resolution platform with cause-effect user interface for facilitating determination of potential causes and solutions of new faults. Basu teaches:
Claims 1: A method comprising (Basu [0013] Various embodiments of the present disclosure provide methods and systems for collaborative evidence-based problem investigation and resolution.)
Claims 12: A system comprising: one or more processors; and a memory coupled to the one or more processors, wherein the memory is configured to provide the one or more processors with instructions which when executed cause the one or more processors to: (Basu[0015] In another embodiment, a server system is disclosed. The server system includes a memory to store instructions and a processor to execute the stored instructions in the memory and thereby cause the server system to receive data related with problems or faults that have occurred in a faulty system.)
Claim 20: A computer program product, the computer program product being embodied in a non- transitory computer readable storage medium and comprising computer instructions for: (Basu[0197] The disclosed systems and methods with reference to FIGS. 1 to 21, or one or more operations of the flowchart 1700 and the flowchart 2000 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard drives or solid-state non-volatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device).)
Claims 1, 12, 20:
-providing, to an analysis service in communication with a network, (Basu [0051] In at least one example embodiment, the supervisor devices 104a and 104b and the investigator device 108 are equipped with a collaborative problem investigation platform 116 that facilitates collaborative evidence-based problem investigation and resolution. The supervisor devices 104a and 104b and the investigator device 108 may be any communication devices having hardware components for enabling User Interfaces (UIs) of the collaborative problem investigation platform 116 to be presented on the supervisor devices 104a and 104b and the investigator device 108. The supervisor devices 104a and 104b and the investigator device 108 may be capable of being connected to a wireless communication network (such as the network 110). Examples of the supervisor devices 104a and 104b and the investigator device 108 include a mobile phone, a smart telephone, a computer,.. [0054] In an embodiment, the server 114 provides a software application, herein referred to as the collaborative problem investigation platform 116, in response to request received from the supervisor devices 104a and 104b or the investigator devices 108a to 108n (associated with the investigators 106a to 106n, respectively) via the network 110.) The broadest reasonable interpretation (BRI) of analysis service is any service that performs analysis, including both software and non-software embodiments in view of at least [0023] of the present specification. Therefore, Basu’s collaborative problem investigation platform is an example of an analysis service.
- a user interface to manage an information technology incident detected in the network and identified with an incident ticket; (Basu [0052] In at least one example embodiment, the supervisors 102a and 102b may access the collaborative problem investigation platform 116 for reviewing investigation status reports associated with a problem/fault that has occurred in a faulty system 112 and for taking decisions for resolving the problem based on the investigation status reports. The collaborative problem investigation platform 116 may enable the supervisors 102a and 102b to effectively track the status and progress of the investigation performed to determine potential causes behind the problem that has occurred in the faulty system 112. In an embodiment, the faulty system 112 is a software system. Examples of the problem/fault that can occur in the software system include, but are not limited to, website outage, failed user logins (i.e., inability to access the system), slow data entry, corrupt or invalid data, and other unexpected or undesirable occurrences such as hacker attacks by unauthorized users. In another embodiment, the faulty system 112 is a non-software system. Examples of the problem/fault that can occur in the non-software system include ... networks not transmitting data, [0055] In at least one example embodiment, the collaborative problem investigation platform 116 is configured to provide interactive visual diagrams on their interfaces, which are concurrently updatable in real time by investigators 106a to 106n to promote shared understanding among them during investigation of the problem that has occurred in the faulty system 112... In an embodiment, the evidences/symptoms are collected by monitoring tools that are monitoring the faulty system 112 and are provided to the server 114 using the network 110.) It is clear that in Basu [0052] and [0055], a user interface to manage an information technology incident (problem/fault), detected in the network (networks not transmitting data/tools monitoring the faulty system provided to the server using network 11)
-retrieving performance data related to at least one device identified as part of the incident ticket, (Basu [0069] The fault data receiving module 206 is in communication with the UI module 204 and the database 202. The fault data receiving module 206 is configured to receive data relevant for investigation of the faults that have occurred in the faulty system. The data includes monitoring data, log event data, system alerts and anomalies occurring in the faulty system. In an embodiment, the data is provided by monitoring tools that collect and continuously analyze data of the faulty system. In another embodiment, that data is automatically pulled from the faulty system by connecting the system 200 to the monitoring tools through application program interfaces (API's) [0002] They are responsible for monitoring the systems on an on-going basis as well as for promptly resolving any problems or incidents that may arise in them. The systems can be any software or non-software system including multiple complex components. The systems include, but are not limited to, computing systems, telecommunication systems, or electro-mechanical systems. See also [0052]) The BRI of “performance data” in view of specification [0051] includes, “error logs, crash reports, performance metrics, user logs, and/or usage logs, among other data.” The fault data receiving module in Basu satisfies the limitations of retrieving performance data related to at least one device impacted by the information technology incident because it receives data such as “monitoring data, log event data, system alerts and anomalies” which is mapped to the “performance data” of the present claims. This data is related to the computing systems, telecommunication systems or electro-mechanical systems which is mapped to the “at least one device.” It is clear in Basu [0052], that these systems are those that are impacted by the information technology incident.
- wherein the at least one device was impacted by the information technology incident (Basu [0052] In an embodiment, the faulty system 112 is a software system. Examples of the problem/fault that can occur in the software system include, but are not limited to, website outage, failed user logins (i.e., inability to access the system), slow data entry, corrupt or invalid data, and other unexpected or undesirable occurrences such as hacker attacks by unauthorized users. In another embodiment, the faulty system 112 is a non-software system. Examples of the problem/fault that can occur in the non-software system include automobile engine not working, aircraft not working, networks not transmitting data, machinery in a factory not working as smoothly as expected etc. [0058] In an example scenario, as shown in FIG. 1, the faulty system 112 may not be working properly because of a problem/fault that has occurred in the faulty system 112 and the supervisors 102a and 102b supervising the functioning of the faulty system 112 may have been asked to resolve the problem as soon as possible.)
-identifying, by the analysis service, one or more candidate factors based on performance data (Basu [0074] The recommendation engine 212 is in communication with the database 202, the fault analysis module 208 and the reporting module 210. The recommendation engine 212 is configured to make prescriptive recommendations for new faults using the historical data related with the resolved faults/problems stored in the database, actions facilitated by the fault analysis module 208 and the reports generated by the reporting module 210. In an embodiment, the actions facilitated by the fault analysis module 208 includes actions performed on the symptoms table, actions performed on the cause-effect graph and the actions performed on the cause-tree/fishbone diagram. The prescriptive recommendations may include one or more likely clues and their cause-effect relationships for a new fault, one or more users who are qualified to find solutions for the new fault, one or more potential causes for the new fault,) Basu’s recommendation engine (which is part of the analysis service), identifies “one or more likely clues,” and “one or more potential causes” which are examples of candidate factors, based on actions facilitated by the fault analysis module, which has been mapped to the ”performance data.”
- and a first candidate factor of the one or more candidate factors provided via the user interface,(Basu [0059] In at least one example embodiment, one or more investigators of the investigators 106a to 106n may use the symptoms table available in the collaborative problem investigation platform 116 to identify one or more clues. In an embodiment, a clue is a symptom that indicates notable event for causing the failure in the faulty system. The investigators may post the identified one or more clues on a cause-effect user interface (UI) provided on the collaborative problem investigation platform 116. The investigators may also connect the clues posted on the cause-effect user interface with causal arrows to form a cause-effect graph (shown in FIG. 5). In the cause-effect graph, nodes of the graph correspond to the clues for the problem and the clue that happened earlier in time may be connected to a clue that happened later through the directed arrow to indicate that there is a cause-effect relationship between the two clues. In an embodiment, a plurality of clues may be grouped together in a group to indicate a correlation between them. In an embodiment, the cause-effect graph with one or more directed arrows may be used to represent causality relationships between the one or more clues. In another embodiment, other representations can also be used to present causality relationships between the one or more clues.) The BRI of this limitation is that a first candidate factor is identified out of the one or more candidate factors provided on a user interface. Basu’s one or more clues is an example of a first candidate factor out of the candidate factors provided in a user interface (cause-effect user interface).
-wherein the one or more candidate factors correspond to a potential cause of the incident or tasks related to the incident; (Basu [0057] In an embodiment, the collaborative problem investigation platform 116 may enable the investigators 106a to 106n to perform exploration of potential causes that are causing a fault in the faulty system 112 in a methodical manner by creating a hierarchical cause-tree diagram. In the cause-tree diagram, the potential causes may split up recursively into sub-causes, with each cause or sub-cause having its own attributes such as name, notes, fault status etc. to enable the investigators 106a to 106n to perform systematic cause analysis of the fault that occurred in the faulty system 112. [0067] The database 202 is configured to store data related with one or more problems/faults that are investigated and solved using the system 200 or the historical data from prior problem investigations. The data includes context of each problem, one or more symptoms associated with each problem, fault analysis outcomes of each problem (e.g., the one or more potential causes responsible for causing the problem), information about users who were involved in resolving the problem and the one or more solutions that are provided by the users for resolving the problem.) Basu’s potential causes are mapped to the candidate factors of the incident, and “solutions” are mapped to tasks related to the incident.
-receiving, by the analysis service, a request to perform a root cause analysis associated with the incident; (Basu [0058] In an example scenario, as shown in FIG. 1, the faulty system 112 may not be working properly because of a problem/fault that has occurred in the faulty system 112 and the supervisors 102a and 102b supervising the functioning of the faulty system 112 may have been asked to resolve the problem as soon as possible. The supervisors 102a and 102b may then ask investigators 106a to 106n to investigate and resolve the problem. The investigators 106a to 106n may use the collaborative problem investigation platform 116 installed on the investigator devices 108a to 108n to investigate about the problem that has occurred in the faulty system 112. [0098] In an embodiment, one or more symptoms as well as an actions list may be associated to a cause of the plurality of causes to support human decision-making and evidence-based cause analysis/root cause analysis, and for self-learning to generate prescriptive recommendations for new problems.) Basu’s investigators receive a request from supervisors and the investigators initialize an analysis process that culminates with the root cause.
-And in response to receiving the request, providing, by the user interface of the analysis service, at least one of the one or more candidate factors as a cause and effect element of the root cause analysis; and. (Basu[0071] The cause-effect graph creation and managing unit 208b is in communication with the symptom table creation and managing unit 208a for extracting one or more clues that are marked in the symptoms table. The cause-effect graph creation and managing unit 208b is configured to facilitate display of a cause-effect user interface (UI) on one or more display screens of one or more electronic devices of the one or more users for facilitating creation of a cause-effect graph by the one or more users using the one or more clues marked in the symptoms table. The cause-effect graph creation and managing unit 208b is configured to facilitate concurrent updating of the cause-effect graph by at least two users of the plurality of users as per the concurrency control model provided for the cause-effect graph to generate an updated cause-effect graph. In an embodiment, the updated cause-effect graph includes an updated cause-effect relationship between the one or more clues. The cause-effect graph creation and managing unit 208b is further configured to facilitate display of the updated cause-effect graph to at least some of the one or more users.) Fig. 7A shows an example of cause and effect elements where reference numbers 708 and 710 show effect elements, and the cause elements are labeled as such.
-generating, by the analysis service, an incident timeline as part of a visual representation of the incident(Basu [0059] In at least one example embodiment, one or more investigators of the investigators 106a to 106n may use the symptoms table available in the collaborative problem investigation platform 116 to identify one or more clues. In an embodiment, a clue is a symptom that indicates notable event for causing the failure in the faulty system. The investigators may post the identified one or more clues on a cause-effect user interface (UI) provided on the collaborative problem investigation platform 116. The investigators may also connect the clues posted on the cause-effect user interface with causal arrows to form a cause-effect graph (shown in FIG. 5). In the cause-effect graph, nodes of the graph correspond to the clues for the problem and the clue that happened earlier in time may be connected to a clue that happened later through the directed arrow to indicate that there is a cause-effect relationship between the two clues. [0085] The symptoms table 300 includes one or more rows for describing the one or more symptoms that may have occurred in one or more modules of the faulty system and a plurality of columns for defining one or more details associated with each symptom. The one or more details include, but are not limited to, symptom identifier, symptom pattern, time of symptom occurrence, component at fault and symptom category. [0087] The symptom pattern field 304 represents an event that has been considered as a symptom for the fault. The time of event occurrence field 306 indicates the times at which the event has been observed. [0089] As shown in the FIG. 3, the ‘application’ module has encountered three symptoms which are identified by ‘A1’, ‘A2’ and ‘A3’, of which ‘A1’ and ‘A2’ are categorized as ‘Error’ and ‘A3’ is categorized as ‘Other’. The symptom pattern for A1 is ‘DB connection failed’. The time(s) of occurrence of the symptom is important in understanding how the events unfolded leading to the problem, and for A1 the last occurrence time is specified as ‘2018-11-15 16:09:19 UTC’. As another example, consider the last row in the symptoms table 300. A symptom identified by W2 that has been observed in the ‘web’ module, specified to be of type ‘Other’ with the event being ‘404 File not found’, happened at two different times.) In the teachings above, Basu’s cause-effect graph (show in Fig. 5) satisfies the limitation because it shows the incident as a visual representation with timestamps, and arrows that indicate the time relationship between clues.
-wherein the incident timeline includes at least one event leading up to the information technology incident, and (Basu [0059] In the cause-effect graph, nodes of the graph correspond to the clues for the problem and the clue that happened earlier in time may be connected to a clue that happened later through the directed arrow to indicate that there is a cause-effect relationship between the two clues. In an embodiment, a plurality of clues may be grouped together in a group to indicate a correlation between them. In an embodiment, the cause-effect graph with one or more directed arrows may be used to represent causality relationships between the one or more clues. In another embodiment, other representations can also be used to present causality relationships between the one or more clues. [0089] As shown in the FIG. 3, the ‘application’ module has encountered three symptoms which are identified by ‘A1’, ‘A2’ and ‘A3’, of which ‘A1’ and ‘A2’ are categorized as ‘Error’ and ‘A3’ is categorized as ‘Other’. The symptom pattern for A1 is ‘DB connection failed’. The time(s) of occurrence of the symptom is important in understanding how the events unfolded leading to the problem, and for A1 the last occurrence time is specified as ‘2018-11-15 16:09:19 UTC’. As another example, consider the last row in the symptoms table 300.) In the excerpts above, the events leading up to the incident are displayed.
- wherein the visual representation specifies one or more nodes corresponding the cause and effect element associated with the at least one device impacted by the information technology incident. (Basu [0188] At operation 2008, the method 2000 includes causing, by the processor, provisioning of a cause-effect user interface (UI) on one or more display screens of one or more electronic devices of the one or more users for facilitating creation of a cause-effect graph using the one or more clues. The cause-effect graph is used by the plurality of users to concurrently analyze the cause-effect relationships between the one or more clues. A ‘how’ aspect of the problem is defined using the cause-effect graph i.e. how the problem happened by determining the cause-effect relationships among the symptoms seen. In an embodiment, the one or more clues are pinned on the provided cause-effect user interface to create the cause-effect graph. In another embodiment, the one or more clues may be grouped together to indicate correlation of the one or more symptoms. The one or more clues or groups of clues are connected with causal arrows to show ‘how’ the events unfolded. [0130] FIG. 12 is an example representation of a fishbone diagram 1200 displayed to the users (e.g., the investigators 106a to 106n) on their electronic devices while performing problem investigation using the collaborative problem investigation platform 116, in accordance with another example embodiment... [0138] The concurrent operations that can be performed on or interact with the cause-effect graph include: [0139] pinning a symptom on the cause-effect graph, which creates a node in the graph for the symptom [0140] unpinning a symptom/clue, which removes the node for that symptom from the graph [0141] connecting a pair of symptoms/clues on the graph with cause-effect arrows to indicate causality [0142] disconnecting a pair of symptoms/clues on the cause-effect graph that are connected [0143] grouping a set of symptoms/clues on the cause-effect graph to indicate correlation [0144] ungrouping a set of previously grouped symptoms/clues on the cause-effect graph [0145] deleting a symptom pinned on the cause-effect graph from the symptoms table, which also causes the node for the symptom to be deleted from the cause-effect graph.) The fishbone diagram of Fig. 12 is an example of generating a visual flow diagram of the incident, specifying nodes [0138] reflecting the cause and effect element. Since this visual flow diagram pertains to a particular faulty system, which includes devices impacted by the incident, then the limitation has been satisfied. The cause-effect graph specifies nodes which corresponds the symptoms (effect), with the clues (cause).
However, Basu fails to teach:
-that the “information technology incident detected in the network” is identified with an incident ticket; (In fact, Basu specifically recites the features as an improvement over incident ticketing systems, “[0007] issue tracking/ticketing system such as JIRA™, Remedy™ or ServiceNow™. There is often an overload of text-based information, e.g., 10 people working together on a problem could easily generate 100 messages or updates in 1-2 days.”)
-that the device in which performance data was retrieved is “identified as part of the incident ticket,”
However, Jividen discloses a root cause detection of anomalous behavior in a networked computing environment, in which incident tickets are automatically opened in response to the detection of anomalous event and sent to the appropriate persons for resolution. Jividen suggests:
-that the “information technology incident detected in the network” is identified with an incident ticket; (Jividen [0031] This number may be compared to a threshold number or a threshold percentage to determine if the anomalous event (successfully resolved) is occurring on a frequent enough basis (e.g., execution of a program on a server fails during 95% of attempts over a predefined period of time) to provoke an incident ticket (i e, a support ticket), troubleshooting, or further review by a user. In one example, an incident ticket is filed by a user of the system in response to a hardware or software failure (e.g., an application failure, process failure, server failure, etc.). In another example, the incident ticket is automatically generated by the system. It is appreciated that the term “failure” within the context of this disclosure is not limited to a complete failure of software or hardware, but also to partial failure or any type of performance, problem, error or activity issue with the software or hardware, including applications, components, code, data, etc. associated therewith. [0049] Once a root cause of the anomalous event has been identified, an incident (or support) ticket generated by the incident ticket generator 220 may be sent to the nodes identified as the root cause of the anomalous event, at operation 310.)
-that the device in which performance data was retrieved is “identified as part of the incident ticket,”(Jividen [0038] The incident ticket generator 222 may generate and transmit a report to a user of the report based on an identified chain of failures. In one example embodiment, the incident ticket generator 222 may identify a role associated with a user and output an incident report or ticket to the user based on the user's role. For example, the role of the user may be determined based on a username, an employee identification number, or an email address associated with the user. In one example, a person with a technical role within an insurance organization may receive a report with technical information (e.g., server utilization information). While a person with a non-technical role within the insurance organization may receive a report with business-focused information (e.g., the number of people who can currently connect to a particular application or the estimated downtime for the particular application). [0031] The location component 206, when executed the processor(s) 116, causes the processor(s) 116 to identify at least one of the event groups having at least one of the events assigned thereto with a status 212 indicating failure of a process or component identified by the process and component identifier 214 of the at least one event.) Jividen’s component identifier is an example of a device identified as part of the incident ticket.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the present disclosure to modify Basu with the teachings of Jividen by adding the features of identifying the incidents with incident tickets. By simply adding Jividen’s incident tickets to the detection of Basu’s incidents one would reasonably have expected to arrive at the claimed limitations, as the modification would have been obvious to try. Furthermore, one of ordinary skill in the art would have been motivated to add Jividen’s teachings as it would yield the benefit of adding precision and reducing false alarms if the event can be self-resolved, ultimately reducing the volume of incident tickets. (Jividen [0002] Some existing systems detect errors in a process by assuming that a first or last error event that occurs during an analysis window execution of the process is the root cause. However, this approach lacks precision and may produce false alarms (e.g., if the error event is not severe, is only temporary, or if the event self-resolves). [0004] In one example, the system, device and techniques described herein allow for a configurable multi-cycle correlation and enrichment based on multiple data sources (e.g., configuration, transaction ID, etc.) and key/value pairs. Additionally, configuration and topology data may be correlated to account for multi-tiered relationships between configuration items in a node, including recognition of neighboring relationships that are not a reason to correlate (i.e., false positive avoidance). Moreover, based on the alerts and related dependency chains, machine learning algorithms may determine the probable root cause of the anomalous event and open the incident tickets to the appropriate persons or entities for resolution. The incident tickets may be sent to persons or entities of a node responsible for resolution of the anomalous event, while persons and entities of a node that is affected or impacted by the anomalous event, but otherwise not identified as the root cause, are notified.)
Regarding Claims 2, 13:
The combination of Basu and Jividen teaches The method of claim 1/system of claim 12,
Furthermore, Basu teaches:
-wherein the user interface includes a flow diagram interface. (Basu[0092] The cause-effect graph 400 includes three nodes 402, 404 and 406. The nodes 402, 404 and 406 correspond to the clues A, B and C, respectively for the problem being investigated. As shown in FIG. 4, the node 402 is connected to the nodes 404 and 406 through two directed arrows to indicate that at least one event in the clue A has happened earlier in time than the events in clues B and C and there is a cause-effect relationship between the clues A and B, and the clues A and C. In at least one example embodiment, the users (e.g., the investigators) can pin, i.e., post the clues on the cause-effect user interface facilitated by the collaborative problem investigation platform 116 to form the cause effect graph to determine the cause-effect relationships between the clues relevant for the problem, and can also pin them to causes in the cause-tree/fishbone diagram for evidence-based problem analysis. An example of cause-effect graph prepared for the ‘website down’ problem is explained in detail with reference to FIG. 5.) In Basu [0092] arrows between nodes are the same thing as a flow diagram. Furthermore, cause-trees/fishbone diagrams are examples of types of flow diagrams, therefore the limitation has been taught.
Regarding Claims 3, 14:
The combination of Basu and Jividen teaches The method of claim 2 further comprising (or system of claim 13 wherein the memory is further configured to provide the one or more processors with instructions which when executed cause the one or more processors to):
Furthermore, Basu teaches:
-provid(ing) a visual representation of the incident using the flow diagram interface. (Basu [0190] At operation 2012, the method 2000 includes displaying, by the processor, the cause-tree/fishbone diagram on one or more display screens of the one or more electronic devices of the one or more users for facilitating determination of one or more potential causes responsible for causing the fault based on one or more evidences and one or more recommendations for resolving the fault. The displayed cause-tree/fishbone diagram includes a head representing the fault that has occurred in the faulty system, one or more bones that branch off the spine for major causes, with sub-branches for sub-causes, to as many levels as required, representing the one or more causes and their sub-causes for the fault and one or more attributes associated with each cause of the one or more causes for the fault.) Basu’s “fault” is mapped to the incident, and the fishbone diagram provides a visual flow diagram.
Regarding Claims 6, 17:
The combination of Basu and Jividen teaches The method of claim 1/The system of claim 14,
Furthermore, Basu teaches:
-wherein the visual representation includes one or more connected nodes, and (Basu[0095] As described with reference to FIG. 3, the symptoms identified by A1, A2, D1, D2, and W1 have all been marked as clues in the symptoms table 300 to indicate that these symptoms are notable events and are significant for the cause-effect analysis. So, the cause-effect graph 500 includes nodes 502, 504, 506, 508 and 510 corresponding to the clues identified by D2, A1, D1, A2, and W1, respectively. The node 502 is shown to be connected to the nodes 504 and 506 through directed arrows indicating that the error in clue D2 is responsible for causing the errors in clues A1 and D1. Similarly, node 504 is further shown to be connected to the nodes 508 and 510 through directed arrows indicating that the error in clue A1 is responsible for causing the errors in clues A2 and W1.)
-wherein each of the one or more connected nodes has a node type. (Basu[0130] FIG. 12 is an example representation of a fishbone diagram 1200 displayed to the users (e.g., the investigators 106a to 106n) on their electronic devices while performing problem investigation using the collaborative problem investigation platform 116, in accordance with another example embodiment. The fishbone diagram 1200 may be used by the users of the collaborative problem investigation platform 116 for identifying potential causes for the problem ‘system outage’ which is shown in a head of the fishbone diagram 1200.) As noted by the examiner, Fig. 12 does show different “types” of nodes, with different shapes reflecting the type of issue they represent.
Regarding Claims 7, 18:
The combination of Basu and Jividen teaches The method of claim 6/The system of claim 17,
Furthermore, Basu teaches:
-wherein the node type is an issue type, and wherein the cause and effect element of the root cause analysis corresponds to the factor type. (Basu [0131] As shown in FIG. 12, four potential main causes for the problem system outage can be ‘Application’, ‘Database’, ‘Security’ & ‘Web’. Sub-causes within each of the main causes may help break down the main causes into their constituent parts so that the user can explore them systematically. For example, the ‘Database’ cause is broken down into ‘Memory Issue’ or ‘Query Issue’, each of which may be individually analyzed by the users (e.g., the investigators 106a to 106n). Likewise, the ‘Security’ cause may be due to one of ‘SQL Injection’ or ‘DDOS Attack’, the latter being a nested Fishbone (the details of which are not shown in FIG. 12).) “Memory issue” or “Query Issue” is an issue type, and the elements in Fig. 12, labeled Memory Issue and Query Issue corresponds to their type.
Regarding Claims 8:
The combination of Basu and Jividen teaches The method of claim 1,
Furthermore, Basu teaches:
-further comprising identifying one or more collaborators associated with the information technology incident. (Basu [0075] In at least one example embodiment, the recommendation engine 212 is configured to self-learn from the actions facilitated by the fault analysis module 208. A primary goal of self-learning is to recommend likely clues and useful actions for new problems using historical data captured for solved problems. [0080] Investigator suggestions: suggestions for one or more personnel that are likely to get the new problem resolved. [0091] FIG. 4 is an example representation of a cause-effect graph 400, in accordance with an example embodiment. The cause-effect graph 400 is created by the users (e.g., the investigators 106a to 106n) of the collaborative problem investigation platform 116 on the cause-effect user interface facilitated by the collaborative problem investigation platform 116 for determining cause-effect relationships between the clues determined for a problem.) Since the investigators are collaborators, the generation of suggestions for which personnel to solve the problem anticipates this limitation.
Regarding Claims 9:
The combination of Basu and Jividen teaches The method of claim 8,
Furthermore, Basu teaches:
-further comprising providing the identified one or more collaborators with access to the user interface to manage the information technology incident. (Basu [0053] In an embodiment, the investigators 106a to 106n may access the collaborative problem investigation platform 116 for identifying potential causes that are leading to the problem occurring in the faulty system 112 and for determining actions that need to be taken for resolving the problem occurring in the faulty system 112. The collaborative problem investigation platform 116 enables investigators 106a to 106n to jointly analyse issues that are leading to the problem in the faulty system 112. In at least one example embodiment, the investigators 106a to 106n are subject matter experts (SMEs) responsible for different modules/machinery of the faulty system 112 and their team members working with SMEs on different modules for resolving the problem that has occurred in the faulty system 112.)
Regarding Claims 10, 19:
The combination of Basu and Jividen teaches The method of claim 1/ The system of claim 12,
Furthermore, Basu teaches:
-wherein the user interface is a collaborative user interface accessible by two or more collaborators. (Basu [0048] The collaborative problem investigation platform also creates and displays an updatable cause-tree/fishbone diagram for facilitating collaborative and hierarchical cause analysis for the fault. This cause-tree/fishbone diagram helps the investigators (SMEs) in systematically exploring potentially faulty components as well as external issues and also helps in identifying one or more factors responsible for the problem. [0086] A symptoms table for ‘website down’ problem that has occurred in an e-commerce website and needs to be investigated collaboratively is shown in FIG. 3. The e-commerce application may consist of three main modules which are application module, database module, and web module. A plurality of investigators may typically be involved in the problem analysis, as people in different teams are generally responsible for different modules. Here, at least three investigators are expected to collaborate i.e., SMEs of the application, database and web modules may be required for investigating about the ‘website down’ problem.)
Regarding Claim 11:
The combination of Basu and Jividen teaches The method of claim 1
Furthermore, Basu teaches:
-further comprising providing a timeline of the information technology incident. (Basu [0004] This step requires reconstructing the actions and decisions that were taken while the investigation was going on and reviewing the timeline of the actions and decisions, including who did what and when.)
Regarding Claim 21:
The combination of Basu and Jividen teaches The method of claim 1,
Furthermore, Basu teaches:
-wherein the incident timeline reflects events including the at least one event leading to the incident arranged as a time-based display. (Basu [0053] In an embodiment, the investigators 106a to 106n may access the collaborative problem investigation platform 116 for identifying potential causes that are leading to the problem occurring in the faulty system 112 and for determining actions that need to be taken for resolving the problem occurring in the faulty system 112. The collaborative problem investigation platform 116 enables investigators 106a to 106n to jointly analyse issues that are leading to the problem in the faulty system 112. [0087] The time of event occurrence field 306 indicates the times at which the event has been observed. [0059] In the cause-effect graph, nodes of the graph correspond to the clues for the problem and the clue that happened earlier in time may be connected to a clue that happened later through the directed arrow to indicate that there is a cause-effect relationship between the two clues. In an embodiment, a plurality of clues may be grouped together in a group to indicate a correlation between them. )
Regarding Claim 22:
The combination of Basu and Jividen teaches The method of claim 21,
Furthermore, Basu teaches:
-wherein the events are tagged to identify a relevant party associated with the at least one device. (Basu [0053] The collaborative problem investigation platform 116 enables investigators 106a to 106n to jointly analyse issues that are leading to the problem in the faulty system 112. In at least one example embodiment, the investigators 106a to 106n are subject matter experts (SMEs) responsible for different modules/machinery of the faulty system 112 and their team members working with SMEs on different modules for resolving the problem that has occurred in the faulty system 112. [0086] A plurality of investigators may typically be involved in the problem analysis, as people in different teams are generally responsible for different modules. Here, at least three investigators are expected to collaborate i.e., SMEs of the application, database and web modules may be required for investigating about the ‘website down’ problem.) SME’s involved in different modules/machinery of a faulty systems are examples of relevant parties associated with the device.
Regarding Claim 23:
The combination of Basu and Jividen teaches The method of claim 22,
Furthermore, Basu teaches:
- the relevant party to access the analysis service including the visual representation.(Basu [0134] The collaborative problem investigation platform 116 supports fine-grained concurrent operations on the symptoms table by the plurality of users (e.g., the investigators 106a to 106n) working together on a same problem. [0048] The collaborative problem investigation platform also creates and displays an updatable cause-tree/fishbone diagram for facilitating collaborative and hierarchical cause analysis for the fault.)
However, Basu fails to teach:
-identifying at least one collaborator based on the tagged events; and
-inviting the relevant party to access the analysis service
Alternatively, Jividen suggests:
-identifying at least one collaborator based on the tagged events; and (Jividen [0038] The incident ticket generator 222 may generate and transmit a report to a user of the report based on an identified chain of failures. In one example embodiment, the incident ticket generator 222 may identify a role associated with a user and output an incident report or ticket to the user based on the user's role. For example, the role of the user may be determined based on a username, an employee identification number, or an email address associated with the user. [0049] Once a root cause of the anomalous event has been identified, an incident (or support) ticket generated by the incident ticket generator 220 may be sent to the nodes identified as the root cause of the anomalous event, at operation 310. In another example embodiment, the incident ticket is sent to a user of the generated incident ticket, such as an administrator of the network or a technical advisor, such as an IT manager, or the person or entity responsible for handling incident tickets.)
-inviting the relevant party to access the analysis service (Jividen [0070] If the server 108 does not detect any additional alerts during the time period, and similar to the preceding operations, a standard incident ticket is created and sent to the person or entity responsible for handling resolution of the alert, at operation 634. [0049] In another example embodiment, the incident ticket is sent to a user of the generated incident ticket, such as an administrator of the network or a technical advisor, such as an IT manager, or the person or entity responsible for handling incident tickets. The incident ticket may be generated to advise a party (e.g., the administrator) of a failure associated with the network. For example, the incident ticket may specify that a particular application is not available along with a description of the alerts associated with the failed application, which may also include any causal graph previously generated by the server 108. In response to receiving the incident ticket reporting the anomalous event, the appropriate person or entity may proactively investigate the anomalous event and identify the particular root cause of the anomalous event. Subsequent to identifying one or more root causes of the detected anomaly condition, the appropriate person(s) or entity(ies) associates the detected anomalous event to the resource causing the failure or error. Additionally, the appropriate person(s) or entity(ies) associates the detected anomalous event to corresponding corrective action required to fix the underlying root cause(s) associated with the resource failure or error.) User’s proactively investigating the anomalous event as a result of receiving an incident ticket, is an example of inviting a relevant party to access the analysis service.
Therefore, it would have been obvious to one of ordinary skill before the effective filing date of the present disclosure to modify Basu by adding Jividen’s teachings of identifying the appropriate persons or entities to address an incident ticket, and alerting those users. By adding these teachings to Basu’s collaboration platform of investigators, one of ordinary skill in the art would reasonably expect to arrive at the predictable outcome of inviting the relevant party to access the analysis service including the visual representation. In view of Basu’s teachings of subject matter experts added as investigators to the platform, and Jividen’s assignment of relevant parties, it would have been obvious to try inviting the relevant user’s to Basu’s platform. One of ordinary skill in the art would have been motivated by Jividen’s benefit of minimizing the number of incident tickets issued and time spent troubleshooting. (Jividen [0073] With an ability to correlate alerts, incident tickets and troubleshooting can be provided more effectively to minimize the number of incident tickets issued and time spent troubleshooting thus reducing cost. Moreover, the system sends incident tickets to persons or entities that have been identified as having systems and components responsible for the root cause of an anomalous event, but notifying those persons and entities impacted by the anomalous event but not otherwise responsible for the anomalous event itself. Thus, persons and entities receiving a notification, but not an incident ticket, become aware of the network issues but are not otherwise consumed with attempting to resolve the network issue, thereby saving time and cost.)
Regarding Claim 24:
Basu teaches:
A method comprising:
-retrieving, by the analysis service, performance data related a device impacted by the information technology incident; (Basu [0069] The fault data receiving module 206 is in communication with the UI module 204 and the database 202. The fault data receiving module 206 is configured to receive data relevant for investigation of the faults that have occurred in the faulty system. The data includes monitoring data, log event data, system alerts and anomalies occurring in the faulty system. In an embodiment, the data is provided by monitoring tools that collect and continuously analyze data of the faulty system. In another embodiment, that data is automatically pulled from the faulty system by connecting the system 200 to the monitoring tools through application program interfaces (API's) [0002] They are responsible for monitoring the systems on an on-going basis as well as for promptly resolving any problems or incidents that may arise in them. The systems can be any software or non-software system including multiple complex components. The systems include, but are not limited to, computing systems, telecommunication systems, or electro-mechanical systems. See also [0052])
-identifying, by the analysis service utilizing the performance data, a plurality of candidate factors including a first candidate factor of the plurality of candidate factors, (Basu [0074] The recommendation engine 212 is in communication with the database 202, the fault analysis module 208 and the reporting module 210. The recommendation engine 212 is configured to make prescriptive recommendations for new faults using the historical data related with the resolved faults/problems stored in the database, actions facilitated by the fault analysis module 208 and the reports generated by the reporting module 210. In an embodiment, the actions facilitated by the fault analysis module 208 includes actions performed on the symptoms table, actions performed on the cause-effect graph and the actions performed on the cause-tree/fishbone diagram. The prescriptive recommendations may include one or more likely clues and their cause-effect relationships for a new fault, one or more users who are qualified to find solutions for the new fault, one or more potential causes for the new fault,) Basu’s recommendation engine (which is part of the analysis service), identifies “one or more likely clues,” and “one or more potential causes” which are examples of candidate factors, based on actions facilitated by the fault analysis module, which has been mapped to the ”performance data.”
-wherein each of the plurality of candidate factors corresponds to a potential cause of the information technology incident; (Basu [0057] In an embodiment, the collaborative problem investigation platform 116 may enable the investigators 106a to 106n to perform exploration of potential causes that are causing a fault in the faulty system 112 in a methodical manner by creating a hierarchical cause-tree diagram. In the cause-tree diagram, the potential causes may split up recursively into sub-causes, with each cause or sub-cause having its own attributes such as name, notes, fault status etc. to enable the investigators 106a to 106n to perform systematic cause analysis of the fault that occurred in the faulty system 112. [0067] The database 202 is configured to store data related with one or more problems/faults that are investigated and solved using the system 200 or the historical data from prior problem investigations. The data includes context of each problem, one or more symptoms associated with each problem, fault analysis outcomes of each problem (e.g., the one or more potential causes responsible for causing the problem), information about users who were involved in resolving the problem and the one or more solutions that are provided by the users for resolving the problem.) Basu’s potential causes are mapped to the candidate factors of the incident, and “solutions” are mapped to tasks related to the incident.
- generating, by the analysis service, an incident timeline as part of a visual representation of the incident, (Basu [0059] In at least one example embodiment, one or more investigators of the investigators 106a to 106n may use the symptoms table available in the collaborative problem investigation platform 116 to identify one or more clues. In an embodiment, a clue is a symptom that indicates notable event for causing the failure in the faulty system. The investigators may post the identified one or more clues on a cause-effect user interface (UI) provided on the collaborative problem investigation platform 116. The investigators may also connect the clues posted on the cause-effect user interface with causal arrows to form a cause-effect graph (shown in FIG. 5). In the cause-effect graph, nodes of the graph correspond to the clues for the problem and the clue that happened earlier in time may be connected to a clue that happened later through the directed arrow to indicate that there is a cause-effect relationship between the two clues. [0085] The symptoms table 300 includes one or more rows for describing the one or more symptoms that may have occurred in one or more modules of the faulty system and a plurality of columns for defining one or more details associated with each symptom. The one or more details include, but are not limited to, symptom identifier, symptom pattern, time of symptom occurrence, component at fault and symptom category. [0087] The symptom pattern field 304 represents an event that has been considered as a symptom for the fault. The time of event occurrence field 306 indicates the times at which the event has been observed. [0089] As shown in the FIG. 3, the ‘application’ module has encountered three symptoms which are identified by ‘A1’, ‘A2’ and ‘A3’, of which ‘A1’ and ‘A2’ are categorized as ‘Error’ and ‘A3’ is categorized as ‘Other’. The symptom pattern for A1 is ‘DB connection failed’. The time(s) of occurrence of the symptom is important in understanding how the events unfolded leading to the problem, and for A1 the last occurrence time is specified as ‘2018-11-15 16:09:19 UTC’. As another example, consider the last row in the symptoms table 300. A symptom identified by W2 that has been observed in the ‘web’ module, specified to be of type ‘Other’ with the event being ‘404 File not found’, happened at two different times.) In the teachings above, Basu’s cause-effect graph (show in Fig. 5) satisfies the limitation because it shows the incident as a visual representation with timestamps, and arrows that indicate the time relationship between clues.
- wherein the incident timeline includes at least one event leading up to the information technology incident, and (Basu [0059] In the cause-effect graph, nodes of the graph correspond to the clues for the problem and the clue that happened earlier in time may be connected to a clue that happened later through the directed arrow to indicate that there is a cause-effect relationship between the two clues. In an embodiment, a plurality of clues may be grouped together in a group to indicate a correlation between them. In an embodiment, the cause-effect graph with one or more directed arrows may be used to represent causality relationships between the one or more clues. In another embodiment, other representations can also be used to present causality relationships between the one or more clues. [0089] As shown in the FIG. 3, the ‘application’ module has encountered three symptoms which are identified by ‘A1’, ‘A2’ and ‘A3’, of which ‘A1’ and ‘A2’ are categorized as ‘Error’ and ‘A3’ is categorized as ‘Other’. The symptom pattern for A1 is ‘DB connection failed’. The time(s) of occurrence of the symptom is important in understanding how the events unfolded leading to the problem, and for A1 the last occurrence time is specified as ‘2018-11-15 16:09:19 UTC’. As another example, consider the last row in the symptoms table 300.) In the excerpts above, the events leading up to the incident are displayed.
- wherein the visual representation specifies one or more nodes corresponding to a cause and effect element associated with the device impacted by the information technology incident; and (Basu [0188] At operation 2008, the method 2000 includes causing, by the processor, provisioning of a cause-effect user interface (UI) on one or more display screens of one or more electronic devices of the one or more users for facilitating creation of a cause-effect graph using the one or more clues. The cause-effect graph is used by the plurality of users to concurrently analyze the cause-effect relationships between the one or more clues. A ‘how’ aspect of the problem is defined using the cause-effect graph i.e. how the problem happened by determining the cause-effect relationships among the symptoms seen. In an embodiment, the one or more clues are pinned on the provided cause-effect user interface to create the cause-effect graph. In another embodiment, the one or more clues may be grouped together to indicate correlation of the one or more symptoms. The one or more clues or groups of clues are connected with causal arrows to show ‘how’ the events unfolded. [0130] FIG. 12 is an example representation of a fishbone diagram 1200 displayed to the users (e.g., the investigators 106a to 106n) on their electronic devices while performing problem investigation using the collaborative problem investigation platform 116, in accordance with another example embodiment... [0138] The concurrent operations that can be performed on or interact with the cause-effect graph include: [0139] pinning a symptom on the cause-effect graph, which creates a node in the graph for the symptom [0140] unpinning a symptom/clue, which removes the node for that symptom from the graph [0141] connecting a pair of symptoms/clues on the graph with cause-effect arrows to indicate causality [0142] disconnecting a pair of symptoms/clues on the cause-effect graph that are connected [0143] grouping a set of symptoms/clues on the cause-effect graph to indicate correlation [0144] ungrouping a set of previously grouped symptoms/clues on the cause-effect graph [0145] deleting a symptom pinned on the cause-effect graph from the symptoms table, which also causes the node for the symptom to be deleted from the cause-effect graph.) The fishbone diagram of Fig. 12 is an example of generating a visual flow diagram of the incident, specifying nodes [0138] reflecting the cause and effect element. Since this visual flow diagram pertains to a particular faulty system, which includes devices impacted by the incident, then the limitation has been satisfied. The cause-effect graph specifies nodes which corresponds the symptoms (effect), with the clues (cause).
- establishing, by the analysis service, a workspace for collaboration based on the cause and effect element, (Basu [0068] The user interface module 204 is in communication with the database 202. The user interface module 204 is configured to present one or more UIs for facilitating collaborative evidence-based problem investigation and resolution. [0088] In at least one example embodiment, the users (e.g., the investigators) can pin, i.e., post the clues on the cause-effect user interface facilitated by the collaborative problem investigation platform 116 to form the cause effect graph to determine the cause-effect relationships between the clues relevant for the problem, and can also pin them to causes in the cause-tree/fishbone diagram for evidence-based problem analysis.)
- wherein the workspace incorporates at least one member identified as part of the incident timeline. (Basu 0053] In an embodiment, the investigators 106a to 106n may access the collaborative problem investigation platform 116 for identifying potential causes that are leading to the problem occurring in the faulty system 112 and for determining actions that need to be taken for resolving the problem occurring in the faulty system 112. The collaborative problem investigation platform 116 enables investigators 106a to 106n to jointly analyse issues that are leading to the problem in the faulty system 112. In at least one example embodiment, the investigators 106a to 106n are subject matter experts (SMEs) responsible for different modules/machinery of the faulty system 112 and their team members working with SMEs on different modules for resolving the problem that has occurred in the faulty system 112.)
However, Basu fails to teach:
- receiving, at an analysis service, an incident ticket reflecting an information technology incident detected in a network;
-retrieving, by the analysis service, performance data related a device...identified in the incident ticket;
Alternatively, Jividen teaches:
- receiving, at an analysis service, an incident ticket reflecting an information technology incident detected in a network;(Jividen [0031] This number may be compared to a threshold number or a threshold percentage to determine if the anomalous event (successfully resolved) is occurring on a frequent enough basis (e.g., execution of a program on a server fails during 95% of attempts over a predefined period of time) to provoke an incident ticket (i e, a support ticket), troubleshooting, or further review by a user. In one example, an incident ticket is filed by a user of the system in response to a hardware or software failure (e.g., an application failure, process failure, server failure, etc.). In another example, the incident ticket is automatically generated by the system. It is appreciated that the term “failure” within the context of this disclosure is not limited to a complete failure of software or hardware, but also to partial failure or any type of performance, problem, error or activity issue with the software or hardware, including applications, components, code, data, etc. associated therewith. [0049] Once a root cause of the anomalous event has been identified, an incident (or support) ticket generated by the incident ticket generator 220 may be sent to the nodes identified as the root cause of the anomalous event, at operation 310.)
-retrieving, by the analysis service, performance data related a device...identified in the incident ticket;(Jividen [0038] The incident ticket generator 222 may generate and transmit a report to a user of the report based on an identified chain of failures. In one example embodiment, the incident ticket generator 222 may identify a role associated with a user and output an incident report or ticket to the user based on the user's role. For example, the role of the user may be determined based on a username, an employee identification number, or an email address associated with the user. In one example, a person with a technical role within an insurance organization may receive a report with technical information (e.g., server utilization information). While a person with a non-technical role within the insurance organization may receive a report with business-focused information (e.g., the number of people who can currently connect to a particular application or the estimated downtime for the particular application). [0031] The location component 206, when executed the processor(s) 116, causes the processor(s) 116 to identify at least one of the event groups having at least one of the events assigned thereto with a status 212 indicating failure of a process or component identified by the process and component identifier 214 of the at least one event.) Jividen’s component identifier is an example of a device identified as part of the incident ticket.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the present disclosure to modify Basu with the teachings of Jividen by adding the features of identifying the incidents with incident tickets. By simply adding Jividen’s incident tickets to the detection of Basu’s incidents one would reasonably have expected to arrive at the claimed limitations, as the modification would have been obvious to try. Furthermore, one of ordinary skill in the art would have been motivated to add Jividen’s teachings as it would yield the benefit of adding precision and reducing false alarms if the event can be self-resolved, ultimately reducing the volume of incident tickets. (Jividen [0002] Some existing systems detect errors in a process by assuming that a first or last error event that occurs during an analysis window execution of the process is the root cause. However, this approach lacks precision and may produce false alarms (e.g., if the error event is not severe, is only temporary, or if the event self-resolves). [0004] In one example, the system, device and techniques described herein allow for a configurable multi-cycle correlation and enrichment based on multiple data sources (e.g., configuration, transaction ID, etc.) and key/value pairs. Additionally, configuration and topology data may be correlated to account for multi-tiered relationships between configuration items in a node, including recognition of neighboring relationships that are not a reason to correlate (i.e., false positive avoidance). Moreover, based on the alerts and related dependency chains, machine learning algorithms may determine the probable root cause of the anomalous event and open the incident tickets to the appropriate persons or entities for resolution. The incident tickets may be sent to persons or entities of a node responsible for resolution of the anomalous event, while persons and entities of a node that is affected or impacted by the anomalous event, but otherwise not identified as the root cause, are notified.)
Claims 5, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Basu (US 20200241949 A1) in view of Jividen(US 20230016199 A1), further in view of Chakravarty et al. (US 10380548 B2) hereinafter Chakravarty.
Regarding Claims 5 and 16:
The combination of Basu and Jividen teaches: The method of claim 1/The system of claim 14,
Furthermore, Basu teaches:
-wherein the visual representation is modified by an action to place the cause and effect element of the root cause analysis as a node of the visual representation.(Basu [0138] The concurrent operations that can be performed on or interact with the cause-effect graph include: [0139] pinning a symptom on the cause-effect graph, which creates a node in the graph for the symptom [0140] unpinning a symptom/clue, which removes the node for that symptom from the graph [0141] connecting a pair of symptoms/clues on the graph with cause-effect arrows to indicate causality [0142] disconnecting a pair of symptoms/clues on the cause-effect graph that are connected [0143] grouping a set of symptoms/clues on the cause-effect graph to indicate correlation [0144] ungrouping a set of previously grouped symptoms/clues on the cause-effect graph [0145] deleting a symptom pinned on the cause-effect graph from the symptoms table, which also causes the node for the symptom to be deleted from the cause-effect graph.) Basu described various actions that can be used to place the elements on the diagram.
However, neither Basu nor Jividen teach or suggest: -a drag action to place the elements
Alternatively, Chakravarty discloses a graphical user interface to create customizable automated workflows for incident remediation. Chakravarty teaches:
-a drag action to place cause elements as a node on a visual flow diagram (Chakravarty[Col. 3 Lines 59-63] For example, a system work item can be configured to perform an action that may be implemented on a source network device (or downstream device) that caused an incident. Completion of the system work-item may depend on results from the action(s) taken. [Col. 9 Lines 57-63] The panel for process elements 203 displays all the elements including step/work-item elements, transitions elements, and variable elements in a tree view. This allows the user to view all supported elements and custom elements (e.g., myWork-items) in an organized tree view. Objects from this panel may be dragged and dropped into the graph or otherwise incorporated therein.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the present disclosure to further modify Basu by adding Chakravarty’s interface feature of dragging and dropping to add interface elements to a diagram. One would have been motivated to make this combination as it would provide the benefit of improving user collaboration by providing user-friendly interface features such as drag-and-drop. (Chakravarty [Col. 2 Lines 60 – Col. 3 Line 17])
Response to Arguments
Applicant's arguments filed 01/20/2026 have been fully considered but they are not persuasive.
Regarding arguments over rejections under 35 U.S.C. 101, in view of the amended claims, the applicant asserts that the claims have been amended to more clearly recite that they are directed to “statutory subject matter.” However, the examiner respectfully disagrees. In view of the applicant’s arguments that the relied upon characterization of the claims as a “mental process” ignores the subject matter recited by the pending claims. However, these arguments are moot in view of the updated rejection, which no longer relies on assertion that the claims are solely directed to a mental process. The current rejection now only places the claims within the sub-categories of “certain methods of organizing human activity,” which is a separate category from mental process. Therefore, the applicant’s argument that the relied upon characterization overlooks “both the retrieval of telemetry from affected devices in communication with an analysis services and a network” is not persuasive because retrieval of information from devices alone, does not integrate the “certain method of organizing human activity” into a practical application or provide significantly more. It is merely a collection of data from generic computing devices. Furthermore, since the identification of candidate factors based on the retrieved performance data does not specifically limit how the identification occurs, it is an “apply it” level element because it merely claims the idea of the solution or outcome without the mechanisms required to arrive at the claimed idea or solution. Thus, even when evaluating the claim as a whole, the additional elements are not merely dismissed as “generic computing components” but have been given full consideration under MPEP 2106.05(a), and MPEP 2106.05(f) as to whether they reflect an improvement to technology. The applicant’s arguments that the recited steps go beyond mere observation or evaluation by a human mind and instead require computer-based implementation are not persuasive because merely “requiring” computer-based implementation, does not integrate the claims into a practical application or provide significantly more.
Furthermore, the applicant’s arguments that the claims integrate the abstract idea into a practical application in Prong 2 are not persuasive because the abstract idea is not applied, relied on, or used in a manner that imposes a meaningful limit on it. The recited functionality does not meaningfully limit how the candidate factors are determined, nor how the visual representation is arranged, leaving these steps to be broad enough to encapsulate mere instructions to manage personal behavior. The applicant’s arguments that the recited functionality goes beyond merely organizing or displaying information is not persuasive, because the elements in which the applicant argues are not reflected within the scope of the present claims. For example, the applicant alleges that the functionality provides a technical solution to a technical problem, diagnosing and visualizing root causes of networked devices failures in real-time, but fails to note that the diagnostic and visualization steps are recited with such generality that they can be performed by an individual interacting with the computing device. Furthermore, the applicant’s argument that the generation of a visual representation and time line with cause and effect nodes is not a mere presentation of information, but rather a “transformation of raw device performance data into an actionable, structured representation that aids analysis of complex incidents” is not persuasive because nothing in the claims meaningfully limits how the data is transformed or structured to be limited to technical implementation. In other words, the claims are recited with such generality that they are merely instructions to an individual to manage their personal behavior.
Therefore, the applicant’s argument that the claims integrate any alleged abstract concept into a practical application by “reciting a specific technical process for retrieving data, performing an automated analysis, and generating a visual diagnostic tool to address IT incidents,” is not persuasive because it is merely instructing “certain methods of organizing human activity” to be performed on a computing device, without meaningfully limiting the claims to technical implementations. Merely instructing a computer to perform the abstract idea, in order to “perform an automated analysis” is equivalent to “apply it” or mere instructions to carry out the abstract idea, especially when the claims do not specifically recite how the computer aids the method.
In response to applicant’s arguments over claim rejections under 35 U.S.C. 102 and 103, the applicant’s remarks have been fully considered but are not persuasive. The applicant alleges that Basu does not teach or suggest the following features:
- generating, by the analysis service, an incident timeline as part of a visual representation of the incident, wherein the incident timeline includes at least one event leading up to the information technology incident, and wherein the visual representation specifies one or more nodes corresponding to the cause and effect element associated with the at least one device impacted by the information technology incident.
However, as shown in the rejection above, the limitations are rendered obvious by the combination of Basu and Jividen. The applicant’s argument that “while Basu teaches the cause-tree/fishbone diagram, Basu is silent regarding an incident timeline” is not persuasive because these diagrams are not mutually exclusive. The term “incident timeline” given its broadest reasonable interpretation is satisfied by Basu’s teachings, as Basu’s teachings provide a sequence of events with time stamps. Furthermore, the allegations that Basu is silent on “establishing a workspace for collaboration based on the cause and effect element, wherein the workspace incorporates at least one member identified as part of the incident timeline” is contrary to the findings in the rejection above, which show that Basu satisfies these limitations.
Furthermore, the applicant’s arguments in page 11 of the applicant’s remarks have been fully considered but none are persuasive in view of the updated rejections over 35 U.S.C. 103 in view of the combination of Basu and Jividen. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Therefore, the claims remain rejected under 35 U.S.C. 103, in view of the combination.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
-Thompson (US 20230388324 A1, provisional application #63,347,389 is attached for prior art date and reference) discloses an adaptive security architecture with an incident timeline and collaborative platform for addressing incidents.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICO LAUREN PADUA whose telephone number is (703)756-1978. The examiner can normally be reached Mon to Fri: 8:30 to 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jessica Lemieux can be reached at 571-270-3445. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICO L PADUA/Junior Patent Examiner, Art Unit 3626 /SANGEETA BAHL/Primary Examiner, Art Unit 3626
Prosecution Insights