A METHOD AND A COMPUTER SYSTEM FOR INTERACTIVE CONFIGURATION

Abstract: There is provided a method of controlling the flow of information in a client/server system for interactive configuration, wherein a request to a rule base is processed, comprising the steps of: providing request information, resulting from a first client interaction; transferring said request information to the server; collecting intermediate information, resulting from at least one second client interaction succeeding said first client interaction; creating response information on the server responsive to said request information; transferring said response information to the client; determining whether said response information indicates conformity with said rule base; creating merged information responsive to said intermediate information and said response information; determining whether said intermediate information represents a higher level of knowledge than said response information; selecting at least one of the following actions according to said determinations: use said merged information to update said client or transmit said merged information as a request.

Description: A Method and a Computer System for Interactive Configuration. Field of the Invention The invention relates to the field of controlling the flow of information in a client/server system for interactive configuration, wherein a request to a rule base is processed. Background of the Invention In short, the general interactive configuration problem can be described as having a computer based model of a number of selectable objects, or selectable attributes of objects, and a number of rules that define constraints on the selectable objects and attributes. The configuration process is the process of selecting or deselecting objects or object attributes until a solution is found that satisfies all the constraints. During this configuration, the configuration engine will deduce consequences of the selections made, as well as interactively handling conflicting selections, and aiding the user in resolving these . Traditionally, the configuration process in a cli- ent/server environment consisted in the user making a number of selections at the client side and then submitting all the selections for validation by the server. This traditional way of operation has the serious drawback, that the user can end up with a set of selections that does not satisfy all the constraints, without having means of knowing exactly which selections caused the inconsistency. It may thereby be likely that the user is forced to undo all or at least hardly all selections in order to reach a valid state. A computer system intended to solve a configuration problem is a special application of artificial intelligence where the problem can be stated in terms of a set of selectable objects and a number of relations between these selectable objects. The configuration problem is solved when the set of all selectable objects is completely divided into two disjunct sub-sets representing objects that are included in the configuration and objects that are excluded from the configuration, respectively, with- out violating any of the relations between the selectable objects . A selectable object is anything that can be included or excluded. It can be a physical object (e.g. a car or a specific kind of engine), an attribute (e.g. the color red or the texture pattern of a carpet) or something abstract (e.g. a specific number of trips between home and work or a particular type of contract) . A relation is a rule involving one or more selectable objects. A relation or a collection of relations can e.g. be stated by means of boolean rules having boolean variables and wherein 'Selected' is indicted by assigning the value of such a variable to boolean 'True' , the variable otherwise being assigned to the value boolean 'False' . The purpose of a rule is to constrain the selection of objects to obey some requirements. A rule can be based on a physical limitation (e.g. if a car needs a large engine to support a large number of selected electrical accesso- ries), or a discretionary decision (e.g. if the marketing division in a car manufacturing company decides that all cars having a particular large engine are produced only in red color to give them a more sporty look) . Often the term 'Constraint' is used to refer to a rule limiting how objects can be combined. A configuration engine is the heart of a computer system for solving configuration problems. The principle for designing an inference engine is e.g. disclosed in WO 90/09001. The configuration engine maintains a value for each selectable object reflecting the current knowledge of that object. The knowledge value is 'Unknown' to begin with, and can be set by either the user of the computer system or the configuration engine. Some examples of val- ues are: Selected, meaning that the user operating the computer system has chosen to positively include the object. Discarded, meaning that the user operating the computer system has chosen to positively exclude the object. Concluded, meaning that the Configuration Engine has deduced that the object must be included. Rejected, meaning that the Configuration Engine has deduced that the object must be excluded. Unbound, meaning that the Configuration Engine has de- duced that the object may be either included or excluded. Possibly concluded, meaning that the Configuration Engine has deduced that the object may be included but cannot be excluded. Possibly rejected, meaning that the Configuration Engine has deduced that the object may be excluded but cannot be included. Unknown, meaning that the configuration engine has no present knowledge of whether the object is included or not . It is possible to define a partial ordering of knowledge values that reflects the level of knowledge which the configuration engine has about the object. An example of such an ordering is given in table 1 below: Table 1. Table 1 shows the ordering of knowledge values. Two values are said to be equivalent if they have the same effect on the set of selected objects. Using the example values in table 1, selected is equivalent with concluded and discarded is equivalent with rejected. If two different values of the same object are compared, one value may overrule the other value if it has a higher associated knowledge level. If e.g. the value of an object is 'Unbound' in one part of the computer system and 'Selected' in another part of the system, then the value of 'Selected' may overrule the value of 'Unbound' i.e. if a variable has the value 'Unbound' the value may be changed to 'Selected' without taking the risk of violat- ing any constraints, because 'Selected' has a higher level of knowledge that 'Unbound' according to table 1. An object is defined as 'Free' if it is either unbound, possibly concluded, possibly rejected or unknown. An object is defined as 'Bound' if it is selected, discarded, concluded or rejected. The configuration engine uses the rules to assist the user in the selection process. This assistance can be more thorough, the more calculations the configuration engine is allowed to perform. It is possible to define the amount of assistance given to the user in terms of the deduction level reached by computations of the configuration engine. Some possible definitions of deduction levels are given below: Validation is defined as the deduction level where all rules have been examined without finding any violations. Propagation is defined as the deduction level where the first implications of the rules are computed. If e.g. a rule states "if A then B" and A is included (selected) , propagation means that the configuration engine has deduced that B is also included (selected) . A deduction of consequences is a calculation by the configuration engine where at least the propagation level is reached. A contradiction is defined as the situation where the user performs a choice to either include or exclude an object, following which the configuration engine is not able to reach a level of validation because at least one rule is violated. Cross References Reference is made to the following patent applications, filed the same day as this application and assigned to the same assignee, Beologic A/S: (1) A Method of Configuring a Set of Objects in a Computer (2) A Method and Apparatus for Inference of Partial Knowledge in Interactive Configuration (3) Method of Processing a Request to a Boolean Rule (4) A method of enabling Invalid Choices in Interactive Configuration Systems which are hereby incorporated as references to be understood in connection with the present invention. Summary of the Invention A first object of the invention is to provide clients connected to a server with instant information on the consequences of selecting single items from a larger set of logically interrelated items. A second object of the invention is to provide a method for efficient exchange of state information between a server and a client, and a unique method of synchronizing these otherwise asynchronous states. A third object of the invention is to provide a method which limits both the interruptions imposed on the client by the server and the total number of requests issued by the client to the server. The invention provides a method of controlling the flow of information in a client/server system for interactive configuration, wherein a request to a rule base is proc- essed, comprising the steps of: providing request information, resulting from a first client interaction; transferring said request information to the server; collecting intermediate information, resulting from at least one second client interaction succeeding said first client interaction; creating response information on the server responsive to said request information; transferring said response information to the client; determining whether said response information indicates conformity with said rule base; creating merged information responsive to said intermediate information and said response information; determining whether said intermediate information represents a higher level of knowledge than said response information; selecting at least one of the following ac- tions according to said determinations: use said merged information to update said client or transmit said merged information as a request. According to the second object the invention provides a method which makes the delay between requests and responses to these requests introduced by, for example, a computer network, transparent to the end user (client) . According to the third object, the invention provides a method which results in a smooth user interface, i.e prevents or limits disturbing updates of the user interface, and which limits the data transport effort between the client and the server. The concept is unique in that the concept allows users on one side of a network connection to reach a complete and valid configuration with continuous assistance from a server on the other side of the network, without going through a trial-and-error process. This makes it significantly faster for the user to reach a valid solution. s such, this invention is not concerned with the type of configuration engine or system used - other than requiring certain information to be available. Nor is it, in fact, concerned with the actual cause of the delay if any - such as a slow network, a slow configuration-engine, or a large number of simultaneous clients. Further, the invention relates to a computer system for interactive configuration. Brief Description of the Drawings The invention will be explained more fully below in connection with a preferred embodiment and with reference to the drawing, in which: fig. 1 shows a stand alone configuration system; fig. 2 shows a client/server configuration system; fig. 3 shows a synchronous configuration cycle according to the invention; fig. 4 shows a configuration cycle with transparent syn- chronization according to the invention; fig. 5 shows the process of merging state vectors; fig. 6 shows the principle of an efficient encoding of a state vector for transmission; fig. 7 shows merging of intermediate and result state vectors; fig. 8 shows the second merging of state vectors; fig. 9 shows the operation of a server according to the invention; fig. 10 shows the operation of a client according to the invention. Detailed Description of the Invention Fig. 1 shows a stand alone configuration system. The con- figuration system comprises a user interface 1 where a user makes selections. The user interface presents all selectable objects, or selectable attributes of objects, to the user, and accepts user selections 3. Whenever the user performs a selection, a request 4 is generated to the configuration engine 2. The configuration engine is responsible for holding the state information of all selectable objects or attributes during the configuration process. For each selectable object or attribute, the configuration engine registers whether the object or at- tribute is free for selection, is specifically selected or deselected by the user, or is selected (concluded) or deselected (rejected) as a result of a computation. The configuration engine also has access to at least one rule which defines the constraints on the selections. The con- figuration engine uses the rule base and the state information on all objects to calculate the consequences 9 of the user selection. If e.g. some rule says that selecting one object means that a second object must also be selected, the configuration engine will deduce this during the calculation 5 of consequences, and select the second object on the user's behalf. When the deduction calculation 5 is terminated, the configuration engine builds a response 6 to the user. This response may contain information not only about the object or object attribute selected by the user at the user interface 1 in user interaction 8, but also on other selectable objects that were affected by the user's selection as a consequence of one or more of the rules. The response generated by the configuration engine is used to provide an update 7 to the user interface with all the consequences of the selection, and the configuration system is prepared to accept the next user selection. Fig. 1 illustrates a traditional approach of interactive configuration where a user must wait for the response to a command before making a second command, i.e. the configuration cycle 8, 3, 4, 5, 9, 6 and 7 is repeated with- out interruptions until the configuration process is finished, other things being equal. Fig. 2 shows a client/server configuration system. The configuration cycle is the same as the configuration cy- cle shown in fig. 1, but with the addition of multiple sources of delay. This figure illustrates why the method of fig. 1 is insufficient when large delays are introduced into the system i.e. introduced into the configuration cycle. The interactive configuration system operates via a network connection 10 that separates the user interface 1 and the configuration engine 2. There are many possible types of network connections to which this description applies. One type of network connection is a Local Area Network (LAN), i.e. a network connecting a number of computers within a limited geographical area. Examples of such net- works are an "Ethernet" or a "Token Ring" net. A second type of network connection is a connection via a network of networks, i.e. a situation in which many smaller networks are interconnected to form a very large network, possibly allowing connections between computers all over the world. An example of such a network is known as the 'Internet' . A third type of network connection is a connection where a public telecommunications network is used to connect two computers at two different locations, possibly in two different countries. Examples of such public telecommunications networks are the telephone network and the X.25 network. Fig. 2 describes the selection cycle when any type of network connection separates the user doing the selections from the configuration engine doing the calculations . When the user selects an object or an attribute, the request informing the configuration engine of this selection is delayed by the network up-link part 12. The term 'up-link' is used to identify the part of the network connection used for transmitting data from the client to the server. The calculation 5 of consequences 9 by the configuration engine introduces a second delay that may be substantial, because configuration problems are generally computationally NP-hard, i.e. the number of calculations necessary increases exponentially with the number of objects, attributes and rules. The response generated by the configuration engine is delayed by the network down-link part 11, before the conse- quences can be presented to the user. The term "downlink" is used to identify the part of the network connection used for transmitting data from the server to the client. Fig. 3 shows a synchronous configuration cycle according to the invention. The figure shows the flow of information in a configuration system wherein the user interface 317 and the configuration engine 318 are separated by a network having an uplink part 305 and a downlink part 310. The user interface 317 is located at the client 301 and the configuration engine 318 is locate at the server 302. When the user performs a selection 303, a local state vector, StateVector [1] , 304 comprising state information for all selectable objects and attributes is updated to reflect the selection. This state vector is sent as a request to the server 302, which will receive it after a delay DELAY1 introduced by the up-link part 305 of the network connection. The server stores the received request state, StateVector [I' ] 306, and uses the information to determine which calculations to perform. The configuration engine 306 performs a deduction of consequences 308 introducing a DELAY2 due to the HP-hard computational problem. The response generated by the configuration engine 318 is represented in a response state vector, StateVector [4] 309. This state information is transmitted to the client as a response subject to a delay DELAY3 introduced by the network down-link part 310. The Total Delay 311 is the sum of the three contributing delays, i.e. DELAY1 + DELAY2 + DELAY3. The client receives the response state vector, StateVec- tor[4'] 312 which contains state information that is usually different from the local state vector StateVector [3] 307. The client and the server no longer have the same view on the state of the configuration, i.e. the information available to the user is different from the information known by the server. To solve this problem, a merging unit 313 performing an intelligent combination of the local state vector State- Vector [3] 307 and the received response state vector StateVector [4' ] 312 is introduced. This generates a merged state vector StateVector [5] 314. The information in the merged state vector StateVector [5] 314 is used to update the user interface 317, and is used as information 315 for the next user selection cycle. The information in the merged state vector StateVector [5] 314 may be used as new request 316. The state vectors 304 and 307 are generated on a predefined event (s) arising by the users interaction with the user interface. The user interface can e.g. comprise a screen displaying selectable object attributes. The ob- ject attributes can be displayed by means of simple text and/or icons e.g. arranged in list boxes, combo boxes, or as legends to check boxes or radio buttons. The object attributes can be selected by using simple text statements or commands or by the use of a computer mouse where a cursor can be moved according to movements of the computer mouse to point at an object attribute and where buttons on the computer mouse is activated by the user when the cursor is directed to point on an object attribute subject for selection. The more specific de- tails of such event driven user interfaces is known to a person skilled in the art. Thus, when an object attribute is selected the event of selecting the object attribute can generate the state vectors 304 or 307. The content of the state vectors may depend upon how the configuration system is implemented. In a preferred embodiment a state vector comprising all selectable objects and object attributes are generated each time a user changes the value of an object attribute. When the client is not waiting for a response state vector i.e. e.g. when a user changes the value of an object attribute for the first time in a given configuration session the generated state vector 304 is transmitted to the server. This can be carried out by invoking a transfer procedure using of some type of protocol e.g. the well-known TCP/IP protocol for the transmission of the state vector. Alternatively, if the client is waiting for a response state vector the generated state vector 307 is used as input to the merging unit 313. It should be noted that it is known to a person skilled in the art to determine whether the client is waiting for a response from the server or not. Likewise to generating a state vector resulting from an event on the user interface, a state vector can be used to generate or update a user interface. This may be done by letting the user interface reading a state vector representing what is to be shown to the user at given points in time or by simply updating the user interface with the contents of a state vector when new information should be provided to the user. Fig. 4 shows a configuration cycle with transparent syn- chronisation according to the invention. This cycle pro ¬ vides a better user interface, because the user is allowed to continue interaction without having to wait for the server to complete the processing of a request. This mode of operation is made possible by the merging unit 416, as explained in the following. The figure shows the user interface 419 and the configuration engine 420. In a preferred embodiment, the user interface and the configuration engine are separated by a network; however, the specific type of network is not important to the object of the invention. When the user performs a first selection 403, a local state vector, StateVector [1] , 404 holding state informa- tion for all selectable objects and attributes is updated to reflect the selection. This state vector is sent as a request to the server 402, which will receive it after a DELAY1 introduced by the up-link part 405 of the network connection. The server stores the received request state vector StateVector [1' ] 406, and uses the information to determine what type of processing to perform. After sending the request state vector StateVector [1] 404, the client 401 will allow the user to make a second selection 407. Then a selection will cause the client to update the corresponding state information in an intermediate state vector, StateVector [2] 408. This intermediate state vector is not transmitted to the server, but stored locally. The user may continue to make selections 409 which all results in the intermediate state vector being updated 410. The server performs a deduction of consequences 411 introducing a DELAY2 due to the HP-hard computational problem. The response generated by the configuration engine 420 is represented in a response state vector StateVec ¬ tor [4] 412. This state information is transmitted to the client subject to a DELAY3 introduced by the network down-link part 413. The total delay 414 observed by the client when the server is contacted is the sum of the three contributing delays, i.e. DELAY1 + DELAY2 + DELAY3. The client receives the response state vector StateVec- tor[4'] 415 which contains state information that is usually different from the latest intermediate state vector StateVector [3] 410 because the user is allowed to change object values while a state vector representing previous user selections is examined by the configuration engine. Thus, the client and the server no longer have the same view on the state of the configuration, i.e. the information available to the user is different from the information known by the server. To make things worse, the client's view of the state information is not the same as when the request was sent to the server. To solve this problem, a merging unit 416 performing an intelligent combination of the latest intermediate state vector StateVector [3] 410 and the received response state vector [4'] 415 is introduced. This generates a merged state vector StateVector [5] 417. Depending on the information retrieved during the merging operation, the merged state vector can be used in different ways. That is, a number of actions can be taken. If the information received in the response state vector StateVector [4' ] 415 does not invalidate any of the user's selections represented by the intermediate state vector StateVector [3] 410, the user interface is updated with the new information 418, and the merged state vector is used as the information to the user (by means of the user interface 419) regarding more user selections. However, in some situations, the merging unit may find that the user interface should not be updated before the contents of the merged state vector have been verified by sending it to the server as a new request 419, thereby repeating the cycle comprising 405, 411, 413, 416 and 418 or 419. If the merging unit 416 finds a conflict between the in- formation in the response state vector StateVector [4' ] 415 and the intermediate state vector StateVector [3] 410, the information used to update the client 418 will prompt the user to resolve the conflict. The user can do this by making a new client selection 403, starting a new cycle. The merging unit 416 can actually reduce the number of requests sent to the server. Normally, if the client makes one or more additional selections 407 and 409, these would require a new request to be sent to the server following the merging as described above. However, if the server deduction 411 results in a response state vector StateVector [4' ] 415 that is compatible with the latest intermediate state vector StateVector [3] 410, then no new request is necessary. For some product models this can reduce the load on the server significantly. As can be seen from the above description, the merging unit 416 is a very elegant method of making asynchronous operation work in a manner similar to synchronous opera- tion. The details of the merging unit are described in the following. Table 2 Table 2 shows an example of possible object states Table 2 describes a possible definition of the states that each configurable object can take, i.e. 'Selected', 'Discarded', 'Concluded', 'Rejected', and 'Free'. The states 'Concluded' and 'Rejected' may be changed by the configuration engine, and where the states 'Selected' and 'Discarded' may be changed by the user as a result of a user interaction. The state 'Free' may be changed by the client as well as the configuration engine. The merging unit may change all the states, if required. Table 2 is by no means exhaustive, but intended as a tool to show the general principle of the invention. An example of a binary encoding of states is shown for completeness, however, this is irrelevant to the general concept. It may be worth noting that though each configurable object is considered 'binary' - i.e. is either included or excluded - there are two ways in which they can be chosen: by the client as a consequence of user commands, or by the configuration engine at the server. The four possible combinations can be organized as shown in table 3. Table 3 Table 3 shows classification of selectable object states. Equivalent states are states that would cause the con- figuration to end up with the same subsets of included and excluded objects. In table 3 equivalent states are represented by the two columns. That is, 'selected' is equivalent with 'concluded' . Contradictory states are states that would cause different subsets of included and excluded objects for the same configuration. In table 3 contradictory states are represented by the two diagonals. That is, selected is in contradiction to rejected. In addition to the selectable object states, the configurable object may be in an intermediate 'not-yet- selected' state, i.e. the state 'Free'. This sums up to a total of 5 states. Other configuration engines may use more or less than 5 states - this is not important to the concept, but the tables described in the following will need to be adjusted accordingly. The 'Selected' state indicates that the user has issued a request to include a specific object in the configuration. It can also be used to indicate that the server has decided to include the object on the user's behalf. An example of this is when the user asks for default values that are predefined for objects, and the server sets the state as if the user did the selection. The 'Discardad' state indicates that the user has issued a request to exclude the object from the configuration. It can also be used to indicate that the server has decided to exclude the object on the user's behalf. The 'Concluded' state indicates that the configuration engine has determined that this object must be included if the constraints of the configuration problem are to be met. The 'Rejected' state indicates that the configuration engine has determined that this object must be excluded if the constraints of the configuration problem are to be met . The 'Free' state indicates that it is still undetermined whether the object is included in or excluded from the configuration . The 'impossible' state is not a real state, but is used in the following description to indicate combinations of the states in the server and the client, respectively, that cannot occur due to the semantics of assigning states in a configuration problem. s s D F R R C C R S F F S R F S Table 4. Table 4 shows the contents of a sample state vector. Table 4 shows an example of a state vector as a simple set of states, describing the state of a system with 16 objects rather than the state of a single object. Each object of the state vector can take exactly one of the defined object states defined in table 2. Fig. 5 shows the process of merging state vectors. This is the overall operation of the state merging unit introduced in fig. 3 and fig. 4. The merging unit takes the latest intermediate state vector I 501 and compares it with the received response state vector R 502. The two vectors are scanned 503, one element representing one ob- ject at a time, and a merged state vector M 504 is generated. According to the invention, the process of merging the state vectors can be stopped when a pre-specified state or pre-defined states are detected in the intermediate, response, or merged state vector. Tables containing the rules for combining an intermediate object state with a response object state determine the states of the objects in the merged state vector. Thus, in a practical implementation of the invention the merging process can be carried out by means of a table lookup function or procedure, however other implementations can be used e.g. case-of or if-then-else statements. This is within the skills of a person skilled in the art. Turning now to a table that can be used for creating the merged state vector and determining a proper preliminary action of what to do in the client/server environment in order to execute the process of configuration according to the invention. Firstly, turning to a table that can be used when the configuration engine has performed a successful deduction, i.e. no contradictions has been found. Table 5a. Table 5a shows a merge table for successful deduction. Table 5a shows a table for generating the merged information responsive to the response information and the intermediate information. It should be stressed that the table is used to create the merged state vector by for each respective element in the intermediate and response state vector representing a specific object, looking up a state to assign to the merged state vector for the respective object and a corresponding action determining what to do in the client/server environment e.g. comprising determining what to do with the merged state vector. Each row in the table corresponds to a defined state of the latest intermediate state vector. Each column of the table corresponds to a defined state of the received re- sponse state vector. Thus a field in the table is found by for each corresponding element in the latest intermediate state vector and the response state vector (i.e. the respective elements representing the state of the same object) looking up the respective states and using these states as entries to table 5a. The field found contains a state 'S', 'D' , 'C , 'R' , or 'F' to write to the merged state vector unless the field containing an 'X' is looked up. The field 'X' represents a situation that should be handled as a fault and is considered to be out of the scope for this description. Further, the field found contains a reference '0', '1', or '2' that indicates which action in the client/server environment to execute. The references '0', '1', and '2' are given the following brief interpretation: 0 No update of the user interface, set the merged information equal to the intermediate information, and send the merged information as a new request; this action is also denoted 'Send Local' . 1 Update the user interface with the merged information and send the merged information as a new request; this action is also denoted 'Send Merged' . 2 Update the user interface with the merged information and do not send the merged information as a new request; this action is also denoted 'Accept' . When a field containing the reference λ 0' in table 5a is found the user interface is not updated with the knowl- edge contained in the merged state vector because the user may have altered the state for a given object from 'Selected' to 'Discarded' or vice versa in the time interval from when the request state vector was sent until the corresponding response state vector was received. Alternatively, the user interface is not updated because the user may have changed the state for a given object from 'Free' , 'Selected' , or 'Discarded' to 'Discarded' or 'Selected' while the inference engine has deduced knowledge for that object which is incompatible with the users change of the state for the object. Thereby the response information may be wrong according to the latest intermediate state vector. Thus, it is unclear how the user interface should be updated until the latest intermediate state vector has been examined by the inference engine and a descent decision is therefore not to update the user interface. The intermediate state vector is sent as a new request such that the response information is in consistency with the latest intermediate state vector. When a field containing the reference '1' in table 5a is found the user interface is updated with the knowledge contained in the merged state vector because the knowledge level for a given object is increased by the user. Thus no inconsistency between the latest intermediate state vector and the response state vector is detected. Just in order to keep the inference engine informed of the latest changes, the merged state vector is sent as a request. The user is thereby allowed to continue the process of configuration even though the latest changes has not yet been responded to by the inference engine. When this action is released a serious reduction of the response time is obtained because the user is allowed to continue right away while it as a matter of fact is ensured that the user did not turn into a dead end by doing his last choice. When a field containing the reference '2' in table 5a is found the user interface is updated with the knowledge contained in the merged state vector but the inference engine is not updated. This action is chosen because the merged state vector is similar to the response state vector and it is thereby unnecessary to update the inference engine . The principles applied when constructing the merge table for successful deduction is given below. If the state of the response vector is the same as the state of the intermediate vector, the merged vector also gets this state, and the result can be used for updating the client. This situation corresponds to the diagonal of table 5. If the state of the response vector is equivalent to the state of the intermediate vector, the merged vector is set to the state of the response vector, and the result can be used for updating the client by means of the user interface. Another possibility would be to set the state of the merged vector to the state of the intermediate vector, but this would require the merged vector to be sent to the server as a new request. If the state of the response vector indicates a choice (i.e. the user has selected the state 'Selected' or 'Discarded' for an object), but the state of the response vector is different from the state of the intermediate vector, then the merged vector is set to the state of the intermediate vector. The result cannot be used for updating the client, as the merged state vector must first be sent to the server as a new request. If neither the state of the intermediate vector nor the state of the response vector indicates a choice by the client, then the state of the merged vector is set to the state of the response vector, accepting the result of the configuration engine. The result is used to update the client . If the state of the intermediate vector indicates a choice by the client and the state of the response vector indicates that the object is free, then the merged vector is set to the state of the intermediate vector. The result cannot be used for updating the client, as the merged state vector must first be sent to the server as a new request. Other embodiments of the merge table (Table 5a) for successful deduction may be adapted according to the invention. Table 5b shows an example of another merge table for successful deduction. Table 5b. In table 5b the number of states is reduced to 'S' equal to selected, 'D' equal to discarded, and 'F' equal to free. In comparing table 5a and 5b there is in table 5b not distinguished between selections made by the inference engine and selections made by the client. In table 5b only, the following interpretations are thus given: Either the user or the configuration engine has selected. Either the user or the configuration engine has discarded. Either the user or the configuration engine has set to free. The actions indicated by the numbers '0', '1', and '2' has the same interpretation as for table 5a above. Note that four of the fields in table 5b comprise two alternative and useful suggestions to the content of the respective fields. The most important thing to learn from the tables 5a and 5b is that the user in some situations are allowed to continue the process of configuring a product without having to wait for a response from the server or inference engine and most important of all without taking the risk of letting the user to be trapped in a dead end of the configuration. It should be noted that table 5a and table 5b shows examples of merging tables that is used when the configuration engine has performed a successful deduction, i.e. no contradictions were found by the inference engine. Now, secondly, turning to a table that can be used when the configuration engine has performed a non-successful deduction, i.e. contradictions in the request state vector has been found. Table 6a . Table 6a shows the merge table for non-successful deduction. Table 6a contains actions indicated by the numbers '0' and '1' and has the following brief interpretation: 0 The conflict must be handled by the user; this action is also denoted 'Conflict' . The conflict is possibly resolved, the user is not updated, and the merged information is transmitted as a new request this action is also denoted 'Send Local' corresponding to the 'Send Local' action for successful deduction. Action '1' . It is determined that the conflict causing the non-successful deduction is possibly resolved when the knowledge level for a given object is lowered by the user in the time interval from the request state vector was sent to the response state vector was received and the merging process started. Thus a larger space of valid configurations may be enabled. Alternatively, it is determined that the conflict causing the non-successful deduction is possibly resolved when the state for a given object is changed from 'Selected' to 'Discarded' or vice versa. In order to ensure whether the conflict actually is resolved the merged information is transmitted as a new request to the inference engine. The user is not up- dated with the merged state information because it is not yet verified whether the conflict is resolved and no qualified information for such an update of the states of the objects on the user interface exists. Action '0' . Otherwise it is determined that the user must take action in order to solve the conflict. This action can be supported by the inference engine, providing alternatives to the user by means of the user interface. The alternatives can be in the form of what to change in order to avoid the conflict or a list of valid configurations or partial valid configurations. Partial valid configurations are configurations where a number of objects have been assigned with states such that the user himself may finish the configuration. Each row in the table corresponds to a defined state of the latest intermediate state vector. Each column of the table corresponds to a defined state of the received response state vector. The table is used like it is de- scribed for table 5a and 5b except for that table 6a is used when a contradiction is detected. The principles applied when constructing the merge table for contradictions is given below. If the state of the response vector indicates a choice by the client and the state of the intermediate vector also indicates a choice by the client or that the state of the object is changed to 'Free', then the merged vector is set to the state of the intermediate vector. The reason is that the new choice made by the client may be suffi- cient to solve the contradiction. The result cannot be used for updating of the client, as the merged state vector must first be sent to the server as a new request. In all other cases, the client is prompted to solve the contradiction. Other embodiments of the merge table (Table 6a) for contradictions may be adapted. Table 6b is shows an example of another merge table for contradictions. Table 6b. In table 6b the number of states is reduced to 'S' equal to selected, 'D' equal to discarded, and 'F' equal to free. In comparing table 5a and 5b there is in table 5b not distinguished between selections made by the inference engine and selections made by the client. In table 5b only, the following interpretations are thus given: 'S' Either the user or the configuration engine has selected. D' Either the user or the configuration engine has discarded. wF' Either the user or the configuration engine has set to free. The preliminary actions indicated by the numbers '0' and '1' has the same interpretation as for table 6a. The merging unit receiving the response state vector must determine whether the inference engine has detected a contradiction or not in order to select the correct erg- ing table, or in other words to select the correct strategy for the merging. This can be done in various ways, however in a preferred embodiment this is done by letting the inference engine assigning the variables involved in the contradiction with a special contradiction state (e.g. denoted 'Contradiction'). The response state vector can thereby be treated as if it contains no contradictions i.e. using a table for successful deduction. Each corresponding element in the response state vector and the intermediate state vector is thus used as entries to the merge table (e.g. table 5a or 5b). If a contradiction then is detected in a given element in the response state vector, the merging process for the rest of the elements in the response and intermediate state vector can be merged by use of the table for non-successful deduction. When a merged state vector is provided by the merging unit the different types of actions determined for the individual elements in the merged state vector can be examined. This examination uses a predetermined ranking of the possible actions: Table 6c. Table 6c shows a table for determining a resulting action. When an action for the elements in the state vector has been determined a resulting action should be determined, i.e. selecting one of the actions and handling the merged state vector according to this selected or resulting ac ¬ tion. According to table 6c the merged state vector should be handled according to the 'Conflict' action described above if at least one action in the merged state vector is 'Conflict' . If no 'Conflict' action is determined and if at least one action in the merged state vector is 'Send Local' , the merged state vector should be handled according to the 'Send Local' action described above. If no 'Conflict' and no 'Send Local' action is determined and if at least one action in the merged state vector is 'Send Merged' the merged state vector should be handled according to the 'Send Merged' action described above. If no 'Conflict', 'Send Local', and 'Send Merged' action is determined the merged state vector should be handled according to the 'Accept' action described above. Of cause, it is not necessary to examine the entire merged state vector if a 'Conflict' action is read before the entire merged state vector is examined. If it is desired an action with a higher ranking than a determined action can be selected, but it is not possible to select an action with a lower ranking than a determined action. A large number of different examples of possible merging strategies has been shown by means of the above tables. Fig. 6 shows the principle of an efficient encoding of a state vector for transmission. Each object of an entire state vector is assigned a reference number 601. The state vector representing the previous transmission, P, 602 is compared with the new state vector to be transmit- ted, N, 603. The minimum information to be transmitted is the objects where the state was changed between the previous and the new transmission 604. An efficient encoding of this is represented by T 605 where only the intervals of changed objects are transmitted. Each interval of changed objects is encoded as the index number of the first object in the interval 606, the num- ber of objects in the interval 607, and the state of each object in the interval 608. Example: The following is a short example illustrating how the invention works in a preferred embodiment. For the purpose of illustration, the following elements, object attributes and intervals are defined. Table 7. Table 7 shows a definition of configurable items. The table contains the following information: Id. This is a numeric value used to identify the configu- ration items. Configuration Item. This is a brief specification of the configuration items. Type. This is the type of the configuration item. For this example, three types are considered: an Object, an Attribute and an Interval. Objects. This is the number of objects contained in the configurable item. Object Ids. For each configuration item, this is a list of numeric values used to identify the objects. For the purpose of illustration the following constraints are defined: Table 8 Table 8 shows a definition of constraints. The constraints in this example can be explained as follows: A) If the user chooses to have a remote job, he must have a car. B) If a car is chosen, this must have an engine which is one of the two defined types: Either a 1600cc engine or a 2000cc engine. C) If the engine is chosen to be either a 1600cc or a 2000cc, the car has power steering. D) This constraints the number of trips possible. On the left side of the equation, each trip is 100km. The rule for calculating the total mileage of the car is on the right side of the equation. With a 2000cc engine, the car normally runs 400km. With a 1600cc engine, the car normally runs 500km. In both cases the mileage is reduced by 100km if the car has a sunroof. E) If the engine is 1600cc, the number of electrically operated accessories is limited to 2. F) If the engine is 2000cc, the number of electrically operated accessories is limited to 3 G) If the 2000cc engine is chosen, the color of the car must be red. With a reference to table 4, the state of the configuration problem can be represented as a state vector where each dimension of the vector corresponds to a selectable object in the configuration model. Using the object IDs defined above, this gives the following representation: Table 9. Table 9 shows mapping of configuration objects to a state vector. The first row is the object number from table 7. The second row is the configuration item (using an abbreviated text) . The third row is the configurable objects. The fourth row is the state vector representation with the states of the objects as they appear after the ini- tial deduction of the consequences of the rules. In most cases the initial state of the objects will be Free (F) , but, in this case, the configuration engine deduced from rule C (and the implicit rule that either a 1600cc or a 2000cc engine must be chosen) that power steering is con- eluded (C) . With reference to fig. 4, assume that the user selects to have a remote job. The local state 404 will then have the state for object 1 set to selected (S) . Table 10. Table 10 shows the local state vector after the first selection. This vector is transmitted to the server. The user now makes a second selection 407, setting the engine to 2000cc. This will cause the intermediate state vector 408 to be updated for the 3rd object. Table 11. Table 11 shows the local state vector after the second selection. The server performs a deduction of consequences 411, resulting in a response state vector 412. When this is received by the client, it is merged with the intermediate state vector 410. Fig. 7 shows merging of the intermediate state vector with the response state vector containing the conse- quences deducted by the server based on the first selection. Using constraint "A" in table 7, the server deduced that a Car is necessary, thus setting object 2 701 of the response state vector R 702 to "C". The merging unit finds according to table 5 that object 2 of the merged state vector is "C" with a preliminary action 2: Use the merged result, no re-send required. When comparing the objects in position 3, however, the merging unit sets the state of the merged object to "S" with ac- tion 1: Use the merged state vector, and send this to the server as a new request state vector. The user interface is updated to reflect the conclusion of a car, and a second cycle is initiated without user intervention, using the merged state vector as a new request state vector. Fig. 8 shows the second merging of state vectors. The re- suit M of merging the intermediate state vector, I, 801 with the response state vector, R, 802 following a second deduction of consequences by the server. 803 indicates the changed objects. In the second deduction, the server concludes that the car does not have a 1600cc engine (setting object 4 to "R") ; further from rule "G" that the color must be Red (setting objects 5, 6 and 7 to "C", "R" and "R" respectively) , and from rule "D" that the number of trips can- not be 1, 2 or 5 (setting objects 12, 13 and 16 to "R") . The merging unit finds that object 4, 5, 6, 7, 12, 13 and 16 of the merged state vector should be set to "R", "C", "R", "R", "R", "R" and "R" respectively, and that action 2 (use merged, no re-send) is applicable. The user interface is updated to reflect the conclusions of the colours and the number of trips, and the client and the server are now synchronised again. Fig. 9 shows the operation of a server according to the invention. In step 901 the server is idle, waiting to receive a state vector in step 902. In step 903 the configuration engine located at the server is initiated with the received state vector as an input. In step 904 the configuration engine is working calculating a response to the input. During the calculation, the server may be interrupted if a new state vector from the same client is received and thereby drop the calculation and continue in step 907 receiving the new state vector. In step 908 the configuration engine is restarted with the new state vector as an input. This may be done if the new state vector comprises major changes relative to the state vector received in step 902 and a response to this state vector thereby is meaningless. After the configuration engine has been restarted the new calculations are performed in step 904. If the configuration engine is not interrupted by the client, the calculation is completed in step 905 and the corresponding response state vector is sent to the client in step 906. Fig. 10 shows the operation of a client according to the invention. In step 1001 the client is idle waiting for the client to activate the user interface. In step 1002 the user interface provides information from the user and a request state vector is generated. In step 1003 the request state vector is sent to the server. In step 1004 the client is waiting for a response from the server. However, additional user selections may be received from the user interface in step 1011. In step 1012 it is determined whether the additional user selections should be send as a new request state vector or whether the additional user selections should be stored until response from the server is received. In step 1014 the additional user selections can be stored as a request state vector. In step 1013 the additional user selections are send as a request state vector. If no additional user selections are provided the client waits for the response state vector from the server, which is received in step 1005. In step 1006 the merging unit is invoked for determining a proper action according to the invention. In one of the steps 1007, 1008, 1009, and 1010 a selected action is executed. Generally, it should be noted that the configuration engine can be implemented in numerous ways, however typi ¬ cally inspiration is obtained from the fields of search, comprising the fields: Constraint Logic Programming, Con- straint Synthesis, Relational algebra, Propositional Logic, Integer programming, Graph theory, Predicate Calculus etc. The characteristics of a search problem is proven to be NP-Hard, i.e. its run-time complexity is exponential meaning that time the algorithm execution times are exponential to the size of the problem for non-trivial problems. This is a very unfortunate property of the problem, which have sparked the large interest in the algorithms. When looking at just one of these areas Constraint Logic Programming again a large number of different algorithms have been proposed, see e.g. 'The Many Paths to Satisfaction', Eugine C. Freuder, Constraint Processing Selected papers. Meyer (Ed.) ISBN 3-540-59479-5; 'Constraint satisfaction in Logic Programming' . Pascal Van Hentenryck. The MIT Press. 1989; and 'Algorithms for Constraint- Satisfaction Problems: A Survey'. Vipin Kumar. Al Magazine. Spring 1992. The invention may be embodied as a computer program or a part of a computer program, which may be loaded into the memory of a computer and executed therefrom. The computer program may be distributed by means of any data storage or data transmission medium. The storage media can be magnetic tape, optical disc, compact disc (CD or CD-ROM) , mini-disc, hard disk, floppy disk, ferro-electric memory, electrically erasable programmable read only memory (EEPROM) , flash memory, EPROM, read only memory (ROM) , static random access memory (SRAM) , dynamic random access memory (DRAM) , ferromagnetic memory, optical storage, charge coupled devices, smart cards, etc. The transmission medium can be a network, e.g. a local area network (LAN) , a wide area network (WAN) , or any combination thereof, e.g. the Internet. The network may comprise wire and wire-less communication links. Via the network a software embodiment (i.e. a program) of the invention, or a part thereof, may be distributed by transferring a program via the network. It should be stressed that the important aspect of the invention as such by no means is limited to the disclosed tables, other alternatives to the tables, having the same, fewer, or more states as well as tables having the same fewer, or more actions is to be considered as within the scope of the invention.

Claims: Claims 1. A method of controlling the flow of information in a client/server system for interactive configuration, wherein a request to a rule base is processed, comprising the steps of: - providing request information, resulting from a first client interaction; - transferring said request information to the server; - collecting intermediate information, resulting from at least one second client interaction succeeding said first client interaction; - creating response information on the server responsive to said request information; - transferring said response information to the client; - determining whether said response information indicates conformity with said rule base; - creating merged information responsive to said intermediate information and said response information; - determining whether said intermediate information rep- resents a higher level of knowledge than said response information; - selecting at least one of the following actions according to said determinations: use said merged information to update said client or transmit said merged information as a request. 2. The method according to claim 1, wherein said request, response, and intermediate information comprise state information for at least one object. 3. The method according to claim 2, wherein said states comprise client states which may be changed as a result of a client interaction and server states which may be changed as a result of server processing. 4. The method according to claim 3, wherein said states further comprise free states which may be changed by the client as well as the server and overruled by said client and server states. 5. The method according to claim 1, wherein said determination of whether said response information is in conformity with said rule base is performed by testing whether said response information comprises a contradiction indi- cation. 6. The method according to claim 3, wherein said client states and said server states may comprise states which are mutually exclusive. 7. The method according to claim 3, wherein at least one of said client states is equivalent with at least one of said server states. 8. The method according to claim 3, wherein said client states comprise the states 'selected' and 'deselected', and wherein said server states comprise the states 'concluded' and 'discarded' . 9. The method according to claim 7, wherein said 'selected' and 'concluded' states are equivalent and wherein said 'deselected' and 'rejected' states are equivalent . 10. The method according to claim 5, wherein a higher level of knowledge may be assumed at least if a free state in said response information is changed to a client state in said intermediate information. 11. The method according to claim 6, wherein a higher level of knowledge may be assumed at least if a contra- diction indication is detected and if a client state for an object in said intermediate information excludes a client state for said object in said response information. 12. The method according to claim 9, wherein said further client interaction may be activated if there is contradiction in said response information. 13. The method according to claim 12, wherein said further client interaction may result in a solution to said contradiction, that is, change a state causing said contradiction to another client state. 14. The method according to claim 6, wherein said transmission of said merged information as a further request may be activated if there is contradiction in said response information, and if a first client state in said response information for a given object excludes a second client state in said intermediate information for said given object. 15. The method according to claim 14, wherein said merged information is said intermediate information. 16. The method according to claim 9, wherein said transmission of said merged information as a further request may be activated if there is no contradiction in said response information, and if said client states in said in- termediate information are not equivalent to said states in said response information. 17. The method according to claim 8, wherein said transmission of said merged information as a further request may be activated if there is no contradiction in said response information, and if a client state in said re- sponse information is changed to a free state in said intermediate information. 18. The method according to claim 8, wherein said client is updated with the merged information, and wherein said merged information is transmitted as a further request if there is no contradiction in said response information, and if a free state in said response information is changed to a client state in said intermediate informa- tion. 19. The method according to claim 9, wherein said client may be updated with the merged information, and wherein the merged information is not transmitted as a request if said client states in said intermediate information are equivalent to said response information. 20. The method according to claim 8, wherein said client may be updated with the merged information, and wherein the merged information is not transmitted as a request if said server states in said response information overrule said intermediate information. 21. The method according to claim 8, wherein said client may be updated with the merged information, and wherein the merged information is not transmitted as a request if said server states in said intermediate information overrule said response information. 22. The method according to claim 8, wherein said merged state information is created according to the following rule: if said response information is equivalent to said intermediate information, then said merged state information may be set similar to said response state information in at least some occurrences. 23. The method according to claim 8, wherein said merged state information is created according to the following rule : if said server states in said response information are not equivalent to said server states in said intermediate information, then said merged state information is set similar to said response state information in at least some occurrences. 24. The method according to claim 8, wherein said merged state information is created according to the following rule : if said client states in said intermediate information overrule said response information, then said merged state information is set similar to said intermediate state information in at least some occurrences. 25. The method according to claim 8, wherein said merged state information is created according to the following rule: if said server states in said response information overrule said intermediate information, then said merged state information may be set similar to said response state information in at least some occurrences. 26. The method according to claim 8, wherein said merged state information is created according to the following rule: if said free state information occur in said response information and said server state occur in said intermediate information, then said merged information may set to free state information in at least some occurrences. 27. The method according to claim 8, wherein said merged state information is created according to the following rule: if said free state occurs in said response information and said client state occurs in said intermediate information, then said merged information is set similar to said intermediate state information in at least some occurrences . 28. The method according to claim 2, wherein said objects are merged individually, and wherein each object is associated with an action according to said set of rules. 29. The method according to claim 28, wherein said action is determined for a whole state vector as that action which maximizes client selections while fulfilling system/model constraints. 30. A method of controlling the flow of information in a client/server system for interactive configuration, wherein a request to a rule base is processed, comprising the steps of: - providing request information, resulting from a first client interaction; - transferring said request information to the server; - collecting intermediate information, resulting from a second client interaction succeeding said first client activation; - creating response information on the server responsive to said request information; - transferring said response information to the client; said request, response, and intermediate information may comprise at least two types of information; client states which are provided as a result of a client interaction and server states which are provided as a result of server calculations; - creating merged information responsive to said intermediate information and said response information; - determining an action according to a set of rules, at least comprising the following rules: if said response information does not contain contradictions, then the client is updated with the merged information for at least some occurrences of request and response information; if said response information does not contain contradic- tions and said response information is not equivalent to said client states in said intermediate information, then the client generates a new server request; if said response information contains contradictions, then a client interaction is requested for at least some combinations of said intermediate and said response information. 31. The method according to claim 30, wherein said state information is contained in a state vector with a number of objects and wherein each object has a state representation. 32. The method according to claim 31, wherein said objects in said request information are determined as the objects involved in said first client interaction. 33. The method according to claim 31, wherein said objects in said intermediate information are determined as the union of objects comprised by all intermediate infor- mation collected after transmission of said request information and before receiving said response information. 34. The method according to claim 31, wherein said objects in said response state vector are determined as the union of objects involved in said first client interac- tion and the objects which are included in said result of server calculations . 35. The method according to claim 30, wherein at least some combinations of response and request information are impossible . 36. The method according to claim 30, wherein the set of rules further comprises the following rule: if said response information contains a contradiction and said client states in said response information are different from said client states in said intermediate information, then said contradiction is possibly resolved and said intermediate information is transmitted as re- quest information. 37. The method according to claim 30, wherein the set of rules further comprises the following rule: if said response information contains a contradiction and said client states occur in said response information and said free states occurs in said intermediate information, then said intermediate state information is transmitted as a server request. 38. The method according to claim 30, wherein the set of rules further comprises the following rule: if said response information does not contain contradictions and said response information in at least one occurrence contains free state information, then the merged information is further transmitted as a server request for at least one state outcome of said response information. 39. The method according to claim 30, wherein the set of rules further comprises the following rule: if said response information do not contain any contradictions and said client states occur in said response information and said free states occur in said intermediate information, then said intermediate state information is transmitted as a server request. 40. The method according to claim 30, wherein the set of rules further comprises the following rule: if said response information does not contain any contra- dictions and said free state information occurs in said response information and said client state information occurs in said intermediate information, then the merged information is further transmitted as a server request. 41. The method according to claim 30, wherein the set of rules further comprises the following rule: if said response information does not contain any contradictions and said client or server states in said response information are not equivalent to said client states in said intermediate state information, then said merged state information is transmitted as a server request. 42. The method according to claim 31, wherein said server states and said client states overrule said free state information in said merging process. 43. The method according to claim 31, wherein said merged state information is created according to the following rule: if said response information is equivalent to said intermediate information, then said merged state information is set similar to said response state information in at least some occurrences. 44. The method according to claim 31, wherein said merged state information is created according to the following rule: if said server states in said response information are not equivalent to said server states in said intermediate information, then said merged state information is set similar to said response state information in at least some occurrences. 45. The method according to claim 42, wherein said merged state information is created according to the following rule: if said client states in said response information overrule said intermediate information, then said merged state information is set similar to said intermediate state information in at least some occurrences. 46. The method according to claim 42, wherein said merged state information is created according to the following rule: if said server states in said response information overrule said intermediate information, then said merged state information is set similar to said response state information in at least some occurrences. 47. The method according to claim 31, wherein said merged state information is created according to the following rule: if said free state information occur in said response in- formation and said server state occur in said intermediate information, then said merged information is set to free state information in at least some occurrences. 48. The method according to claim 31, wherein said merged state information is created according to the following rule: if said free state occurs in said response information and said client state occurs in said intermediate information, then said merged information is set similar to said intermediate state information in at least some oc- currences . 49. The method according to claim 31, wherein said objects are merged individually, and wherein each object is associated with an action according to said set of rules. 50. The method according to claim 49, wherein said action is determined for a whole state vector as that action which maximises client selections while fulfilling system/model constraints. 51. The method according to claim 49-50, wherein said action is determined based on a ranking of a set of possible actions by for each object involved in the merging determining an action and selecting the action which re- quires most computational effort or user interaction. 52. A method of controlling the flow of information in a client/server system for interactive configuration, wherein a request to a rule is processed, comprising the steps of: - providing request information, resulting from a client interaction; - transferring said request information to a server; - creating response information on the server responsive to said request information; - transferring said response state information to the client; - creating merged information responsive to said request information and said response information; - determining an action according to a strategy, comprising the following strategy: if said response information does not contain contradictions, then the client is updated with the merged information for at least some combinations of request and response information; if said response information contains contradictions, then a client interaction is requested for at least some combinations of request and response information. 53. A computer system for interactive configuration com- prising a client having a user interface and a memory, and a server having a memory, said client and server being connected by a communication link; wherein the memory in said client holds a client procedure for: - providing request information, resulting from a first client interaction by means of said user interface; - transferring said request information to the server; - collecting intermediate information, resulting from a second client interaction succeeding said first client activation; and wherein the memory in said server holds a server procedure for: creating response information on the server responsive to said request information; and transferring said response information to the client; said request and response information being represented by means of a finite number of states; said client proce- dure creating merged information responsive to said intermediate information and said response information; and determining an action according to a set of rules, at least comprising the following rules: if said response information does not contain contradic- tions, then the user interface is updated with the merged information for at least some occurrences of request and response information; if said response information does not contain contradictions and said response information is not equivalent to said client states in said intermediate information, then the client generates a new server request; if said response information contains contradictions, then a client interaction is requested for at least some combinations of said intermediate and said response information. 54. A computer system for interactive configuration according to claim 53, wherein said state information is contained in a state vector with a number of objects and wherein each object has a state representation. 55. A computer system for interactive configuration according to claim 53-54, wherein said objects in said request information are determined as the objects involved in said first client interaction. 56. A computer system for interactive configuration according to claim 53-55, wherein said objects in said intermediate information are determined as the union of objects comprised by all intermediate information collected after transmission of said request information and before receiving said response information. 57. A computer system for interactive configuration according to claim 53-56, wherein said objects in said re- sponse state vector are determined as the union of objects involved in said first client interaction and the objects which are included in said result of server calculations . 58. A computer system for interactive configuration according to claim 53-58, wherein the set of rules further comprises the following rule: if said response information contains a contradiction and said client states in said response information are dif- ferent from said client states in said intermediate information, then said contradiction is possibly resolved and said intermediate information is transmitted as request information. 59. A computer system for interactive configuration ac- cording to claim 53-58, wherein the set of rules further comprises the following rule: if said response information contains a contradiction and said client states occur in said response information and said free states occurs in said intermediate information, then said intermediate state information is transmitted as a server request. 60. A computer system for interactive configuration according to claim 53-59, wherein said objects are merged individually, and wherein each object is associated with an action according to said set of rules. 61. A computer system for interactive configuration according to claim 53-60, wherein said action is determined for a whole state vector as that action which maximises client selections while fulfilling system/model constraints . 62. A computer system for interactive configuration ac- cording to claim 53-61, wherein said action is determined based on a ranking of a set of possible actions by for each object involved in the merging determining an action and selecting the action which requires most computational effort or user interaction.

Inventors: JOERGENSEN NIELS, JOERGENSEN, NIELS
Applicants: BAAN FRONT OFFICE SYSTEMS A S, JOERGENSEN NIELS, BAAN FRONT OFFICE SYSTEMS A/S, JOERGENSEN, NIELS
Application year: 1998
Main classification: G06F17
IPC codes: G06F9, G06F17, G06N5