Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
Office Action is in response to the RCE filed by Applicant on 10/14/2025. Claims 1-20 are pending. This Office Action is Final.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/14/2025 has been entered.
Response to Arguments
A) Applicant’s arguments with respect to claim(s) 1, 11 and 16 have been considered but are moot because the new ground of rejection does not rely on the exact combination of references applied in the prior rejection of record for the matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 3-5, 8, 11, 13-16 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zaslavsky et al. (US 2020/0242525) in view of Aghdale et al. (US 10,459,827).
As per claim 1, Zaslavsky teaches a method comprising: receiving, at a security platform, a plurality of data sets characterizing prior intrusive activities with respect to computing resources associated with one or more entities (Zaslavsky, Paragraph 0026 recites “FIG. 3 is a flow chart illustrating an exemplary implementation of a data-driven risk detection policy extraction process 300, according to one embodiment of the disclosure. As shown in FIG. 3, the exemplary data-driven risk detection policy extraction process 300 initially obtains the features 130 during step 310 that were identified in the organization data 110 for risk analysis. Generally, a given feature comprises multiple data values, where each data value for the given feature comprises a discrete value of the given feature or a range of values for the given feature (e.g., associated with a data bucket).” And Paragraph 0031 recites “The anomalous data value and/or buckets are identified, for example, by defining a threshold using a previously calculated probability. For example, for a specific feature 130, the anomalous bucket can be identified as the bucket(s) containing less than 1% of the total number of users. One or more aspects recognize that if there are anomalous values for each transaction, relevant features can be selected to generate a final policy representation to detect future anomalies having similar characteristics.” Transactions being monitored would read on access to resources in the network);
applying the one or more rule generation policies to the plurality of data sets characterizing the prior intrusive activities to generate a plurality of intrusive activity detection rules (Zaslavsky, Paragraph 0034 recites “Finally, the exemplary data-driven risk detection policy extraction process 300 generates one or more policies 240 for the organization during step 350, using one or more of the combinations of candidate anomalous data values based on a corresponding intervention rate. For example, the simplest combination of features can be selected for use in the generated policy 240 (or rule) (e.g., which combination of features 130 contains the smallest number of features), and also has a challenge rate below the estimated baseline challenge rate (e.g., with respect to threshold).”);
and causing the plurality of intrusive activity detection rules to be used to detect subsequent intrusive activities (Zaslavsky, Paragraph 0025 recites “In addition, the exemplary risk detection policy management system 250 provides a feedback path to the exemplary anomaly detection-based policy extraction module 230 comprising policy usage feedback and performance information 260. For example, the feedback may comprise a fraud detection rate indicating how many transactions were identified as fraudulent or otherwise risky.”).
But fails to teach receiving, at the security platform, one or more rule generation policies each pertaining to one or more respective transformations of one or more data sets into one or more intrusive activity detection rules, wherein the one or more rule generation policies are associated with a plurality of transformation types supported by the security platform.
However, in an analogous art Aghdale teaches receiving, at the security platform, one or more rule generation policies each pertaining to one or more respective transformations of one or more data sets into one or more intrusive activity detection rules (Aghdale, Col. 22 Lines 3-14 recites “At block 608, the anomaly detection system 130 can update the anomaly detection model based, at least in part, on the historical data, the feedback data, and/or the contextual data. Depending on the specific embodiment, an update to one or more anomaly detection models may be based, at least in part, on information received from the data aggregation system 134 and/or information received from the anomaly feedback system 138. After the anomaly detection model has been updated, the anomaly detection model can be used to analyze application host system 120 data in accordance with the interactions described in association with FIG. 3A.”,)
wherein the one or more rule generation policies are associated with a plurality of transformation types supported by the security platform (Aghdale, Col. 21 Lines 58-67 recites “At block 606, the anomaly detection system 130 can receive contextual data associated with one or more data sets. The contextual data may identify a specific reason or identifier associated with a previously detected anomaly event. For example, an anomaly event that was identified as a false positive could be accompanied by contextual data indication that the increased load for accessing a download server was due to the release of a game patch. The contextual data may identify specific conditional identifiers associated with the feedback provided by the subscriber. For example, the anomaly detection system 130 may classify the conditional identifiers according to defined classes.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Aghdale’s Machine-learning Based Anomaly Detection For Heterogenous Data Sources with Zaslavsky’s automated generation of adaptive policies from organizational data for detection of risk-related events because it offers the advantage of an efficient way to keep detection policies up to date in real-time.
As per claim 3, Zaslavsky in combination with Aghdale teaches the method of claim 1, Zaslavsky further teaches further comprising: receiving, at the security platform, a plurality of updated data sets characterizing the prior intrusive activities (Zaslavsky, Paragraph 0026 recites “FIG. 3 is a flow chart illustrating an exemplary implementation of a data-driven risk detection policy extraction process 300, according to one embodiment of the disclosure. As shown in FIG. 3, the exemplary data-driven risk detection policy extraction process 300 initially obtains the features 130 during step 310 that were identified in the organization data 110 for risk analysis. Generally, a given feature comprises multiple data values, where each data value for the given feature comprises a discrete value of the given feature or a range of values for the given feature (e.g., associated with a data bucket).” Zaslavsky is an adaptive method which is being interpreted that performing the main invention creating new policies with updated data would be covered);
applying the one or more rule generation policies to the plurality of updated data sets characterizing the prior intrusive activities to generate a plurality of updated intrusive activity detection rules (Zaslavsky, Paragraph 0034 recites “Finally, the exemplary data-driven risk detection policy extraction process 300 generates one or more policies 240 for the organization during step 350, using one or more of the combinations of candidate anomalous data values based on a corresponding intervention rate. For example, the simplest combination of features can be selected for use in the generated policy 240 (or rule) (e.g., which combination of features 130 contains the smallest number of features), and also has a challenge rate below the estimated baseline challenge rate (e.g., with respect to threshold).”);
and causing the plurality of updated intrusive activity detection rules to be used to detect subsequent intrusive activities (Zaslavsky, Paragraph 0025 recites “In addition, the exemplary risk detection policy management system 250 provides a feedback path to the exemplary anomaly detection-based policy extraction module 230 comprising policy usage feedback and performance information 260. For example, the feedback may comprise a fraud detection rate indicating how many transactions were identified as fraudulent or otherwise risky.”).
As per claim 4, Zaslavsky in combination with Aghdale teaches the method of claim 3, Zaslavsky further teaches wherein the plurality of updated data sets characterizing the prior intrusive activities comprise user feedback regarding one or more alerts generated by the plurality of intrusive activity detection rules (Zaslavsky, Paragraph 0028 recites “For example, data values and/or data buckets having a low probability of occurrence are considered rare events and are good policy candidates for generating alerts.”).
As per claim 5, Zaslavsky in combination with Aghdale teaches the method of claim 1, Zaslavsky further teaches wherein each of the plurality of data sets characterizing prior intrusive activities comprises at least one of: a set of time series log data associated with the prior intrusive activities, a malware binary pattern associated with the prior intrusive activities, or a user-generated template representing the prior intrusive activities (Zaslavsky, Paragraph 0021 recites “In some embodiments, anomaly detection techniques are applied to the features 130 identified in the organization data repository 110, in order to find anomalous patterns in the organization data, and thereafter generate the extracted risk detection policies 150 (e.g., for fraud detection, optionally to achieve a desired intervention rate).”).
As per claim 8, Zaslavsky in combination with Aghdale teaches the method of claim 1, Aghdale further teaches wherein the plurality of transformation types include at least two of: a template that maps data sets to intrusive activity detection rules: an algorithm that ingests data sets to generate rules: or an algorithm that translates source rules to intrusive activity detection rules (Aghdale, Col. 10 Lines 54-67 recites “The historical data 152 can include data received from one or more data sources, such as, for example, an application host system 120. The historical data 152 can include data from different application host systems 120, different data sources, different data types, and any data generated by the application host systems. In some embodiments, the historical data 152 may include a very large number of data points, such as millions of data points, aggregated by the data aggregation system 134. In some embodiments, depending on the anomaly detection model being generated, the historical data 152 may be filtered to include a subset of the total available data. For example, the historical data may only include data of one or more defined data types in accordance with a model generation rule set 166.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Aghdale’s Machine-learning Based Anomaly Detection For Heterogenous Data Sources with Zaslavsky’s automated generation of adaptive policies from organizational data for detection of risk-related events because it offers the advantage of an efficient way to keep detection policies up to date in real-time.
Regarding claims 11 and 16, claims 11 and 16 are directed to a system and a non-transitory computer-readable medium associated with the method of claim 1. Claims 11 and 16 are of similar scope to claim 1, and are therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed to a similar system associated with the method of claim 3 respectively. Claim 13 is similar in scope to claim 3, respectively, and are therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a similar system associated with the method of claim 4 respectively. Claim 14 is similar in scope to claim 4, respectively, and are therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a similar system associated with the method of claim 5 respectively. Claim 15 is similar in scope to claim 5, respectively, and are therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a similar a non-transitory computer-readable medium associated with the method of claim 8 respectively. Claim 18 is similar in scope to claim 8, respectively, and are therefore rejected under similar rationale.
Claim(s) 2 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zaslavsky et al. (US 2020/0242525) and Aghdale et al. (US 10,459,827) and in further view of Drapeau et al. (US 2020/0389472).
As per claim 2, Zaslavsky in combination with Aghdale teaches the method of claim 1, but fails to teach further comprising: testing a rule of the plurality of intrusive activity detection rules on a test data set to determine an intrusive activity detection false positive rate metric; determining that the rule does not meet a false positive rate threshold criterion; and queuing the rule for security analysis by a user.
However, in an analogous art Drapeau teaches testing a rule of the plurality of intrusive activity detection rules on a test data set to determine an intrusive activity detection false positive rate metric; determining that the rule does not meet a false positive rate threshold criterion; and queuing the rule for security analysis by a user (Drapeau, Paragraph 0050 recites “A rule manager 340 provides management components for distribution of new rules to endpoints, maintenance of hierarchy and exceptions and rules, and reporting of successful or unsuccessful application of rules. A testing component 342 tests new compiled rule 318 (the low-level representation (RepLL) of the rule) and stores the results in 344. In some examples, testing component 342 determine the true detection rate and/or the false positive rate. These are compared with one or more thresholds in thresholds 346, for example detection threshold 346a and false alarm threshold 346b. If new compiled rule 318 is deemed ineffective (e.g., because the true detection rate is less than detection threshold 346a and/or the false positive rate is greater than false alarm threshold 346b), a better rule may be needed.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Drapeau’s stateful rule generation for behavior based threat detection with Zaslavsky’s automated generation of adaptive policies from organizational data for detection of risk-related events because it offers the advantage of ensuring a rule/policy is operating properly or is necessary.
Regarding claim 12, claim 12 is directed to a similar system associated with the method of claim 2 respectively. Claim 12 is similar in scope to claim 2, respectively, and are therefore rejected under similar rationale.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zaslavsky et al. (US 2020/0242525) and Aghdale et al. (US 10,459,827) and in further view of Addepalli et al. (US 8,903,593).
As per claim 6, Zaslavsky in combination with Aghdale teaches the method of claim 1, but fails to teach wherein each of the plurality of data sets characterizing prior intrusive activities comprises a set of time series log data coupled with associated intrusive activity detections from an external intrusive activity detection tool.
However, in an analogous art Addepalli teaches wherein each of the plurality of data sets characterizing prior intrusive activities comprises a set of time series log data coupled with associated intrusive activity detections from an external intrusive activity detection tool (Addepalli, Col. 18 Line 63 – Col. 19 line 13 recites “In the example embodiment of FIG. 3C, diagnostic cloud 150 includes data mining components in an abnormal behavior detection module 156. Abnormal behavior detection module 156 can include time and space series based trend analyzer 152a and possibly a policy based trend analyzer 152b for detecting both abnormal and normal trends. Abnormal behavior detection module 156 may also include a trend correlator 151 for correlating diagnostic data across multiple vehicles of a given type and model, for example, in order to identify abnormal behavior. An alert system 155 and a policy database 153 may also be included in diagnostic cloud 150. Policy database 153 may include polices issued by humans 94, software agents 95, clouds 45-48, authorized entities 98, or any other suitable and authorized policy creator. Alert system 155 may be configured to alert any appropriate entity of a detected vehicular problem (e.g., manufacturing defect, vehicle malfunction, etc.), including alerts to an owner, a manufacturer or OEM, and/or safety authorities.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Addepalli’s System And Method For Analyzing Vehicular Behavior In A Network Environment with Zaslavsky’s automated generation of adaptive policies from organizational data for detection of risk-related events because it offers the advantage of being able to analyze data relative to time.
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zaslavsky et al. (US 2020/0242525) and Aghdale et al. (US 10,459,827) and in further view of Miao et al. (US 10,997,312).
As per claim 7, Zaslavsky in combination with Aghdale teaches the method of claim 1, but fails to teach wherein each of the plurality of data sets characterizing prior intrusive activities comprises a plurality of source rules in a first format, wherein the plurality of intrusive activity detection rules are in a second format, and wherein the one or more of rule generation policies define translation of the plurality of source rules in the first format to the plurality of intrusive activity detection rules in the second format.
However, in an analogous art Miao teaches wherein each of the plurality of data sets characterizing prior intrusive activities comprises a plurality of source rules in a first format, wherein the plurality of intrusive activity detection rules are in a second format, and wherein the one or more of rule generation policies define translation of the plurality of source rules in the first format to the plurality of intrusive activity detection rules in the second format (Miao, Claim 1 recites “identifying a data source comprising one or more fields from a plurality of data sources; creating an access policy including one or more attributes bound to the one or more fields, a view of the data source, and a rule associated with the one or more attributes, wherein the view is a query that indicates a subset of fields from the data source; receiving a data request referencing the view; in response to the data request, applying the access policy to rewrite the data request to include a JOIN operation on the data source and the view, wherein the rewritten data request limits access to the view in accordance with the rule, and wherein rewriting the query includes rewriting the view to include a query condition comprising a value of the one or more attributes; and executing the rewritten data request.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Miao’s Access Control Framework with Zaslavsky’s automated generation of adaptive policies from organizational data for detection of risk-related events because it offers the advantage of being able to analyze data in relevance to source rules.
Regarding claim 17, claim 17 is directed to a similar a non-transitory computer-readable medium associated with the method of claim 7 respectively. Claim 17 is similar in scope to claim 7, respectively, and are therefore rejected under similar rationale.
Claim(s) 9, 10, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zaslavsky et al. (US 2020/0242525) and Aghdale et al. (US 10,459,827) and in further view of Gaddam et al. (US 2022/0050897).
As per claim 9, Zaslavsky in combination with Aghdale teaches the method of claim 1, Zaslavsky further teaches wherein: at least one of the plurality of intrusive activity detection rules corresponds to a machine learning model (Zaslavsky, Paragraph 0020 recites “In some embodiments, guidance from such subject matter experts and data scientists can be used to define the features 130 that comprise indicators of compromise (IoC) that can be employed by the data-driven risk detection policy extraction system 100 to identify and extract one or more extracted risk detection policies 150, as discussed hereinafter. Generally, for any machine learning model, the better the features processed by the machine learning model, the better the results.”).
But fails to teach at least one of the one or more rule generation policies defines a set of features and respective labels in the plurality of data sets characterizing prior intrusive activities that are to be used to train the machine learning model, wherein each label of the respective labels indicates presence or absence of intrusive activity in one or more corresponding features of the set of features; and applying the one or more rule generation policies to the plurality of data sets characterizing prior intrusive activities comprises training the machine learning model using training data comprising: the set of features representing training inputs; and the respective labels representing target outputs for the training inputs.
However, in an analogous art Gaddam teaches at least one of the one or more rule generation policies defines a set of features and respective labels in the plurality of data sets characterizing prior intrusive activities that are to be used to train the machine learning model, wherein each label of the respective labels indicates presence or absence of intrusive activity in one or more corresponding features of the set of features; and applying the one or more rule generation policies to the plurality of data sets characterizing prior intrusive activities comprises training the machine learning model using training data comprising: the set of features representing training inputs; and the respective labels representing target outputs for the training inputs.
(Gaddam, Paragraph 0108 recites “At step S716, the microservice evaluator 704 can train a plurality of machine learning models corresponding to the plurality of microservices using the system level activity data or a derivative thereof as training data. The microservice evaluator 704 may train the machine learning models to classify system level activities (including system calls and commands) from the system level activity data as either normal or abnormal. Normal system level activities may include system level activities that occur frequently during normal execution of the microservices, while abnormal system level activities may include system level activities that do not occur frequently, or are potentially hazardous. The microservice evaluator 704 may use any appropriate supervised or unsupervised machine learning model, including, as examples, one-class support vector machines and k-means clustering.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Gaddam’s microservice adaptive security hardening with Zaslavsky’s automated generation of adaptive policies from organizational data for detection of risk-related events because it offers the advantage of using machine learning techniques to create a more secure environment.
As per claim 10, Zaslavsky in combination with Gaddam teaches the method of claim 9, Gaddam further teaches wherein causing the plurality of intrusive activity detection rules to be used to detect subsequent intrusive activities comprises: applying the trained machine learning model to a new data set characterizing a new activity; and obtaining an output of the trained machine learning model, the output indicating whether the new activity is intrusive (Gaddam, Paragraph 0108 recites “At step S716, the microservice evaluator 704 can train a plurality of machine learning models corresponding to the plurality of microservices using the system level activity data or a derivative thereof as training data. The microservice evaluator 704 may train the machine learning models to classify system level activities (including system calls and commands) from the system level activity data as either normal or abnormal. Normal system level activities may include system level activities that occur frequently during normal execution of the microservices, while abnormal system level activities may include system level activities that do not occur frequently, or are potentially hazardous. The microservice evaluator 704 may use any appropriate supervised or unsupervised machine learning model, including, as examples, one-class support vector machines and k-means clustering.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Gaddam’s microservice adaptive security hardening with Zaslavsky’s automated generation of adaptive policies from organizational data for detection of risk-related events because it offers the advantage of using machine learning techniques to create a more secure environment.
Regarding claim 19, claim 19 is directed to a similar a non-transitory computer-readable medium associated with the method of claim 9 respectively. Claim 19 is similar in scope to claim 9, respectively, and are therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a similar a non-transitory computer-readable medium associated with the method of claim 10 respectively. Claim 20 is similar in scope to claim 10, respectively, and are therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, 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 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.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/ Primary Examiner, Art Unit 2439