DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 03/23/2026.
In the instant Amendment: Claims 1, 13 and 19 have been amended, claims 9-10, 15-18 and 20 have been cancelled and claims 23-28 newly added. Claims 1-8, 11-14, 19, 21-28 have been examined and are pending. This Action is made FINAL.
Examiner’s Notes
To promote compact prosecution, the Examiner contacted applicant’s representative, Hean Koo (Reg. No.: 61214) and proposed an examiner’s amendment. However, the Examiner and applicant’s representative were unable to reach an agreement.
Response to Arguments
Applicants’ arguments with respect to amended claims 1 has been considered but are moot in view of the new ground(s) of rejection. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
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 discloses as set forth in section 102 of this title, 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 1, 11, 13, 19 and 21-28 are rejected under 35 U.S.C. 103 as being unpatentable over Lifshitz et al. (“Lifshitz,” US 20190380037, published Dec. 12, 2019) and Schmitt et al. (“Schmitt,” US 20210110262, filed Oct. 13, 2020).
Regarding claim 1, Lifshitz discloses An electronic surveillance system that detects alert conditions in data networks, the electronic surveillance system comprising a processor programmed to: receive input data from one of a plurality of data networks, each data network from among the plurality of data networks being associated with different types of data from the respective data network (Lifshitz FIGs 1-2, [0036], [0040]-[0041]. A Sensor Unit 221, or other sensing or listening or tracking or monitoring unit, sees or listens or monitors or tracks or captures or collects all the relevant network traffic (e.g., via Gi interface), as well as subscriber (IoT device) address mapping information (e.g., provided by a Subscriber Mapping unit 230, via Sm interface). The Sensor Unit 221 monitors and collects the following data for each of the endpoints identified as managed IoT devices, and/or for each data connection: (a) timestamp of start; (b) 5-tuple of the connections (e.g., source IP address, source port, destination IP address, destination port, protocol being used); (c) Identified protocols; (d) upstream volume of traffic; (e) downstream volume of traffic; (f) upstream packet count; (g) downstream packet count. Outliers are detected and flagged as suspicious, for example, based on distance greater than a pre-defined threshold value, or based on other indicators for irregularity of values or ranges-of-values; and a notification is generated with regard to such flagged IoT device, e.g., for further manual and/or automatic handling, for initiating attack mitigation operations, for remote de-activation or remote pausing of the IoT device, or the like.);
store a data record based on the input data (Lifshitz [0040]. The Sensor Unit 221 monitors and collects the following data for each of the endpoints identified as managed IoT devices, and/or for each data connection: (a) timestamp of start; (b) 5-tuple of the connections (e.g., source IP address, source port, destination IP address, destination port, protocol being used); (c) Identified protocols; (d) upstream volume of traffic; (e) downstream volume of traffic; (f) upstream packet count; (g) downstream packet count. The data is periodically collected (e.g., at pre-defined time intervals) by a Data Collector unit 211 (e.g., via Cl interface), and is stored in a repository therein.);
access a plurality of learned filter parameters for alert condition detection, each learned filter parameter from among the plurality of learned filter parameters being learned from historical datasets over a respective one of multiple tiers using computational modeling based on statistical analysis (Lifshitz [0040] – [0041]. The Sensor Unit 221 monitors and collects the following data for each of the endpoints identified as managed IoT devices, and/or for each data connection: (a) timestamp of start; (b) 5-tuple of the connections (e.g., source IP address, source port, destination IP address, destination port, protocol being used); (c) Identified protocols; (d) upstream volume of traffic; (e) downstream volume of traffic; (f) upstream packet count; (g) downstream packet count. An Analyzer unit 212 performs analysis of the collected data: (a) Network activity profiling, performed periodically (e.g., at pre-defined time intervals), by clustering the collected data (e.g., via Cd interface) using a pre-defined clustering mechanism or clustering algorithm (e.g., by utilizing K-Means, or other suitable clustering method); and performing extraction of features from the data-set, per class of IoT devices, wherein a class pertains to a set of IoT devices that belongs to the same IoT service or type (e.g., type of “vending machine”, or type of “smoke detector”). (b) Each new data point for a particular IoT device is compared to the cluster(s) of the class for that device; or, the features or characteristics of traffic pertaining to a particular IoT device, is compared to the features or characteristics that characterize the cluster of IoT devices of that type. (c) Outliers are detected and flagged as suspicious, for example, based on distance greater than a pre-defined threshold value, or based on other indicators for irregularity of values or ranges-of-values; and a notification is generated with regard to such flagged IoT device. [Note that “tiers” can refer to sets of information/criteria for alert analysis, see Specification par. [0040].] ) and/or
machine-learning and defining a value or range of values for which an alert condition is to be raised with respect to the respective one of the multiple tiers (Lifshitz [0126], [0129], [0157]. In some embodiments, the baseline behavior determination unit is to dynamically update said RBCCB profile of said particular IoT group, based on continued Machine Learning (ML) of traffic-related behavior of members of said particular IoT group. In some embodiments, the enforcement actions generator is to send a notification, to an owner or an operator of said particular IoT group, indicating (i) an identifier of said particular IoT device, and (ii) an indication that said particular IoT device is malfunctioning or compromised. The UP Probe 432 may count these messages, per type of message and/or in the aggregation of types, and may track their number or their quantity per time-unit (e.g., per minute) per IoT device from which they originate and/or per type-of-device from which they originate; and the system may then compare the monitored data to pre-defined threshold values or ranges-of-values, and/or may perform Machine Learning (ML) processes of such data, in order to determine that the number (the quantity) and/or the frequency of such monitored control messages is excessively high and/or irregular and/or abnormal and thus indicates that the IoT device is infected and/or compromised and/or malfunctioning.);
wherein each tier from among the multiple tiers corresponds to a respective time period in the historical datasets and the respective time period at least partially overlaps with a time period of at least one tier from among the multiple tiers (Lifshitz [0041], [0093], [0095], [0126]. An Analyzer unit 212 performs analysis of the collected data: (a) Network activity profiling, performed periodically (e.g., at pre-defined time intervals), by clustering the collected data (e.g., via Cd interface) using a pre-defined clustering mechanism or clustering algorithm (e.g., by utilizing K-Means, or other suitable clustering method); and performing extraction of features from the data-set, per class of IoT devices. In some embodiments, the IoT grouping unit is to group said multiple IoT devices into said particular IoT group, based on at least detection that each one of said IoT devices: (I) sends every T hours cellular data having total volume in the range of between M1 to M2 bytes… In some embodiments, the IoT grouping unit is to group said multiple IoT devices into said particular IoT group, based on at least detection that each one of said IoT devices receives incoming cellular data … not more than one time every T minutes. In some embodiments, the baseline behavior determination unit is to dynamically update said RBCCB profile of said particular IoT group, based on continued Machine Learning (ML) of traffic-related behavior of members of said particular IoT group.);
generate, for a given data record, a plurality of differences comprising at least a first difference between one or more fields in the data record with corresponding one or more fields in the historical datasets for a first tier associated with a first time period, and at least a second difference between the one or more fields in the data record with corresponding one or more fields in the historical datasets for a second tier associated with a second time period that at least partially overlaps with the first time period, the first difference and the second difference each representing a difference between one or more fields in the data record with corresponding one or more fields in the historical datasets over the respective first and second time periods (Lifshitz [0019], [0040] – [0041], [0126]. [A] set of IoT devices, such as, an array of Internet-connected vending machines, or an array of Internet-connected smoke detectors, exhibit a generally stable and predictable network behavior and/or traffic activity; for example, each vending machine sends 3 kilobytes of data every hour on the hour, and also sends additional 7 kilobytes of data once a day at 3 AM. Accordingly, the system of the present invention may utilize this information in order to detect anomalies; for example, observing that ten vending machines are currently sending 800 kilobytes of data every 12 minutes, or that one vending machine is currently sending 240 kilobytes of data every minute, triggers a determination that this or these vending machine(s) is (or are) malfunctioning and/or compromised. The Sensor Unit 221 monitors and collects the following data for each of the endpoints identified as managed IoT devices, and/or for each data connection: (a) timestamp of start; (b) 5-tuple of the connections (e.g., source IP address, source port, destination IP address, destination port, protocol being used); (c) Identified protocols; (d) upstream volume of traffic; (e) downstream volume of traffic; (f) upstream packet count; (g) downstream packet count. An Analyzer unit 212 performs analysis of the collected data: (a) Network activity profiling, performed periodically (e.g., at pre-defined time intervals), by clustering the collected data (e.g., via Cd interface) using a pre-defined clustering mechanism or clustering algorithm (e.g., by utilizing K-Means, or other suitable clustering method); and performing extraction of features from the data-set, per class of IoT devices, wherein a class pertains to a set of IoT devices that belongs to the same IoT service or type (e.g., type of “vending machine”, or type of “smoke detector”). (b) Each new data point for a particular IoT device is compared to the cluster(s) of the class for that device; or, the features or characteristics of traffic pertaining to a particular IoT device, is compared to the features or characteristics that characterize the cluster of IoT devices of that type. (c) Outliers are detected and flagged as suspicious, for example, based on distance greater than a pre-defined threshold value, or based on other indicators for irregularity of values or ranges-of-values; and a notification is generated with regard to such flagged IoT device. In some embodiments, the baseline behavior determination unit is to dynamically update said RBCCB profile of said particular IoT group, based on continued Machine Learning (ML) of traffic-related behavior of members of said particular IoT group.”).);
compare each difference from among the plurality of differences to a respective one of the learned filter parameters for the respective one of the multiple tiers; and generate a plurality of alert conditions for the data record based on the comparisons, each alert condition indicating whether or not an alert is to be raised for the data record a corresponding tier from among the multiple tiers (Lifshitz [0060] –[0061]. An Outlier Detector unit 307 may detect that a particular IoT device exhibits network traffic characteristics that are dissimilar relative to said cluster of regular pattern of network traffic of said particular type of IoT devices. A Notifications Generator unit 308 may generate a notification or alarm or alert, that said particular IoT device is malfunctioning or is compromised, based on said dissimilar network traffic characteristics that are exhibited by said particular IoT device.);
wherein a sanction is imposed in response to at least one alert condition from among the plurality of alert conditions, and wherein the sanction is recorded in association with the at least one alert condition (Lifshitz [0061], [0078]. A Notifications Generator unit 308 may generate a notification or alarm or alert, that said particular IoT device is malfunctioning or is compromised, based on said dissimilar network traffic characteristics that are exhibited by said particular IoT device. In some embodiments, an Enforcement and Quarantine Unit 330, upon detection that said particular IoT device is malfunctioning or compromised, activates or operates a Full IoT Device Isolation Module 331 (i) to block relaying of all traffic that is outgoing from said particular IoT device to all destinations, and also (ii) to block relaying of all traffic that is incoming to said particular IoT device from all senders.)
Lifshitz does not explicitly disclose: wherein each tier from among the multiple tiers comprises a distinct historical dataset defined by a different time-window length, and wherein at least two tiers correspond to time windows that partially overlap in time such that a first tier includes a first set of historical datasets and a second tier includes a superset of the first set of historical datasets plus additional historical datasets, and wherein the processor is configured to simultaneously evaluate the data record against both the first tier and the second tier using their respective historical datasets.
However, in an analogous art, Schmitt discloses a system, comprising:
wherein each tier from among the multiple tiers comprises a distinct historical dataset defined by a different time-window length, and wherein at least two tiers correspond to time windows that partially overlap in time such that a first tier includes a first set of historical datasets and a second tier includes a superset of the first set of historical datasets plus additional historical datasets (Schmitt FIG. 2, [0064], [0070], [0099]. The method may execute a pre-processing of the obtained time-series of values, either obtained from the digital twin simulation of the machinery as first time-series of values or measured from the machinery as the second time-series of values, in order to generate data sets to be used for training of the machine learning model. FIG. 2 illustrates this approach for a first window position i in time and a second window position i+1 in time. The time windows for i and i+1 are shifted by a predetermined time 1 (stride). Subsequent time windows for i+1 and i+2 may be shifted by the predetermined time 1 or by a different further predetermined time 2, as indicated in FIG. 2. The time windows for i and i+1 may partially overlap in time, as depicted with an overlapping time generating an overlap area 3 in FIG. 2. Further parameters, which might be tuned are one or more parameters from the pre-processing of the first and second sets of time-series data and feature extraction and include, for example, a window size W of the time-windows for the data samples, a window time overlap, a predetermined time between succeeding windows i and i+1, a number and type of statistical features to be extracted from the time-windows, additional variables to be included into the extracted data samples (feature vectors).), and
wherein the processor is configured to simultaneously evaluate the data record against both the first tier and the second tier using their respective historical datasets (Schmitt [0039], [0061], [0101]. The method according to an embodiment uses, in the monitoring phase, the calculated anomaly score value of a new data sample {right arrow over (x)}NEW, calculated from the set of multivariate time-series values measured by the plurality of sensors. The anomalous score value AS represents a determination value, which enables to determine if the machinery is indeed in an anomalous operating status. Determining whether the machinery is in an anomalous operating status may be performed by comparing the calculated anomaly score value with a predetermined threshold value. After completing the training phase, the Siamese auto-encoder based neural network architecture is efficiently used for generating a raw anomaly score value AS for each novel data sample in an online operation of monitoring the physical machinery.)
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Schmitt and Lifshitz to include: wherein each tier from among the multiple tiers comprises a distinct historical dataset defined by a different time-window length, and wherein at least two tiers correspond to time windows that partially overlap in time such that a first tier includes a first set of historical datasets and a second tier includes a superset of the first set of historical datasets plus additional historical datasets, and wherein the processor is configured to simultaneously evaluate the data record against both the first tier and the second tier using their respective historical datasets. One would have been motivated to provide users with a means for using machine-learning algorithm for analyzing and detecting abnormal machine or network operating conditions against a trained AI model. (See Schmitt [0064].)
Regarding claim 11, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses wherein to generate the plurality of differences, the processor is further programmed to: determine a statistical deviation between the one or more fields in the data record with corresponding one or more fields in the historical dataset (Lifshitz [0040] - [0041]. The data is periodically collected (e.g., at pre-defined time intervals) by a Data Collector unit 211 (e.g., via Cl interface), and is stored in a repository therein. An Analyzer unit 212 performs analysis of the collected data: (a) Network activity profiling, performed periodically (e.g., at pre-defined time intervals), by clustering the collected data (e.g., via Cd interface) using a pre-defined clustering mechanism or clustering algorithm (e.g., by utilizing K-Means, or other suitable clustering method); and performing extraction of features from the data-set, per class of IoT devices, wherein a class pertains to a set of IoT devices that belongs to the same IoT service or type (e.g., type of “vending machine”, or type of “smoke detector”). Outliers are detected and flagged as suspicious, for example, based on distance greater than a pre-defined threshold value, or based on other indicators for irregularity of values or ranges-of-values; and a notification is generated with regard to such flagged IoT device, e.g., for further manual and/or automatic handling, for initiating attack mitigation operations, for remote de-activation or remote pausing of the IoT device, or the like.).
Regarding claim 13, claim 13 is directed to a method corresponding to the system of claim 1. Claim 13 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a computer-readable storage medium corresponding to the system of claim 1. Claim 19 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 21, Lifshitz and Schmitt disclose the computer readable storage medium of claim 19. Lifshitz further discloses wherein a sanction is imposed in response to at least one alert condition from among the plurality of alert conditions, and wherein the sanction is recorded in association with the at least one alert condition (Lifshitz [0061], [0078]. A Notifications Generator unit 308 may generate a notification or alarm or alert, that said particular IoT device is malfunctioning or is compromised, based on said dissimilar network traffic characteristics that are exhibited by said particular IoT device. In some embodiments, an Enforcement and Quarantine Unit 330, upon detection that said particular IoT device is malfunctioning or compromised, activates or operates a Full IoT Device Isolation Module 331 (i) to block relaying of all traffic that is outgoing from said particular IoT device to all destinations, and also (ii) to block relaying of all traffic that is incoming to said particular IoT device from all senders.).
Regarding claim 22, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses:
each tier from among the multiple tiers corresponds to a time window that terminates at a common reference time associated with the data record and has a different duration than at least one other tier, such that the time windows at least partially overlap, and wherein the processor is further programmed to (Lifshitz [0019]. [A] set of IoT devices, such as, an array of Internet-connected vending machines, or an array of Internet-connected smoke detectors, exhibit a generally stable and predictable network behavior and/or traffic activity; for example, each vending machine sends 3 kilobytes of data every hour on the hour, and also sends additional 7 kilobytes of data once a day at 3 AM. Accordingly, the system of the present invention may utilize this information in order to detect anomalies; for example, observing that ten vending machines are currently sending 800 kilobytes of data every 12 minutes, or that one vending machine is currently sending 240 kilobytes of data every minute, triggers a determination that this or these vending machine(s) is (or are) malfunctioning and/or compromised.):
generate, for the same data record, a plurality of differences comprising at least a first difference computed between one or more fields in the data record and corresponding one or more fields in the historical datasets for a first tier associated with a first time window, and at least a second difference computed between the one or more fields in the data record and corresponding one or more fields in the historical datasets for a second tier associated with a second time window that at least partially overlaps with the first time window (Lifshitz [0019]. [A] set of IoT devices, such as, an array of Internet-connected vending machines, or an array of Internet-connected smoke detectors, exhibit a generally stable and predictable network behavior and/or traffic activity; for example, each vending machine sends 3 kilobytes of data every hour on the hour, and also sends additional 7 kilobytes of data once a day at 3 AM. Accordingly, the system of the present invention may utilize this information in order to detect anomalies; for example, observing that ten vending machines are currently sending 800 kilobytes of data every 12 minutes, or that one vending machine is currently sending 240 kilobytes of data every minute, triggers a determination that this or these vending machine(s) is (or are) malfunctioning and/or compromised.); and
compare each of the first difference and the second difference to a corresponding learned filter parameter that was learned from the historical datasets of the respective tier (Lifshitz [0060] –[0061]. An Outlier Detector unit 307 may detect that a particular IoT device exhibits network traffic characteristics that are dissimilar relative to said cluster of regular pattern of network traffic of said particular type of IoT devices. A Notifications Generator unit 308 may generate a notification or alarm or alert, that said particular IoT device is malfunctioning or is compromised, based on said dissimilar network traffic characteristics that are exhibited by said particular IoT device.),
wherein the plurality of alert conditions are generated for the data record based further on the comparisons (Lifshitz [0060] –[0061]. An Outlier Detector unit 307 may detect that a particular IoT device exhibits network traffic characteristics that are dissimilar relative to said cluster of regular pattern of network traffic of said particular type of IoT devices. A Notifications Generator unit 308 may generate a notification or alarm or alert, that said particular IoT device is malfunctioning or is compromised, based on said dissimilar network traffic characteristics that are exhibited by said particular IoT device.).
Regarding claim 23, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses wherein the processor is further programmed to: compute, for each tier independently, a respective difference value using a same field of the data record against different historical datasets corresponding to each tier, such that a first difference for a first tier and a second difference for a second tier are computed in parallel using different sample sizes of historical data (Lifshitz [0019]. [A] set of IoT devices, such as, an array of Internet-connected vending machines, or an array of Internet-connected smoke detectors, exhibit a generally stable and predictable network behavior and/or traffic activity; for example, each vending machine sends 3 kilobytes of data every hour on the hour, and also sends additional 7 kilobytes of data once a day at 3 AM. Accordingly, the system of the present invention may utilize this information in order to detect anomalies; for example, observing that ten vending machines are currently sending 800 kilobytes of data every 12 minutes, or that one vending machine is currently sending 240 kilobytes of data every minute, triggers a determination that this or these vending machine(s) is (or are) malfunctioning and/or compromised.).
Regarding claim 24, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses wherein each learned filter parameter is uniquely associated with only one tier and is learned exclusively from the historical datasets corresponding to that tier, such that learned filter parameters for different tiers are derived from non-identical historical datasets (Lifshitz [0040] – [0041]. The Sensor Unit 221 monitors and collects the following data for each of the endpoints identified as managed IoT devices, and/or for each data connection: (a) timestamp of start; (b) 5-tuple of the connections (e.g., source IP address, source port, destination IP address, destination port, protocol being used); (c) Identified protocols; (d) upstream volume of traffic; (e) downstream volume of traffic; (f) upstream packet count; (g) downstream packet count. An Analyzer unit 212 performs analysis of the collected data: (a) Network activity profiling, performed periodically (e.g., at pre-defined time intervals), by clustering the collected data (e.g., via Cd interface) using a pre-defined clustering mechanism or clustering algorithm (e.g., by utilizing K-Means, or other suitable clustering method); and performing extraction of features from the data-set, per class of IoT devices, wherein a class pertains to a set of IoT devices that belongs to the same IoT service or type (e.g., type of “vending machine”, or type of “smoke detector”). (b) Each new data point for a particular IoT device is compared to the cluster(s) of the class for that device; or, the features or characteristics of traffic pertaining to a particular IoT device, is compared to the features or characteristics that characterize the cluster of IoT devices of that type. (c) Outliers are detected and flagged as suspicious, for example, based on distance greater than a pre-defined threshold value, or based on other indicators for irregularity of values or ranges-of-values; and a notification is generated with regard to such flagged IoT device. [Note that “tiers” can refer to sets of information/criteria for alert analysis, see Specification par. [0040].]).
Regarding claim 25, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses wherein the plurality of alert conditions comprises a vector of alert determinations corresponding one-to-one with the multiple tiers, such that a first alert condition corresponds to a first tier and a second alert condition corresponds to a second tier, and wherein the alert conditions are independently generated for each tier based on the respective comparison (Lifshitz [0040] – [0041]. The Sensor Unit 221 monitors and collects the following data for each of the endpoints identified as managed IoT devices, and/or for each data connection: (a) timestamp of start; (b) 5-tuple of the connections (e.g., source IP address, source port, destination IP address, destination port, protocol being used); (c) Identified protocols; (d) upstream volume of traffic; (e) downstream volume of traffic; (f) upstream packet count; (g) downstream packet count. An Analyzer unit 212 performs analysis of the collected data: (a) Network activity profiling, performed periodically (e.g., at pre-defined time intervals), by clustering the collected data (e.g., via Cd interface) using a pre-defined clustering mechanism or clustering algorithm (e.g., by utilizing K-Means, or other suitable clustering method); and performing extraction of features from the data-set, per class of IoT devices, wherein a class pertains to a set of IoT devices that belongs to the same IoT service or type (e.g., type of “vending machine”, or type of “smoke detector”). (b) Each new data point for a particular IoT device is compared to the cluster(s) of the class for that device; or, the features or characteristics of traffic pertaining to a particular IoT device, is compared to the features or characteristics that characterize the cluster of IoT devices of that type. (c) Outliers are detected and flagged as suspicious, for example, based on distance greater than a pre-defined threshold value, or based on other indicators for irregularity of values or ranges-of-values; and a notification is generated with regard to such flagged IoT device. [Note that “tiers” can refer to sets of information/criteria for alert analysis, see Specification par. [0040].]).
Regarding claim 26, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses wherein the processor is further programmed to: generate, for the data record, a plurality of signals each corresponding to a respective combination of (i) a tier from among the multiple tiers and (ii) a field of the data record, and to independently evaluate each signal to generate a corresponding alert condition (Lifshitz [0040] – [0041]. The Sensor Unit 221 monitors and collects the following data for each of the endpoints identified as managed IoT devices, and/or for each data connection: (a) timestamp of start; (b) 5-tuple of the connections (e.g., source IP address, source port, destination IP address, destination port, protocol being used); (c) Identified protocols; (d) upstream volume of traffic; (e) downstream volume of traffic; (f) upstream packet count; (g) downstream packet count. An Analyzer unit 212 performs analysis of the collected data: (a) Network activity profiling, performed periodically (e.g., at pre-defined time intervals), by clustering the collected data (e.g., via Cd interface) using a pre-defined clustering mechanism or clustering algorithm (e.g., by utilizing K-Means, or other suitable clustering method); and performing extraction of features from the data-set, per class of IoT devices, wherein a class pertains to a set of IoT devices that belongs to the same IoT service or type (e.g., type of “vending machine”, or type of “smoke detector”). (b) Each new data point for a particular IoT device is compared to the cluster(s) of the class for that device; or, the features or characteristics of traffic pertaining to a particular IoT device, is compared to the features or characteristics that characterize the cluster of IoT devices of that type. (c) Outliers are detected and flagged as suspicious, for example, based on distance greater than a pre-defined threshold value, or based on other indicators for irregularity of values or ranges-of-values; and a notification is generated with regard to such flagged IoT device. [Note that “tiers” can refer to sets of information/criteria for alert analysis, see Specification par. [0040].]).
Regarding claim 27, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses
wherein the processor is further programmed to reuse at least a portion of the historical datasets of the first tier in computing both a first difference for the first tier and a second difference for the second tier such that the first difference and the second difference are computed over partially identical underlying data (Lifshitz [0126]-[0127]. In some embodiments, the baseline behavior determination unit is to dynamically update said RBCCB profile of said particular IoT group, based on continued Machine Learning (ML) of traffic-related behavior of members of said particular IoT group. In some embodiments, the outlier detector is: (i) to detect that said particular IoT device exhibits cellular communication activity that is sufficiently dissimilar, beyond a pre-defined threshold of dissimilarity, from said RBCCB profile of said particular IoT group, and (ii) to trigger said enforcement actions generator to perform one or more enforcement operations with regard to said particular IoT device.).
Schmitt further discloses
wherein the historical datasets corresponding to a second tier include all historical datasets of a first tier and additional historical datasets extending further back in time (Schmitt FIG. 2, [0064], [0070], [0099]. The method may execute a pre-processing of the obtained time-series of values, either obtained from the digital twin simulation of the machinery as first time-series of values or measured from the machinery as the second time-series of values, in order to generate data sets to be used for training of the machine learning model. FIG. 2 illustrates this approach for a first window position i in time and a second window position i+1 in time. The time windows for i and i+1 are shifted by a predetermined time 1 (stride). Subsequent time windows for i+1 and i+2 may be shifted by the predetermined time 1 or by a different further predetermined time 2, as indicated in FIG. 2. The time windows for i and i+1 may partially overlap in time, as depicted with an overlapping time generating an overlap area 3 in FIG. 2. Further parameters, which might be tuned are one or more parameters from the pre-processing of the first and second sets of time-series data and feature extraction and include, for example, a window size W of the time-windows for the data samples, a window time overlap, a predetermined time between succeeding windows i and i+1, a number and type of statistical features to be extracted from the time-windows, additional variables to be included into the extracted data samples (feature vectors).).
The motivation is the same as that of claim 1 above.
Regarding claim 28, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz further discloses a first difference and a second difference are each computed using an identical field of the data record and identical field definitions in the historical datasets, and wherein the processor is further programmed to determine whether the first difference and the second difference diverge from one another by at least a threshold amount to identify a temporal inconsistency across overlapping time periods (Lifshitz [0118], [0126]. In some embodiments, the baseline behavior determination unit is to generate said RBCCB profile which indicates that each member of said particular IoT group, establishes between N1 and N2 core network connection requests per T hours, wherein N1 and N2 and T are pre-defined threshold values; wherein the outlier detector comprises a communication frequency abnormality detector, (i) to determine that said particular IoT device establishes R core network connection requests per T hours, wherein D is not between N1 to N2, and (ii) to determine that said particular IoT device is malfunctioning or compromised. In some embodiments, the baseline behavior determination unit is to dynamically update said RBCCB profile of said particular IoT group, based on continued Machine Learning (ML) of traffic-related behavior of members of said particular IoT group. [Suppose T = 1hour, between 3:00-4:00 PM an IOT device requested 5 core connection requests, which is within the N1, N2 threshold, while between 3:50 PM and 4:50 PM, the number of core request is greater than D and is thus abnormal.]. ).
Claims 2, 3, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lifshitz et al. (“Lifshitz,” US 20190380037, published Dec. 12, 2019), Schmitt et al. (“Schmitt,” US 20210110262, filed Oct. 13, 2020) and Silverman et al. (“Silverman,” US 20220035770, filed Oct. 26, 2020).
Regarding claim 2, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz and Schmitt do not explicitly disclose:
wherein the processor is further programmed to: receive, from a user, a user-defined filter parameter; and replace at least one of the plurality of learned filter parameters with the user- defined filter parameter, wherein the plurality of alert conditions is generated based on the user-defined filter parameter instead of the replaced one of the plurality of learned filter parameters.
However, in an analogous art, Silver discloses a system, comprising:
wherein the processor is further programmed to: receive, from a user, a user-defined filter parameter; and replace at least one of the plurality of learned filter parameters with the user- defined filter parameter, wherein the plurality of alert conditions is generated based on the user-defined filter parameter instead of the replaced one of the plurality of learned filter parameters (Silverman [0041] – [0042]. In certain embodiments, the information collected by the provisioning management application of data source 30 may comprise at least a portion of one or more policies (e.g., the information may comprise one or more rules of a policy or an entire policy). Policies may be developed manually, automatically (e.g., using machine learning), or both (e.g., a user provides initial policy information, machine learning updates the policy information, the user can review/override the policy information). Examples of policies for email may include encrypting, filtering, archiving, and/or branding policies. These policies may indicate content and/or metadata to be reviewed for an email or email attachment and actions to perform if the content and/or metadata matches or fails to match keywords or characteristics defined by the policy. A filter policy may indicate which emails require filtering, which filter(s) to apply (e.g., antivirus, anti-spam), which actions to take (e.g., quarantine the email, discard the email after a certain period of inaction, perform a malware scan and attempt to remediate the email, etc.), and/or other filter-related rules.)
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Lifshitz, Schmitt and Silverman to include: wherein the processor is further programmed to: receive, from a user, a user-defined filter parameter; and replace at least one of the plurality of learned filter parameters with the user- defined filter parameter, wherein the plurality of alert conditions is generated based on the user-defined filter parameter instead of the replaced one of the plurality of learned filter parameters. One would have been motivated to provide users with a means for using user-defined policy for filtering emails. (See Silverman [0041].)
Regarding claim 3, Lifshitz, Schmitt and Silverman disclose the system of claim 2. Silverman further discloses wherein the user is part of a group of users, and wherein processor is further programmed to: use the user-defined filter parameter for all users in the group (Silverman [0036], [0041]-[0042]. An enterprise may generally refer to a group of users configured to have at least some provisioning data 22 in common. As an example, an enterprise may be a company and the users may be employees of the company. As an example, an email service provider may host email services for a number of enterprise customers and/or a number of customers that are individual users. In certain embodiments, the information collected by the provisioning management application of data source 30 may comprise at least a portion of one or more policies (e.g., the information may comprise one or more rules of a policy or an entire policy). A filter policy may indicate which emails require filtering, which filter(s) to apply (e.g., antivirus, anti-spam), which actions to take (e.g., quarantine the email, discard the email after a certain period of inaction, perform a malware scan and attempt to remediate the email, etc.), and/or other filter-related rules.)
The motivation is the same as that of claim 2 above.
Regarding claim 14, claim 14 is directed to a method corresponding to the system of claim 2. Claim 14 is similar to claim 2 and is therefore rejected under similar rationale.
Claims 4, 5, 7, 8 are rejected under 35 U.S.C. 103 as being unpatentable over Lifshitz et al. (“Lifshitz,” US 20190380037, published Dec. 12, 2019), Schmitt et al. (“Schmitt,” US 20210110262, filed Oct. 13, 2020) and Lewis (“Lewis,” US 20220046047, filed Aug. 10, 2020).
Regarding claim 4, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz and Schmitt do not explicitly disclose: wherein to generate the plurality of differences between one or more fields in the data record with corresponding one or more fields in the historical dataset, the processor is further programmed to: limit the historical datasets to those associated with a user that is the same user that is also associated with the data record to make the comparison to historical activity of the user.
However, in an analogous art, Lewis discloses a system comprising:
wherein to generate the plurality of differences between one or more fields in the data record with corresponding one or more fields in the historical dataset, the processor is further programmed to: limit the historical datasets to those associated with a user that is the same user that is also associated with the data record to make the comparison to historical activity of the user (Lewis [0066]. For example, in training the machine learning model to the monitored data at step 204, cyber event analysis computing platform 110 may train the machine learning model to recognize an anomaly relative to a typical virtual desktop session accessed by the remote user computing device 170 based on a learned pattern of user activity during a virtual desktop sessions. For instance, the cyber event analysis computing platform 110 may learn that a typical virtual desktop session of a particular person occurs in the morning hours and consists and creating files. Accordingly, a virtual desktop sessions that deviates from this pattern (e.g., a session at night consisting on only viewing files) may be indicative of a potential cyber-attack.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Lifshitz, Schmitt and Lewis to include: limit the historical datasets to those associated with a user that is the same user that is also associated with the data record to make the comparison to historical activity of the user. One would have been motivated to provide users with a means for detecting anomaly according to the user activity profile. (See Lewis [0066].)
Regarding claim 5, Lifshitz and Schmitt disclose the system of claim 1. Lewis further discloses wherein to generate the plurality of differences between one or more fields in the data record with corresponding one or more fields in the historical dataset, the processor is further programmed to: limit the historical datasets to those associated with users in the same organization as the user associated with the data record to make the comparison to historical activity of an organization of a user (Lewis [0067]. In some embodiments, applying the machine learning model to the monitored data received from the one or more data source computer systems may include applying the machine learning model to data received from a virtual desktop session on the remote user computing device 170, where the virtual desktop session accesses information associated with an enterprise organization, and where at least some of the information may be confidential and/or have varying levels of confidentiality. For example, in applying the machine learning model to the monitored data received from the one or more data source computer systems (e.g., remote user computing device 170, local user computing device 140) at step 204, cyber event analysis computing platform 110 may train the machine learning model to associate user accounts with a confidentiality level of information likely to be accessed by that user account, an/or a type of information likely to be accessed by that user account. As such, the machine learning model may be trained to detect anomalous activity based on the user account at the virtual desktop accessing a type of information that differs (e.g., in confidentiality, in classification, and the like) from information that is typically accessed.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Lifshitz, Schmitt and Lewis to include: limit the historical datasets to those associated with users in the same organization as the user associated with the data record to make the comparison to historical activity of an organization of a user. One would have been motivated to provide users with a means for detecting anomaly according to the user activity profile with respect to policies or expected behavior for an enterprise. (See Lewis [0067].)
Regarding claim 7, Lifshitz and Schmitt disclose the system of claim 1. Lewis further discloses wherein the processor is further programmed to: receive, from a user, a number and type of a plurality of signals to use for alert generation, wherein a number of the plurality of signals is based on the multiple tiers and the one or more fields and wherein each signal of the plurality of signals is assessed to generate a corresponding alert condition (Lewis [0065]-[0066], [0081]. For instance, the data received may be used to identify a number of factors associated with the user activity (e.g., actions taken, content accessed, session timing, or the like) for which the machine learning model may be trained to predict a potential cyber-attack. For instance, the cyber event analysis computing platform 110 may learn that a typical virtual desktop session of a particular person occurs in the morning hours and consists and creating files. Accordingly, a virtual desktop sessions that deviates from this pattern (e.g., a session at night consisting on only viewing files) may be indicative of a potential cyber-attack. In some embodiments, sending the security response alert generated based on the new activity data may include sending the security response alert to the one or more enterprise computer systems in real-time as the activity data is being captured and monitored by the cyber event analysis computing platform 110. ).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Lifshitz, Schmitt and Lewis to include: receive, from a user, a number and type of a plurality of signals to use for alert generation, wherein a number of the plurality of signals is based on the multiple tiers and the one or more fields and wherein each signal of the plurality of signals is assessed to generate a corresponding alert condition. One would have been motivated to provide users with a means for detecting anomaly according to the user activity profile with respect to policies or expected behavior of the user of an enterprise. (See Lewis [0066])
Regarding claim 8, Lifshitz, Schmitt and Lewis disclose the system of claim 7. Lewis further discloses wherein the user is part of a group of users, and wherein processor is further programmed to: use the number and the type of the plurality of signals for all users in the group (Lewis [0067]. In some embodiments, applying the machine learning model to the monitored data received from the one or more data source computer systems may include applying the machine learning model to data received from a virtual desktop session on the remote user computing device 170, where the virtual desktop session accesses information associated with an enterprise organization, and where at least some of the information may be confidential and/or have varying levels of confidentiality. For example, in applying the machine learning model to the monitored data received from the one or more data source computer systems (e.g., remote user computing device 170, local user computing device 140) at step 204, cyber event analysis computing platform 110 may train the machine learning model to associate user accounts with a confidentiality level of information likely to be accessed by that user account, an/or a type of information likely to be accessed by that user account. As such, the machine learning model may be trained to detect anomalous activity based on the user account at the virtual desktop accessing a type of information that differs (e.g., in confidentiality, in classification, and the like) from information that is typically accessed.).
The motivation is the same as that of claim 7 above.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Lifshitz et al. (“Lifshitz,” US 20190380037, published Dec. 12, 2019), Schmitt et al. (“Schmitt,” US 20210110262, filed Oct. 13, 2020) and Doron et al. (“Doron,” US 20180255095, published Sept. 6, 2018).
Regarding claim 6, Lifshitz and Schmitt disclose the system of claim 1. Lifshitz and Schmitt do not explicitly disclose: wherein to generate the plurality of differences between one or more fields in the data record with corresponding one or more fields in the historical dataset, the processor is further programmed to: limit the historical datasets to those associated with a financial instrument that is the same financial instrument in the data record to make the comparison specific to all users in the historical dataset who have traded the financial instrument.
However, in an analogous art, Chamberlain discloses a system comprising:
wherein to generate the plurality of differences between one or more fields in the data record with corresponding one or more fields in the historical dataset, the processor is further programmed to: limit the historical datasets to those associated with a financial instrument that is the same financial instrument in the data record to make the comparison specific to all users in the historical dataset who have traded the financial instrument (Chamberlain FIGs 3-4, [0038], [0040], [0048]. For example, the rules may be automatically generated based on market trends, data mining, and machine learning. For example, the risk analysis circuit 244 is connected to the account database 240 to access (e.g., query) the account/profile information, historical transaction information, and/or trading partner information stored thereon. The electronic transaction may correspond to a payment or transfer of funds from a user of the user device to a beneficiary. In some arrangements, the anomaly may be detected if the electronic transaction is not consistent with a profile or a pattern of behavior of the user. For example, in some arrangements, user account/profile information, trading partner data, and/or transactional history data are analyzed to detect the anomaly.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Lifshitz, Schmitt and Chamberlain to include: limit the historical datasets to those associated with a financial instrument that is the same financial instrument in the data record to make the comparison specific to all users in the historical dataset who have traded the financial instrument. One would have been motivated to provide users with a means for detecting suspicious financial transaction through a statistical analysis of historic trading behavior among user’s trading partners. (See Chamberlain [0048].)
Claims 12 is rejected under 35 U.S.C. 103 as being unpatentable over Lifshitz et al. (“Lifshitz,” US 20190380037, published Dec. 12, 2019), Schmitt et al. (“Schmitt,” US 20210110262, filed Oct. 13, 2020) and Kaimal et al. (“Kaimal,” US 11483339, filed Dec. 18, 2019).
Regarding claim 12, Lifshitz and Schmitt discloses the system of claim 1. Lifshitz and Schmitt do not explicitly disclose: wherein the processor is further programmed to: conduct multi-branched filter parameter learning to learn the plurality of learned filter parameters and a second set of a plurality of learned filter parameters for second historical datasets, the multi-branched filter parameter learning being based on a first source associated with the historical datasets and a second source associated with the second historical datasets; identify a source associated with the data record; and select the plurality of learned filter parameters based on a match between the source associated with the data record and the first source associated with the historical datasets.
However, in an analogous art, Kaimal discloses a system comprising:
wherein the processor is further programmed to: conduct multi-branched filter parameter learning to learn the plurality of learned filter parameters and a second set of a plurality of learned filter parameters for second historical datasets, the multi-branched filter parameter learning being based on a first source associated with the historical datasets and a second source associated with the second historical datasets (Kaimal FIG. 4A, col. 7: 20-26, 30-45. FIG. 4A is a flowchart illustrating operations performed when a data analyzer receives a set network traffic (402). The data analyzer can determine the type of device, for example, using device profile data received from a device profiler (404). The analyzer can determine if the device providing the data is in a learning period (406). If the device is not in a learning period, then the operations of the flowchart of FIG. 4B can be performed (“NO” branch of 406). If the device is in a learning period (“YES” branch of 406), then the analyzer can determine if a baseline has been established for the device, type of device, and/or class of device (408). If a baseline doesn't exist (“NO” branch of 408), then a baseline is created for the device (410). In some aspects, the baseline may be created by determine a particular set of predetermined features from the set of incoming network traffic. For example, device type, domain names of source or destination devices communicating with the device of interest, packet rates, data rates, OS version, software version etc. may be used to create a baseline profile for the device. Similarly, a baseline profile for the device type or device class may be created using similar features.);
identify a source associated with the data record (Kaimal col. 7: 65-67; col. 8: 1-8. Features of the incoming data can be compared to the features stored in the baseline profile (418). For example, in the case where the baseline profile stores predetermined features, the feature values can be extracted from the incoming network data and compared with the feature values in the baseline profile. In the case where the baseline profile includes a machine learning model, the incoming data can be run through the model and the resulting predicted features can be used to determine if an anomaly exists (420).); and
select the plurality of learned filter parameters based on a match between the source associated with the data record and the first source associated with the historical datasets (Kaimal col. 8: 7-21. As an example, domain names or IP address/Port combinations that appear in the incoming network traffic can be compared with domain names or IP address/port combinations that are in the baseline profile. If a domain name appears in the incoming network traffic that is not in the baseline profile, then it may be likely that an attacker has spoofed the MAC address of network device. Similarly, if the packet rate or data rate associated with incoming network traffic is different from the baseline profile, an attacker may be using tools that generate a different amount of network traffic or different packet rate, which can indicate that malware is installed on the network device or an attacker has spoofed the MAC address of the network device and is using attack tools that generate a different amount of network traffic or traffic at a different rate than is expected from a non-spoofed or non-infected device.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the embodiments of Lifshitz, Schmitt and Kaimal to include: select the plurality of learned filter parameters based on a match between the source associated with the data record and the first source associated with the historical datasets. One would have been motivated to provide users with a means for selecting an appropriate base-line profile and to detect an anomaly based on the selected network baseline profile. (See Kaimal col. 8: 7-21.)
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a)..
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system.
Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights