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
Claims 1, 5, 9-12, 14-18, and 20 have been amended
Claims 2 and 3 have been cancelled
Claims 21 and 22 are added new
Objection to claim 16 has been overcome due to Applicant’s amendments
USC 112(b) rejection for claims 1-4, 17-20 listed in the non-final office action mailed on 11/04/2025 has been overcome due to Applicant’s amendments
Claims 1 and 4-22 are pending
Priority
This application claims priority to U.S. Prov. App. No. 63/572,691, filed on April 1, 2024. Therefore, the effective filing date of this application is 04/01/2024.
Response to Arguments
Applicant’s arguments filed on 03/04/2026 have been fully considered.
With respect to the objection to claim 16. The objection has been overcome due to Applicant’s amendments.
With respect to the USC 112(b) rejection for claims 1-4, 17-20 listed in the non-final office action mailed on 11/04/2025. The rejection has been overcome due to Applicant’s amendments.
With respect to arguments of claims 1, 5, and 18. Applicant has argued that BROOKS or WAGHORN fails to teach of “applying, to the security event object with a rule processing engine separate from the rule store, each of the one or more detection rules from the group of one or more rule objects selected with the rule store based on at least the operating system configuration and the software configuration from the platform configuration of the source of the security event”. Examiner respectfully disagrees. BROOKS teaches ([BROOKS, para. 0044] “At step 209, the threat detection client 151 can launch the threat detection runtime environment 153. The threat detection runtime environment 153 can be a runtime environment that can process and execute the threat detection rules 125 on the client device 106.”) ([BROOKS, para. 0049] “At step 215, after receiving an event from the threat detection client 151, the threat detection runtime environment 153 can evaluate the event against the threat detection rules 125 to determine whether the device is compromised”) ([BROOKS, para. 0024] “The device profiles include data describing a current configuration of a client device 106. The data describing the device can include an operating system, operating system version, device manufacturer, and/or hardware features of the client device 106. The device data can be used by the threat detection service 121 to identify an appropriate set of threat detection rules to deploy to a particular client device 106.”) ([BROOKS, para. 0027] “For example, if a particular file has a particular attribute, such as a read or write permission, the device can be deemed compromised. As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”). BROOKS teaches as seen in these citations of a client device consisting of a threat detection client and a threat detection runtime environment composed in a management component separate from the data store as seen in figure 1 of BROOKS. The threat detection runtime environment can process and execute the threat detection rules. Furthermore, it is the threat detection client which detects an event on the client device and executes rules using the threat detection runtime environment. The event as recited in BROOKS is analogous to the security event object as recited in the claims. Even furthermore, BROOKS teaches of device profiles storing data describing a current configuration of a client device. The data describing the device can include an operating system and operating system version. Rules can also be applied to data pertaining to software configuration such as a particular file has a particular attribute, such as a read or write permission. Also under broadest reasonable interpretation data describing the device includes an operating system and operating system version, both of these teach an operating system configuration and the software configuration. An operating system is a system software that manages computer hardware. Therefore, data describing the operating system and selecting a rule based on the data also teaches selecting a rule based on software configuration. Therefore, BROOKS teaches this limitation. The same arguments apply for claims 5 and 18. BROOKS teaches all limitations of claims 5 and 18 and BROOKS-WAGHORN teaches all limitations of claim 1.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are:
“a plurality of rule objects for processing” in claims 1 and 18
“one or more detection rules for detecting” in claims 1 and 18
“one or more selection criteria for determining” in claims 1 and 18
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
See specification para. [0003, 0004, 0006] for functional support for “a plurality of rule objects for processing”
See specification para. [0131, 0140] for hardware support for “a plurality of rule objects for processing”
See specification para. [0104, 0105, 0111] for functional support for “one or more detection rules for detecting”
See specification para. [0086, 0131, 0140] for hardware support for “one or more detection rules for detecting”
See specification para. [0104, 0111, 0113] for functional support for “one or more selection criteria for determining”
See specification para. [0086, 0131, 0140] for hardware support for “one or more selection criteria for determining”
If applicant does not intend to have these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 4, 6-11, 14, 15, and 18-22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 18 recites the limitation " a group of one or more of the rule objects from the plurality of rule objects ". There is insufficient antecedent basis for “the rule objects” in the claims. For the purpose of examination Examiner is interpreting this limitation as "a group of one or more rule objects …”. Similar to how this limitation is recited in the limitation “one or more detection rules from the group of one or more rule objects”. Appropriate correction is required.
Claims 4 and 19-22 depend on claims 1 and 18. Therefore, they also inherit the rejection.
Claims 6-11, 14, and 15 recite the limitation “source of the event object”. However, the current amendments for claim 5 now recite of “a source of an activity”. It is unclear what is the difference between “source of the event object” and “a source of an activity”. Examiner suggests amending all instances of “… source of the event object” to “… source of the activity”. Appropriate correction is required.
Claims 14 and 15 recite the limitation “the source of the event object”. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination Examiner is interpreting this limitation as “the source of the activity”. Appropriate correction is required.
Claims 18, 21, and 22 recite the limitation “the source of the security event object”. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination Examiner is interpreting this limitation as “the source of the security event”. Appropriate correction is required.
Claims 19-22 depend on claim 18. Therefore, they also inherit the rejection.
Claims 18 and 21 recite the limitation “the type of the security event object”. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination Examiner is interpreting this limitation as “a type of the security event object”. Appropriate correction is required.
Claims 19, 20, and 22 depend on claim 18. Therefore, they also inherit the rejection.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 5-7, 9-14, 18, 19, 21, and 22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by BROOKS (US-20200092335-A1).
Regarding claim 5, BROOKS teaches “A method comprising: storing a plurality of rule objects for processing events in an event stream of an enterprise network, wherein each one of the plurality of rule objects includes: ([BROOKS, para. 0008] “The present disclosure relates to dynamically updating threat detection rules that are used by applications on a mobile device, or a client device, to detect whether the device has been compromised or modified in a manner that conflicts with an enterprise policy”) ([BROOKS, para. 0018] “The management service 115 can oversee the operation of client devices 106 enrolled as managed devices with the management service 115. In some embodiments, an entity, such as one or more enterprises, companies, or other organizations, can operate the management service 115 to oversee or manage the operation of the client devices 106”) ([BROOKS, para. 0017] “The computing environment 103 can include a data store 113. The data store 113 can include memory of the computing environment 103”) ([BROOKS, para. 0023] “The data stored in the data store 113 can include, for example, threat detection rules 125. In some implementations, the data store 113 can also house data that facilitates operation of the management service 115”) one or more detection rules for detecting activities, and ([BROOKS, para. 0026] “Threat detection rules 125 can specify how a client device 106 can be designated as compromised. A threat detection rule 125 can be defined by an administrator and identify an expected condition on the client device 106 that should be present on a client device 106.”) ([BROOKS, para. 0027] “As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”) and one or more load rules for determining, based on a platform configuration for a source of an activity, whether to apply the one or more detection rules to the events in the event stream, wherein the platform configuration includes at least an operating system configuration for the source of the activity and a software configuration for the source of the activity; ([BROOKS, para. 0024] “The device profiles include data describing a current configuration of a client device 106. The data describing the device can include an operating system, operating system version, device manufacturer, and/or hardware features of the client device 106. The device data can be used by the threat detection service 121 to identify an appropriate set of threat detection rules to deploy to a particular client device 106.”) ([BROOKS, para. 0027] “For example, if a particular file has a particular attribute, such as a read or write permission, the device can be deemed compromised. As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”) receiving one of the events as an event object in the event stream; ([BROOKS, para. 0030] “Threat detection rules 125 can be defined as event handlers that listen for a particular event triggered on the client device 106. For example, a rule specifying a particular outcome of a shell command can be defined as an event handler that listens for the result or command line output of executing a shell command.”) ([BROOKS, para. 0040] “Beginning with step 203, the threat detection client 151 can startup. The threat detection client 151 can startup upon launch or foregrounding of a management component 131 or client application 133 in which the threat detection client 151 is implemented”) ([BROOKS, para. 0041] “the threat detection client 151 can launch when an application launches, … occurrence of an event in the operating system, or any other trigger point that can be defined by the threat detection rules 125 or instrumented within the threat detection client 151.”) determining a type of the event object; ([BROOKS, para. 0042] “At step 205, the threat detection client 151 can request threat detection rules 125 from the threat detection service 121. The threat detection client 151 can authenticate the client device 106 or the user associated with the client device 106. In some instances, the threat detection service 121 can select a particular set of threat detection rules 125 based upon a device identifier, a device type, operating system, or an identity of the user.”) ([BROOKS, para. 0030] “For example, a rule specifying a particular outcome of a shell command can be defined as an event handler that listens for the result or command line output of executing a shell command.”) selecting, with a rule store that stores the plurality of rule objects, a first rule object from the plurality of rule objects based on the type of the event object and the one or more load rules in each one of the plurality of rule objects for use by a rule processing engine in determining whether to apply the one or more detection rules of each one of the plurality of rule objects; ([BROOKS, para. 0023] “The data stored in the data store 113 can include, for example, threat detection rules 125. In some implementations, the data store 113 can also house data that facilitates operation of the management service 115, such as user account data, device profiles, and compliance rules.”) ([BROOKS, para. 0042] “At step 205, the threat detection client 151 can request threat detection rules 125 from the threat detection service 121. The threat detection client 151 can authenticate the client device 106 or the user associated with the client device 106. In some instances, the threat detection service 121 can select a particular set of threat detection rules 125 based upon a device identifier, a device type, operating system, or an identity of the user.”) ([BROOKS, para. 0065] “At step 406, the threat detection service 121 can determine one or more device or user categories for the threat detection rules 125. Threat detection rules 125 can be categorized by operating system, device manufacturer, user group, or user identifier. The categories can be embedded within tags in the threat detection rules 125 that are provided to the threat detection service 121. By categorizing the threat detection rules 125, the threat detection service 151 can provide the appropriate set of threat detection rules 125 to a client device 106 making a request over the network 109.”) [Examiner’s note: BROOKS teaches of data store storing rules, the threat detection service selects rules based on based upon a device identifier, a device type, operating system, or an identity of the user. BROOKS further teaches the threat detection rules include tags which categorize the rules based on operating system, device manufacturer, user group, or user identifier. Examiner is interpreting the tags of the detection rules as one or more load rules in each one of the plurality of rule objects.] applying, to the event object with the rule processing engine separate from the rule store, a first detection rule from the first rule object selected with the rule store based on at least the operating system configuration and the software configuration from the platform configuration of the source of the activity ([BROOKS, para. 0044] “At step 209, the threat detection client 151 can launch the threat detection runtime environment 153. The threat detection runtime environment 153 can be a runtime environment that can process and execute the threat detection rules 125 on the client device 106.”) ([BROOKS, para. 0049] “At step 215, after receiving an event from the threat detection client 151, the threat detection runtime environment 153 can evaluate the event against the threat detection rules 125 to determine whether the device is compromised”) ([BROOKS, para. 0024] “The device profiles include data describing a current configuration of a client device 106. The data describing the device can include an operating system, operating system version, device manufacturer, and/or hardware features of the client device 106. The device data can be used by the threat detection service 121 to identify an appropriate set of threat detection rules to deploy to a particular client device 106.”) ([BROOKS, para. 0027] “For example, if a particular file has a particular attribute, such as a read or write permission, the device can be deemed compromised. As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”) in response to identifying one of the activities in the event object with the first detection rule from the first rule object, initiating a response to the one of the events. ([BROOKS, para. 0049] “The event handler can determine, based upon the definition of the rule in the threat detection rules 125, whether the response indicates that the client device 106 is compromised”) ([BROOKS, para. 0050] “At step 216, the threat detection runtime environment 153 can transmit a notification that the device is compromised to the threat detection service 121, the management component 131, or management service 115. In some instances, the threat detection service 121 can take action in response to notification of the compromised device automatically by consulting a rules engine. In other instances, a remedial action can be taken by an administrative user”).
Regarding claim 6, BROOKS teaches all limitations of claim 5. BROOKS further teaches “wherein the type of the event object includes a source of the event object.” ([BROOKS, para. 0042] “At step 205, the threat detection client 151 can request threat detection rules 125 from the threat detection service 121. The threat detection client 151 can authenticate the client device 106 or the user associated with the client device 106. In some instances, the threat detection service 121 can select a particular set of threat detection rules 125 based upon a device identifier, a device type, operating system, or an identity of the user.”)
Regarding claim 7, BROOKS teaches all limitations of claim 6. BROOKS further teaches “wherein the source of the event object includes a compute instance associated with the enterprise network.” ([BROOKS, para. 0018] “The management service 115 can oversee the operation of client devices 106 enrolled as managed devices with the management service 115. In some embodiments, an entity, such as one or more enterprises, companies, or other organizations, can operate the management service 115 to oversee or manage the operation of the client devices 106 of its employees”).
Regarding claim 9, BROOKS teaches all limitations of claim 5. BROOKS further teaches “wherein the type of the event object includes the platform configuration for a source of the event object.” ([BROOKS, para. 0024] “The device profiles include data describing a current configuration of a client device 106. The data describing the device can include an operating system, operating system version, device manufacturer, and/or hardware features of the client device 106. The device data can be used by the threat detection service 121 to identify an appropriate set of threat detection rules to deploy to a particular client device 106.”) ([BROOKS, para. 0042] “At step 205, the threat detection client 151 can request threat detection rules 125 from the threat detection service 121. The threat detection client 151 can authenticate the client device 106 or the user associated with the client device 106. In some instances, the threat detection service 121 can select a particular set of threat detection rules 125 based upon a device identifier, a device type, operating system, or an identity of the user.”).
Regarding claim 10, BROOKS teaches all limitations of claim 9. BROOKS further teaches “wherein the platform configuration includes the operating system configuration for the source of the event object.” ([BROOKS, para. 0042] “At step 205, the threat detection client 151 can request threat detection rules 125 from the threat detection service 121. The threat detection client 151 can authenticate the client device 106 or the user associated with the client device 106. In some instances, the threat detection service 121 can select a particular set of threat detection rules 125 based upon a device identifier, a device type, operating system, or an identity of the user.”).
Regarding claim 11, BROOKS teaches all limitations of claim 9. BROOKS further teaches “wherein the platform configuration includes the software configuration for the source of the event object.” ([BROOKS, para. 0027] “For example, if a particular file has a particular attribute, such as a read or write permission, the device can be deemed compromised. As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”).
Regarding claim 12, BROOKS teaches all limitations of claim 5. BROOKS further teaches “wherein the one of the events includes a malicious activity, and wherein initiating the response includes initiating a remediation of the malicious activity.” ([BROOKS, para. 0050] “At step 216, the threat detection runtime environment 153 can transmit a notification that the device is compromised to the threat detection service 121, the management component 131, or management service 115. In some instances, the threat detection service 121 can take action in response to notification of the compromised device automatically by consulting a rules engine. In other instances, a remedial action can be taken by an administrative user”).
Regarding claim 13, BROOKS teaches all limitations of claim 12. BROOKS further teaches “wherein initiating the remediation includes transmitting a notification of the malicious activity to a threat management facility for the enterprise network.” ([BROOKS, para. 0050] “At step 216, the threat detection runtime environment 153 can transmit a notification that the device is compromised to the threat detection service 121, the management component 131, or management service 115. In some instances, the threat detection service 121 can take action in response to notification of the compromised device automatically by consulting a rules engine. In other instances, a remedial action can be taken by an administrative user”).
Regarding claim 14, BROOKS teaches all limitations of claim 12. BROOKS further teaches “wherein initiating the remediation includes initiating a threat response to the malicious activity by the source of the event object.” ([BROOKS, para. 0051] “The threat detection rule 125 corresponding to the detected condition can specify a remedial action. A remedial action can involve disabling access to the client application 133 in which the threat detection client 151 and threat detection runtime environment 153 are running. The client application 133 can be instrumented to disable access to its features if the threat detection runtime environment 153 reports a compromised state to the threat detection client 151. By disabling applications on an application-by-application basis, some applications can continue to execute even when the device is compromised, whereas other applications can be disabled.”).
Regarding claim 18, this claim recites of a system that recites features of method claim 5. Therefore, claim 18 is rejected in a similar manner as in the rejection of claim 5. BROOKS further teaches “… a rule processing engine configured by computer executable code stored in a non-transitory computer readable medium that, when executing on one or more processors, ([BROOKS, para. 0068] “The client devices 106 or devices making up the computing environment 103 can include at least one processor circuit, for example, having a processor and at least one memory device, both of which are coupled to a local interface, respectively.”) … in response to at least one of the one or more detection rules identifying one of the malicious activities, generating a notification of a detection of malicious activity, and transmitting the notification to a threat management facility for the enterprise network. ([BROOKS, para. 0050] “At step 216, the threat detection runtime environment 153 can transmit a notification that the device is compromised to the threat detection service 121, the management component 131, or management service 115. In some instances, the threat detection service 121 can take action in response to notification of the compromised device automatically by consulting a rules engine. In other instances, a remedial action can be taken by an administrative user”).
Regarding claim 19, BROOKS teaches all limitations of claim 18. BROOKS further teaches “wherein the event stream includes a plurality of security event objects from a plurality of compute instances in the enterprise network managed by the threat management facility.” ([BROOKS, para. 0014] “With reference to FIG. 1, shown is an example of a networked environment 100. The networked environment 100 can include a computing environment 103 and one or more client devices 106 in communication with one another over a network 109”) ([BROOKS, para. 0018] “The management service 115 can oversee the operation of client devices 106 enrolled as managed devices with the management service 115. In some embodiments, an entity, such as one or more enterprises, companies, or other organizations, can operate the management service 115 to oversee or manage the operation of the client devices 106 of its employees”).
Regarding claim 21, BROOKS teaches all limitations of claim 18. BROOKS further teaches “wherein the type of the security event object includes the source of the security event object.” ([BROOKS, para. 0042] “At step 205, the threat detection client 151 can request threat detection rules 125 from the threat detection service 121. The threat detection client 151 can authenticate the client device 106 or the user associated with the client device 106. In some instances, the threat detection service 121 can select a particular set of threat detection rules 125 based upon a device identifier, a device type, operating system, or an identity of the user.”)
Regarding claim 22, BROOKS teaches all limitations of claim 21. BROOKS further teaches “wherein the source of the security event object includes a compute instance associated with the enterprise network.” ([BROOKS, para. 0008] “The present disclosure relates to dynamically updating threat detection rules that are used by applications on a mobile device, or a client device, to detect whether the device has been compromised or modified in a manner that conflicts with an enterprise policy”).
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 1 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over BROOKS (US-20200092335-A1) in view of WAGHORN (US-20190081963-A1), hereinafter BROOKS-WAGHORN.
Regarding claim 1, BROOKS teaches “A computer program product comprising computer executable code embodied in a non-transitory computer readable medium that, when executing on one or more computing devices associated with an enterprise network, causes the one or more computing devices to perform steps of: ([BROOKS, para. 0008] “The present disclosure relates to dynamically updating threat detection rules that are used by applications on a mobile device, or a client device, to detect whether the device has been compromised or modified in a manner that conflicts with an enterprise policy”) ([BROOKS, para. 0018] “The management service 115 can oversee the operation of client devices 106 enrolled as managed devices with the management service 115. In some embodiments, an entity, such as one or more enterprises, companies, or other organizations, can operate the management service 115 to oversee or manage the operation of the client devices 106”) ([BROOKS, para. 0030] “Threat detection rules 125 can be defined as event handlers that listen for a particular event triggered on the client device 106.”) ([BROOKS, para. 0017] “The computing environment 103 can include a data store 113. The data store 113 can include memory of the computing environment 103”) ([BROOKS, para. 0018] “The components executed on the computing environment 103 can include, for example, the management service 115, the threat detection service 121, as well as other applications”) storing a plurality of rule objects for processing security events in an event stream of the enterprise network, wherein each one of the plurality of rule objects includes: ([BROOKS, para. 0023] “The data stored in the data store 113 can include, for example, threat detection rules 125. In some implementations, the data store 113 can also house data that facilitates operation of the management service 115, such as user account data, device profiles, and compliance rules”) one or more detection rules for detecting malicious activities, and ([BROOKS, para. 0026] “Threat detection rules 125 can specify how a client device 106 can be designated as compromised. A threat detection rule 125 can be defined by an administrator and identify an expected condition on the client device 106 that should be present on a client device 106.”) ([BROOKS, para. 0027] “As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”) one or more selection criteria for determining, based on a platform configuration for a source of a security event, whether to load the one or more detection rules for use by an event processing service to evaluate the security event … wherein the platform configuration includes at least an operating system configuration and a software configuration for the source of the security event; ([BROOKS, para. 0024] “The device profiles include data describing a current configuration of a client device 106. The data describing the device can include an operating system, operating system version, device manufacturer, and/or hardware features of the client device 106. The device data can be used by the threat detection service 121 to identify an appropriate set of threat detection rules to deploy to a particular client device 106.”) ([BROOKS, para. 0027] “For example, if a particular file has a particular attribute, such as a read or write permission, the device can be deemed compromised. As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”) receiving one of the security events in the event stream at the event processing service as a security event object; ([BROOKS, para. 0030] “Threat detection rules 125 can be defined as event handlers that listen for a particular event triggered on the client device 106. For example, a rule specifying a particular outcome of a shell command can be defined as an event handler that listens for the result or command line output of executing a shell command.”) ([BROOKS, para. 0040] “Beginning with step 203, the threat detection client 151 can startup. The threat detection client 151 can startup upon launch or foregrounding of a management component 131 or client application 133 in which the threat detection client 151 is implemented.”) ([BROOKS, para. 0041] “the threat detection client 151 can launch when an application launches, restores from a sleep state, upon expiration of a timer, occurrence of an event in the operating system, or any other trigger point that can be defined by the threat detection rules 125 or instrumented within the threat detection client 151”) determining the platform configuration for the source of the security event object; selecting, with a rule store that stores the plurality of rule objects a group of one or more of the rule objects from the plurality of rule objects based on the platform configuration for the source of the security event object and the one or more selection criteria in each one of the plurality of rule objects for determining whether to load the one or more detection rules of each one of the plurality of rule objects; ([BROOKS, para. 0023] “The data stored in the data store 113 can include, for example, threat detection rules 125. In some implementations, the data store 113 can also house data that facilitates operation of the management service 115, such as user account data, device profiles, and compliance rules.”) ([BROOKS, para. 0042] “At step 205, the threat detection client 151 can request threat detection rules 125 from the threat detection service 121. The threat detection client 151 can authenticate the client device 106 or the user associated with the client device 106. In some instances, the threat detection service 121 can select a particular set of threat detection rules 125 based upon a device identifier, a device type, operating system, or an identity of the user.”) ([BROOKS, para. 0065] “At step 406, the threat detection service 121 can determine one or more device or user categories for the threat detection rules 125. Threat detection rules 125 can be categorized by operating system, device manufacturer, user group, or user identifier. The categories can be embedded within tags in the threat detection rules 125 that are provided to the threat detection service 121. By categorizing the threat detection rules 125, the threat detection service 151 can provide the appropriate set of threat detection rules 125 to a client device 106 making a request over the network 109.”) [Examiner’s note: BROOKS teaches of data store storing rules, the threat detection service selects rules based on based upon a device identifier, a device type, operating system, or an identity of the user. BROOKS further teaches the threat detection rules include tags which categorize the rules based on operating system, device manufacturer, user group, or user identifier. Examiner is interpreting the tags of the detection rules as a selection criteria in each one of the plurality of rule objects.] applying, to the security event object with a rule processing engine separate from the rule store, each of the one or more detection rules from the group of one or more rule objects selected with the rule store based on at least the operating system configuration and the software configuration from the platform configuration of the source of the security event; ([BROOKS, para. 0044] “At step 209, the threat detection client 151 can launch the threat detection runtime environment 153. The threat detection runtime environment 153 can be a runtime environment that can process and execute the threat detection rules 125 on the client device 106.”) ([BROOKS, para. 0049] “At step 215, after receiving an event from the threat detection client 151, the threat detection runtime environment 153 can evaluate the event against the threat detection rules 125 to determine whether the device is compromised”) ([BROOKS, para. 0024] “The device profiles include data describing a current configuration of a client device 106. The data describing the device can include an operating system, operating system version, device manufacturer, and/or hardware features of the client device 106. The device data can be used by the threat detection service 121 to identify an appropriate set of threat detection rules to deploy to a particular client device 106.”) ([BROOKS, para. 0027] “For example, if a particular file has a particular attribute, such as a read or write permission, the device can be deemed compromised. As one example, the threat detection rule 125 can specify that if a file such as “Superuser.apk” is present on an Android device in a directory where applications are stored, the client device 106 is compromised.”) in response to identifying one of the malicious activities in the security event object with the one or more detection rules from the group of one or more rule objects, generating a notification of malicious activity; and transmitting the notification to a threat management facility for the enterprise network. ([BROOKS, para. 0049] “The event handler can determine, based upon the definition of the rule in the threat detection rules 125, whether the response indicates that the client device 106 is compromised.”) ([BROOKS, para. 0050] “At step 216, the threat detection runtime environment 153 can transmit a notification that the device is compromised to the threat detection service 121, the management component 131, or management service 115. In some instances, the threat detection service 121 can take action in response to notification of the compromised device automatically by consulting a rules engine. In other instances, a remedial action can be taken by an administrative user.”) ([BROOKS, para. 0052] “the remedial action could involve generating a warning message for a user in a notification on the client device 106 that a compromised condition exists on the client device 106. … a remedial action can be initiated remotely by an administrator after receiving a notification about a detected compromised condition.”).
However, BROOKS does not teach “… evaluate the security event for potential malware;”.
In analogous teaching WAGHORN teaches “… evaluate the security event for potential malware;” ([WAGHORN, para. 0021] “The threat management facility 100 may provide an enterprise facility 102 protection from computer-based malware”) ([WAGHORN, para. 0043] “The detection techniques facility 130 may include monitoring the enterprise facility 102 network or endpoint devices, such as by monitoring streaming data through the gateway, across the network, through routers and hubs, and the like.”) ([WAGHORN, para. 0088] “A security product 332 may execute on the endpoint 310 to detect a security event on the endpoint 310, which may act as the beacon or trigger event for the system 300. The security product 332 may use techniques such as signature-based and behavioral-based malware detection”).
Thus, given the teaching of WAGHORN, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of malware by WAGHORN into a teaching of storing and applying rules by BROOKS. One of ordinary skill in the art would have been motivated to do so because WAGHORN recognizes the need to improve event detection ([WAGHORN, para. 0003] “There remains a need for improved techniques for real-time, event-based detection of malware and other complex computational events or contexts.”) ([WAGHORN, para. 0004] “An event handler implements a state machine or similar construct for processing of complex event chains as incremental events are detected. This approach advantageously limits processing to monitoring for and responding to a next event in a sequence of events, and supports complex event detection in a manner that scales efficiently in time and computation”).
Regarding claim 4, BROOKS-WAGHORN teach all limitations of claim 1. BROOKS further teaches “wherein the source of the security event includes a compute instance associated with the enterprise network.” ([BROOKS, para. 0008] “The present disclosure relates to dynamically updating threat detection rules that are used by applications on a mobile device, or a client device, to detect whether the device has been compromised or modified in a manner that conflicts with an enterprise policy”).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over BROOKS (US-20200092335-A1) in view of SINGLA (US-20140165200-A1).
Regarding claim 8, BROOKS teaches all limitations of claim 6. However, BROOKS does not teach “wherein the source of the event object includes a firewall associated with the enterprise network.”.
In analogous teaching SINGLA teaches “wherein the source of the event object includes a firewall associated with the enterprise network.” ([SINGLA, para. 0026] “The typical sources of security events are common network security devices, such as firewalls, intrusion detection systems and operating system logs. Agents 12a-n can collect events from any source that produces event logs or messages”) ([SINGLA, para. 0040] “Since each distributed rule is associated with a master manager, and each master manager provides a complete picture of security activity with respect to that rule, the group of managers acting in a master capacity provides a complete, enterprise-wide picture of security activity for all distributed rules over network security system 100.”).
Thus, given the teaching of SINGLA, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of source of the event object includes a firewall by SINGLA into a teaching of storing and applying rules by BROOKS. One of ordinary skill in the art would have been motivated to do so because SINGLA recognizes the need to efficiently monitor events ([SINGLA, para. 0014] “Security systems receive events from potentially thousands of sources.”) ([SINGLA, para. 0026] “Agents 12 a-n are software programs, which are machine readable instructions, that provide efficient, real-time (or near real-time) local event data capture and filtering from a variety of network security devices and/or applications”).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over BROOKS (US-20200092335-A1) in view of COULTER (US-20230252140-A1).
Regarding claim 15, BROOKS teaches all limitations of claim 12. However, BROOKS does not teach “wherein initiating the remediation includes at least one of quarantining the source of the event object, updating security software for the source of the event object, performing a scan of the source of the event object, and requesting data from a data recorder for a local security agent executing on the source of the event object.”.
In analogous teaching COULTER teaches “wherein initiating the remediation includes at least one of quarantining the source of the event object, updating security software for the source of the event object, performing a scan of the source of the event object, and requesting data from a data recorder for a local security agent executing on the source of the event object.” ([COULTER, para. 0061] “The method 300 can be executed by a system, such as the system 10 of FIG. 1. The method 300 includes receiving, from a plurality of sources, data associated with a plurality of events at the plurality of sources … the fine sorted data defining a plurality of distances between data point of the fine sorted data, at 314; based on the fine sorted data, identifying an anomalous event from the plurality of events, at 316; quarantining an artifact associated with an event from the plurality of events”).
Thus, given the teaching of COULTER, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of quarantining by COULTER into a teaching of storing and applying rules by BROOKS. One of ordinary skill in the art would have been motivated to do so because COULTER recognizes the need to detect anomalous events ([COULTER, para. 0003] “Thus, there is a need for dynamically determining computer events that are atypical (e.g., anomalous, uncommon, different, etc.) to allow for the identification and storage of events that may indicate a potential security incident, without overwhelming computing resources and is capable of scaling to larger groups of data”).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over BROOKS (US-20200092335-A1) in view of VERMA (US-20250247400-A1).
Regarding claim 16, BROOKS teaches all limitations of claim 5. However, BROOKS does not teach “wherein the event object includes a JavaScript Object Notation (JSON) object.”
In analogous teaching VERMA teaches “wherein the event object includes a JavaScript Object Notation (JSON) object.” ([VERMA, para. 0043] “Event data in a structured format may include data that is organized into a recognized format. The structured event log may include event data in a Javascript Object Notation (JSON) format”).
Thus, given the teaching of VERMA, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of JSON object by VERMA into a teaching of storing and applying rules by BROOKS. One of ordinary skill in the art would have been motivated to do so because VERMA recognizes the need to efficiently analyze events ([VERMA, para. 0025] “The event log analytics system can then analyze the converted event log data in the predefined format to identify alternative configurations that are more efficient. As a consequence, computing resources used by the computing network are reduced and computing resource usage is more efficient”).
Claims 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over BROOKS (US-20200092335-A1) in view of JAIN (US-20210218758-A1).
Regarding claim 17, BROOKS teaches all limitations of claim 5. However, BROOKS does not teach “further comprising: selecting a group of two or more of the plurality of rule objects based on the type of the event object; and applying the one or more detection rules from the group of two or more of the plurality of rule objects to the event object.”
In analogous teaching JAIN teaches “further comprising: selecting a group of two or more of the plurality of rule objects based on the type of the event object; and applying the one or more detection rules from the group of two or more of the plurality of rule objects to the event object.” ([JAIN, para. 0004] “The identified set of contextual attributes are provided to an intrusion detection system (IDS) engine that executes on the host computer to enforce several IDS rules. The IDS engine uses the identified set of contextual attributes to identify a subset of the IDS rules that are relevant to the received data message and that do not include all of the IDS rules enforced by the IDS engine.”) ([JAIN, para. 0055] “After identifying the contextual attribute set for a data message flow, the service engine 230 in some embodiments performs its service operation based on service rules that are stored in the context-based service rule storage 240”) ([JAIN, para. 0073] “Examples of contextual attributes include the source application name, the application version, traffic type identifier, resource consumption, threat level, user ID, group ID, etc.”).
Thus, given the teaching of JAIN, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of selecting a group of two or more of the rule objects by JAIN into a teaching of storing and applying rules by BROOKS. One of ordinary skill in the art would have been motivated to do so because JAIN recognizes the need to efficiently apply rules ([JAIN, para. 0019] “The above-described method provides an efficient method for performing IDS operations, as it allows the IDS engine to only examine IDS rules that are applicable to a data message flow, while ignoring a potentially large number of other IDS rules that are irrelevant to the data message flow.”).
Regarding claim 20, BROOKS teaches all limitations of claim 18. However, BROOKS does not teach “wherein each one of the plurality of rule objects includes one or more refinement rules that provide instructions for additional processing of one of the security events after the detection of the malicious activity is made based on the at least one of the one or more detection rules.”.
In analogous teaching JAIN teaches “wherein each one of the plurality of rule objects includes one or more refinement rules that provide instructions for additional processing of one of the security events after the detection of the malicious activity is made based on the at least one of the one or more detection rules.” ([JAIN, para. 0031] “After identifying a matching IDS rule, the IDS engine performs (at 125) an IDS operation based on the action parameter of the matching IDS rule. … In addition to dropping the data message, the IDS rules can also specify alert and log actions instead of or in conjunction with the dropping of the data message”) ([JAIN, para. 0033] “The log action in some embodiments records similar data (e.g., signature/rule identifier, five tuple identifier of the flow and contextual attributes of the flow), but stores this data in a log file that is sent to or retrieved by a server (e.g., a controller) at a later time for the server to analyze the detected intrusion event(s).”).
The same motivation to modify BROOKS with JAIN as in the rejection of claim 17 applies.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
LESPERANCE (US-20230239315-A1): This prior art teaches of a data network is configured to pass data messages between hosted devices. A plurality of network sensors are configured to: sense operations of the data network; generate event objects that record the operations of the data network; and store an event-timestamp that records a first time at which the operations were sensed. A datastore is configured to: store the event objects in a bulk-memory; and store a reception-timestamp that records a second time at which the event object was received for storage. A rules-scheduler is configured to: identify at least one security-rule to be run, the security-rule specifying a time-length; identify a time-window having a beginning-time before the event-timestamp and an end-time after the event-timestamp; and cause the security rule to be run on the matching event objects.
MILAZZO (US-11012472-B2): This prior art teaches of security rules management mechanisms are provided. A cognitive computing system of the security rules management system ingests natural language content, from one or more corpora, describing features of security attacks, and ingests security event log data from a monitored computing environment. The cognitive computing system processes the natural language content from the one or more corpora and the security event log data to identify attack characteristics applicable to the security event log data. A security rule query engine evaluates existing security rules present in a security rules database to determine if any existing security rule addresses the attack characteristics. In response to the evaluation indicating that no existing security rule addresses the attack characteristics, a security rule generator automatically generates a new security rule based on the attack characteristics, which is then deployed to the monitored computing environment.
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 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 AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
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, ALI SHAYANFAR can be reached at (571) 270-1050. 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.
/A.A./
05/27/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights