Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed on 4/7/2026. Claim 1 is amended and claims 1-20 are pending and ready for examination.
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 (i.e., changing from AIA to pre-AIA ) 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.
Applicant's arguments filed 4/7/2026 have been fully considered but they are not persuasive.
The examiner has reviewed the Applicant’s arguments in their entirety (Pages 12 – 16).
Applicant’s argument are not persuasive because Applicant argues a causal relationship that is not recited in the claim language. Applicant characterizes claim 1 as requiring that the determination of whether the alert is new or repetitive causes a value in a publish field to be set to a first value or a second value. However, the claim does not recite that causal step. The claim recites a two part logical flow; first, determining that the alert is a new alert or a repetitive alert; and second, in response to that determination, determining the publish treatment for the alert by setting a value in a publish field corresponding to the alert. Thus Applicant improperly compresses the claim language into a narrower causation requirement that the status determination itself must directly cause a particular field-value change.
Applicant is importing a narrower direct-causation requirement that the claim recites The claim requires a responsive logical flow, not a specifically labeled field directly changed by the new/repetitive determination itself.
In re Self, 671 F.2d 1344, 1348 9CCPA 1982) – applicant’s arguments fail when they are not based on limitations appearing in the claims.
Applicant argues that “Simsek does not disclose any field that is set to different values based on a determination of whether an alert is new or repetitive as required by claim 1”
Applicant’s argument is not cogent and is not persuasive. Applicant’s position effectively treats Simsek’s alert data object as a static record whose fields and parameters never change state. Simsek teaches the opposite. Simsek teaches an alert data object having predetermined alert configurations parameters that indicate how the alert is resolved, handled, routed, or otherwise managed b the alert monitoring service tool, including notification policy data used to generate and/or route alert notifications ([0055)). Simsek further teaches an escalation parameter set associated with the alert data object, including escalation rules, schedules, escalation progression time periods, escalation entity identifiers, repetition value , severity. Priority, importance and ranking ([0059], [0133]), where the alert severity level may indicate whether the alert needs to be escalated if the alert is not mitigated and/or acknowledged within a a predetermined alert escalation time period ([0059]).
Thus, Simsek’s alert data object maintains dynamic alert-management state. The claims do not require the claimed “publish field” to have a particular field name, database column structure, or implementation form. Under the broadest reasonable implementation, the claimed publish fields reads on state/configuration data corresponding to the alert that controls whether and how the alert is published, generated, routed, escalated, or otherwise handled. Accordingly, Applicant’s assertion that Simsek discloses no field set to different values based on whether the alert is new or repetitive mischaracterizes Simsek’s disclosure. Applicant’s argument effectively requires Simsek’s alert data object to never change or update state, even though Simsek expressly discloses alert configuration and escalation parameter states that control different handling of the alert.
Applicant is not addressing what Simsek teaches under the broadest reasonable interpretation. Rather, Applicant is selecting a narrowed product management view of how Simsek could be practiced and then arguing that the narrowed implementation does not meet the claim. That argument is not persuasive. Simsek teaches an alert data object having dynamic alert-configuration and escalation parameter state that controls how the alert is generated, routed, escalated, repeated, or otherwise handled. Applicant’s arguments improperly treats Simsek’s alert data object as a static object that never changes state, which mischaracterizes Simsek’s disclosure. One ordinarily skilled in the art is not an automaton and would understand Simsek for what its disclosed alert data object is capable of doing, not merely for a narrowed implementation selected by Applicant to avoid anticipation.
Simsek’s alert data object maintains dynamic state, and its state values change depending on how the alert is handled. The claim has no metes and bounds requiring a specific field name, field structure, or implementation. Therefore, Applicant’s argument that Simsek lacks a field set to different values improperly narrows the claim and ignores Simsek’s dynamic alert data object state.
Accordingly, Applicant’s argument effectively treats Simsek’s alert data object as never changing state, which mischaracterizes Simsek’s disclosure and ignores the alert configuration and escalation parameter states expressly taught in ([0055], [0059], and [0133])
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 5, and 7-8, 10 -11, 14, 16-17, and 19 -20 are rejected under 35 USC 102(a)(2) as being anticipated by Simsek (US 2025/0110847), Filed September 28th, 2023
Regarding claim 1, Simsek discloses a computer-implemented method for noise reduction in a cloud-based computing environment, the method comprising:
identifying an alert, generated for the cloud-based computing environment, containing data corresponding to one or more predefined service names, wherein each of the one or more predefined service names corresponds to a different alert service and the alert is generated when one or more metrics corresponding to an operation of a service of the cloud-based computing environment meets a threshold (Simsek; [0008], [0048], [0063], [0064]
see e.g. [0009] “... a resource allocation model associated with the alert monitoring service tool, whether the software application framework has satisfied an alert monitoring service resource threshold...”
see e.g. [0048] “... The term “alert attribute” refers to data, text, identifiers, metadata, or other alert related characteristics or features that are extracted from and/or otherwise associated with a respective alert, caution, problem, error, issue, and/or incident related to a software application framework. Example alert attributes include an alert identifier, an alert description, a tag identifier, a log identifier, a service identifier, and/or at least one alert response entity identifier. “
see e.g. [0044]
see e.g. [0052] “The term “service identifier” refers to one or more items of data by which a service (e.g., feature, application, product, etc.) associated with a software application framework may be identified. In some embodiments, the service identifier may comprise data indicating the upstream and downstream services for each specific service associated with the software application framework. In some embodiments, the service identifier may comprise service tier level data to indicate the importance of the service (e.g., the importance of the service to an enterprise and/or end user using the software application framework) for the user of the software application framework (e.g., monolithic platform and/or the service-oriented platform). In some embodiments, the service identifier may comprise data associated with other service identifiers which may indicate the number of impacted services from an alert of a specific service. In some embodiments, a particular service identifier (e.g., and therefore a particular service) may be associated with specific alert response team within a software application framework monitoring system. A service identifier may comprise text string(s), numerical character(s), alphabetical character(s), alphanumeric code(s), ASCII character(s), a pointer, an IP address, a MAC address, a memory address, other unique identifier, or a combination thereof”
see e.g. [0063] “A resource allocation model may be configured to determine whether a software application framework has satisfied (e.g., met and/or exceeded) an alert monitoring service resource threshold. The alert monitoring service resource threshold may be associated with a predetermined allotment of software application framework monitoring resources, communications network resources, personnel resources, computational resources, data storage resources, and/or the like that have been provided for a respective software application framework”
see e.g. [0064] “A resource allocation model may be configured to, in response to determining that an alert monitoring service resource threshold has been satisfied (e.g., met and/or exceeded) for a respective software application framework ... “.
see e.g. [0041] “The term “software application framework,” refers to a software platform comprising one or more types of software applications (e.g., a monolithic platform and/or a service-oriented platform), which are described in more detail below. A software application framework may be a distributed framework wherein the one or more types of software applications (e.g., monolithic platforms and/or service-oriented platforms) may be configured to interface, integrate, transfer data, and/or otherwise communicate with one another via a respective communications network,”
see e.g. [0042] “... Micros™ by Atlassian® platform or DynamoDB® by Amazon”
The Examiner notes Micros and Dynamo DB are cloud based computing platforms);
determining whether the alert is a new alert or a repetitive alert (Simsek;
Simsek discloses repetition handling of alerts through a repetition value ([0061], enabling the system to determine whether an alert instance corresponds to a repeated occurrence (i.e. a new alert in contrast to a repetitive alert). The repetition value provides one of ordinary skill in the art to discern between a new alert and repetitive alert.
[0061] In various examples, an alert monitoring service tool can generate a single escalation transaction associated with a respective alert data object and, as such, the single escalation transaction can be employed to facilitate the transmission of one or more alert escalation notifications to one or more respective alert response entities. The use of a single escalation transaction to facilitate the communications of the one or more alert escalation notifications reduces the number of redundant alert data objects and/or alert escalation objects generated for an unacknowledged alert by conventional alert monitoring service tools. For example, a single escalation transaction may be used to communicate multiple alert escalation notifications for an alert escalation that is repeated (e.g., looped, cycled, etc.) according to an escalation repetition value associated with a respective alert data object.);
in response to determining that the alert is the new alert, determining that the alert should be published by setting a value in a publish field, corresponding to the alert, to a first value (Simsek;
Simsek teaches an alert data object that is a dynamic state object whose state changes when the alert is treated as a new alert; that change in state corresponds to setting a field value indicating that the alert should be published ([0055]) The “determining” step is met because setting our suing the alert data object’s dynamic state to cause publication reflects the system’s determination that the new alert should be published.
Simsek teaches an alert data object includes predetermined alert configuration parameters that indicated how the alert is resolved, handled, routed, or otherwise managed by the alert monitoring service tool, including notification-policy data associated with the alert data object ([0055]). The alert monitoring tool uses data associated with those alert configuration parameters to generate and/or route alert notifications for the alert ([0055]). Under the broadest reasonable interpretation, publishing the alert is met by generating and/or routing alert notifications for the alert.
Accordingly, Simsek teaches the publication state for an alert that is not in the repetitive escalation state because the alert data object includes predetermined alert configuration parameters that control routing and notification policy handling for the alert ([0055]), and the alert monitoring service uses those parameter to generate and/or route alert notifications)
in response to determining that the alert is the repetitive alert, determining that the alert should not be published by setting the value in the publish field to a second value (Simsek; Simsek teaches an alert data object that is a dynamic state object whose state changes when the alert is treated as a repetitive alert; that change in state corresponds to setting a different field vale indicating that the alert should not be published as a new alert ([0059], [0060], [0061], [0133] The “determining” step is met because setting or using the alert data object’s dynamic escalation sate to prevent publication as a new alert reflects the system’s determination that the repetitive alert should not be published.
Simsek teaches ([0059], [0060], [0061], [0133]) that the alert data object includes an escalation parameter state that indicates whether the alert needs to be escalated when the alert is not mitigated and/or acknowledged by a first response entity within a predetermined alert escalation time period. That escalation parameter state is the alert data object’s second state for handling the repetitive alert, rather than treating the alert as a new alert. to be published.
The repetitive alert determination is tied to the escalation parameter state. Paragraph [0059] says the escalation parameter set includes escalation rules, schedules, progression time periods, entity identifiers, repetition value, severity, priority, importance, and ranking, and it expressly gives the scenario where the alert needs escalation if it is not mitigated or acknowledged within the predetermined time period. The Examiner notes that the escalation parameter set is included in and associated with the alert data object, and a change to any of the escalation parameter values is a change in the alert data object’s state.
Simsek teaches ([0059]) an escalation parameter state scenario where if the alert is not mitigated and/or acknowledged within the predetermined alert escalation progression time period, the alert needs escalation. The alert data object’s escalation parameter state is the state/value used to handle the alert as repetitive rather than publishing it as a new alert.
The alert data object contains state/configuration data. Setting that state one way causes the alert monitoring service to publish the alert as a notification. Setting the state another way causes the alert monitoring service not to publish it as a new alert, but instead handle it under the escalation path.
The alert data object maintains state/configuration data, and that state controls whether the alert is pushed downstream as a published notification or handled differently through the repetitive /escalation path
The examiner has interpreted these limitations as a two-part logical flow: first determining the alert status, and second, in response to that alert-status determination, determining the publish treatment by setting a value in a field corresponding to the alert. .);
storing the alert with the corresponding publish field in a database (Simsek further teaches storing the alert with the corresponding publish field in a database, as Simsek discloses an alert data object associated with the alert and including stored escalation parameters ([0059], [0067]
[0067] In various examples, one or more alert monitoring event objects may be stored, accessed, received, transmitted to, and/or otherwise managed by a data storage subsystem associated with a software application framework monitoring system. Additionally or alternatively, in various examples, one or more alert monitoring event objects may be stored, accessed, received, transmitted to, and/or otherwise managed by one or more cloud-based storage platforms (e.g., cloud-based databases, cloud-based data-querying tools, and/or the like) associated with the software application framework monitoring system. Examples of cloud-based storage systems include Redis® by Redis Ltd.®, DynamoDB® by Amazon Web Services®, and Elasticsearch® by Elasticsearch BV.);
analyzing, at a predetermined time, the database to identify one or more first different alerts with a corresponding publish field with the first value (Simsek;
Simsek teaches analyzing alerts at a predetermined time, as Simsek discloses alert escalation rules including escalation time periods that determine when alerts are reevaluated ([0133] – [0134]. The system reevaluate stored alert data objects ([0059]) to determine which alerts require further action, thereby identifying alerts associated with stored alert parameters corresponding under BRI to the claimed publish field having the first value.); and
publishing the one or more first different alerts over a computer network to one or more client devices (Simsek teaches publishing alerts over a computer network to one or more client devices, as Simsek discloses that alert notifications may be communicated to alert response entities via an escalation transaction ([0135]). Simsek further teaches that the monitoring computing device communicates with one or more client computing device using one or ore computer networks ([0070]. Accordingly, Simsek teaches publishing alerts over a computer network to client devices).
Regarding claim 2, Simsek discloses the computer-implemented method of claim 1, wherein the alert includes one or more fields and/or one or more first values that indicate that the alert was generated by a particular alert generation system (Simsek; [0059])
Regarding claim 5. Simsek discloses the computer-implemented method of claim 1, further comprising: transforming the alert to include one or more additional fields for storing information that includes one or more of (1) region information indicating a geographical area where a component, impacted by an issue that resulted in the generation of the alert, is allocated, (2) availability zone information indicating an identifier for an availability zone, of the region, wherein the component is allocated, (3) an application identifier indicating an application that interacts with the component, (4) a suggested remediation action indicating one or more predefined actions to implement to address the issue, (5) a virtual device identifier for a virtual device hosting the application that interacts with the component (Simsek;
see e.g. [0048] “... The term “alert attribute” refers to data, text, identifiers, metadata, or other alert related characteristics or features that are extracted from and/or otherwise associated with a respective alert, caution, problem, error, issue, and/or incident related to a software application framework. Example alert attributes include an alert identifier, an alert description, a tag identifier, a log identifier, a service identifier, and/or at least one alert response entity identifier. “ )
.
Regarding claim 7, Simsek discloses the computer-implemented method of claim 1, further comprising:
analyzing, at the predetermined time, the database to identify one or more second different alerts with a corresponding publish field with the second value (Simsek; The system identifies alerts having the second value in the publish field and treats those alerts as suppressed alerts within the alert database.;[0133]); and
preventing the one or more second different alerts from publishing over the computer network to the one or more client devices (Simsek, As a result, those identified alerts are prevented from being transmitted or published to client devices over the network [0133]).
Regarding claim 8, Simsek discloses the computer-implemented method of claim 1, further comprising:
analyzing a selected first different alert of the one or more first different alerts; identifying particular information stored within the selected first different alert (Simsek; Simsek describes examining alert records an evaluating the information contained within the alert entry to determine the nature of the alert condition. Through this evaluation process, the system identifies particular information associated with the selected alert [0133])
in response to identifying the particular information, (1) automatically performing one or more predetermined remediation actions for the cloud-based computing environment or (2) imitating a self-healing action that automatically performs the one or more predetermined remediation actions for the cloud-based computing environment (Simsek; Based on the identified alert information, the system performs automated handling of the alert condition, such as escalation or automated corrective handling. This automated response corresponds to predetermined remediation behavior within the monitored computing environment. [0135]).
Regarding claim 10, Simsek discloses a system for noise reduction in a cloud-based computing environment, the system comprising:
a software module executed by a processor of the cloud-based computing environment, the software module configured to (Simsek; see e.g. [0179], [0180]):
identify an alert, generated for the cloud-based computing environment, containing data corresponding to one or more predefined service names, wherein each of the one or more predefined service names corresponds to a different alert service and the alert is generated when one or more metrics corresponding to an operation of a service of the cloud-based computing environment meets a thresholdthreshold (Simsek; [0008], [0048], [0063], [0064]
see e.g. [0009] “... a resource allocation model associated with the alert monitoring service tool, whether the software application framework has satisfied an alert monitoring service resource threshold...”
see e.g. [0048] “... The term “alert attribute” refers to data, text, identifiers, metadata, or other alert related characteristics or features that are extracted from and/or otherwise associated with a respective alert, caution, problem, error, issue, and/or incident related to a software application framework. Example alert attributes include an alert identifier, an alert description, a tag identifier, a log identifier, a service identifier, and/or at least one alert response entity identifier. “
see e.g. [0044]
see e.g. [0052] “The term “service identifier” refers to one or more items of data by which a service (e.g., feature, application, product, etc.) associated with a software application framework may be identified. In some embodiments, the service identifier may comprise data indicating the upstream and downstream services for each specific service associated with the software application framework. In some embodiments, the service identifier may comprise service tier level data to indicate the importance of the service (e.g., the importance of the service to an enterprise and/or end user using the software application framework) for the user of the software application framework (e.g., monolithic platform and/or the service-oriented platform). In some embodiments, the service identifier may comprise data associated with other service identifiers which may indicate the number of impacted services from an alert of a specific service. In some embodiments, a particular service identifier (e.g., and therefore a particular service) may be associated with specific alert response team within a software application framework monitoring system. A service identifier may comprise text string(s), numerical character(s), alphabetical character(s), alphanumeric code(s), ASCII character(s), a pointer, an IP address, a MAC address, a memory address, other unique identifier, or a combination thereof”
see e.g. [0063] “A resource allocation model may be configured to determine whether a software application framework has satisfied (e.g., met and/or exceeded) an alert monitoring service resource threshold. The alert monitoring service resource threshold may be associated with a predetermined allotment of software application framework monitoring resources, communications network resources, personnel resources, computational resources, data storage resources, and/or the like that have been provided for a respective software application framework”
see e.g. [0064] “A resource allocation model may be configured to, in response to determining that an alert monitoring service resource threshold has been satisfied (e.g., met and/or exceeded) for a respective software application framework ... “.
see e.g. [0041] “The term “software application framework,” refers to a software platform comprising one or more types of software applications (e.g., a monolithic platform and/or a service-oriented platform), which are described in more detail below. A software application framework may be a distributed framework wherein the one or more types of software applications (e.g., monolithic platforms and/or service-oriented platforms) may be configured to interface, integrate, transfer data, and/or otherwise communicate with one another via a respective communications network,”
see e.g. [0042] “... Micros™ by Atlassian® platform or DynamoDB® by Amazon”
The Examiner notes Micros and Dynamo DB are cloud based computing platforms;
determine whether the alert is a new alert or a repetitive alert alert (Simsek;
Simsek discloses repetition handling of alerts through a repetition value ([0061], enabling the system to determine whether an alert instance corresponds to a repeated occurrence (i.e. a new alert in contrast to a repetitive alert). The repetition value provides one of ordinary skill in the art to discern between a new alert and repetitive alert.
[0061] In various examples, an alert monitoring service tool can generate a single escalation transaction associated with a respective alert data object and, as such, the single escalation transaction can be employed to facilitate the transmission of one or more alert escalation notifications to one or more respective alert response entities. The use of a single escalation transaction to facilitate the communications of the one or more alert escalation notifications reduces the number of redundant alert data objects and/or alert escalation objects generated for an unacknowledged alert by conventional alert monitoring service tools. For example, a single escalation transaction may be used to communicate multiple alert escalation notifications for an alert escalation that is repeated (e.g., looped, cycled, etc.) according to an escalation repetition value associated with a respective alert data object.;
determine, in response to determining that the alert is the new alert, that the alert should be published by setting a value in a publish field, corresponding to the alert, to a first value(value (Simsek;
Simsek teaches an alert data object that is a dynamic state object whose state changes when the alert is treated as a new alert; that change in state corresponds to setting a field value indicating that the alert should be published ([0055]) The “determining” step is met because setting our suing the alert data object’s dynamic state to cause publication reflects the system’s determination that the new alert should be published.
Simsek teaches an alert data object includes predetermined alert configuration parameters that indicated how the alert is resolved, handled, routed, or otherwise managed by the alert monitoring service tool, including notification-policy data associated with the alert data object ([0055]). The alert monitoring tool uses data associated with those alert configuration parameters to generate and/or route alert notifications for the alert ([0055]). Under the broadest reasonable interpretation, publishing the alert is met by generating and/or routing alert notifications for the alert.
Accordingly, Simsek teaches the publication state for an alert that is not in the repetitive escalation state because the alert data object includes predetermined alert configuration parameters that control routing and notification policy handling for the alert ([0055]), and the alert monitoring service uses those parameter to generate and/or route alert notifications));
determine, in response to determining that the alert is the repetitive alert, that the alert should not be published by either (1) setting the value in the publish field to a second value or (2) maintaining the publish field as null value (Simsek; Simsek teaches an alert data object that is a dynamic state object whose state changes when the alert is treated as a repetitive alert; that change in state corresponds to setting a different field vale indicating that the alert should not be published as a new alert ([0059], [0060], [0061], [0133] The “determining” step is met because setting or using the alert data object’s dynamic escalation sate to prevent publication as a new alert reflects the system’s determination that the repetitive alert should not be published.
Simsek teaches ([0059], [0060], [0061], [0133]) that the alert data object includes an escalation parameter state that indicates whether the alert needs to be escalated when the alert is not mitigated and/or acknowledged by a first response entity within a predetermined alert escalation time period. That escalation parameter state is the alert data object’s second state for handling the repetitive alert, rather than treating the alert as a new alert. to be published.
The repetitive alert determination is tied to the escalation parameter state. Paragraph [0059] says the escalation parameter set includes escalation rules, schedules, progression time periods, entity identifiers, repetition value, severity, priority, importance, and ranking, and it expressly gives the scenario where the alert needs escalation if it is not mitigated or acknowledged within the predetermined time period. The Examiner notes that the escalation parameter set is included in and associated with the alert data object, and a change to any of the escalation parameter values is a change in the alert data object’s state.
Simsek teaches ([0059]) an escalation parameter state scenario where if the alert is not mitigated and/or acknowledged within the predetermined alert escalation progression time period, the alert needs escalation. The alert data object’s escalation parameter state is the state/value used to handle the alert as repetitive rather than publishing it as a new alert.
The alert data object contains state/configuration data. Setting that state one way causes the alert monitoring service to publish the alert as a notification. Setting the state another way causes the alert monitoring service not to publish it as a new alert, but instead handle it under the escalation path.
The alert data object maintains state/configuration data, and that state controls whether the alert is pushed downstream as a published notification or handled differently through the repetitive /escalation path
The examiner has interpreted these limitations as a two-part logical flow: first determining the alert status, and second, in response to that alert-status determination, determining the publish treatment by setting a value in a field corresponding to the alert. .)));
store the alert with the corresponding publish field in a database (Simsek further teaches storing the alert with the corresponding publish field in a database, as Simsek discloses an alert data object associated with the alert and including stored escalation parameters ([0059], [0067]
[0067] In various examples, one or more alert monitoring event objects may be stored, accessed, received, transmitted to, and/or otherwise managed by a data storage subsystem associated with a software application framework monitoring system. Additionally or alternatively, in various examples, one or more alert monitoring event objects may be stored, accessed, received, transmitted to, and/or otherwise managed by one or more cloud-based storage platforms (e.g., cloud-based databases, cloud-based data-querying tools, and/or the like) associated with the software application framework monitoring system. Examples of cloud-based storage systems include Redis® by Redis Ltd.®, DynamoDB® by Amazon Web Services®, and Elasticsearch® by Elasticsearch BV.;
analyze, at a predetermined time, the database to identify one or more first different alerts with a corresponding publish field with the first value value (Simsek;
Simsek teaches analyzing alerts at a predetermined time, as Simsek discloses alert escalation rules including escalation time periods that determine when alerts are reevaluated ([0133] – [0134]. The system reevaluate stored alert data objects ([0059]) to determine which alerts require further action, thereby identifying alerts associated with stored alert parameters corresponding under BRI to the claimed publish field having the first value.); and
publish the one or more first different alerts over a computer network to one or more client devices devices (Simsek teaches publishing alerts over a computer network to one or more client devices, as Simsek discloses that alert notifications may be communicated to alert response entities via an escalation transaction ([0135]). Simsek further teaches that the monitoring computing device communicates with one or more client computing device using one or ore computer networks ([0070]. Accordingly, Simsek teaches publishing alerts over a computer network to client devices).
Regarding claim 11, claim 11 recites the same substantive limitations as claim 2 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 2.
Regarding claim 14, claim 14 recites the same substantive limitations as claim 5 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 5.
Regarding claim 16, claim 16 recites the same substantive limitations as claim 7 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 7.
Regarding claim 17, claim 17 recites the same substantive limitations as claim 8 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 8.
Regarding claim 19. Simsek discloses a non-transitory computer readable medium having software encoded thereon, the software when executed by one or more computing devices operable to:
identify an alert, generated for the cloud-based computing environment, containing data corresponding to one or more predefined service names, wherein each of the one or more predefined service names corresponds to a different alert service and the alert is generated when one or more metrics corresponding to an operation of a service of the cloud-based computing environment meets a threshold threshold (Simsek; [0008], [0048], [0063], [0064]
see e.g. [0009] “... a resource allocation model associated with the alert monitoring service tool, whether the software application framework has satisfied an alert monitoring service resource threshold...”
see e.g. [0048] “... The term “alert attribute” refers to data, text, identifiers, metadata, or other alert related characteristics or features that are extracted from and/or otherwise associated with a respective alert, caution, problem, error, issue, and/or incident related to a software application framework. Example alert attributes include an alert identifier, an alert description, a tag identifier, a log identifier, a service identifier, and/or at least one alert response entity identifier. “
see e.g. [0044]
see e.g. [0052] “The term “service identifier” refers to one or more items of data by which a service (e.g., feature, application, product, etc.) associated with a software application framework may be identified. In some embodiments, the service identifier may comprise data indicating the upstream and downstream services for each specific service associated with the software application framework. In some embodiments, the service identifier may comprise service tier level data to indicate the importance of the service (e.g., the importance of the service to an enterprise and/or end user using the software application framework) for the user of the software application framework (e.g., monolithic platform and/or the service-oriented platform). In some embodiments, the service identifier may comprise data associated with other service identifiers which may indicate the number of impacted services from an alert of a specific service. In some embodiments, a particular service identifier (e.g., and therefore a particular service) may be associated with specific alert response team within a software application framework monitoring system. A service identifier may comprise text string(s), numerical character(s), alphabetical character(s), alphanumeric code(s), ASCII character(s), a pointer, an IP address, a MAC address, a memory address, other unique identifier, or a combination thereof”
see e.g. [0063] “A resource allocation model may be configured to determine whether a software application framework has satisfied (e.g., met and/or exceeded) an alert monitoring service resource threshold. The alert monitoring service resource threshold may be associated with a predetermined allotment of software application framework monitoring resources, communications network resources, personnel resources, computational resources, data storage resources, and/or the like that have been provided for a respective software application framework”
see e.g. [0064] “A resource allocation model may be configured to, in response to determining that an alert monitoring service resource threshold has been satisfied (e.g., met and/or exceeded) for a respective software application framework ... “.
see e.g. [0041] “The term “software application framework,” refers to a software platform comprising one or more types of software applications (e.g., a monolithic platform and/or a service-oriented platform), which are described in more detail below. A software application framework may be a distributed framework wherein the one or more types of software applications (e.g., monolithic platforms and/or service-oriented platforms) may be configured to interface, integrate, transfer data, and/or otherwise communicate with one another via a respective communications network,”
see e.g. [0042] “... Micros™ by Atlassian® platform or DynamoDB® by Amazon”
The Examiner notes Micros and Dynamo DB are cloud based computing platforms;
determine whether the alert is a new alert or a repetitive alert(Simsek;
Simsek discloses repetition handling of alerts through a repetition value ([0061], enabling the system to determine whether an alert instance corresponds to a repeated occurrence (i.e. a new alert in contrast to a repetitive alert). The repetition value provides one of ordinary skill in the art to discern between a new alert and repetitive alert.
[0061] In various examples, an alert monitoring service tool can generate a single escalation transaction associated with a respective alert data object and, as such, the single escalation transaction can be employed to facilitate the transmission of one or more alert escalation notifications to one or more respective alert response entities. The use of a single escalation transaction to facilitate the communications of the one or more alert escalation notifications reduces the number of redundant alert data objects and/or alert escalation objects generated for an unacknowledged alert by conventional alert monitoring service tools. For example, a single escalation transaction may be used to communicate multiple alert escalation notifications for an alert escalation that is repeated (e.g., looped, cycled, etc.) according to an escalation repetition value associated with a respective alert data object.);
determine, in response to determining that the alert is the new alert, that the alert should be published by setting a value in a publish field, corresponding to the alert, to a first value (Simsek;
Simsek teaches an alert data object that is a dynamic state object whose state changes when the alert is treated as a new alert; that change in state corresponds to setting a field value indicating that the alert should be published ([0055]) The “determining” step is met because setting our suing the alert data object’s dynamic state to cause publication reflects the system’s determination that the new alert should be published.
Simsek teaches an alert data object includes predetermined alert configuration parameters that indicated how the alert is resolved, handled, routed, or otherwise managed by the alert monitoring service tool, including notification-policy data associated with the alert data object ([0055]). The alert monitoring tool uses data associated with those alert configuration parameters to generate and/or route alert notifications for the alert ([0055]). Under the broadest reasonable interpretation, publishing the alert is met by generating and/or routing alert notifications for the alert.
Accordingly, Simsek teaches the publication state for an alert that is not in the repetitive escalation state because the alert data object includes predetermined alert configuration parameters that control routing and notification policy handling for the alert ([0055]), and the alert monitoring service uses those parameter to generate and/or route alert notifications)
determine, in response to determining that the alert is the repetitive alert, that the alert should not be published by either (1) setting the value in the publish field to a second value or (2) maintaining the publish field as nul(Simsek; Simsek teaches an alert data object that is a dynamic state object whose state changes when the alert is treated as a repetitive alert; that change in state corresponds to setting a different field vale indicating that the alert should not be published as a new alert ([0059], [0060], [0061], [0133] The “determining” step is met because setting or using the alert data object’s dynamic escalation sate to prevent publication as a new alert reflects the system’s determination that the repetitive alert should not be published.
Simsek teaches ([0059], [0060], [0061], [0133]) that the alert data object includes an escalation parameter state that indicates whether the alert needs to be escalated when the alert is not mitigated and/or acknowledged by a first response entity within a predetermined alert escalation time period. That escalation parameter state is the alert data object’s second state for handling the repetitive alert, rather than treating the alert as a new alert. to be published.
The repetitive alert determination is tied to the escalation parameter state. Paragraph [0059] says the escalation parameter set includes escalation rules, schedules, progression time periods, entity identifiers, repetition value, severity, priority, importance, and ranking, and it expressly gives the scenario where the alert needs escalation if it is not mitigated or acknowledged within the predetermined time period. The Examiner notes that the escalation parameter set is included in and associated with the alert data object, and a change to any of the escalation parameter values is a change in the alert data object’s state.
Simsek teaches ([0059]) an escalation parameter state scenario where if the alert is not mitigated and/or acknowledged within the predetermined alert escalation progression time period, the alert needs escalation. The alert data object’s escalation parameter state is the state/value used to handle the alert as repetitive rather than publishing it as a new alert.
The alert data object contains state/configuration data. Setting that state one way causes the alert monitoring service to publish the alert as a notification. Setting the state another way causes the alert monitoring service not to publish it as a new alert, but instead handle it under the escalation path.
The alert data object maintains state/configuration data, and that state controls whether the alert is pushed downstream as a published notification or handled differently through the repetitive /escalation path
The examiner has interpreted these limitations as a two-part logical flow: first determining the alert status, and second, in response to that alert-status determination, determining the publish treatment by setting a value in a field corresponding to the alertl;
store the alert with the corresponding publish field in a database; analyze, at a predetermined time, the database to identify each of one or more first different alerts with a corresponding publish field with the first value (Simsek further teaches storing the alert with the corresponding publish field in a database, as Simsek discloses an alert data object associated with the alert and including stored escalation parameters ([0059], [0067]
[0067] In various examples, one or more alert monitoring event objects may be stored, accessed, received, transmitted to, and/or otherwise managed by a data storage subsystem associated with a software application framework monitoring system. Additionally or alternatively, in various examples, one or more alert monitoring event objects may be stored, accessed, received, transmitted to, and/or otherwise managed by one or more cloud-based storage platforms (e.g., cloud-based databases, cloud-based data-querying tools, and/or the like) associated with the software application framework monitoring system. Examples of cloud-based storage systems include Redis® by Redis Ltd.®, DynamoDB® by Amazon Web Services®, and Elasticsearch® by Elasticsearch BV.; and
publish the one or more different first alerts over a computer network to one or more client devices (Simsek teaches publishing alerts over a computer network to one or more client devices, as Simsek discloses that alert notifications may be communicated to alert response entities via an escalation transaction ([0135]). Simsek further teaches that the monitoring computing device communicates with one or more client computing device using one or ore computer networks ([0070]. Accordingly, Simsek teaches publishing alerts over a computer network to client devices).
Regarding claim 20, claim 20 recites the same substantive limitations as claim 5 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 5.
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.
Claims 3 - 4 and 12 -13 are rejected under 35 USC 103 as being unpatentable over Simsek in view of Puentes (US 20120323702)
Regarding claim 3, Simsek discloses the computer implemented method of claim 1, wherein determining whether the alert is the new alert or the repetitive alert, the method further comprising:
identifying a first previous alert stored in a database that has a same application identifier and a same component identifier as the alert (Simsek,Simsek describes storing alert records in the alert database together with identifiers associated with the monitored application and component. Wen evaluating alerts, the system retrieves a prior alert entry associated with the same identifiers, thereby identifying a previously stored alert corresponding to the same application and component [0049], [0133-0136], [0070]);
identifying a second previous alert that has the same application identifier and the same component identifier as the alert (Simsek, Simsek further describes examining stored alert records associated with the same application and component identifiers within the alert database. Through this examination the system identifies another previously stored alert entry associated with the same identifiers [0133-136], [0070]);
determining that the alert is the new alert when (1) a current status of the alert is not a same value as a first previous status of the first previous alert stored in the database, and (2) the current status of the alert is not the same value as a second previous status of the second previous alert cache (Simsek, Simsek further explains comparing the current alert status with previously stored status values for alerts associated with the same identifiers. When the status values correspond, the system determines that the alert represents a repetitive alert condition[0133-136], [0070]), and
determining that the alert is the repetitive alert when (1) the current status of the alert is the same value as the first previous status of the first previous alert stored in the database, or (2) the current status of the alert is the same value as the previous status of the previous alert (Simsek, [0133-136], [0070]
Simsek describes comparing the current alert status with previously sotred status values associated with alerts having the same identifiers. When the current status corresponds to the stored status value of a previous alert, the system determines that the alert represents a repetitive alert condition).
Simsek does not expressly disclose cache, however in analogous art Puentes discloses:
Cache (Puentes;
[0065] Memory 136 may also include means for reliable storage of large quantities of data. Such means may include one or more instances of a database, hierarchical or tiered storage systems including a cache, redundant arrays of disks such as RAID systems, flat files, network attached storage (NAS) devices, distributed hash tables, or striped disk arrays.)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Puente’s cache infrastructure. The motivation being the combined solution provides for optimizing database transactions.
Regarding claim 4, Simsek in view of Puentes discloses the computer-implemented method of claim 3, the method further comprising:
publishing the alert when the alert is new and a notification status corresponding to the alert is not set to paused (Simsek; Simsek describes transmitting alert notifications to client devices when the alert condition is determined to require notification and the notification status permits delivery. Thus, when the alert is treated as a new alert and notification delivery is enabled, the system proceeds to publish the alert to the corresponding recipients [0059], [0135-0136]); and
preventing the alert from being published when the alert is repetitive or the notification status corresponding to the alert is set to paused (Simsek; Simsek further describes suppressing or withholding alert notifications when alert management logic determines that the alert should not be transmitted. When the alert condition is repetitive or when notification delivery is paused, the stem prevent the alert form being published to client devices [0059], [0135-0136]);
Regarding claim 12, claim 12 recites the same substantive limitations as claim 3 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 3.
Regarding claim 13, claim 13 recites the same substantive limitations as claim 4 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 4.
Claims 6 and 15 is rejected under 35 USC 103 as being unpatentable over Simsek in view of Katari (US 20090019458)
Regarding claim 6. Simsek discloses the computer-implemented method of claim 5, wherein the transformed alert is generated from a first alert generation system and a second transformed alert is generated from a second alert generation system that is different from the first alert generation system (Simsek; [0059]), Simsek does not expressly disclose wherein the transformed alert and the second transformed alert have a same format with same fields.
However in analogous art Katari discloses:
wherein the transformed alert and the second transformed alert have a same format (Katari;
[0057] The Metadata API 206 registers and instantiates 404 a type class and a property class for the incoming metadata format. The Metadata API 206 is configured, in at least one embodiment, to operate on two or more different metadata formats. The type class is configured to convert type metadata from the original metadata format to a common metadata format and the property class is configured to do the same with regard to property metadata. Type and property interfaces may also be provided for accessing object-level metadata and property-level metadata respectively)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Katari’s conversion scheme. The motivation being the combined solution provides for implementing a known technique resulting in the ability to transform data objects to the same format.
Regarding claim 15, claim 15 recites the same substantive limitations as claim 6 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 6.
Claims 9 and 18 are rejected under 35 USC 103 as being unpatentable over Simsek in view of Astigarraga (US 20150106511)
Regarding claim 9, Simsek discloses the computer-implemented method of claim 8, Simsek does not expressly disclose wherein the one or more predetermined remediation actions includes a failover technique where the service is switched from executing on a first cloud-based device to a second cloud-based device of the cloud-based computing environment and a failback technique where the service is switched from executing on the second cloud based device to the first cloud-based device of the cloud computing environment.
However in analogous art Astigarraga discloses:
where the service is switched from executing on a first cloud-based device to a second cloud-based device of the cloud-based computing environment (Astigarraga;
[0078] According to an embodiment, an end user may input operating parameters and thresholds into the user input module 402 that the SCMA 404 will use to establish and monitor the cloud system 400. For example, the end user may input preferences including, but not limited to: (i) which cloud will serve as the primary cloud 406 (by providing an Internet protocol (IP) address for the primary cloud 406), (ii) whether multiple redundant paths should be used, (iii) whether there should be a preferred secondary cloud 408 (if so, by providing an IP address for the preferred secondary cloud 408), (iv) how many secondary clouds 410, 412 will be used (by providing IP addresses for each of the secondary clouds 410, 412), which security features will be used (e.g., IP security (SEC), Transport Layer Security, Secure Socket Layer), and threshold settings for various monitors (e.g., a policy manager, a performance manager, a cloud health monitor, preferred failover paths, and individual user authorizations or group user authorizations).)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Astigarraga’s failover scheme. The motivation being the combined solution provides for implementing a known technique resulting in protecting enterprise data for unforeseen events.
Regarding claim 18, claim 18 recites the same substantive limitations as claim 9 in a different statutory form, and therefore is rejected for the same reasons discussed above with respect to claim 9.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304.
/TODD L BARKER/Primary Examiner, Art Unit 2449
Prosecution Insights