WO2004042609A2

WO2004042609A2 - A list building unit and contact system

Info

Publication number: WO2004042609A2
Application number: PCT/GB2003/004811
Authority: WO
Inventors: Stephen John Isaac; Jeremy Dennis Chatfield
Original assignee: SITRA Ltd
Current assignee: SITRA Ltd
Priority date: 2002-11-06
Filing date: 2003-11-06
Publication date: 2004-05-21
Anticipated expiration: 2005-05-06
Also published as: WO2004042609A3

Abstract

A list building unit for building a list of providers, each having an assigned geographic location, in response to a request by a user as a requestor, wherein the list building unit comprises a list building module for building a list of providers, where the providers are located in an elongate geographic zone extending from a geographic location or represent a set of providers, as a cluster, which satisfy cluster characteristics for the classification to which the request is addressed.

Description

A LIST BUILDING UNIT AND CONTACT SYSTEM

The present invention relates to a list building unit for building a list of providers, and a contact system for contacting ones of the providers in the list of providers, the providers providing goods or services.

In one aspect the present invention provides a list building unit for building a list of providers, each having an assigned geographic location, in response to a request by a user as a requestor, the list building unit comprising: a list building module for building a list of providers located in an elongate geographic zone extending from a geographic location.

In one embodiment the geographic location is provided by the requestor and derived from the calling line identity of a communicator by which the requestor makes a request.

In another embodiment the geographic location is provided by the requestor and is a geographic location other than the current geographic location of the requestor.

Preferably, the list building module is configured to build a list of providers in accordance with a predetermined listing mechanism attributed to the classification for the request.

More preferably, the list building module is configured repeatedly to build a list of providers located in another, new elongate geographic zone extending from the geographic location provided by the requestor until a list of providers in accordance with the predetermined listing mechanism attributed to the classification for the request can be built.

In one embodiment the new elongate geographic zone is randomly selected.

In another embodiment each successive geographic zone is angularly spaced by a predetermined angle from the previous geographic zone Preferably, the elongate geographic zone comprises a segment of a circle.

In another aspect the present invention provides a contact system comprising: the above-described list building unit; and a contact unit for contacting at least ones of the providers in the list of providers.

In a further aspect the present invention provides a list building unit for building a list of providers, each having an assigned geographic location, in response to a request by a user as a requestor, the list building unit comprising : a list building module for building a list of providers which represent a set of providers, as a cluster, which satisfy cluster characteristics for a classification to which the request is addressed.

In one embodiment the cluster characteristics define a closest cluster of providers comprising at least a predetermined number of providers within a geographic zone based on a geographic location provided by a requestor.

In another embodiment the cluster characteristics define a cluster of providers of greatest density within a geographic zone based on a geographic location provided by a requestor.

In a preferred embodiment the geographic zone is of a predetermined size, typically direct (point-to-point) distance, travelling distance or travelling time.

In one embodiment the geographic location provided by the requestor is derived from the calling line identity of a communicator by which the requestor makes a request.

In another embodiment the geographic location provided by the requestor is a geographic location other than the current geographic location of the requestor. In a still further aspect the present invention provides a contact system comprising: the above-described list building unit; and a contact unit for contacting at least ones of the providers in the list of providers.

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 local trade directories, such as the Yellow Pages^® or Thomson Directory^® in the UK, and, when seeking goods or services, a person would use a local trade 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 be 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.

In a preferred embodiment the present invention is to be utilized in an automated matching system, to be known as the Responsa ™ matching system, which provides for the matching of requests, in particular voice requests, and especially free-format requests, to providers.

In one 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.

A 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.

In this way, automated matching is achieved in a manner which allows for a 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. 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;

Figure 2 illustrates a representation of Listing Mechanism A (Closest) as utilized by the provider selection module of the matching system of Figure 1;

Figure 3 illustrates a representation of Listing Mechanism B (Closest Cluster) as utilized by the provider selection module of the matching system of Figure 1;

Figure 4 illustrates a representation of Listing Mechanism C (Greatest Cluster Density) as utilized by the provider selection module of the matching system of Figure 1;

Figure 5 illustrates a representation of Listing Mechanism D (Segment) as utilized by the provider selection module of the matching system of Figure 1;

Figure 6 illustrates a representation of Listing Mechanism E (All) as utilized by the provider selection module of the matching system of Figure 1;

Figure 7 illustrates a representation of three candidate provider lists as created by the provider selection module of the matching system of Figure 1;

Figure 8 illustrates a representation of three provider contact lists as created by the provider sorting module of the matching system of Figure 1 from the three candidate provider lists of Figure 7; Figure 9 illustrates a representation of a merged provider contact list as created by the provider list building unit of the matching system of Figure 1 from the three provider contact lists of Figure 8; and

Figure 10 illustrates a representation of the re-centering of the search center to the location of a provider providing a positive reply as performed by the provider selection units of the matching system of Figure 1.

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 to 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 CPLs 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 CPLs 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 CPLs:

Listing Mechanism A - Closest

This listing mechanism creates a candidate provider list CPL 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 CPL 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 CPL 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.

By way of exemplification, Figure 2 represents the identification of a predetermined number of providers P closest to the search center SC.

Listing Mechanism B - Closest Cluster

This listing mechanism creates a candidate provider list CPL of candidate providers which represent the closest set of providers, as a closest cluster, which satisfies 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.

By way of exemplification, Figure 3 represents the closest cluster C of providers P which satisfies the cluster characteristics for the classification to which a request is addressed relative to the search center SC.

Listing Mechanism C - Greatest Density Cluster

This listing mechanism creates a candidate provider list CPL of candidate providers which represent the set of providers, as a cluster but not necessarily the closest cluster, which satisfies the cluster 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.

By way of exemplification, Figure 4 represents the cluster C of providers P which satisfies the cluster density characteristics for the classification to which a request is addressed relative to the search center SC.

Listing Mechanism D - Segment

This listing mechanism creates a candidate provider list CPL 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 CPL 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.

By way of exemplification, Figure 5 represents the identification of a segmented circle comprising a plurality of equal segments SEGs each having a segment angle θ and a geographic radius r from the search center SC. As embodied, a first segment SEG1 is randomly selected, but this segment SEG1 does not encompass a minimum number n of providers P. Thus, a second segment SEG2, which is the subsequent segment in the clockwise sense, is selected, but this segment SEG2 again does not encompass the minimum number n of providers P. So, a third segment SEG3, which is the subsequent segment in the clockwise sense, is selected, and this segment SEG3 encompasses the minimum number n of providers P. The providers P in this third segment SEG3 are all within a general travel direction extending from the search center SC, and thus allow for the requestor to visit the identified providers P when travelling in one general travel direction, thereby avoiding excessive travelling.

Listing Mechanism E - All

This listing mechanism creates a candidate provider list CPL 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.

By way of exemplification, Figure 6 represents all of the providers P within a geographic radius r from the search center SC.

Listing Mechanism F - Threshold

This listing mechanism creates a candidate provider list CPL 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.

By way of exemplification, Figure 7 represents an embodiment in which the listing mechanism for the classification to which a request is addressed requires three candidate provider lists CPL1, CPL2, CPL3.

The provider list building unit 43 further includes a provider sorting module 45 for creating provider contact lists PCLs by sorting the candidate providers in the candidate provider lists CPLs 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 PCLs 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 CPL. The provider contact list PCL has the order of the candidate provider list CPL as created by the provider selection module 44.

Sorting Mechanism B - Random

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

Sorting Mechanism C - Take-Turns

This sorting mechanism creates a provider contact list PCL by sorting a candidate provider list CPL 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 PCL by sorting a candidate provider list CPL 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 PCL by sorting a candidate provider list CPL 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.

By way of exemplification, Figure 8 represents an embodiment in which the sorting mechanism for the classification to which a request is addressed requires the first candidate provider list CPL1 to be sorted by sorting mechanism B (Random), the second candidate provider list CPL2 to be sorted by sorting mechanism C (Take-Turns) and the third candidate provider list CPL1 to be sorted by sorting mechanism A (None).

In this embodiment, where the list building criteria for a selected classification utilizes a plurality of provider contact lists PCLs, the list building unit 43 is configured to merge the plurality of provider contact lists PCLs to create a single, merged provider contact list PCL. The creation of a single merged provider contact list PCL from a plurality of provider contact lists PCLs finds application where a mix of providers, for example, local and national providers, are to be selected. A typical classification to which such a merged provider contact list PCL is appropriate is that of computer suppliers, where a requestor may want a local provider or perhaps a national provider. By way of exemplification, Figure 9 represents a merged provider contact list PCL as derived from the provider contact lists PCL1, PCL2, PCL2, in this embodiment merged randomly.

The provider contact lists PCLs 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 PCL, 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 a positive reply, in a preferred embodiment a provider providing a 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 PCL 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.

By way of exemplification, Figure 10 represents the re-centering of the search center SC, from a first search center SCI as provided by the requestor, for example, as determined from the CLI of the communicator 20 of the requestor, to a second search center SC2 corresponding to the location of a provider P providing a first positive reply.

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 PCL 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 re-trying 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 PCL 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 PCL 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.

Claims

1. A list building unit for building a list of providers, each having an assigned geographic location, in response to a request by a user as a requestor, the list building unit comprising: a list building module for building a list of providers located in an elongate geographic zone extending from a geographic location.

2. The list building unit of claim 1, wherein the geographic location is provided by the requestor and derived from the calling line identity of a communicator by which the requestor makes a request.

3. The list building unit of claim 1, wherein the geographic location is provided by the requestor and is a geographic location other than the current geographic location of the requestor.

4. The list building unit of any of claims 1 to 3, wherein the list building module is configured to build a list of providers in accordance with a predetermined listing mechanism attributed to the classification for the request.

5. The list building unit of claim 4, wherein the list building module is configured repeatedly to build a list of providers located in another, new elongate geographic zone extending from the geographic location provided by the requestor until a list of providers in accordance with the predetermined listing mechanism attributed to the classification for the request can be built.

6. The list building unit of claim 5, wherein the new elongate geographic zone is randomly selected.

7. The list building unit of claim 5, wherein each successive geographic zone is angularly spaced by a predetermined angle from the previous geographic zone

8. The list building unit of any of claims 1 to 7, wherein the elongate geographic zone comprises a segment of a circle.

9. A contact system comprising: the list building unit of any of claims 1 to 8; and a contact unit for contacting at least ones of the providers in the list of providers.

10. A list building unit for building a list of providers, each having an assigned geographic location, in response to a request by a user as a requestor, the list building unit comprising: a list building module for building a list of providers which represent a set of providers, as a cluster, which satisfy cluster characteristics for a classification to which the request is addressed.

11. The list building unit of claim 10, wherein the cluster characteristics define a closest cluster of providers comprising at least a predetermined number of providers within a geographic zone based on a geographic location provided by a requestor.

12. The list building unit of claim 10, wherein the cluster characteristics define a cluster of providers of greatest density within a geographic zone based on a geographic location provided by a requestor.

13. The list building unit of claim 11 or 12, wherein the geographic zone is of a predetermined size, typically direct (point-to-point) distance, travelling distance or travelling time.

14. The list building unit of any of claims 11 to 13, wherein the geographic location provided by the requestor is derived from the calling line identity of a communicator by which the requestor makes a request.

15. The list building unit of any of claims 11 to 13, wherein the geographic location provided by the requestor is a geographic location other than the current geographic location of the requestor.

16. A contact system, comprising: the list building unit of any of claims 10 to 15; and a contact unit for contacting at least ones of the providers in the list of providers.