(57)【要約】  推定される個々の顧客のとのドライバー稼動性および適合性に基づいて運輸の事前スケジューリングおよび送達サービスを促進させるための、カスタマイズされたプラットフォームの提供方法。サービス提供者および顧客のマッチングが、お気に入り、選好またはレギュラーならびに選好、制限およびインジケータの派遣マトリックスに基づいて行われ得る。顧客およびサービス提供者は、相互のフィードバックに基づいて、お気に入りリスト、選好リストおよびブラックリストを生成し得、顧客が自身のお気に入りのサービス提供者からのサービスを受けることまたはその逆を可能にし、ブラックリストに記載された場合に顧客およびサービス提供者間のサービス提供を回避する。顧客およびドライバーはまた、需要および供給に少なくとも部分的に基づいて、リクエストされたサービスの価格を交渉し得る。本方法により提供される運輸サービスの自動的スケジューリングにより、マイクロ派遣システムを用いてパートナードライバーの配置に基づいて、ライブでの派遣エージェントの関与を必要とすること無くサービスリクエストが受容され、および自動的にスケジュールされる。
2019537166.tif 000002
【特許請求の範囲】
【請求項１】
カスタマイズ可能な事前に計画された運輸派遣の提供のための、コンピュータにより実行される方法であって、
１つ以上のコンピューティングデバイスを通じて、少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好を有する顧客からの事前スケジューリングについてのサービスリクエストを受信することであって、前記サービスリクエストは、ピックアップ時刻、ピックアップ場所、下車時刻または下車場所のうち少なくとも１つを有する少なくとも１つの行程を含み、前記少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好は、お気に入りのドライバー、好みのドライバーまたはレギュラードライバーのうち１つを含むドライバー種類を少なくとも含む、ことと、
前記１つ以上のコンピューティングデバイスを通じて少なくとも１つのドライバー任意選択のプリセットされたサービス選好を任意選択のプリセット場所制限または時間制限と共に受信することと、
少なくとも１人のドライバーが前記少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好に基づいてまたは前記顧客のブラックリストに基づいて前記サービスリクエストを完了することができない場合、第１の１組の複数のドライバーのうち前記少なくとも１人のドライバーを前記サービスリクエストの受信から自動的に排除することと、
サービス関連データに対応する第２の１組の前記複数のドライバーと関連付けられた少なくとも１つのインジケータを生成することと、
前記少なくとも１つのインジケータを前記顧客へ送信することであって、前記少なくとも１つのインジケータは、前記少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好に対応する、ことと、
少なくとも１つの指定された日付または時刻について、前記少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好が以下の少なくとも一部とマッチするかを決定することであって：
前記少なくとも１つのドライバー任意選択のプリセットされたサービス選好、および
前記少なくとも１つのインジケータ、
ことと、
前記第２の１組の前記複数のドライバーのうち前記少なくとも１人のドライバーへ前記サービスリクエストを割り当てることと、
前記サービスリクエストを発信する少なくとも１つの通知を前記第２の１組の前記複数のドライバーから前記少なくとも１人のドライバーへ送信することと、
前記少なくとも１人のドライバーからの前記サービスリクエストの受諾を前記第２の１組の前記複数のドライバーから受信することと、
少なくとも１つのデータベース中の前記サービス関連データを動的に更新することと、
を含む、方法。
【請求項２】
前記サービスリクエストが前記第２の１組の複数のドライバーへ割り当てられていない場合、少なくとも１つの二次インジケータを生成することであって、前記少なくとも１つの二次インジケータは、サービス関連データに対応する第３の１組の前記複数のドライバーと関連付けられ、前記サービス関連データは、以下のうち少なくとも１つを含む：識別状態、稼動性、現在の場所、帰還場所、ピックアップの推定される時間、または精通度レベル、ことと、
前記サービスリクエストを発信する少なくとも１つの通知を前記第３の１組の前記複数のドライバーから前記少なくとも１人のドライバーへ送信することと、
前記少なくとも１人のドライバーからの前記サービスリクエストの受諾を前記第３の１組の前記複数のドライバーから受信することと、
をさらに含む、請求項１に記載の方法。
【請求項３】
前記サービスリクエストが前記第２または前記第３の１組の複数のドライバーへ割り当てられていない場合、前記サービスリクエストをジョブプールに保存することであって、前記ジョブプールは、少なくとも１人以上の利用可能なドライバーが前記１つ以上のコンピューティングデバイスを通じてアクセスすることが可能である、ことと、
前記１つ以上のコンピューティングデバイスの前記ジョブプール中の前記サービスリクエストのうち少なくとも残りの１つを前記１人以上の利用可能なドライバーが選択することを可能にすることと、
をさらに含む、請求項２に記載の方法。
【請求項４】
前記第２の１組の前記複数のドライバーのうち前記顧客のお気に入りリストに記載されているドライバーがいないかを決定することと、
前記第２の１組の前記複数のドライバーのうち前記お気に入りリストに記載されているドライバーがいない場合、１つ以上のマッチング属性を有する前記適合する好みのドライバーに基づいて、前記少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好にマッチする前記少なくとも１つのドライバー任意選択のプリセットされたサービス選好と共に、適合する好みのドライバーを前記顧客へ提供することと、
前記顧客に対して以前行われたサービスリクエストの合計数に基づいて、前記サービスリクエストに対して最高数の前記マッチング属性を有する前記適合する好みのドライバーまたは前記顧客に対して最も経験豊富な好みのドライバーを割り当てることと、
をさらに含む、請求項１に記載の方法。
【請求項５】
前記第２の１組の複数のドライバーのうち利用可能なドライバーが前記お気に入りのドライバーの少なくとも１人のお気に入りのドライバーまたは前記好みのドライバーの少なくとも１人の前記好みのドライバーではない場合、前記少なくとも１つのドライバー任意選択のプリセットされたサービス選好と、前記少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好との間の１つ以上のマッチング属性に基づいて、前記顧客に対して適合するレギュラードライバーを決定することと、
前記適合するレギュラードライバーを前記サービスリクエストへ割り当てることと、
をさらに含む、請求項１に記載の方法。
【請求項６】
前記受諾されたサービスリクエストについて、割り当てられたドライバーによる再派遣リクエストを
前記割り当てられたドライバーと関連付けられたパートナードライバーへ送信することと、
１つ以上の再派遣通知を前記パートナードライバーへ送信することと、
前記サービスリクエストの受諾を前記パートナードライバーから受信することと、
をさらに含む、請求項１に記載の方法。
【請求項７】
前記少なくとも１人のドライバー種類は、お気に入りのドライバー、前記好みのドライバーまたは前記レギュラードライバーのうち１人を含み、前記お気に入りのドライバー、前記好みのドライバーまたは前記レギュラードライバーは、ランク毎に優先順位が付けられる、請求項１に記載の方法。
【請求項８】
前記精通度レベルは、前記サービスリクエストの経路と、前記第２の１組の前記複数のドライバーのうち少なくとも１人と関連付けられた経路データとの間の重複量の決定によって計算され、前記量は、以下のうち少なくとも１つとして表示される：階層、一定範囲の階層、グレード、一定範囲のグレード、スコア、一定範囲のスコア、パーセンテージ、一定範囲のパーセンテージまたは他の任意の図解、請求項１に記載の方法。
【請求項９】
前記少なくとも１人の顧客は、前記第２の１組の前記複数のドライバーのうち少なくとも１人と関連付けられた前記送信された少なくとも１つのインジケータを用いて、前記サービスリクエストに関連する価格について、前記第１および前記第２の１組の前記複数のドライバーのうち前記少なくとも１人と交渉する、請求項１に記載の方法。
【請求項１０】
前記少なくとも１つのインジケータは、ドライバーのユーザ種類、顧客のユーザ種類、前記ピックアップ場所から前記下車場所までの推定移動時間、前記ドライバーの稼動性、前記ドライバーが利用可能な残り時間、未割当のサービスリクエスト、前記ドライバーの現在の場所、前記ドライバーの帰還場所、前記ピックアップ場所、前記下車場所、価格、前記ピックアップ場所と前記下車場所との間の経路についての前記ドライバーの精通度レベル、前記第２の１組の１人以上のドライバーの識別状態、前記顧客の前記サービスリクエストを実行するための前記第２の１組の１人以上のドライバーの稼動性、前記第２の１組の１人以上のドライバーが１つ以上のサービスリクエストを潜在的に実行するために利用可能な残り時間、前記第２の１組の１人以上のドライバーの１つ以上の現在の場所、前記第２の１組の１人以上のドライバーの１つ以上の帰還場所、ピックアップの前記推定時間、前記１人以上のドライバーが行うサービスリクエストの合計数、潜在的な利用可能なサービスリクエストの合計数と、プリセットされた検索パラメータ内の潜在的な利用可能な顧客の合計数と比較した際の需要および供給、前記１人以上のドライバーが前記ピックアップ場所の識別情報または前記下車場所の識別情報のゾーン内においてサービスリクエストを行う頻度、前記顧客と前記１人以上のドライバーとの間の完了したサービスリクエストの合計数のうち少なくとも１つを反映し、
前記顧客のユーザ種類または前記ドライバーのユーザ種類は、お気に入り、選好またはレギュラーのうち少なくとも１つを含み、
前記割り当てられたドライバーは、前記少なくとも１つのインジケータから提供された情報に少なくとも部分的に基づく、
請求項１に記載の方法。
【請求項１１】
カスタマイズ可能な自動化された事前に計画された運輸派遣を提供するための、コンピュータにより実行される方法であって、
事前スケジューリングについて複数のサービスリクエストを受信することであって、前記複数のサービスリクエストはそれぞれ、ピックアップ時刻、ピックアップ場所、下車時刻または下車場所のうち少なくとも１つを有する少なくとも１つのレッグを含む、ことと、
前記ピックアップ場所または前記下車場所のうち１つの地域に従って、前記複数のサービスリクエストをソートすることと、
前記複数のサービスリクエストを１つ以上のデータベース中に保存することと、
（ｉ）前記複数のサービスリクエストの各サービスリクエストと関連付けられた顧客の顧客情報であって、前記顧客情報は、任意選択的にプリセットされたサービス選好、お気に入りリスト、選好リストまたはブラックリストのうち少なくとも１つを含む、顧客情報と、（ｉｉ）１人以上のドライバープロファイルであって、前記１人以上のドライバープロファイルはそれぞれドライバー情報を含み、前記ドライバー情報は、地理的サービス領域および任意選択的にプリセットされたサービス制限、サービス履歴、お気に入りリスト、ブラックリストまたは履歴データのうち少なくとも１つを含む、１人以上のドライバープロファイルと、（ｉｉｉ）指定された日付の指定された地域についての下記のうち少なくとも１つとを前記１つ以上のデータベースからから検索することであって、
前記保存された複数のサービスリクエストからのサービスリクエストのバッチと、
前記バッチと関連付けられた複数の顧客に対応する複数の顧客プロファイルであって、前記顧客プロファイルは顧客情報を含む、複数の顧客プロファイル、または、
前記バッチへ割り当てられる複数のドライバーに対応する複数のドライバープロファイルであって、前記ドライバープロファイルは、ドライバー情報を含む、複数のドライバープロファイル、
ことと、
以下のような１人以上のドライバーを第１の１組のドライバーから排除することであって、（ｉ）前記サービスリクエストに適合しない者、（ｉｉ）前記顧客の前記ブラックリストに記載されている者、または（ｉｉｉ）前記ドライバーの前記ブラックリスト上に前記顧客を有する者、ことと、
少なくとも１組以上のインジケータに基づいて前記サービスリクエスト、前記顧客情報、および第２の１組のドライバーからのドライバーの前記１人以上のドライバープロファイルを用いて派遣マトリックスを生成することであって、前記派遣マトリックスにより、前記第２の１組のドライバーの各ドライバーへの割当の優先順位が生成される、ことと、
前記第２の１組のドライバーからの各前記ドライバーを前記バッチのサービスリクエストに対して前記優先順位割当に従って割り当てることと、
前記第２の１組のドライバーからのドライバーのグループを前記優先順位割当に基づいて顧客コンピューティングデバイスへ送信することと、
前記ドライバーのグループから選択された１人の最良にマッチするドライバーを前記顧客コンピューティングデバイスから受信することと、
前記サービスリクエストを前記選択された１人の最良にマッチするドライバーへ送信することと、
を含む、方法。
【請求項１２】
前記顧客の前記任意選択的にプリセットされたサービス選好は、前記顧客の前記お気に入りリスト上の少なくとも１人のお気に入りのドライバーを優先付ける前記顧客または前記顧客の前記選好リスト上の少なくとも１人の好みのドライバーを優先付ける前記顧客のうち少なくとも１人を含み、
前記ドライバーの前記任意選択的にプリセットされたサービス制限は、前記ドライバーの前記お気に入りリスト上の少なくとも１人のお気に入りの顧客を優先付ける前記ドライバーを含み、
前記優先付けることは、前記顧客が前記最良にマッチするドライバーを選択する前に実行され、
前記顧客は、前記優先順位を動的に変更することができる、
請求項１１に記載の方法。
【請求項１３】
前記派遣マトリックスは、前記顧客と前記ドライバーとの間の適合性を以下を含む要素に基づいて決定するための出力を提供する：
前記顧客からの前記サービスリクエストを受諾するための前記ドライバーの稼動性、
前記ドライバーは、前記顧客の前記お気に入りリスト、前記顧客の前記選好リストまたは前記顧客の前記ブラックリストに記載され、または、
前記顧客の前記任意選択的にプリセットされたサービス選好にマッチする前記ドライバーの前記任意選択的にプリセットされたサービス制限、
請求項１１に記載の方法。
【請求項１４】
ドライバーのユーザ種類、顧客のユーザ種類、前記ピックアップ場所から前記下車場所までの推定される移動時間、前記ドライバーの稼動性、前記ドライバーが利用可能なままでいる時間、未割当のサービスリクエスト、前記ドライバーの現在の場所、前記ドライバーの帰還場所、前記ピックアップ場所、前記下車場所、価格、前記ピックアップ場所と前記下車場所との間の経路についての前記ドライバーの精通度レベル、前記第２の１組の１人以上のドライバー識別状態、前記顧客の前記サービスリクエストを実行するための前記第２の１組の１人以上のドライバーの前記稼動性、潜在的に１つ以上のサービスリクエストを実行するために前記第２の１組の１人以上のドライバーが利用可能であり続ける時間、前記第２の１組の１人以上のドライバーの１つ以上の現在の場所、前記第２の１組の１人以上のドライバーの１つ以上の帰還場所、ピックアップの前記推定される時間、前記１人以上のドライバーによって行われるサービスリクエストの合計数、プリセットされた検索パラメータ内の潜在的な利用可能な顧客の合計数と比較したときの潜在的な利用可能なサービスリクエストの合計数に基づいた需要および供給、前記ピックアップ場所の識別情報または前記下車場所の識別情報のゾーン内において前記１人以上のドライバーがサービスリクエストを実行する頻度、前記顧客と、前記１人以上のドライバーとの間の完了したサービスリクエストの合計数うち少なくとも１つを反映する１組の１つ以上のインジケータを生成するステップ、
をさらに含み、
前記顧客のユーザ種類または前記ドライバーのユーザ種類は、お気に入り、選好またはレギュラーのうち少なくとも１つを含み、
前記サービスリクエストに対して前記選択された１人の最良にマッチするドライバーは、前記１組以上のインジケータから提供される情報に少なくとも部分的に基づく、
請求項１１に記載の方法。
【請求項１５】
前記精通度レベルは、パーセンテージ、階層、または異なるレベルの精通度を示す他の任意の図解のうち少なくとも１つによって反映され、
前記精通度レベルは、前記サービスリクエストの経路と、前記第２の１組の１人以上のドライバーのうち少なくとも１人と関連付けられた履歴経路データとの間の重複量を少なくとも決定することにより決定され、
前記履歴経路データは、前記サービスリクエストの完了時に前記１人以上のドライバーを自動追跡することによって入手され、前記データは前記１つ以上のデータベース中に保存され、
前記精通度レベルは、少なくとも間接的精通度または直接的精通度を含む、
請求項１４に記載の方法。
【請求項１６】
前記サービスリクエストの経路についての前記間接的精通度として前記精通度レベルを表示することであって、各別個の共通部分は、前記サービスリクエストの経路よりも短い、ことと、
前記第２の１組の１人以上のドライバーが完了した１つ以上のサービスリクエストの前記経路および１つ以上の経路間の前記１つ以上の別個の共通部分として１つ以上の経路セグメントを特定することと、
前記第２の１組の１人以上のドライバーの前記１人以上のドライバーそれぞれが完了した前記１つ以上のサービスリクエストの前記１つ以上の別個の共通部分の合計を計算することと、
前記１つ以上の別個の共通部分の合計を前記サービスリクエストの前記経路の合計距離によって除算することと、
前記サービスリクエストの前記経路についての前記直接的精通度として前記精通度レベルを表示することであって、前記１つ以上の別個の共通部分のうち少なくとも１つは、前記サービスリクエストの経路以上である、ことと、
をさらに含む、請求項１５に記載の方法。
【請求項１７】
前記地理的サービス領域は、郵便番号、市町村、州、通り、通りのグループ、近隣、行政区、国、またはフィーチャを規定する他の任意の領域を含み得る、請求項１１に記載の方法。
【請求項１８】
前記顧客のお気に入りリストに記載されておりかつ前記顧客のサービスリクエストを受諾するために利用可能であること、最高数の完了したサービスリクエストを有すること、開始価格提案が最低であること、前記顧客が開始した価格提案に対する価格応答が最低であること、前記ピックアップ場所と、前記サービスリクエストの前記下車場所との間の経路に最も精通していること、前記ピックアップ場所の地域内において実行したサービスリクエスト数が最も多いこと、前記下車場所の地域内において実行したサービスリクエスト数が最も多いこと、前記顧客に対して完了したサービスリクエスト数が最も多いこと、推定到着時刻が最も早いこと、現在の場所が前記ピックアップ場所に最も近いこと、およびプリセット帰還場所の時間および場所が前記サービスリクエストの前記時間および下車場所と適合する場合に前記プリセット帰還場所が前記１人以上のドライバーの推定される移動時間の計算に含まれることのうち１つ以上に従って１人以上のドライバーに優先順位を付けるステップ、
をさらに含み、
前記優先順位を付けることは、前記顧客が前記最良にマッチするドライバーを選択する前の任意の時間において前記任意選択的にプリセットされたサービス選好に基づいて実行され、前記顧客は、前記優先順位を付けることを動的に変更し得る、
請求項１１に記載の方法。
【請求項１９】
前記ドライバーが前記地理的サービス領域またはサービス時間制限のうち少なくとも１つを対話電子インターフェースを用いて設定することを可能にするステップ、
をさらに含む、請求項１１に記載の方法。
【請求項２０】
複数のクリック可能地域に分割された電子マップディスプレイをドライバーコンピューティングデバイス上に表示するステップと、
前記ドライバーが前記ドライバーコンピューティングデバイスを通じて前記地理的サービス領域を前記電子マップから選択することを可能にするステップと、
前記地理的サービス領域のうち１つが前記１人以上のドライバーによって選択された場合、前記データベースを動的に更新するステップと、
をさらに含む、請求項１１に記載の方法。
【請求項２１】
少なくとも１つの前記サービスリクエストが少なくとも１人の前記ドライバーへ割り当てられていない場合、サービス関連データに関連する第３の１組のドライバーと関連付けられた１組の二次のインジケータを生成することと、
前記サービスリクエストが前記第２または前記第３の１組の複数のドライバーへ割り当てられていない場合、前記サービスリクエストをジョブプールに保存することであって、前記ジョブプールは、少なくとも１人以上の利用可能なドライバーが前記１つ以上のコンピューティングデバイスを通じてアクセスすることが可能である、ことと、
前記１人以上の利用可能なドライバーが前記１つ以上のコンピューティングデバイスの前記ジョブプール中の前記サービスリクエストのうち少なくとも残り１つを選択することを可能にすることと、
をさらに含む、請求項１１に記載の方法。
【請求項２２】
前記ジョブプール中の各未割当の前記サービスリクエストを電子マップディスプレイ上の１つ以上のクリック可能なアイコンとして表示するステップと、
前記ジョブプール中の前記サービスリクエストのうち１つが前記１人以上の利用可能なドライバーのうち１人によって選択された際、前記ジョブプールおよび前記電子マップディスプレイを動的に更新するステップと、
をさらに含み、
前記電子マップは、複数の地域に分割される、
請求項２１に記載の方法。
【請求項２３】
複数の地域に分割された電子マップディスプレイ上に各利用可能なドライバーを表示するステップと、
各前記利用可能なドライバーの前記１つ以上のリモートコンピューティングデバイスの時間と共に変化する地理的場所を自動的かつ周期的に追跡するステップと、
前記１つ以上のリモートコンピューティングデバイスの前記時間と共に変化する地理的場所に基づいて、前記１つ以上のデータベースおよび前記電子マップディスプレイを動的に更新するステップと、
前記利用可能なドライバーを前記顧客が前記マップから選択することを可能にするステップと、
をさらに含む、請求項１１に記載の方法。
【請求項２４】
前記任意選択的にプリセットされたサービス選好は、前記顧客によって提供され、車両種別、車両の型式およびモデル、車両の座席定員、車両空間の容量、車両重量容量、車椅子のアクセシビリティ、ベビーシート稼動性、ペット対応、ドライバーの言語能力、ドライバーの性別、ドライバーの運転経験、前記経路についてのドライバーの精通度、ドライバーの特定の種類の物品を取り扱った経験、壊れ物または他の特殊なパッケージングまたは送達方法を要する物品への対応のうち１つ以上に関連する選好を含む、請求項１１に記載の方法。
【請求項２５】
前記任意選択的にプリセットされたサービス制限は、前記１人以上のドライバーによって提供され、１つ以上の個人的制限または１つ以上の法的制限を含み、
前記１つ以上の個人的制限は、前記地理的サービス領域と、以下のうち１つ以上に関連する１つ以上の他の制限とに基づいた１つ以上の場所制限を含む：プリセット帰還場所への推定到着時刻、推定される移動時間、推定される移動距離、物品種類、物品数、物品重量、物品サイズ、アレルギーおよびペット対応、
前記１つ以上の法的制限は、前記地理的サービス領域内においてサービスを提供している前記１人以上のドライバーの不法行為に基づいた１つ以上の場所制限を含む地方条例、サービス時間、乗客数、ベビーシート稼動性およびアクセシビリティに関連する１つ以上の他の制限のうち１つ以上に関連し、
前記１つ以上の法的制限に起因して前記１人以上のドライバーが前記サービスリクエストを実行できなかった場合、前記１つ以上の法的制限は、前記１人以上のドライバーが前記サービスリクエストを受信するのを排除するように実行される、
請求項１１に記載の方法。
【請求項２６】
前記選択された１人の最良にマッチするドライバーが前記受諾されたサービスリクエストを完了することができなかった場合、前記受諾されたサービスリクエストは、以下を行うことにより、前記選択された１人の最良にマッチするドライバーと関連付けられたパートナードライバーへ再派遣される：
前記受諾されたサービスリクエストについての再派遣リクエストを前記パートナードライバーへ送信すること、
前記再派遣リクエストの受諾を前記パートナードライバーから受信すること、
前記再派遣リクエストの通知を、前記サービスリクエストと関連付けられた前記顧客へ送信すること、
前記顧客による前記再派遣リクエストの受諾を受信すること、
請求項１１に記載の方法。
【請求項２７】
１人よりも多くのお気に入りのドライバーが前記選好において特定された場合、優先順位が最も高いお気に入りのドライバーを決定し、前記優先順位が最も高いお気に入りのドライバーを前記サービスリクエストへ割り当てるステップと、
前記優先順位が最も高いお気に入りのドライバーが利用できない場合、第２の優先順位のお気に入りのドライバーを決定し、前記第２の優先順位のお気に入りのドライバーを前記サービスリクエストへ割り当てるステップと、
１人よりも多くのお気に入りの顧客が特定された場合、優先順位が最も高いお気に入りの顧客を決定し、前記ドライバーを前記優先順位が最も高いお気に入りの顧客へ割り当てるステップと、
前記優先順位が最も高いお気に入りの顧客が既に割り当てられている場合、第２の優先順位のお気に入りの顧客を決定し、前記第２の優先順位のお気に入りの顧客を前記ドライバーへ割り当てるステップと、
をさらに含む、請求項１１に記載の方法。
【請求項２８】
１つ以上のコンピューティングデバイスに関連する１つ以上の表示装置を通じて前記１つ以上のインジケータを表示することであって、前記表示することは、前記顧客がマッチするドライブを選択することを可能にし、前記お気に入りリスト上の前記１人以上のドライバーのうち前記サービスリクエストに適合しない者は、前記１つ以上の組のインジケータを通じて表示されず、前記１つ以上の組のインジケータは、異なるフォーマットで表示される、
をさらに含む、請求項１１に記載の方法。
【請求項２９】
運輸サービスのためのカスタマイズ可能な自動化されたマイクロ派遣を提供するための、コンピュータにより実行される方法であって、
１つ以上のリモートコンピューティングデバイスを通じて、スケジューリングについてのサービスリクエストを１つ以上の任意選択的にプリセットされたサービスリクエスト選好を有する顧客から受信することであって、前記サービスリクエストは、経路の少なくとも１つのレッグを含む、ことと、
前記サービスリクエストに関連する情報を１つ以上のデータベースに保存することと、
１つ以上のインジケータを通じて表示される情報に少なくとも部分的に基づいて、前記サービスリクエストを受信するドライバーをドライバーのサブセットから選択し、前記サービスリクエストを前記選択されたドライバーへ発信することと、
前記サービスリクエストの受諾を前記選択されたドライバーから受信することと、
前記選択されたドライバーと関連付けられた１人以上のパートナードライバーをマイクロ派遣システムにおいて特定することであって、前記１人以上のパートナードライバーは、前記１つ以上のリモートコンピューティングデバイスを通じて前記選択されたドライバーと通信する、ことと、
前記選択されたドライバーが前記受諾されたサービスリクエストについての再派遣リクエストを前記１人以上のパートナードライバーのうち特定された者へ送信することと、
再派遣通知を前記特定されたパートナードライバーへ送ることと、
前記再派遣リクエストの受諾を前記パートナードライバーから受信することと、
前記特定されたパートナードライバーの前記顧客に自動的に通知し、前記特定されたパートナードライバーを受容または拒否するオプションを前記顧客へ提供することと、
前記パートナードライバーからの前記再派遣リクエストの前記受諾の受信に基づいて、前記１つ以上のデータベース中の前記サービス関連データを動的に更新することと、
を含む、方法。
【請求項３０】
サーバコンピューティングシステム上に保存されたデータベースと、少なくとも１つのリモートコンピューティングデバイスとの間で交換されるサービス関連データを動的かつ自動的に更新する方法であって、
顧客からのサービスリクエストをサーバコンピューティングデバイスにおいて受信することであって、前記サービスリクエストは、経路の少なくとも１つのレッグを含む、ことと、
前記サービスリクエストに関連するサービス関連データを前記サーバコンピューティングデバイス上の１つ以上のデータベース中に保存することと、
ドライバーのグループからドライバーを選択して前記サービスリクエストを完了し、前記サービスリクエストを前記選択されたドライバーへ自動的に派遣することと、
１つ以上のリモートドライバーコンピューティングデバイスを通じて前記サービスリクエストの受諾を前記選択されたドライバーから受信することと、
前記サービスリクエストに関連する第１の更新されたサービス関連データを特定することであって、前記第１の更新されたサービス関連データは、前記サービスリクエストの完了前に前記サーバコンピューティングデバイスにおいて特定される、ことと、
前記第１の更新されたサービス関連データと共に前記データベースを動的に更新することと、
前記第１の更新されたサービス関連データを前記１つ以上のリモートドライバーコンピューティングデバイスを通じて表示するために前記ドライバーへ自動的に送信することと、
前記サービスリクエストに関連する第２の更新されたサービス関連データを特定することであって、前記第２の更新されたサービス関連データは、前記ドライバーによる前記サービスリクエストの受諾後に前記１つ以上のリモートドライバーコンピューティングデバイスを通じて前記ドライバーによって特定される、ことと、
前記第２の更新されたサービス関連データを前記サーバコンピューティングデバイスへ自動送信することと、
前記データベースを前記第２の更新されたサービス関連データと共に動的に更新することと、
前記第２の更新されたサービス関連データを表示装置上に表示することと、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照
本出願は、米国仮特許出願第６２／３９９，１２９号（出願日：２０１６年９月２３日）、（米国仮特許出願第６２／３２５，６０２号（出願日：２０１６年４月２１日）の恩恵を主張する米国非仮特許出願第１５／２３９，７８３号（以下、「７８３」出願）（出願日：２０１６年８月１７日）の部分継続出願である）米国仮特許出願第６２／５０５，６２６号（出願日：２０１７年５月１２日）、および米国仮特許出願第６２／２９０，７７８号（出願日：２０１６年２月３日）の恩恵を主張し、本明細書中、同文献の開示全体を参考のため援用する。
【０００２】
本開示は、運輸サービスのためのシステムおよび方法に主に関し、より詳細には、事前に計画された運輸サービスのためのシステムおよび方法に関する。１つ以上のサービスリクエストが、指定された派遣日に先行して受信され、個々の顧客とのドライバーの稼動性および適合性に基づいて、事前に計画されかつ／またはグループ分けされる。
【背景技術】
【０００３】
運輸サービス業界における派遣およびスケジューリング用ソフトウェアは、ドライバーおよび顧客に関連する異なる変数に対処するようにプログラムされる（例えば、顧客およびベンダー双方から受信されたサービスリクエストの処理から、これらのサービスリクエストに基づいたドライバーの調整）。しかし、派遣ソフトウェアの場合、収集される情報の種類と、スケジュール生成時に後で処理するために情報が保存される点とにおいて不完全である。エラーまたは矛盾が有る場合、処理速度の低下および問題の複雑化に繋がり得るため、最終的にサービスの妨げになり得る。このような情報をデータベースにおいて編成し、包括的にクエリ生成してサービスリクエストを効率的に事前スケジュールするためには、多数の課題がある（特に、予備マッチが見つけるまでドライバーを一人一人ソートするシステムの場合）。予備マッチが見つかった後は、トライバーが実際にサービスを提供できるか確認するために、トライバーに連絡をとる必要がある。あるいは、ドライバーが既にスケジュールが組まれている行程のリストを受け取った場合、矛盾が有る場合は１つ以上をキャンセルする必要があり得る。
【０００４】
従来のシステムにおいては、このような問題のため、派遣担当者にとって前日に行程を事前スケジュールすることは極めて複雑かつ時間がかかり得るかまたはコンピューティングシステム上において煩雑になり得る。キャンセルおよび予約変更を考慮する場合（特に、行程毎に複数の区間が存在する場合）（例えば、顧客を自宅から店舗に連れて行った後に自宅へ戻る場合、１人よりも多くの顧客に対して同時サービスが有る場合、または複数の行程が引き続いてスケジュールされている場合）、プロセスはさらに複雑になる。変更またはキャンセルが有った場合、サービスリクエストを（多くは手作業による）リスケジューリングのために「ダッシュボード」へ返送する必要があり得る。
【０００５】
サービスリクエストが提示されると、ドライバーは、そのリクエストを定刻通りに完了できると推定し得るものの、予期せぬ経路変更または見込み違いに起因して、ドライバーが望む停止時間を超えて働かなくてはならない場合があり得る。そのため、ドライバーのスケジュールと適合しないサービスリクエストへドライバーが派遣する事態が往々にしてあり、顧客およびドライバーは直前になってキャンセルを通知しなくてはならなくなる。また、派遣担当者は、顧客がどんな人であるかについて必ずしも熟知している訳では無く、顧客の選好を知らない場合がある。派遣担当者が最も近隣にいるドライバーを顧客へ送ったものの、そのドライバーがそのエリアに不案内であるかまたは顧客へ割り当てられたそのドライバーが顧客の好みではない場合がある。ドライバーは近隣にいるため顧客を迅速にピックアップすることができても、顧客がサービスに不満を持つ可能性がある。さらに、サービス担当として事前に計画されている派遣されたドライバーが特定の時刻に現れた場合であっても、顧客の準備ができていないため外で長時間待機しなくてはならない場合がある。派遣担当者は、顧客の準備がいつできるのかについてドライバーに連絡するかまたは効率的に更新する方法を持たない。派遣および運輸サービスの提供は複雑なオペレーションであり、体系的改善が必要な領域が多数存在する。従来の派遣方法の場合、新規のサービスリクエストまたは予期せぬ様態で変化するサービスリクエストに対する適応性が低い。
【０００６】
よって、これらの問題への対処、プロセスの効率化、ドライバー稼働率の増加、効率向上、手作業による派遣の制限、顧客およびドライバーの不満足への対処、事前スケジューリングサービスリクエストの割当のための顧客およびドライバーのカスタマイズ化、および事前計画されたサービスの自動化による技術的向上の利用のための、向上したシステムおよび方法が当該分野において必要とされていることが理解される。
【発明の概要】
【０００７】
本発明は、コンピュータにより実行される事前スケジューリングシステムの多様なシステムおよび方法に関する。本要旨は、本明細書中で主張される主題の範囲の本質的特徴を特定または指示するかまたは制限することを意図しない。本発明は、運輸サービスを事前スケジューリングする方法およびシステムに関する。この方法およびシステムにおいて、複数のサービスリクエストが指定された派遣日に先行して受信され、事前に計画され、個々の顧客のとのドライバー稼動性および適合性に基づいてグループ分けすることにより、公知のスケジューリングおよび派遣サービスシステムの欠陥を解消する。本発明は、少なくとも以下の目的を有する。
【０００８】
既知の顧客の選好および既知のサービス提供者の選好および制約の派遣マトリックスに基づいてサービス提供者および顧客を最適にマッチさせる、カスタマイズ可能な事前スケジューリング派遣サービス方法およびシステムを提供すること。
【０００９】
高品質のサービス提供のため、顧客およびサービス提供者のプリセット、設定、選好、制限、フィードバックまたは他の情報の変更を通知するために、データベースを動的に更新するように構成されたシステムを提供すること。
【００１０】
顧客が（最良のサービスを最良にマッチするサービス提供者から受けるために）システム内のオプションを自身の選好の種類に基づいてカスタマイズすることを可能にすること。
【００１１】
サービス品質向上のために顧客とサービス提供者との間でやり取りされるフィードバックに基づいたお気に入りリストおよび選好リストの生成により顧客とサービス提供者との間の関係の進展および促進を進めることと、顧客が１人以上のお気に入りのおよび／または選好されるサービス提供者を選択することを可能にすることとのために、お気に入りのサービス提供者は、自身のお気に入りリスト上に記載されているお気に入りの顧客からサービスリクエストを受信するための優先順位を受け取り得る。
【００１２】
事前スケジューリングプロセス時に発生する任意の矛盾を解消するために、ドライバーが自身のお気に入りの顧客リスト上の顧客リストに優先順位を付けることを可能にすること。
【００１３】
事前スケジューリングプロセス時に発生する任意の矛盾をさらに解消するために、顧客またはドライバーが選好カテゴリまたは制限カテゴリそれぞれを優先順位付けすることを可能にすること。
【００１４】
顧客によってブラックリストに記載されたサービス提供者については、顧客からの派遣サービスリクエストについて当該サービス提供者を無視するためのブラックリストを生成すること。
【００１５】
顧客およびサービス提供者が、デフォルト価格を参照しつつ需要および供給に少なくとも部分的に基づいて、リクエストされたサービスの価格について自発的に設定または交渉を行うための、電子的に実行されるプラットフォームを提供すること。
【００１６】
単一のサービスリクエストについてのベストマッチの簡便かつ効率的な選択を促進するために、多様な複数組のインジケータを顧客および／またはドライバーへ提供すること。
【００１７】
従来の派遣システムの作業負荷を実質的に軽減するために、ドライバーとパートナードライバーとの間のマイクロ派遣システムを促進すること。
【００１８】
ドライバーがサービス提供を望むプリセットされた１つ以上の地域をそれぞれ有する１人以上のドライバーに対し、サービスリクエストのバッチについての自動化された事前スケジューリングを可能にすること。
【００１９】
派遣ウェブポータルと、サービスリクエストに割り当てられたドライバーと関連付けられたドライバーデバイスとにおける事前に計画されたサービスリクエストの変更を表示することにより、派遣担当者とドライバーとの間の接続性を促進し、当該変化について（通話通信を全く用いずに）更新および保存をデータベースにおいて動的に行うこと。
【００２０】
顧客と、１人以上の最良にマッチするドライバーとの間において、単一のサービスリクエストについて価格交渉を可能にすること。
【００２１】
フルサービス派遣を可能にすること。フルサービス派遣は、サービスリクエストの事前スケジューリング、サービサーリクエストの発信、サービスリクエストの変更の動的な更新および促進、および運輸時における全パーティへのリアルタイム情報提供を含む。
【００２２】
例示的実施形態によれば、カスタマイズ可能な事前に計画された運輸派遣のための、コンピュータにより実行される方法が提供される。本方法は、１つ以上のコンピューティングデバイスを通じて、少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好を有する顧客からの事前スケジューリングについてのサービスリクエストを受信することを含む。このサービスリクエストは、ピックアップ時刻、ピックアップ場所、下車時刻または下車場所のうち少なくとも１つを有する少なくとも１つの行程を含む。少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好は、少なくともドライバー種類を含む。ドライバー種類は、お気に入りのドライバー、好みのドライバーまたはレギュラードライバーのうち１つを含む。本方法は、以下をさらに含む：１つ以上のコンピューティングデバイスを通じて、少なくとも１つのドライバー任意選択のプリセットされたサービス選好を任意選択のプリセット場所制限または時間制限と共に受信することと、少なくとも１人のドライバーが少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好に基づいてまたは顧客のブラックリストに基づいてサービスリクエストを完了できない場合、第１の１組の複数のドライバーのうち少なくとも１人のドライバーをサービスリクエストの受信から自動的に排除することと、サービス関連データに対応する第２の１組の複数のドライバーと関連付けられた少なくとも１つのインジケータを生成することと、少なくとも１つのインジケータを顧客へ送信することであって、少なくとも１つのインジケータは、少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好に対応することと、少なくとも１つの指定された日付または時刻について、少なくとも１つの顧客任意選択のプリセットされたサービスリクエスト選好が少なくとも１つのドライバー任意選択のプリセットされたサービス選好および少なくとも１つのインジケータのうち少なくとも一部とマッチするかを決定することと、第２の１組の複数のドライバーから少なくとも１人のドライバーへサービスリクエストを割り当てることと、サービスリクエストを発信する少なくとも１つの通知を第２の１組の複数のドライバーから少なくとも１人のドライバーへ送信することと、少なくとも１人のドライバーからのサービスリクエストの受諾を第２の１組の複数のドライバーから受信することと、少なくとも１つのデータベース中のサービス関連データを動的に更新すること。
【００２３】
他の例示的実施形態によれば、カスタマイズ可能な自動化された事前に計画された運輸派遣の提供のための、コンピュータにより実行される方法が提供される。本方法は、以下を含む：事前スケジューリングについて複数のサービスリクエストを受信することであって、複数のサービスリクエストはそれぞれ、ピックアップ時刻、ピックアップ場所、下車時刻または下車場所のうち少なくとも１つを有する少なくとも１つのレッグを含む、ことと、ピックアップ場所または下車場所のうち１つの地域に従って、複数のサービスリクエストをソートすることと、複数のサービスリクエストを１つ以上のデータベース中に保存することと、１つ以上のデータベースから以下のうち少なくとも１つを取り出すことであって、（ｉ）複数のサービスリクエストの各サービスリクエストと関連付けられた顧客の顧客情報であって、顧客情報は、任意選択的にプリセットされたサービス選好、お気に入りリスト、選好リストまたはブラックリストのうち少なくとも１つを含む、顧客情報と、（ｉｉ）１人以上のドライバープロファイルであって、１人以上のドライバープロファイルはそれぞれドライバー情報を含み、ドライバー情報は、地理的サービス領域および任意選択的にプリセットされたサービス制限、サービス履歴、お気に入りリスト、ブラックリストまたは履歴データのうち少なくとも１つを含む、１人以上のドライバープロファイルと、（ｉｉｉ）指定された日付の指定された地域について、保存された複数のサービスリクエストからのサービスリクエストのバッチ、バッチと関連付けられた複数の顧客に対応する複数の顧客プロファイルであって、顧客プロファイルは顧客情報を含む、複数の顧客プロファイル、またはバッチへ割り当てられる複数のドライバーに対応する複数のドライバープロファイルであって、ドライバープロファイルはドライバー情報を含む、複数のドライバープロファイルのうち少なくとも１つを取り出すことと、以下のような１人以上のドライバーを第１の１組のドライバーから排除することであって、（ｉ）サービスリクエストに適合しない者、（ｉｉ）顧客のブラックリスト上に記載がある者、または（ｉｉｉ）ドライバーのブラックリスト上に顧客を有する者、ことと、少なくとも１組以上のインジケータに基づいてサービスリクエスト、顧客情報および第２の１組のドライバーからのドライバーの１つ以上のドライバープロファイルを用いて派遣マトリックスを生成することであって、派遣マトリックスにより、第２の１組のドライバーの各ドライバーに対して優先順位割当が生成される、こと。本方法は、優先順位割当に従って、第２の１組のドライバーからバッチのサービスリクエストへ各ドライバーを割り当てることと、第２の１組のドライバーからのドライバーのグループを優先順位割当に基づいて顧客コンピューティングデバイスへ送信することと、ドライバーのグループから選択された１人の最良にマッチするドライバーを顧客コンピューティングデバイスから受信することと、サービスリクエストを選択された１人の最良にマッチするドライバーへ送信することとをさらに含む。
【００２４】
他の実施形態において、運輸サービスのためのカスタマイズ可能な自動化されたマイクロ派遣を提供するための、コンピュータにより実行される方法が提供される。本方法は、以下を含む：１つ以上のリモートコンピューティングデバイスを通じて、１つ以上の任意選択的にプリセットされたされたサービスリクエスト選好を有する顧客からスケジューリングについてのサービスリクエストを受信することであって、サービスリクエストは経路の少なくとも１つのレッグを含む、ことと、サービスリクエストに関連する情報を１つ以上のデータベースに保存することと、１つ以上のインジケータを通じて表示される情報に少なくとも部分的に基づいて、サービスリクエストを受信するドライバーをドライバーのサブセットから選択し、サービスリクエストを選択されたドライバーへ発信し、サービスリクエストの受諾を選択されたドライバーから受信することと、選択されたドライバーと関連付けられた１人以上のパートナードライバーをマイクロ派遣システムにおいて特定することであって、１人以上のパートナードライバーは、選択されたドライバーと１つ以上のリモートコンピューティングデバイスを通じて通信する、ことと、受諾されたサービスリクエストについての再派遣リクエストを選択されたドライバーが１人以上のパートナードライバーのうち特定された者へ送信することと、再派遣通知を特定されたパートナードライバーへ送ることと、再派遣リクエストの受諾をパートナードライバーから受信することと、特定されたパートナードライバーの顧客に自動通知し、特定されたパートナードライバーを受容または拒否するオプションを顧客へ提供することと、パートナードライバーからの再派遣リクエストの受諾の受信に基づいて、１つ以上のデータベース中のサービス関連データを動的に更新すること。
【００２５】
他の実施形態において、サーバコンピューティングシステム上に保存されたデータベースと少なくとも１つのリモートコンピューティングデバイスとの間においてやり取りされるサービス関連データを動的かつ自動的に更新する方法が提供される。本方法は、以下を含む：顧客からのサービスリクエストをサーバコンピューティングデバイスにおいて受信することであって、サービスリクエストは、経路の少なくとも１つのレッグを含む、ことと、サービスリクエストに関連するサービス関連データをサーバコンピューティングデバイス上の１つ以上のデータベース中に保存することと、ドライバーのグループからドライバーを選択してサービスリクエストを完了することと、サービスリクエストを選択されたドライバーへ自動的に発信することと、サービスリクエストの受諾を１つ以上のリモートドライバーコンピューティングデバイスを通じて選択されたドライバーから受信することと、サービスリクエストに関連する第１の更新されたサービス関連データを特定することであって、第１の更新されたサービス関連データは、サービスリクエストの完了前に、サーバコンピューティングデバイスにおいて特定される、ことと、データベースを第１の更新されたサービス関連データと共に動的に更新することと、第１の更新されたサービス関連データを１つ以上のリモートドライバーコンピューティングデバイスを通じた表示対象としてドライバーへ自動送信することと、サービスリクエストに関連する第２の更新されたサービス関連データを特定することであって、第２の更新されたサービス関連データは、ドライバーによるサービスリクエストの受諾後に１つ以上のリモートドライバーコンピューティングデバイスを通じてドライバーによって特定される、ことと、第２の更新されたサービス関連データをサーバコンピューティングデバイスへ自動送信することと、データベースを第２の更新されたサービス関連データと共に動的に更新することと、第２の更新されたサービス関連データを表示装置上に表示すること。
【００２６】
本発明の他の目的、特徴および特性と、関連する構造的要素の動作および機能の方法と、開発および製造の部品および経済性の組み合わせとは、添付図面を以下の詳細な説明と共に参照すればより明らかになる。これらは全て、本明細書の一部を形成する。
【図面の簡単な説明】
【００２７】
添付図面に記載される好適な実施形態を参照することにより、本発明のさらなる理解が得られ得る。図面は、特に添付または後に補正される請求項に記載される本発明の範囲を制限することを意図せず、ひとえに本発明を明確化かつ例示するためのものである。よって、本発明および付随する態様の多くのより深い理解は、添付図面と共に参照されれば、以下の詳細な説明の参照により得られるため、容易に得られ得る。
【図１】例示的な事前に計画された派遣システムを示す。この派遣システムは、本発明の多様な実施形態と共に用いられるコンピューティングシステムおよび１つ以上の周辺コンピューティングデバイスを含む。
【図２】本発明の多様な実施形態による、例示的コンピューティングデバイスおよび関連付けられたコンポーネントを示す。
【図３】本発明の多様な実施形態による、例示的派遣マトリックスを用いた派遣動作を示す。
【図４Ａ】本発明の多様な実施形態による、例示的派遣論理を示すフローチャートである。
【図４Ｂ】例示的運輸方法を示し、本発明の多様な実施形態による、顧客またはドライバーキャンセルを用いたフローチャートである。
【図５】派遣担当者ウェブポータルを含むかまたは含まない、ドライバーと顧客との間の例示的価格交渉を示すフローチャートである。
【図６】本発明の多様な実施形態による、複数の事前に計画されたサービスリクエストを割り当てる例示的方法を示すフローチャートである。
【図７Ａ】本発明の多様な実施形態による、第１のアルゴリズムに基づいて複数の事前に計画されたサービスリクエストを割り当てる例示的方法を示すフローチャートである。
【図７Ｂ】本発明の多様な実施形態による、第１のアルゴリズムに基づいて複数の事前に計画されたサービスリクエストを割り当てる例示的方法を示すフローチャートである。
【図８】本発明の多様な実施形態による、第２のアルゴリズムに基づいて複数の事前に計画されたサービスリクエストを割り当てる例示的方法を示すフローチャートである。
【図９】本発明の多様な実施形態による、複数のサービスリクエストの事前スケジューリングおよびリスケジューリングをパートナードライバーおよびオンデマンド方法を用いて行う例示的方法を示すフローチャートである。
【図１０】本発明の多様な実施形態による、異なる地域中の未割当のサービスリクエストを示す例示的電子マップインターフェースを示す。
【発明を実施するための形態】
【００２８】
本開示は、そのように選択された特定の用語に限定されることを意図しておらず、各特定の要素は、同様に動作する技術的相当物全てを含むことが理解されるべきである。実施され得る特定の実施形態は、例示および説明目的のために図示される。これらの実施形態は、当業者が実施形態を実施することを可能にするように充分に詳細に記載され、論理的変更、機械的変更および他の変更が実施形態の範囲から逸脱することなく可能であり得ることが理解されるべきである。よって、以下の詳細な説明は、制限的なものとしてとられるべきではない。図面中に例示される本発明の例示的実施形態の記載において、特定の用語が明確性のために用いられる。
【００２９】
本明細書中、派遣サービスおよび運輸サービスの提供のためのシステムおよび方法が記載される。当業者であれば、このような例示的実施形態のうち１つ以上が、多様なプログラムエンジン、プログラムモジュールあるいは他のハードウェアまたは１つ以上のルーチンまたは１つ以上のサブルーチンを含むソフトウェアコンポーネントを用いて実施され得、これらは、任意の適切な技術的手段上において個々にまたは組み合わされて利用および実施され得ることを理解する。
【００３０】
本明細書中に記載されるシステムおよび方法の多様なモジュールは、インターネットによりイネーブルされるモバイルデバイスのオペレーティングシステム上のインターフェーシングモバイルアプリケーション（ａｐｐ）（例えば、Ａｎｄｒｏｉｄ、ｉＯＳ、またはＷｉｎｄｏｗｓ  ＰｈｏｎｅＯＳ）を用いて部分的にかつウェブポータルインターフェースを用いて部分的に実行され得、また、異なる種類のユーザがシステムの異なる機能を用い得ることも理解される。このようなユーザまたは加入者は、例えば１人以上の「ドライバー（単数または複数）」または顧客を含み得る。本明細書中、「顧客（単数または複数）」は、任意の者（例えば、１人以上の個人、エンティティあるいはサービスをリクエストまたは注文したエンティティからの１人以上の個人）を含み得る。「顧客」は、運輸サービス、送達サービスまたは双方などのサービスの種類に関係無く、システムに登録されている任意の者を指し得、サービスをリクエストまたは注文したエンティティからの個人（単数または複数）を指し得る。顧客およびサービス提供者は、本明細書中に記載の方法およびシステムを同様に利用するため、サービスリクエストにおいて提供する役割に対応する特定のユーザ種類と呼ばれるのに加えて、双方とも主に「ユーザ（単数または複数）」と呼ばれ得る。少なくとも２種類のユーザ（すなわち、サービス提供者および顧客）がある。
【００３１】
本明細書中、「サービス」とは、３種類のサービス（すなわち、ライダーのための運輸サービス、物品の送達サービス、および運輸および送達双方のサービス）を指し得る。これらのサービスは、事前に計画してもよいし、あるいはオンデマンドでリクエストしてもよい。本明細書中、「オンデマンド」とは、リクエストされたときにリアルタイムでサービスが行われることをさらに意味する。「オンデマンド」という用語は、「事前に計画」という概念の対義語としてまたは将来の一定の時期（例えば、数時間後または数日後）に発生する意味として用いられる。オンデマンドサービスは即時的に行われる一方、事前に計画されたサービスは、将来の所定の時期、日付または所定の時間枠において行われる。さらに、「カスタマイズ」とは、サービスの性質を変更することであり、顧客の選好あるいはサービスに関与するサービス提供者の個人レベルの選好または制限を指す。サービスの種類に関係無く、本明細書中、「サービス提供者」とは、１人の個人（例えば、ドライバー）、人々のグループ、または民営事業エンティティ（例えば、運輸サービスまたは送達サービスまたは両方を提供するために呼び出され得る車両サービス企業）のアフィリエイトであり得る。サービス提供者のサービス提供能力は、サービス提供者が自由に使用できるツールに応じて異なる。例えば、顧客をどこかへ送り届ける場合、車両が必要になるが、送達サービスのリクエストは、車両だけでなく、徒歩や自転車によっても提供され得る。
【００３２】
本明細書中、「派遣担当者（単数または複数）」とは、サービスリクエスト（単数または複数）の管理および多様なスケジューリングおよび事前スケジューリング機能の操作を行う当事者を含み得る。本明細書中、「ベンダー」とは、ブローカーまたは他の事業エンティティ、官公庁、または顧客または乗客の代わりにサービスのブローカーとして機能する個人を指し得る。本明細書中の記載のように、異なる役割はそれぞれ、システムに登録されているかあるいはシステムと直接的または間接的に関連付けられた「ユーザ（単数または複数）」を特定的または包括的に指し得る。
【００３３】
任意の種類のサービスのリクエストとは、本開示全体において、「サービスリクエスト」または「行程（単数または複数）」を主に指す。本開示の例示的実施形態によれば、サービスリクエストは、顧客の選好（単数または複数）およびドライバーの選好および／または制限に基づいてドライバーへ割り当てられ、１つ以上の属性または先行行程に基づいて、優先順位が顧客を含む特定の行程について特定のドライバーへ付与される。「選好」という用語は、本明細書中で用いられるように、（特定のドライバー、ドライバーが使用する特定の車両、および関連する任意の属性について）顧客へ提供されるサービス全体に顧客が含めて欲しいと望む特定のサービスに関する多様な要素を指す。これらの選好は、サービスリクエストについての理想的または好ましい条件を示し得る。あるいは、このような選好は、サービスについての必要条件も示し得る。顧客は、自身の選好をモバイルデバイス上に設定し、これらの選好を任意の時点において更新することができるため、顧客にとって快適であり得、最後には、受けられるサービスの質に満足することができる。顧客は、１つ以上のこのような「選好」を有し得る。
【００３４】
本開示の例示的実施形態によれば、「制限」という用語は、ドライバーが提供するサービスにドライバーが課したいと思う任意の種類の制約を指し得る。これらの制限は、２つの広範なカテゴリ（すなわち、ドライバーが提供するサービスの時期、場所、方法およびサービス提供相手に関する個人的制限）を含み得る。このような個人的制限を挙げると、特定の地理的ゾーンではサービスを提供したくないというドライバーの意志に基づいた場所制限や、特定の時間帯においてサービスを提供したくないというドライバーの意志に基づいた時間制限がある。あるいは、特定の好適な実施形態において、ドライバーは、ドライバーのサービスを提供したいという望み（例えば、（特定地理的ゾーン内において）仕事を受けたいという選好）に基づいて１つ以上のプリセット場所選好を指定してもよい。このような実施形態において、ドライバーは、ドライバーがサービス提供を選好する地理的ゾーン内における特定の地理的ゾーン内においてはサービスを提供したくないまたは提供できないということに基づいて、自身の場所選好内における場所制限を指定してもよい。ドライバーが顧客へのサービス提供を行いたくない場合、サービス制限は、追加的にまたは代替的に時間または時間枠に関連し得る。このような時間を挙げると、１日のうちの複数の時間、週の内の数日、年間のうちの時期などがある。ドライバーは、場所および時間について「制限」を設定することもできる。例示目的のため、ドライバーは、１０ＰＭを超えた時間において特定の領域内においてサービス提供を行いたくないが、その時間を超えても他の領域内においてはサービス提供をしたい場合があり得る。このような実施形態において、ドライバーは、ドライバーがサービスリクエストを受けることを希望する期間を示す時間選好も指定し得る。ドライバーは、１つ以上のこのような「制限」および／または「選好」を有し得る。「選好」および「制限」という用語は、選好または制限を有する顧客またはドライバーのみに限定されることを意図しない。すなわち、「選好」および「制限」という用語は、例示的な対比を示すものとして意図される。
【００３５】
本発明の例示的実施形態によれば、複数の用語が、ドライバーと良好な関係を確立している顧客を指す際に用いられる。すなわち、「お気に入りの顧客」とは、ドライバーの「お気に入りの顧客リスト」に記載されている者を指す。顧客と良好な関係を確立しているドライバーは、「お気に入りのドライバー」（例えば、顧客の「お気に入りリストに記載されている者））と呼ばれる。本明細書中で用いられるように、「お気に入り」という用語は、広範に解釈されるものとして意図され、サービスリクエスト割当において優先される任意の顧客またはドライバー（例えば、「お気に入りリスト」上に記載されている者））を指す。当業者であれば、「お気に入りリスト」という概念は、例えば「友だち」、「トップ」、「優先」またはそのようなリストの概念を定義するためにドライバーまたは顧客によって用いられる他の任意の言葉であってもよいし、あるいはそのように呼ばれてもよいことを理解する。特定の用語に関係無く、最優先という意味は、ドライバー／顧客間のマッチングを包含する良好なドライバー／顧客関係の概念を示す。
【００３６】
「お気に入り」と対照的な意味として、ドライバーの「ブラックリスト」または顧客の「ブラックリスト」とは、本明細書中で用いられるように、ドライバーおよび顧客が将来マッチされる事態を回避することができる（例えば、サービスリクエスト処理から双方を排除する）リストを指す。当業者であれば、この概念を示す他の用語が用いられ得る（例えば、「ブロックリスト」、「禁止リスト」「嫌悪リスト」など）ことを理解する。特定の用語に関係無く、その意図は、ドライバーがサービスを提供したくない顧客またはドライバーが接触したくない顧客、およびサービス提供または接触をしたくないドライバーを排除するために顧客が用いる方法を示すことである。
【００３７】
追加的にまたは代替的に、顧客は、「好みの」ドライバーを有し得る。好みのドライバーとは、顧客のお気に入りリストに記載は無いが顧客の「選好リスト」に記載されるよう顧客から直接リクエストされたドライバーであるかまたはお気に入リストに記載されるよう顧客からリクエストされているがそのリクエストがドライバーによって承認されていないドライバーである。いずれの場合も、ドライバーが顧客のリクエストを拒否した場合、そのドライバーがその顧客のお気に入りリストまたは選好リストに付加されることは無く、逆の場合も然りである。そのため、好適な実施形態において、ドライバーおよび顧客双方が同意した場合、ドライバーおよび顧客はお気に入りリストに記載され、双方が直接リクエストした場合または当事者がお気に入りとしてリクエストしたが他方から応答が無い場合、選好リスト上に記載される。「選好」という用語は、本明細書中で用いられるように、事前に計画されたサービスリクエストの割当の際に顧客およびドライバーをマッチさせる目的のための、「お気に入り」よりも低いランキングを主に指す。ドライバーおよび顧客は、本明細書中さらに議論するようなこれらの分類においてさらに相互をランク付けし合い得る。下車場所が複雑である場合があり、例えば病院またはクリニックのようにレイアウトが分かりにくいまたは不明確である場合があり得る。これらの場所においては、どこが正しい入口なのか分かりにくい場合がある。そのため、この種の場所の場合、特定の経路をよく知っているドライバーにサービスリクエストを発信することが好ましい場合がある。特定の実施形態において、顧客のお気に入りのドライバーまたは好みのドライバーではないドライバーは全て、本明細書中「レギュラー」ドライバーと呼ばれる。この用語は、ドライバーが好みのドライバーではなく、お気に入りリストに付加されていないことを実質的に意味する。ドライバーに関連する特定の状態（すなわち、ドライバー種類）（例えば、「お気に入り」、「選好」または「レギュラー」）は常に相対的なものであることが理解される。或る顧客にとって好みであるドライバーが、別の顧客にとってお気に入りである場合があり得る。
【００３８】
本明細書中、「システム」という用語は、ポータブルコンピューティングデバイスを動作させるハードウェアおよびソフトウェアの組み合わせを通じた実行として言及される。ポータブルコンピューティングデバイスは、基本的コンポーネント（例を非限定的に挙げると、１つ以上のサーバ、データベース、モバイルエンドアプリケーション、ウェブポータル、ネットワーク設定など）と組み合わされかつ一体化される多様な事前プログラムされたフィーチャを含む。これらのコンポーネントのサポートにより、システムは、ユーザインターフェース（例えば、ウェブサイトまたはモバイルアプリケーション）を通じてサービスを提供する。加えて、本システムは、世界中のあらゆる場所に位置し得るデータセンターからのサポートにより分散型構造にされ得る１つよりも多くのサーバを有し得る。これらの実行様態は、通信可能な様態でリンクされ、クロスプラットフォーム型であり得るため、モバイルデバイス（例えば、スマートフォン、タブレットなど）上または据え付け型（例えば、デスクトップコンピュータなど）のユーザに、ユーザのサービスリクエスト（例えば、電子マップ表示、移動時間、経路、価格設定情報、プロファイル／設定情報などを示すインジケータなど）に関連する情報を提供することができる。「インジケータ」という用語は、本明細書中で用いられるように、顧客またはサービス提供者あるいは双方へサービス関連情報を簡単、迅速かつ簡便な様態で伝送または表示する手段を指す。
【００３９】
本明細書中に記載のシステムの多様な実施形態により、コンピューティングシステムを通じた運輸の事前スケジューリングが提供される。本明細書中に記載のコンピューティングシステムは、ハードウェアおよびソフトウェアの任意の組み合わせを含み得、例えば（基本的コンポーネントと組み合わされかつ一体化された多様な事前プログラムされたフィーチャへユーザがアクセスすることを可能にする）広域のパケット交換ネットワークを通じて複数のポータブルコンピューティングデバイスと通信し得る。このようなフィーチャおよびコンポーネントを非限定的に挙げると、通信フレームワーク／ネットワーク内の１つ以上のサーバ、データベース、モバイルエンドアプリケーション、ウェブポータル、ネットワーク設定などがある。 これらのコンポーネントのサポートにより、本明細書中に記載のシステムは、ユーザインターフェース（例えば、ウェブサイトまたはポータブルコンピューティングデバイス上のモバイルアプリケーション）を通じてサービスを提供する。これらのシステムは、世界中のあらゆる場所に位置し得るデータセンターからのサポートにより分散型構造として動作可能に配置された１つよりも多くのサーバも含み得る。
【００４０】
本明細書中に記載のシステムの特定の実施形態は、従来のコンピュータプログラムを用いたアプリケーションまたはアプリケーションを実行させるプログラム可能な装置に限定されない。例えば、本開示の実施形態は、光コンピュータ、量子コンピュータ、アナログコンピュータなどを含み得ることが企図される。
【００４１】
本明細書中のフローチャート中の各要素は、コンピュータにより実行される方法のステップまたはステップ群を示し、各ステップは、１つ以上のサブステップを含み得る。例示目的のため、これらのステップ（ならびに任意および他の全ての定義および記載のステップ）が、特定の論理順序において提示される。しかし、本明細書中に記載の任意の例示的実施形態は、本明細書中に開示される技術の特定の適用に適合された別の順序のステップを含み得、任意の変更および／または改変が本開示の範囲内に全て収まるものとして意図されることが理解される。任意の特定の順序のステップについて図示および記載するが、これは、特定の明示的に記載された用途において必要な場合または文脈から明確である場合を除いて、異なる順序のステップを有する実施形態を除外することを意図しない。
【００４２】
本明細書中に記載のシステムおよび方法は、以下に詳細に示される以下の図面を参照すれば、最良に理解される。先ず図１を参照して、例示的コンピューティングシステム１００と、本発明の多様な例示的実施形態と共に用いられる複数の周辺コンピューティングデバイスとの図が示される。ハードウェアおよびソフトウェアの組み合わせは、主にローカルエリアネットワーク（ＬＡＮ）インターフェース１２０を通じてローカルデバイスと共に採用された有線または無線の広域ネットワーク（ＷＡＮ）１２４（例えば、インターネット）への１つ以上の接続により、複数のコンピューティングデバイス１２８およびコンピューティングシステム１００上において動作する。コンピューティングデバイス１２８は、ソフトウェアを有する無線モバイルハードウェアデバイスであり得る。このソフトウェアは、他のモバイルデバイスまたはコンピュータシステムへの情報の通信と、地理的位置探知能力により（例えば、セルシステムの三角測量、ＧＰＳ、ユーザからの場所特定によるもの）による当該デバイスの場所の決定と、私的コンピュータネットワークまたは公衆回線（例えば、ネットワークを通じたインターネット）への接続とを行うことができる。
【００４３】
コンピューティングシステム１００は、例えば（中央処理装置（ＣＰＵ）１０４、メモリユニット１０６、データベース１０８、インターフェース１１０、通信手段１１２、表示ユニット１１４、１つ以上の入力デバイス１１６（例えば、キーボード、マウスなど）、ＬＡＮデータ送信コントローラ１１８、ＬＡＮインターフェース１２０、ネットワークコントローラ１２２、および内部バス１３８を含む）サーバ１０２を含み得る。図示のように、本システムは、データ保存デバイス（例えば、有線または無線のリンクを介して１つ以上のデータベース１０８を配置したハードディスク）へ接続され得る。中央コンピューティングシステム１００は、図１に示すサーバ１０２と同一または類似に構成された１つ以上のサーバまたは（異なるハードウェアまたはソフトウェアを配置し得る）異なる様態で構成された１つ以上のサーバを含み得る。例えば、コンピューティングシステム１００は、複数の空間中にホストされた複数のサーバ（例えば、データセンターまたはサーバファーム）を含み得る。
【００４４】
コンピューティングシステム１００は、通信手段１１２を通じて調整されたネットワークサービスと通信するように構成され得る。通信手段１１２は、１つ以上のネットワークを介したまたは１つ以上の周辺デバイスへのデータ通信のための任意のアプローチを含み得る。通信手段１１２を非限定的に挙げると、無線接続、有線接続、セルラー接続、データポート接続、ブルートゥース（登録商標）接続またはこれらの任意の組み合わせを提供するための回路および制御システムがあり、この手段は、このような通信アプローチを用いて通信するようにイネーブルされたデバイスを含み得る。当業者であれば、多数の通信アプローチが用いられ得ることを理解する。
【００４５】
サーバ１０２およびコンピューティングシステム１００は、通信手段１１２およびＷＡＮ１２４を通じて周辺デバイス（例えば、コンピューティングデバイス１２８、ベンダーデバイス１２６、管理者デバイス１３４、および派遣担当者デバイス１３６）へ通信可能な様態でリンクされ得る。コンピューティングデバイス１２８は、１つ以上の顧客コンピューティングデバイス１３０Ｃ１〜１３０Ｃｎまたはドライバーコンピューティングデバイス１３２Ｄ１〜１３２Ｄｎとして構成され得る。コンピューティングデバイス１２８は、ユーザ（例えば、顧客、ドライバーなど）とコンピューティングシステム１００との対話を可能にするデバイス（例えば、スマートフォン、スマートウォッチなど）であり得る。任意の数（例えば、１、２、３、…ｎ）のドライバーデバイス１３２Ｄ１…１３２Ｄｎまたは顧客デバイス１３０Ｃ１…１３０Ｃｎが、コンピューティングシステム１００と共に用いられ得る。
【００４６】
コンピューティングシステム１００は、世界中のあらゆる場所に位置し得るデータセンターからのサポートされた分散型構造内の１つよりも多くのサーバ１０２を有し得る。これらの実行様態は、通信可能な様態でリンクおよびクロスプラットフォームされ得るため、モバイルデバイス上のユーザに対し、サービスリクエスト関連情報（例えば、電子マップ表示、移動時間を表示するインジケータ、経路、価格設定情報、プロファイル情報、設定情報など）を提供することができる。本明細書中に記載のシステムの特徴は、プロセッサによる方法ステップの処理および出力を可能にするコンピューティングデバイスを通じて実行され得る。本発明の例示的実施形態によれば、サーバ１０２は、ユーザインターフェースを調整し、データベース１０８と対話する。各ユーザには、ユーザの役割および必要性に応じて異なる機能が提供され得る。
【００４７】
サーバ１０２は、顧客入力情報、場所情報およびサービスリクエスト情報をサーバインターフェースを通じて受信して、内容と、ドライバーからの情報（例えば、場所情報、制限情報、履歴情報など）とを構成し得る。上記したように、サーバ１０２は、サーバインターフェースを通じて情報を１つ以上のコンピューティングデバイスへ送信し得、情報は、コンピューティングデバイスのディスプレイへ出力され得る。このような内容を挙げると、（特にサービスリクエストのマッピングまたは経路設定について）特に関連する領域情報が存在する場合に領域固有のフィーチャがある。
【００４８】
サーバインターフェースを通じて受信されるサービスリクエスト情報は、データベース１０８中のコンピューティングシステム１００によって保存され得、例えば以下を含み得る：サービスリクエストの状態、ドライバーが受諾したサービスリクエストの状態、ドライバからのサービスリクエストをキャンセルする理由、割り当てられたサービスリクエストと関連付けられた履歴、派遣担当者の動作ログなどがある。通知の内容／時間スタンプおよび確認状態をシステムログ中に記録してもよく、この情報は、コンピューティングシステム１００の管理者によってチェックされ得る。これは、システムが記録し得る動作サービスリクエスト情報の網羅的なリストではないことが理解される。
【００４９】
コンピューティングシステム１００の１つ以上のデータベース１０８中に保存されたデータは、本明細書中に記載の全てのユーザ情報と共に連続的に更新され得、事前に計画された運輸サービスの効率的な予約および派遣を可能にするように、本明細書中に記載の多様な方法に従って分析され得る。特定の実施形態において、コンピューティングシステム１００が顧客、ドライバー、派遣担当者または他のユーザから入力／リクエストを入手するたびに、コンピューティングシステム１００は、先ずデータベース（単数または複数）／データベースセンターを用いて安全アクセスチャンネルを開いた後、クエリセンテンスをアクセスチャンネルを通じてデータベース管理モジュールへ送信し得る。関連データベースが用いられる場合、データテーブルは、一種の関係（例えば、他のデータテーブル（単数または複数）との一対多数関係、多数対多数関係、および一対一関係）を有し得る。データテーブル間の関係に基づいて、データベース（単数または複数）の管理モジュールは、クエリセンテンスに正確にフォローし得、２つ以上のデータテーブルの接合を含むかまたは含まないＩＤ（単数または複数）、テーブル名およびテーブルのカラム名を用いることにより特定のデータテーブル（単数または複数）を発見し得る。データテーブルの代わりに非関連データベースが用いられる場合、データをキーバリュー対中に保存した後、データベース管理モジュールは、クエリセンテンスを正確にフォローすることができ、クエリセンテンスから得られたキーを用いることにより、特定のデータを発見することができる。
【００５０】
コンピューティングシステム１００は、１つ以上のデータベース１０８中に保存される情報全てにアクセスすることができる。データベース（単数または複数）１０８を挙げると、規則および手順データ、ドライバーデータ、管理データ、グループデータ、顧客データ、マップコンポーネントデータ、およびコンピューティングシステム１００の実行様態に関連する他の任意のデータがある。規則および手順のデータを挙げると、システム価格、プロモーション設定規則および手順、ならびにインジケータ、紹介、支払い、サービスリクエスト、システム管理、システムログ、システム分析および最適化などに関する規則および手順がある。マップコンポーネントデータは、ＧＰＳおよびＬＢＳによって特定されたサービスリクエストについてのマップデータを保存し得る。ＧＰＳおよびＬＢＳデータにより、コンピューティングデバイスの場所を異なる方法で（例えば、場所ベースのリソースの受信を通じた方法）を決定することができる。ドライバーデータは、ドライバーのプロファイルを含み得る（例えば、個人的データ（例えば、ドライバーの写真およびドライバーの運転経験年数、性別、出身国、および言語能力））。
【００５１】
データベース１０８は、ドライバーの車両に関連するデータも含み得る（例えば、型式およびモデル、色、座席定員およびアクセシビリティ、保険状態、およびさらには車両の写真）。ドライバーのプロファイルさらなる情報を挙げると、ドライバーのお気に入りリストおよびブラックリスト、郵便番号、時間、場所、および価格に関連する制限、ならびにサービスデータおよび記録などがある。データベース１０８は、価格およびレートを含む管理データと、連絡先およびＦＡＱ情報などのシステムデータと、顧客およびドライバーに関する登録詳細とをさらに含み得る。例えば、データベース１０８は、請求先情報または（コンピューティングシステム１００のための管理オンデマンドサービスアプリケーションに関連する）他の情報を保存し得る。グループデータを挙げると、ベースデータ、会社データ、個人データのグループ、またはデータベンダー関連データがある。顧客データは、顧客のプロファイル（例えば、個人的データ、顧客のお気に入りのドライバーリスト、顧客のドライバーブラックリスト、顧客の選好、サービスリクエストデータおよび記録）を含み得る。当業者であれば、データベース１０８は動的に同期することができるため、データブロックの変更または更新が行われるたびに、サーバ１０２およびデータベース１０８はデータを相応に動的に更新して、最新の変更を反映させることができる。さらに、一次データベース１０８においてデータ紛失が有った場合、少なくとも１つのバックアップデータベースが、データベース１０８のうち一次の１つをバックアップするために用いられ得る。当業者であれば、データベース１０８のコンポーネントは、本明細書中に記載のものと異なり得ることを理解する。
【００５２】
あるいは、コンピューティングシステム１００は、顧客の選好および必要性に基づいて適合するドライバーを派遣するために事前に計画されたサービスアプリケーションを提供および維持するために、１組のデータベースまたはデータ保存媒体を用い得る。データベース１０８は、いくつかのデータカテゴリまたはグループ分けを含み得る。データベース１０８のセクションは、双方のセクションから同時に情報を取り出すように、独立し得るかまたは同期され得る。このようなデータを挙げると、規則および手順のデータ、管理データ、顧客データ、ドライバーデータ、ベースデータを含むグループデータ、会社のデータ、または個人のデータのグループ、および他の種類のデータ（例えば、ユーザ種類に関連するデータ）がある。本発明の例示的実施形態によれば、全ての履歴情報は、データベース１０８においてカテゴリー分けされおよび保存され得、データベース１０８から取り出され得る。コンピューティングシステム１００をサービスリクエストへ差し戻すことを支援するために、追跡番号、サービスＩＤ番号または各サービスリクエストに対応する行程ＩＤを割り当てることにより、履歴データを部分的に追跡することができる。この識別状態を用いてカテゴリー分けされた情報を挙げると、サービスリクエストの種類、リクエスト者およびリクエスト実行者、リクエスト発生場所（例えば、郵便番号、行政区、国、市町村、州）、前回の経路の詳細、サービスリクエストのコスト、サービス支払いが行われた時期および方法、および当事者がお気に入りリストまたはブラックリストへ付加されているかがある。顧客またはドライバーの選好または制限に関する全情報、価格設定、および他のカスタマイズ可能な情報をデータベース１０８内に保存することができる。
【００５３】
このような包括的データベース１０８は、管理データおよび他の情報を保存し得る。管理データは、事前に計画されたサービスアプリケーションの一部である任意の情報またはデータを含み得、システムデータを含む（例えば、連絡先およびＦＡＱ情報、顧客およびドライバー登録詳細（例えば、請求先情報）または事前に計画されたサービスアプリケーションの管理に関連する他の関連情報）。例示目的のため、登録詳細は、ユーザがシステムに登録してからの経過時間または事前に計画されたサービスアプリケーションのユーザの利用頻度を含み得る。管理データは、情報（例えば、異なる組織からの経路についての価格およびレート情報）を含み得る。他の保存された情報は、サービス規則、手順、および価格と、ドライバーの設定および顧客の設定の手順とを含み得る。
【００５４】
本発明の例示的実施形態によれば、完了したサービスリクエストの記録をデータベース１０８内に保存および維持することができる。コンピューティングシステム１００は、包括的データベース中の任意の完了したサービスリクエストについての履歴データの記録を自動的に保存することができる。データベース１０８は、サービスの予約および完了と共に動的に更新され得る。データベース１０８は、リクエストされている各サービスおよび完了した各サービスのインデックスを保存し得る（例えば、必要なときにいつでも参考のために取り出すことが可能な顧客およびドライバーの登録番号またはユーザ識別状態）。
【００５５】
データベース１０８中に保存されたサービスリクエスト情報を挙げると、例えば、サービスリクエストＩＤ、関連ドライバー情報、関連顧客情報、リクエストされたピックアップ場所、実際のピックアップ場所、リクエストされた下車場所、実際の下車場所、ピックアップ時刻、下車時刻、距離、継続時間、状態、価格、保険会社などがある。顧客がスマートフォンを持っていない場合またはシステムと通信しているアプリケーションを使用していない場合でも、システムへのアクセスを持たない顧客を迂回する方法が用いられ得るため、システムの機能に悪影響は無い。例えば、派遣担当者は、そのような顧客に対し、顧客のサービスリクエストまたはドライバーの場所について最新情報を伝達し得る。上記したスタートボタン機能によりドライバーを派遣担当者へバックエンドで瞬時に接続することができるため、派遣担当者は、顧客へ最新の情報を提供することができる。
【００５６】
関連サービス情報に含まれ得る情報を挙げると、例えば、車両ナンバー、名前、苗字、ユーザ名、ｅメール、パスワード、電話番号、生年月日、性別、出身国、運転経験、ドライバー種類（例えば、所有者−運転者）、アフィリエイト会社名、アフィリエイトベース名、ペット可、車椅子可、言語、署名、および一般的プロファイルがある。関連サービス情報にも、免許交付情報が含まれ得る（例えば、ライセンス番号、ライセンスクラス、ライセンス状態、ライセンス発行、ライセンス有効期限、ＦＨＶライセンス番号、ＦＨＶライセンス発行日、およびＦＨＶライセンス有効期限）、運転記録情報（例えば、運転記録開始日および運転記録有効期限日）、車両情報（登録状況、登録状態、登録開始日／終了日、モデル年、ブランド、モデル、ＶＩＮ、車載種別、プレートナンバー、ＦＨＶ登録開始／終了日、ＦＨＶライセンス番号、およびＦＨＶライセンス）、ならびに保険および点検情報（負債状態、保険状態、保険提供者、保険開始日、保険終了日、車両点検、および車両点検終了日）。
【００５７】
包括的データベース１０８は、各特定のドライバーについてのサービスリクエストの詳細も詳細の参照のために保存し得る。データベース１０８は、ドライバーの車両についてのデータを含み得る（例えば、車両種別、モデル、色、座席定員およびアクセシビリティ、保険状態およびさらには車両の写真）。ドライバーのプロファイルに含まれるさらなる情報を挙げると、ドライバーのお気に入りリストおよびブラックリスト、選好および制約（例えば、郵便番号、時間または場所の制限、およびサービスデータおよび記録）がある。
【００５８】
データベース１０８に関連する任意のバックアップデータベースを、最新の変更を反映するように相応に更新することができる。特定の実施形態において、このような情報は、有効なソーティングおよび検索が可能なように編成または構築され得る。情報は、非関連または非構造的な様態で保存され得る。当業者であれば、本明細書中に記載の本発明の例示的実施形態に従って、データベース１０８または他のデータ保存媒体中のデータの提供、ソートおよび編成を行うための多数の方法を用いることが可能であることを理解する。さらに、一次データベースからの任意のデータ損失時において一次データベースを頻繁にバックアップする少なくとも１つのバックアップデータベースが用いられ得ることが理解される。
【００５９】
データベース（単数または複数）に保存された情報を用いて、（さらに以下に述べる）多様なインジケータを事前に計画されたサービスシステム１００内に生成することができる。インジケータに関連するアイコン、形状、または他の図解をデータベース１０８に保存することができる。データベース１０８中における検索および分析の結果と、アイコン、形状または他の図解割当規則とに基づいて、アイコン、形状または他の図解を他のインジケータと共に顧客、ドライバーおよび派遣担当者に対して相応に表示することができる。データベース１０８中に保存された顧客およびドライバーについて維持された情報を用いて、事前に計画されたサービスシステム１００は、（自身と動作可能に関連付けられた）任意の事前に計画されたサービスアプリケーションへ関連情報を提供し得る。ドライバー情報は、利用可能なドライバー自身についての情報（例えば、ドライバーについてのプロファイル情報、車両の現在の場所または動き、あるいは顧客からの特定の距離またはピックアップまでにかかる推定時間）に対応し得る。
【００６０】
コンピューティングシステム１００は、適合するドライバーを顧客の選好および必要性に基づいて派遣するために事前に計画されたサービスアプリケーションを提供および維持するための１組のデータベース１０８またはデータ保存媒体も用い得る。データベース１０８は、いくつかのデータカテゴリまたはグループ分けを含み得る。データベース１０８のセクションは、双方のセクションから同時に検索するために独立するかまたは同期され得る。本明細書中に記載のように、このようなデータは、規則および手順データ、管理データ、顧客データ、ドライバーデータ、グループデータ（例えば、ベースデータ、会社のデータ、個人のデータのグループ、および他の種類のデータ（例えば、ユーザ種別に関連するデータ））を含み得る。本発明の例示的実施形態によれば、データベース１０８中の全履歴情報がカテゴリー分けされ得、データベース１０８において保存および検索され得る。履歴データが、追跡番号、サービスＩＤ番号または（疑義の有る際にコンピューティングシステム１００がサービスリクエストを再度参照するすることを支援するために各サービスリクエストへ割り当てられた）行程ＩＤ番号の割当により、部分的に追跡され得る。保存された情報を挙げると、リクエストされたかまたは提供されたサービスリクエストの種別、情報をリクエストした者および実行者、サービスの実行場所（例えば、郵便番号、行政区または国、市町村または州）、用いられた経路、サービスリクエストコスト額、サービス支払いが行われた時期および方法、および当事者がお気に入りリストまたはブラックリストへ付加されているかがある。顧客またはドライバーの選好または制限、価格設定に関する全情報および他のカスタマイズ可能な情報が、コンピューティングシステム１００のデータベース１０８内に保存され得る。
【００６１】
さらに、特定のデータ（例えば、サービスリクエストの時期およびサービスリクエストの価格）が、顧客がサービス予約時に公平な価格を受けることができるように当該顧客について平均価格を発見するための基準として用いられ得る。データベース１０８へ入力および保存されたデータについて、連続的な照合が行われ得る。包括的データベース１０８を維持することにより、顧客またはドライバーにとって争議になり得るサービスリクエストの正確な追跡も可能になり得る。任意のクレームをタイムリーに解決することができるよう、サービスリクエスト記録は、データベース１０８から効率的に検索され得る。
【００６２】
さらなるデータが、データベース１０８へ入力され得る（例を非限定的に挙げると、顧客の移動先の場所、お気に入りリストまたはブラックリスト、場所、他の取引データおよび詳細、履歴データ、保険契約の有効期限日、点検日、ドライバーのライセンスの有効期限日、またはこれらの任意の組み合わせ）。このデータは、インジケータおよびその表示に関連する情報も含み得る。例示目的のため、データを挙げると、全顧客または全ドライバーが特定の領域（例えば、１つ以上の通り、郵便番号、町、市町村、行政区、国、州、またはフィーチャを規定する他の任意の領域）を完了したサービスリクエストまたはコンピューティングシステム１００によって顧客およびドライバーがペアにされた回数がある。
【００６３】
コンピューティングシステム１００によって用いられるコンピュータプログラム命令は、コンピュータにより実行可能なコードを含み得ることが理解される。コンピュータプログラム命令を表現するための多様な言語が可能である（例を非限定的に挙げると、Ｃ、Ｃ＋＋、Ｊａｖａ(登録商標)、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｙｔｈｏｎ、アセンブリ言語、Ｌｉｓｐなど）。解決すべき技術的課題が有る場合、顧客およびドライバーに合った具体的かつ個別対応のサービスの提供のために、特定の論理関数を実行する必要があり得る。これらの論理関数は、多様な選好および制約に対応するように事前プログラムされ得、特定のｉｆ−ｔｈｅｎシナリオを実行するのには過度に複雑である場合がある。特定のパラメータを特定する規則が確立され得る。このようにして、多数の複雑な条件を考慮することができ、これらのフィルタに基づいたチェーニング論理関数によりドライバーおよび顧客をフィルタリングすることができる。多様な言語フィーチャを、プログラミング言語（例えば、Ｊａｖａ（登録商標））を通じて利用、プログラムおよび実行することができる。このような言語を挙げると、アセンブリ言語、ハードウェア記述言語、データベースプログラミング言語、機能プログラミング言語、命令型プログラミング言語などがある。特定の実施形態において、コンピュータ、プログラム可能なデータ処理装置、プロセッサまたはプロセッサアーキテクチャの異種の組み合わせなどを実行するように、コンピュータプログラム命令を保存、コンパイルまたは解釈することができる。
【００６４】
ここで図２を参照して、コンピューティングデバイス１２８例示的実施形態の多様なコンポーネントが図示される。上記したように、コンピューティングデバイス１２８は、顧客によって（例えば、デバイス１３０Ｃ１…１３０Ｃｎを介して）またはドライバーによって（例えば、デバイス１３２Ｄ１…１３２Ｄｎを介して）または双方によって用いられ得、コンピューティングシステム１００の多様な有形または無形のコンポーネントと通信し得る。コンピューティングデバイス１２８は、多様な内部デバイス２００および外部デバイス２０２を含み得、例えばＷＡＮ１２４を介してコンピューティングシステム１００と接続するための声、テキストおよびデータを受信するモバイル通信デバイス２２０と、現在の場所についての識別状態についての場所識別子２０４（例えば、全地球測位システム（ＧＰＳ）受信器）とを用い得る。アプリケーション、マップコンポーネント、マップデータ、および場所識別子２０４（例えば、ＧＰＳモジュールまたは場所に基づいたサービス（ＬＢＳ）データを提供するための他の回路）が、特定の場所の識別情報機能のために、１つ以上のコンピューティングデバイス１２８と一体化され得る。場所識別子２０４により、コンピューティングデバイス１２８の場所が異なる様態で（例えば、場所に基づいたリソースの受信を通じて）特定され得る。当業者であれば、場所の識別情報および場所に基づいたサービスの提供のための多数のアプローチが存在することを理解する。ＧＰＳによってイネーブルされたシステムまたはデバイスにより、コンピューティングデバイス１２８の場所をコンポーネントが追跡することが可能になる。例えば、場所識別子２０４は、コンピューティングデバイス１２８の場所に基づいたリソースまたは位置認識型リソースから処理受信されたＧＰＳデータを通じてインスタンス生成され得る。さらに、場所識別子２０４は、１つ以上のアプリケーションプログラムインターフェース（ＡＰＩ）を用いてコンピューティングデバイス上において動作する他のアプリケーションまたはプログラムからＧＰＳデータを受信し得る。アプリケーションは、場所情報を用いて、ユーザインターフェースコンポーネントにユーザインターフェースフレームワークを構成させ得る。
【００６５】
好適な実施形態において、顧客は、顧客モジュールへアクセスし得る（例えば、（行程詳細（例えば、ピックアップおよび下車場所ならびに所望のピックアップおよび下車時刻）を含む）サービスリクエストを入力するためにコンピューティングシステム１００と動作可能に関連付けられたコンピューティングデバイス１２８）。しかし、任意のエンティティが（例えば、場所識別子２０４から受信された（１人以上のドライバーの場所および／またはデータベース１０８中のドライバー制限について）データに基づいて）システムと適合するとみなされるサービスをリクエストした場合、派遣担当者に通知が送られ得る。
【００６６】
コンピューティングシステム１００は、サービスリクエストにおいて指定された顧客ピックアップ場所から特定の距離（例えば、１〜２マイル）にある領域内にドライバーが入った場合、顧客デバイス１３０へ通知を生成するように構成され得る。このような場所に基づいたサービスが、ドライバーデバイス１３２Ｄ１…１３２Ｄｎ中の場所識別子２０４によって促進されることにより、二地点間の方向に基づいたドライバーの経路設定を効率的に行うことが可能になる。ドライバーデバイス１３２Ｄ１…１３２Ｄｎはそれぞれ、場所識別子２０４によって収集された場所情報を提供するインターフェースコンポーネントを含み得、このような場所情報を顧客デバイス１３０Ｃ１…１３０Ｃｎ上のインターフェースコンポーネントへＷＡＮ１２４およびサーバ１０２を介して送り得る。ドライバーデバイス１３２Ｄ１…１３２Ｄｎは、ドライバーがが自身の車両にいるかまたは自身の車両から離れているときにシステムに警告を出すように、無線周波数認識情報（ＲＦＩＤ）技術あるいは他の類似の識別状態デバイスまたは手段も含み得る。
【００６７】
場所識別子２０４は、ＧＰＳによってイネーブルされたシステムまたはデバイスを含み得る。このシステムまたはデバイスは、サービスリクエストを作成している顧客およびサービスを提供しようとしているドライバーの場所を特定する追跡コンポーネントを含む。コンピューティングシステム１００は、アプリケーションマネージャを含み得る。アプリケーションマネージャは、顧客の現在の場所またはサービス場所に基づいて、領域固有の顧客インターフェースフィーチャを表示装置２１２上の顧客インターフェースコンポーネントから出力させる。顧客固有の領域は、顧客がサービスを事前スケジュールすることを望む顧客の現在の場所またはサービス場所を含み得る。領域は、コンピューティングデバイス１２８が現在配置されている郵便番号、市町村名、都市圏名などによって特定され得、顧客の現在の場所から特定の距離または半径（例えば、１マイル、５マイルなど）の場所にある領域であってもよいし、あるいは、他の領域から特定に区分された領域であってもよい。事前に計画されたサービスについての領域固有の情報が、ドライバー場所データ３２４（図３）を供給するシステムによって部分的に提供され得る。場所に関連する選好または制限の利用は、ＧＰＳによってイネーブルされたデバイスに部分的に依存し得ることが理解される。データを相互参照することにより、本明細書中に記載の事前に計画されたサービスシステムは、特定された場所の近位かつ／または特定された場所に配置された特定の場所（例えば、店舗、レストラン、団地、予定地、通りの住所、など）を特定することができ、この特定の場所情報を場所データとして（例えば、トラフィックおよびマップデータ３２６の一部として）提供することができる。
【００６８】
プロセッサ２０６が、好適にはコンピューティングデバイス１２８上のソフトウェアまたは１組の命令の実行のために提供される。コンピューティングデバイス１２８は、記憶装置２０８（例えば、ランダムアクセスメモリ（ＲＡＭ）またはフラッシュ記憶装置）も含み得る。入力／出力（Ｉ／Ｏ）デバイス２１０は、コンピューティングデバイス１２８の利用可能な機能に応じてコンピューティングデバイス１２８を他のシステム機器へ接続させるために用いられ得る。例えば、ドライバーは、（カメラを持たない場合がある）車載ナビゲーションシステムを用い得る。スマートフォンに内蔵カメラが含まれる場合もある。この状況において、カメラは、車載ナビゲーションシステムの入力として含まれ得る。他のＩ／Ｏデバイス２１０を挙げると、スキャナ、マイクロフォンおよび／またはスピーカがある。コンピューティングデバイス１２８は、ユーザ通知および／またはコンピューティングシステム１００から受信された他のデータの受信および表示を行う表示装置２１２も含み得る。表示装置２１２は、例えば、本発明の多様な方法に従ってユーザインターフェース２１４を提供するように構成された電子タッチスクリーンディスプレイであり得る。コンピューティングデバイス１２８は、現在時刻を決定する内部クロック機構２１６も用い得る。速度、加速、方向変化などを測定するための加速度計または速度計２１８を、コンピューティングデバイス１２８の一部としてかつ／またはコンピューティングデバイス１２８と通信した様態で設けてもよい。
【００６９】
ユーザインターフェース２１４は、ユーザの選択および選好に基づいて、多様な内容を表示する。コンピューティングデバイス１２８の１つ以上のコンポーネントを組み合わせることにより、ユーザ選択およびユーザ場所特有のユーザフィーチャを提供することができることが理解される。これらの選択はユーザへ表示され得、ユーザは、ユーザインターフェース２１４を用いて、識別状態の表示と対話することができる。例えば、ユーザインターフェース２１４は、スマートフォンまたは他のポータブルコンピュータデバイス（例えば、タブレットコンピュータまたはパーソナル情報端末（ＰＤＡ））へダウンロードされたプログラムに対応し得る。ユーザは、アプリケーションを１つ以上のコンピューティングデバイス１２８上にダウンロードおよびインストールし、システムに登録し得る。特定の実施形態において、コンピューティングデバイス１２８の事前プログラムされたフィーチャは、基本的コンポーネント（例えば、サーバ、データベース１０８、モバイルエンドアプリケーション、ウェブポータル、ネットワーク設定など）の統合の特定のプロトコルまたは方法に基づいて用いられる。アプリケーションは、Ａｎｄｒｏｉｄ（Ｇｏｏｇｌｅによって開発されたモバイルプラットフォームおよびオープンハンドセットアライアンス）、ＩＯＳ（Ａｐｐｌｅ社によって開発されたモバイルプラットフォーム）、Ｗｉｎｄｏｗｓ  Ｐｈｏｎｅ（Ｍｉｃｒｏｓｏｆｔ社によって開発されたモバイルプラットフォーム）向けに書かれたアプリケーションなどであり得る。
【００７０】
活動追跡目的のために、全ての種類のユーザがシステム中に登録および入力され得る。登録は、例えばユーザＩＤが入力されたときにのみシステム機能へのアクセスが可能となるようにユーザＩＤを各ユーザへ割り当てる手段を通じて行われ得る。さらに、システムへのアクセス時にユーザが用いたデバイスが、ＩＰアドレスによって追跡され得、システム活動が時間スタンプまたは類似の手段によって追跡され得、データベース１０８中に保存され得る。このようにして、システム管理者は、システムにアクセスしている者を追跡するだけでなく、アクセス元であるデバイス、デバイスの場所および当該アクセスの時期も追跡することができる。このような能力により、派遣担当者は、活動を追跡することができ、エラーが発生した場合（例えば、サービスリクエスト時に誤ったアドレスが入力された場合）、当該エラーの原因を容易に診断し、原因に対処することができる。業界における現在の欠点として、（派遣担当者がエラーを認めたがらない場合に特に）このようなエラーの検出および発見が不可能である点がある、このような機能により、セキュリティ向上に繋がることが理解される。不正なコンピュータから入力された任意のサービスリクエストを無視することができる。コンピューティングデバイス１２８に対してアクセス許可が付与されていない限り、コンピューティングデバイス１２８は、登録されたユーザへ制限された特定の機能にアクセスすることはできない。人間の判断を要する例外的状況が発生し得るため、派遣システムを派遣担当者によって部分的に実行させることにより、必要に応じて柔軟性および執行機能を拡大させることが可能になる。
【００７１】
本発明の例示的実施形態によれば、ユーザインターフェース２１４は、例えば、ホームページ、（ドライバー向けの）派遣ポータルへのアクセス、（顧客向けの）サービスリクエストモジュール、データベース１０８に対するアクセスインターフェース、または本明細書中に記載の特徴のうちいずれかのうち１つまたは組み合わせへユーザがアクセスする方法であり得る。システムは、ユーザの情報およびデータベース１０８に保存された他のデータを検索し得る。このような情報およびデータは、ローカルにかつ／またはリモートに提供され得る。当業者であれば、多数のさらなるユーザインターフェースがユーザインターフェース２１４と共にまたはユーザインターフェース２１４の代替として利用および企図され得ることを理解する。
【００７２】
顧客デバイス１３０Ｃ１…１３０Ｃｎはそれぞれ、地理的情報を示すマップ上に多様なインジケータを表示するための顧客インターフェースを利用し得る。各インジケータは、例えば異なる顧客情報またはコンピューティングシステム１００が顧客から受けた顧客入力、ベンダーまたは事前に計画されたサービスリクエスト３００を顧客から受けた任意のアプリケーションを意味し得る。顧客デバイス１３０Ｃ１…１３０Ｃｎはそれぞれ、顧客入力を介して提供された顧客選択に基づいて、内容を動的に同期させるように適合されたアプリケーションフィーチャも含み得る。
【００７３】
顧客コンピューティングデバイス１３０Ｃ１…１３０Ｃｎ上のユーザインターフェース２１４を非限定的に挙げると、ホームページ顧客インターフェース、サービスリクエストの詳細を特定するために顧客のために用いられるサービスリクエストパネル、選好詳細など、要旨顧客インターフェース、場所検索顧客インターフェース、確認ページインターフェース、またはこれらの特徴のうち任意の組み合わせがある。例示目的のため、顧客の現在の場所が元々のリクエストされたピックアップ場所と異なる場合、顧客は、コンピューティングデバイス１２８またはコンピューティングシステム１００中に保存された現在の場所と異なる新規のピックアップ場所を手動で事前スケジュールすることができる。
【００７４】
スタートボタン機能は、例えばドライバーデバイス１３２Ｄ１…１３２Ｄｎのうち１つ以上の上のコンピューティングデバイス１２８の一部として設けられ得る。１つ以上のモバイルドライバーデバイス１３２Ｄ１…１３２Ｄｎのディスプレイは、待ち行列中の次の行程から開始する行程待ち行列についての関連情報をドライバーへ表示し得、行程待ち行列において、当該行程の詳細が表示される（例えば、ピックアップ場所およびピックアップ時刻ならびに目的地およびスケジュールされた下車時刻）。次に、ドライバーは、（例えば、物理的押しボタンまたはドライバーデバイス１３２Ｄ上のタッチスクリーンインターフェースを介して）「スタート」をクリックして行程を開始し、行程途中である旨を派遣または管理者へ知らせる。モバイルデバイス上のディスプレイは、待ち行列中の残りの行程のリストも限られた詳細と共に表示し得る。これらの限られた詳細は、後で拡張または視認することができる。派遣担当者は、現在進行中のサービスリクエストを容易に特定することができるため、このスタートボタン機能により、多様なパーティ間の通信の現在の欠陥に対処することが支援される。さらに、第２のレッグをスケジュールした顧客がドライバーに関連アポイントメントの状態を知らせることを可能にする手段も得られる。従来の電話によって実行された派遣システムの場合、ドライバーの現在の場所および第２のレッグ顧客の状態が不明である場合がある。そのため、派遣担当者は、サービスリクエストの調整時にドライバーまたは顧客に容易に連絡することができない場合、当てずっぽうで進めていくしかなくなる。ドライバーがサービスリクエストの各レッグの開始時にスタートボタンを押圧すると、システムは、この状態をデータベース１０８中に記録し得る。このような機能により、サービスリクエストのレッグが１人よりも多くのドライバーによって取り扱われる場合、追跡もより容易になる。
【００７５】
本明細書中に開示されるシステムおよび方法により、従来の派遣サービス方法よりもずっと円滑でありかつより全般的に効率的なプロセスを可能にする機能が得られる。スタートボタンが押圧されると、派遣バックエンドシステムに影響を与える一連のイベントがトリガされ得、これら一連のイベントは、多様なソフトウェアおよびハードウェア実行の支援によって実行され得る。スタートボタンが押圧されると、例えば、ドライバーの場所がサードパーティマッピングおよびナビゲーションサービス（例えば、Ｗａｚｅ）へリレーされ得、これにより、ドライバーの現在の速度および各経路と関連付けられた距離に基づいて多様な経路設定オプションおよびドライバーのＥＴＡが各経路について構成され得る。この情報は、派遣、顧客へリレーされ得、ドライバーへ返送され得、リアルタイムで提供され得る。
【００７６】
特定の実施形態において、ユーザインターフェースは、スタートボタンを含み得る。スタートボタンにより、データ保存について一連のイベントがデータベース１０８内においてトリガされ、ドライバーのジオロケーションが、サービスリクエスト、顧客、ドライバーなどと関連付けられた記録の一部として場所識別子２０４によって追跡される。このスタートボタン機能無しでは、ＧＰＳデバイスは、ドライバーの現在の場所および進行方向を検出することができる。しかし、事前に計画されたサービスを提供する場合、ドライバーは、スケジュールされた行程の長いリストを有し、ドライバーが特定の顧客をピックアップする途中であることを実際に確認しないことには、ドライバーが進行してい行っているようにみえる場所が顧客のピックアップ場所であるかを確認する方法は無い。その結果、スタートボタンは、派遣担当者および他のパーティに対してドライバーのリアルタイム状態を瞬時に更新できる強力な機能である。
【００７７】
他の機能は、ＮＥＭＴ（非緊急医療輸送）において利用され得る（例えば、クリニック側においてユーザへ提供される機能）。クリニック運転者（例えば、クリニックの従業員）は、クリニックとアフィリエイトされたアポイントメントを管理（例えば、検索／追加／削除／変更）することができ得、スタートボタン機能を用いることにより、クリニックの他の従業員および顧客に対して任意の変更を通知することができる。例えば、クリニック運転者または顧客は、自身のそばにあるスタートボタンを押圧することにより、アポイントメントが開始した旨を他のユーザに通知することができ得る。例えば、アポイントメントがスケジュールよりも遅く開始した場合、システムは、任意の必要な変更を行うことができ得る（例えば、アポイントメントを異なる時間にずらすことまたはその変更によりアポイントメントが受ける影響を顧客に通知すること）。さらに、特定の実施形態において、アポイントメントの終了時において顧客をピックアップするよう割り当てられたドライバーは、顧客の状態についてのリアルタイム通知（例えば、「チェックイン」、「通院中」、「もうすぐ終了」、「終了」）を入手し得る。これにより、ドライバーは、スケジュールされたピックアップ時刻において任意の変更に対して備えることができる。
【００７８】
顧客デバイス１３０Ｃ１…１３０Ｃｎは、顧客が（住所（例えば、通りの番号、通りの名称、市町村、州など）の入力またはサービス場所のグラフィック／アイコンを顧客インターフェースの一部の上の電子マップ表示上へ操作および移動させることにより）需要場所入力を手入力することを可能にするように構成され得る。このような顧客選択に応答して、顧客デバイス１３０Ｃ１…１３０Ｃｎのうち１つ以上の上において実行される事前に計画されたサービスアプリケーションから、場所データがコンピューティングシステム１００へ提供され得る。
【００７９】
スタートボタンが噛み合わされ後、コンピューティングシステム１００は、推定到着時刻（ＥＴＡ）を計算し得る。可能性のあるジョブがこのインターフェースを通じてドライバーへ提供され得、行程の派遣についてクエリが一時的に表示され得る。ドライバーモジュールにより、モバイルデバイス上のインターフェースが車両内にいるドライバーを示すことが促進され得る。顧客が行程を署名して受け取ることができない場合、コンピューティングシステム１００は、顧客にドライバーの電話を使って署名してもらうことについて、ドライバーに依存し得る。
【００８０】
好適な実施形態において、システム１００は、サービスリクエストの開始前または開始時において、サービスリクエストの任意の変更またはサービスリクエストの状態の更新情報について動的に更新および保存し、これらの変更を（派遣担当者向けのウェブポータルおよびサービスリクエストが割り当てられたドライバーと関連付けられたドライバーデバイス１３２上のドライバーインターフェース双方において）リアルタイムで表示する。例えば、顧客がサービスリクエストをキャンセルした場合またはピックアップ時刻または場所を変更する必要がある場合、顧客は、この情報を顧客デバイス１３０を介してシステム１００へ入力し得る。この新規の情報は、データベース１０８中に保存される。派遣担当者のウェブポータルが更新され、この変更の通知がサービスリクエストと関連付けられたドライバーへドライバーデバイス１３２を介して迅速に送られる。次に、ドライバーは好適には、派遣担当者のウェブポータル内に表示されたサービスリクエストについての情報と同じ情報にアクセスすることができる。さらに、好適な実施形態において、サービスリクエストに先行して入力された顧客についての任意の新規情報（例えば、電話番号、ｅメールアドレス、選好の変更など）を派遣担当者のウェブポータルおよびサービスリクエストが割り当てられたドライバーデバイス１３２のユーザインターフェースへ通信することができる。好適には、関連するドライバーデバイスのみが、新規の顧客情報について更新される（例えば、顧客のサービスリクエストに関与するドライバーと関連付けられたドライバーデバイス）。
【００８１】
ドライバーが各行程またはサービスリクエストのレッグの開始時にスタートボタンを押圧すると、行程状態が、派遣担当者のウェブポータルおよび顧客の顧客デバイス１３０内において更新され得る。よって、顧客は、自身のドライバーの推定到着時刻を先に視認することができることが理解される。このような機能により、派遣担当者は、サービス変更についての通話に対応する必要もなくまたドライバーに電話する必要も無いため、派遣担当者の作業負荷が低減または除去される。
【００８２】
当業者であれば、これらの例はひとえに例示であり、ドライバーのインターフェースの他の機能が利用可能であることを理解する。
【００８３】
外部デバイス２０２（すなわち、さらなるモバイルデバイス、タブレット、ラップトップまたは他のコンピューティングデバイス）は、有線または無線の接続を通じてコンピューティングデバイス１２８へ接続し得る。これらの外部デバイス２０２は、コンピューティングデバイス１２８がモバイルデバイス（例えば、タブレットまたはスマートフォン、車載ナビゲーションシステム、または別の種類のコンピューティングデバイス）であるかに関係無く、さらなる機能または向上した機能をコンピューティングデバイス１２８へ提供することができる任意のデバイスを含み得ることが理解される。
【００８４】
コンピューティングシステム１００は、多様な業界（例えば、ＮＥＭＴ業界）に特有の異なる機能を統合し得ることが理解される。ＮＥＭＴ業界においては、住所が指定された２つの場所の間において極めて具体的な日時におけるサービス提供をリクエストしたブローカーからサービスリクエストを受け取ることが従来から慣行になっている。当然のことではあるが、これらの特有の規定は、詐欺と戦うことおよびサービスリクエストが適切に完了したことを確認することを意味する。しかし、この業界のドライバーにとっては、正確なタイミングおよび指定された住所を固守することは必ずしも容易ではない。予期せぬ渋滞または工事が有る場合、ドライバーが定刻通りにピックアップ場所および下車場所双方に到着できなくなる。リクエストされた通りの正確な住所において顧客を降車させることは、駐車規制、ピックアップ規則および下車規則、駐停車禁止または他の適用可能な法律または罰金に起因して不可能である場合がある。その場合、ドライバーは、停止および下車が適切かつ適法である場所において一定期間にわたって待機するかまたはブロックを隔てた先または角において下車を完了させる必要があり得る。
【００８５】
特定の実施形態において、本明細書中に開示されるシステムおよび方法は、米国特許出願シリアル番号第１５／４７４，６８５号（出願日：２０１７年３月３０日、タイトル：「Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  Ｆｏｒ  Ｇｅｏ−Ａｗａｒｅ  Ｔｒａｎｓｐｏｒｔａｔｉｏｎ  Ｂｉｌｌｉｎｇ  Ｖｅｒｉｆｉｃａｔｉｏｎ」）に開示されるシステムおよび方法と共に用いられ得る。本明細書中、同文献全体を参考のため援用する。場所識別子２０４を用いてドライバーのジオロケーションを追跡することおよび（ピックアップまたは下車場所およびタイミングが所定の受容性範囲内（例えば、指定された住所から１５０フィート以内または１５分間の時間枠内）に確実に来るように）ピックアップまたは下車時に時間スタンプを割り当てることにより、これらの請求調整の善意の性質を確認することができる。サービスリクエストがこのような所定の受容性範囲から外れた場合、このような逸脱の理由の調査のために照会が行われ得る。このようにして、請求先の事務員が貴重な時間を節約することができ、ドライバーが罰金を受ける危険性が無くなり、ブローカーは、自身が予約したサービスリクエストが誠実に完了したことを知ることができる。
【００８６】
ここで図３を参照して、派遣システムに対し、大量のサービスリクエストの受領、編成、調整および派遣が割り当てられることが理解される。各ドライバーに対して顧客を公正かつ効率的に事前スケジューリングすることは、困難であり得る。サービスを事前に計画する際、顧客は、派遣されるドライバーを選択する際の選好について要求する場合がある。例えば、スペイン語を話す顧客の場合、スペイン語を話せないドライバーに不満を持つ場合がある。本発明は、顧客の選好に基づいてサービスリクエストをソートし得、多様な要素に基づいて特定のドライバーに対して優先順位を付与し得る。
【００８７】
図３は、本発明の多様な実施形態による、例示的派遣マトリックスを用いた例示的派遣動作を示す図である。図示されるのは、コンピューティングシステム１００の動作の例示的実施形態であり、サービスリクエスト３００が受容され、派遣マトリックス３２２に基づいてドライバーが派遣されて、サービスリクエスト３００が完了する。受容されたサービスリクエスト３００からの情報は、顧客デバイス１３０Ｃ１…１３０Ｃｎのうちの１人から（または顧客の代わりのベンダーがベンダーデバイス１２６を通じて）顧客から提出され得、生成された派遣マトリックス３２２に含まれる。顧客は、サービスリクエスト３００の入力または提出を従来の電話を用いて入力することもできることが理解される。
【００８８】
特定の顧客またはベンダーがサービスリクエスト３００を提出すると、プロセッサ１０４は、特定の顧客の情報３０２に関連してデータベース１０８からの関連データを検索せよとの命令を実行する。データは好適には、データベース１０８中にカテゴリー的に保存され得、動的に更新されて、最新の情報が事前スケジューリングプロセスにおいて確実に用いられる。
【００８９】
顧客情報３０２は、顧客と関連付けられた任意の情報を含み得る（例えば、顧客の運輸の必要性、１つ以上の顧客選好、顧客のお気に入りリスト、顧客のブラックリスト、顧客連絡先情報、顧客請求先情報）。顧客情報３０２は、顧客の自宅住所、顧客の事業場所、顧客の選好、履歴情報（例えば、顧客がサービスをリクエストした前回の場所についての情報、お勧めの特定地点など）も含み得る。顧客がお勧めの特定地点の入力から１つを現在の場所および／またはピックアップ場所として選択すると、システムは、多様な種類の履歴および現在のドライバー場所データ３２４を検索し得る。図示のように、コンピューティングシステム１００は、ドライバープロファイル情報３１０をデータベース１０８からさらに検索し得る。ドライバープロファイル情報３１０は、ドライバーサービス制限、ドライバー履歴および／またはサービス履歴、ドライバーお気に入りリスト、ドライバーブラックリストなどを含み得る。データベース１０８は、複数の顧客およびドライバーについての顧客情報３０２およびドライバープロファイル情報３１０と、所望であれば他の任意のデータ３０８とを保存し得ることが理解される。
【００９０】
ドライバーは、多様な制限をプリセットし得る。これらの制限は、ドライバーから提供されるサービスリクエストの範囲を制限することを意図し、顧客のサービスリクエストにマッチするドライバーを特定する際に考慮される。例えば、ドライバーの現在の場所からピックアップ場所までの距離に関連してドライバーの制限がある場合、コンピューティングシステム１００は、リクエストされたピックアップ場所からの現在の距離がこのドライバーがプリセット場所または距離の制限としてプリセットした距離を超えた特定のサービスリクエストについてはドライバーに表示できなくすることができる。ドライバーは、矛盾の発生時に矛盾の可能性を解消するために、多様なプリセット制限について優先順位を付け得る。さらに、ピックアップ場所までの距離についてプリセットドライバー制限を設定した場合、電子マップディスプレイ１０００上にドライバーに対して表示された利用不可能なサービスリクエスト１０１０が制限され得る。同様に、事前スケジューリングサービスがオンデマンドサービスへ切り換えられた場合、ドライバーが可能なオプションとして顧客へ表示されない場合がある。
【００９１】
各ドライバーについてコンピューティングシステム１００が検索した履歴データを挙げると、以下の情報がある：ドライバーが現在のバッチを取り扱う特定の派遣担当者によって以前に割り当てられているかまたはコンピューティングシステム１００によって自動派遣されるか、ドライバーがドライバーがサービス提供を望む場所の任意の特定の郵便番号を保存したか、ドライバーが今までサービスリクエストのレッグの経路に沿って（直接的または間接的に）サービスリクエストを取り扱った回数、ドライバーの格付け（例えば、ユーザ格付け、行程をキャンセルしたかつ／または顧客によって拒否またはブラックリスト記載された回数など）。これらの要素はそれぞれ、コンピューティングシステム１００によって特定の重み付けが割り当てられ得る。履歴データは、ドライバーＩＤ番号または名称、自宅住所、選好されるサービス場所または地域、選好される営業時間、パートナーリスト、お気に入りリスト、ブラックリスト、スケジュールされた行程リスト、および受諾された行程リストも含み得る。顧客の選好、ドライバーの制限、および顧客およびドライバーと関連付けられた他の情報に関連するこれらの他の要素も、ドライバーをサービスリクエストまたはそのレッグへ割り当てる際に用いられ得る。多様なアルゴリズムおよび重み付けされた要素が、本明細書中に記載のシステムおよび方法に従ってドライバー割当の作製において用いられ得る。任意のドライバーがサービスリクエストのバッチについて特定された元々検索された可能性のある１組のドライバー（下記にさらに説明する）中に記載されておらず、サービスリクエストのピックアップ場所の近隣に有りかつ利用可能である場合、コンピューティングシステム１００は、このようなドライバーが顧客と適合する（例えば、顧客のブラックリストに記載されていない、顧客が自身のブラックリストに記載されていない、顧客の選好とドライバーの制限との間の任意の絶対的マッチによって排除されていない）場合、このようなドライバーのうち１人を割り当て得ることが理解される。
【００９２】
顧客情報３０２およびドライバープロファイル情報３１０に基づいて、派遣マトリックス３２２は、「適合性」に関連する１組の規則に基づいて、サービスリクエスト３００の１つ以上の局面に起因してサービスリクエスト３００についてサービスを提供することができない１人以上のドライバーおよび／またはこの特定の顧客へのサービス提供を望まないドライバーを排除するように実行され得る。例えば、（ドライバープロファイル３１０に含まれる）ドライバーの制限がサービスリクエスト３００と何らかの様態において矛盾する場合（例えば、サービスリクエスト３００がブルックリンからマンハッタンまでの行程を含んでおりかつドライバープロファイル情報３１０がドライバーがマンハッタンにおけるサービス提供を選択していない旨を示している場合またはサービスリクエスト３００が７ＡＭにおけるピックアップを含むがドライバープロファイル情報３１０においてはドライバーが顧客をピックアップすることを望む最も早い時間が８ＡＭである旨が示されている場合）、このようなドライバーを、コンピューティングシステム１００によって生成された適合する１組のドライバー３２０に含まれるものから排除することができる。
【００９３】
特定の実施形態において、ドライバー場所データ３２４および／またはトラフィックおよびマップデータ３２６は、コンピューティングシステム１００によって検索され得、特定のドライバーが適合する１組のドライバー３２０に含まれるものとして充分に適合するかについてのシステムの決定に織り込まれる。ドライバー場所データ３２４は、プリセットおよび／またはドライバーの比較的現在の場所またはドライバーが特定の時間にいることがスケジュールされる場所を含み得る。トラフィックおよび／またはマップデータ３２６を挙げると、地理、トラフィック、および特定の領域と関連付けられた移動時間情報がある。データベース１０８は、複数のドライバーについてのドライバー場所データ３２４および広範な地理的領域アレイについてのトラフィックおよびマップデータ３２６を含み得ることが理解される。
【００９４】
特定の実施形態において、コンピューティングシステム１００は、異なる優先順にを有する異なる変数を処理する処理関数を用いることにより、適合する１組のドライバー３２０および派遣マトリックス３２２をサービスリクエスト３００、顧客情報３０２、ドライバープロファイル３１０および／またはドライバー場所データ３２４から生成する。例えば、受容されたサービスリクエスト３００は、多数の詳細を含み得る（例えば、タイミング情報および１人以上の顧客が移動先として望む場所）。ドライバー場所データ３２４およびトラフィック／マップデータ３２６（例えば、経路、トラフィックトラフィックパターンを含む情報、混雑など）は、計算に追加的にまたは代替的に織り込まれ得る。加えて、ドライバー優先順位が確立され得、このドライバー優先順位は、ドライバーへ割り当てられた特定の「重み」を含む。この「重み」は、特定のドライバーがサービスリクエスト３００、顧客の選好および顧客お気に入りリストならびに／あるいはピックアップ時に現れることが期待される場所（ドライバー場所データ３２４）においてドライバーがリクエストをサービスできる実行可能性および予期されるトラフィックパターン（トラフィックおよびマップデータ３２６）とどれくらいマッチするかを示す。
【００９５】
例示目的のため、サービスリクエスト３００の特定の経路に精通しておりかつサービスリクエスト３００と干渉するサービス制限を持たない適合ドライバー３２０が２人おり、これらのドライバー３２０に対して、これらの要素について同一の重み付けされた優先順位が割り当てられ得る。しかし、これら２人のドライバーのうち１人が顧客のお気に入りリストに記載されている一方で他方のドライバーは顧客のお気に入りリストに記載されていない場合、お気に入りリスト上のドライバーは、お気に入りリストに記載されていないドライバーよりも優先され得、より高いドライバー優先順位が割り当てられ得る。適合する１組のドライバー３２０について派遣マトリックス３２２中に確立された多様なドライバー優先順位に基づいて、コンピューティングシステム１００は、派遣出力３３０を生成する。派遣出力３３０は、可能なドライバーの選択の表示を含み得、コンピューティングシステム１００から顧客へ自動送信され得るかまたは例えばコンピューティングシステム１００を操作しているサードパーティ管理者１３４によってレビューされ得、その後顧客へ送信され得る。派遣出力３３０は、適合する１組３２０に食い込むドライバー数および顧客が見たいと望むドライバーについてのオプション数に応じて、適合する１組のドライバー３２０または適合する１組のドライバー３２０全体のサブセットであり得る。次に、顧客は、派遣出力３３０に含まれるドライバーのリストからドライバーを選択し得る。次に、顧客によって選択されたドライバーは、受容するオプションが付与されるかまたは自動的にスケジュールされ得る（図４Ｂについてさらに説明する）。
【００９６】
ドライバーがサービスリクエストを受容すると、ドライバーは、自身のサービスリクエストリスト上の受諾されたサービスリクエストの状態（「受諾済み」としてマークされたもの）を確認することができる。次に、ドライバーは、１つ以上のサービスリクエストを共に開始することを選択し得る。ドライバーが１つよりも多くのサービスリクエストを選択し、第１のサービスリクエストに取りかかり始めた後、選択されたサービスリクエスト全てのリストがドライバーデバイス１３２Ｄ１…１３２Ｄｎのうち１つを介して参考のためにドライバーへ提示され得、ドライバーは、各サービスリクエストの状態を更新し得る。例えば、各サービスリクエストは、「ナビゲーション」、「ピックアップ場所に到着済み」、「行程開始」、「下車場所に到着済み」などのボタンを有し得る。ドライバーが同時に取り扱う１つよりも多くのサービスリクエストがある場合、ドライバーは、ピックアップおよび下車を順に決定し得る。サービスリクエストの完了前または完了後にシステムが顧客にｅ署名してもらうための署名機能が付加され得る。
【００９７】
ドライバーデバイス１３２Ｄ１…１３２Ｄｎはそれぞれ、ロックアウト画面も含み得る。ロックアウト画面は、現れているアイテムのみが行程を確認するかについてドライバーにクエリする通知となるように、他の機能をブロックする。このような通知により、行程の詳細（例えば、ピックアップ場所、ピックアップ時刻、目的地、および下車時刻）が示され得るが、行程確認のための「はい」または「いいえ」クエリ以外の他の任意の対話フィーチャは含まれない。
【００９８】
事前に計画されたサービスリクエストは、「割り当て済み」または「未割当」というキャプションをそれぞれ有するリストと共に状態カラム上に表示され得る。ドライバーには、２つのオプション（すなわち、受諾または拒否）が付与され得る。ドライバーがサービスリクエストを受諾すると、サービスリクエストは、サービスリクエストリストの状態カラム内において「受諾済み」と表示される。ドライバーがサービスリクエストを拒否した場合、サービスリクエストは、状態カラム内に「拒否済み」と表示され、に計画されたドライバーの名が参考のために表示され得る。データベース１０８中の記録に基づいて更新されたリストまたはバージョンから削除されたサービスリクエストまたは更新されたバージョンにおいて「キャンセル済み」とマーク付与されたサービスリクエストは、キャンセルされたサービスリクエストとしてコンピューティングシステム１００内に保存され得る。特定のキャンセルされたサービスリクエストが元々はドライバーへ割り当てられてスタートしたものであった場合、システムは、これらのサービスリクエストを「スタート後にキャンセル済み」としてマーク付与または保存し得、ドライバー名がさらなる参照のために記録され得る。前回のサービスリクエストスケジュール更新時に現れなかった新規サービスリクエストが受容された場合、このような新規サービスリクエストが派遣担当者へ表示され得、これらのサービスリクエストについてドライバーおよび派遣をできるだけ早期に見つけるよう派遣担当者を促すために、高い優先順位が割り当てられ得る。派遣担当者が新規サービスリクエストを例えば電話、ｅメール、テキストメッセージなどにより受信した場合、これらはサービスリクエストリストへ手動入力され得、リクエストを受諾または拒否し得るドライバーへその後割り当てられ得る。
【００９９】
特定の実施形態において、システムは、各ユーザの制限および選好に関連する多様な要素を比較することにより、顧客とドライバーとの間のサービスリクエストについての適合性を決定することができる。例えば、ドライバーが標準中国語の言語能力を示して折らずかつ顧客が全ドライバー候補として標準中国語を話すドライバーを好む場合、標準中国語を話さないサービス提供者は全て、不適合としてシステムにみなされ得る。時間制限については、ドライバーの時間制限と、推定される移動時間とを比較して、顧客のサービスリクエストを完了する（例えば、ドライバーがピックアップ場所から下車場所から戻る場所までに移動するのにかかり得る時間（ただし、適用可能な場合））。推定される移動時間がドライバーの時間制限を超える場合（例えば、ドライバーが特定時刻まで有る場所に現れる必要が有るがそれが不可能である場合）、ドライバーまたはサービス提供者は、その特定のサービスリクエストについて不適合とみなされ得る。システムは、ドライバーの場所制限と、サービスリクエストの経路とを比較することもできる。ドライバーが特定の領域に行きたくない旨を示した場合、顧客のピックアップまたは下車場所がこれらの領域のうち少なくとも１つが含まれる状況において、ドライバーは、不適合とみなされ得る。各顧客は、任意の要素または属性を（事前に計画されたサービスについてドライバーとマッチする）自身の適合性選好に関連させるかと、各属性が関連する度合いとをカスタマイズすることができる。システムは、ドライバー、ドライバーの車両、ドライバーの能力ならびに／あるいは特定のドライバーがこのような選好を有するかまたは提供するかについての多様な選好についての顧客のプリセット優先順位レベルに基づいて、重み付けされた計算を行うように構成され得る。
【０１００】
場所制限は、ドライバーが最終手的にサービスを提供する場所に大きく影響し得、本明細書中に記載の例示的実施形態により、サービスリクエストをスケジューリングする際に異なる規定された地域を要素として用いることが可能な効率的な派遣システムが可能になることが理解される。これらの領域は、国毎にまたはより小さな区域（例えば、州、国または行政区、近隣およびさらには郵便番号）毎に規定され得る。サービスリクエストが行われる場所は、サービスリクエストがスケジュールされる時期に関連し、領域毎にグループ分けすることができるため、本システムは、サービスリクエストが行われる場所（特に、スタート場所および終了場所）を特定するように構成され得る。データベース１０８中の情報を用いたこのようなグループ分けにより、従来のランダムな派遣慣行に比して効率向上が可能になることが理解される。例えば、大きな市町村（例えば、ニューヨーク）において、ドライバーは、ランダムな場所へランダムに派遣され得る。ＮＥＭＴ業界において、ドライバーは、例えば顧客をブロンクスで下車させた直後に後、クイーンズのファーロッカウェーにおいて別の顧客をピックアップするよう派遣される場合がある。これらの場所双方はニューヨークのメトロエリア内にあるものの、地理的に相互に離れている。加えて、ニューヨークにおいて一般的なトラフィックおよびナビゲーションの問題を織り込んだ後、これら二箇所の間の移動時間が１時間を超えることは容易にあり得る。サービスリクエストを地理的領域毎にグループ分けし、ドライバーを追跡することにより、派遣の実行をより効率的にすることができ、ドライバーがより多数のサービスリクエストをより短時間で完了することが可能になる。このようなグループ分けにより、派遣担当者がサービスリクエストを事前スケジュールすることがより容易かつずっと高効率になることが可能になることが理解される。
【０１０１】
本明細書中に記載のシステムおよびプロセスにより、このような事前スケジューリングが同一日のサービスのためのものか、数時間前のサービスのためのものかまたは数日前または数週間前のサービスのためのものかに関係無く、サービスリクエストおよびドライバー割当の事前スケジューリングが可能になることが理解される。顧客情報、ドライバープロファイル情報、ドライバー場所データおよびトラフィックマップデータを上記したように保存することにより、コンピューティングシステム１００は、データベース１０８中の複数のドライバーを迅速に除去することができ、ドライバーの場所または予測される場所に基づいて、サービスリクエストと、顧客およびそのサービスリクエストと最も適合するとみなされる選択されたドライバーリストとをマッチさせることができる。このような処理により、コンピューティングシステム１００は、より適合しかつ地理的に近いドライバーに迅速に集中することができるため、コンピューティングシステム１００のより効率的な動作が可能になることが理解される。
【０１０２】
ここで図４Ａを参照して、本発明の実施形態による例示的派遣動作を示すフローチャートが図示される。プロセスは、コンピューティングシステム１００がベンダーからアップロードされかつ／または顧客から提供され得るサービスリクエスト３００をダウンロードまたは受信することから開始する（ステップ４００）。コンピューティングシステム１００は、プログラムステップに基づいてサービスリクエスト３００を自動的にダウンロードしてもよいし、あるいは、派遣担当者が（例えばウェブポータル中のダウンロードリンクをクリックするかまたは係属中のリクエストページを更新することにより）サービスリクエストを手動でダウンロードしてもよい。コンピューティングシステム１００は、サービスリクエストを（任意の変更を反映するように）ポピュレートおよび更新するいくつかの方法が可能になるように、構成され得る。例えば、コンピューティングシステム１００は、サービスリクエストのリストをダウンロードするために関連ベンダーウェブポータルまたはアプリケーションプログラムインターフェース（ＡＰＩ）へアクセスするように構成され得る。サービスリクエストリストが最新の変更を確実に反映するように、コンピューティングシステム１００は、このようなダウンロードを繰り返し一定間隔で（例えば、５分毎、１５分毎、３０分毎など）行い得る。ベンダーはまた、ベンダーモジュールを通じて（例えば、ベンダーデバイス１２６を通じて）サービスリクエストを供給および編集し得る。いずれの場合も、コンピューティングシステム１００は、更新されたサービスリクエストリストをその後処理し、データベース１０８内に保存された履歴記録に基づいてそれらのリクエストと、過去のサービスリクエストとを比較して、類似点が有るかを決定する（ステップ４０２）。
【０１０３】
次に、コンピューティングシステム１００は、その詳細と、データベース１０８中に保存された任意の先行サービスリクエストの記録とマッチするかを決定する（ステップ４０４）（例えば、マッチする顧客名、ピックアップ場所および／または下車場所）。マッチが見つからない場合、サービスリクエスト３００は新規処理のために発信のために送られる（ステップ４０６）。しかし、サービスリクエスト３００の派遣の前に、システムは、サービスリクエスト３００が有し得る任意のフィルタ条件（４０８）（例えば、経路の精通レベル、顧客について行われた前回のサービスリクエスト数、２ドア対４ドア車両など）を特定し、例えばこれらのフィルタ条件と、データベース１０８中のドライバーの制限の関連部分とを比較し、特定のドライバーを選択対象から排除して、サービスリクエストを完了する（例えば、サービスリクエストは、ドライバーが特定の言語に流ちょうであることを要求するが、そのドライバーはその特定の言語を話さない）ことにより、これらのフィルタ条件を収容する。マッチする記録が発見された（ステップ４０４）かまたは新規のサービスリクエスト記録が処理された（ステップ４０６／４０８）後、コンピューティングシステム１００は、データベース１０８中の記録を検索して、サービスリクエストについての顧客のお気に入りのドライバーがサービスリクエスト３００の実行に利用可能であるかを決定する（ステップ４１０）。
【０１０４】
お気に入りのドライバーが利用可能であると決定された場合（「はい」、ステップ４１０）、コンピューティングシステム１００は、サービスリクエスト３００を受諾してもらうようにお気に入りのドライバーへ送る（ステップ４１２）。利用可能であると決定されたお気に入りのドライバーがいない場合（「いいえ」、ステップ４１０）、コンピューティングシステム１００は、データベース１０８を検索して、好みのドライバーが利用可能であるかを決定する（ステップ４１４）。好みのドライバーが利用可能である場合（「はい」、ステップ４１４）、コンピューティングシステム１００は、その好みのドライバーへ受諾のためにサービスリクエスト３００を送る（ステップ４１２）。利用可能なお気に入りのドライバーまたは好みのドライバーが見つからなかった場合（「いいえ」、ステップ４１４）、コンピューティングシステム１００は、レギュラードライバーが利用可能であるかを特定する（ステップ４１６）。レギュラードライバーが利用可能である場合（「はい」、ステップ４１６）、コンピューティングシステム１００は、サービスリクエストをレギュラーのドライバーへ受諾のために送る（ステップ４１２）。レギュラーのドライバーが利用できない場合（「いいえ」、ステップ４１６）、コンピューティングシステム１００は、次の利用可能なドライバーの特定されたおよびスケジュールを行うために全ドライバーを継続的に監視する（ステップ４２０）。利用可能なドライバーが特定された後、サービスリクエスト３００は、その特定された利用可能なドライバーへ送られ得る（ステップ４１２）。
【０１０５】
ステップ４１２においてサービスリクエスト３００が送られた第１のレギュラーのドライバーがサービスリクエストを受諾しなかった場合、システムは、別のドライバーが特定されるまで、プロセスを繰り返し得る（ステップ４２０）。ドライバーがサービスリクエスト３００を自身のドライバーデバイス１３２Ｄ１…１３２Ｄｎ上において受信すると、当該ドライバーは、リクエストを受諾または拒否する選択肢を有する（ステップ４１８）。ドライバーがサービスリクエスト３００を受諾した場合、当該ドライバーは、サービスリクエストを完了するものとしてスケジュールされる（ステップ４２２）。しかし、ドライバーがサービスリクエスト３００を拒否した場合、コンピューティングシステム１００はステップ４１０へサイクルバックし、任意のお気に入りのドライバーが利用可能であるかを再度確認する。お気に入りの選好されるドライバーまたはレギュラーのドライバーが利用できない場合、一定時間の経過後、派遣担当者に対し、別のドライバーを特定するプロセスを行うよう通知する必要があり得る（ステップ４２０）。
【０１０６】
サービスリクエストの完了後、ドライバーは、ドライバーのお気に入りの顧客リストおよび／またはドライバーの顧客ブラックリストへ追加を行い得る。例えば、ドライバーに対し、ドライバーが顧客に満足したかについてクエリが送られ得る。ドライバーがその顧客に対して不満がある場合、そのドライバーは、その顧客をドライバーの顧客ブラックリストへ追加し得、その場合、ドライバーおよび顧客がその後のサービスリクエストにおいてマッチされることが無くなる。ドライバーがその顧客について中立的である場合、ドライバーは何もアクションをとる必要は無く、顧客は、ドライバーのお気に入りの顧客リストまたはドライバーの顧客ブラックリストへ追加されない。ドライバーが顧客に対して満足している場合、ドライバーは、ドライバーをドライバーのお気に入りの顧客リストに追加することを許可してもらうよう顧客へリクエストを送り得る。このような実施形態において、このリクエストを受諾するか否かは顧客次第である。顧客がこのリクエストを拒否した場合、その顧客は、ドライバーのお気に入りの顧客リストに付加されない。この顧客がこのリクエストを受諾した場合、顧客は、ドライバーのお気に入りの顧客リストへ追加される。ドライバーが別の時にサービスを顧客へ提供した場合、ドライバーに対し、その顧客について満足したかについてのクエリが再度送られ得る。その顧客について満足した場合、ドライバーは、ドライバーが別のときにサービスをその顧客へ提供するまで、その顧客を自身のお気に入りの顧客リスト上に保持することができる。ドライバーが別のときにサービスをその顧客へ提供した場合、上記クエリが再度発生するといった具合に進めていく。このようにして、ドライバーに対し、各サービスリクエストの終了時に顧客について満足しているかについてのクエリが送られ得る。ドライバーがその顧客に不満がある場合、ドライバーは、その顧客をドライバーのお気に入りの顧客リストから削除することを選択し得る。
【０１０７】
顧客は、サービスリクエスト完了後、自身のお気に入りのドライバーリストおよび／または自身のドライバーブラックリストへの追加を同様に行い得る。顧客に対し、ドライバーに満足したかについてのクエリが送られ得る。顧客がドライバーに不満がある場合、顧客は、ドライバーを顧客のドライバーブラックリストへ付加し得る。その場合、顧客およびドライバーは、その後のサービスリクエストにおいて共にマッチされない。顧客がドライバーについてどう思うのかについて中立である場合、その顧客は任意のアクションをとる必要は無く、ドライバーは、顧客のお気に入りのドライバーリストまたは顧客のドライバーブラックリストへ追加されない。顧客がドライバーに満足している場合、顧客は、顧客のお気に入りのドライバーリストへ追加する許可を乞うリクエストドライバーへを送り得る。このような実施形態において、このリクエストを受諾するか否かはドライバーが決定することである。ドライバーがこのリクエストを拒否した場合、ドライバーは顧客のお気に入りのドライバーリストへ追加されない。ドライバーがこの許可を受諾した場合、そのドライバーは、顧客のお気に入りのドライバーリストへ追加される。ドライバーが別のときにサービスを顧客へ提供する場合、システムは、ドライバーに満足しているかについてのクエリを再度顧客へ送り得る。ドライバーに満足している場合、顧客は、ドライバーが別のときにサービスを顧客へ提供するときまで、ドライバーをお気に入りのドライバーリスト上に保持し得る。ドライバーが別のときにサービスを顧客へ提供すると、クエリが再度出現し得るといった具合に進行する。顧客に対し、各サービスリクエストの終了時にドライバーに満足しているかについてクエリが送られ得る。顧客がドライバーについて不満がある場合、顧客は、そのドライバーを自身のお気に入りのドライバーリストから除去することを選択し得る。コンピューティングシステム１００は、サービスリクエストを終了した回数が最も多いドライバーを決定し、このドライバーを顧客のお気に入りリストへ追加しようとするように構成され得る。このドライバーが利用できない場合、コンピューティングシステム１００は、顧客に対してサービスリクエストを終了した回数が２番目に多い別のお気に入りのドライバー、顧客に対してサービスリクエストを終了した回数が３番目に多い別のお気に入りのドライバーを割り当てるといった具合に構成され得る。
【０１０８】
顧客がドライバーまたは数人のドライバーを自身のドライバーブラックリストへ追加することを望む旨を示した場合、顧客は、理由（単数または複数）を入力するように促され得る。ブラックリストに記載されたドライバーを自動的にスキップすることにより、顧客および派遣マトリックス３２２および派遣出力３３０の生成におけるコンピューティングシステム１００の処理速度において、サービス効率が向上することが理解される。また、ドライバーブラックリストは、ドライバーが自身の全般的サービスを向上させるための奨励ツールとして機能することが理解される。ドライバーは、より多くの仕事を得るためにはサービス向上が必要であることを認識し得る。
【０１０９】
ドライバーは、自身のお気に入りの顧客リストからの顧客を別のドライバーへ引き合わせ得る。例えば、このようなプロセスにおいて２人のドライバーが関与する場合、これら２人のドライバーをドライバー１およびドライバー２と呼び、顧客は顧客１と呼ぶ。ドライバー１は、お気に入りの顧客である顧客１を別のドライバーであるドライバー２へ引き合わせたい旨を示し得る。その場合、先ず、この紹介の許可を顧客１に選択してもらうための許可リクエストが顧客１へ送られる。顧客１がこの紹介を許可しない場合、紹介は行われない。顧客１がこの紹介を許可しなかった場合、ドライバー２に通知が行き、この紹介を受諾するかの選択肢が付与される。ドライバー２が紹介を受諾しない場合、紹介は行われない。ドライバー２がこの紹介を受諾した場合、ドライバー２に対し、完了すべきサービスリクエストが付与され、次に、顧客１は、ドライバー２のお気に入りの顧客リストへ追加され得る。同様に、ドライバー２は、顧客１のお気に入りのドライバーリストへ追加され得る。
【０１１０】
コンピューティングシステム１００のユーザは、コンピューティングシステム１００の他のユーザへの紹介を行い得る（ただし、双方のユーザが登録されている限り）。ユーザがブラックリストまたはお気に入りリスト上に載っている誰かの紹介を受けた場合、情報（例えば、参照された個人についてのプロファイル情報）が、紹介を受けたユーザにとって利用可能となることができる。コンピューティングシステム１００は、紹介された当事者に対し、紹介されているユーザについての情報を同様に提供することができる。例えば、ドライバーについての情報を受信した第２の顧客は、当該ドライバーのプロファイル情報中において当該ドライバーが過去にノーショーを起こしたことを知ることができ、顧客は、そのドライバーを自身のお気に入りリストに追加しないことを選択することができる。
【０１１１】
顧客は、自身のブラックリストからのドライバーを他の顧客へ紹介することもできる。顧客の紹介においては、個々のドライバー、ドライバーのグループまたはブラックリストに記載されたドライバーの全リストを他の１人または数人の顧客へ紹介することができる。ドライバーは、自身のお気に入りリストからの顧客を他のドライバーへ紹介することができる。ドライバーの紹介において、個々の顧客、顧客のグループまたはお気に入りリスト全体の１人または数人の他のドライバーを紹介することができる。ドライバーは、１つ以上のプリセットされた理由またはお気に入りの顧客（単数または複数）を紹介する簡単な説明を含み得る。このようなプロセスは、例えば、顧客１のお気に入りのドライバーリストに記載されているドライバー１を別の顧客である顧客２へ紹介したい旨を顧客１が伝えるところから開始され得る。しかし、紹介の実行前に、紹介を許可する選択肢が付与されたドライバー１へ許可リクエストが送られる。ドライバー１が紹介を許可しない場合、紹介は行われない。ドライバー１が紹介を受諾した場合、顧客２に対し、この紹介を受諾するオプションが付与される。顧客２が紹介を受諾しない場合、紹介は行われない。顧客２が紹介を受諾した場合、ドライバー１は、顧客２のお気に入りのドライバーリストへ追加される。同様に、顧客２は、ドライバー１のお気に入りの顧客リストへ追加され得る。
【０１１２】
コンピューティングシステム１００は、未割当のままのサービスリクエストを示す情報を派遣担当者へ提供し得る。このような情報は、サービスリクエストまたは顧客番号を特定するラベルを特定するマップ表示を用いて提示され得る。この同じ表示上において、派遣担当者は、未割当のサービスリクエストの場所の近隣のドライバーを見ることができる。多様なインジケータは、利用可能なドライバーを利用できないドライバーと視覚表示上において区別するために用いられ得、これにより、派遣担当者は、サービスリクエストを割り当てるべきドライバー（単数または複数）を即座に知ることができる。例えば、利用可能なドライバーは、白い車両を示すインジケータによってマークされ得、利用できないドライバーは、黒い車両を示すインジケータによってマークされ得る。当業者であれば、本明細書中に記載のインジケータは制限的なものではなく、本発明の例示的実施形態を例示するものであることを理解する。
【０１１３】
よって、システムは、ユーザ（例えば、ドライバーおよび顧客）をサービスをスケジュールすることまたはサービスを事前計画することをより良好に支援するための複数組のインジケータを提供することができる。多様な複数組のインジケータが、情報伝達の合理化のために提供され得る。インジケータは、１つ以上の文字、数字、アイコン、シンボルまたはユーザのインターフェース上に表示され得る情報の他のグラフィック表示を通じて、この情報を示すことができる。例えば、１組のインジケータは、顧客のピックアップ場所からサービスリクエスト中に指定された顧客の下車場所までの推定移動時間（ＥＴＴ）を伝達するために用いられ得る。サービスリクエストが１つよりも多くのレッグを有するように事前に計画された場合、サービスリクエストは、複数のピックアップおよび下車を含み得る。ＥＴＴを伝達するこの１組のインジケータにより、顧客のピックアップ場所および顧客の下車場所と関連付けられた場所情報が事前に計画されたサービスリクエスト中において接続される。好適には、このようなインジケータは、推定される輸送中時間について顧客に通知またはサービスリクエストを完了するための推定移動時間についてドライバーに通知するために、表示される。このようなインジケータは、（サードパーティマッピングＡＰＩ（例えば、Ｇｏｏｇｌｅ（登録商標）Ｍａｐｓ）によって提供され得る）ピックアップ場所から下車場所までにかかる推定時間に基づき得る。ドライバーの視点から、これは、さらなるステップとして、現在の場所からピックアップ場所までの時間およびピックアップ場所から下車場所までの時間であり得る。顧客のサービスリクエストが複数の区間を有するように事前に計画された場合、これも変化し得る。このようなインジケータは、適用可能な帰還場所制限がドライバーによって設定されている場合、ドライバーが下車場所から帰還場所へ戻るまでにかかる時間も含み得る。ドライバーの視点から、推定される移動時間は、サービスリクエストを完了するのにかかる時間も意味する。しかし、顧客の視点からの完了したサービスリクエストは、ピックアップ場所（単数または複数）から下車場所（単数または複数）までの時間のみである。
【０１１４】
ドライバーのより具体的な稼動性を特定するために、１組のインジケータも提供され得る。このようなインジケータは、電子マップ上の顧客および派遣担当者双方へ表示され得、ドライバーは、アクティブであるときにのみ電子マップ上に表示される。このようなインジケータは、ドライバーがプリセットした日および／または時間に基づいて、ドライバーの稼動性についての情報も含み得る。例えば、このようなインジケータは、稼動性および稼動性が持続する期間または無限の稼動性であるかを示し得る。ドライバーが非番であるかまたは現在サービスリクエストを実行中である場合、このようなインジケータは除去され得る。あるいは、このようなインジケータは、顧客のサービスリクエストがドライバーへ割り当てられているかを特定するために提供され得る。このようなインジケータは、派遣担当者に対して電子マップディスプレイ上において表示され得るため、未だ割り当てられていない行程の視覚表示が提供され、ドライバーがサービスリクエストのために派遣された場合（例えば、サービスリクエストがもはや未割当状態でなくなった場合）、派遣担当者のインターフェースから自動的に消去されるように構成され得る。
【０１１５】
１組のインジケータは、ドライバーが帰還場所をプリセットした場合、ドライバーの現在のジオロケーションおよびドライバーの帰還場所についての情報を伝達するようにも提供され得る。このようなインジケータは、派遣担当者が自身のタッチスクリーン電子マップディスプレイ上において視認されるように提供され得るため、派遣担当者は、サービスリクエストを最も適合するドライバーに割り当てることができる。別の実施形態において、１組のインジケータは、指定されたピックアップ場所および下車場所と、顧客によって事前に計画されたサービスリクエストの第１および第２のレッグからの場所とについての情報を伝達するために提供され得る。このようなインジケータは、場所情報に関連するサービスリクエストを、タッチスクリーン電子マップディスプレイ上の派遣担当者またはドライバーへ表示し得る。タッチスクリーンディスプレイにより、顧客がサービスリクエストについての選択を行うことが可能になり、クリック可能であるかまたは他の接触応答型のタッチスクリーンディスプレイ内のセンサーを備え得る。タッチスクリーンディスプレイ内のセンサーによって受信された信号は、プロセッサが入力として受信し得るものであり、これらの信号は出力となって、顧客またはドライバーが行った選択をシステムに実行させる。
【０１１６】
１組のインジケータは、リクエストされたピックアップ場所におけるドライバーの推定到着時刻（ＥＴＡ）を顧客へ表示するために提供され得る。ドライバーのＥＴＡを生成するために、システムは、サードパーティＡＰＩ（例えば、Ｗａｚｅ（登録商標））による支援により、ドライバーの現在のリアルタイムの移動速度（例えば、ドライバーの現在の場所から事前に計画されたピックアップ場所までの可能な経路に沿った道路速度）を特定し得る。あるいは、１組のインジケータは、顧客の推定される準備可能までの時間（ＥＴＲ）を表示するためドライバーに提供され得る。顧客が行程の第２のレッグをスケジュールした場合、このようなインジケータは、例えば顧客がピックアップの準備を行おうとするときを明確にし得る。例えば、医師とのアポイントメントを持つ顧客は、自身が帰還行程の準備を３０分以内に行うと推定する旨を顧客デバイス１３０Ｃ１…１３０Ｃｎのうち１つ以上に入力し得る。。ＥＴＲインジケータの機能により、事前に計画されたサービスの提供における効率が向上する。このような事前スケジューリングおよびＥＴＲ推定により、ドライバーが無駄な時間を節減することを支援することができることが理解される。ＥＴＲインジケータの支援により、ドライバーは、顧客の現在の状態を引き続き認識することができ、ＥＴＲが充分に長期間にわたって発生している場合、ドライバーは、この期間にわたって別のサービスリクエストを完了し得る。
【０１１７】
この機能は、複数の区間行程において特に有用である。第１のレッグ上の第１の顧客に対してサービスを提供した第１のドライバーは、第１の顧客によって指定されたＥＴＲに基づいて、第２のレッグ上の第１の顧客を待機するかまたは第２の異なるサービスリクエストをとるかを決定し得る。第１の顧客のＥＴＲがしばらくの間は準備ができない旨を示した場合、第１のドライバーは、第２のサービスリクエストをとることを決定し得、第２のレッグの準備ができる時期までにこれを完了することを予期する。第１のドライバーが第１の顧客にとって好みのドライバーとみなされている場合であっても、ＥＴＡに基づいて、第１のドライバーが第２のレッグについて定刻通りに到着できないことをシステムが検出した場合、システムは第１の顧客に通知し得る。この時点において、第１の顧客は、好みのドライバーが自身の第２のサービスリクエストを完了するのを待機するかまたは第２のレッグを別のドライバーへ再度割り当てることをリクエストするかについて同意するオプションを有する。第２のレッグが別のドライバーへ提供されると、その他方のドライバーに対し、ＥＴＲインジケータによって伝達され得る第２のレッグについてピックアップ場所についての推測が送られる。
【０１１８】
システムは、サービスリクエストについて最良にマッチするサービス提供者の顧客による選択をより良好に支援するための複数組のインジケータを提供する。顧客およびサービス提供者双方において、大規模なカスタマイズが可能になり得る。しかし、多様な情報（例を非限定的に挙げると、価格設定、完了したサービスリクエスト数についての具体的情報、サービスリクエスト中の経路についての精通度）は、サービスリクエストについて取引においてユーザをナビゲートする際に複雑になり得る。顧客およびサービス提供者が求める情報は異なるため、インジケータは、必要になり得る情報に応じて異なる。サービス提供者および顧客は、自身の経験、予想および選好を多様な複数組のインジケータを通じてカスタマイズすることができる。本発明の例示的実施形態により、少なくとも２６個のカスタマイズ可能な１組のインジケータを用いて、この包括的情報が合理化される。システムは、混乱回避のために統一されたインジケータを表示するが、ユーザは、特定の１組のインジケータの変更も選択することができる。例えば、ユーザは、或るインジケータを示すデフォルトシンボルまたはアイコンを自身の固有のシンボル（例えば、ユーザ自身のユーザＩＤの感情または略語）と交換したい場合がある。さらに、各インジケータの意味の説明も提供され得、顧客およびサービス提供者はどちらとも、これらの説明をオン／オフにするかまたは一時的に隠蔽するオプションを有する。顧客およびサービス提供者がこれらをオフにすると、これらのうちいずれかまたは全てをオンにするかまたは戻すことができる。例えば、新規のユーザの場合、説明をオンにすることを好み得、サービスをしばらく使ったことのあるためこのサービスに深く精通しているユーザの場合、多様な複数組のインジケータの意味の説明は不要であり得る。顧客およびサービス提供者は、１組のインジケータを別の組のインジケータよりも優先させたい場合、インジケータが表示される順序も変更することができる。
【０１１９】
インジケータは、サービス関連情報を顧客、サービス提供者または双方に簡単、高速かつ簡便な様態で伝達または表示する手段である。複数の組のインジケータは、２者間の適切なサービスマッチングの支援に用いられ、顧客およびサービス提供者双方によるカスタマイズの可能化にも用いられる。顧客およびサービス提供者は、異なるインジケータを各インターフェース上に有し得るが、相互のインジケータも希望すれば見ることができる。さらに、（最小および最大量を有する範囲の数を含む）いくつかのインジケータの階層化システムが設けられ得、各階層は、異なる顧客およびサービス提供者に対して異なる意味を示す。以下、選好される１組のインジケータを簡単に説明する。これらのインジケータのより詳細な説明については、‘７８３出願に記載がある。本明細書中、同文献全体を参考のため援用する。
【０１２０】
第１の１組のインジケータは、ドライバーにとってのユーザ種類を３つのカテゴリを特定し得る（例を非限定的に挙げると、お気に入りのドライバー、選好のドライバー、およびレギュラードライバー）。第２の１組も、顧客にとってのユーザ種類を３つのカテゴリを特定し得る（例を非限定的に挙げると、お気に入りの顧客、選好の顧客、およびレギュラー顧客）。第３の１組は、サービス提供者の稼動性を特定し得る。この稼動性は、サービス提供者がサービスリクエストについて利用可能であり続ける時間において接続し得る。第４の１組は、（顧客からのサービスリクエストが利用可能であり続ける時間において接続し得る）顧客が現在サービスリクエストをリクエストしているかを特定し得る。第５の１組は、サービス提供者が実行したサービスリクエスト量に基づき得、履歴データに関する数が接続される。すなわち、これらは、サービス提供者が特定の期間内に行ったサービスリクエストの合計数を反映するように数を接続し得、この合計数は、一定期間に従ってさらに分割され、数、階層またはこれらの組み合わせによって反映される。第６の１組は、顧客によってプリセットされた対応する検索パラメータの１つ以上または任意の組み合わせに基づいた１つ以上の地理的ゾーンまたは地理的ゾーンの任意の組み合わせを示し得る。第７の１組は、第６の１組のインジケータによって提供されるデータおよび情報に基づき得、可能な利用可能なサービス提供者の合計数と、可能な利用可能な顧客の合計数とをさらに比較する。第８の１組は、価格設定についての数を接続することにより、顧客からの価格提案に対するサービス提供者の応答に関する価格設定情報の合理化を支援し得る。第９の１組は、顧客が見積もり価格無しでサービスリクエストを送り、サービス提供者が提案価格（これは、交渉可能であるか交渉不可能であり得る）と共に応答した場合に、サービス提供者から開始された価格に関する情報を表示し得る。第１０の１組は、顧客がサービスリクエストにおいてピックアップ場所として示す地理的ゾーン内においてサービス提供者が完了したサービスリクエストの合計数に基づいてゾーン情報に関する情報を反映する履歴データおよびジオロケーションデータを接続し得る。。第１１の１組は、顧客がサービスリクエストにおいて下車場所を示す地理的ゾーン内においてサービス提供者が完了したリクエストの合計数に基づいてゾーン情報に関する情報を反映するように、履歴データおよびジオロケーションデータを接続し得る。
【０１２１】
第１２の１組は、少なくともパーセンテージまたは他の任意の図解（例えば、階層）を通じて表現されるサービスリクエストの経路と共に、サービス提供者の精通レベルを伝達し得る。精通度は、ピックアップ場所と、顧客のサービスリクエストによって示される下車場所との間の経路と、データベース中に保存された１人以上のサービス提供者の履歴サービスデータから導出された１人以上のサービス提供者の過去の経路とをマッチさせることにより、計算される。コンピューティングシステム１００の管理者（例えば、派遣担当者）は、ドライバーを多様な顧客と共に調整する職務権限に固有の機能を用い得る。このような調整は、経路マッチングソフトウェアを通じて自動的に行ってもよいし、サービスリクエスト実行に利用可能な可能性の高い者について決定する人間の派遣担当者が手動で行ってもよいし、またはこれらのいくつかの組み合わせによって行ってもよい。
【０１２２】
この１組のインジケータは、リクエストされた経路情報と、データベース中に保存されたサービス提供者のサービス記録とを接続させることにより、生成され得る。運輸リクエストについて、この情報は、サービスリクエスト中に示される経路についてのサービス提供者の精通度を含み得る。送達サービスの場合、これは、経路に関するサービス提供者の経験または精通度などの情報であり得る。サービスリクエスト種別に関係無く、インジケータは、状況に関連する情報を表示するように調節される。パーセンテージは、パーセンテージそのものをパーセンテージとして表示してもよいし、階層に分割してもよい（例えば、階層Ｅは、０〜１９パーセントの精通度を示し、階層Ｄは、２０〜３９パーセントの精通度を示し、階層Ｃは、４０〜５９パーセントの精通度を示し、階層Ｂは、６０〜７９パーセントの精通度を示し、階層Ａは、８０〜１００パーセントの精通度を示す）。階層は、精通度パーセンテージを階層別に分割する任意の単一の図解または図解の組み合わせとして表示され得るため、階層の表示は、Ａ〜Ｅに制限する必要もまたはさらには文字全体に制限する必要も無い。階層およびパーセンテージを共に表示してもよい。サービス提供者にとって、これは、多数の顧客をピックアップするかまたは数人の顧客のみをピックアップする際の評価において有用なインジケータであり得る。この１組のインジケータは、サービス提供者が最も経験豊富なまたは最も貴重な場所を評価する際に用いてもよいし、あるいは、サービスリクエストに対して顧客が持ち得る経験に基づいて最良にマッチするサービス提供者を顧客が選択する際に用いてもよい。
【０１２３】
サービス提供者の精通度は、２つの方法として「直接的」または「間接的」な精通度によって説明され、各種別は別個である。直接的精通度は、ピックアップ場所から下車場所への経路が１つの行程において全て行われる場合のように、サービス提供者が特定の経路に精通する度合いの計算である。これと対照的に、間接的精通度は、ピックアップ場所と下車場所との間の経路にサービス提供者が精通する度合いの計算であるが、この精通度は、経路についての断片的な経験を通じて得られ得る。例えば、２人のサービス提供者が経路について１００パーセントの精通度を有する場合、第１のサービス提供者は、同じピックアップ場所から同じ下車場所までの経路のサービスを前回顧客のために提供している。これは直接的精通度であり、マッチングにおいて１００パーセントの格付けが付与されるのに加えて、このサービス提供者が同一経路を用いてサービスを提供した数または階層によって表示され得る。第２のサービス提供者も１００パーセントの精通度を有するが、過去に異なる顧客のために自身が提供した経路の一部と、当該経路の別の部分とが、同様に別のサービスリクエストにおいて経路の一部として含まれる。サービス提供者がこの経路全体の長さを横断した場合でも、これは、同じピックアップ場所から同じ下車場所までのものではない。サービス提供者が経路について有する精通度は、間接的なものである。リクエストされた経路についての精通度は、前回完了したサービスリクエストの経路に対してリクエストされた経路の全体または任意の部分が共通するレベルを追跡することにより、直接的なものにしろ間接的なものにしろ、リクエストされた経路と、同一のサービス提供者が前回完了したサービスリクエストの経路とを比較することにより、計算される。リクエストされた経路についてのサービス提供者の精通度は、リクエストされた経路の任意の部分がＧＰＳ信号が弱いかまたは存在しないことが知られている領域内にある場合またはサービスリクエストが暗くなってから発生したためナビゲーション方向の追随がより困難になる場合に、特に重要になる。
【０１２４】
第１３の１組のインジケータは、顧客およびサービス提供者がマッチされた回数および共に取引を完了した回数に基づき得る。第１４の１組は、サービス提供者の場所情報と、顧客のピックアップ場所の場所情報とを接続させて、サービス提供者が顧客をピックアップ時間、推定到着時刻（ＥＴＡ）を表示し得る。第１５の１組は、顧客のピックアップ場所からサービスリクエスト中に示された顧客の下車場所までの推定移動時間（ＥＴＴ）に基づき得る。第１６の１組は、顧客のピックアップおよびサービスリクエスト中に示された下車場所を少なくとも反映するように、ジオロケーションデータを接続し得る。第１７の１組は、サービスリクエストの合計数についての情報を伝達し得る。第１８の１組は、サービス提供者がプリセットした１つ以上の検索パラメータまたは検索パラメータの任意の組み合わせに基づいて、１つ以上の地理的ゾーンまたは地理的ゾーンの任意の組み合わせを特定し得る。第１９の１組は、第１８の１組のインジケータに基づき得、可能な利用可能な顧客の数と比較して可能な利用可能なサービス提供者の数をさらに表示する。第２０の１組は、顧客が開始した価格提案の表示を合理化させ得、価格設定情報に関する数値が接続および表示される。第２１の１組は、サービス提供者の提案価格に対する応答として発生する顧客の提案価格についての詳細を提供し得、価格設定情報に関する数値がこの１組のインジケータによって接続および表示される。第２２の１組は、顧客のサービスリクエスト履歴に関する履歴データおよびジオロケーションデータを接続して、ピックアップ場所の地理的ゾーンに基づいて、顧客がリクエストおよび完了したサービスリクエスト数毎に顧客を特定し得る。第２３の１組は、顧客がリクエストおよび完了したサービスリクエスト数別に下車場所地理的ゾーンに基づいて顧客を特定し得、ジオロケーションデータおよび履歴サービスリクエストデータが接続される。第２４の１組は、履歴サービスリクエストデータを接続し得、サービス提供者および顧客が相互にマッチされかつ取引を共に完了した回数を表示し得る。第２５の１組は、サービス提供者についてサービスリクエストを完了するための推定移動時間を特定し得る。サービス提供者が帰還場所をプリセットした場合、第２６の１組は、サービスリクエストを実行した後、サービス提供者のジオロケーションデータおよびサービス提供者のプリセット帰還場所のジオロケーションデータを接続し得る。
【０１２５】
加えて、数えられる数に少なくとも部分的に基づいた任意のインジケータは、階層についても反射され得る。システムによって割り当てられた階層は、顧客またはサービス提供者へ適用されるかおよび運輸サービス、送達サービスまたは運輸および送達サービス双方に適用されるかに応じてに依存する最小量および最大量を含む数の範囲であり得る。インジケータは、各階層間の差を示す文字、形状または色または他の任意の方法として表示され得る。いくつかの顧客のインジケータおよびサービス提供者のインジケータは、異なる意味を有し得る。インジケータは、そのユーザ種類、カテゴリおよびサブカテゴリに相対して活動を示す。システムは、サービスリクエスト記録をシステムのデータベース中に保存するため、サービスリクエスト記録が時間スタンプを用いることにより作製された際または実行された場合およびリクエスト詳細によって実行された場合、これらの記録を定量化することができる。しかし、時間または他の数についてのこれらの記録は、スケールアップまたはダウンされ得、顧客は、関連する時間枠を分割し得る（例えば、１日以上、１月以上、または１年以上）。時間または時間枠またはゾーンまたは他の数についてのこれらの異なる調節可能な検索パラメータは全て、顧客およびサービス提供者を個別調整し、顧客およびサービス提供者が見ることを望む情報に優先順位を付けるように、カスタマイズ可能なように設計される。
【０１２６】
サービス提供者に関連する需要および供給は、ピックアップ場所からの距離において顧客がピックアップ場所においてピックアップが行われることを期待する時間に基づいて、顧客がサービスリクエストの価格について交渉することを望む所望の数のサービス提供者に基づいて、顧客によってプリセットされた検索パラメータによって表示され得る。時間に基づいた検索パラメータは、検索半径を生成し得、ピックアップ場所へ繋がる可能な全経路上の全サービス提供者を特定することと、可能な経路それぞれに沿ったリアルタイムの移動速度を特定することと、各サービス提供者の可能な経路に沿った移動速度をプリセットを顧客がプリセットした最大時間と乗算して、顧客がプリセットした最大時間内にサービス提供者が移動できる最大距離を計算することと、顧客のピックアップ場所を検索半径の中心点として特定することと、検索半径の極値点を特定することであって、極値点は、検索パラメータ内のサービス提供者の最も離れた場所または顧客がプリセットした距離にある何らかの他の点であり得る、ことを含み得る。検索パラメータ内におけるサービスリクエストの需要および供給が、供給側の潜在的な利用可能な顧客数と比較した需要側の潜在的な利用可能なサービス提供者として、顧客に対して表示され得る。
【０１２７】
検索パラメータが顧客によってプリセットされることは、所望の数のサービス提供者をプリセットおよび検索することと、ピックアップ場所を検索半径の中心点として特定することにより検索半径を生成することと、検索半径の極値点をサービス提供者の中心点から最も離れた場所として特定することとを含み得る。検索半径は、時間または距離に基づく検索半径よりも小さくても大きくてもよく、サービス提供者の推定到着時刻がインジケータの支援によって顧客について特定され得るを含み得る。検索半径内において特定されたサービス提供者の数は、顧客のために価格交渉について優先順位が付けられ得る。
【０１２８】
顧客およびサービス提供者は、自身のインターフェース上に表示された異なるインジケータを有し得る。これらのインジケータのうちいくつかは、サービスを提供またはリクエストするかに関わらず、ユーザの種類に関連し得る。好適には、いくつかのインジケータは顧客にとってより有用であり得、いくつかのインジケータはサービス提供者にとってより有用である。しかし、好適には１人の当事者へ表示されるインジケータはその他の当事者にとって有用な情報を反映し得るため、インジケータは、サービス提供者のみまたは顧客のみに排他的に表示されることを意図していない。しかし、ユーザが選択した場合、自身の情報をシステムを通じて見ることができる。ユーザが（他のユーザが自身のサービスリクエスト履歴について見ているインジケータが正しいことを確認するために）自身のインジケータまたは自身のサービスリクエスト履歴を見ることに興味を持つ場合、ユーザは、自身のプロファイル情報または（適用される全インジケータを示す）システムによって指定された他の任意の手段を通じてこれを行い得る。このサービスリクエスト履歴は、他のパーティが見ることが可能な情報を含み得る（例えば、完了したまたはリクエストされたサービスリクエストの合計数についてのインジケータ）。サービスリクエスト履歴は、他のパーティが見ることができない情報も含み得る（例えば、どれだけ稼いだかまたは費やしたかについての私的な情報）。このようなインジケータは全て、（相互に最良の取引をするために最良にマッチするサービス提供者または顧客それぞれを選択する際の支援となり得る）カスタマイズ可能な情報を顧客およびサービス提供者へ提供することを意図する。他の種類の関連情報の要旨を視覚的に伝達する手段として、さらなるインジケータが１つ以上のコンピューティングデバイスを通じた展開のために開発および／または利用され得ることが理解される。
【０１２９】
サービスリクエストを受諾するためにドライバーがとり得る第１のアクションは、ドライバーデバイス１３２Ｄ１…１３２Ｄｎ上の「受諾」ボタンを押圧することである。ドライバーは、サービスを開始する準備ができた場合、ピックアップ場所へ向かっている途中である旨を示す「スタート」ボタンを押圧し得る。ドライバーは、自身が向かっている旨を顧客に伝えるために顧客に電話もかけ得る。「スタート」ボタン後の任意の時点においてドライバーが（例えば、タイヤのパンクまたはドライバーの車両に機械的故障が発生したことまたは他の任意の正当なキャンセル理由に起因して）キャンセルする必要が出た場合、ドライバーは、キャンセルを行い得る。このような状況においては、ドライバーは、キャンセル理由を提供し得、サービスリクエストをキャンセルし得る。その場合、サービスリクエストは、別のドライバー（例えば、パートナードライバー）へ再送され得る。
【０１３０】
ドライバーは、サービスリクエストを好きなときにキャンセルし得る。ドライバーがキャンセルを１日前に行った場合、キャンセルの理由を報告する必要は特に無い。このような場合、派遣担当者は、新規ドライバーを再スケジュールおよび再派遣し得る。ドライバーがサービスリクエストを完了すべき日の当日にキャンセルした場合、ドライバーは、有り得るデフォルト理由から選択するかまたはテキスト入力により理由を入力して、キャンセル理由を提供し得る。キャンセル後にサービスリクエストを受諾できるドライバーがいない場合、サービスリクエストは、主要ウェブポータル上のサービスリクエストリストに戻って、派遣担当者は他のドライバーを割り当てる。派遣担当者がサービスリクエストを再スケジュールおよび再送した後、コンピューティングシステム１００は、別の通知を顧客へ送るように構成され得る。この通知は、前回のドライバー名、前回のドライバーが顧客にサービスを提供できない理由、新規ドライバーの名、新規ドライバーの電話番号、新規ドライバーの車両、ブランドおよび色、ピックアップ時刻などを含み得る。顧客は、サービスリクエストの変更またはキャンセルをいつでも行い得る。顧客が目的地を変更したい車両が入力されると、ドライバーは、意図される目的地へ再度経路設定し得る。ドライバーおよび顧客が下車場所に到着した後、ドライバーは、顧客に（サービスが正しくかつ満足いく様態で行われたことの確認として）サービスリクエストに署名するよう求め得る。これらのステップが完了すると、サービスリクエストは終了する。
【０１３１】
ドライバー派遣の事前スケジューリングにより、個々のドライバーは、サービスリクエストの受諾または拒否について選択する裁量を得ることができることが理解される。コンピューティングシステム１００は、ドライバーが（例えばその日、次の日、次週などの利用可能な経路を示す電子マップを用いて）潜在的なサービスリクエストを選択する機能を提供し得る。ドライバーの時間および場所制限の考慮については、現在のおよび／または将来の予測されるトラフィックおよび移動時間に影響を与える可能性のある他のイベント（例えば、工事、道路閉鎖、事故など）またはドライバーについての場所制限の利用によって行われる。このようなデータは、データベース１０８中に保存され得、トラフィックおよびマップデータ３２６（図３を参照）の一部として派遣マトリックス３２２中へ供給され得る。
【０１３２】
次に図４Ｂを参照して、図４Ａの例示的派遣動作の後に顧客またはドライバーが事前に計画されたサービスリクエストをキャンセルするための例示的な一連のステップを示すフローチャートと、ドライバーのキャンセルに代替する新規プロセスとが図示される。ドライバーまたは顧客は、事前に計画されたサービスリクエストをいつでもキャンセルし得る。ドライバー（または顧客）が事前に計画されたサービスリクエストを充分に前もって（例えば、１日、１週間前などに）キャンセルした場合、ドライバー（または顧客）は、キャンセル理由を報告する必要は無い。このような状況において、派遣担当者またはコンピューティングシステム１００は、顧客側からのキャンセルの場合はサービスリクエストを単にキャンセルするか、または、サービスリクエストを新規のドライバーへ再スケジュールおよび再送する。しかし、間際になってキャンセルしたドライバーについては、そのようなドライバーに代替するための異なるプロセスが用いられ得る。
【０１３３】
詳細には、図４Ｂに示すように、サービスリクエスト３００がドライバーに対してスケジュールされた場合（ステップ４２２）、コンピューティングシステム１００は、サービスリクエスト３００のスケジュールが完了した旨を示す通知を顧客へ送り得る（ステップ４２４）。ドライバーがキャンセルせず（ステップ４２６）かつ顧客もキャンセルしない（ステップ４２８）場合、サービスリクエストがスケジュール通りに実行され（ステップ４３０）、プロセスが終了する（ステップ４３２）。次に、ドライバーは、請求先プロセスを開始し得る。しかし、顧客が例えば顧客デバイス１３０Ｃ１…１３０Ｃｎのうち１つを通じてキャンセルした場合（ステップ４２８）、顧客は、キャンセル理由（例えば、アポイントメントのキャンセル、別の理由、サービスが不要になった、など）を提示するよう求められ得（ステップ４３４）、プロセスは終了し（ステップ４３２）、請求は発生しない。次に、割り当てられたドライバーは他の場所へ派遣され得る。ドライバーがキャンセルした場合（ステップ４２６）、コンピューティングシステム１００は、新規ドライバーを派遣する必要がある。一実施形態において、顧客がパートナードライバーについて許可をプリセットしている場合、コンピュータシステム１００は、キャンセルを行ったドライバーが指定した１人以上のパートナードライバーに基づいてサービスリクエスト３００を派遣する（ステップ４３５）。その場合、パートナードライバーに対して受諾してもらうよう通知が送られる（ステップ４３７）。顧客がパートナードライバーについて許可をプリセットしていない場合、サービスリクエストは、派遣処理対象として送られ得る（ステップ４３９）。パートナードライバーの場所は、コンピューティングシステム１００が迅速にアクセスできるよう、データベース１０８中に保存され得る。この場合、サービスリクエスト３００はパートナードライバーへ送られ得（ステップ４３６）、サービスリクエスト３００が完了する。任意選択的に、サービスリクエスト３００は、１人よりも多くの潜在的なパートナードライバーへ送られ得、これらの最良にマッチするパートナードライバーのリストが選択対象として顧客へ表示され得る。顧客が選択したパートナードライバーがサービスリクエストを受諾した場合（ステップ４３７）、このパートナードライバーは、サービスリクエストをサービスする（ステップ４３８）。
【０１３４】
サービスリクエストに対するサービスを提供するパートナードライバー（またはサービスリクエストに対するサービスを提供し得るパートナードライバーのリスト）を選択するために用いられる方法は、適合する１組のドライバーおよび図３について上記した派遣マトリックスの生成方法に類似し得る。換言すると、これは、潜在的なパートナードライバーに特定のドライバー優先順位を割り当てることと、稼動性、制限などを評価することとを含み得、顧客は、これらの考慮事項を用いて、自身の裁量で選択をすることができる。あるいは、割り当てられたドライバーがキャンセルした瞬間にパートナードライバー（ただし、利用可能でありかつ顧客ブラックリストに記載されていない者）がサービスリクエストへ自動的に割り当てられるように、単一のパートナードライバーと、各ドライバーとが関連付けられ得る。パートナードライバーがキャンセルしたドライバーの代わりとして確認されると、パートナードライバーはサービスを完了し（ステップ４３８）、プロセスは終了する（ステップ４３２）。次に、パートナードライバーは、請求先プロセスを開始し得る。
【０１３５】
顧客がサービスリクエスト３００のキャンセルを充分事前に行った場合（例えば、閾値として１．５時間）、サービスリクエスト３００は「キャンセル済み」としてマーク付与され得、コンピューティングシステム１００は、即座にドライバーに通知し得る。ドライバーこのようなキャンセル通知が通知されると、システムは、キャンセルの受信を確認するようドライバーに要求するように構成され得る。あるいは、ドライバーがキャンセルの受信を確認しない場合、ドライバーデバイス１３２Ｄ１…１３２ｎのうち関連する１つの上において実行されるアプリケーションがロックされ得、そのドライバーは、キャンセルの受信を確認するまで、当該アプリケーション内においけるいかなる動作も行うことができなくなる。しかし、顧客がサービスリクエストのキャンセルを間際になって行った場合（例えば、ピックアップ時刻から１．５時間未満）、その顧客に対し、サービスリクエストを土壇場で行ったことを特定する手段（例えば、「ピックアップの５分前にキャンセル」から開始する表示）が割り当てられ得る。所定数最終時間および／またはキャンセル全体の後、その顧客はシステムのブラックリストに付加されて、コンピューティングシステム１００は、その顧客についてのサービスリクエスト全てを特定期間にわたって事前スケジュールしないようになる。コンピューティングシステム１００は、３０分以内にさらに２回キャンセルした場合は顧客がシステムのブラックリストに記載されることになり得る旨の通知を送るように構成され得る。コンピューティングシステム１００は、顧客が質問が有る場合、連絡先情報も提供し得る。
【０１３６】
顧客のサービスリクエストがドライバーによって土壇場でキャンセルされた場合、そのサービスリクエストは即座に再送される。このプロセスの第１のステップは、キャンセルを通知することである。このキャンセルは、再送の詳細を含み得る。このようなシナリオにおいて、コンピューティングシステム１００は、例えばサービスリクエストと顧客のお気に入りリスト上の任意のドライバーとの適合性を決定し得る。適合するものがいくつか有る場合、システムは、利用可能なサービスリクエストのドライバーに通知し得、お気に入りのドライバーのうち１人が、サービスリクエストへ最初に割り当てられたサービスリクエストを受諾する。
【０１３７】
コンピューティングシステム１００は、ドライバーが自身のプリセットされたブラックリストへ追加するオプションをドライバーへ付与するように、構成され得る。ドライバーが顧客をドライバーの顧客ブラックリストへ追加した後、ドライバーは、その顧客のサービスリクエストについてマッチするドライバーを検索する際、コンピューティングシステム１００によってスキップされる。対立を回避するため、システムは、ドライバーの顧客ブラックリストに記載されていた顧客からのサービスリクエストを受信した際、コンピューティングシステム１００がリクエストを別のドライバーへ自動送信し、顧客によって各ブラックリストへ追加されたドライバー全員をスキップするように、構成され得る。
【０１３８】
ドライバーが顧客をブラックリストに記載した場合、同じブラックリストに記載されている顧客は、ドライバーのお気に入りの顧客リストへの追加から排除される。換言すると、ブラックリストに記載された顧客は、ドライバーのブラックリストおよびそのドライバーのお気に入りリストに同時に記載されることはできない。派遣担当者は、特定のドライバーが特定の顧客によってブラックリストに記載されている場合およびその逆の場合にコンピューティングシステム１００から通知を受けることもでき、これにより、派遣担当者は、より適したまたはより近隣のドライバーに心当たりが有る場合にコンピューティングシステム１００を無視したいときに、特定のサービスリクエストについて派遣すべきではないドライバーを知ることができる。「ブラックリスト」は本質的には、「振る舞いの良くない」「難しい」顧客またはドライバーのためのものである。しかし、ドライバーまたは顧客を任意の理由のためにブラックリストに記載することが可能であることが理解される。ブラックリストに記載された顧客およびドライバーは、特定の対応するドライバーまたは顧客とのマッチングから自動的に排除されるか、または、派遣から共に排除され得る。
【０１３９】
データベース１０８中に保存および動的に更新された顧客についてのプリセットされた「選好」情報を非限定的に挙げると、ピックアップ場所、下車場所、車両の型式、モデルおよび種別、運転経験年数、座席定員、性別、話せる言語、サービスアクセシビリティ、医療デバイスの稼動性、ペット対応およびベビーシート稼動性に関連する選好情報がある。ピックアップ場所の選好情報により、顧客は、自身のピックアップ場所を特定することができる。下車場所の選好情報により、顧客は、自身の下車場所を特定することができる。車両の型式、モデルおよび種別により、顧客は、自身のサービスリクエストにおいて自身が好む車両の型式、モデルおよび種別を指定することができる。「運転経験年数」の選好情報により、顧客は自身のドライバーに持ってもらいたい経験年数をプリセットすることができる。「座席定員の選好」により、顧客は、自身のサービスリクエストにおける複数の乗客を指定することができる。性別選好により、顧客は、特定の性別のドライバーを選択することができる。「話す言語」という選好により、顧客は、特定の言語を話すドライバーを選択することができる。「アクセシビリティ選好」により、顧客は、特殊なアクセシビリティを備えた車両を有するドライバーについての選好をプリセットすることができる。「医療デバイス稼動性」という選好により、顧客は、運輸車両が特定の設備（例えば、酸素タンクまたは他の医療デバイス）を備えていることを確認することができる。「ペット対応」という選好により、顧客は、ペットに対応可能なサービスリクエストについての選好をプリセットすることができる。「ベビーシート稼動性」という選好により、顧客は、ベビーシートを提供することが可能なドライバーをリクエストすることができる。
【０１４０】
顧客は、ドライバーのサービスリクエストの特定の経路についての精通度についての選好情報も有し得る。ドライバーの精通度は、「直接的」精通度または「間接的」精通度であり得、どちらの精通度も、顧客デバイス１３０Ｃ１…１３０Ｃｎの関連する１つの上の顧客インターフェースを通じて顧客へ伝達され得る。直接的精通度は、例えばドライバーがピックアップ場所から下車場所までの経路についてどれくらい精通しているかの計算であり得る。間接的精通度は、ドライバーがピックアップ場所と下車場所との間の経路についてどれくらい精通しているかの計算であり得るが、経路については断片的な経験しかないことを示す。例えば、２人のドライバーは、所与の経路について１００パーセント（１００％）の精通度を有し得るが、経験は異なり得る。第１のドライバーは、ピックアップ場所から同一下車場所までの同一経路についてサービスを提供してい得る。このような経験は直接的精通度を構成し、マッチする経路についての１００％格付けに加えて、このドライバーが同一経路を用いてサービスを提供したことを示す数または階層によって示される。第２のドライバーは、過去異なる顧客に対して経路の一部に対してサービス実行をしたことがあり得、別のサービスリクエストに対して経路の別の部分に対してサービス実行をしたことがあり得る。この第２のドライバーがサービスリクエストに対して経路全体長さを横断した場合でも、同一ピックアップ場所から同一下車場所までとは異なる。よって、この第２のドライバーは、そのサービスリクエストの経路について間接的精通度を有する。
【０１４１】
リクエストされた経路についての精通度は、直接的なものであれあるいは間接的なものであれ、リクエストされた経路と、同一ドライバーが前回完了したサービスリクエストの経路とを比較することと、リクエストされた経路のうち全てまたは任意の部分がドライバーが以前完了した経路に対して共通する度合いを追跡することとを行うことにより、計算され得る。リクエストされた経路についてのドライバーの精通度は、リクエストされた経路の任意の部分がＧＰＳ信号が弱いかまたは全く無い領域内に存在する場合および／またはサービスリクエストが暗くなってから発生したものであるため、ナビゲーション方向の追随がより困難になる場合に特に重要になることが理解される。各ドライバー上のＧＰＳデータの自動化追跡と、データベース１０８中のこのようなデータの連続的な保存および更新とを用いて、ドライバーの所与の経路に関する精通度レベルを確認することができることが理解される。
【０１４２】
システムのカスタマイズは、顧客の選好およびドライバーの制限に部分的に基づく。本明細書中に記載される選好の概念は、サービスリクエストに対して特定の条件を課すオプションを顧客に付加することに関連する。当業者であれば、「選好」という用語は、この概念をいかようにも制限しないことが理解される。他の用語（例えば、「条件」、「フィルタ条件」（単数または複数）または「視覚」）が代わりに用いられ得る。「制限」という用語も、サービスリクエスト受諾についてドライバーが制限を課すことを可能にする概念をいかようにも制限しない。「制限」または「境界」などの用語は、「制限」の代わりに用いられ得る。さらに、「選好」および「制限」などの用語は、相互に対照的に用いられ得、この対照性は、顧客とドライバーとの間のユーザ種類の差を伝達することを意図しており、根本的に対照的な概念としての「選好」および「制限」の代わりになはらない。選好を有する顧客は、制限も有し得、制限を有するドライバーも特定の選好を有し得ることが理解される。
【０１４３】
ドライバーに対するサービス制限を非限定的に挙げると、制限に関連するサービス時間、帰還場所および時間、サービス領域、アクセシビリティ、乗客数、アレルギー、ベビーシート制限および他の任意の関連制限がある。サービス時間制限により、ドライバーは、自身サービスを提供することができない時間をプリセットすることができる。帰還場所および時間制限により、ドライバーは、特定の時間に自身が存在したい特定の場所をプリセットすることができる。サービス領域制限により、ドライバーは、（例えば郵便番号、行政区、市町村、州などに基づいて）サービス提供を行いたくない場所として１つ以上の地理的ゾーンをプリセットすることができる。ドライバーは、ドライバーデバイス１３２Ｄ１…１３２Ｄｎのうち関連する１つのドライバーインターフェース上の対話マップを通じて、地理的ゾーンについて制限を設定し得る。ドライバーは、マップ上の郵便番号をクリックして、サービス提供を行いたくない場所を決定することができる。地理的場所の選択についてのこのようなドライバー制限は、サービスリクエストが以下の図６〜図９を参照して述べるようなグループ中のドライバーへバッチおよび分散される実施形態において必要になり得る。
【０１４４】
例えば、ブルックリンにいるドライバーは、ブルックリン内の郵便番号を反映するサブセクションに分割された行政区マップを確認し得る。ドライバーは、それぞれをクリックして、特定のサービス領域を示し得る。クリック可能なマップインターフェース（すなわち、対話マップインターフェース）により、ドライバーは、自身の固有の用語について自身の制限を迅速かつ効率的に設定することができる（例えば、ドライバーが自身が働きたい地域を選択することを可能にすることができる）。本発明の例示的実施形態によれば、１人のドライバーのクリック可能なマップは、別のドライバー（例えば、パートナードライバー）のクリック可能なマップと追加的にまたは代替的に統合され得る。ドライバーおよびパートナードライバーのサービス領域を組み合わせることにより、コンピューティングシステム１００は、派遣担当者に対し、ドライバーおよびドライバーのパートナードライバーがサービスを提供することができる場所の範囲を生成および表示することができる。個人的な場所制限に加えて、ドライバーは、自身の勤務シフトに関連して個人的な時間制限をプリセットし得る。コンピューティングシステム１００は、郵便番号を行政区または国、町、市町村または州にグループ分けし、データベース１０８中のマッピングデータにグループ分けし得る。コンピューティングシステム１００が郵便番号または他の場所制限情報を特定した後、派遣マトリックス３２２および派遣出力３３０の生成の際に関連場所制限のあるドライバーをスキップすることができるため、ドライバー制限を含む領域に関与する当該ドライバーへはサービスリクエストは送られなくなる。当業者であれば、本明細書中に記載のドライバーのサービス制限のリストは排他的なものではなく、ドライバーは、自身のサービスに関連する他の制限を有し得ることが理解される。
【０１４５】
場所に関連する制限は、ドライバーが最終的にサービス提供と共に終了する場合に大きく影響し得る。本発明の例示的実施形態により、異なる規定された領域をスケジュールサービスリクエストに対して用いた効率的な派遣システムが可能になることが理解される。サービスリクエストが行われる場所は、スケジュールされる時間に関連し、領域別にグループ分けすることが可能であるため、コンピューティングシステム１００は、サービスリクエストが行われる場所（特に、スタート場所および終了場所）を特定することができる。現在の業界慣行においては、派遣はほとんどランダムに行われる。ニューヨークなどの大きな市町村においては、ドライバーは、ランダムな場所へランダムに派遣され得る。サービスリクエストを地理的領域別にグループ分けし、ドライバーを追跡することにより、派遣担当者は、サービスリクエストの事前スケジュールをずっと効率的に行うことができ、ドライバーは、サービスリクエストの完了をより短時間で行うことができる。
【０１４６】
ここで図５を参照して、サービス提供者（例えば、ドライバー）と、顧客との間の価格交渉の例示的ワークフローが図示される。本発明のこの例示的実施形態において、顧客は、サービスリクエストに対して提案価格をシステムへ提出し得る（ステップ５０１）。顧客の提案価格はデフォルト価格に基づき得、１つ以上のプロセッサは、提案価格がデフォルト価格よりも高いか、低いかまたは等しいときを決定し得る。運輸サービスのデフォルト価格は、送達サービスのデフォルト価格と異なり得る。顧客がサービスの組み合わせをリクエストすると、デフォルト価格は、運輸サービスおよび送達サービスそれぞれについてデフォルト価格から導出され得る。
【０１４７】
簡潔さのため、図５は、顧客が運輸サービスの価格を提案するシナリオのみを示す。システムは、顧客が任意のお気に入りのサービス提供者（または任意の利用可能なお気に入りのサービス提供者）を有するかまたは有さないかに応じて、顧客が提案価格の送り先としたい者について顧客へクエリを送る（決定５０２）。利用可能なお気に入りのサービス提供者が存在する場合、顧客は、価格提案をこれらの利用可能なお気に入りのサービス提供者のうち１人以上へ送るかを決定し得る（決定５０３）。顧客が価格提案をお気に入りのサービス提供者のうちいずれかへ送りたい場合、顧客は、自身の提案価格がお気に入りのサービス提供者と交渉可能か否かについてさらに決定する（決定５０４）。お気に入りのサービス提供者が存在しない場合、お気に入りのサービス提供者が利用できない場合、または顧客が自身の提案価格をお気に入りのサービス提供者のうちいずれにも送りたくない場合、顧客は、自身の提案価格が任意の選好されるサービス提供者またはレギュラーのサービス提供者（単数または複数）と交渉可能か否かについて決定し得る（決定５０５）。１人以上のサービス提供者と交渉しているかまたは交渉していないかに関係無くこのプロセスが確立された後は、このプロセスは、サービス提供者がお気に入りのサービス提供者またはレギュラーサービス提供者であるかに関係無く同じである。
【０１４８】
顧客が自身が交渉可能であるとみなした価格を設定すると、サービス提供者に対し、その旨が通知される（ステップ５０６）。次に、交渉すべきか否かがサービス提供者が決定される（決定５０７）。サービス提供者は、交渉可能な価格提案について３つのオプションを有する。サービス提供者がサービスリクエストを全くとりたくない場合、サービス提供者は、交渉およびリクエスト双方を拒否し、リクエストは期限切れになる（ステップ５０８）。サービス提供者が交渉はしたくないがサービスリクエストは提供したい場合、サービス提供者は、元々の交渉可能な価格をそのまま受託し（ステップ５１３）、その後、派遣される（ステップ５１４）。サービス提供者にとって利用可能な第３のオプションは、価格を交渉することである。サービス提供者は、カウンターを作製し（ステップ５０９）、このカウンターは顧客へ送られる。次に、顧客は、カウンターを受諾するかを選択し得る（決定５１０）。顧客がカウンターを受諾すると、サービス提供者は、システムによって派遣される（ステップ５１４）。顧客がカウンターを受諾しない場合、顧客はカウンターに対してカウンターし（ステップ５１１）、交渉はサービス提供者までサイクルバックする。次に、サービス提供者に対し、カウンター価格を受諾するかの決定が提示される（決定５１２）。サービス提供者がカウンター価格を受託すると、サービス提供者が派遣される（ステップ５１４）。サービス提供者がカウンターを受諾しない場合、サービス提供者は、顧客のカウンターにカウンターする（ステップ５０９）。サービス提供者および顧客双方が価格に同意するまでプロセスが繰り返され、同意が得られると、サービス提供者が派遣される（ステップ５１４）。
【０１４９】
顧客が交渉不可能とみなす価格を設定した場合、リクエストは、顧客のお気に入りのサービス提供者（または（顧客が利用可能なサービス提供者を自身のお気に入りリスト上に持たない場合は）他の任意のサービス提供者）へ経路設定され、当該サービス提供者は、交渉不可能な価格を受諾するかまたは受諾しない（決定５１５）。サービス提供者が交渉不可能な価格を受諾した場合、当該サービス提供者が派遣される（ステップ５１４）。サービス提供者がリクエストを受諾しない場合、顧客が提案した価格ではサービスリクエストが受諾されなかった旨が顧客に通知される（ステップ５１６）。次に、顧客は、通知を受けると、元々のサービスリクエストを訂正し、新規の価格提案を再提出する（ステップ５０１）。
【０１５０】
当業者であれば、図５は、サービス提供者と顧客との間の価格交渉の多数の可能なシナリオのうち１つを示しているだけであり、本システムは、サービス提供者または顧客いずれかから初期価格提案を受信し得ることが理解する。よって、初期価格提案は、顧客およびサービス提供者双方からカウンターされ得る。加えて、当業者であれば、本明細書中のに記載のプロセスは排他的なものではなく、所望の結果を達成するための特定の順序は不要であることを理解する。
【０１５１】
ここで図６を参照して、バッチ（すなわち、複数の）未割当のサービスリクエストの事前スケジューリングのための例示的方法を示すフローチャートが図示される。複数のサービスリクエストが、コンピューティングシステム１００によって受信され得る（例えば、顧客／乗客によっておよび／またはサードパーティベンダー（例えば、運輸サービスを必要とする患者の代理の保険会社））によってアップロードされ、識別番号（ＩＤ）が割り当てられる（ステップ６００）。このようなアップロードは、顧客コンピューティングデバイス１３０Ｃ１…１３０Ｃｎのうち１つ以上を用いて顧客が行ってもよいし、顧客またはサードパーティベンダーがベンダーデバイス１２６を用いてウェブインターフェースを通じて電子的に行ってもよいし、かつ／またはサービスリクエスト（単数または複数）および関連付けられたスケジュールを電話、テキストメッセージ、ｅメールまたは紙コピーを受領した後に派遣担当者が派遣担当者デバイス１３６を用いて手動で行ってもよい。あるいは、システムは、対話声認識（ＩＶＲ）技術および／またはボイスツーテキスト技術を用いて、サービスリクエストを従来の電話システムを介して自動受信してもよい。
【０１５２】
適切な場合、各サービスリクエスト３００は、行程の各部位（例えば、ピックアップ場所（単数または複数）、下車場所（単数または複数）など）に対応するレッグに分解される（ステップ６２０）。サービスリクエストは、場所Ａにおけるピックアップおよび場所Ｂにおける下車ならびにその後の場所Ｂにおけるピックアップおよび場所Ａにおける下車からなり得る。しかし、サービスリクエストは３本以上のレッグおよび／または異なるピックアップおよび下車場所を含んでもよく、その日にわたって分散し得ることが理解される。例えば、サービスリクエスト３００は、顧客の自宅（場所Ａ）、病院（場所Ｂ）および職場（場所Ｃ）を含み得、３本のレッグＡ〜Ｂ、Ｂ〜ＣおよびＣ〜Ａを含み得る。これら３本のレッグは、経時的に発生し、異なる期間を挟んで設けられる。サービスリクエストと、そのレッグと、これらと関連付けられた全情報（例えば、各レッグのピックアップ場所および下車場所に対応する郵便番号、および任意の必要なピックアップ時刻および／または下車時刻）とが、データベース１０８中に保存され得る。
【０１５３】
派遣担当者は、派遣担当者デバイス１３６を用いて、特定の地域（例えば、ニューヨーク市の５つの行政区のうちの１つ）と、コンピューティングシステム１００中の未割当のサービスリクエストへドライバーを割り当てることを望む特定の日付（例えば、同日、翌日、本日から数日後、本日から１週間後など）とを指定することができる。（ステップ６１０）。あるいは、コンピュータシステム１００は、リクエストされたサービス日付よりも所定の日数前にサービスリクエストを自動的にバッチおよび割り当てるようにプリセットされてもよい。例えば、コンピュータシステム１００は、８月１８日にスケジュールされたサービスリクエストに対してバッチされた割当プロセスを８月１７日に行うようにプリセットされ得る。派遣担当者は、派遣担当者デバイス１３６上のインターフェースを介して、コンピューティングシステム１００中の受諾された未割当のサービスリクエストの（経時的のまたは他の場合にその各サービスリクエスト日付別の）リストを視認し得る。派遣担当者またはコンピュータシステム１００は、未割当のサービスリクエストがコンピューティングシステム１００中に残留している最も早い日付と共に単純に開始し得る。コンピューティングシステム１００は、特定の日付（例えば、任意の未割当のサービスリクエストがシステム中に残留している最も早い日付）および当該日付においてスケジュールすべき第１の地域（例えば、マンハッタン、クイーンズなど）を自動的に選択するようにも構成され得る。
【０１５４】
特定の日付および特定の地域を受信した後、コンピューティングシステム１００は、未割当のサービスリクエストのバッチを保存された複数のアップロードされた未割当のサービスリクエストから受信する（ステップ６３０）。未割当のサービスリクエストの検索されたバッチは好適には、特定の指定地域内に収まるピックアップ場所および下車場所と共に（または特定の指定地域内に収まる各ピックアップ場所および下車場所のうち少なくとも１つと共に）レッグをを有し、その特定の日付のリクエストされたピックアップ時刻および／または下車時刻を有する（指定日付）（ステップ６２０）。コンピューティングシステム１００は、未割当のサービスリクエストのバッチと関連付けられた複数の顧客に対応する顧客情報と、潜在的な１組のドライバーに対応するドライバープロファイルとを取り出して、特定の地域および特定の指定日付に基づいてバッチを割り当てる。顧客情報は、顧客ＩＤ番号または名前、サービス選好、お気に入りリスト、選好リストおよびブラックリストを含み得る。ドライバープロファイルは、１つ以上のサービス制限、サービス履歴、お気に入りリスト、ブラックリストおよび履歴データを含むドライバー情報を含み得る。
【０１５５】
コンピューティングシステム１００は、バッチの未割当のサービスリクエストについての潜在的な１組のドライバーの稼動性および適合性を特定し得（ステップ６４０）、ドライバーをバッチの複数の未割当のサービスリクエストへ割り当て得る（ステップ６５０）。システムは、派遣日の受信の前にステップ６４０および６５０を実行することができるため、ドライバーは、サービスリクエストへ予備的に割り当てられ、派遣担当者からの特定の派遣日の受信の前にアルゴリズムにより動的に更新される（ステップ６５０）。この時点にいて、システムは、指定された派遣日の提案スケジュールを印刷する。図示のように、各割当は、事前に計画された次のサービスリクエストに対する特定のドライバーの稼動性を変化させる可能性があるため、コンピューティングシステム１００は、利用可能なドライバーおよび適合するドライバーの特定と、ドライバーの割り当てとの間でサイクルする（ステップ６４０、６５０）。ドライバーの稼動性は、ドライバーのプリセット制限と、未割当のサービスリクエストのピックアップ時刻におけるドライバーの推定場所とに基づいて評価され得る（例えば、ドライバーは、データベース１０８に保存された先行サービスリクエストレッグに既に割り当てられている場合がある）。その場合、このドライバーの下車場所および下車時刻により、未割当のサービスリクエストへのサービス提供においてドライバーが利用可能であるか否かが分かる。
【０１５６】
例えば、先に割り当てられたサービスリクエストの最終レッグがおよそ時間Ｔ１において場所Ｘ１にて下車したいとのリクエストを有し、第１のレッグがおよそ時間Ｔ２において場所Ｘ２においてピックアップして欲しいとのリクエストを有する場合、場所Ｘ１およびＸ２が相互に比較的近い場合（例えば、同じ郵便番号内に有る場合）でありかつ時間Ｔ１およびＴ２が時間的に比較的近接している場合、ドライバーは、（例えば保存されたトラフィックおよびマップデータ３２６を用いた移動時間推定に基づいて）時間Ｔ１においてＸ１から時間Ｔ２においてＸ２へ移動する時間があり、このドライバーは、コンピューティングシステム１００によって未割当のサービスリクエストについて利用可能とみなされ得る。このようにして、顧客およびドライバーの選好／制限を考慮した後、コンピューティングシステム１００は、サービスリクエストをドライバーへ効率的に割り当てることができる。
【０１５７】
バッチの未割当のサービスリクエストについての潜在的な１組のドライバーの適合性の評価は、１つ以上のアルゴリズムまたは基準に従って、例えば（本明細書中に記載のような）ブラックリスト上のドライバーの存在、お気に入りリストまたは顧客の選好リストに基づいて行われる。好適な実施形態において、顧客のお気に入りリスト上の利用可能なドライバーに対して最高の優先順位が付与された後、利用可能なドライバーが顧客の選好リスト上に記載される。顧客のブラックリスト上の利用可能なドライバーは、当該顧客のサービスリクエストへの割り当てから排除される。顧客のお気に入りリストの利用可能なドライバー全員および（必要な場合に）選好リストが、コンピューティングシステム１００によって潜在的な割当としてレビューおよび検討される。
【０１５８】
コンピューティングシステム１００は、ドライバーを所定のアルゴリズムに従って割り当てる（ステップ６５０）。コンピューティングシステム１００は、第１のサービスリクエストと共に開始し得、場所、時間、矛盾、ブラックリスト、行程矛盾などについてドライバー制限をチェックし得、非稼動性、ブラックリスト、ピックアップ時刻において予測される地理的場所、ランチ休憩の予測または停止時間あるいは他の任意の理由に起因して未割当のサービスリクエスト対してサービス提供ができないドライバーを全て除外する。次に、コンピューティングシステム１００は、排除されていないドライバーが他にいないかチェックして決定する（（例えば、ピックアップ時刻および日付において利用可能でありかつピックアップ場所に合理的に近接していることが予測されるドライバー）が顧客のお気に入りのリストまたは選好リストに記載されているか）。そのような場合、このようなドライバーに対して高い優先順位が付与され得る。
【０１５９】
任意選択的に、クライアントの満足最大化のための主要基準として適合性を用いて、ステップ６５０において同一のドライバーがサービスリクエストの全レッグに対して割り当てられ得る。しかし、サービスリクエストの第２のレッグ（例えば、帰還レッグ）が、第１のレッグへ割り当てられたドライバーと異なるドライバーによってサービスされる可能性があることが理解される。あるいは、コンピューティングシステム１００は、（第１のドライバーの状態を２本のレッグの間の数時間にわたって「利用可能」として同時に保持しながら）第１のドライバーを第１のサービスリクエストの第２のレッグへ割り当て得、その後（コンピューティングシステム１００がバッチのサービスリクエストについて確認した結果、第１のドライバーが適合およびマッチするものが発生した場合に）第１のドライバーを当該利用可能な期間において別のサービスリクエストの別のレッグへ割り当て得る。コンピューティングシステム１００は、顧客およびドライバー選好および制約を固守しつつ、サービスリクエストの異なるレッグに対して１人以上のドライバーを予約するように構成され得る。
【０１６０】
ドライバーが乗客を持っているシフトの時間全体により、ドライバーの待機時間が最小限になり、ドライバーに対する仕事の事前スケジュールが自動的に増加し得ることが理解される。また、キャンセル、遅延または他の問題に起因して状況が発生した場合にドライバーの派遣およびワークフローを動的に更新することができることも理解される。サービスリクエストの受諾、グループ分けおよび派遣が時間に先駆けて行われると、ドライバーの仕事スケジュールが事前に完全に埋められ、コンピューティングシステム１００は、顧客およびドライバーの必要性をまかないつつ、効率を最大化させ、ドライバー稼動性の変化と共に（例えば、ドライバーから病気の電話が入る、時間帯変更の連絡があるのと共に、など）スケジューリングを動的に更新することができる。
【０１６１】
コンピューティングシステム１００は、ドライバーに割り当てられていないバッチの残りのサービスリクエスト全てをステップ６５０において用いられるアルゴリズム／基準に従って（複数の利用可能なドライバーがリモートドライバーコンピューティングデバイス１３２Ｄ１…１３２Ｄｎを通じてアクセスすることが可能な）ジョブプール中に保存するように構成され得（ステップ６６０）、これにより、ドライバーは、残りの未割当のサービスリクエストから少なくとも１つを選択することができる。コンピューティングシステム１００は、単一のドライバーが選択することが可能なジョブプール中の未割当のサービスリクエストの数を制限することができる。
【０１６２】
図１０に示すように、ジョブプールの未割当のサービスリクエストは、ドライバーがドライバーデバイス１３２Ｄ１…１３２Ｄｎを介してアクセスすることが可能なクリック可能な電子マップディスプレイ１０００を介して、表示され得る。電子マップディスプレイ１０００は、６つの区分（すなわち、Ｉ、ＩＩ、ＩＩＩ、ＩＶ、ＶおよびＶＩ）別に記録されるような異なる地理的領域を表示し得る。これらの地理的領域は、例えば、未割当のサービスリクエストピックアップおよび下車場所が含まれる複数のローカル地域に対応する。未割当のサービスリクエストは、クリック可能インジケータ１０１０として表示され得る。「星」が図示されているが、任意の種類の形状、アイコン、文字または画像が用いられ得、１つよりも多くの種類のインジケータが異なるものまたはフィーチャを指示するために用いられ得ることが理解される。ドライバーは、ドライバーデバイス１３２Ｄ１…１３２Ｄｎのうち関連する１つを介して複数の区分Ｉ〜ＶＩのうち１つを選択（例えば、クリック）しかつ／またはクリック可能インジケータ１０１０のうち１つ以上を選択して、割当領域または対応する未割当のサービスリクエストをリクエストし得る。ドライバーは、このようなマップ表示１０００を用いて、サービスについての自身の初期制限または他の事前設定も指定し得る。例えば、ドライバーは、１日以上についてのデフォルト設定として、６つの区分Ｉ〜ＶＩのうち１つを選択することにより、コンピューティングシステム１００中の選好ワーキングエリアを指定し得る。ドライバーのデフォルト選好ワーキングエリアは、ドライバーの自宅住所に対応するものにおいて設定され得る。
【０１６３】
再度図６を参照して、特定のドライバーが充分なサービスリクエストに割り当てられかつ指定された日付において残っているドライバーの稼動性が最小である場合、コンピューティングシステム１００は、ドライバーの事前に計画された行程の概要をレビューおよび同意のために送り得る（ステップ６７０）。ドライバーは、スケジュール中の各サービスリクエストを受諾または拒否し得る。ドライバーへのこのような通知およびドライバーによる同意は、例えばサービスリクエストに対するサービス実行日として指定された日付の数日前またはさらには数週間前に発生し得るが、このような通知は、スケジュールされた日付に近い時期またはさらには開始時に提供されてもよい。
【０１６４】
顧客は、ドライバーを自身のお気に入りリスト、選好リストまたはブラックリストへいつでも追加することができ、ドライバーも、顧客をドライバーのブラックリストまたはお気に入りリストに追加することができる（ただし、お気に入りに追加されており、顧客がリクエストに同意した場合）。このような追加は、例えば、バッチの事前に計画されたサービスリクエストの完了後に行われ得る。ユーザは、以前のドライバーおよび顧客のプロファイルを視認し、お互いのお気に入りリストに記載してもらえるようリクエストを送り得る。検索機能が、顧客およびドライバーのアカウントを見つけるために設けられ得る。ドライバーのブラックリストへの顧客の追加または顧客のブラックリストへのドライバーの追加は、相互の通知または同意と共に行ってもよいし、行わなくてもよい。このように当事者への通知無しにブラックリストの一方向の許可を行うと、顧客とドライバーとの間の対立またはぎこちなさの回避が支援されることが理解される。双方のドライバーが同意した場合にドライバーは、パートナードライバーをいつでも追加することができる。
【０１６５】
ドライバーが事前に計画されたサービスリクエストを拒否（またはキャンセル）した場合（ステップ６７０）、コンピューティングシステム１００は、マイクロ派遣システムおよび／またはプロセスに関与するように構成され得、ドライバーがキャンセルされると、キャンセルされた事前に計画されたサービスリクエストがパートナードライバーへ派遣される。このようなパートナードライバーが利用可能でありかつ受諾した場合、コンピューティングシステム１００は、パートナードライバーを割り当て得る（ただし、パートナードライバーが顧客のブラックリストに記載されていないまたは逆の場合）。このようなパートナードライバーは、例えばドライバーがサービスリクエストを受諾したがピックアップ場所へ定刻通りに到着することができない場合にも、利用され得る。ドライバーは、サービスリクエストレッグを自身のパートナードライバーへ送り得る（ただし、コンピューティングシステム１００がパートナードライバーの顧客との適合性に基づいてこれをを許可した場合）。各ドライバーは、複数のパートナードライバーをマイクロ派遣システムおよびプロセス中に有し得る。ドライバーに対し、ドライバーがキャンセルしている事前に計画されたサービスリクエストを別の非パートナードライバーへ転送するオプションが付与され得、コンピューティングシステム１００は、キャンセルされた事前に計画されたリクエストを他のドライバーへ割り当て得る（ただし、この他のドライバーが受諾し、利用可能でありかつ顧客と適合するとみなされる（例えば、顧客のブラックリストに記載されていない）場合）。
【０１６６】
ドライバーが任意の事前に計画された割当を拒否した場合（ステップ６７０）、コンピューティングシステム１００は、キャンセルされた期間のドライバーの状態およびサービスリクエストの状態双方を「割り当て済」から「未割当」へ切り換えることができ、上記した同じ基準／アルゴリズムを用いて、別のドライバーをサービスリクエストのために特定および割り当てることができる（ステップ６８０）。データベース１０８中に保存された事前に計画されたドライバー割当を動的に更新し、ドライバーを再度割り当てることができる（ステップ６８０）。ドライバーが特定のサービスリクエストを自身のスケジュール上において拒否した場合、コンピューティングシステム１００は、この拒否されたサービスリクエストをジョブプールに追加し得る（ステップ６６０）か、または、サービスリクエストをパートナードライバーへ自動的に再度割り当て得る（ただし、このようなパートナードライバーが利用可能である場合）。ジョブプールは、ドライバーが自身へ送られてきたサービスリクエストのスケジュールについて全体的または部分的に同意または拒否する際に動的にかつ連続的に更新され得る。このような更新は、データベース１０８中に保存され得る。
【０１６７】
特定の実施形態において、コンピューティングシステム１００は、ドライバーが任意の事前に計画されたサービスリクエストまたはそのレッグをを拒否した場合、そのドライバーは優先順位を失い得るように構成され得る。顧客選好およびドライバー制限に基づいて、コンピューティングシステム１００は、未割当のサービスリクエストについて適合するドライバーを迅速に特定し得ることが理解される。例えば、制限無しのドライバーおよび選好情報無しの顧客は、適合するためマッチするものとして特定され得る。あるいは、任意の設定（例えば、ドライバー制限、顧客選好など）が相互に矛盾する場合、ドライバーおよび顧客は、適合しないものとしてみなされ得、マッチングから外される。サービスリクエスト詳細、ドライバーの制限および顧客の選好の包括的開示により、顧客およびドライバー双方の経験が向上することも理解される。
【０１６８】
ここで図７Ａ〜図７Ｂを参照して、本発明の例示的実施形態による複数の（またはバッチ）の事前に計画されたサービスリクエストを割り当てるための第１の例示的アルゴリズムを示すフローチャートが図示される。未割当のサービスリクエストの潜在的な１組のドライバーおよびバッチが指定された日付および地理的場所についてコンピューティングシステム１００により（例えば図６のステップ６３０において）取り出されると、当該バッチ中の未割当のサービスリクエストをサイクルすることと、できるだけ多くのドライバーへ割り当てることのプロセスが開始される（ステップ７００）。好適には、ドライバーがジョブを受諾したいと思う地理的領域についてのプリセット制限バッチ型サービスリクエストを持たなければならない場合、潜在的な１組のドライバー中のドライバーが検討される。
【０１６９】
バッチの第１の未割当のサービスリクエストと、これに対応する関連付けられた顧客と、指定された日付についての任意のピックアップ場所および／または下車場所および／または時間要求とが特定される（ステップ７１０）。潜在的な１組のドライバー（指定された日付に基づいて初期に検索されたもの、派遣担当者またはシステムによって指定された地域）がレビューされ、顧客のブラックリストに記載されている潜在的な１組のドライバーのうちいずれかが除外され、顧客を自身のブラックリストに記載している者が除外される（ステップ７１２）。次に、残りの潜在的な１組のドライバーのいずれかがサービス未割当のサービスリクエストに対して利用可能であるかが決定される（ステップ７１４）。稼動性は、ドライバーのプリセット制限と、上記したような未割当のサービスリクエストのピックアップ時刻よりも前にドライバーがいると推定される場所との双方に基づいて評価され得る。例えば、時間Ｔ内に場所Ｘ１から場所Ｘ２へ移動する必要のあるドライバーは、データベース１０８中に保存された履歴トラフィックおよびマップデータ３２６に基づいてこれを行うことができるが、各サービスリクエストの異なるレッグ間にどれくらい遠くまえ移動できるかについてのプリセット制限を有し得る。ドライバーが利用できないとみなされた場合、このドライバーの状態は「利用付加」に設定され、このドライバーは、この特定の未割当のサービスリクエストに対する潜在的な１組のドライバーから除外される。潜在的な１組中のドライバーのうち利用可能とみなされる者がいない場合、サービスリクエストはジョブプール７１６へ送られる。ジョブプール７１６において、このリクエストは、本明細書中に記載のように他の利用可能なドライバーによってビューおよび潜在的に選択され得る。割当プロセスは再度開始され（ステップ７００）、バッチの第２の未割当のサービスリクエストと、第２のサービスリクエストと関連付けられた新規顧客、場所、および時間情報とが特定される（ステップ７１０）。
【０１７０】
コンピューティングシステム１００が当該ドライバーが利用可能であるとみなした場合（ステップ７１４）、利用可能なドライバーのうちいずれかが特定の顧客のお気に入りリストに記載されているかが決定される（ステップ７１６）。次に、単一のお気に入りのドライバーのみまたは複数のお気に入りのドライバーが利用可能であるかが決定される（ステップ７１８）。お気に入りのドライバーが１人しか利用可能でない場合、単一のお気に入りのドライバーが未割当のサービスリクエストへ割り当てられる（ステップ７２０）。次の未割当のサービスリクエストが処理される（ステップ７１０）。ドライバーが先に割り当てられたサービスリクエストを実行しているときに第２のサービスリクエスト割当を受けた場合、ドライバーは、第２のサービスリクエストを顧客選好に応じて受諾し得る。例えば、帰還場所をプリセットしたドライバーは、この第２のサービスリクエストの下車場所および下車時刻がドライバーの帰還場所および時間に適合するため、この第２のサービスリクエストについて喜んで待機し得る。好適には、コンピューティングシステム１００は、可能な場合に空レッグを回避するように構成され得、プリセット帰還場所およびプリセット帰還時間が顧客のサービスリクエストと共に調整されているドライバーを割り当てることができれば、ドライバーが他の場合に空であり得たサービスリクエストのレッグから利益を得ることが可能になるため、有用である。
【０１７１】
複数のお気に入りのドライバーが利用可能である場合、コンピューティングシステム１００は、複数のお気に入りのドライバーをレビューして（ステップ７２２）、最も経験豊富なドライバーを決定する（例えば、ステップ６３０において受信された履歴データによって示されるように、この顧客に対してこの顧客に対して今まで行われたサービスリクエストの合計数について決定する）（ステップ７２４）。データベース１０８中に保存されたこのような履歴および他のデータは、本明細書中に開示されるプロセス多様なステップにおいて検索され得ることが理解される。最も経験豊富なお気に入りのドライバーが、未割当のサービスリクエストへ割り当てられる（ステップ７２６）。
【０１７２】
複数の最も経験の豊富なお気に入りのドライバーが決定された場合（ステップ７２４）、コンピューティングシステム１００は、（例えば、場所ｓＸ１、Ｘ２ならびに時間Ｔ１およびＴ２について上記例において述べたように）指定された日付のピックアップ時刻における推定される場所から未割当のサービスリクエストの指定されたピックアップ場所までにかかる最短推定時間に基づいて、これらのドライバーのうち最も近くにいるであろうドライバーを決定し得る。次に、最も近隣の経験豊富なお気に入りのドライバーが未割当のサービスリクエストへ割り当てられる。ドライバーがリクエストへ割り当てられた後（ステップ７２６）、次の未割当のサービスリクエストが処理される（ステップ７１０）。
【０１７３】
残りの潜在的な１組のドライバーのいずれも顧客のお気に入りリストに記載されていない場合、残りの潜在的な１組のドライバーのうちいずれかが顧客の選好リストに記載れてているかが決定される（ステップ７３２）。好みのドライバーが１人しか利用可能ではなかった場合（ステップ７３４）、この１人の好みのドライバーが未割当のサービスリクエストへ割り当てられる（ステップ７３６）。複数の好みのドライバーが利用可能である場合（ステップ７３８）、コンピューティングシステム１００は、最も適合するかまたは最も経験豊富な好みのドライバーを決定し得、顧客のプリセット選好とドライバーおよびドライバーの車両の多様な属性または制限との間のマッチ数に基づいてドライバーを選択し得るおよび（ステップ７４０）。この最も適合するかまたは最も経験豊富な好みのドライバーは、未割当のサービスリクエストへ割り当てられる（ステップ７４２）。履歴データを用いて、顧客のために今まで行われたサービスリクエストの合計数に基づいて、これらの好みのドライバーのうち顧客にとって最も経験豊富ドライバーを決定することができる。
【０１７４】
顧客のプリセット選好と、ドライバーのプリセット選好／制限との間の属性マッチを挙げると、例えば以下がある：車両種別、車両サイズ、色、型式、モデル、年式、ツードア、フォードア、国籍、運転年数、車両種類、車両の型式およびモデル、車両座席定員、車両空間容量、車両重量容量、車椅子のアクセシビリティ、ベビーシート稼動性、ペット対応、ドライバーの言語能力、ドライバーの性別、ドライバーの運転経験、ドライバーの経路精通度、ドライバーの特定の種類の物品を取り扱った経験、または壊れ物または他の特殊なパッケージングまたは送達方法を要する物品への対応、または他の任意の属性または選好がある。これらのマッチした属性の数は、（好みのドライバーが顧客のために行った以前の行程数ではなく）好みのドライバーを未割当のサービスリクエストへ割り当てる際の基準となり得る。また、複数の利用可能な好みのドライバーのうち１人を選択する際に用いられる基準またはアルゴリズムは、これらの概念の組み合わせを用い得ることが理解される。例えば、顧客にマッチする最高の選好を有する好みのドライバに対し、所与の優先順位が付与された後、当該顧客に対して最も多く今までの行程を有するドライバーに優先順位が付与され、他の場合に２人以上の好みのドライバーがこれらの基準に基づいて等しく適合するとみなされた場合、場所および時間に基づいて最も近隣にいると推定されるドライバーが割り当てられ得る。
【０１７５】
お気に入りのドライバーまたは好みのドライバーが全く利用できない場合、未割当のサービスリクエストは、レギュラードライバーとしてカテゴリー分けされたドライバーへ割り当てられ得る（ステップ７４４）。コンピューティングシステム１００は、先ず、複数のドライバーが利用可能である場合に利用可能なドライバーが１人だけであるかを評価する（ステップ７４６）。レギュラードライバーが１人だけである場合（ステップ７４６）、この１人のレギュラードライバーは未割当のサービスリクエストへ割り当てられる（ステップ７４８）。複数の好みのドライバーが利用可能である場合（ステップ７４６）、コンピューティングシステム１００は、利用可能なレギュラードライバーをレビューし得（ステップ７５０）、最も適合するかまたは最も経験豊富なレギュラードライバーを決定し得（ステップ７５２）、顧客のプリセット選好と、ドライバーおよびドライバーの車両の多様な属性または制限との間のマッチ数に基づいてドライバーを選択し得る。この最も適合するかまたは最も経験豊富なレギュラードライバーが、未割当のサービスリクエストへ割り当てられ得る（ステップ７５４）。履歴データを用いて、顧客に対してまたは特定の領域内において今まで行われたサービスリクエストの合計数に基づいて、これらのレギュラードライバーのうち顧客に対して最も経験豊富である者を決定することができる。ドライバーのプリセット制限（または顧客の選好）のうちの１つにより、任意のステップにおいて特定のサービスリクエストへのドライバー割り当てが排除され得る。任意の理由により、利用可能なレギュラードライバーがいない場合（ステップ７４４）、コンピューティングシステム１００は、未割当のサービスリクエストをジョブプール中に保存し得る（ステップ７１６）。
【０１７６】
残りの複数のレギュラードライバーのうち２人以上が顧客に対して同数のサービスリクエストを行ったことが有る場合、コンピューティングシステム１００は、レギュラードライバーの推定される場所からサービスリクエストのピックアップ場所まで到達するまで推定される時間が最も短いドライバーに基づいて、最も近隣のドライバーを決定し得る。次に、コンピューティングシステム１００は、最も近隣でありかつ最も経験豊富なレギュラードライバーを未割当のサービスリクエストへ割り当て得る（ステップ７５４）。ドライバーがリクエストへ割り当てられてた後、（ステップ７４８または７５４）、次の未割当のサービスリクエストが処理される（ステップ７１０）。
【０１７７】
好適な実施形態において、顧客が複数のお気に入りのドライバーおよび／または複数の好みのドライバーを有する場合、顧客は、自身のお気に入りのおよび好みのドライバーと、各お気に入りのドライバーおよび各好みのドライバーについての特定のランキングとを任意選択的にプリセットする。ドライバーは、お気に入りの顧客または選好される顧客について特定のランキングを同様にプリセットし得る。例えば、顧客が自身のお気に入りリスト上においてお気に入りのドライバーを４人有する場合、顧客は、自身の４人のお気に入りのドライバーそれぞれに対応する第１、第２、第３および第５の顧客をプリセットとしてランキングし得る。顧客は、同一のお気に入りのランキングまたは選好されるランキングを用いて２人以上のドライバーをプリセットすることもできる。よって、複数のランキングシナリオが可能になることが理解される。第１のシナリオにおいて、分類されたお気に入りのおよび好みのドライバー／顧客に間の任意ののランキング無しに、分類（お気に入り、選好）がプリセットされる。第２のシナリオにおいて、ドライバー／顧客の分類およびランキング双方がプリセットされる。第３のシナリオにおいて、ドライバー／顧客の分類およびランキング双方がプリセットされ、分類内の２人以上のドライバー／顧客に対し、同一のランキングが付与される。第４のシナリオにおいて、顧客は、ドライバーの分類およびランキングを割り当てるが、１人以上のドライバーは、例えばランキング無しに分類を顧客へ割り当て得る。ランキングが同じの１人よりも多くのお気に入りのドライバーまたは好みのドライバーが利用可能である場合、システムは、サービスリクエストをランキングが同じこれらのドライバーのうち１人へランダムに割り当て得るか、または、本明細書中の多様な実施形態に記載のようなさらなる基準（例えば、顧客に対して行われた今までのサービスリクエスト数、経路についての精通度レベル）を用い得る。よって、システムは、先ずサービスリクエストの割り当ての際に顧客の利用可能なお気に入りのドライバーを確認し、お気に入りのドライバーのうち最も経験豊富であるかまたは最も近隣にいる者に関係無く、（複数のお気に入りのドライバーを特定した場合に）お気に入りのドライバーランク毎に割り当てるように構成され得る。お気に入りのドライバーが利用可能ではない場合、システムは、好みのドライバーランク毎に同様に割り当て得る。このようにして、顧客は、自身が望むドライバー割当の階層についてほとんど疑問を持たなくてすむ。
【０１７８】
システムは、割当の際に、ドライバーのお気に入りの顧客リスト選好される顧客リストに記載された顧客のドライバーの分類およびランキングを考慮するようにも構成され得る。換言すると、顧客のドライバーのランキングおよびドライバーの顧客のランキングは、ドライバーを顧客のサービスリクエストへマッチングさせる際にマッチング基準の一部として用いられ得る。しかし、ドライバーは一般的にはより多くの事業を望むため、好適な実施形態において、顧客の選好が優先されることが理解される。システムは、顧客サービスリクエストをドライバーへ割り当てる際、全てのプリセット情報を利用し得る。全てのプリセットデータが、１つ以上のウェブポータルまたはコンピューティングデバイス（例えば、１３０Ｃ１〜１３０Ｃｎ、１３２Ｄ１〜１３２Ｄｎ）を通じて行われ得る。顧客またはドライバーが設定を完了しない場合、代替的にまたは追加的に、デフォルト設定が用いられ得る。
【０１７９】
顧客は、特定のお気に入りのドライバーまたは好みのドライバーが指定された派遣日に利用できないかまたはキャンセルされた場合、パートナードライバーを自身のサービスリクエスト（単数または複数）へ割り当てることを許可するかについてさらにプリセットし得る。パートナードライバーについて、以下の図９を参照してさらに説明する。顧客は、パートナードライバーに自身のリクエストの取扱およびシステムにおけるこれのプリセットを全く任せたくない場合、システムは、ランキングを優先順位として用いておよび／または図７Ａ〜図９を参照して本明細書中に記載のアルゴリズムを用いて、お気に入りのドライバーおよび好みのドライバーをサイクルし得る。割り当てられた事前に計画されたドライバー（例えば、お気に入りのドライバーまたは選好されるドライバー）がキャンセルしたかまたは利用できない場合において、顧客がパートナードライバーに自身のサービスリクエストを取り扱ってもらいたくない場合、システムは、パートナードライバーを割り当て得る（ただし、顧客のブラックリストに記載されているかまたは顧客のサービスリクエストまたは選好の他の任意の要求を満たしていないため、パートナードライバーが顧客への割り当てから排除されていない場合）。事前に計画されたサービスリクエストについてパートナードライバーを割当に織り込む際に用いられる階層（例えば、システムが次に高いランキングのお気に入りのドライバーまたは特定のランキングのお気に入りのドライバーのパートナードライバーへを探しているか）が、各顧客毎にプリセットされ得る。このようなアルゴリズムのためのデフォルト設定は、顧客が特定の基準をプリセットしていない場合に用いられ得る。よって、本明細書中に記載のパートナードライバー方法は、サービスリクエスト実行について事前に計画された割り当てられたドライバーによるキャンセル、拒否または利用不可が行われた場合または顧客が図９について述べるようにサービスリクエストを変更した場合における事前スケジューリング実施形態においてだけでなく、単一のサービスリクエストまたは所与のバッチ中の複数のサービスリクエストの初期事前スケジューリングにおいても用いられ得る。
【０１８０】
本明細書中に記載のように２人以上のドライバーが相互にパートナー担っている場合、このようなグループ分けにより、従来の手動による派遣を軽減または排除するマイクロ派遣システムが得られる。このマイクロ派遣システムは、コンピューティングデバイス（例えば、ドライバーデバイス１３２および派遣担当者デバイス１３６）を通じてサーバ１０２およびネットワーク１２４を介して、一般的派遣システム１００へ動的に接続され、一般的派遣システム１００を更新する。サービスリクエストがパートナードライバー間に転送されても、顧客およびドライバー選好および制約全てが適用されるため、サービスリクエストをパートナードライバー間において転送することができず、サービスリクエストをジョブプールへ経路設定することができるかまたは本明細書中に開示される他の任意の方法に従って取り扱われる。
【０１８１】
図８を参照して、複数の事前に計画されたサービスリクエストを本発明の多様な例示的実施形態に従って割り当てるための第２のアルゴリズムを示すフローチャートが図示される。図示のように、顧客のお気に入りのリストおよび選好リストよりも顧客選好およびドライバー制限のマッチングを優先させるアルゴリズムが用いられ得る。指定された日付および地理的場所について潜在的な１組のドライバーおよび未割当のサービスリクエストのバッチが検索された後（図６、ステップ６３０を参照）、コンピューティングシステム１００は、バッチ中の未割当のサービスリクエストをサイクルして、ドライバーをできるだけ多くのドライバーへ割り当てることを開始する準備ができる。あるいは、お気に入りの分類および選好される分類に対して、他の利用されるマッチング基準に加えて、重み付けされたランキングそのものが付与され得る（例えば、分類およびランクを確認した後に他のマッチング属性を確認する代わりに、特定の実施形態において、最良にマッチするドライバーを決定するために、システムは、マッチング基準計算における重み付けされた値をマッチング分類へ付与するようにプリセットされ得ることが理解される）。
【０１８２】
コンピューティングシステム１００は、先ず、バッチの第１の未割当のサービスリクエスト（例えば、任意の関連付けられた顧客関連情報、任意のピックアップ場所／下車場所／時間）を特定する（ステップ８１０）。第１の潜在的な１組のドライバーが指定された日付およびドライバー制限中に指定された地域に基づいてレビューされ、これにより、特定のドライバーを、顧客のブラックリストに記載されることまたは顧客を自身のブラックリストに記載させることから除外することができる（ステップ８１２）。次に、未割当のサービスリクエストに対して、残りの潜在的な１組のドライバーのうちいずれかが（例えば、時間、場所などに基づいて（図７Ａ〜図７Ｂを参照））利用可能であるかが（ステップ８１４）。ドライバーが利用できないとみなされた場合、ドライバーの状態は態は「利用不可」と設定され得、ドライバーは、この特定のサービスリクエストについて第１の潜在的な１組のドライバーから除外される。第１の潜在的な１組の中のドライバーのうち利用可能な者がいない場合、サービスリクエストはジョブプールへ送られ得（ステップ８１６）、他の利用可能なドライバーによってビューおよび選択され得る。次に、第２の未割当のサービスリクエストのバッチと、新規顧客、場所、第２のサービスリクエストと関連付けられた時間情報とが特定され、バッチのサービスリクエスト全てが割り当てられ、任意の未割当のリクエストがジョブプールへ送られるまで、プロセスが継続する。
【０１８３】
潜在的なドライバーが利用可能であると決定され、コンピューティングシステム１００は、このようなドライバーが割り当ても可能であるかについて問い合わせ得る（ステップ８１５）（例えば、任意の顧客選好またはドライバー制限により、このようなドライバーへのサービスリクエストの割り当てが排除されるか）。少なくとも１人のドライバーが割り当て可能であると分かった場合、コンピューティングシステム１００は、複数の利用可能でありかつ割り当て可能なドライバーが１人だけまたは複数存在するかについて問い合わせる（ステップ８１８）。利用可能でありかつ割り当て可能なドライバーが１人だけいる場合、このようなドライバーはサービスリクエストへ割り当てられる（ステップ８２０）。次の未割当のサービスリクエストが、処理対象として特定される。
【０１８４】
１人よりも多くの利用可能でありかつ割り当て可能なドライバーが決定されると、コンピューティングシステム１００は、顧客選好とのマッチング属性に基づいて、各このようなドライバーについて適合性要素を決定し得る（ステップ８２２）。いくつかの実施形態において、このような適合性要素は、顧客のお気に入りのリストまたは選好リストに記載されているドライバーがいないかということよえいも優先され得る。顧客情報およびドライバープロファイル情報に基づいて、システム１００は、サービスリクエスト、顧客選好および／またはドライバー制限のうち１つ以上の局面に起因して顧客に充分適合しないとみなされる１人以上のドライバーを排除し得る。このような局面または適合性要素は、顧客が選好の順序として付与したい順序に基づいて顧客別に優先付けされ得る。処理機能を用いることで、このような選好、制限および／またはサービスリクエスト要求に関連する異なる変数／属性に対して異なる優先順位が割り当てられ、処理が行われる。このようなマッチング基準は、米国特許出願シリアル番号第１５／２３９，７８３号（タイトル：「Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｏｎ−Ｄｅｍａｎｄ  Ｃｕｓｔｏｍｉｚｅｄ  Ｓｅｒｖｉｃｅｓ」）（「‘７８３出願」）に開示される任意の実施形態について述べた実施形態に従って用いられ得る。本明細書中、同文献全体を参考のため援用する。
【０１８５】
コンピューティングシステム１００は、最も適合するドライバー（例えば、適合性要素が最も高いドライバー（ステップ８２４）がいるかを決定し、サービスリクエストを最も適合する割り当て可能なドライバーへ割り当てる（ステップ８２６）。次に、新規のサービスリクエストが処理対象として特定される（ステップ８１０）。複数の適合するドライバーが最高の適合性要素を有するが対等であるかまたは実質的に対等であると決定された場合、コンピューティングシステム１００は、場所および時間に基づいて、このようなドライバーのうちサービスリクエストのピックアップ場所に最も近接する者を推定し得る（ステップ８２８）。次に、コンピューティングシステム１００は、最も高い適合性要素を有する残りの複数の適合するドライバーの最近隣にサービスリクエストを割り当てる（ステップ８３０）、次の未割当のサービスリクエストを処理対象として特定された（ステップ８１０）。
【０１８６】
ここで図９を参照して、本発明の多様な実施形態による、取り出されたバッチの複数のサービスリクエストをパートナードライバーと用いて事前スケジューリングおよびリスケジューリングする例示的方法と、オンデマンド方法とを示すフローチャートが図示される。コンピューティングシステム１００は、本明細書中に記載のアルゴリズムまたは基準（例えば、図７Ａ、図７Ｂおよび図８について図示および議論したアルゴリズム）のうち１つを用いて、例えば２０１７年８月１５日に特定の指定日付（例えば、２０１７年８月１８日）について、ドライバーと共にサービスリクエストのバッチを事前スケジュールし得る（ステップ９００）。本例において、２０１７年８月１５日と、２０１７年８月１７日との間において、ドライバーが自身に付与されたサービスリクエスト割当を受諾／拒否すると、コンピューティングシステム１００は好適には、バッチに対するドライバー割当を動的に更新および終了し、コンピューティングシステム１００は、本明細書中に記載の多様な実施形態に従ってサービスリクエストを再度割り当てる（ステップ９０２）。次に、指定された派遣日（例えば、２０１７年８月１８日）に、バッチの特定のサービスリクエストＸＣに対応する顧客から、サービスリクエストのピックアップ時刻を２：００ＰＭから５：００ＰＭに変更してもらいたい旨の通知が受信される（ステップ９０４）。顧客は、他の変更（例えば、ピックアップ場所またはサービスリクエストの他の任意の属性または当該属性と関連付けられた顧客選好）を望む場合があることが理解される。
【０１８７】
変更のリクエスト（単数または複数）が顧客から受信されると、コンピューティングシステム１００は、事前に計画されたドライバーにサービスリクエスト、ＸＣについて通知する（ステップ９０６）。顧客は、割り当てられたドライバーと直接的に通信して、変更（単数または複数）をリクエストし得る。このような通信は、例えば関連顧客デバイス１３０Ｃ１…１３０Ｃｎからドライバーデバイス１３２Ｄ１…１３２Ｄｎ、ベンダーデバイス１２６、管理者デバイス１３４、派遣担当者デバイス１３６またはこれらの組み合わせへと直接的に行われ得る。割り当てられたドライバーは、サービスリクエストに対して変更（単数または複数）を受諾するかを示すように促される（ステップ９０８）。サービスリクエストについての変更が受諾されると、割り当てられたドライバーのサービスリクエストのうち別のものとの矛盾が生じ得、コンピューティングシステム１００は、割り当てられたドライバーがその変更を（その後のサービスリクエストへの影響と無関係に）受諾するように構成され得るか、または、ドライバーがその変更を受諾する事態を回避することおよび新規ドライバーをサービスリクエスト（例えば、パートナードライバー）へ再度割り当てることを行うように構成され得るが理解される。あるいは、その後のサービスリクエストにおいて何らかの混乱のみですむことが予測される場合、ドライバーは変更を受諾し得る。割り当てられたドライバーが変更を受諾した（ステップ９０８）場合、コンピューティングシステム１００は、サービスリクエストへ割り当てられた同じドライバーを保持する（ステップ９１０）。
【０１８８】
割り当てられたドライバーが変更を受諾しない（ステップ９０８）場合、コンピューティングシステム１００は、割り当てられたドライバーが任意のパートナードライバーを有するかを特定し得る（ステップ９１２）。割り当てられたドライバーが任意のパートナードライバーを有する場合、コンピューティングシステム１００は、現在の場所または推定される場所、任意の潜在的な矛盾（例えば、ブラックリスト）またはその制限と、割当を排除する顧客の選好との間の任意の矛盾に基づいて、パートナードライバーのうちいずれかがサービスリクエストＸＣの実行に対して利用可能であるかまたは将来利用可能となるかを特定し得る（ステップ９１４）。１人以上のパートナードライバーが利用可能である場合、コンピューティングシステム１００は、最も適合するかまたは最も近隣にいる利用可能なパートナードライバーへリクエストを送る（ステップ９１６）。近接性は、履歴と、最新のトラフィックおよびマップデータ３２６との双方を用いて、場所および時間の推定値双方に基づいて確立され得る。適合性は、本明細書中に記載のようなお気に入りリスト、選好リストまたはマッチング基準顧客選好およびドライバー制限に基づいて確立され得る。パートナードライバーは、リクエストの自身の受諾または拒否と共に応答する（ステップ９１８）。受諾された場合、コンピューティングシステム１００は、サービスリクエストＸＣをパートナードライバーへ再度割り当てる（ステップ９２０）。拒否された場合、コンピューティングシステム１００は、パートナードライバーの状態（ステップ９２２）を「利用可能」から「利用不可」に自動的に切り換えて、他の任意の利用可能なパートナードライバーを再度チェックする（ステップ９１４）。
【０１８９】
利用可能なパートナードライバーがいない場合（ステップ９１２、９１４）、コンピューティングシステム１００は、顧客選好、ドライバー制限および他のマッチング基準を用いて、少なくとも１人の最良にマッチする利用可能なドライバーを特定し得る（ステップ９２４）。ピックアップ時刻が事前に計画されたサービスリクエストに近づいてきたときに、問題（例えば、土壇場でのドライバーキャンセルまたは顧客変更または未割当のままのサービスリクエスト）が有る場合、コンピューティングシステム１００は、‘７８３出願に図示および記載の多様なオンデマンド実施形態に従って動作し得る。
【０１９０】
最良にマッチする利用可能なドライバーは、顧客選好とドライバー制限との間のマッチと、場所制限、時間制限およびプリセット制限（ただし、少しでも有る場合）とに基づいたおよびドライバー稼動性とに基づいて特定され得る。コンピューティングシステム１００は、例えば顧客デバイス１０３Ｃ１…１３０Ｃｎおよびドライバーデバイスｓ１３２Ｄ１…１３２Ｄｎの時間と共に変化する地理的場所を自動的かつ周期的に追跡し得、トラフィックおよびマップデータ３２６およびドライバー場所データ３２４に基づいて、サービスリクエストの完了のために利用することが可能なドライバーを特定し得る。顧客デバイスｓ１０３Ｃ１…１３０Ｃｎの地理的場所、ドライバーデバイス１３２Ｄ１…１３２Ｄｎ、ジョブプール７１６／８１６、電子マップディスプレイ１０００は、顧客およびドライバーのプリセット、設定、選好、制限、フィードバックまたは高品質のサービスを提供するための他の情報の変更を示すように、データベース１０８において動的に更新され得る。このような少なくとも１人の最良にマッチする利用可能なドライバーを特定するオンデマンドプロセスにおいて、サービス提供者（例えば、ドライバー）および顧客を顧客選好およびドライバー制限のマトリックスに基づいて適切にマッチさせることができ、これにより、顧客の個人的選好に対応し続けながら、土壇場での割当を効率的に顧客へ提供することができる。顧客の選好およびドライバーの制限双方を考慮に入れることにより、サービスの事前スケジューリング時およびサービスオンデマンドの提供時において双方の当事者に対応することができる、よりカスタマイズされた経験を提供することができる。
【０１９１】
フィードバックは、ポジティブフィードバック、中立的フィードバックまたはネガティブフィードバックを含み得る。ポジティブおよびネガティブフィードバックは、提供者のパフォーマンス評価に基づいて、プリセットされたポジティブ／ネガティブな理由それぞれの形態で提供され得る。この評価は、顧客または最良にマッチするサービス提供者によって提供され得、顧客または最良にマッチするサービス提供者は、対応する当事者をお気に入りリストまたはブラックリストへ追加することをさらに選択し得る。中立的フィードバックまたはフィードバックの場合、将来のサービスリクエストの割り当てにおいて顧客とサービス提供者との間のマッチに影響は無い。サービス提供者および顧客は、相互のお気に入りリストまたはブラックリストに記載され得るが、相互のブラックリストおよびお気に入りリストに同時に記載されることはあり得ない。顧客は、１つ以上のエンティティを自身のブラックリストへ追加し得、このようなエンティティとアフィリエイトされたサービス提供者全ても、ブラックリストへ追加され得る。
【０１９２】
あるいは、顧客をサービス提供者のブラックリストに付加することにより顧客を匿名で評価するためのネガティブな理由をプリセットすることにより、ネガティブフィードバックを提供してもよい。ネガティブな理由を挙げると、不潔、ノーショー、うるさすぎる、言葉による虐待または身体的虐待、支払い拒否または他の類似の理由がある。同様に、第２のサービス提供者を顧客のブラックリストに付加することにより、サービス提供者を匿名で評価するためにネガティブフィードバックが設けられ得る。ここで、ネガティブな理由を挙げると、無礼、言葉による虐待または身体的虐待、乱雑な車両、運転スキルが低い、通りの条件についての精通度の欠如、顧客の命令に従わない、物品の不適切な取扱、物品の損壊または紛失、送達の遅れまたは他の類似の理由がある。顧客およびサービス提供者がネガティブフィードバックを受けた旨および／またはその理由を通知するために、任意のネガティブフィードバックから特定の時間が経過した後に顧客およびサービス提供者へ提供され得る。ネガティブフィードバックに基づいて、顧客および／またはサービス提供者は、サービスから保留にされ得る。
【０１９３】
特定された後、コンピューティングシステム１００は、最良にマッチするドライバーのグループ（例えば、ドライバー１、ドライバー２、ドライバー３、ドライバー４など）を、インジケータを通じて表現される各ドライバーについての詳細と共に顧客に示し得る（ステップ９２６）。このような詳細を挙げると、顧客からの距離または時間、経路情報、経路精通度などがある。自身のサービスリクエストについて簡便かつ効率的な方法で顧客が提案された最良にマッチするドライバーのグループからドライバーを選択する作業を促進するように、複数組のインジケータを用いてもよい。最良にマッチするドライバーのうち１人を特定する顧客選択が受信された後（ステップ９２８）、その顧客が通知される（ステップ９３０）。選択された最良にマッチするドライバーに対して、サービスリクエストを受諾したいか否かについてのクエリが送られる（ステップ９３２）。選択されたドライバーがサービスリクエストを受諾しない場合、コンピューティングシステム１００は、顧客選好、ドライバー制限および他のマッチング基準を用いて別の最良にマッチする利用可能なドライバーを特定する（ステップ９２４）。選択されたドライバーは、サービスリクエストを受信し、コンピューティングシステム１００は、サービスリクエストＸＣを選択されたドライバーへ再度割り当てる（ステップ９３４）。
【０１９４】
特定の好適な実施形態において、本明細書中に導入される概念は、（単一の顧客の単一の事前に計画されたサービスリクエストについての顧客およびドライバー、単一の顧客の複数のサービスリクエスト、または１人以上のドライバーに割り当てられた複数の顧客についての複数のサービスリクエストについて）事前スケジューリングサービスを（指定された派遣日に先駆けてまたは指定された派遣日当日に）カスタマイズするために、多様な組み合わせにおいて所望に利用され得、多様なマッチングアルゴリズムが用いられ得ることが理解される。本明細書中に開示される事前スケジューリング方法はオンデマンド方法と共に用いられ得、本システムは事前スケジューリングおよびオンデマンドまたはその逆の間で状況に応じて切り替わることができることも理解される。例えば、顧客は、事前スケジューリングのために単一のサービスリクエストをシステムに入力し得、顧客が見たいと思う各ドライバーについての識別状態に基づいた各最良にマッチするドライバーに対応する１組のインジケータを含む最良にマッチするドライバーのリストを受信し得（例えば、ドライバーのマッチング属性、特定の経路についての精通度または経験のレベルを示すインジケータなど）、サービスリクエストの実行に際してこのような最良にマッチするドライバーのうち１つ以上を選択し得る。あるいは、顧客は、事前に計画されたドライバーが土壇場でキャンセルした旨が通知され得、最良にマッチするドライバーのリストから選択するオプションが付与され得る。同様に、例えばオンデマンドサービスのためのドライバーを選択した顧客が自身の医師が遅刻していることを突如知り、オンデマンドサービスリクエストをキャンセルして数時間後または別の日にピックアップしてもらう必要がある場合、システムは、オンデマンド方法から事前スケジューリング方法に切り替わり得る。
【０１９５】
顧客およびドライバーがシステム中にプリセットする情報が多いほど、システムによる割当のカスタマイズ、手動派遣の軽減または排除がより向上され（例えば、自動化されたカスタマイズ可能な派遣が可能になり）、システムの全ユーザに対してより多くの情報およびオプションを提供することができる。顧客は、ドライバーを自身のサービスリクエスト（単数または複数）に割り当てる際に用いられるマッチング基準の１つ以上の局面を任意選択的にプリセットしてもよいし、あるいは、サービスリクエストそのものの点以外の任意の基準（例えば、ピックアップ時刻、下車時刻、日および場所）を単に設定しなくてもよい。
【０１９６】
パートナードライバーシステムの意図するところは派遣の最小化であるため、パートナードライバーは、パートナードライバーがリクエストを紹介されたかまたは送られた領域と同じ領域中に選好地域を持ってもよいし、持たなくてもよいことも理解される。例えば、ドライバーがサービスリクエストをキャンセルすると、当該ドライバーは、ボタンを押圧し、自身のパートナードライバーの現在の状態およびパートナードライバーの各場所を確認し、推奨または通知をこれらのパートナードライバーのうち１人に送り得る。次に、システムが許可した場合に（例えば、サービスリクエストのパートナードライバーおよび顧客が相互のブラックリストに記載されていないことあるいはいくつかの他のプリセット基準または理由に起因して排除されていないことをシステムが決定した場合に）、パートナードライバーは、リクエストを受諾し得る。このような機能により、ドライバーは、土壇場でキャンセルしなくてはならない場合、自身の事業を保持し、自身の顧客を満足させることができる。
【０１９７】
本明細書中、「利用可能」および「利用不可」という用語について、（１）当該日および当該時刻においてドライバーがいると予測される場所と、（２）トラフィックおよびマップデータに基づいて、ドライバーがピックアップ場所に到達すると予測される時間とに基づいて、ドライバーが特定の日付に働いているかおよびドライバーが特定の指定されたピックアップ時刻に特定の指定されたピックアップ場所に到達することができるかについて述べてきた。しかし、ドライバーは、サービスリクエストの実行について調整を行うことができ、若干異なるピックアップ時刻または場所について顧客と連絡および調整できるため、本システムは、ドライバーが「利用可能」であるかの決定において柔軟に構成され得ることが理解される。このような柔軟性は、システム内において顧客によってプリセットされ得る（例えば、お気に入りのドライバーが、リクエストされたピックアップ時刻から３０分遅く顧客に到着することができる場合、受容可能であり得る）。
【０１９８】
システムが指定された日付について複数のサービスリクエストを事前スケジュールする実施形態において、仕事を受ける地域（単数または複数）と、仕事を受ける期間（単数または複数）とについての各ドライバーの選好が、選好される地域（単数または複数）内の地理的場所についてのドライバーが有する任意の制限またはドライバーの選好される期間（単数または複数）内の期間についての制限と共に好適にプリセットされる。例えば、（例えば、マップインターフェース中のマップの特定地域をクリックおよび／または協調表示によって）ドライバーが特定地域（単数または複数）をシステム内にプリセットすると、ドライバーは、複数の事前に計画されたサービスリクエストをシステムから受信し得る。これらのリクエストはそれぞれ、当該地域内のピックアップ時刻および下車場所を有する。ドライバーがサービス提供を望まない地域内に特定の郵便番号または場所が有る場合において、ドライバーは、手入力またはマップ表示インターフェースのクリックにより、このような制限をシステム内に指定することができる。ドライバーが自身のプリセット地域内において仕事を受けたいと望む特定の期間がある場合、ドライバーは、このような特定期間選好を同様にシステム内にプリセットすることができる。ドライバーが選好期間としてにおいて仕事を受けたくない特定の期間がある（例えば、ドライバーのお昼休憩時または日中の個人的アポイントメント）、ドライバーは、このような期間制限もシステム内にプリセットすることができる。このようにして、システムは、複数のサービスリクエストの事前スケジュールを高精度かつ高効率に行うことができる。単一の事前に計画されたサービスリクエストに対して、時間および場所についての顧客およびドライバー選好は不要である。なぜならば、スケジューリングにおける柔軟性が高まる（すなわち、ドライバーに個々に通知することができかつ／または顧客が個々のドライバーを選択する）からである。よって、地域および時間についてのドライバーの選好が任意選択的にプリセットされるが、特定の実施形態において、指定された日付において複数のリクエストが割り当てられたものとみなされる必要がある。各ドライバーが選好する地域についてのプリセットデータをシステムが含む場合、システムは、複数のサービスリクエストの割り当てをより効率的に行うことができる。なぜならば、ほとんどのサービスリクエストは、指定された地域間と対照的に、ドライバーが指定した特定地域内（例えば、マンハッタン内、クイーンズ内、ブルックリン内、３０番通りと９０番通りとの間）に当てはまるからである。
【０１９９】
特定の実施形態において、システムが（システムが実行しようと構成されているプリセットデータおよびアルゴリズムに基づいて）多様なドライバーが良好にマッチするとみなした場合、システムは、ジョブプール６６０および７１６へ送られたかまたはジョブプール６６０および７１６中に既にあるサービスリクエストについて、このようなドライバーに推奨または通知し得る。例えば、システムは、突然利用可能になりかつ／または特定の地域を入力しかつ／または顧客のマッチング基準を満たすドライバーに対し、ジョブプール中のサービスリクエストを推奨し得る。システムは、受諾のために所定の期間をドライバーへ付与し得る。ドライバーが受諾しない場合、システムは、別のドライバーに利用可能なサービスリクエストについて通知し得るといった具合である。他の実施形態において、システムは、利用可能なドライバーに対し、（割り当てられたドライバーがキャンセルしたかまたはシステムがプリセットドライバー選好に基づいてサービスリクエストを事前スケジュールできなかった場合に起因して）ジョブプール中に保存される寸前のサービスリクエストを通知し得る。その場合、システムは、このようなドライバーに対し、ジョブプール中に保存される前にサービスリクエストを選択しかつ／または自身のプリセット選好および制約を変更する能力を付与し得る。ドライバーは、このような推奨されたサービスリクエストをとろうという気持ちになり得る。なぜならば、このリクエストがジョブプール中に保存された後は、今までドライバーに付与されていた独占権は失われ得、別のドライバーが選択するからである。特定の実施形態において、制限性のより高いアルゴリズムを用いた場合に特定されていなかった潜在的なドライバーを特定するために、システムは、ジョブプール中のサービスリクエストに対して、より包括的なまたはより制限性の低いアルゴリズム（例えば、１つ以上の基準を排除したかまたは重み付けの低いもの）を実行するように構成され得る。アルゴリズムの包括性が高いほど、例えば稼動性に関連する任意の事前設定に対する制限が低くなり得る。例えば、ある地域に精通するドライバーは、システムが計算する時間よりも短時間でサービスリクエストを取り扱うことができ得、かつ／または、顧客と通信し、異なるピックアップ時刻に同意する場合がある。このような通信により、派遣問題の解消が支援され得、より多数のサービスリクエストをジョブプールから除去することができる。
【０２００】
システムに対する新規顧客が有る場合または既存の顧客が新規地域においてサービス提供したいと思う場合、お気に入りのドライバーまたは好みのドライバーがその新規領域（単数または複数）内にいない場合があり得ることが理解される。そのため、特定の実施形態において、システムは、例えば所与の経路についてのドライバーの精通レベルおよび／または地理的領域内においてドライバーが典型的に行うサービスリクエスト数に基づいて、ドライバーを顧客に推奨し得るかまたはその逆が行われ得る。顧客およびドライバーが自身の事前設定を変更するたびおよびサービスリクエストの完了時および完了後に、全データがデータベース１０８から検索および分析され得、および動的にシステムを通じて更新され得る。
【０２０１】
好適な実施形態において、データベース１０８は、新規のドライバー場所データ３２４、トラフィックおよびマップデータ３２６、ジョブプール６６０および７１６からのデータ、マップ表示１０００からのデータ、および顧客デバイス１３０Ｃ１〜１３０Ｃｎ上の任意のユーザインターフェースと共に動的に更新され得、ドライバーデバイス１３２Ｄ１〜１３２Ｄｎは、サービスリクエストのスタート、完了、変更、選択、キャンセル、割り当て時などにリアルタイムで動的に更新され得る。
【０２０２】
特定の実施形態において、本明細書中に記載の最良にマッチするドライバーのステップは、顧客のための単一のサービスリクエストの事前スケジューリングを例えば図５について述べた価格交渉ステップと組み合わせて行う際に追加的にまたは代替的に用いられ得る。顧客は、最良にマッチするドライバーのリストを（特定のドライバーと関連付けられた情報の要旨を反映する各インジケータと共に）レビューし、価格交渉のために１つ以上を選択することができる。
【０２０３】
本明細書中開示される１組のインジケータにより、顧客が供給がより低いときにより低価格を供給がより高いときにより高価格を提案することが可能になるため、（交渉における価格設定において重要であり得る）顧客による需要および供給要素の評価を支援することができることが理解される。サービスを提供することが可能な利用可能なサービス提供者の数と、特定の領域内のサービスを現在リクエストしている顧客の数とがデータベース１０８内において動的に更新され得る。サービス提供者が地理的ゾーン内におりかつ利用可能である限り、顧客のサービスリクエスト中のサービスと同種のサービスを提供している任意のサービス提供者が潜在的な利用可能なサービス提供者のプール中に含まれ得る。顧客へ表示される１組のインジケータは、顧客が顧客デバイス１３０を介してオンまたはオフにすることができる。顧客が１組のインジケータをオフにした場合、当該顧客は、ディスプレイ上にそのインジケータを見ることがなくなる。しかし、顧客のサービスリクエストは、適切なサブカテゴリ内の利用可能なリクエスト全てのシステムによる調査においてカウントされ続けられ得る。
【０２０４】
多様な複数組のインジケータが、ドライバーデバイス１３２を介してサービス提供者（例えば、ドライバー）へ表示され得、例えば多様な種類の顧客情報に基づいてサービスリクエストの価格を設定する際においてドライバーにとって有用であり得る。特定の実施形態において、サービス提供者は、顧客へ表示される検索結果または需要および供給情報と同じものにアクセスすることができ、そのような情報がサービス提供者へ付与され得る。特定の実施形態において、システムにより、顧客およびサービス提供者が自身に表示された情報を全体的または部分的に相互に交換することができ、これにより、交渉プロセスの透明性が高まる。ドライバーに対し、顧客属性を示すインジケータが価格交渉のためだけにではなく、本明細書中に記載の多様な他の実施形態ためにも付与され得ることが理解される。例えば、ドライバーがジョブプールからジョブを選択するかを評価している場合またはシステムから通知された新規のまたは利用可能なサービスリクエストを受諾すべきかを評価している場合、システムは、ドライバーがサービスリクエストと関連付けられた顧客情報および所望の顧客情報と関連付けられたレビューインジケータへアクセスすることを可能にするように構成され得る。このようにして、ドライバーは、事前に計画されたサービスリクエストを受諾するかについての決定について連絡を受けることができる。
【０２０５】
本発明の例示的実施形態によれば、システムは、顧客からの価格提案に対する１人以上のサービス提供者の応答についての価格設定情報の合理化を支援するための１組のインジケータを利用することができ、これにより、顧客は、数人の最良にマッチするドライバーと価格交渉を同時に行うことができる。特定の実施形態において、顧客がサービスリクエストを見積もり価格無しで送り、サービス提供者が（交渉可能なまたは交渉不可能なであり得る）提案価格と共に応答した場合、システムは、ドライバー（単数または複数）が開始した価格設定数値を顧客のために１組のインジケータと共に表示し得る。提案価格が交渉可能である場合、最終交渉または交渉無しになるまで、交渉が往復で行われ得る。
【０２０６】
特定の実施形態によれば、提案を開始した当事者に応じて、多様な複数組のインジケータが異なる状況のために用いられ得る。インジケータそのものは、価格提案がシステムから提供されたデフォルト価格を上回るのか、下回るのかまたは等しいのかを伝達し得る。例えば、システムは、開始価格がデフォルト価格を超える場合に緑色のインジケータまたは上向き矢印を表示し得、開始価格がデフォルト価格を下回る場合に赤色のインジケータまたは上向き矢印を表示し得る。デフォルト価格と正確にマッチする価格は、黄色またはドットとして表示され得る。これらの３つの異なる色により、これら３つの状況それぞれの差が伝達され、他の場合に時間のかかる見やすい視覚表示に基づいて、ユーザによるソートをより迅速に行うことを可能にする明確な差が図示される。この表示中に含まれるものとして、例えば、実際の提案価格と、価格提案とデフォルト価格との間の差をドルまたはパーセンテージとして比較する情報とがある。この１組のインジケータは、ユーザの裁量に応じてオフにしてもよいし、あるいは表示される１つまたは任意の部分を有してもよい。このような事前に計画されたサービスリクエスト時において、システムは、最終価格に同意が得られない場合に交渉を時間切れにするように構成され得るか、または、サービスリクエストの日付および時間まで交渉を継続するオプションを顧客へ付与するように構成され得る。ユーザは、デフォルト価格よりも高いかまたは低い価格閾値を事前設定することにより、価格提案が自動的に拒否される制限も設定し得る。好適には、これらの複数の組のインジケータは、顧客およびサービス提供者双方に表示される。多様な複数組のインジケータが、システム中の任意のユーザ種類へ表示され得る。サービス提供者からの価格提案をリクエストした顧客は、デフォルト価格よりも５０パーセント以上高い任意の価格提案を設定において見ないようにプリセットし得る。そうではない場合、価格提案は自動的に拒否され得る。顧客は、価格差に応じて価格インジケータを選択する裁量を有する。
【０２０７】
インジケータは、顧客がサービスリクエストのピックアップ場所を示す地理的ゾーン内においてサービス提供者が完了したサービスリクエストの合計数に基づいて、ゾーン情報についての情報を反映する顧客についても表示され得る。このようなインジケータは、データベース１０８から取り出された履歴データを示し得る。このインジケータは、サービス提供者のピックアップ場所における経験または精通度を迅速に伝達する表示を顧客に提供し得ることが理解される。このような情報により、当該領域におけるより豊富な経験があるためサービスリクエストにより適しているサービス提供者について顧客へ通知することが支援され得る。
【０２０８】
１組のインジケータは、各地理的ゾーン内の潜在的な利用可能な顧客数と比較した潜在的な利用可能なサービス提供者の数と、潜在的な利用可能なサービス提供者のプールと、潜在的な利用可能な顧客のプールと、検索パラメータ（例えば、数、時間および距離またはこれらの任意の組み合わせ）に基づいた地理的ゾーンとを表示し得る。この１組のインジケータにより、検索パラメータに基づいた各地理的ゾーン内の需要および供給についての情報が得られ得、設定価格に織り込まれ得る。特定の実施形態において、サービス提供者は、お気に入りの顧客のみからのリクエスト、選好される顧客のみからのリクエストあるいはお気に入りの顧客からのリクエスト、選好される顧客からのリクエスト、レギュラーの顧客からのリクエストおよび新規顧客からのリクエストのみを表示するようも自身の表示を限定し得る。
【０２０９】
本明細書中に開示されるシステムおよび方法の多様な実施形態により、コンピューティングデバイスを通じた自動化された派遣の提供により手動派遣が実質的に低減または排除され、１つ以上のリモートコンピューティングデバイスを通じた関連情報の動的展開を通じて、顧客、ドライバーおよび派遣担当者間の通信が増大し、フルサービス派遣が可能になる（例えば、サービスリクエストの事前スケジューリング、サービスリクエストの派遣、サービスリクエストの動的な更新および変更の痩躯心、および顧客運輸時の全パーティへのリアルタイム情報の提供）。
【０２１０】
本明細書中に用いられる文言または用語は説明目的のためのものであり、制限的なものではないことが理解される。多様な好適な実施形態について本発明を図示および記載してきたが、当業者であれば、特許請求の範囲に記載のような本発明の意図および範囲から逸脱することなく多様な変更および／または改変が可能になり得ることを容易に理解する。本明細書中に記載の任意の例示的実施形態はひとえに例示的なものであり、本開示の意図または添付の特許請求の範囲の範囲から逸脱することなく、多数の変更が導入され得る。例えば、異なる例示的実施形態の要素および／またはフィーチャを相互に組み合わせかつ／または相互に代替することが可能であり得る。よって、本発明の範囲は、以下の特許請求の範囲のみによって規定され、当業者であれば、このような詳細において多数の変更が（本発明の意図および原理から逸脱することなく）可能であり得ることを理解する。
【図１】
2019537166.tif 000003
【図２】
2019537166.tif 000004
【図３】
2019537166.tif 000005
【図４Ａ】
2019537166.tif 000006
【図４Ｂ】
2019537166.tif 000007
【図５】
2019537166.tif 000008
【図６】
2019537166.tif 000009
【図７Ａ】
2019537166.tif 000010
【図７Ｂ】
2019537166.tif 000011
【図８】
2019537166.tif 000012
【図９】
2019537166.tif 000013
【図１０】
2019537166.tif 000014
【国際調査報告】
2019537166.tif 000015
2019537166.tif 000016
2019537166.tif 000017