(57)【要約】  実施形態は、輸送要求情報に関連付けられた位置のピックアップ位置スコア（ＰＬｏＳ）に基づいて代替要求位置を決定するための、システムおよび方法を含む技術を提供する。ピックアップ位置スコアは、プロバイダによるピックアップのための位置の適合性の客観的な定量的測定値が含まれ得る。例えば、実施形態は、要求位置を含むリクエスタコンピューティングデバイスに関連付けられた輸送要求情報を受信し、要求位置の閾値距離内にある１つまたは複数の代替要求位置の各々の位置スコアに少なくとも基づいて修正要求位置を決定し、修正要求位置と第１のリクエスタコンピューティングデバイスとに関連付けられた修正輸送要求情報を、輸送要求情報にマッチしたプロバイダに関連付けられたプロバイダコンピューティングデバイスに送信し得る。【選択図】図１
2020520010.tif 000002
【特許請求の範囲】
【請求項１】
動的輸送マッチングシステムにより、リクエスタに関連するリクエスタコンピューティングデバイスから輸送要求情報を受信することであって、前記輸送要求情報はピックアップの要求位置を含む、前記受信することと、
前記動的輸送マッチングシステムにより、前記要求位置の閾値距離内にある１つまたは複数の代替要求位置の各代替要求位置の位置スコアに少なくとも基づいて、前記要求位置に関連する修正要求位置を決定することと、
前記動的輸送マッチングシステムにより、前記修正要求位置と前記リクエスタコンピューティングデバイスとに関連する修正輸送要求情報を、前記輸送要求情報にマッチしたプロバイダに関連するプロバイダコンピューティングデバイスに送信することと、
を含む方法。
【請求項２】
各代替要求位置の位置スコアは、前記ピックアップに対する各代替要求位置の適合度を示す
請求項１に記載の方法。
【請求項３】
前記ピックアップに対する各代替要求位置の適合度は、前記代替要求位置の各々に関連する予想遅延またはキャンセル確率のうちの少なくとも１つと相関する
請求項２に記載の方法。
【請求項４】
各代替要求位置に対するプロバイダとリクエスタとの間の連絡率の履歴、各代替要求位置に対するプロバイダ到着からリクエスタピックアップまでの推定時間、各代替要求位置に対する前記マッチしたプロバイダへの前記リクエスタの移動の推定距離、または、各代替要求位置に対するキャンセル率の履歴、の少なくとも１つに基づいて、各代替要求位置の位置スコアを決定することをさらに含む
請求項１に記載の方法。
【請求項５】
各代替要求位置の位置スコアは、前記輸送要求情報に関連する時間、前記輸送要求情報に関連する日、前記輸送要求情報に関連する道路状況、または、前記輸送要求情報に関連する天気、の少なくとも１つに基づく
請求項４に記載の方法。
【請求項６】
前記要求位置に関連する修正要求位置を決定することは、
前記要求位置の要求位置スコアを決定することと、
前記要求位置の前記閾値距離内にある前記１つまたは複数の代替要求位置を決定することと、
前記１つまたは複数の代替要求位置の各代替要求位置の各位置スコアを決定することと、
前記要求位置スコアを各代替要求位置の各位置スコアと比較することと、
各代替要求位置の各位置スコアを前記要求位置の前記要求位置スコアと比較することに少なくとも部分的に基づいて、選択された代替要求位置を決定することと、
をさらに含む
請求項１に記載の方法。
【請求項７】
前記要求位置に関連する修正要求位置を決定することの前に、
前記要求位置の要求位置スコアを決定することと、
前記要求位置の前記要求位置スコアを閾値位置スコアと比較することと、
前記要求位置の前記要求位置スコアが前記閾値位置スコアを満たしていないことを決定することと、
をさらに含む
請求項１に記載の方法。
【請求項８】
地理的領域内の１つまたは複数の建物の建物境界を決定することと、
前記地理的領域の複数の経路のレイアウトを決定することと、
前記複数の経路の推定中心線から前記建物境界までの距離に基づいて、前記複数の経路の幅を決定することと、
前記複数の経路のそれぞれの経路に接する１つまたは複数の縁石セグメントを、少なくともそれぞれの経路の幅と前記建物境界とに基づいて、決定することと、
前記１つまたは複数の縁石セグメントの位置を記述する縁石セグメントデータを保存することであって、前記縁石セグメントデータは前記１つまたは複数の建物の位置と複数の経路の前記レイアウトとに関して特定の縁石セグメントを識別する、前記保存することと、
をさらに含む
請求項１に記載の方法。
【請求項９】
少なくとも前記縁石セグメントデータに基づいて、前記要求位置の前記閾値距離内にある１つまたは複数の縁石セグメントを決定することと、
前記１つまたは複数の縁石セグメントの交点を決定することと、
各交点に対して、交差する各縁石セグメントに沿った１つまたは複数の代替要求位置を決定することであって、前記１つまたは複数の代替要求位置の各々は前記交点からの閾値距離である、前記決定することと、
をさらに含む
請求項８に記載の方法。
【請求項１０】
前記要求位置の要求位置スコアに関連する第１のピックアップ遅延時間を決定することと、
前記修正要求位置の前記位置スコアに関連する第２のピックアップ遅延時間を決定することと、
前記リクエスタコンピューティングデバイスに、少なくとも前記代替要求位置へのナビゲーションルートを含むマッピングデータを表示させることと、
前記リクエスタコンピューティングデバイスに、前記第１のピックアップ遅延時間と前記第２のピックアップ遅延時間と間の差を含む、前記代替要求位置に対応する情報を表示させることと、
前記リクエスタコンピューティングデバイスから、前記代替要求位置の選択の指示を受信することと、
をさらに含む
請求項１に記載の方法。
【請求項１１】
歩行距離選好データ、歩行履歴データ、年齢、平均歩行速度データ、標高データ、天気データ、現在時刻、または道路安全データ、の少なくとも１つを含む前記リクエスタに関連するデータに基づいて、前記１つまたは複数の代替要求位置のサブセットを決定することと、
前記リクエスタコンピューティングデバイスに、前記１つまたは複数の代替要求位置の前記サブセットを表示させることと、
前記リクエスタコンピューティングデバイスから、代替要求位置の前記サブセットから選択された代替要求位置を受信することと、
をさらに含む
請求項１に記載の方法。
【請求項１２】
プロセッサとコンピュータ可読媒体とを有するコンピューティングデバイスであって、  前記コンピュータ可読媒体は、前記プロセッサによって実行可能なコードであって、前記コンピューティングデバイスに、
リクエスタに関連するリクエスタコンピューティングデバイスに関連する輸送要求情報を受信させ、前記輸送要求情報はピックアップの要求位置を含み、
前記要求位置の閾値距離内にある１つまたは複数の代替要求位置の各代替要求位置の位置スコアに少なくとも基づいて、前記要求位置に関連する修正要求位置を決定させ、
前記修正要求位置に関連する修正輸送要求情報を、前記リクエスタコンピューティングデバイスと前記輸送要求情報にマッチしたプロバイダに関連するプロバイダコンピューティングデバイスとに送信させる、
ためのコードを含む
コンピューティングデバイス。
【請求項１３】
前記コンピューティングデバイスに、
各代替要求位置に対するマッチしたプロバイダとリクエスタとの間の連絡率の履歴、各代替要求位置に対するプロバイダ到着からリクエスタピックアップまでの推定時間、または、各代替要求位置に対する前記マッチしたプロバイダへの前記リクエスタの移動の推定距離、の少なくとも１つに基づいて、各代替要求位置の位置スコアを決定させる、
ためのコードをさらに含む
請求項１２に記載のコンピューティングデバイス。
【請求項１４】
各代替要求位置の位置スコアは、前記輸送要求情報に関連する時間、前記輸送要求情報に関連する日、前記輸送要求情報に関連する道路状況、または、前記輸送要求情報に関連する天気、の少なくとも１つに基づく
請求項１３に記載のコンピューティングデバイス。
【請求項１５】
前記要求位置に関連する修正要求位置を決定することは、前記コンピューティングデバイスに、
前記要求位置の要求位置スコアを決定させ、
前記要求位置の前記閾値距離内にある前記１つまたは複数の代替要求位置を決定させ、
前記閾値距離内にある前記１つまたは複数の代替要求位置の各代替要求位置の各位置スコアを決定させ、
前記要求位置スコアを各代替要求位置の各位置スコアと比較させ、
各代替位置スコアを前記要求位置スコアと比較することに少なくとも部分的に基づいて、選択された代替要求位置を決定させる、
ためのコードをさらに含む
請求項１２に記載のコンピューティングデバイス。
【請求項１６】
前記要求位置に関連する修正要求位置を決定することの前に、前記コンピューティングデバイスに、
前記要求位置の要求位置スコアを決定させ、
前記要求位置の前記要求位置スコアを閾値位置スコアと比較させ、
前記要求位置の前記要求位置スコアが前記閾値位置スコアを満たしていないことを決定させる、
ためのコードをさらに含む
請求項１２に記載のコンピューティングデバイス。
【請求項１７】
前記コンピューティングデバイスに、
歩行距離選好データ、歩行履歴データ、年齢、平均歩行速度データ、標高データ、天気データ、現在時刻、または道路安全データ、の少なくとも１つを含む前記リクエスタに関連するデータに基づいて、前記１つまたは複数の代替要求位置のサブセットを決定させ、
前記リクエスタコンピューティングデバイスに、前記１つまたは複数の代替要求位置の前記サブセットを表示させ、
前記リクエスタコンピューティングデバイスから、代替要求位置の前記サブセットから選択された代替要求位置を受信させる、
ためのコードをさらに含む
請求項１２に記載のコンピューティングデバイス。
【請求項１８】
リクエスタコンピューティングデバイスから、ピックアップの縁石セグメントに関連する要求位置を含む輸送要求を受信し、
前記縁石セグメントの位置スコアを決定し、
前記要求位置に関連する複数の代替要求位置を、前記複数の代替要求位置の複数の代替位置スコアと前記縁石セグメントの前記位置スコアとに少なくとも基づいて決定し、
前記複数の代替要求位置を、前記リクエスタコンピューティングデバイスとプロバイダコンピューティングデバイスとに送信する
ように構成された動的輸送マッチングシステムを含むシステム。
【請求項１９】
前記複数の代替要求位置の前記複数の代替位置スコアは、前記輸送要求に関連する時間、前記輸送要求に関連する日、前記輸送要求に関連する道路状況、または、前記輸送要求に関連する天気、の少なくとも１つに基づく
請求項１８に記載のシステム。
【請求項２０】
前記要求位置に関連する複数の代替要求位置を決定することは、前記コンピューティングデバイスに、
前記縁石セグメントの前記位置スコアに少なくとも部分的に基づいて、前記要求位置の要求位置スコアを決定させ、
前記要求位置の閾値距離内にある１つまたは複数の代替要求位置を決定させ、
前記閾値距離内の前記１つまたは複数の代替要求位置の代替位置スコアを決定させ、
前記要求位置スコアを前記１つまたは複数の代替要求位置の代替位置スコアの各々と比較させ、
前記代替位置スコアを前記要求位置スコアと比較することに少なくとも部分的に基づいて、選択された代替要求位置を決定させる
請求項１８に記載のシステム。
【請求項２１】
動的輸送マッチングシステムにより、第１のリクエスタコンピューティングデバイスに関連する第１の輸送要求情報を受信することであって、前記第１の輸送要求情報は第１の要求位置および第１の目的地位置を含む、前記受信することと、
前記動的輸送マッチングシステムにより、マッチしたプロバイダを、前記第１の要求位置から前記第１の目的地位置への前記マッチしたプロバイダの第１の推定至目的地時間（ＥＴＤ）に少なくとも基づいて決定することと、
前記動的輸送マッチングシステムにより、第１のリクエスタが前記第１の要求位置から前記第１の要求位置の閾値距離内にある複数の代替要求位置の各々に移動する推定移動時間（ＥＴＴ）を決定することであって、前記複数の代替要求位置は複数の縁石セグメントに対応する、前記決定することと、
前記動的輸送マッチングシステムにより、前記複数の代替要求位置の１つから前記第１の目的地位置への前記マッチしたプロバイダの第２のＥＴＤを決定することであって、前記第２のＥＴＤはそれぞれのＥＴＴを含む、前記決定することと、
前記動的輸送マッチングシステムにより、前記代替要求位置から前記第１の目的地位置への前記第２のＥＴＤが前記第１の要求位置から前記第１の目的地位置への前記第１のＥＴＤより小さいことを決定することと、
前記動的輸送マッチングシステムにより、前記代替要求位置と前記第１のリクエスタコンピューティングデバイスとに関連する修正された第１の輸送要求情報を、前記マッチしたプロバイダに関連するプロバイダコンピューティングデバイスに送信することと、
を含む方法。
【請求項２２】
所与の地理的領域内の１つまたは複数の建物の各々の建物境界を決定することと、
前記所与の地理的領域の複数の道路のレイアウトを決定することと、
前記複数の道路の１つまたは複数の道路の幅を、前記１つまたは複数の道路の推定中心線から前記建物境界の１つまたは複数の建物境界までの距離に基づいて決定することと、
前記１つまたは複数の道路のそれぞれの道路に接する１つまたは複数の縁石セグメントを、少なくともそれぞれの道路の幅と前記建物境界とに基づいて、決定することと、
前記１つまたは複数の縁石セグメントの位置を記述する縁石セグメントデータを保存することであって、前記縁石セグメントデータは前記複数の建物の位置と複数の道路の前記レイアウトとに関して特定の縁石セグメントを識別する、前記保存することと、
をさらに含む
請求項２１に記載の方法。
【請求項２３】
少なくとも前記縁石セグメントデータに基づいて、前記第１の要求位置の前記閾値距離内にある複数の縁石セグメントを決定することと、
前記複数の縁石セグメントの交点を決定することと、
各交点に対して、交差する各縁石セグメントに沿った１つまたは複数の代替要求位置を決定することであって、前記１つまたは複数の代替要求位置の各々は前記交点からの閾値距離である、前記決定することと、
をさらに含む
請求項２２に記載の方法。
【請求項２４】
前記第１のリクエスタコンピューティングデバイスに、少なくとも前記代替要求位置へのナビゲーションルートを含むマッピングデータを表示させることと、
前記第１のリクエスタコンピューティングデバイスに、それぞれのＥＴＴまたは前記第１のＥＴＤと前記第２のＥＴＤとの差の少なくとも１つを含む、前記代替要求位置に対応する情報を表示させることと、
前記第１のリクエスタコンピューティングデバイスから、前記代替要求位置の選択の指示を受信することと、
をさらに含む
請求項２１に記載の方法。
【請求項２５】
第２のリクエスタコンピューティングデバイスに関連する第２の輸送要求情報を受信することであって、前記第２の輸送要求情報は第２の要求位置を含む、前記受信することと、
前記代替要求位置が前記第２の要求位置の第２の閾値距離内にあると決定することと、
第２のリクエスタが前記代替要求位置に移動する第２のＥＴＴがそれぞれのＥＴＴの閾値時間内であると決定することと、
前記代替要求位置と前記第２のリクエスタコンピューティングデバイスとに関連する修正された第２の輸送要求情報を、前記マッチしたプロバイダに関連する前記プロバイダコンピューティングデバイスに送信することと、
をさらに含む
請求項２１に記載の方法。
【請求項２６】
前記第２の輸送要求情報は第２の目的地位置を含み、
前記第２の輸送要求情報を受信すると、前記第２の目的地位置への前記マッチしたプロバイダの第３のＥＴＤを決定することと、
前記第１の目的地位置の閾値距離内にある複数の代替目的地位置を決定することと、
前記複数の代替目的地位置の少なくとも１つの各々から前記第２の目的地位置への前記マッチしたプロバイダの第４のＥＴＤを決定することと、
前記複数の代替目的地位置の１つからの前記第４のＥＴＤが前記第３のＥＴＤより小さいことを決定することと、
前記代替目的地位置を含む修正された第１の輸送要求情報を、前記マッチしたプロバイダに関連する前記プロバイダコンピューティングデバイスに送信することと、
をさらに含む
請求項２５に記載の方法。
【請求項２７】
前記第１のリクエスタコンピューティングデバイスに、前記代替目的地位置から前記第１の目的地位置までのナビゲーションルートを含むマッピングデータを表示させることと、
前記第１のリクエスタコンピューティングデバイスに、前記第１のリクエスタが前記代替目的地位置から前記第１の目的地位置に移動する第３のＥＴＴを表示させることと、
前記第１のリクエスタコンピューティングデバイスから、前記代替目的地位置の選択の指示を受信することと、
をさらに含む
請求項２６に記載の方法。
【請求項２８】
歩行距離選好データ、歩行履歴データ、年齢、平均歩行速度データ、標高データ、天気データ、現在時刻、または道路安全データ、の少なくとも１つを含む前記第１のリクエスタに関連するデータに基づいて、前記複数の代替要求位置のサブセットを決定することをさらに含み、前記代替要求位置は複数の代替要求位置の前記サブセットから選択される
請求項２１に記載の方法。
【請求項２９】
プロセッサとコンピュータ可読媒体とを有するコンピューティングデバイスであって、  前記コンピュータ可読媒体は、前記プロセッサによって実行可能なコードであって、前記コンピューティングデバイスに、
【請求項３０】
前記コンピューティングデバイスに、
所与の地理的領域内の１つまたは複数の建物の各々の建物境界を決定させ、
前記所与の地理的領域の複数の道路のレイアウトを決定させ、
前記複数の道路の１つまたは複数の道路の幅を、前記１つまたは複数の道路の推定中心線から前記建物境界の１つまたは複数の建物境界までの距離に基づいて決定させ、
前記１つまたは複数の道路のそれぞれの道路に接する１つまたは複数の縁石セグメントを、少なくともそれぞれの道路の幅と前記建物境界とに基づいて、決定させ、
前記１つまたは複数の縁石セグメントの位置を記述する縁石セグメントデータを保存させ、前記縁石セグメントデータは前記複数の建物の位置と複数の道路の前記レイアウトとに関して特定の縁石セグメントを識別する、
ためのコードをさらに含む
請求項２９に記載のコンピューティングデバイス。
【請求項３１】
前記コンピューティングデバイスに、
前記第１のリクエスタコンピューティングデバイスに、少なくとも前記代替要求位置へのナビゲーションルートを含むマッピングデータを表示させ、
前記第１のリクエスタコンピューティングデバイスに、それぞれのＥＴＴまたは前記第１のＥＴＤと前記第２のＥＴＤとの差の少なくとも１つを含む、前記代替要求位置に対応する情報を表示させ、
前記第１のリクエスタコンピューティングデバイスから、前記代替要求位置の選択の指示を受信させる、
ためのコードをさらに含む
請求項２９に記載のコンピューティングデバイス。
【請求項３２】
前記コンピューティングデバイスに、
第２のリクエスタコンピューティングデバイスに関連する第２の輸送要求情報を受信させ、前記第２の輸送要求情報は第２の要求位置を含み、
前記代替要求位置が前記第２の要求位置の第２の閾値距離内にあると決定させ、
第２のリクエスタが前記代替要求位置に移動する第２のＥＴＴがそれぞれのＥＴＴの閾値時間内であると決定させ、
前記代替要求位置と前記第２のリクエスタコンピューティングデバイスとに関連する修正された第２の輸送要求情報を、前記マッチしたプロバイダに関連する前記プロバイダコンピューティングデバイスに送信させる、
ためのコードをさらに含む
請求項２９に記載のコンピューティングデバイス。
【請求項３３】
前記第２の輸送要求情報は第２の目的地位置を含み、
前記コンピューティングデバイスに、
前記第２の輸送要求情報を受信すると、前記第２の目的地位置への前記マッチしたプロバイダの第３のＥＴＤを決定させ、
前記第１の目的地位置の閾値距離内にある複数の代替目的地位置を決定させ、
前記複数の代替目的地位置の少なくとも１つの各々から前記第２の目的地位置への前記マッチしたプロバイダの第４のＥＴＤを決定させ、
前記複数の代替目的地位置の１つからの前記第４のＥＴＤが前記第３のＥＴＤより小さいことを決定させ、
前記代替目的地位置を含む修正された第１の輸送要求情報を、前記マッチしたプロバイダに関連する前記プロバイダコンピューティングデバイスに送信させる、
ためのコードをさらに含む
請求項３２に記載のコンピューティングデバイス。
【請求項３４】
前記コンピューティングデバイスに、
前記第１のリクエスタコンピューティングデバイスに、前記代替目的地位置から前記第１の目的地位置までのナビゲーションルートを含むマッピングデータを表示させ、
前記第１のリクエスタコンピューティングデバイスに、前記第１のリクエスタが前記代替目的地位置から前記第１の目的地位置に移動する第３のＥＴＴを表示させ、
前記第１のリクエスタコンピューティングデバイスから、前記代替目的地位置の選択の指示を受信させる、
ためのコードをさらに含む
請求項３３に記載のコンピューティングデバイス。
【請求項３５】
複数の建物の少なくとも１つの建物の境界エッジを決定し、前記境界エッジは複数の道路の少なくとも１つの道路に隣接し、
前記少なくとも１つの道路の幅を決定し、
前記少なくとも１つの道路と１つまたは複数の隣接する建物との間の縁石セグメントを決定し、
前記縁石セグメントを、特定の地理的領域内の複数の縁石セグメントのレイアウトを記述する縁石セグメントデータに保存する
ように構成された縁石識別システムと、
リクエスタコンピューティングデバイスから、第１の縁石セグメントに関連する第１の要求位置と第２の縁石セグメントに関連する第１の目的地位置とを含む第１の輸送要求を受信し、
前記第１の要求位置から前記第１の目的地位置までの第１の推定至目的地時間（ＥＴＤ）を決定し、
前記縁石セグメントデータに基づいて、前記第１の要求位置に近い複数の代替縁石セグメントのセットを決定し、
複数の代替縁石セグメントの前記セットの各代替縁石セグメントから前記第１の目的地位置への第２のＥＴＤを決定する
ように構成された動的輸送マッチングシステムと、
を含むシステム。
【請求項３６】
前記少なくとも１つの道路の幅を決定することは、さらに、前記縁石識別システムに、
前記少なくとも１つの道路の中心線から前記少なくとも１つの建物の境界エッジまでの距離を決定させる
請求項３５に記載のシステム。
【請求項３７】
前記縁石識別システムは、
前記複数の道路のレイアウトを含む道路データを受信し、前記複数の道路の前記レイアウトは前記複数の道路の各道路の位置、方向、および長さを記述し、
前記複数の建物の位置を含む建物データを受信する
ようにさらに構成される
請求項３５に記載のシステム。
【請求項３８】
前記少なくとも１つの道路と１つまたは複数の隣接する建物との間の縁石セグメントを決定することは、前記少なくとも１つの道路の幅と前記少なくとも１つの建物の境界エッジとに少なくとも基づく
請求項３５に記載のシステム。
【請求項３９】
前記動的輸送マッチングシステムは、
前記第１の要求位置と前記１つまたは複数の代替縁石セグメントのそれぞれとの間のそれぞれの推定移動時間（ＥＴＴ）を決定し、
前記１つまたは複数の代替縁石セグメントの各々について、前記第２のＥＴＤとそれぞれのＥＴＴとを含む合計ＥＴＤを決定し、
前記１つまたは複数の代替縁石セグメントのいずれかの合計ＥＴＤが前記第１のＥＴＤより小さいかどうかを決定する
ようにさらに構成される
請求項３５に記載のシステム。
【請求項４０】
前記動的輸送マッチングシステムは、
第３の縁石セグメントに関連する第２の要求位置と第４の縁石セグメントに関連する第２の目的地位置とを含む第２の輸送要求を受信し、
前記縁石セグメントデータに基づいて、前記第３の縁石セグメントが前記第１の縁石セグメントの閾値距離内にあることを決定し、
前記第２の要求位置が前記第１の縁石セグメントに関連付けられるように、前記第２の輸送要求を修正し、
前記第２の輸送要求に関連するコンピューティングデバイスに、前記第３の縁石セグメントから前記第１の縁石セグメントへのナビゲーション指示を送信する
ようにさらに構成される
請求項３５に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
伝統的に、人々は特定のサービスプロバイダから固定された場所でサービスを要求し受信してきた。例えば、家庭または職場のユーザに配達することによって、様々なサービスが実現された。現在、多くのサービスはモバイルコンピューティングデバイスを介してアクセスすることができ、多くの場合、オンデマンドでアクティブ化されるサービスプロバイダによって、任意の位置で実行することができる。このようなオンデマンドサービスの提供は、サービスを受けるために固定された場所にいる必要がないユーザにとって便利である。さらに、オンデマンドのサービスマッチングシステムは、要求位置の近くのサービスプロバイダの位置およびステータスに基づいて要求を選択し、サービスプロバイダに提供することができる。しかしながら、要求位置に生成される様々なルートは、最適ではない場合がある。長いトリップは、遅延、キャンセルされた要求、および重複した要求につながるので、非効率的なリソース割振りにつながる。
【０００２】
さらに、交通、障害物、および／または道路の構成のために、プロバイダがリクエスタをうまく探し出しリクエスタと出会うことは、いくつかの要求位置ではより困難であり得る。例えば、縁石上に駐車された車があるにぎやかな通りでは、ピックアップ位置のための安全な位置を見つけることが困難であり得る。したがって、リクエスタはプロバイダが駐車するのに安全である場所を見つけるために、ブロックの周りを歩かされることを余儀なくされ得る。これはピックアップのやり取りを遅延させ、プロバイダとリクエスタとの間の不必要な通信を必要とし、および／または妥当な位置が見つからない要求のキャンセルにつながる可能性がある。したがって、正確な移動時間推定値および到着時間推定値を決定することは困難であり、いくつかの要求位置では、サービスポイントでの不必要な遅延が生じることがある。これは、プロバイダとリクエスタとの間の不正確なマッチング、および、リクエスタを見つけようとする間にプロバイダによるダウンタイムが増加するので、システムリソースの非効率的な使用につながる。したがって、全体的な移動時間の決定、システムおよびプロセッサリソースの効率的な使用、ならびにプロバイダとリクエスタとの間の全体的な改善された経験のために、やり取りの識別を改善し、プロバイダとリクエスタとの間のやり取りを改善する必要がある。
【図面の簡単な説明】
【０００３】
本開示による様々な実施形態を、図面を参照して説明する。
【０００４】
【図１】本技法の一実施形態による、マッチしたプロバイダおよびリクエスタを含むライドマッチングシステムの一例を示す図である。
【図２Ａ】本技法の一実施形態による、ピックアップ位置までのピックアップ経路が決定されるライドマッチングシステム環境の一例を示す図である。
【図２Ｂ】本技法の一実施形態による、ピックアップ位置までのピックアップ経路が決定されるライドマッチングシステム環境の一例を示す図である。
【図２Ｃ】本技法の一実施形態による、ピックアップ位置までのピックアップ経路が決定されるライドマッチングシステム環境の一例を示す図である。
【図３】本技法の一実施形態による、縁石セグメントに対応する複数の代替ピックアップ位置が決定されるライドマッチングシステム環境の一例を示す図である。
【図４Ａ】本技法の一実施形態による、ピックアップ位置の最適化に関連するデータを表示するための例示的なインターフェース手法を示す図である。
【図４Ｂ】本技法の一実施形態による、ピックアップ位置の最適化に関連するデータを表示するための例示的なインターフェース手法を示す図である。
【図５Ａ】本技法の一実施形態による、縁石セグメンテーション技法のための例示的な手法を示す図である。
【図５Ｂ】本技法の一実施形態による、縁石セグメンテーション技法のための例示的な手法を示す図である。
【図５Ｃ】本技法の一実施形態による、縁石セグメンテーション技法のための例示的な手法を示す図である。
【図５Ｄ】本技法の一実施形態による、縁石セグメンテーション技法のための例示的な手法を示す図である。
【図６】本技法の一実施形態による、ライドマッチングシステムの例示的なブロック図である。
【図７】本技法の実施形態による、最適化されたピックアップ位置を提供するために縁石セグメントデータを使用するための方法の例示的な流れ図である。
【図８】本技法の実施形態による、要求位置および代替要求位置のピックアップ位置スコアを使用して、要求の修正されたピックアップ位置を決定するための方法の例示的な流れ図である。
【図９】本技法の実施形態による、最適化されたピックアップ位置を提供するために代替要求位置を識別するフィルタとして位置スコアを使用するための方法の例示的な流れ図である。
【図１０】本技法の実施形態による、最適化されたピックアップ位置を提供するために位置スコアに関連する遅延時間を使用するための方法の例示的な流れ図である。
【図１１】様々な実施形態による、例示的なリクエスタ／プロバイダ管理環境を示す図である。
【図１２】様々な実施形態による、例示的なデータ収集およびアプリケーション管理システムを示す図である。
【図１３Ａ】各種実施形態による例示的なプロバイダ通信デバイスを示す図である。
【図１３Ｂ】各種実施形態による例示的なプロバイダ通信デバイスを示す図である。
【図１３Ｃ】各種実施形態による例示的なプロバイダ通信デバイスを示す図である。
【図１４】各種実施形態による例示的なコンピュータシステムを示す図である。
【発明を実施するための形態】
【０００５】
以下の説明では、様々な実施形態について説明する。説明の目的のために、特定の構成および詳細が、実施形態の完全な理解を提供するために記載される。しかしながら、当業者には、実施形態が特定の詳細なしに実施されてもよいことも明らかであろう。さらに、周知の特徴は、記載されている実施形態を不明瞭にしないために省略または簡略化され得る。
【０００６】
モバイルデバイスを介してアクセスされるオンデマンドサービスは、より普及しつつある。しかしながら、オンデマンドマッチングシステムによってマッチングされるプロバイダおよびリクエスタの分散型および携帯型の性質のために、静止したピックアップポイントに基づいてプロバイダおよびリクエスタを効率的にマッチングすることは困難であり得る。例えば、リクエスタはピックアップ要求を開始するときに、特定のストリートに関連付けられた縁石セグメントの中央に存在し得る。ピックアップ要求に応答して、プロバイダは、要求にマッチングされ、応答する。本明細書で論じるプロバイダは、車両内の人間の運転手（車両を完全にまたは部分的に制御する）、ならびに人間および／または自動システムによって派遣される車両を含み得る。「プロバイダ」は例えば、輸送要求に応答するために自律車両を派遣する自動動的輸送マッチングシステム、自律車両または他の方法でコンピュータ制御された車両（全体または一部）、または人間の運転者を含むことができる。プロバイダは要求位置へのルートをナビゲートする際に、リクエスタへの直接ルートではなく複雑なルートを移動しなければならない場合があり、例えば、プロバイダとリクエスタとの間の道路のレイアウトには、要求位置へのアクセスを提供する通りに到達するためにプロバイダにブロックを迂回させる一方通行の道路が存在する場合がある。この点に関して、非効率的な要求位置は、ピックアップ位置へのルートを効率的でなくすることによって、道程に時間を追加する。別の例として、リクエスタは道路のレイアウトにおいて特定の道路に沿って直接到達することができる目的地を指定することができるが、要求位置は特定の道路に戻ってナビゲートする前にリクエスタをピックアップするために、プロバイダが特定の道路をオフにすることを要求する縁石セグメントに沿っている。この点に関して、非効率的な要求位置は、目的地までのルートを効率的でなくすることによって、道程に時間を追加する。本技術は動的輸送マッチングシステムのコンピュータ関連技術を改善し、他の問題の中でも、非効率的なピックアップ位置に関連する輸送要求の技術的問題を解決する。
【０００７】
リクエスタおよびプロバイダの両方に送信されるピックアップ位置の精度を改善することによって、動的輸送マッチングシステムは要求とピックアップとの間の時間を低減することを含む方法で改善され、これにより、システムは、より少ない処理リソースを使用することが可能になる。例えば、プロバイダがリクエスタを「ピックアップ」するまでには至っていないが、動的輸送マッチングシステムは更新された推定到着時間（ＥＴＡ）演算、リクエスタを受け取らないか否かの決定（例えば「救済」）、全体的なシステムＥＴＡ決定、及び他の活動の中で、更新された推定到着時間（ＥＴＡ）演算を引き続き実行する。これらの自動化されたプロセスは処理時間、メモリ、帯域幅、および他のシステム資源を使用するために動的輸送マッチングシステムを必要とし、これは、プロバイダがより速くリクエスタを拾い上げることができるほど、より効率的に利用することができる。さらに、プロバイダがそれほど早く到着しない場合、リクエスタは要求をキャンセルする可能性が高く、これはリクエスタが元のプロバイダによって満たされない可能性がある新しい要求を送信することにつながり、したがって、単一のリクエスタにサービスを提供するためにプロバイダの数の２倍（またはそれ以上）を必要とし、システム全体にわたって遅延を引き起こし、これは膨大な数のユーザからの追加のキャンセルおよび再リクエスト（「カスケードリクエスト」または「ボタンマッシング」）につながる可能性があり、その各々は動的輸送マッチングシステムによるより大きなリソース使用および非効率的なリソース割振りを引き起こし、深刻な場合には動的輸送マッチングシステムをクラッシュさせる可能性がある。
【０００８】
両方の例において、要求位置が、リクエスタへのより効率的なルートおよび／または要求位置から目的地へのより効率的なルートを可能にする異なる縁石セグメントに沿って代替要求位置に移動された場合に必要とされるよりも長い道程が行われる。以前のアプローチによって生成された潜在的に非効率的なルートは要求位置がより効率的である場合、リクエスタに必要以上に長い移動時間が通知されることになり、これは、多くの場合、プロバイダがすでに輸送要求にマッチした後に、ライド要求のキャンセルにつながる可能性がある。単に輸送要求をキャンセルすることに加えて、リクエスタは初期要求をキャンセルした直後に新しい要求を作成することができ、その結果、同様に長いピックアップおよび／または移動時間が生じ、その後、キャンセルおよび新しい要求などにつながることがある。これらのカスケード要求およびキャンセルは、複数のプロバイダが他の要求の代わりに、すぐにキャンセルされる輸送要求を受け入れるので、プロバイダのダウンタイムにつながる可能性がある。また、キャンセルされたプロバイダはキャンセルに不満を抱き、特定の領域内で完全に輸送を提供することを停止し、潜在的に実際の高需要時に、その領域内のプロバイダサービスに不足をもたらす可能性がある。
【０００９】
したがって、非効率的な要求位置は、カスケード要求およびキャンセルが輸送マッチングシステムに送信されるので、プロバイダリソースの管理ミス、ならびにデータ処理およびシステム通信の増加につながる。したがって、本明細書で説明される技法は、交通整合システム、ならびに交通整合システムインフラストラクチャの一部として利用されるコンピューティングシステムの運用および効率を改善する。
【００１０】
少なくとも１つの実施形態は、要求位置の周囲の特定の地理的領域内など、縁石セグメントの決定に基づいて要求位置の代替要求位置を決定するための、システムおよび方法を含む技法を提供する。一実施形態では、要求位置への推定到着時間（ＥＴＡ）が例えば、地理的領域内の道路レイアウトの道路と、その道路に隣接する１つまたは複数の建物境界エッジとの間の特定の縁石セグメントにおいて決定される。一実施形態では、例えば要求位置に関連付けられた特定の地理的領域内の縁石セグメントのレイアウトを記述する縁石セグメントデータを決定し、格納し、代替要求位置のうちの１つまたは複数を決定するために利用することができる。一実施形態では、代替要求位置のそれぞれは要求位置の地理的領域内の縁石セグメントのうちの１つに関連付けられる。一実施形態では、リクエスタが元の要求位置の閾値距離内（例えば、特定の地理的領域内）の１つまたは複数の代替要求位置に移動するのにかかる推定時間を示す推定移動時間（ＥＴＴ）が決定され、代替要求位置へのＥＴＴを考慮に入れて、代替要求位置の１つへのＥＴＡが元の要求位置へのＥＴＡよりも小さいかどうかの決定が行われる。
【００１１】
一実施形態では、輸送要求にマッチするプロバイダの推定至目的地時間（ＥＴＤ）が決定される。ＥＴＤは本明細書で説明されるように、要求位置へのＥＴＡを含むことができ、または要求位置と要求の目的地との間で決定されることができ、またはそれらの組合せであることができる。リクエスタが多数の代替要求位置の各々に移動するためのＥＴＴが決定される；例えば、特定のリクエスタが新しい位置に歩くのにどのくらいの時間がかかるか（例えば、平均歩行速度、標高、横切る交点（交差点）の数、道路データなどの様々な要因を考慮に入れて）。ＥＴＴを考慮に入れて、代替要求位置の各々から目的地までの新しいＥＴＤが決定され、代替目的地位置の１つへの移動が道程上の時間を節約するかどうかの決定が行われ、例えば、新しい要求位置（例えば、ＥＴＴ）まで歩くのにかかる時間は、元の要求位置と比較して、新しい要求位置に基づく目的地までの時間の減少によって補償される。
【００１２】
さらに、いくつかの実施形態は、要求位置および／または代替要求位置のピックアップ位置スコア（ＰＬｏＳ）に基づいて代替要求位置を決定するための、システムおよび方法を含む技法を提供する。ピックアップ位置スコアは、リクエスタとプロバイダとの間のやり取りのための位置の適合度の任意の客観的な定量的測定値を含むことができる。例えば、ピックアップ位置スコアは、道路、ブロック、サブブロック、および／または対応する位置におけるプロバイダによるリクエスタのピックアップの適合性のための位置に対応するマップの任意の他の適切なセグメントを特徴付けることができる。したがって、ピックアップ位置スコアはリクエスタとプロバイダとの間のやり取りのために、領域、道路、ブロック、サブブロックなど内の特に良好な位置を識別するために使用され得る。例えば、ピックアップのためにその場所に有益であるかまたは悪影響を及ぼす可能性がある消火栓または停止禁止区域が存在する可能性がある。したがって、いくつかの実施形態は、ピックアップ位置スコアを使用して、要求位置よりもピックアップのためのより良い位置であり得る近くの位置を識別することができる。
【００１３】
ピックアップ位置スコアは、動的輸送マッチングシステムによって捕捉された異なるタイプの情報を使用して、様々な異なる方法によって決定することができる。例えば、ピックアップ位置スコアは特定の要求位置におけるマッチしたライドについてのプロバイダとリクエスタとの間の接触率（例えば、ピックアップの前に相手方当事者に接触する要求位置に関連するライドのパーセンテージ）、特定の要求位置について開始されるマッチしたライドについてのプロバイダに対するリクエスタの平均移動距離（例えば、要求位置とリクエスタがピックアップされた実際の位置との間の差）、キャンセル（プロバイダまたはリクエスタのいずれかからの）、および／または、要求位置におけるプロバイダによる到着時刻と、マッチしたライドの開始についてのプロバイダへのリクエスタの到着時刻との間で測定される遅延時間（例えば、リクエスタおよびドライバーが互いに見つけるのにどれくらいの時間がかかったか）に基づいてもよい。さらに、要求位置に関連付けられたマッチしたライドのキャンセル率、およびピックアップのための不良位置に関連付けられ得るプロバイダとリクエスタとの間の遅延に関連付けられた任意の他の情報は、位置のためのピックアップ位置スコアを決定する際に使用され得る。実施形態は動的輸送マッチングシステムを介してリクエスタとプロバイダとの間の各要求についての統計を追跡することができ、格納されたライド履歴情報を使用して、任意の要求位置に適用することができるピックアップ位置スコア（ＰＬｏＳ）モデルを構築することができる。ピックアップ位置スコアはある時間（例えば、朝の通勤）中の特定の位置のピックアップ位置スコアが別の時間（例えば、午後）中のピックアップ位置スコアとは異なるように、時間依存であってもよい。したがって、ライド履歴は時間（例えば、朝、通勤、午後、夜など）、日（例えば、平日、週末、休日など）、季節（例えば、夏、冬など）、天候（例えば、曇、雨、雪など）、道路条件（例えば、乾燥、滑り、氷など）、および／または場所の交通流および／または場所のピックアップ条件に影響を及ぼし得る任意の他の変数を含む変数に従って、場所のための異なるピックアップ場所スコアを記憶し、使用することができる。
【００１４】
さらに、いくつかの実施形態では、ピックアップ位置スコア閾値を使用して、動的輸送マッチングシステムを介して受信された要求に対して代替位置を決定すべきかどうかを示すことができる。例えば、要求位置が特に悪い（例えば、ピックアップ位置スコア閾値未満）ことを示すピックアップ位置スコアを有する要求位置は要求位置の特定の距離（例えば、リクエスタにとって妥当な歩行距離）内のより良い位置とマッチングされてもよい。さらに、および／または代替として、いくつかの実施形態はピックアップ位置の任意の最適化が十分な品質の位置に対してのみ実行されることを保証するために、ピックアップ位置スコアをフィルタとして使用してもよい。例えば、代替要求位置のピックアップ位置スコアは最適化されている位置が少なくとも特定の量的品質であり、低品質ピックアップ位置による最適化からの時間節約の損失をもたらさないことを保証するために、任意のピックアップ最適化プロセスで使用される前に、閾値ピックアップ位置スコアと比較されてもよい。
【００１５】
さらに、いくつかの実施形態では、位置スコアが要求の推定移動時間および／または推定到着時間に適用することができる遅延時間に変換することができる。例えば、要求位置に到着するプロバイダとマッチしたライド開始との間の遅延時間の平均量はリクエスタおよびプロバイダがそれらの到着時間および移動時間をより正確に予測することができるように、要求のための目的地位置への推定到着時間に組み込まれてもよい。さらに、到着通知は要求位置に起因する遅延を組み込むことができ、要求位置に関連する遅延を制限するために、プロバイダが要求位置に到着する前に、到着通知を送信することができる。いくつかの実施形態では、代替要求位置決定プロセスがピックアップ位置の品質に起因する遅延を組み込むことを確実にするために、ピックアップ位置スコアからの変換された遅延時間をピックアップ経路最適化プロセスに組み込むことができる。例えば、実施形態は代替位置がピックアップ位置スコアに基づいて２０秒の移動時間を節約することができるが、ピックアップルートに基づいて以前の要求位置と比較して１０秒を失うことができると決定することによって、要求の代替要求位置を決定することができる。
【００１６】
したがって、実施形態は以前のライド履歴データに基づいてピックアップ位置の測定された品質スコアを決定し、追跡し、使用して、ピックアップおよび移動時間をより良好に推定し、プロバイダおよびリクエスタに、要求されたピックアップ位置から所定の距離内のより効率的なピックアップ位置を指示することができる。
【００１７】
さらに、１つまたは複数の実施形態は、道路および建物データに基づいて縁石識別システムによって格納され得るような縁石セグメントデータを使用し得る。例えば、特定の地理的領域における道路のレイアウトの位置、方向、長さ等のような情報を含む道路データを受信することができる。特定の地理的領域内の様々な建物の位置および形状などの情報を含む建物データを受信することができ、そこから、建物の境界（そのうちの少なくともいくつかは道路に隣接している）を決定することができる。一実施形態では、建物および道路データ（例えば、特定の地理的領域内の道路のレイアウトを記述する道路データであって、道路のレイアウト内の１つまたは複数の道路の位置、中心線、方向、および長さを含むレイアウト）に基づいて、道路の推定中心線から隣接する建物の境界エッジまでの距離などに基づいて、道路の幅を決定することができる。道路幅および建物境界に基づいて、縁石セグメントを決定することができる。例えば、少なくとも１つの道路と１つ以上の隣接する建物との間の縁石セグメントは、少なくとも１つの道路の幅と、１つ以上の隣接する建物の境界エッジとに基づいて決定されてもよい。次に、例えば、多角形によって表される道路間の交点を見つけ、多角形の点（例えば、道路が交差する場所）を突き止め、交点間の線を引いて多角形のエッジを形成することによって、縁石を決定することができる。特定の地理的領域における縁石セグメントのレイアウトを記述する縁石セグメントデータは例えば、緯度及び経度を記述する地理空間点等を使用して記憶されてもよい。
【００１８】
さらに、いくつかの実施形態では、縁石セグメントデータがローカル特徴およびランドマーク（例えば、消火栓、駐車ゾーンなし、積載ゾーンなど）を組み込み、ローカル特徴を使用して、ローカルストリート特徴を組み込むサブセグメントを作成することができる。例えば、消火栓を含む縁石セグメントは、消火栓の前、消火栓、および消火栓の後の領域を捕捉するサブセグメントに分離されてもよい。サブセグメントの各々は、消火栓を囲む位置が縁石の囲むサブセグメントよりも客観的に良好なピックアップ位置であることを示す異なるピックアップ位置スコアを有することができる。
【００１９】
したがって、消火栓セクションは、縁石セグメントの３つのサブセグメントに関連するピックアップ位置スコアに基づいて、より容易に識別することができる。したがって、実施形態は目的地への輸送要求を決定することができる、より効率的な要求位置の決定を提供し、これは、不必要にキャンセルされたライド要求および新しいライド要求の発行のためのシステムリソースの使用を制限することができ、ならびにプロバイダの失われたダウンタイムおよび増加したスループットを制限することができる。
【００２０】
図１は、本技法の一実施形態による、マッチしたプロバイダ１４０Ａおよびリクエスタ１１０Ａを含むライドマッチングシステム１３０の一例を示す。ライドマッチングシステム１３０は、リクエスタコンピューティングデバイス１２０およびプロバイダコンピューティングデバイス１５０の両方と通信するように構成され得る。プロバイダコンピューティングデバイス１５０は、プロバイダ１４０および／またはリクエスタ１１０に情報を容易かつ効率的に表示するように構成されたプロバイダ通信デバイス１６０と通信するように構成され得る。リクエスタ１１０は、リクエスタコンピューティングデバイス１２０上のライドマッチングリクエスタアプリケーションを使用して、指定されたピックアップ位置でのライドを要求することができる。要求は、通信ネットワーク１７０を介してライドマッチングシステム１３０に送信されてもよい。ライド要求は例えば、要求位置、リクエスタおよび／またはリクエスタコンピューティングデバイスに関連する識別子、リクエスタコンピューティングデバイスに関連するユーザ情報、リクエスタコンピューティングデバイスの位置、要求時間（例えば、スケジュールされたライドは、要求が満たされるための将来の時間、またはできるだけ早く輸送するための「瞬間／現在」時間を有することができる）、および／または本明細書で説明されるような輸送プロバイダと輸送要求をマッチングさせるための任意の他の関連情報を含むことができる輸送要求情報を含むことができる。要求位置は例えば、現在の位置、将来の位置、「最良適合／予測」位置、縁石セグメント、または現在の時間または将来に見つけられるリクエスタのための位置を示すための任意の他の適切な情報を含むことができる。いくつかの実施形態では、輸送要求が例えば、リクエスタ輸送選好（例えば、ハイウェイ対サイドストリート、温度、音楽選好（第３者音楽プロバイダプロファイルへのリンクなど）、プロバイダ通信デバイス上に表示するための個人化されたパターン／色など）、およびリクエスタ輸送制限（例えば、ペットフレンドリー、チャイルドシート、車椅子アクセス可能など）を含む他の要求関連情報をさらに含むことができる。
【００２１】
リクエスタコンピューティングデバイスはプロバイダ１４０Ａによって提供されサービス（例えば、ライドまたは輸送、配達など）を要求するために使用される。プロバイダコンピューティングデバイスは利用可能なプロバイダに連絡し、要求を利用可能なプロバイダとマッチさせるために使用されてもよい。しかしながら、要求に関連付けられた位置は、要求位置へのプロバイダ移動時間および／または要求位置から目的位置へのプロバイダ移動時間に関して、最も効率的な位置ではない場合がある。例えば、プロバイダは要求位置への長い遠回りのルートをとらなければならない場合があり、一方、リクエスタが隣接ブロック上の新しい縁石セグメントまで歩く場合、プロバイダは要求位置へのより短いルートを有することになり、および／またはプロバイダは目的地へのより効率的なルートを有することができる（例えば、ブロックの周りをループする必要がないなど）。したがって、実施形態は、ライドマッチングシステムが要求位置の閾値距離内の別の縁石セグメントが道程の１つまたは複数のレッグに関連する移動時間（たとえば、要求位置への道程、要求位置からの道程、複数の要求位置および／または目的地位置を伴う道程など）を低減するかどうかを判定して、最も効率的なマッチングを保証し、ライドマッチングシステムによるプロバイダダウンタイムの最小量および最も可能なスループットをもたらすことを可能にする解決策を提供する。
【００２２】
ライドマッチングシステム（「動的輸送マッチングシステム」とも呼ばれる）１３０は、プロバイダ通信デバイス１５０Ａ上のアプリケーションを介してライドマッチングシステム１３０に登録されている利用可能なプロバイダを識別することができる。ライドマッチングシステム１３０はライド要求をプロバイダ通信装置１５０Ａに送信することができ、プロバイダ１４０Ａは、プロバイダ通信デバイス１５０Ａを介してライド要求を受け入れることができる。さらに、および／または代替として、いくつかの実施形態では、プロバイダがプロバイダが要求を明示的に受け入れることができないように、要求と予測的におよび／または自動的にマッチさせることができる。例えば、プロバイダは、プロバイダが受け入れる前に要求を拒否および／またはレビューする能力なしに、プロバイダに送信されるすべての要求を受け入れることに同意するモードに入ることができる。いずれの場合も、プロバイダコンピューティングデバイスは、プロバイダが輸送要求を受信したことを示すマッチを示す情報を返すことができる。例えば、マッチを示す情報はプロバイダが受信したことを示し、インジケータを受け入れるプロバイダ受け入れインジケータ（例えば、フラグ）を含むことができ、または様々な異なる情報を含むことができる。例えば、マッチを示す情報は位置情報、車両内の他の乗客のための他のルート情報、将来の利用可能性に関する情報（例えば、いつオフラインになるか）を提供するプロバイダのためのスケジュール、自動車に関連する診断（例えば、ガスレベル、バッテリレベル、エンジン状態など）、および／または任意の他の適切な情報を含むことができる。プロバイダ１４０Ａおよびリクエスタ１１０Ａはマッチされてもよく、両者はリクエスタ情報（例えば、名前、代表記号またはグラフィック、ソーシャルメディアプロファイルなど）、プロバイダ情報（例えば、名前、代表記号またはグラフィックなど）、リクエスト位置、目的地位置、それぞれのコンピューティングデバイス位置、レーティング、過去のライド履歴、上記で識別された他の輸送要求情報および／またはプロバイダ受け入れ情報のいずれか、および／または提供されているマッチおよび／またはサービスを容易にするための任意の他の関連情報を含む、他のそれぞれのパーティに関連するマッチ情報を受信してもよい。したがって、ライドマッチングシステム１３０は、地理的領域全体に分散されたリクエスタおよびプロバイダを動的にマッチングすることができる。
【００２３】
図２Ａ〜２Ｂは、本技法の一実施形態による、位置をピックアップするためのピックアップ経路が決定されるライドマッチングシステム環境の一例を示す。図２Ａの例２００では、多数の建物２１４があり、それらの間に道路２１６が走っている。人は建物のうちの１つの外側の位置２０２でライド（例えば、輸送）を要求し、目的地２０４が要求に示されている。プロバイダ２０６は要求にマッチングされており、リクエスタの位置２０２へのナビゲーションルート２０８（例えば、ライドマッチングシステムによって提供され、オンラインナビゲーションシステムに位置を送信することによって自己決定されるなど）が提示される。この例ではプロバイダがリクエスタをピックアップするためにブロックの周りを移動しなければならない（例えば、プロバイダはＵターンを行うことができない）。プロバイダ２０６が位置２１０でリクエスタをピックアップすると、プロバイダ２０６は目的地２０４への自分のルート２１２上のブロックの周りを継続しなければならず、例えば、リクエスト位置２０２が位置するストリートは、一方通行道路であってもよく、または交通がＵターンを危険にするなどである。
【００２４】
図２Ｂの例では、代替要求位置２２６が、要求がプロバイダ２０６にマッチされると、それに沿ってリクエスタが代替要求位置２２６に到達するために歩くことができるルート２２４と共に、リクエスタに提供されている。図２Ｂに示すように、代替要求位置２２６に移動することによって、プロバイダが代替要求位置に移動するナビゲーションルート２２２はリクエスタが異なる縁石セグメントに移動したので、より短くなる（すなわち、元の要求位置２０２へのブロックの余分なターンアラウンドは必要とされない）。同様に、プロバイダ２０６が代替リクエスト位置２２６でリクエスタをピックアップした後、目的地までのナビゲーションルート２２８はより短くなる（すなわち、プロバイダ２０６はブロックを回る必要がない）。
【００２５】
図２Ｃは、本技法の一実施形態による、異なるピックアップ位置に関連するピックアップ位置スコア２３８〜２４２が決定され、要求のための代替ピックアップ位置２２６を決定する際に使用されるライドマッチングシステム環境２３０の一例を示す。図２Ａ〜図２Ｂと同様に、図２Ｃの例２３０では、間を走る道路２１６を有する多数の建物２１４があり、人は建物のうちの１つの外側の位置２０２でライド（例えば、輸送）を要求し、同様の目的地（図示せず）が要求に示されている。この例では、様々な縁石セグメントに関連するピックアップ位置スコアが異なるパターン片２３８〜２４２で示されている。例えば、不良ピックアップ位置スコア２３８Ａ〜２３８Ｋを有する位置に関連する縁石セグメントは第１のパターン（例えば、ストライプパターン）で示される。不良なピックアップ位置を有する位置または縁石セグメントはピックアップ位置スコアし閾値を満たさない可能性があり、したがって、代替要求位置として使用するための互換性のない位置または望ましくない位置である可能性がある。ピックアップ位置スコア閾値は、以前のピックアップ位置の履歴データ、ピックアップまでの時間、ピックアップからライド開始までの時間、または位置へのナビゲーションの容易さ、プロバイダがリクエスタをピックアップするための位置の合法性および安全性、少ないキャンセル履歴、成功したピックアップの履歴数などの他の要因に基づいて決定され得る。したがって、ピックアップ位置スコア閾値を満たすスコアを有する位置は位置がピックアップに適しており、成功する可能性が高いことを示すことができる。不十分なピックアップ位置スコアは、位置に関連するマッチした要求の大きな遅延および／または高いパーセンテージがプロバイダとリクエスタとの間の連絡またはキャンセルをもたらすことを示し得る。
【００２６】
中程度のピックアップ位置スコア２４０Ａ〜２４０Ｆを有する位置に関連する縁石セグメントは第２のパターン（例えば、点線パターン）で示される。適度なピックアップ位置スコアを有する位置または縁石セグメントはピックアップ位置スコア閾値を満たすことができるが、プロバイダとリクエスタとの間のやり取りのための優れた位置ではないことがある。適度なピックアップ位置スコアはプロバイダとリクエスタとの間のいくらかの遅延および／または連絡がおそらくマッチした要求に対するものであるが、遅延が最小または合理的であることを示すことができる。
【００２７】
良好なピックアップ位置スコア２４２Ａを有する位置に関連する縁石セグメントは第３のパターン（例えば、ベタパターン）で示される。良好なピックアップ位置スコア２４２Ａを有する位置または縁石セグメントは、ピックアップ位置スコア閾値を満たすだけでなく、やり取りの位置に起因する遅延、当事者間の連絡、またはキャンセルの最小または無視できる確率を有する可能性がある。本明細書で説明されるように、ピックアップ位置スコアは何千もの以前のライドに関連付けられた履歴ライド情報を使用して決定されてもよく、データが現在の要求に関連することを保証するために、時間、日付、曜日、および／または任意の他の関連する変数に関連付けられてもよい。例えば、不良なピックアップ位置を有する位置および／または縁石セグメントはその時間、曜日などにマッチしたライドの履歴を有することがあり、その結果、プロバイダとリクエスタとの間の連絡が生じ、要求位置とマッチしたライドの最終ピックアップ位置との間の距離が長くなり、および／またはプロバイダが位置に到着し、リクエスタがプロバイダに会うまでの遅延が長くなる。これらは、ピックアップ位置に関連する不良ピックアップ経験のいくつかの指標のほんの数例であり、キャンセル、不良リクエスタ格付け、不良プロバイダ格付けなどを含む不良ピックアップ位置を識別するために、追加の基準を使用することができる。
【００２８】
様々な領域間のピックアップ位置スコアの差は、道路２１４および建物２１６の道路状態、構成、および／または特徴に起因し得る。例えば、縁石セグメント２３８Ａおよび２３８Ｊは、停車するのに適したスペースを見つけること、およびプロバイダとリクエスタとの間のやり取りを可能にすることを困難にする、それらの道路上の駐車を伴うにぎやかな一方通行道路上にあってもよい。さらに、これらの領域は、建設のために閉鎖されてもよく、歩行者がアクセスできなくてもよく、および／またはプロバイダがアクセスできなくてもよい。これらの位置２３８Ａ〜２３８Ｋに関連する位置スコアが不良であるために、任意の数の異なる理由が存在し得、これらは、位置スコアが不良になり得る障害物のタイプの２つの例にすぎない。しかしながら、履歴ライドデータに基づくピックアップ位置スコアを使用することによって、動的輸送マッチングシステムは、これらの位置が要求のための修正された要求位置として選択するのに適した位置ではないことを識別することができる。例えば、履歴ライドデータはプロバイダまたはリクエスタのいずれかによって行われた、その位置における以前のキャンセルを含むことができ、これは、位置スコアに影響を及ぼす可能性があり、位置がアクセス不能、位置を見つけることの困難性などのために、キャンセルされやすい可能性があることを示す。さらに、これらの位置のうちの１つに関連付けられた要求が受信された場合、動的輸送マッチングシステムは、代替の要求位置が要求にとって有益であり得ることを識別し得る。
【００２９】
図２Ｃから分かるように、縁石セグメント２４０Ａ〜２０４Ｆおよび２４２Ａに関連する位置は、要求のためのより良い位置である。したがって、システムは要求位置を取り囲む代替要求位置を決定することができ、それらの縁石セグメントおよび／または特定の代替要求位置に関連するピックアップ位置スコアを決定することができる。周囲の縁石セグメントに関連付けられたピックアップ位置スコアを識別し、ランク付けして、要求に対する最良の可能な代替要求位置を決定することができる。いくつかの実施形態では、可能な最高のピックアップ位置を要求について決定し、要求の代替要求位置として使用することができる。さらに、および／または代替として、いくつかの実施形態ではピックアップ位置スコアがピックアップ位置スコア閾値と比較されてもよく、それらがその閾値を満たす限り、位置は要求の代替ピックアップ位置として十分に適合されてもよい。したがって、ピックアップ位置スコア閾値は移動時間または目的地への到着時間についてピックアップ位置を最適化する際に使用され得る潜在的な代替要求位置をフィルタリングするために使用され得るが、ピックアップ位置スコア値は最良の可能な位置を識別するために互いに比較され得ない。代わりに、プロバイダの位置およびナビゲーションルートは、要求のための修正された要求位置として選択される代替ピックアップ位置に影響を及ぼすことができる。さらに、いくつかの実施形態では、ピックアップ位置スコアが時間遅延メトリックに変換されてもよく、時間遅延メトリックはプロバイダからさらに離れている、および／または別の位置よりもリクエスタによるさらなる移動を必要とする、より少ない遅延でピックアップ位置からの潜在的なゲインを重み付けしてもよい、ピックアップ位置最適化プロセスに因数分解されてもよい。いずれにしても、ピックアップ位置スコアを使用した縁石セグメントの特徴付けを使用して、地理的領域内の代替の要求位置および要求に対する修正された要求位置を識別することができる。
【００３０】
図２Ｃに示されるように、いくつかの縁石セグメントは、地図に局所的特徴および／または目印を組み込むためにさらにセグメント化されてもよい。例えば、縁石セグメント２４０Ａ〜２４０Ｂおよび２４２Ａは、従来の縁石セグメントのサブセグメントである。しかしながら、サブセグメント２４０Ａ〜２４０Ｂは、第３のサブセグメント２４２Ａによって分割される。第３のサブセグメント２４２Ａは、サブセグメント２４０Ａ〜２４０Ｂよりも良好なピックアップ位置スコアを有する。サブセグメント２４２Ａは、縁石がマッチングされるべき要求のための特に良好な位置となる特定の品質を有することを示す。これはおそらく、乗り場、一時的な駐車領域、および／またはライドをマッチングさせるために位置が特に良好であることを可能にする、縁石の他の局所的な特徴に起因する。以下でさらに詳細に説明されるように、サブセグメント２４２Ａは、位置がピックアップのための肯定的な位置であり得ることを示すインフラおよび／またはローカル特徴データに基づいて、より大きなサブセグメントから識別され、セグメント化され得る。例えば、以下でさらに詳細に説明するように、縁石推定モジュールは、位置が乗り場、消火栓、および／または縁石セグメントがそれ自体のサブセグメントであるべきであることを意味する他のインフラストラクチャを有することができることを示す縁石セグメントに関連するインフラストラクチャ情報を受信することができる。しかしながら、局所的特徴および／または対応するサブセグメントの識別は、サブセグメントが良好なピックアップ位置スコアを有し得るかどうかに影響を及ぼさない。
【００３１】
例えば、サブセグメント２８３Ｊ〜２３８Ｌは、局所的特徴またはランドマークがその位置に存在することを示す、均一な縁石セグメント内の複数のサブセグメントを含む。しかしながら、低いピックアップ位置スコアを有する縁石サブセグメントは局所的特徴が存在するが、道路特徴及び／又は道路構成が有益なピックアップ結果をもたらさないことを意味する。したがって、いくつかの実施形態では縁石サブセグメントが潜在的により良好なピックアップ位置スコアを示すことができるが、履歴ライドデータは縁石サブセクション内の位置の最終ピックアップ位置スコアを決定するために使用される。したがって、特定の履歴ライド情報およびピックアップ位置スコアを識別するために使用される基準の使用は良好な要求位置を識別するためにローカル特徴を単に使用するシステムが識別しないという反直観的な利点を提供するが、その理由はそれらの位置の多くが、それらの位置（たとえば、グリッドロック、道路構造、歩行者にとってアクセス不可能な領域など）での不十分な相互作用を依然としてもたらす特定の固有の道路特徴および構成を有するからである。したがって、過去のライド情報の定量的分析および動的ピックアップ位置スコアリングモデルは、地図ベースの分析システムに勝る利点を提供する。
【００３２】
図２Ｃに示すように、動的輸送マッチングシステムは縁石セグメント２３８Ａ〜２３８Ｍ、２４０Ａ〜２４０Ｆ、および２４２Ａのうちの１つまたは複数に関連する代替要求位置のセットを識別することができ、縁石サブセグメント２４２Ａに関連する位置が要求の最良の代替要求位置であることを識別することができる。したがって、動的輸送マッチングシステムは要求位置２０２を変更された要求位置２２６に変更し、リクエスタを変更された要求位置２２６にナビゲートすることができる。この例では、要求がプロバイダに会うために、図２Ｂに示された例よりもさらにブロックの周りを移動することができる。プロバイダ２０６が位置２２６でリクエスタをピックアップすると、プロバイダ２０６は、目的地（不図示）へのルート２２２を続けることができる。
【００３３】
図３は、本技法の一実施形態による、縁石セグメントに対応する複数の代替ピックアップ位置が決定されるライドマッチングシステム環境の例３００を示す。図３の例３００では要求位置３０２が第１アベニューと第２アベニューとの間の建物内に表示され、これはリクエスタがその位置から輸送要求を行ったことを示すが、いくつかの実施形態ではリクエスタが建物内に要求位置を手動で配置した可能性がある。要求位置からの閾値距離３０４が決定され、例えば、要求位置を取り囲む一様な半径であってもよく、他の実施形態では、閾値距離がユーザ選択の結果として生成される、様々な要因に基づいて動的におよび／または自動的に生成されるカスタム領域であってもよい。
【００３４】
一実施形態によれば、特定の領域内（例えば、要求位置３０２の閾値距離３０４内）の縁石セグメントに対応するなど、いくつかの代替要求位置３０６を決定することができる。一実施形態によれば、要求位置３０２からの閾値距離３０４は、閾値距離３０４内のいくつかの代替要求位置３０６と共に決定することができる。例えば、動的輸送マッチングシステムは、すべての要求に使用される要求位置３０２からのデフォルト距離を示すデータを維持することができる。このデータはリクエスタのすべてまたはサブセットに適用することができ、例えば、ユーザはアプリケーションにおいてデフォルト距離を設定することができ、次いで、このデフォルト距離は、動的輸送マッチングシステムに送信され、リクエスタのアカウントに関連して格納され、将来の要求のために使用される。一実施形態では、距離が代替要求位置３０６の最小数および／または最大数が要求に応答して提供されるという要件に基づいて自動的に決定され得る。例えば、特定の要求は、動的輸送マッチングシステムにおいて、少なくとも１０個であるが２０個以下の代替要求位置３０６が要求のために見つかったことを示すデータに関連付けられてもよい。地理的データは例えば、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、または別個の地理的位置データベースなどへのＡＰＩ呼び出しを実行する動的輸送マッチングシステムによって、動的輸送マッチングシステムに提供することができ、要求が密集した都市領域に関連付けられていると判定することができる。したがって、小さい初期閾値距離３０４を使用することができる。要求がより密度の低い領域からのものであった場合、より大きな初期閾値距離３０４を利用することができる。初期閾値距離３０４に基づいて、多数の代替要求位置３０６が決定される。数が最小値未満である場合、最小数の代替要求位置３０６が見つかるまで、閾値距離３０４を増加させ、別の決定を行うことができ、以下同様であり、最大数についてはその逆である。閾値距離３０４を段階的に動的に増加させることによって、動的輸送マッチングシステムが、適切な数の代替要求位置３０６を見つけることが可能な最小閾値距離３０４に関する分析を実行することを可能にすることによって、動的輸送マッチングシステムに対するストレスを軽減することができる。
【００３５】
一実施形態では、閾値距離３０４内の潜在的な代替要求位置３０６のサブセットを、例えば、リクエスタに関連するデータに基づいて選択することができる。この例では、リクエスタに関連付けられた装置が適切な閾値距離３０４を決定する際に利用され得る特定の特性を記述するデータを有し得る。動的輸送マッチングシステムはアプリケーションからデバイス上のオペレーティングシステムへのＡＰＩコールを介してデバイスからこのデータを受信することができ、または、使用が許可されている様々な基準をデバイスのユーザが選択することに応答して動的輸送マッチングシステムにプッシュすることができる。例えば、リクエスタの年齢はより小さい閾値距離３０４が適切であることを示してもよく（例えば、リクエスタは高齢であってもよく）、その逆も同様である。ユーザは、代替要求位置３０６に移動するために受け入れる意思のある最大歩行距離を示す設定をアプリケーション内に有することができる。動き検出構成要素によって蓄積され、記憶されるような、デバイス上のデータは動的輸送マッチングシステムがユーザが（例えば、他のユーザと比較して）平均を上回る量を歩くことを決定することを可能にし、したがって、より長い閾値距離３０４を歩く傾向があり得る。標高データベースまたは同様のシステムへのＡＰＩ呼び出しを開始する動的輸送マッチングシステムによって受信され得るような標高データは閾値距離３０４を設定するために使用されてもよく、例えば、要求位置３０２からの１つの方向が上り坂（例えば、急勾配坂を上る）である場合、その方向の閾値距離３０４は低減されてもよく、または閾値距離３０４の軌跡はその方向から離れるようにシフトされてもよく、その逆もまた同様であり、下り坂で歩きやすい方向である。例えば、気象サービスへのＡＰＩ呼び出しに応答して動的輸送マッチングシステムによって受信された気象データを使用することができ、例えば、悪天候では、閾値距離３０４を低減することができる。夜遅い場合には、閾値距離３０４も同様に減少させることができる。
【００３６】
一実施形態によれば、閾値距離３０４を修正する代わりに、閾値距離３０４内の代替要求位置３０６のサブセットを、上述のようなデータに基づいて選択することができる。例えば、リクエスタは代替要求位置３０６に到達するために、どの道路をも横断したくないことを示してもよく、したがって、閾値距離３０４内の代替要求位置３０６のサブセット（例えば、道路横断を必要としない）が選択される。一実施形態では、要求された位置の範囲内でいくつかの代替要求位置をサンプリングすることができ、最良のまたは最適な代替要求位置を決定することができる。例えば、リクエスタの現在の要求された位置には５分のＥＴＡが存在し得るが、リクエスタがブロックの周りの代替の要求位置に歩行するためには２分のＥＴＡが存在し得る。これらの推定時間はいくらかの不確定性、予測不能性、および／または誤差を含み得るが、推定時間はまた、位置（例えば、ピックアップのための便利で容易な位置）と全体的な移動時間および／または遅延との間の確率およびトレードオフを考慮し得る。そのピックアップ要求位置の周りのピックアップ要求位置およびサンプルピックアップ位置はそれらのそれぞれのピックアップ位置スコアについて評価されてもよく、任意の時間節約／経験はピックアップ位置スコアと組み合わせて考慮されてもよい。推定された時間節約／経験について、統計的確率が適用されてもよい（例えば、少なくとも８０％の可能性または時間節約が存在するのであろうという信頼度など）。
【００３７】
図３の例では、代替要求位置３０６のサブセットが選択されている。一実施形態では、これは縁石セグメントデータを評価することに基づくことができる。例えば、閾値距離３０４を有する各交点間のセグメントを縁取る。例えば、第１アベニューとメインストリートとの交点、第２アベニューとメインストリートとの交点、第３アベニューとメインストリートとの交点である。図３の例では、第１アベニューと第２アベニューとの間の交点は閾値距離３０４の外側にあり、したがって、潜在的な代替要求位置３１０ａ、３１０ｂはサブセットの一部ではない。
【００３８】
一実施形態によれば、各交差点において、代替要求位置を各交差縁石セグメントに関連付けることができる。一実施形態によれば、要求位置３０２から各代替要求位置３０６への移動経路３０８、例えば、要求位置３０２から各代替要求位置３０６への最適経路を決定することができる。様々な実施形態では、最適経路が最小の道路交差点、標高データなどの基準を考慮に入れることができる。
【００３９】
図４Ａ〜４Ｂは、本技法の一実施形態による、ピックアップ位置の最適化に関連するデータを表示するための例示的なインターフェース手法を示す。図４の例４００では、プロバイダおよび／またはリクエスタに関連付けられたコンピューティングデバイス上に表示することができるアプリケーションインターフェース４１０が示されている。例示的なインターフェース４１０では、要求位置４０２が道路のレイアウト内の特定の位置に表示される。プロバイダ４０４の表現（例えば、要求位置に関連付けられた輸送要求を受け入れた）は、プロバイダの現在位置に対応する位置に表示され、要求位置へのプロバイダ４０４のルート４０６がリクエスタが要求位置４０２でピックアップされた後に取られる要求目的地（不図示）へのルート４０８と共に示されている。図４Ａに見られるように、プロバイダは目的地への直接ルートを取ることができず、代わりに、現在の要求位置４０２は、プロバイダ４０４がいくつかの交替を行うことを要求する。
【００４０】
図４Ｂの例４２０では、代替要求位置４２４が要求位置４０２に関して識別されている。例えば、先に説明したように、要求位置４０２の周りの閾値距離を決定することができ、１つ（またはいくつかの実施形態では、複数）が（図４Ａに示すように）元のルートよりも特定の量だけＥＴＡまたはＥＴＤのうちの１つ、またはその両方を減少させることがわかるまで、１セットの代替要求位置を評価することができる。この例では、代替要求位置４２４が代替要求位置４２４への移動経路４２２と共に表示される。この特定の代替要求位置４２４では、代替要求位置４２４へのプロバイダのルート４２６がより効率的であり（すなわち、より短く、折り返しがない）、目的地への旅行がブロックの周りを折り返す必要なしに、ピックアップ後に直ちに街路４２８を下って進むことを可能にすることなどが分かる。
【００４１】
代替要求位置４２４が選択されると、図４Ｂの例ではインターフェース４１０が新しいピックアップ位置（すなわち、要求位置）が利用可能であることを示し、代替要求位置４２４への２分の移動が全体の移動で５分を節約することを示すダイアログボックスまたは同様の要素４２８をリクエスタのデバイス上に提示するが、様々な実施形態ではリクエスタへのＥＴＡ、目的地へのＥＴＤ、またはその両方を示すことができる。次に、リクエスタは代替要求位置４２４を確認すること（４３２）または拒否すること（４３０）ができ、この決定は動的輸送マッチングシステムによって、代替要求位置４２４と共にプロバイダに（例えば、修正された第１の輸送要求情報を介して）送信される。
【００４２】
図５Ａ〜図５Ｄは、本技法の一実施形態による、セグメンテーション技法を抑制するための例示的な手法を示す。図５Ａの例５００では、道路５０２のレイアウト、例えば、第４２ストリート、ブロードウェイ、および第３アベニューが示されている。道路のレイアウトは、長さ、中心線、方向、位置などの１つまたは複数の道路の特性も記述する道路データに含めることができる。この道路データは、道路の特性に従って道路のレイアウトが構築されることを可能にする地理空間データと共に道路のリストを含むことができる。一実施形態では、道路データがＯｐｅｎＳｔｒｅｅｔＭａｐ(ＯＳＭ)データまたは同様のデータを含むことができる。図５Ａの例５００では、様々な建物５０４〜５０８が示されており、線は建物５０４〜５０８の境界に対応する。建物および境界データは建物データに含めることができ、建物データは、様々な実施形態では建物の位置、および建物境界を決定することができる形状または他の特性を記述する。例えば、建物は緯度値および経度値に関連する地理空間点のセットとして定義されてもよく、一実施形態では境界が様々な地理空間点間のエッジによって定義される。例えば、正方形の建物境界は、各々が建物のコーナーである４つの地理空間点と、多角形を含む地理空間点の組の間のエッジとを含むことができる。
【００４３】
図５Ｂの例５２０では、道路（第３アベニュー）に隣接する建物５０４の境界エッジ５２４が決定される。道路の幅（第３アベニュー）は一実施形態では例えば、道路データ、画像解析などに基づいて、道路の中心線５２２を決定することによって決定することができる。次いで、道路の幅は道路５２２の中心を道路に隣接する建物５０４の境界５２４と比較し、一実施形態では、道路５２４に隣接する建物の境界エッジと道路５２２の中心線との間の距離５２６を乗算することによって決定することができる。一実施形態では、それぞれの道路に隣接する建物境界間の距離を半分に分割して、道路幅の大まかな近似を与えることができる。一実施形態では、建物と道路との間の歩道または他のオフセットが推定係数を使用することによって推定することができる。例えば、建物の境界エッジから隣接する道路のエッジまでの距離の百分率（例えば、１５％）である。一実施形態によれば、道路、建物などの様々な要素は、グラフィカルデータ内の多角形、およびそれぞれの多角形を縮小するために使用されるグラスファイアなどのアルゴリズムまたは変換として表すことができる。
【００４４】
図５Ｃの例５４０では縁石セグメント５４２ａ、５４２ｂの概念は道路の幅、道路の中心線、および道路に隣接する建物境界エッジに基づいて決定することができる。例えば、道路の幅は既知であってもよく、または一実施形態では例えば、建物の境界と道路の中心線との間の距離を乗算することによって、または別の実施形態では上述したように、道路の両側の建物の境界間の距離の半分に分割することによって、決定されてもよい。一実施形態によれば、縁石セグメントは、Ｕターンを除いて、運転者が移動に関して選択肢を有さない道路の最小セグメントと考えることができる。例えば、図５Ｃの道路セグメント５４２ａは、第４２ストリートとブロードウェイとの間の第３アベニューの最小セグメントを含む。一実施形態では、横断歩道５４４ａ〜５４４ｃが縁石セグメント間の交点を評価し、縁石セグメント交点のおおよその位置での横断歩道を推定することによって決定されてもよい。例えば、図５Ｃの例５４０では第３アベニュー５４２ａに沿った図示された縁石セグメントがブロードウェイと第３アベニューとの間の第４２ストリートの縁石セグメント（不図示）と交差５５０し、２つの横断歩道５４４ａ、５４４ｃはこれらの地点におけるそれぞれの道路の交差を可能にすると推定される。一実施形態では、様々なデータが利用可能なデータソースから決定され、または導出され、または収集され得る。例えば、ＯＳＭは、道路幅、方向、一方通行道路、道路幅などを示すことができる。
【００４５】
図５Ｄの例５６０では、歩道推定のための別の実施形態が提供される。例えば、道路ネットワーク内の道路５６２、５６４は少なくとも２つの地点（例えば、地点間に直線が引かれた場合に道路を表す緯度及び経度を示す２つの地理空間地点）によって定義され得る幅（道路幅）を有する線と見なされ得る。カーブを有する道路はより多くの点（例えば、道路がカーブしている中央点、ベジェ点など）を含むことができる。本明細書で論じるように、少なくとも１つの建物５６６の境界および隣接する道路５６２の中心線を利用することによって、道路幅を決定し、道路の幅を表す線セグメントを決定することができ、線セグメントの幅は道路の幅を表す。ある意味では、道路は平坦なリボンと考えることができる。交差点は「リボン」が交差５７２し、「リボン」の交点５６８が、道路５６２、５６４の各個々の側部上の縁石のエッジを識別する場所であってもよい。交差領域５７２は多角形を表すことができ、交差点５６８間の線５７０は、横断歩道と考えることができる多角形のエッジを表す。一実施形態では、縁石セグメントのデータベースが緯度および経度を有する地理空間点などの「線セグメント」を表すデータを含むことができる。一実施形態では縁石セグメントがデータベース内でポリゴンとして表されてもよく、ポリゴンの点および／またはエッジは地理空間点によって記述される。
【００４６】
図６は、本技法の一実施形態によるライドマッチングシステム１３０の例示的なブロック図６００を示す。上述のように、ライドマッチングシステム１３０はリクエスタコンピューティングデバイス１２０に関連付けられたリクエスタ１１０からの要求マッチングを、プロバイダコンピューティングデバイス１５０に関連付けられた利用可能なプロバイダ１４０と識別し、容易にすることができる。ライドマッチングシステム１３０は、リクエスタインターフェース１３１、プロバイダインターフェース１３２、および移動時間推定モジュール１３４Ｂおよびプロバイダ選択モジュール１３５を含むライドマッチングモジュール１３３を含むことができる。ライドマッチングシステム１３０はまた、リクエスト情報データストア１３６Ａ、プロバイダ情報データストア１３６Ｂ、履歴ライドデータストア１３６Ｃ、及び対応するモジュールの機能を実行するために情報を得るためにライドマッチングシステム１３０のいずれのモジュールでも使用可能なナビゲーションデータストア１３６Ｄを含むことができる。ライドマッチングシステム１３０は、複数のリクエスタコンピューティングデバイス１２０および複数のプロバイダコンピューティングデバイス１５０と通信するように構成され得る。ライドマッチングシステム１３０は単一のシステムで示されているが、ライドマッチングシステム１３０は複数のサーバコンピュータ上でホストされてもよく、および／または複数のシステムにわたって分散されてもよい。さらに、モジュールは、任意の数の異なるコンピュータおよび／またはシステムによって実行され得る。したがって、モジュールは本明細書で説明される機能を実行するために、複数のサービスに、および／または複数の異なるシステムを介して分離され得る。
【００４７】
実施形態はライド要求を参照して説明されてもよいが、任意の数の異なるサービスが同様の要求およびマッチング機能を介して提供されてもよい。したがって、実施形態はライド要求のマッチングに限定されず、当業者は接続されたコンピューティングデバイスのネットワークを介してマッチングされるリクエスタおよびプロバイダを有する任意の数の異なるサービスについて実施形態が実装され得ることを認識するであろう。
【００４８】
リクエスタインターフェース１３１は、ライドマッチングシステム１３０と複数のリクエスタコンピューティングデバイス１２０との間で通信および／または他の情報を送受信するように構成された任意のソフトウェアおよび／またはハードウェアコンポーネントを含むことができる。リクエスタインターフェース１３１は、ライドマッチングシステム１３０と、複数のリクエスタコンピューティングデバイス１２０のそれぞれで動作するリクエスタアプリケーション１２１との間の通信を容易にするように構成され得る。リクエスタインターフェース１３１はリクエスタアプリケーション１２１がリクエスタコンピューティングデバイス１２０上でアクティブであるときに、ライド要求、位置情報、要求位置（「ピックアップ」位置とも呼ばれる）、リクエスタ状態情報、リクエスタコンピューティングデバイスの位置、リクエスタコンピューティングデバイスによる要求位置への進行、および／またはリクエスタコンピューティングデバイス１２０からの任意の他の関連情報を定期的に受信するように構成することができる。ライド要求は、リクエスタ識別子、リクエスタコンピューティングデバイス１２０の位置情報、ライド要求のピックアップ位置、１つまたは複数の目的地位置、ピックアップ時間、および／またはリクエスタにサービスを提供することに関連する任意の他の適切な情報を含むことができる。ライド要求は、単一のメッセージで送信されてもよく、または一連のメッセージを含んでもよい。ライドマッチング部１３３はライド要求を受信し、ライド要求情報で履歴ライドデータストア１３６Ｃを更新することができる。
【００４９】
さらに、リクエスタインターフェース１３１は、ライドマッチメッセージ、プロバイダコンピューティングデバイスの位置情報、プロバイダ情報、移動ルート、ピックアップ推定値、交通情報、リクエスタ更新／通知、および／または任意の他の関連情報を、リクエスタコンピューティングデバイス１２０のリクエスタアプリケーション１２１に送信するように構成され得る。リクエスタインターフェース１３１は、リクエスタ情報データストア１３６Ａを、リクエスタに受信および／または送信されたリクエスタ情報、リクエスタのステータス、リクエスタコンピューティングデバイスの位置、および／または任意の他の関連情報で更新することができる。
【００５０】
リクエスタコンピューティングデバイス１２０は、１つまたは複数の通信ネットワーク１７０を介してライドマッチングシステム１３０および／またはプロバイダコンピューティングデバイス１５０と通信するように構成された任意のデバイスを含むことができる。リクエスタコンピューティングデバイス１２０は、リクエスタコンピューティングデバイス１２０が１つまたは複数の通信ネットワーク１７０を介して通信することを可能にするために、プロセッサ、コンピュータ可読メモリ、ならびに通信ハードウェアおよび／またはソフトウェアを備えることができる。例えば、リクエスタコンピューティングデバイス１２０は、携帯電話、タブレット、スマートウォッチ、ラップトップコンピュータ、デスクトップコンピュータ、および／またはプロセッサ、メモリ、および通信ハードウェアを有する任意の他の適切なデバイスを含むことができる。いくつかの実施形態では、リクエスタコンピューティングデバイス１２０がライドマッチングシステム１３０との通信を管理し、リクエスタコンピューティングデバイス１２０のユーザ（すなわち、リクエスタ）とインターフェースするように構成されたリクエスタアプリケーション１２１を含むことができる。リクエスタアプリケーション１２１は、ユーザがライドを要求すること、マッチしたライドの状態を監視すること、ライドに対する支払いをすること、ライド履歴を監視すること、ライドマッチングシステム１３０に関連する他のリクエスタ指向サービスを実行すること、および／またはライドマッチングシステム１３０から他のリクエスタ指向情報を取得することを可能にし得る。
【００５１】
プロバイダインターフェース１３２は、ライドマッチングシステム１３０と複数のプロバイダコンピューティングデバイス１５０との間で通信および／または他の情報を送受信するように構成された任意のソフトウェアおよび／またはハードウェアを含むことができる。プロバイダインターフェース１３２はプロバイダアプリケーション１５１がプロバイダコンピューティングデバイス１５０上でアクティブであるときに、プロバイダコンピューティングデバイス１５０の位置情報、プロバイダステータス情報、および／またはプロバイダコンピューティングデバイス１５０からの任意の他の関連情報を定期的に受信するように構成され得る。さらに、プロバイダインターフェース１３２は、ライド要求、リクエスタコンピューティングデバイス１２０の位置情報、ピックアップ位置、移動ルート、ピックアップ推定値、交通情報、プロバイダ更新／通知、および／または任意の他の関連情報をプロバイダコンピューティングデバイス１５０のプロバイダアプリケーション１５１に送信するように構成され得る。プロバイダインターフェース１３２は、プロバイダ情報データストア１３６Ｂを、プロバイダに受信および／または送信されたプロバイダ情報、プロバイダのステータス、プロバイダコンピューティングデバイスの位置、および／または任意の他の関連情報で更新することができる。
【００５２】
プロバイダコンピューティングデバイス１５０は、１つまたは複数の通信ネットワーク１７０を介してライドマッチングシステム１３０および／またはプロバイダコンピューティングデバイス１５０と通信するように構成された任意のコンピューティングデバイスを含むことができる。プロバイダコンピューティングデバイス１５０はプロバイダコンピューティングデバイス１５０が１つまたは複数の通信ネットワーク１７０を介して通信することを可能にするために、プロセッサ、コンピュータ可読メモリ、ならびに通信ハードウェアおよび／またはソフトウェアを備えることができる。例えば、プロバイダコンピューティングデバイス１５０は、携帯電話、タブレット、スマートウォッチ、ラップトップコンピュータ、デスクトップコンピュータ、および／またはプロセッサ、メモリ、および通信ハードウェアを有する任意の他の適切なデバイスを含むことができる。いくつかの実施形態では、プロバイダコンピューティングデバイス１５０がライドマッチングシステム１３０との通信を管理し、プロバイダコンピューティングデバイス１５０のユーザとインターフェースするように構成されたプロバイダアプリケーション１５１を含むことができる。プロバイダアプリケーション１５１はユーザがライド要求を受け入れ、マッチしたライドの状態を監視し、マッチしたライドのナビゲーション方向またはマッピングされたルートを取得または生成し、ライドの代金を支払い、ライド履歴を監視し、ライドマッチングシステム１３０に関連する他のプロバイダ指向のサービスを実行し、および／またはライドマッチングシステム１３０から他のプロバイダ指向の情報を取得することを可能にすることができる。
【００５３】
ライドマッチングモジュール１３３はリクエスタと要求されたサービスのプロバイダとをマッチングさせるために、ライドマッチングシステム１３０のリクエスタとプロバイダとの間のライド要求、ライド応答、および他の通信を処理するように構成されたソフトウェアモジュールを含むことができる。例えば、ライドマッチング部１３３は、ピックアップ位置に関連する地理的領域を識別することによって、リクエスタからのライド要求のための利用可能なプロバイダを識別するように構成されてもよく、ピックアップ位置および／または地理的領域から所定の距離内の利用可能なプロバイダを識別するためにプロバイダ情報データストア１３６Ｂを検索してもよい。
【００５４】
ライドマッチングモジュール１３３は、ライドマッチングモジュールが本明細書で説明される動的モデルを使用して効率的なマッチングを実行することを可能にするように構成される、ピックアップ位置評価モジュール１３４Ａ、移動時間推定モジュール１３４Ｂ、およびプロバイダ選択モジュール１３５を含み得る。例えば、ライドマッチングモジュール１３３が要求を受信すると、ライドマッチングモジュールは、要求位置、要求時間、リクエスタ識別子、リクエスタの位置、および／または任意の他の関連情報を含む輸送要求情報を、ピックアップ位置評価モジュール１３４Ａ、移動時間推定モジュール１３４Ｂ、またはその両方に渡すことができる。
【００５５】
ピックアップ位置評価モジュール１３４Ａは要求位置が不良位置に関連付けられているかどうか、および／または代替要求位置がプロバイダとリクエスタとの間のより良好なやり取りをもたらすことができるかどうかを判定するために、要求位置を評価するように構成することができる。ピックアップ位置評価モジュール１３４Ａは要求位置を受信することができ、要求位置に基づいて、修正された要求位置が要求のために提供され得るかどうかを評価することができる。例えば、ピックアップ位置評価モジュール１３４Ａは閾値を満たすピックアップ位置スコアのみを有する位置を考慮して、移動するための推定時間および目的地までの推定時間を最適化するために、ピックアップ位置スコアのためのフィルタを実装するように構成され得る。ピックアップ評価モジュール１３４Ａは不十分なピックアップ位置スコアを有する位置をフィルタリングし、閾値を超えるピックアップ位置スコアを有するピックアップ位置に基づいてルートを最適化することができる。代替的に及び／又は追加的に、特に、移動までの推定時間及び／又は目的地までの推定時間の著しい節約が見つからない場合に、異なる位置の異なるピックアップ位置スコア間の差を評価して、どの位置が最適であるかを決定することができる。いくつかの実施形態では、ピックアップ位置スコアがピックアップ位置としてのその適合度について位置を評価するために、以前のライド履歴データに基づいて計算されてもよい。以前のライド履歴データはまた、プロバイダまたはリクエスタのいずれかによって開始された、そのピックアップ位置に関連するいくつかのキャンセルを含むことができ、キャンセルの傾向があるかどうかを示すためにピックアップ位置の位置スコアに影響を及ぼすことができる。位置の適合性は、ピックアップ位置がプロバイダの効率および生産性を向上させ、動的輸送マッチングシステムの全体的なリソース割振りを向上させながら、リクエスタの待ち時間を低減させる可能性があることを示す客観的な測定値とすることができる。
【００５６】
例えば、いくつかの実施形態では、ピックアップ位置評価モジュール１３４Ａが過去のリクエスタおよびマッチしたプロバイダがピックアップを調整するために通信しなければならなかったかどうかを判定することによって、要求された位置のピックアップ位置スコアを評価することができる。ピックアップを調整するためのリクエスタとプロバイダとの間の外部通信（例えば、テキストメッセージ、電話呼び出し、電子メールなど）は、提供されるピックアップサービスの利便性および機能性を損なうため、望ましくない場合がある。外部通信の必要性はプロバイダに送信された要求位置が正確でない可能性があること、または要求位置がプロバイダが識別するのに便利または容易な位置（例えば、隠れた車道または入口）ではないこと、またはリクエスタと会う（例えば、交通量が多い、交通を遮断する結果になるなど）ことを示すことができる。したがって、ピックアップを容易にするためのリクエスタとプロバイダとの間の外部通信は、リクエストされた位置が最適位置ではなく、したがって、リクエストされた位置のピックアップ位置スコアに影響を及ぼすという指示であり得る。外部通信は、以前のライド履歴データの一部として記録され、記憶されてもよく、ピックアップ位置のための外部通信のレートが決定され、ピックアップ位置スコアを評価するために使用されてもよい。
【００５７】
要求された位置のピックアップ位置スコアを評価するためにピックアップ位置評価モジュール１３４Ａによって考慮され得る他の要因は、マッチしたプロバイダがリクエスタがいる位置で実際に停止しているかどうかを判定することを含む。ピックアップ評価モジュール１３４Ａは、要求されたピックアップ位置から実際のピックアップ位置までの距離を計算することができる。例えば、リクエスタは、プロバイダがリクエスタが待っていたリクエストされた位置にドライブすることができなかった可能性があるので、プロバイダによって実際にピックアップされるためにブロックを歩き回ることに終わる可能性がある。要求された位置は無停車ゾーン、特定の車両のみに限定されたもの、高い交通量、または建設ゾーンにあってもよく、これは実際のピックアップ位置を要求された位置とは異なる位置にする可能性がある。したがって、要求された位置ピックアップから実際のピックアップまでの距離を使用して、要求された位置のピックアップ位置スコアを決定することもできる。例えば、リクエスタが要求されたピックアップ位置から実際のピックアップ位置まで歩く平均距離は、その要求された位置のピックアップ位置スコアに影響を及ぼし得る。気象条件および他の要因も考慮することができ、例えば、悪天候では、実際のピックアップ位置が要求されたピックアップ位置にあるか、またはできるだけ近いことが重要である場合がある。別の例では、リクエスタが障害者であるか、または多くの食料雑貨品を持ち運んでいる可能性があり、要求されたピックアップ位置から別の位置に容易に到達することができない。要求されたピックアップ位置から実際のピックアップ位置まで歩いた平均距離はまた、時間遅延に変換され、要求された位置ピックアップ位置スコアにも影響を及ぼし得る全体的な移動遅延に結合され得る。
【００５８】
さらに、および／または代替として、いくつかの実施形態では、ピックアップ評価モジュール１３４Ａがプロバイダがリクエスタをピックアップするために安全かつ合法的な停止を行うことができるかどうかを考慮することができる。例えば、ピックアップ評価モジュール１３４Ａは、事故、衝突、警察レポート、および／または交通量の過去の事故に基づく安全評価スコアを考慮することもできる。これに加えて、またはこれに代えて、安全性評価スコアをピックアップ位置スコアに組み込むことができる。要求されたピックアップ位置がリクエスタとプロバイダの両方にとって極めて危険な位置である状況、例えば、主要な高交通量道路へのオンランプまたはオフランプ、または接近する交通がそれらの前方に車が停止していることを容易に見ることができないターンである状況があり得る。これらの状況では、ピックアップ評価モジュール１３４Ａが縁石推定システム内の縁石データベースに縁石識別子を照会することによって、要求された位置が適切でないと判断し、縁石セグメントが危険すぎるという指示を受信することができる。その結果、特定の縁石セグメントが安全でないと識別された場合、そのピックアップ位置スコアは要求された位置がプロバイダが停止するのに安全でない、または違法であることをリクエスタに示し、安全である最も近い代替ピックアップ位置を識別し、その代わりに、全体的な移動遅延を低減し、安全性を保証するために、その最も近い代替ピックアップ位置に移動するようリクエスタに要求するように影響され得る。
【００５９】
さらに、いくつかの実施形態では、ピックアップ位置スコアがピックアップ位置固有の期待値および／またはピックアップ位置固有の確率を含む時間通信確率モデルを組み込むことができる。例えば、ピックアップ位置固有の期待値はプロバイダとリクエスタとの間の通信の時間（例えば、秒単位の調整可能なコスト）の関数とすることができる。例えば、ピックアップ位置固有の確率は（１）プロバイダ到着とリクエスタピックアップとの間の時間間隔（例えば、リクエスタがリクエストされたピックアップ位置から実際のピックアップ位置まで歩かなければならない場合）がある閾値未満である確率と、（２）ピックアップを行う場所を調整するためにプロバイダ到着とリクエスタピックアップとの間の時間間隔中にリクエスタとプロバイダとの間に外部通信がない確率との２つの条件が満たされる確率を含むことができる。ピックアップ位置スコアはまた、時間メトリックに変換されてもよく、例えば、より良好なピックアップ位置スコアは、ライド全体の時間節約、またはリクエスタの最終目的地へのより早期の推定到着時間によって示されてもよい。
【００６０】
要求された位置のピックアップ位置スコアを評価するためにピックアップ位置評価モジュール１３４Ａによって考慮され得る他の要因は、そのピックアップ位置に関連するキャンセルの数を決定することを含む。キャンセルはプロバイダまたはリクエスタのいずれかによって開始されてもよく、アクセス不能（例えば、丘の中の風の強い暗い道路）、位置を見つけることの困難さ（例えば、大きな駐車場の中の隠れた店の前端）、停止することの困難さ（例えば、路肩のない単一車線の高交通量街路）などのために、キャンセルする傾向があるかどうかを示すために、ピックアップ位置の位置スコアに影響を及ぼすことができる。リクエスタ、プロバイダ、履歴データ、リアルタイム交通データ、環境データ、統計的交通確率、および／またはピックアップ位置がリクエスタおよびプロバイダにとって適切であり、効率的であり、便利であり、最適であるかどうかを判定する際の任意の他のデータに関連する任意の要因、パラメータ、またはデータを含むが、これらに限定されない、多くの他の要因がピックアップ位置評価モジュール１３４Ａによって考慮されて、要求された位置のピックアップ位置スコアを判定することができる。
【００６１】
別の実施形態ではピックアップ要求に応答してリアルタイムでピックアップ位置スコアを計算する代わりに、ピックアップ位置評価モジュール１３４Ａは位置スコアデータベース６１４に格納された領域内の各種縁石部分および／または街路について、位置スコアリングシステム６１０から事前に計算されたピックアップ位置スコアを受信することができる。位置スコアリングシステム６１０は１つ以上の地域のために以前に計算されたピックアップ位置スコアを保存する位置スコアデータベース６１４を備えることができ、また、抑制セグメント、位置識別子、および／または他のピックアップ位置識別情報を受け取ることに応じて、ピックアップ位置スコアをピックアップ位置評価モジュール１３４Ａに送ることができる。位置スコアリングシステムは受信された位置識別情報に関連付けられた１つ以上のピックアップ位置に関連付けられた１つ以上の予め計算されたピックアップ位置スコアを識別し、１つ以上のピックアップ位置スコアをピックアップ位置評価モジュール１３４に返すことができる。したがって、いくつかの実施形態では、ライドマッチングシステム１３０が要求が受信される前に生成された事前に計算されたピックアップ位置スコアを利用することができる。したがって、位置スコアリングシステム６１０は位置スコアデータベース６１４から事前計算されたピックアップ位置スコアを取り出し、ピックアップ位置評価モジュール１３４Ａによる評価のために、それをライドマッチングシステム１３０に送信することができる。
【００６２】
同時におよび／または連続して（ピックアップ位置評価モジュール１３４Ａの処理が開始および／または完了する前または後のいずれかに）、移動時間推定モジュール１３４Ｂは輸送要求情報を受信することができ、要求位置周辺の地理的領域内の利用可能なプロバイダを識別することができる。移動時間推定モジュール１３４Ｂは閾値距離（例えば、５ブロック、２００ヤード、１０マイル、１５マイルなど）、１つまたは複数の郵便番号または他の地理的識別子（例えば、街路、ブロック、近隣、都市、地域など）、または任意の他の適切な地理的制限を使用して、要求位置に関連する利用可能なプロバイダを識別することができる。例えば、移動時間推定モジュール１３４Ｂは、プロバイダ情報データストア１３６Ｂを検索して、要求位置からある距離内に位置する任意の利用可能なプロバイダを識別することができる。移動時間推定モジュール１３４Ｂはまた、利用可能なプロバイダが要求にサービスを提供できるように、利用可能なプロバイダの探索をライド要求基準を満たすプロバイダに制限することができる。例えば、プロバイダ車両がセダン、ラグジュアリー、ＳＵＶ、または他のタイプの自動車であるかどうかにかかわらず、特定のタイプの特徴または快適性（例えば、自動車座席、犬フレンドリーなど）を有し、多数の利用可能な座席を有し（例えば、２人の要求など）、かつ／またはライドマッチングシステムにおいて任意の他の記憶された情報を使用して、利用可能なプロバイダを要求に応じることができるプロバイダに限定することができる。
【００６３】
移動時間推定部１３４Ｂが領域内の利用可能なプロバイダを識別すると、移動時間推定部１３４Ｂは、プロバイダのそれぞれについて、プロバイダの現在位置から要求位置までの推定移動時間を計算することができる。上述のように、移動時間推定モジュール１３４Ｂは、交通量、天候、道路閉鎖、および／または移動時間に影響を及ぼし得る任意の他の条件を推定に組み込み得る。移動時間推定モジュール１３４Ｂは、時刻、街路、および地理的領域、ならびにそれらの時間、領域、道路状態、および／または任意の他の情報にわたる記憶された以前のライドに関連する履歴ライドデータを使用して、プロバイダがそれらの現在位置から要求位置まで移動するための推定値を取得することができる。例えば、移動時間推定モジュール１３４Ｂは、プロバイダコンピューティングデバイスのそれぞれの位置を取得するように構成され得る。移動時間推定モジュール１３４Ｂは要求位置を識別し、要求位置へのプロバイダおよびリクエスタのそれぞれのナビゲーションルートをマップするように構成され得る。移動時間推定モジュール１３４Ｂは、ナビゲーションデータストア１３６Ｄから取得されたナビゲーション情報に基づいて、様々な異なるルートの推定到着時間を計算することができる。ナビゲーション情報はリアルタイムおよび過去の交通情報、過去の移動時間情報、地理的領域または地域の既知のルート、交通規則、および／または輸送のタイプ（例えば、運転、自転車乗り、航行、飛行など）に基づいて１つの場所から別の場所に移動するための潜在的なルートをマッピングおよび／または識別するための任意の他の適切な情報を含むことができる。
【００６４】
移動時間推定モジュール１３４Ｂはプロバイダ位置から要求位置ならびに代替要求位置への複数の可能なルートをマッピングし、潜在的にマッピングされたルートのそれぞれについて推定された到着時間を生成することができる。移動時間推定モジュール１３４Ｂは、プロバイダのそれぞれのための最も速いルートおよび／または最も確率の高いルートと、そのルートのための対応する推定移動時間とを、プロバイダのための推定移動時間として選択することができる。移動時間推定モジュール１３４Ｂはプロバイダの推定到着時間を計算するために、現在の交通状況、道路閉鎖、気象状況、および任意の他の関連する移動時間関連情報を組み込むことができる。推定到着時間はまた、マップされたルートのそれぞれの到着時間の平均値をとること、最も速いルートの推定到着時間を選択すること、プロバイダによって潜在的なルートのうちの１つの選択を受信すること、プロバイダによって使用されているルートに基づいてとられているルートを識別すること、および／または任意の他の適切な方法によって計算され得る。プロバイダが誤ったターンをし、および／または移動時間推定部１３４Ｂによって計算されたものとは異なるルートをたどる場合、移動時間推定モジュール１３４Ｂはプロバイダコンピューティングデバイスの更新された位置を取得し、可能なルートおよび推定された到着時間を再計算することができる。このように、推定された移動時間は、移動及び道路の状態、天候等が更新されるにつれて更新されてもよい。したがって、移動時間推定モジュール１３４Ｂは、要求位置に関連付けられたナビゲーションルートと、プロバイダのそれぞれの推定移動時間とを決定することができる。さらに、推定時間は、複数のルートの平均値をとること、最速ルートを選択すること、時間の推定の確実性が低い場合に追加のクッション時間を追加することなどを含む、任意の適切な方法によって決定され得る。したがって、移動時間推定モジュール１３４Ｂは、潜在的に要求にマッチする可能性がある領域内の利用可能なプロバイダのそれぞれについて推定移動時間を決定することができる。
【００６５】
さらに、移動時間推定モジュール１３４Ｂは、要求位置および／または代替要求位置のうちの１つまたは複数へのリクエスタの到着時間を決定することができる。リクエスタの到着時間は、移動時間と、リクエストに提供されたリクエスト時間とに依存する。例えば、移動時間は、リクエスタの現在位置から要求位置までの推定移動時間を決定することによって決定されてもよい。移動時間は、ルートに関連付けられた以前の時間推定値についてリクエスタ情報データストア１３６Ａを、および／またはルートに関連付けられた関連する移動時間について履歴ライドデータストア１３６Ｃを検索することによって推定され得る。リクエスタの移動時間は、歩行速度に基づいて決定されてもよく、ナビゲーションデータストア１３６Ｄを使用して、異なる位置からの歩行に関連する移動時間を識別してもよい。さらに、リクエスタが建物内に位置する場合、移動時間推定値は時間推定値の精度を改善するために、それらの建物内のリクエスタが建物を離れる平均移動時間を組み込むことができる。さらに、リクエスタ到着時間は、ライドを要求すると、ユーザによってアプリケーションに入力された遅延によって指示される要求時間コンポーネントを有することができる。例えば、リクエスタは出発する準備が整う前にさらに１０分を必要とするが、出発する準備が整うとプロバイダとマッチすることを知るようにライドを要求することができる。したがって、リクエスタは、ライドが１０分、１時間、１日、または将来の任意の他の関連する時間の間スケジュールされることを要求することができる。したがって、到着時間は、移動時間および要求時間成分の両方を有することができる。
【００６６】
いくつかの実施形態では、移動時間および要求時間が一緒に加算されてもよく、または別々に使用されてもよい。例えば、要求が１０分間離れており、ユーザの近くの位置に対するものである場合、リクエスタ到着時間は、ちょうど１０分間の待ち時間であってもよい。しかしながら、ユーザがブロックを下っている要求位置でスケジュールされたライドを要求し、システムが、ユーザがすでに離れているはずのときに要求位置に向かって歩いていないと判定した場合、移動時間を要求時間に加えて、正確なマッチを保証することもできる。
【００６７】
さらに、いくつかの実施形態では、移動時間推定モジュール１３４Ｂがサードパーティマッピングサービスから推定値を要求することによって、プロバイダおよびリクエスタに関するすべての移動推定値を取得することができる。例えば、移動時間推定モジュール１３４Ｂは要求位置、リクエスタの現在位置、プロバイダの現在位置、および要求時間がサードパーティマッピングサービスに提供されるように、サードパーティマッピングサービスに関連するＡＰＩを呼び出すことができる。マッピングサービスはルートの実際の推定を実行し、その推定値を、マッチングのためのプロバイダを選択する際に使用するために、移動時間推定モジュール１３４Ｂに返すことができる。いずれにしても、移動時間推定部１３４Ｂは、利用可能なプロバイダおよびリクエスタの移動時間推定値を、さらなるマッチング処理のためにライドマッチングモジュール１３３に返すことができる。同様に、いくつかの実施形態では、本明細書で説明されるピックアップ位置スコアリング機能がサードパーティ位置スコアリングサービスによって提供されてもよく、ピックアップ位置スコアに基づく位置スコアおよび／または推奨位置は当業者が認識するように、マッチングプロセスに組み込まれてもよい。
【００６８】
次いで、ライドマッチングモジュール１３３は、プロバイダおよびリクエスタの推定移動時間をプロバイダ選択モジュール１３５に提供することができる。プロバイダ選択モジュール１３５は推定移動時間を取得することができ、要求とマッチすべき１つまたは複数のプロバイダを選択することができる。したがって、プロバイダ選択モジュール１３５は、プロバイダのそれぞれの推定リクエスタ到着時間および推定プロバイダ時間の両方を組み込む動的プロバイダ適格性モデルを生成して、マッチに適格な利用可能なプロバイダを識別することができる。したがって、上述したように、プロバイダ選択モジュール１３５は要求にマッチする適格な利用可能なプロバイダを識別するために、リクエスタ到着時間よりは長いが閾値移動時間よりは短いプロバイダ移動時間を識別することができる。次いで、プロバイダ選択モジュール１３５は適格な利用可能なプロバイダのサブセットを選択し、システム効率、ランキング、ルート、到着時間、および／またはマッチングに使用することができる任意の他の適切な情報に基づいて、プロバイダのうちの１つを選択することができる。例えば、２つの利用可能なプロバイダは一方のプロバイダが要求位置から離れて移動し、他方のプロバイダが要求位置に向かって移動している要求に適格であると識別されてもよい。プロバイダ選択モジュール１３５は、より少ない運転、より少ない旋回、より安全な運転、およびプロバイダが現在の移動方向を維持することを可能にする他のすべての利点を引き起こすので、要求位置に向かって移動しているプロバイダを選択することができる。
【００６９】
さらに、いくつかの実施形態では、プロバイダ選択モジュール１３５が最良の可能なマッチが行われていることを保証するために、利用可能なプロバイダ予測を実行することができる。例えば、プロバイダ選択モジュール１３５は要求位置の近くでオンラインに来る利用可能なプロバイダの履歴レートを示すことができる履歴ライドデータストア１３６Ｃから、要求位置に関連する利用可能なプロバイダレートを取得することができる。例えば、いくつかの領域は、ライドマッチングシステムが要求位置の近くの利用可能なプロバイダを予測するために使用することができる特定の時間中にオンラインに来るプロバイダの割合が高い場合がある。比較的大きいリクエスタ到着時間（例えば、５分以上）が未処理であり、予測される利用可能なプロバイダのレートが高い要求の場合、システムはより効率的なシステムマッチが生じないことを保証するために、利用可能であり、要求に適格な複数のプロバイダが存在する場合であっても、適格なプロバイダへのマッチングを遅延させることができる。さらに、ライド履歴データストア１３６Ｃは、リクエスタ到着時間が経過する前に領域内のリクエスタをドロップオフするプロバイダを有する既存のライドについて調べることができる。例えば、リクエスタを有する多数の異なるプロバイダが以前にマッチしたリクエスタをドロップオフしているビジー領域、および／またはリクエスタ到着時間の時間フレーム中に新しいプロバイダがアクティブになることが分かっているビジー領域について要求が受信される場合、プロバイダ選択部１３５はプロバイダがリクエストのための既存の適格なプロバイダよりも近い領域内で利用可能になるかどうかを見るために、マッチングを遅延させてもよい。ライドマッチング部はプロセスを繰り返し、リクエスタがリクエスト位置に到着する前に、十分にマッチし、適格なプロバイダがリクエストにマッチすることを確実にするために、リクエスト位置に向かうリクエスタの進行と共に、領域内の利用可能でマッチしたプロバイダのステータスを監視することができる。したがって、システムアクティビティを追跡および監視すること、ならびにプロバイダおよびリクエスタの推定到着時間を経時的に使用することによって、システムは、プロバイダリソースをリクエスタリソースとより効率的かつ効果的にマッチングさせて、リソースの最も効率的なマッチングを保証することができる。
【００７０】
別の実施形態では、ピックアップ位置評価モジュール１３４Ａがライド履歴ストア１３６Ｃに結合されて、マルチファクタ確率モデルを使用してそれぞれの位置のピックアップ位置スコアを決定することができる。ライド履歴データストア１３６Ｃは、複数の位置のピックアップ位置スコア、それらの位置に関連する時間遅延、ならびにプロバイダおよび／またはリクエスタに関連する他の要因に関する集約データを含むことができる。したがって、ライド履歴データストア１３６Ｃに記憶されるライド履歴データが多いほど、特定の要求位置がピックアップのためにどれだけ適切であるかを予測する際に、マルチファクタ確率モデルをより正確にすることができる。ピックアップ位置スコア計算に含まれ、および／またはライド履歴データストア１３６Ｃに記憶され得る他のピックアップ要因は要求された位置から近くの交差点までの距離、道路セグメントタイプ（例えば、高速道路、ローカル道路）、速度制限、道路内のレーン数、道路方向性（例えば、一方通行）、平均履歴交通速度、掲示規則（例えば、無停車ゾーン、自転車レーン、バスレーン、路肩なしなど）、および／または交差点のタイプ（例えば、交通信号、４方向停車、横断歩道、ラウンドアバウトなど）を含むことができる。さらに、いくつかの他の実施形態では、ピックアップ位置評価モジュール１３４Ａが時間通信確率モデルとマルチファクタ確率モデルとの組み合わせを使用して、様々な位置についてのそれぞれのピックアップ位置スコアを計算することができる。別の実施形態では、地理的領域に応じて、一方の確率モデルを他方の確率モデルよりも使用することができる。例えば、多くの要因が関与する都市ではマルチファクタ確率モデルが正確なピックアップ位置スコアを決定するのにより適しており、農村地域ではより単純な時間通信確率モデルがピックアップ位置スコアを決定するのに十分である。
【００７１】
ライドマッチングモジュール１３３はライド要求が１つまたは複数の利用可能なプロバイダに送信され得るように、プロバイダ連絡先情報またはプロバイダ識別子を用いてプロバイダインターフェイス１３２にライド要求を提供することができる。ライドマッチングモジュール１３３は、ライド要求および／またはライド要求からの情報を、選択された利用可能なプロバイダのうちの１つまたは複数に送信して、利用可能なプロバイダがライド要求を受け入れることに関心があるかどうかを判定することができる。１つまたは複数の利用可能なプロバイダはプロバイダコンピューティングデバイス１５０のプロバイダアプリケーション１５１を介してライド要求を受信することができ、要求を評価することができ、プロバイダアプリケーション１５１を介して入力を提供することによって要求を受け入れるかまたは拒否することができる。ライドマッチングシステム１３０が応答を処理することを可能にするために、ライドが受け入れられたかどうかを示し、プロバイダ識別子、プロバイダの位置、および／または任意の他の適切な情報を含むライド応答メッセージが、ライドマッチングシステム１３０に送信され得る。あるいは、プロバイダが要求を無視してもよく、所定の期間の後、要求は拒否されたとみなされてもよく、対応するライド応答メッセージがライドマッチングシステム１３０に送信されてもよい。いくつかの実施形態では、ライド要求が受け入れられ、プロバイダから応答が受信されない限りライドが拒否されると仮定されない限り、応答は送信されない。他の実施形態では、応答は不要であり、ライドは直ちに受け入れられてもよい。インジケータ、フラグ、および／または他の情報が、ライドマッチングシステムに戻されて、プロバイダコンピューティングデバイスが要求を受信したことをシステムに保証することができる。
【００７２】
ライドマッチングモジュール１３３はライド応答を受信し、プロバイダが要求を受け入れたか拒否したかを評価し、（拒否された場合）要求のための追加の利用可能なプロバイダを見つけるか、またはライド要求が受け入れられたと判定し、照合されたライド情報をリクエスタコンピューティングデバイス１２０およびプロバイダコンピューティングデバイス１５０に送信することができる。マッチしたライド情報は、プロバイダ情報、リクエスタ情報、ピックアップ位置、プロバイダコンピューティングデバイスの現在位置、リクエスタコンピューティングデバイスの現在位置、プロバイダの推定到着時間、および／またはリクエスタおよびプロバイダが要求されたサービスを完了することを可能にする任意の他の適切な情報を含むことができる。ライドマッチングモジュール１３３は、マッチングされたライドについての対応するマッチングされたライド情報で履歴ライドデータストア１３６Ｃを更新することができる。したがって、ライドマッチングモジュールは、プロバイダとの要求のより効率的かつ効果的なマッチングを実行することができる。
【００７３】
縁石推定システム６０２は、別個のシステムとして、またはライドマッチングシステム１３０の一部として提供されてもよく、逆もまた同様である。縁石推定モジュール６０４は、縁石推定システム６０２の一部であり得る、および／または縁石推定システム６０２と通信可能に結合され得る、インフラストラクチャデータ６０６などの様々なデータストアを利用し得る。例えば、インフラストラクチャデータ６０６は他の例の中でもとりわけ、道路データ、建物データ、ローカル特徴（例えば、消火栓、停止ゾーンなし、積み込み専用ゾーンなど）を含むことができる。縁石推定モジュール６０４は例えば、地理的領域内の縁石セグメントを決定するために、前述のようにデータを利用することができる。縁石セグメントが決定されると、縁石セグメントデータは、例えば縁石データベース６０８に記憶される。
【００７４】
位置スコアリングシステム６１０は、別個のシステムとして、またはライドマッチングシステム１３０の一部として提供されてもよく、逆もまた同様である。位置スコアリングモジュール６１２は位置スコアリングシステム６１０の一部であってもよく、および／または履歴ライドデータ１３６Ｃなどの位置スコアリングシステム６１０と通信可能に結合されてもよい、様々なデータストアを利用してもよい。例えば、履歴ライドデータ１３６Ｃは、ライドマッチングシステム１３０および／または任意の他のサードパーティライドデータソースによってサービスされた要求およびマッチングされたライドのデータセットを備えることができる。例えば、履歴ライドデータ１３６Ｃは輸送要求から受信した任意の情報（例えば、リクエスタのユーザ識別子、要求位置、目的地、要求が行われたときのリクエスタおよびプロバイダの位置など）と、輸送要求に関連する任意の情報（例えば、ライドマッチングプロセスが進行することにつれてのプロバイダおよび／またはリクエスタの現在位置、輸送要求の結果（例えば、キャンセル、完了など））、要求が完了した後のフィードバック、要求の日付、日付、および時間、要求時の天気、ならびに輸送要求に関連して捕捉、格納、および追跡することができる任意の他の情報）とを含むことができる。位置スコアリングモジュール６１２は例えば、地理的領域内の代替要求位置と同様に要求位置のピックアップ位置スコアを決定するために、前述のようにデータを利用することができる。
【００７５】
位置スコアリングモジュール６１２は、任意の適切なプロセスによってピックアップ位置スコアを決定することができる。例えば、本明細書で論じられるように、ピックアップ位置スコアは（１）リクエスタとプロバイダとの間の通信、（２）リクエスタがプロバイダを見つけるために長距離を歩かなければならなかったかどうか（例えば、示されたピックアップ位置から実際のピックアップ位置まで）、および（３）プロバイダ到着と実際のリクエスタピックアップとの間の時間（例えば、リクエスタが直ちに存在しなかった場合および／またはプロバイダがリクエスタを見つけることができない場合に、対処する時間）があったかどうかに基づいてもよい。
【００７６】
いくつかの実施形態では、位置スコアリングモジュール６１２はまた、縁石セグメントデータへのアクセスを有し、縁石セグメントデータを使用して、ピックアップ位置スコアリングのための一様なアドレッシングおよび／または参照マッピングシステムを作成することができる。ピックアップ位置スコアは例えば、縁石セグメントデータに従って（または縁石セグメント識別子を参照して）位置スコアデータベース６１４に格納されてもよい。さらに、位置スコアリングシステム６１０は利用可能な縁石セグメントデータのピックアップ位置スコアを定期的に、トリガ時に、および／または任意の他の処理スキームを使用して、要求位置の要求が受信されると、ピックアップ位置スコアが要求位置のために提供される準備ができるように維持し、処理することができる。代替的に及び／又は追加的に、ピックアップ位置スコアは、履歴ライドデータ１３６Ｃを使用して要求が受信されると生成されてもよい。
【００７７】
図７は、本技法の実施形態による、最適化されたピックアップ位置を提供するために縁石セグメントデータを使用するための方法の例示的な流れ図を示す。ステップ７０２において、動的輸送マッチングシステムは、リクエスタコンピューティングデバイスからライド要求を受信する。ライド要求はライド要求の要求位置（すなわち、ピックアップ位置）、要求目的地（すなわち、ドロップオフ位置）、要求時間、リクエスタ識別子、リクエスタコンピューティングデバイス位置、および／またはライド要求および／またはリクエスタに関連する任意の他の関連情報を含むデータ（たとえば、輸送要求情報）を含むことができる。
【００７８】
ステップ７０４において、プロバイダは例えば、輸送要求情報に基づいて、輸送要求にマッチングされる。一実施形態ではマッチングシステムが要求とマッチングする最も近いプロバイダを決定するが、いくつかの実施形態では距離、格付け、既存の移動ルート、および／または任意の他の適切な情報を含む任意の適切な基準を使用してプロバイダマッチングを行うことができる。一実施形態ではマッチしたプロバイダが特定のプロバイダが要求先に移動するのにかかる時間である第１の推定至目的地時間（ＥＴＤ）に基づいて決定され、この時間はプロバイダの要求位置への推定到着時間（ＥＴＡ）を含んでも含まなくてもよい。
【００７９】
ステップ７０６において、第１の要求位置の閾値距離が決定される。例えば、要求位置を取り囲む均一な半径を確立することができ、前述のような他の例では、閾値距離に対応する境界および／または距離を修正するために様々なデータを利用することができる。
【００８０】
ステップ７０８において、代替要求位置が決定される。一実施形態では、複数の代替要求位置が例えば、要求位置の閾値距離内で決定される。一実施形態では、代替要求位置が代替要求位置が各交差点の周りの点に対応するように、交差点によって定義されるように、閾値距離内のセグメンテーションを抑制することに対応する。例えば、２つの道路が交差する場合、図３に見られるように、メインストリートと第１アベニューとの交差点に、対応する縁石セグメントの８つの交差点があってもよい。様々な実施形態では、より多くのまたはより少ない交差点および／または代替の要求位置が道路の各交差点に対応し得る。一実施形態では、閾値距離内のすべての代替要求位置のサブセットが例えば、リクエスタによる手動選択、リクエスタに対応するデータに基づく自動選択、道路データ、地理データ、気象データなどに基づいて選択され得る。
【００８１】
ステップ７１０において、リクエスタが元の要求位置から代替要求位置の各々に移動するための推定移動時間（ＥＴＴ）が決定されるが、様々な実施形態では代替要求位置のすべてよりも少ないものが決定の一部である。ＥＴＴは、平均歩行速度、年齢などのリクエスタに対応する様々なデータ、ならびに道路データ、地理データ、気象データなどの前述の他のデータを考慮に入れることができる。
【００８２】
ステップ７１２で、代替要求位置のいずれかが、目的地へのより効率的なＥＴＤ（例えば、より速い時間、より短いルート、より少ないターン、より少ないトラフィックなど）をもたらすかどうかの判定が行われる。例えば、元の要求位置は、元のＥＴＤに関連付けられる。一実施形態では、代替要求位置のうちの少なくとも１つについて、代替要求位置に対するリクエスタのＥＴＴが代替要求位置に対応する新しいＥＴＤに追加される。合計時間が元の要求位置からの元のＥＴＤよりも短い場合、代替要求位置が選択される。一実施形態では、複数の代替要求位置が元の要求位置よりも速いＥＴＤを有することができ、その場合、ユーザは１つを選択することができ、または本明細書で説明するように、様々なデータに基づいて動的に選択することができる。
【００８３】
代替要求位置のどれも速くない場合、ステップ７１８で元の要求位置が確認される。代替要求位置がより速い場合、制御はステップ７１４に移り、代替要求位置を含む修正された輸送要求情報がリクエスタに送信される。ステップ７１６で、代替要求位置がリクエスタによって受け入れられたかどうかが判定される。そわない場合、制御はステップ７１８に進み、元の要求位置が確認される。そう場合、制御はステップ７２０に移り、代替要求位置を含む修正された輸送要求情報がリクエスタに送信される。一実施形態では、元の要求位置よりも速い複数の代替要求位置が存在し、リクエスタが１つを拒絶する場合、別の代替要求位置、例えば、元の要求位置よりも速い２番目に速い代替要求位置を、受諾または拒絶のためにリクエスタに提示することができる。
【００８４】
一実施形態ではプロバイダを共有している複数のリクエスタがあってもよく、例えば、リクエスタは目的地に向かうマッチしたプロバイダを有してもよく、目的地へのルートに沿ってピックアップされることを要求する別のリクエスタがピックアップされてもよく、２つのリクエスタは移動のコストを共有する。様々な実施形態は、この概念の修正を含む。例えば、本明細書で説明するように、リクエスタは移動をより短くするために、輸送要求を行い、プロバイダにマッチし、代替の要求位置を受け入れることができる。別のリクエスタは、他のリクエスタの代替要求位置の閾値距離内の要求位置を有する輸送要求を行うことができる。第２のリクエスタが代替要求位置に移動するためのＥＴＴが第１のリクエスタのＥＴＴの閾値時間内であると判定された場合、第２のリクエスタが代替要求位置でピックアップされることを示す修正された輸送情報がプロバイダに送信され得る。例えば、元のリクエスタは、自分の受け入れられた代替要求位置まで歩くのに５分かかることがある。他のリクエスタは、受け入れられた代替リクエスト位置まで歩くのに７分かかることがある。追加の２分が許容可能である場合（例えば、元のリクエスタによって定義され得るように、閾値時間内である場合、または、時間量が閾値時間量に関係なく元のリクエスタによって肯定的に受け入れられる場合など）、プロバイダは元のリクエスタをピックアップした後、他のリクエスタがピックアップ位置（すなわち、代替の要求位置）に到着するのを待つ。
【００８５】
一実施形態では、他のリクエスタが元のリクエスタの目的地とは異なる要求を有する目的地を含むことができる。新しいリクエスタの目的地へのプロバイダのＥＴＤが、元のリクエスタの目的地への１つまたは複数の代替の目的地位置とともに決定される。代替目的地位置の１つから他のリクエスタの目的地へのプロバイダのＥＴＤが決定され、そのＥＴＤが新しいリクエスタの元の目的地への元のＥＴＤよりも小さい場合、代替目的地位置を含む修正された輸送情報がマッチしたプロバイダに送信される。例えば、元のリクエスタは位置Ａに行き、ＥＴＤは５分である。他のリクエスタは位置Ｂに行くことになり、位置Ａから位置Ｂへの移動を含むＥＴＤ（元のリクエスタが最初にドロップオフされているため）は１０分である。位置Ｃが位置Ａの閾値距離内にあること、および位置Ａの代わりに位置Ｃを有する他のリクエスタのＥＴＤが７分であることが決定される。その３分の改善が閾値量内である場合、位置Ｃは、元のリクエスタのためのドロップオフ点として使用される。一実施形態では、元のリクエスタのコンピューティングデバイスが元のリクエスタが位置Ｃから位置Ａに移動するためのＥＴＴと共に、位置Ｃから位置Ａへのナビゲーションルート（例えば、歩行ルート）を含むマッピングデータを表示し、元のリクエスタの変更の受諾または拒否の指示が受信される。
【００８６】
図８は、本技法の実施形態による、要求位置および代替要求位置のピックアップ位置スコアを使用して、要求の修正されたピックアップ位置を決定するための方法８００の例示的な流れ図を示す。ステップ８０２において、動的輸送マッチングシステムの位置評価モジュールは、要求の要求位置を含む輸送要求情報を受信することができる。ライド要求はライド要求の要求位置（すなわち、ピックアップ位置）を含むデータ（例えば、輸送要求情報）を含むことができる。一実施形態では、ライド要求はまた、要求位置に加えて、要求目的地（すなわち、ドロップオフ位置）、要求時間、リクエスタ識別子、リクエスタコンピューティングデバイス位置、および／またはライド要求および／またはリクエスタに関連する任意の他の関連情報を含むことができる。
【００８７】
ステップ８０４で、動的輸送マッチングシステムの位置評価モジュールは、要求位置のピックアップ位置スコアを決定することができる。要求位置のピッキング位置スコア（ＰＬｏＳ）は、動的輸送マッチングシステムの位置評価モジュールによって決定することができる。ＰＬｏＳは要求位置の適合度を示すことができ、適合度はリクエスタとプロバイダとの間のやり取りにとって最適であり、効率的であり、便利であるものとして、位置を任意の客観的な定量的測定値を含む。位置の適合性はプロバイダの効率および生産性を向上させ、動的輸送マッチングシステムの全体的なリソース割振りを向上させながら、リクエスタの待ち時間を短縮することができる。例えば、ピックアップ位置スコアは、道路、ブロック、サブブロック、および／または対応する位置におけるプロバイダによるリクエスタのピックアップの適合性のための位置に対応するマップの任意の他の適切なセグメントを特徴付けることができる。したがって、ピックアップ位置スコアはリクエスタとプロバイダとの間のやり取りのために、領域、道路、ブロック、サブブロックなど内の特に良好な位置を識別するために使用され得る。例えば、特定の交通区域、例えば、任意の時間区域を停止しない区域があってもよく、これは、その位置がピックアップに適しており、かつ便利であるかどうかに影響を及ぼし得る。
【００８８】
様々な実施形態によれば、ピックアップ位置スコアは特定の要求位置におけるマッチしたライドについてのプロバイダとリクエスタとの間の接触率（例えば、ピックアップの前に相手方当事者に接触する要求位置に関連するライドのパーセンテージ）、特定の要求位置について開始されるマッチしたライドについてのプロバイダに対するリクエスタの平均移動距離（例えば、要求位置とリクエスタがピックアップされた実際の位置との間の差）、および／または、要求位置におけるプロバイダによる到着時刻と、マッチしたライドの開始についてのプロバイダへのリクエスタの到着時刻との間で測定される遅延時間（例えば、リクエスタおよびドライバーが互いに見つけるのに要した時間）に基づいてもよい。さらに、要求位置に関連付けられたマッチしたライドのキャンセル率、およびピックアップのための不良位置に関連付けられ得るプロバイダとリクエスタとの間の遅延に関連付けられた任意の他の情報は、位置のためのピックアップ位置スコアを決定する際に使用され得る。さらに、動的輸送マッチングシステムは動的輸送マッチングシステムを介して、リクエスタとプロバイダとの間の要求についてのライド履歴を収集し、集約し、分析することができる。統計およびパターンは、格納されたライド履歴情報を分析することから生成されてもよく、任意の要求位置に適用され得るピックアップ位置スコア（ＰＬｏＳ）モデルを構築するために使用されてもよい。ピックアップ位置スコアは特定の時間（例えば、朝の通勤）中の特定の位置についてのピックアップ位置スコアが別の時間（例えば、午後）中の同じ位置についてのピックアップ位置スコアとは異なり得るように、時間依存であり得る。したがって、格納されたライド履歴は、環境変数に従って、場所のための異なるピックアップ場所スコアを生成するために格納され、使用されてもよい。位置スコアを計算するために使用することができる環境変数は、時間、季節、気象条件、道路条件、および／または交通流および／または位置のピックアップ条件に影響を及ぼすことができる任意の他の変数を含むことができる。
【００８９】
ステップ８０６で、動的輸送マッチングシステムの位置評価モジュールは、ピックアップ位置スコアをピックアップ位置スコア閾値と比較して、ピックアップ位置スコアがピックアップ位置スコア閾値を満たすかどうかを判定することができる。そのピックアップ位置のピックアップ位置スコアがその閾値を満たす場合、その位置は、要求のための適切なピックアップ位置として識別され得る。ピックアップ位置スコア閾値はピックアップ要求位置および目的地への移動時間または到着時間についてピックアップ位置を最適化する際に使用され得る他の潜在的な代替要求位置をフィルタリングするために使用され得るが、ピックアップ位置スコア値は最良の可能な位置を識別するために互いに比較され得ない。代わりに、プロバイダの位置およびナビゲーションルートは、要求のための修正された要求位置として選択される代替ピックアップ位置に影響を及ぼすことができる。ピックアップ位置スコアが閾値を満たす場合、ステップ８２０で、要求位置がプロバイダと確認される。
【００９０】
要求位置のピックアップ位置スコアがピックアップ位置スコア閾値を満たさない場合、制御はステップ８０８に進み、動的輸送マッチングシステムの位置評価モジュールは、代替処理の要求位置が識別されるべきであると判定することができる。したがって、動的輸送マッチングシステムの位置評価モジュールは、要求位置の閾値距離を決定することができる。閾値距離は要求位置からの半径方向距離（例えば、１マイル、２マイル、１０マイル、１５マイルなど）、１つまたは複数の郵便番号または他の地理的識別子（例えば、街路、ブロック、近隣、都市、地域など）、あるいは要求位置に関連する利用可能なプロバイダを識別するための任意の他の適切な地理的制限として識別され得る。
【００９１】
ステップ８１０において、動的輸送マッチングシステムの位置評価モジュールは、要求位置の閾値距離内の少なくとも１つの代替要求位置を決定することができる。要求位置の周りの閾値距離を決定することができ、少なくとも１つの代替要求位置が識別されるように、１セットの代替要求位置を閾値距離内で評価することができる。代替処理の要求位置は、上記の図３および５Ａ〜５Ｄを参照して説明したような任意の適切なプロセスに基づいて、または要求位置の周りの潜在的な位置をサンプリングするための任意の他の適切な方法によって識別され得る。いくつかの実施形態では、少なくとも１つの代替要求位置が少なくとも１つの位置が元のルート上で特定の量だけ、ＥＴＡまたはＥＴＤのうちの１つ、あるいはその両方を低減するかどうかに基づいて決定され得る。
【００９２】
ステップ８１２において、動的輸送マッチングシステムの位置評価モジュールは、少なくとも１つの代替要求位置の各々について位置スコアを決定することができる。要求位置を取り囲む代替要求位置を決定するとき、システムは、代替要求位置に関連するピックアップ位置スコアを決定することができる。代替要求位置に関連付けられたピックアップ位置スコアは、要求のための最良の可能な代替要求位置を決定するために決定され、ランク付けされ得る。
【００９３】
ステップ８１４において、動的輸送マッチングシステムの位置評価モジュールは、少なくとも１つの代替要求位置のピックアップ位置スコアを要求位置スコアと比較して、少なくとも１つの代替要求位置のいずれかが元の要求位置よりも良好な位置スコアを有するかどうかを判定することができる。いくつかの実施形態では、可能な最高のピックアップ位置を要求について決定し、要求の代替要求位置として使用することができる。代替位置スコアが要求位置スコアよりも良好（例えば、高い）である場合、ステップ８１６において、代替位置がリクエスタに送信される。しかしながら、代替位置が元の要求位置よりも悪い（例えば、低い）ピックアップ位置スコアを有する場合、ステップ８２０において、元の要求位置がプロバイダに確認される。
【００９４】
ステップ８１６において、代替位置スコアのいずれかが要求位置スコアよりも良好である場合（例えば、スコアリングが正のスケールに基づく場合、より高いスコア）、動的輸送マッチングシステムの位置評価モジュールは、少なくとも１つの代替リクエスト位置の代替リクエスト位置を動的輸送マッチングシステムに返すことができる。動的輸送マッチングシステムは時間節約および／またはプロバイダとの改善されたやり取り経験のために、リクエスタが要求位置を代替要求位置に移動させる意思があるかどうかに関して、リクエスタによる評価のために、代替要求位置をリクエスタコンピューティングデバイスに送信することができる。
【００９５】
ステップ８１８で、動的輸送マッチングシステムは、代替要求位置が受け入れられるかどうかを判定することができる。リクエスタは修正された要求位置を受け入れるか、または拒否することができ、処理のために動的輸送マッチングシステムに送信される、リクエスタアプリケーションを介したそれらのコンピューティングデバイス上のフィードバックを提供することができる。動的輸送マッチングシステムは、ユーザが変更された要求位置を受け入れたか拒否したかを判定することができる。
【００９６】
ステップ８２０において、リクエスタが変更されたリクエスト位置を拒否したか、または受け入れなかった場合、動的輸送マッチングシステムはプロバイダへの初期リクエスト位置を確認し、および／またはプロバイダコンピューティングデバイスに更新された位置を提供しなくてもよい。しかしながら、いくつかの実施形態では、動的輸送マッチングシステムが元の要求位置の遅延および／または好ましくない条件を最小限に抑えるために、１つまたは複数のアクションを実行することができる。例えば、動的輸送マッチングシステムはプロバイダが位置に到着する前に到着メッセージを送信して、リクエスタがプロバイダをより多く見つけることを可能にし、および／または、位置が遅延に関連付けられていることをリクエスタに警告し、リクエスタがそれらの遅延を最小限に抑えることができる特定の方法（例えば、早く離れる、プロバイダに連絡するなど）をアドバイスすることができる。
【００９７】
ステップ８２２において、リクエスタが変更された要求位置を受け入れた場合、動的輸送マッチングシステムは変更された要求位置へのルーティングおよび輸送のために、変更された要求位置をプロバイダコンピューティングデバイスに送信することができる。
【００９８】
図９は、本技法の実施形態による、最適化されたピックアップ位置を提供するために代替要求位置を識別するフィルタとして位置スコアを使用するための方法９００の例示的な流れ図を示す。図９のステップの多くは、図７および図８のステップと同様である。したがって、異なるステップのみを以下に明示的に説明し、残りのステップに関する追加情報は、少なくとも図７および図８を参照して見出すことができる。
【００９９】
図９のステップ９０２〜９０８は、図７のステップ７０２〜７０８と同様である。ステップ９０２において、動的輸送マッチングシステムの位置評価モジュールは、要求の要求位置を含む輸送要求情報を受信することができる。ステップ９０４において、プロバイダは例えば、輸送要求情報に基づいて、輸送要求にマッチングされる。ステップ９０６において、第１の要求位置の閾値距離が決定される。例えば、要求位置を取り囲む均一な半径を確立することができる。
【０１００】
ステップ９０８において、代替要求位置が決定される。一実施形態では、複数の代替要求位置が例えば、要求位置の閾値距離内で決定される。ステップ９１０において、動的輸送マッチングシステムの位置評価モジュールは、少なくとも１つの代替要求位置の各々について位置スコアを決定することができる。
【０１０１】
ピックアップ位置スコアが最適化されたピックアップ位置を提供するために代替要求位置を識別するためのフィルタとして使用される実施形態によれば、ステップ９１２において、動的輸送マッチングシステムの位置評価モジュールは、少なくとも１つの代替要求位置のピックアップ位置スコアを要求位置スコアと比較して、少なくとも１つの代替要求位置のいずれかが所定の閾値を超えるかどうかを判定することができる。代替位置が有効なピックアップ位置と見なされるように、システムは、代替位置のピックアップ位置スコアが閾値を満たすかどうかを判定する。ピックアップ位置スコアが閾値を満たす場合、代替位置は要求のための適切な代替ピックアップ位置として識別することができ、システムはステップ９１４に続く。しかしながら、代替位置のピックアップ位置スコアが閾値スコアを満たさない場合、システムはステップ９０８に戻り、別の代替要求位置を決定する。システムはシステムがステップ９１４に進むことができる前に、閾値を満たすピックアップ位置スコアを有する代替位置が決定されるまで、ステップ９０８、９１０、および９１２を繰り返すことができる。
【０１０２】
残りのステップ９１４〜９２４は、図７のステップ７１０〜７２０と同様である。ステップ９１４において、リクエスタが元の要求位置から代替要求位置の各々に移動するための推定移動時間（ＥＴＴ）が決定される。ステップ９１６で、代替要求位置のいずれかが目的地へのより効率的なＥＴＤ（例えば、より速い時間、より短いルート、より少ないターン、より少ないトラフィックなど）をもたらすかどうかの判定が行われる。ステップ９１８で、代替要求位置がより高速である場合、代替要求位置を含む修正された輸送要求情報がリクエスタに送信される。代替要求位置のどれも高速でない場合、ステップ９２２で元の要求位置が確認される。ステップ９２０で、代替要求位置がリクエスタによって受け入れられたかどうかが判定される。そわない場合、制御はステップ９２２に進み、元の要求位置が確認される。そう場合、制御はステップ９２４に移り、代替要求位置を含む修正された輸送要求情報がリクエスタに送信される。一実施形態では、元の要求位置よりも速い複数の代替要求位置が存在し、リクエスタが１つを拒絶する場合、別の代替要求位置、例えば、元の要求位置よりも速い２番目に速い代替要求位置を、受諾または拒絶のためにリクエスタに提示することができる。
【０１０３】
図１０は、本技法の実施形態による、最適化されたピックアップ位置を提供するために位置スコアに関連する遅延時間を使用するための方法１０００の例示的な流れ図を示す。図１０のステップの多くは、図７〜９のステップと同様である。したがって、異なるステップのみが以下で明示的に説明され、残りのステップに関する追加情報は、少なくとも図７〜図９を参照して見出すことができる。
【０１０４】
図１０のステップ１００２〜１０１０は、図９のステップ９０２〜９１０と同様である。ステップ１００２において、動的輸送マッチングシステムの位置評価モジュールは、要求の要求位置を含む輸送要求情報を受信することができる。ステップ１００４において、プロバイダは例えば、輸送要求情報に基づいて、輸送要求にマッチングされる。ステップ１００６において、第１の要求位置の閾値距離が決定される。ステップ１００８において、代替要求位置が決定される。一実施形態では、複数の代替要求位置が例えば、要求位置の閾値距離内で決定される。ステップ１０１０において、動的輸送マッチングシステムの位置評価モジュールは、少なくとも１つの代替要求位置の各々について位置スコアを決定することができる。
【０１０５】
最適化されたピックアップ位置を提供するために位置スコアに関連する遅延時間を使用するための一実施形態によれば、ステップ１０１２において、動的輸送マッチングシステムの位置評価モジュールは、代替要求位置のピックアップ遅延を決定することができる。いくつかの要求位置および代替要求位置は、プロバイダが交通、障害物、および／または道路の構成のために、リクエスタの位置およびインターフェースをうまくとることがより困難であり得る。例えば、縁石上に駐車された車を有するにぎやかな街路は、ピックアップ位置のための安全な位置を見つけることが困難であり得る。その結果、リクエスタはプロバイダが駐車するのに安全であった場所を見つけるために、ブロックの周りを歩くことを余儀なくされることがある。これはピックアップやり取りを遅延させ、プロバイダとリクエスタとの間の不必要な通信を必要とし、および／または妥当な位置が見つからないリクエストのキャンセルにつながる可能性がある。したがって、位置評価モジュールは、交通、障害物、道路の構成、および／または環境に関連する他の要因に少なくとも部分的に基づいて、ピックアップ遅延を決定することができる。例えば、他の環境要因は、気象条件、建設迂回、または事故を含むことができる。
【０１０６】
残りのステップ１０１４〜１０２４は、図９のステップ９１４〜９２４と同様である。ステップ１０１４において、リクエスタが元の要求位置から代替要求位置の各々に移動するための推定移動時間（ＥＴＴ）が決定されるが、様々な実施形態では代替要求位置のすべてよりも少ないものが決定の一部である。ステップ１０１６で、代替要求位置のいずれかが、推定されたピックアップ遅延を含めて、目的地へのより効率的なＥＴＤ（例えば、より速い時間、より短いルート、より少ないターン、より少ないトラフィックなど）をもたらすかどうかの判定が行われる。推定されたピックアップ遅延を含む代替要求位置がより速い場合、代替要求位置を含む修正された輸送要求情報が、ステップ１０１８で要求側に送信される。ステップ１０１８で代替要求位置が要求側に送信された後、ステップ１０２０で、要求側が代替要求位置を受け入れるかどうかが判定される。ステップ１０１６において、推定されたピックアップ遅延を含む代替要求位置のいずれも速くない場合、ステップ１０２２において元の要求位置が確認される。ステップ１０２０で、代替要求位置がリクエスタによって受け入れられたかどうかが判定される。受け入れられない場合、制御はステップ１０２２に移り、元の要求位置が確認される。代替要求位置が受け入れられた場合、制御はステップ１０２４に進み、代替要求位置を含む修正された輸送要求情報がリクエスタに送信される。
【０１０７】
本例はオンデマンドライド共有アプリケーションに焦点を当てているが、任意の適切なサービスが同様の機能を使用して実行され得ることに留意されたい。例えば、サービスの配信は、サービスの配信の場所を見つけるために実施される同様のプロセスを有することができる。プロバイダ（自律プロバイダ、人間プロバイダ、または任意の他のタイプのサービスプロバイダ）とリクエスタ（人間、自律、または任意の他のタイプのリクエスタ）との間のやり取りのための適切な位置を見つけることに関連する任意の適切なアプリケーションは、本明細書で説明される実施形態を実装することができる。
【０１０８】
図１１は、様々な実施形態によるリクエスタ／プロバイダ管理環境１１００を示す。図１１に示すように、管理システム１１０２は、リクエスタおよびプロバイダデバイスに様々なサービスを提供するように構成することができる。管理システム１１０２は、アイデンティティ管理サービス１１０４、位置サービス１１０６、ライドサービス１１０８、または他のサービスを含む、１つまたは複数のサービスまたはソフトウェアアプリケーションを実行することができる。管理システム１１０２によって提供されるものとして３つのサービスが示されているが、様々な実装形態ではより多くのまたはより少ないサービスを提供することができる。様々な実施形態では、管理システム１１０２が１つまたは複数の汎用コンピュータ、サーバコンピュータ、クラスタコンピューティングシステム、クラウドベースコンピューティングシステム、または任意の他のコンピューティングシステムまたはコンピューティングシステムの構成を含むことができる。管理システム１１０２は、本明細書で発明される本技法の様々な実施形態に関して発明されるサービスおよび／またはソフトウェアアプリケーションのいずれかまたはすべてを実行するように構成され得る。いくつかの実施形態では、管理システム１１０２が任意の適切なオペレーティングシステム、ならびにコモンゲートウェイインターフェース（ＣＧＩ）サーバ、ＪＡＶＡ（登録商標）サーバ、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバ、ファイル転送プロトコル（ＦＴＰ）サーバ、データベースサーバなどの様々なサーバアプリケーションを実行することができる。
【０１０９】
アイデンティティ管理サービス１１０４は管理システム１１０２とやり取りするときに、リクエスタおよびプロバイダのためのアクセス管理および許可サービスなど、様々なアイデンティティサービスを含むことができる。これは、例えば、プロバイダのアイデンティティを認証することと、プロバイダが管理システム１１０２を介してサービスを提供することを許可されていることを決定することとを含むことができる。同様に、リクエスタのアイデンティティを認証して、リクエスタが管理システム１１０２を介して要求されたサービスを受信することを許可されているかどうかを判定することができる。アイデンティティ管理サービス１１０４は、運転履歴および／またはライド履歴、個人データ、または他のユーザデータなど、管理システム１１０２によって維持されるプロバイダおよびリクエスタデータへのアクセスを制御することもできる。位置サービス１１０６は、ナビゲーションおよび／または交通管理サービスおよびユーザインターフェース、または他の位置サービスを含むことができる。
【０１１０】
様々な実施形態では、ライドサービス１１０８がリクエスタをプロバイダに接続するためのライドマッチングおよび管理サービスを含むことができる。ライドサービス１１０８はユーザインターフェースを含むことができ、および／または、それぞれのデバイス上で実行されるアプリケーションを介してリクエスタおよびプロバイダからデータを受信することができる。ライドサービス１１０８は例えば、アイデンティティ管理サービス１１０４を使用してリクエスタおよびプロバイダのアイデンティティを確認し、各ユーザがリクエストされたライドサービスに対して許可されていることを決定することができる。いくつかの実施形態では、ライドサービス１１０８が例えば、最も近いプロバイダを識別するために、リクエスタおよび位置サービス１１０６から取得された位置を使用して、適切なプロバイダを識別することができる。したがって、ライドサービス１１０８は、本明細書で説明される実施形態とマッチして、プロバイダおよびリクエスタリソースの配布および割り振りを管理することができる。
【０１１１】
管理システム１１０２は、ネットワーク１１１０および１１１２を介して様々なデバイスに接続することができる。ネットワーク１１１０、１１１２は、ＡｐｐｌｅＴａｌｋ、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、インターネットパケット交換（ＩＰＸ）、システムネットワークアーキテクチャ（ＳＮＡ）などの様々な通信プロトコルを使用してデータ通信を送受信するように構成された任意のネットワークを含むことができる。いくつかの実施形態ではネットワーク１１１０、１１１２はイーサネット（登録商標）、トークンリング、または他のＬＡＮなどのローカルエリアネットワーク（ＬＡＮ）を含むことができる。ネットワーク１１１０、１１１２は、広域ネットワークおよび／またはインターネットを含むことができる。いくつかの実施形態ではネットワーク１１１０、１１１２はＶＰＮ（仮想プライベートネットワーク）、ＰＳＴＮ（公衆交換電話ネットワーク）、赤外線ネットワーク、またはＩＥＥＥ８０２．１１ファミリーの規格、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標)Ｌｏｗ  Ｅｎｅｒｇｙ、ＮＦＣ、および／または任意の他の無線プロトコルを実装するネットワークを含む任意の無線ネットワークを含むことができる。様々な実施形態ではネットワーク１１１０、１１１２はモバイル電話ネットワーク、セルラネットワーク、衛星ネットワーク、または他のモバイルネットワークなどのモバイルネットワークを含むことができる。ネットワーク１１１０、１１１２は、図１の通信ネットワーク１７０と同じであってもよい。いくつかの実施形態では、ネットワーク１１１０、１１１２はそれぞれ、本明細書で説明されるネットワークの組合せ、または当業者に知られている他のネットワークを含むことができる。
【０１１２】
次いで、ユーザは、プロバイダデバイスおよびリクエスタデバイス上で実行されるアプリケーションを使用して、管理システム１１０２によって提供される１つまたは複数のサービスを利用することができる。図１１に示すように、プロバイダコンピューティングデバイス１１１４、１１１６、１１１８、および／または１１２０はモバイルデバイス（例えば、ｉＰｈｏｎｅ（登録商標）、ｉＰａｄ（登録商標）、モバイル電話、タブレットコンピュータ、携帯情報端末（ＰＤＡ））、ウェアラブルデバイス（例えば、ヘッドマウントディスプレイなど）、シンクライアントデバイス、ゲームコンソール、または１つまたは複数のネットワーク１１１０、１１１２を介して通信するように構成された他のデバイスを含むことができる。各プロバイダまたはリクエスタ装置は各種オペレーティングシステム（例えば、Ａｎｄｒｏｉｄ、ｉＯＳなど）を実行することができ、インターネット、Ｂｌａｃｋｂｅｒｒｙ（登録商標）メッセンジャ、ショートメッセージサービス（ＳＭＳ）、メール送信、ならびに各種他のメッセージングアプリケーションおよび／または通信プロトコルを介して通信するように構成される。リクエスタおよびプロバイダコンピューティングデバイスは汎用コンピュータ（例えば、パーソナルコンピュータ、ラップトップコンピュータ、またはｍａｃＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、各種ＵＮＩＸ（登録商標）、もしくはＵＮＩＸ（登録商標）またはＬｉｎｕｘベースのオペレーティングシステム、または他のオペレーティングシステムなどのオペレーティングシステムを実行する他のコンピューティングデバイス）を含むことができる。いくつかの実施形態では、プロバイダコンピューティングデバイス１１１４が車両ナビゲーションシステムなどの車両統合コンピューティング装置、または車両自体と統合された他のコンピューティングデバイスを含むことができる。
【０１１３】
いくつかの実施形態では、プロバイダコンピューティングデバイス１１１８がドライバー、乗客、歩行者、および他のユーザなどのユーザと通信するように構成されたプロバイダ通信デバイスを含むことができる。いくつかの実施形態では、プロバイダ通信デバイス１１１８が管理システム１１０２と直接、またはプロバイダコンピューティングデバイス１１１６などの別のプロバイダコンピューティングデバイスを介して通信することができる。いくつかの実施形態では、リクエスタコンピューティングデバイスがピアツーピア接続、Ｂｌｕｅｔｏｏｔｈ接続、ＮＦＣ接続、アドホック無線ネットワーク、または任意の他の通信チャネルまたは接続を介してプロバイダ通信デバイス１１１８と直接通信する１１２６ことができる。特定のデバイスはネットワーク１１１０および１１１２を介して管理システム１１０２と通信するものとして示されているが、各種実施形態では管理システム１１０２がエンドユーザと管理システム１１０２との間の媒介として働くことができる各種サードパーティを可能にするために、アプリケーションプログラミングインターフェース（ＡＰＩ）またはサービスプロバイダインターフェイス（ＳＰＩ）などのインターフェースを公開することができる。
【０１１４】
リクエスタ／プロバイダ管理環境１１００は４つのプロバイダデバイスおよび２つのリクエスタデバイスと共に示されているが、任意の数のデバイスをサポートすることができる。本明細書で示され、説明される様々な構成要素は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実装され得る。リクエスタ／プロバイダ管理環境の１つの実施形態が図１１に示されているが、これは単に１つの実施例に過ぎず、限定を意味するものではない。
【０１１５】
図１２は、様々な実施形態による、データ収集およびアプリケーション管理環境１２００を示す。図１２に示されるように、管理システム１２０２は、データ収集インターフェース１２０６を介して各種データ収集デバイス１２０４からデータを収集するように構成され得る。上述のように、管理システム１２０２は、１つまたは複数のコンピュータおよび／またはサーバ、あるいはそれらの任意の組合せを含むことができる。データ収集デバイス１２０４はユーザデバイス（上述したようなプロバイダおよびリクエスタコンピューティングデバイスを含む）、プロバイダ通信デバイス、ラップトップまたはデスクトップコンピュータ、車両データ（例えば、車両に統合された、またはそわなければ車両に接続されたセンサからの）、地上ベースまたは衛星ベースの電源（例えば、位置データ、交通データ、気象データなど）、または他のセンサデータ（例えば、道路埋め込みセンサ、交通センサなど）を含むことができるが、これらに限定されない。データ収集インターフェース１２０６は例えば、各データ収集デバイスのためのインターフェースをサポートするように構成された拡張可能な装置フレームワークを含むことができる。様々な実施形態では、データ収集インターフェース１２０６が新しいデータ収集デバイスが解放されるときにそれらをサポートするように、および／または既存のデータ収集デバイスに対する変更をサポートするために既存のインターフェースを更新するように拡張することができる。様々な実施形態では、データ収集デバイスが１つまたは複数のネットワークを介してデータ収集インターフェース１２０６と通信することができる。ネットワークは、上述のネットワークを含む、当業者によって認識されるような任意のネットワークまたは通信プロトコルを含むことができる。
【０１１６】
図１２に示すように、データ収集デバイス１２０４から受信したデータは、データ記憶装置１２０８に記憶することができる。データストア１２０８は、データベース、オブジェクトストレージシステムおよびサービス、クラウドベースのストレージサービス、ならびに他のデータストアなどの１つまたは複数のデータストアを含むことができる。例えば、履歴データストア１２１０、ライドデータストア１２１２、およびユーザデータストア１２１４などの、管理システム１２０２にアクセス可能な一時的でない記憶媒体上に、様々なデータストアを実装することができる。データストア１２０８は管理システム１２０２に対してローカルであってもよく、あるいは上述のネットワーク、ストレージ領域ネットワーク、または他のネットワーク化されたストレージシステムなどのネットワークを介してリモートでアクセス可能であってもよい。各種実施形態では、履歴データ１２１０が各種データ収集デバイスから受信された所与の１つまたは複数の領域に関する、履歴交通データ、気象データ、要求データ、道路状態データ、または任意の他のデータを含むことができる。ライドデータ１２１２はルートデータ、リクエストデータ、タイミングデータ、および他のライド関連データを、集合的に、および／またはリクエスタまたはプロバイダによって含むことができる。ユーザデータ１２１４は、ユーザアカウントデータ、プリファレンス、位置履歴、および他のユーザ固有データを含むことができる。特定のデータ保存が示されているが、本明細書で説明される様々な実施形態に従って収集および／または格納された任意のデータを、データ保存１２０８に格納することができる。
【０１１７】
図１２に示すように、アプリケーションインターフェース１２１６は各種アプリケーション１２１８が管理システム１２０２を介して利用可能なデータおよび／またはサービスにアクセスすることを可能にするために、管理システム１２０２によって提供することができる。アプリ１２１８は様々なユーザデバイス（上述したようなプロバイダおよびリクエスタコンピューティングデバイスを含む）上で実行することができ、および／または様々なデバイス（例えば、コンピュータ、サーバ、またはそれらの組合せ）にわたって実行するように構成されたクラウドベースまたは他の分散アプリを含むことができる。アプリ１２１８は例えば、データ１２０８を利用して様々なサービス（例えば、サードパーティのライド要求および管理アプリ）を提供することができる集約および／または報告アプリを含むことができる。様々な実施形態では、アプリケーションインターフェース１２１６がアプリケーション１２１８のサードパーティ開発を可能にするＡＰＩおよび／またはＳＰＩを含むことができる。いくつかの実施形態では、アプリケーションインターフェース１２１６が管理システム１２０２によって提供されるデータ１２０８および／またはサービスへのウェブベースのアクセスを可能にするウェブインターフェースを含むことができる。様々な実施形態では、アプリケーション１２１８が１つまたは複数のネットワークを介してアプリケーションインターフェース１２１６と通信するように構成されたデバイス上で実行することができる。ネットワークは、本開示の実施形態に従って、上記で論じたネットワークを含む、当業者によって認識されるような任意のネットワークまたは通信プロトコルを含むことができる。
【０１１８】
環境１２００の特定の実施例が図１２に示されているが、これは例示の目的のためだけであり、限定されることを意図していない。いくつかの実施形態では、環境１２００が当業者によって認識されるように、より少ないまたはより多い構成要素を含んでもよい。
【０１１９】
図１３Ａ〜図１３Ｃは、様々な実施形態による例示的なプロバイダ通信デバイス１３００を示す。図１３Ａに示すように、プロバイダ通信デバイス１３００の正面図１３０２は、正面ディスプレイ１３０４を示す。いくつかの実施形態では、フロントディスプレイ１３０４が二次領域または別個のディスプレイ１３０６を含むことができる。図１３Ａに示すように、フロントディスプレイは１つまたは複数の液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）の１つまたは複数のアレイ、または他のディスプレイ技術を含むが、これらに限定されない、様々なディスプレイ技術を含むことができる。いくつかの実施形態では、フロントディスプレイがディスプレイを複数の領域に分割するカバーを含むことができる。いくつかの実施形態では、別個のディスプレイを各領域に関連付けることができる。フロントディスプレイ１３０４は、プロバイダ車両の外部のリクエスタおよび他のユーザに色、パターン、色パターン、または他の識別情報を示すように構成することができる。いくつかの実施形態では、二次領域または別個のディスプレイ１３０６がフロントディスプレイ１３０４と同じまたは対照的な情報を表示するように構成されてもよい。
【０１２０】
図１３Ｂに示すように、プロバイダ通信デバイス１３００の背面図１３０８は、リアディスプレイ１３１０を示す。リアディスプレイ１３１０はフロントディスプレイ１３０４と同様に、リアディスプレイ１３１０は１つ以上の液晶ディスプレイ（ＬＣＤ）、１つ以上の発光ダイオード（ＬＥＤ）のアレイ、またはその他の表示技術を含むが、これらに限定されない様々な表示技術を含むことができる。リアディスプレイは、プロバイダ、リクエスタ、またはプロバイダ車両内部の他のユーザに情報を表示するように構成されてもよい。いくつかの実施形態では、リアディスプレイ１３１０がプロバイダ車両の背後に位置するプロバイダ車両の外部のユーザに情報を提供するように構成されてもよい。図１３Ｂにさらに示されるように、プロバイダ通信デバイスは、プロバイダ通信デバイスをオンまたはオフにするために使用され得る電源ボタン１３１２または他のスイッチを含み得る。様々な実施形態では、電源ボタン１３１２が電力がプロバイダ通信デバイス１３００に提供されるかどうかを物理的に制御するハードウェアボタンまたはスイッチであってもよい。あるいは、電源ボタン１３１２がソフトウェアおよび／またはファームウェア命令によって管理される起動／シャットダウン手順を開始するソフトボタンであってもよい。いくつかの実施形態では、プロバイダ通信デバイス１３００が電源ボタン１３１２を含まなくてもよい。さらに、プロバイダ通信装置は、プロバイダ通信装置１３００に隣接する領域を照明するように構成された１つまたは複数の光特徴１３１４（１つまたは複数のＬＥＤまたは他の光源など）を含むことができる。いくつかの実施形態では、プロバイダ通信デバイス１３００がプロバイダコンピューティングデバイスがプロバイダ通信デバイス１３００に接続されることを可能にするためのコネクタを含むことができる。いくつかの実施形態では、電力がコネクタ１３１６を介してプロバイダ通信デバイスに提供されてもよい。
【０１２１】
図１３Ｃは、プロバイダコンピューティングデバイス１３００のブロック図を示す。図１３Ｃに示すように、プロバイダ通信デバイスは、プロセッサ１３１８を含むことができる。プロセッサ１３１８は、リアディスプレイ１３１０およびフロントディスプレイ１３０４に表示される情報を制御することができる。上述のように、各ディスプレイは、ユーザおよびプロバイダ通信デバイスの位置に応じて、異なるユーザに情報を表示することができる。いくつかの実施形態では、ディスプレイデータ１３２０が記憶された表示パターン、シーケンス、色、テキスト、またはフロントおよび／またはリアディスプレイ上に表示される他のデータを含むことができる。いくつかの実施形態では、ディスプレイデータ１３２０が接続されたプロバイダコンピューティングデバイスから受信されたときに表示データを記憶するバッファとすることができる。いくつかの実施形態では、ディスプレイデータ１３２０がハードディスクドライブ、ソリッドステートドライブ、メモリ、または管理システムからの情報を含む他の記憶デバイスを含むことができる。いくつかの実施形態では、照明コントローラ１３２２が光特徴１３１４によって表示される色および／または他の光を管理することができる。いくつかの実施形態では、通信コンポーネント１３２４がプロバイダ通信デバイス１３００と１つまたは複数のネットワーキングコンポーネントまたは他のコンピューティングデバイスとの間のネットワーキングまたは他の通信を管理することができる。種々の実施形態において、通信コンポーネント１３２４は、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣ、ＲＦ、または他の有線または無線の通信ネットワークまたはプロトコルを通して通信するように構成され得る。いくつかの実施形態では、プロバイダ通信デバイス１３００が表示部を介して提供される出力に加えて出力を提供し、かつ／またはユーザから入力を受信するように構成された入力／出力システム１３２６を含むことができる。例えば、Ｉ／Ｏシステム１３２６は、ユーザからのモーションまたはジェスチャベースの入力を認識するように構成された画像キャプチャデバイスを含むことができる。それに加えて、またはその代わりに、Ｉ／Ｏシステム１３２６はユーザにオーディオ出力（警告、命令、または他の情報など）を提供し、かつ／または音声認識システムまたは他のコマンドインターフェースによって解釈され得るオーディオコマンドなどのオーディオ入力を受信するように構成されたオーディオデバイスを含むことができる。いくつかの実施形態では、Ｉ／ＯシステムがＵＳＢ(ユニバーサルシリアルバス）ポート、ライトニングコネクタポート、またはユーザが自分のデバイスをプロバイダ通信デバイスに直接接続すること（例えば、データを交換すること、識別情報を検証すること、電力を供給することなど）を可能にする他のポートなど、１つまたは複数の入力ポートまたは出力ポートを含むことができる。
【０１２２】
図１４は、様々な実施形態による例示的なコンピュータシステム１４００を示す。様々な実施形態では、コンピュータシステム１４００を使用して、本明細書で説明するシステム、装置、または方法のいずれかを実装することができる。いくつかの実施形態ではコンピュータシステム１４００がモバイルデバイス、タブレットコンピューティングデバイス、ウェアラブルデバイス、パーソナルまたはラップトップコンピュータ、車両ベースのコンピューティングデバイス、または本明細書で説明される他の装置またはシステムを含むが、これらに限定されない、本明細書で説明される様々な装置のいずれかに対応し得る。図１４に示すように、コンピュータシステム１４００は、バス１４０２によって接続された様々なサブシステムを含むことができる。サブシステムは、Ｉ／Ｏデバイスサブシステム１４０４、ディスプレイデバイスサブシステム１４０６、および１つまたは複数のコンピュータ可読記憶媒体１４０８を含む記憶サブシステム１４１０を含むことができる。サブシステムはまた、メモリサブシステム１４１２、通信サブシステム１４２０、および処理サブシステム１４２２を含むことができる。
【０１２３】
システム１４００では、バス１４０２が様々なサブシステム間の通信を容易にする。単一のバス１４０２が示されているが、代替処理のバス構成を使用することもできる。バス１４０２は当業者に知られているような通信を容易にするために、任意のバスまたは他の構成要素を含むことができる。そのようなバスシステムの例は、ローカルバス、パラレルバス、シリアルバス、バスネットワーク、および／またはバスコントローラによって調整される複数のバスシステムを含むことができる。バス１４０２は、パラレルＡＴＡ、シリアルＡＴＡ、ＩＳＡ（Industry Standard Architecture）バス、ＥＩＳＡ（Extended ISA）バス、ＭＣＡ（MicroChannel Architecture）バス、ＰＣＩ（Peripheral Component Interconnect）バス、または当技術分野で知られている任意の他のアーキテクチャまたは規格などの様々な規格を実装する１つまたは複数のバスを含むことができる。
【０１２４】
いくつかの実施形態では、Ｉ／Ｏデバイスサブシステム１４０４がそのようなデバイスと通信するための様々な入力デバイスおよび／または出力デバイスまたはインターフェースを含むことができる。そのようなデバイスはタッチスクリーンまたは他のタッチセンシティブ入力デバイス、キーボード、マウス、トラックボール、モーションセンサまたは他の移動ベースのジェスチャ認識デバイス、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、音声コマンドを受信するように構成されたオーディオ認識デバイス、マイクロフォン、目の動きまたは瞬きに基づいてコマンドを認識するように構成された目の活動モニタなどの画像キャプチャベースのデバイス、および他のタイプの入力デバイスを含むことができるが、これらに限定されない。Ｉ／Ｏデバイスサブシステム１４０４はまた、指紋スキャナ、声紋スキャナ、虹彩スキャナ、または他のバイオメトリックセンサもしくは検出器などの識別装置または認証装置を含み得る。様々な実施形態では、Ｉ／Ｏ装置サブシステムがスピーカ、メディアプレーヤ、または他の出力装置などのオーディオ出力装置を含むことができる。
【０１２５】
コンピュータシステム１４００は、ディスプレイデバイスサブシステム１４０６を含むことができる。ディスプレイデバイスサブシステムは、１つまたは複数の発光ダイオード（ＬＥＤ）、ＬＥＤアレイ、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイまたは他のフラットスクリーンディスプレイ、タッチスクリーン、ヘッドマウントディスプレイまたは他のウェアラブルディスプレイデバイス、投影デバイス、陰極線管（ＣＲＴ）、および情報を視覚的に伝達するように構成された任意の他のディスプレイ技術などの１つまたは複数のライトを含むことができる。様々な実施形態では、ディスプレイデバイスサブシステム１４０６が上述のディスプレイ技術のいずれかなどの外部ディスプレイを制御および／または通信するためのコントローラおよび／またはインターフェースを含むことができる。
【０１２６】
図１４に示すように、システム１４００は、ハードディスクドライブ、ソリッドステートドライブ（ＲＡＭベースおよび／またはフラッシュベースのＳＳＤを含む）、または他の記憶装置などの各種コンピュータ可読記憶媒体１４０８を含む記憶サブシステム１４１０を含むことができる。様々な実施形態では、コンピュータ可読記憶媒体１４０８が本明細書で説明される機能を提供するためにプロセッサによって実行可能な、プログラム、コード、または他の命令を含むソフトウェアを記憶するように構成され得る。いくつかの実施形態では、記憶システム１４１０が各種データ保存またはリポジトリを含むことができ、あるいは本明細書で説明する実施形態で使用されるデータを保存する各種データ保存またはリポジトリとインターフェースすることができる。そのようなデータストアは、データベース、オブジェクトストレージシステムおよびサービス、データレークまたは他のデータウェアハウスサービスまたはシステム、分散データストア、クラウドベースのストレージシステムおよびサービス、ファイルシステム、および任意の他のデータストレージシステムまたはサービスを含むことができる。いくつかの実施形態では、ストレージシステム１４１０が１つまたは複数の外部および／または取り外し可能ストレージデバイスと通信するために、メディアリーダ、カードリーダ、または他のストレージインターフェースを含むことができる。様々な実施形態では、コンピュータ可読記憶媒体１４０８が任意の適切な記憶媒体または記憶媒体の組合せを含むことができる。例えば、コンピュータ可読記憶媒体１４０８はランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電子的消去可能プログラマブルＲＯＭ(ＥＥＰＲＯＭ)、フラッシュメモリまたは他のメモリ技術、光ストレージ（例えば、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、ブルーレイ（登録商標）ディスクまたは他の光ストレージデバイス）、磁気ストレージ（例えば、テープドライブ、カセット、磁気ディスクストレージまたは他の磁気ストレージデバイス）のうちの任意の１つまたは複数を含むことができるが、これらに限定されない。いくつかの実施形態では、コンピュータ可読記憶媒体がデータ信号、またはデータを送信および／または受信することができる任意の他の媒体を含むことができる。
【０１２７】
メモリサブシステム１４１２は、ＲＡＭ、ＲＯＭ、フラッシュメモリ、または他のメモリを含む様々なタイプのメモリを含むことができる。メモリ１４１２は、ＳＲＡＭ(スタティックＲＡＭ）またはＤＲＡＭ(ダイナミックＲＡＭ）を含むことができる。いくつかの実施形態ではメモリ１４１２がＢＩＯＳ(基本入出力システム）、または例えば、起動中に様々なコンポーネントの初期化を管理するように構成された他のファームウェアを含むことができる。図１４に示すように、メモリ１４１２は、アプリケーション１４１４およびアプリケーションデータ１４１０を含むことができる。アプリケーション１４１４は、プロセッサによって実行することができるプログラム、コード、または他の命令を含むことができる。アプリケーション１４１４は、ブラウザクライアント、位置管理アプリケーション、ライド管理アプリケーション、データ管理アプリケーション、および任意の他のアプリケーションなどの様々なアプリケーションを含むことができる。アプリケーションデータ１４１６は、アプリケーション１４１４によって生成および／または消費される任意のデータを含むことができる。メモリ１４１２は、ＭａｃＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、各種ＵＮＩＸ（登録商標）、ＵＮＩＸ（登録商標）またはＬｉｎｕｘ（登録商標）ベースのオペレーティングシステム、または他のオペレーティングシステムなどのオペレーティングシステム１４１８をさらに含むことができる。
【０１２８】
システム１４００はまた、システム１４００と様々な外部コンピュータシステムおよび／またはネットワーク（インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、モバイルネットワーク、または任意の他のネットワークなど）との間の通信を容易にするように構成された通信サブシステム１４２０を含むことができる。通信サブシステム１４２０は無線ネットワーク、モバイルまたはセルラー音声および／またはデータネットワーク、ＷｉＦｉネットワーク、または他の無線通信ネットワークを介した通信を容易にするために、各種有線（イーサネット（登録商標）または他の有線通信技術など）または無線トランシーバなどのワイヤレス通信チャネルを介した通信を可能にするためのハードウェアおよび／またはソフトウェアを含むことができる。例えば、通信ネットワークは、図１に通信ネットワーク１７０として示されている。さらに、または代替として、通信サブシステム１４２０は、ＧＰＳ(全地球測位システム）などの衛星ベースまたは地上ベースの位置サービスと通信するためのハードウェアおよび／またはソフトウェアコンポーネントを含むことができる。いくつかの実施形態では、通信サブシステム１４２０が各種ハードウェアまたはソフトウェアセンサを含むか、またはそれらとインターフェースすることができる。センサは、通信サブシステム１４２０を介してコンピュータシステムに連続的または／および周期的なデータまたはデータストリームを提供するように構成されてもよい。
【０１２９】
図１４に示すように、処理システム１４２２は、コンピューティングシステム１４００を制御するように動作可能な１つまたは複数のプロセッサまたは他のデバイスを含むことができる。そのようなプロセッサは、中央処理ユニット（ＣＰＵ）、グラフィカル処理ユニット（ＧＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、または任意の他の一般化されたもしくは特殊化されたマイクロプロセッサもしくは集積回路を含むことができるシングルコアプロセッサ１４２４、マルチコアプロセッサを含むことができる。プロセッサ１４２４および１４２６など、処理システム１４２２内の様々なプロセッサを、アプリケーションに応じて、独立して、または組み合わせて使用することができる。
【０１３０】
様々な他の構成を使用することもでき、ハードウェアで実施されるものとして示されている特定の要素は、代わりにソフトウェア、ファームウェア、またはそれらの組合せで実施することができる。当業者は、本明細書に記載される特定の実施形態に対する様々な代替物を認識するのであろう。
【０１３１】
本明細書および図面は、説明および例示を容易にするために提供され、限定することを意図しない特定の実施形態を説明する。実施形態は、本開示の精神および範囲から逸脱することなく、様々な環境で使用されるように実装され得る。
【０１３２】
開示された実施形態を説明する文脈（特に、以下の特許請求の範囲の文脈）における用語「ａ」および「ａｎ」および「ｔｈｅ」ならびに同様の指示対象の使用は本明細書中で別段の指示がない限り、または文脈によって明らかに矛盾しない限り、単数および複数の両方を包含すると解釈されるべきである。語句「備える(comprising)」、「有する(having)」、「含む(including)」および「包含する(containing)」は特に断りのない限り、オープンエンドターム（すなわち「〜を含むが限定しない(including, but not limited to)」という意味）として解釈される。用語「接続された(connected)」は、何かが介在している場合であっても、部分的にまたは全体的に内部に含まれる、取り付けられる、または一緒に結合されるものとして解釈されるべきである。本明細書中の値の範囲の記載は本明細書中で別段の指示がない限り、単に、範囲内に入る各別個の値を個々に言及する簡潔な方法としての役割を果たすことを意図し、各別個の値はあたかも本明細書中に個々に列挙されたかのように、本明細書中に組み込まれる。本明細書で記載した全ての方法は本明細書に別段の指示がない限り、或いは明らかに文脈に矛盾しない限り、任意の好適な順序で実行され得る。本明細書で提供される任意のおよびすべての例、または例示的な言語（例えば、「のよう(such as)」）の使用は単に、本開示の実施形態をより明確にすることを意図しており、特に主張されない限り、本開示の範囲に対する限定を提示するものではない。本明細書中のいかなる言語も、本開示の実施に不可欠であるとして特許請求されていない要素を示すものと解釈されるべきではない。
【０１３３】
語句「Ｘ、Ｙ、またはＺのうちの少なくとも１つ」などの離接語は特に別段の指定がない限り、項目、用語などがＸ、Ｙ、またはＺ、あるいはそれらの任意の組合せ（たとえば、Ｘ、Ｙ、および／またはＺ）であり得ることを提示するために一般に使用される文脈内で理解されることが意図される。したがって、そのような離接語は一般に、特定の実施形態が、Ｘ、Ｙのうちの少なくとも１つ、またはＺのうちの少なくとも１つのうちの少なくとも１つがそれぞれ存在することを必要とすることを意図せず、暗示するべきではない。
【０１３４】
本開示の好ましい実施形態は、本開示を実行するために発明者に知られている最良の形態を含めて、本明細書に記載されている。これらの好ましい実施態様の変形は、上述の記載を読めば当業者には明らかとなり得る。本発明者らは当業者がそのような変形を適切に使用することを期待し、本発明者らは、本明細書に具体的に記載される以外の方法で本開示が実施されることを意図する。したがって、本開示は、適用法で許可されるように、本明細書に添付された特許請求の範囲に列挙された主題のすべての修正および同等物を含む。さらに、そのすべての可能な変形における上述の要素の任意の組み合わせは、本明細書で特に明記しない限り、または文脈により明らかに矛盾しない限り、本開示に含まれる。
【０１３５】
本明細書に引用される出版物、特許出願、および特許を含むすべての文献は、各文献が個別にかつ具体的に参照により組み込まれることが示され、その全体が本明細書に示されるのと同程度に参照により組み込まれる。
【図１】
2020520010.tif 000003
【図２Ａ】
2020520010.tif 000004
【図２Ｂ】
2020520010.tif 000005
【図２Ｃ】
2020520010.tif 000006
【図３】
2020520010.tif 000007
【図４Ａ】
2020520010.tif 000008
【図４Ｂ】
2020520010.tif 000009
【図５Ａ】
2020520010.tif 000010
【図５Ｂ】
2020520010.tif 000011
【図５Ｃ】
2020520010.tif 000012
【図５Ｄ】
2020520010.tif 000013
【図６】
2020520010.tif 000014
【図７】
2020520010.tif 000015
【図８】
2020520010.tif 000016
【図９】
2020520010.tif 000017
【図１０】
2020520010.tif 000018
【図１１】
2020520010.tif 000019
【図１２】
2020520010.tif 000020
【図１３Ａ】
2020520010.tif 000021
【図１３Ｂ】
2020520010.tif 000022
【図１３Ｃ】
2020520010.tif 000023
【図１４】
2020520010.tif 000024
【国際調査報告】
2020520010.tif 000025
2020520010.tif 000026
2020520010.tif 000027