Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kleynhans (US 20170279678 A1) in view of Proctor (US 8418135 B2), Speeter (US 20060143144 A1) and Klonowski (US 20200311261 A1).
Regarding claim 1, Kleynhans teaches:
A method comprising: (Claim 11. In a computing environment implementing configuration layers for containerized configurations, a method of configuring a node, the method comprising: )
retrieving, by a processing device, new configuration data of a containerized computing cluster,. ([0014] Embodiments described herein can implement a containerized based configuration approach. In a containerized based configuration approach, various hierarchical configuration layers are used to configure entities. [0029] Embodiments may include a configuration engine 208. The configuration engine 208 can provides a dynamic, unified view of multiple configurations. The configuration engine 208 manages configuration changes for any configuration layer, ensuring the appropriate configuration layers reflect these changes. The configuration engine 208 further provides a filter manger (such as filter manager 120 illustrated in FIG. 1) with operating system-specific filters to bridge configuration gaps (e.g. different operating system versions or types). [0030] The configuration engine 208 may be configured to inspect one or more configuration stores 202 and determine the appropriate configuration data sets for a given set of configuration layers (e.g. based on policy, configuration, available hardware, operating system version, location, etc.).)
and wherein the new configuration data reflects a change of a configuration of the containerized computing cluster with respect to a previous configuration of the containerized computing cluster. ([0050] The following illustrates how configuration changes propagate across layers in a mixed operating system environment. Configurations may be changed through an API, through direct reads/writes, through policy received from an MDM server or LDAP server. For example, in the event that a first operating system configuration layer, such as a configuration layer for Windows® available from Microsoft corporation of Redmond Wash., changes impacting a second operating system configuration layer such as a configuration layer for Unix®, the configuration engine 208 monitors the configuration map between the layers for changes.)
storing the new configuration data into a working memory, wherein the working memory is in a stateful session. ([0024] FIG. 1 further illustrates a Host Configuration Store 106. The Host Configuration Store 106 maintains a consistent configuration for the host operating system 100. This may be implemented as a database, as one or more configuration files, in a configuration graph, etc. It may reside on disk, in memory or a combination of both.)
extracting the fact from the new configuration data. ([0034] The configuration engine 208 may be configured to provide location. The assignment and tracking of an operating system instance and to what configuration layer(s) and location(s) it is assigned can be managed by the configuration engine 208. This may include efficient access to configuration data as configuration settings are read, updated and deleted. The configuration engine 208 may embed this location information in the configuration layers, in configuration store 202, or maintain additional data structures to track this.)
Kleynhans does not appear to explicitly teach: creating, for a working memory, a stateful session that provides a time period for evaluating a fact.
However, Proctor teaches: col 3, line 10-35. Overview of a Rule As mentioned above, a rule is a logical construct for describing the operations, definitions, conditions, and/or constraints that apply to some predetermined data to achieve a goal. In some embodiments, a rule is in the form of a two-part structure with a Left Hand Side (LHS) and a Right Hand Side (RHS). Further, a rule may have additional attributes, such as salience, agenda group, auto-focus, activation group, no-loop, duration, etc. In some embodiments, the LHS of a rule includes Conditional Elements (CE) and Patterns, which are used to facilitate the encoding of propositional and first order logic. The term Pattern is used to indicate Constraints on a fact type. Some examples of CEs include and, or, not, exist, forall, accumulate, etc. Some examples of Constraints include Literal Constraint, Bound Variable Constraint, Return Value, Predicate, etc. As facts are asserted and modified in a working memory, a rule engine matches the facts against the LHS conditions of the rules. When all the LHS conditions of a rule are met and determined to be true, the rule and those matched facts are activated. When a rule is activated, the rule is placed onto an agenda of a rule engine for potential execution, where the Actions of the RHS of the rule, called the Consequence, are executed. col 6, line 36-56 Working Memory In some embodiments, a working memory is the main class for using the rule engine at runtime. The working memory holds references to data (i.e., facts) that has been "asserted" into the working memory (until retracted). Further, the working memory is the place where the interaction with the application occurs. Working memories are stateful objects. They may be shortlived, or longlived. If a rule engine is executed in a stateless manner, then a RuleBase object is used to create a new working memory for each session, and the working memory is discarded when the session is finished. Note that creating a working memory is typically a low cost operation. In an alternative approach, a working memory is kept around for a longer time (such as a conversation) and kept updated with new facts. To dispose of a working memory, a dispose( ) method may be used. The dispose( ) method removes the reference from the parent RuleBase. Since this is a weak reference (as discussed above in the section on RuleBase), the reference would eventually be garbage collected. The term working memory action may refer to assertions, retractions, and/or modifications of facts in the working memory.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kleynhans and Proctor before them, to include Proctor’s stateful working memory Kleynhans’s container configuration system. This would result in a system with a working memory session that persist for a defined amount of time and provides a context to evaluate facts.
Kleynhans does not appear to explicitly teach: evaluating a rule against the fact during the time period, wherein the rule specifies a condition and an operation to perform if the condition is satisfied; and responsive to determining that the condition specified by the rule matches the fact, performing the operation specified by the rule, wherein the operation comprises a notification regarding a change of a state of the containerized computing cluster.
However, Speeter teaches: [0149] A rules engine 504 interprets and applies rules against the known attributes of the servers contained in the configuration database. The rules engine may be used to derive relationships between different configuration elements, and by extension, different computers, software components, or data. [0215] FIG. 14 is a generalized block diagram of a screen 1400 to select and run rules and rule sets. A target is selected in host target entry field 1401. Host target data is selected in host target entry field 1402. The selected host target data may be the configuration data of a given target host, or may be another data set. For example, compliance with rules may be performed by running a rule set against saved versions of configuration data. In systems which take regular snapshots of configuration data, as the present system may be used, this provides for both checking of historical compliance and troubleshooting of problems in that may be impacted by miss-configuration of computer systems. [0231] If at step 1506 the configuration management server determines the rule has not been satisfied, the configuration management server proceeds to step 1508 and records the failure of the rule in the configuration database. Additionally, the configuration management server may send an alert or take other action based upon the failure of the rule.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kleynhans and Speeter before them, to include Speeter’s rule engine in Kleynhans’s container configuration system. One would have been motivated to make such a combination to more efficiently automate the detection of configuration state changes and trigger responsive actions such as notifications.
Kleynhans does not appear to explicitly teach and stopping executing the rule in response to receiving a halt command.
However, Klonowski teachesa known behavior of : [0019] Accordingly, the present disclosure provides systems and methods for behavioral threat detection. In an example, a rule is used to identify a specific behavior, thereby determining that a set of circumstances is malicious, is not malicious, or should be subject to additional scrutiny, among other determinations. A rule comprises a set of rule instructions relating to computations, comparisons, and other instructions that form a computer programming language. In some instances, the rule instructions relate to one or more events, such that computations, comparisons, and other instructions may be applied to events and, in some instances, such that continued execution of the rule instructions is predicated on the occurrence (or lack thereof) of one or more events. In examples, a rule may be executed using a rule virtual machine, such that the rule virtual machine maintains a state for the rule (e.g., the current rule instruction in the set of instructions, values of one or more variables, a last event that was matched, etc.). Events are queued in an event queue for the rule virtual machine, such that the events may be evaluated using the rule for which the virtual machine is instantiated. If a matching event is identified (e.g., a positive match, a negative match, etc.), execution of the rule instructions continues until another “wait” instruction to wait for an event is encountered. In some instances, a rule may alternatively or additionally comprise a “halt” instruction, which may cause execution of the rule to halt, thereby indicating that the rule was or was not matched. In other instances, a halt instruction may indicate that additional analysis should be performed. Thus, as used herein, a rule virtual machine is a complex finite state machine used to execute a rule and arrive at a determination accordingly. [0031] After a rule virtual machine is initialized, the virtual machine management engine 114 executes rule instructions in the rule virtual machine. In examples, execution comprises identifying a thread from a virtual machine execution thread pool with which to execute the rule instructions. During execution, a wait or halt rule instruction may eventually be encountered. For instance, upon encountering a wait rule instruction, a wait packet is generated and added to a wait packet queue for the rule virtual machine. In examples, the wait packet comprises information relating to an event for which the set of rule instructions is waiting, including, but not limited to, an identifier associated with a specific event and/or one or more parameters relating to the event (e.g., a specific value, a type of value, a set of values, etc.), among other information. In examples, the wait rule instruction may relate to multiple events, such that a wait packet for each event is generated and added to the wait packet queue. In another example, it will be appreciated that a single wait packet relating to multiple events may be used. As described above, a wait rule instruction may specify the presence of one or more events and/or the absence of one or more events. Execution of the rule virtual machine may then be paused, such that the rule virtual machine is in a waiting execution state. See also [0034], [0049] and [0080]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kleynhans and Klonowski before them, to include Klonowski’s halt instruction functionality in Kleynhans’s container configuration system. One would have been motivated to make such a combination to provide termination of rules once the rule determination is reached avoiding continued rule processing.
Regarding claim 2, Kleynhans teaches:
The method of claim 1, further comprising: detecting a change in configuration data of the containerized computing cluster in a data store of the containerized computing cluster. ([0024] FIG. 1 further illustrates a Host Configuration Store 106. The Host Configuration Store 106 maintains a consistent configuration for the host operating system 100. This may be implemented as a database, as one or more configuration files, in a configuration graph, etc. It may reside on disk, in memory or a combination of both. [0029] Embodiments may include a configuration engine 208. The configuration engine 208 can provides a dynamic, unified view of multiple configurations. The configuration engine 208 manages configuration changes for any configuration layer, ensuring the appropriate configuration layers reflect these changes. The configuration engine 208 further provides a filter manger (such as filter manager 120 illustrated in FIG. 1) with operating system-specific filters to bridge configuration gaps (e.g. different operating system versions or types). Note that the “configuration engine” is described as one component for illustrative purposes. In any given implementation it could be composed of multiple components and/or sub-components; it could also be packaged and stored in these pieces. In some embodiments, the configuration engine may be implemented in a distributed fashion, with portions of the configuration engine stored at various different machines in different locations.)
Regarding claim 3, Kleynhans teaches:
The method of claim 2, wherein retrieving the new configuration data is performed responsive to detecting the change in the configuration data of the containerized computing cluster in the data store. ([0050] The following illustrates how configuration changes propagate across layers in a mixed operating system environment. Configurations may be changed through an API, through direct reads/writes, through policy received from an MDM server or LDAP server. For example, in the event that a first operating system configuration layer, such as a configuration layer for Windows® available from Microsoft corporation of Redmond Wash., changes impacting a second operating system configuration layer such as a configuration layer for Unix®, the configuration engine 208 monitors the configuration map between the layers for changes.[0051] For example, if the change occurs in a Windows® configuration layer, the configuration engine 208 uses the Windows® registry database API to read the changed value and location and re-map the change onto the Unix® configuration layer. Note that the configuration engine 208 may also read directly from the registry database in some offline scenarios. The mapping is implemented by identifying the Unix® configuration file name and location, parsing the file and finding the equivalent configuration data. The changed configuration data is then written to that file. With some configuration changes, the Unix® daemon may need to be restarted to consume the change)
Regarding claim 4, Kleynhans teaches:
The method of claim 1, wherein the new configuration data is retrieved from a data store of the containerized computing cluster. ([0024] FIG. 1 further illustrates a Host Configuration Store 106. The Host Configuration Store 106 maintains a consistent configuration for the host operating system 100. This may be implemented as a database, as one or more configuration files, in a configuration graph, etc. It may reside on disk, in memory or a combination of both.[0025] FIG. 1 further illustrates a Host Configuration Engine 118. The Host Configuration Engine 118 filters the host configuration store 106 for the guest operating system 114, providing the core configuration of the guest operating system 114. The Host Configuration Engine 118 may contain a filter manager 120 that filters host configuration based on operating system type and host configuration store type. In some embodiments, a database filter 122 and a file filter 124 are included.)
Regarding claim 5, Kleynhans teaches:
The method of claim 4, wherein retrieving the new configuration data is performed responsive to determining that the new configuration data in the data store satisfies a threshold condition. ([0030] The configuration engine 208 may be configured to inspect one or more configuration stores 202 and determine the appropriate configuration data sets for a given set of configuration layers (e.g. based on policy, configuration, available hardware, operating system version, location, etc.). See also [0087])
Regarding claim 6, Kleynhans teaches:
The method of claim 1, wherein the new configuration data of the containerized computing cluster comprises at least one of a desired state or a current state of the containerized computing cluster. ([0034] The configuration engine 208 may be configured to provide location. The assignment and tracking of an operating system instance and to what configuration layer(s) and location(s) it is assigned can be managed by the configuration engine 208. This may include efficient access to configuration data as configuration settings are read, updated and deleted. The configuration engine 208 may embed this location information in the configuration layers, in configuration store 202, or maintain additional data structures to track this. [0037] The configuration engine 208 may be configured to provide down-stack mutability. In particular, the configuration engine 208 may include the ability to determine when to write to a local, isolated copy-on-write store, and when to write to an underlying configuration layer. In particular, embodiments may be able to change a configuration for an OS kernel by changing a local configuration layer and/or by changing an underlying configuration layer. For example, assume that an OS kernel is running using the configuration layer 212-1-1. Embodiments could update the OS kernel by performing a write to the configuration layer 212-1-1, the configuration 212-1 and/or the configuration layer 212-H. See also [0093])
Regarding claim 7, Kleynhans teaches:
The method of claim 1, wherein the operation comprises a corrective operation with respect to the change of the state of the containerized computing cluster. (0095] The method 500 may be practiced where the first configuration layer is modified as a result of an operating system kernel running on one or more of the other configuration layers initiating modification of the first configuration layer. For example, the virtual machine 214-3 may be running on the guest configuration layer 212-1-1 and hosting applications for compatibility a reasons. The virtual machine 214-3 may determine that it needs additional memory resources to continue hosting the applications. The virtual machine 214-3 can indicate to the host configuration layer 212-H that configuration settings should be updated to provide the needed additional memory resources. In some embodiments, the virtual machine 214-3 may be given sufficient permissions to cause the modifications to configuration settings to occur at the host configuration layer 212-H, without any oversight from the host. In other embodiments the virtual machine 214-3 may need to request and authority indicating that the host configuration layer 212-H needs to update its configuration settings. The authority has the ability to grant or deny the request from the guest configuration layer virtual machine 214-3. See also [0096-0097])
Regarding claim 8, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Kleynhans also teaches:
A system comprising: a memory; a processing device coupled to the memory, the processing device to: (Claim 1. A system comprising: one or more processors; and one or more computer-readable media having stored thereon instructions that are executable by the one or more processors that direct the computer system to configure a node, including instructions that are executable to configure the computer system to perform at least the following:: )
Regarding claim 9, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 10, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 11, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 12, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Regarding claim 15, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Kleynhans also teaches:
A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to: ([0108] Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: physical computer-readable storage media and transmission computer-readable media.)
Regarding claim 16, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m 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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights