AU755756B2 - Decision platform for object comparison - Google Patents

Description

PCT/AU99/00893 Received 15 January 2001 -1- [Amended] 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.

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.

z AMENDED SHE r -2- 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.

Unless the context clearly requires otherwise, throughout the description and the claims, the words 'comprise', 'comprising', and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".

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; S• Figure 2 shows a diagrammatic representation of the qualification process of the •15 invention; Figure 3 shows a diagrammatic representation of a simple template used for initialising an object; Si ~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; SFigure 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; WO 00/23922 PCT/AU99/00893 -3- Figure 10 shows a diagrammatic representation of the beef side element attached to its decision array (cube); Figure 11 shows a diagrammatic representation of seller side application space of the application of Figure 8; and Figure 12 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 WO 00/23922 PCT/AU99/00893 -4with 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 11, 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 WO 00/23922 PCT/AU99/00893 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 Field Purpose Unique ID An integer which uniquely identifies the element.

Parent ID An integer which uniquely identified the parent of the element, or O if there is no parent.

Operator How the comparison is to be made.

Examples of this are: WO 00/23922 PCT/AU99/00893 -6-

EQUAL

GREATER THAN OR EQUAL GREATER THAN AND EQUAL LESS THAN OR EQUAL LESS THAN AND EQUAL' GREATER THAN LESS THAN NOT EQUAL Operand What is the orientation of the comparison. What the comparison is to be performed on.

This embodiment allows comparisons to be performed on: a) A comparison between the states of the consumer object selection and the product object selection b) A comparison between the value of the product object and the value of the consumer object.

Precedence This determines how this element effects the priority of the product object.

The precedence is added to the product objects priority, as it becomes NOT disqualified that is it changes from disqualified to either qualifying or qualified. It is subtracted when the element becomes disqualified.

Data Type This indicates the data type of the value.

Value This is a variable. It could be a string, an integer or any other object. This field is used for comparisons between it and its associated element in the consumer.

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 WO 00/23922 PCT/AU99/00893 -7decision 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 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 WO 00/23922 PC-r/AU99/00893 -8process 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 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.

WO 00/23922 PCT/AU99/00893 -9- 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.

WO 00/23922 PCT/AU99/00893 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 O, 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 O.

Case 2 WO 00/23922 PCT/AU99/00893 -11- 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 LBeef sides LWeight 500 WO 00/23922 PCT/AU99/00893 -12- LVeal [Weight 250 LPrime lamb [Weight 250 2. The product object array Again this describes the complete shipment.

Shipment Beef sides [Beef sides [Weight 500 LVeal [Weight 250 [Prime lamb LWeight 250 3. The beef array A decision array of the beef lot LBeef sides [Weight 500 4. The veal array A decision array of the veal lot LVeal LWeight 250 The lamb array A decision array of the lamb lot.

LLamb 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.

WO 00/23922 PCT/AU99/00893 13- 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 The seller side processing will now be described with reference to Figure 11. 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 WO 00/23922 PCT/AU99/00893 -14object 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 12: Figure 12 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 WO 00/23922 PCT/AU99/00893 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 described.

Claims (12)

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, each element being 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.

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

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

4. A method according to any one of the preceding claims wherein one object relates to a consumer and another object relates to a product.

A method according to any one of the preceding claims 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.

6. 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 -17- being indicative of whether the object has qualified by a successful comparison, is qualifying or is disqualified by unsuccessful comparison, each element being 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.

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

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

9. A system according to any one of claims 6 to 8 wherein one object relates to a consumer and another object relates to a product.

10. A system according to any one of claims 6 to 9 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.

11. A method of comparing properties of objects in a computer environment substantially as herein described with reference to any one of the embodiments of the invention illustrated in the accompanying drawings.

12. A system for comparing properties of objects in a computer environment 20 substantially as herein described with reference to any one of the embodiments of the invention illustrated in the accompanying drawings. DATED this 14 th day of November, 2001 RACEBASE PTY LTD Attorney: PETER R. HEATHCOTE Fellow Institute of Patent and Trade Mark Attorneys of Australia of BALDWIN SHELSTON WATERS