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 .
Response to Amendment
This action is responsive to applicant's amendment and remarks received on 03/17/2026.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-41 are rejected under 35 U.S.C. 103 as being unpatentable over Naidoo (US 20040086088 A1) in view of Yu (US 20060208872 A1).
Regarding claim 28, Naidoo discloses a computing device comprising: a memory; a network interface; and at least one processor coupled with the memory and the network interface (Naidoo discloses a computing device in the form of a processor-based security system server 131 and/or automation system server 420 in a data center 132 (i.e., a computing environment), which includes at least one processor, memory for storing alarm and account data, and one or more network interfaces for communicating over IP-based networks with a security gateway 115 at a monitored premises and with monitoring clients 133 at a central monitoring station (Naidoo FIGS. 1–2 and 4; [0040]–[0043], [0065]–[0068], [0080], [0083]–[0087]). The servers are described as Windows-based database and application servers (Naidoo [0080] and [0085]), which inherently comprise processors coupled with memory and network interface) and configured to:
receive, via the network interface, at least one first milestone originating from a base station at a location remote from the computing device (Naidoo further teaches that security gateway 115, located at premises 110 and operatively coupled to sensors 105, cameras 112, and audio stations 107, generates alarm notifications and associated cached/stored audiovisual data when an alarm or other event occurs and transmits this information to security system server 131 and media handler 415 for verification and response (Naidoo [0048]–[0053], [0066]–[0068], [0083]–[0085]). These alarm notifications and event records correspond to at least one first milestone originating from a base-station-type device at a location remote from the computing device and being received via the server’s network interface.),
receiving, via the network interface, at least one second milestone originating from a workstation within a monitoring center remote from the computing device and the location (Naidoo also discloses that a central monitoring station 136 includes one or more monitoring clients 133 operated by monitoring personnel (Naidoo [0081]–[0083]). Monitoring client 133 is a workstation at a monitoring center that is remote from both the data center and the monitored premises. Naidoo explains that automation system server 420 logs alarm conditions and serves as a workflow system for operators responding to alarm conditions, recording monitoring activity and operator actions communicated from monitoring client 133 (Naidoo [0084]–[0086]). Those operator actions and workflow events constitute at least one second milestone originating from a workstation within a monitoring center and received, via a network interface, by the computing device (server)),
transmitting to the base station, via the network interface, a command to exit the alarm (Naidoo further teaches that the server-side components (e.g., automation system server 420, media handler 415, application server 434) use alarm notifications and associated audiovisual information from the security gateway 115, together with monitoring-station workflow activity, to verify alarms and determine appropriate responses, including contacting authorities and controlling the security system (Naidoo [0042]–[0043], [0048]–[0053], [0081]–[0086]). Naidoo also discloses authenticated remote control of the security system via web interface 432 and application server 434, where the server evaluates user credentials and permissions and then issues control commands, including arming and disarming partitions and bypassing zones, to the security gateway 115 (Naidoo [0054]–[0056], [0087]–[0092]). Transmitting such control commands from the server to the gateway over the network, in particular commands that disarm or clear alarm conditions at the premises, corresponds to transmitting to the base station, via the network interface, a command to exit the alarm.).
However, Naidoo does not expressly disclose validating, based on the at least one first milestone and the at least one second milestone, a request to exit an alarm; and transmitting the command to exit the alarm based on validation of the request.
In an analogous art, Yu is directed to intelligent alarm management in surveillance systems and discloses an alarm management system in which an alarm receiver module receives alarms from multiple sensor devices and surveillance systems, a condition evaluation module evaluates one or more customized conditions for a given alarm using shared state information (including a history of events and active alarms), and an action handling module executes actions based on the evaluation (Abstract; [0012]–[0013], [0015]–[0018]). Yu explains that a rule engine evaluates rules composed of predicates over the current alarm and an active_alarms data structure, enabling detection of multiple inter-correlated event patterns and use of end conditions so that an alarm state (e.g., active vs. completed) is terminated and corresponding actions are executed only when specified multi-event conditions are satisfied (FIG. 5; [0018]–[0027], [0029]–[0031]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure Naidoo’s server-side alarm handling (e.g., security system server 131/automation system server 420) to implement Yu’s rule-based condition evaluation, so that the server validates an alarm-handling request (such as clearing or exiting an alarm at the premises) based on multiple events/milestones—for example, data from the premises security gateway and data reflecting monitoring-center actions or status—before transmitting a command to terminate or exit the alarm. Yu expressly teaches improving alarm processing reliability and flexibility by evaluating rules over multiple correlated events and shared state and firing actions only when combined conditions are satisfied, in contrast to simple single-event triggers (Yu [0012]-[0013], [0018]–[0020], [0024]–[0027]). Naidoo already stores and uses both premises-side event information (from security gateway 115 and sensors/cameras) and monitoring-center information (via monitoring client 133 and automation system server 420) in making alarm-handling decisions (Naidoo [0040]–[0047], [0081]–[0087]). Accordingly, a person of ordinary skill in the art, seeking to reduce false or unauthorized alarm clearances and provide more robust alarm verification in Naidoo’s system, would have been motivated to adopt Yu’s teaching of evaluating alarm-handling rules over multiple event sources and state information and to configure Naidoo’s server to validate a request to exit an alarm based on the combination of (i) milestones/events from the base station and (ii) milestones/events from the monitoring center. This would have been a predictable use of known rule-based alarm correlation techniques to improve alarm exit/clearance reliability in Naidoo’s remote monitoring system and would have involved only routine implementation of Yu’s evaluation mechanisms in Naidoo’s existing server environment.
Regarding claim 29, Naidoo in view of Yu discloses the computing device of claim 28, wherein: to receive the at least one first milestone includes to receive a milestone indicating initiation, by the base station, of the alarm; and to receive the at least one second milestone includes to receive another milestone indicating reception, by the workstation, of valid authentication information (Naidoo in view of Yu teaches a server-side computing device that receives alarm/event information from a premises security gateway 115 when an alarm condition is initiated at the premises (i.e., a milestone indicating initiation of the alarm by the base station) and also authenticates monitoring/remote users at monitoring client 133/remote client 155 before permitting alarm-handling operations, thereby providing an event corresponding to reception of valid authentication information at a workstation (Naidoo [0042], [0049]–[0052], [0054]–[0060], [0081]–[0087], [0094]–[0102]). Yu teaches representing such events and validation results as explicit alarm-related states/conditions consumed by a rule engine when deciding whether actions may fire (Yu Abstract; [0012]–[0013], [0015]–[0021]). It would have been obvious to one of ordinary skill in the art to model Naidoo’s premises alarm initiation and workstation authentication success as distinct “first” and “second” milestones used in the server’s rule-based validation before honoring an alarm-exit request, in order to improve security and reduce unauthorized alarm clearances, consistent with Yu’s multi-event, validation-aware alarm processing.).
Regarding claim 30, Naidoo in view of Yu discloses the computing device of claim 29, wherein to validate the request to exit the alarm includes to determine that the at least one first milestone and the at least one second milestone were received in a sequence specified as being proper (Naidoo already operates in a workflow in which an alarm is raised at the premises, a remote/monitoring user is authenticated, and only then are alarm-handling operations (e.g., disarming/clearing) permitted (Naidoo [0040]–[0047], [0054]–[0057], [0081]–[0087], [0094]–[0102]). Yu teaches a rule engine that evaluates conditions and “end conditions” over sequences of events using timestamps and shared state, and that executes actions only when specified multi-event, ordered conditions are met (Yu, e.g., [0013], [0018]–[0027], [0029]–[0031], FIG. 5). It would have been obvious to one of ordinary skill in the art to implement Yu’s time/sequence-aware rule predicates in Naidoo’s server so that an alarm-exit request is validated only if the first (alarm-initiation) and second (authentication) milestones are detected in a preconfigured “proper” sequence, thereby enforcing the expected order of events before exiting an alarm.).
Regarding claim 31, Naidoo in view of Yu discloses the computing device of claim 30, wherein to determine that the at least one first milestone and the at least one second milestone were received in the sequence includes to determine that the at least one first milestone was received prior to the at least one second milestone (As noted above, Naidoo’s normal operation contemplates that an alarm at the premises is raised before a monitoring-center user authenticates and issues alarm-handling commands (Naidoo [0042], [0045], [0049]–[0052], [0054]–[0057], [0081]–[0087]). Yu explicitly teaches using event histories and dynamically generated timestamps to detect inter-correlated event patterns “based on time” and to enforce ordered relationships between start, follow-on, and termination events before actions are executed (Yu [0013], [0018]–[0027], [0029]–[0031]). It would have been obvious to one of ordinary skill in the art, when applying Yu’s rule engine to Naidoo’s alarm and authentication workflow, to require that the alarm-initiation milestone (from the base station) be recorded as occurring before the authentication milestone (from the workstation) as part of the validation logic for exiting an alarm, thereby formalizing the expected temporal ordering that already underlies Naidoo’s process.).
Regarding claim 32, Naidoo in view of Yu discloses the computing device of claim 31, further comprising to receive at least one third milestone including the request to exit the alarm (Naidoo teaches that, after authentication, a monitoring/remote client sends alarm-control commands (including disarming or otherwise clearing an alarm) to the server, which then forwards corresponding commands to the premises security gateway 115 (Naidoo, e.g., [0054]–[0058], [0088]–[0091], [0094]–[0104]). Yu teaches modeling each significant alarm-related event as an object (e.g., entries in an alarm queue DB and active_alarms structures) that is consumed by the rule engine when evaluating conditions and deciding when alarms terminate and actions fire (Yu [0017]–[0021], [0024]–[0027], FIG. 3 at 52–68, FIG. 5). It would have been obvious to one of ordinary skill in the art to treat Naidoo’s workstation-originated alarm-exit request as a distinct third milestone/event received by the server and used alongside the first and second milestones in the rule evaluation, so that the server explicitly receives and processes a third milestone that includes the exit request in validating whether to send a corresponding command to the base station.).
Regarding claim 33, Naidoo in view of Yu discloses the computing device of claim 32, wherein to validate the request to exit the alarm includes to determine that the at least one first milestone was received prior to the at least one second milestone and that the at least one second milestone was received prior to the at least one third milestone (Naidoo contemplates a temporal flow from (i) alarm initiation at the premises, to (ii) authentication at the monitoring center, to (iii) issuance of an alarm-clear/exit command from the workstation to the server and then to the base station (Naidoo [0040]–[0047], [0054]–[0058], [0081]–[0087], [0094]–[0104]). Yu’s rule engine expressly evaluates time-ordered sequences of events (start events, follow-on events, and end events) and uses event timestamps and shared alarm state to ensure that actions occur only when events satisfy specified temporal relationships (Yu [0013], [0018]–[0027], [0029]–[0031]). It would have been obvious to one of ordinary skill in the art to configure Yu-style rules in Naidoo’s server such that the exit-alarm action is permitted only if the server determines that (1) the alarm-initiation milestone occurred first, (2) the authentication milestone occurred thereafter, and (3) the exit-request milestone followed, in that order, thereby formalizing and enforcing the expected alarm-authentication-command sequence to improve reliability and prevent out-of-order or unauthorized alarm exits.).
Regarding claim 34, Naidoo in view of Yu discloses the computing device of claim 28, wherein the at least one processor is further configured to store, in a database, information linking the alarm, the at least one first milestone, the at least one second milestone, and the command (Naidoo teaches that security system server 131 / automation system server 420 receive alarm notifications and associated pre-/post-event audiovisual data from security gateway 115, log alarm conditions and “associated data,” and maintain alarm history and related information in database-backed workflow/logging systems for later retrieval (Naidoo [0049]–[0052], [0081]–[0087]). Thus, Naidoo already stores alarm records and related event information in a database in association with server-side alarm handling. Yu further teaches an alarm management server that maintains multiple persistent data stores (e.g., an alarm queue DB, alarm log DB, rule/condition DBs) that hold alarm instances together with their associated events/conditions and the actions taken, as shared state and “accumulated metadata” such as histories of events and effects of the events (Yu [0012]–[0013], [0017]–[0021], FIG. 3). It would have been obvious to one of ordinary skill in the art, when implementing Yu’s rule-based alarm handling within Naidoo’s server infrastructure, to configure the database schema/logging so that each alarm record explicitly associates (i) the alarm instance, (ii) the premises-side first milestone (alarm initiation), (iii) the monitoring-center second milestone (authentication/handling event), and (iv) the resulting command used to exit the alarm, thereby “linking” these items in the database. Doing so is a straightforward application of Yu’s teaching of storing alarms, correlated events, and actions together as related state to Naidoo’s existing alarm-history logging, and would predictably improve traceability and auditability of alarm handling using routine database implementation within the ordinary skill in the art.).
Claims 21–27 are rejected under 35 U.S.C. 103 as being unpatentable over Naidoo (US 20040086088 A1) in view of Yu (US 20060208872 A1). Claims 21–27 recite method steps that correspond in substance to the system features/functions recited in claims 28–34, and the limitations are met by Naidoo and Yu for the same reasons set forth above with respect to claims 28–34.
Regarding claim 35, Naidoo discloses a method comprising:
receiving, by a server within a computing environment, a first milestone originating from a base station at a location remote from the computing environment (Naidoo discloses a method carried out by a server within a computing environment (security system server 131 / automation system server 420 in data center 132) that cooperates with a premises security gateway 115 and a monitoring center workstation 133 over networks 120/134 ([0040]–[0043], [0065]–[0068], [0080]–[0091]). Naidoo teaches that security gateway 115, located at the premises 110, monitors sensors 105 and, when an alarm is triggered, sends alarm notification and associated pre-event/post-event audiovisual data to the security system server 131/automation system server 420, which logs the alarm conditions and associated data and forwards the alarm to monitoring client 133 at a central monitoring station 136 ([0042]–[0052], [0081]–[0087]). Thus, Naidoo teaches receiving, by a server within a computing environment, a first milestone originating from a base station at a location remote from the computing environment, where the “first milestone” reasonably corresponds to the alarm/event notification and associated data sent from security gateway 115 at premises 110 to the server.);
receiving, by the server, a second milestone originating from a workstation within a monitoring center remote from the computing environment and the location (Naidoo further discloses that monitoring client 133 at the monitoring center 136 uses the alarm information to evaluate whether an alarm condition exists and that automation system server 420 serves as a workflow/logging system for operators responding to alarm conditions, recording their handling actions ([0081]–[0087]). In doing so, Naidoo’s server receives and logs operator-generated alarm-handling events originating from the monitoring client 133, which reasonably correspond to a second milestone originating from a workstation within a monitoring center.);
receiving, by the server, a message originating from the workstation, the message specifying a request to exit an alarm (Naidoo teaches that control and configuration data destined for security gateway 115 may originate from an operator located at central monitoring station 136 through monitoring client 133, and that such data includes control messages for arming and disarming partitions and bypassing zones, which are relayed by the server (e.g., media handler 415) to security gateway 115 ([0086]–[0087]). Thus, an operator-originated disarm/clear command sent from monitoring client 133 through the server to the security gateway corresponds to receiving, by the server, a message originating from the workstation, the message specifying a request to exit an alarm.);
transmitting to the base station, by the server, a command to exit the alarm (Naidoo further teaches that the server-side components (e.g., automation system server 420, media handler 415, application server 434) use alarm notifications and associated audiovisual information from the security gateway 115, together with monitoring-station workflow activity, to verify alarms and determine appropriate responses, including contacting authorities and controlling the security system (Naidoo [0042]–[0043], [0048]–[0053], [0081]–[0086]). Naidoo also discloses authenticated remote control of the security system via web interface 432 and application server 434, where the server evaluates user credentials and permissions and then issues control commands, including arming and disarming partitions and bypassing zones, to the security gateway 115 (Naidoo [0054]–[0056], [0087]–[0092]). Transmitting such control commands from the server to the gateway over the network, in particular commands that disarm or clear alarm conditions at the premises, corresponds to transmitting to the base station, by the server, a command to exit the alarm.).
However, Naidoo does not expressly disclose validating, by the server, an order of reception of the first milestone, the second milestone, and the message; and transmitting to the base station, by the server and based on a valid order of reception, a command to exit the alarm.
In an analogous art, Yu is directed to intelligent alarm management in surveillance systems and teaches an alarm server that receives alarms from sensor devices/surveillance systems, evaluates customized conditions using a rule engine and shared state information (including histories of events and active alarms), and executes actions based on that evaluation (Abstract; [0012]–[0013], [0015]–[0018]). Yu explains that shared state information may include accumulated metadata such as a history of events and an active_alarms data structure, and that rules composed of multiple predicates over the current alarm and the active alarms are used to detect inter-correlated event patterns based on time, sequence, and other metadata, with rule and “end” conditions determining when an alarm becomes active, when it terminates, and when actions are fired (FIG. 5; [0013], [0018]–[0027], [0029]–[0031]). In other words, Yu teaches validating whether a set of events, including their ordering and timing, satisfies a specified rule before an action is executed.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure Naidoo’s server-side alarm handling (security system server 131/automation system server 420) to implement Yu’s rule-based condition evaluation so that the server validates the order in which key events are received—such as (i) an alarm/milestone from the premises, (ii) a monitoring-center milestone, and (iii) a request message from the monitoring workstation to clear the alarm—before issuing a command to exit/terminate the alarm. Yu teaches that alarm-processing reliability is improved by evaluating rules over multiple correlated events and shared state, including event sequences, and firing actions only when those combined conditions are satisfied, rather than on a single event. Naidoo already stores and uses both premises-side event information (from security gateway 115) and monitoring-center workflow information (via monitoring client 133 and automation system server 420) in making alarm-handling decisions and maintaining alarm history. A person of ordinary skill in the art, seeking to reduce false or unauthorized alarm clearances and to provide more robust, auditable alarm verification in Naidoo’s system, would have been motivated to apply Yu’s event-sequence rules and configure Naidoo’s server to validate the order of reception of the first milestone, second milestone, and exit-request message and to transmit the exit command only when that order is determined to be valid. Implementing such sequence-checking within Naidoo’s existing server and database infrastructure would have been a predictable use of Yu’s multi-event, rule-based alarm correlation techniques in a closely analogous environment and would have involved routine configuration of rule definitions and event timestamps.
Regarding claim 36, Naidoo in view of Yu discloses the method of claim 35, wherein: receiving the first milestone includes receiving a milestone indicating initiation, by the base station, of the alarm; and receiving the second milestone includes receiving another milestone indicating reception, by the workstation, of valid authentication information (Naidoo in view of Yu teaches receiving, by a server, a first milestone from a base station corresponding to alarm initiation at the premises and a second milestone from a monitoring-center workstation corresponding to a monitoring/remote user’s authenticated state, as well as receiving a workstation message requesting exit of an alarm (Naidoo, e.g., [0042], [0045], [0049]–[0052], [0054]–[0057], [0081]–[0087], [0094]–[0102]; Yu Abstract; [0012]–[0013], [0015]–[0021]). Naidoo’s security gateway 115 and sensors 105 generate and send alarm notifications when an alarm is initiated, while the server authenticates workstation users and issues access tokens/permissions (first and second milestones). It would have been obvious to one of ordinary skill in the art, in view of Yu’s teaching of correlating multiple alarm events and validation data in rule conditions, to treat the premises-side alarm initiation as the first milestone and the reception of valid workstation authentication information as the second milestone.).
Regarding claim 37, Naidoo in view of Yu discloses the method of claim 36, wherein validating the order of reception includes determining that the first milestone and the second milestone were received in a sequence specified as being proper (As noted above, Naidoo in view of Yu teaches validating, before exiting an alarm, the order in which key events are received by the server—alarm initiation from the premises, authentication at the monitoring-center workstation, and a workstation exit request—using a rule engine that evaluates event sequences and shared state (Naidoo [0040]–[0047], [0056]–[0060], [0081]–[0087], [0094]–[0101]; Yu Abstract; [0012]–[0013], [0015]–[0018], [0021]–[0027], [0029]–[0031]). It would have been obvious to one of ordinary skill in the art to express this as a rule that treats certain sequences (e.g., alarm then authentication) as “proper” for clearing an alarm, and that validates the order of reception of the first and second milestones against that specified sequence, as recited.).
Regarding claim 38, Naidoo in view of Yu discloses the method of claim 37, wherein determining that the first milestone and the second milestone were received in the sequence includes determining that the first milestone was received prior to the second milestone (In Naidoo’s system, an alarm at the premises is necessarily raised before the monitoring-center workstation authenticates a user for alarm handling, and Yu teaches evaluating temporal order using event timestamps and patterns “based on time” before alarms terminate and actions fire (Naidoo [0042], [0045], [0049]–[0052], [0054]–[0057]; Yu [0013], [0018]–[0020], [0021]–[0023], [0024]–[0027], [0029]–[0031], FIG. 5). It would have been obvious to one of ordinary skill in the art to configure the server’s rule engine so that a “proper” sequence requires the timestamp of the first (alarm-initiation) milestone to precede that of the second (authentication) milestone when validating whether an exit-alarm request may be honored, as a direct application of Yu’s time-ordered predicates to Naidoo’s alarm and authentication events.).
Regarding claim 39, Naidoo in view of Yu discloses the method of claim 38, further comprising receiving a third milestone including the message (Naidoo teaches that control and configuration data destined for security gateway 115—including control messages for arming and disarming partitions and bypassing zones—may originate from an operator at central monitoring station 136 through monitoring client 133 and be relayed by the server (e.g., media handler 415) to the security gateway (Naidoo [0086]–[0087]). This operator-originated disarm/clear command from monitoring client 133 corresponds to the recited message. Yu teaches modeling such alarm-handling events as distinct alarm instances or messages in an alarm queue DB and active_alarms structures that are processed by the rule engine (Yu [0017]–[0021], [0024]–[0027], FIGS. 3 and 5). It would have been obvious to one of ordinary skill in the art to treat the workstation's exit-request message as a third milestone event received by the server and included in the same rule-based validation flow as the first and second milestones.).
Regarding claim 40, Naidoo in view of Yu discloses the method of claim 39, wherein validating the order of reception includes determining that the first milestone was received prior to the second milestone and that the second milestone was received prior to the third milestone (Naidoo in view of Yu teaches a method in which the server evaluates the order of these three events—alarm initiation at the premises, authentication at the workstation, and a workstation exit request—and only then issues an alarm-exit command when the sequence is appropriate, using event histories and timestamps (Naidoo [0040]–[0047], [0054]–[0058], [0081]–[0087], [0094]–[0101]; Yu [0013], [0018]–[0027], [0029]–[0031], FIG. 5). It would have been obvious to one of ordinary skill in the art to configure Yu-style rules so that an exit-alarm action is permitted only if the server determines that (1) the alarm-initiation (first) milestone precedes the authentication (second) milestone and (2) the authentication milestone precedes the exit-request (third) milestone, thereby enforcing the expected alarm–authentication–exit sequence and preventing out-of-order or unauthorized alarm clearances.).
Regarding claim 41, Naidoo in view of Yu discloses the method of claim 35, further comprising storing, in a database, information linking the alarm, the first milestone, the second milestone, and the command (Naidoo teaches a server-based security system in which security system server 131 / media handler 415 / automation system server 420 receive alarm events from the premises via security gateway 115, receive monitoring-center actions from monitoring client 133, and maintain alarm history and associated handling information in persistent storage (e.g., customer data, prior alarm notifications/events, and related workflows) for later review (Naidoo [0049]–[0052], [0081]–[0087], [0090]). Yu teaches that an alarm management server stores alarm instances, their associated conditions/events, and the actions executed in databases such as an alarm queue DB and alarm log DB, thereby maintaining linked data structures associating each alarm with its triggering events and the actions taken (Yu [0012]—[0013], [0017]–[0021]). In view of Yu, it would have been obvious to one of ordinary skill in the art to implement the combined method so that, after receiving the first milestone (alarm initiation), the second milestone (workstation authentication), and the exit command, the server stores in its database a record that explicitly links the alarm instance with those milestones and the command, to support later audit, troubleshooting, and further rule evaluation. Such explicit linking uses the same type of alarm/event/action logging already taught by Naidoo and Yu, applied to the particular milestones and command recited in the claim, and would have been a routine and predictable implementation detail within the ordinary skill in the art.).
Response to Arguments
Applicant's arguments filed 03/17/2026 have been fully considered but they are not persuasive.
As an initial matter, the Examiner acknowledges Applicant's observation that the prior Office action paraphrased the transmitting limitation as "based on a validation"; the recited language is "transmitting to the base station, by the server and based on validation of the request, a command to exit the alarm." This clarification of the record does not alter the rejection. The rejection does not rely on Naidoo for the validating element; that element is supplied by Yu, while Naidoo supplies the system architecture, the milestone sources, and the request and command to exit the alarm, as explained below.
Argument A: Applicant argues that Naidoo's monitoring client is a "downstream interface positioned at the end of the alarm-processing pipeline" that does not generate a discrete event transmitted to the server as a validation input, and that the Office Action improperly treats this downstream interface as an upstream source of validation inputs.
Response to Arguments A: Naidoo discloses that the monitoring workstation communicates events upstream to the server. Operator workflow activity at monitoring client 133 is communicated to and logged by automation system server 420 (Naidoo [0085]), and control data—"including control messages for arming and disarming partitions"—may originate from an operator at the central monitoring station through monitoring client 133 (Naidoo [0086]–[0087]). Naidoo's workstation is therefore not a passive downstream node, and the recorded operator activity meets the broadly recited "second milestone originating from a workstation within a monitoring center." Further, the independent claims do not recite that the server autonomously exits the alarm state or that disarm authority is withheld from the monitoring professional; those features appear only in the Specification ([0088], [0097], [0117]) and are not read into the claims. Applicant's arguments are not persuasive.
Argument B: Applicant argues that Yu does not disclose a milestone from a monitoring-center workstation, source-specific events from different nodes, or a "request to exit an alarm," and that Yu is merely an architectural framework that terminates alarms based on conditions (Yu [0023]) and makes no mention of milestones.
Response to Argument B: These arguments attack Yu in isolation for teachings on which Yu was not relied; one cannot show nonobviousness by attacking references individually where the rejection rests on their combination. Naidoo supplies the milestone sources (base station/security gateway 115 and monitoring-center workstation/monitoring client 133) and the request to exit the alarm (the disarm/clear command, Naidoo [0086]–[0091], [0104]). Yu supplies the validating element—a rule-engine evaluation of multiple correlated events and shared state, including "a history of events" and detection of "inter-correlated event patterns based on time" (Yu [0013], [0018]–[0021], [0024]–[0030])—with actions executed only when the conditions are met. To the extent Applicant characterizes Yu as a mere framework lacking substantive disclosure, Yu sets forth a concrete rule-evaluation model in which predicates are evaluated in a specified order (Yu [0026], [0030]) over time-stamped, inter-correlated events (Yu [0013]), with actions fired only when conditions are satisfied (Yu [0021]–[0022]). The absence of the label "milestone" in Yu is not dispositive, as Naidoo supplies the recited milestones and Yu supplies the validation logic applied to them. The combination, not Yu alone, meets the limitations. Applicant's arguments are not persuasive.
Argument C: Applicant argues that, because the transmitting is "based on validation of the request," the validation must be of a request that neither reference discloses.
Response to Arguments C: Naidoo discloses the request to exit the alarm and validating it before honoring it, by verifying authentication and the requestor's permission profile prior to permitting control (Naidoo [0092], [0096]–[0100]); Yu adds validation based on multiple events. The combination thus discloses transmitting, based on validation of the request, a command to exit the alarm, where the validation is based on the first and second milestones. Applicant's arguments are not persuasive.
For the foregoing reasons, Applicant's arguments are not persuasive, and the rejection of claims 21–41 under 35 U.S.C. 103 over Naidoo in view of Yu is maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
/QUAN ZHEN WANG/Supervisory Patent Examiner, Art Unit 2685
Prosecution Insights