WO2000023922A1

WO2000023922A1 - Decision platform for object comparison

Info

Publication number: WO2000023922A1
Application number: PCT/AU1999/000893
Authority: WO
Inventors: Mark Richard Reay
Original assignee: Racebase Pty Ltd
Priority date: 1998-10-15
Filing date: 1999-10-15
Publication date: 2000-04-27
Also published as: EP1121660A1; AUPP650598A0; EP1121660A4

Abstract

A method and system for comparing properties of objects in a computer environment wherein the objects are defined by an array of elements describing a decision process. Each element contains data related to a particular property or properties of its associated object and a rule or rules for comparison of the property with related properties in another object. The method comprises the steps of comparing associated properties within the objects according to the rule or rules provided by each element and allocating a priority value to the object indicating the state of the comparison of each property. The priority value is indicative of whether the object has qualified by a successful comparison, is qualifying or is disqualified by unsuccessful comparison.

Description

TITLE: DECISION PLATFORM FOR OBJECT COMPARISON

TECHNICAL FIELD

The present invention relates a common decision platform for comparisons of one object to another. It is designed to compare objects, and give a result in the form of the nature of the relationship in a useful manner. DISCLOSURE OF THE INVENTION

According to one aspect the present invention provides a method of comparing properties of objects in a computer environment wherein said objects are defined by an array of elements describing a decision process, each element containing data related to a particular property or properties of its associated object and a rule or rules for comparison of the property with related properties in another object, the method comprising the steps of comparing associated properties within said objects according to said rule or rules provided by each element and allocating a priority value to said object indicating the state of the comparison of each property, said priority value being indicative of whether the object has qualified by a successful comparison, is qualifying or is disqualified by unsuccessful comparison.

In one preferred embodiment the array of elements in hierarchical, in another embodiment the array of elements is relational.

Preferably, said priority value is a numeric value with a first predetermined value representing the object has qualified, a second predetermined value representing the object has disqualifies and wherein a priority value between the first and second predetermined values representing the object is qualifying. For preference, each element is provided with a weighting value indicative of its importance or precedence, said weighting value modifying the priority value in accordance with the comparison state of said element.

According to a second aspect, the present invention provides a system for comparing properties of objects wherein said objects are defined by an array of elements describing a decision process, each element containing data related to a particular property or properties of its associated object and a rule or rules for comparison of the property with related properties in another object, the system including means for comparing associated properties within said objects according to said rule or rules provided by each element and means for allocating a priority value to said object indicating the state of the comparison of each property, said priority value being indicative of whether the object has disqualified by an unsuccessful comparison, qualified or still qualifying.

BRIEF DESCRIPTION OF FIGURES

Preferred embodiments and examples of applications of the invention will now be described, by way of example only, with reference to the accompanying figures, in which:-

Figure 1 shows a diagrammatic representation of a simple two object application of the invention;

Figure 2 shows a diagrammatic representation of the qualification process of the invention;

Figure 3 shows a diagrammatic representation of a simple template used for initialising an object;

Figure 4 shows a diagrammatic representation of association between the elements of each object in the application of Figure 1 ;

Figure 5 shows a diagrammatic representation of the initialised states of the two objects of the application of Figure 1 ;

Figure 6 shows a table of the product object qualification and priority values;

Figure 7 shows a table of the decision array associated with the product object of Figure 6;

Figure 8 shows a diagrammatic representation of the seller and buyer screens of a bid/offer application using the invention;

Figure 9 shows a diagrammatic representation of buyer side application space of the application of Figure 8; Figure 10 shows a diagrammatic representation of the beef side element attached to its decision array (cube);

Figure 1 1 shows a diagrammatic representation of seller side application space of the application of Figure 8; and

Figure 1 2 shows a diagrammatic representation of the interaction between the buyer and seller side application spaces of the application of Figure 8.

PREFERRED EMBODIMENTS OF THE INVENTION

An example of simple application will now be described, referring to the above figures, consisting of two logical components, which can be arranged in a variety of architectures. Typically, each of the components has the same functionality as the other, which is enabled depending on the architecture employed. This is optimal in the current Internet environment because the compiled code is smaller, and thus will transmit more quickly. In a different environment, creating two physical components to do their respective functions may be desirable.

The two components as the product and the consumer, for the purposes of demonstration and give examples of the invention being employed in several architectures.

The two components, and their relationships to each other, are shown in Figure 1 .

From this Figure it can be seen that the consumer object is communicating with the product object and visa-versa. The consumer can be considered the client process, and the product the server process. The consumer provides an interface mechanism to negotiate with the product object. Any changes to the consumer by an external client, such as a user interface, or other external process, are handled by the consumer. This ensures that any changes in state are directed to the appropriate processing in the product object.

It should be noted that this client server relationship can be repeated ad infinitum. One consumer can have, and usually does many products associated with it. Also one product may have many consumers associated with it, this depends on the application.

Also, one product may act as a client to many consumers, in the case of the product being the client, and the consumer being the server. This is demonstrated in Figures 8, 9 and 1 1 , where bid and offer objects are acting as both a client and a server.

The function of invention is to provide meaningful results to a decision process. It does this by the product object firing events on changes to its state of qualification. There are three states of qualification. • Qualified

• Qualifying

• Disqualified

There is desirably a mechanism to define the intermediate state of qualification. To do this the product object has a priority. The priority indicates how qualified an item actually is. Normally, though not necessarily when a product object is fully qualified its priority is 0. As it becomes less qualified, its priority increases. There may be occasions when there is a requirement to determine when a product object is more than fully qualified, in which case, the priority is able to go negative if the product object is instructed to allow it. This is not the normal case however, as the primary function of the priority is to indicate how near to qualified a qualifying item is. There may also be a reason to indicate how disqualified a product object is. To enable this, the priority continues to change even after the product disqualifies. This ability is also optional. Figure 2 shows the product objects qualification process. As the consumer object varies items within the product object, the product object's qualification and priority may vary. The qualification is varied by the decision structure within the product object, and the priority is varied by the precedence of elements within the product object, depending on their qualification state. Qualification may also be decided purely on priority.

The qualification process occurs within the product object. It is determined by what we refer to as a decision array. This array is typically a multi dimensional array of product elements. Each of these elements has a qualification. The qualification is determined by the item state and optionally also by the items child states in relation to items in the consumer object.

To allow the qualification process, the product object needs to be initialised. This initialisation can occur in one of two ways. It is either initialised by an external template, or as a subset of a parent product object.

The external template can be supplied via any means. The containing process is responsible for retrieving the template from its archive and initialising the product object from the template data. For this embodiment, it will be assumed all external template data arrives from a database somewhere in the form of a data set.

The template as a data set consists of a number of records. Each record describes a single element that is part of the product objects decision array. Typically there are many elements in a decision array. Each template record may contain at least the following details, however, it will be appreciated that the type and function of records can be varied to suit the particular application:

• The parent ID of the element, if any.

• The unique ID of the element.

• The operator of the element.

• The operand of the element. • The precedence of the element.

• The data type of the element.

• The value of the element.

These fields have the following purposes

From the template the product object can be created. Each template record goes towards creating an element in the decision array. An example of a simple decision array is the array for a simple comparison of financial products on an Internet based comparison site.

To create the template, typically all the products that are to be processed by the array are analysed, and the properties they have which relate to the decision process isolated. Each of these properties is arranged in a hierarchy to reflect the decision process. A simple sub-section of this template consists of loan repayment options available. For the purposes of explanation this will be used as a template. The template shown in Figure 3, illustrates a simple decision array. The array is referred to as a cube in the figures. Its only two dimensional, and has in total, only seven elements.

From this example, we can examine how the product consumer relationship effects the product decision array, but first we will explain the consumer object.

As mentioned earlier, the consumer object is the interface between the external process and the qualifying product objects. It consists of the same type of template that can make up a product object. The consumer object may or may not have elements associated with any particular product object. In this example it does. The consumer object template is identical to the product object template, and each element in the consumer object is associated with its related element in the product object. The consumer maintains a list identifying this relationship. This is association shown in Figure 5.

By means of this association, the consumer object is able to communicate changes to the consumer object to the related element in the product object.

An example of a scenario, which may occur with this template is as follows. The product object has been initialised, and the consumer object has been initialised, in this case both from the same template (some of the fields used to initialise the consumer object are not necessary for the initialisation of the consumer object). Masking occurs to both the product object and the consumer object. It may or may not be part of the initialisation process. In the case of the product, it usually is, and in the case of the consumer, it sometimes is. Masking completes the initialisation of a decision object by setting its initial state.

For this example, the product object is attached to a product which has only four available repayment periods - daily, weekly, two-weekly and monthly. The process needs to set the selection of the other three objects from the external process. To do this, the external initialisation process needs to mask out the related records in the product object, that is the quarterly, semi-annual and annual repayment options. These are not available to that product. To do this the external process sets the selection of these items to false.

The consumer object needs no masking during initialisation. Any consumer object masking at initialisation is in regard to setting the defaults. In this case the default is all repayment periods are selected.

At the end of this process the consumer and product objects are in their fully initialised states and ready to run and are shown in Figure 5:

The ticks represent items, which are selected, and the crosses represent items, which have been masked.

In addition to a selection, the initialisation has also caused the product object to calculate the initial qualification of each of its elements, and also the priority and qualification of the product object. The mechanism for doing this is explained in the following section named qualifying. In summary the initialisation process has left the two objects in the state shown in Figure 5. The product object has also initialised a lot of variables behind the scenes, which are intrinsic to the operation of the mechanism. The tables of Figures 6 and 7 show the detail of the state of each element.

The qualifying process will now be described. Qualifying involves the consumer object being changed by some external process, for example, a user interacting with a user interface, which in turn sets the selection of an item in the consumer object. This is the same mechanism that the product object uses at initialisation time to perform masking - in fact it is the same process, except the user interface is masking elements in the consumer object, instead of the initialisation routines.

After initialisation the product object is in a qualifying state, that is not fully qualified and not disqualified. The priority is at 28 which means it is some way off fully qualified, as three of the most important elements (those with the highest precedence) are disqualified. Now say, for example, the consumer object has its annual selection changed. In this scenario, this has happened because the user has specified that he or she does not need annual repayments.

So the set selection method in the consumer object receives a notification telling it to change the annual selection from true to false. This it does, then checks its products associated list to find any product elements associated with it. It finds only one - the annual element in the one and only product object. The consumer object then sends a notification to the product object telling it to requalify its annual element against the new consumer profile.

The product object receives the notification, telling it to requalify its annual element against the new consumer state. This requalification occurs in two stages.

• Stage 1 - Qualify the element itself

Qualifying the element itself occurs as follows. The product object compares the element to its related element in the consumer object, in the manner specified by the elements rules. In this case, the operand specifies the comparison is to be done by comparing the selection of the product object element to the selection of the consumer object element. The operator specified that if the two items to be compared are equal, the comparison is true, otherwise it is false. In this example, the comparison returns true because the selection in both elements is false. Therefore, the qualification of the annual element changes from being disqualified to being qualified (there is no grey area in an = to comparison. It either is or is not - qualified or disqualified). The change causes the precedence of the element to be subtracted from the product objects priority therefore the priority is now 21 (28 - Annual element precedence = 21 )

So the action has caused a change to the qualification of the annual element from false to true. This change causes stage two of the qualification process to be initiated.

• Stage 2 - Qualify the parent. The change in the qualification of one of the children in the hierarchy involves this routine in the parent. It is now necessary to examine the qualification of all the child items in relation to their relative consumer items and apply the parent qualification logic to them in the manner specified by the product object's parent element - the 'repayment period' element in the example given.

In this instance the parent qualification does not change. This item remains only still qualifying, because the semi-annual and quarterly elements are still disqualified.

At this point stage two finishes because there is no change.

This process is repeated when the user selects any other item of the children until one of two things happen. Either the user deselects both the quarterly and semi-annual elements, or the user deselects all elements.

Case 1

The user deselects the semi-annual and quarterly elements. This causes the parent to become qualified. When this occurs, the change from qualifying to qualified causes the parent elements precedence to be subtracted from the product objects priority. This causes the priority to become 0, indicating the product object has now become qualified.

Stage 2 of the process is iterated up the tree structure by performing it for the parent element's parent, until there is either no parent, or no change to the parent's qualification. In this instance, because the parent is the root element, it has no parent so iteration stops at one level. Alternatively, the setting, of the qualification in the root element can be used to set the qualification of the product object, rather than the priority becoming less than 1 .

At the end of this process the product object is fully qualified and its priority is 0.

Case 2 The user deselects all elements. With the current operator, this causes the product object disqualify, because all elements in the decision array have disqualified.

At the end of this process the product object is disqualified and its priority is 38.

Another example of an application of the invention is a negotiation process between seller and buyer. In the following example, there are two clients connected over the Internet to a meat producer. They are negotiating to buy wholesale meat as a shipment. The shipment consists of a number of lots.

The shipment being defined thus: Shipment

500 Tonnes Beef Sides

250 Tonnes Veal

250 Tonnes Prime Lamb

So we can see that the shipment is made up of four components, the shipment and the three lots being offered.

The producer has a package they wish to sell. It does not match either of the client's requirements, and the price being bid does not meet the supplier's offer. He wishes to offer the bidders a slightly different package, in the hope of making a sale at an acceptable price to one or more of them.

There are five logically distinct decision arrays created to handle this scenario. They are shown below.

1 . The consumer object array

This describes the complete shipment. Its hierarchical array can be illustrated as follows: Shipment

Beef sides

|_Beef sides

LWeight 500 LVeal

LWeight 250 LPrime lamb

LWeight 250

2. The product object array

Again this describes the complete shipment. Shipment

Beef sides |_Beef sides

[Weight 500 LVeal

LWeight 250 |_Prime lamb LWeight 250

3. The beef array

A decision array of the beef lot l_Beef sides

LWeight 500

4. The veal array

A decision array of the veal lot LVeal

LWeight 250

5. The lamb array

A decision array of the lamb lot.

[_Lamb

LWeight 250

The beef, veal and lamb arrays may be, though not necessarily logical objects, consisting of a pointer to the relative node in product object array. Now we have these arrays they are attached to their relevant objects within the application. In this scenario, we assume the user interface for the application looks like that shown in Figure 8.

To provide this application, a means to communicate between the clients and the server is required. It be will assumed the Internet is employed using whatever inter-process communication protocols are suitable, however, it will be appreciated that this architecture will work with any suitable means of communication, as it will work in a single process.

The underlying application structure, when separated it from its user interface and its communication mechanisms can be simplified for the purposes of demonstration to a buyer communicating with a seller.

First we will look at the invention employed in the buyer side of the application. It consists of a consumer object representing the shipment, and two product objects, again representing the shipment. From Figure 9, it can seen three decision objects are required. The buyer, through his user interface communicates to one. The others send messages to the buyers bid object and receive messages from the sellers offer object telling them (typically) to update what the buyer sees on their bid and offer screens according to the state of the underlying decision objects. As specified earlier, each shipment object contains four product objects, so with the consumer object we have nine objects - three physical and six logical.

Each of these objects is attached to a data set, which gives further information about the item we are dealing with. The decision system of the invention controls the state of this object, by separating any decision-related properties from the rest of the data.

Taking the beef sides element, the beef array is associated to it as shown in

Figure 10:

The seller side processing will now be described with reference to Figure

1 1 . The underlying seller side application space is almost identical to the supplier side processing for the purposes of negotiation. There are only really two differences - the seller has a buyer list to hold a reference to each buyer's session and the seller's consumer object is attached to the buyer's offer object.

In the simplified example illustrated, the seller's buyer list contains only one object referring to the single bid object which is controlled by the one and only negotiating buyer. The seller's consumer object allows him or her to make offers to the one and only buyer's product offer object.

With the addition of the underlying communications necessary we now have a application which will work over any network. It is also platform independent. In an internet scenario, the underlying network communication protocol is TCP/IP. The inter-process communication protocols vary depending on the implementation platform of the application. Regardless of whichever technologies are used, the complete application architecture typically looks like that shown in Figure 1 2:

Figure 1 2 demonstrates a complex scenario which allows multiple sellers to offer to multiple clients, and multiple clients to bid with multiple sellers. There are no limits imposed by the invention on the complexity of the application. All it does is provide a decision logic array which can be attached to any or all objects involved in the negotiation process. Manipulation of the decision arrays will now be described. In this application there are two consumer object decision arrays which manipulate two physical product object decision arrays each. Each physical product arrays has three child product arrays, which are manipulated as the parent is manipulated.

The buyer and the seller have a consumer array each. This allows the buyer to manipulate the two bid arrays (which are analogous to the product objects previously referred to) through it (one on the buyer's machine, and one on the sellers machine). The seller is able to maintain the two offer arrays via his or her consumer array.

As an example of this manipulation, take the case of the seller wishing to offer buyer the shipment without the beef component. He or she deselects the beef component in his consumer array. The consumer array communicates with the two product arrays associated to it, telling each of them to requalify themselves according to the new consumer profile. The product arrays perform the qualification process as described above, and each of the arrays sends a message, which is detected by their relative user interfaces. In response to this message, the interfaces update their appearances to reflect the new state of their product arrays - so the buyer's and seller's offer screens change.

This example illustrates how the invention works for a simple scenario and it will be appreciated by those skilled in the art that the invention can be applied to highly complex bid-offer applications. All that is required is that the user interfaces are changed to give the correct appearance to the application, and that initialisation templates are created which specify the decision logic required for the products to be handled.

It will be appreciated that further embodiments and exemplifications of the invention are possible without departing from the spirit or scope of the invention

Claims

CLAIMS:

1 . A method of comparing properties of objects in a computer environment wherein said objects are defined by an array of elements describing a decision process, each element containing data related to a particular property or properties of its associated object and a rule or rules for comparison of the property with related properties in another object, the method comprising the steps of comparing associated properties within said objects according to said rule or rules provided by each element and allocating a priority value to said object indicating the state of the comparison of each property, said priority value being indicative of whether the object has qualified by a successful comparison, is qualifying or is disqualified by unsuccessful comparison.

2. A method according to claim 1 wherein said priority value is a numeric value with a first predetermined value representing the object has qualified, a second predetermined value representing the object has disqualifies and wherein a priority value between the first and second predetermined values representing the object is qualifying.

3. A method according to claim 1 or claim 2 wherein each element is provided with a weighting value indicative of its importance or precedence, said weighting value modifying the priority value in accordance with the comparison state of said element.

4. A method according to claim 2 wherein the priority value can exceed the predetermined values to indicate over qualification or disqualification.

5. A method according to claim 1 wherein one object relates to a consumer and another object relates to a product.

6. A method according to claim 1 including the step of initialising the data in each element using a template defining initial property and rule data to be held by the array.

7. A system for comparing properties of objects wherein said objects are defined by an array of elements describing a decision process, each element containing data related to a particular property or properties of its associated object and a rule or rules for comparison of the property with related properties in another object, the system including means for comparing associated properties within said objects according to said rule or rules provided by each element and means for allocating a priority value to said object indicating the state of the comparison of each property, said priority value being indicative of whether the object has qualified by a successful comparison, is qualifying or is disqualified by unsuccessful comparison.

8. A system according to claim 7 wherein said priority value is a numeric value with a first predetermined value representing the object has qualified, a second predetermined value representing the object has disqualifies and wherein a priority value between the first and second predetermined values representing the object is qualifying.

9. A system according to claim 7 or claim 8 wherein each element is provided with a weighting value indicative of its importance or precedence, said weighting value modifying the priority value in accordance with the comparison state of said element.

1 0. A system according to claim 8 wherein the priority value can exceed the predetermined values to indicate over qualification or disqualification.

1 1 . A system according to claim 7 wherein one object relates to a consumer and another object relates to a product.

1 2. A system according to claim 7 including means for initialising the data in each element of the array using a template defining initial property and rule data to be held by the array.