WO2000038090A1

WO2000038090A1 - Method for trying to supply a potential customer with at least one selected product offer

Info

Publication number: WO2000038090A1
Application number: PCT/IB1999/001613
Authority: WO
Inventors: Christian Facciorusso; Simon Field; Yigal Hoffner; Matthew R. Robinson
Original assignee: International Business Machines Corporation
Priority date: 1998-12-21
Filing date: 1999-10-01
Publication date: 2000-06-29
Also published as: TW571208B

Abstract

A method for trying to supply a potential customer with at least one selected product offer out of a set of available product offers is proposed. The product offers are provided by a product supplier, whereby each available product offer comprises a product description. When the product supplier further has provided at least one supplier constraint concerning the potential customer and the potential customer has provided a customer description and at least one customer constraint concerning the available product offers, the following steps are performed. The customer constraint is compared with the product descriptions in order to find at least one approximate or complete match between them. The supplier constraint is compared with the customer description in order to find at least one at least approximate match between them. Finally only those product offers whose product description at least approximately matches the customer constraint and where the customer description at least approximately matches the supplier constraint, are selected and provided to the potential customer.

Description

METHOD FOR TRYBNG TO SUPPLY A POTENTIAL CUSTOMER WITH AT LEAST

ONE SELECTED PRODUCT OFFER

The invention relates to a method for trying to supply a potential customer with at least one selected product offer out of a set of available product offers, a storage medium comprising machine-readable code thereof, a data-processing unit equipped with such a storage medium, and an apparatus comprising storage means, comparison means and selection means.

More particularly, it relates to a method for providing a potential customer with a selected product offer that matches his requirements, while the customer description matches given supplier constraints.

TECHNICAL FIELD AND BACKGROUND OF THE INVENTION

Trading is defined as the activity of choosing products, such that they match some product requirement. A "product" can be an item of any type, as well as an arbitrary service. A "product supplier" is any person, company or other legal entity, e.g. a service provider, that offers a product for sale, rent, loan or other change of ownership, be it definitely or temporarily, for free or for something in return. The choice of a product is based on the comparison of the specification of a product required, supplied by a prospective customer, and the product specifications supplied by the product suppliers or their agents [Deschrevel, J-P., "The ANSA Model for Trading and Federation", APM.1005, Architecture Projects Manage- ment, APM Ltd., Poseidon House, Castle Park, Cambridge CB3 ORD U.K., 1993]. The OMG trading object product [OMG RFP5 Submission: CORBA Trading Object Product, OMG Document orbos/96-05-06, May 10, 1996] facilitates the offering and the discovery of instances of products of particular types. A "trader" is an object which supports the trading object product in a distributed environment. Trading can be viewed as a way of providing product suppliers with the ability to advertise or "export" their product offers, and potential product consumers with the ability to search or "query" a set of products offers to find those which match their needs. The CORBA Trading Object Service specifies the interfaces of such a product and the operations which can be performed on such a product.

In the document ANSA Phase in, "A designer's introduction to trading" by Y. Hoffner, APM.1387.01, 13th Dec. 1994, Architecture Projects Management, APM Ltd., Poseidon House, Castle Park, Cambridge CB3 ORD U.K., the principle of symmetric information exchange between a client and a server is discussed. The client therein obtains information about servers while the servers receive information about potential clients. Thereafter, different aspects of the supplied client and server descriptions may be compared and tested for compatibility. It is stated that not a complete match between clients and servers is needed, but a sufficiently close match suffices. What constitutes a "sufficiently close match" is not answered in this document. It is also not specified, where, how and by who the matchmaking is to be performed.

The current trading model is based on an one-way match-making relationship between the client and the product supplier. A product supplier advertises itself in terms of properties it asserts about itself in the export operation. An example of a product property sequence is: "Price_CentsPerPage =55 Quality = Ηigh'". A client can constrain the search for appropriate offers by supplying a customer constraint expression when performing the query operation. An example of a customer constraint expression is: "Price_CentsPerPage < 100 and Quality = ^vHigh"\ This customer constraint expression is applied by the trader to the property sequence associated with each product offer previously advertised. By applying the above mentioned client constraint "Price_CentsPerPage < 100 and Quality = Ηigh'", to a product (assuming a conformant type) and the above product property sequence, the result of the match-making will be successful. Applying the same constraint to a product advertised with the product property sequence: "Price_CentsPerPage = 200 Quality = "High"', would have resulted in an unsuccessful match.

The one-way nature of the relationship stems from the fact that the client has the ability to define the selection criteria by which the product will be chosen, while not allowing the product supplier to do likewise. The client does not supply any description of itself, only of what it requires, and the product supplier cannot select the client by specifying a selection criteria to be applied to it.

OBJECT AND ADVANTAGES OF THE INVENTION

It is an object of the invention according to claim 1 to provide for a method that allows a product supplier to specify constraints also with regard to a potential customer, while the customer is provided with information, enabling him to establish a commercial relationship for products that match his requirements. Thereby the supplier/customer relation is more balanced, in that both sides can specify constraints which lead to a selection of the partner, i.e. whether a commercial relationship can be established or not. The outcome is fairer, since also the product supplier can influence the outcome of the commercial-relationship- establishing procedure.

In the subclaims various modifications and improvements to claim 1 are contained.

When the comparison between the customer constraint and all or a subset of the available product descriptions is preceding the comparison between the supplier constraint and the customer description, the possibility is created that the potential customer can choose from the product offers without needing to bring in his customer description. This will allow a situation when the customer description need only be specified when a matching product offer has been found, i.e. when there is a product that matches the potential customer's desires, respectively constraints. This promotes some stage of anonymity in that as long as no matching product has been found, the potential customer can remain anonymous. On the other hand, the whole process can also be applied the other way round, in that first a match between the customer description and the supplier constraint is searched and afterwards the match between customer constraint and product descriptions is searched for. This turns then the above named advantages towards the product supplier. For instance the product supplier can only offer products to potential customers who satisfy his constraints. Such a constraint can be a credit card, the age, sex, nationality a.s.o. Also mixed forms are applicable, i.e. some customer constraints are compared with the product descriptions first, then some supplier constraints with the customer description and afterwards other customer constraints with the product descriptions. Generally, when it is talked of a description and a constraint, any such expression, a part of it or a group with several of it can be used. One will only compare those pieces of information with each other that are suited and/or needed to perform the comparison. Such alternating comparison schemes can be chosen e.g. for first checking the customer age, then adaptively offering a first selection of products, i.e. chosen to match the customer age, then having a comparison step which e.g. tries to find among various radios the ones that according to the customer constraint have a PLL tuner, and finally checking whether the customer has a suitable credit card. Those alternating schemes need of course more sophisticated and complicated comparison schemes than those that simply perform one comparison set for the customer constraint / product description and another before or afterwards with the customer description / supplier constraint.

Whenever the at least approximate match between the customer constraint and the product descriptions occurs, the comparison between the supplier constraint and the customer description can be performed. Then the advantage occurs that a smaller number of supplier constraint/customer description comparison steps need be performed, namely only for those cases, where a match occurred in the first comparison step. The product offer can then be selected right away and be presented to the customer. On the other hand, if several matching products are awaited to group up, until they are selected to be shown to the potential customer, he has the possibility to compare them among each other.

A compromise between both methods can be to perform the customer constraint / product description comparison step until a certain number of matching products has occurred and then to perform for these products the supplier constraint / customer description comparison steps. This leads to a groupwise treatment and a groupwise selection and presentation to the potential customer who can then at least in that group can perform his own, maybe very personal selection.

It may be conceived that the potential customer can then even deselect, or respectively select the one or other product from the presented list and thereby restrict the presentation to his favorites. By that the potential customer can have also various groups e.g. on a screen among which groups he can perform additional selections according to his personal desires or needs. He can then also formulate new customer constraints which he might adapt to the then displayed selection, in that these constraints are significant for the further reduction of choosable products. The system, i.e. the product supplier might insofar interfere in that according to the actually displayed list he might propose significant product differences as basis for customer constraints, i.e. the product supplier might propose that the potential customer e.g. chooses for the radio example as next customer constraint the maximum loudness or the question whether a balance control exists or not.

The decision on which of the comparisons shall be performed first can be based on a value derived from previous executions of said method and/or on the preference of the potential customer and/or product supplier and/or a method parameter, such as execution speed or execution cost. This leads to the advantage that the system chooses the most probably efficient comparison strategy according to its experience. Such experience can be based on former executions, i.e. another customer has already queried the same product category, or also the same customer has already used the system for another category or also a mixture of these experiences. This approach exploits the tendency of humans to form habits and hence in some way performs an adaptive self-learning effect. It can be assumed that the more often the system is used and the more people it is used by, the better is the overall system efficiency concerning product searching. Anyway, it may be conceived that a customer can simply overrule such system behavior and instruct the system to use his preferred comparison process strategy. A respective input mechanism can be provided therefor, e.g. for speci- fying the number of products that are to be grouped together before the second comparison step follows the first.

When right after it has been found that the at least approximate match between the customer constraint and the product descriptions, and the at least approximate match between the supplier constraint and the customer description has occurred, the selected product offer is immediately presented to the potential customer, he is confronted in shorter time with a matching product offer. If the potential customer then chooses to terminate the comparison process, the whole process is shortened to the satisfaction of the potential customer and the product supplier. Particularly for a huge number of product offers and a also big number of matches for the customer constraint / product description comparison step, this might have a significant impact on the final total product choice time. On the other hand, if more matching products are selected to be shown to the potential customer, he has the possibility to compare them among each other.

The comparison process can be stopped as soon as the potential customer has accepted one of the selected product offers. This avoids unnecessary comparisons, since the main interest of the potential customer is apparently fulfilled and it can be assumed that the potential customer behaves like the most, i.e. wants to choose only one product. It might be conceived to offer to the potential customer the choice to continue the process although he has already accepted an offer. This choice can be provided by offering a respective input mechanism for the potential customer. The advantage that the product supplier can immediately react and thereby shorten e.g. online time for a contract conclusion, is realized when the fact that the potential customer has accepted one of the selected product offers is communicated to the product supplier .

For the product descriptions and/or the supplier constraint and/or the customer constraint and/or the customer description an input interface should be supplied, since this facilitates the whole process. The risk of failure due to a non-understanding of an input expression is extremely reduced. The standard can either be applied in that an automatic standardization interface translates user input into this language or in that the user already was instructed which terms are to be used, e.g. in form of system-based on-screen proposals in menu form or the like. The CORBA Trading Object Service standard constraint language is therefor an excellent choice since this language has already been adopted by a number of entities in the course of trading which makes the introduction of a system easier.

It proves of advantage when the potential customer 1 and the product supplier 2 can both use a language that allows them to use the same name for the same type of information. E.g. the potential customer 1 can specify his creditcard type as "client_credit_card = Visa" and the product supplier 2 can specify his supplier constraint as "supplier_credit_card = Visa". The trader can then easily process comparisons since he can derive the pairs to be matched among each other by analysis of the variable name. It can here be seen that in the case of several constraints 6, 8, the trader has the task to find the respective comparison partner among the descritions 6, 9, since it makes no sense to compare different types of information, e.g. a product size constraint with a product price descrition. It also makes sense to be able to use the described properties of both, potential customer 1 and product supplier 2, in their constraints 6, 8. The product supplier 2 can for example then simply specify "client_credit_card = supplier_credit_card" independent from the finally in fact used credit card type.

The supplier constraint can also be compared with the customer description and with the product descriptions, as well as the customer constraint can be compared with the product descriptions and with the customer description . This method improvement is of advantage since it allows more complex comparison schemes. The supplier can thereby couple his supplier constraint to a specific part of the supplier description. This tri-member comparison can be used to formulate constraints that refer to both descriptions 7, 9. For instance a calculated expression as supplier constraint like the following can be used:

"customer_product_prize > supplier_product_prize" or

"customer_product_prize > (customer_nr_of_items * supplier_product_prize_per_item) + supplier_prize_overhead"

whereby the parameters, respectively variables pre-fixed with "customer" are customer descriptions and the parameters pre-fixed with "supplier" are supplier descriptions.

The described method proves particularly advantageous since it can be carried out by technical means, such as a computer program.

It is another object of the invention to provide a trading service apparatus, short trader, which performs the task of trying to provide the customer with a selected product offer.

Generally the comparison is intended to lead to a match. The result of a match need not be a pure yes/no decision, since this can be realised such that on one hand the criterion of a successful match is that only a certain percentage of exactly matching information needs to be present and on the other hand, a match can also be made dependent on other criteria, such as the price of the product. For instance the requirement that the customer has to pay with a valid specific credit card, can be reduced to a valid credit card of any other type, when the product price is very low, or the creditibility of the customer is known to the trader from other sources.

The process described in this proposal supports the two-way match-making of client and product supplier description and requirements.

SUMMARY OF THE INVENTION

In order to make the process of trading two-way with regard to the match-making process, the ability of the client to constrain the search is complemented by enabling the product supplier to do likewise. Thus, the client can supply a property-sequence describing itself, and the product supplier can supply a constraint expression specifying its requirements of the client. This provides the product supplier with the ability to constrain the search in a similar manner to that already given to the client. The result is a two-way match-making process.

The sequence of events in the proposed extended trading differs from the known process in several points:

For export, the product supplier advertises its product offer by providing a description of the product as in the known trading scenario. In addition, the product supplier includes a set of requirements of the potential client or customer described by a constraint expression, also referred to as supplier constraint.

To query, the potential customer asks a trader for a product with certain characteristics in terms of product properties. In addition, the potential customer provides a description of itself using a property sequence.

The trader checks the requirements of the potential customer, each specified as a constraint expression, against product descriptions, specified as a sequence of properties, and checks the requirements of the product supplier, specified as supplier constraints, against the customer description, specified as a sequence of properties, which the product holds. The match-making between client query and each product offer is done by evaluating each constraint expression against the related properties.

If successful, the trader returns to the potential customer one or more product offers, that is a description of each product which matched the requirements. The potential customer can then choose one of the offers, contact the product supplier and rent, buy or otherwise use the product.

DESCRIPTION OF THE DRAWINGS

Examples of the invention are depicted in the drawings and described in detail below by way of example.

It is shown in:

Fig. 1 a schematic representation of a trading environment with a potential customer and a product supplier. All the figures are for sake of clarity not shown in real dimensions, nor are the relations between the dimensions shown in a realistic scale.

DETAILED DESCRIPTION OF THE INVENTION

In the following, the various exemplary embodiments of the invention are described.

A potential customer 1 is willing to buy a product or at least to get information about available products and therefor gets into communication with a trading service means 13, also referred to as trading service apparatus or simply trader 13 which is connected to the potential customer 1 as well as to a product supplier 2. This connection can typically be a connection via computers which are connected via the Internet.

The product supplier 2 has provided a set of product offers, i.e. offers of different products, each comprising a product description 9 for the respective product. These product descriptions 9 may each contain different product features. Here exemplarily as the product, a computer equipment is contemplated. The product descriptions 9 contain for this example as product features e.g. processor speed, harddisk size, product prize etc.. Furthermore, the product supplier 2 has provided a supplier constraint 8, which is an expression which tells which features the product supplier 2 wishes the potential customer 1 to have. On the other hand, the potential customer 1 has provided a customer description 7 of himself which tells which features the potential customer 1 in fact has. Such features my for example be the age, nationality, creditibility, credit card type, bank account coverage etc..

The potential customer 1 further provides a customer constraint 6 which contains the desired product features for a product the potential customer 1 wishes to buy, loan, rent, borrow or otherwise use or get into his possession or simply get information of.

The potential customer 1 and the product supplier 2 both make use of the trader 13. This trader 13 has the task of satisfying the potential customer's 1 wish to get information over a selection of products that match his desires and to have only those potential customers 1 provided with this information who match the desires, respectively constraints of the product supplier 2. Therefor a twofold comparison process is performed by the trader 13. For having all constraints 6, 8 and the descriptions 7, 9 available for comparison, these are stored in a storage means 11. The following is a particular embodiment for a typical sequence of events in trading:

For export, the product supplier 2 advertises its product offer by providing the product descriptions 9. The product descriptions 9 consist each of: a type description, a sequence of properties (name - value pairs) and an object-reference which provides sufficient informa- tion for accessing the product.

To query, the potential customer 1, also referred to as client, asks the trader 13 for a product with certain characteristics, described in his customer constraint 6 in terms of: the required type of product and other constraint expressions. The customer constraint 6 is a well formed expression conforming to a constraint language, e.g. the CORBA Trading Object Service which specifies a constraint language that can be used as a standard. Using a common language for the potential customer 1 and the product supplier reduces the complexity, since there is no need of an intermediate translator who then would have to adapt different languages. Nevertheless, a sort of translator means can be used which provides the potential customer 1 with a fixed set of constraint vocabulary which is tied to the product type the whole action is about. Such language might then be provided also by the product supplier 2 or even be retrieved from a database by the translator means, e.g. in dependence of the product and/or customer nationality.

The trader 13 checks the requirements of the potential client 1, expressed in the customer constraint 6 against the product descriptions 9 that have been exported to it earlier. The match-making between customer constraint 6 and each product description is done by evaluating the customer constraint 6 supplied by the potential client 1 against the properties of each product advertised by the product supplier 2. As product supplier 2 not only the actual vendor of a product but also any intermediate or final deliverer, advertiser or other entity can act. In the case, the potential client 1 only wants to get information about products, without buying them at that point in time and from the product supplier 2, this product supplier 2 can simply be any information provider. The service of customer information may hence be offered independently from the actual product acquisition. Such information service can also be offered for a certain fee. The result of the evaluation of the customer constraint 6 against the properties of each product offer in the trader 13 can be a success or a failure. Here the match-making is contemplated to be not mandatorily a pure match. An almost match, i.e. at least approximate match may suffice. How approximate this may be can again be chosen dependent on the respective case. The trader 13 may therefore have a certain inherent intelligence to be able to define, in which cases stronger matching criteria and in which cases a certain flexibility is allowed for the determination whether a match has occurred or not.

The comparisons are performed here in comparison means 4, 5 which form part of the trader 13. A first comparison means 4 performs the comparison between the customer constraint 6 and the pds 9 while the second comparison means 5 performs the comparison between the customer description 7 and the supplier constraint 8. The comparison steps can be performed simultaneously but also following each other.

So it can be summarized that:

The potential customer 1 provides a description of itself in terms of a sequence of properties, in a similar fashion to the properties of the product, this description being referred to as the customer description 7. The product supplier 2 provides a constraint expression to be applied to clients' property sequence, this expression being the supplier constraint 8. The match-making process in the trader 13 evaluates the customer constraint 6 against the product descriptions 9, and similarly evaluates the supplier constraint 8 against the customer description 7.

In order for the trader 13 to return a successful match to the potential client 1 the following relationship between the two match-making activities is applied:

Successful match between potential client 1 and the product = Successful match of customer constraint 6 applied to the product descriptions 9

AND

Successful match of supplier constraint 8 applied to customer description 7.

The logical combination of the two comparison results is here performed in a selection means 3 which selects those products where the above condition applies, and provides them to the potential customer 1. This can be done e.g. on a screen where the various product offers are then displayed, e.g. in form of a product name and the most decisive product features or properties such as size, price, availability or the like. As displayed features preferably those are displayed that are suited to differentiate the products from each other. This makes it easier for the potential customer 1 to decide among the displayed products using their different properties. The potential customer 1 can finally choose to accept one or more of the product offers and may communicate this to the trader 13, respectively to a therein provided communicator means 10, which then communicates this acceptance further to the product supplier 2, who himself can conclude the deal by acknowledging the accep- tance. Also this acknowledgement can be promoted via the communicator means 10. Electronic payment may also be considered to finalize the deal to one half such that it simply remains to deliver the ordered product or products to the potential customer 1. In case of information products, this also can be done online.

A specific example of the two-way match-making is provided below:

The client 1 supplies as the customer constraint 6: "Price_CentsPerPage < 100 and Quality = "High"' and as customer description 7: "CreditCard = {'Visa', "Master'}". The product supplier 2 supplies as the product description 9: "Price_CentsPerPage = 55 Quality = "High"' and as the supplier constraint 8 "CreditCard = "Visa"'. Evaluating the customer constraint 6 against the product description 9 will return a successful match; similarly in this case evalu- ating the supplier constraint 8 against the customer description 7 will return a successful match, and therefore the overall result in the above case will be a successful match.

In the known trading scenario, a client 1 could constrain the search for a compatible product by imposing some requirements on the product. In the herein proposed two-way trading process, a product can similarly demand that a potential client 1 provides a description of itself and allows the product supplier 2 to place a requirement on the compatibility from his point of view. Thus both the potential client 1 and the product supplier 2 can now supply selection criteria upon which the choice of compatible potential client 1 and product will be determined by the trader 13.

The export and query interfaces to the CORBA trading object service can be the following:

l.OfferId export( Object reference,

ProductTypeName type, PropertySeq properties

) raises( InvalidObjectRef,

IllegalProductType, UnknownProductType, InterfaceTypeMismatch, IllegalPropertyName, Property TypeMismatch, ReadOnlyDynamicProperty,

MissingMandatoryProperty, DuplicatePropertyName

)

The input parameters of the export operation relate to the product being offered. They contain the reference to the point of product provision, the type of the product being offered, and a sequence of properties specified using the CORBA trading object service constraint language. The reply to the operation is an Offerld - a unique identifier of the offer in the trading object service.

The product offer being given to the trader 13 through the export operation, is checked by the trader 13 and if anything is incorrect or inappropriate, this will result in raising an exception to the operation. The exceptions which might be raised are numerous and refer to various objections which the trader 13 may have with respect to the offer being exported.

2. void query( ProductTypeName type,

Constraint const,

Preference pref,

PolicySeq policies,

SpecifiedProps desired_props, unsigned long how_many,

OfferSeq offers,

Offerlterator offer_itr,

PolicyNameSeq limits_applied

) raises( IllegalProductType,

UnknownProductType,

IllegalConstraint, IllegalPreference, IllegalPolicyName , Policy TypeMismatch, InvalidPolicy Value, IllegalPropertyName,

DuplicatePropertyName, DuplicatePolicyName,

)

The input parameters of the query operation relate to the product, the type of the product being searched for, and on the constraint expression specified in the CORBA trading object service constraint language. The reply parameters are the product offers and the offer_itr which facilitates going through the product offers if more than one product offer is returned. The rest of the parameters relate to the search policy that the trader 13 is to apply, the number of matching product offers to be returned, etc. The trader 13 checks the parameters of the operation and raise exceptions in response if they are incorrect or inappropriate.

The proposed new interface which supports the two-way match-making combines features from both the export and the query operations. The constraint parameter is introduced into the export operation and therefore the exceptions which can be raised accordingly are added. The PropertySeq parameter is introduced into the query operation and therefore the excep- tions which can be raised accordingly are added.

l.Offerld export_symmetric(

Object reference,

ProductTypeName type,

PropertySeq properties, Constraint const

) raises(

InvalidObjectRef,

IllegalProductType,

UnknownProductType, InterfaceTypeMismatch, IllegalPropertyName,

Property TypeMismatch,

ReadOnlyDynamicProperty,

MissingMandatoryProperty,

DuplicatePropertyName, niegalConstraint

)

2.void query_symmetric(

ProductTypeName type,

PropertySeq properties,

Constraint const,

Preference pref,

PolicySeq policies,

SpecifiedProps desired_props, unsigned long how_many,

OfferSeq offers,

Offerlterator offer_itr,

PolicyNameSeq limits_applied

) raises(

IllegalProducfType,

UnknownProductType,

IllegalConstraint,

IllegalPreference,

IllegalPolicyName,

PolicyTypeMismatch,

InvalidPolicy Value,

IllegalPropertName,

DuplicatePropertyName,

DuplicatePolicyName,

Property TypeMismatch, ReadOnlyDynamicProperty, MissingMandatoryProperty

)

The same match-making process which is applied in the current CORBA Trading Object Service is applied twice in the proposed match-making process.

1. Match-making of the customer constraint 6 applied to the product description 9;

2. Match-making of the supplier constraint 8 applied to customer description 7;

3. Only if the match-making of both stages is successful, is the entire two-way matchmaking process successful.

The pair of match-making operations can be performed for each product which is advertised in the trader 13. The question arises as to whether the trader 13 should perform both matchmaking operations on each product before progressing to the next product, herein called sequential match-making, or whether it should first perform one match-making operation on all products, then the other match-making operation on those products which did not fail the first one, herein called batch match-making.

When the trader 13 applies sequential match-making, it reads the advertised products sequentially. For each product, it applies one match-making operation. If the match-making fails, it can read the next advertised product. If the match-making is successful, then the other match-making operation is performed. If the second match-making is also successful, the advertised product is added to the set of offers to be returned to the client 1. If the second phase of match-making fails, the trader 13 moves on to the next advertised product.

One advantage of using sequential match-making is that the decision as to which of the two match-making operations should be performed first can be made for each individual advertised product. The trader 13 could apply an algorithm to determine for each product whether first the customer constraint 6 should be matched against the product descriptions 9, followed by the matching of the supplier constraint 8 against the customer description 7, or vice versa. Priority could be determined according to, for example, the lowest cost of execution, or the highest speed of execution, or any other parameter. Reference to the likelihood of failure of clauses in the supplied constraints 6, 8, based on previous match-making experience, could be used to select for execution first the match-making operation most likely to fail, resulting in a choice optimized for speed of execution.

This can be done for each pair of offer/request or groupwise or blockwise. The order of the match efforts can be chosen predetermined, customer-preferenced, supplier-preferenced or optimized by the trader 13, e.g. predicting cost or likelihood to fail.

Choosing the higher likelihood to fail for the first comparison will lead to a shorter overall process time, since less obsolete comparison steps are performed. Since cost is in trading the decisive factor, the question, which comparison scheme offers the lowest cost for achieving a successful result is decisive. For online trading certainly the online time is therefore of central interest since costs regularly rise with online time. Hence it will be in the interest of both partners, the product supplier and the potential customer, to reduce the online time to the minimum. On the other hand, the potential customer will want to be as fully informed as possible. There is certainly some sort of tradeoff which can be satisfied only partially. A best-mode solution might be the way to perform a groupwise sequential process, i.e. one of the two comparison procedures is selected by its likelihood to fail and is performed until a predetermined number of e.g. 5 products out of 100 product offers has resulted in an at least approximate or essential match for the first comparison. Then, for these products the second comparison procedure is performed. Whenever also here a match is encountered, the selection means 3 selects the respective product offer and promotes it to the potential customer 1. The potential customer 1 is thereby supplied with more and more product offers which have passed the two-way match-making procedure. At any time, the potential customer 1 can amend his customer constraints 6 to get a preciser subselection of the selected product offers, or can also reset, i.e. modify his customer constraints, to get an alternative set of product offers. Also at any time can the potential customer 1 accept an offer by communicat- ing with either the trader 13, or even directly with the product supplier 2, or with the product supplier 2 via the trader 13, respectively its communicator means 10. The comparison process might be stopped as soon as an acceptance of a selected product offer is detected. The trader 13 has then fulfilled its task as a sales promoter.

One special case remins to be named, i.e. the case when no product offer returns a twofold match as required. The trader 13 has then tried to provide to the potential customer 1 a product offer that satisfies all comparisons but returns no product offer. This failure can be communicated to the potential customer 1 and this potential customer 1 can then try to amend his customer constraints or customer description, e.g. by offering a different credit card number, and start the process again. It can also be an issue to heold soem of the overall information, i.e. pd, cc, sc, cd confidential. The trader 13 is then the only entity who knows all this information. For instance the product supplier 2 can have an interest in the potential customer 1 not knowing which supplier constraints 8 he pursues, e.g. requiring a certain minimum financial level, since the product supplier would not want to risk a negative publicity on his chosen constraints. Also the potential customer 1 might want to remain anonymous as long as he has not accepted a product offer, in order that his interests not be known to others, e.g. competitors.

Claims

1. Method for trying to supply a potential customer (1) with at least one selected product offer out of a set of available product offers, provided to a trading service means (13) by a product supplier (2), each available product offer comprising a product description (9), whereby in the case said product supplier (2) further having provided to said trading service means (13) at least one supplier constraint (8) concerning the potential customer (1) and said potential customer (1) having provided to said trading service means (13) a customer description (7) and at least one customer constraint (6) concerning the available product offers, said method comprising the steps of comparing in said trading service means (13) said customer constraint (6) with said product descriptions (9) in order to find at least one at least approximate match between them, comparing comparing in said trading service means (13) said supplier constraint (8) with said customer description (9) in order to find at least one at least approximate match between them, and selecting and providing by said trading service means (13) to said potential customer (1) only those one or more product offers whose product description (9) at least approximately matches said customer constraint (6), where said customer description (7) at least approximately matches said supplier constraint (8).

2. Method according to claim 1, whereby the comparison between the customer constraint (6) and all or a subset of the available product descriptions (9) is preceding the comparison between the supplier constraint (8) and the customer description (7).

3. Method according to claim 1 or 2, whereby the each time the at least approximate match between the customer constraint (6) and the product descriptions (9) occurs, the comparison between the supplier constraint (8) and the customer description (7) is performed.

4. Method according to claim 1 , whereby the decision on which of the comparisons shall be performed first is based on a value derived from previous executions of said method and/or on the preference of the potential customer (1) and/or product supplier (2) and/or a method parameter, such as execution speed or execution cost.

5. Method according to one of claims 1 to 4, whereby right after it has been found that the at least approximate match between the customer constraint (6) and the product descriptions (9), and the at least approximate match between the supplier constraint (8) and the customer description (7) has occurred, the selected product offer is provided to the potential customer ( 1 ) .

6. Method according to one of claims 1 to 5, whereby the comparison process is stopped as soon as the potential customer (1) has accepted one of the selected product offers.

7. Method according to one of claims 1 to 6, whereby the fact that the potential customer (1) has accepted one of the selected product offers is communicated to the product supplier (2).

8. Method according to one of claims 1 to 7, whereby for the product descriptions (9) and/or the supplier constraint (8) and/or the customer constraint (6) and/or the customer description (7) an input interface is supplied, which preferably is using a standardized language, particularly the CORBA Trading Object Service standard constraint language.

9. Method according to one of claims 1 to 7, whereby the supplier constraint (8) is compared with the customer description (7) and with the product descriptions (9) and/or the customer constraint (6) is compared with the product descriptions (9) and with the customer description (7).

10. Method according to one of claims 1 to 9, being carried out by means of technical means, such as a computer program.

11. Storage medium comprising machine-readable code of a computerized method according to one of claims 1 to 9.

12. Storage medium comprising machine-readable program code for controlling computer hardware to perform the method according to one of claims 1 to 9.

13. Data-processing unit equipped with a storage medium according to claim 11 or 12.

4. Trading service apparatus (13) comprising storage means (11) for storing product descriptions (9) for available product offers and at least one supplier constraint (8) concerning a potential customer (1), both being providable by said product supplier (2), for furthermore storing a customer description (7) and at least one customer constraint (6) concerning the available product offer, both being providable by said potential customer, comprising furthermore comparison means (4, 5) for comparing said customer constraint (6) with said product descriptions (9) in order to find at least one at least approximate match between them, and for comparing said supplier constraint (8) with said customer description (7) in order to find at least one at least approximate match between them, comprising selection means (3) for selecting and providing to said potential customer (1) only those one or more product offers whose product description (9) at least approximately matches said customer constraint (6), where said customer description (7) at least approximately matches said supplier constraint (8).

15. Apparatus according to claim 14, with decision means (12) for deciding which of the comparisons shall be performed first, preferably having as input variable a value derived from previous executions of said method and/or on the preference of the potential customer (1) and/or product supplier (2) and/or a method parameter, such as execution speed or execution cost.

16. Apparatus according to claim 14 or 15, with communicator means (10) for communicating to the product supplier (2) the fact that the potential customer (1) has accepted one of the selected product offers.

17. Apparatus according to one of claims 14 to 16, with an input interface for the product descriptions (9) and/or the supplier constraints (8) and/or the customer constraints (6) and/or the customer description (7), which preferably makes use of a standardized language, particularly the CORBA Trading Object Service standard constraint language.