TW201339857A - Detecting cases with conflicting rules - Google Patents

Abstract

A method, system and computer program product for managing condition action rules comprising: a treated case modeler for building a family of cases that make some rules applicable; a conflict detector for iteratively building and testing subsets of cases of the family searching for cases with conflicting decisions in order to locate a subset of cases that all have conflicting decisions. The conflict detector is further adapted for eliminating subsets of cases that have all non-conflicting decisions. The conflict detector is further adapted for distinguishing conflicting decisions from unrelated decisions and thus avoids the reporting of false conflicts.

Description

Detecting cases with conflict rules

The present invention relates generally to a rule management system and, in particular, to a method and apparatus for calculating a case in a rule management system with conflicting rules.

Business Rule Management (BRM) technology is an area of automation for decision making in business issues such as loan approvals, insurance claims processing, or customer loyalty programs. Implement a Business Rule Management System (BRMS) to work with the rule project. BRMS allows for rule editing in a natural language like control, which makes it easy to use without the specific knowledge of the rules. Rules can be kept in the rule repository in different versions. The BRMS further allows rules to be enforced by the rules engine, which also performs rule analysis for detecting conflict rules, redundancy rules, and missing rules. Another feature is rule verification by testing and simulation.

Business rules are a convenient way to represent decision making principles that are used to make decisions that depend on a given case. A case is usually composed of a combination of features, and the decision can be a combination of basic choices. Business rules make decisions by applying actions to a given case. Business rules cannot handle all cases, but only those that meet the conditions. Business rules are therefore made up of conditions and actions, usually a combination of tests, and actions can consist of a sequence of basic steps. Because business rules only deal with certain cases, business rules only define a part of the overall decision making process. Other business rules are needed to make decisions for the remaining cases. If a business rule gives a decision for each relevant case, then Then this collection is complete. Otherwise, the rule will not process each case and additional rules need to be added to make the rule complete.

Automated decision making for issues such as insurance claim processing, loan approval, or discount calculations for shopping carts is to make decisions for a large number of cases in a consistent and predictable manner. Automated decision making is achieved through business principles that include business rules that map every possible case to a single decision. Business rules provide a convenient way to express complex principles for making decisions in mutually exclusive and complex forms. Each rule represents an independent part of the principle and makes decisions for a subset of the case. Business rules consist of conditions and actions that describe cases handled by rules that consist of actions that make decisions for the case. Because the case can be complex and consists of different items, such as different items in a shopping cart, the business rules can only process selected items of the case, and thus have categories that describe the types of items that the business rules can handle. The complex principle can therefore be represented in a simple way by a set of business rules.

Because there are many ways to express principles based on rules, additional criteria are necessary to determine good representations for decision automation. First, it's important to keep the representation manageable and as small as possible. The number of rules can be reduced by making the rules as general as possible and by avoiding redundant rules. Second, different rules should be independent of each other in order to facilitate the modification of rules that are attributed to changes in business principles. If the business principle changes for a particular case, the business user needs to adapt all the rules for handling the case to the new principles. If the rules overlap, the principle change may require modification of several rules. In the case where the overlap is due to the fact that the rules are as general as possible, this consumption in rule editing is acceptable. However, there is no change in existence but no change In the case of a redundant rule of decision making behavior of a set of rules, the consumption is unacceptable.

The decision-making principle defines which decision will be made for which case. The principle of decision making sets the same decision for all cases with the same characteristics, and thus guarantees the basic form of consistency in the decision making process. This situation is important for issues such as insurance claim processing, loan approval or discount determination, all of which involve processing a large number of cases based on routines. Some of these cases may have the same characteristics and the comparison of decisions in their cases may in principle be possible. The consistent handling of their cases is therefore important for achieving predictable behavior, automating the decision making process and meeting the customer base.

Cases of decision making problems are often characterized by multiple objects with multiple attributes, which means that the decision principle is a mapping from a multidimensional case space to a decision set. If this complex principle consists of different parts that depend only on some attributes but not on all attributes, each part can be represented by a generation rule (or condition-action rule). The production rule consists of conditions and actions that describe the case handled by the rule, which consists of the operation of making decisions for the case. In addition, the rules have a scope that defines which objects of the case are checked (or matched) by the rules. Since the case can consist of an unlimited number of items (such as different items in a shopping cart), the rule will only process a fixed number of items in the case.

The set of rules thus provides a convenient way of representing the principles of decision making for complex cases. Since each decision principle can be represented by a set of rules, not every rule set represents an effective decision principle. In detail, it can exist as The same case sets the rules for different decisions, and these decisions can conflict. For example, in the case of a case handled by two rules, the rules for accepting a loan conflict with the rules for refusing a loan. The decisions of their rules conflict, because it is impossible to accept and reject the same loan request. This situation means that things cannot be configured in such a way that both decisions are valid for the case.

Given that issues such as loan approval are made up of operations that make a single decision, other issues such as insurance claim processing can involve multiple decisions, that is, acceptance or rejection of an insurance claim and determination of the amount of damage. The rules governing insurance claims and the rules for determining the amount of damage make different decisions, but these decisions are not in conflict. It is possible to configure things in such a way that both decisions are valid. In fact, the two decisions are independent of each other and focus on the different aspects of the overall problem. This situation does not hold true for rules that accept insurance claims and rules that reject the same insurance claim. Their rules have conflicting decisions.

This discussion demonstrates the need for additional knowledge to determine whether different decisions conflict when rules make multiple decisions. There are different ways of providing knowledge about conflict decisions. Knowledge can be given in implicit form by appropriate structuring of the set of rules or appropriate representation of the regular actions. In a well structured set of rules, the rules are encapsulated into different groups such that the rules of a group focus on a single decision. The rules of the group thus make an alternative to the same decision, and if the two rules in the group make different decisions for the same case, the two rules conflict. However, in general, the structuring of this good training is not given. If a rule action is represented in the form of assigning a value to an object's attributes, then the two rules are in and only assign the same value to the same object for the same object. The case has conflicting decisions. Therefore, the form of the action enables the detection of conflicts. This situation is no longer possible for a more general and abstract form of an action that can be described by a method applied to some of the arguments. Because they constitute abstract behavioral descriptions, explicit knowledge is needed to declare which methods make conflicting decisions.

The general system for analyzing the consistency of a set of rules must therefore be able to handle the rules that are formulated by any form of action regardless of whether the actions are represented by a specific assignment or by an abstract method call. This system must distinguish between rules for making conflict decisions and rules for making different but unrelated decisions. For this purpose, the rule analyzer needs to consider conflicting actions. In addition, rule makers do not have to know which rules conflict, but must identify the case in which such conflicts occur. The consistency analyzer must therefore be able to characterize and report cases with conflicting rules. The description of their case provides key information that allows the rule maker to modify the set of rules to ensure consistent decision making. For example, the rule maker may add a high priority rule that acts as an arbiter and imposes better decisions for their case while keeping the existing rules unchanged.

Existing systems and methods for detecting conflicting rules are limited in one aspect or another. The consistency analysis of the classical approach is limited to a decision table that represents a set of rules for alternative selections that make the same kind of decision. For example, the methods described in U.S. Patent No. 5, 259, 066, U.S. Patent No. 7,020, 869 B2, U.S. Patent No. 10, 639, 674, and U.S. Patent Application Serial No. 2003/0018486 A1 report two rules in the case where the rules have overlapping conditions but the rules differ in their actions. The conflict between. Because the decision table completely describes the rule action, In the event that two rules have different table entries in an action row (or action column, depending on the orientation of the table), the rules have conflicting actions. It is understood that for the reasons described above, it is important that such methods are unable to find conflicts between rules belonging to different tables. In addition, their methods cannot find conflicts between rules of any kind.

The method described in the article "An Approach to Verifying Completeness and Consistency in a Rule-Based Expert System" by Motoi Suwa, A. Carlisle Scott, and Edward H. Shortliffe assumes that each rule has the appropriate form (ie, assigns values) A single decision in the form of an object that is matched by rules. The method then groups the rules according to the scope of the rules (i.e., the type of matching object) and the attributes assigned by the rules. For each of the groups, the method builds a decision table that represents the rules of the group and then looks for columns with overlapping conditions and different actions. Because the method assumes that the rule action has the form of an assignment, it is not possible to find a conflict between rule actions in the form of an abstract method call.

Similar restrictions apply to methods that detect conflicts between rules that assign different values to the same attribute or parameter. An example is the conflict checker of US Patent Publication 2007/0162966 A1 and the consistency analyzer of IBM WebSphere Ilog JRules BRMS 7.1. These methods use constraint satisfaction techniques to check for the existence of a condition that satisfies the conditions of the two rules with conflicting assignments. Although their parsers are able to find conflicts between rules with arbitrary conditions, the parsers assume that the rule action has the form of an assignment. Because the parsers do not consider knowledge about conflicting actions, the parsers will not find a conflict between the two: by calling the loan The method of "accepting" to accept the loan, and the rule of rejecting the loan by calling the method of "refusing" for the same loan object.

U.S. Patent Publication No. 12079021 simply states that if two rules have overlapping (or matching) conditions and different actions, the rules conflict. These methods cannot distinguish between conflicting rules and rules that make irrelevant but non-conflicting decisions. Similar notes apply to non-convergence analysis because this note is known for project rewrite systems. Non-convergence analysis can be adapted to generate rules to find different rule sequences that lead from different initial states to different final states. However, as argued above, the difference between the two final states does not necessarily mean that conflict decisions have been made by two rule sequences. In a multi-decision problem, it is possible that not all decisions are made in each sequence. Therefore, the final state can be different due to some decisions being missed in one of the states. Non-convergence thus indicates the existence of a case with conflicting decisions or the execution of a missing decision. Separate non-confluent analysis is therefore not sufficient for detecting cases with conflicting decisions.

The conflict detection method for logic rules and preset rules uses a model of conflicts (such as the mutual exclusion constraint in US Patent Application 2003/0023573 and the article "Expressive policy analysis with enhanced system dynamicity" by Craven et al. Knowledge of state conflicts. Given that the use of such constraints is natural in a logical rule system, the use of such constraints for conflict analysis of condition-action rules can result in additional difficulties not solved by such prior work. In a logical architecture, it is easy to accumulate the conclusions of multiple rules in a single state and publish constraints on those conclusions. In order to achieve the similar ability of the condition-action rules, it is necessary to carefully design the rules. The appropriate logical representation.

This check of existing practices thus indicates that there is no method and system for finding conflicts between rules with arbitrary forms of conditions and actions. Furthermore, existing methods for detecting conflict rules assume that conflicts are resolved by modifying one or both of the two conflicting rules. Therefore, these methods focus on the issue of detecting conflicts between rules.

Describe an example of a problem. Alan, an analyst at Fair Credits Inc., wrote a rule for accepting loans with a loan amount of up to $600k and a debt ratio of up to 35%. Fairyans reviewer Ryan wrote a rule for refusing loans when the amount is greater than $300k and the debt ratio is greater than 30%. Customer Jim's request for a $500k with a 32% debt ratio was accepted. Customer Jane's request for a $500k with a 32% debt ratio was rejected. Reporter Mary and friends from Jim and Jane posted articles about Fair Credits' unfair customer processing. Fair Credits lost 20% in the stock market.

The head of Fair Credits asked the Business Rules Management System (BRMS) administrator Bob to report all cases with conflicting decisions. Bob did not find the report characteristics in the BRMS tool, and even the conflict rule analysis did not report the problem. Bob concluded that the BRMS tool has serious limitations.

None of these references shows how to calculate a family of cases with conflicting decisions.

In a first aspect of the present invention, a method for managing a conditional action rule is provided, the method comprising: constructing a family of cases for which some rules apply; repeatedly establishing and testing for cases with conflicting decisions The home A subset of the family case in order to locate a subset of cases that all have conflicting decisions.

In the case where there are only two sets of the following types of cases, the method would be easy for the rule management system: all cases have only type 1) of conflicting decisions; and all cases have only non-conflicting decision types 2) Collection. However, in fact, most collections have cases with conflicting decisions and cases with non-conflicting decisions (type 3) and must be further broken down to classify them as having only conflicts or only non-conflicting. The solution of the above solution and preferred embodiment decomposes each type 3 set into smaller subsets and repeats the decomposition over and over until the subsets are either type 1 or type 2. Advantageously, the method further comprises eliminating a subset of cases having all non-conflicting decisions.

In the above aspect of the invention, the term "decision" is used, and in the embodiments and other aspects of the invention, the term "action" is used by appropriate adjustment. The decision of a rule is directly related to the action taken. For example, the decision on the loan money is directly related to the action of the loan money.

The implementation task is formulated into a logical satisfiability problem, in which the test of the conflict is formulated into a logical unsatisfiability problem.

More advantageously, the family of the case and the subset are modeled using a constraint-based technique. Embodiments of the present invention use logic and constraint-based satisfiability techniques for checking whether two conditions of any form can be satisfied at the same time.

This method can handle the rules for making multiple decisions. If different types of decisions are made for the same item (such as accepting or rejecting an insurance claim and determining the amount of damage to the insurance claim) or making the same type of decision for multiple items Policy, there are multiple decisions.

Preferably, the method further comprises distinguishing between conflicting decisions and irrelevant decisions, and thus avoiding reporting of false conflicts. The method achieves this important screening by performing an appropriate analysis of one of the rule actions while considering knowledge about conflicting decisions. As long as each rule makes the entire decision, the disclosed method achieves this analysis of any form of condition-action rules.

More preferably, the method further includes defining a subset of the cases with conflicting decisions such that a new rule uses the definition and eliminates the conflict. These conflicting decisions are those cases that are handled differently by multiple rules. The method thus gives a concise report of the basic form of inconsistency in the decision making behavior of the set of rules. This report explains that if the rule set is applied to the case listed in the report, the rule set will not make a clear decision. The disclosed method produces a compact description of such cases with conflicting decisions in the form of a family of similar cases. This description promotes the task of a rule-maker who seeks to establish a consistent decision-making behavior by adding rules that act as arbiters. For example, the rule maker can create a family with a higher priority that processes a family of cases with conflicting decisions and imposes the desired decision. The method thus shows how to calculate important information that allows a rule maker to establish a consistent decision making behavior without lengthy repairs to one of the existing rules.

In order to find cases with conflicting decisions, the method uses knowledge about the rules actions for making conflict decisions. This knowledge can be given in different forms. The most explicit form is the form of an axiom that states that certain actions are incompatible. For example, the act of accepting a loan is incompatible with the act of rejecting the same loan. also This knowledge may be provided in a form defined by one of the decisions that describes the scope of the decision (ie, the type of object to which the decision applies) and lists alternative actions (such as accepting or rejecting) used to make this decision. a loan). It is also possible to give this knowledge in the form of the nature of the method of an object model, such as the nature of a setter-method that would necessarily produce different results if applied to the same object.

However, the method does not require a detailed model of one of the rule actions (such as implementing a model of a Java code such as an abstract method call for "accepting a loan" that occurs in the rule action) to determine such actions Whether to make conflict decisions. Given the knowledge of incompatible actions, the method performs an consistency analysis at an abstraction level.

The following may occur: Knowledge about incompatible actions is incomplete. Even in this case, the reported problem is valid. If this knowledge is extended (or improved), the method can determine additional cases with conflicting decisions, but such previously reported issues will remain valid with this additional knowledge.

The method takes advantage of a satisfiable technique such as in constraint stylization and theorem proving to determine a family of cases in which at least two conflicting rules apply. The present invention uses a family that generates and tests practices to determine cases with conflicting decisions. The production phase creates a family of cases in which a rule applies, while the testing phase checks whether each case in the family has a conflicting decision. To achieve this, the conflict checker attempts to solve the reverse problem. The conflict checker determines if the family contains at least one case such that the action applicable to the rules of the case does not violate any axioms regarding incompatible actions. If the family contains at least one case, then some of the family The case does not have a conflict decision, which means that part of the family needs to be discarded. If the family does not contain the at least one case, then each case of the given family applies at least two rules, and the actions of those rules are incompatible according to the given knowledge about the action of the rules. Therefore, a family of cases with conflicting decisions is detected in this situation. Given the task of formulating a task as a logical satisfiability problem, conflict checking is equivalent to a logical unsatisfiability problem.

A second aspect of the present invention provides a method for managing a conditional action rule, the method comprising: determining a compatible and incompatible action of a rule in a set of rules; and establishing at least one of the set of rules for testing Testing a family in one of the rule cases; determining a compatible subset of the family's case such that applying the applicable rules in the subset results in only a compatible action; determining that the family is from a portion that is not part of the compatible subset One of the cases tests a subset whereby one or more of the cases in the test subset have the possibility of conflicting actions with the rules in the set of rules; and all in the test subset Where the cases have conflicting actions, the test subset is determined to be a conflicting subset; otherwise, a new test family having one of the test subsets is defined and a new compatible subset and a new test subset are executed. It is determined that until a new test subset is determined to be in conflict.

The disclosed method is important because it helps to achieve decision consistency in a rule management system, that is, the method helps ensure that the same case receives the same decision.

The disclosed method enables a business user to overall control a decision management platform and Add overall trust to the system.

Preferably, the method further comprises compiling a conflicting subset of the case and a report of the conflicting action. This solution replaces one of the conflicting rules with manual trial and error analysis and editing.

More preferably, each family and subset of cases is characterized by primitive conditions from the set of rules.

Suitably, the method further comprises determining at least one arbitrator rule for adding to the set of rules to resolve the conflicting actions regarding the cases of the conflicting subset.

This determination of a family of cases with conflicting decisions permits the addition of an arbitrator rule with a higher priority that enforces the desired decision.

According to a third aspect of the present invention, a system for managing conditional action rules is provided, the system comprising: a processed case modeling tool for constructing a family of cases for which some rules apply; A detector that is used to repeatedly build and test a subset of cases of the family, searching for cases with conflicting decisions to locate a subset of cases that all have conflicting decisions.

In accordance with a fourth aspect of the present invention, a conflict detector for implementing a test and test method is provided; and a processed case modeling tool for describing all cases for which a rule applies. The following two form part of the functionality of the collision detector, but are either an entity part or a separate one depending on the embodiment: a description of which case will be performed on which case, a rule set inference modeling tool, and providing incompatibility A motion reasoner for knowledge of rule actions.

The processed case modeling tool constructs a rule set applicability map, The rule set applicability graph indicates that a rule matches some of the items in the case and that the items satisfy the conditions of the rule. The rule set applicability graph represents an extract of the applicability graph of the individual rules. The applicability chart of a rule describes a case handled by a rule in a compact logical form.

The rule set inference modeling tool models a decision making behavior of the rule set in an implicit logical form by constructing a rule set implicit graph, and the rule set implicit graph describes the action of the applicable rule by using the rule set A set of rules to execute. In fact, a rule set implicit graph represents the conjunction of the implicit graphs of individual rules. A rule implied graph description: In the case where the case contains objects matched by the rule and the objects satisfy the rule condition, the rule action will be performed by the rule set. Given a case, a logic problem solver can then determine the applicable rules and derive the action to be performed. If some of the actions are incompatible, then the logic problem solver will not be able to find a solution to the rule set implicit map for the given case. The logic problem solver has therefore demonstrated that this case has conflicting decisions.

The action reasoner manages knowledge about conflicting actions. The action reasoner uses this knowledge to generate incompatibility constraints between the regular actions that occur in the set of rules. If a rule formulates a plurality of decisions by performing a sequence of actions, the action reasoner processes the assignments and derives values of the intermediate expressions modified by the assignments. Moreover, the motion reasoner achieves a comparison of one of the different sequences of actions by appropriate transformations (i.e., by having the different sequences of actions achieve the same order).

The collision detector is implemented by implementing the generation and test method described above Search for a family of cases that make conflict decisions. The collision detector is thus composed of a case family generator and a conflict checker. The case family generator searches the entire space of the processed case (ie, the case where at least one rule applies). The case family generator uses a bad person storage area to eliminate previously generated candidates that have been discarded by the conflict checker or have been included in the report on cases with conflicting decisions. Initially, this bad person storage area was empty. In order to find a new family of one of the processed cases, the case family generator submits the rule set applicability map and the bad person to a processed case solver. If the processed case solver does not find the rule set applicability graph and one of the bad ones that mark the root node as true and considers all graph operations, then there is no applicable rule and the entire analysis stops. Otherwise, the case family generator extracts a family of processed cases from the icon representation by examining the true value of the proposition node in the graph. The case family generator then sends the family of cases to the conflict checker.

The conflict checker constructs a non-conflicting graph representing the family of processed cases, a rule set implicit graph, and constraints on incompatible actions occurring in the rule set implicit graph. The conflict checker requests these constraints from the action reasoner. The conflict checker submits the non-conflicting graph to a non-conflicting graph calculator. If the non-conflicting graphical calculator finds a one of the satisfaction graphs, then the candidate case family contains at least one case that does not have a conflicting decision. The conflict checker managed to eliminate this and similar cases. The conflict checker thus constructs one of the cases to improve the family by examining the indication generated by the non-conflicting graphical calculator. The cases in the improved family satisfy one of the proposition nodes in the non-conflicting map if and only if the node is marked as true. The conflict checker thus uses these proposition nodes and their labels to produce a description of one of the improved families. The conflict checker then sends the improved family to the case family generator, which converts the improved family into a bad one and thus eliminates such cases in the improved family. The generator will then generate a new family of one of the processed cases and repeat the method. However, if the non-conflicting graphical calculator does not find a flag that satisfies the non-conflicting graph, then the non-conflicting graph does not have a solution, which means that the given case family has conflicting decisions. The conflict checker then includes this family of cases in the final report.

In a particular embodiment, the conflict checker summarizes the improved family by using a consistency based interpretation method prior to transmitting the improved family to the case family generator.

This method is repeated to find other families with cases of conflicting decisions. For this purpose, the conflict checker informs the case family generator in the report that it has included a case with a conflicting decision. The case family generator then adds a bad person to its defective storage area, which avoids regeneration of one of the families. The case family generator then manages to create a new family and submit the new family to the conflict checker. The method stops when the family generator cannot find other families in the case.

According to a fifth aspect of the present invention, a computer program product comprising a computer readable recording medium having computer readable code for detecting a case by conflict rules is stored on the computer readable recording medium, the computer readable The reading code, when loaded onto a computer system and executed, performs the following steps: building a family of cases for which some rules apply; re-establishing and testing the program A subset of family cases, searching for cases with conflicting decisions to locate a subset of cases that all have conflicting decisions.

According to a sixth aspect of the present invention, a computer program is stored on a computer readable medium and loadable into an internal memory of a digital computer, the computer program being included in a computer executed on the computer The software code portion for performing the method of any one of claims 1 to 4.

Embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings.

Rules are a convenient way of expressing the entire collection of cases and not only making certain decisions for a single case, such as accepting or rejecting a loan request. In particular, the rules allow decision makers to generalize decisions made for a particular case by extending their decisions to a family of similar cases. For example, a decision to accept a request for a loan of $200,000 under a 35% gearing ratio can be summarized as a loan request with a debt ratio of up to $600,000 and up to 35%. The result of this generalization step is the following rule: If the amount of the loan request is at most $600,000 and if the debt ratio of the loan request is at most 35%, the loan request is accepted. Independent of this, the decision to reject a loan of $300,000 under a debt ratio greater than 40% can be summarized as a loan requirement greater than $300,000 and a gearing ratio greater than 30%. The result of this second generalization step is the rule that if the loan request amount is greater than $300,000 and if the loan request debt ratio is greater than 30%, the loan request is rejected. When applying their rules to a loan request of a debt ratio of $500,000 and 32%, both the loan and the loan will be rejected. Therefore, the decision making behavior of these rules is inconsistent because it is impossible to Configure things in a way that both rejects the loan and accepts the loan. These decisions conflict and should select only one of those decisions.

Cases with conflicting decisions can occur for a number of reasons. First, it is possible to introduce cases with conflicting decisions when summarizing decisions in existing cases. The generalization steps can be performed independently of each other and follow their own underlying principles (such as finding rules with the most general conditions for making decisions that summarize existing cases). In addition, cases with conflicting decisions may be introduced when changing existing rules, as the modification of the rules may introduce overlap with other rules. Inconsistencies are attributable to unpredictable interactions between rules, and inconsistencies occur not only in the context of collaborative rule authoring, but also in cases where rules are defined by a single rule maker. In fact, the nature of the rules makes inconsistency almost inevitable. Rules form a compact and simple representation of complex decision making principles. Rules represent different segments of decision-making principles that are independent of each other. More general rules take precedence over more specific rules, because more general rules result in shorter and simpler descriptions of the rule conditions, and also reduce the total number of rules. However, the high degree of generality of the rule conditions tends to lead to overlap between rule conditions and leads to inconsistencies in the case where their overlapping rules make conflicting decisions. Therefore, the problem stems from the fact that the entire area of the case space needs to be covered by a block of cases that can be handled by a single rule.

The classic way to resolve conflicts between rules is to modify the conditions of one or two rules so that the conditions no longer overlap.

The classic approach has several drawbacks. First, the classic approach needs to identify all the rules that make conflict decisions for the case. In fact, it is possible to have more than two rules Then make conflict decisions for each case. Second, the classic approach requires modifying the rules to ensure that they do not overlap.

The simple rule is to declare one of the rules as the winner and give it priority over the other rules.

Another approach is to modify the rule conditions to avoid any overlap. This modification may result in a more complex description of the rule conditions involved in the nesting and extraction nesting.

In an alternative approach, the rules can be split into a number of more specific rules. All of these methods require lengthy investigations into existing rules.

However, the practice adopted by the embodiment is to directly address cases with conflicting decisions. Instead of fixing existing rules, rule-makers can add higher-priority rules that make the right decisions for these cases and act as arbiters. A single arbitrator rule can make decisions for the entire family of similar cases with conflicting decisions. If properly defined, the arbitrator rule has the same form as the other rules. The embodiment practices maintain the simplicity and generality of the rules while handling inconsistencies by adding an arbiter rule layer. The embodiment approach no longer requires the identification of conflicting rules. The embodiment approach only needs to detect families with cases with conflicting decisions.

Debate: There is no need to resolve conflicts between rules, because the rules engine will enforce conflict rules in a certain order. In fact, if several rules conflict, then only one of the rules' decisions will be effective and unlikely to encounter, for example, both a loan and a loan. Due to this, when the rule engine applies the rule to a single case, the conflict decision cannot be made. However, when the engine is called multiple times for a similar case, the conflict can be revealed. If there are conflicting rules, the final decision will depend on the order in which the engine executes the rules. This order may depend on secondary criteria (such as the name of the object, internal memory address, etc.), which may vary for equivalent cases and for different calls to the engine. Therefore, the engine can make different decisions for equivalent cases when it is called multiple times. Therefore, a rule-based system produces different outputs for the same input when called multiple times. Conflict rules can therefore cause irregular behavior of the rules engine, and it should be possible to observe this behavior within the larger samples executed by the engine.

However, conflict rules are not the only reason for irregular behavior. If the order of multiple rules is important for making decisions, the rule-based system can also produce different outputs for the same input. For example, a set of rules for insurance claim processing must use a sequence rule that includes a determination of the amount of damage to decide whether to accept the claim or reject the claim. If the rule engine is applied to an equivalent insurance claim multiple times, the rules engine can execute the rules in a different order. So in this example, the rules engine will produce different outputs for the same input.

Missing decisions are another reason for obtaining different outputs. Because a set of rules can make multiple decisions, comparing the resulting output state is not sufficient when looking for cases with conflicting decisions. The different output states are attributed to the following questions: 1) conflict decision; or 2) missing decision. A deeper analysis is therefore necessary to distinguish between these two issues.

The conflict rule analyzer must therefore distinguish between rule actions that make conflict decisions (such as accepting and rejecting the same insurance claim) and rule actions that make unrelated decisions (such as accepting insurance claims and determining the amount of damage). In order to distinguish between conflict and irrelevant decisions, the parser needs additional knowledge about the action of the rules. For example, the analyzer needs to know to accept and reject the same insurance claim The actions are incompatible, and this is because these actions make conflicting decisions.

Figure 1 is a table showing examples of rules for making conflict decisions for certain cases (Table 1: Rule Project 1). Write the rules in the IBM WebSphere Ilog JRules BRMS 7.1 Business Action Language (BAL). The rules determine the decision to accept or reject a loan request based on the amount of the loan request and its debt ratio. Rules can also classify loan requests into categories such as low risk or high risk. For example, if the loan's debt ratio is at most 35% and its amount is at most $600k, then rule d1 accepts the loan: rule d1: Loan1 is set as the loan; if Loan1's debt ratio is at most 35 % and Loan1's amount is at most $600,000, then accept Loan1; if the debt ratio of the loan is greater than 30% and its amount is greater than $300k, then rule d2 rejects the loan request: rule d2: Loan1 is set as the loan; if Loan1's debt ratio is greater than 30 % and Loan1's amount is greater than $300,000, Loan1 is rejected ; such rules have refused to accept both the (e.g.) 35% of the gearing ratio and the amount of the loan request of $ 600K. Therefore, the conflict rules make conflict decisions for their cases, as shown in the shaded hatched area of the marker in Figure 2.

If the loan amount is greater than $1000k or its debt ratio is greater than 40%, rules d3 and d4 reject the loan: rule d3: Loan1 is set as the loan; if Loan1's debt ratio is greater than 40 % , Loan1 is rejected; rule d4: Loan1 is set to Loan; Loan1 is rejected if the amount of Loan1 is greater than $1,000,000; eventually, if the loan amount exceeds $300k, rule c1 assigns a high risk to the loan: rule c1: Loan1 is set as a loan; if Loan1 is greater than $300,000, Loan1 is classified For high risk; a loan request of $2000k and a 50% debt ratio will result in a number of rules (ie, d2, d3, d4 and c1). Because rules d2, d3, and d4 reject this loan request, they do not conflict. In addition, rule c1 classifies this loan as high risk, independent of the decision to accept or reject the loan. Therefore, classifying a loan as high risk is compatible with rejecting the loan. Therefore, a given loan request results in multiple but non-conflicting multiple decisions.

2 is a state diagram depicting a case space in the form of a two-dimensional coordinate system having a loan amount axis and a liability ratio axis. Figure 2 shows the decision making behavior for a set of rules for a single loan. Cases handled by rules correspond to rectangles Block. Different forms of hatching indicate acceptance or rejection of a loan. Cases with conflicting decisions are obtained in spaces where different forms of rules (marked by different hatching) overlap.

In an object-oriented rules language (such as the object-oriented rule language of IBM WebSphere Ilog JRules BRMS 7.1), rule actions can be represented in abstract form depending on method calls. For example, a loan or the like has three methods of representing three actions of a void accept (), a void reject (), and a void classify (...), wherein the term "Void" defines the following methods: class Loan{ void accept(); void reject(); void classify(RiskCategory risk);

This instance loan class declares the arguments and return types of the method, but does not reveal any information about its role. The class declaration does not interpret the method call x.accept() and x.reject() to form an option for the loan x approval decision. In addition, the class declaration does not explain the option to invoke x.classify(y) for the classification decision for loan x for different risk categories y. Therefore, additional definitions of decision making are needed to understand the role of methods such as decision making procedures.

Embodiments of the present invention use this definition of decision making in order to detect actions that make conflicting decisions. Because the different options of the decision are mutually exclusive, the parser can export the method calls x.accept() and x.reject() which are incompatible with the action "accept x" and "reject x". In addition, the analyzer can conclude that if the risks y and z Different, the method calls x.classify(y) and x.classify(z) are incompatible.

Explicit definitions of decisions are common in decision support systems and constitute a convenient way to provide knowledge about conflict decisions. These definitions of decisions need to consider the specificity of rule-based decision making, and rule-based decision making will make multiple kinds of decisions for multiple objects. In addition to the list of options, the definition of the decision set of the rule set must therefore also take into account the scope of the decision, that is, the number and type of objects for which the decision is made. For example, a loan approval decision is made for a loan item. Therefore, the scope of this decision is the scope of the loan object. The decision-making option is the action of the object applied to the category. For example, a loan approval decision for a loan item Loan1 has the option of accepting the item Loan1 or rejecting the item. The possible grammar for this decision definition consists of the keyword "decision" followed by the name and scope of the decision and the description of the option. The category declaration may have the same grammar as the category of the rule, that is, an item declaration list, such as "set Loan1 as a loan." The option description uses the phrase "The option will be <action 1>, which will be <action 2>,..., and will be <action n>". The action has the same syntax as the rule action. The loan approval decision can therefore be defined as follows: Decision LoanApproval sets Loan1 as a loan; the option will be to accept Loan1 and reject Loan1; other decisions may have to choose between different applications of the same action. In this case, the action is applied to the extra arguments and the options differ in the value of their arguments. For example, the loan classification decision is to classify the loan object as a risk, where the risk is low risk or high risk. The option description for this decision thus declares such arguments, their type, and possibly their domain. For example, the loan classification decision can be defined as follows: Decision LoanClassification sets Loan1 as a loan; the option will be to classify Loan1 as Risk1 where Risk1 is the risk category in {low risk, high risk}; if the decision definition is available, the conflict The rule analyzer can extract knowledge about incompatible actions from the decision definitions. For example, the conflict rule analyzer can export that it is not possible to accept and reject the loan. However, if the decision definition is not available, then you need to explicitly specify their incompatibility constraints. Furthermore, the incompatibility constraint has the scope of the object described as the subject of the constraint. In addition, incompatibility constraints list collections of actions that are mutually exclusive. The possible syntax for this incompatibility constraint begins with the keyword "constraint" followed by a category declaration and incompatibility description. The incompatibility description uses the phrase "it is incompatible with <action 1>, is incompatible with <action 2>, ..., and is incompatible with <action n>". For example, the incompatibility of accepting and rejecting the same loan can be expressed as follows: Constraint: Loan1 is set as a loan; Loan1 is accepted as incompatible with Loan1; if more than two actions are listed, then all actions are Incompatible with each other. Incompatibility constraints express binary collisions between decisions.

Incompatibilities can also occur if the same action is applied to different arguments. These incompatibilities must declare their arguments as part of their scope. In addition, the incompatibility constraint includes a conditional part that states different arguments. For example, the incompatibility of a loan classified in two different ways can be stated as follows: Constraint: Loan1 is set as a loan; Risk1 is set as a risk category; Risk2 is set as a risk category; if Risk1 is not equal to Risk2, The classification of Loan1 as Risk1 is incompatible with the classification of Loan1 into Risk2; see Figure 3, which shows a deployment diagram of computer system node 10 for the rule management system of the preferred embodiment. Computer system node 10 includes a computer system/server 12 that can operate with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 12 include, but are not limited to, personal computer systems, server computer systems, thin client, complex client, handheld Type or laptop device, multiprocessor system, microprocessor based system, set-top box, programmable consumer electronic device, network PC, mini computer system, large computer system, and including the above system or device A decentralized cloud computing environment, or the like.

The computer system/server 12 can be described in the general context of computer system executable instructions (such as a program module) being executed by a computer system. In general, a program module can include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Wait. The computer system/server 12 can be embodied in a decentralized cloud computing environment where tasks are performed by remote processing devices that are coupled via a communication network. In a distributed cloud computing environment, the program module can be located in both the local computer system storage medium including the memory storage device and the remote computer system storage medium.

The computer system/server 12 is in the form of a general purpose computing device. Components of computer system/server 12 may include, but are not limited to, one or more processors or processing units 16, system memory 28, and confluence of various system components including system memory 28 to processor 16. Row 18.

Busbar 18 represents any one or more of a number of types of busbar structures, including memory busbars or memory controllers, peripheral busbars, accelerated graphics, and processors using any of a variety of busbar architectures. Or regional bus. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) Bus, Micro Channel Architecture (MCA) Bus, Enhanced ISA (EISA) Bus, Video Electronics Standards Association (VESA) Area Bus and Peripheral Components Interconnect (PCI) bus.

Computer system/server 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server 12 and includes both volatile and non-volatile media, removable media and non-removable media.

System memory 28 can include computer system readable media (such as random access memory (RAM) 30 and/or cache memory 32) in the form of volatile memory. Computer system/server 12 may further include other removable/non-removable and volatile/non-volatile computer system storage media. Only as a real For example, a storage system 34 can be provided for reading and writing from non-removable, non-volatile magnetic media (not shown and commonly referred to as "hard disk drives") to non-removable, non-volatile magnetics. media. Although not shown, a disk drive for reading and writing to a removable, non-volatile disk (for example, a "floppy disk") to a removable or non-volatile disk can be provided, and A removable, non-volatile optical disc (such as a CD-ROM, DVD-ROM, or other optical medium) is read or written to a disc drive, non-volatile disc. In these examples, each can be connected to busbar 18 by one or more data media interfaces. As will be further depicted and described below, the memory 28 can include at least one program product having a collection of program modules (eg, at least one program module) configured to perform embodiments of the present invention. Features.

The rules management system 40 is stored in the memory 28.

The computer system/server 12 can also be in communication with one or more external devices 14, such as a keyboard, indicator device, display 24, etc.; one or more devices that enable a user to interact with the computer system/server 12. And/or any device (eg, a network card, data machine, etc.) that enables computer system/server 12 to communicate with one or more other computing devices. This communication can occur via the I/O interface 22. However, computer system/server 12 may be via network adapter 20 with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (eg, the Internet) Road communication. As depicted, network adapter 20 communicates with other components of computer system/server 12 via bus bar 18. It should be understood that although not shown, other hardware and/or software components may be utilized in conjunction with computer system/server 12. Examples include (but are not limited to): microcode, device drivers, redundant processing units, external disks Machine array, RAID system, tape drive and data archive storage system.

4 is a component diagram of the rules management system 40 of the preferred embodiment. The rules management system 40 takes as input a set of rules 50 and a set of definitions 52 of decisions (or a set of incompatibility constraints) and calculates a family of similar cases 54 with conflicting decisions. The rule management system 40 includes a processed case modeling tool 42; a rule set inference modeling tool 44; an action reasoner 46; a conflict detector 48; and a bad person storage area 49.

The components 40 through 49 shown in rectangular form in Figure 4 interact with the inputs and outputs 50 through 59 shown in ellipses in Figure 4.

The processed case modeling tool 42 transforms the rule set 50 input into a rule set applicability map 56 output, and the rule set applicability map 56 outputs processed cases that describe the set of rules in a compact logic and constraint based form. The processed case modeling tool 42 builds a constraint map that represents the processed cases and actions of the rule set in implicit form as a data tree structure with root nodes and child nodes connected by edges. The case and action are formed by logical expressions, and the processed case modeling tool 42 recursively traverses the logical expression of each rule in the set of rules containing the rules, and maps each of the accessed logical expressions to the figure One node. The processed case modeling tool 42 ensures a unique representation, i.e., mapping two occurrences of the same expression to the same graph node. The processed case modeling tool 42 maps original expressions such as numbers, string literals, and objects that are matched by rules to leaf nodes, and the processed case modeling tool 42 will attributes such as arithmetic operations, comparisons, and access objects. The compositional expression is mapped to an internal node, which is labeled by an operator and has an outgoing edge to the node representing its expression. table The leaf nodes showing the objects matched by the rules are renamed by the type and number of each rule to reduce the size of the map. For example, if a rule matches an object called a "loan," the modeling tool renames it to "Loan1." The processed case modeling tool 42 constructs a rule set applicability graph of the rule set by introducing a graph node, the graph node representing the conjunction of the test of the rule ("and" logical operation) and having nodes to represent the tests Outgoing edge. Finally, the processed case modeling tool 42 introduces the root node of the rule set applicability map 56, which represents the disjunction of different rule applicability maps and has outgoing edges to nodes representing such rule applicability maps. The "processed case" is a diagram showing the logical indication "true" or "false" of a graph node having logical operations considering other graph nodes. The case that has been processed is the case where the root node is marked by "true". The processed case modeling tool 42 only considers the conditions of the rules and does not consider the actions of the rules.

The rule set inference modeling tool 44 transforms the rule set 50 input into a rule set implicit map 58 output. The rule set implies that Figure 58 describes which actions are performed by which set of rules.

In the event that a given set of rules implies the input of the Figure 58 input and decision definition 52, the action reasoner 46 derives the output of the incompatibility constraint map 59 in this figure. Incompatibility Constraints Figure 59 is a constraint diagram depicting the incompatibility and constraints between actions occurring in a set of rules.

The conflict detector 48 uses the rule set applicability map 56, the rule set implied map 58, and the incompatibility constraint map 59 as inputs to calculate the family of cases 54 with conflicting decisions.

Maintaining a bad storage area 49 for discarding non-conflicting decisions A family of pieces and used to abandon families with cases that have recorded conflicting decisions. The second category of bad individuals permits the calculation of several families or all families of cases that are repeated and thus have conflicting decisions.

5 is an example rule set applicability map 56 established by the processed case modeling tool 42. The rule set applicability map 56 is used to describe cases processed by a set of rules in a compact logical form. The rule set applicability graph is a constraint graph that represents the disjunction of the applicability graph of the individual rules (ie, the rule applicability graph). The applicability chart of the rule states that there are objects in the case that are matched by rules and satisfy the conditions of the rule. The rule applicability graph thus represents the existence quantification of the logical formulation of the rule conditions. Figure 5 depicts a rule set applicability graph for the example rules d1, d2, d3, d4, c1. For readability, the diagram is somewhat simplified by omitting the condition that the variable "?Loan1" has a type loan.

6 is an example rule set implied graph 58 built by the rule set inference modeling tool 44. The instance rule set implied FIG. 58 is used to describe the action of the applicable rule to be performed by the rule set. The rule set implicit graph 58 is a constraint diagram showing the conjunction of the hidden graphs of the individual rules (d1, d2, d3, d4, c1). Implied graph description of the rule: For all objects in the case matched by the rule, if the matched object satisfies the rule condition, the rule action will be executed by the rule set. The implicit graph thus represents the implicit universal quantization represented by the implicit nodes of each rule. This logical formulation represents the action as a logical item, and the logical formulation uses the unary predicate "isDone" to indicate that the action is performed by the set of rules. For example, rule d1 has an implicit map stating: for all types of loans (see the connection from the d1 graph node "forall" to the graph node "?Loan1") (see node "forall") Object x, if x is a loan and the debt ratio of x is at most 35% and the amount of x is at most $600,000 (see the connection of the d1 graph node "isDone" and "accept" and the connection to the graph node "?Loan1"), the action "Accept" x". The implied residual arguments represent the logical formulation of the rule conditions (see the d1 graph node ">=" respectively connected to the graph node "35%" "liability ratio" and "$600k" "amount". The diagram is somewhat simplified by omitting the condition that the variable "?Loan1" has a type loan.

The rule set implied graph 58 is similar to the rule set application graph that models the action (unlike the rule set applicability graph of the embodiment of the invention in which the action is not modeled), but is also different in a subtle manner. The rule set application diagram describes that a rule applies and its actions have been performed, while the rule set implicit diagram describes the actions that will enforce the applicable rules. In the case of a given case, the rule set application graph states the action that will execute an applicable rule, while the rule set implicit graph statement will perform all applicable rule actions. The first statement models the actual decision making behavior of the rules engine as an applicable rule for this engine. This model of actual decision making behavior is important for redundant analysis. However, conflict analysis needs to apply a model of fictitious behavior of all applicable rules. This fictitious behavior reveals a conflict that remains hidden in the actual behavior of the rules engine.

The incompatibility constraint map 59 (also referred to as the constraint on the action diagram) is built by the action reasoner 46, which uses the decision definition 52 (which is also the specification of the incompatibility constraint). Input. The action reasoner 46 also receives the request from the conflict checker to check the compatibility of the given action on a case-by-case basis. The action reasoner 46 can also check the rule set implicit map to extract the phase Turn off the action to check. For example, the action reasoner 46 can receive three actions, namely "accept Loan1", "reject Loan1", and "classify Loan1 as high risk". The action reasoner 46 checks the compatibility constraints (or decision definitions) given before and determines that the action "accept Loan1" is incompatible with "reject Loan1". The action reasoner 46 thus creates an incompatibility constraint map that uses the predicate "isDone" to state that one of these actions cannot be performed. Therefore, this figure shows that "Do not" "accept" "Loan1" or not "go" and "reject" "Loan1".

The action reasoner 46 is also used to manage information about action statements and to use the information to compare compound actions, such as sequences of more basic actions. If the sequence of actions utilizes a variable to store the intermediate result of the calculation, then action reasoner 46 will replace the variables with intermediate results as necessary. If the action reasoner 46 must check the compatibility of two compound actions (such as "accept Loan1; classify Loan1 as high risk;" and "classify Loan1 as high risk; reject Loan1;"), action reasoner 46 Attempts will be made to transform these sequences of actions into appropriate forms for permitting comparisons. For example, the action reasoner 46 may reorder the basic actions of the first sequence into "classify Loan1 as high risk; accept Loan1;" because none of the basic actions affects another basic action. The action reasoner 46 can then detect that the reordered sequence of actions is incompatible with the second sequence of actions because the final elements of the sequence of actions are incompatible and the initial elements of the sequence of actions are the same.

Figure 7 is a component diagram of a collision detector 48 that includes interaction between components. The conflict detector 48 is used to implement a family that generates and tests methods to determine cases with conflicting decisions. Conflict detector 48 includes: processed case generator 482 and conflict checker 484.

The processed case generator 482 uses the rule set applicability map 56 to generate a family 70 of processed cases, i.e., a set of cases for which a certain rule in the set of rules is applicable. This family can be quite general and, for example, include all cases handled by some of the rules.

The conflict checker 484 then determines if the family contains only cases with conflicting decisions. The conflict checker 484 uses the rule set implicit graph 58 for this purpose, and the conflict checker 484 requests the action reasoner 46 for incompatibility constraints 59 regarding the actions that occur in this figure. If the conflict checker 484 is able to prove within the given time limit that the family of processed cases 70, the rule set implied map 58, and the join of the action incompatibility constraint 59 do not have any solution, the conflict checker 484 displays : Each of the families 70 of the processed cases has conflicting decisions. The conflict detector 48 thus returns this family 70 of processed cases as a result of the case 54 with conflicting decisions. However, if the conflict checker 484 is able to find a solution within a given time limit, the conflict checker 484 finds a case in the family of processed cases that does not have a conflicting decision. Conflict detector 48 seeks to eliminate this case and all similar cases that do not have conflicting decisions. For this purpose, the conflict checker 484 generalizes cases that do not have conflicting decisions to the family 72 of cases that do not have conflicting decisions, and the family 72 of cases that do not have conflicting decisions are described by a set of tests (or constraints), and The conflict checker 484 communicates the family 72 of cases that do not have conflicting decisions to the processed case generator 482. Inevitably, the family 72 of cases that do not have conflicting decisions is a subset of the corresponding family 70 of processed cases. In the preferred embodiment, the conflict checker 484 will have the case in place The family is considered a limited number of subsets and a subset of cases including those found cases that do not have conflicting decisions are selected. This subset becomes a family 72 of cases that do not have conflicting decisions.

The processed case generator 482 eliminates such cases by flagging the cases in the family 72 and the corresponding family of cases that do not have conflicting decisions. The bad family of the case is a family of banned cases. If the case violates at least one of the tests for the characteristic bad family, the case is not a bad family. The processed case generator 482 places the defective family of cases in the initially empty storage area 49. In calculating a new family of processed cases, the processed case generator 482 ensures that the case in the generated family is not in the bad person storage area 49, that is, none of the newly generated family cases are in the bad family. Either. If the processed case generator 482 does not find any new family of processed cases (since all of their families have been abandoned), then the method stops signaling: the family with the conflicting decision has not been found.

If one of these components reaches the time limit, a specific situation occurs. If the processed case generator 482 does not find any family of processed cases, then the entire method only stops, and does not report any family of cases with conflicting decisions. However, if the conflict checker does not find a case in a given family that does not have a conflicting decision, nor can it prove that there is no case without a conflict decision, the procedure can continue by discarding the entire family of the processed case.

Figure 8 illustrates an overview of the execution tracking steps of the collision detector for the set of rules given in Figure 1. The left row shows the stage of the family 70 of processed cases after the operation of the case generator 482 has been processed. Right line shows in conflict check The stage of family 72 of cases that do not have conflicting decisions after the operation of checker 484. Each operation consists in calculating a family of cases considering certain characteristics.

Figures 9 through 14 show the various operations of Figure 8 in more detail. In Figures 8 through 14, a portion of the case space defined by the conflict checker 484 or by the processed case generator is shown by the operation of the rounded rectangle delimitation.

Referring to the upper left diagram of Figures 9 and 8, the defective storage area 49 is initially empty, which means that the processed case generator 482 can generate any family of processed cases. In this example, the bad person storage area 49 determines the family of processed cases consisting of a single loan item Loan1. The family contains all cases in which the amount of the item is at most $600k and the debt ratio is at most 35%. This family of processed cases 70 can be described by the following test (or constraint): Loan1 amount up to $600k Loan1 debt ratio up to 35 %

Referring to the upper right diagram of FIGS. 10 and 8, the processed case generator 482 passes this description to the conflict checker 484. Because the conflict checker 484 can only consider cases in this family, all other areas in the case space are crossed out. The conflict checker 484 finds the following cases that do not have conflicting decisions and summarizes them as cases without conflicting decisions: Loan1 amounts up to $300k Loan1 has a debt ratio of up to 35 %

Referring to the left middle diagrams of Figures 11 and 8, the processed case generator 482 converts the family of cases without conflicting decisions into bad cases in order to discard all elements of the family. The abandoned family is indicated by cross-hatching and the following definitions: Loan1 amount is up to $300k and Loan1's debt ratio is up to 35 %

Next, the processed case generator 482 generates a new family of processed cases, the new family of processed cases meets the bad and therefore does not include any of the abandoned cases: Loan1 amount up to $600k Loan1 is greater than $300 k Loan1's debt ratio is up to 35 %

See the right middle figure in Figures 12 and 8. Upon communication to the conflict checker 484, the checker finds a new family 72 of cases that do not have conflicting decisions. Although the case in this family makes the two rules (ie, d1 and c1) applicable, the conflict checker can find a solution because the actions of these rules do not conflict: the amount of Loan1 is up to $600k Loan1 More than $300k Loan1's debt ratio is up to 30 %

See the lower left diagram in Figures 13 and 8. In addition, the conflict checker 484 sends the family to the processed case generator, and the processed case generator discards the family by creating a bad family. The abandoned family is crossed out and marked as a new bad family. The processed case generator 482 finds the third new family of the processed cases. 70: The amount of Loan1 is up to $600k. The amount of Loan1 is greater than $300k. The debt ratio of Loan1 is at most 35 % . The debt ratio of Loan1 is greater than 30 %.

Referring to the lower right diagram of Figures 14 and 8, the conflict checker 484 is not able to find cases in this family that do not have conflicting decisions. In fact, each of the cases in this family applies rules d1 and d2, and these rules perform incompatible actions "accept Loan1" and "reject Loan1". Thus, the system has found a family 56 of cases with conflicting decisions.

The preferred embodiment provides a logical description of the condition-action rules and incompatibilities between the actions of their rules, but another embodiment may use an induced inference engine to induce inference of such incompatibility constraints.

This induced inference embodiment will use the induced inference approach described in the article "Expressive policy analysis with enhanced system dynamicity" by Robert Craven et al. This operation finds conflicts between rules that express the access control principles of granting or rejecting actions. This approach expresses rules in a logical language and uses an inductive inference engine to find cases that both permit and dismiss an action. The induced reasoning engine therefore attempts to prove that the goal of an action is permitted and dismissed by completing the evidence space.

The inductive inference engine completes the evidence space, and the conflict detector completes the case space by solving a series of satisfiability problems. Depending on the nature of the problem, both the inductive inference engine and the collision detector may have their respective advantages. It should be noted that the principle of the inductive inference engine (ie, inference search) goes back to the article "R. Reiter and E. Minicozzi" published in the 1972 journal "Artificial Intelligence" "A Note On Linear Resolution Strategies in Consequence-Finding However, it is not known how to solve their problems by satisfying the satisfiability of the series. If there are many inconsistencies The latter approach has advantages if it is capacitively bound and if there are many cases with conflicting decisions.

Figure 15 is a block diagram of the processed case generator 482. The processed case generator 482 includes: a processed case pre-solver 485; an object generator 486; a processed case solver 487; and a case family extractor 488. The processed case generator 482 inputs the family 72 of the rule set applicability map 56, the bad person storage area 49, and (when supplied) cases that do not have conflicting decisions. If the family 72 of the case that does not have the conflict decision is supplied, the bad person generator 150 establishes the bad person map 152, and the bad person map 152 represents the disjunction of the test that constitutes the description of the family. The processed case generator 482 adds the bad person map 152 to the bad person storage area 49 before supplying the bad person map 152 to the processed case generator 482.

The processed case pre-solver 485 is used to build the rule execution individual suitability map 154 given a set of rule suitability maps 56. The purpose of this is to eliminate the presence quantifiers in the rule set applicability graph 56, whereby the presence of the quantized constraints is replaced by the disjunction of the free quantifier constraints. There is a quantitative constraint expression: the rule will match some of the items in the case that satisfy the rule condition. If the case consists of several items (ie, several loan requests named Loan1 and Loan2), then rules such as d1 will have two execution individuals. The first execution individual matches Loan1 and the second execution individual matches Loan2. If the enforcement entity for rule d1 of Loan1 handles the case or if the case is handled by the enforcement entity for rule d1 of Loan2, rule d1 will then process the case consisting of Loan1 and Loan2. The processed case pre-solver 485 handles the case with an execution individual for d1 of Loan1 or for Loan2 The statement that the execution entity of d1 handles this case replaces the statement of one of the individual execution cases of d1.

The object generator 486 creates a sufficient number of objects for each type by examining the rule categories (i.e., the number and type of objects matched by each rule). The object generator returns an object definition field 156, such as the domain {Loan1, Loan2}, which contains two objects of the type loan. The processed case pre-solver 485 then selects an object from the defined domain for each variable in which the quantization constraint exists, and instantiates the constraint by replacing each occurrence of the variable with the selected value. The processed case pre-solver 485 creates this execution individual for each combination that can be used to replace the value of the variable. The processed case pre-solver 485 then constructs the disjunction of all such execution individuals, and thus obtains a single rule rule execution individual suitability map. The processed case pre-solver 485 continues in this manner for all rules, and the overall rule execution individual suitability map 154 of the complete rule set is constructed by performing the extraction of the individual suitability map by the rules of the individual rules.

Since a case can have an infinite number of objects, only a limited number of objects are necessary for performing conflict rule analysis. Since it is sufficient to consider the conflict between the two rules, it is not necessary to analyze all the objects that appear in the case, but only the sufficient number to match the two rules. The object generator 486 checks each type of object that is matched by a certain rule and determines that the maximum number of items of this type is matched by rules. If all rules match a single item of the loan type, the maximum number of matches for the type of loan is 1. If there is a rule that matches two objects of type loan Then, the number is 2. The object generator 486 then needs to generate as many items of each type as indicated by this maximum number to ensure that each rule matches the object in the resulting object definition domain. To ensure that the two rules match different objects, the object generator 456 needs to produce twice the object, that is, the maximum number of doublings. This situation will ensure that the method is completed, but can significantly increase the number of enforced individuals of the constraint. The good principle is to start with a small collection of objects and perform an analysis on this small collection. Once completed, the method can be repeated for a larger set (the number of known objects is delimited by a doubling of the maximum number of rules matched to objects of this type).

Since the rules d1, d2, d3, d4, c1 all match a single loan object, it is sufficient to create a single loan object called Loan1 in the first stage and create an execution entity that quantifies the applicability constraint. The processed case pre-solver 485 will then replace all existing quantified applicability constraints and create a free quantifier rule execution individual suitability map in this manner.

The processed case solver 487 is used to mark the rule execution individual suitability map 154 such that the labels are consistent with the root node, taking into account the operations expressed in the graph. The processed case solver 487 uses known search and inference methods as defined in the constraint stylization and propositional theorem proving.

16 is an example of a free quantifier rule execution individual suitability map 154. The processed case generator 482 sends the rule execution individual suitability map 154 and the bad person map 152 to the processed case solver 487. If the processed case solver 487 does not find a consistent flag within the given time limit, then the entire analysis process is stopped and the collision detector signals that it has not found a conflicting decision in consideration of the bad person in the bad place storage area 49. Any family of cases. If already Processing case solver 487 finds a consistent flag, which then returns the resolved rule execution individual suitability map 158, as shown in FIG.

17 is an illustration of an individual suitability map 158 for a solved rule for the example of FIG.

The case family extractor 488 is used in the self-solving rule execution individual applicability map 158 to extract a family of similar cases. The extractor checks the child nodes of the root node and selects one of the child nodes labeled true. Since the root node represents disjunction, it is sufficient to find one of the true ones to ensure that the entire disjunction is true. The extractor then checks all the basic tests for the children representing the nodes of this disjunction. In the solved chart, the following tests are marked as true: Loan1's debt ratio is up to 35 % Loan1 is up to $600k

Any case that satisfies these tests will therefore ensure that the disjunction and hence the entire disjunction is marked as true. Therefore, any case that satisfies these tests is a processed case. Thus, the list of tests describes the family of cases 70 that have been processed, and the processed case generator 482 returns the family 70 of the processed cases as a result. If a bad person is given, the bad person needs to be handled in the same way, so that other tests are added to the family description. If one of the relevant tests is marked as false, then a negative is added to the case family description. Other principles for extracting a family of processed cases may process each test that appears in the solved graph and include the test or the negation of the test in the case family description. These principles will result in a more specific family and, as a result, different behavioral behaviors of conflict detectors.

Once the processed case generator 482 has calculated a new family of processed cases 70. The processed case generator 482 sends the new family 70 of processed cases to the conflict checker 484.

Figure 18 is a component diagram of the interaction of the conflict checker 484 and its major components. The conflict checker 484 includes: an object extractor 1802; a conflict pre-solver 1804; a non-collision map builder 1806; a non-conflicting graph calculator 1808; a conflict reporter 1810; a case family extractor and a summarizer 1812.

The object extractor 1802 is used to build an object definition field 1814 for all objects that appear in the family of processed cases. This object definition field 1814 is a subset of the object definition fields constructed by the processed case generator 482.

The conflict pre-solver 1804 is for using the object definition field 1814 to cause the rule set to imply all of the general quantization constraints in FIG. 58 to be instantiated. The conflict pre-solver 1804 selects a value from the object definition field 1814 for each variable of the quantization constraint, and then replaces all occurrences of the variable with the selected value, thereby generating a free quantifier execution individual of the rule implicit map. The conflict pre-solver 1804 generates an execution individual for each possible value assignment between the variable of the quantization constraint and the object definition field. Next, the pre-solver constructs the conjunction of the resulting individual to produce a single rule with a rule execution individual implicit map. The pre-solver processes all the rules in this manner, and then constructs a rule for each rule to perform the conjunction of the individual hidden graphs, thereby generating a rule execution individual implied graph 1816 for the entire set of rules.

The non-conflicting map builder 1806 is used to build the non-conflicting graph 1818, which is the conjunction of the processed case 70, the rule execution individual implied graph 1816, and the incompatibility constraint graph 59. An incompatibility constraint is requested to action reasoner 46. Non-conflicting graph 1818 then represents a processed case that does not have a conflicting decision All cases in a given family. The non-conflicting graph 1818 is submitted to the non-conflicting graph operator 1808.

The non-conflicting graphical calculator 1808 uses a search and inference method to find the label of the graph node that is true and considers the operation of the graph node. If the non-conflicting graphical calculator 1808 finds this indication, the non-conflicting graphical calculator 1808 returns the resolved non-conflicting graph.

19 shows an example of a non-conflicting graph that has been solved corresponding to the solution found for the operation in FIG. For the sake of readability, nodes representing families of processed cases have been omitted. The test of the case family description appears in the figure, and these nodes are directly marked as "true". This flag is marked because the indicator cannot be changed by the solver. Figure 19 is a diagram showing a solved non-conflicting graph of an example indication that cannot be changed by a thick dotted line mark.

Because the facts indicate that there are cases that do not have conflicting decisions, the conflict checker tries to discard the case and similar cases. For this purpose, the conflict checker verifies the true value of all nodes in the graph representing the basic test and not paying attention to the quantifier "isDone". The conflict checker generates a description of the conflict-free family of cases by including the test if the test is marked as "true" and by including a negative test in the case where the test is marked as "false." For Figure 19, this gives a description: Loan1's debt ratio is greater than 30 % Loan1's debt ratio is at most 35 % Loan1's debt ratio is up to 40 % Loan1's amount is up to $300k Loan1's amount is up to $600k Loan1's amount is up to $1000k

This family can be generalized by using consistency-based interpretation techniques (eg, by detecting sets of related tests in the description of the family and by relining other tests to summarize the family of missing cases). The correlation test forms the smallest set of tests that are inconsistent with the conjunction of the rule set applicability map. In order to achieve a similar reduction in cases that do not have conflicting decisions, the summarizer uses rules to enforce the negation of individual implicit maps. This step will allow the conflict detector to identify two related tests, ie: Loan1 amount up to $300k Loan1 debt ratio up to 35 %

The conflict checker then sends the family of cases that do not have conflicting decisions to the processed case generator, causing the processed case generator to discard the family of cases that do not have conflicting decisions. If no generalization is used, the processed case generator will discard the smaller set of cases, which means that more families need to be repeated to find the family of cases with conflicting decisions, but this does not affect the overall outcome of the method.

20 is a second, resolved, non-conflicting map of the program depicted in FIG. In this figure, the two node predicates marked by "isDone" are marked as "true", that is, the node indicating "accepting Loan1" and the node "classifying Loan1 as high risk". However, because these actions are compatible, it is determined that there is no conflict.

Figure 21 is a non-conflicting diagram for the last iteration depicted in Figure 14. The following families of processed cases are given as input in this step: Loan1 amount up to $600k Loan1 amount is greater than $300k Loan1's debt ratio is up to 35 % Loan1's debt ratio is greater than 30 %

Figure 21 is a diagram indicating the test, which is marked as "true" and because the indication cannot be changed by the non-conflicting graphical calculator, the indication is marked by a thick dotted line. In order to mark the root node of the graph as "true", the nodes in the graph must be marked as indicated. However, this label violates the incompatibility constraint that states that "Do not accept Loan1" must be marked as "true" or "no rejection of Loan1" must be marked as "true". Since these nodes are marked "false" and have not been selected to derive this indication, the non-conflicting map in Figure 21 does not have a solution. Therefore, a given family of cases that have been processed contains only cases with conflicting decisions. Thus, the conflict checker has found a family of cases with conflicting decisions and returns a description of the family of cases with conflicting decisions as a result.

The rule maker can then type in the rules that impose higher priority on the family to process. For example, rule-makers may decide to reject loan requests for their case: Rule Arbitrator 1 defines Loan1 as a loan, if Loan1 amounts up to $600k and Loan1 amounts greater than $300k and Loan1's debt ratio is at most 35 % and Loan1's debt ratio greater than 30 % rejects Loan1; rule-makers can also split the family of conflict cases into a subset of accepted loans and another subset of rejected loans. Therefore, reported cases with conflicting decisions contain basic information for conflict resolution. Rule-makers can therefore resolve conflicts by writing new rules with higher priority, and this does not require lengthy investigations and modifications to existing rules. This promotes and simplifies the entire conflict resolution process. Conflict resolution is achieved here by formulating specific decisions (and rules) for key cases, rather than by resolving conflict rules.

The entire method can be repeated to find other families with conflicting decisions. For this purpose, the overall system creates a bad person who eliminates families with conflicting decisions and adds bad people to the bad person storage area. The collision detector will then be able to find new families with conflicting decisions. Finally, the collision detector will no longer find any of this family and the method stops.

Other embodiments of the invention are now described.

It will be apparent to those skilled in the art that all or a portion of the method of the preferred embodiments can be suitably and usefully embodied in one or more additional logic devices including logic elements configured to perform the steps of the method, and Equal logic elements can include additional hardware components, firmware components, or a combination thereof.

It will be equally apparent to those skilled in the art that some or all of the functional components of the preferred embodiments may be suitably embodied in one or more alternative logic devices including logic elements for performing equivalent functionality using equivalent method steps. And such logic elements can include several components, such as, for example, a logic gate in a programmable logic array or a special application integrated circuit. These logic elements Further embodied in an enabling component for temporarily or permanently using a virtual hardware descriptor language, such as a virtual hardware descriptor language that can be stored and transmitted using a fixed or transportable carrier medium, in the array or circuit Establish a logical structure.

It will be appreciated that the methods and configurations described above may also be suitably implemented, in whole or in part, in software executing on one or more processors (not shown), and may be carried on, for example, a magnetic disk. The software is provided in the form of one or more computer program components on any suitable data carrier (not shown) of the optical disc or the like. Likewise, the channels for data transmission can include all of the described storage media as well as signal-carrying media, such as wired or wireless signal-carrying media.

The present invention can be further suitably embodied as a computer program product for use in a computer system. This embodiment may comprise a series of computer readable instructions either affixed to a tangible medium such as a computer readable medium (eg, magnetic disk, CD-ROM, ROM or hard disk) or may be used with data And other interface devices for transmission to a computer system on tangible media including, but not limited to, optical or analog communication lines, or intangible use including, but not limited to, microwave, infrared or other transmission technologies Conducted by wireless technology. The series of computer readable instructions embody all or part of the functionality previously described herein.

Those skilled in the art will appreciate that such computer readable instructions can be written in a number of programming languages for use with many computer architectures or operating systems. In addition, any memory technology including (but not limited to) semiconductor memory technology, magnetic memory technology or optical memory technology can be used (current or Future instructions to store such instructions, or any communication technology (current or future) including, but not limited to, optical communication techniques, infrared communication techniques, or microwave communication techniques may be used to transmit such instructions. It is contemplated that the computer program product can be distributed as removable media with accompanying printed or electronic files (eg, compressed packaging software) that can be preloaded into, for example, the system ROM by a computer system or On a fixed disk, this computer program product can be distributed from a server or bulletin board on a network (for example, the Internet or World Wide Web).

In an alternative, a preferred embodiment of the present invention can be implemented in the form of a computer implemented method of deploying a service, the computer implemented method comprising the steps of deploying a computer code operable to be deployed in a computer infrastructure and Execution on the computer infrastructure causes the computer system to perform all steps of the method.

In another alternative, a preferred embodiment of the present invention may be implemented in the form of a data carrier having functional data for containing the computer when loaded into a computer system and operated by the computer system The system is capable of performing a functional computer data structure for all steps of the method.

It will be apparent to those skilled in the art that many modifications and changes may be made to the foregoing exemplary embodiments without departing from the scope of the invention.

10‧‧‧Computer System Node

12‧‧‧Computer System/Server

14‧‧‧External devices

16‧‧‧Processor or processing unit

18‧‧‧ Busbar

20‧‧‧Network adapter

22‧‧‧I/O interface

24‧‧‧ display

28‧‧‧System Memory

30‧‧‧ Random Access Memory (RAM)

32‧‧‧Cache memory

34‧‧‧Storage system

40‧‧‧Rules Management System

42‧‧‧Processed case modeling tools

44‧‧‧ rule set inference modeling tool

46‧‧‧Action Reasoning Machine

48‧‧‧Clash detector

49‧‧‧Understanding storage areas

50‧‧‧ rule set

52‧‧‧Definition of decision

54‧‧‧ Cases with conflict decision-making

56‧‧‧ rule set applicability map/family with cases of conflict decision

58‧‧‧ rule set implicit map

59‧‧‧Incompatibility Constraints

70‧‧‧The family of cases that have been processed

72‧‧‧Families without cases of conflict decision-making

150‧‧‧ Bad Producer

152‧‧‧ Bad map

154‧‧‧ rule implementation individual suitability map

156‧‧‧object definition domain

158‧‧‧Resolved rule execution individual applicability chart

482‧‧‧Processed case generator

484‧‧‧Clash Checker

485‧‧‧Processed case pre-solver

486‧‧‧ Object Generator

487‧‧‧ handled case solver

488‧‧‧ Case Family Extractor

1802‧‧‧ Object Extractor

1804‧‧‧ conflict pre-solver

1806‧‧‧ Non-conflict map builder

1808‧‧‧ Non-conflicting graphic calculator

1810‧‧‧Crisis Reporter

1812‧‧‧ Case Family Extractor and Generalizer

1814‧‧‧Object Definition Domain

1816‧‧‧ rule execution individual implied map

1818‧‧‧ non-conflict map

1820‧‧‧No solution

1822‧‧‧Solved rule set applicability map

Figure 1 is a table providing examples of rules for making conflict decisions for certain cases; Figure 2 is a state diagram for two-dimensional case space drawing rules with a loan amount axis and a liability ratio axis; 3 is a component diagram of a preferred embodiment; FIG. 4 is a component diagram of a rule management system of a preferred embodiment; and FIG. 5 is a diagram showing a suitability of a rule set for a case processed by a rule set in a compact logical form. Figure 6 is a block diagram of a rule set for describing the action of the applicable rule to be executed by the rule set; Figure 7 is a component diagram of the conflict detector including the interaction between the components; Figure 8 is for Figure 1 An overview flow chart of the execution tracking steps of the conflict detectors of the rule set is given; FIG. 9 to FIG. 14 show each of the tracking steps of FIG. 8 in more detail; FIG. 15 is a component diagram of the processed case generator; FIG. The free quantifier rule performs an example of the individual suitability map 154; FIG. 17 is a diagram of the individual suitability for the solved rule for the example of FIG. 16; FIG. 18 is a component diagram of the conflict checker including the interactive stream; The solved non-conflicting graph of the example of FIG. 10; FIG. 20 is a non-conflicting graph for the example of FIG. 12; and FIG. 21 is a non-conflicting graph for the example of FIG.

Claims (15)

A method for managing conditional action rules in a set of rules, comprising: constructing a family of cases in which some of the rules in the set of rules apply; repeatedly establishing and testing the family for cases with conflicting decisions A subset of cases to locate a subset of cases that all have conflicting decisions. The method of claim 1, further comprising eliminating a subset of cases having all non-conflicting decisions. The method of claim 1 or 2, wherein the family of the case and the subset are modeled using a constraint-based technique. The method of claim 1 or 2, further comprising distinguishing between conflicting decisions and irrelevant decisions, and thus avoiding reporting of false conflicts. The method of claim 1 or 2, further comprising defining a subset of the cases with conflicting decisions such that a new rule uses the definition and eliminates the conflict. A method for managing conditional action rules, comprising: determining compatible and incompatible actions of rules in a rule set; establishing a test family for testing one of at least one rule in the set of rules; determining a compatible subset of the family's case such that the applicable rules applying the subset only result in a compatible action; the determination of such cases from families not in the compatible subset a test subset whereby one or more of the cases in the test subset have a likelihood of conflicting actions with the rules in the set of rules; and all such cases in the test subset have In the case of a conflicting action, the test subset is determined to be a conflicting subset, otherwise, a new decision family having one of the test subsets is executed and a new compatible subset and a new test subset are repeatedly determined until one The new test subset is judged to be a conflict. The method of claim 6, wherein the family of the case and the subset are constructed using a constraint model of the rules in the set of rules. The method of claim 6, further comprising compiling a conflicting subset of the case and a report of the conflicting action. The method of any one of clauses 6 to 8, wherein each family and subset is characterized by a primitive condition from the set of rules. The method of claim 6, further comprising determining at least one arbitrator rule for adding to the set of rules to resolve the conflicting actions regarding the cases in the conflicting subset. A system for managing conditional action rules, comprising: a processed case modeling tool for constructing a family of cases for which some rules apply; a conflict detector for targeting conflicting decisions The case repeatedly builds and tests a subset of the family's cases in order to locate a subset of cases that all have conflicting decisions. The system of claim 11, wherein the conflict detector is further adapted to Used to eliminate subsets of cases with all non-conflicting decisions. The system of any one of clauses 11 to 12, wherein the conflict detector is further adapted for distinguishing between conflicting decisions and irrelevant decisions, and thus avoiding reporting of false conflicts. A computer program product comprising a computer readable recording medium having stored thereon a computer readable program code for detecting a case by conflicting rules, the computer readable code being loaded onto a computer system And when executed, perform the following steps: build a family of cases that apply some rules; repeatedly build and test a subset of the family's cases, search for cases with conflicting decisions to locate one of the cases with conflicting decisions Subset. A computer program stored on a computer readable medium and loadable into an internal memory of a digital computer, the computer program being included for execution in the request items 1 to 4 when the program is executed on a computer The software code portion of any of the methods.