Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This action is responsive to the communication filed on 01/02/2026. Claims 1-20 are pending.
Applicants' arguments filed 01/02/2026 have been fully considered but they are not deemed to be persuasive. Rejections and/or objections not reiterated from previous office actions are hereby withdrawn. The following rejections and/or objections are either reiterated or newly applied. They constitute the complete set presently being applied to the instant application.
Claim Rejections - 35 USC § 103
2. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
3. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
4. 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.
5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. Claims 1, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over HE in view of Scrandis et al (US 6816461 B1 hereinafter, “Scrandis”).
7. With respect to claim 1,
HE discloses
a computer-implemented method, comprising:
sending, by a first processing node, a request (HE pages 2-3 e.g. request) comprising an identified alert record (HE pages 2-3 e.g. alarm) from a shared alert data store (HE pages 2-3 e.g. the record node) that is shared amongst a cluster (HE pages 2-3 e.g. cluster) of processing nodes (HE pages 2-3 e.g. nodes) comprising the first processing node;
receiving, by the first processing node and responsive to the request, a delete (HE pages 2-3 e.g. remove) alert record uniquely identifying the identified alert record and comprising an annotation identifying a new delete alert record as being a delete alert record type (HE pages 2-3 e.g. The invention claims a recording method of alarm log in cluster environment, the all the nodes report the alarm log to the record node, specifically comprising the following steps: the node pulls the alarm log of the user from the local first queue; when the node receives the alarm synchronization request of the user, storing the pulled alarm log to the local second queue; the third queue of the cache middleware obtains the alarm log stored in the local second sequence. The invention claims a recording method of alarm log in cluster environment, the pulling the reported alarm log, and according to the corresponding relation of the value of the sequence number of the alarm log and the value of the maximum alarm sequence number counter; recording the alarm log into the first alarm log file through the file reference, specifically comprising the following steps: drawing and removing the alarm log [as a delete alert record uniquely identifying an identified alert record] from the third queue by the record user node; if the value of the sequence number of the current alarm log is not greater than the value of the maximum alarm sequence number counter, discarding the current alarm log [as an annotation identifying a new delete alert record as being a delete alert record type]; if the value of the sequence number of the current alarm log is the value of the maximum alarm sequence number counter adding 1; adding the current alarm log to the last row of the first alarm log file through the file reference, and adding one to the value of the maximum alarm sequence number counter; if the value of the sequence number of the current alarm log is greater than the value of the maximum alarm sequence number counter adding 1, the sequence number is the value of the sequence number of the current alarm log subtracting one to the value of the maximum alarm sequence number counter adding a corresponding all the alarm log to write to the end of the first alarm log file, after, adding the current alarm log to the last row of the first alarm log file by the file reference, and updating the value of the maximum alarm sequence number counter as the value of the sequence number of the current alarm log).
Although HE substantially teaches the claimed invention, HE does not explicitly indicate
matching, by the first processing node and responsive to the annotation, the delete alert record to a local copy of the identified alert record based on the delete alert record uniquely identifying the identified alert record; and
deleting, by the first processing node and based on the annotation, the local copy of the identified alert record according to the delete alert record
Scrandis teaches the limitations by stating
receiving, by the first processing node and responsive to the request, a delete alert record uniquely identifying the identified alert record and comprising an annotation identifying a new delete alert record as being a delete alert record type;
matching, by the first processing node and responsive to the annotation, the delete alert record to a local copy of the identified alert record based on the delete alert record uniquely identifying the identified alert record; and
deleting, by the first processing node and based on the annotation, the local copy of the identified alert record according to the delete alert record (Scrandis col. 21 lines 4-19 e.g. (188) Adding/Deleting a MS Alarm Objects 200 (189) If an MS alarm object 200 is added to a channel, a check is made to determine if there is an existing MS Alarm Object 200 with its node's IP address and the same fault type stored in the span database 100. If a matching MS Alarm Object 200 is not found, a new MS Alarm Object 200 is created. This mechanism handles multiple alarm conditions for the same fault condition on the same channel on a node. An alarm count is increment by 1 for each uncorrelated alarm, and decreased by 1 each time an associated alarm clears. This ensures that the MS Alarm Object 200 is not deleted from the database 100 until all associated local alarm conditions have cleared. Note that when an MS Alarm Object 200 is deleted, the invention recorrelates any suppressed faults associated with this parent MS Alarm Object 200 [as
receiving, by the first processing node and responsive to the request, a delete (e.g. cleared/deleted) alert record uniquely identifying the identified alert record and comprising an annotation (e.g. IP address and same fault type) identifying a new delete alert record (e.g. an MS alarm object 200 is added) as being a delete alert record type;
matching (e.g. matching - existing), by the first processing node and responsive to the annotation (e.g. IP address and same fault type), the delete (e.g. cleared/deleted) alert record to a local copy (e.g. local alarm) of the identified alert record based on the delete alert record uniquely identifying the identified alert record; and
deleting (e.g. cleared/deleted), by the first processing node and based on the annotation (e.g. IP address and same fault type), the local copy (e.g. local alarm) of the identified alert record according to the delete alert record]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of HE and Scrandis, to perform distributed optical network management of faults and alarms. (Scrandis col. 1 lines 20-25).
8. Claim 11 is same as claim 1 and is rejected for the same reasons as applied hereinabove.
9. Claim 17 is same as claim 1 and is rejected for the same reasons as applied hereinabove.
10. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over HE in view of Scrandis, and further in view of ZHOU.
11. With respect to claim 7,
Although HE and Scrandis combination substantially teaches the claimed invention, they do not explicitly indicate
obtaining, by a second processing node, from the shared alert data store, a set of saved search selectors;
obtaining, by the second processing node, the first set of alert records for a saved search selector in the set of saved search selectors;
storing, by the second processing node, the first set of alert records in a local alert data store;
receiving, by the second processing node, a request to display the first set of alert records; and
displaying, by the second processing node, the first set of alert records.
ZHOU teaches the limitations by stating
obtaining, by a second processing node, from the shared alert data store, a set of saved search selectors;
obtaining, by the second processing node, the first set of alert records for a saved search selector in the set of saved search selectors;
storing, by the second processing node, the first set of alert records in a local alert data store;
receiving, by the second processing node, a request to display the first set of alert records; and
displaying, by the second processing node, the first set of alert records (ZHOU pages 2 & 4-6 e.g. If the UCM system directly stores the log file of each node, not only the system storage load is high, and the log query is not friendly, cannot efficiently provide valuable log. if so, taking the traditional relationship database (for example: MYSQL) to store the mass time sequence log of the cloud computing node, then it is necessary to add a time stamp on the traditional relation type database can be used as the time sequence database).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of HE, Scrandis and ZHOU, to perform distributed optical network management of faults and alarms. (Scrandis col. 1 lines 20-25).
12. Claims 2-6, 12-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over HE in view of Scrandis and ZHOU, and further in view of Bowman.
13. With respect to claim 2,
ZHOU further discloses
a same trigger time as the identified alert record, and
a timestamp based on a time of adding the delete alert record to the shared alert data store (ZHOU page 2 e.g. If the UCM system directly stores the log file of each node, not only the system storage load is high, and the log query is not friendly, cannot efficiently provide valuable log. if so, taking the traditional relationship database (for example: MYSQL) to store the mass time sequence log of the cloud computing node, then it is necessary to add a time stamp on the traditional relation type database can be used as the time sequence database).
Although HE, Scrandis and ZHOU combination substantially teaches the claimed invention, they do not explicitly indicate a new timestamp.
Bowman teaches the limitations by stating
a new timestamp based on a time of adding the delete alert record to the shared alert data store (Bowman col. 10 lines 26-34 e.g. (48) Alarm manager 134 accepts a closure status from alarm presentation 170 when an alarm is cleared. The status indicates whether the alarm was true or false. Alarm manager 134 also accepts new time stamps in the create alarm request from FDE 130 so the events which contributed to the alarm may be retrieved from the call event database within logs database 156. The time stamps correspond to the "begin time" of the associated bucket, and the event time of the event which triggered the alarm.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of HE, Scrandis, ZHOU, and Bowman, to provide a time sequence log management system based on cloud computing and electronic device comprising the system, for solving the problem that the cloud computing node timing log in the prior art has large storage cost, high maintenance cost, poor query performance and so on (ZHOU page 2).
14. With respect to claim 3,
ZHOU further discloses
a same trigger time, a same expiration time, and a same saved search selector as the identified alert record, and
a timestamp based on a time of adding the delete alert record to the shared alert data store (ZHOU page 2 e.g. If the UCM system directly stores the log file of each node, not only the system storage load is high, and the log query is not friendly, cannot efficiently provide valuable log. if so, taking the traditional relationship database (for example: MYSQL) to store the mass time sequence log of the cloud computing node, then it is necessary to add a time stamp on the traditional relation type database can be used as the time sequence database).
Bowman further discloses a new timestamp based on a time of adding the delete alert record to the shared alert data store (Bowman col. 10 lines 26-34 e.g. (48) Alarm manager 134 accepts a closure status from alarm presentation 170 when an alarm is cleared. The status indicates whether the alarm was true or false. Alarm manager 134 also accepts new time stamps in the create alarm request from FDE 130 so the events which contributed to the alarm may be retrieved from the call event database within logs database 156. The time stamps correspond to the "begin time" of the associated bucket, and the event time of the event which triggered the alarm.).
15. With respect to claim 4,
ZHOU further discloses
a same trigger time as the identified alert record, and
a timestamp in an alert identifier field based on a time of adding the delete alert record to the shared alert data store (ZHOU page 2 e.g. If the UCM system directly stores the log file of each node, not only the system storage load is high, and the log query is not friendly, cannot efficiently provide valuable log. if so, taking the traditional relationship database (for example: MYSQL) to store the mass time sequence log of the cloud computing node, then it is necessary to add a time stamp on the traditional relation type database can be used as the time sequence database).
Bowman further discloses a new timestamp in an alert identifier field based on a time of adding the delete alert record to the shared alert data store (Bowman col. 10 lines 26-34 e.g. (48) Alarm manager 134 accepts a closure status from alarm presentation 170 when an alarm is cleared. The status indicates whether the alarm was true or false. Alarm manager 134 also accepts new time stamps in the create alarm request from FDE 130 so the events which contributed to the alarm may be retrieved from the call event database within logs database 156. The time stamps correspond to the "begin time" of the associated bucket, and the event time of the event which triggered the alarm.).
16. With respect to claim 5,
ZHOU further discloses sending, to the shared alert data store a latest trigger time in a local alert data store of the first processing node (ZHOU pages 2 & 4-6 e.g. If the UCM system directly stores the log file of each node, not only the system storage load is high, and the log query is not friendly, cannot efficiently provide valuable log. if so, taking the traditional relationship database (for example: MYSQL) to store the mass time sequence log of the cloud computing node, then it is necessary to add a time stamp on the traditional relation type database can be used as the time sequence database).
Bowman further discloses
obtaining, from the shared alert data store, a second set of alert records having a timestamp after the latest trigger time (Bowman col. 10 lines 26-34 e.g. (48) Alarm manager 134 accepts a closure status from alarm presentation 170 when an alarm is cleared. The status indicates whether the alarm was true or false. Alarm manager 134 also accepts new time stamps in the create alarm request from FDE 130 so the events which contributed to the alarm may be retrieved from the call event database within logs database 156. The time stamps correspond to the "begin time" of the associated bucket, and the event time of the event which triggered the alarm.).
17. With respect to claim 6,
ZHOU further discloses
sending, to the first processing node, a latest trigger time in a local alert data store of the first processing node (ZHOU pages 2 & 4-6 e.g. If the UCM system directly stores the log file of each node, not only the system storage load is high, and the log query is not friendly, cannot efficiently provide valuable log. if so, taking the traditional relationship database (for example: MYSQL) to store the mass time sequence log of the cloud computing node, then it is necessary to add a time stamp on the traditional relation type database can be used as the time sequence database).
Bowman further discloses
obtaining, from the shared alert data store, a second set of alert records having a timestamp after the latest trigger time and matching a set of saved search selectors having at least one alert issued, the second set of alert records comprising the new delete alert record (Bowman col. 10 lines 26-34 e.g. (48) Alarm manager 134 accepts a closure status from alarm presentation 170 when an alarm is cleared. The status indicates whether the alarm was true or false. Alarm manager 134 also accepts new time stamps in the create alarm request from FDE 130 so the events which contributed to the alarm may be retrieved from the call event database within logs database 156. The time stamps correspond to the "begin time" of the associated bucket, and the event time of the event which triggered the alarm.).
18. Claims 12-16 are same as claims 2-6 and are rejected for the same reasons as applied hereinabove.
19. Claims 18-20 are same as claims 2-4 and are rejected for the same reasons as applied hereinabove.
20. Claims 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over HE in view of Scrandis and ZHOU, and further in view of Hughes.
21. With respect to claim 8,
HE further discloses batching an update to a shared suppression data store using the plurality of new suppression keys in the local suppression cache (HE pages 7 & 10 e.g. batch).
ZHOU further discloses obtaining a plurality of new alerts based on an execution of a search (ZHOU pages 2 & 4-6 e.g. If the UCM system directly stores the log file of each node, not only the system storage load is high, and the log query is not friendly, cannot efficiently provide valuable log. if so, taking the traditional relationship database (for example: MYSQL) to store the mass time sequence log of the cloud computing node, then it is necessary to add a time stamp on the traditional relation type database can be used as the time sequence database).
Although HE, Scrandis, and ZHOU combination substantially teaches the claimed invention, they do not explicitly indicate
identifying, from the plurality of new alerts, a set of unique field values matching a set of field names listed in suppression information;
generating a plurality of new suppression keys corresponding to a plurality of combinations of the set of unique field values;
adding the plurality of new suppression keys to a local suppression cache.
Hughes teaches the limitations by stating
identifying, from the plurality of new alerts, a set of unique field values matching a set of field names listed in suppression information;
generating a plurality of new suppression keys corresponding to a plurality of combinations of the set of unique field values;
adding the plurality of new suppression keys to a local suppression cache (Hughes [0054] e.g. 2.1 Alert Suppression [0054] FIG. 7 depicts the UAS alert type configuration interface 332, in accordance with an embodiment of the invention. Alert suppression is enabled by use of an alert suppression key that is sent in as part of an Alert message, together with the Alert type and suppress period field 748 depicted in FIG. 7. Interface 332 enables alert suppression, whereby duplicate alerts are suppressed with in specified periods of time. The durations of time (e.g., seconds, minutes, hours, or days) can be entered using suppress period field 748. In an embodiment, users and administrators identify when to suppress alerts by selecting alert suppression including a Storm Suppression key in the Alert XML message. For example, this key could be the IP address of a server. This would cause multiple subsequent alerts of the same Alert type that were issued for the server with the IP address within the suppression period configured in suppress period field 748 to be suppressed. For example, if two alerts have the same alert type and suppression key selected, then they are regarded as same alert (i.e., duplicate alerts) and the second alert is discarded if the two alerts are within the same suppression period. In an embodiment, the suppression period is a tunable parameter entered in suppress period field 748.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of HE, Scrandis, ZHOU and Hughes, to provide a time sequence log management system based on cloud computing and electronic device comprising the system, for solving the problem that the cloud computing node timing log in the prior art has large storage cost, high maintenance cost, poor query performance and so on (ZHOU page 2).
22. With respect to claim 9,
ZHOU further discloses batching an update to the shared suppression data store using the plurality of new suppression keys (HE pages 7 & 10 e.g. batch). Hughes further discloses storing a plurality of existing suppression keys for a search from a shared suppression data store into a local suppression cache;
obtaining a plurality of new alerts based on an execution of the search;
generating a plurality of new suppression keys corresponding to a plurality of combinations of a set of unique field values;
suppressing the plurality of new alerts using the plurality of existing suppression keys and the plurality of new suppression keys (Hughes [0054] e.g. 2.1 Alert Suppression [0054] FIG. 7 depicts the UAS alert type configuration interface 332, in accordance with an embodiment of the invention. Alert suppression is enabled by use of an alert suppression key that is sent in as part of an Alert message, together with the Alert type and suppress period field 748 depicted in FIG. 7. Interface 332 enables alert suppression, whereby duplicate alerts are suppressed with in specified periods of time. The durations of time (e.g., seconds, minutes, hours, or days) can be entered using suppress period field 748. In an embodiment, users and administrators identify when to suppress alerts by selecting alert suppression including a Storm Suppression key in the Alert XML message. For example, this key could be the IP address of a server. This would cause multiple subsequent alerts of the same Alert type that were issued for the server with the IP address within the suppression period configured in suppress period field 748 to be suppressed. For example, if two alerts have the same alert type and suppression key selected, then they are regarded as same alert (i.e., duplicate alerts) and the second alert is discarded if the two alerts are within the same suppression period. In an embodiment, the suppression period is a tunable parameter entered in suppress period field 748.).
23. With respect to claim 10,
HE further discloses sending, by the first processing node and to a shared data store, a first alert record of the first alert and suppression information based at least in part on the first alert; (HE pages 2-3).
Hughes further discloses
issuing, by the first processing node, a first alert when first event data satisfies a trigger condition (Hughes [0010] – [0011], [0028], [0034] – [0035], [0042], [0121] and claim 8 e.g. alert trigger);
sending, by the first processing node and to a shared data store, a first alert record of the first alert and suppression information based at least in part on the first alert (Hughes [0054]);
determining, by a second processing node of the cluster of processing nodes, that second event data satisfies the trigger condition (Hughes [0010] – [0011], [0028], [0034] – [0035], [0042], [0121] and claim 8 e.g. alert trigger);
obtaining, by the second processing node and from the shared data store, the suppression information indicating that an expiration time for suppressing the first alert is unexpired (Hughes [0054]).
Response to Argument
24. On pages 11-12, Applicant alleges the cited references fail to teach "receiving, by a first processing node and responsive to a request, a delete alert record uniquely identifying an identified alert record and comprising an annotation identifying the delete alert record as being a delete alert record type."
Examiner disagrees because:
As described in HE pages 2-3, The invention claims a recording method of alarm log in cluster environment, the all the nodes report the alarm log to the record node, specifically comprising the following steps: the node pulls the alarm log of the user from the local first queue; when the node receives the alarm synchronization request of the user, storing the pulled alarm log to the local second queue; the third queue of the cache middleware obtains the alarm log stored in the local second sequence. The invention claims a recording method of alarm log in cluster environment, the pulling the reported alarm log, and according to the corresponding relation of the value of the sequence number of the alarm log and the value of the maximum alarm sequence number counter; recording the alarm log into the first alarm log file through the file reference, specifically comprising the following steps: drawing and removing the alarm log [as a delete alert record uniquely identifying an identified alert record] from the third queue by the record user node; if the value of the sequence number of the current alarm log is not greater than the value of the maximum alarm sequence number counter, discarding the current alarm log [as an annotation identifying a new delete alert record as being a delete alert record type]; if the value of the sequence number of the current alarm log is the value of the maximum alarm sequence number counter adding 1; adding the current alarm log to the last row of the first alarm log file through the file reference, and adding one to the value of the maximum alarm sequence number counter; if the value of the sequence number of the current alarm log is greater than the value of the maximum alarm sequence number counter adding 1, the sequence number is the value of the sequence number of the current alarm log subtracting one to the value of the maximum alarm sequence number counter adding a corresponding all the alarm log to write to the end of the first alarm log file, after, adding the current alarm log to the last row of the first alarm log file by the file reference, and updating the value of the maximum alarm sequence number counter as the value of the sequence number of the current alarm log, a current alarm log [as a delete alert record uniquely identifying the identified alert record] is removed/discarded when its value of the sequence number [as annotation] is not greater than the maximum alarm sequence number counter.
The disclosure reasonably describes the argued limitation of "receiving, by a first processing node and responsive to a request, a delete alert record uniquely identifying an identified alert record and comprising an annotation identifying the delete alert record as being a delete alert record type".
25. On pages 12-13, Applicant alleges the cited reference fails to teach or suggest "matching, by the first processing node and responsive to the annotation, the delete alert record to a local copy of the identified alert record based on the delete alert record uniquely identifying the identified alert record."
Examiner disagrees because:
As described in Scrandis col. 21 lines 4-19 e.g. (188) Adding/Deleting a MS Alarm Objects 200 (189) If an MS alarm object 200 is added to a channel, a check is made to determine if there is an existing MS Alarm Object 200 [as matching, by the first processing node and responsive to the annotation, the delete alert record to a local copy of the identified alert record based on the delete alert record uniquely identifying the identified alert record] with its node's IP address and the same fault type [as matching, by the first processing node and responsive to the annotation] stored in the span database 100. If a matching MS Alarm Object 200 is not found, a new MS Alarm Object 200 is created. This mechanism handles multiple alarm conditions for the same fault condition on the same channel on a node. An alarm count is increment by 1 for each uncorrelated alarm, and decreased by 1 each time an associated alarm clears. This ensures that the MS Alarm Object 200 is not deleted from the database 100 until all associated local alarm conditions have cleared [as the delete alert record to a local copy of the identified alert record based on the delete alert record uniquely identifying the identified alert record]. Note that when an MS Alarm Object 200 is deleted [as the delete alert record to a local copy of the identified alert record based on the delete alert record uniquely identifying the identified alert record], the invention recorrelates any suppressed faults associated with this parent MS Alarm Object 200, a matching/existing local MS Alarm Objects 200 with its node’s IP address and the same fault type [as annotation] is cleared/deleted.
The disclosure reasonably describes the argued limitation of "matching, by the first processing node and responsive to the annotation, the delete alert record to a local copy of the identified alert record based on the delete alert record uniquely identifying the identified alert record".
26. On page 13, Applicant alleges the cited reference fails to teach or suggest "deleting, by the first processing node and based on the annotation, the local copy of the identified alert record according to the delete alert record."
Examiner disagrees because:
As described in Scrandis col. 21 lines 4-19 e.g. (188) Adding/Deleting a MS Alarm Objects 200 (189) If an MS alarm object 200 is added to a channel, a check is made to determine if there is an existing MS Alarm Object 200 with its node's IP address and the same fault type stored in the span database 100. If a matching MS Alarm Object 200 is not found, a new MS Alarm Object 200 is created. This mechanism handles multiple alarm conditions for the same fault condition on the same channel on a node. An alarm count is increment by 1 for each uncorrelated alarm, and decreased by 1 each time an associated alarm clears. This ensures that the MS Alarm Object 200 is not deleted from the database 100 until all associated local alarm conditions have cleared. Note that when an MS Alarm Object 200 is deleted [as deleting, by the first processing node and based on the annotation, the local copy of the identified alert record according to the delete alert record], the invention recorrelates any suppressed faults associated with this parent MS Alarm Object 200, the invention recorrelates any suppressed faults associated with this parent MS Alarm Object 200, a matching/existing local MS Alarm Objects 200 with its node’s IP address and the same fault type [as annotation] is cleared/deleted [as deleting, by the first processing node and based on the annotation, the local copy of the identified alert record according to the delete alert record].
The disclosure reasonably describes the argued limitation of "deleting, by the first processing node and based on the annotation, the local copy of the identified alert record according to the delete alert record ".
Conclusion
27. 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SyLing Yen whose telephone number is 571-270-1306.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 571-272-4098. The fax and phone numbers for the organization where this application or proceeding is assigned is 571-273-8300.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist whose telephone number is 571-272-2100.
/SYLING YEN/Primary Examiner, Art Unit 2166
January 21, 2026