DETAILED ACTION
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 .
Claim Objections
Claims 1, 17, and 20 are objected to because of the following informalities: they recite "repeat duration period" but subsequently refer to "the repeat duration," creating an inconsistency in terminology. They should recite "the repeat duration period ". Appropriate correction is required.
Claim Interpretation
Applicant's specification defines the "tile transformation" solely by the data it contains, and not by any structure, format, or arrangement: each tile transformation "is defined by a: 1) 'alarm duration' period, (60) 2) 'rest duration' period 62, and 3) 'repeat duration' period 64" (PGPUB Spec [0067]). No other defining characteristic is provided. Under the broadest reasonable interpretation consistent with the specification, a "tile transformation" is therefore any discrete per-alarm-event data structure containing the recited duration values. The word "tile" is a label applied to that data structure and imparts no structural limitation entitled to patentable weight beyond the duration values expressly recited. See MPEP 2111.01.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites "activity duration period" but subsequently refers to "the alarm duration," creating an inconsistency in terminology and rendering "the alarm duration" without proper antecedent basis. Claim 1 further recites "wherein for each of the plurality of tiles," which lacks proper antecedent basis, the claim having previously recited only "tile transformations." Appropriate correction is required. For purposes of examination, "the alarm duration" is treated as referring to "the activity duration period," and "the plurality of tiles" is treated as referring to "the plurality of tile transformations." Claims 17 and 20 are rejected for the same reasons set forth in the rejection of claim 1 because they recite similar claim language. Claims 2-16, 18-19, and 21-22 are rejected the same because they depend upon claim 1, 17, or 20.
Claim 5 recites "wherein the asset is one of a point or equipment managed by the BMS." Claim 5 depends from claim 1, which recites no asset, and the limitation therefore lacks proper antecedent basis. An asset is first introduced in claim 3 ("an asset managed by the BMS"). For purposes of examination, claim 5 is treated as depending from claim 3. Appropriate correction is required.
Claim 7 recites "using the at least one certain algorithmic technique." Claim 1 recites "at least one algorithmic technique," without the modifier "certain." The limitation therefore lacks proper antecedent basis, and it is unclear whether "certain" is intended to designate a particular subset of the techniques of claim 1.
Claim 9 recites "1) alarm duration period," which lacks proper antecedent basis, claim 1 having recited an "activity duration period."
Claim 10 recites "as a 3) stale nuisance alarm label if the activity duration of the tile is greater than a third time period 3) and if no, as a 4) flickering nuisance alarm label." The designator "3)" appears twice, and it cannot be determined whether the second occurrence introduces a further condition or is a typographical error.
Claim 10 recites "the activity duration of the tile," which lacks proper antecedent basis. Claim 1 recites an "activity duration period," and claim 9 recites an "alarm duration period."
Claim 11 recites "each of the plurality of tiles," which lacks proper antecedent basis, claim 1 having recited only "tile transformations."
Claim 13 recites "active duration period," which lacks proper antecedent basis, claim 1 having recited an "activity duration period." Claim 13 further recites "each of the tile clusters," which lacks proper antecedent basis, the claim having previously recited only the clustering of "like tiles to one another."
Claim 14 recites "active duration period," which lacks proper antecedent basis, claim 1 having recited an "activity duration period." Claim 14 further recites "each of the tile clusters," which lacks proper antecedent basis, claim 14 reciting no clustering whatsoever and instead reciting a classification model that "classifies each tile."
Claim 18 recites "wherein the one or more processors is further configured to," which lacks proper antecedent basis, claim 17 reciting no processors. Claim 18 further recites "each of the plurality of tiles," which lacks proper antecedent basis.
Claim 19 recites "active duration period" and "each of the tile clusters," which lack proper antecedent basis for the reasons set forth in the rejection of claim 13 above.
Claim 20 recites "the alarm data stream, received from the BMS," which lacks proper antecedent basis, the preamble reciting an alarm data stream received from an automation and industrial control system and reciting no BMS. It cannot be determined whether the alarm data stream is intended to be received from a building management system or from an automation and industrial control system more generally. Claim 20 further recites "the alarm duration," "the plurality of tiles," "active duration period," and "each of the tile clusters," which lack proper antecedent basis for the reasons set forth in the rejections of claims 1 and 13 above.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 19 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 19 recites "The computer-implemented method as recited in claim 1." Claim 1 is a computer monitoring system, not a computer-implemented method, and claim 19 therefore fails to refer back to a preceding claim in a proper dependent form. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
Claim(s) 1-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Menzel et al. (US 2022/0319304 A1) in view of Srinivasan et al. (US 2018/0322770 A1) further in view of Duraisingh et al. (US 2019/0107830 A1).
Regarding claim 1, Menzel discloses a computer monitoring system for classifying an alarm data stream for a certain time period into at least one of a plurality of nuisance alarm labels (Menzel discloses a system that analyzes aggregated alarm information over an analysis period ([0027]: "a minimal quantity of occurrences of the at least one identified alarm nuisance behavior over a given analysis period"; [0293]: "calculating over an analysis period (e.g., 1-month, or 1-quarter as example)") and characterizes the alarm behavior by grouping it into one or more of a plurality of nuisance alarm labels ([0025]: "grouping the at least one identified alarm nuisance behavior into one or more of a plurality of predefined or prescribed alarm nuisance behaviors...include...stale alarm nuisance behavior, chattering alarm nuisance behavior, fleeting alarm nuisance behavior, and flood alarm nuisance behavior"). ), including a plurality of time spaced alarm events (Menzel discloses that each alarm carries pickup and dropout timestamps ([0162]: "the beginning of an event…as well as the dropout timestamp of an event"; [0232]: "is there event pickup timestamped data and event dropout timestamped data for the same event"), and that nuisance characterization is appended to the time-series information associated with the identified alarms ([0028]).), comprising:
one or more storage devices having instructions stored thereon that, when executed by one or more processors (Menzel [0029] and claim 26: "at least one processor; at least one memory device coupled to the at least one processor, the at least one processor and the at least one memory device configured to: process...aggregate...analyze...take or perform at least one action." Implemented on a processor of an IED or a cloud-based diagnostic system ([0152]).), cause the one or more processors to:
transform each of the plurality of alarm events in the alarm data stream, received from the BMS, into a respective discrete tile transformation whereby each tile transformation includes a: 1) activity duration period, and 2) rest duration period, wherein for each of the plurality of tiles the alarm duration is a period of time the alarm event is active (Menzel derives this value for each alarm occurrence. FIG. 3C / [0201]: the y-axis (item 331) is "the duration of the event in seconds." [0186]: metrics derived per IED and per alarm type include "percentile of duration." [0233]: "each alarm duration may be checked against the event and/or alarm type."), and the rest duration period is a period of time the alarm event is inactive (Menzel derives this value for each alarm occurrence. FIG. 3C / [0201]: the x-axis (item 332) is "duration to the next re-occurrence of the alarm in seconds." [0186]: "duration to next alarm." [0233]: "the duration until a next event is detected/triggered may also be determined. This may, for example, be a key metric used to detect specific types of nuisance behaviors including chattering and fleeting for a given event or alarm."); and
perform analytics on the generated plurality of tile transformations, using at least one algorithmic technique, to classify the received alarm data stream as at least one of the plurality of nuisance alarm labels (Menzel FIG. 5 and [0239]–[0257] disclose an ordered rule/threshold cascade applied to the per-event duration metrics that tags the alarm as stale (blocks 515/520), else chattering (blocks 525/530), else fleeting (blocks 535/540), else flood (blocks 545/550). The classification is expressly threshold-driven on the very durations recited: chattering is determined by "any alarm with a duration to next alarm below a certain threshold" ([0246]); fleeting by whether "the duration to next alarm falls within a lower threshold and a higher threshold" ([0251]); stale by "any alarm with a duration lasting more than x hours" ([0241]). Menzel further discloses performing this with machine learning techniques, including "cluster-based, K nearest neighbor, LSTM, ARIMA, Neural Networks" anomaly detection ([0243]) and clustering to derive thresholds ([0295]).).
However, Menzel does not disclose transforming each alarm event into a respective discrete tile transformation, i.e., a discrete per-alarm-event data structure generated for each event in the stream; and the repeat duration period, defined as the aggregate of a period of time the alarm event is active and inactive. Menzel also does not expressly disclose the alarm data stream received from a building management system (BMS) comprises a plurality of time spaced alarm events each having an active state and an inactive state.
In regard to the discrete per-event transformation: Srinivasan discloses arranging the alarm data into a data table having one row per alarm event, and processing that table row-by-row to generate, for each individual alarm event, the two duration values at issue. Srinivasan [0059] states: "assume that a data table includes rows containing alarms in the sequence in which the alarms were issued ... the alarms are analyzed row-by-row. Denote the current row being examined as the j.sup.th row. For the j.sup.th row, calculate the duration of the alarm and the time between this alarm and the alarm in the (j+1).sup.th row." Each such row is a discrete data structure generated for a single alarm event and containing (1) the period of time that alarm event is active — "the duration of the alarm" — and (2) the period of time that alarm event is inactive — "the time between this alarm and the alarm in the (j+1)th row." Under the construction set forth above, Srinivasan's jth row is the claimed "tile transformation." Srinivasan performs this operation for every alarm in the table: "Once the processing of the jth row is completed, the same process could be repeated for each subsequent row until the whole table has been processed" ([0059]), thereby transforming each of the plurality of alarm events into a respective discrete tile transformation. Srinivasan further applies rule-based analytics to those per-row values to assign nuisance alarm labels — "If the calculated duration of the alarm is less than the corresponding timer on delay, the alarm is a fleeting alarm ... If the calculated time between the alarms is less than the corresponding timer off delay, the alarm is a chattering alarm" ([0059]) — and does so by at least one processor executing instructions stored on at least one storage device ([0039]–[0040]) via an analytics engine ([0050]).
In regard to the repeat duration: Srinivasan's jth row contains both operands of the claimed aggregate: the active duration and the inactive (between-alarm) duration. The claimed "repeat duration period," being nothing more than the arithmetic sum of two values already computed and stored in the same jth row, is at minimum an obvious variation. Combining two known values by a known mathematical operation to obtain their aggregate yields an entirely predictable result and is prima facie obvious. See MPEP 2143(A). Menzel itself demonstrates that an ordinarily skilled artisan combines these two operands arithmetically as a matter of routine: Menzel [0356] computes, for a single alarm event, "a ratio of 80 (i.e., 4 sec of 'time-to-next'/0.05 sec of 'alarm duration')." Substituting a sum for a quotient of the same two operands drawn from the same per-alarm data is the substitution of one known arithmetic operation for another to obtain a predictable result. In the alternative, the repeat duration is inherently determinable from the pickup and dropout timestamps that Menzel ([0162], [0232]) and Srinivasan ([0059]) each already store for every alarm event, such that the claimed aggregate is necessarily present in the prior-art data. See MPEP 2112.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date to implement Menzel's per-alarm duration analysis using Srinivasan's row-by-row, per-alarm-event tabulation, and to include therein the aggregate (repeat) duration, because Menzel expressly requires the very per-event values that Srinivasan's tabulation produces but does not specify the data structure used to produce them — Menzel repeatedly calls for the "duration" and the "duration to next alarm" of each alarm occurrence ([0186], [0201], [0233]) as the "key metric used to detect specific types of nuisance behaviors including chattering and fleeting" ([0233]) — such that a skilled artisan seeking to implement Menzel would naturally look to Srinivasan, which is in the same field of endeavor (identifying and rationalizing chattering and fleeting nuisance alarms in automation and control systems under the same ISA-18.2/IEC 62682 alarm-management standards; compare Menzel [0031], [0148] with Srinivasan [0003]) and which discloses precisely the missing implementation detail; using Srinivasan's known row-per-alarm technique to generate the per-event durations Menzel expressly demands is nothing more than the use of a known technique to improve a similar system in the same way, with a wholly predictable result (MPEP 2143(A), (C), (D)), and the skilled artisan would have had a reasonable expectation of success because every operation involved — differencing pickup and dropout timestamps, differencing successive alarms' timestamps, and summing the two — is elementary arithmetic performed on timestamp data that both references already collect and store; moreover, the skilled artisan would have been motivated to do so to obtain the benefit both references identify, namely the automated, scalable separation of nuisance alarms from meaningful alarms so that operators overwhelmed by alarm volume can focus on real issues (Menzel [0010], [0013], [0149]–[0151]; Srinivasan [0002]–[0003], [0026]).
However, Menzel in view of Srinivasan does not expressly disclose that the alarm data stream received from a building management system (BMS) comprises a plurality of time spaced alarm events each having an active state and an inactive state. Menzel names a building management system among the sources whose alarm information is aggregated and analyzed ([0011], [0022], [0064]) and addresses BMS- and HVAC-originated events and alarms ([0156], [0163], [0223], [0363]). Duraisingh is additionally relied upon as expressly disclosing a BMS that generates the recited alarm data stream.
Duraisingh discloses a building management system (BMS) comprising "building equipment operable to affect a physical state or condition of a building" and a system manager that "obtain alarm data from the building equipment" (claim 1; [0002]–[0003]). The BMS system manager "monitor an event list comprising a plurality of alarm events reported by the building equipment" ([0008]), and the alarm data so obtained is expressly stored and transmitted as a timeseries — "store the alarm data as a sample of an alarm timeseries" (claim 1; [0003], [0230]–[0233]). Critically, Duraisingh discloses that each such BMS alarm event carries exactly the active/inactive state and timing information from which the claimed activity, rest, and repeat durations are derived: "An alarm may include an indication of whether the alarm is active (e.g., true/false), a time at which the alarm became active, a time at which the alarm became inactive" ([0229]). Duraisingh thereby discloses a binary alarm timeseries of time-spaced alarm events received from a BMS, that is, the claimed "alarm data stream received from a building management system (BMS)...wherein the alarm data stream includes a plurality of time spaced alarm events." Duraisingh further discloses the recited computing structure: a processing circuit having a processor configured to execute computer code or instructions stored in memory ([0109]–[0110]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply the nuisance-alarm classification of Menzel and Srinivasan to Duraisingh's BMS alarm timeseries, because Menzel already identifies a building management system as one of the alarm sources it analyzes for nuisance behavior ([0022], [0064], [0156]), leading the skilled artisan directly to a BMS alarm feed of the type Duraisingh supplies. Duraisingh's alarm data requires no adaptation: each alarm already carries an active/inactive indication and the times at which it became active and inactive ([0229]), from which the claimed activity, rest, and repeat durations follow by simple subtraction and addition. The combination is therefore the application of a known technique to a known device ready for improvement, yielding a predictable result with a reasonable expectation of success (MPEP 2143(D)). Motivation is further supplied by Applicant's own admissions that BMS nuisance alarms overwhelm building managers and must be separated from useful alarms (PGPUB Spec [0004]–[0005]), and that a BMS and a SCADA system are interchangeable for purposes of the claimed invention (PGPUB Spec [0062]) — establishing both analogous art and an express reason to combine.
Regarding claim 2, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the plurality of nuisance alarm labels include a: 1) chattering alarm, 2) fleeting alarm, 3) flickering alarm, and 4) stale alarm (Menzel further discloses wherein the plurality of nuisance alarm labels include a: 1) chattering alarm, 2) fleeting alarm,…and 4) stale alarm (Menzel [0025] and [0239]: the plurality of nuisance behaviors into which an identified alarm is grouped includes "stale alarm nuisance behavior, chattering alarm nuisance behavior, fleeting alarm nuisance behavior, and flood alarm nuisance behavior," each separately tagged in FIG. 5 — stale at blocks 515/520, chattering at blocks 525/530, fleeting at blocks 535/540; [0241], [0245], [0250] reciting the ISA-18.2 definitions of the stale, chattering, and fleeting alarm, respectively). Srinivasan likewise discloses the chattering and fleeting labels and assigns them on a per-alarm basis ([0053], [0059]). Menzel teaches the behavior Applicant designates by the flickering term. Applicant defines the flickering label operationally by a single criterion — that the tile's rest duration fall below a threshold (PGPUB Spec [0069]: "a 3) flickering nuisance alarm label (63) if the rest duration of the tile is less than a third time period"). Menzel applies that identical test to that identical variable, determining chattering by "any alarm with a duration to next alarm below a certain threshold" ([0246]), the duration to next alarm being the period during which the alarm is inactive. Menzel therefore performs the very determination by which Applicant identifies a flickering alarm and reports the result under a different name. A difference in nomenclature between the claim and the prior art does not patentably distinguish the claim; a reference must be considered for everything it teaches. See MPEP 2131.01. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to include a fourth nuisance alarm label, designated "flickering," among Menzel's plurality of nuisance alarm labels, because Menzel already applies the threshold test by which Applicant identifies that behavior ([0246]) and expressly instructs that its enumerated behaviors "are only a few possible types of alarm nuisance behaviors" and that other "example types of alarm nuisance behaviors will be apparent to one of ordinary skill in the art" ([0239]), while further disclosing user-defined and user-tagged nuisance behavior types ([0024], [0256]); the skilled artisan would have been motivated to designate an additional category in order to give operators a finer-grained diagnosis, Menzel teaching that different nuisance behaviors call for different remedies ("the system may choose to apply different mitigation or remediations, depending on the type(s) of nuisance behaviors," [0219]); and the modification requires no change to Menzel's data or analytics, amounting to the selection of nomenclature applied to a classification output Menzel already generates, with a reasonable expectation of success. Further, subdividing rapid transition nuisance behavior into separately named labels differentiated only by threshold is an obvious implementation detail, the prior art already doing exactly that in separating chattering from fleeting (Menzel [0251]; Srinivasan [0059]).).
Regarding claim 3, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the alarm data stream received from the BMS is an electronic signal derived from rules contingent upon continuously monitored time defined variables associated with an asset managed by the BMS (Menzel discloses that alarms are generated by applying threshold rules to continuously captured measurement data, the signals being "continuously or semi-continuously/periodically captured/recorded and/or transmitted and/or logged" with "alarms...detected/identified based on the energy-related signals" (Menzel [0082]), events being "detected, for example, when a threshold is crossed" ([0158]), and an alarm being "triggered in response to the electrical measurement data being above one or more upper alarm thresholds or below one or more lower alarm thresholds" ([0084]), where the monitored variables are associated with a particular managed load or item of equipment at a metering point ([0077]), expressly including building assets such as "the types of loads monitored by an IED (e.g., lighting, HVAC)" ([0163]); Duraisingh correspondingly discloses a BMS in which networked sensors continuously measure time-varying building variables — "temperature sensors, humidity sensors, pressure sensors, lighting sensors, security sensors, or any other type of device configured to measure and/or provide an input" (Duraisingh [0080]) — used as feedback against setpoints to control "a variable state or condition (e.g., temperature, humidity, airflow, lighting)" ([0081]), with the resulting alarm data obtained by the system manager "from the building equipment" managed by the BMS (Duraisingh, claim 1 and [0003]).).
Regarding claim 4, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 3, wherein the rules are contingent upon one or more user defined configurations (Menzel discloses that the thresholds governing alarm generation are user configured, an alarm being "triggered either on the same thresholds or on different thresholds, customized for the installation," where "one site, part of a site, or even one IED may be configured to generate alarms only if a voltage sag impacted the system" (Menzel [0162]); Menzel further discloses device settings including "thresholds to trigger events and alarm detections" as configurable data associated with each device ([0163]), that thresholds "may be set by domain experts, refined by users, and/or by system engineers at the commissioning time" ([0242]), and that alarm nuisance criteria may be "user-defined (e.g., customized)" ([0024]), including a user-defined duration threshold that "may be different per site or segment sensitive" ([0246]); Menzel additionally discloses recommending and updating the on-delay and off-delay duration settings for each device and alarm, with user validation before implementation ([0200], [0224]); Duraisingh correspondingly discloses that a user may change the alarm-governing configuration of BMS equipment, a command service being "configured to change any data values including setpoints, configuration parameters, schedules, and other types of data used by system manager 302 and/or equipment 1002" and permitting a user to "change the value of any property that is defined as writable in the equipment's equipment model template" (Duraisingh [0213], and [0234]).).
Regarding claim 5, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the asset is one of a point or equipment managed by the BMS (Duraisingh discloses a BMS data model in which each item of equipment — for example an "RTU, zone coordinator, zone controller, thermostat controller" — is associated with "one or more properties 1118 (e.g., data points or attributes)" and with an alarm list, the monitored variables being reported per property (Duraisingh [0187], [0188]); Duraisingh further discloses that an "equipment model for a device can include a collection of point objects that provide information about the device...and store present values of variables or parameters used by the device," including "output variables provided by the device (e.g., temperature measurement, feedback signal, etc.)" ([0072]), and expressly associates the alarm data with the managed asset, stating that "each alarm 1114 is associated with equipment 1112" while each reported timeseries "is fully defined by both a FQR and the property 1118 (e.g., data point) being reported" ([0189]); Menzel correspondingly discloses that each monitoring device monitors a particular managed load or item of equipment at a metering point (Menzel [0077]), expressly including building assets such as "the types of loads monitored by an IED (e.g., lighting, HVAC)" ([0163]).).
Regarding claim 6, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein performing analytics to classify the received alarm data stream as at least one of the plurality of nuisance alarm labels, includes a determination of at least one of: a) determining which of the plurality of nuisance alarm labels is associated with a greatest number of generated tile transformations (Menzel discloses deriving, for each identified nuisance behavior, a count of the alarms exhibiting that behavior, stating that "assorted metrics may be detected or derived per detected nuisance behavior," including the "quantity of alarms for period" and the "quantity of alarms per interval when nuisance behavior occurs" (Menzel [0183], [0186]), and that the action taken in response to an identified nuisance behavior includes "characterizing and/or quantifying the at least one identified alarm nuisance behavior" ([0025], [0177]); Menzel further discloses comparing those per-behavior quantities to identify the greatest, disclosing "global metrics...for the nuisance behaviors," including "the quantity of chattering nuisance behavior in analysis period," together with metrics "to identify specific alarms and IEDs contributing the most to the given nuisance behavior, the top ten worst contributors" ([0209]), and selecting the "most frequently re-occurring pattern," quantified as "57% of the occurrences in this group (i.e., 8 out of 14 sequences)" ([0354]); under the combination applied to claim 1, in which each alarm event is transformed into a respective tile transformation, Menzel's count of alarms bearing a given nuisance behavior is a count of the tile transformations associated with that nuisance alarm label). To the extent Applicant contends that Menzel quantifies each nuisance behavior without expressly selecting the greatest, such a comparison would have been obvious, Menzel computing the per behavior quantities for the express purpose of prioritizing remediation — to "determine the action to prioritize, it may be useful to know what part and how many of the 'overwhelming periods/intervals' may be reduced or resolved" ([0300]) — and selecting the most useful target "based on the count of alarms and of the reoccurrences of the pattern" ([0311]). Identifying which nuisance behavior carries the greatest count is the ordinary and predictable use of counts Menzel already generates, and would have been obvious in order to direct remediation effort to the behavior contributing most heavily to the alarm burden.), and b) determining which of the plurality of nuisance alarm labels has a greatest time value defined by an aggregate sum of the repeat duration values for each tile transformation associated with a certain nuisance alarm label (It would have been obvious to rank the nuisance alarm labels by the aggregate sum of the repeat duration values rather than by count, because Menzel already computes both the counts and the constituent per-alarm duration values ([0183], [0186]) and already ranks nuisance behaviors by aggregated metrics to prioritize remediation ([0209], [0300]); substituting a duration weighted aggregate for a count-based aggregate is the simple substitution of one known ranking metric for another drawn from the same data, yielding the predictable result of identifying the nuisance behavior occupying the greatest share of time (MPEP 2143(B)). Menzel supplies the motivation, teaching that long-duration alarms "present over longer periods such as hours, or even days and weeks, will become a baseline of alarms when present" ([0192]) and thus dominate the operator's alarm picture irrespective of count. Claim 6 requires a determination of "at least one of" alternatives (a) and (b); disclosure of either satisfies the limitation.).
Regarding claim 7, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein performing analytics on the generated plurality of tile transformations, using the at least one certain algorithmic technique, classifies the received alarm data stream as a plurality of nuisance alarm labels (Menzel discloses that the characterization of an identified alarm nuisance behavior "includes grouping the at least one identified alarm nuisance behavior into one or more of a plurality of predefined or prescribed alarm nuisance behaviors, user-defined alarm nuisance behaviors, or learned alarm nuisance behaviors," those behaviors including the stale, chattering, fleeting, and flood types (Menzel [0025], and [0190], and claim 12), the recitation of "one or more" expressly encompassing the assignment of two or more such labels; Menzel further discloses that multiple nuisance behaviors are assigned concurrently, stating that "several nuisance behaviors may co-occur," and illustrating that during a flood period "it is possible to observe several alarms displaying chattering nuisance alarms behavior," such that the flood and chattering labels attach to the same alarm data over the same analysis period ([0218]); Menzel further confirms that plural labels are carried forward in the analysis, disclosing that "the system may choose to apply different mitigation or remediations, depending on the type(s) of nuisance behaviors" ([0219]), and reporting per-behavior metrics separately for each behavior identified in the analysis period ([0209]). Menzel's threshold cascade and machine learning techniques, applied per analysis interval and iterated over all intervals of the analysis period ([0257], FIG. 5, block 555), assign each applicable nuisance label to the alarm data stream, thereby classifying that stream with a plurality of nuisance alarm labels.).
Regarding claim 8, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the at least one algorithmic technique is an Expert System computer algorithm (Menzel discloses classifying each alarm by an ordered cascade of expert-derived threshold rules, tagging the alarm as stale, else chattering, else fleeting, else flood according to whether the per-alarm duration metrics meet the corresponding thresholds (Menzel, FIG. 5 and [0239]–[0257]); Menzel expressly identifies those governing criteria as expert-derived, disclosing that the predefined or prescribed nuisance behaviors are "defined based, at least in part, on good engineering practices, thresholds defined during one of the typical steps of alarms ISA 18.2 'audit and philosophy loop'...or at commissioning of a site" ([0171], and claim 8), that the thresholds "may be set by domain experts, refined by users, and/or by system engineers at the commissioning time" ([0242]), and that the classification of a given behavior "requires domain expertise" which the system applies on the expert's behalf ([0210]); Menzel further discloses applying "expertise or commonsense rules" to filter and correct the statistical classifications ([0298]), a "hybrid inference+expertise-based model" for deriving the fleeting threshold ([0251]), and "expert rules" and "expert incompatibility rules" applied by the system to validate and refine its groupings ([0308], [0342], [0364]); Srinivasan correspondingly discloses assigning the fleeting and chattering labels by rule-based comparison of each alarm's computed duration and time-between-alarms against timer settings (Srinivasan [0059]), using "a decision tree rule structure that is constructed based on domain knowledge" ([0058]). Menzel's rule-based threshold cascade, populated with criteria derived from domain experts and good engineering practice, is a computer program that applies expert judgment to classify the alarm data, and therefore satisfies the recited Expert System computer algorithm as Applicant has defined that term.).
Regarding claim 9, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 8, wherein the Expert System computer algorithm is configured to label each of the plurality of tile transformations as one of the plurality of nuisance alarm labels based upon a determination of a respective tile's: 1) alarm duration period, 2) rest duration period, and 3) repeat duration period (Menzel discloses an ordered rule cascade that tests each alarm against thresholds applied to those two per-alarm durations and assigns a single resulting label, tagging the alarm as stale where "any alarm with a duration lasting more than x hours" is found (Menzel [0241]), else as chattering where "any alarm with a duration to next alarm below a certain threshold" is found ([0246]), else as fleeting where "the duration to next alarm falls within a lower threshold and a higher threshold" ( [0251]), the branches being mutually exclusive such that each alarm receives one label (FIG. 5, blocks 515–550, and [0239]–[0257]); Srinivasan correspondingly labels each alarm by comparing that alarm's computed duration and time-between-alarms against timer settings, assigning the fleeting label where "the calculated duration of the alarm is less than the corresponding timer on delay" and the chattering label where "the calculated time between the alarms is less than the corresponding timer off delay" (Srinivasan [0059]); under the combination applied to claim 1, in which each alarm event is transformed into a respective tile transformation containing those durations, this per-alarm labeling is the labeling of each respective tile transformation. The combination does not expressly disclose labeling based additionally upon a determination of 3) repeat duration period. However, the repeat duration is a value contained within each tile transformation under the combination applied to claim 1, being the aggregate of the two durations upon which Menzel and Srinivasan already condition the labeling, and Menzel demonstrates that a metric combining those same two per-alarm durations serves as a discriminating criterion for classifying an alarm event, computing "a ratio of 80 (i.e., 4 sec of 'time-to-next'/0.05 sec of 'alarm duration')" and using that indication to classify and separate the incident (Menzel [0356]). It would therefore have been obvious to one of ordinary skill in the art before the effective filing date to condition the labeling additionally upon the repeat duration, this being the use of a further threshold criterion drawn from data already stored in each tile to yield the predictable result of assigning the nuisance label; the skilled artisan would have been motivated to do so in order to distinguish among nuisance behaviors that Menzel teaches are differentiated only by where the per-alarm durations fall relative to selected thresholds ( [0246], [0251]), with a reasonable expectation of success, the modification requiring only an additional comparison against a value already present.).
Regarding claim 10, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 9, wherein the Expert System computer algorithm is configured to label each of the plurality of tile transformations as one of a: 1) chattering nuisance alarm label if the determined repeat duration of the tile is less than a first time period, and if no, as a 2) fleeting nuisance alarm label if the activity duration of the tile is less than a second time period, and if no, as a 3) stale nuisance alarm label if the activity duration of the tile is greater than a third time period 3) and if no, as a 4) flickering nuisance alarm label if the rest duration of the tile is less than a fourth time period, and if no, then as a 5) normal (non-nuisance) alarm label (Menzel discloses an ordered sequence of mutually exclusive threshold tests applied to each alarm, in which the alarm is tagged with the first nuisance label whose condition is satisfied and, failing every test, is tagged with no nuisance behavior (Menzel, FIG. 5 and [0239]–[0257]: stale at blocks 515/520, else chattering at blocks 525/530, else fleeting at blocks 535/540, else flood at blocks 545/550, else proceeding to block 555), Menzel expressly recognizing the resulting non-nuisance class in disclosing that later processing may act "only on nuisance events and/or alarms, or conversely, only on events and/or alarms which do not display any nuisance behavior" ([0195]); as to the fleeting branch, Srinivasan discloses the identical test on the identical variable — "If the calculated duration of the alarm is less than the corresponding timer on delay, the alarm is a fleeting alarm" (Srinivasan [0059]) — corroborated by Menzel's ISA-18.2 definition of a fleeting alarm as one transitioning between active and not active states "in a short period of time without rapidly repeating" (Menzel [0250]); as to the stale branch, Menzel discloses the identical test on the identical variable and in the identical direction, identifying a stale alarm by "any alarm with a duration lasting more than x hours" ([0241]); as to the flickering branch, Menzel applies the identical test on the identical variable, identifying the behavior by "any alarm with a duration to next alarm below a certain threshold" ([0246]), the duration to next alarm being the period the alarm is inactive; and as to the recited first through fourth time periods, the claim recites no value, range, or relationship among them, and Menzel discloses setting such thresholds for each determination, whether prescribed by good engineering practice, user-defined per site or segment, or learned by the system ( [0171], [0241]–[0243], [0246], [0251]). Menzel designates the flickering branch's label "chattering" rather than "flickering," but for the reasons set forth in the rejection of claim 2 above, a difference in nomenclature applied to the same determination does not patentably distinguish the claim. As to the chattering branch, Menzel does not expressly recite the sum of the two per-alarm durations as the chattering threshold. Menzel does, however, condition the chattering determination on both constituent durations jointly, plotting each alarm occurrence against event duration on one axis and duration to next occurrence on the other and taking the junction of the two threshold lines as the chattering criterion (Menzel [0201]–[0202], FIG. 3C, items 331, 332, 334, 335, 336). It would therefore have been obvious to one of ordinary skill in the art before the effective filing date to apply the chattering threshold to the repeat duration — a value already contained within each tile transformation under the combination applied to claim 1 — rather than to its two constituents separately, because Menzel already conditions that determination on both constituents jointly and because a chattering alarm is one completing an active-inactive cycle within a short time, a condition the aggregate expresses directly; applying a threshold to a value already stored, in place of thresholds applied to the values from which it is derived, yields the predictable result of identifying rapidly cycling alarms, with a reasonable expectation of success. As to the recited ordering of the branches, the selection of an order among a finite set of known threshold tests, absent a showing of criticality or unexpected result, is a matter of obvious implementation detail. See MPEP 2144.04(IV)(C). Menzel discloses an ordered cascade of the same character employing a different sequence (Menzel, FIG. 5). Examiner further notes that Applicant's own specification recites a different order than claim 10 for the same five branches, placing the flickering test third and the stale test fourth (PGPUB Spec [0069]), whereas claim 10 places the stale test third and the flickering test fourth. Applicant's disclosure of two different orderings for the same set of tests is itself evidence that the particular order is not critical.).
Regarding claim 11, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the one or more processors is further configured to relabel each of the plurality of tiles as another nuisance alarm label based upon further analysis of each of the plurality of tiles using one of either a: 1) K-nearest Neighbor algorithmic technique (Menzel expressly names the K-Nearest Neighbor technique among the machine learning algorithms applied to the per-alarm duration data for classification, disclosing that thresholds "may also be inferred by the system by learning what are 'normal' durations per type of event and/or alarm," that "the system may use a machine learning algorithm to detect outliers or model 'normal behaviors,'" and that all "of these machine learning algorithms may be encompassed in the term of 'anomaly detection algorithms' in the field of unsupervised machine learning (e.g., cluster-based, K nearest neighbor, LSTM, ARIMA, Neural Networks, etc.)" (Menzel [0243]); Menzel further discloses relabeling an alarm previously assigned a nuisance label, stating that where thresholds "are redefined (e.g., due to changes in customer needs or constraints)," or "where new types of alarm nuisance behaviors are added," it "may be desirable to further characterize and/or recharacterize a previously characterized alarm nuisance behavior" ( [0258]), and disclosing iterative reprocessing of its classifications upon detection of changed input data or incorrect grouping ( [0308], [0352])). To the extent Menzel does not expressly state that the recharacterization of [0258] is performed by the K-Nearest Neighbor technique named [0243], it would have been obvious to one of ordinary skill in the art before the effective filing date to employ that named technique for that disclosed recharacterization, this being the use of an algorithm the reference already designates as suitable for classifying its per-alarm duration data to a reclassification the reference already calls for, yielding the predictable result of assigning a revised nuisance label; the skilled artisan would have been motivated to do so because Menzel teaches that classification thresholds are site- and segment-dependent and subject to revision ( [0173], [0242], [0246]), such that alarms initially labeled under one set of thresholds require reassessment under another, with a reasonable expectation of success, the technique operating on per-alarm duration values the combination already stores in each tile transformation.); or 2) Nearest Centroids algorithmic technique (Claim 11 recites the techniques in the alternative; disclosure of either satisfies the limitation.).
Regarding claim 12, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the at least one algorithmic technique is an Unsupervised machine learning (ML) algorithmic technique (Menzel discloses classifying its per-alarm duration data by unsupervised machine learning, stating that thresholds "may also be inferred by the system by learning what are 'normal' durations per type of event and/or alarm," that "the system may use a machine learning algorithm to detect outliers or model 'normal behaviors,'" and that all "of these machine learning algorithms may be encompassed in the term of 'anomaly detection algorithms' in the field of unsupervised machine learning (e.g., cluster-based, K nearest neighbor, LSTM, ARIMA, Neural Networks, etc.)" (Menzel [0243]); Menzel further discloses applying clustering to derive the classification thresholds from the alarm data itself, disclosing that "using clustering, we may find 4 clusters," from whose upper bounds "we may deduce a threshold at 2, 10 and 45 (alarms per 10-minute interval)" separating normal from abnormal and extreme values ([0295]), and identifying such methods as belonging to "the field of outlier identification or anomaly detection" ([0296]).).
Regarding claim 13, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 12, wherein the Unsupervised ML technique consists of a Centroid-based Clustering algorithm that clusters like tiles to one another dependent upon the determined: 1) rest duration period, and 2) active duration period for each of the plurality of tiles, wherein each of the tile clusters is labeled with one of the nuisance alarm labels (Menzel discloses clustering by the K-means algorithm, a centroid-based technique, stating that a distance matrix "is the input for a hierarchical clustering algorithm (e.g., using K means clustering)," with the optimal number of clusters determined and the clustering tree cut at that level (Menzel [0302]); Menzel further discloses resolving the resulting clusters into nuisance classifications, disclosing that "using clustering, we may find 4 clusters" spanning defined value ranges, from whose upper bounds "we may deduce a threshold at 2, 10 and 45," whereby the clusters are resolved into "extreme high values" and "abnormally high values (aka outliers)" against normal values ([0295]), each analyzed unit being thereafter tagged accordingly ([0297], [0299]). The combination does not expressly disclose clustering the tiles dependent upon the determined rest duration period and active duration period for each of the plurality of tiles. Menzel does, however, treat those two per-alarm durations as the paired coordinates by which alarm occurrences are grouped for nuisance classification, plotting each individual occurrence as a discrete point whose one coordinate is "the duration of the event in seconds" and whose other is "duration to the next re-occurrence of the alarm in seconds," and resolving the chattering classification at the junction of percentile boundaries drawn on both axes (Menzel [0201]–[0202], FIG. 3C, items 331, 332, 333, 334, 335, 336). Menzel further directs that its clustering be extended beyond a single feature to additional alarm attributes, stating that the system "may add additional criteria for the clustering to extend beyond the time co-occurrence measurement and move towards multi-dimensional clustering (e.g., adding alarm duration, alarm types, alarm severity score, alarm impact, event source location, etc.)" ([0364]). It would therefore have been obvious to one of ordinary skill in the art before the effective filing date to cluster the tile transformations on their rest duration and active duration values, because Menzel already treats those two durations as the paired coordinates in which alarm occurrences are grouped and nuisance boundaries are drawn ([0201]–[0202]), already applies centroid-based clustering to derive nuisance classifications from alarm data ([0295], [0302]), and expressly directs extension of the clustering to further alarm attributes including alarm duration ([0364]); this is the combination of prior art elements according to known methods yielding the predictable result of grouping alarms of like nuisance behavior. The skilled artisan would have been motivated to do so because Menzel teaches that nuisance thresholds are site- and segment-dependent and are advantageously inferred from the data rather than fixed ([0173], [0243], [0295]), such that clustering in the duration space yields boundaries adapted to the installation, with a reasonable expectation of success, the clustering operating on values the combination already stores in each tile transformation.).
Regarding claim 14, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the at least one algorithmic technique further includes a Supervised machine learning (ML) algorithmic technique utilizing a trained classification model that classifies each tile dependent upon the determined: 1) rest duration period, and 2) active duration period for each of the plurality of tiles, wherein each of the tile clusters is labeled with one of the nuisance alarm labels (Menzel discloses learning the nuisance classification from labeled examples supplied by users, disclosing "learned alarm nuisance behavior" that is "learned from analysis of data received from at least one of: system users, and I/O systems and devices" (Menzel [0024], and claims 7 and 9), and that "the users of the EPMS may use a mobile application enabling the tagging of alarms as nuisance behaviors" ([0171]); Menzel further discloses generalizing those user labels into a model applied to subsequent alarms, disclosing that "the system may also be trained by users what is acceptable...by implementing a user feedback loop to train the system" ([0203]), that the system "may also be taught what thresholds (and other characteristics) are typical for each given nuisance behavior through analysis of user interactions" and "inferred (i.e., learned, derived) from user tagging," where "each team may have an interface or a tool to tag an alarm as displaying a nuisance behavior, enabling users to select the type of nuisance behavior being displayed," from which "the system may generalize the team or user definitions for the alarms" ([0256]), and that the system may "over time (e.g., a 6-month learning period), learn and derive" from user inputs ([0342]). The combination does not expressly disclose that the trained classification model classifies each tile dependent upon the determined rest duration period and active duration period. Menzel does, however, treat those two per-alarm durations as the discriminating coordinates in which nuisance behavior is separated, plotting each alarm occurrence as a discrete point whose one coordinate is "the duration of the event in seconds" and whose other is "duration to the next re-occurrence of the alarm in seconds," and resolving the chattering classification at the junction of percentile boundaries drawn on both axes (Menzel [0201]–[0202], FIG. 3C, items 331, 332, 333, 334, 335, 336), conditions each of its nuisance determinations on one or both of those durations ([0241], [0246], [0251]),and expressly directs extension of its classification criteria to further alarm attributes including "alarm duration" ([0364]). It would therefore have been obvious to one of ordinary skill in the art before the effective filing date to train Menzel's user-taught model on, and to classify each tile according to, those two duration values, because Menzel already identifies them as the variables discriminating among its nuisance behaviors and already learns the corresponding thresholds from user-supplied labels ([0203], [0256]); training a model on the very features the reference identifies as discriminating is the use of a known technique to improve a similar system in the same way, yielding the predictable result of assigning a nuisance alarm label. The skilled artisan would have been motivated to do so because Menzel teaches that the appropriate thresholds vary by site, segment, and operating team and are therefore better learned from user feedback than fixed in advance ([0173], [0246], [0248]), with a reasonable expectation of success, the model operating on values the combination already stores in each tile transformation.).
Regarding claim 15, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 14, wherein the one or more processors is further configured to train the classification model for classifying tiles (Menzel discloses that the system itself performs the training of the model by which alarms are subsequently classified, disclosing that "the system may also be trained by users what is acceptable (and conversely, not acceptable) by implementing a user feedback loop to train the system" (Menzel [0203]), that the system "may also be taught what thresholds (and other characteristics) are typical for each given nuisance behavior through analysis of user interactions," those characteristics being "inferred (i.e., learned, derived) from user tagging," from which "the system may generalize the team or user definitions for the alarms" ([0256]), and that the system may "over time (e.g., a 6-month learning period), learn and derive" the classification criteria from user inputs ([0342]); these operations being performed by the recited computing structure, namely at least one processor and at least one memory device configured to analyze the aggregated information and characterize the alarm nuisance behavior ([0029], and claim 26)).
Regarding claim 16, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 1, wherein the one or more processors are further configured to, when performing analytics on the generated plurality of tile transformations, using at least one algorithmic technique, to classify the received alarm data stream with a normal alarm label responsive to the at least one algorithmic technique determining the plurality of tile transformations does not classify as one of the plurality of nuisance alarm labels (Menzel discloses an ordered cascade of threshold tests in which an alarm failing every nuisance test is passed through without any nuisance tag, the sequence proceeding from the stale test at blocks 515/520, to chattering at blocks 525/530, to fleeting at blocks 535/540, to flood at blocks 545/550, and, upon a negative determination at each, to block 555 (Menzel, FIG. 5 and [0239]–[0257]); Menzel expressly recognizes and acts upon the resulting complementary class, disclosing that later processing may be directed "only on nuisance events and/or alarms, or conversely, only on events and/or alarms which do not display any nuisance behavior" ([0195]); and Menzel applies the recited normal designation as the classification outcome, disclosing the deduction of thresholds separating "what is normal, abnormal, and extreme" ([0294], [0295]) and the tagging of each analyzed unit as "normal," "overwhelming period/interval," or "extremely overwhelming period/interval" according to those thresholds ([0297], [0299]).).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Menzel et al. (US 2022/0319304 A1) in view of Srinivasan et al. (US 2018/0322770 A1), and further in view of Duraisingh et al. (US 2019/0107830 A1), for the same reasons set forth with respect to claim 1 above. Claim 17 is directed to a method reciting steps corresponding to the operations recited in system claim 1, differing only in method form and in the omission of the storage device and processor structure of claim 1. The scope and content of the recited limitations are otherwise identical, and the mapping and motivations to combine set forth in the rejection of claim 1 are incorporated here by reference.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Menzel et al. (US 2022/0319304 A1) in view of Srinivasan et al. (US 2018/0322770 A1), and further in view of Duraisingh et al. (US 2019/0107830 A1), for the same reasons set forth with respect to claim 11 above. Claim 18 recites a relabeling limitation corresponding in scope to that of claim 11, differing only in that it depends from method claim 17 rather than from system claim 1. The scope and content of the recited limitations are otherwise identical, and the mapping and motivations to combine set forth in the rejection of claim 11 are incorporated here by reference.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Menzel et al. (US 2022/0319304 A1) in view of Srinivasan et al. (US 2018/0322770 A1), and further in view of Duraisingh et al. (US 2019/0107830 A1), for the same reasons set forth with respect to claims 12 and 13 above. Claim 19 recites limitations corresponding in scope to those of claims 12 and 13 — namely, that the at least one algorithmic technique is an Unsupervised machine learning technique (claim 12), and that the technique is a centroid-based clustering algorithm clustering like tiles dependent upon the rest duration period and the active duration period, with each cluster labeled with one of the nuisance alarm labels (claim 13) — differing only in that it appears to depend from method claim 17 rather than from system claims 1 and 12. The scope and content of the recited limitations are otherwise identical, and the mapping and motivation set forth in the rejections of claims 12 and 13 are incorporated here by reference.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Menzel et al. (US 2022/0319304 A1) in view of Srinivasan et al. (US 2018/0322770 A1), and further in view of Duraisingh et al. (US 2019/0107830 A1), for the same reasons set forth with respect to claims 1, 12 and 13 above. Claim 20 recites a computer monitoring system whose storage device and processor limitation, transform limitation, and analytics limitation correspond in scope to those of claim 1, and whose recitation of an Unsupervised machine learning technique consisting of a Centroid-based Clustering algorithm keyed to the rest duration period and the active duration period, with each cluster labeled with one of the nuisance alarm labels, corresponds in scope to the limitations of claims 12 and 13. The scope and content of those limitations are identical, and the evidentiary mapping and motivations to combine set forth in the rejections of claims 1, 12, and 13 are incorporated here by reference. Claim 20 differs from claim 1 in reciting that the alarm data stream is received from an automation and industrial control system rather than from a building management system. Menzel discloses that source directly, disclosing that its alarm nuisance analysis is applied to information aggregated from "an EPMS, a SCADA system (e.g., Power SCADA, Manufacturing SCADA), a building management system (BMS), I/O devices, and system users" (Menzel [0022], [0064]), and describing the monitoring and control systems from which the alarms originate as including "programmable logic controllers (PLCs), input/output systems and equipment, and/or any other system or combination of systems and/or devices capable of at least one of monitoring, measuring, deriving, gathering, processing, producing, analyzing, alarming, communicating, displaying, reporting, storing" associated with a facility's utility systems ([0011]), the facilities so monitored being an automated industrial facility or including automated industrial equipment ([0124]). Examiner further notes that Applicant admits the equivalence, stating that an "automation and industrial control system, such as a building management system (BMS) is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area" (PGPUB Spec [0002]), and that the disclosed computer monitoring system "may have application to other automation and industrial control system systems, such as Supervisory Control and Data Acquisition (SCADA) systems" ( PGPUB Spec [0062]).
Regarding claim 21, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 20, wherein the automation and industrial control system is a building management system (BMS) (Menzel names a building management system among the automation and control systems whose alarm information is aggregated and analyzed for nuisance behavior (Menzel at [0011], [0022], [0064]) and addresses BMS- and HVAC-originated events and alarms within its analysis (at [0156], [0223], [0363]). Duraisingh discloses the recited building management system, comprising "building equipment operable to affect a physical state or condition of a building" and a system manager that obtains alarm data from that building equipment (Duraisingh, claim 1 and at [0002]–[0003]).).
Regarding claim 22, Menzel in view of Srinivasan and Duraisingh discloses the computer monitoring system as recited in claim 20, wherein the automation and industrial control system is a supervisory control and data acquisition (SCADA) system (Menzel discloses the recited SCADA system, disclosing that its alarm nuisance analysis is applied to information aggregated from "an EPMS, a SCADA system (e.g., Power SCADA, Manufacturing SCADA), a building management system (BMS), I/O devices, and system users" (Menzel at [0022], [0064]), and identifying "Supervisory control and data acquisition (SCADA) systems (e.g., Power SCADA, Manufacturing SCADA)" among the monitoring and control systems whose alarms are relevant to its disclosure (at [0011]). Examiner further notes that Applicant admits the application of the claimed monitoring system to such systems, stating that "the computer monitoring system 107 in accordance with the illustrated embodiments may have application to other automation and industrial control system systems, such as Supervisory Control and Data Acquisition (SCADA) systems" (PGPUB Spec at [0062]).).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAJSHEED O BLACK-CHILDRESS whose telephone number is (571)270-7838. The examiner can normally be reached M to F, 10am to 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Quan-Zhen Wang can be reached at (571) 272-3114. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RAJSHEED O BLACK-CHILDRESS/Examiner, Art Unit 2685
Prosecution Insights