Ride-share request matching system and method
Abstract
A real-time request matching system and method for matching a free-format request to a user's provider as a requester when processing the request. Each of the requesters has at least one communicator to create a request and address an answer to it, and each of the providers has at least one to address a request and its respective answer to it. Has one communicator. The method is based on a step of receiving a request from the requester and, for each request, a step of causing the request to be relayed to a selected provider so that it can be addressed. For each request, information about each requester is provided for each request, with the steps of receiving the response from the provider created by each provider, and the affirmative answer indicating that the provider can accept the request. It comprises one or both steps of supplying affirmative answers to any provider given and providing information about the answers to each request from the selected provider to each requester.
Term
Term ended
Projected expiry passed 6 November 2022, 3.9 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
116 claims: 49 independent, 67 dependent
- 1リクエスタとしてのユーザのプロバイダに対する要求を、前記要求の処理時にマッチングするためのマッチングシステムであって、前記リクエスタのそれぞれは、要求を作成すると共に、それに対するそれぞれの回答にアドレスするための少なくとも1つのコミュニケータを有し、また前記プロバイダのそれぞれは、要求およびそれに対するそれぞれの回答にアドレスするための少なくとも1つのコミュニケータを有し、前記システムは、リクエスタからの要求を受信するための少なくとも1つの要求受信ユニットと、前記要求のそれぞれが、選択されたプロバイダへ、それによりアドレスされるように中継されるようにするための少なくとも1つの要求中継ユニットと、それぞれの要求に基づいてそれぞれのプロバイダによって作成されたプロバイダからの回答を受信するための少なくとも1つの回答受信ユニットと、肯定回答はプロバイダが要求を受けることができることを示すものとして、各要求に対して、それぞれのリクエスタに関する情報をそれぞれの要求に対する肯定回答を与えられた任意のプロバイダへ供給すること、および選択されたプロバイダからのそれぞれの要求に対する回答に関する情報をそれぞれのリクエスタへ供給すること、の一方または双方を行うための少なくとも1つの情報供給ユニットとを備えることを特徴とするシステム。
- 2前記システムは、実時間マッチングシステムである請求項1に記載のシステム。
- 3前記要求は、フリーフォーマット要求である請求項1または2に記載のシステム。
- 4前記要求は、音声要求を含む請求項1~3のいずれかに記載のシステム。
- 5前記コミュニケータは、電話、PDA、パーソナルコンピュータおよびゲームデバイスのような移動コミュニケータを含む請求項1~4のいずれかに記載のシステム。
- 6前記コミュニケータは、電話、ファックス機器、パーソナルコンピュータ、セットトップボックスおよびゲームコンソールのような固定コミュニケータを含む請求項1~5のいずれかに記載のシステム。
- 7前記コミュニケータは、電話のような複合型固定/移動コミュニケータを含む請求項1~6のいずれかに記載のシステム。
- 8少なくとも1つのインバウンド通信ユニットを備え、それぞれは少なくとも1つの要求受信ユニットを有する請求項1~7のいずれかに記載のシステム。
- 9少なくとも1つのアウトバウンド通信ユニットを備え、それぞれは少なくとも1つの要求中継ユニットと、少なくとも1つの回答受信ユニットと、少なくとも1つの情報供給ユニットとを有する請求項1~8のいずれかに記載のシステム。
- 10少なくとも1つの通信ユニットを備え、それぞれは少なくとも1つの要求受信ユニットと、少なくとも1つの要求中継ユニットと、少なくとも1つの回答受信ユニットと、少なくとも1つの情報供給ユニットとを有する請求項1~7のいずれかに記載のシステム。
- 11前記少なくとも1つの要求中継ユニットは、選択されたプロバイダのコミュニケータに要求を直接中継するものとして構成されている請求項1~10のいずれかに記載のシステム。
- 12前記少なくとも1つの要求中継ユニットは、要求が、その問い合わせをして内容を設定することなく、中継されるものとして構成されている請求項1~11のいずれかに記載のシステム。
- 13前記少なくとも1つの要求受信ユニットは、要求を受信するための複数の受信器を含み、各要求は、予め決定可能な分類に関連した分類連絡アドレスを有する請求項1~12のいずれかに記載のシステム。
- 14前記分類連絡アドレスは、ダイアル番号である請求項13に記載のシステム。
- 15要求にアドレスするプロバイダを選択するための少なくとも1つのプロバイダ選択ユニットを備える請求項1~14のいずれかに記載のシステム。
- 16前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は、それぞれの要求に割り当てられた地理的位置と、プロバイダに割り当てられた地理的位置または地理的区域の一方または双方とに基づいて、要求に対するプロバイダを選択するものとして構成されている請求項15に記載のシステム。
- 17前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタの現在の地理的位置である請求項16に記載のシステム。
- 18前記現在の地理的位置は、それぞれのリクエスタのコミュニケータのコミュニケータ連絡アドレスであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項17に記載のシステム。
- 19前記コミュニケータ連絡アドレスは、ダイアル番号である請求項18に記載のシステム。
- 20前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタによって割り当てられる代替地理的位置である請求項16に記載のシステム。
- 21前記代替地理的位置は、コミュニケータのコミュニケータ連絡アドレスから決定されるものであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項20に記載のシステム。
- 22前記コミュニケータ連絡アドレスは、ダイアル番号である請求項21に記載のシステム。
- 23移動コミュニケータの地理的位置は、セル識別法、三角測量法、無線位置把握法またはGPSのような衛星位置把握法の1つから決定される請求項15~22のいずれかに記載のシステム。
- 24固定コミュニケータの地理的位置は、それぞれの割り当てられた位置から決定される請求項15~23のいずれかに記載のシステム。
- 25前記少なくとも1つのプロバイダ選択ユニットは、それぞれの要求に割り当てられた地理的位置に対して予め決定可能な空間地理的区域内で、要求に対するプロバイダを選択するものとして構成されている請求項15~24のいずれかに記載のシステム。
- 26前記予め決定可能な空間地理的区域は、それぞれの要求に割り当てられた地理的位置に対する地理的半径か、それぞれの要求に割り当てられた地理的位置に対する移動の距離か、それぞれの要求に割り当てられた地理的位置に対する移動の時間の中の1つである請求項25に記載のシステム。
- 27前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は、それぞれのリクエスタに対する少なくとも1つのリクエスタ特徴に基づいて、例えばそれぞれのリクエスタに対する割り当てられた特徴またはそれぞれのリクエスタによる情報作成時の特徴入力としての、地理的に関係した社会経済的情報に基づいて、要求に対するプロバイダを選択するものとして構成されている請求項15~26のいずれかに記載のシステム。
- 28前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は、プロバイダに対する少なくとも1つのプロバイダ特徴に基づいて、例えばそれぞれのプロバイダに対する割り当てられた特徴としての、予め決定可能なプロフィールを有すること、または連絡の詳細を提供することをリクエスタに要求することに基づいて、要求に対するプロバイダを選択するものとして構成されている請求項15~27のいずれかに記載のシステム。
- 29前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は現在時刻に基づいて、要求に対するプロバイダを選択するものとして構成されている請求項15~28のいずれかに記載のシステム。
- 30前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は少なくとも1つの分類特徴に基づいて、例えばそれぞれの分類に対する割り当てられた特徴としての、プロバイダを選択するための選択機構に基づいて、要求に対するプロバイダを選択するものとして構成されている請求項15~29のいずれかに記載のシステム。
- 31前記少なくとも1つの要求中継ユニットは、要求を、予め決定可能な数の選択されたプロバイダへ、それによりアドレスされるように中継するものとして構成されている請求項1~30のいずれかに記載のシステム。
- 32前記少なくとも1つの要求中継ユニットは、要求を、選択されたプロバイダへマルチキャストするものとして構成されており、前記要求は、複数のプロバイダへ、それによりアドレスされるように中継されるものである請求項1~30のいずれかに記載のシステム。
- 33前記少なくとも1つの情報供給ユニットは、各要求に対して、前記要求に対する肯定回答を与えられたプロバイダに関する情報をそれぞれのリクエスタへ供給するものとして構成されている請求項1~32のいずれかに記載のシステム。
- 34リクエスタとしてのユーザのプロバイダに対する要求を、前記要求の処理時にマッチングするためのマッチングシステムであって、複数のリクエスタ・コミュニケータと、複数のプロバイダ・コミュニケータとを備え、各リクエスタ・コミュニケータは、要求を作成し、またそれに対するそれぞれの回答にアドレスするときにリクエスタによって使用されるものであり、前記回答の少なくともいくつかは、選択されたプロバイダからそれぞれのリクエスタへの回答に関する情報を含んでおり、各プロバイダ・コミュニケータは、要求およびそれに対するそれぞれの回答にアドレスするときにプロバイダによって使用されるものであり、前記要求は、それぞれの選択されたプロバイダへアドレスされるように中継されるものであり、また前記要求の少なくともいくつかはそれぞれの要求のリクエスタに関する情報を含んでおり、それぞれの要求に対して肯定回答が与えられ、肯定回答はプロバイダが要求を受けることができることを示すものであることを特徴とするシステム。
- 35前記システムは、実時間マッチングシステムである請求項34に記載のシステム。
- 36前記要求は、フリーフォーマット要求である請求項34または35に記載のシステム。
- 37前記要求は、音声要求を含む請求項34~36のいずれかに記載のシステム。
- 38前記コミュニケータは、電話、PDA、パーソナルコンピュータおよびゲームデバイスのような移動コミュニケータを含む請求項34~37のいずれかに記載のシステム。
- 39前記コミュニケータは、電話、ファックス機器、パーソナルコンピュータ、セットトップボックスおよびゲームコンソールのような固定コミュニケータを含む請求項34~38のいずれかに記載のシステム。
- 40前記コミュニケータは、電話のような複合型固定/移動コミュニケータを含む請求項34~39のいずれかに記載のシステム。
- 41要求は、それぞれの選択されたプロバイダへ直接中継される請求項34~40のいずれかに記載のシステム。
- 42要求は、その問い合わせをして内容を設定することなく中継される請求項34~41のいずれかに記載のシステム。
- 43要求を受信するための複数の受信器を含んだ通信ユニットを更に備え、各要求は、予め決定可能な分類に関連した分類連絡アドレスを有する請求項34~42のいずれかに記載のシステム。
- 44前記分類連絡アドレスは、ダイアル番号である請求項43に記載のシステム。
- 45少なくとも一部は、それぞれの要求に割り当てられた地理的位置と、プロバイダに割り当てられた地理的位置または地理的区域の一方または双方とに基づいて、要求に対するプロバイダが選択される請求項34~44のいずれかに記載のシステム。
- 46前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタの現在の地理的位置である請求項45に記載のシステム。
- 47前記現在の地理的位置は、それぞれのリクエスタのコミュニケータのコミュニケータ連絡アドレスであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項46に記載のシステム。
- 48前記コミュニケータ連絡アドレスは、ダイアル番号である請求項47に記載のシステム。
- 49前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタによって割り当てられる代替地理的位置である請求項45に記載のシステム。
- 50前記代替地理的位置は、コミュニケータのコミュニケータ連絡アドレスから決定されるものであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項49に記載のシステム。
- 51前記コミュニケータ連絡アドレスは、ダイアル番号である請求項50に記載のシステム。
- 52それぞれの要求に割り当てられた地理的位置に対して予め決定可能な空間地理的区域内で、プロバイダが選択される請求項34~51のいずれかに記載のシステム。
- 53少なくとも一部は、それぞれのリクエスタに対する少なくとも1つのリクエスタ特徴に基づいて、例えばそれぞれのリクエスタに対する割り当てられた特徴またはそれぞれのリクエスタによる情報作成時の特徴入力としての、地理的に関係した社会経済的情報に基づいて、要求に対するプロバイダが選択される請求項34~52のいずれかに記載のシステム。
- 54少なくとも一部は、プロバイダに対する少なくとも1つのプロバイダ特徴に基づいて、例えばそれぞれのプロバイダに対する割り当てられた特徴としての、予め決定可能なプロフィールを有すること、または連絡の詳細を提供することをリクエスタに要求することに基づいて、要求に対するプロバイダが選択される請求項34~53のいずれかに記載のシステム。
- 55少なくとも一部は現在時刻に基づいて、要求に対するプロバイダが選択される請求項34~54のいずれかに記載のシステム。
- 56少なくとも一部は少なくとも1つの分類特徴に基づいて、例えばそれぞれの分類に対する割り当てられた特徴としての、プロバイダを選択するための選択機構に基づいて、要求に対するプロバイダが選択される請求項34~55のいずれかに記載のシステム。
- 57リクエスタとしてのユーザのプロバイダに対する要求を、前記要求の処理時にマッチングするためのマッチングシステムであって、前記リクエスタのそれぞれは、要求を作成すると共に、それに対する回答にアドレスするための少なくとも1つのコミュニケータを有し、また前記プロバイダのそれぞれは、要求にアドレスするための少なくとも1つのコミュニケータを有し、前記システムは、リクエスタからの要求を受信するための少なくとも1つの要求受信ユニットと、前記要求のそれぞれが、選択されたプロバイダへ、それによりアドレスされるように中継されるようにするための少なくとも1つの要求中継ユニットと、それぞれの要求に基づいてそれぞれのプロバイダによって作成されたプロバイダからの回答を受信するための少なくとも1つの回答受信ユニットと、を備えることを特徴とするシステム。
- 58リクエスタとしてのユーザのプロバイダに対する要求を、前記要求の処理時にマッチングするためのマッチングシステムであって、複数のリクエスタ・コミュニケータと、複数のプロバイダ・コミュニケータと、前記リクエスタ・コミュニケータおよび前記プロバイダ・コミュニケータと通信可能な少なくとも1つの通信ユニットとを備え、各リクエスタ・コミュニケータは、要求を作成すると共に、それに対するそれぞれの回答にアドレスするときにリクエスタによって使用されるものであり、各プロバイダ・コミュニケータは、要求およびそれに対するそれぞれの回答にアドレスするときにプロバイダによって使用されるものであり、前記少なくとも1つの通信ユニットは、プロバイダを選択して、リクエスタによって作成された各要求にアドレスするための少なくとも1つのプロバイダ選択ユニットを含み、前記システムは、各要求に対し、前記要求が、選択されたプロバイダへ、それによりアドレスされるように中継されるものとして構成されていることを特徴とするシステム。
- 59前記システムは更に、要求に対し、前記それぞれのリクエスタが、選択されたプロバイダからの前記要求に対する回答に関する情報を供給されるように構成されている請求項58に記載のシステム。
- 60前記システムは、実時間マッチングシステムである請求項58または59に記載のシステム。
- 61前記要求は、フリーフォーマット要求である請求項58~60のいずれかに記載のシステム。
- 62前記要求は、音声要求を含む請求項58~61のいずれかに記載のシステム。
- 63前記コミュニケータは、電話、PDA、パーソナルコンピュータおよびゲームデバイスのような移動コミュニケータを含む請求項58~62のいずれかに記載のシステム。
- 64前記コミュニケータは、電話、ファックス機器、パーソナルコンピュータ、セットトップボックスおよびゲームコンソールのような固定コミュニケータを含む請求項58~63のいずれかに記載のシステム。
- 65前記コミュニケータは、電話のような複合型固定/移動コミュニケータを含む請求項58~64のいずれかに記載のシステム。
- 66前記システムは、要求が、選択されたプロバイダの前記プロバイダ・コミュニケータへ直接中継されるように構成されている請求項58~65のいずれかに記載のシステム。
- 67前記システムは、要求が、その問い合わせをして内容を設定することなく中継されるものとして構成されている請求項58~66のいずれかに記載のシステム。
- 68前記少なくとも1つの通信ユニットは、要求を受信するための複数の受信器を含み、各要求は、予め決定可能な分類に関連した分類連絡アドレスを有する請求項58~67のいずれかに記載のシステム。
- 69前記分類連絡アドレスは、ダイアル番号である請求項68に記載のシステム。
- 70前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は、それぞれの要求に割り当てられた地理的位置と、プロバイダに割り当てられた地理的位置または地理的区域の一方または双方とに基づいて、要求に対するプロバイダを選択するものとして構成されている請求項58~69のいずれかに記載のシステム。
- 71前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタの現在の地理的位置である請求項70に記載のシステム。
- 72前記現在の地理的位置は、それぞれのリクエスタのコミュニケータのコミュニケータ連絡アドレスであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項71に記載のシステム。
- 73前記コミュニケータ連絡アドレスは、ダイアル番号である請求項72に記載のシステム。
- 74前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタによって割り当てられる代替地理的位置である請求項70に記載のシステム。
- 75前記代替地理的位置は、コミュニケータのコミュニケータ連絡アドレスから決定されるものであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項74に記載のシステム。
- 76前記コミュニケータ連絡アドレスは、ダイアル番号である請求項75に記載のシステム。
- 77前記少なくとも1つのプロバイダ選択ユニットは、それぞれの要求に割り当てられた地理的位置に対して予め決定可能な空間地理的区域内で、プロバイダを選択するものとして構成されている請求項58~76のいずれかに記載のシステム。
- 78前記予め決定可能な空間地理的区域は、それぞれの要求に割り当てられた地理的位置に対する地理的半径か、それぞれの要求に割り当てられた地理的位置に対する移動の距離か、それぞれの要求に割り当てられた地理的位置に対する移動の時間の中の1つである請求項77に記載のシステム。
- 79前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は、それぞれのリクエスタに対する少なくとも1つのリクエスタ特徴に基づいて、例えばそれぞれのリクエスタに対する割り当てられた特徴またはそれぞれのリクエスタによる情報作成時の特徴入力としての、地理的に関係した社会経済的情報に基づいて、要求に対するプロバイダを選択するものとして構成されている請求項58~78のいずれかに記載のシステム。
- 80前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は、プロバイダに対する少なくとも1つのプロバイダ特徴に基づいて、例えばそれぞれのプロバイダに対する割り当てられた特徴としての、予め決定可能なプロフィールを有すること、または連絡の詳細を提供することをリクエスタに要求することに基づいて、要求に対するプロバイダを選択するものとして構成されている請求項58~79のいずれかに記載のシステム。
- 81前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は現在時刻に基づいて、要求に対するプロバイダを選択するものとして構成されている請求項58~80のいずれかに記載のシステム。
- 82前記少なくとも1つのプロバイダ選択ユニットは、少なくとも一部は少なくとも1つの分類特徴に基づいて、例えばそれぞれの分類に対する割り当てられた特徴としての、プロバイダを選択するための選択機構に基づいて、要求に対するプロバイダを選択するものとして構成されている請求項58~81のいずれかに記載のシステム。
- 83前記システムは、要求が、それによりアドレス指定されたように、予め決定可能な数の選択されたプロバイダの前記プロバイダ・コミュニケータへ中継されるように構成されている請求項58~82のいずれかに記載のシステム。
- 84前記システムは、要求を、それぞれの選択されたプロバイダの前記プロバイダ・コミュニケータへマルチキャストするものとして構成されており、前記要求は、複数のプロバイダへ、それによりアドレスされるように中継されるものである請求項58~83のいずれかに記載のシステム。
- 85リクエスタとしてのユーザのプロバイダに対する要求を、前記要求の処理時にマッチングする方法であって、前記リクエスタのそれぞれは、要求を作成すると共に、それに対する回答にアドレスするための少なくとも1つのコミュニケータを有し、また前記プロバイダのそれぞれは、要求およびそれに対するそれぞれの回答にアドレスするための少なくとも1つのコミュニケータを有し、前記方法は、リクエスタからの要求を受信するステップと、各要求に対し、前記要求が、選択されたプロバイダへ、それによりアドレスされるように中継されるようにするステップと、それぞれの要求に基づいてそれぞれのプロバイダによって作成されたプロバイダからの回答を受信するステップと、肯定回答はプロバイダが要求を受けることができることを示すものとして、各要求に対して、それぞれのリクエスタに関する情報をそれぞれの要求に対する肯定回答を与えられた任意のプロバイダへ供給すること、および選択されたプロバイダからのそれぞれの要求に対する回答に関する情報をそれぞれのリクエスタへ供給すること、の一方または双方を行うステップとを備えることを特徴とする方法。
- 86前記方法は、実時間マッチング方法である請求項85に記載の方法。
- 87前記要求は、フリーフォーマット要求である請求項85または86に記載の方法。
- 88前記要求は、音声要求を含む請求項85~87のいずれかに記載の方法。
- 89前記コミュニケータは、電話、PDA、パーソナルコンピュータおよびゲームデバイスのような移動コミュニケータを含む請求項85~87のいずれかに記載の方法。
- 90前記コミュニケータは、電話、ファックス機器、パーソナルコンピュータ、セットトップボックスおよびゲームコンソールのような固定コミュニケータを含む請求項85~89のいずれかに記載の方法。
- 91前記コミュニケータは、電話のような複合型固定/移動コミュニケータを含む請求項85~90のいずれかに記載の方法。
- 92要求が、選択されたプロバイダへ、それによりアドレスされるように中継されるようにするステップは、選択されたプロバイダの前記コミュニケータへ要求を直接中継するステップを含む請求項85~91のいずれかに記載の方法。
- 93要求は、その問い合わせをして内容を設定することなく中継される請求項85~92のいずれかに記載の方法。
- 94リクエスタからの要求を受信するステップは、リクエスタからの要求を複数の受信器で受信するステップを含み、前記要求のそれぞれは、予め決定可能な分類に関連した分類連絡アドレスを有する請求項85~93のいずれかに記載の方法。
- 95前記分類連絡アドレスは、ダイアル番号である請求項94に記載の方法。
- 96要求にアドレスするそれぞれのプロバイダを選択するステップを更に備える請求項85~95のいずれかに記載の方法。
- 97要求にアドレスするそれぞれのプロバイダを選択するステップは、少なくとも一部は、それぞれの要求に割り当てられた地理的位置と、プロバイダに割り当てられた地理的位置または地理的区域の一方または双方とに基づいて、要求にアドレスするそれぞれのプロバイダを選択するステップを含む請求項85~95のいずれかに記載の方法。
- 98前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタの現在の地理的位置である請求項97に記載の方法。
- 99前記現在の地理的位置は、それぞれのリクエスタのコミュニケータのコミュニケータ連絡アドレスであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項98に記載の方法。
- 100前記コミュニケータ連絡アドレスは、ダイアル番号である請求項99に記載の方法。
- 101前記それぞれの要求に割り当てられた地理的位置は、それぞれのリクエスタによって割り当てられる代替地理的位置である請求項97に記載の方法。
- 102前記代替地理的位置は、コミュニケータのコミュニケータ連絡アドレスから決定されるものであり、前記コミュニケータ連絡アドレスは、割り当てられた位置を有する請求項101に記載の方法。
- 103前記コミュニケータ連絡アドレスは、ダイアル番号である請求項102に記載の方法。
- 104移動コミュニケータの地理的位置は、セル識別法、三角測量法、無線位置把握法またはGPSのような衛星位置把握法の1つから決定される請求項96~103のいずれかに記載の方法。
- 105固定コミュニケータの地理的位置は、割り当てられた位置から決定される請求項96~104のいずれかに記載の方法。
- 106要求にアドレスするそれぞれのプロバイダを選択するステップは、それぞれの要求に割り当てられた地理的位置に対して予め決定可能な空間地理的区域内で、要求にアドレスするそれぞれのプロバイダを選択するステップを含む請求項96~105のいずれかに記載の方法。
- 107前記予め決定可能な空間地理的区域は、それぞれの要求に割り当てられた地理的位置に対する地理的半径か、それぞれの要求に割り当てられた地理的位置に対する移動の距離か、それぞれの要求に割り当てられた地理的位置に対する移動の時間の中の1つである請求項106に記載の方法。
- 108要求にアドレスするそれぞれのプロバイダを選択するステップは、少なくとも一部は、それぞれのリクエスタに対する少なくとも1つのリクエスタ特徴に基づいて、例えばそれぞれのリクエスタに対する割り当てられた特徴またはそれぞれのリクエスタによる情報作成時の特徴入力としての、地理的に関係した社会経済的情報に基づいて、要求にアドレスするそれぞれのプロバイダを選択するステップを含む請求項96~107のいずれかに記載の方法。
- 109要求にアドレスするそれぞれのプロバイダを選択するステップは、少なくとも一部は、プロバイダに対する少なくとも1つのプロバイダ特徴に基づいて、例えばそれぞれのプロバイダに対する割り当てられた特徴としての、予め決定可能なプロフィールを有すること、または連絡の詳細を提供することをリクエスタに要求することに基づいて、要求にアドレスするそれぞれのプロバイダを選択するステップを含む請求項96~108のいずれかに記載の方法。
- 110要求にアドレスするそれぞれのプロバイダを選択するステップは、少なくとも一部は現在時刻に基づいて、要求にアドレスするそれぞれのプロバイダを選択するステップを含む請求項96~109のいずれかに記載の方法。
- 111要求にアドレスするそれぞれのプロバイダを選択するステップは、少なくとも一部は少なくとも1つの分類特徴に基づいて、例えばそれぞれの分類に対する割り当てられた特徴としての、プロバイダを選択するための選択機構に基づいて、要求にアドレスするそれぞれのプロバイダを選択するステップを含む請求項96~110のいずれかに記載の方法。
- 112要求が、選択されたプロバイダへ、それによりアドレスされるように中継されるようにするステップは、要求を、予め決定可能な数の選択されたプロバイダへ、それによりアドレスされるように中継するステップを含む請求項85~111のいずれかに記載の方法。
- 113要求が、選択されたプロバイダへ、それによりアドレスされるように中継されるようにするステップは、要求を、選択されたプロバイダへマルチキャストするステップを含み、前記要求は、複数のプロバイダへ、それによりアドレスされるように中継される請求項85~112のいずれかに記載の方法。
- 114情報を供給するステップは、各要求に対して、前記要求に対する肯定回答を与えられたプロバイダに関する情報をそれぞれのリクエスタへ供給するステップを含む請求項85~113のいずれかに記載の方法。
- 115リクエスタとしてのユーザのプロバイダに対する要求を、前記要求の処理時にマッチングする方法であって、前記リクエスタのそれぞれは、要求を作成すると共に、それに対する回答にアドレスするための少なくとも1つのコミュニケータを有し、また前記プロバイダのそれぞれは、要求にアドレスするための少なくとも1つのコミュニケータを有し、前記方法は、リクエスタからの要求を受信するステップと、各要求に対し、前記要求が、選択されたプロバイダへ、それによりアドレスされるように中継されるようにするステップと、それぞれの要求に基づいてそれぞれのプロバイダによって作成されたプロバイダからの回答を受信するステップとを備えることを特徴とする方法。
- 116リクエスタとしてのユーザのプロバイダに対する要求を、前記要求の処理時にマッチングする方法であって、リクエスタからの要求を有する信号を受信するステップと、各要求に対し、前記要求を受信されたように有する信号を、選択されたプロバイダへ送信するステップと、それぞれの要求に基づいてそれぞれのプロバイダによって作成された、選択されたプロバイダからの回答を有する信号を受信するステップと、肯定回答はプロバイダが要求を受けることができることを示すものとして、各要求に対して、それぞれの要求に対する肯定回答を与えられた任意のプロバイダ向けの、それぞれのリクエスタに関する情報を有する信号と、それぞれのリクエスタ向けの、選択されたプロバイダからのそれぞれの要求に対する回答に関する情報を有する信号の一方または双方を送信するステップと備えることを特徴とする方法。
Independent claims116
528 paragraphs, as filed
[Technical field]
【0001】
The present invention relates to a requirement matching system and method for matching a request to a user's provider (provider) as a requester (requester) at the time of processing the request.
【0002】
The present invention has found applications in many areas, especially in classification structures where the user, as a requester, wishes to create a community of interests, that is, requests for multiple providers that are commonly classified. I'm finding out.
【0003】
It is foreseen that the present invention will find special applications related to transaction classification in which providers are grouped according to the goods and services provided.
【0004】
Such trade classifications are now embodied as local trade directories, such as Yellow Pages and Thomson Directory in the United Kingdom. Then, when looking for a thing or service, one uses that local directory to locate the provider for that thing or service.
【0005】
When using such a directory, one first determines the classification most likely to supply the item or service, reviews the corresponding section in the directory, selects one or more providers, and then to those providers. to call. When calling a provider, the same request is made repeatedly to each provider, for example, "Can you provide goods / services X at cost Y by Z days?" Often, especially when the request is identified, for example, "Do you have auto parts X in stock?", The person calls many of the selected providers to make the request. You need to find one provider that you can meet. This is a special case where two or more providers must be identified so that they can compare costs, delivery times, etc., for example.
【0006】
Such a process spends time as it needs to first identify possible providers and then establish conversations with many providers before one or more providers that can meet that request are identified. .. Moreover, the cost is relatively high due to the telephone costs associated with each of the many providers.
【0007】
Although the present invention is foreseen to find special applications related to transaction classification, the present invention also has applications related to many other classification structures.
【0008】
One such other classification structure is the broadcast classification. In this case, one request can be broadcast to multiple providers, allowing them to get answers from all of the providers, and logging either or both of the positive and negative answers from the providers, as well as the providers who do not answer. To do so. It is foreseen that such classifications will find application, for example, in obtaining information in response to questions when constructing marketing lists and polling.
【0009】
Another such other classification structure is community classification. In this case, those with common interests are categorized in common, allowing one requester to make one request. This requester can also be one provider in the community classification. This provider is included in some or all of others as a provider in the community classification. An example of community classification is a local help group. Members of this group give assistance for each specific question. Requests for assistance can be made by members.
【0010】
Another such classification structure that is different is task classification. In this case, one request is made for multiple providers that need to perform one task. It is foreseen that such classifications will find special applications in a collective environment. In this case, the request can be made by a special department, such as the purchasing or marketing department.
【0011】
Further different such other classification structures are promotional classifications. In this case, the special promotion typically runs for a short period of time and is endorsed by multiple providers. An example of a promotional classification is a holiday break, such as a fixed-price weekend break. In this case, the provider wishing to participate in the promotion decides to join the category. In a preferred embodiment, the provider is capable of deciding to enter or leave the classification according to the availability of goods and services provided by each provider.
【0012】
One object of the present invention is to provide a requirement matching system and method for matching requirements of a user as a requester to a provider. In this case, the requester is not required to identify possible providers and contact those providers to determine if the request is acceptable.
【0013】
In one embodiment, the present invention provides a matching system for matching a request to a user's provider as a requester when processing the request. Each of the requesters has at least one communicator to create a request and address its own answer to it, and each of the providers to address a request and its respective answer to it. Have at least one communicator. The system has at least one request receiving unit for receiving requests from the requester and at least one for each of the requests to be relayed to the selected provider to be addressed by it. One request relay unit and at least one answer receiving unit for receiving answers from the provider created by each provider as a human decision maker based on each request, and the affirmative answer is by the provider. For each request, providing information about each requester to any provider given a positive answer to each request, and each from the selected provider, as an indication that the request can be accepted. It comprises at least one information supply unit for supplying information about the response to the request to each requester, one or both.
【0014】
The system is preferably a real-time matching system.
【0015】
The requirement is preferably a free format requirement.
【0016】
The request preferably includes a voice request.
【0017】
The communicator preferably includes mobile communicators such as telephones, PDAs, personal computers and gaming devices.
【0018】
The communicator preferably includes a fixed communicator such as a telephone, fax machine, personal computer, set-top box and game console.
【0019】
The communicator preferably includes a composite fixed / mobile communicator such as a telephone.
【0020】
In one embodiment, the system comprises at least one inbound communication unit, each having at least one request receiving unit.
【0021】
In one embodiment, the system comprises at least one outbound communication unit, each having at least one request relay unit, at least one response receive unit, and at least one information supply unit.
【0022】
In another embodiment, the system comprises at least one communication unit, each of which has at least one request receiving unit, at least one request relay unit, at least one answer receiving unit, and at least one information supply. Has a unit.
【0023】
In one embodiment, the at least one request relay unit is configured to relay the request directly to the communicator of the selected provider.
【0024】
It is preferable that the at least one request relay unit is configured such that the request is relayed without inquiring about the request and setting the content.
【0025】
It is preferred that the at least one request receiving unit includes a plurality of receivers for receiving the request, and each request has a classification contact address associated with a predeterminable classification.
【0026】
The classification contact address is more preferably a dial number.
【0027】
In one embodiment, the system further comprises at least one provider selection unit for selecting a provider to address the request.
【0028】
The at least one provider selection unit is a provider for a request, at least in part, based on the geographic location assigned to each request and one or both of the geographical locations or geographic areas assigned to the provider. It is preferable that it is configured to select.
【0029】
In one embodiment, the geographic location assigned to each of the above requests is the current geographic location of each requester.
【0030】
The current geographic location is preferably the communicator contact address of the communicator of each requester, and the communicator contact address preferably has an assigned position.
【0031】
The communicator contact address is more preferably a dial number.
【0032】
In one embodiment, the geographic location assigned to each of the above requests is an alternative geographic location assigned by each requester.
【0033】
The alternative geographic location is determined from the communicator contact address of the communicator, and the communicator contact address preferably has an assigned location.
【0034】
The communicator contact address is more preferably a dial number.
【0035】
The geographic location of the mobile communicator is preferably determined from one of the cell identification methods, triangulation methods, radio positioning methods or satellite positioning methods such as GPS.
【0036】
The geographic location of the fixed communicator is preferably determined from each assigned location.
【0037】
The at least one provider selection unit is preferably configured to select a provider for a request within a predeterminable spatial geographic area for the geographical location assigned to each request.
【0038】
The predeterminable spatial geographic area was assigned to each request, whether it was the geographic radius for the geographic location assigned to each request, the distance traveled to the geographic location assigned to each request, or the distance traveled to each request. More preferably it is one of the travel times relative to the geographic location.
【0039】
The at least one provider selection unit, at least in part, is based on at least one requester feature for each requester, for example, as a feature assigned to each requester or as a feature input when information is created by each requester. It is preferably configured to select a provider for the request based on geographically relevant socio-economic information.
【0040】
The at least one provider selection unit has, at least in part, a predeterminable profile based on at least one provider feature for the provider, eg, as an assigned feature for each provider, or contact details. It is preferably configured to select a provider for the request based on requesting the requester to provide.
【0041】
The at least one provider selection unit is preferably configured to select a provider for a request, at least in part, based on the current time.
【0042】
The at least one provider selection unit provides providers for a request, at least in part, based on at least one classification feature, eg, a selection mechanism for selecting a provider, as an assigned feature for each classification. It is preferably configured to be selected.
【0043】
The at least one request relay unit is preferably configured to relay requests to a predetermined number of selected providers, thereby addressing them.
【0044】
The at least one request relay unit may be configured to multicast the request to a selected provider, and the request may be relayed to and thereby addressed to a plurality of providers. preferable.
【0045】
It is preferable that at least one information supply unit is configured to supply information about a provider who has been given a positive answer to the request to each requester for each request.
【0046】
In another embodiment, the present invention provides a matching system for matching a request to a user's provider as a requester when processing the request. The system includes a plurality of requester communicators and a plurality of provider communicators. Each requester communicator is used by the requester when making a request and addressing its respective answer to it, and at least some of the above answers are from the selected provider to the respective requester. Contains information about the answer, each provider communicator is used by the provider when addressing the request and its respective answer to it, and the request is addressed to its respective selected provider. And at least some of the above requests contain information about the requester of each request, a positive answer is given for each request, and the affirmative answer is that the provider receives the request. It shows that you can do it.
【0047】
The system is preferably a real-time matching system.
【0048】
The requirement is preferably a free format requirement.
【0049】
The request preferably includes a voice request.
【0050】
The communicator preferably includes mobile communicators such as telephones, PDAs, personal computers and gaming devices.
【0051】
The communicator preferably includes a fixed communicator such as a telephone, fax machine, personal computer, set-top box and game console.
【0052】
The communicator preferably includes a composite fixed / mobile communicator such as a telephone.
【0053】
In one embodiment, the request is relayed directly to each selected provider.
【0054】
The request is preferably relayed without making the inquiry and setting the content.
【0055】
It is preferred that the communication unit further includes a plurality of receivers for receiving requests, and each request has a classification contact address associated with a predeterminable classification.
【0056】
The classification contact address is more preferably a dial number.
【0057】
At least in part, it is preferred that the provider for the request be selected based on the geographic location assigned to each request and one or both of the geographic locations or geographic areas assigned to the provider.
【0058】
In one embodiment, the geographic location assigned to each of the above requests is the current geographic location of each requester.
【0059】
The current geographic location is preferably the communicator contact address of the communicator of each requester, and the communicator contact address preferably has an assigned position.
【0060】
The communicator contact address is more preferably a dial number.
【0061】
In one embodiment, the geographic location assigned to each of the above requests is an alternative geographic location assigned by each requester.
【0062】
The alternative geographic location is determined from the communicator contact address of the communicator, and the communicator contact address preferably has an assigned location.
【0063】
The communicator contact address is more preferably a dial number.
【0064】
It is preferred that the provider be selected within a spatial geographic area that is predeterminable for the geographic location assigned to each request.
【0065】
Geographically relevant socio-economic information, at least in part, based on at least one requester feature for each requester, for example as a feature assigned to each requester or as a feature input when creating information by each requester. It is preferable that the provider for the request is selected based on.
【0066】
At least in part requires the requester to have a pre-determinable profile, or to provide contact details, based on at least one provider feature for each provider, for example as an assigned feature for each provider. Based on this, it is preferable that the provider for the request is selected.
【0067】
It is preferable that the provider for the request is selected, at least in part, based on the current time.
【0068】
It is preferred that the provider for the request is selected based on at least one classification feature, eg, a selection mechanism for selecting a provider, such as an assigned feature for each classification.
【0069】
In a different form, the present invention provides a matching system for matching a request to a user's provider as a requester when processing the request. Each of the requesters has at least one communicator to create the request and address the response to it, and each of the providers has at least one communicator to address the request. The system has at least one request receiving unit for receiving requests from the requester and at least one for each of the requests to be relayed to the selected provider to be addressed by it. It comprises one request relay unit and at least one response receiving unit for receiving responses from providers created by each provider as a human decision maker based on each request.
【0070】
In a further different form, the present invention provides a matching system for matching a request to a user's provider as a requester when processing the request. The system includes a plurality of requester communicators, a plurality of provider communicators, and at least one communication unit capable of communicating with the requester communicator and the provider communicator. Each requester communicator is used by the requester when creating a request and addressing its respective response to it, and each provider communicator when addressing the request and its respective response to it. The system includes at least one provider selection unit for selecting a provider and addressing each request made by the requester. In response to the request, the request is configured to be relayed to the selected provider as a human decision maker to be addressed thereby.
【0071】
It is preferred that the system is further configured such that, in response to a request, each of the requesters is provided with information regarding a response to the request from a selected provider.
【0072】
The system is preferably a real-time matching system.
【0073】
The requirement is preferably a free format requirement.
【0074】
The request preferably includes a voice request.
【0075】
The communicator preferably includes mobile communicators such as telephones, PDAs, personal computers and gaming devices.
【0076】
The communicator preferably includes a fixed communicator such as a telephone, fax machine, personal computer, set-top box and game console.
【0077】
The communicator preferably includes a composite fixed / mobile communicator such as a telephone.
【0078】
In one embodiment, the system is configured such that the request is relayed directly to the provider communicator of the selected provider.
【0079】
The system is preferably configured such that the request is relayed without making the inquiry and setting the content.
【0080】
It is preferred that the at least one communication unit includes a plurality of receivers for receiving requests, and each request has a classification contact address associated with a predeterminable classification.
【0081】
The classification contact address is more preferably a dial number.
【0082】
The at least one provider selection unit is a provider for a request, at least in part, based on the geographic location assigned to each request and one or both of the geographical locations or geographic areas assigned to the provider. It is preferable that it is configured to select.
【0083】
In one embodiment, the geographic location assigned to each of the above requests is the current geographic location of each requester.
【0084】
The current geographic location is preferably the communicator contact address of the communicator of each requester, and the communicator contact address preferably has an assigned position.
【0085】
The communicator contact address is more preferably a dial number.
【0086】
In one embodiment, the geographic location assigned to each of the above requests is an alternative geographic location assigned by each requester.
【0087】
The alternative geographic location is determined from the communicator contact address of the communicator, and the communicator contact address preferably has an assigned location.
【0088】
The communicator contact address is more preferably a dial number.
【0089】
The at least one provider selection unit is preferably configured to select a provider within a spatial geographic area that is predeterminable for the geographic location assigned to each request.
【0090】
The predeterminable spatial geographic area was assigned to each request, whether it was the geographic radius for the geographic location assigned to each request, the distance traveled to the geographic location assigned to each request, or the distance traveled to each request. More preferably it is one of the travel times relative to the geographic location.
【0091】
The at least one provider selection unit, at least in part, is based on at least one requester feature for each requester, for example, as a feature assigned to each requester or as a feature input when information is created by each requester. It is preferably configured to select a provider for the request based on geographically relevant socio-economic information.
【0092】
The at least one provider selection unit has, at least in part, a predeterminable profile based on at least one provider feature for the provider, eg, as an assigned feature for each provider, or contact details. It is preferably configured to select a provider for the request based on requesting the requester to provide.
【0093】
The at least one provider selection unit is preferably configured to select a provider for a request, at least in part, based on the current time.
【0094】
The at least one provider selection unit provides providers for a request, at least in part, based on at least one classification feature, eg, a selection mechanism for selecting a provider, as an assigned feature for each classification. It is preferably configured to be selected.
【0095】
The system is preferably configured to relay requests to the provider communicator of a predetermined number of selected providers, as addressed thereby.
【0096】
The system is configured to multicast requests to the provider communicator of each selected provider, and each of the requests is relayed to and thereby addressed to multiple providers. It is preferable that it is a thing.
【0097】
In yet another embodiment, the present invention provides a method of matching a request to a user's provider as a requester when processing the request. Each of the requesters has at least one communicator to create a request and address an answer to it, and each of the providers has at least one to address a request and its respective answer to it. Has one communicator. The method is based on a step of receiving a request from the requester and, for each request, a step of causing the request to be relayed to a selected provider so that it can be addressed. As a human decision maker, for each request, the step of receiving a response from the provider created by each provider, and the affirmative answer as an indication that the provider can accept the request, respectively. Providing information about the requester to any provider given a positive answer to each request, and providing information about the answer to each request from the selected provider to each requester, or both. With the steps to do.
【0098】
The method is preferably a real-time matching method.
【0099】
The requirement is preferably a free format requirement.
【0100】
The request preferably includes a voice request.
【0101】
The communicator preferably includes mobile communicators such as telephones, PDAs, personal computers and gaming devices.
【0102】
The communicator preferably includes a fixed communicator such as a telephone, fax machine, personal computer, set-top box and game console.
【0103】
The communicator preferably includes a composite fixed / mobile communicator such as a telephone.
【0104】
In one embodiment, the step of causing the request to be relayed to the selected provider so that it is addressed comprises relaying the request directly to said communicator of the selected provider.
【0105】
The request is preferably relayed without making the inquiry and setting the content.
【0106】
The step of receiving the request from the requester preferably includes the step of receiving the request from the requester with a plurality of receivers, and each of the requests has a classification contact address associated with a predeterminable classification.
【0107】
The classification contact address is more preferably a dial number.
【0108】
In one embodiment, the method further comprises the step of selecting each provider to address the request.
【0109】
The steps to select each provider to address a request are, at least in part, based on the geographic location assigned to each request and one or both of the geographic locations and geographic areas assigned to the providers. , It is preferable to include a step of selecting each provider to address the request.
【0110】
In one embodiment, the geographic location assigned to each of the above requests is the current geographic location of each requester.
【0111】
The current geographic location is preferably the communicator contact address of the communicator of each requester, and the communicator contact address preferably has an assigned position.
【0112】
The communicator contact address is more preferably a dial number.
【0113】
In one embodiment, the geographic location assigned to each of the above requests is an alternative geographic location assigned by each requester.
【0114】
The alternative geographic location is determined from the communicator contact address of the communicator, and the communicator contact address preferably has an assigned location.
【0115】
The communicator contact address is preferably a dial number.
【0116】
The geographic location of the mobile communicator is preferably determined from one of the cell identification methods, triangulation methods, radio positioning methods or satellite positioning methods such as GPS.
【0117】
The geographic location of the fixed communicator is preferably determined from the assigned location.
【0118】
The step of selecting each provider to address each request includes the step of selecting each provider to address the request within a predeterminable spatial geographic area for the geographic location assigned to each request. Is preferable.
【0119】
The predeterminable spatial geographic area was assigned to each request, whether it was the geographic radius for the geographic location assigned to each request, the distance traveled to the geographic location assigned to each request, or the distance traveled to each request. More preferably it is one of the travel times relative to the geographic location.
【0120】
The step of selecting each provider to address the request is, at least in part, based on at least one requester feature for each requester, for example the assigned feature for each requester or the feature at the time of information creation by each requester. It is preferable to include a step of selecting each provider to address the request based on geographically relevant socio-economic information as input.
【0121】
The step of selecting each provider to address the request is to have a predeterminable profile, at least in part, based on at least one provider feature for the provider, eg, as an assigned feature for each provider. Alternatively, it may include the step of selecting each provider to address the request based on requesting the requester to provide contact details.
【0122】
The step of selecting each provider to address the request preferably includes, at least in part, the step of selecting each provider to address the request based on the current time.
【0123】
The step of selecting each provider to address the request is at least in part based on at least one classification feature, eg, a selection mechanism for selecting providers, as an assigned feature for each classification. It is preferable to include a step of selecting each provider to address the request.
【0124】
The step of relaying the request to the selected provider so that it is addressed is the step of relaying the request to a predetermined number of selected providers so that it is addressed. Is preferably included.
【0125】
The step of causing the request to be relayed to the selected provider so that it can be addressed includes the step of multicasting the request to the selected provider, said request to multiple providers, thereby. It is preferred to be relayed to be addressed.
【0126】
The step of supplying information preferably includes, for each request, a step of supplying information about the provider who has been given a positive answer to the request to each requester.
【0127】
In yet another embodiment, the present invention provides a method of matching a request to a user's provider as a requester when processing the request. Each of the requesters has at least one communicator to create the request and address the response to it, and each of the providers has at least one communicator to address the request. The method is based on a step of receiving a request from the requester and, for each request, a step of causing the request to be relayed to a selected provider so that it can be addressed. It also includes, as a human decision maker, a step of receiving responses from providers created by each provider.
【0128】
In yet another alternative form, the present invention provides a method of matching a request to a user's provider as a requester when processing the request. This method is based on a step of receiving a signal with a request from the requester and, for each request, a step of transmitting a signal having the request as if received to a selected provider. For each request, for each request, a step of receiving a signal with a response from the selected provider, created by each provider, and an affirmative answer as an indication that the provider can accept the request. Send one or both signals for any provider given a positive answer with information about each requester and for each requester with information about an answer to each request from the selected provider. Prepare for the steps to be taken.
【0129】
The present invention, known as the Responsa (Trademark) matching system, provides an automated matching system. The system specifically allows voice requests, especially free format requests, to be matched with a provider who has received the request and has confirmed that it is acceptable.
【0130】
In a preferred embodiment, this matching is achieved based on the position associated with the requester, typically the position of the communicator of the requester, the provider's assigned position in the selected classification, and the selected classification. To. In other embodiments, the current time and characteristics of one or both of the requester and the provider are available for provider selection.
【0131】
According to the present invention, the received request is relayed to the selected provider and reproduced for the voice request. If none of the providers can meet the request, does the provider simply have to decline the request, typically by hitting a "deny" answer or a keystroke corresponding to the "deny" answer? Or you just have to turn off the communicator. When the request is relayed, all communication by the requester and provider becomes one-way communication. Thus, there is no direct conversation required between the requester and one provider. Both parties avoid time-consuming tasks that require a polite debate to be established when the provider is unable to meet the demand. Direct conversations are only possible between the requester and one provider who can meet the demand.
【0132】
The present invention allows for automated matching and also allows individuals to communicate in free format format. A preferred embodiment of the present invention gives the requester the freedom to shape the requirements as desired when utilizing the free format requirements. The language and form of the request is not constrained, for example, by requiring the requester to use a given keyword.
【0133】
In addition, the invention is defined by a special classification for providers who wish to receive a request and are in a position to process the request, such as those who are open and within a unique geographic area. Just relay the request.
【0134】
In the present invention, a person who receives a request and interprets the request intelligently is a human decision maker, unlike a computer. This avoids matching system-related problems that require requirements to be specified, for example by using a given keyword, for example using a drop-down menu.
【0135】
Furthermore, the present invention finds applications in both personal environments, such as those manipulated by an organization for use by members of an organization, and social environments, which allow use by members of society.
【0136】
In certain embodiments, the invention may be configured to bias the butting to the benefit of either the requester or the provider of choice. This is expected to be appropriate in some niche applications, especially in personal environments.
【0137】
Hereinafter, preferred embodiments of the present invention will be described only by way of reference with reference to the accompanying drawings.
【0138】
The matching system is at least one phone management (TM) system 1 for managing inbound phone calls to and from the matching system, first and second TM systems 1a in this embodiment. , 1b is provided. This matching system has a single TM system 1 in another embodiment and any number of TM systems 1 from tens to hundreds in different embodiments.
【0139】
The TM systems 1a, 1b are located in the same location in this embodiment, but are located apart in other embodiments. In one such embodiment, TM systems 1a, 1b are located distantly within one geographical area. As an example, within the United Kingdom, one TM System 1a is located in one center, eg London, and serves the southern half of the United Kingdom, while the other TM System 1b is located in another center, eg Glasgow. Serve the northern half of the UK. In other embodiments that include a large number of TM systems 1, the TM system 1 is located in a major center, eg, a city or town across a geographical area.
【0140】
The matching system further comprises a first communication network 3 that provides a communication link to and in between TM systems 1a, 1b.
【0141】
In this embodiment where the TM systems 1a, 1b are located in the same location, the communication network 3 includes a local area network (LAN) such as Ethernet.
【0142】
In another embodiment in which the TM systems 1a, 1b are spaced apart, the communication network 3 comprises a telephone network, preferably an integrated services digital network (ISDN).
【0143】
Each of the TM systems 1a and 1b includes an inbound telephone line 7, preferably an inbound telephone management (ITM) unit 5 for managing inbound telephone calls from a requester on an ISDN line. Since multiple subscriber numbering (MSN) is used in this embodiment, multiple requesters, each requiring the same classification, may be supported at the same time.
【0144】
The ITM unit 5 is connected to an inbound telephone line 7 to monitor inbound telephone calls, with an inbound interactive voice response (IIVR) module 11 supporting voice and key tones, and inbound as described in more detail below. With the Inbound Telephone Application Management (ITAM) Module 13 to generate a request document corresponding to a request in each of the phone calls, a voice request in this embodiment, and to send it to provider selection units 33a, 33b, 33c. , To store the classification features for each classification, the first classification feature (CC) database 15 connected to the ITAM module 13, and to store information about the requester, ITAM. It has a requester information (RI) database 17 connected to module 13.
【0145】
With this configuration, the CC database 15 and the RI database 17 are not accessible to the IIVR module 11, which prevents the RI database 17 from being accessed by a third party. In this embodiment, the ITM unit 5 has an intrusion detector between the IIVR module 11 and the ITAM module 13. This is to monitor the intrusion of a third party and keep the ITAM module 13 secure, typically by identifying anomalous packets.
【0146】
In this embodiment, communication between IIVR module 11 and ITAM module 13 is by VoiceXML communication protocol.
【0147】
In this embodiment, the request document generated by the ITAM module 13 is, in this embodiment, a called party number, a telephone number called by the requester, with a classification identifier that identifies the classification to which the request is matched. In this embodiment, the caller line identification (CLI) of the requester's telephone, that is, the telephone number for the system or the affirmative answering provider to contact in response to the request, the requester identifier that identifies the requester, and the relay to the provider. It includes at least a request file corresponding to the request to be made, and in this embodiment a voice file corresponding to the voice request played back to the provider. In an alternative embodiment, the requester identifier is a telephone number, which is obtained from either the requester's telephone CLI or, for example, information containing an authorization code given by the requester when making a request.
【0148】
In an alternative embodiment, the request document generated by the ITAM module 13 can omit the request file for the request, as described in more detail below. This is the case when the file is stored in an accessible file store 19 so that the request can then be relayed.
【0149】
In this embodiment, the request document generated by ITAM module 13 includes a location identifier that identifies the location of the search center if the provider identification units 33a, 33b, 33c cannot determine the location of the requester from the requester identifier. .. A typical example of a requester identifier not making it possible to determine the location of a requester is that the requester is not listed in the directory, or the requester is not given an address for the calling party number, or is called. The result is that the calling phone is a mobile phone, or the requester is asking the search center for an alternative location. In this embodiment, the location identifier is a telephone number other than the calling party telephone number, which is given by the requester to represent the location of the search center.
【0150】
In this embodiment, CC database 15 is a structured query language (SQL) database.
【0151】
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 located at the same location.
【0152】
In other embodiments, the IIVR module 11 and the ITAM module 13 are co-located, and one or both of the CC database 15 and the RI database 17 are co-located. In this embodiment, the communication network between the ITAM module 13 and the CC database 15 and the RI database 17 is a virtual private network (VPN).
【0153】
In different embodiments, one or both of the IIVR module 11 and the ITAM module 13 are located apart, and the CC database 15 and the RI database 17 are located in the same location.
【0154】
In a further different embodiment, the components of the ITM unit 5, i.e. IIVR module 11, ITAM module 13, CC database 15, and RI database 17 are located apart.
【0155】
Each of the TM systems 1a and 1b further comprises a file store 19 for storing classification greetings and prompts for the supported classifications. As mentioned above, in one embodiment, the file store 19 stores a request file for each request from the requester. The memory of this request file allows the request file to be retrieved. Thus, the request document does not need to contain the request file. Such a small request document size allows for significantly higher traffic (call volume) flow for the same system capacity.
【0156】
The operation of the ITM unit 5 of the TM systems 1a and 1b will be described below.
【0157】
Each ITM unit 5 receives an inbound telephone call from the requester communicator 20, in this embodiment, on each inbound telephone line 7. In this case, the special ITM unit 5 receives the telephone call indicated by the called party number, the number called by the requester.
【0158】
In this embodiment, in which the matching system is configured to act as a transaction classification matching system, one requester can choose from multiple classification entries corresponding to different types of goods and service providers. Each classification entry has an associated telephone number that the requester must dial to access the matching system for that classification. This is, in this embodiment, a classification identifier. This identifier determines the search criteria, matching criteria and termination criteria by which the matching operation is performed, as described in more detail below. In one embodiment, each classification entry can include a summary of one or both of the services and goods. This is so that the requester can determine that the correct classification has been selected for that particular requirement.
【0159】
For each inbound call, the IIVR module 11 transfers the called party number and the calling party number, that is, the calling party line identification (CLI) of the requester communicator 20, which is the calling party communicator, to the ITAM module 13. Send. In this embodiment, the requester communicator 20 is a landline, mobile, combined fixed / mobile, or PDA.
【0160】
The ITAM module 13 searches the CC database 15 for the called party number and searches for the classification greeting file identifier to ask the requester for a "classification" greeting to be played.
【0161】
If the called party number is not related to classification, for example if the called party number was previously used in relation to classification but is no longer used, ITAM module 13 directs IIVR module 11. And run the "Unassigned Classification" script. This script plays an "unassigned classification" greeting and closes the call connection.
【0162】
If the calling communicator 20 does not have a CLI because the CLI is forbidden, the ITAM module 13 directs the IIVR module 11 to execute a "number-free" script. This script plays a "number-free" greeting. This greeting directs the requester to allow the calling party's phone to CLI, or to give the register-related authorization code as an authenticated requester.
【0163】
In this embodiment, the system is configured to allow the requester to handle the request only when the inbound call has a CLI. By requiring the use of a CLI-enabled communicator 20, the system is prevented from being misused by the requester, who directs the answer to a third party.
【0164】
If the calling communicator 20 has a CLI, the ITAM module 13 searches the RI database 17 for the CLI of the calling communicator 20 to check the requester information, for example, the location information is for the CLI. Make sure it is available, and get a default requester preference for, for example, whether requester details for the requester are given to the provider or not used.
【0165】
If the CLI of the calling communicator 20 is that of a fixed communicator and the RI database 17 contains location information for the calling party phone CLI, the ITAM module 13 directs the IIRV module 11 to " Run the "Fixed Requester" script.
【0166】
If the calling communicator 20 CLI is that of a mobile communicator and the RI database 17 does not contain default location information for the calling communicator 20 CLI, the ITAM module 13 will perform the calling communicator. Determine the location of 20 from the network information and instruct IIRV module 11 to run the "moving requester" script. In this embodiment, the cell ID with respect to the calling communicator 20 is used to determine the position of the requester. This cell ID represents a cell that is a geographical area in which the calling communicator 20 is located. In this case, the ITAM module 13 searches for the cell ID in the RI database 17 and obtains the position of the calling communicator 20. In other embodiments, the requester's calling communicator 20 is determined by triangulation, radio positioning, or satellite positioning, such as GPS.
【0167】
If there is a CLI, but the requester is not listed in the directory, for example, and the location cannot be determined from that CLI, that is, the requester does not want to disclose the location information corresponding to the requester communicator 20 number to the service provider. And if the location information is not otherwise provided by the requester, the ITAM module 13 searches the CC database 15 for a search vector for the classification corresponding to the called party number and handles the location-independent requester. Determine if there is. If there is a vector for handling position-independent requesters, ITAM module 13 utilizes that vector. If there is no vector to handle the position-independent requester, ITAM module 13 directs IIRV module 11 to execute the "required position" script. This script plays a "required location" greeting and advises the requester of location information, typically known CLI-enabled phone numbers. Therefore, the location information is stored in the CC database 15 and operates as a search center.
【0168】
If there is a CLI but the calling party number is that of the switchboard (manned or automatic), the ITAM module 13 directs the IIRV module 11 to execute the appropriate "switchboard requester" script.
【0169】
Under the Fixed Requester and Mobile Requester scripts, IIRV Module 11 plays a "Classification Title" greeting that corresponds to the searched Classification Greeting Identifier, and then a "Request Prompt" that facilitates the request from the Requester. Play the greeting. For example, if the called party number corresponds to the classification "toy store", in this embodiment the classification greeting is "Responsa for the toy store".<sup>TM</sup>) Welcome to the classification, and the "Request Prompt" greeting will be "Leave your request after the tone and turn it off when you're done."
【0170】
Under the "Switchboard Requester" script, IIRV Module 11 assigns an extension number by "classification title" greeting corresponding to the searched classification greeting identifier and typically by keying or voice answering that number. The "extension identification" greeting that prompts the requester and the "request prompt" greeting that prompts the requester are played in order. In this embodiment, the "request prompt" greeting is played only following a predetermined keystroke on the calling communicator 20. This keystroke confirms the supply of the extension number of the calling communicator 20. For example, if the called party number corresponds to the classification "toy store", in this embodiment the "classification title" greeting is "Responsa for the toy store".<sup>TM</sup>) Welcome to the classification, and the "Extension Identification" greeting will be "Leave your extension number after the tone, then press the X key", and followed by the required keystrokes, "Request Prompt" The greeting will be "Leave your request after the tone and cut it when you're done".
【0171】
IIVR if the requester wants to set up an alternative preference, for example to suppress contact details from the provider, the default is to give the details to the provider, and to give an alternative search center location or alternative search parameters. Module 11 allows the input of keystrokes to set these preferences.
【0172】
In this embodiment, the IIVR module 11 is configured to allow recording of requests. This is done, for example, by keystrokes of a given keystroke if the requester makes a mistake when recording the request.
【0173】
Also in this embodiment, the IIVR module 11 is configured to allow the request to be reviewed, here replayed, before initiating the matching operation.
【0174】
In this embodiment, the ringing connection is closed after a predetermined period of time has passed following the "request prompt" greeting, or when the requester hangs up when this event is identifiable by IIVR module 11.
【0175】
In this embodiment, the ITAM module 13 stores each request in the file store 19 with the assigned file name.
【0176】
TM systems 1a and 1b manage outbound telephone management (OTM) to manage outbound calls to the provider on the provider communicator 24 and the requester on the requester communicator 20 on the outbound line 23, preferably the ISDN line, respectively. ) Further equipped with unit 21.
【0177】
The OTM unit 21 follows the outbound interactive voice response (OIVR) module 25 connected to the outbound line 23 to fulfill the outbound call to the provider and requester, and the call document received from the provider selection units 33a, 33b, 33c. It includes an outbound telephone application management (OTAM) module 27 for scheduling and directing calls to the OIVR module 25. In this embodiment, the calling document is scheduled according to the priority flag. In this case, for example, the status report for the requester has a lower priority than the request for the provider.
【0178】
In operation, when an outbound call to the provider is made, the OIVR module 25 dials the number of the provider communicator 24 identified in the call document.
【0179】
When the call to the provider communicator 24 made by the OIVR module 25 is answered, the OIVR module 25 executes the "request playback" script. It first plays a "VRS welcome" greeting, for example "VRS for a dressing shop". This is followed by a first short tone. After that, the request to the provider is reproduced. This is followed by a second short tone. In this embodiment, the request is relayed, here reproduced, without a query such as by speech recognition (since such is not needed). The classification is indicated by the called party number. In alternative embodiments where a more precise or sophisticated matching system is required, the requirements are queried.
【0180】
When you hear your request, your provider has the following answer options: Each option has an associated keystroke.
【0181】
"Acceptance" is confirmation that the request is met. For example, if the request is "Can you hairdress?", That is, if the requester is merely trying to get the details of the local hairdresser, and the request is appropriate, the provider will ask. "Accept" answer.
【0182】
"Maybe" indicates that the request is probably fulfilled, but the provider must confirm. If your request is complex, for example, "Can you schedule a hairdressing next Wednesday at 1530?", The provider may recall that it wasn't fully booked next Wednesday afternoon, but it's accurate. You need to check if you have time. In such cases, the provider will "probably" answer.
【0183】
"Rejection" is confirmation that the request is not met. In this embodiment, hanging up is equivalent to the answer option "Reject".
【0184】
"Inappropriate" indicates that the request is either inappropriate or incomprehensible to the classification.
【0185】
"Illegal" indicates that the request is considered to be fraudulent.
【0186】
In this embodiment, the provider's response is logged, allowing, for example, a classification manager to monitor the behavior of the provider and some requesters. This behavior makes it possible to provide guidance specifically targeted at providers and requesters. It even allows you to ban providers or requesters if the behavior is unacceptable.
【0187】
For example, "inappropriate" answers are logged for both the provider who responds so and the requester who made the request. This is because repeated "inappropriate" answers are made by either the requester or the provider who are confused about the purpose of the classification.
【0188】
Also, "illegal" answers are logged to both the provider who responds so and the requester who made the request. In this embodiment, in addition to terminating the matching operation, each requester prohibits the use of the entire classification or matching system by repeated "injustice" answers established by confirmed "injustice" answers. Will result in being done. In this embodiment, the provider's repeated, typically significantly above average, significantly above the average for one classification, will be investigated.
【0189】
The OIVR module 25 executes an acknowledgment script when the provider gives an acknowledgment, ie in this embodiment one of the answer options "accept" or "maybe". This script plays a "answer answered" greeting. This is followed by a short tone. The script also updates the call document to include the affirmative answer identifier and sends the updated call document to the originating provider selection units 33a, 33b, 33c.
【0190】
If the requester's contact details are refrained, the "acknowledgement" script also plays the "contact details refrained" greeting.
【0191】
If the contact details are not reserved, the "acknowledgement" script also gives the contact details to the requester. This is followed by a short tone. In one embodiment, the provider can record the details of the requester and then call the requester. In another embodiment, the provider can contact the requester directly by a predetermined keystroke. If the requester follows a process on the line, the requester can connect directly to the provider if the provider is still on the line.
【0192】
If the calling communicator 20 is from an extension off the manned switchboard, the acknowledgment script also gives the switchboard phone number and requester extension to allow the provider to navigate the switchboard. To do.
【0193】
If the calling communicator 20 is from an extension off the unmanned switchboard, the "acknowledgement" script also plays the "wait on line until you hear the tone" greeting. During the period preceding this tone, the provider details are given to the requester, who is given the opportunity to connect directly with the provider who is still on the line. If an intermediate connection is required, the requester connects to the provider and establishes a conversation. If no intermediate connection is established, the requester may contact the provider later.
【0194】
In this embodiment, the system is configured so that the "acknowledgement" script is re-executed with a given keystroke.
【0195】
In this embodiment, the affirmative answer is either the answer option "accept" or "maybe". In other embodiments, and especially for certain classifications, the matching system can be configured to look only for "accepted" answers as positive answers. In such an embodiment, the "request playback" script also plays a "reject or accept only" greeting. In this case, all "maybe" and "reject" answers are considered negative answers.
【0196】
If there is no response to the call to the provider made by the OIVR module 25, the OIVR module 25 will "get the number" if it cannot get the number held for the provider communicator 24: "Zu", "busy" when the number held for the provider is busy, and "calling" when the phone for the number held for the provider is ringing but there is no answer 1 Is assigned to the call document as a call state identifier, the call document is updated to include the associated call state identifier, and the updated call document is sent to the originating provider selection units 33a, 33b, 33c.
【0197】
TM systems 1a and 1b each provide a communication link to the first main communication network 3, as well as ITM unit 5 (both IIVR module 11 and ITAM module 13 are separate in this embodiment), file store 19 and OTM. It further comprises a telephone management (TM) communication network 29 that provides a communication link between the unit 21 (in this embodiment both the OIVR module 25 and the OTAM module 27 are separate). In one embodiment, the communication with the ITM unit 5, the file store 19 and the OTM unit 21, and the communication between the IIVR module 11 and the ITAM module 13 are encoded. Typically, either encrypted or authenticated communication, such as signed communication.
【0198】
In this embodiment where the ITM unit 5, the file store 19 and the OTM unit 21 are co-located, the TM communication network 29 is a local area network (LAN), such as Ethernet.
【0199】
In another embodiment in which the ITM unit 5, the file store 19 and the OTM unit 21 are located apart, the TM communication network 29 is an established telephone network, preferably an ISDN network.
【0200】
The matching system further includes at least one provider selection unit 33 for selecting the provider to be contacted by OTM unit 21 of TM systems 1a, 1b during request matching and scheduling of contact with the provider, 3 in this embodiment. It has two provider selection units 33a, 33b, 33c. It should be acknowledged here that this matching system can include any number of provider selection units 33. This embodiment simply includes three provider selection units 33a, 33b, 33c for illustration purposes.
【0201】
In this embodiment, the provider selection units 33a, 33b, 33c are located in the same position, but in other embodiments, some or all of the provider selection units 33a, 33b, 33c are located apart.
【0202】
In this embodiment, the provider selection units 33a, 33b, 33c are each configured to support all addressable classifications, whereas in other embodiments, many provider selections, especially tens or hundreds, are selected. Given the units 33a, 33b, 33c, the provider selection units 33a, 33b, 33c may be configured to support only one or a subset of the addressable classifications.
【0203】
The matching system further comprises a second main communication network 34 that provides a communication link to and between the provider selection units 33a, 33b, 33c.
【0204】
In this embodiment where the provider selection units 33a, 33b, 33c are co-located, the second main communication network 34 is a local area network (LAN), such as Ethernet.
【0205】
In another embodiment in which the provider selection units 33a, 33b, 33c are located apart, the second main communication network 34 is a telephone network, preferably an integrated services digital network (ISDN).
【0206】
The matching system further comprises a router 35 for routing request and call documents between TM systems 1a, 1b and provider selection units 33a, 33b, 33c, respectively.
【0207】
The provider selection units 33a, 33b, 33c, respectively, provide information such as provider characteristics for each provider in each of the classifications supported by the respective provider selection units 33a, 33b, 33c, provider list building parameters for each classification, and each. A classification information (CI) database 37 containing matching criteria for classifications and termination criteria for each classification, a second request information (RI) database 39 containing information such as requester characteristics for each requester, and a provider selection unit. From the provider housed in the CI database 37 to the provider for the document scheduler 41 for scheduling documents to and from 33a, 33b, 33c, and the classification to which the request is directed for each request. It has a provider list building unit 43 that builds a sorted provider list of.
【0208】
The CI database 37 contains information about each of the providers in each classification, and each provider is referenced by a provider identifier. The information retained for each provider includes the provider's name, provider's address, provider's contact number, provider characteristics, and system history information, such as the number of requests delivered, the number of affirmative answers (in this embodiment, "" As one of the "accepted" or "maybe" answers, and as an "accepted" answer in other embodiments), the number of negative answers (as a "rejected" answer in this embodiment, and as a "rejected" or "rejected" in other embodiments. Includes (perhaps as one of the "probably" answers), the number of "inappropriate" answers, and the number of "incorrect" answers. The CI database 37 in this embodiment is a spatial aggregate database, that is, a database that enables spatial operations.
【0209】
The provider list building unit 43 has a provider selection module 44. This module is one or more candidates according to a given listing mechanism for the classification to which the request is addressed, and based on the search center if this tabulation mechanism utilizes position-based vectors. It is configured to generate a list of providers. This search center is usually the location of the requester, but it can also be an alternative location identified by the requester. Alternatively, if the search is recentralized, it is the location of the first provider to affirm the request. As described in more detail below, the generation of multiple candidate provider lists defines a set of providers, such as a set of local and national providers.
【0210】
In this embodiment, the provider selection module 44 uses the following tabulation mechanism to generate one or more candidate provider lists.
【0211】
[Table drawing mechanism A-closest contact]
This tabulation mechanism produces a list of candidate providers for the closest candidate providers to the search center with respect to spatially related parameters, typically direct (between two points) distances, distances traveled or times traveled. In one embodiment, the list of candidate providers can be truncated by number, i.e. the search center will contain a predetermined number of closest candidate providers. In another embodiment, the candidate provider list can be truncated by an upper bound on spatially relevant parameters, i.e. to include all providers within a spatial area of a given size.
【0212】
[Table drawing mechanism B-closest group]
This tabulation mechanism generates a candidate provider list of candidate providers that represents the closest set of providers that satisfy the group characteristics for the classification to which the request is addressed as the closest group. In this embodiment, the population feature is that the closest population is a recent provider with at least a predetermined number of providers within a spatial area of a given size, typically a direct (between two points) distance, a distance traveled or a travel time. It is defined as a set of contacts.
【0213】
[Table plotting mechanism C-maximum concentration population]
This tabulation mechanism produces a candidate provider list of candidate providers that represents a set of providers that satisfy the concentration characteristics for the classification to which the request is addressed, as a group, but not necessarily a closest group. In this embodiment, the concentration feature provides the population with the highest number of providers within a first spatial area of a first predetermined size, typically a direct (between two points) distance, a distance traveled or a travel time. It is defined as a set of. The first space area has a second predetermined size of a larger size and is within the second space area centered on the search center. This tabulation mechanism is effective in locating large towns and cities within geographical areas and prevents providers from moving out of the more widely distributed main density. For this reason, it is expected that this tabulation mechanism will be commonly used as part of a series of searches.
【0214】
[Table drawing mechanism D-segment]
This tabulation mechanism generates a candidate provider list of candidate providers from within a circular segment having a predetermined segment angle and radius. This radius is typically a first predetermined size, which is the direct (between two points) distance to the search center, travel distance or travel time, or a second where a segment with a smaller radius contains a predetermined number of candidate providers. Either a small distance. The list of candidate providers in this embodiment is the first in the list with respect to spatially related parameters, typically the direct (between two points) distance from the search center, the distance traveled or the time traveled. It is ordered so that it is done. When requoted as a result of an unsuccessful matching operation, the segment that follows in either the clockwise or counterclockwise direction is utilized. This tabulation mechanism has been developed for use when varying but high concentration providers are present in areas of interest. In this case, the requester sharply identifies the provider within the general direction of travel extending from the search center. In this embodiment, the circle segments are randomly selected.
【0215】
[Table drawing mechanism E-all]
This tabulation mechanism covers all of the provider's spatially relevant parameters, typically direct (between two points) distances, distances traveled or times traveled, for a spatial area of a given size centered around the search center. Generate a candidate provider list.
【0216】
[Table table F-threshold]
This tabulation mechanism produces a list of candidate providers that satisfy the threshold characteristics for the classification to which the request is addressed. In this embodiment, the threshold feature defines a provider that satisfies a given threshold criterion, eg, greater than or less than one threshold. Examples of threshold criteria include turnover, number of employees, quality rating, and delivery speed.
【0217】
The provider list building unit 43 further generates a provider contact list by sorting the candidate providers in the candidate provider list generated by the provider selection module 44 according to a predetermined alignment mechanism for the classification to which the request is addressed. Has a provider alignment module 45 for In one embodiment, the generated provider contact list is truncated.
【0218】
The provider alignment module 45 in this embodiment uses the following alignment mechanism.
【0219】
[Alignment mechanism A-None]
This alignment mechanism does not align the candidate provider list. The provider contact list has the order of the candidate provider list generated by the provider selection module 44.
【0220】
[Alignment mechanism B-Random]
This alignment mechanism generates a provider contact list by randomizing the candidate provider list generated by the provider selection module 44.
【0221】
[Alignment mechanism C-Order]
This alignment mechanism provides providers by sorting the list of candidate providers generated by the provider selection module 44 according to the last contact with the provider to ensure that the providers are contacted in order according to their specific ratios. Generate a contact list. In this case, the last contacted provider is at the bottom of the list. In this embodiment, logs are maintained for previous contact with the provider.
【0222】
[Alignment mechanism D-closest contact]
This alignment mechanism aligns the candidate provider list generated by the provider selection module 44 with respect to spatially related parameters, typically direct (between two) distances to the search center, travel distance or travel time candidates. Generate a provider contact list by doing so. In this case, for example, the most recent one is listed first.
【0223】
[Alignment mechanism E-Ranking]
This alignment mechanism sorts the candidate provider list generated by the provider selection module 44 according to special ranking parameters, in the order ranked by, for example, turnover, number of employees, quality rating, and speed of delivery. By doing so, a provider contact list is generated. This alignment mechanism is particularly suitable for searching for providers when location is not important. These providers tend to be national providers, and the locations of these providers are only relevant as long as the providers include the location of the requester. A typical classification is insurance business, in which case contact with the provider will be by telephone. It should be acknowledged here that this alignment mechanism can generate a list that never contains certain providers, and for that reason it is usually used as part of a series of searches.
【0224】
In this embodiment, if the list building criteria for the selected classification requires a contact provider list of two or more, the list building unit 43 merges the plurality of provider contact lists into a single provider contact list. Is configured to generate. Generating a single provider contact list from multiple provider contact lists finds application when a set of providers, such as local and national providers, is selected. A typical classification for which such a provider contact list is appropriate is that of a computer supplier. In this case, the requester wants a local provider, or perhaps a national provider.
【0225】
The provider contact list constructed by the list building unit 43 contains multiple status fields for each provider entry, with the restriction that one provider is contained in only one field. In this way, the state of the provider can be maintained. Multiple states, including "available," "overtime," "busy," and "calling" states, are grouped together as meaning that the request has not yet been delivered. Final response states include "accepted", "rejected", "maybe", "inappropriate" and "illegal" states.
【0226】
When building a provider contact list, a database query is made to establish which providers are available. This list is examined and providers are sorted into "Available" and "Overtime" states. When each "overtime" provider becomes available, the event is queued and moves the provider from the "overtime" field to the "available" field. Similarly, when each "available" provider becomes unavailable, the event is queued, moving the provider from "available" to "overtime" state.
【0227】
In one embodiment, the provider selection units 33a, 33b, 33c can be configured to recentralize the search center for the location of the provider who gave the first affirmative answer. If recentralization is possible and the provider is identified as a positive answer, the provider list building unit 43 is re-cited to use the identified provider's location as a search center. Generate a provider contact list. Such recentralization is used to identify providers as close as possible to each other. This attempts to avoid distinguishing between two widely distant providers, eg, two providers that are opposite to the search center and are therefore widely separated. Recentralization is expected to find application in identifying a large number of relatively close-positioned providers visited by requesters. For example, when it is desired to be able to compare the goods and services offered by the provider.
【0228】
When scheduling a call document for OTM unit 21 in TM systems 1a, 1b, the document scheduler 41 asks how many providers are currently callable and whether the call is "accept only". It is configured to perform calculations. That number is used to determine that the "in progress" list of providers contacted can accommodate another provider. If another provider is accommodating, the first provider from the "Available" list will be used. If the "Available" list is empty, Document Scheduler 41 waits for the "busy", "calling", or "overtime" providers to become available. Another intermediary method was used to move the provider from one list to the other, which caused the document scheduler 41 to place the "in progress" provider in the final response state, eg, "accepted" or "rejected". , "Maybe", etc. This method is the same as the method used to move a provider between "available" and "overtime" and vice versa. The use of the same method allows multiple checks to be made. For example, a "busy" provider may be requeued when it is "overtime".
【0229】
The provider selection units 33a, 33b, 33c are configured to terminate the search operation if the match criteria are met or if the match criteria do not match one of the possible termination criteria shown below. In this embodiment, for each classification, any of the termination criteria is enabled and disabled. If any of the termination criteria is possible, the provider selection units 33a, 33b, 33c terminate the search operation when the termination criteria are met. Then, the termination report is delivered to each provider.
【0230】
In this embodiment, the termination criteria are as follows.
【0231】
[End Event A-Number of Rejections]
For this termination event, termination occurs when a certain percentage of providers on the provider contact list for each requester are contacted. Provider selection units 33a, 33b, 33c should be in as many of the selected providers as possible when retrying the provider if the phone number for the selected provider is busy or unanswered. It is configured to contact you. As will be appreciated, the telephone number for a provider is permanently busy or calling, and as such, the system may not always be able to contact all selected providers.
【0232】
[End event B-Elapsed of predetermined period]
For this end event, the end occurs when a predetermined time limit has passed. In a preferred embodiment, a predetermined percentage of providers on the provider contact list for a request were not contacted when a predetermined period of time had passed since the requester created the request, or within a predetermined period of time after the requester created the request. The end occurs at the beginning of the time.
【0233】
[End Event C-Illegal Request]
For this termination event, termination occurs when a given number, in this embodiment, two providers report that the request is invalid. A "bad" answer is a provider's answer option.
【0234】
End Event D-Inappropriate Request
Termination occurs when a given number of providers in this embodiment report inappropriate requests for this termination event. An "inappropriate" answer is a provider's answer option.
【0235】
[End Event E-Empty List]
For this termination event, termination occurs when the contact provider list is empty.
【0236】
In a preferred embodiment, the number of "incomprehensible" or "inappropriate" answers is set to a number greater than 1, for example 2 or 3. For this reason, a single "incomprehensible" or "inappropriate" answer, such as given by a bad provider or as a result of a simple error on the provider side, is not enough to end the matching operation.
【0237】
If the system does not meet the matching criteria in a reasonable amount of time, the requester will be contacted and given a progress list. The system continues until it meets either the matching criteria or the termination criteria. If the termination criteria are met for the request, the requester will be contacted and will be informed of the termination of the search and the results achieved. In general, if the requester does not hear anything, the requester can be confident that the system has successfully matched the requirements according to the matching criteria for the classification. Progress or termination reports are returned to the switchboard requester, but the report always begins with the requester's recorded name and extension so that the switchboard operator can pass the message to the requester. it can.
【0238】
In this embodiment, the system can also delay the start of the matching operation. Often happens when a person tries to make a request, but he is aware that most or all of the potential offers are currently closed. Despite these events, the system is still usable. The requester can create a request at any time of the day, for example at 0200, knowing that the request is unlikely to be matched. The selected provider that is active at that time will be contacted. This is to allow those providers the opportunity to respond to their request. The duration of activity is known for all providers. For many providers, the number of providers available is higher during normal daytime business hours. In this case, the requester is given a termination report as usual, but the system is configured to re-relay the request at some other point in time when more providers are active in the given classification. Has been done. In this embodiment, the system is configured to allow this feature to be overridden by the application of a given keystroke. By default, the action of hanging up is interpreted as requiring the request to be relayed at a time when it is more likely to get a match.
【0239】
The system in this embodiment is also configured for the requester to identify an alternative location for the search center that is not related to the CLI of the calling party phone. In this embodiment, the IIRV module 11 allows this feature to be enabled with a given keystroke. Then, when enabled, IIRV module 11 executes the "alternative position" script. This plays the "alternative location" greeting, enters the phone number of the alternative search center, and prompts the requester to perform yet another predetermined keystroke. The system then uses the phone number at the alternative location to determine the search center. The system only uses the alternate location phone number to build a provider contact list, not as a calling party number. This calling party number, usually the CLI, is used as the phone number to which the status or termination report is delivered.
【0240】
This feature defines an environment in which a requester wants to identify a provider within another geographic area. For example, if a requester is traveling to visit a friend on the weekend and wants to locate a French restaurant in the area of the visit, the requester will be in the classification greeting. Make an "alternative position" keystroke, then enter an alternative phone number, typically the phone number of a friend you are visiting, and finally continue with the "done" keystroke. Then leave a request, for example, "Nice French restaurant, table for 4 people, Saturday night 1930, call me tonight". If the contact mode is set to give the requester details, the provider giving the affirmative answer is given the requester's calling party number instead of the alternate location phone number.
【0241】
The system in this embodiment is also configured to allow the requester to stay on the line and follow the matching motion. This is typically the case when the requester believes that the match is about to be achieved quickly. In this embodiment, this feature is enabled by a predetermined keystroke at the completion of recording the request and is disabled by repeating the predetermined keystroke. This matching system reports each event in real time, for example, "cut only rejected", "his hair rejected", "cool cut rejected". In this mode, each provider who answers affirmatively, either "accepted" or "maybe" in this embodiment, is assigned a special keystroke, and by making the associated keystroke , a call to the provider is made. Established.
【0242】
In this embodiment, for each requester, the configuration option includes by default a contact mode setting that allows the requester to configure the system. In this case, either withhold the requester's contact details from the provider (in this case, the report to the requester will give the details of the identified provider who gave a positive answer to allow the requester to contact the provider. Give the identified provider contact details of the requester so that the accepting provider can contact the requester directly upon acceptance of the request.
【0243】
In this embodiment, the system is configured so that the requester can override the default contact mode setting, thereby making a predetermined keystroke during the classification greeting. In this embodiment, the default answer mode setting is to give requester details, unless otherwise configured. If the default contact mode setting is set to give details, applying a given key acts to switch the contact mode setting from a setting that gives requester details to a setting that withholds requester details. As a result, the contact mode greeting "Requester details are withheld" is played. This is followed by a normal recording request tone. If the default contact mode setting is set to withhold details, applying a given key acts to switch the contact mode setting from a setting withholding requester details to a setting with requester details. As a result, the contact mode greeting "Requester details are supplied" is played. This is followed by a normal recording request tone.
【0244】
If the contact mode setting is set to withhold requester details, the system identifying the provider for the request calls the requester with the calling party number, and the provider details, in this embodiment, for each provider. Give a termination report that includes the contact name, either the provider name or the provider contact, and the contact number. In this embodiment, each of the providers mentioned in the termination report is assigned an associated key on the keypad, which allows the requester to quickly dial a selected one in the provider. .. If the requester has not received a call back (return call) from the system, but an answering machine is attached to the calling party number of the requester, the call is received by the answering machine. In this case, the termination report is recorded and the requester will be able to hear the call back later. If the calling party number is being called, but the requester's calling party number does not have an answering phone attached, the system will call back at set intervals until the call is completed. ..
【0245】
At the time of registration, the configuration details include the provider's business availability, ie business hours for each of the 7 days a week. Within these business hours, the system is configured by default assuming that the provider wants to receive the request. In this embodiment, the system is configured to allow the provider to exclude itself from the classification and thus not receive any further requests. It should be noted here that if a provider removes itself from the classification, it will be by list building unit 43 of provider selection units 33a, 33b, 33c until it is willing to reintroduce itself to that classification. It doesn't appear in any of the constructed lists. This feature allows businesses to suspend services for extended periods of time, such as during holidays. Outside business hours, the system does not contact providers who are not expected to receive the request. In this embodiment, the provider can temporarily change the allotted business hours by setting either the "open" or "closed" state, but setting the business in that way is not possible. If it is a temporary feature and the assigned business is not set before the next business time starts, the default time will be applied to the business time.
【0246】
In this embodiment, the system also allows the provider to block requests from requesters who are unable to receive service. A typical example is that the position of the requester is not the position supplied by the requester. Another typical example is when a provider only provides services for a special group of people, such as young people rather than older people, and does not handle requests from older people. Is. This does not bias the search, but simply avoids inappropriate contact.
【0247】
In this embodiment, the system allows the provider to block requests from the requester when the requester's contact details are withheld. In such an environment, the provider can care that the competitor secretly uses this system to gather information.
【0248】
In this embodiment, these references are set by the classification manager using the classification management unit 49.
【0249】
The matching system also includes a classification management unit 49. This unit maintains the classification database, CC database 15 and CL database 37, and the requester database, i.e. first and second RI databases 17, 39. In particular, the classification management unit 49 updates the provider entry, includes the new provider entry, changes the list building parameters for all classifications, and includes the new classification. In this embodiment, the classification management unit 49 has a web interface and enables remote control. In a preferred embodiment, the classification management unit 49 is operated by a plurality of classification managers. Each of the classification managers is assigned to one or more classifications and manages them.
【0250】
Finally, although described in its preferred embodiment, it is understood that the invention can be modified in many different ways without departing from the scope of the invention as defined by the appended claims. Will be.
【0251】
For example, in the embodiments described, the system is configured to use a voice response created using a telephone, but other communicators 20,24, such as PDAs, personal computers, set boxes, gaming devices, etc. And the use of game consoles, i.e. any device with communication capabilities, is expected. Also for receiving and delivering requests such as text coding requests (such as SMS and email), image requests (typically MMS and EMS including figures, still images or videos), and fax requests. Use the format of. In fact, the request can be created in one format, for example as a voice request, and delivered in another format. The requirement can also be, for example, a voice and text coding requirement component or a multiformat requirement with text coding and image requirement components.
【0252】
In general, providers are the people who respond to each request, but there are exceptions. One such provider is an observational provider that can only receive requests and cannot respond to them. Another such provider is a split provider. In this case, one request is received by one person, usually the decision maker who responds to the request, and is transferred to another person who handles the request, for example when dealing with a customer contract. .. Another such provider is an aligned provider that helps receive a request and redirect the request to another provider.
【0253】
As an example of an as-saaffat provider, the provider can have a hierarchical structure. Thus, a "car sale" can have children "new car" and "used car". These can themselves have children of the car type, such as Ford, Vauxhall, VW. The system can support this hierarchy, but with the philosophy that humans are the best people to handle demands, the system supports subordinate connections of classification through human as-saaffats (sorters). Just do it. The matching process is as follows. The requester is the new Ford Focus 1.8, which is a new car. Determined to be looking for Ghia. The requester dials the phone number for the classification "Car Sales" and leaves the request. This request is passed to the provider selected within that classification. However, one provider may be a distributor that sells many types of cars. For this provider, the other departments have been organized up to that point with the children mentioned above. In this case, the person who hears the request acts as an as-saaffat to determine to which department the request should be presented. The system is configured to recognize that this provider is an as-Saaffat and therefore expects to receive a keycode associated with one of the departments set up so far. Upon receiving this keycode, the system presents the request to the newly identified provider, which itself is set up as an as-saaffat provider. After repeating this procedure one or more times, the request is made to a provider that does not require further alignment.
【0254】
Furthermore, if the system is used as a private matching system, the setup for the private matching system is similar to the above. However, this matching system presents a request to a provider that has an internal private matching system. In this situation, all keycodes used to get a response are logged. This is because these codes allow the hierarchical structure to be navigated to report and provide contact details.
[Simple explanation of drawings]
【0255】
FIG. 1 graphically illustrates a matching system according to a preferred embodiment of the present invention for matching a user's request to a provider as a requester during request processing.
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| JP2018073186A | Cited by | Japan | Search report |
38 members in 12 offices
Priority claims24
| Document | Office | Kind | Date |
|---|---|---|---|
| 0126809 | United Kingdom | A | |
| 0126809 | United Kingdom | A | |
| 01268093 | United Kingdom | – | |
| 0129265 | United Kingdom | A | |
| 0129265 | United Kingdom | A | |
| 01292655 | United Kingdom | – | |
| 0202864 | United Kingdom | A | |
| 0202864 | United Kingdom | A | |
| 02028645 | United Kingdom | – | |
| 0221614 | United Kingdom | A | |
| 0221614 | United Kingdom | A | |
| 02216141 | United Kingdom | – | |
| 0204987 | United Kingdom | W | |
| 0204987 | United Kingdom | W | |
| 2001200126809 | – | – | – |
| 2001200129265 | – | – | – |
| 2002200202864 | – | – | – |
| 2002200221614 | – | – | – |
| 200204987 | – | – | – |
| GB20010026809 | – | – | – |
| GB20010029265 | – | – | – |
| GB20020002864 | – | – | – |
| GB20020021614 | – | – | – |
| WO2002GB04987 | – | – | – |
Members38
| Document | Office | Kind | |
|---|---|---|---|
| GB0012195D0 | United Kingdom | D0 | |
| WO0191485A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU6023301A | Australia | A | |
| GB0126809D0 | United Kingdom | D0 | |
| GB0129265D0 | United Kingdom | D0 | |
| GB0202864D0 | United Kingdom | D0 | |
| GB0221614D0 | United Kingdom | D0 | |
| EP1282988A1 | European Patent Office (EPO) | A1 | |
| GB0301256D0 | United Kingdom | D0 | |
| GB0301265D0 | United Kingdom | D0 | |
| GB0301268D0 | United Kingdom | D0 | |
| GB0301271D0 | United Kingdom | D0 | |
| WO03040971A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO03040972A1 | World Intellectual Property Organization (WIPO) | A1 | |
| TW200300534A | Taiwan Province of China | A | |
| CN1436431A | China | A | |
| US2003153330A1 | United States of America | A1 | |
| WO2004042608A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2004042609A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2003285492A1 | Australia | A1 | |
| AU2003285492A8 | Australia | A8 | |
| AU2003301783A1 | Australia | A1 | |
| AU2003301783A8 | Australia | A8 | |
| EP1449137A1 | European Patent Office (EPO) | A1 | |
| BR0213993A | Brazil | A | |
| EP1451737A1 | European Patent Office (EPO) | A1 | |
| WO2004042608A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2004042609A3 | World Intellectual Property Organization (WIPO) | A3 | |
| AR037267A1 | Argentina | A1 | |
| US2004249818A1 | United States of America | A1 | |
| US2004254929A1 | United States of America | A1 | |
| JP2005508558AThis record | Japan | A | |
| MXPA04004425A | Mexico | A | |
| CN1610913A | China | A | |
| CN1656489A | China | A | |
| ZA200403421B | South Africa | B | |
| US7209757B2 | United States of America | B2 | |
| CN100474944C | China | C |
9 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 2005508558
- Publication, DOCDB
- 2005508558
- Publication, EPODOC
- JP2005508558
- Application
- 2003542524
- Application, DOCDB
- 2003542524
- Application, EPODOC
- JP20030542524
Titles2
- Japanese
- 要求マッチングシステムおよび方法
- English
- Request matching system and method
Classification
- CPC, 4
- G06Q10/047
- G06Q30/02
- G06Q30/08
- G08G1/202
- IPC, 3
- G06Q10 00
- G06Q30 00
- G08G1 123
Designated states4
- Regional, 4
- Zimbabwe
- Turkmenistan
- Türkiye
- Togo