GB2375624A

GB2375624A - Ranking data according to multiple criteria

Info

Publication number: GB2375624A
Application number: GB0111934A
Authority: GB
Inventors: Paul James Joseph Worthy; Adam Joseph Wright; Christopher Michael Cocker; Jeremy David Hasse Holland; David Peter Handbury Tee
Original assignee: KPRIME Ltd
Current assignee: KPRIME Ltd
Priority date: 2001-05-16
Filing date: 2001-05-16
Publication date: 2002-11-20
Also published as: GB0111934D0

Abstract

Requests to complex stored data, particularly of a trading character that requires complex requests, e.g. for goods and services, are matched effectively to providers having complex resources or capabilities based on simultaneous consideration of a multiplicity of matching criteria. Providers capabilities are ranked or prioritised data according to a multiplicity of criteria associated with the request. The ranked results are output along with an explanation of the basis on which the ranking was reached. The request may then be resubmitted with modifications to criteria leading to a re-calculated ranking and a new explanation.

Description

MATCHING REQUESTS TO ELEMENTS DEFINED BY COMPLEX STORED DATA FIELD OF THE INVENTION The present invention relates to a process and apparatus for matching requests to elements each defined by complex stored data, and particularly, but not exclusively, to apparatus of a trading character that permits complex requests e. g. for goods and services to be matched effectively to providers having complex resources or capabilities based on simultaneous consideration of a multiplicity of matching criteria.

BACKGROUND TO THE INVENTION Numerous patents describe trading systems based on computer networks such as the Internet. A famous example is provided by US-A-5960411 (Amazon. com, Inc) which describes a method and system for placing an order to purchase an item via the Internet using single-action ordering of items within a client/server environment.

US-A-6125391 (Commerce One, Inc) describes systems and protocols supporting transactions among diverse clients coupled to a network; and more particularly to systems and protocols supporting commercial transactions among platforms having variant architectures. In particular, it is concerned with the need to provide systems for facilitating spontaneous commerce between trading partners without custom integration or prior agreement on industry wide standards. The proposed solution involves companies exchanging information and services using self-defining, machine-readable documents, such as XML (Extensible Markup Language) based documents that can be easily understood amongst the partners. Documents that describe the documents to be exchanged, called business interface definitions BIDs, are posted on the Internet, or otherwise communicated to members of the network. The business interface definitions tell

potential trading partners the services the company offers and the documents to use when communicating with such services. Thus, a typical business interface definition allows a customer to place an order by submitting a purchase order, compliant with a document definition published in the BID of a party to receive the purchase order. A supplier is allowed to check availability by downloading an inventory status report compliant with a document definition published in the BID of a business system managing inventory data. Use of predefined, machinereadable business documents is said to provide a more intuitive and flexible way to access enterprise applications.

US-A-6141653 (TradeAccess Inc) contains some significant observations concerning the problems of creating computer-controlled systems for use in iterative, multivariate negotiations. The inventors explain that business entities have tried for years to adapt computers and networks for use in sophisticated inter-company negotiations for commercial purchase and sales transactions, but with results that usually fall far short of expectations. Early mainframe computer attempts, for example, usually involved one corporation's allowing its existing suppliers and quantity buyers to connect to its internal private, proprietary network, using specially written locally developed application programs and private, proprietary network connections. These private systems were usually extremely costly to develop and maintain (often costing in the multi-millions of dollars) and very often did not meet all the needs and changing requirements of the participating businesses. Since many corporations had different internal networks and computer systems, considerable effort went into working around incompatibilities. Additionally, these systems had to be based on already existing, close relationships between buyers and sellers and usually were also based on previously negotiated agreements. Thus, the systems did not help in searching for information about new buyers and sellers, nor with the evaluation or negotiation processes, nor with the documenting of those processes from the beginning. They were not interactive, but typically batch processing systems, and usually accepted alphanumeric text only, not the inclusion of graphics or sound files. They usually addressed ongoing relationships previously worked out manually, for which

extremely expensive custom systems were developed at buyers'or vendors sites.

The inventors further explained that most business (and many other) negotiation processes are usually multivariate. That is, a business negotiation deals with many variable items, such as price, quantity, quality, shippers, insurance, warranty, schedules, returns and so on. The above solutions typically did not automate multivariate negotiations in any way, since they had to be built on agreements whose terms had all been previously negotiated. With the advent of the Internet and the World Wide Web (Web), the exchange of information amongst companies was greatly enhanced, with the use of Web technologies. However, even with chat rooms, bulletin boards, and forum websites most of this data and information exchange was simply that--not a multivariate negotiations process nor an online, electronic commerce process. The proposed solution involves providing a multivariate negotiations engine system operated at a software provider's Internet site.

SUMMARY OF THE INVENTION None of the above patents addresses the problem with which this invention is concerned of facilitating the establishment of partners to participate in complex transactions, where the requirement is not so much to establish a price or transaction terms but to determine which supplier organization which may be large and complex with a variety of business locations, teams within each location and individuals within each team best matches the need of a client organization whose needs for a particular transaction have similar complexity. Both the matching rules and the data for the potential parties may be"multivariate", and there is a need to provide a method, apparatus and software for facilitating the identification of best matches between complex needs and potential suppliers who can satisfy those needs.

In particular, there is a need for automating the sourcing and procurement of business services, for example by companies involved in telecommunications, financial services, multimedia, utilities, healthcare and insurance. Recent

estimates have suggested that by 2004, global multinational companies will spend about $158 billion per annum on e-business-related IT services alone, and the scale of the market can be seen to be even greater when other services such as human resources/recruitment, consulting, marketing and legal services are added.

The procurement overhead for these services has been estimated to be about 8%, so that anything that speeds and makes more effective the procurement process can provide significant savings.

The invention provides apparatus for providing a match between users with needs (called'buying users') and individuals or organisations who can satisfy those needs (called'capability owners') through a computer network, comprising: (a) means for storing elements each of which has data relating to a multiplicity of aspects of a capability associated with an owner; (b) means for receiving a request from a buying user based on a multiplicity of criteria concerning different aspects of the requirements; (c) means for ranking the elements on the basis of the criteria; and (d) means for outputting data identifying at least one capability owner selected according to the rank of its associated element; (e) means for outputting data explaining the basis on which the ranking was reached according to stored selection rules; (f) means for displaying one or more links provided with the output data and operable to give access to further data concerning the basis on which the ranking was reached and allowing the manipulation of said data; and (g) means for resubmitting the request with modifications to the request or criteria leading to a re-calculation and re-presentation of a new ranking and associated explanation derived from the new request.

In another aspect which is not limited to the field of business service procurement, the invention provides a computer program comprising instructions for : (a) storing elements each of which has data relating to a multiplicity of its aspects;

(b) receiving a request based on a multiplicity of criteria concerning different aspects of the stored elements; (c) ranking the elements on the basis of the criteria; and (d) outputting data identifying at least one element selected according to its rank; wherein the instructions provide for (e) outputting data explaining the basis on which the ranking was reached according to selection rules; (f) displaying one or more links provided with the output data and operable to give access to further data concerning the basis on which the ranking was reached and allowing the manipulation of said data; and (g) resubmitting the request with modifications to the request or criteria leading to a re-calculation and re-presentation of a new ranking and associated explanation derived from the new request.

The invention also includes the program defined above recorded on a data carrier, magnetic or optical disk or as electrical signals transmissible through a computer network.

The invention yet further provides a method for matching buying users and capability owners by means of software on a network, the software used being as described above.

BRIEF DESCRIPTION OF THE DRAWINGS An embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Fig. I is a diagram showing suppliers and clients connected via the Internet to a host server that stores a computer program according to the invention; Fig. 2 is a diagram showing the data structures established by the program of the invention;

Fig 3 is a flow diagram showing how suppliers or so-called"capability owners"and clients enter data and how the data is processed to match requests to capabilities and generate matches; Fig. 4 is a screen dump of a displayed capability undergoing editing by a supplying user; Fig. 5 is a screen dump of a displayed request undergoing data input by a buying user; and Figs 6a-6f are screen dumps of displayed results at varying levels of detail.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT The present invention is based on software that is a combination of artificially intelligent computer algorithms, data models and Internet connectivity methods that have been combined to create a Matching and Reasoning Engine (MRE). The MRE that forms part of the software enables, for example, complex automatic matching of service providers and service buyers. A key feature is the ability of the MRE to supply a service buyer with real-time human understanding of the reasons behind computer matches. The concept of intelligence is further extended to provide users with an iterative reasoning feature: i. e. an algorithm enabling a human user to explore detailed explanations of MRE-generated matches and further modify the selection criteria. The MRE may further contain adaptive algorithms that enable profiles to be automatically modified over time based on previous history. The MRE enables humans to solve complex business selection problems using a computer or computer network that facilitates that selection in a more human and accessible manner.

The present software has a large number of business applications including the following: (i) Bringing efficiency and speed to the process of buying external business services by providing matching facilities to internal company staff on-line (ii) Enabling a company to identify and connect with skilled people within the organization quickly and easily

(iii) Enabling company sales forces to rapidly identify and engage partner companies having skills or services that meet customer needs (iv) Enabling professional service companies to provide clients with an automated service to identify and engage with their experts The software of the invention is applicable to any process that requires complex matching of services and needs, where a human-understandable explanation of the reasons for selection is required together with the ability to change stated needs in light of the explanation. It may form part of larger systems for a variety of different technological and commercial applications. The present software can use conventional computer hardware but it is designed for Internet applications enabling it to handle tens of thousands of buying and supplying users whose capabilities are to be matched. It can be executed on multiple computer servers making the system highly scalable in the number of users it can service.

Users can input information to the present program via specially designed profiles as either a"supplier"or"buyer". The supplier database, buyer profile and related information sources (such as past performance history, external or internal company knowledge) are then processed by the MRE and information is fed back to the buyer in a form that enables further iterations of matching. Suppliers can interact with the MRE in a similar method to the buyer and following a computer driven workflow.

Some of the computer data required for processing by the present program is sourced by users. Additional data is gathered from other machine sources by the MRE from Internet and network connections. Either a user generates control commands or the MRE workflow and AI processes effect control commands in response to changes in data, time or event states. The MRE accumulates data on past activity and adapts its profiles and rules based on this.

A graphical interface is the principal method by which users can interact with the MRE. Internet Web Browsers are used to display the interface. Data may

be stored in profiles drawn from an industry application template library. The profile information may be stored either as conventional RDBMS data items or as XML documents. Event and workflow information may be stored in RDBMS databases. Data for the matching methods (which may include Artificial Intelligence-AI-techniques) and MRE may be stored either as conventional RDBMS or as XML documents.

Pre-stored data such as profiles (stored in RDBMS or XML) are used when processing the input data. The creator of the program provides basic profiles and these may be modified by the end user. The program as supplied provides relevant profile entry forms for implementation and these can then be configured for use in particular organizations and for particular applications.

Data from users can also be captured using standardized data entry forms. The system may also provide facilities for modifying existing profiles based on previous history. Pre-stored supplier data, historical performance and matching rules are processed by the MRE upon the user requesting a match or another workflow event requiring such a match to be made. The implementation connects users across computer networks.

Each station on the network requires only a"thin client"access device such as web browser. Processing usually resides centrally (but may operate at local terminals). Some segments of code may be downloaded to workstation (for example the common use of Java or VBScript). Workstations may (and are highly likely to) reside in different jurisdictions-the novel components to the application are currently processed centrally. It is possible to run the MRE across a distributed architecture. Data after processing is application-generated and can be interpreted by humans as either natural language explanations or GUI representations of information and state. Screen dumps of output are illustrated below.

The advantages of the present program are apparent in decision support providing a simple interface to a complex searching tool that provides efficient access to high value business information : (a) Gathering information from a range of sources of complex services (b) Defining needs of complex problems in a simple form (c) Producing matches that enable the human user to understand the reasons for the match and to further modify that match (d) Efficiency in the process of contacting, engaging and managing suppliers when a match is made.

An embodiment of the invention provides a method and apparatus by which a client can enter a request for goods or services from a terminal into a computer network and can use software held on the network to identify the most appropriate one of a number of suppliers.

As seen in Fig. 1, a client organization has a computer network 10 having

buying user terminals IlJ - 144 connectable via a local server 12 and an internet service provider (ISP) 13 to the Internet 24. Suppliers 151 - 15n are also connected by respective ISPs to the Internet 24 and also have supplying user terminals and local network servers. The capabilities of buying users and supplying users who can operate the terminals are controlled by permissions which may be inherited from a default table or may be set by a manager within the organization, and for this purpose managers are supported, one such terminal which is being operated in the role of a manager or supervisor being shown at 16. A host server 27 holds inter alia software for accumulating and storing a knowledge base of information concerning suppliers and their profiles that the suppliers submit via the Internet, for processing requests submitted by the client 10, and for enabling a user at one of the terminals of the client iteratively to submit a request, receive a list of matching suppliers and to modify and resubmit the request until the match is optimized.

The software held on the server 17 supports buying users, supplying users and managing users, these roles not being exclusive and the managing users supporting several levels of manager. As seen in Fig. 2, a supplier or capability owner 20 may have a number of users 22 within its organization who may be authorized to edit a capability for that supplier that is stored in the memory of the remote server 17. Each capability 24 is associated with its respective owner by a relational link, describes the capacity, skills and requirements of the supplier or capability owner 20, and may contain additional information as explained below.

It may take the form of an XML document or it may be an entry in a relational table. The database established by the program stored in the server 17 will contain a large number of capabilities 24 for different owners 20.

A buying user 26 may issue a request 28 whose form is defined by a prostored template 30. A matching and reasoning engine that forms part of the stored program uses instructions and values in the request 28 to establish a connection 32 to one or more of the capability owners 20 that have been selected based on their stored capabilities 24.

Each buying user 26, supplying user 22 and manager 36 has certain common characteristics defined by a user table 33, for example all users may have a unique name, e-mail address and a password. Optionally the characteristics of each user may be further defined by a profile 34 which is special to each individual user and which may deal with such matters as a colour scheme for screen displays, a signature file for e-mails and'calculated'user preferences. The program can support more than one level of manager, so that each of the buying users 26, supplying users 22 and managers 36 may have their capabilities defined by a manager. The ability of each user to operate within the program is governed by permissions that are initially set by values stored within a permissions default table 38. The values are inherited by stored capability owner permissions and profile table 40 that governs the operations that supplying users 22 within capability owner 20 are authorized to perform. For example the stored permissions may establish that a supplying user 22 cannot edit capability 24 but his or her

manager 36 can. The values in table 40 can be edited by an authorized manager within the capability owner 20 so as to change the supplying users who can perform operations on the capability 24 and the kinds of operation that they can perform. The same is mirrored on the buying user side with a buying user permissions table 42 that operates at the level of a group of buyers 44 contained within the buying user 26 and controlling e. g. which users are allowed to edit and issue a request and which other operations they can perform.

The permissions and authority of a particular user can be delegated. For example, supplying users 22 within a capability owner 20 can access connection 32 provided that they are originally authorized or specifically delegated as represented by connected users table 46. A buying user 26 can delegate his interest in a request by storing this in the request.

Requests can be grouped together into request groups 48. A customer details table 50 enables a buying user 26 to create a request for a third party organization, e. g. when the buying user is a management consultancy acting on behalf of another organization e. g. a financial institution.

As is apparent from Fig. 3, each capability owner is assigned a single capability that is defined by a capability type template 52 and is initially empty as at 24a. The mandatory data for a capability may be, for example, as represented in Table I below:

Table 1 CAPABILITY TEMPLATE

Subject Comments Matter Capability e. g. law firm, accountancy, management consultancy, type facilities management, etc Applicable Whole firm, division, team or individuals level (s) within capability owner Data fields For each field . Field Name . Field Types . Validation Requirements . Initial Settings For all together . Interpretation Logic, e. g. for the interpretation of data within particular fields or groups of fields into a format that the program can use more readily, interpreting a fuzzy term to a numerical term or dictating how specific information about a firm, team or individual should be interpreted into a graded capability Display Initial Entry Form Definition Forms. (fields displayed, order, controls used, etc) Edit Form Definition (fields displayed, etc) Buyer Display Form Definition . (fields displayed, etc) Supplier Display Form Definition . (fields displayed, etc)

The capability 24a is displayed for data entry as a form and controls for fields within the form are established by a definition table 54, entry of data into the fields creating a populated capability 24b which is a member of a pool of capabilities 56 allocated to respective capability owners and stored in the server 17. An example of a completed or populated capability is shown in Fig. 4, in which: o The capability type is specified to be corporate financial legal services.

. Data is entered at various levels e. g. for the whole firm, for teams in particular geographical locations and dor particular individuals within each team.

. Interpretation logic may, for example, geocode entered geographical information or deduce a high level corporate capability based on the capabilities of constituent offices or teams.

The fields, order and controls displayed are in this instance for the editing of a pre-existing capability by a supplying user 26.

The logic for creation of a request mirrors that for creation of a capability.

A template 58 enables a buying user 26 to create a request 28a that is initially empty or unpopulated. It is displayed as a form whose fields have controls the form of which is established by a control definitions table 60. Entry of data leads to a populated request 28b. The mandatory data for a request, which is defined by a request type template, may be as shown in Table II below.

Table II Request template

Subject matter Comments Name e.g.Request for Legal Services Capability e.g. legal services service type to match Level of e. g. firm, team or partner capability owner to match Additional flags for initial selection MRE display Which entries in MRE form table 66 (Fig. 3) describes how form template to the results form should be displayed use MRE display # Column names form parameters &num; in list . &num; selected, etc Data fields For each field . Field Name . Field Types Validation Requirements . Initial Settings For all together Interpretation Logic, e. g. for the interpretation of data within particular fields or groups of fields into a format that the program can use more readily Matching rules For each : . Matching rule name . Request fields/Interpreted fields as input . Capability fields as input . Additional values, tables, etc as input . Names of subsidiary rules . Initial weightings and bias Explanation rules For each : . Level of explanation . MRE display zone . Matching rule applied to Terms to display .'Supplier Detail'hyperlinked placeholder .'Matching Quality'placeholder .'Matching Quality'term calculation .'Matching Quality'control to use .'Matching Quality'Active flag.

*'Requirements Display'Control to Use # 'Requirements Display' Hyperlinked Term Display Forms Initial Entry Form Definition . (fields displayed, order, controls used, etc) Edit Form Definition . (fields displayed, etc) Buyer Display Form Definition . (fields displayed, etc) Supplier Display Form Definition . (fields displayed, etc)

Fig 5 shows an example of an unpopulated legal corporate finance request, it being apparent that what is shown to the buying user is request type, capability of service to match to and data fields, the matching rules and explanation rules which also form part of or are logically related to the request not being shown when the request is being completed, but being accessible to a manager or supervisor. Matching rules and explanation rules may be stored as tables in which each rule has the attributes of a rule name, a rule calculation and a calling definition or external interface.

A matching and reasoning engine forming part of the software in server 17 responds to submission of a populated request 28b by fetching the appropriate matching rules from table 62, applying the rules and the search data in the request to the capabilities within the population 56 and producing an ordered list or match form 64 whose form is set by the selected portions of the table 66 and that includes one or more matches, an ordering or ranking of the matches and an explanation as to that ranking generated according to explanation instructions that are contained within the request.

It is a feature of the invention that the buying user can"drill down"into the explanations (i. e. decompose high level explanations into more detailed explanations and when doing so can change the original data input into the request or the weightings of the rules that are used by the request to generate the matching form 64. Change of parameters gives rise to a revised populated request 28c that

when submitted by the buying user is used to generate a second matching form 64a in the same way that the earlier form 64 was generated. The procedure may be iterated to produce a matching form 64n which fully satisfies the requirements of the buying user 26, after which he can create a connection 32 between the request and the selected capability owner or owners.

Fig 6a is a screen dump of an initial matching form 64 with matches and percentage fits displayed together with control regions generally indicated by the reference numeral 75 that can be selected by a pointer or other input device to provide links to more detailed explanation for each of the recorded matches and/or individual aspects thereof. For example, by selecting the magnifying glass 77 (Fig.

6b) for one of the matches, the overall match figure is decomposed into its components, in this case a sector match, a geography match and an expertise match. Further selecting the magnifying glass 79 for geographic fit breaks down the overall figure for geographic fit into its components e. g. by country or region that are important to the buying user, in this case individual geographic fits for Netherlands, the UK and Germany as in Fig 6c. Further selecting magnifying glass 81 for the Netherlands gives further information about the fit for company location and for individual teams within the Netherlands as in Fig 6d. Selecting magnifying glass 83 produces details of the requirement-specifying entries that have been made in data fields 85 of the request and the data that is present in the corresponding group of fields 87 if the capability. Selecting individual links 89 within the data fields 85 enables the entries in these fields to be varied e. g. from "must have"to"nice to have"for use in the next iteration. The user is thereby enabled to respond to the results in one iteration by adjusting the entries in the various fields of the request to produce a new version 64a that better reflects his true requirements, the new request being re-submitted as explained above. It will be apparent that the links referred to in Figs 6a-6e occur in a hierarchy and provide facilities for . giving access to data showing how a matching rule contributed to a ranking;

giving access to data showing how entries in data fields of the request contributed to a ranking; and giving simultaneous display of entries in the data fields of the request and entries in corresponding fields of a ranked element.

The connection 32 in practice may generate an e-mail, facsimile or other communication with the capability owner to invite him to express an interest in the request. The connection 32 provides states in sequences corresponding to abortive or successful transactions. At all or some of the states of the connection 32 a feedback form whose behaviour and appearance is defined by a template 68 is displayed and when completed by the supplying or buying user is populated as at 70 and when submitted causes the relevant capability to be augmented or modified according to the data and instructions in the feedback form. A template for such a form is shown in Table III below.

TABLE III FEEDBACK FORM TEMPLATE

Subject matter Comments Name Levels of Capability Owners Applicable Data Fields for each . Field Name . Field Types . Validation Requirements * Initial Settings for all together . Interpretation Logic Display Forms Initial Entry Form Definition . fields displayed, order, controls used, etc Edit Form Definition . fields displayed, etc Buyer Display Form Definition . fields displayed, etc Supplier Display Form Definition . fields displayed, etc Modifications Modification to Capability . Additional Fields to add to Capability Modification to Capability Display Forms Modification to Request . Additional Fields to add to Request Modification to Connection Data to store in Connection

There is always a single capability 24a-24d associated with a particular capability owner 32, and it is this capability that is augmented by the feedback form, so that comments are correctly captured and information is accumulated within the capability pool. In this way, future requests benefit from the feedback of previous users.

Claims

1. A computer program comprising instructions for: (a) storing elements each of which has data relating to a multiplicity of its aspects ; (b) receiving a request based on a multiplicity of criteria concerning different aspects of the stored elements; (c) ranking the elements on the basis of the criteria; and (d) outputting data identifying at least one element selected according to its rank; wherein the instructions provide for (e) outputting data explaining the basis on which the ranking was reached according to selection rules; (f) displaying one or more links provided with the output data and operable to give access to further data concerning the basis on which the ranking was reached and allowing the manipulation of said data; and (g) resubmitting the request with modifications to the request or criteria leading to a re-calculation and re-presentation of a new ranking and associated explanation derived from the new request.

2. The program of claim 1, further comprising a template for the elements which is stored separately from the elements and is usable to define an initial field structure for the data in each element.

3. The program of claim I or 2, wherein each element has a multiplicity of levels and a multiplicity of data fields at each level. reflect company, teams, each of which may maintain their own profile separately

4. The program of claim 3, wherein the request has fields for defining levels for data that is to be used in reaching a ranking.

5. The program of any preceding claim, wherein the request includes fields for invoking and defining matching rules.

6. The program of any preceding claim, wherein the request includes fields for invoking and defining explanation rules.

7. The program of any preceding claim, wherein instructions provide for modification by a user of entries in data fields, matching rule fields and/or explanation rule fields.

8. The program of any preceding claim, further comprising a template for the request which is stored separately from the request and is usable to define an initial state for entries in the fields of the request, how the fields are presented and how they behave.

9. The program of any preceding claim, wherein instructions provide for the display of links with the output data that are operable to give access to data showing how a matching rule contributed to a ranking.

10. The program of any preceding claim, wherein instructions provide for the display of links with the output data that are operable to give access to data showing how entries in data fields of the request contributed to a ranking.

11. The program of any preceding claim, wherein instructions provide for the display of links with the output data that are operable following establishment of a ranking to permit simultaneous display of entries in the data fields of the request and entries in corresponding fields of a ranked element.

12. The program of any preceding claim, wherein the stored instructions further provide for the display of a feedback form having one or more fields for data to be added to elements.

13. The program of any preceding claim recorded on a data carrier, magnetic or optical disk or as electrical signals transmissible through a computer network.

14. Apparatus for providing a match between buying users and capability owners through a computer network, comprising: (a) means for storing elements each of which has data relating to a multiplicity of aspects of a capability associated with an owner; (b) means for receiving a request from a buying user based on a multiplicity of criteria concerning different aspects of the stored elements; (c) means for ranking the elements on the basis of the criteria; and (d) means for outputting data identifying at least one capability owner selected according to the rank of its associated element; (e) means for outputting data explaining the basis on which the ranking was reached according to stored selection rules; (f) means for displaying one or more links provided with the output data and operable to give access to further data concerning the basis on which the ranking was reached and allowing the manipulation of said data; and (g) means for resubmitting the request with modifications to the request or criteria leading to a re-calculation and re-presentation of a new ranking and associated explanation derived from the new request.