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 11/25/2025 where 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.
The examiner has reviewed Applicant’s arguments in their entirety from the submission on 7/29/2025 and 11/25/2025.
The examiner has withdrawn the 35 USC 112(b) rejection.
All other arguments are moot based on the prior rejection below covering all Independent and dependent claims in their entirety.
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 taches determining that the alert is anew alert, as Simsek discloses that an alert data object includes an alert escalation repetition value associated with the alert data object ([0059]), which indicates whether the alert corresponds to a repetitive alert, thereby allowing determination of a new alert versus a repetitive alert. Simsek further teaches determining that the alert should be published, as Simsek disclose that alert response entity rules dictate that a first alert notification is be generated for the alert (]0134]). Simsek also teaches a setting a value in a publish field corresponding to the alert to a first value as Simsek discloses that the alert data object includes stored escalation parameters associated with the alert ([0059]), which correspond under BRI to a field associated with the alert data object indicating the alert state.
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; As iSimsek discloses that a single escalation transaction may be used for an alert escalation that is repeated according to an escalation repetition value associated with the data object ([0061], Simsek further teaches that the use of the single escalation transaction reduces the number of redundant data objects (]0061], thereby indicating than additional alert data object is not generated for the repeated alert condition. This corresponds to determining that the repetitive alert should not be published again ([0067])) or;
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(Simsek; Simsek taches determining that the alert is anew alert, as Simsek discloses that an alert data object includes an alert escalation repetition value associated with the alert data object ([0059]), which indicates whether the alert corresponds to a repetitive alert, thereby allowing determination of a new alert versus a repetitive alert. Simsek further teaches determining that the alert should be published, as Simsek disclose that alert response entity rules dictate that a first alert notification is be generated for the alert (]0134]). Simsek also teaches a setting a value in a publish field corresponding to the alert to a first value as Simsek discloses that the alert data object includes stored escalation parameters associated with the alert ([0059]), which correspond under BRI to a field associated with the alert data object indicating the alert state);
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; As iSimsek discloses that a single escalation transaction may be used for an alert escalation that is repeated according to an escalation repetition value associated with the data object ([0061], Simsek further teaches that the use of the single escalation transaction reduces the number of redundant data objects (]0061], thereby indicating than additional alert data object is not generated for the repeated alert condition. This corresponds to determining that the repetitive alert should not be published again ([0067]));
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 taches determining that the alert is anew alert, as Simsek discloses that an alert data object includes an alert escalation repetition value associated with the alert data object ([0059]), which indicates whether the alert corresponds to a repetitive alert, thereby allowing determination of a new alert versus a repetitive alert. Simsek further teaches determining that the alert should be published, as Simsek disclose that alert response entity rules dictate that a first alert notification is be generated for the alert (]0134]). Simsek also teaches a setting a value in a publish field corresponding to the alert to a first value as Simsek discloses that the alert data object includes stored escalation parameters associated with the alert ([0059]), which correspond under BRI to a field associated with the alert data object indicating the alert state.;
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; As Simsek discloses that a single escalation transaction may be used for an alert escalation that is repeated according to an escalation repetition value associated with the data object ([0061], Simsek further teaches that the use of the single escalation transaction reduces the number of redundant data objects (]0061], thereby indicating than additional alert data object is not generated for the repeated alert condition. This corresponds to determining that the repetitive alert should not be published again ([0067])l;
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.
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