JP7291252B2 - 処理ルート情報 - Google Patents

Description

本発明は、通信および管理の一般的な分野に属する。一つの態様は、タクシー型サービス、バイク、配送車両などのオンデマンドサービスプロバイダの状況を有する。これらのサービスプロバイダは、基本的に移動型である。

人と商品をより効果的に動かすことは、ますます重要な目標になってきている。近年、商品や人の双方を従来の技術よりも遅れずに移動させ、または移動させる手段を用いたオンデマンドサービスの提供に成長がある。オンデマンドサービスプロバイダは、車両を運転する人間であってもよく、または代替的に、無人車であってもよい。ユーザが目的地に移動するためにサービスプロバイダを要求した場合、その目的地から、またはその場所の近くから、新しい「ジョブ」を直ちに利用できない可能性が高い。

ここで、「サージ（surge）」の概念について説明する。サージは、サービスプロバイダの不足が生じた場合、または逆に見ると、過剰なサービスユーザが生じた場合に生じる。サージとは、ジョブのコストが通常設定された倍率だけ増加するように、価格設定が変更される場合である。したがって、一例として、通常５ドルかかるジョブは、８ドルに増大することである。価格情報は、有望なユーザに利用可能である。その結果、サービスの必要性が緊急であるこれらの有望なユーザは、サージ手数料を支払うことができる。一方、他のユーザは、単に、高価格のために、それらのリクエストを受けないか、またはサージ状況が解消し、コストが通常に戻るのを待つことを選択する。

本明細書で使用される他の用語：

機械学習：データ分析の分野では、機械学習は、予測に役立つ複雑なモデルおよびアルゴリズムを考案するために使用される方法である。商業的な使用では、これは、予測分析として知られている。これらの分析モデルにより、研究者、データ科学者、エンジニア、およびアナリストは、データにおける履歴的関係および傾向から学習することによって、「信頼性のある反復可能な決定および結果を生み出し」、「隠れたインサイツ」を発見することができる。

生存分析：生存分析は、生物有機体の死および機械的システムにおける故障のような１つまたは複数の事象が起こるまでの予想される持続時間を分析するための統計のブランチである。

最適化：最適化は、利用可能な選択肢のいくつかのセットから（いくつかの基準に関して）最良の要素を選択することである。

ＵＳ２０１７／０２２７３７０Ａは、移動の間の待ち時間を短縮するために、プロバイダに情報を提供する移動調整システムを開示する。領域は、ゾーンに分割され、各ゾーンについてスコアを生成する。ゾーンスコアは、ゾーンの待ち時間を推定することによって生成することができる。これは、待ち時間のモデルによって決定される。待ち時間のモデルは、ゾーン内のプロバイダの数および移動リクエストレートなど、待ち時間に寄与する要因を使用する。各ゾーンのゾーンスコアは、地理的領域のロードマップ上でプロバイダに表示される。移動調整システムはまた、目的地への移動中、割り当てリクエストを受信するための待ち時間を低減するために、ゾーンスコアリングを使用するルートを提供する。移動調整システムは、目的地を識別し、目的地までの候補ルートを生成する。ルートは、ルートスコアに基づいて選択される。

一態様では、モバイルサービスプロバイダを道案内するための技術が開示される。その技術は、サービスプロバイダがジョブを見つけるという予測に従って、複数の目的地から一つの目的地を選択する工程を含む。

この技術は、複数の候補目的地のそれぞれについてジョブ予測を決定するためのルート情報を処理する工程を含む。

第２の態様では、選択されたルートによって選択された目的地に向けてサービスプロバイダを移動させるための技術が開示される。目的地およびルートは、そのルートをたどった結果として行われたジョブが高収益を有するという予測に従って選択される。

第３の態様では、複数の候補目的地が考慮されるモバイルサービスプロバイダのためにルート情報を処理する方法が提供される。ルートおよび目的地は、複数の目的地の各ルートに沿ったジョブを見つける予測確率（probability）に従って各ルートをスコアリングすることによって決定される。

第４の態様では、サービスプロバイダのためのルート情報を処理する方法が提供される。この方法は、スタート位置（すなわち、サービスプロバイダの現在位置）から異なる目的地までのルートに沿ってジョブを見つける確率を予測する工程と、各ルートに沿ったジョブからの収益の予測に応じて、各ルートをスコア付けするためにこの確率を使用する工程と、を含む。

一実施形態は、各潜在的な目的地への各ルートを複数のセグメントに分割し、生存分析（すなわち、オンデマンド目標位置に到達するまでの持続時間を予測する工程）を使用して、ルートに沿って通過中または目的地に到達したときのいずれかで、ジョブを達成する尤度（likelihood、可能性）を判定する。いくつかの実施形態では、予測は、プロバイダが考慮中のルートのそれぞれのセグメントに費やすと予想される時間の長さを考慮し、および連続するセグメントへの入力時間も考慮する。

一実施形態は、履歴データおよびリアルタイムデータを使用して、各セグメントの周りのエリア内の状態を予測する。予測は、すべてのルートおよび目的地について繰り返される。ターゲットプロバイダに、最も高い予測結果を有するルートおよび目的地のメッセージを送る。

第５の態様には、プロセッサとメモリとを含むサーバ装置が開示される。サーバ装置は、プロセッサの制御の下、メモリに記憶された命令を実行し、複数のルートを示すデータを含むルートデータレコードを生成するように構成される。各ルートは、スタート位置とそれぞれの目的地との間にある。各目的地は、スタート位置から目的地への少なくとも１つのルートを有する。サーバ装置は、各ルートを構成するゾーンを示すゾーンデータレコードを決定するためにルートデータレコードを処理するように構成される。また、サーバ装置は、そのルートを構成する各ゾーンのジョブの確率の予測に基づいて、各目的地へのルートを構成するルートデータをスコア化するためにゾーンデータレコードを予測データレコードと組み合わせるように構成される。

別の態様では、複数のゾーンから構成される地理的エリア内のサービスプロバイダの潜在的な移動のためのルート情報を処理する方法がある。その方法は、各ターゲットゾーンについて、現在のサービスプロバイダ通信デバイス位置から各ターゲットゾーン内の各関心地点までのルートを決定する複数のターゲットゾーンとして複数のゾーンを選択する工程と、各ルートについて、現在の位置とターゲットゾーン内の各関心地点との間を移動した軌道セグメントを識別する工程と、軌道セグメント内のジョブの尤度の予測に基づいて、各ターゲットゾーンまでの各ルートをスコアリングする工程とを含む。

さらなる態様では、目的地を有する複数のゾーンから構成される地理的エリア内に位置するサービスプロバイダのためのルート情報を処理する方法がある。この方法は、現在のサービスプロバイダ通信デバイスの位置と目的地との間にある複数のルートを確立する工程を含む。目的地は、現在のサービスプロバイダ通信デバイスの位置から目的地への少なくとも１つのルートを有する。方法は、各ルートを構成する軌道セグメントを決定する工程と、そのルートを構成する各軌道セグメントにおけるジョブの尤度の予測に基づいて、目的地へのルートをスコアリングする工程とを含む。

さらに別の態様では、目的地を有する複数のゾーンから構成された地理的エリア内のサービスプロバイダのためのルート情報の方法が提供される。この方法は、スタート位置と目的地との間にある複数のルートを確立する工程を含む。目的地は、スタート位置から目的地への少なくとも１つのルートを有する。方法はまた、各ルートを構成する軌道セグメントを決定する工程と、そのルートを構成する各軌道セグメント内のジョブから導かれる収益の予測に基づいて、目的地へのルートをスコアリングする工程と、を含む。

さらに別の態様では、機械学習アルゴリズムを実行するように構成されたコンピュータシステムが提供される。アルゴリズムは、記憶装置にアクセスして、記憶装置に保存されているデータを読み取り、読み取られた記憶データに従ってパラメータ値の予測を適応させるように構成されている。

記憶されたデータは、データウェアハウスに保持される。

一実施形態では、機械学習アルゴリズムは、データウェアハウスにアクセスして、セル毎にサービスプロバイダのアイデンティティを決定し、各セルにおける供給、需要、およびサージを予測する際にデータウェアハウスからの情報を使用する。

現在のデータは、アルゴリズムが後続の予測を形成する際に使用されるデータを更新する効果を有するように、保存されているデータと共に考慮される。

一群の実施形態では、サービスプロバイダがアイドル状態になったこと、またはアイドル状態になりそうことを示すと、サーバは、機械学習プロセスの結果を使用して、サービスがリクエストされる位置および位置へのルート、および／または、そのルートをたどることによって得られる可能性のある収益を評価する。

いくつかの実施形態では、結果は、各位置の各ルートについて得られるジョブまたは期待される収益を見つける確率を含む。

いくつかの実施形態における機械学習アルゴリズムは、サービスプロバイダがアイドル状態のプロバイダの車両位置から運転したくない、または運転したくないと予測されるセルの位置を学習する。

一実施形態では、複数の生存モデルを使用して、各セルまたはサブエリアにおける供給、需要、およびサージに基づいて、ジョブ確率および／または収益を予測する。

いくつかの実施形態では、一般性を失うことなく、各ゾーンは、それぞれのジオハッシュである。他の実施形態では、他のタイプのゾーン、例えば、六角形などの非矩形ゾーンが想定される。

実施形態のいくつかの他の特徴は、本明細書の後の従属請求項に記載されている。

実施形態の利点は、最大限のジョブ／稼働率／収益結果の尤度を改善するために、利用可能なデータが処理され、複数のオンラインプロバイダのそれぞれに配信される方法を改善することにある。

図１は、通信システムの概略図を示す。 図２は、地理的領域の概略図を示す。 図３は、アイドル状態のサービスプロバイダと潜在的なターゲット目的地を有する図２の地理的領域を示す。 図４は、再配置ルートの例を示す。 図５は、第１のジオハッシュのすべての第１の層の隣接ジオハッシュのジョブ確率および期待収益を計算することを示す表を示す。 図６は、第１のジオハッシュの第１の層の隣接ジオハッシュのマップを示す。 図７は、ルートを完成するために車両が移動するセルを決定する例示的な例を示す。 図８は、サービスプロバイダを管理するためのプロセスの部分フローチャートを示す。

最初に図１を参照すると、サービスプロバイダを移動させるためのシステム１００が示される。システム１００は、サーバ装置１０２と、サービスプロバイダ通信デバイス１０４と、ユーザ通信デバイス１０６と、データ保存部（本実施形態ではデータウェアハウス２０２）とを含む。これらのデバイスは、例えば、インターネット通信プロトコルを実現するそれぞれの通信リンク１１０、１１２、１１４、２０４を介して、通信ネットワーク１０８（例えば、インターネット）に接続される。通信デバイス１０４、１０６は、他の通信ネットワーク（例えば、移動セルラー通信ネットワークを含む公衆交換電話ネットワーク(ＰＳＴＮネットワーク)など）を介して通信することができる。しかし、これらは、明確にするために図１から省略されている。

サーバ装置１０２は、図１に概略的に示されるように、単一のサーバであり、複数のサーバコンポーネントに分散されたサーバ装置１０２によって実行される機能性を有する。図１の例では、サーバ装置１０２は、多数の個別のコンポーネントを含む。その個別のコンポーネントは、特に限定されないが、１つまたは複数のマイクロプロセッサ１１６と、実行可能命令１２０のローディングのためのメモリ１１８（例えば、ＲＡＭのような不揮発性メモリ）と、を含む。サーバ装置１０２の機能性を定義する実行可能命令は、プロセッサ１１６の制御の下で実行される。サーバ装置１０２はまた、サーバが通信ネットワーク１０８を介して通信することができる入出力モジュール１２２を含む。ユーザインターフェース１２４は、ユーザ制御のために提供され、例えば、ディスプレイモニタ、コンピュータキーボードなどの従来のコンピューティング周辺装置を含む。

サービスプロバイダ通信デバイス１０４は、多数の個別のコンポーネントを含む。その個別のコンポーネントは、特に限定されないが、１つまたは複数のマイクロプロセッサ１２８と、実行可能命令１３２のローディングのためのメモリ１３０（例えば、ＲＡＭのような不揮発性メモリ）と、を含む。サービスプロバイダ通信デバイス１０４の機能を規定する実行可能命令は、プロセッサ１２８の制御の下で実行される。サービスプロバイダ通信デバイス１０４はまた、サービスプロバイダ通信デバイス１０４が通信ネットワーク１０８を介してデータレコードを通信することができる入出力モジュール１３４を含む。データレコード（例えば、ファイル）は、１つまたは複数のフィールドを含む。そのフィールドは、本明細書で説明されるそれぞれのパラメータを表すデータを含む。ルートデータレコードは、以下でさらに詳細に説明するように、例えば、１つまたは複数のルートを表すデータフィールドを含む。スタート位置は「スタート位置」データフィールド内のデータによって表され、目的地位置は「目的地位置」データフィールド内のデータによって表されるなどである。テーブルが図面に示され、以下で説明される場合、データフィールドは、テーブルのセルに示される値を表すデータを含む。そして、複数のデータフィールド（例えば、行全体または行のグループ）は、データレコードを形成するために使用される。

ユーザインターフェース１３６は、ユーザ制御のために提供される。サービスプロバイダ通信デバイス１０４が例えば、スマートフォンまたはタブレットデバイスである場合、ユーザインターフェース１３６は、多くのスマートフォンおよび他の携帯デバイスにおいて普及しているようなタッチパネルディスプレイを有する。あるいは、サービスプロバイダ通信デバイスが例えば、従来のデスクトップコンピュータまたはラップトップコンピュータである場合、ユーザインターフェースは例えば、ディスプレイモニタ、コンピュータキーボード等の従来のコンピューティング周辺装置を有する。

ユーザ通信デバイス１０６は、例えば、サービスプロバイダ通信デバイス１０４と同一または類似のハードウェアアーキテクチャを有するスマートフォンまたはタブレットデバイスである。

この実施形態では、データウェアハウス２０２は、通信リンク２０４を介して、サーバ装置１０２に直接接続される。しかし、これは必須ではない。通信ネットワーク１０８を介した接続も可能である。

一実施形態では、サービスプロバイダ通信デバイス１０４は、サービスプロバイダの状態を示すデータレコードをサーバ装置１０２に定期的にプッシュするように構成される。他の点では、サーバ装置１０２は、サービスプロバイダ通信デバイスに状態情報をポーリングする。このような情報は、サービスプロバイダ通信デバイス１０４の位置を示すデータを含むデータフィールド／レコード、サービスプロバイダが現在アクティブであるかどうか、もしアクティブであれば、プロバイダが非アクティブになるまでどのくらいかかるかなどを含む。いずれの場合も、サービスプロバイダ通信デバイス１０４からのデータレコードは、サーバ装置１０２に通信され、データウェアハウス２０２内の関連する場所に格納される。データウェアハウス２０２内の履歴データは、所定の来るべき期間および任意の所定のエリアにおいてサービスをリクエストするユーザの推定数、その期間において利用可能なサービスプロバイダの推定数、およびそれらの推定地理的分布などの将来の状態を予測するために使用される。

この実施形態の使用において、ユーザは、ユーザ通信デバイス１０６と対話して、サービスをリクエストするデータレコードを入力する。このデータレコードは、サーバ１０２に渡される。サーバは、受信データレコードからデータを抽出し、このデータをデータウェアハウス２０２に保存する。一実施形態では、このようなデータは、とりわけ、特定のユーザ通信デバイス１０６のアイデンティティ、そのデバイスの位置、サービスが要求された時間、サービスの目的地を含む。実施形態では、サーバ装置１０２は、特定のユーザデータを含むデータレコードを特定のサービスプロバイダ通信デバイス１０４に渡す。例えば、ジョブの性質、位置および目的地をすべてのサービスプロバイダデバイス１０４に渡す。一実施形態では、このようなデータは、データウェアハウス２０２に記憶されたデータに従って、特定の基準を満たすサービスプロバイダにのみ渡される。一実施形態における基準は、サービスプロバイダ通信デバイスの位置として、そのデバイスを有するサービスプロバイダが占有されているか、またはフリーであるどうかかを含む。

一実施形態では、マッチング処理は、ユーザがサービスプロバイダからリクエストされたサービスを取得するように、サーバによって実行される。これは、システムによって記録され、データは時間および日付情報と共に、データウェアハウス２０２に格納される。ある時点で、１つまたは複数のサービスプロバイダは、アイドル状態になる可能性がある。アイドル状態は、サービスリクエストを受け入れる準備と意思を意味する。この事実も、一実施形態では、現在アイドル状態にあるサービスプロバイダの日時および位置と共に、データウェアハウス２０２に記録される。

図２を参照すると、地理的領域の概略図は、４×４のマトリクス状に配列された１６のゾーンからなる。このマトリクスのサイズは、説明を簡単にするために選択されたものであり、実際の地理的領域は、より多くのゾーンを有する。以下、ゾーンは、主に「セル」と呼ばれるが、範囲を限定することを意図するものではない。各セルは、本明細書で関心地点（ＰＯＩ）と呼ばれる位置を含む。一実施形態では、関心地点は、ルート選択システムのセットアップ時に選択されるそれぞれのセル内の単一の位置である。この図のセルは、便宜上、１～１６の番号が付されて示されている。そして、セルＣ１３は、サービスプロバイダ車両Ｖである（明確にするために、車両Ｖの表示は図から省略されている）。

別の実施形態では、各セルに多くのＰＯＩが存在する。各セルに対する特定のＰＯＩは、異なる条件に基づいて、特定のサービスプロバイダのために選択される。異なる条件として、サービスプロバイダがそこに行くための距離および時間、ＰＯＩ付近および／またはＰＯＩにおける予測される需要、どのくらいのサービスプロバイダが現在のＰＯＩ付近および／またはＰＯＩにいるか、どのくらいのサービスプロバイダがこのモデルによってＰＯＩに行くことが提案されているか（これは、同じＰＯＩに送信されるサービスプロバイダが多すぎることを回避する）、サービスプロバイダがＰＯＩに留まることができるか、またはＰＯＩ付近に留まることができるかどうか等が挙げられる。

一実施形態では、サーバ１０２は、機械学習プロセスを実行する。この機械学習プロセスは、データウェアハウス２０２内のデータレコード／フィールドにアクセスして、セルごとにサービスプロバイダのアイデンティティにアクセスし、各セル内の供給、需要、およびサージを予測するために、データウェアハウス２０２からの情報を使用する。サービスプロバイダがアイドル状態になったこと、またはアイドル状態になりそうことを示すと、実施形態では、サーバは、機械学習プロセスの結果を使用して、サービスがリクエストされる場所およびその場所へのルート、ならびに／または、そのルートに従うことによって得られる可能性のある収益を評価する。実施形態における結果は、各セルにおける各ルートのスタート時間の推定値と、各セルにおいて費やされた時間の持続時間とを含む。いくつかの実施形態では、機械学習アルゴリズムは、アイドル状態のプロバイダの車両位置から、サービスプロバイダが運転したくない、または運転したくないと予測されるセルの位置を学習する。

機械学習プロセスの非限定的な例では、サーバは、次のステップの一部またはすべてを実行する。

ｉ)複数の地理的エリアのそれぞれについて、供給、需要、およびサージを予測する。例えば、都市を構成する１組のエリアまたはゾーンについて、予測が行われる期間は、（交通状況または都市に特有の他のパラメータに応じて）１つの都市については１５分、別の都市については３０分といった停車時間の期間、または、変動／選択可能な期間のいずれかとして変化させることができる。「変動期間」とは、いかなる制約もなく変化させることができる期間を意味する。「選択可能な期間」とは、選択に利用可能な期間の値の母集団が存在することを意味する。したがって、例えば、１５分の期間は昼間の間に選択されるが、ラッシュアワーについては１０分の期間、および真夜中については３０分の期間が選択される。期間は、時間に依存するか、または適応可能である。その結果、要求が異常に低い場合、システムはそれに応じて期間を変化させる。予測アルゴリズムは、ダブルシーズンホルトウィンター（ＤＳＨＷ）、自己回帰統合移動平均（ＡＲＩＭＡ）等のような時系列モデル、または、再帰型ニューラルネットワーク（ＲＮＮ）、長期短期メモリ（ＬＳＴＭ）のようなＭＬモデルを含む。

ｉｉ）各アイドル状態のサービスプロバイダについて、候補ＰＯＩを見つけ、候補ＰＯＩへのトップＫ走行ルートを見つける。

ｉｉｉ）Ｋ個のルートを軌跡セグメントに分割する。１つ複数の軌跡セグメントを複数のルートで共有することは許容される。

ｉｖ）各軌道セグメントについて、ルーティング距離、リアルタイム交通情報、移動速度などを使用して、軌道セグメントのスタート時間および軌道セグメントで費やされた時間の持続時間を予測する。

ｖ）ＣｏｘのハザードモデルおよびＡａｌｅｎの加法的ハザードモデルなどの生存分析技法を使用して、それぞれのセグメントにおいて費やされた予測スタート時間および継続時間、サービスプロバイダの予測需給および格付け、サービスプロバイダの優先順位、緯度、経度、曜日、時刻、祝日などに基づいて、各軌道セグメントにおいてジョブを達成する尤度を決定する。

ｖｉ）各軌道セグメントについて、ジョブを確保するための予測確率、履歴データからの１移動当たりの平均運賃、１ｋｍ当たりの平均ガソリン費用、１分間当たりの平均ドライバ収入、ルーティング距離、および予想される消費時間の期間および予想されるサージに基づいて、各軌道の期待収益を予想する。

ｖｉｉ）例えば、実際に使用されたルートまたは軌道セグメントに基づいて、実際の結果を使用して予測を形成する際に使用されるデータを更新する。

一実施形態では、サーバ１０２は、複数の生存モデルを使用して、各サブエリアにおける供給、需要、およびサージに基づいて、ジョブ確率および／または収益を予測する。

図２に示すように、ここで説明する実施形態のすべてのセルは、同じサイズおよび形状である。しかし、これは、説明および理解を容易にするためだけのものである。それは、概念にとって基本的ではない。いくつかの実施形態では、セルは、単一の固定されたサイズである。他の実施形態では、セルは、時間および位置に基づいて調整される（例えば、都市中心部のより小さいセル、および周辺国のより大きいセルなど）。同様に、交通条件が時間と共に実質的に変化する場合、いくつかの実施形態におけるセルサイズは、対処するために変更される。したがって、例えば、ＣＢＤは、週末に交通量がほとんどないため、平日のラッシュ時間に使用される比較的小さいセルよりも大きいセルが使用される。利点の１つは、少ない供給および需要しか有さない多くの類似のセルについてメトリックを算出する必要がないことであり、これは最終スコアの算出を節約する。

システムが人間のサービスプロバイダを管理する場合、一実施形態では、ＰＯＩは、サービスプロバイダに知られているどこか、または、サービスプロバイダには明らかなどこかであると選択される。それは、社会的または他の重要性のある場所である必要はなく、例えば単純に駐車場であるかもしれない。上述したように、現在アイドル状態にあるサービスプロバイダ車両Ｖは、領域（Ｃ１３）の左上のセルに位置している。この簡略化された実施形態では、このようなアイドル状態のサービスプロバイダの車両が１つのみと考慮する。実施形態では、おそらく、必ずしもそうではないが、異なるセル内に、相当数のアイドル状態のサービスプロバイダ車両が存在する。いくつかの実施形態では、すぐにアイドル状態になると予測されるプロバイダ車両が同様に考慮され、「アイドル状態のサービスプロバイダ車両」という用語に含まれる。いくつかの実施形態では、サービスプロバイダとして動作する人間のドライバまたはライダは、例えば、専用ボタンを使用して、またはサービスプロバイダ通信デバイス上のＧＵＩと対話することによって、本明細書で説明する動作をリクエストする能力を有する。

予測工程は、全てのセルにおける、需要、サービスプロバイダ供給、およびサージ（すなわち、基本料金から最終料金を計算する乗数）を特定の期間にわたって予測するために実行される。期間は、典型的には、サービスプロバイダ車両が最も遠いゾーンに到達するのにかかる時間の長さに概ね対応する持続時間を有する間近に迫った期間である。予測工程は、本実施形態では、車両がアイドル状態になったときにのみ、または本明細書に記載される操作をリクエストするときにのみ、各アイドル状態のサービスプロバイダの車両に対して実施される。

別の実施形態では、予測工程は、連続的または実質的に連続的に実行される。連続的に行われる予測には、供給、需要、およびサージが含まれる。なお、予測は、このモデルのためだけでなく、システム全体で利用されることも可能である。ＰＯＩの提案に関して、一実施形態では、候補ルートスコアは、サービスプロバイダがアイドル状態になったことに応答して単独で実行されるか、または、サービスプロバイダがこのサポートをリクエストするためにボタンを押すことに応答して単独で実行される。一実施形態における同一のサービスプロバイダに対する結果は、時間ウィンドウの間（例えば、５分間）、キャッシュされる。すなわち、同一時間ウィンドウにおいて同一サービスプロバイダがこれをリクエストする場合、同じ結果が計算を更新せずに与えられる。

一群の実施形態では、どのセルが候補目的地セルであるかについて判定が行われる。「候補目的地セル」は、アイドルサービスプロバイダの位置に十分に近いセルを意味する。一群の実施形態の１つの実施形態では、この決定は、サービスプロバイダがアイドル状態のプロバイダの車両位置から運転したくないと予測されるセルを決定するために、機械学習アルゴリズムを使用して行われる。別の実施形態では、決定は、経験的に到達される。したがって、例えば、４つのセルを通る運転は、限界と見なされる。

次のステップでは、遠すぎるゾーンは考慮されない。本実施例では、ゾーンＣ４は、Ｃ１３から遠すぎるものとして除外される。

別の実施形態では、すべてのセルが考慮される。すなわち、セルは、到達するのに長すぎるか、または遠すぎることに基づいて除外されない。

図３を参照すると、セルＣ１３内の位置「スタート」は、サービスプロバイダがアイドル状態になったポイントである。

次のステップは、スタート位置から各関心地点までの設定された数のルートを識別することである。これは、専用のルート発見アプリケーションを使用することによって実行されてもよく、または任意の他のルート発見アプリケーションによって実行されてもよい。

簡単にするために、図２および図３では、単一の関心地点ＰＯＩ２が考慮される。これは、単に説明のためであることが理解される。実際の例では、除外されていない全ての目的地は、各候補サービスプロバイダ車両に注意を払っている間に考慮される。

図３に示すように、ＰＯＩ２は、セルＣ２内に位置する。スタートからＰＯＩ２への２つのルートが識別される。ルートの数は、状況および位置の性質に応じて決定される。多数の代替ルートが可能である場合、設定された数は、制限される必要がある。この実施形態では、２つのルートは、独自のルートファインダによって提供される２つの代替物である。

システムは、各ルートがどのセル内を移動するかを決定し、いくつかの実施形態では、各ルート上を移動する間に各セル内で費やされる時間の長さを予測する。

第１のルートは、セグメントＳ０（セルＣ１３のスタートセグメント）、Ｓ１、Ｓ２、Ｓ３、およびＳ４（セルＣ２の最終セグメント）からなることに留意されたい。第２のルートは、セグメントＳ５、Ｓ６、Ｓ７、Ｓ８およびＳ９からなる。一実施形態で、「セグメント」は特定のセルを横切るルートの一部であるが、セグメントは代替の方法で定義することができることも理解される。例えば、特定のセルを横切るルートは、２つ以上のセグメントを含む。そのセグメントは、そのセル内の中間点で合流する。

これは、第１のルートがＣ１３、Ｃ１４、Ｃ１０、Ｃ６、Ｃ２を移動し、第２のルートがＣ１３、Ｃ９、Ｃ５、Ｃ１、Ｃ２を移動するということを意味する。

図３の寸法が正確であれば、セルＣ９を横切るルートセグメントＳ６の長さは、セルＣ１４を横切るルートセグメントＳ１の長さよりも長い。Ｃ９で費やされる時間は、Ｃ１４で費やされる時間よりも長い。しかし、これは、セグメントＳ６が高速道路であり、Ｓ１が都市の交通渋滞による遅い移動である場合には真実である必要はない。

セグメントＳ０およびＳ５は同じセルＣ１３内にあるが、本実施形態では、２つのセグメントの「スコア」は、同じである必要はない。実際、それらが同じになる可能性は低い。これは、ドライバがセグメントＳ０上をドライブする場合に、セルＣ１３内のドライバが要する時間の長さが、ドライバがセグメントＳ５上をドライブする場合に、ドライバがセルＣ１３内で費やす時間の長さと異なる可能性があるからである。

そのため、本実施形態は、時間、曜日、道路走行速度の履歴、リアルタイムの交通状況、天候等に基づいて、例えば、機械学習アルゴリズムを使用して、各セルで費やされる時間の持続時間を予測することを含む。

同様に、ルート２を走行するドライバは、ルート１にいる場合（Ｓ４でＣ２に入る）、ドライバの到着時刻とは異なる時刻にセグメントＳ９（セルＣ２）に入る可能性がある。その場合、セグメントＳ９に費やされる時間の長さも、セグメントＳ４の時間の長さとは異なる可能性がある。

本実施形態は、例えば、機械学習アルゴリズムによってこれらの要因を考慮する。

本実施形態では、セル内の距離および時間に関するルートの判定は、ルートが確立されるたびに（すなわち、サービスプロバイダがアイドル状態になるたびに）行われる。他の実施形態では、各ルートのパラメータは、それが最初に確立された後に記憶される。後者の場合、後続のサービスプロバイダがＣ１３でアイドル状態になると、Ｃ２への２つのルートが単にメモリから取得される。システムセットアッププロセス中に、セグメント化された形でルートを作成することも可能である。

いくつかの実施形態では、ルートが１つのセグメントの終わりと次のセグメントの始まりである境界に到達するときから、セル境界を識別することのみが必要である。

いくつかの実施形態では、ルートは、独自のルート発見アプリケーションによって、または、ルート発見プロバイダ（例えば、グーグルマップなど）から提供される。この場合、ルートに沿って、中間点のリストを見つけることができる。たとえ連続的なルートが利用可能でなくても、ルートに沿った点は、それらがどのセル内にあるかに関して識別することができ、このシステムにとって十分である。セルがジオハッシュによって定義される場合、ルート検索プロバイダまたはその他のＡＰＩは、各ポイントがどのジオハッシュに属するのかということを返すことができる。

あるいは、図７を参照すると、スタート点Ａがセル１内にある場合、サーバ装置は、ルート上の点が新しいセル（例えば、点Ａ１）内にあることが見出されるまで、中間点を通過する。ルートが通過するセルをリストするこのプロセスは、エンドポイントセル（セルＢ）まで続く。

他方、システム自体がセルを定義する場合、点がセルに属するか否かが分かる。次に、上記のプロセスを使用して、セルを「ジオハッシュ」のように処理する。

各ルートについて、システムは、サービスプロバイダがそれぞれのルートセグメントが位置するセルにおいてジョブを取得する推定収益および確率について、各セルにスコアを付ける。各セルにおけるジョブの尤度のスコアリングは、予測される供給、需要、および関心のセルに費やされると予測されるルートセグメントの継続時間に少なくとも部分的に基づいている。

次に、システムは、ルートセグメントの計算された値を使用することによって、このルートの予想収益と、ルート全体（最初のセルおよび最後のセルを含む）についてのジョブの確率と、を計算する。ルートはランク付けされ、最良の確率または最高の予測収益の予測を有するルートが選択される。

図３のような単純な設定では、ランキングは、Ｃ１３に留まることによってジョブを確保する確率の比較である。これは、Ｃ１３についての予測された供給、需要、およびサージを使用し、ＰＯＩ２への２つのルートのそれぞれについての予測を比較する。

別の配置では、検討中の複数の目的地セルがある。それぞれは、アイドル状態のサービスプロバイダが位置するスタート位置から目的地への１つまたは複数のルートを有する。

サービスプロバイダが人間のドライバである場合、次のステップは、推奨される目的地ＰＯＩおよびそのＰＯＩへの好ましいルートのドライバ（およびこの実施形態ではドライバのみ）に通知するために、関連するドライバの通信デバイスにメッセージを送信することである。自律車両が使用される場合、メッセージは、代わりに、一実施形態では、車両の目的地およびルートを直接制御する。

明確にするために、各セルは、ルートを構成するセグメントの各セットに含まれることに留意されたい。また、上述のように、１つのルートは、スタートセル内でスタートする位置にあることができることに留意されたい。例えば、ユーザが出発セルの列車駅で自分のルートを終了し、本システムが、高い確率のジョブが出発セルのショッピングモールでも見つかると予測する場合、サービスプロバイダは、単に、ショッピングモールまたはその周辺に移動することによってジョブを待つように、出発セルに留まるメッセージを受信する。

一実施形態では、生存分析を使用して、各ルートセグメントにおいて予測する供給、需要、およびサージに基づいて、ジョブ確率を推定する。

ここで、特定の実施形態で使用される詳細な技術の例を説明する。この実施形態では、セルは、ジオハッシュとして定義される。ジオハッシュは、英数字文字列を使用して、位置（世界中のどこでも）を表現する便利な方法と見なすことができる。より小さいセルは、より長いストリングを使用して定義される。付加された文字は、前のセルサイズの３０分の１のセルを定義する。

異なる長さのジオハッシュのセルサイズは、以下の通りである。セル幅が赤道から離れるにつれて減少する（磁極で０になる）ことに留意されたい。

ジオハッシュ長さ セル幅 セルの高さ
１ ≦５，０００ｋｍ × ５，０００ｋｍ
２ ≦１，２５０ｋｍ × ６２５ｋｍ
３ ≦１５６ｋｍ × １５６ｋｍ
４ ≦３９．１ｋｍ × １９．５ｋｍ
５ ≦４．８９ｋｍ × ４．８９ｋｍ
６ ≦１．２２ｋｍ × ０．６１ｋｍ
７ ≦１５３ｍ × １５３ｍ
８ ≦３８．２ｍ × １９．１ｍ
９ ≦４．７７ｍ × ４．７７ｍ

ジオハッシュのサイズ（および他の実施形態では、他の方法で定義されるゾーンまたはセルのサイズ）は、人口密度、サービスプロバイダの数などの特徴に従って選択される。一実施形態では、ジオハッシュ長さ６が使用される。異なる都市の実施形態では、異なるセルサイズが存在する。また、同じ都市について、上述したように、いくつかの実施形態では、異なるセルサイズは、時間および位置に基づいて選択される。

ジオハッシュは長方形であるが、本発明はそのように限定されず、他の実施形態では他の形状が想定される。

本実施形態では、セルは、各セル内の状況が類似するように分離される。各サブエリアは、ジオハッシュ、または、いくつかのジオハッシュまたは特定のエリアの組み合わせであることができる。

一実施形態では、サーバ１０２は、複数の機械学習アルゴリズムを使用して、各セルにおける供給、需要、およびサージを予測する。

各セル内のルートのスタート時間も、機械学習アルゴリズムによって推定される。たとえば、サービスプロバイダは、９：００にＡ地点からＢ地点に移動し始め、セル１、２、３を通過してＢ地点に行く。例えば、セル２に９：０４に到着し、セル３に９：０６に到着し、目的地Ｂに９：１０に到着した場合、サーバ１０２の供給、需要、およびサージ予測は、エリア２で９：０４から９：０６になる。

一実施形態では、サーバ１０２は、複数の生存モデルを使用して、各サブエリアにおける供給、需要、およびサージに基づいてジョブ確率を予測する。上記の例では、エリア２のジョブ確率は、Ｐｂａｒ１×Ｐ［９．０４－９．０６］である。

「Ｐｂａｒ１」はサービスプロバイダがエリア１でジョブを取得しない確率であり、Ｐ［９．０４－９．０６］はサービスプロバイダが９：０４から９：０６までジョブを取得する確率である（サービスプロバイダが９：０４から９：０６までジョブを取得する確率は、生存モデルから予測される）。

サービスプロバイダが推奨場所Ｂに行くことに応じる場合、供給数字は更新される。

上記の例では、サービスプロバイダは、９：０４～９：０６のエリア２にいる。ユーザは、推奨ルートに沿ってセル内でいつでもアクティブになる。そして、以前にアイドル状態になっていたサービスプロバイダは、そのユーザによってリクエストされたジョブを受け入れることを選択する。これらに留意する必要がある。

本実施形態は、データ分析（例えば、ＰｙｔｈｏｎパッケージＰａｎｄａｓにおけるＤａｔａｆｒａｍｅ、ＲにおけるＤａｔａｆｒａｍｅ、ＳｃａｌａにおけるＤａｔａＦｒａｍｅ）を行うために、サイズ変異可能な異種の表データ構造を使用する。

図４は、再配置ルートの例を示している。各グリッドは、ジオハッシュを表す。異なるジオハッシュ内の異なるルートセグメントは、異なる色で表示される。ルートは、各セグメントが１つのジオハッシュまたは１つのみのジオハッシュ（セル）に属するように、セグメントに分離される。サービスプロバイダの現在位置から目的地（すなわち、ターゲットジオハッシュにおけるＰＯＩ）までのこのルートに５つのルートセグメントがある。

サービスプロバイダが同じセルに滞在する場合に、待ち時間にジョブを得る確率を推定するために、この確率は、Ｆ（ｔ）として示される。これは、生存分析における寿命分布関数とも呼ばれる。そして、生存関数は、Ｓ（ｔ）＝１－Ｆ（ｔ）である。この実施形態において、生存モデルは、例えば、データウェアハウス２０２からの履歴データから、そこに格納された特徴データを使用することによってトレーニングされる。「特徴データ」は、ジオハッシュの集約された需要および供給、ドライバ評価、ドライバ優先度、中央ビジネス区域であるかどうか、平日であるかどうか、ピーク時であるかどうかなどの一部またはすべてを含む。ジョブ確率は、特徴を考慮して、Ｆ（ｔ；ｘ）で示される。式中、ｘは、特徴ベクトルである。

式ｐ_ｉは、サービスプロバイダが、時間ｔ_ｉ－１前にジョブが発生しないことを与えられた期間（ｔ_ｉ－ｔ_ｉ－１）待っている時、ｉ番目のルートセグメント（ルートに沿ったｉ番目のセル）内でジョブを取得する条件付き確率である。（すなわち、サービスプロバイダは（ｉ－１）番目のセルに入る前に、まだジョブを取得していない）。

ｘ_ｉがｉ番目のルートセグメントの特徴ベクトルと仮定すると、第１のセル（セル１）について、ｐ_１は、ｐ_１＝Ｆ（ｔ_１－ｔ_０；ｘ_１）によって与えられる。

次に、次のジオハッシュｐ_２は、ｐ_２＝Ｆ（１－ｐ_１）Ｆ（ｔ_２－ｔ_１；ｘ_２）によって与えられ、ｐ_３＝（１－ｐ_１－ｐ_２）Ｆ（ｔ_３－ｔ_２；ｘ_３）、・・・・によって与えられる。

一般に、ルートがｎ個のセグメントを持つ場合、次の式で表される。

サービスプロバイダがスタートから終了までのルートに沿って移動していると予測される時間ウィンドウＴの間にジョブを取得する確率は、下記式によって与えられる。

Ｔは、いくつかの実施形態では、サービスプロバイダがジョブの探索中に移動する可能性が高い最大時間として選択される持続時間である。

ここで、ｓ_ｉ（ｔ）は、時間ｔにおけるｉ番目のルートセグメント（ルートに沿ったｉ番目のセル）のサージである。ｄ_ｉ、ｔ_ｉは、それぞれ、現在位置からｉ番目のルートセグメントの最後の地点までの距離、時間である。ｆは、ジョブ当たりの平均基本料金である。ｃは、１ｋｍ当たりの平均燃料コストである。ｖは、１秒当たりの平均収入である。特に、セットｄ_０＝０、ｔ_０＝０、ｔ_ｎ＝Ｔである。

Ｔは、所定の最大カット持続時間（例えば、サービスプロバイダがジョブを探して移動する可能性が最も高い時間）である。したがって、たとえば、特定のアプリケーションでは、Ｔ=１０分である。任意の特定のセルは、サービスプロバイダがＴ＝１０分以内に到着でき、ルート距離が所定のしきい値以下である場合およびその場合にのみ、アイドル状態のサービスプロバイダの位置に隣接する候補隣接セルと見なされる。あるいは、別の方法では、「Ｔは、任意の候補隣接セルの任意の到着時間よりも長い所定の停止時間である」。サービスプロバイダがＴ＝１０分以内にセルＡに到着できない場合、セルＡは、全く考慮されない。理解されるように、１０分は一例に過ぎず、他の持続時間も可能である。

目的地ジオハッシュへの１つのルートの期待収益Ｅは、下記式によって与えられる。

ここで、ｒ_ｉは、ｉ番目のルートセグメント内の推定収益である。
ｒ_ｉ＝ｆ×ｓ_ｉ（ｔ_ｉ）－ｃ×（ｄ_ｉ－ｄ_ｉ－１）－ｖ×（ｔ_ｉ－ｔ_ｉ－１）

図５は、ジオハッシュのすべての第１の層の隣接ジオハッシュのジョブ確率および期待収益を計算する例を示す。この例では、現在の位置から各目的地へのルートが１つだけ見つかる。この表は、期待収益の降順にソートされる。

図６のマップでは、各ジオハッシュの中心は、それぞれの目的地ＰＯＩとして設定されている。このマップは、図５のテーブルに対応している。両方の図を参照すると、目的地３は１５分以内にジョブの最高確率を有するが、目的地１は最高期待収益を有することが分かる。出発点に近い目的地４は、仕事の確率が比較的低く、予想される収益が比較的低い。

１つのセル（例えば、ジオハッシュ）の需要および供給が計算されるとき、サービスプロバイダは、隣接するセルにおいてジョブを得るので、隣接するジオハッシュの数を集約することが必要である。

生存回帰モデルを訓練するために、利用可能なオンライン待機時間は、所定の時間ウィンドウ内の各サービスプロバイダのリアル待機時間として、システムによって計算される。さらに、サービスプロバイダは、待機時間中にジョブを取得しても取得しなくてもよい。打ち切り（Censoring）は、サービスプロバイダが待ち時間ｔの間にジョブを取得せず、システムがサービスプロバイダのジョブを取得するための待ち時間が少なくともｔであることのみを知っている場合に発生する。実際、使用される生存回帰モデルは、打ち切りを扱うことができる。

上述したように、期待収益は、離散（discrete）の方法で計算される。

代替的に、各ルートの予想収益を下記連続バージョンで計算することもできる。

この場合、ｒ（ｔ）は、時間ｔでの予想収益である。Ｆ（ｔ）は、サービスプロバイダが待ち時間ｔの間のジョブを取得する確率である。

ここで図８を参照すると、サーバ１０２で実行されるプロセスの一実施形態のフローチャートの一部の概略図が示されている。

ブロック５０２は、使用中、サービスプロバイダ通信デバイス１０４によってサーバ装置１０２にプッシュされるタイプの入力データレコードを表す。入力データレコード５０２は、データレコードを発信するサービスプロバイダ通信デバイス１０４を示す情報を保持するフィールドと、現在位置、アイドル状態であるか否か、現在のジョブの終了までの予測時間などの項目のフィールドとを含む。

入力データレコード５０２は、サービスプロバイダデータフィールドがプロバイダがアイドル状態になったことを示すかどうかをテストするサーバの決定プロセス５０４に渡される。プロバイダがアイドル状態であることが判明した場合、決定プロセス５０４は、パケットをルート提案プロセス５１０に渡し、サーバ装置からデータウェアハウス２０２に他のデータを渡す。プロバイダがアイドル状態でない場合、決定プロセス５０４は、現在のサービスプロバイダの位置データを含むパケットをデータウェアハウス２０２に渡して、そこに記憶する。

決定プロセス５０４がデータレコードをルート提案プロセス５１０に渡す場合、データレコードは、それによって、セル決定プロセス５１４に渡される。セル決定プロセス５１４は、複数の候補目的地セルを示すデータレコードのセットを決定する。

候補目的地セルは、この実施形態では、システムによって監視されるすべてのセルのサブセットである。例えば、アイドル状態のサービスプロバイダの位置から遠すぎないと見なされるセルである。「遠すぎない」パラメータは、セル決定プロセス５１４に入力されるか、または、セル決定プロセス５１４によって保持されるパラメータによって設定される。

データレコード５０２を生じさせる各候補目的地セルおよびサービスプロバイダ通信デバイスを示すフィールドを含むデータレコードは、位置プロセス５１６に渡される。これは、各候補目的地セル内の関心地点（ＰＯＩ）を決定し、各目的地を示す目的地データレコードを提供する。

次いで、目的地データレコードは、ルートファインダアプリケーション５４０に渡される。これは、各ＰＯＩへのルートの詳細を含むルートデータレコードを返す。目的地ルートレコードは、ルート分解プロセス５１８に渡される。ルート分解プロセス５１８は、それぞれのルートが通過するセルのセットを含むセルデータレコードを含む分解されたルートデータレコードを提供する。セルデータレコードは、ルートアセンブリプロセス５２２に渡される。

位置プロセス５１６はまた、メッセージを発信するサービスプロバイダ通信デバイスを示す情報を含むデータレコードの一部をルートセグメントプロセス５１８に渡す。ルート分解プロセス５１８は、メッセージを発信するサービスプロバイダ通信デバイスを示す情報をルートアセンブリプロセス５２２に渡す。

ルートアセンブリプロセス５２２は、予測プロセス５２０から、セル当たりのジョブ確率の予測を含む予測データレコードを受け取る。予測プロセス５２０は、データウェアハウス２０２にアクセスし、特徴（例えば、各セルの供給、需要、および可能性のあるチャージ量など）を予測することができるように、履歴データおよび他のデータを使用する。

予測データレコードは、ルートアセンブリプロセス５２２において、ルート分解プロセス５１８からのセグメント情報と結び付けられて、このルート上で生じるジョブからの予想される収益と、予測されたジョブ確率との各ルートについてのスコアを提供する。

一実施形態では、予測プロセスは、実質的に常に生じる。別の実施形態では、予測プロセスは、必要なとき（例えば、サービスプロバイダがアイドル状態になったとき、またはこの支持を求めるリクエストが受信されたとき）にのみ行われる。この場合において、全てのＰＯＩへのルート上のジオハッシュよりむしろ、ルート内のジオハッシュのみ（すなわち、候補目的地ＰＯＩのみ）が考慮されるので、予測の計算を削減することができる。

次いで、メッセージを発信するサービスプロバイダ通信デバイスを示す情報とともに、これらの推定値は、比較プロセス５２４に適用され、出力プロセス５２６に供給される。比較プロセス５２４は、ジョブの最も高い予測または最も高い予測収益を有するルートを選択するように、ルートをランク付けする。出力プロセスは、比較プロセス５２４から提供された情報を使用して、選択されたルート上のデータを、メッセージを発信するサービスプロバイダ通信デバイスに出力させる。一実施形態では、このルートデータは、アイドルメッセージを発信するサービスプロバイダ通信デバイスにのみ提供される。

サービスプロバイダが人間のドライバである場合、このルートデータは、サービスプロバイダ通信デバイスがドライバの注意を提案ルートに引き付けることができる形式である。これは、視覚的なディスプレイ上にあってもよいし、音声の提案であってもよい。データは、サービスプロバイダの車両のナビゲーションデバイス上に即座に表示する形式で出力される。自律走行車両がサービス提供車両である場合、出力プロセスによって送られるデータは、典型的には、決定された目的地に移動する車両に命令するようにフォーマットされる。一群の実施形態では、システムは、サービスプロバイダが通常の運転速度で目的地に直接行くことが想定されるので、目的地でのみ待機時間を考慮する。人間のドライバに中間セルで待つように伝えることは困難である。他の実施形態において（例えば、いわゆる「ドライバレス車両」のための実施形態に限定されない）、これが仕事の機会または利益のある仕事の機会を改善するときに、中間位置で停止するように指示が与えられる。

人間のサービスプロバイダの場合、送信されるメッセージは、待ち時間の予測を含む。例えば、特定の目的地で約５分待つ場合に、ジョブを期待できることをプロバイダに伝えることを含む。ただし、５分以内にジョブの保証はない。

ドライバに示される異なる目的地での待ち時間は変化する。しかし、最適なルートが計算されるとき、全てのルートに対して公平になるように、カットオフ時間Ｔが必要である。

本発明は、例としてのみ記載されていることが理解される。添付の特許請求の範囲の精神および範囲から逸脱することなく、本明細書で説明される技術に様々な修正を行うことができる。開示された技術は、スタンドアロン方式で、または互いに組み合わせて提供され得る技術を含む。したがって、１つの技術に関して説明した特徴は、別の技術と組み合わせて提示することもできる。

Claims (23)

1. プロセッサと、メモリとを含むルート情報を処理するためのサーバ装置であって、
   前記サーバ装置は、前記プロセッサの制御の下、前記メモリに記憶された命令を実行するように構成され、
   ａ．スタート位置と、前記スタート位置からの少なくとも１つのルートを有する目的地との間にある複数のルートの詳細を含むルートデータレコードを生成し、
   ｂ．各前記ルートを構成し、ゾーンに位置するルートセグメントを示すセグメントデータレコードを決定するために前記ルートデータレコードを分解し、
   ｃ．前記ルートを構成する前記ルートセグメントにおける予測値に基づいて、前記目的地までの前記ルートを構成するルートデータをスコア化するように、前記ルートを構成する前記ルートセグメントについての前記予測値を含む予測データレコードと前記セグメントデータレコードを結び付けるように構成されていることを特徴とするサーバ装置。
2. 前記予測データレコードは、前記ゾーンにおけるジョブの尤度の予測を含む請求項１に記載のサーバ装置。
3. 前記予測データレコードは、前記ゾーンにおける見込み収益の予測を含む請求項１または２に記載のサーバ装置。
4. 入力データレコードがアイドル状態になったサービスプロバイダを示すデータを含むかどうかを判定するために、サービスプロバイダ通信デバイスの前記入力データレコードを処理し、それに応答して、前記ルートデータレコードを生成する工程を開始するようにさらに構成される請求項１に記載のサーバ装置。
5. 最高スコアを有する前記ルートを示すデータを前記サービスプロバイダ通信デバイスに送信するようにさらに構成される請求項４に記載のサーバ装置。
6. サービスプロバイダデバイスに表示するための少なくとも１つのスコア付けされたルートを示すデータを出力するように動作可能である請求項１ないし５のいずれかに記載のサーバ装置。
7. 目的地を有する複数のゾーンで構成された地理的エリア内のサービスプロバイダのルート情報を処理するサーバ装置において実行される方法であって、
   前記方法は、前記サーバ装置のプロセッサの制御の下、
   ａ．スタート位置と、前記スタート位置からの少なくとも１つのルートを有する目的地との間にある複数のルートの詳細を含むルートデータレコードを確立する工程と、
   ｂ．各前記ルートを構成し、各前記ゾーンに位置するするルートセグメントを示すセグメントデータレコードを決定するために前記ルートデータレコードを分解する工程と、
   ｃ．前記ルートを構成する前記ルートセグメントのための予測値を含む予測データレコードと前記セグメントデータレコードを結び付ける工程と、前記ルートを構成する前記ルートセグメントにおける前記予測値に基づいて、前記目的地への前記ルートを構成するルートデータをスコアリングする工程と、
   を含むことを特徴とする方法。
8. 前記予測データレコードは、前記ゾーンにおけるジョブの尤度の予測をさらに含む請求項７に記載の方法。
9. 前記値は、前記ゾーンにおける見込み収益の予測を含む請求項７に記載の方法。
10. 前記ルートを構成する前記ゾーンは、前記スタート位置を含む請求項７ないし９のいずれかに記載の方法。
11. 前記ルートを構成する前記ゾーンは、前記目的地を含む請求項７ないし１０のいずれかに記載の方法。
12. 前記スコア化されたルートから、最高スコアを有する前記ルートを決定する工程をさらに含む請求項７に記載の方法。
13. 前記最高スコアを有する前記ルートを示すデータを、表示のためにサービスプロバイダデバイスに通信する工程をさらに含む請求項１２に記載の方法。
14. サービスプロバイダ通信デバイスから受信されたメッセージに応答して、前記複数のルートを確立する工程を開始する工程をさらに含む請求項１３に記載の方法。
15. 前記最高スコアを有する前記ルートを示すデータを前記サービスプロバイダ通信デバイスのみに送信する工程をさらに含む請求項１４に記載の方法。
16. 前記メッセージは、サービスプロバイダ通信デバイスが位置する前記ゾーンを示すデータを含む請求項１４に記載の方法。
17. 前記複数のルートを確立する工程において使用するための候補目的地を決定する工程と、
    前記候補目的地ではない前記目的地を無視する工程とをさらに含み、
    前記候補目的地を決定する工程は、前記スタート位置からの移動時間を予測する工程と、
    所定時間未満の予測移動時間を有する前記ルートを前記候補目的地として選択する工程とを含む請求項７ないし１６のいずれかに記載の方法。
18. 前記ルートをスコアリングする工程は、前記ゾーンにおけるジョブの確率を決定するために前記ゾーンをスコア化する工程と、ルートスコアを達成する確率を合計する工程とを含む請求項１２に記載の方法。
19. 各前記ルートをスコアリングする工程は、前記ゾーンにおける見込み収益の予測を決定するために前記ゾーンをスコア化する工程と、ルートスコアを達成する確率を合計する工程とを含む請求項１２に記載の方法。
20. すべてのゾーンについて、ユーザの数および利用可能なサービスプロバイダの数を予測することによって、ジョブの確率の予測を形成する工程をさらに含む請求項７ないし１９のいずれかに記載の方法。
21. すべてのゾーンについて、サービスリクエストの数および利用可能なサービスプロバイダの数を予測することによって、見込み収益の予測を形成する工程をさらに含む請求項７ないし２０のいずれかに記載の方法。
22. すべての候補ゾーンを検索する工程と、前記スタート位置から関心地点（ＰＯＩ）までの最大トップｋの走行軌跡および履歴予約に基づいて、前記候補ゾーン内の前記関心地点を検索する工程とをさらに含み、
    前記候補ゾーンは、前記スタート位置から所定の閾値未満の距離を有するゾーンである請求項１４に記載の方法。
23. 前記ゾーンは、ジオハッシュである請求項７ないし１６のいずれかに記載の方法。

Images