Request matching system and method

Request matching system and method

The present invention relates to a request matching system and method for matching a request of a user as a requester and a provider serving the request. The present invention can be applied to many fields, especially when the user as the requester wants to be interested in The community is the classification structure of requests from multiple providers that are collectively classified.

It is conceivable that the present invention is particularly applicable to aspects related to trade classification, in which providers are grouped according to the goods or services provided.

Such trade classifications are currently implemented in local trade directories, such as the Yellow Pages or Thomson Directory in the UK, and when looking for goods or services, a person will use Local catalogs to locate providers of goods or services.

In using such a catalog, a person will first determine the category of goods or services most likely to provide, consult the corresponding part of the catalog, select one or more providers, and then call those providers. When calling providers, you will have to repeat the same request to each provider, such as "Can you provide goods/services X at price Y before date Z?". Often, especially if the request is specific, such as "Do you have a stock of car part X?", this person will have to call many of the selected providers before finding a provider that can satisfy the request. A. This is especially true when multiple providers must be identified in order to compare prices, delivery times, etc.

Such a process is time-consuming, because it is necessary to identify possible providers first, and establish a dialogue with multiple providers at the same time, until one or more providers that can satisfy the request are identified, and the cost of such a process is relatively high because This incurs phone costs associated with calls made by multiple providers.

Although it is conceivable that the present invention is particularly applicable to aspects related to trade classification, the present invention can also be applied to aspects related to many other classification structures.

One such other classification structure is broadcast classification, where requests are broadcast to multiple providers, which makes it possible to get answers from all providers, and provide records of one or both of the positive or negative responses from the providers, and Those providers who did not respond. It is conceivable that such classification can find applications in obtaining information in response to queries, such as building marketing catalogs or voting.

Another such other classification structure is the community classification, in which people with common interests are collectively classified, which allows the requestor to make a request to multiple or all other people in the community classification as the provider, where the requestor is also It may be a provider in the classification of associations. An example in the classification of associations is a local mutual aid group whose members provide ad hoc services, in which requests for help can be sent to the members of the mutual aid group.

In addition, such other classification structure is task classification, in which requests are made to multiple providers that require tasks to be performed. It is conceivable that this classification is particularly useful in a collective environment, where requests can be made to specific departments such as purchasing or marketing departments.

In addition, such other classification structure is a promotion classification, in which a specific promotion is typically carried out in a short period of time, and there are multiple providers supporting the promotion. An example of a promotion classification is a holiday promotion, such as a fixed-price weekend promotion, in which a provider who wishes to join the promotion determines to participate in the classification. In a preferred embodiment, the provider will be able to determine the category of participation and exit based on the availability of the goods or services it provides.

The object of the present invention is to provide a matching system and method for matching the request of a user as a requester with a provider without the requester identifying possible providers and contacting those providers to determine whether they satisfy the request.

On the one hand, the present invention provides a matching system for matching the request of a user as a requester and a provider of servicing these requests. Each requester has at least one communication machine for issuing requests and processing corresponding replies. , And each provider has at least one communication machine for processing requests and corresponding replies, the system includes: at least one request receiving unit for receiving requests from the requester; at least one request relay unit for Provide to relay each request to a selected provider for processing; at least one response receiving unit for receiving a response from the provider, and the received response is made by the corresponding provider as the decision maker in accordance with the corresponding request; and at least An information providing unit for performing one or both of the following operations for each request: providing any provider that provides a positive answer to the corresponding request with information about the corresponding requester, where a positive answer indicates that the provider can satisfy the request ; And provide the corresponding requester with information about the response to the corresponding request from the selected provider.

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

Preferably, the request is a free-form request.

Preferably, the request includes a voice request.

Preferably, the communication device includes a mobile communication device, such as a telephone, a PDA, a personal computer, and a game device.

Preferably, the communication machine includes a fixed communication machine, such as a telephone, a fax machine, a personal computer, a set-top box, and a game console.

Preferably, the communication device includes a combined fixed/mobile communication device, such as a telephone.

In an embodiment, the system includes: at least one inbound communication unit, each of which includes at least one request receiving unit.

In one embodiment, the system includes: at least one outbound communication unit, each of which includes at least one request relay unit, at least one reply receiving unit, and at least one information providing unit.

In another embodiment, the system includes: at least one communication unit, each of which includes at least one request receiving unit, at least one request relay unit, at least one reply receiving unit, and at least one information providing unit.

In one embodiment, at least one request relay unit is configured to directly relay the request to the communication machine of the selected provider.

Preferably, the at least one request relay unit is configured to provide a relay request to determine the content without any interrogation.

Preferably, the at least one request receiving unit includes a plurality of receivers for receiving requests, and each request has a category contact address related to a predeterminable category.

Preferably, the classified contact address is a dial number.

In an embodiment, the system further includes: at least one provider selection unit for selecting a provider to process the request.

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: a geographic location assigned to the corresponding request, and one or both of the geographic location or geographic area assigned to the provider.

In one embodiment, the geographic location assigned to the corresponding request is the current geographic location of the corresponding requestor.

Preferably, the current geographic location is determined by the communication device contact address of the corresponding requester's communication device, wherein the communication device contact address has an assigned location.

Preferably, the contact address of the communication machine is a dial number.

In one embodiment, the geographic location assigned to the corresponding request is an alternate geographic location assigned by the corresponding requestor.

Preferably, the alternative geographic location is determined by a communication device contact address of the communication device, wherein the communication device contact address has an assigned location.

Preferably, the contact address of the communication machine is a dial number.

Preferably, the geographic location of the mobile communication device is determined by one of cell identification, triangulation, radio positioning, or satellite positioning such as GPS.

Preferably, the geographic location of the fixed communicator is determined by the corresponding allocated location.

Preferably, the at least one provider selection unit is configured to select a provider for the request within a predetermined spatial geographic area relative to the geographic location assigned to the corresponding request.

More preferably, the predetermined spatial geographic area is one of the following items: the geographic radius relative to the geographic location allocated to the corresponding request; the driving distance relative to the geographic location allocated to the corresponding request; or relative to the geographic radius allocated to the corresponding request. The travel time of the requested geographic location.

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: at least one requester characteristic of the corresponding requester, such as geographic-related information and socio-economic information, serves as a response to the corresponding request The characteristics assigned by the requester; or the characteristics input by the corresponding requester when the request is made.

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: at least one provider characteristic of the provider, such as requiring the requester to have a predeterminable profile Or provide contact details as a feature assigned to the corresponding provider.

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

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: at least one classification feature, such as a selection mechanism for selecting a provider, as a feature assigned to the corresponding classification.

Preferably, the at least one request relay unit is configured to relay the request to a predetermined number of selected providers for processing.

Preferably, the at least one request relay unit is configured to multicast the request to a selected provider, wherein the request is to be relayed to multiple providers for processing.

Preferably, the at least one information providing unit is configured to provide the corresponding requester with the information regarding the provider who provided an affirmative answer to the request for the request.

On the other hand, the present invention provides a matching system for matching a request of a user as a requester and a provider serving the request. The system includes: a plurality of requester communication machines, each of which is used by the requester to issue The request and the processing response to it, at least one of which includes information about the response to the corresponding request from the selected provider as the decision maker; and a plurality of provider communication machines, each of which is used by the provider Processing a request and a reply thereto, the request being relayed to a corresponding selected provider for processing and at least one of the replies includes information about the requester of the corresponding request in which an affirmative reply was provided to the corresponding request , Where a positive answer indicates that the provider can satisfy the request.

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

Preferably, the request is a free-form request.

Preferably, the request includes a voice request.

Preferably, the communication device includes a mobile communication device, such as a telephone, a PDA, a personal computer, and a game device.

Preferably, the communication machine includes a fixed communication machine, such as a telephone, a fax machine, a personal computer, a set-top box, and a game console.

Preferably, the communication device includes a combined fixed/mobile communication device, such as a telephone.

In one embodiment, the request is relayed directly to the communicator of the selected provider.

Preferably, the request is relayed without any inquiry to determine the content.

Preferably, the system further includes: a communication unit including a plurality of receivers for receiving requests, each request having a category contact address related to a predeterminable category.

More preferably, the classified contact address is a dial number.

Preferably, a provider is selected for the request based at least in part on the following conditions: the geographic location assigned to the corresponding request, and one or both of the geographic location or geographic area assigned to the provider.

In one embodiment, the geographic location assigned to the corresponding request is the current geographic location of the corresponding requestor.

Preferably, the current geographic location is determined by the communication device contact address of the corresponding requester's communication device, wherein the communication device contact address has an assigned location.

More preferably, the contact address of the communication machine is a dial-up number.

In one embodiment, the geographic location assigned to the corresponding request is an alternative geographic location assigned by the corresponding requestor.

Preferably, the alternative geographic location is determined by a communication device contact address of the communication device, wherein the communication device contact address has an assigned location.

More preferably, the contact address of the communication machine is a dial-up number.

Preferably, the provider is selected within a predeterminable spatial geographic area relative to the geographic location assigned to the corresponding request.

Preferably, the provider is selected for the request based at least in part on the following conditions: at least one requester characteristic of the corresponding requester, such as geographic-related information and socioeconomic information, as a characteristic assigned to the corresponding requester; or when the request is made The characteristics entered by the corresponding requester.

Preferably, the provider is selected for the request based at least in part on the following conditions: at least one provider characteristic of the provider, such as requiring the requester to have a pre-determinable profile or provide contact details, which is assigned to the corresponding provider feature.

Preferably, the provider for the request is selected based at least in part on the current time.

Preferably, a provider is selected for the request based at least in part on at least one classification feature, such as a selection mechanism for selecting a provider, as a feature assigned to the corresponding classification.

On the other hand, the present invention provides a matching system for matching a request of a user as a requester and a provider serving the request. Each requester has at least one communication machine for issuing requests and processing responses to them. , And each provider has at least one communication machine for processing requests. The system includes: at least one request receiving unit for receiving requests from the requester; at least one request relay unit for providing the And then to the selected provider for processing; and at least one response receiving unit for receiving a response from the provider, and the received response is made by the corresponding provider as the decision maker in accordance with the corresponding request.

On the other hand, the present invention provides a matching system for matching a request of a user as a requester and a provider serving the request. The system includes: a plurality of requester communication machines, each of which is used by the requester to issue Request and processing the corresponding reply; a plurality of provider communication machines, each of which is used by the provider to process the request and the corresponding reply; and at least one communication unit, which can communicate with the requester communication machine and the The provider communicator talks and includes at least one provider selection unit for selecting a provider to process the request issued by the requester; wherein, for each request, the system is configured to provide the request to relay it to the The decision makers selected provider is thus processed.

Preferably, the system is further configured to provide the corresponding requester with information regarding the response to the corresponding request from the selected provider for the request.

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

Preferably, the request is a free-form request.

Preferably, the request includes a voice request.

Preferably, the communication device includes a mobile communication device, such as a telephone, a PDA, a personal computer, and a game device.

Preferably, the communication machine includes a fixed communication machine, such as a telephone, a fax machine, a personal computer, a set-top box, and a game console.

Preferably, the communication device includes a combined fixed/mobile communication device, such as a telephone.

In one embodiment, the system is configured to relay the request directly to the provider communicator of the selected provider.

Preferably, the system is configured to provide relay requests without any inquiry to determine the content.

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

More preferably, the classified contact address is a dial number.

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: a geographic location assigned to the corresponding request, and one or both of the geographic location or geographic area assigned to the provider.

In one embodiment, the geographic location assigned to the corresponding request is the current geographic location of the corresponding requestor.

Preferably, the current geographic location is determined by the communication device contact address of the corresponding requester's communication device, wherein the communication device contact address has an assigned location.

More preferably, the contact address of the communication machine is a dial-up number.

In one embodiment, the geographic location assigned to the corresponding request is an alternative geographic location assigned by the corresponding requestor.

Preferably, the alternative geographic location is determined by a communication device contact address of the communication device, wherein the communication device contact address has an assigned location.

More preferably, the contact address of the communication machine is a dial-up number.

Preferably, at least one provider selection unit is configured to select a provider within a predetermined spatial geographic area relative to the geographic location assigned to the corresponding request.

More preferably, the predetermined spatial geographic area is one of the following items: the geographic radius relative to the geographic location allocated to the corresponding request; the driving distance relative to the geographic location allocated to the corresponding request; or relative to the geographic radius allocated to the corresponding request. The travel time of the requested geographic location.

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: at least one requester characteristic of the corresponding requester, such as geographic-related information and socio-economic information, serves as a response to the corresponding request The characteristics assigned by the requester; or the characteristics input by the corresponding requester when the request is made.

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: at least one provider characteristic of the provider, such as requiring the requester to have a pre-determinable profile or provide contact details Data as a feature of distribution to the corresponding provider.

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

Preferably, the at least one provider selection unit is configured to select a provider for the request based at least in part on the following conditions: at least one classification feature, such as a selection mechanism for selecting a provider, as a feature assigned to the corresponding classification.

Preferably, the system is configured to provide provider communicators that relay requests to a predetermined number of corresponding selected providers for processing.

Preferably, the system is configured to multicast the request to the provider communicator of the corresponding selected provider, wherein the corresponding request is to be relayed to multiple providers for processing.

On the other hand, the present invention provides a matching method for matching a request of a user as a requester and a provider serving the request. Each requester has at least one communication device for issuing requests and processing responses to them. , And each provider has at least one communication machine for processing the request and replying to it. The method includes the following steps: receiving the request from the requester; for each request, providing that the request is relayed to the selected provider To process; receive the response from the selected provider, and the received response is made by the corresponding provider as the decision maker in accordance with the corresponding request; and perform one or both of the following operations for each request: Any provider that has given a positive reply provides information about the corresponding requester, where a positive reply indicates that the provider can satisfy the request; and provides the corresponding requester with information about the response to the corresponding request from the selected provider.

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

Preferably, the request is a free-form request.

Preferably, the request includes a voice request.

Preferably, the communication device includes a mobile communication device, such as a telephone, a PDA, a personal computer, and a game device.

Preferably, the communication machine includes a fixed communication machine, such as a telephone, a fax machine, a personal computer, a set-top box, and a game console.

Preferably, the communication device includes a combined fixed/mobile communication device, such as a telephone.

In one embodiment, providing the step of relaying the request to the selected provider for processing includes the step of relaying the request directly to the communicator of the selected provider.

Preferably, the request is relayed without any inquiry to determine the content.

Preferably, the step of receiving a request from the requester further includes the step of: receiving requests from the requester at a plurality of receivers, each request having a category contact address related to a predeterminable category.

More preferably, the classified contact address is a dial number.

In one embodiment, the method further includes the following step: selecting a corresponding provider to process the request.

Preferably, the step of selecting the corresponding provider to process the request includes the following steps: selecting the corresponding provider to process the request based at least in part on the following conditions: the geographic location assigned to the corresponding request, and the geographic location or geographic location assigned to the provider One or both regions.

In one embodiment, the geographic location assigned to the corresponding request is the current geographic location of the corresponding requestor.

Preferably, the current geographic location is determined by the communication device contact address of the corresponding requester's communication device, wherein the communication device contact address has an assigned location.

More preferably, the contact address of the communication machine is a dial-up number.

In one embodiment, the geographic location assigned to the corresponding request is an alternative geographic location assigned by the corresponding requestor.

Preferably, the alternative geographic location is determined by a communication device contact address of the communication device, wherein the communication device contact address has an assigned location.

Preferably, the contact address of the communication machine is a dial number.

Preferably, the geographic location of the mobile communication device is determined by one of cell identification, triangulation, radio positioning, or satellite positioning such as GPS.

Preferably, the geographic location of the fixed communicator is determined by the allocated location.

Preferably, the step of selecting the corresponding provider to process the request includes the following steps: selecting the corresponding provider to process the request within a predetermined spatial geographic area relative to the geographic location assigned to the corresponding request.

More preferably, the predetermined spatial geographic area is one of the following items: the geographic radius relative to the geographic location allocated to the corresponding request; the driving distance relative to the geographic location allocated to the corresponding request; or relative to the geographic radius allocated to the corresponding request. The travel time of the requested geographic location.

Preferably, the step of selecting the corresponding provider to process the request includes the following steps: selecting the corresponding provider to process the request based at least in part on the following conditions: at least one requester characteristic of the corresponding requester, such as geographic-related information and socio-economic information, It is used as a characteristic assigned to the corresponding requester; or a characteristic input by the corresponding requester when the request is made.

Preferably, the step of selecting the corresponding provider to process the request includes the following steps: selecting the corresponding provider to process the request based at least in part on the following conditions: at least one provider feature of the provider, such as requiring the requestor to have a pre-determinable profile File or provide contact details as a feature assigned to the corresponding provider.

Preferably, the step of selecting the corresponding provider to process the request includes the following steps: selecting the corresponding provider to process the request based at least in part on the current time.

Preferably, the step of selecting the corresponding provider to process the request includes the following steps: selecting the corresponding provider to process the request based at least in part on the following conditions: at least one classification feature, such as a selection mechanism for selecting a provider, serves as a response to the corresponding provider. Classification and distribution characteristics.

Preferably, the step of providing the request to be relayed to a selected provider for processing includes the following step: providing to relay the request to a predetermined number of selected providers for processing.

Preferably, providing the step of relaying the request to the selected provider for processing includes the following steps: multicasting the request to the selected provider, wherein the request is to be relayed to multiple providers for processing.

Preferably, the step of providing information includes the following step: providing the corresponding requester with the information about the provider who provided affirmative response to the request for the request.

On the other hand, the present invention provides a matching method for matching a request of a user as a requester and a provider serving the request. Each requester has at least one communication device for issuing requests and processing responses to them. , And each provider has at least one communication machine for processing requests, the method includes the following steps: receiving a request from the requester; for each request, providing that the request is relayed to a selected provider for processing; and The response from the provider is received, and the received response is made by the corresponding provider as the decision maker in accordance with the corresponding request.

On the other hand, the present invention provides a matching method for matching a request from a user as a requester and a provider serving the request. The method includes the following steps: receiving a signal containing a request from the requester; for each request , Send a signal containing the received request to the selected provider; receive a signal containing a response from the selected provider, the response being made by the corresponding provider according to the corresponding request; and for each request, send one of the following signals Or both: a signal containing information about the corresponding requester sent to any provider that provided a positive response to the corresponding request, where a positive response indicates that the provider can satisfy the request; and a signal containing information sent to the corresponding requestor about the requester The information signal of the provider's response to the corresponding request.

The present invention, called the ResponsaTM matching system, provides an automatic matching system, particularly allowing voice requests, especially free-form requests, to be matched with providers who have received the request and confirmed that the request can be satisfied.

In a preferred embodiment, matching can be achieved based on the following conditions: the location related to the requester, typically the location of the requester's communication device, the provider's assigned location in the selected category, and the selected category. In other embodiments, the current time and the characteristics of one or both of the requester and the provider may be used in selecting the provider.

According to the present invention, the received request is relayed to the selected provider, and the sound request is replayed, and if any provider cannot satisfy the request, the provider only needs to simply reject the request, typically through A "reject" response, a button corresponding to the "reject" response, or simply hang up the communicator. When the request is relayed, all communication between the requester and the provider is one-way communication. Therefore, no direct dialogue is required between the requester and the provider, so that when the provider cannot satisfy the request, both parties avoid the time-consuming task of having to establish a polite discussion. There is only a direct dialogue between the requester and the provider who can satisfy the request.

The present invention provides automatic matching and also allows personal, free-form style human communication. In a free-form request, the preferred embodiment of the present invention provides the requester with the freedom to construct the request as needed; the language and form of the request are not restricted, such as requiring the requester to use predetermined keywords.

In addition, the present invention only relays requests to those providers who wish to receive requests and are in a position to service those requests, for example, the providers are open and located in a specific geographic area as indicated by a specific classification.

In the present invention, as opposed to a computer, it is a human decision maker who receives requests and can intelligently interpret these requests. This avoids the problem that the matching system requires the requester to be restricted to use predetermined keywords, such as through the use of drop-down menus.

Moreover, the present invention can be applied to a private environment such as being operated by an organization to be used by members of the organization, and also applicable to a public environment that allows public members to use it.

In some embodiments, the present invention may be configured to perform matching favorably for the requester or selected provider with a bias. It is conceivable that this is suitable for some special applications, especially private environments.

The preferred embodiments of the present invention are illustrated below with reference to the accompanying drawings, in which:

Fig. 1 schematically shows a matching system for matching a request of a user as a requester with a provider serving the request according to a preferred embodiment of the present invention.

The matching system includes at least one telephone management (TM) system 1, in this embodiment the first and second TM systems 1a, 1b, which are used to manage inbound phone calls into the matching system and outbound calls from the matching system. Station phone call. In another embodiment, the matching system may include a single TM system 1, and in other embodiments may include any number of TM systems 1 from tens to hundreds.

In this embodiment, the TM systems 1a and 1b are in the same position, but in other embodiments, they may be in a remote position. In one such other embodiment, the TM systems 1a, 1b may be located at different locations in a geographic area. For example, in the United Kingdom, one TM system 1a may be located in a center, such as London, to serve the southern half of the United Kingdom, and another TM system 1b may be located in another center, such as Glasgow, to serve the northern half of the United Kingdom. In other embodiments including multiple TM systems 1, the TM systems 1 may be located in multiple major centers, such as multiple cities and towns throughout a geographic area.

The matching system also includes a first communication network 3, which provides a communication link between the TM systems 1a, 1b and the TM systems 1a, 1b.

In this embodiment, when the TM systems 1a and 1b are in the same position, the communication network 3 includes a local area network (LAN), such as Ethernet.

In other embodiments, when the TM systems 1a, 1b are in remote locations, the communication network 3 may include a telephone network, preferably an integrated services digital network (ISDN).

Each of the TM systems 1a, 1b includes an inbound telephone management (ITM) unit 5 for managing inbound telephone calls from the requester on the inbound telephone line 7, especially on the ISDN line. In this embodiment, multiple subscriber numbers (MSN) are used, so that multiple requesters who require the same classification can be supported at the same time.

The ITM unit 5 includes: an inbound interactive voice response (IIVR) module 11, which is connected to the inbound telephone line 7 to monitor inbound telephone calls and supports voice and keytone; inbound telephone application management (ITAM) Module 13 is used to generate a request document corresponding to the request, which is a voice request in this embodiment, in each inbound telephone call and send it to the provider selection units 33a, 33b, 33c, which will be changed later Detailed description; the first classification feature (CC) database 15, connected to the ITAM module 13, used to store the classification features of each classification; and the requester information (RI) database 17, connected to the ITAM module 13, used to store and Information about the requester.

With this configuration, the CC database 15 and the RI database 17 are inaccessible to the IIVR module 11, thereby protecting the RI database 17 from being accessed by third parties. In this embodiment, the ITM unit 5 includes an intrusion detector located between the IIVR module 11 and the ITAM module 13, so that third-party intrusions are typically monitored by identifying abnormal packets, thereby providing the security of the ITAM module 13.

In this embodiment, the communication between the IIVR module 11 and the ITAM module 13 adopts the VoiceXML communication protocol.

In this embodiment, the request document generated by the ITAM module 13 includes at least one classification identifier. In this embodiment, the classification identifier is the called number, that is, the telephone number called by the requester, and the classification identifier Identifies the category to be matched with the request; a requester identifier, in this embodiment, the calling line identifier (CLI) of the requester's phone, that is, the phone number that the system or the provider of the affirmative answer should contact when responding to the request , And the requester identifier identifies the requester; and the sound file corresponding to the request to be relayed to the provider, in this embodiment, is the sound file corresponding to the sound to be reproduced to the provider. In an alternative embodiment, the requester identifier may be a phone number obtained from the CLI of the requester's phone, or, for example, information including an authentication code provided by the requester when the request is made.

In an optional embodiment, as described in detail later, the request file generated by the ITAM module 13 may omit the requested request file, where the file is stored in a file storage device 19 that can be accessed to allow subsequent relay requests .

In this embodiment, the request document generated by the ITAM module 13 includes a location identifier, which identifies the location of the search center. The location of the requester cannot be obtained from the requester identifier in the provider identification units 33a, 33b, 33c. to make sure. Typical examples where the requester identifier does not allow the location of the requester to be determined are: the requester is not registered (ex-directory), and the requester does not provide the address of the calling number, or the calling phone is a mobile phone, or the request The user needs an alternative location for the search center. In this embodiment, in addition to the number of the calling phone provided by the requester to indicate the location of the search center, the location identifier is a phone number.

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 in the same position.

In other embodiments, the IIVR module 11 and the ITAM module 13 may be located at the same location, and one or both of the CC database 15 and the RI database 17 may be located at a remote location. In this embodiment, the communication network between the ITAM module 13, the CC database 15 and the RI database 17 is a virtual private network (VPN).

In another embodiment, one or both of the IIVR module 11 and the ITAM module 13 may be at a remote location, and the CC database 15 and the RI database 17 may be at the same location.

In another embodiment, all the components of the ITM unit 5, that is, the IIVR module 11, the ITAM module 13, the CC database 15 and the RI database 17 may be in remote locations.

Each of the TM systems 1a, 1b also includes a file storage device 19 for storing classification greetings and supported classification prompts. As described above, in one embodiment, the file storage device 19 stores the requested file for each request from the requester. Storing the request files in this way makes it possible to retrieve these request files, so these request files do not need to include these request files. For the same system capacity, including these request files will require very high business traffic, while the request files have a much smaller size. .

The operation of the ITM unit 5 of the TM system 1a, 1b is described below.

The ITM unit 5 receives the inbound telephone call from the requester communication machine 20 on the corresponding inbound telephone line 7. In this embodiment, the requester communication machine 20 is a telephone, and the specific ITM unit 5 receiving the telephone call is controlled by the The called number is the indication of the phone number called by the requested party.

In this embodiment, when the matching system is configured to work as a trade classification matching system, the requester can select from a plurality of classification items corresponding to different types of goods and service providers. Each category entry has an associated phone number, and the requester must dial this number to access the matching system to get that category, and in this embodiment, the category identifier determines the search criteria, matching criteria, and termination criteria, and passes these criteria To perform the matching operation, which will be described in more detail later. In one embodiment, each category entry may include a summary of one or both of services or goods, so that the requestor can be sure that the correct category has been selected for a 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 requester's communication machine 20, that is, the calling communication machine to the ITAM module 13. In this embodiment, the requestor communication machine 20 may be a fixed phone, a mobile phone, a combined fixed/mobile phone, or a PDA.

Then, the ITAM module 13 queries the called number in the CC database 15, and retrieves the classified greeting file identifier of the "classified" greeting to be played to the requester.

In the case where the called number is not associated with the classification, for example, in the case where the called number was previously used in relation to a classification but is not currently in use, the ITAM module 13 instructs the IIVR module 11 to execute the "unassigned classification" script, The script plays an "unassigned category" greeting and closes the call connection.

In the case that the calling communicator 20 does not have a CLI, for example, when the CLI is disabled, the ITAM module 13 instructs the IIVR module 11 to execute the "number withheld" script, which plays a "number withheld" greeting to instruct the requester to enable The CLI of the calling phone or as an authenticated requester provides an authentication code related to registration.

In this embodiment, the system is configured to allow the requester to proceed with the request only when the inbound call has a CLI. By requiring the use of the CLI-enabled communicator 20, it is possible to prevent misuse of the system by the requester who leads the third-party reply.

In the case that the calling communicator 20 has a CLI, the ITAM module 13 queries the CLI of the calling communicator 20 in the RI database 17 in order to confirm the requester information, including confirming that the location information is available to the CLI, and obtain the default requester first. Options, such as whether to provide the requester's requester details to the provider or keep it.

In the case where the CLI of the calling communicator 20 is the CLI of a fixed communicator, and the RI database 17 includes the location information of the CLI of the calling communicator 20, the ITAM module 13 instructs the IIVR module 11 to execute the "fixed requestor" script.

In the case that the CLI of the calling communicator 20 is the CLI of the mobile communicator, and the RI database 17 does not include the default location information of the CLI of the calling communicator 20, the ITAM module 13 determines the location of the calling communicator 20 from the network information And instruct the IIVR module 11 to execute the "movement requester" script. In this embodiment, the cell ID of the calling communicator 20 is used to determine the location of the requester, where the cell ID represents the cell in which the calling communicator 20 is located, that is, the geographic area, and the ITAM module 13 queries the RI database 17 for the cell ID , Get the location of the calling communicator 20. In other embodiments, the calling communicator 20 of the requestor may be determined by triangulation, radio positioning, or satellite positioning such as GPS.

In the case where the CLI exists but the location cannot be determined from the CLI, such as when the requester is not registered, that is, when the requester has requested the service provider not to disclose the location information corresponding to the number of the requester communicator 20, and When the provider does not provide location information in other ways, the ITAM module 13 searches the CC database 15 for the classification search vector (search vector) corresponding to the called number to determine whether there is a vector for processing location-independent requesters . When there is a vector for processing position-independent requesters, the ITAM module 13 utilizes the vector. In the absence of a vector for processing position-independent requesters, the ITAM module 13 instructs the IIVR module 11 to execute a "request location" script, which plays a "request location" greeting and prompts the requester to provide location information, typically The known CLI-enabled phone number, where the location information is stored in the CC database 15 acting as a search center.

When the CLI exists but the calling number is the number of the switch (manual or automatic), the ITAM module 13 instructs the IIVR module 11 to execute the appropriate "switch requester" script.

Under the "fixed requester" and "mobile requester" scripts, the IIVR module 11 plays the "category title" greeting corresponding to the retrieved category greeting identifier, followed by the "request reminder" greeting, which is used to remind the requester Provide request. For example, in the case where the called number corresponds to the category "Toy Store", in this embodiment, the category greeting will be "Welcome to the ResponsaTM category of the toy store", and the "Request Reminder" greeting will be "Please call Leave your request afterwards and hang up when it's over".

Under the "exchange requester" script, the IIVR module 11 sequentially plays the "category title" greetings corresponding to the retrieved category greeting identifiers, and prompts the requester to provide the extension number "extension identification", typically by keying in the number or passing Voice response and a "request reminder" greeting that prompts the requester to provide the request In this embodiment, the "request reminder" greeting is only played after a predetermined button of the calling communicator 20, where the button confirms that the calling communicator 20 provides an extension number. For example, when the called number corresponds to the category "Toy Store", in this embodiment, the "Category Title" greeting will be "Welcome to the ResponsaTM Category of Toy Store", and the "Extension Identification" greeting will be "Please call Then leave your extension number, and then press the X button", and after the requested button, the "request reminder" greeting will be "please leave your request after the call tone and hang up after the end".

When the requester wants to set optional preferences, for example, if you want to keep contact details for the provider and the default is to provide the provider with detailed information, provide the optional search center location or optional search parameters. IIVR module 11 supports buttons Enter to set these preferences.

In this embodiment, the IIVR module 11 is configured to allow, for example, to re-record the request by pressing a predetermined key when the requester makes a mistake in the recording request.

In addition, in this embodiment, the IIVR module 11 is configured to be able to refer to the replay request here before initiating the matching operation.

In this embodiment, the call connection is closed after a predetermined period of time has passed after the "request prompt greeting, or when the requester hangs up, where the hang-up event can be identified by the IIVR module 11.

In one embodiment, the ITAM module 13 stores each request in the file storage device 19 under the assigned file name.

Each of the TM systems 1a, 1b also includes an outbound phone management (OTM) unit 21 for managing the outbound line 23, preferably on the ISDN line, the provider and requester communicator 20 on the provider communicator 24 The outbound call of the requester on.

The OTM unit 21 includes: an outbound interactive voice response (OIVR) module 25, which is connected to an outbound line 23 for implementing outbound calls to providers and requesters; and an outbound phone application management (OTAM) module 27, It is used to schedule and instruct calls to the OIVR module 25 according to the call documents received from the provider selection units 33a, 33b, 33c. In this embodiment, the call documents can be scheduled according to priority flags, where, for example, the status report to the requester has a lower priority than the request to the provider.

In operation, when an outbound call to the provider is implemented, the OIVR module 25 dials the number of the provider communication machine 24 identified in the call document.

When answering the call to the provider communicator 24 implemented by the OIVR module 25, the OIVR module 25 executes the "request for playback" script, which first plays the "VRS welcome" greeting, such as "VRS to the barber", and then A short tone, followed by a request to the provider, followed by a second short tone. In this embodiment, the request is relayed and replayed here without any inquiry, because inquiry such as by voice recognition is unnecessary; the classification is indicated by the called number. In an alternative embodiment, the request can be queried, where a more sophisticated or sophisticated matching system is required.

When hearing the request, the provider has the following reply operations, each of which has a related button: "Accept", which is a confirmation that the request can be satisfied. For example, in the case where the request is "Do you have a haircut?", that is, in the case where the requester is only trying to obtain the details of the local hairdresser and the request is appropriate, the provider will reply "Accept".

"Maybe", it is an indication that the request may be met, but the provider must confirm it. In the case of a more complicated request, such as "Can you cut my haircut at 15:30 next Thursday?", the provider may remember that the appointment for next Thursday afternoon is not full, but needs to check whether the exact time is free, In this case, the provider will reply "maybe".

"Reject", it confirms that the request cannot be fulfilled. In this embodiment, hanging up is equivalent to the reply operation "rejection".

"Inappropriate" indicates that the request is not suitable for the classification or is not understandable.

"Abusive" means that the request is considered abusive.

In this embodiment, the provider's reply is recorded, so that the classification manager can monitor the behavior of the provider and part of the requester, and in particular, it is allowed to provide targeted guidance to the requester and the provider, and even prohibit its behavior. Is an unacceptable requestor or provider.

For example, since repeated "inappropriate" responses may be caused by the requester or provider confusing the classification purpose, the "inappropriate" responses are recorded, both for the provider who responded in this way, and for the request that made the request By.

In addition, the "abuse" reply is recorded, both for the provider of such a reply and the requester who issued the request, and in this embodiment, in addition to terminating the matching operation, the repetition determined by the confirmed "abuse" reply Abuse of the request results in the corresponding requester banning the use of classification or even the entire matching system. In this embodiment, repeated "abuse" responses from providers that are typically significantly higher than the classification average will also be investigated.

When the provider provides an affirmative reply, that is, in this embodiment, one of the reply options "accept" or "possible", the OIVR module 25 executes the "confirmation" script, which plays the "reply confirmation" greeting followed by a short tone, The call document is then updated to include an affirmative reply identifier and the updated call document is transmitted to the originating provider selection unit 33a, 33b, 33c.

When the requester's contact details are restricted, the "confirmation" script also plays a "contact details restriction" greeting.

When the contact details are not restricted, the "confirmation" script also provides the requester's contact details followed by a short tone. In one embodiment, the provider can record the details of the requester to call the requester later. In another embodiment, the provider can directly contact the requester through a predetermined button. While the requester is tracking the process online, the requester can directly contact the provider while the provider is still online.

When the calling communicator 20 comes from the extension of the manual switch, the "confirmation" script also provides the switch phone number and the requester's extension to allow the provider to navigate the switch.

When the calling communicator 20 comes from an extension of a non-manual exchange, the "confirmation" script also plays a greeting of "Please stay online until you hear the phone tone". During the period before the call tone, the provider's details are provided to the requester, thus giving the requester an opportunity to directly contact the provider who is still online. When an immediate contact is required, the requester is connected to the provider and a dialogue is established therefrom. When immediate contact is not established, the requester can contact the provider later.

In this embodiment, the system is configured to allow the "confirmation" script to be executed again through a predetermined button.

In this embodiment, the affirmative reply is to reply to either of the options "accept" or "possibly". In other embodiments, especially for some categories, the matching system can be configured to only look for "accepted" responses as affirmative responses. In such embodiments, the "request to replay" script also plays "Please only choose to reject or accept" Regards, all "possible" and "rejected" responses are considered negative responses.

When the call to the provider implemented by the OIVR module 25 is not answered, the OIVR module 25 assigns one of the following states to the call document as the call state identifier, namely: "Number Unobtainable" is for the provider The number saved by the communicator 24 is invalid; "engaged" means that the number saved for the provider is in a busy state, and "Rings Out" means that the number saved for the provider has no answer and no answer, The OIVR module 25 updates the call document to include the relevant call state identifier and sends the updated call document to the originating provider selection unit 33a, 33b, 33c.

Each of the TM systems 1a, 1b also includes a telephone management (TM) communication network 29, which provides a communication link with the first main communication network 3, and an ITM unit 5, which in this embodiment is a separate IIVR module 11 and ITAM The module 13; the file storage device 19; the OTM unit 21, which is a communication link between a separate OIVR module 25 and an OTAM module 27 in this embodiment. In one embodiment, the communication with the ITM unit 5, the file storage device 19 and the OTM unit 21, and the communication between the IIVR module 11 and the ITAM module 13 are encoded, that is, encrypted communication or authenticated communication, such as signed communication .

In this embodiment, in the case where the ITM unit 5, the file storage device 19, and the OTM unit 21 are in the same location, the TM communication network 29 includes a local area network (LAN), such as Ethernet.

In other embodiments, when the ITM unit 5, the file storage device 19, and the OTM unit 21 are in remote locations, the TM communication network 29 may include a predetermined telephone network, preferably an ISDN network.

The matching system also includes at least one provider selection unit 33. In this embodiment, there are three provider selection units 33a, 33b, and 33c, which are used to select the provider to be contacted when a matching request is made and pass the TM system 1a, 1b. The OTM unit 21 schedules contact with the provider. It should be understood that the matching system may include any number of provider selection units 33; the inclusion of three provider selection units 33a, 33b, and 33c in this embodiment is just an example.

In this embodiment, the provider selection units 33a, 33b, 33c are in the same position, but in other embodiments, multiple or all of the provider selection units 33a, 33b, 33c may be in remote positions.

In this embodiment, each of the provider selection units 33a, 33b, 33c is configured to support all processable categories, but in other embodiments, especially when there are dozens or hundreds of provider selection units 33a, 33b, 33c, the provider selection unit 33a, 33b, 33c can be configured to support only one category or a subset of the processable categories.

The matching system also includes a second main communication network 34, which provides a communication link with the provider selection units 33a, 33b, 33c and a communication link between the provider selection units 33a, 33b, 33c.

In this embodiment, when the provider selection units 33a, 33b, 33c are in the same position, the second main communication network 34 includes a local area network (LAN), such as Ethernet.

In other embodiments, when the provider selection units 33a, 33b, 33c are in remote locations, the second primary communication network 34 may include a telephone network, preferably an integrated service digital network (ISDN).

The matching system also includes a router 35 for routing the request document and the call document between the respective TM systems 1a, 1b and the provider selection units 33a, 33b, 33c.

Each of the provider selection units 33a, 33b, 33c includes: a classification information (CI) database 37 containing information about each provider in each category supported by the respective provider selection units 33a, 33b, 33c The provider characteristics of each category, the provider list construction parameters of each category, the matching criteria of each category and the termination criteria of each category; the second requester information (RI) database 39 contains the following information, namely about each requester The document scheduling program 41 is used to schedule documents in and out of the provider selection units 33a, 33b, 33c; and the provider list construction unit 43, for each request, from the providers included in the CI database 37 , To construct a ranking provider list for the category that the request is directed to.

The CI database 37 contains information about each provider in each category, and each provider is referenced by a provider identifier. The information saved for each provider includes the providers name; the providers address; the providers contact number; the providers characteristics; and system history information, which includes the number of requests sent and affirmative answers The number of replies is one of "accepted" and "possible" in this embodiment, "accepted" replies in other embodiments, and the number of negative replies, that is, "rejected" replies in this embodiment. In other embodiments, it is one of "rejected" or "probably" responses, the number of "inappropriate" responses, and the number of "abuse" responses. In this embodiment, the CI database 37 is a spatial-join database, that is, a database that supports spatial operations.

The provider list construction unit 43 includes a provider selection module 44 configured to create one or more candidate provider lists according to a predetermined list construction mechanism for the category targeted by the request, and wherein the list construction mechanism The search center uses a location-based vector, which is usually the location of the requester, but it can also be an alternative location specified by the requester, or the first to make the request when the search is re-centered The location of the provider who answered affirmatively. The creation of multiple candidate provider lists supports a mix of providers, such as a mix of local and international providers, which will be described in more detail later.

In this embodiment, the provider selection module 44 uses the following list construction mechanism to create one or more candidate provider lists:

List building mechanism A-The closest to this list building mechanism creates a list of candidate providers that are closest to the search center based on spatially related parameters, where spatially related parameters are typically direct (point-to-point) distance, travel distance or travel time . In one embodiment, the candidate provider list can be reduced by number, that is, it includes a predetermined number of providers closest to the search center. In another embodiment, the candidate provider list can be reduced by the upper limit of the space-related parameters, that is, it includes all providers in a space area of a predetermined size.

List construction mechanism B-closest cluster (cluster) This list construction mechanism creates a candidate provider list representing the closest group of providers as the closest cluster, and this mechanism satisfies the cluster characteristics of the category for which the request is directed. In this embodiment, the group feature defines the closest group as the closest provider set, including a predetermined size range of space, typically direct (point-to-point) distance, travel distance or at least a predetermined number within travel time Provider.

List Construction Mechanism C-Maximum Density Group This list construction mechanism creates a list of candidate providers representing a group of providers as a group that satisfies the density characteristics of the classification for which the request is directed, but the group is not necessarily the closest group. In this embodiment, the density feature defines the group as a set of providers, which includes the highest number of providers within a first spatial range of a first predetermined size. The first spatial range is typically a direct (point-to-point) distance , Travel distance or travel time, where the first spatial range is within a second predetermined size of the first spatial range centered on the search center. This list building mechanism can effectively locate the largest town or city in a geographic area, and eliminate providers outside of the main density, because they may be more widely dispersed. Therefore, it is expected that this list building mechanism is usually used as part of a series of searches.

List construction mechanism D-segment (segment) The list construction mechanism creates a candidate provider list of candidate providers from within a circle, the circle has a predetermined radius and distance, the radius is to search The first predetermined size of the center is typically the direct (point-to-point) distance, travel distance or travel time, or the second smaller size. The circle with the smaller radius in the foregoing distance contains a predetermined number of candidates provider. In this embodiment, the candidate provider list is sorted according to spatially related parameters, typically direct (point-to-point) distance from the search center, travel distance or travel time, and the closest one is ranked first in the list. Bit. When it is called again due to unsuccessful matching operation, the next circle is used in a clockwise or counterclockwise sense. This list building mechanism was developed for situations where there are variable but high-density providers in an area of interest, and the requester is eager to identify providers in the general driving direction extending from the search center. In this embodiment, the circle gap of the circle is randomly selected.

List building mechanism E-All this list building mechanism creates all candidate providers with a predetermined size and a spatial area centered on the search center according to spatially related parameters, which are typically direct (point-to-point) distance, travel distance, or travel time List of candidate providers.

List building mechanism F-Threshold This list building mechanism creates a provider list of candidate providers that meet the threshold characteristics of the classification for which the request is directed. In this embodiment, the threshold feature defines providers that meet a predetermined threshold standard, for example, higher or lower than at least one predetermined threshold. Examples of threshold criteria include turnover, number of employees, quality level, and delivery speed.

The provider list construction unit 43 also includes a provider ranking module 45, which is used to create providers by ranking the candidate providers in the candidate provider list created by the provider selection module 44 according to a predetermined ranking mechanism for the classification of the request. Contact list. In one embodiment, the created provider contact list can be deleted.

In this embodiment, the provider classification module 45 may adopt the following sorting mechanism: sorting mechanism A-no sorting mechanism does not sort the candidate provider list. The provider contact list has the order of the candidate provider list created by the provider selection module 44.

Sorting Mechanism B-Random This sorting mechanism creates a provider contact list by randomly arranging the candidate provider list created by the provider selection module 44.

Sorting mechanism C-turning This sorting mechanism creates a provider contact list by sorting the candidate provider list created by the provider selection module 44 according to the last contact with the provider, so as to ensure that the providers take turns in accordance with the specified ratio The place is contacted, and the last contacted provider is at the bottom of the list. In this embodiment, log records are maintained for previous contacts with providers.

Sorting mechanism D-Closest This sorting mechanism creates a provider contact list by sorting the candidate provider list created by the provider selection module 44 according to spatially related parameters, where the spatially related parameters are typically direct (points) to the search center To the point) distance, travel distance or travel time, the closest one is ranked first, and so on.

Ranking mechanism E-ranked (ranked) This ranking mechanism creates offers by sorting the candidate provider list created by the provider selection module 44 into a hierarchical order according to specific ranking parameters, such as turnover, number of employees, quality level, and delivery speed. Contact list. This sorting mechanism is particularly suitable for searching providers whose location is not important. These providers are often international providers, and the location of these providers is only relevant to the extent to which the provider includes the location of the requester. A typical classification will be insurance services, where the provider will be contacted by telephone. It should be understood that this sorting mechanism can create a list that never includes a particular provider, so the sorting mechanism is usually used as one of a series of searches.

In this embodiment, when the list construction criteria of the selected category require multiple contact provider lists, the list construction unit 43 is configured to merge multiple provider contact lists to create a single provider contact list. Creating a single provider contact list from multiple provider contact lists can be used in situations where a mixed provider such as local and international providers is to be selected. A typical classification suitable for such a provider contact list is a computer provider, where the requester may need a local provider or possibly an international provider.

The provider contact list constructed by the list construction unit 43 includes a plurality of status fields for each provider entry, but has a limitation that the provider can be included in only one field. In this way, the state of the provider can be maintained. Several statuses can be grouped, which means that the request has not been delivered. These include "available", "out of hours", "busy", and "no answer" status. The final response status includes "accepted", "rejected", "maybe", "inappropriate" and "abuse" status.

In constructing the provider contact list, perform a database inquiry to determine which providers are available. Check this list and categorize providers into "available" and "out of business hours" status. When each provider "out of business hours" becomes available, an event is queued to move the provider from the "out of business hours" field to the "available" field. Similarly, when each "available" provider becomes unavailable, an event is queued to move the provider from "available" to "out of office hours" state.

In one embodiment, the provider selection units 33a, 33b, 33c may be configured to support re-determination of the search center as the location of the provider that provided the first affirmative answer. In the case where the re-determination of the center is permitted and the provider who provided an affirmative answer is identified, the provider list construction unit 43 is called again to create an additional provider contact list that uses the location of the identified provider as the search center. This re-centering is used to identify providers that are as close as possible to each other, so as to try to avoid identifying providers that are far apart, for example, two providers that are in the opposite direction to the search center and are therefore far apart. It is conceivable that the redefinition center can be applied to identify multiple providers located relatively close to be visited by the requester, which is expected to allow comparison of services or goods provided by the providers.

The document dispatcher 41 is configured in the OTM unit 21 that dispatches the call document to the TM system 1a, 1b to perform calculations to calculate how many providers can be called at the same time, and whether these calls are "accept-only" . This number is used to determine whether the "in progress" list of the provider 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 providers that are "busy", "no answer", or "out of office hours" to become available. Further interface methods are also used to move providers from one list to another, thereby allowing the document dispatcher 41 to move "in progress" providers to the final response state, such as "accepted", "rejected", " Maybe" wait. The same method is used to move providers between "available" and "out of office hours" and vice versa. The use of the same method allows multiple checks to be performed, such as requeueing "busy" providers when the provider is "out of working hours".

The provider selection units 33a, 33b, and 33c are configured to terminate the search if the matching criterion is met, or if the matching criterion is not met but one of the activated following termination criteria is met. In this embodiment, for each category, any termination criterion can be activated or deactivated. In the event that any termination criterion is activated, the provider selection units 33a, 33b, 33c terminate the search when the termination criterion is met, and pass the termination report to the corresponding provider.

In this embodiment, the termination criteria are as follows: termination event A-number of rejections For this termination event, termination occurs when a predetermined percentage of providers on the provider contact list of the corresponding request are contacted. The provider selection units 33a, 33b, 33c are configured to retry contacting as many selected providers as possible among these providers when the provider's phone number is in use or there is no answer. It should be understood that the phone numbers of some providers may be always busy or unanswered, so that the system cannot necessarily contact all selected providers.

Termination event B-predetermined time period end For this termination event, termination occurs when the predetermined time limit ends. In a preferred embodiment, the termination occurs when a predetermined percentage of providers on the provider contact list have not been contacted within a predetermined period of time since the requester issued the request or the predetermined period of time since the requester issued the request.

Termination Event C-Abusive Request For this termination event, termination occurs when a predetermined number of providers report that the request is abusive for two providers in this embodiment, and the "abuse" response is the provider's response option.

Termination Event D-Inappropriate Request For this termination event, termination occurs when a predetermined number of providers report that the request is inappropriate for two providers in this embodiment, and the "inappropriate" response is the provider's response option .

Termination event E-list exhaustion For this termination event, termination occurs when the contact provider list is exhausted.

In a preferred embodiment, the number of "incomprehensible" or "inappropriate" responses is set to be greater than one, such as two or three, so that a single "incomprehensible" or "inappropriate" response is not enough to cause a match The termination of the operation, because it may be provided by a rogue provider or caused by a simple error on the provider's side.

When the system fails to meet the matching criteria within a reasonable time, contact the requester and provide a progress report. The system continues until one of the matching criteria or termination criteria is met. If the termination criteria are met for the request, the requester is contacted to report the end of the search and the results obtained. Generally speaking, if the requester does not hear anything, the requester can be sure that the system has successfully matched the request according to the classification matching criteria. Progress or termination reports are returned to the switch requester, but the recorded name and extension number of the requester always precede these reports, so that the operator of the switch can deliver the message to the requester.

In this embodiment, the system also supports the initiation of delayed matching operations. There are often occasions when a person wishes to make a request, but he knows that most or all of the potential offers are currently closed. The system can still be used on these occasions. The requester can make a request at any time of the day, such as at 02:00, so that it knows that the request cannot be matched. Any selected providers that are active at that time will be contacted, giving those providers an opportunity to respond to the request. The active period is known to all providers. For many providers, the number of available providers will be much larger during normal daytime working hours. If this is the case, a termination report will be provided to the requester as usual, but the system is configured to relay the request again at a designated other time when more providers in a given category are active. In this embodiment, the system is configured to ignore this feature by applying predetermined keys. By default, the action of hanging up is used to request that the request be relayed to a time when it is more likely to be matched.

In this embodiment, the system is also configured so that the requester can specify an alternative location for a search center that is not related to the CLI of the calling phone. In this embodiment, the IIVR module 11 provides a predetermined button to activate the feature, and after activation, the IIVR module 11 executes the "alternative location" script, which plays the "alternative location" greeting and prompts the requester to enter an alternate search center Phone number and follow another predetermined button. The system then uses the alternate location phone number to determine the search center. The system only uses alternative location phone numbers instead of calling numbers to construct a provider contact list. The calling number is usually the phone number to which the CLI is used as a status or termination report.

This feature supports situations where the requester wants to identify providers in different geographic areas. For example, suppose the requester is traveling on a weekend to visit friends and wants to locate a French restaurant in the area to be visited. The requester will execute the "alternative location" button during the classified greeting and enter the alternate phone number, which is typically the desired visit The phone number of your friend, and enter a "done" button, and then leave a request, such as "a very good French restaurant, table for four people, 19:30 Saturday night, please call back tonight" . When the contact mode is set to provide details of the requester, any provider who provides a positive answer will be provided with the requester's calling number instead of the location telephone number.

In this embodiment, the system is also configured to allow the requester to stay online and track matching operations. This is typically when the requester believes that the match is likely to be reached soon. In this embodiment, this feature is activated by a predetermined key when the requested recording is completed, and the feature is disabled by repeating the predetermined key. The matching system reports every event in real time, such as "single cut, rejected", "his hair, rejected", "cool cut, accepted", etc. In this mode, each provider who provides a positive answer in this embodiment is assigned a specific button for one of "accept" or "possible", and a related button is operated to establish a call to the provider.

In this embodiment, for each requester, the configuration options include the contact mode setting, which allows the requester to configure the system by default to restrict the requesters contact details to the provider. In this case, any request The report of the applicant provides the details of the identified provider who has provided an affirmative answer, thereby allowing the requester to contact the provider, or provide the requesters contact details to the identified provider when accepting the request, thereby The accepting provider can contact the requester directly.

In this embodiment, the system is configured to enable the requester to ignore the default contact mode setting, here by operating a predetermined button during the classified greeting. In this embodiment, unless specifically configured, the default reply mode setting is to provide details of the requester. When the default contact mode setting is set to provide detailed information, the application of the predetermined key causes the contact mode setting to be switched from providing requester details to restricting requester details, so the contact mode greeting "requester details will be restricted" is played, and Follow the usual recording request tone. When the default contact mode setting is set to restrict details, applying a predetermined key causes the contact mode setting to switch from restricting requester details to providing requester details, so the contact mode is played to greet "requester details will be provided", and Follow the usual recording request tone.

When the contact mode setting is set to restrict the details of the requester, the system will call the requester on the calling number after identifying the provider for the request, and provide a termination report including the details of each provider. In this implementation In the example, for each provider, the providers detailed information is the contact name, or the providers name, or the providers contact name, and the contact number. In this embodiment, each provider mentioned in the termination report is assigned a related key on the keypad, allowing the requester to speed dial to contact one of the selected providers. When the requester does not answer the call returned from the system and the requester's calling number has an attached answering machine, the call is received by the answering machine, and the termination report is recorded, thereby allowing the requester to listen to the return call later. When there is no answer from the calling number and there is no answering machine attached to the calling number of the requester, the system calls again at the set interval until the call is completed.

At the time of registration, the configuration details include the provider's business availability (businessavailability), that is, the business hours of each day of the week. During these working hours, the system is configured by default to assume that the provider wants to receive requests. In this embodiment, the system is configured to allow the provider to delete himself/herself from the classification, so no more requests are received. It should be noted that if a provider deletes himself/herself from the classification, the provider no longer appears in any list constructed by the list construction unit 43 of the provider selection unit 33a, 33b, 33c, until the provider affirms Re-introduce him/herself into the classification. This feature allows commercial establishments to be closed for a long time, such as holidays. Outside of business hours, the system does not contact the provider, who is assumed to not want to receive requests. In this embodiment, the provider can temporarily change the assigned business hours by setting one of the "open" or "closed" statuses, but setting the business in this way is only a temporary function, and if it is not reset during the next business hours The assigned business uses the default time for business hours.

In this embodiment, the system may allow the provider to block requests from requesters that cannot be serviced. A typical example is because the location of the requester is not the location served by the provider. Another typical example is that the provider only provides services for a specific group of people, such as young people relative to the elderly, and the requests of the elderly cannot be served. This does not bias the search zone, but only avoids inappropriate connections.

In this embodiment, the system also allows the provider to block requests from requesters whose contact details are restricted. In such a situation, the provider may be concerned that competitors may use the system to gather intelligence secretly.

In this embodiment, these preferences can be set by a category manager using the category management unit 49.

The matching system also includes a classification management unit 49, which supports the maintenance of classification databases, namely the CC database 15 and the CL database 37, and the requester database, namely the first and second RI databases 17, 39. Specifically, the category management unit 49 supports the update of provider entries, the inclusion of new provider entries, the change of list construction parameters for any category, and the inclusion of new categories. In this embodiment, the classification management unit 49 includes a web (World Wide Web) interface to allow remote operation. In a preferred embodiment, multiple category managers operate the category management unit 49, and each category manager is assigned to manage one or more categories.

Finally, it should 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 defined by the appended claims.

For example, in the described embodiment, the system is configured to use voice requests made by telephone, but it is conceivable to use other communication devices 20, 24, such as PDAs, personal computers, set-top boxes, game devices, and game consoles, namely Any device with communication function, as well as other formats for request reception and delivery, such as text encoding requests, such as SMS and e-mail, picture requests, typically containing pictures, still images or video, such as MMS and EMS, and fax requests . In fact, one format can be used to send a request, such as a voice request, and another format can be used to deliver the request, such as an SMS request. In addition, the request may be a multi-format request, for example, including a voice and text encoding request component or a text encoding and picture request component.

Generally speaking, the provider is the person who responds to the corresponding request, but there are exceptions. One such other provider is an observation provider, he can only receive requests, but not respond to requests. Another such provider is a division of labor provider, where one person, usually the decision maker who answers the request, receives the request and passes the request to another person who further processes the request, such as processing customer appointments. Another such provider is the categorized provider, who receives the request and forwards it to another provider.

As an example of categorizing providers, these providers can have a hierarchical structure. Thus, "car sales" can have sub-layers "new cars" and "used cars", and they can also have sub-layers according to the manufacturer of the car, such as Ford, Vauxhall, VW, and so on. The system can support this hierarchical structure, but, consistent with the view that people are the best candidates to process requests, the system only supports classification levels that are manually classified. The matching process is as follows. The requester decides that he/she is looking for a new blue Ford Focus 1.8 Ghia car. The requester makes a call to the category "car sales" and leaves a request. The request is passed to the selected provider in the group. However, one provider may be a dealer who sells cars from multiple manufacturers. For this provider, other departments were previously configured as sub-layers as described above. In this case, the person who heard the request acts as a classifier to decide which department to provide the request to. The system is configured to recognize that the provider is a sorter, and therefore expects to receive a key code related to one of the previously set departments. Upon receiving the key code, the system provides the request to the newly identified provider, which may also be set as a categorizer. After cycling the process one or more times, the request will be sent to providers that do not require further classification.

In addition, when the system is to be used as a private matching system, the setting of the private matching system is similar to the above except that the matching system provides a request to a provider with an internal private matching system. In this case, record all the key codes used to get the response, as these codes allow navigation of the hierarchical structure to report and provide contact details.