WO2006015628A2

WO2006015628A2 - Networked system for automatic trading of personalized assets

Info

Publication number: WO2006015628A2
Application number: PCT/EP2004/051797
Authority: WO
Inventors: Chie Noda; Wolfgang Kellerer; Anthony Tarlano; Kiminori Motonaga; Hiroshi Honjo; Christoph Weckerle; Linda Strick
Original assignee: Ntt Docomo, Inc.; Ntt Data Corporation; Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V.
Priority date: 2004-08-13
Filing date: 2004-08-13
Publication date: 2006-02-16

Description

NETWORKED SYSTEM FOR AUTOMATIC TRADING OF

PERSONALIZED ASSETS

FIELD OF THE INVENTION

The present invention relates to a networked system for automatically trading personalised assets.

BACKGROUND OF THE INVENTION

In our days almost all areas of personal and professional life are administrated by comput¬ ers and computer systems, and this is typically done by creating and maintaining data- bases where data related to individuals are stored so that an institution administering such a database may access the data related to a certain individual. If an institution maintaining such a database is an institution like a company which offers certain services, such as a travel agency, an airline, a department store chain, or the like, then the data which is stored in relation with a certain individual typically contains information about certain services which are assigned to a certain individual, such as a flight being booked for a certain per¬ son, a hotel being booked for a certain individual, a ticket for a concert in a concert hall being reserved for a certain person, or the like. Such personalised data are maintained by a certain institution rendering the services, and they may be regarded as "assets" or "claims" owned by a certain individual. These assets or claims correspond to files or rec- ords in the database, and the thus stored data can be accessed or changed by staff mem¬ bers of the institution through computer terminals which are entitled to access said data, however typically not through the individuals themselves. This is mainly for security rea¬ sons in order to make sure that only authorised persons access the database of the institu¬ tion to avoid fraudulent use or "attacks" to such databases. Accordingly, so far it is not pos- sible for the individuals whose data is maintained and stored in the database of such an aforementioned institution to exchange or trade these claims or "assets" amongst each other.

It is therefore an object of the present invention to provide a networked system which is capable of overcoming the aforementioned deficiencies. SUMMARY OF THE INVENTION

According to one aspect of the invention there is provided a networked computer system for trading personalised assets which are stored in a computer of a service institution, said computer being accessible through clients belonging to said service institution and through an enforcement server acting as a mediator between said resource server and computers not belonging to said service institution, said system further comprising:

- a publish/subscribe server capable of receiving transaction proposals, whereas a transaction proposal originated from a certain customer of said service institution comprises an offer, a demand, and a negotiating strategy, said offer and said demand relating to services which may be claimed by or to assets which are owned by said customer as a customer of said service institution;

- an enforcement server , said enforcement server comprising: - a public interface for receiving from a computer outside of said service institution data about a transaction to be performed with respect to the personalised asset stored in said resource server based on a match between two transaction pro¬ posals;

- a non-public interface for contacting said resource server through said non-public interface, said non-public interface being identical to the interface through which client computers of said service institution access said resource server,

- a receiving module for receiving through said public interface data indicating a transaction reflecting a match between two transaction proposals of different customers, - a checking module for checking the validity of said transaction;

- a conversion module to convert said received transaction data into such a format that it can be forwarded to said resource server to thereby trigger the execution of the transaction on the resource server; a contacting module for contacting said resource server of said service institution which maintains a database of said personalised services of said clients through said non-public interface to forward said converted transaction data to thereby trigger the execution of said transaction on said resource server. Such a networked computer system enables the trading of assets owned by users or cus¬ tomers which under conventional system configurations are not tradable by the us¬ ers/customers.

According to one embodiment the networked system comprises: a monitoring server for monitoring transaction proposals stored on said publish/subscribe server as to whether offer and demand of two or more proposals match, said monitoring server further compris¬ ing: a forwarding module for forwarding transaction data to said enforcement server in case of a match between offer and demand of a pair of proposals being detected.

The monitoring server enables an automatic watching for proposals which match, thereby enabling an automated trading process.

According to one embodiment the networked system comprises: a negotiation server for automatically negotiating a settlement between two transac¬ tion proposals which partly match based on a negotiation strategy which has been respec¬ tively assigned to said transaction proposals.

This enables automatically reaching an agreement even in cases where two proposals do not fully match.

According to one embodiment said negotiation server is adapted to negotiate between more than two proposals if one proposal preliminarily matches with more than one other proposal.

According to one embodiment a transaction proposal may contain invariable items and at least one variable item and a negotiation strategy indicating how said variable item may be automatically varied by said negotiation server to reach a settlement; and said monitoring server selects such pairs of transaction proposals as partly matching proposals which coincide at least with respect to the items which in both propos¬ als of a selected pair are non-variable items, and where for the not coinciding items of the proposals belonging to a certain pair at least one item is indicated to be a variable item, said negotiation server automatically varies said at least one variable item ac¬ cording to said negotiation strategy in order to arrive at a full matching between said trans¬ action proposals. - A -

With such a configuration it becomes possible to select such pairs of proposals where the boundary conditions indicate that a settlement might be reached and further enables the reaching of a settlement through an automated negotiation process,

According to one embodiment the negotiation strategy comprises an indication which item of a transaction proposal is variable and further a limit for the variable item or a defined list of variations of said item ordered according to their priority. This makes it possible to set a clear boundary condition for a negotiated settlement.

According to one embodiment said checking module comprises:

- a key infrastructure module for enabling to check based on personalised keys the identity and/or the authorisation of the parties involved in said settlement;

- an identity and/or authorisation database for storing identity information identifying individuals and/or authorisation data indicating whether a certain individual is authorised to execute a certain transaction;

- a determining module for determining whether said transaction should be carried out based on the result from said key infrastructure module.

This makes it possible to check the validity of a transaction proposal to avoid a fraudulent use.

According to one embodiment said publish/subscribe server comprises: a transaction proposal database for storing data sets related to a certain transaction proposal, wherein a data set related to a certain transaction pro¬ posal comprises: • the type of offer indicating the type of asset or service which is to be offered;

• the type of demand indicating the type of asset demanded as com¬ pensation for said offer,

• a sub-type of said offer indicating particulars of said offer; • a sub-type of said demand indicating particulars of said demand; and wherein said negotiation strategy comprises:

• an indication corresponding to said types and sub-types and indi¬ cating whether said types and/or said sub-types may be varied by said ne¬ gotiation engine to reach an agreement between two proposals. According to one embodiment the publish/subscribe server comprises: a push service unit for automatically forwarding proposals to a user who has sub¬ scribed to the push service.

The categorisation according to types makes it possible to browse for a rough matching of proposals.

According to one embodiment said monitoring server searches for not fully matching pairs of proposals based on the following conditions: offer and demand of the selected pair of proposals partly match and for the non- matching parts of offer and demand at least one proposal indicates that the corresponding non-matching item may be varied according to a certain negotiation strategy.

According to one embodiment the networked system comprises:

- a user interface for defining said negotiation strategy by inputting through said user at least one or more of the following:

• a variable item as a component of said offer and/or said demand;

• a minimum value for said variable component; • a maximum value of said variable component;

• a set of values for said variable component ordered according to their priority; and a negotiation server which comprises:

- a negotiation engine for negotiating a match between the variable components of said offers belonging to two different individuals to reach a settlement. Based on such a configuration negotiation strategies may be defined and followed auto¬ matically.

According to one embodiment said negotiation engine comprises:

- a module for calculating a settlement value of said variable value based on a cal- culated average of the limits of said variable values given for the transaction pro¬ posals belonging to a pair of transaction proposals between which the negotiation engine tries to reach a settlement; and/or

- a module for varying said variable component of said offer according to a prede¬ fined variation scheme until a match between the two variable components of the two parties involved is reached. According to one embodiment if two corresponding items of a pair of transaction proposals which do not fully match both are variable said negotiation engine varies both items in or¬ der to reach a balanced settlement value.

According to one embodiment a validity check comprises checking whether the items of¬ fered in a certain proposal are owned by the individual making the offer.

According to one embodiment after a validity check has been executed for a certain pro- posal a reservation is made by indicating in said resource server that the offered items are subject to an offer and should not be amended before a transaction related to said offer has been concluded.

According to one embodiment reservations are cumulatively made in case of a plurality of proposals being submitted by a certain individual.

According to one embodiment a validity check is performed once again before triggering a transaction and after having reached a negotiated settlement.

According to one embodiment the networked system comprises: a plurality of resource servers which can be accessed by a single enforcement server for triggering transactions; a plurality of publish/subscribe servers and/or monitoring servers and/or negotiat¬ ing servers connected to a single enforcement server.

According to one embodiment said publish/subscribe server integrates a plurality of service institutions such that the predefined categories of offer data and demand data for a certain transaction proposal may belong to different service institutions, and wherein said enforcement server enforces a transaction based on such a transaction pro- posal by triggering transactions in resource servers belonging to different service institu¬ tions.

According to one embodiment said publish/subscribe server is implemented by a client terminal owned by a certain user. According to one embodiment the networked system comprises: a loyalty points server on which in a database loyalty points granted by said serv¬ ice institution to customers of said service institution are stored, and wherein a transaction proposal may involve loyalty points as an offer or a demand and said enforcement server accesses said loyalty points server through its non-public interface to trigger transactions which have been concluded and which involve loyalty points.

According to one further embodiment there is provided a method for operating a networked computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 schematically illustrates a networked system according to an embodiment of the in¬ vention.

Figures 2A to 2D schematically illustrate embodiments for transaction proposals or parts of transaction proposals.

Fig. 3 schematically illustrates a flowchart illustrating an embodiment of the invention.

Fig. 4A schematically illustrates a networked system according to an embodiment of the invention.

Fig. 4B schematically illustrates a distributed system according to an embodiment of the invention.

Fig. 5 schematically illustrates a flowchart illustrating an embodiment of the invention.

Fig. 6 schematically illustrates an enforcement server according to an embodiment of the invention.

DETAILED DESCRIPTION A first embodiment according to the present invention will now be described in connection with Fig. 1. Fig. 1 shows a resource server 120 which may be a server computer having stored and maintained thereon a database like one as it is operated for example by an air¬ line where flight bookings and reservations, customer names, seat numbers, luggage data, and all other flight related data with respect to certain individuals are stored. Resource server 120 as such with respect to its functions and its operation is not different from a typi¬ cal conventional server computer operated by an airline for the storing and managing of service data for certain individuals (such as flights, luggage, accompanying service, seat number, etc.). This resource server may be accessed by the individual client computers of the institution operating the resource server (here the airline), and such client computers are schematically illustrated as computers 125 which may access the resource server through a communications link 127. Through communications link 127 the employees of the institution (here the airline) may access the resource server 120 to make reservations, bookings, changes of reservations and bookings, or the like. It should be noted here that the components 120 (the resource server) and the client computers (125) together with communications link 127 typically form a closed network in the sense that the resource server and its related client computers are accessible only by employees of the institution running this system. As will be very well understandable it is not desirable that any third person may access the resource server in order to change flight data, bookings, reserva- tions, or the like, and therefore the system comprising the resource server and the client computers forms a "closed system".

Additionally shown in Fig. 1 is loyalty points server 130. Loyalty points server 130 may store or maintain loyalty points which are assigned to a certain individual as a loyalty bonus by for example an airline if the individual has booked a flight with this airline, in other words, loyalty points server 130 similar to resource server 120 also is operated by a certain institution such as an airline and therefore forms an element of a kind of a "closed system".

While some airlines offer their customers access to their loyalty points account for example through the internet, it should be noted that this does not enable the performance of any transactions, especially it does not enable the performance of any transactions between different customers. A customer through such an access may order some gift or goods in compensation for his loyalty points, but this does not mean that there is any interaction with other customers at all. The system comprising resource server 120, loyalty points server 130, and client comput¬ ers 125 together with communications link 127 therefore is "closed" with respect to interac¬ tions by customers, in particular with respect to interactions and transactions between indi¬ vidual customers. System configuration 135 as shown within the dashed-lined box in Fig. 1 therefore forms a "classical administration system" as operated by a certain service institu¬ tion which renders services to certain individuals and which furthermore maintains a loyalty points system granting loyalty points for customers based on the amount of services ren¬ dered to these individual customers. Interaction between client computers 125 and the loy¬ alty points server 130, and especially interaction between client computers 125 and re- source server 120 is performed through a certain interface which defines how commands must be structured in order to be executed by the resource server or the loyalty points server when received from a client computer 125. Through this interface the client comput¬ ers are able to perform transactions such as conduct bookings, reservations, in other words assigning certain services to certain individuals which then are performed by the service institution. This may for example relate to the booking of a flight for a certain individual. Such a booking is performed using this standardised interface (not shown here in detail) which is accessed through communications link 127 and which typically is not accessible to any person outside the service institution because system 135 in this respect forms a "closed system" so that only authorised members of the system through client computers 125 may have access to resource server 120 and loyalty points server 130 in order to per¬ form transactions through this interface. Typically the details of such an interface are not public because the service institution does not want that anybody from outside the service institution can access the server 130, and particularly the server 120. Resource Server 120, loyalty points server 130, communications link 127 and the terminals 125 can be re- garded as a system according to the prior art.

In the following there will be described in connection with Fig. 1 a system configuration ac¬ cording to an embodiment of the invention which still maintains the security demands and of the service institution while nevertheless allowing individuals from the outside having at least to some extent access to the "closed system" 135. Fig. 1 illustrates a configuration where the system components outside dashed-lined box 135 in Fig. 1 are directed to over¬ come this "closeness" of system 135 in order to enable individuals outside the service in¬ stitution to negotiate and perform transactions with respect to the services and claims (as¬ sets) stored in the resource server 120 and the loyalty points server 130. The operation of these components will now be described in the following. Components 105 shown in Fig. 1 are client terminals belonging to a certain individual such as a mobile phone, a personal digital assistant, a computer, or the like. The individual him¬ self is a client of "service institution" 135 in the respect that he either has booked or re- served some services stored on the resource server, or in the respect that at some time before he has already received some services through the service institution and in return has been granted loyalty points which are stored on his account in the loyalty points server. The customer may therefore be regarded as owning some "assets" which either may be services booked or reserved for him, or these assets may be his loyalty points. The cus- tomer may further have the desire to "trade" his assets with another customer who similarly to himself is a customer of this service institution, and who therefore also has a corre¬ sponding record either in the resource server 120 or the loyalty points server 130 (or both of them) of the service institution which operates system 135. It may therefore be assumed that customer A owning a certain client terminal may wish to trade some of his assets, and also customer B who owns another client terminal may as well wish to trade some of his "assets". The reason for this desire may for example be that customer A wishes to have a window seat instead of a seat on the aisle on his next flight, he may wish to carry more luggage than he is allowed according to his booking record, he may wish to have a different or a better meal than he is assigned according to his booking record, or any other desire may be present with respect to the services which he "owns" or may claim from service institution 135. In order to gain and obtain what he wants he may wish to offer as a com¬ pensation some of his assets, for example he may offer a certain amount of his loyalty points if he then will be able to receive a window seat on his next flight instead of a seat on the aisle.

To summarise, customer A may wish to trade some of his "assets" stored either on the re¬ source server or on the loyalty points server, and customer B may wish to do so as well. In order to enable the customers to exchange their desires and to possibly lead them to a match there is provided a system which will now be described in the following.

Publish/subscribe server 100 is a server computer, which may be accessible through client terminals 105 owned by customers of the service institution which operates system 135. Publish/subscribe server 100 offers a platform where the individual customers may submit their desire to "trade" their assets, in other words the customers may "upload" a certain offer for trading assets onto the publish/subscribe server. Publish/subscribe server 100 maintains a database of registered (subscribed) customers who are entitled to contact the server 100 through a communications link (not shown) such as through WAP₁ GPRS, SMS, Internet, i-mode, UMTS, WLAN or through any other communications link which enables establishing a communication between client terminal 105 and server 100. Once the client has identified himself through his client-ID, he may upload (publish) his "offer". Alternatively a customer may wish to only "download" or "view" already existing offers which so far have been uploaded to the publish/subscribe server 100.

In order to enable a further processing of the offer (and the other offers which may be sub- mitted by different customers) the offer should follow a standardised scheme, for example it may contain two parts, one containing the "demand" which is what the customer requests (for example a window seat), and the other part being the actual "offer", in other words it contains what the customer is prepared to offer or "pay" if he will finally receive what he requests with his demand.

In addition to the "offer" and the "demand" the submitted proposal may furthermore contain a "negotiation strategy" which may later be used if offer and demand of customer A and offer and demand of customer B do not fully match in order to finally "negotiate" a settle¬ ment so that actually finally a transaction can be concluded.

Rg. 2A schematically illustrates the format of a "proposal" which may be submitted by a certain customer to the publish/subscribe server as a proposal for a certain transaction. The client-ID is the registration-ID under which the client is registered at the pub¬ lish/subscribe server, and it typically corresponds to a certain registration-ID under which this customer is also registered at the resource server 120 and the loyalty points server 130. The offer contained in the proposal may for example be "seat in the aisle", "ten kilo¬ grams of luggage capacity", "the meal with the fish", or any alike services which may be offered by a service institution which in the present example is an airline. Instead of these "concrete" offers relating to certain specific services the customer may also offer a certain amount of loyalty points which are stored on his account in the loyalty points server 130.

The "demand" component of transaction proposal 200 may for example be "window seat", "the meal with the fish", "additional luggage capacity of five kilograms", or the demand may be as well relate to a certain amount of loyalty points which the customer would like to get to be stored on his account. It should be mentioned here that the types of offers and the types of demands follow a certain prescribed rule in the sense that the publish/subscribe server is configured to ac¬ cept certain types of offers and certain types of demands in order to enable to look for a match between offers and demands in a systematical manner. For example the user when starting to submit a certain transaction proposal 200 on his client terminal will have installed a software which offers him (for example as pull-down menu) all the available types of of¬ fers and all the available offers of demands, and based on these standardized types of of¬ fers and demands he may fill in his transaction proposal and then submit it to the pub- lish/subscribe server 100.

One can say that a "proposal" which a certain customer may wish to place on the pub¬ lish/subscribe server typically contains an "offer" and a "demand". The offer is the service which the customer owns and wishes to sell, and the demand contains the compensation or "payment" which the customer wants to get as a compensation. Fig. 2B gives a detailed exemplary example how such proposals could look like, and which types of offers and de¬ mands could be implemented in case of an airline. In this example there are three types of offers, namely "seat offers", "luggage offers", and "meal offers", so the types are seat, meal and luggage. To each of this type of offer belongs a sub-type which gives more details of particulars about the specific offer. In the present example sub-types of "Meal" are meat, fish and vegetarian. A specific offer from a certain customer therefore may comprise an offer "vegetarian meal" which belongs to the type "meal" and the sub-type "vegetarian". To a certain offer belongs a corresponding demand to complete a proposal to be published on the Publish/subscribe server. In the present example this demand contains only one type, namely "loyalty points", and the sub-type (or details) of the type loyalty points is just the number of loyalty points requested in the demand.

According to one embodiment there is maintained a database at the publish/subscribe server which is configured such that its structure reflects the predefined types and sub- types of offers and demands which are implemented to be used by the system. According to one embodiment there is implemented an input interface which enables a user to select the types and sub-types of the offer and the demand which should form his proposal. He may for example choose "seat" as the offer type, and then the interface (e.g. in form of a pull-down menu) may offer the corresponding sub-types which are implemented in the system, like here window, aisle and between, from which he may then choose "window" as his detailed offer. In a similar manner he may choose his demand, by first choosing "loyalty points" as demand type and by then inputting the requested number of loyalty points which he desires in compensation for his offered window seat. While not shown in Fig. 2B there may be implemented a plurality of "demand types" from which the user may select, so that he may e.g. choose "meal" as demand type and "vegetarian" as demand sub-type. In this case this would mean that in his proposal the customer offers his window seat in compen¬ sation for a vegetarian meal.

Based on the inputted proposal data there is then generated a database record or dataset in a database which reflects the selected or inputted proposal data such that the offer type, offer sub-type, demand type and demand sub-type are stored as individual data fields. This enables a user then to browse the proposals on the publish/subscribe server according to their offer type, demand-type, or according to their sub-types which makes it convenient to look for suitable proposals.

In addition to the elements "offer" and "demand" the transaction proposal may contain a "negotiation strategy" selected by the user. This may refer for example to a modified offer or a modified demand, for example a maximum value of loyalty points which the user would be prepared to "pay" if his demand will be met. According to another negotiation strategy a user may input variations of his proposal and assign priorities to these variations. An ex¬ ample is schematically illustrated in Rg. 2C which shows how the proposal data varies and is assigned different priorities for the variations. Based on such a priority list a negotiation engine then may try to reach a settlement between such an offer published by customer A and another offer published by a different customer B.

According to another negotiation strategy the user may select a certain item in his pro¬ posal, e.g. the number of loyalty points which he demands as compensation for his offer as the "negotiable" or "variable" item. He then may further input a "maximum value" which re¬ flects his desire what he would like to get as compensation, and furthermore a "minimum value" corresponding to the minimum value of loyalty points for which he still would be pre¬ pared to conclude the deal. Fig. 2D schematically illustrates an example for such a nego¬ tiation strategy. The "demand type" field indicates that the desired compensation consists in loyalty points, the "demand sub-type" indicates the actual value the user desires to get for his offer, namely 10.000 loyalty points. The field "negotiable" is a flag which indicates whether the preceding field "demand sub-type" may be varied automatically by a negotia- tion engine to reach a settlement, the "1 " indicates that this is the case, and the field "mini¬ mum" indicates the minimum value for which the user would still be ready to make the deal. This means that the "negotiable" flag and the "minimum" field actually define a negotiation strategy which may then be used by a negotiation engine to reach a deal by trying to match the proposal with other proposals from different users.

Based on the selected negotiation strategy the system may then negotiate a settlement as will be described in more detail in the following.

However, before describing in detail an automatic matching between two proposals a "manual matching" will be described in somewhat more detail. In a manner described be¬ fore different customers may submit their corresponding transaction proposals 200 to the publish/subscribe server 100. In one embodiment the data on the publish/subscribe server is accessible by the individual client 105 in such a manner that they may "view" the trans- action proposals submitted on the server 100, and a client may for example "browse" the submitted proposals and look whether one of them may match his desires. Once he found a proposal matching his desires he may then select it and initiate a procedure for conduct¬ ing a transaction in accordance with this proposal. In this embodiment he may for example during browsing the proposals find a proposal which offers a "window seat" in the next flight to Berlin in exchange for a seat on the aisle and in exchange for an additional amount of 5000 loyalty points. Assuming that this transaction proposal matches with the desires of the user he may then signal his agreement with this proposal, for example by pushing an "ok"- button displayed on the screen of his client terminal. In response to this agreement signal his client terminal 105 will then transmit a message to a publish/subscribe server 100 con- taining his client-ID and some message content signalling that the client agrees with this transaction proposal. In such a case a match has been found "manually" and then this match between two different customers with respect to their transaction proposals will be conducted and enforced as will be explained later in the following.

In order to enforce the transaction proposal the publish/subscribe server may at first com¬ pose a "mirror" transaction proposal which correspond to the client who has accepted the initial proposal. This "mirror transaction proposal" would then contain as a client-ID the ID of the accepting customer, in the field "offer" it would contain the amount of loyalty points demanded by the customer who has initially submitted the transaction proposal, and in the field "demand" there will be inserted "window seat" as it was offered by the customer who initially submitted the transaction proposal. The negotiation strategy field(s) may remain empty because a settlement has already been reached manually. The thus generated mir¬ ror proposal contains as "offer" the demand of the other party, and as demand it contains the "offer" of the other party so that offer and demand of the parties involved match and a transaction can be made. Based on these two corresponding matching transaction propos¬ als, one being manually submitted and another one being automatically generated by pub¬ lish/subscribe server 100 after a customer has agreed with the initial proposal, then an en¬ forcement of the transaction may be made as will be described later.

According to one further embodiment a user may instead of manually browsing the offers on the publish/subscribe server subscribe for a push service offered by a push service unit (not shown) of the publish/subscribe server. The user may define the category of offers he is interested in, and once another customer uploads such an offer to the publish/subscribe server the user on his terminal will be informed by a push message which delivers this offer to his terminal. Based on his preferences he may then accept the offer, or he may instead upload another proposal with a somewhat reduced counter offer and a negotiation strategy so that then the system may try to automatically reach a settlement between the two pro¬ posals as will be described in more detail in the following.

Instead of the "manually browsing" of the submitted transaction proposals through the dif¬ ferent clients there may also be performed according to a further embodiment an "auto¬ matic matching" as will be described in the following.

In Fig. 1 there is shown monitoring server 110 which is connected to the publish/subscribe server 100 through a communications link 115. The monitoring server 110 continuously monitors ("polls") the publish/subscribe server and looks whether there is a kind of a rough or "partly matching" between individual transaction proposals submitted to the server 100. This "partly matching" may refer to the fact that the offers and demands of two certain pro¬ posals may match with respect to the types of offer and demand, however, the sub-types, e.g. the actual "amount" of loyalty points offered or demanded by the two customers who have submitted these roughly matching transaction proposals to not match so that there is no full match between offer and demand. For example a certain customer may demand 10.000 loyalty points for a window seat offered by him and another customer who demands a window seat is prepared to pay only 5.000 loyalty points. In such a case it can be said that there is a "rough matching" in the sense that with respect to the types there is a matching between offer and demand, however, with respect to the detailed offer and de¬ mand data (the "sub-types") there is no matching. The monitoring server 110 according to this embodiment looks for this type of "partly matching" between transaction proposals, and if there are found pairs of transaction proposals for which there is a "rough matching" or "preliminary matching" or "partly matching", such as a matching of the types or categories of offers and demands, then such a pair of transaction proposals is selected and is for¬ warded through a communications link to negotiation server 125. According to one em¬ bodiment only such pairs of proposals will be selected for which the non-matching items either for both or at least for one of the proposals are indicated as variable so that the ne- gotiation server then based on varying these items may try to reach a settlement.

Based on the offers and demands as well as on the selected negotiation strategies for the pairs of transaction proposals the negotiation server 125 then tries to negotiate a settle¬ ment. This will now be described in somewhat more detail in the following.

According to one embodiment a negotiation strategy may for example consist in "setting a limit", for example a limit of the maximum loyalty points a customer is wishing to "pay" for a certain service, or on the other hand a "minimum amount" which is a minimum amount of loyalty points a customer wishes to obtain in compensation for his offer of certain service. Let us now assume that the offer consists in the offering of a window seat and the demand consists in 10.000 loyalty points, further let's assume that the negotiation strategy consists in a "minimum amount" of 5000 loyalty points. This may correspond to a transaction pro¬ posal of a certain customer A. Through the monitoring server 110 this has been found to "preliminarily or partly match" with another transaction proposal from a different customer B which offers 3.000 loyalty points, which demands a window seat, and which sets as the negotiation strategy a maximum amount of loyalty points of 7.000, thereby indicating the variability of this proposal item. The monitoring server has found a preliminary match be¬ cause the offer "window seat" matches with the demand "window seat", and furthermore there is a match between offer and demand at least with respect to the category because the category of offer and demand is "loyalty points" even if the amount of loyalty points de¬ manded by customer A and offered by customer B do not match. Due to the found prelimi¬ nary match and because the proposals for the non-matching items indicate that these items may be varied this pair of transaction proposals is then forwarded to negotiation server 125 which then negotiates a settlement according to the following procedure. In case of a "category matching" between offer and demand being present and only the "amount" being not present, and further in case of the negotiation strategy being of the type "set limit" the negotiation server 125 according to a first embodiment proceeds as follows. At first the average between the offered and demanded amount of loyalty points is calcu- lated and then it is checked whether the thus calculated average value is within the limits set in the different negotiation strategies of the different customers. In the present case customer B offers 3.000 loyalty points with a limit of 7.000 and customer A demands 10.000 loyalty points with a set limit of 5.000 loyalty points. The average between initial

-i - 10.000+3.000 , _._ ^u- . ■ ,. ,u . ,- ■_* offer and demand is = 6.500. This average value is above the lower limit

set by customer A, and further it is below the upper limit set by customer B, this means that both limit conditions are fulfilled so that a match can be performed at 6.500 loyalty points while fulfilling the negotiation strategies set by customers A and B in their initial proposal.

The negotiation server 125 then determines that a negotiation settlement has been suc- cessful, and he will then return a message to the monitoring server containing an indication about the details of the reached settlement, in other words the actual data of offers and demands for which a settlement has been reached. Based on these data then the settle¬ ment will be enforced as will be described in more detail later.

It should be mentioned that the procedure of the negotiation as described before merely relates to a specific embodiment and that other types of negotiating a settlement may be implemented as well. In order to enable negotiation server 125 to reach a settlement it must be provided with data regarding offer and demand, and furthermore with a negotiation strategy. The negotiation strategy thereby has to contain two types of elements, it must contain an indication about the variability of the data relating to offer and demand, such as an indication that for example the amount of loyalty points may be varied, and it must fur¬ ther as another element contain a certain constraint which is an indication of a limit up to which the variation may be performed. Based on this negotiation strategy data the negotia¬ tion server will then vary the offer or demand data in accordance with the prescribed nego- tiation strategy, and this variation will be conducted up to the set limit and during variation of the offer or demanded data the varied transaction proposal will be compared with its "counterpart" and it will be checked whether a match already has been reached. If the limit set in the negotiation strategy is reached without a match having been reached, then the negotiation was unsuccessful and a corresponding notification will be sent from the nego¬ tiation server 125 to the monitoring server 110.

According to a further embodiment of a negotiation strategy there may also be set a se- quence of offers or demands with ascending or descending priority, and the negotiation strategy may then consist in varying the elements of the sequence according to the order of priority up to a certain limit. For example a customer may in his demand request 5.000 loy¬ alty points and as an initial offer he may offer a free luggage capacity of 10 kilograms. As an additional offer with lower priority he may offer a window seat in addition to the free lug- gage capacity. The negotiation server will then try to at first negotiate a settlement based on the initial offer, and then it will vary the initial offer according to the order of priority so that next the offer which combines luggage capacity and window seat will be tried to be matched with a counterpart. If a match will be detected, then the thus reached negotiation settlement will be enforced, otherwise negotiation will be aborted. Such an order list of variations corresponds to the list of proposals schematically illustrated in Rg. 2C

According to one embodiment the negotiating strategy may include a timing component, such as e.g. that the constraints are released as time proceeds. For example the negotia¬ tion strategy may define a timing scheme according to which the offer is changed, and based on this timing scheme the negotiation process may proceed until a settlement is reached. The timing scheme may also involve increasing a demand instead of relaxing it, e.g. a higher value of loyalty points may be demanded for a free seat if the departure time comes closer. Such timing constraints may be chosen by the user or they may be prede¬ fined by the entity which operates the negotiation server, or by a combination of both. For example the user may be offered an option whether he wants to combine his proposal with a timing scheme, and he may then select a start value and end value of his offer as well as a start time and an end time, and then the negotiation engine will automatically change the offer according to these boundary conditions defined by the user.

The negotiation strategy may comprise two types of components, a user-defined compo¬ nent which may be selected or determined according to the preferences of the user, and another component which contains those parts of the negotiation strategy which can not be influenced by the user and are e.g. determined by the entity operating the negotiation server. The first component may be referred to as user-defined negotiation strategy, it may comprise such elements as the initial offer, the limit which is acceptable to the user, and possible some timing scheme which should be followed during negotiation as explained before.

The user-defined negotiation strategy may be defined or selected by the user when pre- paring or submitting a proposal to the publish/subscribe server. For that purpose the user's terminal or the publish/subscribe server may provide a suitable user interface for inputting by the user the parameters necessary to define the user-defined strategy.

In addition to those user-defined negotiation strategy elements there may be a component which is defined or influenced by the entity operating the negotiation server. This operator defined negotiation strategy component will now be describe by one example where the entity operating the negotiation server is an airline.

Assume that a customer has to offer a seat on a flight that is overbooked, then the negotia- tion strategy defined by the airline (the operator-defined negotiation strategy) may be to make the deal with the customer which offers the highest value of loyalty points in compen¬ sation for the free seat in order to make it attractive for customers to offer their free seats. Moreover, in case of such an offer of a free seat the system may offer to the customer who offered the free seat an option to assist in looking for another flight, e.g. by a corresponding menu displayed on his display. The customer bay based on the thus offered information receive assistance in making reservation for another flight. Also the offer of the free seat may be set as a conditional offer which is only "validated" if the customer will be able to get a suitable other flight, and if this was successful, then the seat actually is offered for a transaction. Thereby the system gives an incentive to offer seats in flight which a customer actually does not need and thereby the system can help to better distribute customers among the flights of an airline. Other examples of operator-defined negotiation strategies can also be imagined, e.g. the question whether a settlement between two offered values is arranged to be made at the average between the two values or whether one of the two offers is preferred. Another example could include a timing scheme defining how conditions are relaxed or varied until two proposals match and a settlement is reached.

According to a further embodiment the negotiating process may involve more than two pro¬ posals. As an example, customer A may offer 20 kg in baggage weight, and customers B and C need to get 15 kg and 5 kg of baggage weight, respectively. In this case there is a preliminary matching between the offer of customer A and the demands of customers B and C. The monitoring server 110 detects this preliminary matching and forwards the three proposals to the negotiating server 125. The negotiating server 125 then tries to negotiate an agreement between the three proposals. This may be done by pipelining the demands which preliminarily match with a certain offer according to their priority according to a cer- tain priority rule, and by then individually negotiating the thus resulting pairs one after an¬ other. The priority rule may be chosen according to the circumstances, one example could be to order the offers according to the offered value, the highest offer first and then the lower offers. In the present example this would mean that at first the proposals of custom¬ ers A (20 kg) and B (15 kg, the next ranking) would be negotiated, and then if after a set- tlement there remains enough value to offer on the side of A, then a negotiation process with customer C would start. Since customer A after a settlement still has 5 kg to offer and since customer C only demands 5 kg there could be reached a settlement.

Another example could be that customer A offers a service which contrary to baggage weight can only be sold "once", such as a window seat, and customers B and C offer dif¬ ferent values of loyalty points. Then also the negotiating server 125 would rank the offers of customers B and C according to their priority and the better offer (in this case the customer with the higher value offered) would make the deal.

According to one embodiment the search for preliminarily matching proposals is done in the following manner. If a new proposal enters the publish/subscribe server then it is checked against all already existing proposals on the publish/subscribe server as to whether there is a preliminary match. If a match is detected, then the thus paired proposal is forwarded to the negotiation server.

If the newly entered proposal matches with a plurality of existing proposals then a plurality of pairs may be generated which are then forwarded to the negotiation server. In order to avoid multiple settlements being based on the same proposal each proposal has a corre¬ sponding unique ID assigned, and if a proposal has become subject to a settlement during the negotiation process then it will be removed from all those pairs of proposals in which it has been included but which are actually not part of the settlement.

A newly entered proposal which has been added to the publish/subscribe server may also be added in a pipelined manner to already existing pairs of proposals in a pipelined manner as described before. Alternatively to pipelining proposals such as adding new proposal C as pipelined alternative to the already existing pair of proposals A-B, e.g. C being an alter¬ native for B, the monitoring server may also form a new pair A-C which is then forwarded to the negotiation server where the negotiation server tries to reach a settlement based on this new pair simultaneously to trying to reach settlements for all other pairs of existing pro- posals. Once a settlement has been reached for any pair, e.g. for pair A-C, all other pairs which exist on the negotiation server are checked based on the corresponding proposal ID as to whether they involve either proposal A or C. For those pairs where this check is posi¬ tive the proposals A or C, respectively, are removed or at least the negotiation process with respect to these proposals is put on hold until the final fate of the proposal pair A-C is clari- tied. If then finally the A-C settlement is enforced without problems, then the other pairs involving A or C may be cancelled. If the enforcement cannot be carried out for some rea¬ son, e.g. because either proposal A o C is not valid anymore, then only the non-valid pro¬ posal is removed from existing pairs and the other still valid proposal may be maintained and pairs of proposals which have been put on hold may be reactivated.

Fig. 3 schematically shows a flow chart illustrating the negotiation procedure. At first in op¬ eration 300 the initial offer and demand data of the two counterpart proposals is compared as to whether a match is detected (operation 310). If a match is detected then it will be en¬ forced in operation 320. However, if no match has been detected, then in operation 330 the offer and/or demand data is varied according to the negotiation strategy chosen by the us¬ ers. According to one embodiment this is done simultaneously for the two counterpart pro¬ posals in order to reach a "balanced" settlement. In one embodiment the variation may be performed by conducting a step-by step variation according to the order of priority of differ¬ ent proposals chosen by the user. After a variation has been made in operation 330 it is then checked whether the constraint set by a user has already been reached (or acceded). If this is not the case, then the procedure returns to operation 310 and checks whether now with the varied offer/demand data a match can be detected between the two proposals. If this is still not yet the case, then a further variation is made in operation 320, however, if a match has been detected then the found match is enforced to operation 325.

If a further variation is made through operation 320, then once again the check whether a constraint (such as a limit set by the user) has been reached or acceded, and if this is the case, then in operation 340 the negotiation procedure is stopped and in operation 350 the monitoring server 110 is notified about the failed negotiation. If the negotiation has failed then the monitoring server may continue to monitor the propos¬ als submitted to the publish/subscribe server for initial or preliminary matches, and if such an initial match is found then the negotiation procedure may start again for a different pair of proposals. However, if a match has been reached through the negotiation procedure, then the reached settlement has to be enforced, and this enforcement procedure will now be described in the following.

The reached settlement consists in an exchange of services or "assets" between custom¬ ers A and B, and for that purpose an access must be made to either resource server 120 or to loyalty points server 130 or to both of them. However, these two servers typically are not accessible from clients outside the institution operating these servers, especially they are not accessible directly through customers of these institutions for security reasons. In order to maintain security and stability within the system shown in dashed-lined box 135 there is provided a specialised "enforcement server" 140 shown in Fig. 1 which is allowed to access resource server 120 and loyalty points server 130 through communications links 145. Through these communications links 145 enforcement server 140 can access the same interface as the individual clients 125 belonging to the service rendering institution. These interfaces are "non-public interfaces" in the sense that they are not open to third party computers but only to computers which belong to the institution 135, except for the en- forcement server 140. This is because there is a trust relationship between the resource server 120 and the enforcement server 140 as well as between the loyalty points server 130 and the enforcement server 140. This means that enforcement server 140 actually is capable of accessing the databases in resource server 120 and loyalty points server 130 and to make changes in the data sets recorded therein, thereby assigning services to the individual customers of the institution different from the services which have been assigned to them before the change. Through such an operation the enforcement server may per¬ form a "transaction" corresponding to a settlement reached in the negotiation process de¬ scribed before.

Such transactions are should not be open to the public or any third person, and therefore the resource server and the loyalty points server are only accessible through a non-public interface. Enforcement server 140 also has implemented such an interface because it is a trusted entity, and therefore the enforcement server is allowed to and capable of accessing resource server 120 and loyalty points server 130 in order to trigger transactions thereon. HOWΘVΘΓ, in order to avoid fraudulent use and confusion and instability through unauthor¬ ised access the enforcement server 140 is responsible for checking in advance whether any transaction initiated or triggered by the enforcement server 140 actually is based on authorised customers. Therefore the enforcement server implements security checks for checking the identity and the authorisation of the parties involved in a transaction. Such a check also may involve to check whether the "assets" which are to be traded actually are owned by these authorised customers.

Enforcement server 140 has a "trusted relationship" to resource server 120 and loyalty points 130 in the sense that it may access their databases in a similar manner as clients 125. However, before accessing resource server 120 and loyalty points server 130 the en¬ forcement server 140 must make sure that the transaction initiated through such an access was concluded by authorised customers and is based on assets (loyalty points or services which may be claimed by the customers) which are actually owned by these customers such that they can be traded between them. This is a kind of a "validity check" which must be performed for each transaction before it is enforced by the enforcement server. The va¬ lidity check will now be described in somewhat more detail in the following.

One of the things which must be confirmed before a transaction is enforced is the identity of the individual customers for which the transaction should be performed, This "identity check" according to one embodiment is carried out by having a certificate attached to each transaction proposal, the certificate consisting for example in a message generated using the private key of the customer who has submitted this proposal. By using the correspond¬ ing public key the publish/subscribe server 100 and/or a monitoring server 110 and/or the enforcement server 140 may check the identity of the author of a certain transaction pro¬ posal. Where and how often the identity of the author of a certain proposal is checked somewhat depends on the trust established between the different communication partners. For example, if there is a trust relationship between the monitoring server 110 and the en¬ forcement server 140, and if a check has been already performed at the monitoring server, then it may be unnecessary to check the author's identity once again at enforcement server 140 if it has already been checked through the monitoring server 110. However, if the monitoring server 110 is less trustworthy and may be prone to fraudulent access through hackers which may pretend any reached settlement, then it might be preferable to have an identity check once again be performed on the enforcement server. It should be noted here, that the final authority for checking the validity of a transaction is the enforcement server because the enforcement server is a trusted authority which can access directly the resource server and the loyalty points server in a manner similar to the clients 125 through the corresponding interface. There is the same level of trust between resource server 120 and enforcement server 140 as it is between resource server 120 and client 125, and the same trust relationship also exists between loyalty points server 130 and enforcement server 140. This is necessary in order to be able to make use of an already existing sys¬ tem as shown in dashed-lined box 135 and its interfaces to enable transactions between individual customers who normally have no direct access to such a system. Since the cus¬ tomers may access this system and the servers maintaining the service database only through enforcement server 140 it must be made sure that a sufficient transaction validity check has been performed through enforcement server 140 in order to allow it to access resource server 120 and loyalty points server 130 for enforcing the transaction.

As mentioned before, the identity check of individual customers can be performed by using public key infrastructure (or any other key infrastructure or coding scheme) and by ensuring their identity through a certificate based on the respective (private) key of a certain cus¬ tomer.

Another condition which needs to be confirmed is whether the customer actually "owns" the assets which he wishes to trade, in other whether he actually is entitled to claim the service from the service institution which he offers (e.g. whether he actually is booked for the flight where he offers a window seat) or whether he actually owns the loyalty points he offers. This may be referred to as checking the "validity" of an offer. According to one embodiment such a check may already be carried out before the actual negotiation procedure starts. For that purpose the monitoring server may ask the enforcement server 140 through a corre¬ sponding communications link 150 to check with the resource server 120 and the loyalty points server 130 whether the loyalty points offered in a certain transaction proposal and the service offered in a certain transaction proposal actually are owned by the customer who is offering these services/loyalty points. Once this has been confirmed by a return message to the monitoring server then the negotiation procedure may start, or in other words the proposal may be used by the monitoring server for checking whether there is a preliminary match.

According to one further embodiment the monitoring server may directly access the loyalty points server and the resource server for checking, however, such an architecture is somewhat less preferable because it actually leads to an architecture of reduced security in case of the monitoring server having no direct trusted relationship with the resource server and the loyalty points server. However, typically the monitoring server according to one embodiment will have a less trusted relationship to the resource server and the loyalty points server, and therefore the communications links 160 shown in Fig. 1 are less prefera¬ bly used for checking whether the services are available and owned by the corresponding customer.

According to one particular embodiment the validity check whether the services/loyalty points owned by a certain customer extends not only to the offered services but also to the limit set in the negotiation strategy to make sure that during negotiation there will not be reached a settlement based on an amount of services/loyalty points which exceeds the services/loyalty points actually owned by the certain customer.

If the validity check turns out that actually a proposal or a certain negotiation strategy is invalid, then a corresponding feedback may be delivered to correct the advertisements at the publish/subscribe server, e.g. by deleting invalid proposals or by correcting the contents of the advertisements, e.g. by adapting a limit of a negotiating strategy chosen by a user to such a value of loyalty points which he actually owns.

Once the validity check as described before has been made, and assuming that the check has performed successfully, according to one particular embodiment there may be carried out a "reservation" of the offered services/loyalty points. Such a reservation may be used to prevent that any transaction with respect to the offered services/loyalty points is made be- fore a negotiation settlement is reached, because otherwise it might be possible that a ne¬ gotiation settlement would be reached and the corresponding services/loyalty points are not owned any more by the corresponding customer because a separate transaction has made them disappearing. For that purpose it is preferable to have a reservation being car¬ ried out once a transaction proposal has been submitted to the publish/subscribe server 100. Depending on the individual trust relationship between monitoring server 100 and resource server 120 and loyalty points server 130 such a reservation could be made di¬ rectly through communications links 160 or it can be made via the enforcement server 140.

Assuming that a user or a customer may submit several transaction proposals it is accord- ing to a further embodiment possible to "pipeline" reservations such that the accumulated amount of services/loyalty points offered by a certain customer is reserved and may not be used for other transactions.

According to one particular embodiment the enforcement server 140 before actually en- forcing a concluded transaction once again checks whether the services and/or loyalty points involved in the transaction are still available and owned by the corresponding cus¬ tomers. For example it may happen that due to some system failure or due to some other external reasons (e.g. a flight may be cancelled) the services involved in a transaction are not available any more, and under such a condition the transaction should be prevented from being enforced. For that reason before actually enforcing the transaction the enforce¬ ment server once again preferably checks whether the services and/or loyalty points in¬ volved in the transaction are still available. Once this check has been performed success¬ fully, the enforcement server transmits messages to the resource server 120 and/or the loyalty points server 130 and based on these messages theses services execute the trans- action which has been reached during the negotiation.

The timing of the validity check and of the reservation may depend on the particular em¬ bodiment. According to one embodiment validity check and reservation are done as soon as advertisements are available on the publish/subscribe server. According to a further embodiment a validity check is done when advertisements are available on the pub¬ lish/subscribe server, and a reservation is made just before negotiation starts. According to an even further embodiment a validity check and a reservation are carried out just before the negotiation starts.

According to one embodiment a reservation does not prevent a certain asset from being advertised in other advertisements, however if under negotiation already in connection with a certain proposal then this asset will not be used for another negotiation process once it has been reserved.

According to one embodiment after a reservation has been made for a certain asset which can be divided into smaller units (e.g. in case of loyalty points where only a part of the loy¬ alty points of a user are necessary for a certain proposal), then only the extent of the asset as necessary for a certain proposal will be reserved, the remaining asset value (e.g. the remaining loyalty points) will be calculated and will not be reserved but will be free for fur- ther negotiations. It should be noted that the messages to enforce or to "trigger" the transactions which are sent from the enforcement server are consistent with the interface protocol provided by the resource server and the loyalty points server also to the clients 125. Therefore the en- forcement server accesses the resource server and the loyalty points server in similar manner as to the clients 125 which are client computers belonging to the service rendering institution (in the present example an airline).

Enforcement server 140 therefore acts as a "mediator" which enables customers who un- der normal circumstances are not able to access the network inside the service rendering institution to nevertheless perform transactions and trade assets which they own within the within the service rendering institution (resource server and loyalty points server). For that purpose there are provided the publish/subscribe server for enabling the submission of transaction proposals, the monitoring server and the negotiation server for negotiating a settlement, and the enforcement server for enforcing and conveying the reached settlement to the computers inside the "closed system" or the service rendering institution.

For that purpose the enforcement server also is responsible for any necessary protocol or format conversions which are necessary to access the server computers inside the service rendering institution through their standard interfaces. The customers in the outside world may therefore access the administration system inside a service institution through the en¬ forcement server 140 which itself is accessed through the "trading and negotiating system" composed of publish/subscribe server, monitoring server and negotiation server, which again is accessed through the clients owned by the individual customer. With such a sys- tern configuration it becomes possible for individual customers to trade their individual "as¬ sets" which they own within or can claim from a certain service institution.

With respect to Fig, 4A now a further embodiment of the present invention will be de¬ scribed. Fig. 4A shows an enforcement server 400 which is connected to a plurality of service rendering institutions 410. These institutions may comprise airlines, travel agen¬ cies, courier services or any other institutions which render certain services and which have inside their administration computerised databases which maintain records of services which may be claimed by or are assigned to individual customers. It should be noted here that similar to the embodiment of Fig. 1 enforcement server 400 is a "trusted authority" in the sense that there is a trust relationship between the enforcement server 400 and the individual service institutions 410. This means that because of this trust relationship en¬ forcement server 400 is allowed to access the individual server computers of the service institutions 410 in such a manner as to perform transactions which relate to the exchange or trading of services between individual customers. The enforcement server 400 thereby uses non-public interfaces which normally are only available to client computers inside the service institutions 410 to access the respective servers inside these service institutions 410.

Fig. 4A furthermore shows "trading and negotiation systems" 420 which may comprise re- spectively a publish/subscribe server, a monitoring server and a negotiation server as de¬ scribed in connection with Fig. 1. Each of these trading and negotiating systems may cor¬ respond to a certain service institution 410, it may therefore be customarily designed for the service institution 410 and be adapted to the individual services rendered by this institution and which may therefore be traded by the individual users. Each of these systems 420 may then be accessed through client terminals 425 of individual customers, and based there upon transactions may be concluded and corresponding settlements may be reached. Once the settlement has been reached the trading and negotiation system may convey it to the enforcement server 400 through public interfaces, and the enforcement server 400 then performs a validity check and through corresponding messages through the non-public interfaces to individual service institutions 410 will trigger the enforcement of the transactions. It should be noted here that according to this preferred embodiment there is one single enforcement server which serves a plurality of service institutions and their corresponding resource servers, and which simultaneously also serves a plurality of trading and negotiation systems 420 corresponding to the individual service institutions. This means that based on such an architecture with a centralised enforcement server 400 it be¬ comes possible to make use of a once established trusted relationship for a plurality of service institutions, and therefore it becomes possible to implement a service trading capa¬ bility between individual customers for a plurality of service institutions while still maintain¬ ing security and confidentiality within their respective computer and administration systems due to the trusted relationship between the enforcement server and the service institutions.

Moreover, according to one particular embodiment a plurality of trading and negotiation engines 420 may be included into a single trading and negotiation engine as schematically illustrated by the dashed-lined box 440 in Fig. 4A. By integrating the trading and negotia- lion engines 420 of two different service institutions it becomes possible to trade services bθtween customers which actually belong to different service institutions, such as for ex¬ ample trading a window seat in compensation for a concert ticket. It should be noted in this context that for that purpose the publish/subscribe servers should be configured such that they allow not only offers relating to a certain single service institution but to the two service institutions which are integrated through the integrated trading and negotiation 440 shown in Fig. 4. This means that the categories of office and demands which a customer may submit to a publish/subscribe server actually may relate to different service institutions 410, and therefore a transaction may involve services rendered by different service institutions 410. Because of the trust relationship established between enforcement server 400 and the individual service institutions 410 and due to the validity check performed by the en¬ forcement server 400 before enforcing a transaction, the service institutions 410 without losing their security may based on such a system architecture enable a trading of their services between individual customers which even goes beyond the individual service in¬ stitutions.

Fig. 4B shows in somewhat more detail a distributed system architecture according to the embodiment of Fig. 4A. In Fig. 4B there are shown Publish/Subscribe Servers 450 which are connected to monitoring server 460 in an n:1 relationship, i.e. one monitoring server may serve several publish/subscribe servers. A plurality of negotiation servers 470 are connected to the monitoring server 460 in an m:1 relationship. Furthermore a plurality of monitoring servers 460 of which only one is shown are connected in an p:1 relationship to an enforcement server 480 so that one enforcement server may serve a plurality of moni¬ toring servers. Finally there is a q:r relationship between a plurality of enforcement servers and a plurality of resource servers 490 of one or more service institutions. If the relationship between the enforcement servers is a n:m relationship as shown in Fig. 4B, e.g. if there are multiple enforcement servers serving a resource server and a loyalty point server, then data consistency is considered, e. g. by checking the availability of assets and by making a corresponding reservation before starting to negotiate a settlement in order to avoid con¬ flicting transactions being executed by the distributed enforcement servers.

Publish/subscribe servers 450, negotiation servers 470 and monitoring server 460 corre¬ spond to the trading and negotiation system shown in Fig. 4A, while Fig. 4B illustrates the distributed nature of this system according to one embodiment. In the following the process flow of a trading of services according to a particular embodi¬ ment will be described in somewhat more detail with respect to Fig. 5. As shown in Fig. 5 at first the transaction proposals are submitted by customers A and B together with their respective client-ID, the offer and demand, and the respective negotiation strategy to the publish/subscribe server. This is schematically illustrated by operation 500. The transac¬ tion proposals submitted to the publish/subscribe server are watched or monitored by the monitoring server 110 for preliminary matches. This is illustrated by operation 510. Fur¬ thermore, in operation 520 the transaction data corresponding to the offers and amounts may be reserved or blocked so that they cannot be consumed by the other transaction. This operation 520 can either be performed directly after the submission of the proposal or after the monitoring for a preliminary matching (operation 510) has been successful. Once a successful preliminary matching has been found, the corresponding pair of transaction proposals is forwarded to the negotiation server. At the negotiation server there will be tried to negotiate a settlement (operation 540). If no settlement is reached during the ne- gotiation process, then the procedure returns to the operation of monitoring for preliminary matching (510).

In case of a settlement being reached it is then checked whether the services and/or loyalty points involved in the settled transaction are still available (operation 560). According to one particular embodiment the procedure may further include the request of a confirmation of the reached settlement by the clients, and in operation 580 the clients may confirm the settlement (operation 580). This confirmation may involve the use of certificates generated based on the private keys of the clients. After confirmation the data related to the reached settlement can be forwarded to the enforcement server (operation 585). This may involve the attachment of a certificate to the settlement data which certifies that the settlement has been approved by the clients. For that purpose either the private keys of the clients in¬ volved in the transaction may be used, or the monitoring server may generate a certificate on its own to certify the authenticity of the reached settlement. The thus generated mes¬ sage is then forwarded to the enforcement server (operation 585), and the enforcement server then enforces the settlement by contacting the administration server/servers of the service institution.

It should be noted that according to one embodiment the request for an explicit confirma¬ tion of the reached settlement through the clients may depend on the system configuration as set by the client, for example a client may wish to be asked for explicit confirmation after a settlement has been reached through automatic negotiation.

It should further be noted that the use of a certificate for authentication between the moni- toring server and the enforcement server depends on the trust relationship which may exist or not exist between the monitoring server and the enforcement server. In case of a fully trusted relationship existing between these two servers there is no need to for further authenticate any reached settlement because in such a case the monitoring server already has been responsible for performing the authentication and validity checking process. However, if there is no full trust established between the enforcement server and the monitoring server (which may sometimes be the case) it is recommendable to introduce an additional authentication certificate when forwarding the data related to the reached settle¬ ment from the monitoring server to the enforcement server.

In the following there will be described an embodiment of an enforcement server in some¬ what more detail by referring to Fig.6. Enforcement server 600 comprises in this embodi¬ ment comprises a receiving module 610 which is connected to the outside world (in this example to monitoring server 620) through a public interface (not shown) implemented in receiving module 610. Through receiving module pairs of transaction proposals are re- ceived. Checking module 630 checks their validity as explained already before, e.g. by checking the identity and authorisation of the authors, the assets involved, etceteras.

Conversion module 640 receives the pairs of proposals for which the validity check was successful, i.e. which actually represent a valid transaction. Conversion module 640 then transforms the transaction data corresponding to a reached agreement into transaction data which is in accordance with the non-public interface of the resource server(s) to which the transaction data must be forwarded to trigger a transaction. This may involve format conversions, protocol conversions, insertion of specific keys necessary to access the re¬ source server(s), or the like.

The converted transaction data then is forwarded to contacting module 645 which then contacts through the non-public interface (not shown) resource server 650 to forward the transaction data and to thereby trigger the transaction in the resource server. This then results in a change of database values in the resource server which reflects the trade of assets as agreed upon in the transaction. Depending on the type of transaction the con- tacting module 645 may contact two or more resource servers an may trigger the transac¬ tion therein.

It should be noted that the configurations and system architectures described in connection with the foregoing embodiments has been described as a distributed system in the sense that the publish/subscribe server, the monitoring server, the negotiation server, the en¬ forcement server, and the resource server and the loyalty points server are different enti¬ ties. According to one particular embodiment it may be possible to integrate the negotia¬ tion server into the monitoring server such that they form one integrated entity. Moreover, it may also be possible to integrate the publish/subscribe server 100 into such an entity. However, due to the particular trust relationship which needs to be established between the enforcement server and the royalty points server as well as the resource server it is rec- ommendable to have an enforcement server 140 as an entity different from the monitoring server, the negotiation server and the publish/subscribe server. This is because it then becomes possible to link a plurality of trading/negotiating systems as shown in Fig. 4 to a single enforcement server while it is only necessary to establish the trust relationship be¬ tween the service institution and the enforcement server once, and different trad¬ ing/negotiating systems can be connected to such a trusted single enforcement server 140.

Moreover, it should be noted that the publish/subscribe server may be implemented in a distributed architecture, it may for example also be implemented as a part of or through a client terminal 105. In such a case it is natural that the publish/subscribe server should not be trusted and that it is the task of the monitoring server to perform the necessary identity and validity checks. However, if the publish/subscribe server is a separate entity which itself already is credited with trust to a certain extent, then it may be sufficient that the pub¬ lish/subscribe server checks the identity of the clients submitting the transaction proposals.

It will be apparent to the skilled person that the networked computer system according to the present invention may be implemented by one or more standard computers which are suitably equipped to establish communications links, e.g. by the internet, telephone lines, WAP, GPRS, i-mode, intranet, or the like, and which are suitably programmed to imple¬ ment a networked system according to embodiments of the invention. Accordingly one em¬ bodiment of the present invention may comprise a computer program comprising computer executable instructions which when running on a computer implement a networked system according to embodiments of the invention. According to a further embodiment the inven- tion comprises a data carrier having recorded thereupon or embodying such a computer program.

The present invention has been described in the following by means of exemplary em¬ bodiments. It should be readily apparent to a skilled person that modifications of these embodiments can be made without departing from the spirit and scope of the present in¬ vention.

Claims

1. A networked computer system for trading personalised assets which are stored in a resource server being a computer of a service institution, said computer being acces- sible through clients belonging to said service institution and through an enforcement server acting as a mediator between said resource server and computers not be¬ longing to said service institution, said system further comprising:

- an enforcement server , said enforcement server comprising: a public interface for receiving from a computer outside of said service institution data about a transaction to be performed with respect to the personalised asset stored in said resource server based on a match between two transaction pro¬ posals;

- a receiving module for receiving through said public interface data indicating a transaction reflecting a match between two transaction proposals of different customers,

- a checking module for checking the validity of said transaction; - a conversion module to convert said received transaction data into such a format that it can be forwarded to said resource server to thereby trigger the execution of the transaction on the resource server;

- a contacting module for contacting said resource server of said service institution which maintains a database of said personalised services of said clients through said non-public interface to forward said converted transaction data to thereby trigger the execution of said transaction on said resource server.

2. The networked computer system of claim 1 , further comprising: a monitoring server for monitoring transaction proposals stored on said pub¬ lish/subscribe server as to whether offer and demand of two proposals match, said moni¬ toring server further comprising: a forwarding module for forwarding transaction data to said enforcement server in case of a match between offer and demand of a pair of proposals being detected.

3. The networked computer system of claim 1 or 2, further comprising: a negotiation server for automatically negotiating a settlement between two transac¬ tion proposals which partly match based on a negotiation strategy which has been respec- tively assigned to said transaction proposals.

4. The networked computer system of claim 3, wherein said negotiation strategy com¬ prises: a user-defined negotiation strategy component definable by the user according to his preferences, and an operator-defined negotiation strategy component definable by the operator of said negotiation server.

5. The networked computer system of one of claims 1 to 4, wherein said negotiation server is adapted to negotiate between more than two proposals if one proposal preliminarily matches with more than one other proposal.

6. The networked computer system of claim 3, 4 or 5, wherein a transaction proposal may contain invariable items and at least one variable item and a negotiation strategy indicating how said variable item may be automatically varied by said negotiation server to reach a settlement; and wherein said monitoring server selects such pairs of transaction proposals as partly matching proposals which coincide at least with respect to the items which in both propos¬ als of a selected pair are non-variable items, and where for the not coinciding items of the proposals belonging to a certain pair at least one item is indicated to be a variable item, said negotiation server automatically varies said at least one variable item ac¬ cording to said negotiation strategy in order to arrive at a full matching between said trans¬ action proposals.

7. The networked computer system of one of claims 2 to 6, wherein said monitoring server is adapted to check a proposal newly entered on the publish/subscribe server against all already existing proposals on the publish/subscribe server as to whether there is a prelimi¬ nary match, and further being adapted to form pairs of proposals for those cases where a preliminary match was found.

8. The networked computer system of one of claims 3 to 7, wherein said negotiation strat¬ egy includes a timing scheme according to which one or more variable items are varied during negotiation.

9.. The networked computer system of one of claims 3 to 8, wherein said negotiation strat¬ egy comprises an indication which item of a transaction proposal is variable and further a limit for the variable item or a defined list of variations of said item ordered according to their priority.

10.. The networked computer system of one of claims 1 to 9, wherein said checking mod¬ ule comprises:

- a key infrastructure module for enabling to check based on personalised keys the identity and/or the authorisation of the parties involved in said settlement; - an identity and/or authorisation database for storing identity information identifying individuals and/or authorisation data indicating whether a certain individual is authorised to execute a certain transaction;

11. The networked system of one of the preceding claims, wherein said publish/subscribe server comprises: a transaction proposal database for storing data sets related to a certain transaction proposal, wherein a data set related to a certain transaction pro- posal comprises:

• the type of offer indicating the type of asset or service which is to be offered;

• the type of demand indicating the type of asset demanded as com¬ pensation for said offer, • a sub-type of said offer indicating particulars of said offer; • a sub-type of said demand indicating particulars of said demand; and wherein said negotiating strategy comprises:

• an indication corresponding to said types and sub-types and indi¬ cating whether said types and/or said sub-types may be varied by said ne- gotiation engine to reach an agreement between two proposals.

12. The networked system of one of the preceding claims, wherein each proposal is assigned a unique ID, and once a proposal has been subject to a set¬ tlement all pairs of proposals are checked whether they include the proposals which have been subject to the settlement, if so, then the pairs including these proposals are put on hold or the proposals involved in the settlement are removed from these pairs.

13. The networked system of one of the preceding claims, wherein said publish/subscribe server comprises: a push service unit for automatically forwarding proposals to a user who has sub¬ scribed to the push service.

14. The networked system of one of the preceding claims, wherein said monitoring server searches for not fully matching pairs of proposals based on the following conditions: offer and demand of the selected pair of proposals partly match and for the non- matching parts of offer and demand at least one proposal indicates that the corresponding non-matching item may be varied according to a certain negotiation strategy.

15. The networked system of one of the preceding claims, further comprising:

• a variable item as a component of said offer and/or said demand;

- a negotiation engine for negotiating a match between the variable components of said offers belonging to two different individuals to reach a settlement.

16. The networked system of one of claims 3 to 15, wherein said negotiation engine comprises:

- a module for calculating a settlement value of said variable value based on a cal¬ culated average of the limits of said variable values given for the transaction pro- posals belonging to a pair of transaction proposals between which the negotiation engine tries to reach a settlement; and/or

- a module for varying said variable component of said offer according to a prede¬ fined variation scheme until a match between the two variable components of the two parties involved is reached.

17. The networked system of one of claims 3 to 16, wherein if two corresponding items of a pair of transaction proposals which do not fully match both are variable said negotiation engine varies both items in order to reach a balanced settle¬ ment value.

18. The networked system of one of claims 1 to 17, wherein a validity check comprises checking whether the items offered in a certain proposal are owned by the individual making the offer.

19.. The networked system of one of claims 1 to 18, wherein after a validity check has been executed for a certain proposal a reservation is made by indicating in said resource server that the offered items are subject to an offer and should not be amended before a transaction related to said offer has been concluded.

20. The networked system of claim 19, wherein reservations are cumulatively made in case of a plurality of proposals being submitted by a certain individual.

21. The networked system of one of claims 3 to 20, wherein a validity check is performed once again before triggering a transaction and after having reached a negotiated settlement.

22. The networked system of one of claims 1 to 21 , further comprising: a plurality of resource servers which can be accessed by a single enforcement server for triggering transactions; a plurality of publish/subscribe servers and/or monitoring servers and/or negotiat¬ ing servers connected to a single enforcement server.

23. The networked system of one of claims 1 to 22, wherein said publish/subscribe server integrates a plurality of service institutions such that the predefined categories of offer data and demand data for a certain transaction proposal may belong to different service institutions, and wherein said enforcement server enforces a transaction based on such a transaction pro¬ posal by triggering transactions in resource servers belonging to different service institu- tions.

24. The networked system of one of claims 1 to 23, wherein said publish/subscribe server is implemented by a client terminal owned by a cer¬ tain user.

25. The networked system of one of claims 1 to 24, further comprising: a loyalty points server on which in a database loyalty points granted by said serv¬ ice institution to customers of said service institution are stored or maintained, and wherein a transaction proposal may involve loyalty points as an offer or a demand and said enforcement server accesses said loyalty points server through its non-public interface to trigger transactions which have been concluded and which involve loyalty points.

26. A computer program for implementing when being executed on a computer a net¬ worked system of one of claims 1 to 25.

27. A data carrier comprising a computer program according to claim 26.

28. A method for operating a networked computer system for trading personalised assets which are stored in a resource server being a computer of a service institution, said computer being accessible through clients belonging to said service institution and through an enforcement server acting as a mediator between said resource server and computers not belonging to said service institution, said method comprising: - receiving transaction proposals by a publish/subscribe server, whereas a transac¬ tion proposal originated from a certain customer of said service institution com- prises an offer, a demand, and a negotiating strategy, said offer and said demand relating to services which may be claimed by or to assets which are owned by said customer as a customer of said service institution; wherein said networked computer system further comprises an enforcement server , said method further comprising: - receiving by a public interface of said enforcement server from a computer out¬ side of said service institution data about a transaction to be performed with re¬ spect to the personalised asset stored in said resource server based on a match between two transaction proposals;

- contacting by a non-public interface of said enforcement server said resource server through said non-public interface, said non-public interface being identical to the interface through which client computers of said service institution access said resource server,

- receiving by a receiving module of said enforcement server through said public interface data indicating a transaction reflecting a match between two transaction proposals of different customers,

- checking by a checking module the validity of said transaction;

- converting by a conversion module said received transaction data into such a format that it can be forwarded to said resource server to thereby trigger the exe¬ cution of the transaction on the resource server; - contacting by a contacting module of said enforcement server said resource server of said service institution which maintains a database of said personalised services of said clients through said non-public interface to forward said con¬ verted transaction data to thereby trigger the execution of said transaction on said resource server.

29. The method of claim 28, wherein said networked computer system is a system accord¬ ing to one of claims 2 to 25.