DETAILED ACTION
This is a non-final, first office action on the merits. 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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of application No. 18/391,026.
This is a provisional double patenting rejection since the conflicting claims have not yet been patented.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over respective corresponding Claims 1-20 of application No. 18/391,026 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the current application claims can be anticipated by the reference application claims.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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 “in response to a qualifying incident management event associated with an incident, identify data associated with the incident; extracting, from one or more data sources, one or more data features associated with an incident corresponding to the incident identifier; identifying an incident identifier that satisfies post-incident report generation criteria; generating a post-incident report based on the one or more data features and using models; transmitting the post-incident report; receive a post-incident report request, wherein the post-incident report request comprises an incident identifier; generate, based on the one or more data features and using models, post-incident data associated with the incident identifier; and initiate performance of one or more incident management actions using a model and based on the post-incident data”.
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 a user interface, enterprise applications, a generative artificial intelligence model, 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 7-8 and 15-16 do not include any additional elements beyond those recited with respect to claims 1, 9, and 17. As a result, claims 7-8 and 15-16 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 2-6, 10-14, and 18-20 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 2-6, 10-14, and 18-20 include a user interface, a generative artificial intelligence model, machine learning models, communication channels, enterprise applications, a computing device, and one or more computer-executable instructions. 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 2-6, 10-14, and 18-20 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 a user interface, a generative artificial intelligence model, 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 7-8 and 15-16 do not include any additional elements beyond those recited with respect to claims 1, 9, and 17. As a result, claims 7-8 and 15-16 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 2-6, 10-14, and 18-20 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 2-6, 10-14, and 18-20 include a user interface, a generative artificial intelligence model, machine learning models, communication channels, enterprise applications, a computing device, and one or more computer-executable instructions. 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 2-6, 10-14, and 18-20 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 § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 9-13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Goswami et al. (US Pub No. 2024/0037464) (hereinafter Goswami et al.), hereinafter Goswami.
Regarding claim 9, Goswami discloses a computer-implemented method, comprising:
identifying an incident identifier that satisfies post-incident report generation criteria (see Goswami, para [0142], wherein a first title resolvable object has a first title "CRITICALticket 310846 issued" and a second resolvable object has a second title "CRITICAL-ticket 310849 issued." (i.e., an incident identifier ticket 310849 issued qualifies for a post-incident report it meets criteria such as incident is classified as a high severity CRITICAL));
extracting, from one or more data sources, one or more data features associated with an incident corresponding to the incident identifier (see Goswami, para [0109], wherein databases, one or more XML databases, one or more operating system files, one or more unstructured data databases, one or more synchronous or asynchronous event…; paras [0165]-[0166], wherein 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…..incident features can include resolution data, which can be data relating to how incidents were resolved; and para [0142], wherein a first title resolvable object has a first title "CRITICALticket 310846 issued" and a second resolvable object has a second title "CRITICAL-ticket 310849 issued." (i.e., an incident identifier ticket 310849 issued qualifies for a post-incident report it meets criteria such as incident is classified as a high severity CRITICAL));
generating a post-incident report based on the one or more data features and using one or more machine learning models (see Goswami, para [0158], 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; and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful); and
transmitting one or more computer-executable instructions configured to cause rendering of the post-incident report on a post-incident report user interface (see Goswami, para [0024], wherein investigate the incident (or, equivalently, the alert that triggered the incident) and (ultimately) perform or cause to be performed actions that resolve the incident. The responder may indicate that the incident has been resolved using an interface (e.g., a graphical user interface) of the EMB; para [0108], wherein such events may include facts regarding system errors, warning, failure reports, customer service requests, status messages, or the like…..that may be tracked; 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 paras [0111]-[0112] & [0188], 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).
Regarding claim 10, Goswami discloses the computer-implemented method of claim 9, wherein the one or more data sources correspond to one or more enterprise applications (see Goswami, para [0053], wherein monitor the performance of computer operations for an entity (e.g., company or enterprise). For example, the monitoring server computer 114 may be arranged to monitor whether applications/systems are operational, network performance, trouble tickets and/or their resolution).
Regarding claim 11, Goswami discloses the computer-implemented method of claim 10, wherein the one or more data features comprise alert features, wherein extracting the one or more data features comprises:
identifying alert data maintained via at least one enterprise application of the one or more enterprise applications (see Goswami, para [0079], wherein FIG. 1, the monitoring server computer 114 of FIG. 1, the application server computer 112 of FIG. 1, or the like. 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, combination thereof);
generating one or more vector representations of the alert data (see Goswami, para [0151], wherein incident (or alert) titles may be normalized to obtain normalized titles. The normalized titles can be tokenized, cleaned, and vectorized. Tokenizing can split the normalized title into words and/or groups of groups (collectively, n-grams), typically using special characters and/or white spaces to identify then-grams. Cleaning (e.g., normalizing) the words of the normalized title, which may be performed before or after the tokenizing, can include zero or more of stemming, removing stop words (e.g., very common, words that do not add value to the title) from the word vector, other steps, or a combination thereof. Vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model)); and
inputting the one or more vector representations of the alert data into a machine learning model configured to generate the alert features based on the one or more vector representations (see Goswami, paras [0151] & [0171], wherein Cosine similarities or cosine similarity is a metric used to measure the similarity between features of two items, documents, or the like, represented as feature vectors……incident (or alert) titles may be normalized to obtain normalized titles. The normalized titles can be tokenized, cleaned, and vectorized…..Vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model); and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful)).
Regarding claim 12, Goswami discloses the computer-implemented method of claim 10, wherein the one or more data features comprise incident features, wherein extracting the one or more data features comprises:
identifying incident data maintained via at least one enterprise application of the one or more enterprise applications (see Goswami, para [0034], wherein incidents are identified based on a historical collection of incidents (such as a database or a training set) used in conjunction with historical incidents and expertise of responders or responder teams involved (e.g., associated) with those historical incidents; para [0079], wherein Fig. 1, the monitoring server computer 114 of FIG. 1, the application server computer 112 of FIG. 1, or the like. 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, combination thereof);
generating one or more vector representations corresponding to the incident data (see Goswami, para [0151], wherein incident (or alert) titles may be normalized to obtain normalized titles. The normalized titles can be tokenized, cleaned, and vectorized. Tokenizing can split the normalized title into words and/or groups of groups (collectively, n-grams), typically using special characters and/or white spaces to identify then-grams. Cleaning (e.g., normalizing) the words of the normalized title, which may be performed before or after the tokenizing, can include zero or more of stemming, removing stop words (e.g., very common, words that do not add value to the title) from the word vector, other steps, or a combination thereof. Vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model)); and
inputting the one or more vector representations into a machine learning model configured to generate the incident features based on the one or more vector representations (see Goswami, paras [0151] & [0171], wherein Cosine similarities or cosine similarity is a metric used to measure the similarity between features of two items, documents, or the like, represented as feature vectors……incident (or alert) titles may be normalized to obtain normalized titles. The normalized titles can be tokenized, cleaned, and vectorized…..Vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model); and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful)).
Regarding claim 13, Goswami discloses the computer-implemented method of claim 10, wherein the one or more data features comprise communication features, wherein extracting the one or more data features comprises:
identifying communication data maintained via at least one enterprise application of the one or more enterprise applications (see Goswami, para [0079], wherein FIG. 1, the monitoring server computer 114 of FIG. 1, the application server computer 112 of FIG. 1, or the like. 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, combination thereof);
generating one or more vector representations corresponding to the communication data (see Goswami, para [0151], wherein vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model)); and
inputting the one or more vector representations into a machine learning model configured to generate the communication features based on the one or more vector representations (see Goswami, paras [0151] & para [0171], wherein Cosine similarities or cosine similarity is a metric used to measure the similarity between features of two items, documents, or the like, represented as feature vectors……incident (or alert) titles may be normalized to obtain normalized titles. The normalized titles can be tokenized, cleaned, and vectorized…..Vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model); and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful)).
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-8 and 14-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 Thompson et al. (US Pub No. 2024/0340301) (hereinafter Thompson al.).
Regarding claim 1, Goswami discloses an apparatus comprising at least one processor and at least one memory including program code, the at least one memory and the program code configured to, with the at least one processor (see Goswami, Fi. 2), cause the apparatus to at least:
in response to a qualifying incident management event associated with an incident, identify one or more enterprise applications comprising data associated with the incident (see Goswami, para [0053], wherein the monitoring server computer 114 represents various computers that may be arranged to monitor the performance of computer operations for an entity (e.g., company or enterprise); para [0007], wherein the operations include triggering an incident that requires a resolution responsive to an event detected in a managed information technology environment; and para [0021], wherein events (or causes that may have triggered or resulted in the events) include that a particular cloud-based service is down, that a particular database is unresponsive, that a particular product line is exhibiting issue (such as system errors in web applications or web services applications), that a web server is down (resulting in customers being unable to access a website offered by the web server); that a particular database is corrupted (such as due to a hardware failure);
extract, from the one or more enterprise applications, one or more data features (see Goswami, para [0053], wherein the monitoring server computer 114 represents various computers that may be arranged to monitor the performance of computer operations for an entity (e.g., company or enterprise); and para [0165]-[0166], wherein 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…..incident features can include resolution data, which can be data relating to how incidents were resolved);
generate, based on the one or more data features and using one or more machine learning models, post-incident data associated with the incident (see Goswami, para [0158], 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; and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful); and
initiate performance of one or more incident management actions using a (machine learning) model and based on the post-incident data (see Goswami, para [0053], wherein the monitoring server computer 114 represents various computers that may be arranged to monitor the performance of computer operations for an entity (e.g., company or enterprise); paras [0028] & [0028], wherein investigate the incident (or, equivalently, the alert that triggered the incident) and (ultimately) perform or cause to be performed actions that resolve the incident; para [0120], wherein a machine-learning model recommendation engine; 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 [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).
Goswami et al. fails to explicitly disclose using a generative artificial intelligence model.
Analogous art Thompson discloses initiate performance of one or more incident management actions using a generative artificial intelligence model and based on the post-incident data (see Thompson, para [0054], wherein trigger a first set of actions based on a first type of detected event….; para [0099], wherein the performance dataset 165 includes diverse sets of data, including threat data, actor data, vector data, incident data, claim data, capability data, vendor data, organization data, and team member data. These performance-related datasets capture information for assessing the organization's security posture, incident history, and overall operational performance. They enable effective monitoring, analysis, and decision-making in incident response activities; para [0267], wherein leverage generative artificial intelligence (AI) algorithms to enhance the security posture analysis. Generative AI algorithms can analyze large volumes of data from various sources, such as threat intelligence feeds, incident reports, and security best practices, to identify patterns, trends, and potential vulnerabilities that human analysts may not have detected; and para [0267], wherein past incidents consist of resolved threats or breaches and serve as a historical record of the entity's cybersecurity events).
Goswami directed to a system for incident that requires a resolution responsive to an event detected in a managed information technology. Thompson directed to utilizing one or more protection parameters cybersecurity protection plan corresponding to a new cybersecurity attribute to protect the entity. 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 initiate performance of one or more incident management actions using a generative artificial intelligence model and based on the post-incident data because both inventions teach improving incident response plan. 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 claim 2, Goswami discloses the apparatus of claim 1, wherein initiating performance of the one or more incident management actions comprises:
generating, based on the post-incident data and using the (machine learning) model, a post-incident report for the incident (see Goswami, para [0158], 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; para [0108], wherein such events may include facts regarding system errors, warning, failure reports, customer service requests, status messages, or the like. One or more external services, at least some of which may be monitoring services, may collect events and provide the events to the system 400. 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 [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 [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).
Goswami et al. fails to explicitly disclose using the generative artificial intelligence model.
Analogous art Thompson discloses generating, based on the post-incident data and using the generative artificial intelligence model, a post-incident report for the incident (see Thompson, para [0054], wherein trigger a first set of actions based on a first type of detected event….; para [0121], wherein the IRC system 138 can collect and aggregate relevant data. This can include gathering information from various sources such as incident reports, security logs, system alerts, and user-generated data; para [0267], wherein leverage generative artificial intelligence (AI) algorithms to enhance the security posture analysis. Generative AI algorithms can analyze large volumes of data from various sources, such as threat intelligence feeds, incident reports, and security best practices, to identify patterns, trends, and potential vulnerabilities that human analysts may not have detected; and para [0267], wherein past incidents consist of resolved threats or breaches and serve as a historical record of the entity's cybersecurity events).
One of ordinary skill in the art would have recognized that applying the known technique of Thompson would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 1.
Regarding claim 3, Goswami discloses the apparatus of claim 2, wherein initiating performance of the one or more incident management actions further comprise:
transmitting the post-incident report to an enterprise application of the one or more enterprise applications (see Goswami, para [0108], wherein such events may include facts regarding system errors, warning, failure reports, customer service requests, status messages, or the like. One or more external services, at least some of which may be monitoring services, may collect events and provide the events to the system 400. 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 [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 [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).
Regarding claim 4, Goswami discloses the apparatus of claim 2, wherein initiating performance of one or more incident management actions further comprise:
transmitting one or more computer-executable instructions configured to cause rendering of a post-incident report interface on a client computing device, wherein the post-incident report interface comprises the post-incident report (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).
Regarding claim 5, Goswami discloses the apparatus of claim 1, wherein the one or more data features comprise alert features, wherein extracting the one or more data features comprises:
identifying alert data maintained via at least one enterprise application of the one or more enterprise applications (see Goswami, para [0079], wherein FIG. 1, the monitoring server computer 114 of FIG. 1, the application server computer 112 of FIG. 1, or the like. 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, combination thereof);
generating one or more vector representations corresponding to the alert data (see Goswami, para [0151], wherein incident (or alert) titles may be normalized to obtain normalized titles. The normalized titles can be tokenized, cleaned, and vectorized. Tokenizing can split the normalized title into words and/or groups of groups (collectively, n-grams), typically using special characters and/or white spaces to identify then-grams. Cleaning (e.g., normalizing) the words of the normalized title, which may be performed before or after the tokenizing, can include zero or more of stemming, removing stop words (e.g., very common, words that do not add value to the title) from the word vector, other steps, or a combination thereof. Vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model)); and
inputting the one or more vector representations into a machine learning model configured to generate the alert features based on the one or more vector representations (see Goswami, paras [0151] & [0171], wherein Cosine similarities or cosine similarity is a metric used to measure the similarity between features of two items, documents, or the like, represented as feature vectors……incident (or alert) titles may be normalized to obtain normalized titles. The normalized titles can be tokenized, cleaned, and vectorized…..Vectorizing can mean converting the n-grams into respective vector representations of numbers based on all the words identified in the training dataset (i.e., all words of the normalized titles used for training the ML, model); and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful)).
Regarding claim 6, Goswami discloses the apparatus of claim 1, wherein the one or more data features comprise one or more of (i) incident features, (ii) alert features, or (iii) communication features extracted from one or more communication channels generated via at least one enterprise application of the one or more enterprise applications (see Goswami, para [0163], wherein features of incidents in a historical data set (i.e., a training set)).
Regarding claim 7, Goswami discloses the apparatus of claim 1, wherein the post-incident data comprises fault data that identifies a faulty service of one or more services (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).
Regarding claim 8, Goswami discloses the apparatus of claim 7, wherein the post-incident data further comprise root cause data for the incident (see Goswami, para [0021], wherein underlying cause that caused the event to be generated), wherein generating the post-incident data comprises:
performing one or more inference operations to generate the root cause data based on one or more of alert features or incident features from the one or more data features (see Goswami, para [0139], wherein the classifier 502 uses historical data of observable objects to obtain (e.g., determine, choose, infer, identify, output, derive, etc.) a type for the resolvable object 508; para [0021], wherein underlying cause that caused the event to be generated. Additional examples of events ( or causes that may have triggered or resulted in the events) include that a particular cloud-based service is down, that a particular database is unresponsive, that a particular product line is exhibiting issue (such as system errors in web applications or web services applications), that a web server is down (resulting in customers being unable to access a website offered by the web server); that a particular database is corrupted (such as due to a hardware failure); and para [0163], wherein features of incidents in a historical data set (i.e., a training set));
Further, Analogous art Thompson discloses root cause data for the incident comprises: performing one or more inference operations to generate the root cause data based on one or more of alert features or incident features from the one or more data features (see Thompson, para [0044], wherein this includes capabilities pre-incident, what happened after the incident occurred, what was the root cause, and recording. For example, results are traceable and linkable, and issues are identified, tasks are created, work is routed to vendors, and proof of resolution is recorded…..the response system 130 can include a drag and drop file tokenization feature that allows users to securely tokenize and store sensitive files. In particular, this feature is useful when organizations desire to share sensitive information with third parties or with internal stakeholders. The system ensures that the information is secure and that only authorized parties can access it. Thus, this feature is designed to streamline the incident response process and enable better collaboration between all stakeholders).
One of ordinary skill in the art would have recognized that applying the known technique of Thompson would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 1.
Regarding claim 14, Goswami discloses the computer-implemented method of claim 9, wherein generating the post-incident report based on the one or more data features comprises:
generating post-incident data based on the one or more data features (see Goswami, para [0158], 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; and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful); and
generating the post-incident report using a (machine learning) model and based on the one or more data features (see Goswami, para [0158], 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; para [0108], wherein such events may include facts regarding system errors, warning, failure reports, customer service requests, status messages, or the like. One or more external services, at least some of which may be monitoring services, may collect events and provide the events to the system 400. 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; and paras [0164]-[0166], 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….the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful; 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).
Goswami et al. fails to explicitly disclose using the generative artificial intelligence model.
Analogous art Thompson discloses generating the post-incident report using a generative artificial intelligence model and based on the one or more data features (see Thompson, para [0054], wherein trigger a first set of actions based on a first type of detected event….; para [0121], wherein the IRC system 138 can collect and aggregate relevant data. This can include gathering information from various sources such as incident reports, security logs, system alerts, and user-generated data; para [0267], wherein leverage generative artificial intelligence (AI) algorithms to enhance the security posture analysis. Generative AI algorithms can analyze large volumes of data from various sources, such as threat intelligence feeds, incident reports, and security best practices, to identify patterns, trends, and potential vulnerabilities that human analysts may not have detected; and para [0267], wherein past incidents consist of resolved threats or breaches and serve as a historical record of the entity's cybersecurity events).
One of ordinary skill in the art would have recognized that applying the known technique of Thompson would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 1.
Regarding claim 15, Goswami discloses the computer-implemented method of claim 14, wherein the post-incident data comprises fault data that identifies a faulty service of one or more services, as set forth above with claim 7.
Regarding claim 16, Goswami discloses the computer-implemented method of claim 14, wherein the post-incident data comprise root cause data for the incident, wherein generating the post-incident data comprises:
performing one or more inference operations based on alert features and incident features from the one or more data features to generate the root cause data, as set forth above with claim 8.
Regarding claim 17, Goswami discloses 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), when executed by at least one processor:
receive a post-incident report request via a post-incident report interface, wherein the post-incident report request comprises an incident identifier (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…..; para [0188], wherein a user interface, to responder already associated with the incident; para [0121], wherein presented to the responder in a user interface of (e.g., generated by) the system 400 (i.e., interactive without navigating); and para [0142], wherein a first title resolvable object has a first title "CRITICALticket 310846 issued" and a second resolvable object has a second title "CRITICAL-ticket 310849 issued." (i.e., an incident identifier ticket 310849 issued qualifies for a post-incident report it meets criteria such as incident is classified as a high severity CRITICAL));
extract, from one or more data sources and based on the incident identifier, one or more data features (see Goswami, para [0109], wherein databases, one or more XML databases, one or more operating system files, one or more unstructured data databases, one or more synchronous or asynchronous event…; paras [0165]-[0166], wherein 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…..incident features can include resolution data, which can be data relating to how incidents were resolved; and para [0142], wherein a first title resolvable object has a first title "CRITICALticket 310846 issued" and a second resolvable object has a second title "CRITICAL-ticket 310849 issued." (i.e., an incident identifier ticket 310849 issued qualifies for a post-incident report it meets criteria such as incident is classified as a high severity CRITICAL));
generate, based on the one or more data features and using one or more machine learning models, post-incident data associated with the incident identifier (see Goswami, para [0158], 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; and paras [0164]-[0166], wherein the features of incidents can include the tokens associated with the incidents, the skills associated with the incidents (e.g., skills identified as being required or helpful); and para [0142], wherein a first title resolvable object has a first title "CRITICALticket 310846 issued" and a second resolvable object has a second title "CRITICAL-ticket 310849 issued." (i.e., an incident identifier ticket 310849 issued qualifies for a post-incident report it meets criteria such as incident is classified as a high severity CRITICAL)); and
initiate performance of one or more incident management actions using a generative artificial intelligence model and based on the post-incident data, as set forth above with claim 1.
Regarding claim 18, Goswami discloses the at least one non-transitory computer-readable storage medium of claim 17, wherein initiating performance of the one or more incident management actions comprises:
generating, based on the post-incident data and using a generative artificial intelligence model, a post-incident report, as set forth above with claim 2.
Regarding claim 19, Goswami discloses the at least one non-transitory computer-readable storage medium of claim 18, wherein initiating performance of the one or more incident management actions further comprise:
transmitting the post-incident report to one or more enterprise applications, as set forth above with claim 3.
Regarding claim 20, Goswami discloses the at least one non-transitory computer-readable storage medium of claim 18, wherein initiating the performance of the one or more incident management actions further comprise:
transmitting one or more computer-executable instructions configured to cause rendering of a post-incident report interface on a client computing device, wherein the post-incident report interface comprises the post-incident report, as set forth above with claim 4.
Conclusion
The prior arts made of record and not relied upon is considered pertinent to applicant's disclosure. (US Pub No. 2016/0162804; US Pub No. 2020/0057953; US Pub No. 2020/0372367; US Pub No. 2023/0360058; US Pub No. 2023/0105304; US Pub No. 2022/0215325; US Pub No. 2023/0305549; US Pub No. 2022/0358005; US Pub No. 2022/0383256; US Pub No. 2022/0114041; US Pub No. 2019/0318288; US Pat No. 2024/0248783; US Pub No. 2017/0178038; US Pub No. 2023/0028408; US Pub No. 2013/0055399; US Pub No. 2020/0159600; US Pat No. 2020/0201989; US Pub No. 2020/0089765; US Pat No. 11,188,411; and L Wu et al. (Automatic performance diagnosis and recovery in cloud microservices) - 2022 - search.proquest.com.
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 10/05/2026
