Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This action is in response to the application filed 8/9/2024.
2. Claims 1-20 have been examined and are pending in the application.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
3. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pinel U.S Patent No. 8,903,923 in view of Arendt U.S Patent No. 10,977,001.
As to claim 1, Pinel teaches a method, comprising:
receiving an event (…an event alert is received…, lines 19-20 column 4) from a managed organization (…used to manage events received by the enterprise console 112…, lines 18-19 column 4);
determining that the event is of a likely transient type (…a determination is made as to whether the alert is non-actionable…, lines 20-21 column 4); and
in response to determining that the event is of the likely transient type, withholding performance of an action for a pause period (…If the alert is non-actionable, the process proceeds to step 206 and a waiting time is imposed…, lines 22-24 column 4), wherein the action comprises triggering an alert responsive to the event, and wherein performing the action comprises triggering an incident responsive to the alert (…After the waiting time has elapsed, at step 210, a determination is made as to whether the alert has cleared. If the alert has not cleared, the process proceeds to step 240 and a ticket is created..., lines 24-28 column 4).
Pinel does not teach normalizing the event to obtain a normalized event.
Arendt teaches a system of event notification (…The event information for each event received by event platform 200 from event source 110 may comprise various data characteristics…, lines 7-9 column 3) wherein the system normalizing an event to obtain a normalized event (…The normalization microservice may be configured to manipulate or alter the event information received from event source 110 into a desired format. The desired format may be a common format which all normalized event information (i.e., event information received from any event source 110 that has been processed by the normalization microservice) may assume. Normalizing event information into a desired format may comprise, for example, changing a field name of the event information (e.g., transforming data into different field names) or transforming a data value in the event information into a data value that is recognized within event platform 200 and/or event pipeline 210…, line 62 column 4 to line 7 column 5…; ….For example, event information from event source 110 may be received by event pipeline 210 entitled “event name,” and the normalization microservice may alter the event information such that the title is “event name and description.”…, lines 41-45 column 7).
It would have been obvious before the effective filing date of the claimed invention to a person of ordinary skill in the art to have modified Pinel reference to include the teachings of Arendt reference because by normalizing an event to obtain a normalized event, the system could map disparate incoming event information from different event sources into a common internal format so that the processing of the events is uniform, as disclosed by Arendt (lines 28-31 column 7).
As to claim 2, Pinel as modified further teaches determining whether the alert is of the likely transient type (…a determination is made as to whether the alert is non-actionable…, lines 20-21 column 4).
Pinel does not teach obtaining a normalized title from a title of the alert.
Arendt teaches obtaining a normalized title from a title of the alert (…The normalization microservice may be configured to manipulate or alter the event information received from event source 110 into a desired format. The desired format may be a common format which all normalized event information (i.e., event information received from any event source 110 that has been processed by the normalization microservice) may assume. Normalizing event information into a desired format may comprise, for example, changing a field name of the event information (e.g., transforming data into different field names) or transforming a data value in the event information into a data value that is recognized within event platform 200 and/or event pipeline 210…, line 62 column 4 to line 7 column 5…; ….For example, event information from event source 110 may be received by event pipeline 210 entitled “event name,” and the normalization microservice may alter the event information such that the title is “event name and description.”…, lines 41-45 column 7). Note the discussion of claim 1 above for the reason of combining references.
As to claim 3, Pinel as modified further teaches using a rolling table to track a last predetermined number of alerts, how long those alerts took to resolve, and how those alerts were resolved (…In order to make these determinations, embodiments of the present invention provide for a process 400 of data collection and analysis. At step 402, data relating to recent tickets and events is collected. At step 404, raw data relating to the tickets and events is preprocessed. At step 406, predictive rules for identifying non-actionable alerts are generated…,, lines 56-63 column 4;… a process 700 for generating non-actionable alert predictive rules. For an alert event e, e.label denotes the label and e.duration denotes the duration. At step 702, the non-actionable alerts whose duration is longer than delaymax are removed because they may not be transient. At step 704, historical data are mined to obtain predictive rules from the historical data stored in the event database 116 and the ticket tracking database 122…, lines 36-44 column 6); and
determining that the alert is of the likely transient type if a minimum number of the last predetermined number matching the normalized title of the alert were transient (…The rule generator 514 may suitably employ two criteria to quantify the minimum predictive power: a minimum confidence mincon f and a minimum support minsup. For example, the criterion for mincon f may be that for each predictive rule found, the value of mincon f must be 0.9, that is, at least 90% of the covered historical alerts are non-actionable. The criterion for minsup f may be that at least 10% of historical alerts are covered by the rule. To achieve the best possible performance, the rule generator 514 may loop through values for mincon f and minsup and compute performance for each pair of values…, lines 56-67 column 5).
As to claim 4, Pinel as modified further teaches using a prediction table to track a number of resolved alerts matching the normalized title within a history period (…In order to make these determinations, embodiments of the present invention provide for a process 400 of data collection and analysis. At step 402, data relating to recent tickets and events is collected. At step 404, raw data relating to the tickets and events is preprocessed. At step 406, predictive rules for identifying non-actionable alerts are generated…,, lines 56-63 column 4;… a process 700 for generating non-actionable alert predictive rules. For an alert event e, e.label denotes the label and e.duration denotes the duration. At step 702, the non-actionable alerts whose duration is longer than delaymax are removed because they may not be transient. At step 704, historical data are mined to obtain predictive rules from the historical data stored in the event database 116 and the ticket tracking database 122…, lines 36-44 column 6); and
determining that the alert is of the likely transient type responsive to identifying that, of resolved alerts matching the normalized title within the history period, at least a threshold number of the resolved alerts were identified as transient (…The rule generator 514 may suitably employ two criteria to quantify the minimum predictive power: a minimum confidence mincon f and a minimum support minsup. For example, the criterion for mincon f may be that for each predictive rule found, the value of mincon f must be 0.9, that is, at least 90% of the covered historical alerts are non-actionable. The criterion for minsup f may be that at least 10% of historical alerts are covered by the rule. To achieve the best possible performance, the rule generator 514 may loop through values for mincon f and minsup and compute performance for each pair of values…, lines 56-67 column 5).
As to claim 5, Arendt further teaches using a machine learning model (…event platform 200 and/or event pipeline 210 may comprise a machine learning engine (e.g., comprised in analysis system 216, or any other suitable location). The machine learning engine may be configured to monitor problems and the resulting remedies, and continually learn to identify problems with the functional health of a system (e.g., event source 110) and the associated solution. In various embodiments, the machine learning engine may be configured to identify a problem and necessary solution, and automatically implement such a solution. Therefore, the solution to a problem may not require manual interference, and can simply be resolved automatically. The normalization of incoming event information may facilitate greater efficiency in event platform 200, analysis system 216, and/or the machine learning engine identifying problems and solutions because all normalized event information will comprise the same format…, lines 21-37 column 11) that takes as input a vectorized normalized title derived from the normalized title (…For example, event information from event source 110 may be received by event pipeline 210 entitled “event name,” and the normalization microservice may alter the event information such that the title is “event name and description.” Normalization may affect all event information associated with an event, or at least one piece of event information associated with an event. As another example, the normalization microservice may transform values of data characteristics comprised in the event information to a recognized value (i.e., a value used internally in event platform 200 and/or event pipeline 210). As yet another example, date/time event information may be represented differently depending on the event source 110, the event type, or the like. In response, the normalization microservice may transform dates and/or date/time stamps to a uniform format (e.g., coordinated universal time). As yet another example, written characters in received event information may comprise upper and/or lower case characters, so normalization may, for example, normalize all characters to upper case characters…., lines 41-60 column 7). Note the discussion of claim 1 above for the reason of combining references.
As to claim 6, Pinel as modified further teaches the pause period is associated with a normalized event title (…If the alert is non-actionable, the process proceeds to step 206 and a waiting time is imposed…, lines 22-24 column 4).
As to claim 7, Pinel as modified further teaches the pause period is a function of a calculated pause period and a preset pause period (…If the alert is non-actionable, the process proceeds to step 206 and a waiting time is imposed…, lines 22-24 column 4).
As to claim 8, Arendt further teaches normalizing the event comprises: removing any newlines from the event; removing any tab characters from the event; converting the event to a single case; and replacing at least some punctuation characters with a predefined character (…For example, event information from event source 110 may be received by event pipeline 210 entitled “event name,” and the normalization microservice may alter the event information such that the title is “event name and description.” Normalization may affect all event information associated with an event, or at least one piece of event information associated with an event. As another example, the normalization microservice may transform values of data characteristics comprised in the event information to a recognized value (i.e., a value used internally in event platform 200 and/or event pipeline 210). As yet another example, date/time event information may be represented differently depending on the event source 110, the event type, or the like. In response, the normalization microservice may transform dates and/or date/time stamps to a uniform format (e.g., coordinated universal time). As yet another example, written characters in received event information may comprise upper and/or lower case characters, so normalization may, for example, normalize all characters to upper case characters…., lines 41-60 column 7). Note the discussion of claim 1 above for the reason of combining references.
As to claim 9, Arendt further teaches normalizing the event comprises: replacing each identifier in the event with a respective representative token; and replacing each number of a numeric string of the event with a predefined character (…For example, event information from event source 110 may be received by event pipeline 210 entitled “event name,” and the normalization microservice may alter the event information such that the title is “event name and description.” Normalization may affect all event information associated with an event, or at least one piece of event information associated with an event. As another example, the normalization microservice may transform values of data characteristics comprised in the event information to a recognized value (i.e., a value used internally in event platform 200 and/or event pipeline 210). As yet another example, date/time event information may be represented differently depending on the event source 110, the event type, or the like. In response, the normalization microservice may transform dates and/or date/time stamps to a uniform format (e.g., coordinated universal time). As yet another example, written characters in received event information may comprise upper and/or lower case characters, so normalization may, for example, normalize all characters to upper case characters…., lines 41-60 column 7). Note the discussion of claim 1 above for the reason of combining references.
As to claim 10, note the discussions of claims 8-9 above.
As to claims 11-19, note the discussions of claims 1-4 and 6-10 above, respectively.
As to claim 20, note the discussion of claim 1 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S Publication No. 2024/0403770 discloses modifying an event notification configuration based on incident resolution data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andy Ho whose telephone number is (571) 272-3762. A voice mail service is also available for this number. The examiner can normally be reached on Monday – Friday, 8:30 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Kevin Young can be reached on (571) 270-3180.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIM) system. Status information for published applications may be obtained from either Private PAIR or' Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist whose telephone number is 571-272-2100.
Any response to this action should be mailed to:
Commissioner for Patents
P.O Box 1450
Alexandria, VA 22313-1450
Or fax to:
AFTER-FINAL faxes must be signed and sent to (571) 273 - 8300.
OFFICAL faxes must be signed and sent to (571) 273 - 8300.
NON OFFICAL faxes should not be signed, please send to (571) 273 – 3762
/Andy Ho/
Primary Examiner
Art Unit 2194
Prosecution Insights