WO2001075642A2 - Improvements relating to information systems - Google Patents

Abstract

A distributed transaction exchange (1) for supporting a mediated transaction (12) between a supplier (24) and a customer (28) is described. The exchange (1) comprises: a plurality of exchange member (20) and meta members (16). Each member (20) and meta member (16) is arranged to perform a processing function, to play any of the roles of a supplier (24), a customer (28) or a mediator (26), and to publish its demand, supply and mediation capabilities for consideration and use by the exchange (1). Each meta member (16) is related to a group of exchange members (20) or meta members (16) and is arranged to describe the attributes of that group. The exchange (1) is arranged to construct the mediated transaction (12) between the supplier (24) and the customer (28) from members (20) and meta members (16) selected on the basis of their published capabilities.

Description

Improvements Relating to Information Systems

Field of the Invention

The present invention concerns improvements relating to information systems and more particularly, though not exclusively, to a distributed transaction exchange for supporting co-operative mediation through use of a versatile modelling technology. This can provide support for improved mediated transactions, information searching and service provision to both customers and suppliers in any transaction.

Background of the Invention

Transactions involving a supplier and a consumer are frequently facilitated with the aid of mediators. In an efficient exchange, these brokers perform the tasks associated with the matching of supply and demand providing a negotiation nexus that attempts to elicit the transaction of most value for the participants and the exchange itself.

Traditionally the task of mediation has often resembled a fixed and brittle dynamic in any given transaction model. This is evidenced by the difficulties organisations have encountered in migrating their operations from their older, high cost brokerage such as branch networks to the new cheap and versatile channels exemplified by but certainly not confined to the Internet. New enteφrises have fared better but a familiar observation remains that most modern transactional models focus on the supplier and consumer aspects as the value drivers while mediation often resembles little more than operational overhead.

Take, for example, a high street branch network selling mortgage products. This is a high cost yet effective channel for such transactions between the mortgage providers and most customers. The cost driver may lead the manager of the exchange to close the branch network in favour of the online low cost channel. This may be a reasonable choice given the option. However, this channel may only be effective for a given segment of consumers and selection of products. Channels on an exchange are not usually modelled at the micro level with the other transaction participants in terms of their economics and facilitation effectiveness. Campaign management tools for instance solve for the supplier and consumer and then layer the channel choices on top. This crude level of granularity prevents the automation of a highly efficient exchange.

An example of an automated mediated exchange is provided in WO-A-99/60537. Here, a platform comprising component objects (corresponding to a component of a transaction) is provided. Each component comprises a related member which is populated with member information from various member categories and a plurality of the member objects are interrelated by use of a notational language. Whilst a commercial exchange supporting brokered transactions can be modelled, the above described difficulty is also inherent in this prior art system.

Other examples of electronic transaction exchanges which use intelligent agents are seen in WO-A-99/52042 and WO-A-97/26612. Again, there is no appreciation in these prior art systems that there can be any problem with the way channels are modelled within such exchanges and accordingly these systems are limited.

Summary of the Present Invention The present invention aims to overcome or substantially reduce at least some of the problems and disadvantages of current transaction systems and methods of modelling transactions.

It is another object of the present invention to improve the efficiency of an exchange for the conduction of transactions.

The present invention, according to one aspect, resides in the appreciation that there are significant advantages in the use of a distributed exchange; in particular, a distributed exchange that enables a series of smaller sub-exchanges to collaborate in as a federated system of networked services in an attempt to satisfy customer, supplier and mediation capability.

More specifically, according to one aspect of the present invention there is provided a distributed transaction exchange for supporting a mediated transaction between a supplier and a customer, the exchange comprising: a plurality of exchange members and meta members, wherein: each member and meta member is arranged to perform a processing function, to play any of the roles of a supplier, a customer or a mediator, and to publish its demand, supply and mediation capabilities for consideration and use by the exchange; and each meta member is related to a group of exchange members or meta members and is arranged to describe the attributes of that group; the exchange being arranged to construct the mediated transaction between the supplier and the customer from members and meta members selected on the basis of their published capabilities.

Thus the present invention involves the use of meta members that can take on any of the roles of a supplier, customer or mediator in a transaction exchange. These meta members are not only collections of members but also have relationship information (relating to other members/meta members) provided in them to enable information substitution or aggregation such that efficient modelling can be carried out even when all of the required information is not present.

Because of the use of such meta members, it is now possible to model the economics and effectiveness of channels in transactional behaviour which was not previously possible. The consideration of the cost and effectiveness of a channel in modelling a transaction exchange is not only novel but also enables consideration of the role of the channel as mediator, equivalent to suppliers and consumer in the ability to model its dynamics in terms of the above with respect to the same granularity at the meta and micro level (explained later). One aspect which is important to the present invention is the concept of content neutrality. A member of the exchange may play the role of supplier, consumer or mediator in a given transaction. This 'agnostic' view of transactional exchanges allows a member to play different roles in different transaction models yet retain their immutability. This is facilitated by the active modelling of transaction^" roles which form the bridge between the state of the member and its behaviour in a transaction.

The concept of a distributed transaction exchange assumes that members acting as agentsperform the functions that comprise an overall transaction process which ultimately solves for the supply and demand requirements of the exchange's members. Mediators in such an exchange can be thought of as stand alone agents with the ability to perform transactional steps or sub-processes. This has the effect of automating the exchange and improving its efficiency. The publication of an agent's capabilities and the potential value it offers to other agents enables intelligent graphs of transactional activity to be sourced from supply or demand drivers. Some agents might publish demand profiles for certain services while others might publish supply profiles. Examples of mediators include web sessions, call centre agents, fax, e-mail and SMS gateways, sales agents and even advertising billboards. With the present invention all of these can be modelled because of the use of meta members to facilitate transactions between individual or collective groups of suppliers and consumers.

The present invention also provides a distributed transaction exchange for supporting cooperative multi-modal mediation between a supplier and a customer. The term 'multi- modal mediation' means cross-channel mediation, i.e. a transaction might start of as _. a web interaction, be followed up by a phone call, then confirmed in an e-mail. In a multi- modal mediation, all steps are executed on the same transactional platform using the same underlying technology.

In implementing the concept of the distributed exchange as provided by the present invention, the inventor has appreciated that this has the following implications: 1. Standardisation of transactions and content. For the participants of the exchange to interact, the components of a transaction, in terms of supply, demand and mediation parameters, needs consistent expression. This involves the modelling of transactions and content in a uniformly accepted format.

2. Technological deployment. A multi-channel distributed exchange poses challenges with respect to how agents are incarnated and communicate with each other. This implies the use of synchronous and asynchronous messaging protocols that complement the uniform format transaction modelling approach described in point 1.

3. Definition of the rules and assumptions on which the exchange operates. In the distributed market space each agent is considered autonomous with its own capabilities and value motivators. These need to be reconciled with the operation of the exchange itself as it creates value for consumers and suppliers. It also implies that liquidity of mediation should be understood along with supply and demand.

4. Support for multiple transactional models. The granularity of the transactional activity is discreet and de-coupled which implies that different flavours of transactional models can be explored.

The above describes how the needs of disparate members of an exchange may interact through a multi-mediated network made possible by technologies enabling transaction homogeneity and ubiquitous deployment.

According to another broader aspect of the present invention there is provided a distributed exchange for executing a transaction between a supplier and a customer via a mediator, the exchange comprising a plurality of members which are arranged to take the role of the mediator and, wherein at least one of the members comprises a meta member, each meta member comprising a collection of information representing the features of a group of related members that are able to participate in mediation of the transaction supported by the exchange, such that any member of that group can be modelled by the meta member.

The present invention effectively models a transactional exchange using meta members and one of the major advantages is that even if the required information regarding a member is not available, the characteristics of the meta member to which the member belongs can be used instead. This facilitates an exchange whereby an outcome can be estimated rather than not at all. The use of meta members together with further advantages is described in detail below.

The concept of 'meta members' can be used in conjunction with a transactional pattern in the creation of trading systems using software. Each construct plays a revolutionary role in the modelling of trading scenarios between suppliers, consumers and mediators. These scenarios can be implemented on the automated exchange, which facilitates the steps of publication, prospecting and execution required in all transaction market spaces. The effective modelling of meta members can also be used to radically improve the efficiency and transparency of such trading operations.

The terms in which the present invention and, in particular, the preferred embodiment of the present invention will be described are:

Exchange. A market constructed to facilitate transactions. Its artefacts include the hardware, software, humans, support systems, and interfaces that enable trading to take place.

Member. A player (participant) on the exchange able to participate in a transaction. Individual participants are known as particle members while collections or abstractions are known as meta members. Transaction. An interaction containing relationships between one or more participants with clearly defined boundaries. Each participant may play the role of:

^■ a supplier providing content such as goods or services,

■ a consumer with demand for content, or. ^■ a mediator bringing together suppliers and consumers and facilitating transactions.

Transactions can represent potential, or unrealised, agreements and a transaction's state is used to describe its status. The execution of a transaction culminates in a discreet outcome.

Members are described by their relationship with respect to other members. The notation adopted herein is:

mMember - a particle or leaf member, for example: mJoeDeacon, mJagM201 ALM

mMetaMember - the meta member, or category container, for example: mmMortgages, mmGuardianReaders

rRelation - the one-many relationship between a category and sub-category of members, for example: mmEvent rLocates mmLocationEvent

TxTransaction( supplierMember, consumerMember, mediatorMember ) - a transaction involving members or meta members in the roles of supplier, consumer, mediator. For example: TxPublishMortageOnWeb( mmMortgage/m, mmUser, mmWeb/m );

The base meta member is known as the domain or mmDomain. All other meta members and particle members inherit characteristics from the domain. The primary transaction is known as TxZ and the exchange can be understood to be:

TxZ( mmDomain, mmDomain, mmDomain ) A participant in a transaction can be modelled as a macro component where what is known of the participant is confined to the broad category it belongs to or has originated from. The macro member of the exchange might be the anonymous purchaser of a newspaper and the target of an advertising campaign. As all is knowri about the macro member is effectively the characteristics of its category, there are limited uses of the information in the process of prospecting potential transactions. In contrast, a micro player in a transaction is a fully qualified entity where all its details available. Examples of micro members include financial instruments in a dealing system or a registered user on a membership scheme. A fully enriched micro player for a transaction is an exchange operator's dream as all is known about a trade to enable the most effective prospecting. Unfortunately the elicitation of this information is a non-trivial process whose complexity is often commensurate to the value of the type of transaction pursued. Through the transaction process, as more knowledge is gathered, an exchange's participant is effectively morphing from its macro to its micro state.

The meta member construct can be considered as a bridge between these two categories of participants, such that a participant in a transaction can be represented by a known aggregation of its details. In other words, if a field such as 'age' is desired for the prospecting process, in the absence of its knowledge, the age distribution of an associated meta member can be substituted.

In software modelling terms, a meta member is modelled as a representative collection of information relating to a potential transaction. This helps in constructing a more efficient exchange for the conduction of transactions, because meta members can be introduced in the model to optimise a trading process (described in detail later). For example, a meta member constructed to reflect the audience of a given media can be exploited to decide the kind of product or service an individual reader might be interested in. Whilst, this has been the practice of marketing campaigns since conception, however, seldom have previous modelling processes considered a member beyond its macro state. The meta member method of the present invention allows a prospecting model to discern the value of information - if it is likely this information will yield a positive transaction outcome then the effort can be exerted to elicit the data.

In implementing a transaction, consideration is given to what is involved in any trading process, namely that as a first step, needs are gathered. This process is effectively the publication of demand, supply or mediation capability of members of the exchange. Once these details are known, a prospecting process can be used to match the triumvirate and proceed to an executed trade. It is the publication or elicitation of supply, demand or mediation that represents the most expensive component in the transaction process - hence the value of an in-bound request over a cold call. The meta member provides a means to quantify the potential for a transaction and determine if a step is economically worth proceeding with.

In notational terms, this can be considered as:

Tx( mSupplier, mConsumer, mMediator )

- a transactional step between three participants.

The value of this step can easily be understood as it is made up of discreet components like commission from the supplier, cost of the mediation, incentive points to the consumer etc. However, the step has most value if its outcome is positive and this will not be known until the trade is entered into and the requisite facts gathered from all parties. Where the meta member plays a role is by substituting the virtual member in_. place of the actual to enable a probability assessment of the likely outcome i.e. Tx( mSupplier, mmConsumer, mMediator)

- in the absence of the consumer's demand requirements, or,

Tx( mmSupplier, mmConsumer, mmMediator)

- in a total prospecting scenario. The exchange can exploit this probability coefficient along with the calculated value to decide if the transactional step should be executed.

As mentioned above, as more information is gathered about the participant of a transaction then the aggregation converges to the micro representation. This can be viewed as analogous to a crime wave in a given area, which disappears as an individual incident is considered - this is no longer dealing with distributions but actual values. These actual values allow the binary decision of transaction outcome to be made where the meta representation can only give a probabalistic estimate.

The way in which the moφhing process is represented in software technology is now described. A transaction between participants can be appropriately modelled as a relationship with each member's role object containing the appropriate state and behaviour. Similarly, the meta member can also be viewed as a container of its individual members and this arrangement can also be represented as a relationship. This linkage allows a transaction access to the actual or aggregated values. A further problem lies in enabling a transaction to determine that a value is not present and to use the substituted distribution in its model instead. This is addressed by a generic data-object construct that can be used to represent either an instance value or a distribution which allows a model that encounters it to behave appropriately.

Transactions can be viewed as nested with the outermost transaction being the kernel of the exchange itself. The transaction pattern that can be used with the present invention is based on a publish, prospect and execute behavioural triad. These activities are described below:

■ Publish. This phase is effectively the birth, or instantiation, of a transaction. The rules governing the publication of a transaction are based on observation of previous transactions and the requirements of the potential members. ^■ Prospect. Once created, a transaction is prospected for execution. The pattern assumes multiple published transactions vying for potential execution. The execution phase of an outer transaction determines which of these move to the next stage. However the coefficient it uses comes from a propensity/value model which resides in the prospected transaction itself.

^■ Execute. If a transaction is sanctioned for execution, its mediator performs the mechanics of this task. The task culminates in an outcome which may trigger the publication of other potential transactions.

According to another aspect of the present invention, there is provided a method of implementing a transaction using a distributed exchange, the exchange having a plurality of transaction members and respectively related meta members containing groups of members, each member and meta member being capable of performing a processing function and of playing the role of a customer, a supplier or a mediator, the method comprising: publishing full details of the demand, supply or mediation capabilities of each member or, if a member's full details are not available, publishing full details of the demand, supply or mediation capabilities of a related meta member; prospecting the published demand, supply or mediation capabilities; and executing the transaction based on a selection of members' or meta member's processing functions which when combined enable the transaction to be completed from the supplier to the customer via the mediator.

The articulation of transactions describe the dynamics of the modelled exchange. A transaction modelled or supported by the exchange of present invention is described by the following components:

α The 'roles' of the members. The supplier, consumer and mediator participants are described in terms of their attributes and behaviour that play a role in the transactional step. These are accessed in the publication, prospecting and execution of the transaction. α The events triggering and the rules governing publication. These are described as one or more observation/instantiation cutlets. The observation task views the outcomes of other transactions while the instantiation phase creates the transactions spawned by these. The roles of the spawned transactions are constructed from those observed.

□ The propensity/value (p,v) model exploited to sanction the transaction for execution.

The propensity calculation determines the likelihood of a given outcome while the value model describes its potential worth. There are as many p,v models as there are potential outcomes and the outer transaction uses these to decide which transaction should execute next. p,v models are covered in more depth below.

According to a further aspect of the present invention there is provided a method of performing a transaction step of a transaction process implemented on a distributed transaction exchange, the method comprising: identifying a transaction step having a member which is missing desired information, such that the transaction step cannot be evaluated for execution; substituting a meta member associated with the member in place of the member to provide approximation information relating to the missing information of the identified transaction step; evaluating the identified transaction step to determine an approximation to the outcome of the transaction step; selecting an evaluated transaction step having the most desirable outcome or approximated outcome; and executing the selected transaction step on the transactional exchange.

The above method solves a problem when an incomplete or evolving data set regarding a member is being obtained. In this case, using the probability function of a set to which the desired member belongs advantageously provides a best approximation as to the likely outcome of the desired member function.

In an embodiment of the present invention, users publish their demand and supply on a proprietary information exchange. Using trading algorithms, intelligent agents prospect on behalf of the buyer (or seller) to find a match. The exchange of the present embodiment then, by applying escalating intelligence, executes a transaction either within the information service (the information service accepts the buyer's credit card payment on behalf of the seller who then fulfils the demand) or outside the information service, by handing off the buyer to the seller's e-commerce platform.

Preferably the exchange is designed to offer ubiquitous access across all channels, with a focus on wireless (including SMS-Short Messaging Service, WAP-Wireless Application Protocol, GPRS-General Packet Radio Service and UMTS-Universal Mobile Telephone Service), internet and digital television. The exchange is designed to be multilingual and seamlessly link local, national and international information services under one branded umbrella. For example, if a Londoner travels to Holland and searches for "black cab" on his WAP phone, the system will understand he or she wants a licensed taxi.

Transactions are preferably based not only on a basic connection between buyer and seller, but also on various other trading models. The information service provides a "request for quote" model (users can ask subscribers to quote for a service), a "reverse shopping" model (sellers can "push" services) and an auctioning model (single seller with multiple buyers).

Using the exchange of the present invention, an information service supported thereby is not structured around two axes of location (e.g. SW3) and classification (e.g. plumber) alone. Rather, demand and supply is matched according to key attributes (e.g. price category, payment methods accepted, opening hours) so that the user can find not just "an Italian restaurant in London W3", but the cheapest one, or the one that is "open on Sunday". Key attributes are combined with location, using "geo-spatial coding". A full subscriber listing in the information service enhanced directory thus entails much deeper profiles than have been available in the past, containing these "key attributes". With this technical improvement, the information service improves on a previous limit of three telephone listings in a cluster (the combination of location and classification), allowing the information service to put more subscribers in a particular category and location.

The exchange embodying the present invention also enables the information service to identify users more accurately when they access the information service (online, via phone or via interactive TV) and maintain a more in-depth profile of its users in order to better serve their needs: the present invention enables a user's purchasing behavior to be remembered. The information service combines this user data with lifestyle data from providers, and credit data from external credit scoring agencies. Demographic data (age, income, credit rating) can be assigned to the user, based on certain information provided by the user. The present invention enables the information service to group users into similarly profiled groups which can be addressed by subscribers. (Under privacy laws, the information service cannot give out details on individual users, but can group users by certain criteria). The information service can then "push" content to such a group of users, rather than simply react to user requests.

The above described exchange also gives all subscribers a unique local rate virtual phone number provided by a telephone service provider. The information service reads out (whether by voice operator or on a web page) the supplier's details, including his virtual telephone number. When this phone number is called, the subscriber knows, and the information service tracks, that the lead was generated by the information service. Previously information services could only track voice contacts if the user was immediately connected through to an Information Service Connect subscriber through call completion, or on the Internet, if the user contacts the subscriber via fax-back or via e-mail.

Brief Description of the Drawings

A presently preferred embodiment of the present invention will now be described with reference to the accompanying drawings. In the drawings:

Figure 1 is a high-level schematic representation of distributed object architecture of an exchange embodying the present invention;

Figure 2a is a schematic block diagram showing the relationship between particle and meta members of the exchange of Figure 1 ;

Figure 2b is a schematic block diagram showing the way in which a transaction links together different members of the exchange of Figure 1;

Figure 3 is a schematic representation of the object domain space and the functional services of the exchange of Figure 1 ;

Figure 4 is a schematic representation of the kernel transaction space of the exchange of Figure 1;

Figure 5 is a schematic representation of the mediator transaction space of the exchange of Figure 1;

Figure 6 is a schematic representation of the interface object space of the exchange of Figure 1;

Figure 7 is a high-level schematic representation of an example transactional model and its participants supported by the exchange of Figure 1 : in this model, the suppliers are known as subscribers, consumers are known as users, and mediators are known as agents;

Figure 8 is a flow diagram showing the implementation steps of the transactional process of Figure 7;

Figure 9 is a graph showing the values that are associated with each potential transaction of the transactional process of Figure 8; Figure 10a is a schematic diagram of a first example for illustrating the transaction flows, in particular transaction prioritisation within the exchange of Figure 1;

Figure 10b is a schematic diagram of a second example for illustrating the transaction flows, in particular call hand off within the exchange of Figure 1;

Figure 11 is a schematic diagram of a third example for illustrating the transaction flows, in particular transaction push within the exchange of Figure 1;

Figure 12 is a block diagram illustrating the relationship between meta members and particle members in an example of a transaction model involving an event service implemented on the exchange of Figure 1

Figure 13 is block diagram illustrating the relationship between transactions in the example of a transaction model shown in Figure 12;

Figure 14 is a block diagram illustrating event service push flows in the example of a transaction model shown in Figure 12;

Figure 15 is a block diagram illustrating further event service push flows in the example of a transaction model shown in Figure 12;

Figure 16 is a block diagram at a highest level illustrating event service request flows in the example of a transaction model shown in Figure 12;

Figure 17 is a block diagram of event service request flows of Figure 16 showing how the guess classification, time period and location transactions are refined;

Figure 18 is a block diagram illustrating the event service request flows involved in presenting results to a customer which result from one of the transactions of Figure 17; Figure 19 is a geographical map showing the geo-spatial catchment distribution used in a visiting plumber example;

Figure 20 is a geographical map showing the geo-spatial catchment distribution used in a cinema event seeker example for showing how the geo-spatial propensity aspect in a p,v model between cinema events and consumers can be evaluated;

Figure 21 is a schematic representation of two geographical areas used in a dating parties example for showing how a proximity coefficient is used in the propensity model for a dating transaction between suppliers and consumers;

Figure 22 is a schematic representation showing the relationship between members, meta members and meta content as defined in the embodiment of the present invention;

Figure 23 is a schematic representation of a channel framework of the exchange of Figure 1 : in this transactional model the suppliers are known as subscribers and consumers as users;

Figure 24 is a schematic representation of the internet channel of the channel framework shown in Figure 23;

Figure 25 is a schematic representation of the SMS channel of the channel framework shown in Figure 23; and

Figure 26 is a schematic representation of the fax channel of the channel framework shown in Figure 23.

Detailed Description of a Preferred Embodiment of the Present Invention A distributed information exchange, together with its support structures, according to a preferred embodiment of the present invention is now described. The distributed information exchange of this embodiment is herein after referred to as the Kobe exchange.

Figure 1 shows the high-level distributed object architecture of the Kobe exchange 1. More specifically, the distributed object architecture is based around the facilitation of arbitrary transaction models. The exchange 1 is segmented into three distributed object spaces, namely an object domain space 2, a kernel transaction space 4 and a mediator transaction space 16, that are undeφinned by hardware and software subsystems which make up an overall system which supports the exchange 1. These object spaces 2,4,6 radiate concentrically from a kernel of the exchange 1 to its external interfaces which are provided in the interface object space 8.

The exchange 1 is concerned with providing a technological infrastructure to support the homogeneity of its members 10 and the activities (phases) of publication, prospecting and execution (described in detail later). To do this a user of the exchange 1 must provide the means for the articulation of various members, roles, relationships and transactions on the exchange 1. This articulation takes the form of the efficient modelling of business logic and intelligent interfaces to members' systems. Transactional models are implemented on top of the object spaces 2,4,6 and each is described in further detail below.

Object Domain Space

The object domain space 2 is where the members 10 of the exchange 1 reside. These members 10 are created and maintained on the system supporting the exchange 1 and become the suppliers, consumers, or mediators in transactions conducted on the exchange 1. A domain member 10 may be one of the following types:

A particle member: a representation of an individual participant or player on the exchange 1. A particle member generally has a tangible form in the outside world such as a customer, product or agent. As shown in Figure 2a, particle members 14 exist in the contexts or collections of related members, or meta members 16, and transactions between them represent the objective of the exchange 1. Each particle member 14 has a relationship 18 with the meta member 18. As the particle member 14 and the meta _. member can take on different roles, the role 20 of the particle member 14 is stored within the particle member and the associated role 22 of the meta member 16 is stored within the meta member 16 (described in more detail later with reference to Figure 2b).

A meta member 16 is a collection or aggregation of members 10 on the exchange 1 belonging to a common category. The term 'meta' refers to the descriptive qualities of members 10 belonging to the collection and these are generally represented as distributions rather than actual values. Accordingly, meta members contain fields and observations as distributions. As such they act as aggregated proxies that can greatly enhance the relationship management process by providing probabilistic values in the absence of actual data. Meta members 16 can also participate in transactions 12 in order to establish probabilistic outcomes, which is described later. The construction of meta members can be sourced from outside or, ideally, from the observations of transactions made in the market space.

Meta members fall into two types concrete and abstract. A concrete meta member is a representation of a collection of particle members - a simple container of related objects such as Guardian readers or financial products. Typically a concrete meta member is constructed from a complete list of members of a given category. If an inventory of content exists on the exchange, the meta member is effectively a rollup of the category. An abstract meta member is a representation of the characteristics of a particular member when the individual parameters are unknown. Namely, an abstract meta member is an aggregation which represents characteristics of the membership without having access to the individuals it comprises. For example, the source profile of a newspaper readership is an abstract meta member. Both types of meta members can be used in the same way, as a substitute for the individual members 10 to enable trading decisions to be made in the absence of the actual parameters.

The object domain space 2 maintains the state of the particle and meta members 14,16 and exposes them to the transaction spaces 4,6 through their names.

Kernel Transaction Space.

Potential transactions 12 reside in the kernel transaction space 4. Referring to Figure 2b, in the exchange 1, a transaction 12 is a stage in a transaction process that has three participants, a supplier 24, a consumer 26 and a mediator 28. A transaction 12 contains the relationships between its constituent members 10 of the exchange 1 and describes an agreement between those members 10 to perform a particular function. A typical commercial transaction, i.e. the exchange of goods for payment, between a supplier and consumer over the Internet is an example of such relationships. Members 10 of the exchange 1 enter into transactions 12 with other members 10 as they progress through the market space. A customer 28 may initially form a relationship with an Internet agent 26, then progress to selecting the category (classification) of supplier, and subsequently choose to be transferred to an individual supplier 24. In this way, transactions 12 link together in the form of paths where each has outcome that determines the next transition that is entered into.

The transaction 12 links together three members 10 from the object domain space 2 and each member 10 then takes on one of the following three roles: a supplier role 30, a mediator role 32 and a consumer role 34. The exchange 1 uses a generic approach with the exchange's members 10. The approach assumes that any category of subscriber, user or agent members 24,28,26 can be modelled on the exchange 1 and that any transaction 12 between members 10 of these categories can also be represented. The approach also assumes that any type of member 10 can take any of the roles of supplier 30, consumer 34, or mediator 32 where appropriate in the transactional process. The relationship between the three participants 24,26,28 in a transaction 12 is now described in detail.

As mentioned above, transactions 12 link together to create trafficable trades between these participants 24,26,28. Each participant 24,26,28 may be a particle or meta member. Transactions 12 are prospected and dispatched for execution by this object space 2. The exchange's kernel is effectively programmed by the rules of a transaction model that is implemented on the exchange 1. Potential transactions 12 are created by templates and are scheduled for execution according to probability and value coefficients (described in detail later). As a transaction 12 is executed, its outcome determines the next transactions 12 to be scheduled for execution. In this way, a graph of transactions 12, or transaction paths, of the exchange members 10 are built up. When a potential transaction 12 is elected for execution it is passed to the mediator participant 26 which is responsible for ensuring the transaction 12 is completed to an outcome.

Mediator Transaction Space.

A mediator 26 on the Kobe exchange 1 is required to be able to perform the transactional steps it participates in. Examples of mediators 26 are web agents, tele-agent sessions, credit screening entities - and messaging services. On execution, a transaction 12 is dispatched to its mediator 26 which performs the tasks it comprises. These tasks may include the presentation and elicitation of information on behalf of one of the other participants 24,26,28 and performing calculations or models based on this information. , Whatever the activity, the mediator_. 26 ensures that the transaction 12 concludes becoming a concluded transaction 36 and the transaction outcome is signalled to the scheduling kernel so the appropriate subsequent transactions 12 are precipitated. A mediator 26 communicates with the external world through interface objects 38.

Interface Object Space. Interface (presentation) objects 38 represent the means for information exchange with beings and entities external to the exchange 1. In the present embodiment, an html page 38 is rendered for human consumption and the request for a credit check, for example, is formatted for and communicated to the appropriate agent, mediator 26. The interface object space 8 is a thin layer linked to the mediator transaction space 6 and each mediator 26 understands the format and dynamics of its interface objects 38.

Coupling the Object Spaces

Progressing further than the n-tier model, the Kobe exchange 1 exploits a de-coupled architecture rendering highly interactive and distributed. The key modules residing in the domain and transaction object spaces 2,4,6 communicate in an XML message format allowing the architecture to be open and transparent. Complex behaviour such as models and calculations are accessed by reference through remote Java objects. Interface objects 38 are created from their XML source through style sheets (XSL) or via object wrappers where external systems are involved.

The object spaces 2,4,6 are supported by subsystems and modules, each of which is described below with reference to Figures 3, 4 and 5.

Referring to Figure 3, factories 40 are provided for supporting the domain object space 2. More specifically, members 10 of the exchange 1 are created and named by a life factory 42 using an object lifecycle approach, namely objects which are created and progress through different stages of their life until destruction. The life factory 42 is also responsible for deletion of members 10 from the object domain space 2 at the end of their life cycle or as required. A management factory 44 is provided for member management in particular meta members. The management factory 44 allows the immutable participants 24,26,28 on the exchange 1 to be maintained. A finder factory 46 is also available to locate objects 10 by both name and selection criteria. The finder factory 46 includes a query and collection capability. Meta members (containers) 16,48 may be tiered and are maintained by a relationship service implementation of containment. The kernel transaction space 4 contains the most complex functionality and subsystems of the Kobe exchange 1. Each transaction 12 is represented by a relationship and the roles 30,32,34 of its participants 24,26,28 as shown in Figure 2b.

Referring now to Figure 4, as with the members 10 themselves, these transactions 12 are created by the appropriate life factory 50 and the process is managed by a relationship service. Transactional engines 52 providing engine processes support the scheduling and execution of transactions 12 in the kernel transaction space 4 that are responsible for the implementation of the trading model defined for the exchange 1. This task is assisted by the invocation of propensity and value models which are available from model interfaces 54. Lastly to undeφin these models, and to provide for other peripheral reporting and administrative support systems, a comprehensive transactional database 56 is generated. The database 56 is essentially three dimensional allowing it to be viewed from the perspective of the consumer 28, supplier 24 or mediator 26 and is relational by definition.

Referring now to Figure 5, the exchange's mediator transaction space 6 is populated by mediator systems and services 60 that execute the transactions 12. Mediators 26 are responsible for the carrying out of the tasks of acquisition, publishing, prospecting, execution and outcome elicitation that transactions 12 on the exchange 1 comprise. In this embodiment, a telemarketing subsystem 62 is implemented by creating clients that understand how to execute transactions 12 using phonic channels. Like all mediators 26 these clients are modelled on the Kobe exchange 1 as active, and economic, members .10 of the transactions 12 that they participate in. An Internet session subsystem 64 with different dynamics and economics is also modelled. The Kobe exchange 1 presents the opportunity for autonomous agents 66 to perform tasks such as searching for transactional candidates and the automatic publication of content. Thus the inherent independence of these agents 66 adds an interesting dimension to the dynamics of the exchange 1. Finally, systems 68 performing valued added services such as credit checking and consumer demographic augmentation are incoφorated into a transactional model by external mediators (not shown). All these mediator subsystems 60 are able to transform/translate the Kobe exchange's vertically implemented XML semantics into the presentation format of the target interface in the interface object space 8. These translation functions benefit from a high degree of reuse.

As described above, Kobe exchange's mediators 26 are responsible for the mapping of XML transactions 12 into the interface (presentation) objects 38. Figure 6 shows some examples of these, namely an html page, a fax, a csv record, a radio jingle, an SMS message, a sales lead, a television commercial, an external request an e-mail, a row of a database. These are only examples of the types of interface objects 38 that can be supported by the interface object space 8 of the exchange 1.

The boundaries of the exchange 1 can extend to transactions 12 in the domains of sales and marketing as the language used to implement the exchange facilitates modelling at both the macro and micro level. A major characteristic of the interface object space 8 is its 'thinness' as the higher level operations such as transaction modelling and execution are performed by the heavy duty members 10 in the exchange 1. This pattern also sits comfortably in relation to the modular construction of a trading model and its extensibility.

The architecture of the Kobe exchange 1 sits upon the horizontal services 40,50,52,54, 56,60 and containers 16,48 described above. It provides an open, flexible and extensible framework for the rapid construction of commercial models across a number of domains, namely vertical models. Such a vertical model is now described and the major aspects of its approach are identified.

Domain Model

A Transactional Exchange

The Kobe exchange 1 models a transactional exchange, whose, goal is to match consumer's demand with suppliers' services. Its strength lies in its ability to model transactions ranging from extremely shallow, such as a bouquet of flowers, through to deep and complex, such as a mortgage or personal loan.

The act of modelling can be considered to be an inherent part of using a meta member because the meta member will always contain distribution/aggregation information. Applying the characteristics of a meta member involves the modelling of content, i.e. structuring the distribution. This may be rollup information from the contained membership (concrete meta members) or applied aggregations from external sources (abstract meta members). The modelling can be automated into the publication phase of the publish, prospect, execute process.

Transactions within the Kobe exchange 1 are driven by a propensity/value model, allowing transactions 12 with a low probability of completion, and with a low potential value to the participants 24, 26, 28, to be eliminated at the earliest possible opportunity. This maximises the efficiency of the exchange 1, and ensures that the participants' requirements are met with optimum effectiveness.

Each transaction 12 is instantiated in the publish phase where the supplier, consumer and mediator roles 30,32,34 are assigned to members 10. The transaction 12 then enters the prospect phase where it is potentially elected for execution and its p,v (propensity, value) is evaluated with comparable transactions 12 to assign the order of execution. If the transaction 12 is elected then it is sent to the physical mediator to perform the execution. The mediator may be a kernel mediator (i.e. none rendering such as the software mediator in the exchange kernel) or an interface mediator responsible for rendering the transaction for the appropriate channel (Web, WAP, SMS etc.)

The Kobe exchange's architecture encompasses the entire spectrum of an electronic exchange, ranging from user interfaces 38 to the system via a number of channels including Internet, Intranet, and telephone, to hand-off mechanisms for transmitting completed transaction data to the various participants 24,26,28, again over a number of channels, such as Fax, e-mail, SMS, and print media. It accommodates the full dynamics of commercial transactions which are modelled in terms of the sub tasks of acquisition, publication, prospecting, execution and outcome and feedback reconciliation.

Transaction Participants

Transactions within Kobe occur between suppliers 24, consumers 28, and mediators 26. The roles of each participant 24,26,28 and their relevance to the transaction model are now described with reference to Figure 7.

Suppliers

A supplier 24 provides goods or services 70 to the exchange 1. These goods or services 70 are published on the exchange 1, by the supplier 24, in an attempt to invite potential transactions 12. For example, a supplier 24 may be a subscriber, such as Joe Bloggs Plumbers based in Oxford, who have published the details of their plumbing service 70 on the Kobe exchange 1.

In the present embodiment, suppliers 24 are modelled at the micro level. This entails collecting full details from the subscriber 24 when they complete a subscriber contract, and this information is entered into the exchange database. Suppliers 24 take part in transactions 12 at an explicit level, where they are named parties to the transaction 12.

Consumers

A consumer 28 is the recipient of the goods or service 70 provided by the supplier 24. The consumer 28 may request the goods or service 70 from the exchange 1 , or the exchange 1 may push the goods or service 70 to the consumer 28 based on a perceived interest, indicated by the high propensity of the prospective transaction 12. Continuing with the example set out above, a consumer 28 is a user who has called for details of say, plumbers based in Oxford.

A transactional history of the consumer's actions within the exchange can and is recorded, and therefore transactions can be optimised based on recorded consumer preferences. The exchange 1 encourages consumers 28 to identify themselves, thus increasing the opportunity to maximise the propensity p of prospective transactions 12 on the exchange 10.

Mediators

A mediator 26 brings together suppliers 24 and consumers 28 on the exchange 1.

A transaction 12 can be executed when the propensity p of each participant 24,26,28 accepting the terms of the other is maximised. One factor of this propensity p is the potential value v to each party of the completed transaction 36.

Categories of participants 24,26,28 represent collections with common characteristics. Categories may be sub-divided and a member 10 may belong to more than one category. A category may also play the role of a supplier 24, a consumer 28 or a mediator 26 in a transaction 22; this allows generic collections to be represented within a transaction 12 where a specific instance of a member 10 may not be appropriately employed or available.

Acquire, Publish, Prospect, Execute, Outcome The exchange's domain follows a five-stage transactional process 71 to bring users (consumers 24) and subscribers (suppliers 28) together via a mediator 26. The five stages are acquisition, publication at 72, prospecting at 74, execution at 76 and outcome. At the heart of this are the publication, prospecting and execution stages 72,74,76 that are shown schematically in Figure 7. However, the five-stage transactional process 71 is now described in detail with reference to Figure 8.

Before members 10 can become active on the exchange 1, they are acquired at 78, that is, attracted to participating in transactions 12 on the exchange 1. Much of the success of attracting members 10 to the exchange 1 will be the use of transactional data to prove its efficiency by targeting members 10 from the supplier 24, consumer 28 and mediator 26 categories. Typically, subscribers 24 are shown that their content, if published on the exchange 1, would receive interest and be involved in a sufficient number of completed transactions 36. Transactional data can illustrate performance in the appropriate content section, and models can even be established to plug prospective subscriber profiles into a simulated exchange to demonstrate expected performance levels. Such data increases sales efficiency in attracting new subscribers 24 to the exchange 10.

Although use of membership and associated reward schemes ensures greater repeat use of the exchange 1, users 28 must be attracted to the exchange 1 as a first step. Just as the acquisition function at 78 can employ transactional data to attract subscribers, so historical information can assist in marketing by attracting new users 28 to the exchange 1. Advertising campaigns can be assisted by transactional data to illustrate which demographic would be most appropriate to target for individual categories of content. This could refer to the average profile of a certain type or instance of media, such as a radio station's listeners or a newspaper's readers, for example.

Each participant prepares at 80 information regarding their capabilities and requirements for participating in transactions on the exchange 1. Typically, this information includes a transaction profile which may be in any suitable form such as a graph or a table of information. This information is then registered on the exchange 1 in order to take part in a transaction or transactions. The subsequent step of publishing at 72 allows protagonists, or participants on the exchange 1, to declare themselves available, and also offers the exchange 1 a view of their transaction profile, which is used in suggesting which transactions 12 they would most effectively take part in. It is the process of publication at 72 that accomplishes the capture of supply, demand and mediation information that facilitates the prospecting at 74 of transactions 12.

The transaction process then carries out a check at 82 to determine whether any member has requested a transaction 12. If not then the check at 82 continues until a transaction 12 is requested. The prospecting stage 74 of the transaction process 71 commences with a member 10 requesting at 82 a transaction 12. During the transaction process 71, a plurality of transactions 12 are created at 84 on behalf of a request by a user 28 or a subscriber 24, which are called prospective transactions 12. These are transactions 12 that may possibly be taken up by both parties 24,28. Each prospective transaction 12 has an associated propensity score p which indicates how strong the possibility of acceptance is. Propensity calculations can be simple or complex, and involve a number of different inputs from each participant (a user's requested service, a subscriber's location, etc.) and a calculation model which produces the score from these inputs. Propensity models are discussed further below. Transactions with a prohibitively low propensity score p are eliminated at 86.

At this stage of the transaction process 71, a further set of transactions 12 are eliminated at 88 based on their transaction value v. The value v of a transaction 12 is a function of the value to each participant 24,26,28 of the transaction 12, should it be completed. For example, a mid-call transfer of a user to a subscriber via an infomediary's connect service presents value to the consumer 28 in terms of savings on the cost of the phone call, the supplier 24 in terms of the value of the new customer, and to the mediator 26 in terms of the revenue received from the subscriber 24 for the transfer.

An arbitrary number of prospective transactions 12 with a suitably high propensity score p are then presented at 90 to the participant 24,26,28 that requested them, ordered by their potential value v.

The transaction requesting member 10, then selects at 92 a prospective transaction 12. Once a prospective transaction 12 has been selected, it is executed at 76 to completion. This can be the act of an infomediary's connect service call transfer as described in the example above, it can comprise sending the results of a search to a mobile phone caller using the SMS (Short Messaging Service), or can be as simple as reading out the results of a search over the phone. However it is completed at 76, an outcome is recorded at 94, and the transaction 12 is retired at 94. Just as the propensity model driving the transaction 12 directly affects its outcome, the outcome of the transaction 12 becomes part of an aggregation of transactional data that is fed back into the process 71 in order to refine it. This is discussed further below.

As indicated above, the transaction outcome is highly relevant as^* it assists in the prospecting process at a number of different levels. If the outcome of a transaction 12 is understood at the micro level, a user 28 can be targeted in the future with the benefit of feedback. Likewise, understanding the success of transactions 12 at a meta level can lead to optimisations on whole classification of content.

Transaction Value

Referring now to Figure 9, the value of a transaction 12 is an economic indicator that may be measured in three dimensions:

• Horizontal 100. This value represents how much a transaction 12 is worth to the supplier 24 and is largely determined by the supplier's classification. For example, a lead in one sector will often be worth more than a lead in another.

• Nertical 102. This dimension relates to take-up or coverage and represents the relative size of the potential market for the type of trade considered. Classification

(plumbers, mortgages) and sub-classification (mortgages/fixed) obviously play a major role. Customer characteristics such as location and external factors such as date and climate etc. also contribute significantly.

• Depth 104. This refers to number of value points of the transaction 12 within its classification. The most shallow of transaction 12 could be considered a lead, while the deepest, a full exchange of goods, or a signed contract. The classification of content will determine the granularity of the scale between the two poles. For example, transactions 12 involving lightweight products such as flowers may only have a depth of two value points - lead and exchange, whereas information intensive transactions 12 involving content such as mortgages may have depth of many more points - lead, demand requirements met, qualification, credit score, approval in principle, etc. All this implies that the modelling of transactions 12 of variable dimensions is facilitated by the Kobe exchange 10.

Propensity Models

Propensity models have been used previously within infomediary systems. However, these have been essentially hardwired models. For example, in these cases the user's propensity is driven largely by the location of the service requested, the subscriber's propensity is entirely economics-based, and the agent 26 has no impact on the propensity model whatsoever. In the present embodiment, the exchange 1 also looks to use this three-tier propensity model, combining probability scores based on the user 28, the subscriber 24, and the agent 26, but the inputs to the models are greater including inputs' from the mediator 26, and the propensity models themselves far more sophisticated.

Contrary to the known propensity models, the present embodiment does away with the notion that a user's propensity^ has to be driven entirely by location. More specifically, the propensity models of this embodiment take into account the value of other factors in the transaction 12. For example, clearly when searching for a hotel in a given location, proximity is important; however a user 28 may have more detailed requirements, such as a swimming pool, childcare facilities, an excellent reputation and so on. There will likely be many hotels in the requested area, and it is from there that the models begin, not end.

The exchange's propensity models are based on aggregated representations of transaction participants 10, or protagonists. Transactional behaviour can be studied, either in terms of rolled-up transactional data harvested from a data warehouse (macro-protagonist), or in terms of modelling a typical category member (meta-protagonist). These views of protagonist behaviour are employed in the establishment and refinement of propensity models offline. Micro-protagonist profiles can then be plugged into the models online, ensuring maximum value is gained from potential transactions 12. The use of the above propensity model enables the transactions to become intelligent. An intelligent transaction represents a potential transaction 12 with the ability to take a view on behalf of its members 10 in terms of its viability and likelihood. A trade between a supplier 24 and a customer 28 can describe whether the supplier 24 is able to proceed to the next step and how likely the step is to have a positive outcome (and vice-versa for the customer 28).

For a tangible example, consider a deep transaction being proposed between a supplier 24 publishing a mortgage offer and high-value customer 28 publishing demand for a mortgage product. The intelligence of the transaction 12 can be used to determine two things on behalf of the supplier 24:

• Viability. The supplier 24 may decide if the transaction 12 is viable based on the customer's income or credit rating.

• Probability. The probability that the supplier 24 may agree the transaction 12 could be based on a model predicting the customer's likely income and credit rating based on known information such as demographics.

This simplified example demonstrates the two functions of an intelligent transaction: to determine its viability, and, to establish the probability of a positive outcome. An intelligent transaction may exploit sophisticated services to assess viability and estimate outcome propensity.

Transaction Flows

To illustrate the transaction flows within the exchange 1, and the propensity/value model used to prioritise and execute transactions 12 as described above, three examples of relevant commercial scenarios are now described with reference to Figures 10a, 10b and 11. Transaction Prioritisation

Referring now to Figure 10a, a user 28 calls the infomediary call centre 26 at 11PM and requests a plumber. Using a keyword search, the telephonic agent registers the user's demand on the exchange 1. There are a plurality of suppliers 24 associated with the keyword 'plumber', and so several potential transactions 12 are created. ^'

The prioritisation of these potential transactions 12 involves use of the propensity model. Of the members 10 of the plumber category on the exchange 1, many are eliminated due to prohibitive distance from the user 28 as a first pass. However, as can be seen from the remaining suppliers 24 schematically shown in Figure 10a, the profile of the closest supplier 24,108 does not show 24-hour availability; the time of the call, which is a function of the propensity of the transaction 12, indicates that it has a very low propensity to execute, and is therefore eliminated 110. The next closest supplier 24,112 is available 24 hours a day as indicated by symbol 114. However, since the supplier 24 is not a subscriber as indicated by symbol 116, the propensity of the potential transaction 12 is low, and again is eliminated at 118.

The next two suppliers 24,120 and 24,122 are subscribers as indicated by symbol 116, both have good location synergy as indicated by symbol 124 and are available 24 hours a day as indicated by symbol 114, however only one of them subscribes to the Scoot Connect service as indicated by symbol 126. The potential transaction 12 of this supplier 24,122 has a higher value to each party, due to the revenue from a completed call transfer to the mediator 26, the cost saving to the user 24, and the value of the lead to the subscriber 24, and therefore has the highest propensity; it immediately assumes the highest priority, and is presented first at 128. The transaction 12 can then be settled. The high propensity of the transaction 12 and the associated value of a call transfer, coupled with the time of the call indicating an urgent requirement for fulfilment, would lead to a live transfer of this call.

Call Handoff

Referring now to Figure 10b, an example of a call handoff is described. The handoff mechanisms described below are modelled within the Kobe exchange 1 as interface mediators 26 - they effectively exist at the boundary of the exchange's functionality (the interface object space 18), but incoφorate properties which are used by the exchange 1 to determine possible transaction propensities p. For example, each interface mediator 26 has different characteristics such as the cost of the handoff mechanism and the depth of transaction which can be supported. This allows the exchange 1 to take into account properties of the handoff mechanism when choosing the transaction to execute.

A user 28 calls the infomediary's registered users telephone service using their mobile phone 130. The exchange 1 recognises the caller's number, and as a result the caller's member profile and transactional history become accessible. Once the agent 26 has found a suitable subscriber 24 that matches the user's requirements, the details of the transaction 12 need to be handed off to the user 28.

In this example, the transaction history available indicates that the user's preferred method of receiving readout information is via SMS 134, and this is therefore pushed as the most appropriate channel for the transaction handoff. Once the agent 26 confirms this with the user 28, the data is sent to their mobile phone 130 via SMS 134.

Although in this instance the user's past history indicated a high propensity for receiving SMS handoffs, a meta-model could also have been applied if no such history were available. A simple meta-model of a user calling from a mobile phone 130 would show a high propensity for SMS handoffs. This meta-model would be used in instances where transaction history was not available, for instance for a new user 28. As the user 28 enhances their profile through repeated activity on the exchange 1, the meta-model would be replaced with the user's own micro-model, allowing their actual preferences to be used in the propensity calculation.

The exchange 1 supports a number of channels 26 for transaction handoffs, including fax 132 for deep transactions 12 at a medium cost, SMS 134 for shallow transactions 12 at a low cost, e-mail 136 for deep transactions 12 at a low cost and a web handoff (not shown) for deep transactions 12 at a low cost. A telephonic call handoff is only suitable for shallow transactions because of its relatively high cost and low data capacity. Of these variety of handoff methods, the most appropriate is selected by the exchange 1 based on such considerations as the cost of the handoff method, the depth of the transaction 12 to be handled, and of the transaction channel 26.

Transaction Push

Referring now to Figure 11, an example of a transaction push from the exchange 1 is now described. A pre-registered user 138 visits the infomediary's website and logs on, using their membership details. The user 138 requests details of the nearest hotel to the conference hall where they will be attending a two-day seminar. The web agent 140 at the website performs the search on the user's behalf using the exchange 1, and finds a number of hotels in the area where the user 138 will be staying.

The user 138 has previously signed up to the infomediary's cinema listing service, and over some months usage has enriched their profile with details on the sort of films they generally like. The web agent 140 does a secondary search using the exchange 1, finding the nearest cinema to the requested location, and retrieves the list of films 142 currently showing there.

The user's transactional history shows that the user is an admirer of Stanley Kubrick and David Cronenberg, so the films 'Eyes Wide Shut' and 'eXistenZ' both assume a high propensity. However, the user has also previously enjoyed the films 'Trainspotting' and 'Face', both featuring the actor Robert Carlyle, who also stars in the film 'Ravenous'. 'Ravenous' is also made by Antonia Bird, the director of 'Face'. Of the available films, this receives the highest propensity. The details of the hotel, the cinema, and the performances of 'Ravenous' 144 are then presented to the user 138, who can drill down for more detail on each, perhaps to review what else is showing, or to see a review of 'Ravenous'.

This example also demonstrates how some channels are more appropriate for transactions than others. The phonic channel is unlikely to be as applicable in this instance as the Web as its cost may render it prohibitive for this kind of dialog. The propensity model in the prospecting phase would incoφorate this factor.

Transaction Modelling To further illustrate how the present invention can be used, the following with reference to Figures 12 to 16, provides a simple example of a transaction model involving an event service, which is implemented on the exchange 1. The service seeks to match supplier events from the cinema, theatre, and music categories with consumer preferences. In this example, the model is implemented over the Internet. The notation used through the example is that which has been described previously.

Referring more specifically to Figures 12 and 13, several meta members (categories) 150 and their respective relationships 152 are shown. Leaf members (not shown) hang off the outermost boxes (excluding the incomplete graphs). These are the actual users 28 of the service, the web sessions involved and the event members in the cinema, theatre and music categories.

In the present example, the following transactions and relationships involved in the model are considered:

TxEvent (mmEvent, mmUser/m, mmWeb/m) 154 - the primary event transaction involving the meta member, mmEvent 156 as supplier 24, the known user of the service, mmUser/m 158, as consumer 28 and the current web session, mmWeb/m 160, as mediator 26. This transaction 12 will execute when a user 28 enters into the event service.

TxLocationEvent (mmEvent/mmLocationEvent, mmUser/m, mmWeb/m) 162 - the event transaction involving the meta member, mmLocationEvent 164 as supplier 24, the known user of the service, mmUser/m 158 and mmWeb/m 160. This transaction 12 will execute when the event service in a given location is entered into by a user 28. TxCinemaEvent (mmEvent/mmLocationEvent/mmCommercialEvent/mmCinemaEvent, mmUser/m, mmWeb/m) 166 etc. (namely TxTheatreEvent 168 and TxMusicEvent 170) - the event transactions 12 involving the meta members 150 for the different commercial events on the service.

The Domain Model

The basic domain model extract that is considered is:

TxLocationEvent observes TxEvent, outcome=LOCATIONSELECT instantiate TxLocationEvent supplier = mmEvent/mmLocationEvent consumer = mmUser/m mediator = mmWeb/m execute elicit the event type(s) selected

TxCinemaEvent observes TxEvent, outcome=CINEMASELECT instantiate TxEventCinemaEvent supplier = mmEvent/mmLocationEvent/mmCinemaEvent consumer = mmUser/m mediator = mm Web/m observes TxEvent, outcome=CINEMASELECT

observes TxLocationEvent, outcome=CINEMASELECT instantiate TxEventCinemaEvent supplier = mmEvent/mmLocationEvent/mmCinemaEvent consumer = mmUser/m mediator = mm Web/m execute elicit the cinema criteria

The model assumes that the transaction 12 observes/instantiates arrangements dictate the potential Tx paths through the model. This works as follows:

For each Tx outcome, certain criteria must be satisfied. These criteria represent tests on fields between the supplier 26, consumer 28 and mediator 26. So for TxEvent 154 to have an outcome of LOCATIONSELECT, the location field 172 will need to be satisfied. This will allow TxLocationEvent 162 to instantiate and be prospected as the next best transaction 12. Similarly for TxEvent 154 to have an outcome of CINEMASELECT, the event type field 174 will need to be satisfied. This will allow TxCinemaEvent 166 to instantiate and be prospected as the next best transaction 12. As usual the best transaction tier (summation across the one or more Txs will determine which possible transactions 12 are executed next). The p,v models are used in this calculation.

The probability of an outcome for Tx is calculated as:

Tx(outcome) .probability = likelihood of achieving the outcome

The value of a Tx is calculated as:

Tx(outcome). value = Tx(cost/value of achieving the outcome) + the summation of the p,v calculations from all sub transactions 12 that may execute from this outcome.

This information gives a Tx the ability to know which criteria is best evaluated or which fields are best elicited.

The above framework works as transactions 12 can be prospected given that the criteria for their creation are met. Prospecting the transactions 12 may take place in the absence of the appropriate fields. In this case, the meta member role in the transaction 12 may provide a proxy or in its absence a neutral input would be used. Implementation Considerations

As described above, the value v model for the transaction TxCinemaEvent 166 includes a rollup of the projected probability/value (p,v) calculations for all the potential cinema member, user member and web member transactions 22:

Tx( mmEvent/mmLocationEvent/mmCinemaEvent/mFilml, mmUser/m, mm Web/m ) Tx( mmEvent/mmLocationEvent/mmCinemaEvent/mFilm2, mmUser/m, mm Web/m ) Tx( mmEvent/mmLocationEvent/mmCinemaEvent/mFilm3, mmUser/m, mm Web/m )

If it is impractical to perform this rollup in real time and in this event it is possible to use the meta member mmEvent/mmLocationEvent/mmCinemaEvent 156,164,176 in a value calculation instead. This means that a model can exploit distributions derived from the meta membership. For example, a user member profile can be modelled against the categories of film 178 comprised by the meta member 156,164,176. If a user 28 is observed to prefer action movies, the propensity of the value proxy model will be better where the meta member 156,164,176 shows a larger number of action films. The maintenance of the distributions is a low overhead as they will only change when the membership changes.

The use of meta member proxies also allows the scaled deployment of increasingly sophisticated p,v models as the transactional database grows and the analytical activity yields results.

Additional Implications

The publish, prospect, and execute transactional process pattern can also be exploited to link different transactional models that share a common exchange. Allowing transactions in one market space to observe the outcomes of those in another does this and provides the capability for pushing synergistic content. For example, when a mortgage transaction takes place, a potential buildings insurance transaction might observe this and publish itself in the same transaction space.

Examples of event service push flows at a generic level are set out in Figures 14 and 15. More specifically, the process of pushing an event service commences with the transaction TxListenForEventlnterest 180 continually observing publications of outcomes and requests on the exchange 1. Once a transaction relating to event goes has been observer at 182, a transaction TxdisplayEventNotification 184 is triggered. TxdisplayEventNotification 184 describes the service to the user 28 associated with the observed transaction and asks the user if they wish to register. If the consumer/user 28 is not interested the process of pushing an event service ends. Otherwise the consumer 28 is interested at 186 and a transaction event TxIdentifyConsumer 188 is activated. TxIdentifyConsumer 188 checks to see if the consumer 28 is recognised at 190 as a previously registered user. If the consumer is recognised at 190 as such, then the transaction event TxEventDetails 192 is triggered for collecting the details of the consumer's event preferences. If however, the consumer is not recognised at 194 as having been previously registered then transaction event TxRegisterConsumer 196 is triggered. TxRegisterConsumer 196 finds or creates a registered consumer using information input by the consumer 28 on request. On completing of this task, the consumer 28 is registered at 198 and is then taken to the TxEventDetails 192 transaction event for collecting details of the consumer's event preferences.

Once information concerning the consumer's event preferences has been collected by TxEventDetails 192, this information is submitted at 200 to a transaction event TxCreateEventProfile 202. Here an event demand profile is created for the consumer from the received event preference information. This profile is then posted at 204 and the transaction event TxEventProfileConfirmation 206 is activated. The transaction event TxEventProfileConfirmation 206 confirms the service to the consumer 28 and informs them of the next posting of information relevant to their preferences that will be sent (pushed) to them. The effect of implementing the above procedure is to create a registered user's event demand profile. This profile is then used as a filer when at the appropriate time there is information available to send out to registered consumers 28. More specifically, referring

5 to Figure 15, a transaction event TxNextEventMailing 208 is executed on the occurrence of a calendar event, say at the end of each month. This then triggers the next mailing at 21 to occur. The content of the next mailing, for a registered consumer 28, is determined and created by a transaction event TxCreateEventNotification 212. Here the customer profile is matched with new event information that has become available and if there is a match 0 of event requirements with available events or even a match with an event related to something in the customer's event demand profile, then an event notification is created. Subsequently, the notification is posted at 214, 216 to an event transaction TxEventBundle 218. More specifically, a direct match is posed at 214 to the consumer 28 by a transaction event TxPostEventNotification 220 and a related information match is 5 posted at 216 to a transaction event TxRelatedContent 222 which pushes the related information to the consumer 28.

Examples of event service requests (pull) flows at a generic level are set out in Figures 16, 17 and 18 in a similar manner to that of Figures 14 and 15.

Figure 16 illustrates event service request flows in the example of a transaction model shown in Figure 12. As with Figures 14 and 15, the rounded boxes represent interface transactions 12 whereas the cornered boxes represent kernel transactions 12. The Tx What Where transaction 230 is the initial transaction 12 executed by an interface 5 mediator 26 to elicit the classification (what) - TxGuessClassification 232 and proximity (where) - TxGuessLocation 234 of the request. The initial time period is defaulted to the day of the request by the TxGuessTimeperiod 236.

Figure 17 shows how the guess classification transaction 232, time period transaction 236 0 and the location transaction 234 are each refined. Once the initial request is made the results are collated and displayed. They may be refined, related or changed to modify the search. Figure 17 is largely self explanatory and so is not described in further detail.

Figure 18 shows the event service request flows involved in presenting results to a customer which result from one of the transactions shown in Figure 17. This figure shows the subsequent transactions 12 that may result from the initial request in terms of the consumer selecting a presented event and ultimately booking. All transactions 12 follow the above-described Publish Prospect Execute pattern. Again, Figure 18 is largely self explanatory and so is not described in further detail.

The above described embodiment of the present invention is also capable of implementing proximity catchments in the phases of publication 72 and prospecting 74 of transactions 12 as is described below.

Transactions 12 on the Kobe exchange 1 follow the publish, prospect and execute transaction process pattern described previously. Proximity properties can be used in a transaction (Tx) 12 on the Kobe exchange 1 in two ways, namely in the publication phase 72 or in the prospecting phase 74:

1) In the publication phase 72 of the transaction process 71.

This is where a hard catchment boundary is applied to the search requirements of a potential transaction 12. For example, if the location must be in the London area then potential transactions 12 in other localities are excluded.

2) In the prospecting phase 74 of the transaction process 71.

Here proximity weightings are incoφorated to understand the probability and/or value of a given transaction outcome.

In both instances the attributes of location and mobility provide the inputs which can be incoφorated into search filters or probability models. These inputs may be described as the catchment associated with the member 10 in a potential transaction 12. A catchment is stored in a relational database as a polygon containing a collection of geo-spatial coordinates. These co-ordinates are attached weights for propensity puφoses.

The situation can be modelled using the previously described notation: Tx( mmSupplier/m, mmConsumer/m, mmMediator/m ) Where mmMember/m represents a member 10 of a given category (meta member).

The catchment feature of the present embodiment is now described with reference to three examples.

Example 1 - The Visiting Plumber

Referring now to Figure 19, consider a plumber service to the domestic emergency of a house dweller. This transaction 12 might be expressed as: TxPlumberCallout( mmPlumber/m, mmResident/m, mmPhone/m )

The positive outcome of such a transaction 12 tends to yield a visit from the plumber (supplier 28) to the resident (consumer 24). For the consumer 24, their catchment 300 is simply their house number and postcode - the consumer 24 has no choice as to where his pipe burst. For the supplier 28 - their catchment 302 covers the call out area that the plumber is prepared to service. In the present case, this catchment 302 is non-uniform, namely, there are preferred areas 304 within it which can be given a higher weighting.

These can be used in the rules for the publication phase 72 of the transaction process 71 : TxPlumberCallout( mmPlumber/m, mmResident/m, mmPhone/m )

Publish those transactions 12 for each supplier 28 owning a catchment 302 that contains the consumer catchment 300.

And, for the prospecting phase 74 of the transaction process 71 : TxPlumberCallout( mmPlumber/m, mmResident/m, mmPhone/m )

The prospect propensity value p,v is bigger the more serviceable the consumer catchment 300 is within the supplier catchment 302. So in this example, the consumer catchment 300 is within the supplier catchment 302 but is also within the preferred area 304 of Hackney, which means that it has a higher p,v value than if it were in the supplier catchment 302 but not within a preferred area 304.

Example 2 - The Cinema Event Seeker Referring now to Figure 20, consider a socialite (consumer 28) wishing to attend a cinema event. This transaction 12 might be expressed as:

TxCinemaVisit( mmCinemaEvent/m, mmSocialite/m, mmPhone/m )

The positive outcome of such a transaction 12 tends to yield a visit from the socialite 28 to the cinema event. This time it is for the supplier 24 (cinema) that its catchment 306 is simply the event's venue - cinemas tend not to be mobile. For the socialite 28, their catchment 308 covers the area that they are prepared to visit. Again, this catchment 308 is non-uniform in this example, namely there is at least one preferred area 31 within it.

These can be used in the rules for publication:

TxCinemaVisit( mmCinemaEvent/m, mmSocialite/m, mmPhone/m )

Publish those transactions 12 for each supplier 24 owning a catchment 306 that is contained within the consumer's catchment 308.

And, for prospecting:

TxCinemaNisit( mmCinemaEvent/m, mmSocialite/m, mmPhone/m )

The prospect propensity value p,v increases with increasing accessibility of the supplier catchment 308 within the consumer catchment 306. So in this example, the supplier catchment 306 is within the consumer catchment 308 but is not within the preferred area 31 of the region of Leicester Square tube station 312, which means that it has a lower p,v value than if it were in the consumer catchment 306 and within the preferred area 31, namely closer to the tube station 312.

Example 3 - The Dating Parties

Referring now to Figure 21, consider a first party (consumer 28) wishing to find a date with another party (supplier 24). This transaction 12 might be expressed as: TxMakeDate( mmFirstParty/m, mmSecondParty/m, mmPhone/m )

The positive outcome of such a transaction 12 tends to yield a date between the parties 24,28. The respective catchments 320,322 of the first and second parties 28,24 contain locations 324 to which they will be likely to travel to execute the date. These locations 324 are both non-uniformly preferred, having different p,v values and are also scattered within the catchments 320,322.

The catchments 320,322 can be used in the rules for publication:

TxMakeDate( mmFirstParty/m, mmSecondParty/m, mmPhone/m )

Publish those transactions 12 for each supplier's catchment 322 that intercepts the consumer's catchment 320.

And, for prospecting:

TxMakeDate( mmParty/m, mmParty/m, mmPhone/m )

The prospect propensity value p,v increases with an increasing number of catchment interceptions between the supplier and consumer. A consumer proximity indicator is a summation of all of the propensities of the consumer locations 324 which are common with those of the supplier locations 324. In the present example, this is the locations of ECl, EC2 and EC3. Likewise, a supplier proximity indicator is a summation of all of the propensities of the supplier locations 324 which are common with those of the consumer locations 324. A total compound proximity indicator is a combination of both the consumer proximity and the supplier proximity and these indicators are useful in implementing modelling.

Strategy Implications

An obvious implication of this strategy relates to the articulation of catchments 300,302,306,308,320,322. A catchment may be captured when the supply or demand associated with a type of transaction 12 is published at 72 and using the appropriate automated interface. The plumber in the above first example will be asked to 'sketch' his catchment 302 on a map. The boundary of the catchment 300,302,306,308,320,322 represents the publication criteria described above, while the hue of the shading used (see Figure 20 in particular) is used to describe the preferred regions 304,31 used in the prospecting models. This mechanism provides a versatile and effective means to capture quantitative information.

Similarly, on the demand side, a consumer 28 might simply enter a location and a predefined, default, catchment could be designated. This default catchment may be derived from the both the supplier 24 and consumer 28 categories as is described below with relation to proxies. It may be further stretched and shaded according to the consumer's preference.

Once the proximity attributes are captured, searches can be performed using geo-spatial technology that is now available in today's relational databases.

Proxies

As with other absent attributes, geo-spatial requirements can be substituted by proxies for the piupose of prospecting at 74. For example (using the second above described example):

TxCinemaNisit( mmCinemaEvent/m, mmSocialite/m, mmPhone/m ) If the socialite 28 has not provided their demand proximity requirements for this transaction 12 to be prospected, then their known location, and possibly other attributes like mobility, can be used to construct a default catchment from the role of the socialite meta member 16,48 in the transaction 12 involving cinema events.

This default is incoφorated within the transaction 12 as it is derived from properties of the consumer member (mmSocialite/m) and is shaped by the supplier meta member (mmCinemaEvent 150). In this instance, the catchment 306 relies on the ground density of the category's members reflecting the fact that consumers 28 will be prepared to travel further for some types of transactions 12 than others. The transportation mode also provides an additional input in determining the default catchment.

Finally, it is obvious that geo-spatial attributes are irrelevant in transactions 12 involving some forms of content such as Internet events. This is why the publication rules and prospecting models only incoφorate characteristics relevant to the type of transactions being modelled.

Mediators and Proximity

The mediator member has not been mentioned with respect to proximity. However, if a sales process is modelled then the geo-spatial attributes of the mediator 26 will also be relevant and a catchment of a salesman acting as a mediator 26 should be included in the publication 72 and prospecting 74 phases of such transactions 12.

Classification Grouping In the Kobe exchange 1 the structure of classifications is network based, defining the relationship between groups. The Kobe exchange 1 provides the facility to construct classification groups, although it must be stressed that once created, the groups remain in existence for historical reporting puφoses. The Kobe exchange 1 contains a profile of classifications of the business with weightings to gauge the relevance of the classification to the business. For example a garage may sell flowers but its flower selling classification would not be weighted as high as selling petrol, or as high as selling flowers for a florist.

The classification names can be used as keywords for searching or identifying products and services. The relevance of the product or service can be determined by the weighting.

In a content capture phase, a document may be scanned using these keywords to identify document content and website content. This helps to automate the classification process.

Transaction Content

The transactions 12 supported by the exchange 1 are a flexible way to define business rules allowing rapid construction for new business avenues and updating existing ones.

A transaction 12 utilises the content defined in the exchange 1. Each role 30,32,34 within the transaction 12 is modelled within the content. As mentioned earlier, the content may be either an actual instance of a domain or metadata. The roles 30,32,34 within a transaction 12 are viewed as being either members 10 or meta members 16,48,150.

Meta members

Referring to Figure 22, it is important to appreciate the difference between meta members 16,48,150 and meta-content 330. The meta-content 330 describes the classification and relationship between the members 332 and the properties of those members 332, whereas the meta member 16,48,150 describes the most likely behaviour and properties of a member 332. A meta member 16,48,150 will also be described by meta-content 330.

The meta member 16,48,150 is viewed as the parent of members 332, since a member

332 with properties not populated with values inherits the most probable values from the meta member 16,48,150. Also behaviour is inherited from the meta member 16,48,150. A meta member 16,48,150 may also be considered as a child of another meta member 16,48,150, inheriting the most probable values and behaviour not currently defined.

Channel Content In the Kobe exchange 1, a channel's definition is viewed as content and also plays a role within the transaction process 71. The channel definition provides the exchange 1 with both presentational information about the transaction 12 and processing information for the transaction 12.

For example, an e-mail channel is not interactive and its response is relatively slow compared to a web channel which is interactive. The way information is presented in an e-mail needs to be read-only whereas information on a web channel may be read-write.

The channel definition is not the only method of information transfer. Differing channels may have the same method of transfer, but require different presentations. Therefore a channel is better viewed as a mediator 26.

Consumer Content

The consumer role 34 in a transaction 12 defines the type of consumer 28 and references consumer content.

Although the consumer 28 may remain anonymous in some transactions 12, the goal is to build a profile of a consumer 28 to provide a better service for them. It is therefore important to understand who is using the exchange 1, to improve the matching of their requirements and needs. It is therefore preferably to encourage consumers 28 to register on the exchange 1, and provide a means for them to identify themselves in all subsequent transactions 12. The exchange's transactional recording capabilities then log all behavioural data, allowing consumer profiles to influence future transactions 12.

The meta member 16,48,150 plays an important role in deciding the consumer's requirements. Unlike the channel role 32 and the supplier role 30, the consumer role 34 may not enter a transaction 12 fully populated with the values required of the consumer 28. Therefore, to help decide the value of the transaction 12 to the consumer 28, the meta member 16,48,150 of the consumer 28 is used to substitute unknown values. As the consumers 28 provide more information the profile of the consumer 28 represents the individual more than the generalised group, this has previously been referred to as moφhing. Moφhing makes the products and services presented to the consumer 28 more personal and closer to their individual needs.

To capture this personal profile, the consumer 28 needs to be identified and become a member 10 of the exchange 1. The consumer 28 is then an individual member 10 of the Kobe exchange service rather than an anonymous statistic.

Supplier Content

The supplier role 30 in a Kobe transaction references the content for the supplier 24. The supplier role 30 is not the supplier 24 itself but rather a service or product the supplier 24 provides to the exchange 1. This role 30 may be as simple as providing the identity details of the supplier 24.

Channels

As has been described previously, the exchange 1 supports the mediation of supply and demand through channels. The types of channel that are supported in the present embodiment are now described in relation to their delivery characteristics and to the way in which a mediator 26 is modelled so it can be evaluated in terms of a transaction 12.

Channel Design The running of the Kobe exchange 1 involves the publishing of content and performing of transactions 12 through a variety of different mediums (channels). Although these channels may be inherently different i.e. internet, print, fax etc. the design of the exchange 1 provides a generic framework for presenting content and executing transactions 12 across all of these. A channel is modelled on the exchange 1 as a mediator 26 and its attributes can be accessed in any transactional model exploited by the exchange 10.

This section outlines a design for a generic channel framework and emphasises how this can be implemented to support business models.

Channel Framework

Referring now to Figure 23, the channel framework 340 can be thought of as an extensible set of interfaces 342, each of which is associated with a particular channel, internet, fax etc. Each interface 342 provides the appropriate data formatting for the channel that it is associated with. These interfaces 342 depending on the medium support uni-directional data exchanges 344 and/or bi-directional data exchanges 346, e.g. print or internet channels, and are not considered as rendering engines.

As shown in Figure 23, the following channels are provided in the present embodiment.

• Internet

• Telephonic (Fixed and Mobile Phone)

• Short Messaging Service • Electronic Mail

• Fax

• Print

• Digital/Interactive Television (not shown)

The full implementation of the channel framework 340 provides interfaces 342 for all of the above which are easily extendable. Furthermore, the characteristics of these channels are also modelled with respect to transaction effectiveness and value. In this way propensity and value models in the kernel transaction space 4 can incoφorate attributes of the mediator 26 to improve the efficiency of the exchange 1. An important feature of the exchange 1 is its ability to model multi-modal transactions 12, or commercial trades, that span many channels. A web enquiry may progress to a phonic call, to an SMS message, to an e-mail, and to a printed conformation - all within the same unit of commerce. The truly channel neutral aspects of the approach not only add to the power and versatility of the exchange 1 but also offer significant opportunities to reduce transaction cost.

Channel Support - Delivery

The vertical framework of the present embodiment has been designed to exploit XML as the standard format 348 for internal data exchange. However, the external target data format 350 is dependent on the type of channel. It is therefore the responsibility of the channel framework 340 to provide the mapping of this presentation neutral data format 348 into the various formats 350 for delivery. The XML data format 348 itself facilitates this transformation, as it is self-describing. XML tags along with metadata and XML Style Sheets (XSL) can be used to identify how the content is to be rendered depending on the terminating device of the user 28 or subscriber 24. The following sections describe each channel and the details of its delivery mechanisms.

Internet

Referring now to Figure 24, an internet channel 354 comprises a web server 356, delivery agents 358 and the exchange's database 360. The web server 356 receives an html query 362 from a browser 364. The web server 356 subsequently converts the received query into an RMI format 366 (Remote Method Invocation - a standard way for Java objects residing on different machines to communicate) and forwards it onto the delivery agents 358. Next an XML request 368 is formatted and sent to the database 360. From here the transaction .12 based on the query 362 is processed and an XML response 370 is returned to the delivery agents 358. The response is converted at the delivery agent 358 into an RMI format 372 and sent to the web server 356. Here it is converted into an html response 374 and sent to the browser 364.

Due to its cost and ubiquity, the Internet is exploited as a major channel in implementing the exchange 1 of the present invention. The Internet channel 354 is utilised for all internal and external visual applications within the exchange 1 as well as being a direct point of contact to the user 28. The Internet is not just confined to the PC user base, rather it is expanding across a wide range of hand held devices, such as mobile phones and palm tops. This leads to the Internet channel 354 becoming increasing important particularly with respect providing utilities for sales staff. Although it is the most important of the channels, from a technical point of view it is fairly easy to support.

Telephonic

Even though Internet usage is continually expanding, the call centre's role remains an important aspect of most active exchanges. Support of this channel, call control administrative services and agent management, is achieved by a system (not shown) controlling CTI technology (Computer Telephony Integration - known technology to integrate phone activity with computer behaviour) though the Java Telephone API, or JTAPI.

JTAPI can support a wide range of communication protocols. It uses the (Java) Media Services package to provide applications access to the media streams associated with a telephone call. Applications are able to read and write data from these media streams. The following services are also provided in the Java. telephony.media package:

• DTMF (touch-tone) and non-DTMF tone detection and generations

• fax processing

• recording and playback

• text to speech

• automatic speech recognition

Voice calls to the call centre are recorded digitally for legal puφoses. Java-based telephony can also help to increase efficiency in the call centre. By integrating the Java Speech API's text-to-speech capabilities into the system, agents 26 can hand off to the system to read out the results of a user's query, and be free to handle another call. As speech recognition technology advances, the query part of the call process can also be replaced with an automated system, thus removing the need for a call centre altogether.

Short Messaging Service Referring now to Figure 25, an interactive Short Messaging Service (SMS) supporting services such as White Pages Lookup, and refinable queries is facilitated by an SMS channel 380 of the exchange 1.

The SMS channel 380 comprises delivery agent 382, the database 360 and a mobile telephone operator's exchange 384. The delivery agent 382 receives an SMS query 386 from a user 28. The delivery agent 382 subsequently converts the received query 386 into an XML request 388 and sends this to the database 360. From here the transaction 12 based on the query 386 is processed and an XML response 390 is returned to the delivery agents 382. The response is converted at the delivery agent 382 into X.25 data packets 392 and transmitted over a dedicated leased line to the mobile telephone operator's exchange 386. Here it is converted into an SMS response 394 and sent to the corresponding mobile telephone number of the user 28.

The SMS channel 380 can also be used to support two-way pagers. These devices work in a similar manner to conventional pagers, with the additional ability to send acknowledgement and simple interactive services.

Fax

Figure 26 shows a fax channel 400 of the exchange 1. It is used to support back office operations (settlement of invoices etc.) and is an important mechanism for data exchange.

The fax channel 400 comprises a call centre agent 402, delivery agent 404, and the exchange database 360. The call centre agent 402 receives a telephonic query 406 from a user 28. This is then processed by the agent 402 converting the telephonic query into a digitised look up signal 408 which is passed onto the delivery agent 404 via an intranet server 41 of the delivery agent 404. The delivery agent 404 receives the lookup signal 408 and subsequently converts it into an XML request 412. The XML request 412 is then sent to the database 360. From here the transaction 12 based on the query 406 is processed and an XML response 414 is returned to the delivery agents 382. The response is converted at the delivery agent 382 into fax transmission format and transmitted 416 to the telecommunications public branch exchange via a fax server 418 which queues and transmits requested faxes. The response signal is routed to the user's fax machine 420 via the exchange and is printed out for the user 28.

The fax channel 400 can also be coupled to the query generating parts of other channels. For example, a users 28 generating a query via the internet channel 354 may specify that they require the response via the fax channel 400, namely the infomediary's web site may have an option to send a fax to a subscriber 28 from the query results page.

Fax processing is included as one of the objects in the above mentioned Media Services package and telephonic subsystems handle fax calls in an identical way to voice calls.

Telephony over IP can be another way to send the faxes. Outgoing faxes are e-mailed or sent via FTP (file Transfer Protocol) to a fax service provider, which in turn transmits them to destination fax machines.

Print

Printed material, such as letters, pamphlets and bills, will always remain an important method of communication despite the rapid growth of the Internet. The exchange supports the required interfaces for third party print bureaux. It is the responsibility of the print bureau to perform composition and printing.

The print interface 342 simply deals with the preliminary conversion of the XML data, by use of specific print XML Style sheets, into the bureau's proprietary print format, and the delivery of this content via transport methods such as HTTP or FTP. Channel Support - Modelling

In the Kobe exchange 1, channels are modelled as mediator members 26 of the exchange 1. A mediator 26 is the content representation of the delivery channel and contains the parameters that influence the value and propensity proposition of a transaction 12. As with other content such as suppliers 24 and consumers 28, the exchange 1 expects the mediator members 26 along with the roles 32, relationships and transactions 12 they participate in to be modelled in XML. This representation allows a mediator's attributes to be accessed by the various models that undeφin the exchange 1 and provide the means for selecting one channel over another. Mediators 26 also have the ability to execute transactional steps 72,74,76 by invoking the appropriate delivery channel which is responsible for performing the appropriate activities on behalf of the suppliers 24 and consumers 28 in a transaction 12. The exchange's symmetry also allows meta members 16,48,150 representing collections or aggregations of mediators 26 to be exploited and in this way channels can be organised in groups such as tele-agents of a given skill set, a sales force associated with an office, etc.

The modelling of mediators 26 also has implications with respect to the administration of the channels. It is necessary for the logical attributes of the mediators 26 to be maintained at a micro or meta level which means that the appropriate tools need to be constructed.

Channel Modelling Extensions

The exchange 1 supports the ability to model and exploit channels and mediators 26 associated with the boundaries of the exchange 1. The transactions 12 undertaken by sales agents, supplier acquisition for example, are optimised by modelling these activities on the exchange 1. Similarly marketing devices such as adverts can also be considered interface channels and their effectiveness tracked against the transactions they yield. Other mediators that may be represented on the exchange 1 are external services supporting credit checking and data augmentation. Again these can be modelled and the value of their contribution to potential transactions would assist in improving the efficiency of the exchange 1. In all potential examples it is the exchange's ability to facilitate the modelling of channels as active participants in transactions 12 that provides great opportunities for exploiting the exchange 10.

Having described a particular preferred embodiment of the present invention, it is to be appreciated that the embodiment in question is exemplary only and that variations and modifications such as will occur to those possessed of the appropriate knowledge and skills may be made without departure from the spirit and scope of the invention as set forth in the appended claims.

Claims

Claims:

1. A distributed transaction exchange for supporting a mediated transaction between a supplier and a customer, the exchange comprising: a plurality of exchange members and meta members, wherein: each member and meta member is arranged to perform a processing function, to play any of the roles of a supplier, a customer or a mediator, and to publish its demand, supply and mediation capabilities for consideration and use by the exchange; and each meta member is related to a group of exchange members or meta members and is arranged to describe the attributes of that group; the exchange being arranged to construct the mediated transaction between the supplier and the customer from members and meta members selected on the basis of their published capabilities.

2. A distributed transaction exchange according to Claim 1 , wherein each member or meta member is arranged to publish its potential value to the mediated transaction, such that the value can be considered in the selection of members and meta members for the construction of the mediated transaction.

3. A distributed transaction exchange according to Claim 1 or 2, wherein each of the plurality of members and meta members is arranged to return a discreet outcome from its particular processing function.

4. A distributed transaction exchange according to any preceding claim, wherein each of the members and meta members is arranged to publish information regarding the likelihood of success of performing its particular processing function.

5. A distributed transaction exchange according to any preceding claim, wherein the exchange is arranged to consider the published information to determine possible combinations of members and meta members suitable for supporting the mediated transaction.

6. A distributed transaction exchange according to Claim 5, wherein the exchange is arranged to select the most suitable combination of members and meta members for supporting the mediation on the basis of the published information.

7. A distributed transaction exchange according to any preceding claim, wherein the exchange is arranged to execute the transaction process across the selected members and meta members and return a discreet outcome of the overall transaction.

8. A distributed transaction exchange according to Claim 7, wherein the exchange is arranged to sense the occurrence of the discreet outcome and to trigger the publication of information concerning related agents on the basis of the outcome.

9. A distributed transaction exchange according to any preceding claim, wherein the exchange is arranged to substitute information of a specific field from a given meta member into an associated meta member when there is no usable information pertaining to the specific field in the associated meta member.

10. A distributed transaction exchange according to any preceding claim, wherein the meta member contains link information associating it to other related meta members.

11. A distributed transaction exchange according to Claim 10, wherein the link information is related to other meta members in a hierarchical manner.

12. A distributed transaction exchange according to Claim 10 or 11 as dependant from Claim 9, wherein the link information is used for effecting the substitution.

13. A distributed transaction exchange according to any preceding claim, wherein the meta member comprises a concrete meta member, the concrete meta member being constructed from a complete list of members of the group of related exchange members or meta members.

14. A distributed transaction exchange according to any of Claims 1 to 12, wherein the meta member comprises an abstract meta member, the abstract meta member showing the characteristics of the group of related exchange members or meta members without having access to all of the individual members or meta members of the group.

15. A distributed transaction exchange according to any preceding claim, wherein each meta member is arranged to store information regarding its related members or meta members as a distribution.

16. A distributed transaction exchange according to any preceding claim, wherein each meta member is arranged to publish its demand and supply capabilities as respective demand and supply profiles.

17. A distributed transaction exchange according to any preceding claim, wherein each member or meta member is arranged to receive up-dated information regarding at least one of its related members or meta members and to change the characteristics of its function in response to the change of its member's or meta member's information.

18. A distributed transaction exchange according to any preceding claim, wherein each meta member has a generic data object construct, the construct enabling either an instance value or a distribution to be represented by the meta member.

19. A distributed transaction exchange according to any preceding claim, wherein the exchange is arranged to implement a multiple channel structure whereby at least one of the plurality of exchange members and meta members is arranged to participate in a plurality of transactions or parts of transactions, simultaneously.

20. A distributed transaction exchange according to any preceding claim, wherein the exchange is implemented over a wide area network, such as the Internet.

21. A distributed exchange for executing a transaction between a supplier and a customer via a mediator, the exchange comprising a plurality of members which are arranged to take the role of the mediator and, wherein at least one of the members comprises a meta member, each meta member comprising a collection of information representing the features of a group of related members that are able to participate in mediation of the transaction supported by the exchange, such that any member of that group can be modelled by the meta member.

22. A method of implementing a transaction using a distributed exchange, the exchange having a plurality of transaction members and respectively related meta members containing groups of members, each member and meta member being capable of performing a processing function and of playing the role of a customer, a supplier or a mediator, the method comprising: publishing full details of the demand, supply or mediation capabilities of each member or, if a member's full details are not available, publishing full details of the demand, supply or mediation capabilities of a related meta member; prospecting the published demand, supply or mediation capabilities; and executing the transaction based on a selection of members' or meta member's processing functions which when combined enable the transaction to be completed from the supplier to the customer via the mediator.

23. A method according to Claim 22, wherein the publishing step comprises publishing a demand profile of a member or meta member setting out requirements for its processing functions and/or a supply profile of the member or meta member setting out the availability of the processing functions it can provide.

24. A method according to Claim 22 or 23, wherein the publishing step comprises publishing a measure of the worth of the processing function associated with each member or meta member.

25. A method according to Claim 24, wherein the publishing step comprises publishing details of a member's or meta member's propensity score, the propensity score being related to the likelihood of a given outcome for the member or meta member executing its processing function.

26. A method according to Claim 25, wherein the propensity score is the probability of the member or meta member achieving the given outcome.

27. A method according to any of Claims 25 or 26, wherein the publishing step comprises publishing details of a member's or meta member's value, wherein the value is the potential worth of the member's or meta member's processing function to the transaction.

28. A method according to Claim 27, wherein the member's or meta member's value is the cost or value of achieving a desired outcome by the member's or meta member's processing function plus the summation of other members' or other meta members' values of all other members' or other meta members' processing functions which may execute from the outcome of the member's or meta member's processing function.

29. A method according to any of Claims 24 to 28, wherein the prospecting step comprises considering a plurality of different possible combinations of members or meta members to achieve the desired transaction, each combination having an associated cumulative measure of the possible transaction's worth, and selecting the most suitable combination on the basis of the considered cumulative measures of worth.

30. A method according to Claim 29 as dependent from any of Claims 25 to 28, wherein the prospecting step comprises assessing each member's or meta member's propensity score and/or value and consequently selecting one or more appropriate members or meta members for executing the desired transaction.

31. A method according to any of Claims 22 to 30, wherein the execution step comprises implementing the transaction across the selected members or meta members and returning a discreet outcome of the transaction.

32. A method according to any of Claims 22 to 31, wherein the publishing step comprises observing the outcome of other members' or other meta members' processing functions and linking to the member or meta member a new member's or new meta member's processing function spawned by the results of the observed outcome.

33. A method according to any of Claims 22 to 32, wherein the publication and prospecting steps occur iteratively and the results of the prospecting step can change the results of a subsequent publication step.

34. A method of performing a transaction step of a transaction process implemented on a distributed transaction exchange, the method comprising: identifying a transaction step having a member which is missing desired information, such that the transaction step cannot be evaluated for execution; substituting a meta member associated with the member in place of the member to provide approximation information relating to the missing information of the identified transaction step; evaluating the identified transaction step to determine an approximation to the outcome of the transaction step; selecting an evaluated transaction step having the most desirable outcome or approximated outcome; and executing the selected transaction step on the transactional exchange.

35. A method of implementing a transaction process using a distributed exchange, the exchange having a plurality of transaction members each member being capable of performing a processing function and of playing the role of a customer, a supplier or a mediator, the method comprising: publishing details of the demand, supply or mediation capabilities of each member; and carrying out a method of performing a transaction step according to Claim 34.