Patent Application
20050172017
Policy engines are executable instructions used by a computing device to control the operation of the device. Policy engines use a number of instruction sets called policies to provide the control of the devices. Each policy contains a number of rule statements that are made up of a set of logical statements. These logical statements provide a logical framework for the rule statement and determine how the device should respond to the occurrence of a particular event.
For example, one type of logical statement is an if-then statement, as such statements are known to those skilled in the art. In a logical statement, a condition is presented and if met, an action is performed. (i.e., If [condition], then [action]).
The logical framework can be viewed as the format of the rule. The logical framework is the positioning of the different components within the logical statement. For example, the logical framework of the if-then statement above is the positioning of logical components IF and THEN and the positioning of the policy components “condition” and “action”.
A rule statement uses the logical framework and particular policy components to control a function of a device. For example, a rule statement is: If [the network usage is high], then [disable high risk servers]. In this if-then statement, the condition (in the first set of brackets) is met when network usage is high and the action (in the second set of brackets), to disable high risk servers, is initiated when the condition has been met.
Rules can be used to control various actions within the computing device as those skilled in the art will understand. For example, rule statements can be used to: detect network connections; allocate data, processor, or memory resources; or direct information or data from the computing device to another device, such as a computing device or peripheral device, to name a few.
As indicated above, a policy contains one or more rules which are used in various ways such that the policy engine can use a number of rules to perform actions based upon a number of conditions. The rules within a policy can be organized in series or in parallel.
In a series structure, the result of one rule feeds into another rule. For example, if the condition is met, an action occurs, and if an action occurs another condition is met and another action occurs.
For instance, the policy can include two if-then statements, such as if A occurs, then perform B, and if B occurs, then perform C. In such a case, when condition A is met, then action B is performed. However, in this second example, if A is not met, no action is taken. And, when condition A is met, B is performed and since the performance of B is the condition to be met in the second rule of the policy, C is also performed. These rule statements have been organized in serial such that the action or result of one rule is based upon another.
Further, a policy can be created in which an action will be taken regardless of the outcome of an event. For example, the performance or non-performance of an action or the satisfaction or non-satisfaction of a condition, can be a condition for a second rule.
For instance, a policy can include two if-then statements, such as if A occurs, then perform B, and if A does not occur, then perform C. These rule statements have been organized in parallel since the action of one statement does not effect the other statement.
Those skilled in the art will understand that rules can be used for simple and/or complex tasks. For example, rules can be used to do simple tasks such as retrieving a document from storage, extracting information from a document, performing mathematical routines, such as adding or subtracting, formatting information into a print job, or sending a print job to a printing device.
Policies can combine a number of rules to accomplish more complex tasks. For example, policies can be used for tasks containing a number of different actions. Each action could be performed based upon a rule. For example, an exemplary mathematical function can have an addition, subtract, and multiplication component with each component using a rule or a number of rules to perform the operation.
For instance, there can be a rule stating that, given two quantities, add the two together to create a product. Additionally, a rule can be provided that states when to initiate a particular component, such as if multiplication has been done, then perform the addition function.
Policies can also perform a number of the above different tasks, such as retrieving a document from storage, extracting numbers from the document, doing a mathematical calculation on the numbers, formatting the calculated data into a print job, and sending the print job to a printing device for printing.
In some systems, policy engines are provided in a database wherein the rules making up the different policies are grouped together and listed individually. In such cases, there may be duplicate rules in several policies within the policy engine. Additionally, when the policies are updated, entire new rule statements are added. These entire rule statements are then used to replace a rule statement in memory that is to be updated.
In such systems there exists a large amount of duplicate information which takes up valuable memory and can consume processing power in attempting to locate a policy or rule within the database. The use of entire rule statements for updating the system can make the updating of a policy engine time consuming.
Embodiments of the present invention provide methods, systems, and devices for use with respect to implementing and updating policy engines. Embodiments of the present invention use a number of policy components and logical statements stored in memory to construct the various policies and thereby reduce the amount of memory and processing time used by the policy engine.
In such embodiments, the policies can be created by using a logical framework, a number of policy components, and location placement information regarding where the policy components are to be positioned in the logical framework. In this way, a logical framework can be used in creating a number of rules based upon the selection and positioning of policy components within the logical framework. Such embodiments also allow rules and policies to be formed at run-time which reduces the amount of storage used to hold the policies and rules.
As stated above, policies can be used to control functions within a device or can be used to control functions that occur between devices within a network. Accordingly, the embodiments described herein can be used with individual devices or on devices within networks.
The embodiment of
The embodiment of
The examples provided herein do not provide an exhaustive list of network components, but rather are exemplary of some devices that can be within a network environment. Additionally, the above examples and other such devices can also be used as management stations for management of network functions, such as management of network connectivity, print jobs, storage devices, web access, mail service, remote access, file management, and the like.
As stated above, devices can be added to a network and instructions executed to map the new devices within the network. As the number of devices attached to the network proliferates, so too increases the number of policies and rules on the network. In various devices, as technology changes various policies and rules can be changed or updated to address the changes.
For example, with respect to security of a computing device, a policy can be included with the program instructions originally installed on the device. However, as more is understood about the potential threats to a device or as potential threats change, embodiments of the present invention allow the policy to be updated or additional policies added to change the approach to the security of the device. Additionally, embodiments of the invention, as discussed in more detail below, also allow for the policy to be updated or policies to be added without providing an entirely new policy, but rather by updating the policy components or logical framework.
The embodiment of
As one of ordinary skill in the art will appreciate, many of these devices include processor(s) and memory hardware. Computer executable instructions, (e.g., software and/or firmware) reside in memory, such as on a management station or other device, to manage a device feature, and/or manage a network.
Policies can be installed in one or more locations within the distributed network devices. Those skilled in the art will understand that a policy can be included within a set of program instructions, such as within application programs, object oriented program instructions, and/or operating system instructions, among others.
A policy definition is the set of logical statements (i.e., logical framework with a number of logical components positioned therein) that form the policy. For example, in the embodiment shown in
Those skilled in the art will understand that there are a variety of different types of logical statements that can be used such as: if-then, if-else, and while types, to name a few. The logical statement and/or framework can be stored in memory or provided in firmware independently from the policy components that are to be used for a particular rule. For example, the logical statement If [condition 1] AND [condition 2] can be stored separately from the conditions to be placed in the locations designated for condition 1 and condition 2. Condition 1 for example can be any suitable condition, such as “is midnight”. Likewise, condition 2 can be any suitable condition, such as “is network usage high”.
The actions (e.g., “notify security” and “disable high risk servers”) can also be stored independently from the logical statement. In this way, the same logical statement can be used by a number of different rules by using different conditions and actions within the condition and action spaces provided in the logical statement.
The logical framework can also be stored independently from the logical components such as IF, THEN, AND, OR, WHILE, etc. In this way, the meaning of each of the components can be changed without having to update each and every rule or logical statement using the particular logical component. Such embodiments can also be useful when different policy definitions for a particular logical component are to be used, such as when a rule is to be used in different situations, but a different logical meaning for the rule is desired.
By providing the components independent from the logical framework, a number of rule statements can be created from the same set of logical and policy components.
In an example, of an instruction routine for a condition component, the condition component “is midnight” can include instructions to request time from the system clock and to determine whether the returned time is midnight. Such a determination can be accomplished, for example, by identifying if the number given by the system for hours is greater than 00:00 (e.g., for military time) or identifying whether the time is 12 a.m. (e.g., for standard time).
In various embodiments, the components and logical framework can be used to form the rule statements that make up a policy. For example, in the exemplary policy definition provided in
Rule 2 will read: If it is the start of the day and it is not a weekend, then verify that all servers are enabled. In this way, the policy can be used to alert security and take action when certain criteria are met. The policy can also return the system to full server capacity when certain criteria are met.
In various embodiments, each of the components can be updated by providing a different set of instruction routines that are linked to the component. The instruction routines can be maintained in various manners, such as stored in various file formats in memory. For example,
In the case shown in
Additionally, the association of the condition can be changed from one instruction routine to another. For example, condition 1 can be changed to associate with “is a weekend.class” instead of “is midnight.class”. In such a case, a change in association, between the condition and an instruction routine, changes the meaning of the rules and the policies in which condition 1 is used.
This update information can be provided in an update string, as the same are known and understood by those of ordinary skill in the art. The update string can include other update information for updating the device in addition to providing policy components, logical components, and/or logical frameworks and can be part of a larger update having other device update information. The updates can be provided to the device in various manners such as on a storage medium, or transmitted to the device over a network (e.g., LAN, WAN, Internet, etc.), to name a few.
Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments can occur or be performed at the same point in time.
In block 320, the method embodiment of
Program instructions can be provided, such as on the computing device, which are executable to extract the policy components and other information from the update string. The extracted policy component can then be used to replace and/or add to a policy component stored in memory.
An antecedent component, for example in an if-then type statement, is one that defines a condition to be met. A consequent component is, for example in an if-then type statement, an action that is performed when a condition is met. In such a case, an exemplary rule would be “If [antecedent], then [consequent].
The method embodiment also includes associating the policy component with a logical framework stored in memory at block 330. For example, program instructions can be provided, such as with the update string, which are executable to associate the antecedent and consequent policy components with the logical framework from memory. The method embodiment can also include receiving instructions for using the policy component with the logical framework and a number of other policy components stored in memory.
The method embodiment of
At block 430, the method embodiment also includes extracting the policy definition and the location placement information from memory. As described above with respect to
The method embodiment illustrated in
The method embodiment can also include executing a platform independent function call, as the same will be known and understood by those of skill in the art, to extract the location placement information from the update string. In this way, a set of program instructions can be created in a platform independent format, such as Java, and then be used with a variety of platforms.
Although specific embodiments have been illustrated and described herein, those of ordinary skill in the art will appreciate that any arrangement calculated to achieve the same techniques can be substituted for the specific embodiments shown. This disclosure is intended to cover adaptations or variations of various embodiments of the invention. It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one.
Combination of the above embodiments, and other embodiments not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. The scope of the various embodiments of the invention includes various other applications in which the above structures and methods are used. Therefore, the scope of various embodiments of the invention should be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.
In the foregoing Detailed Description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
