Driving an interactive decision service from a forward-chaining rule engine

Disclosed techniques include generating a plurality of questions, each question based upon one or more conditions of a plurality of conditions, wherein the plurality of conditions are generated a plurality of business rules associated with a forward changing rule engine; identifying, as a side effect of evaluating the plurality of business rules for outcome data, missing information corresponding to the plurality of questions; and selecting, for presentation to a user, a first question of the plurality of questions to elicit the missing information from the user.

FIELD OF DISCLOSURE

The claimed subject matter relates generally to interactive decision services and, more specifically to techniques for selecting questions within an interactive decision service.

BACKGROUND OF THE INVENTION

Interactive decision services, such as but not limited to self-service kiosks and interactive voice response systems, are defined here as computer applications that involve a human user in an interactive dialog before arriving at a decision. These computer applications need to determine which question or set of questions to ask next, given a partial set of input data. Techniques for determining which question to ask next may range from very simple (for example, a predetermined sequence for a survey) to very complex (for example, when hundreds of complex business policies determine how to handle a refund request based on a number of different factors).

Currently, there are some techniques for addressing the situation. One such technique employs a decision tree like structure for the question flow, encoded in databases and/or procedural code. When this decision tree gets large or complex, a specialized tool may be used, such as FlexRiver's Flex Dynamic Questionnaire. There are rule-based techniques, which may fall into two categories:

1) Expert system shells, such as EXSYS's Corvid, which essentially use rules to build one or more decision trees (logic blocks) and use backward chaining in a depth-first or breadth-first manner to determine questions to ask.

2) Forward-chaining rule based approaches, such as Exsys Corvid's Smart Questionnaire and IBM's Dynamic Forms using WebSphere Operational Decision Management, which use explicit question generation rules. These rules may use positive logic (e.g. If answer to Q1 is A1 and question Q2 has not been answered then ask question Q2) or negative logic (e.g. if answer to question Q1 is A1, then remove Q3 from predetermined question flow).

SUMMARY

Provided are techniques for interactive decision services and, more specifically to techniques for automatically generating next question(s) within an interactive decision service while processing regular business policies. Disclosed techniques include generating a plurality of questions, each question based upon one or more conditions of a plurality of conditions, wherein the plurality of conditions are generated a plurality of business rules associated with a forward changing rule engine; identifying, as a side effect of evaluating the plurality of business rules for outcome data, missing information corresponding to the plurality of questions; and selecting, for presentation to a user, a first question of the plurality of questions to elicit the missing information from the user.

DETAILED DESCRIPTION

As the Inventors herein have realized, the techniques discussed above in the Background may be sufficient when a problem domain is simple. However, as the complexity of business rules go up, cracks are exposed. A complex domain is one in which a large number of business policies do not fit compactly into a single decision tree. In fact, a complex domain can be thought of as a number of loosely coupled, partial decision trees; more like an acyclic decision graph. Decision trees may share questions but be otherwise disjoint. Decision trees may also be partial, i.e., there is no guarantee that answering the questions constituting the decision tree will lead to an outcome. In such a case, control needs to shift to another decision tree to continue the question flow. Aforementioned forward chaining approaches do not handle this scenario. Moreover, any approach that attempts to force fit complex business policies into a decision tree has several drawbacks, which include:

1) Difficult to build: building a decision tree representation can require a lot of initial analysis of business policies. Sometimes, there is a natural business ordering to the questions, while at other times, the ordering is ad-hoc. For questions that do not have a natural dependency, a business subject matter expert (SME) may prioritize them. Priority or weightage may be assigned based on a number of factors such as likelihood of the question being relevant, likelihood of the question leading to an outcome, difficulty in answering the question, likelihood of it being present in the input data because of extraction from a data source, etc. However, since the way a decision tree typically captures prioritization is through tree links, the resulting tree can be very complex.

2) Difficult to maintain: a decision tree representation is brittle in that a small change to a business policy can lead to a large change to the decision tree structure. This makes it hard to maintain, especially considering that the ad-hoc policies described in (1) are likely to change over time.

3) Inability to deal with unsolicited, non-sequential data: a decision tree traverses down the tree as it receives answers to questions in the tree. If there is an unsolicited answer (for example when a client extracts it from its data source), the answer can only be used after the decision tree has traversed to the corresponding node. Therefore, even if this unsolicited data is sufficient in arriving at an outcome and no more questions are necessary, the decision tree will continue to ask spurious questions.

4) Difficult to deal with skipped questions: to allow end user to skip a question, the decision tree must explicitly represent SKIPPED as an answer to the question.

A backward chaining approach can use regular business rules to generate rules. However, this approach does not offer a rich selection capability from multiple candidate questions. Therefore, what is needed are techniques for generating questions without sacrificing the natural representation of business rules while offering a rich mechanism for conflict resolution if multiple candidate questions are available. This disclosure explains a novel technique for doing just this—generating questions by a regular forward chaining rule engine without the need for explicit question generation rules while offering rich conflict resolution strategies.

Turning now to the figures,FIG. 1is a block diagram of an example of a computing system architecture100that may support the claimed subject matter. A computing system102includes a central processing unit (CPU)104, coupled to a monitor106, a keyboard108and a pointing device, or “mouse,”110, which together facilitate human interaction with computing system100and computing system102. Also included in computing system102and attached to CPU104is a computer-readable storage medium (CRSM)112, which may either be incorporated into computing system102i.e. an internal device, or attached externally to CPU104by means of various, commonly available connection devices such as but not limited to, a universal serial bus (USB) port (not shown). CRSM112is illustrated storing an operating system (OS)114and an Extended Interactive Decision Service (EIDS)116. EIDS116includes an Extended Rete Rule Engine (ERRE)117and a Question Selection Module (QSM)118that implement the claimed subject matter. Although in this example ERRE117and QSM118are illustrated as included in EIDS116, ERRE117and QSM118may also be standalone components that communicate with each other and EIDS116. It should be noted that a typical computing system may include many applications, but for the sake of simplicity only EIDS116, ERRE117and QSM118are shown. Components116,117and118represent components of an Enhanced Interactive Decision service that provide a flexible, robust and easily maintained business information service. Components116,117and118are described in more detail below in conjunction withFIGS. 2-8.

Computing system102and CPU104are connected to the Internet130, which is also connected to a client computing device, or simply “client.”132. Client132is coupled to a CRSM134, which stores logic associated with a rule client136that executes on client132interacts with EIDS116in accordance with the disclosed technology. Although not shown, client132would also typically include a CPU, monitor, keyboard and mouse for human interaction Although in this example, computing system102and client132are communicatively coupled via the Internet130, they could also be coupled through any number of communication mediums such as, but not limited to, a local area network (LAN) (not shown). Client132is used in the following examples as a one possible device from which a user may interact with EIDS116, ERRE117and QSM118. It should be understood that there are many devices that may enable such access such as, but not limited to, a kiosk, a smart phone, a user terminal and so on. Further, it should be noted there are many possible computing system configurations, of which computing system architecture100is only one simple example.

FIG. 2is a block diagram illustrating high-level operation of ERRE117, first introduced in conjunction withFIG. 1. ERRE117employs forward chaining, of which one particular method is a Rete algorithm. A Rete algorithm is based upon network of nodes in which each node, except a root node, corresponds to a pattern of conditions. A path from the root to a particular node defines a complete set of rule conditions. As a new fact is asserted or modified, it propagates through the network such that the fact is noted at each node in which the fact corresponds to a condition. When all the conditions in a particular rule are satisfied, the corresponding action is triggered.

ERRE117receives input, typically in the form of answered questions or the results of actions from rule client136(FIG. 1), and is invoked by EIDS116, first introduced in conjunction withFIG. 1. In this example, ERRE117includes a rueleset140, a working memory170and an agenda180. Ruleset140is shown with a few rules, i.e., a rule_1141, a rule_2142and a rule_3143. It should be understood that ruleset140would typically contain more than three rules but for the sake of simplicity only three are shown. Rules141-143are each associated with sets of conditions, i.e., a cond_1151, a cond_2152and a cond_3153, respectively, and a set of actions that are implemented when the corresponding conditions151-153are satisfied, i.e., an act_1161, an act_2162and an act_3163, respectively. Each of conditions151-153may have one or more individual conditions.

As answers to questions or the results of actions are received from EIDS116, the answers and results are entered into working memory170and are correlated by QSM118(FIG. 1) with domain objects, i.e., an object)171and an object_2172in this example. Objects171and172are correlated with individual conditions (not shown) of conditions151-153. This is termed as pattern matching in a Rete network. When an object171and172correspond to a particular individual condition, a match is generated. In this example object_1171corresponds to a particular condition of cond_1151 of rule_1141, thus generating a match_191. In a similar fashion, example object_2172corresponds to a particular condition of cond_2152of rule_2142, thus generating a match_2192. It should be understood that each object may correspond to conditions in multiple rules141-143. When all the individual conditions of a particular rule141-143are satisfied, the corresponding action or actions151-153are entered into agenda180. In this example, cond_1151of rule_1141is completed and a rule_1 action181is entered into agenda180. Cond_2152of rule141is also completed and a rule_2 action182is also entered into agenda180. QSM118and the generation and interaction of rules, conditions, and actions is explained in more detail below in conjunction withFIGS. 3-8. Simply stated, QSM118extends the Rete network processing of ERRE117by intercepting the pattern matching activity.

FIG. 3is a block diagram of QSM118, first introduced above in conjunction withFIG. 1, in more detail. QSM118includes a data module204, a Request Facade206, a Candidate Tracker208and Question Selection Logic (QSL)210. For the sake of the following examples, logic associated with QSM118is assumed to be stored on CRSM112(FIG. 1) execute on one or more processors (not shown) of CPU104(FIG. 1) of computer102(FIG. 1). It should be understood that the claimed subject matter can be implemented in many types of computing systems and data storage structures but, for the sake of simplicity, is described only in terms of computing system102and system architecture100(FIG. 1). Further, the representation of QSM118inFIG. 3is a logical model. In other words, components204,206,208and210may be stored in the same or separates files and loaded and/or executed within architecture100either as a single system or as separate processes interacting via any available inter process communication (IPC) techniques. For the sake of an example, data module204is illustrated as distinct from processing elements206,208and210although those with skill in the appropriate arts will appreciate that QSM118and ERRE117(FIGS. 1 and 2) may be implemented using object-oriented techniques in which data and behavior, or executable logic, are typically combined into objects.

Data module204is a data repository for information that QSM118requires during normal operation. Examples of the types of information stored in data module204include questions214, question sets216, candidate questions218, QSM run logic220and operating parameters224. Questions214stores potential questions that may be selected and asked in accordance with the disclosed technology. For the sake of the following examples, seven (7) questions are described, Q1-Q7511-517(seeFIG. 8).

The following is a table of sample questions that are used as examples in the following description and figures and is representative of information stored in Questions214:

It should be noted that the questions, and the information stored in conjunction with each question, are listed for the purposes of example only. A typical system would include many more questions and/or, depending upon the application, different questions and information.

In this example, “Question Number” (Q. No.) identitfies a particular question, “Label” identifies a question with text, “Text” provides the actual question and “Choices” identifies potential outcomes that might depend upon specific answers (see OC1-4521-514,FIG. 8). “Question Type” (Q. Type) specifics a particular form that an answer to the corresponding question may take. For example, an answer may be a Yes/No answer (Y/N), a floating point number (DBL.), text (TEXT) or a date (DATE). “Selection Type” (S. Type) further identifies the form that an answer may take. For example, an answer and be “Single Select” (SS) or “free form” (FF). The “Weight” column associates a numerical weight value to each corresponding question. Although not shown, questions214also includes information on reference counts, explained below. Question weights and the selection of particular questions are explained in more detail below in conjunction withFIGS. 4-8.

The following is a table of sample question sets that are used as examples in the following description and figures and is representative of information stored in Question Sets216:

Typically, questions are organized into question sets such that each question set is related to a particular business domain or issue. For example, there might be one question set for refund requests, a second set for credit requests and a third to gather demographic data. It should be noted that the described question sets, and the information stored in conjunction with each question set, are listed for the purposes of example only. A typical system would include many more question sets and/or, depending upon the application, different question sets and information.

In this example, “Question Set Number” (QS. No.) identifies a particular question set, “Weight” associates a numerical weight value with each question set and “Questions” specifies the particular questions that are part of the corresponding question set. “Strategy” identities a particular strategy associated with each question set. For example, “WEIGHTED” specifies that the weights of questions should be employed in calculations to determine the next question, “FIRST” that the first applicable question should be asked, “FIRST_IF_NOT_DONE” that the first applicable question should be asked unless an outcome has already been reached and “ALL” that all applicable questions should be asked. Another possible strategy may include, but is not limited to, “WEIGHTED_MIN/MAX_REF” that specifies the question with the lowest/highest reference count, which is the number of times this candidate is used by the Rete network during pattern matching, should be asked, possibly using weight as a tie-breaker. “SKIP_ALLOWED” specifies whether or not questions may be skipped. The use of the fields of the Question Set table is explained in more detail below in conjunction withFIGS. 3-8.

Candidate questions218is employed to keep track of questions that, during processing, are identified as potentially the next question or group of questions to be asked. The identification of particular questions214that are included in candidate questions218is described in more detail below in conjunction withFIGS. 4-8. QSL run logic220stores the logic necessary for the execution of QSM118. Operating parameters224stores user configurable parameters that control the operation of QSM118. Examples of such parameters include, but are not limited to, the location of log and data files.

Request Facade206exposes questions and answers as domain attributes and values, thereby intercepting all pattern matching activity from the Rete network when matching against domain data. Request Facade206notifies Candidate Tracker208whenever an unanswered question is used by the Rete network. Candidate Tracker208tags this as a potential candidate for the next question (Candidate Question). Candidate Tracker208keeps track of two dynamic properties of a candidate: 1) the sequence number, or ‘ordinal ranking’ of this candidate question which indicates the temporal sequence number of this candidate among other candidates and 2) the ‘reference count’, or the number of times this candidate is used by the Rete network during pattern matching. If during rule processing no outcome is reached, then QSL210selects the next question from the set of candidate questions by using these dynamic properties in addition to the static properties such as user-defined weightage associated with the question.

Request Facade206handles answers to questions transmitted to ERRE117. In other words, during the evaluation of rule conditions during Rete processing, ERRE117requests from request facade206a state of a question and, based upon the data stored in working memory170returns an evaluation of the question. For example a question may evaluate to “TRUE,” “FALSE” or “NOT EVALUATED.” ERRE117employs the returned state to evaluate the corresponding condition. Request facade206also registers the question with candidate tracker208, which keeps track of potential next questions to be asked in response to each question. In addition, candidate tracker208maintains reference counts (see551and552,FIG. 8) corresponding to each candidate question that indicate how many times a particular question has been used during rule engine processing. Reference counts factor into the disclosed question selection process. Further, candidate tracker208is responsible for determining an ordinal ranking corresponding to each candidate question. Ordinal rankings are essentially the ordering of candidate questions in the sequence that are used by ERRE117during rule evaluation.

QSL210stores logic for the evaluation of question with respect to weights and reference numbers. QSL210also selects a next question to present to a user if necessary based upon evaluation of questions in candidate tracker208. Components204,206,208,210,214,216,218,220,222and224are described in more detail below in conjunction withFIGS. 4-8.

FIG. 4is a block diagram illustrating high-level operation of QSM118. QSM run logic220(FIG. 3) processes answered questions232, skipped questions234and applicable (appl.) question sets236to produce next questions242and potentially question set (QS) outcomes244if all conditions of a particular rule have been satisfied. To perform these functions, QSM118has access to data module204(FIG. 3) and questions214(FIG. 3) and question sets216(FIG. 3) stored within data module204. Although not shown next questions242are stored in conjunction with candidate questions218(FIG. 3) of data module204.

FIG. 5is a flowchart of one example of a Setup ERRE process300that may implement aspects of the claimed subject matter. Process300is typically implemented by an administrator, programmer or business user in conjunction with the initial setup of ERRE117(FIGS. 1 and 2).

Process300starts in a “Begin Setup ERRE” block302and proceeds immediately to a “Generate Question Sets and Questions” block304. During block304, each individual condition (not shown) of conditions151-153typically forms the basis of a question stored in questions214(FIG. 3). In addition, questions are organized into question sets216(FIG. 2) based upon each questions relevance to a particular business problem. Questions and question sets may be built using decision tables typically found in current Business Rules Management Systems (BRMSs). It should be understood that any particular question may be relevant to multiple question sets216and rules141-143. For example, a question about payment type might be relevant to question sets related to both a purchase of a product and the processing of a refund.

During processing associated with a “Generate Rule Vocabulary From Questions” block306, business object methods are built for request facade206(FIG. 3). Business object methods correspond to the questions and are verbalizations of the methods so that they may be used as the vocabulary for writing business rules. For example, a ‘getPurchaseAmount’ method that returns the answer to question Q2, “What was amount of purchase?” described above in the input data may be defined in request facade206. In addition, ‘getPurchaseAmount’ method may be associated with a suitable business verbalization, such as “the purchase amount,” for use in rules by business users. It is preferable to automate this process, although it is also possible for a programmer to manually generate the rule vocabulary from Questions214(FIG. 3).

During processing associated with a “Code Business Rules Using Rule Vocabulary” block308, business users or programmers generate business rules by employing the verbalizations generated during processing associated with block306. During processing associated with an “Identify Question Selection Strategies” block310, business users or programmers generate business election strategies and overrides using the business rules generated during processing associated with block310. Finally, control proceeds to an “End Setup ERRE” block319in which process300is complete.

FIG. 6is a flowchart of one example of an Evaluate Conditions process350that may implement aspects of the claimed subject matter. In this example, logic associated with process350is stored on CRSM112(FIG. 1) as part of EIDS116(FIGS. 1 and 2) and executed on one of more processors (not shown) of CPU104. The selection of an initial question or questions depends upon an determination of the relevant question set214and defined question selection strategies (see310,FIG. 5).

Process350starts in a “Begin Evaluate Conditions” block352and proceeds immediately to a “Receive Answer(s) or Outcome(s)” block354. During processing associated with block354, EIDS116receives an answer to a question or questions presented to a user that have been transmitted by rule client136(FIG. 1). It should be understood that multiple questions may be asked at a time and that potential replies might include an relevant answer or the answer may be incomplete or skipped.

During processing associated with an “Update Working Memory” block356, ERRE117(FIGS. 1 and 2) is instantiated an working memory170(FIG. 2) is updated with objects such as objects171and172(FIG. 2) based upon the answer or answers received. In other words, working memory170stores a current state of information relating to the ongoing EIDS session. During processing associated with an “Initiate Rete Update” block358, ERRE117processes the answer or answers with respect to ruleset140(FIG. 2) in a typical Rete fashion.

During processing associated with an “Evaluate Conditions” block360, objects171and172are correlated to conditions151-153(FIG. 2) of rules141-143(FIG. 2) to potentially produce matches191-192(FIG. 2), which may or may not result in the placement of actions such as actions181and182(FIG. 2) into agenda180(FIG. 2). During processing associated with an “Update Candidate Questions” block362, each time a match between a question and a condition is identified one or more candidate questions may be identified. For example, a determination that a purchase price was over a threshold amount may lead to additional questions concerning payment type while, in contrast a low purchase price may lead to an automatic refund. Identified questions, or a reference to identified question or questions, are stored in candidate questions218(FIG. 3). In addition, information relating a reference count and to any weight assigned to a question or corresponding question set are stored in conjunction with each question.

During processing associated with a “Conditions (Cond.) Met?” block364, a determination is made as to whether or not all individual condition associated with any of rules141-143have been met. If so, control proceeds to a “Place Rule Action in Agenda” block366. During processing associated with block366, the action161-163corresponding to the conditions151-153that have been met are placed in agenda170for implementation and processed in accordance with standard action procedures.

If, during processing associated with block364, a determination is made that no conditions151-153have been successfully completed, control proceeds to an “Initiate Question Selection” block368. During processing associated with block368, a question selection procedure is initiated (see400,FIG. 7). Once a rule has been placed in agenda170during processing associated with block366or a question selection process has been initiated during processing associated with block368, control returns to block354and process350waits for the next question or outcome to be received and processing continues as describe above.

In the manner described above, question selection becomes a byproduct of standard Rete processing rather than a completely separate process. Finally, process350is halted by means of an interrupt378, which passes control to an “End Evaluate Conditions” block379and process350is complete. Interrupt378is typically generated when OS114(FIG. 1), EIDS116or computing system102is halted. During normal operation, process350continuously loops through the blocks354,356,358,360,362,364,366and368, processing answers and outcomes as transmitted by rule client136.

FIG. 7is a flowchart of one example of a Question Selection process400that may implement aspects of the claimed subject matter. Like process350, in this example, logic associated with process400is stored on CRSM112(FIG. 1) and executed on one of more processors (not shown) of CPU104. In addition, process400is associated with QSM118(FIGS. 1-4).

Process400starts in a “Begin Question Selection” block402and proceeds immediately to an “Apply Selection Strategy to Candidate Questions” block404. During processing associated with block404, reference counts and weights associated with questions collected during processing associated with the evaluation of conditions (see350,FIG. 6) are processed to determine a next question or questions to be asked. The specific manner in which weights and reference counts employed to make such a determination are based upon operating parameters224(FIG. 3) and the established rules and policies associated with question selection strategies (see310,FIG. 5).

During processing associated with a “Return Selected Question(s) to EIDS” block406, the question or questions selected during processing associated with block404are returned to EIDS117(FIGS. 1 and 2) for transmittal to rule client136(FIG. 1). During processing associated with a “Rule Client Asks Questions” block408, the question or questions transmitted to rule client136are presented to a user and, when an answer is received, the answer is processed in accordance with the procedures described above (see350,FIG. 6). Finally, control proceeds to an “End Question Selection” block409during which process400is complete.

FIG. 8is an example of a decision graph500in accordance with the disclosed technology. Consider the following set of rules for governing refund requests. Note that these rules are simplified for illustration purposes, with each having one or more conditions and a single action.RULE 1: If customer has proof of purchase and the purchase amount is less than $10,then set outcome to APPROVE.RULE 2: If customer does not have proof of purchase and the payment type is DINERS,then set outcome to WRITE_OFF.RULE 3: If customer does not have proof of purchase and the product type is SWIMWEARthen set outcome to DENYRULE 4: If customer has proof of purchase and the refund amount is at least $10 and payment type is AMEXthen set outcome to PENDRULE 5: If customer has proof of purchase and the refund amount is at least $10 and payment type is OTHERthen set outcome to DENYRULE 6: If it is the customer's birthdaythen set outcome to APPROVE

Rules 1-6 may be represented by a directed acyclic decision graph such as graph500. Decision graph500is divided into two (2) sections, i.e., rule conditions502and rule actions504. Within rule conditions502are a number of questions, i.e., a first question, or “Q1,”511, a second question, or “Q2,”512, a third question, or “Q3,”513, a fourth question, or “Q4,”514, a fifth question, or “Q5,”515, a sixth question, or “Q6,”516and a seventh question, or “Q7,”517. In this example, Q1-7511-517correspond to questions 1-7 detailed above in conjunction withFIG. 3. Within rule actions504, are example of four (4) possible outcomes, or “OCs,” i.e., an OC1521, an OC2522, an OC3523and an OC4524. In the following example, OC1521corresponds to an “APPROVE,” OC2522to “PENDING,” OC3523to “DENY” and OC4 to “WRITE_OFF,” all of which should be self-explanatory.

Depending upon the answers to any particular question Q1-7511-517, there may be several possible outcomes. For example Q1511, which has a “TRUE/FALSE” answer, may be relevant to Q2512, Q3513and Q5515. These relevancies between Q1511and Q2512, Q3513and Q5515are represented inFIG. 8by arrows that point from Q1511to Q2512, Q3513and Q5515. In a similar fashion, answers to Q2-Q7512-517are indicated as relevant to either other questions or OC1-4521-524.

Each of the arrows representing relevancies, corresponding to a label that details the corresponding answer to the source of the arrow and conditions associated with the destination question. In other words, each question511-517may be associated with multiple Condition/Action pairs. Specifically, the arrow between Q1511and Q2512corresponds to a label531that indicates an answer to Q1511of “TRUE” and that the “TRUE” answer to Q2512may be an answer to rule 1, condition 1, or “r1-c1,” rule4, condition1, or “r4-c1” and rule 5, condition 1, or “r5-c1.” For the sake of convenience, rule condition pairs will be referred to with the notation “r#-c#” throughout the rest of the Specification.

An answer of “FALSE” to Q1511may indicate a need to present Q3513or Q5515, associated with labels532and533, respectively. In a similar fashion, an answer of “<10” to Q2512corresponds to r1-c2 as indicated by a label534, leading to (1l521. An answer of “>10” corresponds to r5-c2 as indicated by a label535and leading to OC3523and r4-c2 and r5-c2 as indicated by a label536and indicate a need to ask question Q4514. An answer of “Swimwear,” or “SW,” to Q3513corresponds to r3-c2 as indicated by a label537and leads to OC3523. An answer of “AMEX” to Q4514corresponds to r4-c3 as indicated by a label538, which indicates a need to ask Q6516. Any other answer to Q4514corresponds to r5-c3 as indicated by a label539, which indicates a need to ask Q5515. An answer of “TRUE” to Q5515corresponds to r5-c4 as indicated by a label540and leads to OC3523. An answer of “FALSE” to Q5515corresponds to r2-c2 as indicated by a label541and leads to OC4524. An answer of “>365” to Q6515corresponds to r4-c4 as indicated by a label542and leads to OC2522. Finally, an answer of “TRUE” to Q7517corresponds to r6-c1 as indicated by a label543and leads to OC1521.

It should be noted that there may be questions that are skipped or answered with a response that does not correspond to any of the labels531-543. In such a case, the disclosed technology merely returns to a question selection based upon the information that is available without any need to program or establish every special or unusual scenario. Each candidate question corresponding to questions511-517is also associated with a reference count, of which for the same of simplicity only two (2) are shown, i.e., a reference count_1551and a reference count_2552. In this example, reference counts such as counts551and552are based upon a number of r#-C# pairs with which a particular question is associated.

ERRE117traverses to a node of graph500when all precursor conditions have been satisfied. To start, when no answers have not yet been supplied, decision graph500reference count_1551is equal to ‘5’ because of r1-c1, r4-c1 and r5-c1 in label531, r3-c1 in label532and r2-c1 in label533. Reference count552is equal to ‘1’ because the only r#-c# pair associated with Q7517is r6-c1 in label543. The reference count of all other nodes is equal to ‘0’ until either Q1 of Q5 has been answered. It should be noted that a reference count is not determined by a static analysis of rules but rather, during rule processing, candidate tracker208(FIG. 3) updates reference counts based upon the number of times a question is referenced by ERRE117(FIGS. 1 and 2). Reference counts may be employed to determine a next question or questions to ask because they indicate the number of potential conditions that may be met by any particular answer and, potentially, a quicker path to an outcome such as OCs521-514. During Rete pattern matching of the 6 business rules R1-R6, i.e. during the traversal of decision graph500, Candidate Tracker208accumulates the candidate questions and calculates their dynamic properties (reference count and ordinal ranking). If no rule is fired, or no outcome is reached, then the QSL210generates the next question from these candidates based on the user-specified selection strategy.