Method and system for content-based document security, routing, and action execution

[0002] 1. Field of the Invention

[0003] The present invention relates to a computer-implemented rules engine. More particularly, it concerns a method and system that allows end-users to process documents according to rules, based on the content of documents, and to execute actions, dependent upon how the rules evaluate.

[0004] 2. Description of the Related Art

[0005] While there have been other rules engines, they all rely on meta data. Meta data based rule engines require that documents be pre-processed to obtain the meta data or that meta data be manually specified by an end-user. This meta data is then fed to the rule engine for evaluation.

[0006] Thus, a document to be routed according to a conventional system would include, for example, a header containing the data relevant to routing. Further, a document intended to be handled in accordance with certain security rules would include a header containing security-related data. A conventional header would include data related to other actions to be taken (or not taken) on a document.

[0007] Pre-processing of the document is used to determine the data or meta data to be placed in a header, or otherwise stored outside of the document contents, but associated with the document. Thus, in routing a document or otherwise action on a document, the pre-processed meta data is principally used.

[0008] According to the invention, there is provided a method and system for determining, in a computerized system, document content based actions. A rule engine is provided with a document to be acted on, the document having document content, wherein the document content is defined to include at least one delimited content field, and the document is defined to be in XML format. A rule grammar, including at least one rule operator, at least one constant, and at least one content field, is provided. The rule engine is provided with a set of rules and associated actions to be taken upon special conditions; wherein at least one rule in the set of rules includes at least a specified rule operator, a specified constant, and a specified content field; and a plurality of rule objects, a rule object containing a rule of the set of rules, and referencing one or more next rules to execute based on an evaluation of the document against the rule, and referencing one or more actions to be initiated based on the evaluation;. The document is evaluated according to the rules and the document contents; each of the rules is parsed into a parse tree, the document is further evaluated, including, for the provided document, populating the parse tree with at least a portion of the document contents, to create a content-populated parse tree. The content-populated parse tree is evaluated to a determinant. At least a portion of the actions associated with the rules, the portion of the actions to be initiated is selected based on the determinant.

[0009] These and other objects, features and advantages of the present invention are readily apparent from the following drawings and detailed description.

[0010] The invention is described in connection with the drawings, in which:

[0011] FIG. 1 is a flow diagram illustrating the method and system for content-based document security, routing and action execution;

[0012] FIG. 2 is a block diagram illustrating a rule object;

[0013] FIG. 3 illustrates and example of the parse tree resulting from parsing a document according to a rule;

[0014] FIG. 4 illustrates the parse tree of FIG. 3, as populated with document contents;

[0015] FIGS. 5a,5band 5cillustrate an in order traversal of the parse tree of FIG. 4.

[0016] A content based rules engine can evaluate rules based on the content contained within documents without relying on pre-processed data extracted from the document. For example, using the rules engine, a user can write the following rule: ‘If the value of the first name field in the document is “john” and the value of the last name field in the document is “doe” then put the document in the Review queue.’

[0017] FIG. 1 illustrates the rule engine's operation in general. The rule engine 101 is supplied with a document 103 to be acted on. Also supplied to the rule engine 101 is a set of rules 105, indicating actions to be take upon certain conditions. One or more actions 107 are then initiated by the rules engine 101.

[0018] The rule engine 101 is primed with a set of rules 105, and then for each document 103 processed, it performs a set of actions 107. The document 103 is preferably provided in XML (extended markup language) format.

[0019] The rule engine 101 should operate according to a pre-determined rule grammar.

[0020] Implementing and operating the rule engine consists of the following.

[0021] 1.) Determine a rule grammar. The specific grammar chosen is not of importance, so long as boolean operators, constants, and delimited content-fields can be distinguished from one another. It is preferred to use the following rule grammar:

[0022] (token $operator$ token) [$operator$ token $operator$ token]

[0023] where

[0024] token is either a quoted constant of the form “constant-value” or a % delimited content field of the form %content-field% and

[0025] token is either a quoted constant of the form “constant-value” or a % delimited content field of the form %content-field% and

[0026] operator is one of the following:

[0027] $eq$—equals

[0028] $lt$—less than

[0029] $gt$—greater than

[0030] $le$—less than or equal

[0031] $ge$—greater than or equal

[0032] $and$—logical and operation

[0033] $or$—logical or operation

[0034] $not$—logical not operation

[0035] The tokens and operators could be in a form different from the foregoing.

[0036] Table 1 depicts a sample document, highly simplified for illustration purposes, and a valid rule.

[0037] This example is for illustration purposes. The same principles will apply in a document of any size, and a set of rules of any size. Here, the document is in conventional XML format, and thus the fields within the document are delimited.

[0038] A rule condition may be an empty set, or a null operator, etc. The rules check conditions.

[0039] 2.) Define a rule object. The rule object 201 is used to contain a specified rule, to reference the next true rule 207 and false rule 209 to execute if it evaluates to true or false, to reference the next true rule 207 and false rule 209 to evaluate if it evaluates to true or false, to contain a list of true actions 203 to perform if it evaluates to true, and to contain a list of false actions 205 to evaluate if it evaluates to false.

[0040] FIG. 2 illustrates a rule object. Here, the rule object 201 relates to the example of Table 1. The rule object 201 contains the rule %fname% $eq$ “john”. This rule was pre-determined, preferably by a user. The rule object 201 contains, opints to 211, lists, or otherwise indicates one or more true actions 203 to be initiated if the rule, as applied against the document, evaluates to true. The rule object is associated 213 with one or more false actions 205. An appropriate action is a null, or “do nothing”. In this example, if the rule evaluates to true, the action is to “send email to [email protected].”

[0041] The rule object 201 also references the next rule(2), or rule object, to be executed. In this example, the true rule 207 is %name% $eq$ “doe”, and the false object 209 is %fname% $eq$ “jane”.

[0042] 3.) Initialize the Rule Engine. The rule engine 101 (shown in FIG. 1) is provided with a set of rule objects.

[0043] 4.) Parse the rules. When given a document 103 (shown in FIG. 1) to evaluate, the rule engine 101 will parse the rules into a parse tree. Generating the parse tree may be done in any appropriate manner, such as by commercially available grammar parsers, e.g., “Visual Parser”.

[0044] The parse tree illustrated in FIG. 3 would result from parsing the rule in Table 1. The tree includes operators 301, content fields 303, and constant values 305. A larger rule would result in a more complex parse tree,

[0045] There will be one such parse tree contained within each rule object. Thus, a set of rules will result in a set of parse trees, each corresponding to a rule object.

[0046] As an alternative to parsing the set of rules each time a document is provided, the rule engine could process the rules and re-use the parse tree for additional documents.

[0047] 5.) Evaluate Rules. For the provided document, starting with the first rule object, evaluate the parse tree to populate document content values. This advantageously is done by performing a depth-first in order traversal of the parse tree, and for each encountered node which contains a content field, substitute the specified value from the document 307 into the tree.

[0048] The provided document has contents including values that belong to an identifiable type. Preferably, the document is in XML format. Thus, the specified value for that type may be readily located within the document contents, in any conventional manner.

[0049] After performing this operation for the rule and document, the content-populated parse tree will be as in FIG. 4.

[0050] Once all content fields in the parse tree have been substituted with document values 307, the boolean logic of the rule is evaluated, preferably by performing a depth-first in order traversal of the parse tree. For each encountered node (301, 305, 307) which contains an operator 301, the operator node advantageously is replaced with the result of applying the boolean operation specified. This is discussed in detail below in reference to FIGS. 5a-5c. The ultimate result of evaluating the rule (the content-populated parse tree) is a determinant, preferably a boolean value. One of skill in the art will appreciate other manners in which a parse tree may be evaluated.

[0051] 6.) Execute Actions. At this point, according to the preferred embodiment, the parse tree will only be a single node of interest, the determinant. The determinant indicates how the rule evaluated. The value of the determinant determines the actions to be executed. In the preferred embodiment, this indicates whether the rule evaluates to true or false. If the rule is true, then the rule engine initiates execution of the configured set of true actions. If the rule is false, then the rule engine initiates the configured set of false actions.

[0052] 7.) Go to Next Rule. After the actions for the present rule have been executed, the rule engine goes to the next rule associated with the determinant value, if any, and repeats step 5. (Actions are further discussed below.) This process continues until there are no more rules to be processed.

[0053] FIGS. 5a-5cshow the result of performing the rule evaluation of a content-populated parse tree, by way of reference to the example of Table 1, and the content-populated parse tree illustrated in FIG. 4. In a depth first in order traversal for this example, the document value 307 of John and operator 301 of $eq$ are applied to the constant value 305 of John, and the operation result 309 is true. Advantageously, the operation result 309 replaces the operator 301 node of the parse tree (FIG. 5a). Next, the document value 307 of Doe and operator 301 of $eq$ are applied to the constant value 305 of Doe, and the operation result 309 is true (FIG. 5b). Next, the operation results 309 of true are operated on by operand 301 $and$, and the operation result 309 is true (FIG. 5c).

[0054] Actions can be any computing operation. In the presently preferred embodiment, the rule engine initiates security or document routine.

[0055] The rule engine may be used to perform content based document security by controlling which operations may be performed by which users on documents. For content-based security, the set of actions preferably includes the following: Grant Read Access, Grant Write Access, Grant Update Access, Grant Delete Access, Grant Search Access, Deny Read Access, Deny Write Access, Deny Update Access, Deny Delete Access, Deny Search Access. Other security actions are also possible. These actions can be implemented in any conventional manner, and can be initiated by the rules engine in any of the usual manners to initiate such actions. When a user tries to perform an operation (e.g., Read, Write, Update, Delete, or search) on a document, the rules engine executes the configured set of security rules to determine if the user is allowed to perform the operation.

[0056] The actual implementation of each of the above actions will be well understood by one of skill in the relevant art. In the preferred embodiment, each action sets a boolean variable to either true or false, indicating Grant or Deny.

[0057] The engine is also used to perform content based document routing. In the presently preferred embodiment, the following actions are provided: Send Email and Move Document to Queue. Other document routine actions are possible. The rule engine can be invoked, for example, when a document is created or updated, to evaluate document routine rules against that document to determine if the document should be placed in a particular queue or emailed to a user. Other document routing actions are possible, and the above list is not exhaustive.

[0058] The implementation of each of the above actions themselves is conventional, as will be understood by one of skill in the art. In the preferred embodiment, commercially available products are used to implement the actions: Send Email is implemented using “Ultimate TCP/IP” from Dundas Software; Move Document to Queue is implemented using “Message Queue” from Microsoft.

[0059] Sets of other actions and associated sets of rules may be provided. It is the intention that the principles of the present invention will accommodate other actions and rules. Indeed, the rule engine is sufficiently flexible to accommodate documents in a wide variety of formats, other sets of rules, and other sets of actions. Such is anticipated, and is taught by the foregoing, and is within the spirit and scope of the present invention.

[0060] While the preferred mode and best mode for carrying out the invention have been described, those familiar with the art to which this invention relates will appreciate that various alternative designs and embodiments for practicing the invention are possible, and will fall within the scope of the following claims.