DETAILED ACTION
This is a non-final. Claims 1-20 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/13/2026 has been entered.
Status of Claims
Applicant’s amendment date 07/13/2026, amended claims 1-2, 5, 9-10, 13, and 17-18.
Response to Amendment
The previously pending rejection to claims 1-20, under 35 USC 101 (Alice), will be maintained.
Response to Arguments
Applicant’s arguments received on date 07/13/2026 have been fully considered, but they are not persuasive. Moreover, any new grounds of rejection have been necessitated by Applicant's amendments to the claims. The art rejection has been updated to address these amendments.
Response to Arguments under 35 USC 101:
Applicant argues that "Applicant submits that Claims 1, 9, and 17 as amended do not recite a mental process under Step 2A Prong One.” Examiner respectively disagrees.
Pursuant to 2019 Revised Patent Subject Matter Eligibility Guidance, in order to determine whether a claim is directed to an abstract idea, under Step 2A, we first (1) determine whether the claims recite limitations, individually or in combination, that fall within the enumerated subject matter groupings of abstract ideas (mathematical concepts, certain methods of organizing human activity, or mental processes), and (2) determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. 84 Fed. Reg. 52, 54-55. Next, if a claim (1) recites an abstract idea and (2) does not integrate that exception into a practical application, in order to determine whether the claim recites an “inventive concept,” under Step 2B, we then determine whether the claim recites any of the additional elements beyond the recited abstract idea, individually and in combination, are significantly more than the abstract idea itself. 84 Fed. Reg. 56.
Here, under the first prong of Step 2A, the claims (claim 1, and similarly claims 9, and 17) recite “receive, a post-incident indication associated with an incident subsequent to resolution of the incident; determine if the incident satisfies post-incident report generation criteria; in response to determining that the incident satisfies the post-incident report generation criteria: determine, relevant post-incident data associated with the incident, wherein the relevant post-incident data comprises fault data associated with the incident and corrective action data associated with the incident, wherein determining the fault data comprises generating a causal graph of one or more services and a fault propagation path based on the causal graph corrective action data associated with the incident, and wherein determining the corrective action data comprises: extracting first corrective action data within one or more communication channels previously initiated in response to the incident and configured to enable communication among users to facilitate the resolution of the incident; wherein the first corrective action data is corrected with data extracted from one or more issue data objects associated with the incident to identify at least a portion of the corrective action data; generate, based on the relevant post-incident data, a post-incident report for the incident, wherein generating the post-incident report comprises generating timeline segment, a root cause segment based on the fault propagation path, and a corrective action segment based on the corrective action data; and triggering one or more post-incident improvement actions based on the post-incident report at least in part by transmitting, provide the post-incident report.”
A claim recites mental processes when the claim recites concepts performed in the human mind (including an observation, evaluation, judgment, opinion), wherein if the claim, under its broadest reasonable interpretation, covers the claim being practically performed in the mind but for the recitation of generic computer components, then the claim is in the mental process category. Id. at 52 n.14. Therefore, contrary to Applicant’s assertions, the claims are directed to mental processes.
Applicant argues that "Applicant respectfully submits that this constitutes integration into a practical application under Step 2A Prong Two.” Examiner respectively disagrees.
As discussed above, under the second prong of Step 2A, we determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. 84 Fed. Reg. 52, 54-55.
Here, under the second prong of Step 2A, the only additional elements beyond the recited abstract idea of claim 1, and similarly claims 9, and 17, are the recitations of “the post-incident report is provided for rendering within an interactive graphical user interface such that the client computing device fetches and renders the relevant post-incident data for the incident via the interactive graphical user interface without navigating the one or more enterprise applications are carried out by at least one computing device,” and these additional elements, individually and in combination, are nothing more than computing elements recited at high level of generality implementing the abstract idea on a computer (i.e. apply it), and thus, are no more than applying the abstract idea with generic computer components.
Applicant argues that "Applicant submits that claims 1, 9, and 17 as amended recite significantly more than an abstract idea under Step 2B.” Examiner respectively disagrees.
The MPEP discusses that "the second part of the Alice/Mayo test [(Step 2B)] is often referred to as a search for an inventive concept," and "an 'inventive concept' is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself." MPEP 2106.05 (emphasis added). Further, the MPEP goes on to describe "Step 2B asks: Does the claim recite additional elements that amount to significantly more than the judicial exception? Examiners should answer this question by first identifying whether there are any additional elements (features/limitations/steps) recited in the claim beyond the judicial exception(s), and then evaluating those additional elements individually and in combination to determine whether they contribute an inventive concept (i.e., amount to significantly more than the judicial exception(s)).” MPEP 2106.05 (emphasis added).
The search for an inventive concept under § 101 is distinct from demonstrating novel and non-obviousness. See SAP America Inc. v. Investpic, LLC, No. 2017-2081, slip op. at 2-3 (Fed Cir. May 15, 2018) (citing Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151 (Fed. Cir. 2016); Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1315 (Fed. Cir. 2016). Even novel and newly discovered judicial exceptions are still exceptions, despite their novelty. July 2015 Update, p. 3; see SAP America at 2. In Step 2B, “[w]hat is needed is an inventive concept in the non-abstract application realm.” SAP America at 11. As discussed in SAP America, no matter how much of an advance the claims recite, when “the advance lies entirely in the realm of abstract ideas, with no plausibly alleged innovation in the non-abstract application realm,” “[a]n advance of that nature is ineligible for patenting.” Id. at 3.
Here, under Step 2B, the only additional elements beyond the recited abstract idea of claim 1, and similarly claims 9, and 17, are the recitations of “generating a causal graph of one or more services and a fault propagation path based on the causal graph, generating a post-incident report comprising a timeline segment, a root cause segment based on the fault propagation path, and a corrective action segment based on the corrective action data using a generative artificial intelligence model configured for an incident management platform, and providing that report for rendering within an interactive graphical user interface such that the client computing device fetches and renders the relevant post-incident data for the incident via the interactive graphical user interface without navigating the one or more enterprise applications are carried out by at least one computing device,” and these additional elements, individually and in combination, are nothing more than computing elements recited at high level of generality implementing the abstract idea on a computer (i.e. apply it), and thus, are no more than applying the abstract idea with generic computer components. Accordingly, contrary to Appellant’s assertions, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception under Step 2B.
Response to Arguments under 35 USC 102/103:
Applicant's arguments with respect to the claim rejections have been considered, but are moot in view of the new ground(s) of rejection set forth below in this Office action. The art rejection has been updated to address these amendments.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1, 9, and 17 recite, “via the interactive graphical user interface without navigating the one or more enterprise applications.” As best understood, it appears that there is no support for the underlined recitation in the original disclosure of the present application for this limitation. Moreover, none of the drawings shows this particular feature. Therefore, this limitation of claims 1, 9, and 17 is considered to be new matter. Appropriate correction is required.
Claims 2-8, 10-16, and 18-20 are rejected for having the same deficiencies as those set forth with respect to the claims that they depend from, independent claims 1, 9, and 17.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Specifically, claims 1-20 are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea.
With respect to Step 2A Prong One of the framework, claims 1, 9, and 17 recite an abstract idea. Claims 1, 9, and 17 include “receive, a post-incident indication associated with an incident subsequent to resolution of the incident; determine if the incident satisfies post-incident report generation criteria; in response to determining that the incident satisfies the post-incident report generation criteria: determine, relevant post-incident data associated with the incident, wherein the relevant post-incident data comprises fault data associated with the incident and corrective action data associated with the incident, wherein determining the fault data comprises generating a causal graph of one or more services and a fault propagation path based on the causal graph corrective action data associated with the incident, and wherein determining the corrective action data comprises: extracting first corrective action data within one or more communication channels previously initiated in response to the incident and configured to enable communication among users to facilitate the resolution of the incident; wherein the first corrective action data is corrected with data extracted from one or more issue data objects associated with the incident to identify at least a portion of the corrective action data; generate, based on the relevant post-incident data, a post-incident report for the incident, wherein generating the post-incident report comprises generating timeline segment, a root cause segment based on the fault propagation path, and a corrective action segment based on the corrective action data; and triggering one or more post-incident improvement actions based on the post-incident report at least in part by transmitting, provide the post-incident report”.
The limitations above recite an abstract idea under Step 2A Prong One. More particularly, the elements above recite mental processes-concepts performed in the human mind (including an observation, evaluation, judgment, opinion) because the elements describe a process for generating post-incident reports. As a result, claims 1, 9, and 17 recite an abstract idea under Step 2A Prong One.
Claims 2-8, 10-16, and 18-20 further describe the process for generating post-incident reports. As a result, claims 2-8, 10-16, and 18-20 recite an abstract idea under Step 2A Prong One for the same reasons as stated above with respect to claims 1, 9, and 17.
With respect to Step 2A Prong Two of the framework, claims 1, 9, and 17 do not include additional elements that integrate the abstract idea into a practical application. Claims 1, 9, and 17 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 1, 9, and 17 include an interactive graphical user interface, a monitored software application, machine learning models, enterprise applications, a computing device, a processor, a memory, and a non-transitory computer-readable storage medium. When considered in view of the claim as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional computing elements are generic computing elements that are merely used as a tool to perform the recited abstract idea. As a result, claims 1, 9, and 17 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
Claims 2-7, 10-15, and 18-20 do not include any additional elements beyond those recited with respect to claims 1, 9, and 17. As a result, claims 2-7, 10-15, and 18-20 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two for the same reasons as stated above with respect to claims 1, 9, and 17.
Claims 8 and 16 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 8 and 16 include machine learning models and generative artificial intelligence. When considered in view of the claims as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional computing elements do no more than generally link the use of the recited abstract idea to a particular technological environment. As a result, claims 8 and 16 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
With respect to Step 2B of the framework, claims 1, 9, and 17 do not include additional elements amounting to significantly more than the abstract idea. As noted above, claims 1, 9, and 17 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 1, 9, and 17 include an interactive graphical user interface, a monitored software application, machine learning models, enterprise applications, a computing device, a processor, a memory, and a non-transitory computer-readable storage medium. The additional elements do not amount to significantly more than the abstract idea because the additional computing elements are generic computing elements that are merely used as a tool to perform the recited abstract idea. Further, looking at the additional elements as an ordered combination adds nothing that is not already present when considering the additional elements individually. As a result, independent claims 1, 9, and 17 do not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Claims 2-7, 10-15, and 18-20 do not include any additional elements beyond those recited with respect to claims 1, 9, and 17. As a result, claims 2-7, 10-15, and 18-20 do not include additional elements that amount to significantly more than the abstract idea under Step 2B for the same reasons as stated above with respect to claims 1, 9, and 17.
Claims 8 and 16 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 8 and 16 include machine learning models and generative artificial intelligence. The additional elements do not amount to significantly more than the abstract idea because the additional computing elements do no more than generally link the use of the recited abstract idea to a particular technological environment. Further, looking at the additional elements as an ordered combination adds nothing that is not already present when considering the additional elements individually. As a result, claims 8 and 16 do not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Therefore, the claims are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea. Accordingly, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-2, 9-10, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Goswami et al. (US Pub No. 2024/0037464) (hereinafter Goswami et al.), in view of Siracusano et al. (US Pub No. 2024/0411994) (hereinafter Siracusano al.), in view of L Wu et al. (Automatic performance diagnosis and recovery in cloud microservices) - 2022 - search.proquest.com (hereinafter Wu al.), and further in view of Puri et al. (US Pub No. 2020/0328961) (hereinafter Puri et al.).
Regarding claims 1, 9, and 17, Goswami discloses an apparatus for generating post-incident reports and at least one non-transitory computer-readable storage medium for generating post- incident reports, the at least one non-transitory computer-readable storage medium having computer coded instructions configured to (see Goswami, Fig. 2 and paras [0050] & [0078]) , when executed by at least one processor:
receive, a post-incident indication associated with an incident subsequent to resolution of the incident, wherein the incident is associated with a monitored software application (see Goswami, para [0165], wherein (i.e., for some incidents), the received alerts may include at least some of cause data….Cause data may also be obtained from (or provide by) responders assigned to incidents. For example, as an incident is investigated or after it has been resolved; para [0038], wherein an event associated with a monitored application or service; and para [0111], wherein with respect to a resolved alert, the data store 410 can include information regarding the resolving entity that resolved the alert (and/or, equivalently, the resolving entity of the event that triggered the alert), the duration that the alert was active until it was resolved);
determine if the incident satisfies post-incident report generation criteria (see Goswami, para [0133], wherein that the data store 410 includes sufficient data regarding frequent incidents can mean that the data store 410 of FIG. 4 includes a number of incidents that meet a frequency criterion. In an example, the frequency criterion can be that the data store includes at least a predefined number of resolved incidents that are similar to the incident);
in response to determining that the incident satisfies the post-incident report generation criteria: determine, using one or more machine learning models and based on one or more enterprise applications, relevant post-incident data associated with the incident, wherein the relevant post-incident data comprises fault data associated with the incident and corrective action data associated with the incident, wherein determining the fault data, and wherein determining the corrective action data (see Goswami, para [0023], wherein an event corresponding to the operational issue may be received at an EMB, which in tum may trigger an alert and an incident. Alerts are often resolved by modifying the functioning (e.g., affecting the configuration or execution) of one or more underlying IT components (i.e., corrective action data associated with the incident); Fig. 2 and paras [0133] & [0195], wherein the technique 800 may, responsive to determining that the incident is of the rare type or the frequent type, generate, by the machine-learning model recommendation engine, the list of recommended responders by generating the list of recommended responders based on fuzzed incident titles, historical data of past responders for the alert, a skillset needed to respond to the incident and/or responder skillset data; and paras [0111]-[0112], wherein with respect to a resolved alert, the data store 410 can include information regarding the resolving entity that resolved the alert (and/or, equivalently, the resolving entity of the event that triggered the alert), the duration that the alert was active until it was resolved……The resolving entity can be a responder (e.g., a human). The resolving entity can be an integration (e.g., automated system), which can indicate that the alert was auto resolved. That the alert is auto resolved can mean that the system 400 received, such as from the integration, an event indicating that a previous event, which triggered the alert, is resolved) comprises:
extracting first corrective action data within one or more communication channels the incident (see Goswami, wherein paras [0165], [0064] & [0079], wherein with respect to incident causes, in some cases (i.e., for some incidents), the received alerts may include at least some of cause data. As such, incident causes can be extracted therefrom. Cause data may also be obtained from (or provide by) responders assigned to incidents. For example, as an incident is investigated or after it has been resolved, responders associated with the incident may add cause data to the incident…..the audio interface 256 may be coupled to a speaker and microphone (not shown) to enable telecommunication with others or generate an audio acknowledgement for some action. A microphone in the audio interface 256 can also be used for input to or control of the client computer 200, e.g., using voice recognition, detecting touch based on sound….Exchanged communications may include, but are not limited to, queries, searches, messages, notification messages, events, alerts, performance metrics, log data, API calls, or the like);
wherein the first corrective action data is corrected with data extracted from one or more issue data objects associated with the incident (see Goswami, wherein paras para [0023], [0165], [0112] & [0079], wherein resolved by modifying the functioning (e.g., affecting the configuration or execution) of one or more underlying IT components (i.e., corrective action data associated with the incident)…..The data store 410 can include data related to actions performed with respect to alerts. The data store 410 can include data indicating whether an action cleared (or contributed to clearing) a triggering event, or equivalently, the event. The data store 410 can also include associations (i.e., action-component associations) between actions and IT components and associations (i.e., alert-to-component associations) between alerts (i.e., alert types) and IT components…..with respect to incident causes, in some cases (i.e., for some incidents), the received alerts may include at least some of cause data. As such, incident causes can be extracted therefrom. Cause data may also be obtained from (or provide by) responders assigned to incidents. For example, as an incident is investigated or after it has been resolved, responders associated with the incident may add cause data to the incident);
generate, based on the relevant post-incident data configured for an incident management platform, a post-incident report for the incident, wherein generating the post-incident report comprises generating timeline segment, a corrective action segment based on the corrective action data (see Goswami, para [0108], wherein events may be variously formatted messages that reflect the occurrence of events or incidents that have occurred in the computing systems or infrastructures of one or more managed organizations. Such events may include facts regarding system errors, warning, failure reports, customer service requests, status messages, or the like; para [0034], wherein facilitates incident resolution in an EMB so that mean-time-to-resolution (MTTR) of incidents can be minimized therewith maximizing uptime(s) of components (i.e., MTTR is the average time from when an incident starts to when it is fully resolved; para [0026], wherein resolve an event (or, equivalently, an incident), the affected IT component(s) (i.e., the IT component(s) that triggered the event) may need to be identified, the causes of the alert may need to be identified, and appropriate actions that resolve the alert may also need to be identified; and para [0165], wherein (i.e., for some incidents), the received alerts may include at least some of cause data….Cause data may also be obtained from (or provide by) responders assigned to incidents. For example, as an incident is investigated or after it has been resolved; and para [0110], wherein data related to events, alerts, incidents, notifications, other types of objects, or a combination thereof may be stored in the data store 410. The data store 410 can include data related to resolved and unresolved alerts. The data store 410 can include data identifying whether alerts are or not acknowledged); and
triggering one or more post-incident improvement actions based on the post incident report at least in part by transmitting the post-incident report to one or more of a client computing device or an enterprise application from the one or more enterprise applications, wherein the post-incident report is provided for rendering within an interactive graphical user interface such that the client computing device fetches and renders the relevant post-incident data for the incident via the interactive graphical user interface without navigating the one or more enterprise applications (see Goswami, paras [0111]-[0112], wherein with respect to a resolved alert, the data store 410 can include information regarding the resolving entity that resolved the alert (and/or, equivalently, the resolving entity of the event that triggered the alert), the duration that the alert was active until it was resolved……The resolving entity can be a responder (e.g., a human). The resolving entity can be an integration (e.g., automated system), which can indicate that the alert was auto resolved. That the alert is auto resolved can mean that the system 400 received, such as from the integration, an event indicating that a previous event, which triggered the alert, is resolved; para [0108], wherein events may be variously formatted messages that reflect the occurrence of events or incidents that have occurred in the computing systems or infrastructures of one or more managed organizations. Such events may include facts regarding system errors, warning, failure reports, customer service requests, status messages, or the like….provide the events to the system 400. Events as described above may be comprised of, or transmitted to the system 400 via, SMS messages, HTTP requests/posts, API calls, log file entries, trouble tickets, emails, or the like. An event may include associated information, such as, source, a creation time stamp, a status indicator, more information, fewer information, other information, or a combination thereof, that may be tracked; para [0210], wherein a system may include a computer-based system, a processor-containing system, or another system that may selectively fetch instructions from an instruction executable system, apparatus, or device that may also execute instructions; para [0188], wherein a user interface, to responder already associated with the incident. The list may be presented in rank order, as described herein. The responder already associated with the incident may select one or more of the recommended responders to associate with the incident. At 810, the one of the recommended responders is associated with the incident; and para [0121], wherein presented to the responder in a user interface of (e.g., generated by) the system 400 (i.e., interactive without navigating). In response to a selection of one or more of the recommended responders, the responder recommendation tool 418 associates the selected recommended responders with the incident, which may cause notifications to be transmitted to the selected recommended responders).
Goswami et al. fails to explicitly disclose using a generative artificial intelligence model configured for an incident management platform.
Analogous art Siracusano discloses generate, based on the relevant post-incident data and using a generative artificial intelligence model configured for an incident management platform (see Siracusano, para [0149], wherein industry reports, news articles, government intelligence reports, and incident response reports; and para [0147], wherein LLM querying procedure is introduced over the recent approaches used in the design of LLM-based generative AI Agents).
Goswami directed to a system for incident that requires a resolution responsive to an event detected in a managed information technology. Siracusano directed to extracting information from reports using large language models. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Goswami, regarding the Smart Incident Responder Recommendation, to have included generate, based on the relevant post-incident data and using a generative artificial intelligence model configured for an incident management platform because both inventions teach resolving issues efficiency. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Goswami et al. fails to explicitly disclose comprises generating a causal graph of one or more services and a fault propagation path based on the causal graph; and generating a root cause segment based on the fault propagation path.
Analogous art Wu discloses determining the fault data comprises generating a causal graph of one or more services and a fault propagation path based on the causal graph (see Wu, pages 25-29, wherein constructs a two-layered hierarchical causality graph, including service dependency graph and metric causality graph of each service, to show the dependency among metrics; and page 42, wherein including component dependencies, anomaly propagation paths, potential consequences of corrective actions, and bottleneck services or metrics; pages 30-31, wherein uses graph centrality algorithms to get the root causes….identifies the faulty services and which resource, like CPU overhead, causes the service performance degradation. It is a proactive method that applies deep learning to massive data to identify root causes……Faulty components are then pinpointed based on the abnormal change propagation patterns and inter-component dependency relationships. PAL can pinpoint the source of faulty components in distributed applications by extracting anomaly propagation patterns); and
Analogous art Wu discloses generating timeline segment, a root cause segment based on the fault propagation path, and a corrective action segment based on the corrective action (see Wu, page 27, wherein diagnose the root causes from tracing data, cluster the end-to-end request tracing into different categories according to request call sequences and select major categories, then extract the abnormal principal methods that might be causes of performance degradation. The Mystery Machine [93] uses traces to create a causal model to show how software components interact during the end-to-end processing or request. Then it uses the causal model to perform several types of distributed systems performance analysis: finding the critical path, quantifying slack for segments not on the critical path, and identifying segments correlated with performance anomalies. Sambasivan et al [107] builds end-to-end request-flow tracing within and across components and identifies the root causes of changes by comparing request flows from two executions (e.g., of two system versions or periods); and pages 30-31, wherein uses graph centrality algorithms to get the root causes….identifies the faulty services and which resource, like CPU overhead, causes the service performance degradation. It is a proactive method that applies deep learning to massive data to identify root causes……Faulty components are then pinpointed based on the abnormal change propagation patterns and inter-component dependency relationships. PAL can pinpoint the source of faulty components in distributed applications by extracting anomaly propagation patterns).
Goswami directed to a system for incident that requires a resolution responsive to an event detected in a managed information technology. Wu directed to monitoring metrics to enhance automatic performance diagnosis and recovery in cloud microservices. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Goswami, regarding the Smart Incident Responder Recommendation, to have included determining the fault data comprises generating a causal graph of one or more services and a fault propagation path based on the causal graph; and generating timeline segment, a root cause segment based on the fault propagation path, and a corrective action segment based on the corrective action because both inventions teach resolving issues efficiency. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Goswami et al. fails to explicitly disclose initiated in response to the incident and configured to enable communication among users to facilitate the resolution of the incident.
Analogous art Puri discloses extracting first corrective action data within one or more communication channels previously initiated in response to the incident and configured to enable communication among users to facilitate the resolution of the incident (see Puri, para [0388], the collaborative incident management system 2210 may retrieve information and updates related to an incident and may display the information and updates in the form of a centralized graphical user interface; and abstract, wherein outputs of such a system may be useful to help a user identify a problem and resolve an incident. Inventive aspects enable user interactions to trigger automatic connection with network servers to establish communication channels for conveying analytics and other information related to the problem between and among network nodes participating in the resolution of the problem or incidents).
Goswami directed to a system for incident that requires a resolution responsive to an event detected in a managed information technology. Puri directed to monitoring collaborative incident. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Goswami, regarding the Smart Incident Responder Recommendation, to have included extracting first corrective action data within one or more communication channels previously initiated in response to the incident and configured to enable communication among users to facilitate the resolution of the incident because both inventions teach improving the performance of components. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claims 2, 10, and 18, Goswami discloses the apparatus of claim 1, wherein the relevant post-incident data comprises timeline data for the incident (see Goswami, para [0034], wherein facilitates incident resolution in an EMB so that mean-time-to-resolution (MTTR) of incidents can be minimized therewith maximizing uptime(s) of components (i.e., MTTR is the average time from when an incident starts to when it is fully resolved).
Claims 3-5, 7-8, 11-13, 15-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Goswami et al. (US Pub No. 2024/0037464) (hereinafter Goswami et al.), in view of Siracusano et al. (US Pub No. 2024/0411994) (hereinafter Siracusano al.), in view of L Wu et al. (Automatic performance diagnosis and recovery in cloud microservices) - 2022 - search.proquest.com (hereinafter Wu al.), in view of Puri et al. (US Pub No. 2020/0328961) (hereinafter Puri et al.), and further in view of Deng et al. (US Pub No. 2024/0330672) (hereinafter Deng al.).
Regarding claims 3, 11, and 19, Goswami discloses the apparatus of claim 2, wherein generating the relevant post-incident data comprises:
extracting one or more incident features from incident data associated with the incident (see Goswami, paras [0163]-[0168], wherein content-based filtering (i.e., extracting), features of previously resolved incidents are used to provide the responder recommendation, such as the incident features);
extracting one or more alert features from alert data associated with the incident (see Goswami, paras [0163]-[0165], wherein filtering, features of the similar incidents and features of responders can be combined to obtain the list of recommended responders. More specifically, features of incidents and features of responders in a historical data set (i.e., a training set) can be used to train a collaborative filtering mode to, given an incident as an input, output a list of recommended responders…..With respect to incident causes, in some cases (i.e., for some incidents), the received alerts may include at least some of cause data. As such, incident causes can be extracted therefrom);
extracting one or more communication features from communication data associated with the incident and within the one or more communication channels (see Goswami, paras [0118]-[0119], wherein various performance characteristics of each message provider may be stored and/or associated with a corresponding provider performance profile……The selected message providers may transmit (e.g., communicate, etc.) the notification message to the responder…..The message providers may generate an acknowledgment message that may be provided to system 400 indicating a delivery status of the notification message (e.g., successful or failed delivery); paras [0165], [0064] & [0079], wherein…..the audio interface 256 may be coupled to a speaker and microphone (not shown) to enable telecommunication with others or generate an audio acknowledgement for some action. A microphone in the audio interface 256 can also be used for input to or control of the client computer 200, e.g., using voice recognition, detecting touch based on sound….Exchanged communications may include, but are not limited to, queries, searches, messages, notification messages, events, alerts, performance metrics, log data, API calls, or the like);
generating, using a sequence labeling model, the (recommendation) data based on the one or more communication features (see Goswami, paras [0158] & [0176], wherein generate, using one or more machine-learning models, a list of recommended responders based an incident type of an incident, a historical frequency of the incident (based on the incident type), the respective skillsets of responders available to address the incident, other data, or a combination thereof. The technique 700 may analyze processed data such as templatized or "tokenized" incident data parsed from the received incident…….Tokenized incidents and incident titles may be generated for use in collaborative filtering algorithms. Tokenization, when applied to a title, may remove new lines, table spaces, and the like, and replace multiple consecutive white spaces with a single whitespace. Another example of tokenization may be when the recommendation engine processes an incident title, identifies any substring that may indicate a time (e.g., a date, a timestamp, a date and time) and replaces the time with the token ( e.g., string) "datetime."; and paras [0118]-[0119], wherein various performance characteristics of each message provider may be stored and/or associated with a corresponding provider performance profile……The selected message providers may transmit (e.g., communicate, etc.) the notification message to the responder…..The message providers may generate an acknowledgment message that may be provided to system 400 indicating a delivery status of the notification message (e.g., successful or failed delivery); and
generating the fault data based on one or more of (i) the one or more incident features or (ii) the one or more alert features (see Goswami, para [0039], wherein incidents may be a failure or error that occurs in the operation of a managed network and/or computing environment. One or more events may be associated
with one or more incidents; and paras [0165]-[0166], wherein with respect to incident causes, in some cases (i.e., for some incidents), the received alerts may include at least some of cause data…..incident features can include resolution data, which can be data relating to how incidents were resolved).
Goswami et al., Siracusano et al., Wu et al., and Puri et al. combined fail to explicitly disclose using a sequence labeling model, the corrective action data.
Analogous art Deng discloses generating, using a sequence labeling model, the corrective action data (see Deng, para [0040], wherein supervised sequence labeling tasks such as a long term short term memory conditional random field (LSTM-CRF) model….the input device of the mitigation guidance system receives labeled data 215 which includes closing notes 220 and sends the labeled data 215 which includes the closing notes 220 to the split labeled data module 230; para [0041], wherein corpus generation module 235 and the closing notes 220, the trained sequence tagger module 240…extracts a textual sequence which corresponds with the issue and the resolution of the issue (i.e., corrective action)).
Goswami directed to a system for incident that requires a resolution responsive to an event detected in a managed information technology. Deng directed to generation of mitigation information based on corrective action extraction. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Goswami, regarding the Smart Incident Responder Recommendation, to have included generating, using a sequence labeling model, the corrective action data because both inventions teach resolving issues efficiency. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claims 4, 12, and 20, Goswami discloses the apparatus of claim 3, wherein the sequence labeling model, as set forth above with claim 3.
Goswami et al. fails to explicitly disclose BILSTM-CRF.
Analogous art Siracusano discloses BILSTM-CRF (see Siracusano, para [0269]).
One of ordinary skill in the art would have recognized that applying the known technique of Siracusano would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 1.
Regarding claims 5 and 13, Goswami discloses the apparatus of claim 3, wherein generating the fault data comprises:
identifying, based on the alert data, one or more services associated with the incident (see Goswami, paras [0113]-[0115], wherein can identify or can help in identifying causes of the incident or actions that might resolve the incident…..the resolution tracker 412 can receive data from the different services that process events, alerts, or incidents).
Goswami et al., Siracusano et al., and Deng et al. fails to explicitly disclose identifying, using a graph centrality model, initial fault location; and generating, using a link prediction model, a fault propagation path.
Analogous art Wu discloses identifying, using a graph centrality model, initial fault location (see Wu, pages 29-30, wherein uses graph centrality algorithms to get the root causes; page 30, wherein identifies the faulty services and which resource, like CPU overhead, causes the service performance degradation. It is a proactive method that applies deep learning to massive data to identify root causes); and
generating, using a link prediction model, a fault propagation path (see Wu, pages 28 & 87, wherein causal inference, three types of causal properties are considered: (1) propagation across services; (2) propagation across resource and service-related metrics of linked service and container nodes; (3) propagation across resource metrics of linked container and server nodes; and page 28, wherein predict latent errors, faulty microservices, and fault types for traces captured at runtime….. Dependency inference learns the relationship between interconnected components for problem diagnosis, particularly when localizing the source of the problem that propagates across a distributed system. Specific insights sought by dependency inference include service dependencies, request or call paths, deployment information, and transaction tracking through a distributed system).
One of ordinary skill in the art would have recognized that applying the known technique of Wu would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 3.
Regarding claims 7 and 15, Goswami discloses the apparatus of claim 6, wherein ranking, using a learning-to-rank model and based on user input, the (recommendation) action data (see Goswami, para [0160], wherein a list of recommended responders is obtained. The list of recommended responders can be obtained based at least in part on the type of the incident, as described herein. The list of recommended responders may be a ranked list of responders. The list may be ranked based on respective scores output by the machine-learning model used to generate the list of recommended responders. In the case of a novel incident, the responders may be ranked based on respective seniority scores of the recommended responders).
Goswami et al. fails to explicitly disclose generating the corrective action data further comprises ranking, the corrective action data.
Analogous art Deng discloses generating the corrective action data further comprises ranking, the corrective action data (see Deng, para [0040], wherein supervised sequence labeling tasks such as a long term short term memory conditional random field (LSTM-CRF) model….the input device of the mitigation guidance system receives labeled data 215 which includes closing notes 220 and sends the labeled data 215 which includes the closing notes 220 to the split labeled data module 230; para [0041], wherein corpus generation module 235 and the closing notes 220, the trained sequence tagger module 240…extracts a textual sequence which corresponds with the issue and the resolution of the issue (i.e., corrective action)).
One of ordinary skill in the art would have recognized that applying the known technique of Deng would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 3.
Regarding claims 8 and 16, Goswami discloses the 8. The apparatus of claim 1, wherein the one or more machine learning models, as set forth above with claim 1 .
Goswami et al. and Deng et al. fails to explicitly disclose generative artificial intelligence.
Analogous art Siracusano discloses generative artificial intelligence (see Siracusano, para [0147], wherein LLM querying procedure is introduced over the recent approaches used in the design of LLM-based generative AI).
One of ordinary skill in the art would have recognized that applying the known technique of Siracusano would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 1.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Goswami et al. (US Pub No. 2024/0037464) (hereinafter Goswami et al.), in view of Siracusano et al. (US Pub No. 2024/0411994) (hereinafter Siracusano al.), in view of L Wu et al. (Automatic performance diagnosis and recovery in cloud microservices) - 2022 - search.proquest.com (hereinafter Wu al.), in view of Puri et al. (US Pub No. 2020/0328961) (hereinafter Puri et al.), in view of Deng et al. (US Pub No. 2024/0330672) (hereinafter Deng al.), and further in view of in view of Anderson et al. (US Pub No. 9,824,093) (hereinafter Anderson al.).
Regarding claims 6 and 14, Goswami discloses the apparatus of claim 3, wherein generating the corrective action data comprises
data extracted from the communication data based on the one or more communication features (see Goswami, paras [0165]-[0166], wherein (i.e., for some incidents), the received alerts may include at least some of cause data. As such, incident causes can be extracted therefrom……incident features can include resolution data, which can be data relating to how incidents were resolved).
Goswami et al., Siracusano et al., Wu et al., Puri et al., and Deng et al. combined fail to explicitly disclose performing deduplication operation with respect to the first corrective action data and second corrective action data extracted from one or more other data sources, wherein the corrective action data comprises deduplicated corrective action data.
Analogous art Anderson discloses performing deduplication operation with respect to the first corrective action data and second corrective action data extracted from one or more other data sources, wherein the corrective action data comprises deduplicated corrective action data (see Anderson, column 8, lines 52-67, wherein the executor module 416 then resolves the issues in the queue 414 by performing one or more of a reconstruction or repair operation, a garbage collection operation, a deduplication operation, and/or a scrubbing operation, all of which are examples of maintenance or data protection operations……This could result in a situation where the newly uploaded data object is identified as garbage and deleted from the data nodes. As a result, object fragments or data objects may be associated with aging. Anew data object may be associated with an age window (e.g., 30 days) that prevents the repair component (e.g., the executor module) from performing certain operations ( e.g., garbage collection); column 9, lines 11-26, wherein deduplication (remove object fragments that are redundant), repair (when less than the optimal number of object fragments are found and the data object can still be reconstructed), garbage collection (remove all object fragments associated with a data object because the data object is no longer referenced in any manifest), and scrub (some fragments exist, but not enough to reconstruct the data object). In a scrub action, an upload of the data object from the client is forced by removing the reference of the data object in the manifests. The scrub action may leave old data object fragments around but they will be garbage collected or deduplicated during the next scan after the new upload to the data center. Alternatively, the data object fragments will be deduplicated if the new uploaded data object has not changed and therefore has the same hash value).
Goswami directed to a system for incident that requires a resolution responsive to an event detected in a managed information technology. Anderson directed to performing a maintenance operation. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Goswami, regarding the Smart Incident Responder Recommendation, to have included performing deduplication operation with respect to the first corrective action data and second corrective action data extracted from one or more other data sources, wherein the corrective action data comprises deduplicated corrective action data because both inventions teach resolving issues efficiency. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior arts made of record and not relied upon is considered pertinent to applicant's disclosure. (US Pub No. 2023/0028408).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAFIZ A KASSIM whose telephone number is (571)272-8534. The examiner can normally be reached 9:00 - 5:00 PM.
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, Rutao Wu can be reached at 571-272-6045. 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.
/HAFIZ A KASSIM/Primary Examiner, Art Unit 3623 09/21/2026
Prosecution Insights