Request matching system and method

REQUEST MATCHING SYSTEM AND METHOD

The present invention relates to a request matching system for and a method of matching requests of users, as requestors, to providers in servicing the requests.

The present invention finds application in many fields, but particularly in classification structures where a user, as a requestor, wants to make a request of a community of interest, that is, a plurality of providers who are commonly classified.

It is envisaged that the present invention will find particular application in relation to trade classifications, where providers are grouped according to the goods or services provided.

Such trade classifications are currently embodied in a local trade directory, such as the Yellow Pages^® or Thomson Directory^® in the UK, and, when seeking goods or services, a person would use the local directory to locate a provider for the goods or services.

In using such a directory, a person would first determine the classification most likely to supply the goods or services, review the corresponding section in the directory, select one or more providers, and then telephone those providers. When telephoning the providers, the same request, for example, "Can you provide goods/service X, for cost Y and before date Z?", would have to made repeatedly to each provider. Often, especially if the request is specific, for example, "Do you have car part X in stock?", the person would have to telephone many of the selected providers before finding a provider that can satisfy the request. This is particularly the case where more than one provider has to be identified, for example, such as to allow for a comparison of costs, delivery times, etc.

Such a process is both time consuming, in having first to identify possible providers and subsequently establish conversation with many providers until one or more providers are identified who can satisfy the request, and also relatively costly, in incurring the telephone costs associated with telephoning each of the many providers.

Although it is envisaged that the present invention will find particular application in relation to trade classifications, the present invention also has application in relation to many other classification structures.

One such other classification structure is broadcast classifications, where a request is broadcast to a plurality of providers, which enables replies to be obtained from all of the providers, and provides for the logging of one or both of positive and negative replies from providers, and also those providers who do not reply. It is envisaged that such classifications could find application in obtaining information in response to a query, for example, in building marketing lists or polling.

Another such other classification structure is community classifications, where persons having a common interest are commonly classified such as to allow a request to be made by a requestor, who may be a provider in the community classification, of ones or all of the other persons in the community classification, as providers. One example of a community classification is a local help group whose members offer assistance on an ad hoc basis, where requests for assistance can be made of the members.

A further such other classification structure is tasking classifications, where a request is made to a plurality of providers requiring performance of a task. It is envisaged that such classifications will find particular application in the corporate environment, where requests can be made of particular departments, for example, the purchasing or marketing departments.

A yet further such other classification structure is promotion classifications, where a particular promotion is run, typically for a short period of time, and supported by a plurality of providers. One example of a promotion classification is holiday breaks, for example, fixed-price weekend breaks, where providers wishing to join the promotion opt into the classification. In a preferred embodiment the providers would have the ability to opt into and out of the classification subject to the availability of the goods or services provided by the respective providers.

It is an aim of the present invention to provide a matching system and method which provides for the matching of requests of users, as requestors, to providers without a requestor having to identify possible providers and contact those providers to determine whether a request can be met.

In one aspect the present invention provides a matching system for matching requests of users, as requestors, to providers in servicing the requests, each of the requestors having at least one communicator for making requests and addressing respective replies thereto and each of the providers having at least one communicator for addressing requests and respective replies thereto, the system comprising: at least one request receiving unit for receiving requests from requestors; at least one request relaying unit for providing for each of the requests to be relayed to selected providers as addressed thereby; at least one reply receiving unit for receiving replies from providers, the replies received being made by the respective providers, as human decision-makers, based on the respective requests; and at least one information supplying unit for one or both of supplying, for each request, information regarding the respective requestor to any providers having provided a positive reply to the respective request, with a positive reply indicating that a provider is able meet a request, and information regarding replies from selected providers to the respective request to the respective requestor.

Preferably, the system is a real-time matching system.

Preferably, the requests are free-format requests.

Preferably, the requests include voice requests. Preferably, the communicators include mobile communicators, such as telephones, PDAs, personal computers and games devices.

Preferably, the communicators include fixed communicators, such as telephones, fax machines, personal computers, set-top boxes and games consoles.

Preferably, the communicators include combination fixed/mobile communicators, such as telephones.

In one embodiment the system comprises: at least one inbound communications unit, each comprising at least one request receiving unit.

In one embodiment the system comprises: at least one outbound communications unit, each comprising at least one request relaying unit, at least one reply receiving unit and at least one information supplying unit.

In another embodiment the system comprises: at least one communications unit, each comprising at least one request receiving unit, at least one request relaying unit, at least one reply receiving unit and at least one information supplying unit.

In one embodiment the at least one request relaying unit is configured to relay a request directly to the communicators of selected providers.

Preferably, the at least one request relaying unit is configured to provide for a request to be relayed without any interrogation thereof to establish content.

Preferably, the at least one request receiving unit includes a plurality of receivers for receiving requests, each request having a classification contact address associated with a predeterminable classification. More preferably, the classification contact addresses are dialling numbers.

In one embodiment the system further comprises: at least one provider selection unit for selecting providers to address a request.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on a geographic location assigned to the respective request and one or both of geographic locations or geographic zones assigned to the providers.

In one embodiment the geographic location assigned to the respective request is a current geographic location of the respective requestor.

Preferably, the current geographic location is determined from a communicator contact address of the communicator of the respective requestor, where the communicator contact address has an assigned location.

More preferably, the communicator contact address is a dialling number.

In one embodiment the geographic location assigned to the respective request is an alternate geographic location as assigned by the respective requestor.

Preferably, the alternate geographic location is determined from a communicator contact address of a communicator, where the communicator contact address has an assigned location.

More preferably, the communicator contact address is a dialling number.

Preferably, geographic location of mobile communicators is determined from one of cell identification, triangulation, radio positioning or satellite positioning, such as GPS. Preferably, geographic location of fixed communicators is determined from respective assigned locations.

Preferably, the at least one provider selection unit is configured to select providers for a request within a predeterminable spatial geographic zone relative to the geographic location assigned to the respective request.

More preferably, the predeterminable spatial geographic zone is one of a geographic radius relative to the geographic location assigned to the respective request, a distance of travel relative to the geographic location assigned to the respective request, or a time of travel relative to the geographic location assigned to the respective request.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on at least one requestor characteristic for the respective requestor, such as geographically-related and socio-economic information, as an assigned characteristic for the respective requestor or a characteristic input by the respective requestor in making the request.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on at least one provider characteristic for the providers, such as requiring requestors to have a predeterminable profile or to provide contact details, as an assigned characteristic for the respective providers.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on current time.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on at least one classification characteristic, such as a selection mechanism for selecting providers, as an assigned characteristic for the respective classification. Preferably, the at least one request relaying unit is configured to relay a request to a predeterminable number of selected providers as addressed thereby.

Preferably, the at least one request relaying unit is configured to multicast a request to selected providers where the request is to be relayed to a plurality of providers as addressed thereby.

Preferably, the at least one information supplying unit is configured, for a request, to supply information regarding providers having provided a positive reply to the respective request to the respective requestor.

In another aspect the present invention provides a matching system for matching requests of users, as requestors, to providers in servicing the requests, the system comprising: a plurality of requestor communicators, each being for use by requestors in making requests and addressing replies thereto, at least ones of the replies including information regarding replies from selected providers, as human decision-makers, to respective requests; and a plurality of provider communicators, each being for use by providers in addressing requests and replies thereto, the requests being relayed to respective selected providers as addressed and at least ones of the replies including information regarding the requestor of a respective request where having provided a positive reply to the respective request, with a positive reply indicating that a provider is able to meet a request.

Preferably, the system is a real-time matching system.

Preferably, the requests are free-format requests.

Preferably, the requests include voice requests.

Preferably, the communicators include mobile communicators, such as telephones, PDAs, personal computers and games devices. Preferably, the communicators include fixed communicators, such as telephones, fax machines, personal computers, set-top boxes and games consoles.

Preferably, the communicators include combination fixed/mobile communicators, such as telephones.

In one embodiment a request is relayed directly to respective selected providers.

Preferably, a request is relayed without any interrogation thereof to establish content.

Preferably, the system further comprises: a communications unit including a plurality of receivers for receiving requests, each request having a classification contact address associated with a predeterminable classification.

More preferably, the classification contact addresses are dialling numbers.

Preferably, providers are selected for a request based at least in part on a geographic location assigned to the respective request and one or both of geographic locations or geographic zones assigned to the providers.

In one embodiment the geographic location assigned to the respective request is a current geographic location of the respective requestor.

Preferably, the current geographic location is determined from a communicator contact address of the communicator of the respective requestor, where the communicator contact address has an assigned location.

More preferably, the communicator contact address is a dialling number. In one embodiment the geographic location assigned to the respective request is an alternate geographic location as assigned by the respective requestor.

Preferably, the alternate geographic location is determined from a communicator contact address of a communicator, where the communicator contact address has an assigned location.

More preferably, the communicator contact address is a dialling number.

Preferably, providers are selected within a predeterminable spatial geographic zone relative to the geographic location assigned to the respective request.

Preferably, providers are selected for a request based at least in part on at least one requestor characteristic for the respective requestor, such as geographically-related and socio-economic information, as an assigned characteristic for the respective requestor or a characteristic input by the respective requestor in making the request.

Preferably, providers are selected for a request based at least in part on at least one provider characteristic for the providers, such as requiring requestors to have a predeterminable profile or to provide contact details, as an assigned characteristic for the respective providers.

Preferably, providers are selected for a request based at least in part on current time.

Preferably, providers are selected for a request based at least in part on at least one classification characteristic, such as a selection mechanism for selecting providers, as an assigned characteristic for the respective classification. In a further aspect the present invention provides a matching system for matching requests of users, as requestors, to providers in servicing the requests, each of the requestors having at least one communicator for making requests and addressing replies thereto and each of the providers having at least one communicator for addressing requests, the system comprising : at least one request receiving unit for receiving requests from requestors; at least one request relaying unit for providing for each of the requests to be relayed to selected providers as addressed thereby; and at least one reply receiving unit for receiving replies from providers, the replies received being made by the respective providers, as human decision-makers, based on the respective requests.

In a yet further aspect the present invention provides a matching system for matching requests of users, as requestors, to providers in servicing the requests, the system comprising: a plurality of requestor communicators, each being for use by requestors in making requests and addressing respective replies thereto; a plurality of provider communicators, each being for use by providers in addressing requests and respective replies thereto; and at least one communications unit communicatable with the requestor communicators and the provider communicators, and including at least one provider selection unit for selecting providers to address a request made by a requestor; wherein, for each request, the system is configured such that the request is provided to be relayed to selected providers, as human decision-makers, as addressed thereby.

Preferably, the system is further configured such that, for a request, the respective requestor is supplied with information regarding replies from selected providers to the respective request.

Preferably, the system is a real-time matching system.

Preferably, the requests are free-format requests.

Preferably, the requests include voice requests. Preferably, the communicators include mobile communicators, such as telephones, PDAs, personal computers and games devices.

Preferably, the communicators include fixed communicators, such as telephones, fax machines, personal computers, set-top boxes and games consoles.

Preferably, the communicators include combination fixed/mobile communicators, such as telephones.

In one embodiment the system is configured such that a request is relayed directly to the provider communicators of selected providers.

Preferably, the system is configured to provide that a request is relayed without any interrogation thereof to establish content.

Preferably, the at least one communications unit includes a plurality of receivers for receiving requests, each request having a classification contact address associated with a predeterminable classification.

More preferably, the classification contact addresses are dialling numbers.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on a geographic location assigned to the respective request and one or both of geographic locations or geographic zones assigned to the providers.

In one embodiment the geographic location assigned to the respective request is a current geographic location of the respective requestor.

Preferably, the current geographic location is determined from a communicator contact address of the communicator of the respective requestor, where the communicator contact address has an assigned location.

More preferably, the communicator contact address is a dialling number.

In one embodiment the geographic location assigned to the respective request is an alternate geographic location as assigned by the respective requestor.

Preferably, the alternate geographic location is determined from a communicator contact address of a communicator, where the communicator contact address has an assigned location.

More preferably, the communicator contact address is a dialling number.

Preferably, the at least one provider selection unit is configured to select providers within a predeterminable spatial geographic zone relative to the geographic location assigned to the respective request.

More preferably, the predeterminable spatial geographic zone is one of a geographic radius relative to the geographic location assigned to the respective request, a distance of travel relative to the geographic location assigned to the respective request, or a time of travel relative to the geographic location assigned to the respective request.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on at least one requestor characteristic for the respective requestor, such as geographically-related and socio-economic information, as an assigned characteristic for the respective requestor or a characteristic input by the respective requestor in making the request.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on at least one provider characteristic for the providers, such as requiring requestors to have a predeterminable profile or to provide contact details, as an assigned characteristic for the respective providers.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on current time.

Preferably, the at least one provider selection unit is configured to select providers for a request based at least in part on at least one classification characteristic, such as a selection mechanism for selecting providers, as an assigned characteristic for the respective classification.

Preferably, the system is configured such as to provide for a request to be relayed to the provider communicators of a predeterminable number of respective selected providers as addressed thereby.

Preferably, the system is configured to multicast a request to the provider communicators of respective selected providers where the respective request is to be relayed to a plurality of providers as addressed thereby.

In yet another aspect the present invention provides a method of matching requests of users, as requestors, to providers in servicing the requests, each of the requestors having at least one communicator for making requests and addressing replies thereto and each of the providers having at least one communicator for addressing requests and replies thereto, the method comprising the steps of: receiving requests from requestors; for each request, providing for the request to be relayed to selected providers as addressed thereby; receiving replies from selected providers, the replies received being made by the respective providers, as human decision- makers, based on the respective requests; and one or both of supplying, for each request, information regarding the respective requestor to any providers having provided a positive reply to the respective request, with a positive reply indicating that a provider is able to meet a request, and information regarding replies from selected providers to the respective request to the respective requestor.

Preferably, the method is a real-time matching method.

Preferably, the requests are free-format requests.

Preferably, the requests include voice requests.

Preferably, the communicators include mobile communicators, such as telephones, PDAs, personal computers and games devices.

Preferably, the communicators include fixed communicators, such as telephones, fax machines, personal computers, set-top boxes and games consoles.

Preferably, the communicators include combination fixed/mobile communicators, such as telephones.

In one embodiment the step of providing for a request to be relayed to selected providers as addressed thereby comprises the step of: relaying a request directly to the communicators of selected providers.

Preferably, a request is relayed without any interrogation thereof to establish content.

Preferably, the step of receiving requests from requestors comprises the step of: receiving requests from requestors at a plurality of receivers, each of the requests having a classification contact address associated with a predeterminable classification.

More preferably, the classification contact addresses are dialling numbers. In one embodiment the method further comprises the step of: selecting respective providers to address a request.

Preferably, the step of selecting respective providers to address a request comprises the step of: selecting respective providers to address a request based at least in part on a geographic location assigned to the respective request and one or both of geographic locations or geographic zones assigned to the providers.

In one embodiment the geographic location assigned to the respective request is a current geographic location of the respective requestor.

Preferably, the current geographic location is determined from a communicator contact address of the communicator of the respective requestor, where the communicator contact address has an assigned location.

More preferably, the communicator contact address is a dialling number.

In one embodiment the geographic location assigned to the respective request is an alternate geographic location as assigned by the respective requestor.

Preferably, the alternate geographic location is determined from a communicator contact address of a communicator, where the communicator contact address has an assigned location.

Preferably, the communicator contact address is a dialling number.

Preferably, geographic location of mobile communicators is determined from one of cell identification, triangulation, radio positioning or satellite positioning, such as GPS. Preferably, geographic location of fixed communicators is determined from an assigned location.

Preferably, the step of selecting respective providers to address a request comprises the step of: selecting respective providers to address a request within a predeterminable spatial geographic zone relative to the geographic location assigned to the respective request.

More preferably, the predeterminable spatial geographic zone is one of a geographic radius relative to the geographic location assigned to the respective request, a distance of travel relative to the geographic location assigned to the respective request, or a time of travel relative to the geographic location assigned to the respective request.

Preferably, the step of selecting respective providers to address a request comprises the step of: selecting respective providers to address a request based at least in part on at least one requestor characteristic for the respective requestor, such as geographically-related and socio-economic information, as an assigned characteristic for the respective requestor or a characteristic input by the respective requestor in making the request.

Preferably, the step of selecting respective providers to address a request comprises the step of: selecting respective providers to address a request based at least in part on at least one provider characteristic for the providers, such as requiring requestors to have a predeterminable profile or to provide contact details, as an assigned characteristic for the respective providers.

Preferably, the step of selecting respective providers to address a request comprises the step of: selecting respective providers to address a request based at least in part on current time.

Preferably, the step of selecting respective providers to address a request comprises the step of: selecting respective providers to address a request based at least in part on at least one classification characteristic, such as a selection mechanism for selecting providers, as an assigned characteristic for the respective classification.

Preferably, the step of providing for a request to be relayed to selected providers as addressed thereby comprises the step of: providing for a request to be relayed to a predeterminable number of selected providers as addressed thereby.

Preferably, the step of providing for a request to be relayed to selected providers as addressed thereby comprises the step of: multicasting a request to selected providers where the request is to be relayed to a plurality of providers as addressed thereby.

Preferably, the step of supplying information comprises the step of: supplying, for a request, information regarding providers having provided a positive reply to the request to the respective requestor.

In still yet another aspect the present invention provides a method of matching requests of users, as requestors, to providers in servicing the requests, each of the requestors having at least one communicator for making requests and addressing replies thereto and each of the providers having at least one communicator for addressing requests, the method comprising the steps of: receiving requests from requestors; for each request, providing for the request to be relayed to selected providers as addressed thereby; and receiving replies from providers, the replies received being made by the respective providers, as human decision- makers, based on the respective requests.

In a still yet further aspect the present invention provides a method of matching requests of users, as requestors, to providers in servicing the requests, the method comprising the steps of: receiving signals comprising requests from requestors; for each request, transmitting a signal to selected providers comprising the request as received; receiving signals comprising replies from selected providers, the replies being made by the respective providers based on the respective requests; and for each request, transmitting one or both of a signal comprising information regarding the respective requestor to any providers having provided a positive reply to the respective request, with a positive reply indicating that a provider is able to meet a request, and a signal comprising information regarding replies from selected providers to the respective request to the respective requestor.

The present invention, to be known as the esponsa ™ matching system, provides an automated matching system, allowing in particular voice requests, and especially free-format requests, to be matched with providers that have received a request and have confirmed that the request can be met.

In a preferred embodiment this matching is achieved based on a location associated with the requestor, typically the location of the communicator of the requestor, the assigned locations of the providers in the classification selected, and the classification selected. In other embodiments the current time and characteristics of one or both of the requestor and the providers can be utilized in the selection of providers.

With the present invention, the request as received is relayed, re-played for voice requests, to selected providers, and, if any provider cannot satisfy the request, the provider simply has to decline the request, typically through one a "Decline" reply, a keystroke corresponding to a "Decline" reply, or simply hanging up the communicator. As the request is relayed, all communication by the requestors and the providers is a one-way communication. Thus, there is no direct conversation required between the requestor and a provider, both parties avoiding the time consuming task of having to establish a polite discussion when the provider cannot satisfy the request. A direct conversation ensues only between the requestor and a provider who can satisfy the request. The present invention provides for automated matching and yet allows the personal, free-format style of human communication. Preferred embodiments of the present invention, in utilizing free-format requests, provide the requestors with the freedom to frame the requests as desired; the language and form of the requests not being constrained, such as by requiring the requestor to utilize predetermined keywords.

In addition, the present invention only relays requests to providers who wish to receive requests and are in a position to service the requests, for example, providers who are open and within a specific geographic zone, as dictated by the particular classification.

In the present invention, it is human decision-makers, as opposed to a computer, who receive the requests and can intelligently interpret the requests. This avoids the problems associated with matching systems which require the requests to be defined using predetermined keywords, for example, by the use of drop-down menus.

Moreover, the present invention finds application both within a private environment, such as operated by organisations for use by members of the organisation, and a public environment, which allows use by members of the public.

In certain embodiments the present invention can be configured to bias a match in favour of either the requestor or selected providers. This is envisaged to be appropriate within some niche applications, notably in the private environment.

Preferred embodiments of the present invention will now be described hereinbelow by way of example only with reference to the accompanying drawings, in which: Figure 1 diagrammatically illustrates a matching system for matching requests of users, as requestors, to providers in servicing requests in accordance with a preferred embodiment of the present invention.

The matching system comprises at least one telephony management (TM) system 1, in this embodiment first and second TM systems la, lb, for managing inbound telephone calls to and outbound telephone calls from the matching system. In another embodiment the matching system could include a single TM system 1, and in further embodiments could include any number, from tens to hundreds, of TM systems 1.

In this embodiment the TM systems la, lb are co-located, but in other embodiments could be remotely located. In one such other embodiment the TM systems la, lb could be located at separate locations in a geographic region. By way of example, in the UK, one TM system la could be located at one center, for example, London, to serve the Southern half of the UK, and the other TM system lb could be located at another center, for example, Glasgow, to serve the Northern half of the UK. In other embodiments which include many TM systems 1, the TM systems 1 could be located at principal centers, for example, cities and towns, throughout a geographic region.

The matching system further comprises a first communications network 3 which provides a communications link to and between the TM systems la, lb.

In this embodiment, where the TM systems la, lb are co-located, the communications network 3 comprises a local area network (LAN), such as an Ethernet.

In other embodiments, where the TM systems la, lb are remotely located, the communications network 3 could comprise a telephone network, preferably an integrated services digital network (ISDN). The TM systems la, lb each comprise an inbound telephony management (ITM) unit 5 for managing inbound telephone calls from requestors on inbound telephone lines 7, preferably ISDN lines. In this embodiment multiple subscriber numbering (MSN) is employed such that a plurality of requestors each requiring the same classification can be supported simultaneously.

The ITM unit 5 comprises an inbound interactive voice response (IIVR) module 11 which is connected to the inbound telephone lines 7 to monitor for inbound telephone calls and supports voice and keytones, an inbound telephony application management (ITAM) module 13 for generating request documents corresponding to the requests, in this embodiment voice requests, in each of the inbound telephone calls and transmitting the same to a provider selection unit 33a, 33b, 33c, as will be described in more detail hereinbelow, a first, classification characteristics (CC) database 15 for storing the classification characteristics for each classification which is connected to the ITAM module 13, and a requestor information (RI) database 17 for storing information relating to requestors which is connected to the ITAM module 13.

With this configuration, the CC database 15 and the RI database 17 are not accessible to the IIVR module 11, thereby securing the RI database 17 from being accessed by a third party. In this embodiment the ITM unit 5 includes an intrusion detector between the IIVR module 11 and the ITAM module 13 such as to monitor, typically by the identification of unusual packets, for third party intrusion, and thereby provide for the security of the ITAM module 13.

In this embodiment communication between the IIVR module 11 and the ITAM module 13 is by the VoiceXML communications protocol.

In this embodiment a request document generated by the ITAM module 13 includes at least a classification identifier which, in this embodiment, is the called number, that is, the telephone number called by the requestor, and identifies the classification to which the request is to be matched, a requestor identifier which, in this embodiment, is the calling line identification (CLI) of the telephone of the requestor, that is, the telephone number to which the system or positive-reply providers are to contact in reply to the request, and identifies the requestor, and a request file corresponding to the request to be relayed to providers, in this embodiment a voice file corresponding to the voice request to be re-played to providers. In an alternative embodiment the requestor identifier is a telephone number derived either from the CLI of the telephone of a requestor or information, for example, including an authentication code, provided by the requestor in making the request.

In an alternative embodiment, as will be described in more detail hereinbelow, a request document generated by the ITAM module 13 could omit the request file for the request where the file is stored in a file store 19 which is accessible to enable the request subsequently to be relayed.

In this embodiment, a request document generated by the ITAM module 13 includes a location identifier which identifies the location of the search center, where the location of the requestor cannot be determined from the requestor identifier at the provider identification unit 33a, 33b, 33c. Typical examples where the requestor identifier does not allow for the location of the requestor to be determined are as a result of the requestor being ex-directory and the requestor not having otherwise provided an address for the calling number or the calling telephone being a mobile telephone, or where the requestor requires an alternate location for the search center. In this embodiment the location identifier is a telephone number, other than the number of the calling telephone, which is provided by the requestor to represent the location of the search center.

In this embodiment the CC database 15 is a structured query language (SQL) database.

In this embodiment the components of the ITM unit 5, namely the IIVR module 11, the ITAM module 13, the CC database 15 and the RI database 17, are co-located. In other embodiments the IIVR module 11 and the ITAM module 13, can be co-located, and one or both of the CC database 15 and the RI database 17 remotely located. In this embodiment the communications network between the ITAM module 13 and the CC database 15 and the RI database 17 is a virtual private network (VPN).

In further embodiments one or both of the IIVR module 11 and the ITAM module 13 can be remotely located, and the CC database 15 and the RI database 17 co-located.

In a still further embodiment all of the components of the ITM unit 5, namely the IIVR module 11, the ITAM unit 13, the CC database 15 and the RI database 17, can be remotely located.

The TM systems la, lb each further comprise a file store 19 for storing classification greetings and prompts for the supported classifications. As mentioned hereinabove, in one embodiment the file store 19 stores the request files for each of the requests from the requestors. This storage of the request files enables the request files to be retrieved, and thus the request documents need not include the request files, which provides for significantly higher traffic flows for the same system capacity, as the request documents are much smaller in size.

The operation of the ITM units 5 of the TM systems la, lb will now be described hereinbelow.

The ITM units 5 each receive inbound telephone calls on the respective inbound telephone lines 7 from requestor communicators 20, in this embodiment telephones, with the particular ITM unit 5 which receives the telephone call being dictated by the called number, that is, the telephone number called by a requestor. In this embodiment, where the matching system is configured to operate as a trade classification matching system, a requestor is able to select from a plurality of classification entries which correspond to different kinds of goods and service providers. Each classification entry has an associated telephone number which a requestor has to dial to access the matching system for that classification, and in this embodiment is the classification identifier which determines the search criteria, the matching criteria and the termination criteria by which the matching operation is performed, as will be described in more detail hereinbelow. In one embodiment each classification entry can include a summary of one or both of the service or goods in order to enable a requestor to determine that the correct classification is being selected for the particular request.

For each inbound call, the IIVR module 11 transmits the called number and the calling number, that is, the calling line identification (CLI) of the communicator 20 of the requestor, the calling communicator, to the ITAM module 13. In this embodiment the requestor communicator 20 can be a fixed telephone, a mobile telephone, a combination fixed/mobile telephone or a PDA.

The ITAM module 13 then looks up the called number in the CC database 15, and retrieves the classification greeting file identifier for the "Classification" greeting to be played to the requestor.

Where the called number is not associated with a classification, for example, where the called number was previously used in association with a classification but is not currently in use, the ITAM module 13 instructs the IIVR module 11 to execute an "Unassigned Classification" script, which plays an "Unassigned Classification" greeting and closes the call connection.

Where the calling communicator 20 has no CLI, as when CLI barred, the ITAM module 13 instructs the IIVR module 11 to execute a "Number Withheld" script, which plays a "Number Withheld" greeting which instructs the requestor to enable the CLI of the calling telephone or provide an authentication code relating to register as an authenticated requestor.

In this embodiment the system is configured to allow a requestor to proceed with a request only when the inbound call has a CLI. By requiring the use of CLI-enabled communicators 20, abuse of the system by requestors directing replies to third parties can be prevented.

Where the calling communicator 20 has a CLI, the ITAM module 13 then looks up the CLI of the calling communicator 20 in the RI database 17 to confirm requestor information, including confirmation that location information is available for the CLI, and obtain the default requestor preferences, such as whether the requestor details for the requestor are to be provided to providers or withheld.

Where the CLI of the calling communicator 20 is that of a fixed communicator and the RI database 17 includes location information for the CLI of the calling telephone, the ITAM module 13 instructs the IIVR module 11 to execute a "Fixed Requestor" script.

Where the CLI of the calling communicator 20 is that of a mobile communicator and the RI database 17 includes no default location information for the CLI of the calling communicator 20, the ITAM module 13 determines the location of the calling communicator 20 from network information and instructs the IIVR module 11 to execute the "Mobile Requestor" script. In this embodiment the cell ID for the calling communicator 20 is utilized to determine the location of the requestor, which cell ID is representative of the cell, that is a geographic zone, in which the calling communicator 20 is located, with the ITAM module 13 looking up the cell ID in the RI database 17 to obtain the location of the calling communicator 20. In other embodiments the calling communicator 20 of the requestor can be determined by triangulation, radio positioning or satellite positioning, such as GPS. Where there is a CLI, but the location cannot be determined from the CLI, such as when the requestor is ex-directory, that is, where the requester has required the service provider not to disclose location information corresponding to the number of the requestor communicator 20, and no location information has been otherwise provided by the requestor, the ITAM module 13 looks up the search vector for the classification corresponding to the called number in the CC database 15 to determine whether there is a vector for handling location-independent requestors. Where there is a vector for handling location-independent requestors, the ITAM module 13 utilizes that vector. Where there is no vector for handling location-independent requestors, the ITAM module 13 instructs the IIVR module 11 to execute a "Location Required" script which plays a "Location Required" greeting and prompts the requestor for location information, typically the number of a known CLI-enabled telephone, for which location information is held in the CC database 15, to act as the search center.

Where there is a CLI, but the calling number is of a switchboard (manned or automated), the ITAM module 13 instructs the IIVR module 11 to execute an appropriate "Switchboard Requestor" script.

Under the "Fixed Requestor" and "Mobile Requestor" scripts, the IIVR module 11 plays a "Classification Title" greeting corresponding to the retrieved classification greeting identifier, and then a "Request Prompt" greeting which prompts for the request from the requestor. For example, where the called number corresponds to the classification "Toy Shops", in this embodiment the classification greeting would be "Welcome to the Responsa ™ classification for Toy Shops", and the "Request Prompt" greeting would be "Please leave your request after the tone and hang up when completed".

Under the "Switchboard Requestor" script, the IIVR module 11 plays in turn the "Classification Title" greeting corresponding to the retrieved classification greeting identifier, an "Extension Identification" greeting which prompts the requestor to provide an extension number, typically, through the keying in of the number or through a voice reply, and the "Request Prompt" greeting which prompts for the request from the requestor. In this embodiment the "Request Prompt" greeting is played only following a predetermined keystroke on the calling communicator 20, which keystroke confirms the provision of the extension number of the calling communicator 20. For example, where the called number corresponds to the classification "Toy Shops", in this embodiment the "Classification Title" greeting would be "Welcome to the Responsa ™ classification for Toy Shops", the "Extension Identification" greeting would be "Please leave your extension number after the tone, followed by the X key", and, following the required keystroke, the "Request Prompt" greeting would be "Please leave your request after the tone and hang up when completed".

Where a requestor wishes to set alternative preferences, for example, to withhold contact details from providers where the default is to provide details to providers, provide an alternative search center location, or alternative search parameters, the IIVR module 11 provides for the input of keystrokes to set these preferences.

In this embodiment the IIVR module 11 is configured to allow for the re- recording of requests, such as where a requestor makes a mistake in recording a request, through the keying of a predetermined keystroke.

Also in this embodiment the IIVR module 11 is configured to enable requests to be reviewed, here re-played, prior to initiating a matching operation.

In this embodiment the call connection is closed after the elapse of a predetermined period of time following the "Request Prompt" greeting, or on the requestor hanging up where this event can be identified by the IIVR module 11.

In one embodiment the ITAM module 13 stores each request in the file store 19 under an assigned file name. The TM systems la, lb each further comprise an outbound telephony management (OTM) unit 21 for managing outbound calls on outbound lines 23, preferably ISDN lines, to providers on provider communicators 24 and requestors on requestor communicators 20.

The OTM unit 21 comprises an outbound interactive voice response (OIVR) module 25 which is connected to the outbound lines 23 for effecting outbound calls to providers and requestors, and an outbound telephony application management (OTAM) module 27 for scheduling and instructing calls to the OIVR module 25 in accordance with call documents as received from a provider selection unit 33a, 33b, 33c. In this embodiment call documents can be scheduled in accordance with a priority flag, with, for example, status reports for requestors having a lower priority than requests for providers.

In operation, where effecting an outbound call to a provider, the OIVR module 25 dials the number of the provider communicator 24 as identified in the call document.

Where the call effected by the OIVR module 25 to the provider communicator 24 is answered, the OIVR module 25 executes a "Request Playback" script, which first plays a "VRS Welcome" greeting, for example "VRS for hairdressers", followed by a first short tone, and subsequently re-plays the request to the provider followed by a second short tone. In this embodiment the request is relayed, here re-played, without any interrogation, such as by speech recognition, since such is not necessary; the classification being dictated by the called number. In an alternative embodiment the request could be interrogated, where a more refined or elaborate matching system is required.

On hearing the request, the provider has the following reply options, which each have an associated keystroke: "Accept" which is confirmation that the request can be satisfied. For example, where the request is "Do you cut hair?", that is, where the requester is merely attempting to obtain details of local hairdressers, and the request is appropriate, the provider would reply "Accept".

"Probably" which is an indication that the request can probably be satisfied, but the provider has to confirm. Where the request is more complex, such as "Can you fit me in for a haircut next Thursday at 1530?", the provider may recall that next Thursday afternoon is not fully booked, but would need to check if that exact time is free, in which case the provider would reply "Probably".

"Decline" which confirms that the request cannot be satisfied. In this embodiment hanging up is the equivalent of the reply option "Decline".

"Inappropriate" which indicates that the request is either inappropriate for the classification or incomprehensible.

"Abusive" which indicates that the request is considered abusive.

In this embodiment the replies of the providers are logged, such as. o enable the classification managers to monitor the behaviour of the providers and in part the requestors, which inter alia allows for the targeted provision of guidance to requestors and providers, and even the barring of requestors or providers where behaviour is unacceptable.

For example, "Inappropriate" replies are logged against both the providers so replying and the requestors who made the requests, as repeated "Inappropriate" replies may be caused by either the requestors or the providers being confused about the purpose of a classification.

Also, "Abusive" replies are logged against both the providers so replying and the requestors who made the requests, and, in this embodiment, in addition to terminating a matching operation, repeated abusive requests, as established by confirmed "Abusive" replies, result in the respective requestors being barred from use of classifications or even the entire matching system. In this embodiment, repeated "Abusive" replies by providers, typically significantly above the average for a classification, would also be investigated.

On the provider providing a positive reply, that is, in this embodiment one of the reply options "Accept" or "Probably", the OIVR module 25 executes an "Acknowledgement" script, which plays a "Reply Acknowledged" greeting followed by a short tone, and updates the call document to include a positive reply identifier and transmits the updated call document to the originating provider selection unit 33a, 33b, 33c.

Where the contact details of the requestor have been withheld, the "Acknowledgement" script also plays a "Contact Details Withheld" greeting.

Where the contact details are not withheld, the "Acknowledgement" script also provides contact details for the requestor followed by a short tone. In one embodiment the provider can record the details of the requestor subsequently to call the requestor. In another embodiment the provider can contact the requestor directly through a predetermined keystroke. Where the requestor is following the process on line, the requestor is able to connect directly to the provider while the provider is still on line.

Where the calling communicator 20 is from an extension off a manned switchboard, the "Acknowledgement" script also provides the switchboard telephone number and the extension of the requestor so as to allow the provider to navigate the switchboard.

Where the calling communicator 20 is from an extension off an unmanned switchboard, the "Acknowledgement" script also plays a "Please stay on line until a tone is heard" greeting. In the period prior to the tone, the details of the provider are provided to the requestor and the requestor is thus provided an opportunity to connect directly to the provider who is still on line. Where immediate connection is required, the requestor is connected to the provider and thereby establishes a conversation. Where immediate connection is not established, the requestor can contact the provider later.

In this embodiment the system is configured such as to allow the "Acknowledgement" script to be re-executed with a predetermined keystroke.

In this embodiment a positive reply is either of the reply options "Accept" or "Probably". In other embodiments, and particularly for some classifications, the matching system can be configured to seek only "Accept" replies as positive replies, in which embodiments the "Request Playback" script also plays a "Decline or accept only, please" greeting, with all "Probably" and "Decline" replies being taken as negative replies.

Where the call effected by the OIVR module 25 to the provider is not answered, the OIVR module 25 assigns one of the following states as a call state identifier to the call document, that is, "Number Unobtainable" where the number held for the provider communicator 24 is unobtainable, "Engaged" where the number held for the provider is engaged, and "Rings Out" where the number held for the provider rings out and there is no reply, updates the call document to include the relevant call state identifier and transmits the updated call document to the originating provider selection unit 33a, 33b, 33c.

The TM systems la, lb each further comprise a telephony management (TM) communications network 29 which provides a communications link to the first main communications network 3 and between the ITM unit 5, in this embodiment both the IIVR module 11 and the ITAM module 13 separately, the file store 19, and the OTM unit 21, in this embodiment both the OIVR module 25 and the OTAM module 27 separately. In one embodiment the communication with the ITM unit 5, the file store 19 and the OTM unit 21, and between the IIVR module 11 and the ITAM module 13, is coded, typically either an encrypted communication or an authenticated communication, such as a signed communication.

In this embodiment, where the ITM unit 5, the file store 19 and the OTM unit 21 are co-located, the TM communications network 29 comprises a local area network (LAN), such as an Ethernet.

In other embodiments, where the ITM unit 5, the file store 19 and the OTM unit 21 are remotely located, the TM communications network 29 could comprise an established telephone network, preferably an ISDN network.

The matching system further comprises at least one provider selection unit 33, in this embodiment three provider selection units 33a, 33b, 33c, for selecting the providers to be contacted in matching a request and scheduling the contact with the providers by the OTM units 21 of the TM systems la, lb. It will be appreciated that the matching system can include any number of provider selection units 33; this embodiment including three provider selection systems 33a, 33b, 33c simply by way of exemplification.

In this embodiment the provider selection units 33a, 33b, 33c are co-located, but in other embodiments ones or all of the provider selection units 33a, 33b, 33c could be remotely located.

In this embodiment the provider selection units 33a, 33b, 33c are each configured to support all of the addressable classifications, but in other embodiments, particularly where there are many tens or hundreds of the provider selection units 33a, 33b, 33c, the provider selection units 33a, 33b, 33c could be configured to support only one classification or a sub-set of the addressable classifications.

The matching system further comprises a second main communications network 34 which provides a communications link to and between the provider selection units 33a, 33b, 33c. In this embodiment, where the provider selection units 33a, 33b, 33c are co- located, the second main communications network 34 comprises a local area network (LAN), such as an Ethernet.

In other embodiments, where the provider selection units 33a, 33b, 33c are remotely located, the second main communications network 34 could comprise a telephone network, preferably an integrated services digital network (ISDN).

The matching system further comprises a router 35 for routing request documents and call documents between respective ones of the TM systems la, lb and the provider selection units 33a, 33b, 33c.

The provider selection units 33a, 33b, 33c each include a classification information (CI) database 37 which contains information, including provider characteristics, regarding each of the providers in each of the classifications supported by the respective provider selection unit 33a, 33b, 33c, provider list building parameters for each classification, match criteria for each classification and termination criteria for each classification, a second requestor information (RI) database 39 which contains information, including requestor characteristics, regarding each of the requestors, a document scheduler 41 for scheduling documents to and from the respective one of the provider selection units 33a, 33b, 33c, and a provider list building unit 43 which, for each request, builds a sorted provider list of providers from the providers contained in the CI database 37 for the classification to which the request is directed.

The CI database 37 contains information regarding each of the providers in each classification, each provider being referenced by a provider identifier. The information held for each provider includes the name of the provider, the address of the provider, the contact number for the provider, provider characteristics, and system history information, including the number of requests delivered, the number of positive replies, that is, in this embodiment as one of "Accept" or "Probably" replies, and in other embodiments as an "Accept" reply, the number of negative replies, that is, in this embodiment as a "Decline" reply, and in other embodiments as one of "Decline" or "Probably" replies, the number of "Inappropriate" replies, and the number of "Abusive" replies. In this embodiment the CI database 37 is a spatial-join database, that is, a database which provides for spatial operations.

The provider list building unit 43 includes a provider selection module 44 which is configured to create one or more candidate provider lists in accordance with a predetermined listing mechanism for the classification to which the request is addressed, and, where the listing mechanism utilizes a location-based vector, based on a search center, which is usually the location of the requestor, but can be an alternative location as specified by the requestor, or the location of the first provider having replied positively to a request where a search is re-centered. As will be described in more detail hereinbelow, the creation of a plurality of candidate provider lists provides for a mix of providers, for example, a mix of local and national providers.

In this embodiment the provider selection module 44 employs the following listing mechanisms to create the one or more candidate provider lists:

Listing Mechanism A - Closest

This listing mechanism creates a candidate provider list of candidate providers closest, in terms of a spatially-related parameter, typically direct (point-to-point) distance, travelling distance or travelling time, to the search center. In one embodiment the candidate provider list can be truncated by number, that is, to include a predetermined number of closest providers to the search center. In another embodiment the candidate provider list can be truncated by an upper limit to the spatially-related parameter, that is, to include all of the providers within a spatial zone of predetermined size.

Listing Mechanism B - Closest Cluster This listing mechanism creates a candidate provider list of candidate providers which represent the closest set of providers, as a closest cluster, which satisfy the cluster characteristics for the classification to which the request is addressed. In this embodiment the cluster characteristics define the closest cluster as the closest set of providers comprising at least a predetermined number of providers within a spatial zone, typically direct (point-to-point) distance, travelling distance or travelling time, of predetermined size.

Listing Mechanism C - Greatest Density Cluster

This listing mechanism creates a candidate provider list of candidate providers which represent the set of providers, as a cluster but not necessarily the closest cluster, which satisfy the density characteristics for the classification to which the request is addressed. In this embodiment the density characteristics define the cluster as the set of providers comprising the highest number of providers within a first spatial zone, typically direct (point-to-point) distance, travelling distance or travelling time, of a first predetermined size within a second spatial zone of a second predetermined size of greater size than the first spatial zone and centered about the search center. This listing mechanism is effective to locate the largest town or city within the geographic zone, and avoids providers outside of the main concentrations, which are likely to be more widely dispersed. For this reason, it is expected that this listing mechanism will commonly be used as part of a series of searches.

Listing Mechanism D - Segment

This listing mechanism creates a candidate provider list of candidate providers from within a segment of a circle which has a predetermined segment angle and a radius of either a first predetermined size, typically direct (point-to-point) distance, travelling distance or travelling time, to the search center or a second smaller, distance where the segment of the smaller radius encompasses a predetermined number of candidate providers. In this embodiment the candidate provider list is ordered in terms of a spatially-related parameter, typically direct (point-to-point) distance, travelling distance or travelling time, from the search center, with the closest being listed first in the list. Where re-invoked as result of the matching operation not being successful, a subsequent segment, either in a clockwise or counter-clockwise sense, is utilized. This listing mechanism has been developed for use where there is a variable, but high density of providers in a region of interest, and the requestor is keen to identify providers within a general travel direction extending from the search center. In this embodiment the segment of the circle is randomly selected.

Listing Mechanism E - All

This listing mechanism creates a candidate provider list of all of the candidate providers with a spatial zone, in terms of a spatially-related parameter, typically direct (point-to-point) distance, travelling distance or travelling time, of a predetermined size centered about the search center.

Listing Mechanism F - Threshold

This listing mechanism creates a candidate provider list of candidate providers which satisfy the threshold characteristics for the classification to which the request is addressed. In this embodiment the threshold characteristics define providers which satisfy a predetermined threshold criteria, for example, above or below at least one predetermined threshold value. Examples of threshold criteria include turnover, number of employees, quality rating, and speed of delivery.

The provider list building unit 43 further includes a provider sorting module 45 for creating provider contact lists by sorting the candidate providers in the candidate provider lists created by the provider selection module 44 in accordance with a predetermined sorting mechanism for the classification to which the request is addressed. In one embodiment the created provider contact lists can be truncated. In this embodiment the provider sorting module 45 can employ the following sorting mechanisms:

Sorting Mechanism A - None

This sorting mechanism provides for no sorting of a candidate provider list. The provider contact list has the order of the candidate provider list as created by the provider selection module 44.

Sorting Mechanism B - Random

This sorting mechanism creates a provider contact list by randomizing a candidate provider list as created by the provider selection module 44.

Sorting Mechanism C - Take-Turns

This sorting mechanism creates a provider contact list by sorting a candidate provider list as created by the provider selection module 44 in accordance with the last contact with the providers so as to ensure that the providers are contacted in turn according to a specified ratio, with the last-contacted provider being at the bottom of the list. In this embodiment a log is maintained as to the previous contact with the providers.

Sorting Mechanism D - Closest

This sorting mechanism creates a provider contact list by sorting a candidate provider list as created by the provider selection module 44 in terms of a spatially-related parameter, typically direct (point-to-point) distance, travelling distance or travelling time, to the search center, with the closest being listed first and so on. Sorting Mechanism E - Ranked

This sorting mechanism creates a provider contact list by sorting a candidate provider list as created by the provider selection module 44 into ranked order in accordance with a particular ranking parameter, for example, by turnover, number of employees, quality rating, and speed of delivery. This sorting mechanism is particularly suited to searching for providers where the location is unimportant. These providers will tend to be national providers, and the location of these providers is only relevant insofar that the providers encompass the location of the requestor. A typical classification would be insurance services where contact with the providers would be by telephone. It will be appreciated that this sorting mechanism can create lists that never include certain providers and, for that reason, is usually utilized as one of a series of searches.

In this embodiment, where the list building criteria for a selected classification requires more than one contact provider list, the list building unit 43 is configured to merge the plurality of provider contact lists to create a single provider contact list. The creation of a single provider contact list from a plurality of provider contact lists finds application where a mix of providers, for example, local and national providers, are to be selected. A typical classification to which such a provider contact list is appropriate is that of computer suppliers, where a requestor may want a local provider or perhaps a national provider.

The provider contact lists built by the list building unit 43 include a plurality of state fields for each provider entry, but with the restriction that a provider can be included in only one field. In this way, the state of the provider can be maintained. Several states can be grouped as meaning that the request has not yet been delivered, these including the "Available", "Out of Hours", "Engaged" and "Ring Out" states. Final response states include the "Accepted", "Declined", "Probably", "Inappropriate" and "Abusive" states. In building a provider contact list, a database query is performed to establish which providers are available. This list is examined and the providers are sorted into "Available" and "Out of Hours" states. As each "Out of Hours" provider becomes available, an event is queued to move the provider from the "Out of Hours" field to the "Available" field. Similarly, as each "Available" provider becomes unavailable, an event is queued to move the provider from the "Available" to the "Out of Hours" state.

In one embodiment the provider selection units 33a, 33b, 33c can be configured to provide for re-centering of the search center to the location of a provider providing the first positive reply. Where re-centering is enabled, and a provider has been identified who has provided a positive reply, the provider list building unit 43 is re-invoked to create a further provider contact list which utilizes the location of the identified provider as the search center. Such re-centering is utilized to identify providers which are as close together as possible, thereby attempting to avoid the identification of providers which are widely spaced, for example, two providers which are in opposite directions, and hence widely separated, from the search center. It is envisaged that re-centering will find application in identifying a number of relatively-closely located providers to be visited by the requestor, such as would be desired in enabling a comparison of the services or goods provided by the providers.

The document scheduler 41, in scheduling call documents to the OTM units 21 of the TM systems la, lb is configured to perform a calculation to compute how many providers can be concurrently called and whether the calls are "Accept-Only". That number is used to determine if the "In Progress" list of providers to be contacted can accommodate another provider. If another provider can be accommodated, the first provider from the "Available" list is used. If the "Available" list is empty, the document scheduler 41 waits for an "Engaged", "Ring Out" or "Out of Hours" provider to become available. A further interface method is utilized to move a provider from one list to another, thereby allowing the document scheduler 41 to move an "In Progress" provider to the final response state, such as "Accepted", "Declined", "Probably", etc. This is the same method used to move providers between "Available" and "Out of Hours" and vice versa. The use of the same method allows multiple checks to be performed, such as requeuing an "Engaged" provider when the provider is "Out of Hours".

The provider selection units 33a, 33b, 33c are configured to terminate searching where the match criteria is satisfied, or, if the match criteria is not met, one of the following termination criteria where enabled. In this embodiment, for each classification, any of the termination criteria can be enabled or disabled. Where any of the termination criteria are enabled, the provider selection units 33a, 33b, 33c terminate searching where termination criteria are satisfied, and a termination report is delivered to the respective provider.

In this embodiment the termination criteria are as follows:

Termination Event A - Number of Declines

For this termination event, termination occurs when a predetermined percentage of the providers on the provider contact list for the respective request have been contacted. The provider selection units 33a, 33b, 33c are configured to contact as many of the selected providers as possible, in retrying providers where the telephone numbers for those providers are engaged or ring out without answer. As will be appreciated, the telephone numbers for some providers may be permanently engaged or ring out, and, as such, the system cannot necessarily contact all selected providers.

Termination Event B - Elapse of Predetermined Period

For this termination event, termination occurs where a predetermined time limit has elapsed. In preferred embodiments termination occurs at the first of a predetermined time period having elapsed since the request was made by the requestor or a predetermined percentage of providers on the provider contact list for a request have not been contacted within a predetermined period since the request was made by the requestor.

Termination Event C - Abusive Request

For this termination event, termination occurs where a predetermined number, in this embodiment two, of the providers report a request as abusive, an "Abusive" reply being a reply option of the providers.

Termination Event D - Inappropriate Request

For this termination event, termination occurs where a predetermined number, in this embodiment two, of the providers report a request as inappropriate, an "Inappropriate" reply being a reply option of the providers.

Termination Event E - List Exhausted

For this termination event, termination occurs where the contact provider list is exhausted.

In a preferred embodiment the number of "Incomprehensible" or "Inappropriate" replies is set at a number greater than one, for example, two or three, such that a single "Incomprehensible" or "Inappropriate" reply is not sufficient to cause termination of the matching operation, as could be provided by a rogue provider or as a result of a simple mistake on the part of a provider.

Where the system has not satisfied the matching criteria within a reasonable time, the requestor is contacted and provided with a progress report. The system continues until either satisfying the matching criteria or one of the termination criteria. If the termination criteria is satisfied for a request, the requestor is contacted to report the end of the search and the results achieved. In general, if the requestor hears nothing, the requestor can be confident that the system has been successful in matching the request in accordance with the matching criteria for the classification. Progress or termination reports are returned to a switchboard requestor, but the reports are always preceded by the recorded name and extension number of the requestor, so that the switchboard operator can pass the message on to the requestor.

In this embodiment the system also provides for the initiation of the matching operation to be delayed. Often there are occasions when a person would like to make a request, but he is aware that most or all of the potential offers are currently closed. The system can still be used on these occasions. A requestor can make a request at any time of the day, for example, at 0200, knowing that the request is unlikely to be matched. Any selected providers active at that time will be contacted, allowing those providers an opportunity to respond to the request. The active periods will be known for all providers. During normal daytime working hours for many providers, the number of available providers will be much greater. If this is the case, the requestor will be given a termination report as usual, but the system is configured to relay the request again at a specified other time when a greater number of providers in the given classification are active. In this embodiment the system is configured such as to allow this feature to be over-ridden through the application of a predetermined keystroke. As a default, the act of hanging up is taken to require that the request be relayed at a time that is more likely to obtain a match.

In this embodiment the system is also configured such that a requester can specify an alternate location for the search center which is not that associated with the CLI of the calling telephone. In this embodiment, the IIVR module 11 provides for this feature to be enabled with a predetermined keystroke, and, when enabled, the IIVR module 11 executes an "Alternate Location" script which plays the "Alternate Location" greeting and prompts the requestor to input the telephone number of the alternate search center, followed by another predetermined keystroke. The system then utilizes the alternate location telephone number to determine the search center. The system only uses the alternate location telephone number for building the provider contact list and not as the calling number. The calling number, usually the CLI, is utilized as the telephone number to which status or termination reports are delivered.

This feature provides for the circumstance where the requestor wishes to identify providers within a different geographic region. For example, suppose the requestor is travelling away to visit friends for a weekend and wants to locate a French restaurant in the region to be visited, the requestor would perform the "Alternate Location" keystroke during the classification greeting, and enter the enter the alternate telephone number, typically the telephone number of the friends to be visited, followed by a "Completion" keystroke, and then leave the request, for example, "A nice French restaurant, table for four, 1930 Saturday night, please phone back tonight.". Where the contact mode is set to provide requestor details, any providers giving a positive reply would be provided with the calling number of the requestor, as opposed to the alternate location telephone number.

In this embodiment the system is also configured to allow a requestor to remain on line and follow the matching operation. This would typically be where a requester believes that a match is quite likely to be achieved quickly. In this embodiment his feature is enabled through a predetermined keystroke on completion of the recordal of the request, and disabled by repeating the predetermined keystroke. The matching system reports each event in real-time, for example, "Just Cuts, declined", "His Hair, declined", "Cool Cuts, accepted", etc.. In this mode, each provider which provides a positive reply, in this embodiment one of an "Accept" or a "Probably", is assigned a particular keystroke, and performing the relevant keystroke establishes a call to the provider.

In this embodiment, for each requestor, the configuration options include a contact mode setting, which allows the requestor to configure the system, in default, either to withhold the contact details of the requestor from providers, in which case any reports to the requestor are provided with the details of the identified providers which have provided a positive reply in order to allow the requestor to contact the providers, or provide the contact details of the requestor to the identified providers on acceptance of the request, such that the accepting provider can contact the requestor directly.

In this embodiment the system is configured to enable a requestor to override the default contact mode setting, here by performing a predetermined keystroke during the classification greeting. In this embodiment, unless specifically configured, the default reply mode setting is to provide . requestor details. Where the default contact mode setting is set to provide details, the application of the predetermined key acts to switch the contact mode setting to from that of provide requestor details to withhold requestor details, whereupon the contact mode greeting "Requestor details will be withheld" is played, followed by the usual record request tone. Where the default contact mode setting is set to withhold details, application of the predetermined key acts to switch the contact mode setting from that of withhold requestor details to provide requestor details, whereupon the contact mode greeting "Requestor details will be supplied" is played, followed by the usual record request tone.

Where the contact mode setting is set to withhold requestor details, the system, having identified the providers for a request, calls the requestor on the calling number, and provides the termination report which includes the details of the providers, in this embodiment, for each provider, a contact name, either the name of the provider or a contact person at the provider, and the contact number. In this embodiment each of the providers mentioned in the termination report is assigned an associated key on the keypad, such as to allow the requestor to speed dial a selected one of the providers. Where the requestor does not take the return call from the system, and the calling number of the requestor has an attached answer machine, the call is taken by the answer machine, with the termination report being recorded such as to enable the requestor to listen to the return call later. Where the calling number rings out, and the calling number of the requestor does not have an attached answer machine, the system calls back at set intervals until the call is made. At the time of registration, the configuration details include the business availability of the provider, that is, the business working hours for each of the seven days of the week. Within these working hours, the system, as a default, is configured to assume that the provider wishes to receive requests. In this embodiment the system is configured such as to allow the provider to remove himself/herself from the classification and therefore not receive any further requests. Note that if the provider removes himself/herself from the classification, the provider will not appear in any lists built by the list building units 43 of the provider selection units 33a, 33b, 33c until the provider positively re-introduces himself/herself into the classification. This feature allows businesses to turn the service off for long breaks, for example, holidays. Outside business hours, the system does not contact the provider, who, it is assumed, does not want to receive requests. In this embodiment a provider can temporarily alter the assigned business hours by setting one of "Open" or "Closed" states, but so setting the business is only a temporary function, and, if the assigned business are not reset before the next business hours session, the default times for hours of business are adopted.

In this embodiment the system enables a provider to block requests from requestors who cannot be serviced. A typical example is because the location of the requestor is not a location served by the requestor. Another typical example is where the provider only provides a service for a particular group of people, such as for the young as opposed to the elderly, and a request from an elderly person could not be serviced. This does not bias the search, but merely obviates inappropriate contacts.

In this embodiment the system also enables a provider to block requests from requestors where the contact details of the requestors are withheld. In such circumstances, a provider could be concerned that competitors would covertly use the system to gather intelligence.

In this embodiment these preferences are set by a classification manager using the classification management unit 49. The matching system further comprises a classification management unit 49 which provides for the maintenance of the classification databases, that is, the CC database 15 and the CL database 37, and the requestor databases, that is, the first and second RI databases 17, 39. In particular, the classification management unit 49 provides for the updating of provider entries, the inclusion of new provider entries, the alteration of the list building parameters for any classification, and the inclusion of new classifications. In this embodiment the classification management unit 49 includes a web interface to allow for remote operation. In a preferred embodiment the classification management unit 49 is operated by a plurality of classification managers, each of which are assigned to and manage one or more classifications.

Finally, it will be understood that the present invention has been described in its preferred embodiments and can be modified in many different ways without departing from the scope of the invention as defined by the appended claims.

For example, in the described embodiments, the system is configured to utilize voice requests made using a telephone, but the use of other communicators 20, 24 is envisaged, for example, PDAs, personal computers, set-top boxes, games devices and games consoles, that is, any apparatus which has a communications function, and also other formats for the receipt and delivery of requests, for example, text-encoded requests, such as SMS and e-mail, pictoral requests, typically containing drawings, stills or video, such as MMS and EMS, and fax requests. Indeed, requests could be made in one format, for example, as voice requests, and delivered in another format, for example, SMS requests. Also, requests could be multi-format requests, for example, comprising voice and text-encoded request components or text- encoded and pictoral request components.

In general, the providers are the persons who respond to the respective requests, but there are exceptions. One such other provider is an observing provider who can only receive requests, but not respond to the requests. Another such provider is a split provider, where a request is received by one person, usually the decision-maker who replies to the request, and transferred to another person further to handle the request, for example, in handling the customer engagement. A further such provider is a sorting provider who receives the request and acts to re-direct the request to another provider.

As an example of a sorter provider, the providers can have a hierarchy. Thus, "Car Sales" could have children of "New Cars" and "Second Hand Cars", which could themselves have children by make of car, for example, Ford, Vauxhall, VW etc. The system can support this hierarchy, but, consistent with the philosophy that humans are the best people to process requests, the system only supports cascading of classifications via human sorters. The matching process is as follows. A requester decides that he/she is looking for a new blue Ford Focus 1.8 Ghia. The requestor dials the telephone number for the classification "Car Sales" and leaves a request. The request is passed to selected providers within that classification. One provider may, however, be a dealership which sells many makes of car. For this provider, other departments have previously been configured with children described as hereinabove. In this case, the person that hears the request acts a sorter who decides to which department the request should be presented. The system is configured to recognize that this provider is a sorter and therefore expects to receive a keycode related to one of the previously set up departments. On receiving this keycode, the system presents the request to the newly-identified provider, which itself could be set up as a sorter provider. After looping through this procedure one or more times, the request will be made to a provider where no further sorting is required.

Further, where the system is to be utilized as a private matching system, the set-up for a private matching system is similar to above except that the matching system presents the request to a provider which has an internal, private matching system. In this situation, all the keycodes that are used to obtain a response are logged, as these codes allow the hierarchy to be navigated to report and provide contact details.