JP2019500681A - シェアされた輸送のための方法およびシステム - Google Patents

Abstract

輸送手配システムは、乗客から輸送シェア要求を受信し得るサービスを提供するよう動作する。輸送シェア要求は、乗車位置および降車位置を含む１組のパラメータを指定し得る。乗車位置に対する近さの基準を含む１以上の基準を満たす輸送提供者の候補セットが識別される。乗客に対して輸送シェアを提供するための、運転手の候補セットのうちの１名の運転手が選択される。選択は、候補セットの個々の運転手のうちのどの運転手が、乗客についての予測送迎完了時間に関する第１の制約を含む１以上の制約を満たすかを決定することに少なくとも部分的に基づき得る。

Description

関連出願

本願は、２０１５年１１月１６日に出願された米国特許出願第１４／９４２，３６１号による利益を主張するものであり、上記出願の全体を参照するとて本明細書に組み込む。

本発明は、シェアされた輸送のための方法およびシステムに関する。

輸送サービスは、特に、場所から独立したサービスの発展と共に、ますます多様且つ一般的になっている。多くのそのようなサービスは、個々のユーザがオンデマンドで輸送を要求することを可能にする。例えば、現在では、車輌の運転手が、輸送シェアリングの手配における他の潜在的な乗客に対する輸送、並びに、荷物、品物、および／または調理された食品の配達を提供することを可能にする輸送サービスが存在している。

シェアされた輸送サービスを提供するための例示的な輸送手配システムを示す ライドシェアを手配するための輸送手配サービスの一例を示す 輸送手配システムと共に用いられる例示的なモバイルコンピューティング装置を示す １以上の実施形態による、輸送手配システムの論理的アーキテクチャを示す シェアされた輸送サービスを提供するための例示的なインターフェースを示す シェアされた輸送サービスを提供するための例示的なインターフェースを示す 輸送シェア提供者と輸送シェア要求とをマッチングするための例示的な方法を示す 所与の送迎についての送迎完了時間を予測するための例示的な方法を示す

複数の例によれば、輸送手配システムは、乗客から輸送シェア要求を受信し得るサービスを提供するよう動作する。輸送シェア要求は、乗車位置および降車位置を含む１組のパラメータを指定し得る。乗車位置に対する近さの基準を含む１以上の基準を満たす輸送提供者の候補セットが識別される。乗客に輸送シェアを提供するための、運転手の候補セットのうちの１つの候補が選択される。選択は、候補セットの個々の運転手のうちのどの運転手が、乗客についての予測送迎完了時間に関する第１の制約を含む１以上の制約を満たすかを決定することに少なくとも部分的に基づき得る。

記載される例を参照すると、輸送シェアサービス（「ライドシェア」として参照される場合もある）は、異なる乗車位置と降車位置との間において複数の乗客を輸送するサービスを指す。しかし、本願の目的で、輸送シェアサービスには、従来の手法（例えば、バス輸送）とは対照的に、予め設定された乗車位置または降車位置はなく、予め設定された移動ルートさえもない。むしろ、輸送シェアサービスは、少なくとも２つのクラスのユーザ、即ち、運転手クラスユーザと乗客クラスユーザとを有して実装され、その両方が、仲介するコンピュータシステムの技術的機能性およびサービスを共に利用する。仲介するコンピュータシステムの統合により、複数の例は、乗客が、設定された乗車位置または時間を持たず、運転手が、運転手の履歴パターンまたは経験から推定され得る範囲を超えた乗車位置を予め知らない、その場その場の輸送シェアサービスを可能にする。

更に、複数の例は、都会の環境、公開イベント、建設、緊急事態、および様々な他の事象が、乗客の需要および運転手の利用可能性を変え得ることを認識したものである。より詳細に説明するように、複数の例は、サービスのユーザがより効果的に輸送を受けるまたは提供するために用い得る情報に関して動的な輸送手配システムを提供する。

多くの例において、輸送シェアサービス（或いは、「ライドシェアサービス」または「ライドシェア」として参照される）は、運転手クラスユーザが、第１の乗客を第１の乗車位置において乗車させて第１の降車位置まで輸送するよう車輌を操作しており、第１の乗客の送迎の進行中に、運転手が、第２の乗客を乗車させて第２の降車位置まで輸送する要求を受信するよう、実装され得る。運転手は第２の乗客を乗車させ、車輌内には、２名の乗客のうちの１名が車輌から離れるまで、少なくとも或る持続時間にわたって第１の乗客および第２の乗客が一緒に存在する。その結果、ライドシェアにおいて、車輌内での時間が重なる少なくとも２名の乗客が存在し、各乗客が自分の乗車位置および降車位置を有する。そのような例では、一部の実施形態は、（ｉ）例えば、単独の乗客を乗車させるための近さおよび／または待ち時間等のパラメータに基づいて、第１の乗客に対する運転手を選択し、（ｉｉ）その運転手が、第２の乗車要求に対する適切な候補である場合を決定する（それにより、既存の輸送がライドシェアになる）ことにより、関連するクラスのユーザ（例えば、運転手クラスユーザおよび乗客クラスユーザ）にサービスを提供する輸送手配システムを提供する。幾つかの例によれば、輸送手配システムは、ライドシェアのために各乗客が選択される選択処理を強化またはより良好にするために、リアルタイムの処理および情報を用いる。

特に、幾つかの例の輸送手配システムは、所与の地理的範囲にわたるグループとしての乗客の待ち時間に基づいて、乗客／運転手のペアリングを最適化するためのネットワークサービスを提供し得る。それに加えて、またはその代わりに、幾つかの例の輸送手配システムは、ライドシェアの負のまたは望ましくない態様（例えば、第２の乗客が追加された場合の、第１の乗客に対する追加の送迎時間の量等）を制限または最適化する制約または最適化パラメータを実装し得る。

更に、本明細書に記載される多くの例は、送迎完了時間の推定または保証を提供できるライドシェアリングのための輸送手配システムまたはサービスを提供する。他の利益の中でも特に、（ｉ）乗車要求に対して適切な運転手を選択すること、（ｉｉ）選択された運転手が、許容可能な持続時間以内に乗車位置に到着するよう手配すること、および（ｉｉｉ）乗客の送迎の進行中に（例えば、乗客が車輌に乗車した後に）、運転手が乗車要求の降車位置に到着するよう手配することによる固有の不確実性に関係なく、送迎完了時間の推定または保証を提供できる。ライドシェアについては、乗車要求に対して選択された運転手に既に乗客がいるかもしれず、および／または、現在の乗客の送迎を開始した後で、別の乗客を乗車させるかもしれない点で、不確実性が大きく高まる。従って、ライドシェアの個々のユーザについての送迎完了時間に関する確実性を提供するために、輸送手配システムは、制約および／または最適化処理によって、ライドシェアサービスを提供し得る車輌についての最大乗客数、シェアリングを達成するための（個々の乗客または運転手に対する）ルートの逸脱、シェアされた輸送の乗客についての到着位置のばらつき、車輌の利用可能性（または供給）の実際のまたは予測される推定、並びに、乗客（または需要）の実際のまたは予測される推定を含むライドシェアリングの複数の面を考慮し得る。

ライドシェアリングの提供中に、輸送手配サービスは、所与の乗客の各乗車要求について、その乗客が（少なくとも最初は）単独の乗客であるか、または、１以上の既存の乗客の送迎を完了しつつある車輌とマッチングされているかを決定する。複数の例は、そのような乗客ペアリングの決定が、乗客および運転手の利益のバランスをとるようにインテリジェントに行われる場合には、手配されたライドシェアについての変更および全体的な送迎完了時間が大きく減少することを認識したものである。その結果、（運転コストが考慮された場合には）運転手の収入および／または利益を増加させつつ、各乗客の料金が低減される。

幾つかの例では、（ライドシェアにおける追加の乗客または乗車が最小数である）最良のケース、および（ライドシェアにおける追加の乗客または乗車が最大数である）最悪のケースの筋書における送迎完了時間を推定できる輸送手配システムまたはサービスが提供される。より詳細に説明するように、ライドシェアの利用可能性は、予測できないまたは予測困難な時間に動的に発生する事象および変化する条件によって大きく影響されるので、ライドシェアの乗客についての送迎完了時間の推定は、様々な種類のリアルタイムの情報の取得を必要とする。複数の例は、運転手が第１の乗客の送迎中に、ライドシェアの結果に影響する事象または条件（例えば、乗客を有する所与の車輌が別の乗客を乗車させるか否か）が生じる際の、ライドシェアリングをインテリジェントに実装する。

本明細書において用いられるクライアント装置は、輸送手配システムのユーザによって操作されるモバイルコンピューティング装置を含む。特定の例では、クライアント装置は、インターネットを介して提供される輸送手配サービスとの通信チャネルを開いて維持するために、サービスアプリケーションを実行するか、または別様で、そのようにプログラムで備えられる。複数の例は、乗客クラスユーザおよび運転手クラスユーザを含む複数のクラスのユーザを更に設ける。幾つかの実装例では、乗客クラスユーザのクライアント装置の動作は、運転手タイプの装置の動作とは異なる。例えば、輸送手配システムは、乗客のクライアント装置のために、運転手と比較して異なる種類のリアルタイムの情報を提供し得る。更に、各タイプのユーザに提供される機能性、ユーザインターフェース、およびサービスは異なっていてもよい。

多くの実装例において、クライアント装置および／または車輌通信装置は、サービス手配システムと通信するよう構成された指定されているアプリケーションを操作し得る。例えば、乗客は、乗客サービスを受けるための（例えば、輸送手配サービスを介して提供される輸送サービスの利用可能性を見るための）機能性を有する乗客アプリケーションを実行するモバイルコンピューティング装置を含み得る。同様に、輸送車輌を操作する運転手クラスユーザは、シェアされた輸送サービスを含む輸送サービスを提供することに関する機能性を有する運転手サービスアプリケーションを実行するモバイルコンピューティング装置を操作し得る。

例として、クライアント装置の文脈において、モバイルコンピューティング装置は、例えば、スマートフォン、フィーチャーフォン等のセルラー機能を有する装置、適切な機能を有するラップトップ、ノートブック、タブレット（またはハイブリッド装置もしくは「ファブレット」）、および／または、電話／メッセージング機能を有する他の多機能コンピューティング装置を含み得る。変形例において、モバイルコンピューティング装置はローミング装置を含んでもよく、これは、例えば、インターネットを介してネットワークサービスにアクセスするために、無線リンク（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）もしくは８０２．１１プロトコル、赤外線、ＲＦチャネル、近接場通信（「ＮＦＣ」）等を用いる媒体によって実装される無線接続）を用い得る装置である。例として、そのような装置は、プロキシとして動作可能な別の装置とリンクする場合もあるタブレット装置またはウェアラブル電子機器を含み得る。

多くの例は、運転手が、クライアント装置としてモバイルコンピューティング装置を操作することに備えたものであるが、複数の変形例は、少なくとも一部の運転手が車輌の通信装置を操作することに備えたものである。車輌の通信装置は、例えば、カスタムハードウェア、車載装置、および／または、代替の車載診断システム（「ＯＢＤ」）機能を提供する適切に装備された装置を用いて実装され得る。

更に、本明細書に記載される幾つかの例は、複数の乗客に対するシェアされたオンデマンド輸送サービスに関するものであるが、他の例としては、品物（例えば、調理された食品、荷物、または特殊な商品（例えば、子猫）等）の輸送のためのオンデマンド輸送サービスを提供するための輸送手配サービスが挙げられる。複数の例は、ライドシェアリングについて存在するような動的な条件および事象の影響を受ける、そのような商品のためのオンデマンド輸送サービスをその場その場で提供する輸送手配システムを更に提供する。そのような例では、輸送手配システムは、複数のユーザの輸送要求（例えば、個々の要求されている荷物の降車位置への配送、または特定の位置への食品の配達）を遂行するために、サービス提供者のリソースをシェアするよう動作する。

変形例において、特定の適時性を保証する必要がある、時間の影響を受ける製品またはサービスに関する、個人およびサービス提供者のための輸送手配システムが実装される。例えば、ユーザは、本明細書において提供される例によって説明される輸送システムによって提供されるシェアされた輸送サービスを用いて、オンデマンド配達サービス（例えば、食品の配達、メッセンジャーサービス、フードトラックサービス、または野菜製品の出荷）を要求し得る。

本明細書に記載される１以上の実施形態は、コンピューティング装置によって行われる、プログラムで行われる、またはコンピュータによって実装される方法としての方法、技術、および処理を提供する。本明細書において用いられる「プログラムで」とは、コード、即ちコンピュータが実行可能な指示を使用することを意味する。これらの指示は、コンピュータ装置の１以上のメモリリソースに格納され得る。プログラムで行われるステップは、自動化されていてもよく、または自動化されていなくてもよい。

本明細書に記載される１以上の実施形態は、プログラムモジュール、エンジン、またはコンポーネントを用いて実装され得る。プログラムモジュール、エンジン、またはコンポーネントは、プログラム、サブルーチン、プログラムの一部、または、１以上の記述されたタスクまたは機能を行うことができるソフトウェアコンポーネントもしくはハードウェアコンポーネントを含み得る。本明細書において用いられる、モジュールまたはコンポーネントは、他のモジュールまたはコンポーネントから独立して、ハードウェアコンポーネント上に存在し得る。或いは、モジュールまたはコンポーネントは、他のモジュール、プログラム、または機器の共有されたエレメントまたは処理であり得る。

本明細書に記載される一部の実施形態は、一般的に、処理リソースおよびメモリリソースを含むコンピューティング装置の使用を必要とし得る。例えば、本明細書に記載される１以上の実施形態は、全体的にまたは部分的に、例えばサーバ、デスクトップコンピュータ、携帯電話もしくはスマートフォン、ラップトップコンピュータ、プリンタ、デジタルピクチャーフレーム、ネットワーク機器（例えば、ルーター）、ウェアラブル装置、およびタブレット装置等のコンピューティング装置上で実装され得る。メモリリソース、処理リソース、およびネットワークリソースは全て、本明細書に記載される任意の実施形態の構築、使用、または実行（何らかの方法の実行、または何らかのシステムの実装を含む）に関して用いられ得る。

更に、本明細書に記載される１以上の実施形態は、１以上のプロセッサによって実行可能な指示を用いて実装され得る。これらの指示は、コンピュータ可読媒体上に担持され得る。以下の図面と共に示される、または説明される装置は、本発明の実施形態を実装するための指示が担持および／または実行され得る処理リソースおよびコンピュータ可読媒体の例を提供するものである。具体的には、本発明の実施形態と共に示されている多くの機器は、プロセッサと、データおよび指示を保持するための様々な形態のメモリとを含む。コンピュータ可読媒体の例は、例えばパーソナルコンピュータまたはサーバ上のハードドライブ等の永久的なメモリストレージ装置を含む。コンピュータストレージ媒体の他の例は、例えばＣＤもしくはＤＶＤユニット、（例えばスマートフォン、多機能装置、またはタブレット等に搭載された）フラッシュメモリ、および磁気メモリ等の携帯型ストレージユニットを含む。コンピュータ、端末、ネットワークを使用可能な装置（例えば、携帯電話等のモバイル装置）は全て、プロセッサ、メモリ、およびコンピュータ可読媒体に格納された指示を用いる機器および装置の例である。更に、実施形態は、コンピュータ−プログラム、またはそのようなプログラムを担持できるコンピュータが使用可能なキャリア媒体の形態で実装され得る。

システムの説明
図１は、シェアされた輸送サービスを提供するための例示的な輸送手配システムを示す。図１の例によれば、輸送手配システム１００は、集中型のネットワーク機器（例えば、サーバ１０１）、およびシステム１００によって提供される輸送手配サービスのユーザによって操作されるクライアント装置１０２の間に分散している。図１の例では、クライアント装置１０２は、複数のクラスのユーザ（例えば、運転手クラスユーザ、乗客クラスユーザ）によって操作され得る。輸送手配システム１００は、様々なプラットフォームまたは形状因子の様々なエンドユーザ装置（例えば、多機能携帯電話／メッセージング装置、タブレット装置、ウェアラブル電子機器等）が設けられ得るという点で、ヘテロ性であり得る。輸送手配システム１００のネットワークプラットフォームとしての実装は、輸送手配システム１００のサーバまたは他のネットワークリソースとの通信チャネルを確立および／または維持するための機能性を有するクライアント装置１０２を必然的に伴い得る。例として、個々のクライアント装置１０２は、無線通信媒体を介して確立されるインターネットプロトコル接続を確立して維持し得る。

輸送手配システム１００は、複数のネットワーク（例えば、セルラーネットワーク、インターネット）および通信媒体（例えば、セルラー、８０２．１１または「Ｂｌｕｅｔｏｏｔｈ」プロトコル、イーサネット（登録商標）等によって提供される）を用いて、ネットワークプラットフォームとして実装され得るものであり、これらは集合的に通信ネットワーク１０４として表されている。

集合的に、様々なエンドユーザのクライアント装置１０２は、装置プラットフォームまたは形状因子に関してヘテロ型であり得る。１つの実装例において、各クライアント装置１０２は、輸送手配システム１００の対応するサーバ１０１との通信チャネルを確立するサービスアプリケーション１１２を実行する。サービスアプリケーション１１２は、対応するクライアント装置１０２上で実行された際に、例えば、ハードウェアリソース（例えば、地理を意識した構成要素（例えば、ＧＰＳおよびセンサ等）、並びに、データセット（例えば、サードパーティによる地図）およびアプリケーションの他の機能性（例えば、カンレダーアプリケーション）とのインターフェースを行い得る。

他の技術的特徴の中でも特に、輸送手配システム１００は、オンデマンド輸送手配サービスに関する様々な機能性およびサービスの強化を提供するために、様々なクライアント装置１０２からのデータを集めるよう動作する。１つの態様において、輸送手配システム１００は、同じ時間にネットワークプラットフォームのデータ取得要素としてクライアント装置１０２を用いつつ、エンドユーザのプライバシーを維持するための技術を実装する。複数の例によれば、ネットワークプラットフォームを用いてオンデマンド輸送手配サービスを実装するための技術的配慮は、例えば、単にコンピューティング装置に格納されているユーザデータを保護するよりも遥かに複雑である。複数の例は、輸送手配システム１００が、多くの輸送手配サービスおよびサービスの強化を効果的にするために、エンドユーザ装置１０２Ｒ−ｎ（乗客クライアント装置を表す）および１０２Ｄ−ｎ（運転手クライアント装置を表す）からユーザ情報を取得することを認識したものである。他の課題の中でも特に、輸送手配システム１００は、より詳細に後述するように、クライアント装置から、（ｉ）乗客用および運転手用のクライアント装置１０２Ｒ、１０２Ｄからの位置情報１０９Ｒ、１０９Ｄ、並びに／または（ｉｉ）サービス情報およびユーザの集団についての非プライベートなサービス関連情報を提供するための、サービス状況情報１１９Ｒ、１１９Ｄを含む、プライベート情報をリアルタイムで集める。

複数の例によれば、プライバシー制約、条件、または規則に違反しない条件下でまたは別様で、所与のユーザのプライベート情報が別のユーザに開示されないように、集められたユーザ情報の様々な集合が取得されて、エンドユーザのプライバシーを損なわない具体的なリアルタイムの情報として編成され得る。例として、輸送手配システム１００は、個々のユーザのクライアント装置から、リアルタイムの位置情報１０９Ｒ、１０９Ｄおよびサービス状況情報１１９Ｒ、１１９Ｄを取得するために用いられ得る。サービス状況情報１１９Ｒは、例えば、乗客クラスユーザが輸送サービスを要求したか否か、乗客クラスユーザが輸送サービスを受けているか否か、または、（例えば、対応するクライアントユーザ装置を用いたユーザのやりとりに基づいて）乗客クラスユーザが輸送サービスを要求する可能性があるか否か等の情報を識別し得る。運転手クラスユーザについての状況情報１１９Ｄは、輸送サービスを提供するためにその運転手が利用可能であるか、割り当てられているか、または送迎中であるか（例えば、「乗車中」）を示す情報を含み得る。それに加えて、またはその代わりに、状況情報１１９Ｄは、運転手が輸送要求に割り当てられているが、まだ乗車位置に到着していないか否かを示し得る。それに加えて、またはその代わりに、状況情報１１９Ｄは、（例えば、運転手がまだ乗車位置に到着しておらず、現在の割当てが閾値制限時間を超えていない場合に）運転手が、再割当てが許可される持続時間にわたって輸送要求に割り当てられているか否かを示し得る。

同様に、所与の地理的領域内のユーザの位置情報１０９Ｒ、１０９Ｄは、例えば、その領域内の乗客数または運転手を決定するために用いられ得る。様々な乗客クラスユーザの位置情報１０９Ｒは、サービス状況情報１１９Ｒと組み合わされた際に、例えば、オンデマンド輸送サービスに対する需要／または潜在的な需要を定義し得る。同様に、運転手クラスユーザの位置情報１０９Ｄとサービス状況情報１１９Ｄとの組合せは、オンデマンド輸送サービスに対する供給または潜在的な供給を決定し得る。需要情報および供給情報のリアルタイムの取得および更新は、更に、サービスの強化（例えば、送迎完了時間もしくは送迎完了時間のより良好な予測可能性、並びに／または、需要および／もしくは供給を調節するためのリアルタイムの価格調節等）につながり得る。例えば、図１によって示されているような例では、需要および供給の決定を含む強化は、輸送シェアサービスに特定して行われ得る。その結果、そのような強化は、ライドシェアサービスでは、例えば、運転手が稼ぐ全収入に対して相対的な運転手リソース（例えば、利用可能な運転手、個々の運転手によって操作される車輌の燃料）の支出の低減によって、輸送手配システム１００を最適化するよう実施され得る。

更に、輸送手配システム１００の最適化機能は、単独の輸送サービスではなくシェアされた輸送サービスが提供される際には、クライアント装置１０２Ｒ、１０２Ｄ、およびサーバ１０１がより効率的に用いられるという点で、ネットワークプラットフォームの構成要素の効率を改善し得る。例えば、クライアント装置１０２Ｒ、１０２Ｄが、シェアされた輸送を受ける／提供するために要する動作の持続時間および／または計算リソースの量が、ユーザをグループまたは集団として最適化しない別のサービスと比較して、大きく低減され得る。動作の持続時間および計算リソースの低減は、クライアント装置１０２Ｒ、１０２Ｄの電池の節約、並びに、近所にあるクライアント装置１０２Ｒ、１０２Ｄのための帯域幅の増加につながり得る。

図１の例を更に参照すると、輸送手配システム１００は、プライバシー制約または規則に違反することなく、クライアント装置１０２Ｒ、１０２Ｄから情報をセキュアに取得して集めるために、分散型ネットワークプラットフォームとして実装され得る。分散型ネットワークプラットフォームとしての輸送手配システム１００は、ライドシェアリングおよび／または他の輸送手配サービスのインテリジェントなまたは最適化された実装という目的に役立ち得る、正確なリアルタイムの信頼性の高い情報を取得することができる。更に、そのような情報の取得は、輸送手配システム１００が、シェアリングが生じ得る輸送サービスについての送迎の完了時間を予測するのを促進または可能にし得る。より詳細に説明するように、幾つかの変形例は、輸送手配システム１００が、ライドシェアの乗客を対応する車輌に割り当てる前に、乗客の見込みのあるペアリングについての予測完了時間を計算するものとしている。予測完了時間の計算は、例えば、新たに追加される乗客の送迎によって既存の送迎の完了時間が所与の閾値を超える場合に、輸送手配システム１００が、ライドシェアリングに対応するための既存の送迎からの逸脱を制限することによって、乗客ペアリングに対する制約を実装することを可能にし得る。見込みのある乗客ペアリングを、既存のライドシェアとのペアリングにおける好適性について評価する際の、比較の閾値を決定するために、見込みのあるペアリングについての予測完了時間の計算は、更に、平均されてもよく、または、統計的解析もしくは履歴解析を受けてもよい。

更に、クライアント装置１０２からのリアルタイムの情報の取得は、シェアされた輸送サービスについての車輌の乗車率、供給および／または需要、並びに価格の予測を可能にし得る。他の例と同様に、予測は、リアルタイムで取得された情報を用いてリアルタイムで行うことができる。

提供される例の文脈で、「供給」という用語は、主として、所与の地理的領域におけるサービス提供者（例えば、運転手）の数を意味するものと理解される。多くの例において、サービス提供者の数とは、詳細には、サービスを提供するために利用可能なサービス提供者、および／または、サービスを提供するために閾値期間内に利用可能になるサービス提供者を意味し得る。「需要」という用語は、主として、乗客クラスユーザを意味するものと理解される。変形例においては、需要という用語は、詳細には、所与のインスタンスもしくは持続時間においてサービスを能動的に受けている乗客、または、輸送要求が行われる不確実な確率のみが存在するユーザを含み得る（または除外し得る）。

図１の例によって示されるように、輸送手配システム１００は、クライアント装置１０２Ｒ、１０２Ｄが両方ともユーザエンド装置であり、輸送手配システム１００によって用いられる情報のソース装置である、オンデマンドサービスを提供し得る。輸送手配システム１００によってクライアント装置１０２Ｒ、１０２Ｄから取得された情報（例えば、位置情報、サービス状況情報）は、オンデマンドサービスの提供のされ方を調節する。従って、各クライアント装置１０２Ｒ、１０２Ｄは、より大きなユーザグループ（例えば、所与の数の街区内の乗客）に合わせたオンデマンドサービスの実装に影響する情報（例えば、ユーザ位置またはサービス状況情報）を提供しつつ、所与のユーザに対するサービスを取得または提供するために、輸送手配システム１００の一部として動作し得る。

輸送手配システム１００は、情報のソース装置としてクライアント装置１０２を用いるので、例えば、１以上のサーバ１０１によって提供される集中型のまたは仲介するコンピュータの役割は、個々の乗客または運転手の最良の必要性のために働くのではなく、より大きなグループの乗客および運転手についての所望の制約を最適化するため、または忠実に守るために、客観的に決定を実施するものであり得る。

他の技術的利益および目的の中でも特に、サーバ１０１は、人間の関与または影響を除外するやり方で、そのような決定を行うための情報、および取得された情報を用いて決定を行うための処理を取得するための機能性を実装し得る。１つの態様によれば、サーバ１０１は、より大きなユーザグループに対してサービスを強化または拡張するために情報を用いるために、集合的でない場合にはプライベートであると見なされる情報を集める際の、技術的な機能性を実装する。別の態様によれば、サーバ１０１は、供給、需要、到着または合計送迎時間、およびそれらの予測（ライドシェアリングにおける車輌の乗車率の予測を含む）を決定するために、集合的な情報を用いる機能性を実装する。

例として、輸送手配システム１００は、運転手装置が、輸送手配システム１００を介して提供される輸送サービスに関連して用いられるために利用可能である場合は常に、運転手のクライアント装置１０２Ｄは、輸送手配システムのサービスに自動的に位置情報を通信するように実装され得る。運転手装置の地理を意識した（geo-aware）リソース（例えば、ＧＰＳ）によって、特定のインスタンスにおける運転手の位置についての情報のソースが、運転手からの妨害または影響を受けることなく提供されるように、クライアント装置１０２Ｄは、運転手が、例えば、クライアント装置１０２Ｄの地理を意識したリソースを使用不可にするまたは変更することを不可にするか、または能動的に不可能にし得る。この点に関して、リモート計算機構であれば、（本質的に偏見を持ち得ると共に、十分に信頼できないまたは正確ではないことがあり得る）様々なユーザから取得されたデータの有効性を確保するので、輸送手配システム１００は、手動の選択肢を持たない機能性を実装する。例えば、輸送手配システム１００のサービスは、運転手に、所与のインスタンスにおける自分の位置を尋ねることはできない。この理由は、（ｉ）運転手は十分な精度で知ることができない可能性があると共に、（ｉｉ）運転手は知覚される支出を減らす動機を持つので、運転手によって提供される情報は疑わしいからである。

後者のケースの説明として、複数の例は、運転手が送迎中に自分の位置を尋ねられ、その送迎がもうすぐ終わることを知っている場合、運転手は、その運転手のライドシェアが最大化されるように、事業体が新たな乗客をその運転手に割り当てる決定を行うように仕向けるために、不正確な情報を提供することによって、自分の利益になるよう自然と行動し得ることを認識したものである。その結果、（運転手の実際のリアルタイムの位置に基づく）より最適な決定は、第１の乗客を降車させた後、引き返して第２の乗客を乗車させること、或いは、第１の運転手に対する送迎時間の追加は第１の乗客の合計送迎時間の制約に違反するので、第２の車輌に第２の乗客を乗車させることである場合でも、その運転手のルートが第２の乗客に向かって逸脱することが決定され得る。運転手は不正確な情報を提供する偏見を持つのみならず、最適な乗車ペアリングを決定するために必要な情報はリアルタイムで行われる、つまり、ユーザの集団（複数の乗客および複数の運転手の両方）からのリアルタイムの位置情報および状況情報１０９、１１９を用いて行われるので、運転手は最適な決定を行うための情報を持っていない。輸送手配サービスはリアルタイムの情報を用いるので、どの運転手／乗客ペアリングが必要かの実際の決定は、或る持続時間（例えば、３０秒間）にわたって行われ得るものであり、この間、需要および供給の変動、並びに運転手の進行中の送迎および新たな送迎の予測されるルートに基づいて、決定が変更され得る。

複数の例は、輸送手配システム１００の任意のユーザからの手動入力または影響が、予測可能性または効率のために設計された制約を最適化および実装するシステムの能力を弱体化させることを認識したものである。例えば、乗客は、自分の輸送要求に対して、ライドシェアリングを可能にするための値引きを受け得るが、乗客は、一般的に、狭い空間を他人とシェアすることを好まない。従って、乗客は、その特定の乗客に提供されている輸送がシェアされないように、決定に影響する情報を提供する動機を持つ。そのような理由から、輸送手配システム１００は、いかなるユーザも、システムが輸送手配サービスを実装する際に決定を行うために要する情報に混乱または影響を及ぼすことができないようにする、または別様で不可能にする機能性を有するサービスアプリケーションを提供し得る。各クライアント装置１０２上のサービスアプリケーションは、サービスアプリケーション１１２の実行中には、例えば、ユーザがクライアント装置の位置決定リソース（例えば、ＧＰＳ）のスイッチをオフにする機能、および確立されたチャネルを介した輸送手配システム１００とのクライアント装置の通信に大きく干渉する機能を使用不可にし得る。

幾つかの例では、サーバ１０１は、輸送シェアリング論理１０５によって提供されるものとして図示されている、輸送シェアリングサービスを手配すると共に、実際のシェア（例えば、１つの車輌内に２名の乗客）、見込みのあるシェア（ライドシェアの乗客に対応可能な既存の輸送を有する運転手にまだ割り当てられていない実際の乗客の仮定上の配置）、および／または、仮定上のシェア（例えば、予測される供給／需要を所与とした、利用可能な車輌の尤度を示す統計的データからライドシェアが決定される場合）についての予測結果を決定する機能性を実装する。更に、輸送シェアリング論理１０５は、要求されているまたは見込みのある（または仮定上の）ライドペアリングの複数の面を決定するために、複数のユーザ（運転手および乗客を含む）からの情報を用い得る。クライアント装置１０２Ｒ、１０２Ｄは、通信ネットワーク１０４を用いて、例えば、位置情報１０９Ｒ、１０９Ｄおよび／またはサービス状況情報１１９Ｒ、１１９Ｄ等の情報を繰り返しまたは連続的に通信し得る。複数の例において、クライアント装置１０２Ｒ、１０２Ｄは、それぞれのクライアント装置とネットワークサービスとの間の通信チャネルの構成および／または維持を可能にする機能性を提供する様々なサービスアプリケーション１１２を実行する。更に、サービスアプリケーション１１２は、輸送シェアリング論理１０５が予測完了時間および／または車輌の乗車率の予測結果を生成するために用い得る情報（例えば、位置情報１０９Ｒ、１０９Ｄ、サービス状況情報１１９Ｒ、１１９Ｄ）を提供する際に用いられる生データ（例えば、センサ（例えば、ＧＰＳ等）からの位置情報）を取得する目的で、それぞれの装置のハードウェア（例えば、ＧＰＳ、加速度計等）、ソフトウェア、またはデータリソース（例えば、地図）にアクセスするための処理または機能性を実装し得る。

他の例で述べたように、サービスアプリケーション１１２は、ユーザが、生データの取得および生データが輸送手配システム１００に通信される前に処理される方法に干渉することを制限するまたはなくす機能性を実装し得る。例えば、サービスアプリケーション１１２は、位置センサをスキャンして、特定のインスタンスにおける装置の地理的座標を決定し、次に、その情報をアカウント識別子とペアリングし、更に、情報が輸送手配システム１００に送信される前に情報の暗号化（またはハッシュ処理）を行うための自動化された処理を実装し得る。例えば、ユーザがＧＰＳ機能を使用不可にした場合には、サービスアプリケーション１１２は、その装置がサービスを受けることを不可にするか、或いは、装置から通信される情報を考慮せずに、ユーザに提供されるサービスを制限し得る。このようにして、サービスアプリケーション１１２は、それぞれのクライアント装置１０２Ｒ、１０２Ｄから通信される情報の精度および完全性を保護するための機能性を実装する。

図２Ａは、ライドシェアを手配するための輸送手配サービスの一例を示す。輸送手配サービス２００は、例えば、図１の例で説明したような輸送手配システム１００の一部として実装され得る。従って、図２の例は、図１の例の輸送手配システム１００の文脈で見ることができる。

図２Ａの例を参照すると、輸送手配サービス２００は、サーバ（または、複数のサーバもしくは他のネットワークコンピュータの組合せ）を用いて実装され得る。１つの実装例において、サービス２００は、プロセッサ２０１と、読み出し専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）または他の動的ストレージ装置を含み得るメモリ２０２と、ディスプレイ装置２０３と、入力機構２０４と、通信ネットワーク２１４に通信可能に接続するための通信インターフェース２０５とを含む。

サービス２００のプロセッサ２０１は、例えば、図１、２Ａ、３、４Ａ、４Ｂ、５Ａ、および５Ｂ等によって説明されたような実装例で説明された１以上の処理、工程、および他の機能を行う。プロセッサ２０１は、プロセッサ２０１によって実行可能な情報および指示を格納するための、例えば、ランダムアクセスメモリ（ＲＡＭ）または他の動的ストレージ装置によって設けられるようなメモリ２０２に格納されている情報および指示を処理し得る。メモリ２０２は、輸送シェアリング論理１０５および他の論理の実行中に一時変数または他の中間情報を格納するために用いられ得る。メモリ２０２は、プロセッサ２０１のための静的情報および指示を格納するためのＲＯＭまたは他の静的ストレージ装置を含み得る。通信インターフェース２０５は、輸送手配サービス２００がネットワークリンク（無線または有線）を用いて１以上の通信ネットワーク２１４（例えば、セルラーネットワーク）と通信することを可能にするよう動作し得る。サービス２００は、供給および提供に際して、ネットワークリンクを用いて１以上のコンピューティング装置と通信し得る。複数の例によれば、シェアされた輸送サーバ１０１は、輸送手配システム１００によって提供されるシェアされたライドシェアが、（例えば、乗客によって）評価されている際、開始される際、または進行中に、移動中または送迎中の位置情報を含む情報を通信および受信する。

プロセッサ２０１は、輸送シェアリング論理１０５によって示されているメモリからの指示を実行して、ライドシェアマッチング（例えば、図５Ａを参照）、並びに、実際のライドシェア、見込みのあるライドシェア、および／または仮定上のライドシェアについての予測結果（例えば、図５Ｂの例で説明したような予測送迎完了時間）を提供し得る。輸送シェアリング論理１０５は、（例えば、図５Ａで説明したような）ライドシェアマッチング構成要素、および（例えば、図５Ｂの例で実装され得るような）送迎完了時間予測器２２７を含み得る。ライドシェアマッチング構成要素２２５および送迎完了時間予測器２２７と共に用いられる１組のライドシェア制約２２９が格納され得る。ライドシェア制約２２９は、例えば、（ｉ）ライドシェアのために考慮中の所与の車輌に対して許可されている最大乗客数、および／または（ｉｉ）追加の乗客（この場合、逸脱は、ライドシェア輸送を含まない要求者の降車位置までの輸送と比較される）および／または既存の乗客（この場合、逸脱は、追加の乗客を含まずに完了される既存の乗客に対する進行中の輸送と比較される）の観点からの、進行中の既存のライドシェアの追加の乗客としての要求者に対応するために許可されている逸脱を含み得る。

１つの実装例において、プロセッサ２０１は、ライドシェア要求を処理して、乗客の要求についての乗車位置および降車位置等のパラメータを決定し得る。プロセッサ２０１は、制約２２９の下で、その要求者についてのライドシェアを選択するために、ライドシェア要求のパラメータを用い得るライドシェアマッチング構成要素２２５を実行し得る。他の例で説明したように、制約２２９は、履歴情報から決定され得るものであり、時間間隔（例えば、曜日、時刻）および地理的領域を特定したものであり得る。変形例において、制約２２９は、選択された車輌が制約２２９を最良に満たす車輌（例えば、最小の逸脱を有する車輌）であり得るように、ランク付けまたはスコア付けを可能にし得る。更に、プロセッサ２０１は、送迎完了時間予測器２２７を実行して、要求のパラメータを所与とした、選択されたまたは考慮されているライドシェアの送迎完了時間を予測し得る。

図２Ｂは、輸送手配システムと共に用いられる例示的なモバイルコンピューティング装置を示す。図２Ｂの例では、モバイルコンピューティング装置２５０は、輸送手配システムのクライアント装置１０２（図１を参照）のうちの１つとして動作するために、サービスアプリケーション１１２を実行し得る。従って、モバイルコンピューティング装置２５０は、例えば、電話、メッセージング、および／またはデータサービス機能を有するセルラー通信装置（例えば、フィーチャーフォン、スマートフォン等）に対応し得る。変形例において、モバイルコンピューティング装置２５０は、例えば、タブレットまたはウェアラブルコンピューティング装置に対応し得る。モバイルコンピューティング装置２５０は、１以上のプロセッサ２５１、メモリ２５２、表示画面２５３、入力機構２５４（例えば、キーボードまたはソフトウェアによって実装されたタッチスクリーン入力機能等）、位置決定機能（例えば、ＧＰＳモジュール２５５によるもの等）、および、輸送手配サービス２００と通信するために通信ネットワーク２６４と（例えば、データチャネルおよび／または音声チャネルを介してセルラーデータを送受信することによって）通信可能に結合するための１以上の通信インターフェース２５６（例えば、Ｗｉ−Ｆｉ、「Ｂｌｕｅｔｏｏｔｈ」、セルラー媒体を用いた無線通信を可能するためのインターフェース）を含む。

幾つかの例によれば、サービスアプリケーション１１２は、輸送手配サービス２００とやりとりするための１以上のインターフェースを生成するために実行され得る。図２Ｂの例では、サービスアプリケーション１１２は、乗客クラスユーザによって輸送シェア要求が生成され得るライドシェアインターフェース２６６を生成するために、アプリケーション指示２６３を用いて実装され得る。サービスアプリケーション１１２は、輸送手配システム１００によって制御されているウェブサイトから（通信インターフェース２５６を介して）ダウンロードされ得る。図５Ａの例で説明したように、ライドシェアインターフェース２６６は、乗客をライドシェア輸送提供者とマッチングするために用いられ得る。更に、図５Ｂの例で説明したように、ライドシェアインターフェース２６６は、ライドシェアの見込みのある乗客または実際の乗客についての到着時間を推定するために用いられ得る。

幾つかの例によれば、ライドシェアインターフェース２６６は、乗客クラスユーザが、輸送手配サービス２００からのライドシェア輸送を要求する目的で、モバイルコンピューティング装置２５０をクライアント装置１０２として操作することを可能にし得る。輸送要求を行う際、サービスアプリケーション１１２は、ユーザの現在位置を決定するためにＧＰＳモジュール２５５にアクセスするよう実行され得る。サービスアプリケーション１１２は、ユーザが乗車位置（例えば、現在位置または現在位置に対して相対的な位置として）および降車位置を指定することを可能にするために、地図または他の位置に基づくインターフェースを提供し得るかまたはそれにアクセスし得る。輸送手配サービス２００は、輸送シェアリング要求を受信して、コンテンツ（例えば、接近中の車輌の位置）が表示画面２５３上に表示され得るように、それに応答し得る。ユーザは、入力機構（例えば、タッチスクリーン）のうちの１以上を用いてやりとりし、入力を指定し得る（例えば、輸送シェア要求を行う、降車位置および目的地位置を指定する等）。

図３は、１以上の実施形態による輸送手配システムの論理的アーキテクチャを示す。より具体的には、図３は、乗客用および運転手用のクライアント装置１０２Ｒ、１０２Ｄ並びにそのようなクライアント装置と共に用いられる輸送手配サービス２００の構成要素を含む、例示的な輸送手配システム１００（図１を参照）を実装するために組み合わされ得る、論理的またはプログラム構成要素または機能を示す。

図１、図２Ａ、および図２Ｂの例で説明したように、乗客クライアント装置１０２Ｒは、輸送手配サービス２００と通信してそこからのサービスを受けるために、サービスアプリケーション１１２を実行する。特に、クライアント装置１０２Ｒは、サービスアプリケーション１１２を実行して、乗客装置インターフェース３１０を介して輸送手配サービス２００との通信チャネルを開き得るまたは維持し得る。様々なサービスおよび機能性のために様々なタイプの通信が交換され得るが、図３の例は、乗客クライアント装置１０２Ｒが、対応する乗客のライドシェア要求３０１（或いは「輸送シェア要求」等として参照される）および推定要求３０３を通信するものとしている。ライドシェア要求３０１は、乗車位置から降車位置までの輸送シェアリングサービスを受けるための乗客からの要求に対応し得る。推定要求３０３は、送迎持続時間（例えば、送迎完了時間等）に具体的に関連する輸送シェアサービスの属性またはパラメータを推定するための手動またはプログラムで生成された要求に対応し得る。送迎完了時間は、乗客が乗車位置において乗車してから、同じ乗客が降車位置において降車するまでの所要時間を指し得る。例えば、乗客は、ライドシェア要求３０１を行うことを決定する前に、ライドシェアの持続時間についての推定を受信するために、クライアント装置１０２Ｒを操作し得る。或いは、クライアント装置１０２Ｒは、ユーザ入力に応答して、要求しているユーザについての既に開始された（例えば、乗客が車輌に乗車した）または別様で進行中のライドシェアの属性またはパラメータを推定し得る。

他の変形例において、クライアント装置１０２Ｒまたは輸送手配サービス２００のプログラム構成要素または要素は、推定要求３０３を生成するようトリガされ得る。例えば、乗客がライドシェア要求３０１に対する応答３２１を受信したら（例えば、ユーザが、車輌がその乗客を乗車させるためのルートを走行中であることを知らされたら）、クライアント装置１０２Ｒおよび／または輸送手配サービス２００のプログラム要素は、推定要求３０３を自動的に生成し、この要求は、最新の情報を求めて繰り返され得る。多くの例は、推定要求３０３に対する応答を説明する際に、送迎完了時間に対する逸脱または変更を考慮しているが、変形例では、乗客の送迎の他の属性（例えば、距離、料金価格（送迎完了時間または距離によって異なり得る）、および／または乗客の乗車位置および降車位置を所与とした（ライドシェアと単独の輸送との間の）料金比較による送迎に対する変更等）が考慮され得る。

各運転手クライアント装置１０２Ｄは、運転手が活動中であるときに、対応するバージョンのサービスアプリケーション１１２を実行する。運転手クライアント装置１０２Ｄ上のサービスアプリケーション１１２は、輸送手配サービス２００の運転手装置インターフェース３１２との通信リンクを確立して維持し得る。この通信リンクは、運転手情報３２９として示されている様々なタイプの情報を輸送手配サービス２００に通信するために用いられ得る。幾つかの例によれば、運転手情報３２９は、運転手位置情報１０９、運転手状況情報１１９、および／または他の情報（例えば、運転手（または車輌）の識別子等）を含み得る。運転手装置インターフェース３１２は、輸送手配サービス２００の様々な構成要素によって用いられるリアルタイム運転手状況ストア３１５を維持するための論理を含み得る。特に、運転手位置情報１０９Ｄおよび運転手状況情報１１９が最新の状態に維持されるように、運転手装置インターフェース３１２は、各運転手クライアント装置１０２Ｄから通信される運転手情報３２９によって連続的に更新され得る。運転手状況情報１１９Ｄは、運転手が活動中であるかまたは非活動中であるか、および、運転手が送迎中であるかまたは新たな要求者に対するサービスを提供するために利用可能であるかを反映し得る。ライドシェアリングの文脈で、運転手状況情報１１９Ｄは、運転手が既存の乗客を有しているか否か、および／または、運転手が新たな乗客を乗せる余地を有しているか否かを反映し得る。更に、運転手状況情報３１９Ｄは、所与の運転手が従事している送迎についての降車位置を含み得る。

幾つかの変形例では、運転手状況情報１１９Ｄは、運転手が送迎中であるか否か、運転手が乗客に割り当てられたとき（但し、送迎が開始する前）、または運転手が送迎の完了に近づいているときを反映し得る。実装例に応じて、最近の運転手割当て（例えば、割当て後２分間未満）は、利用可能な状況として見なされ得る。同様に、送迎の完了に近づいている運転手も、完了の時間が所与の閾値以内であるときには利用可能であると見なされ得る。

複数の例によれば、輸送手配サービス２００は、乗客をライドシェア輸送とマッチングするための機能性を実装する。ライドシェア輸送は、複数の乗客に対してシェアされ得る手配された輸送に対応し得る。要求者（例えば、ライドシェア要求３０１を生成するユーザ）の観点からは、ライドシェア輸送は、要求者が最初のまたは唯一の乗客である輸送、または、要求者が追加の乗客となる輸送に対応し得る。複数の例によれば、要求者は、提供される輸送が既存の乗客を有するかまたは空車であるかを知らない。更に、要求者は、輸送の状況が経時的にどのように変わるか（例えば、新たな乗客の追加、既存の乗客の降車等があるか）を知らない。

図３の例は、不確実性が、乗客がライドシェア輸送を要求することを取りやめさせ得ることを認識したものである。例えば、要求者の観点からは、ライドシェア輸送は、追加の乗車および／または降車に対応するために、より長い期間がかかり得るものである。より高い確実性を提供するために、輸送手配サービス２００は、任意の特定のライドシェア輸送についての送迎完了時間の範囲を推定および／または堅く制限し得る。１つの実装例において、ライドシェアマッチング構成要素３２０は、受信されたライドシェア要求３０１に対してライドシェア輸送を選択するが、要求者または既存の乗客の観点から、１組のライドシェア制約３３７が、ライドシェア輸送に対する追加の時間または距離の上限を定めている。幾つかの例では、１組のライドシェア制約３３７は、運転手が運ぶことを許可されている最大乗客数（例えば、２名以上）の識別を含む。最大乗客数は、例えば、運転手の車輌のサイズ、輸送手配サービス２００のオペレータの選好設定、および／または輸送手配サービス２００によって用いられる個々の車輌の運転手／オペレータの選好設定に基づき得る。更に、１組のライドシェア制約３３７は、距離および／または時間で測定される、既存のまたは最適な送迎からの許可されている逸脱を含み得る。幾つかの例では、逸脱は、要求者の文脈で、ライドシェアリングを生じずに（例えば、単独の乗客の輸送で）要求者を乗車位置と降車位置との間で輸送する場合と比較した、要求者を要求者の降車位置まで輸送するために要するまたは要し得る追加の時間または距離の大きさを反映するように決定され得る。それに加えて、またはその代わりに、幾つかの変形例では、逸脱は、新たな乗客としての要求者の追加の結果としての、既存の乗客の送迎の持続時間および／または時間に関する延長の大きさであるものとしている。このようにして、ライドシェア制約３３７は、ライドシェア輸送をライドシェア要求にマッチングする際の許容可能な逸脱についての制限または閾値を定め得る。

図３の例によれば、運転手の候補セット３０５が識別された際に、ライドシェア推定器３３０を用いて、送迎完了時間および／または送迎完了距離に対応するライドシェア推定３１９が計算され得る。送迎完了時間および／または距離は、決定された最良のケース（例えば、他の乗客がいないライドシェアの乗客）および／または最悪のケース（例えば、最大数の乗客がいるライドシェアの乗客）の筋書、最良／最悪のケースの筋書の平均、またはそれらの変形に基づいて予測され得る。幾つかの変形例では、ライドシェア推定器３３０は、例えば、最良のケースの筋書（例えば、要求者が単独の乗客である輸送を受ける）、最悪のケースの筋書（例えば、要求者がライドシェア輸送を受ける）、および／またはそれらの確率に基づいて、要求者についての送迎到着時間を計算し得る。また、送迎到着時間は、要求者の送迎のために走行する時間および／または距離を決定するためのルート決定エンジン３３２を用いて、（例えば、最良のケースの筋書と最悪のケースの筋書との間の）範囲に関して表され得る。図５Ｂの例で説明したように、要求者についての到着時間は、要求者に対して提供される輸送が複数の乗客に対応するか否かに関して、または、乗客に対して提供される輸送が、実際にはその乗客の輸送要求が行われた前もしくは後にシェアされている場合に存在するルート変更および時間延長の量に関して、不確実性が存在する場合にも、推定され得る。

送迎到着時間または距離についてのライドシェア推定３１９を決定するために、ライドシェア推定器３３０は、履歴情報３４３を用いて、例えば、（ｉ）供給、（ｉｉ）需要、（ｉｉｉ）１つの車輌内に複数の乗客がいる確率、および／または（ｉｖ）要求者が空の車輌で輸送を開始した場合に、送迎中に、その送迎をライドシェアに変える別のライドシェア要求が受信され得る確率を決定し得る。更に、履歴情報３４３は、所与の地理的領域および／または関連する期間にわたる時間または持続時間の典型的な逸脱を含み得る。ライドシェア推定３１９は、供給、需要、および／または履歴情報の入力を用いた、要求者に対する１回の送迎において発生する複数のライドシェアペアリングの考慮も含み得る。例えば、要求者の送迎が比較的長い場合には、ライドシェア推定３１９は、要求者が降車位置まで輸送される前に、そのユーザのライドシェアが、既存の乗客の降車および新たな乗客の新たな乗車、または複数の降車および／または新たな乗車を含む確率を考慮し得る。

幾つかの実装例では、ライドシェア推定器３３０は、ルート決定エンジン３３２を操作して、追加の乗客に対応する目的で、進行中の送迎のルートを変更する。ルート変更のために、送迎完了時間または距離に対する延長または逸脱を決定するために、候補の運転手によって進行中の送迎が解析され得る。より具体的には、ライドシェア要求３０１について、既存の送迎に対する要求者の追加によって生じる時間または距離の延長を決定することにより、既存の乗客を有する候補の運転手が評価され得る。ライドシェア推定器３３０は、ルート決定エンジン３３２を用いて、運転手の既存の送迎に対する変更または延長を決定する。ルート決定エンジン３３２は、要求者の送迎に対応するための、運転手の既存の送迎に対する１以上の代わりのルート（またはルート変更）を決定する。また、ルート決定エンジン３３２は、要求者が乗車した際に、その要求者の単独の乗客の送迎と比較した、運転手の予測されるルートまたは変更される可能性があるルートを計算するためにも用いられ得る。

候補の運転手の車輌に既存の乗客がいない場合には、ライドシェア推定器３３０は、単独の乗客としての要求者に対して開始された送迎に対して生じ得る延長を決定し得る。生じ得る延長は、要求者の送迎が進行中に別の乗客が乗車する確率を考慮し得る（後続の乗車の結果、要求者の送迎完了時間または全体的な距離が延長され得る）。幾つかの変形例では、確率は、履歴情報３４３から決定され得る。更に、ライドシェア推定器３３０は、確率ではなく、妥当な最悪のケースの筋書（例えば、要求者の送迎中のある時点で新たな乗客が加わり、時間または持続時間の延長が最大化される等）を推測し得る。同様に、幾つかの例では、推定は、履歴情報３４３の統計的解析または確率解析から決定され得る。

幾つかの変形例では、ライドシェア制約３３７の一部または全てを決定するために、履歴情報３４３が用いられ得る。例えば、時間または距離に関する許容可能な逸脱が、所与の地理的領域および／または時間間隔におけるライドシェア輸送についての送迎完了時間または距離に対する以前のデータを平均すること、および／または統計的解析を行うことから決定され得る。

変形例に応じて、ライドシェア制約３３７は静的なものであってもよく（例えば、既存の乗客に対して許可されている延長に関して、または、要求者についての単独の乗客の輸送と比較した追加時間に関して、５分間に固定されている）、動的なものであってもよく（例えば、事象（例えば、交通条件等）および／または供給もしくは需要に基づいて変化する）、または公式に基づくものであってもよい。更に、幾つかの例は、ユーザ（例えば、乗客）が、例えば、輸送シェア要求３０１を行う際等に、制約３３７を指定することを可能にする。例えば、乗客は、輸送シェアについての追加時間が、単独の輸送サービスと比較して、設定された分数を超えないことを条件として、輸送シェア要求についての要求を指定し得る。

幾つかの例によれば、着信乗客輸送要求３０１が受信された際、ライドシェアマッチング構成要素３２０は、その輸送要求に対する運転手を選択するために、ライドシェア推定器３３０と組み合わされる。１つの実装例において、ライドシェアマッチング構成要素３２０は、要求パラメータ３１１（例えば、乗車位置および降車位置）を用いて、その要求に対する適切なライドシェア輸送を選択する。図３の例では、ライドシェアマッチング構成要素３２０は、リアルタイム運転手状況ストア３１５をクエリーして、運転手の候補セット３０５を取得する。運転手の候補セット３０５は、（運転手状況情報１１９に基づいて）利用可能な運転手であって、（運転手位置３０９に基づいて）要求者または乗車位置までの閾値近さ以内にいる運転手を含み得る。

この例を更に進めると、候補セット３０５のどの運転手がライドシェア制約３３７を満たすかを決定する際に、ライドシェアマッチング構成要素３２０は、ライドシェア推定器３３０によって提供される１以上のライドシェア推定３１９を用い得る。１つの実装例において、ライドシェア推定３１９（例えば、予測送迎完了時間、最悪のケースの送迎完了時間等）の決定のために、所与のライドシェア要求者３０１についてのライドシェア情報３１３がライドシェアストア３３９に格納される。幾つかの例によれば、ライドシェアストア３３９は、実際のライドシェア輸送ではなく、見込みのあるまたは仮定上のライドシェア輸送を反映し得る。見込みのあるまたは仮定上のライドシェア輸送は、例えば、候補セット３０５の各運転手が、要求者に対するライドシェア輸送を提供するために選択されたとした場合に、その運転手によって示される時間または距離の逸脱を計算するために用いられ得る。要求者に対応するために必要な時間または距離の逸脱は、候補セット３０５のうちの１つの車輌を別の車輌に対して重み付け、ランク付け、または別様で選択するために用いられ得る。

ライドシェア情報３１３は、要求者の送迎についての乗車位置および降車位置、並びに候補の運転手３０５に関する情報（例えば、現在位置および／または目的地、送迎のために計画されたルート等）を含むライドシェアパラメータ３４７を指定し得る。ライドシェア推定器３３０は、ルート決定エンジン３３２にアクセスして、候補の運転手３０５に対して進行中である活動中の送迎の既存のまたは計画されたルートに対する最適な変更を決定し得る。幾つかの例は、候補の運転手３０５の少なくとも一部について、既存の活動中のルートに対する変更または逸脱が、別の乗客（例えば、要求者）の追加のための時間の延長を決定するために用いられるものとする。他の例では、ルート決定エンジン３３２は、単独の乗客の輸送についての所与の輸送要求３０１に対する可能性のあるルートを決定するために用いられ得る。履歴情報３４３は、制約３３７の下で、要求者の送迎がシェアになる確率を決定するために用いられ得る。或いは、要求の送迎がライドシェアになるという仮定が行われ得る。いずれのケースでも、要求者の送迎がライドシェアになる場合には、代わりのルートが予測され得る。この代わりのルートは、要求者の送迎が開始された後でライドシェアが生じた場合の、要求者の送迎のための時間または距離の延長を決定するために用いられ得る。

１つの実装例において、ライドシェアマッチング構成要素３２０は、運転手の候補セット３０５のどの運転手がライドシェア制約３３７を最良に満たすかを決定するための処理を実装する。例えば、複数の運転手が制約３３７を満たす場合には、更なる選択基準が用いられ得る。更なる選択基準の例は、（ｉ）ライドシェア要求３０１によって指定されている乗車位置までの時間が最小の運転手、（ｉｉ）要求者または既存の乗客に対して最小延長時間または距離でライドシェア輸送を提供できる運転手、および／または（ｉｉｉ）要求者に、時間／距離の制約以内のライドシェアについての単独の時間の最長持続時間を提供する可能性が最も高い運転手を含み得る。

その代わりに、またはその変形として、ライドシェアマッチング構成要素３２０およびライドシェア推定器３３０は、１以上の制約３３７に基づいて候補セット３０５の運転手をランク付けまたは重み付けするための処理を実装するために組み合わされる。例として、後者のケースについては、複数の運転手が全てのライドシェア制約３３７を満たす場合には、輸送要求３０１に対して運転手を選択するために、ライドシェア制約３３７から決定された更なる選択基準が用いられ得る。幾つかの例によれば、選択された運転手は、車輌内に少なくとも１名の乗客を有する運転手であって、その運転手の既存の送迎が、要求者または既存の乗客のライドシェア輸送のための追加時間または追加距離に関して最小量のコンフリクトを示す運転手に対応し得る。従って、例えば、要求者に対して選択される運転手は、要求者によって指定されているのと同じ降車位置まで送迎中である運転手に対応し得る。更に、他の変形例において、特定の運転手の選択は、例えば、運転手がライドシェア要求３０１によって指定されている乗車位置に到着するための到着時間を最小化する等の要因に基づき得る。

更に、図３の例は、ライドシェアマッチング構成要素３２０が、例えば、図５Ａの１以上の例で説明したような選択処理を実装するものとしている。候補セット３０５から運転手が選択された際、ライドシェア割当て３３３がリアルタイム運転手状況ストア３１５に通信され得る。１つの実装例において、ライドシェア割当て３３３は、運転手のレコードを、新たに割り当てられたライドシェア輸送にリンクし、新たな乗車位置を識別し、その乗客の車輌内の乗客数を更新し、新たに追加されたライドシェア輸送についての降車位置を追加または識別する。また、ライドシェアストア３３９は、所与の地理的領域内における個々の運転手についての特定の瞬間のライドシェア割当てを反映する該当するリアルタイムのレコードのインスタンスも表し得る。

図４Ａおよび図４Ｂは、シェアされた輸送サービスを提供するための例示的なインターフェースを示す。様々な実装例によれば、（例えば、図２Ａの例で説明したような）ネットワークサービスから通信されたデータを用いて、（例えば、図２Ｂの例で説明したような）モバイルコンピューティング装置上に輸送要求インターフェース４１０（図４Ａ）およびライドシェアインターフェース４５０（図４Ｂ）が設けられ得る。

図４Ａの例では、サービスのアプリケーション１１２の実行の一部としてまたはそれと共に、クライアント装置１０２上に輸送要求インターフェース４１０が設けられまたは生成される。一例では、輸送要求インターフェース４１０は、個人が選択機構４０６を用いて輸送サービスの選択を行うことを可能にする。提供される輸送サービスは、ライドシェアサービス４０７、および他のタイプまたはレベルのサービスを含み得る。

選択を行う際、ユーザは、乗車位置４０２および降車位置４０３を指定し得る。ユーザは、例えば、指定されている乗車位置４０２（これは、多くのケースではユーザの現在位置であり得る）を用いて輸送要求トリガするための機能４０４を用い得る。図示されている例では、輸送要求は、ユーザが機能４０４を介して選択を行うまで開始されない。機能４０４が選択される前には、要求インターフェース４１０はサービス固有情報４０５ａを含み得る。或るライドシェアサービスについて、サービス固有情報４０５ａは、その時間に輸送手配サービスを介して提供される所与のライドシェアにおいて乗車し得る人の最大数を識別し得る。

図４Ｂの例では、ライドシェアインターフェース４５０は、ライドシェア輸送サービスが選択または要求されたときの、送迎完了時間予測４０８を含み得る。送迎完了時間予測４０８は、例えば、図５Ｂの例で説明したような処理を用いて、例えば、目的地位置４０３から決定され得る。幾つかの例によれば、送迎完了時間予測４０８は、（ｉ）ユーザが（例えば、ライド要求インターフェース４１０を介して）輸送要求を行う前、（ｉｉ）ユーザが、例えば、輸送要求インターフェース４１０の機能４０４を用いて最初のライドシェア要求を行った後であり、ライドシェア要求を確定する前、（ｉｉｉ）ユーザが、例えば、輸送要求インターフェース４１０の機能４０４を用いて最初のライドシェア要求を行い、ライドシェア要求を確定した後であり、輸送が乗車位置に到着する前、および／または（ｉｖ）ライドシェア輸送を用いたユーザの送迎中（例えば、ユーザが既に車輌に乗車して、運転手が既に輸送サービス開始しているとき）に表示され得る。

迎車が到着する前に、ユーザインターフェース上において送迎完了時間予測４０８が提供される例では、送迎完了時間予測４０８の値は、図５Ｂの例で説明されるように、ライドシェアについての送迎完了時間、および適切なライドシェア車輌についての推定乗車時間に基づいて計算され得る。幾つかの例では、適切なライドシェア車輌についての乗車時間を決定するために、履歴情報が用いられ、送迎完了時間予測４０８は、ライドシェアが開始したときの、推定乗車時間と送迎完了時間との合計を表示する。

輸送シェアサービスは、ユーザに対してより低料金の輸送を提供し得ると共に、運転手に対してより高い効率を提供し得るが、ライドシェアは、乗客を所望の降車位置まで送るために、より長い時間がかかり得る。この点に関して、従来の手法では、ライドシェアサービスでは、乗客は、所与の送迎についての完了時間がわからないので、ライドシェアサービスは魅力的でない選択になり得る。複数の例は、乗客がライドシェア制約（具体的には、送迎完了時間）に気づいていない場合、たとえライドシェアが乗客を許容可能な時間枠内に降車位置に送るものであったとしても、不確実性が、乗客に単独の輸送を選択させ得ることを認識したものである。

従来の手法とは対照的に、図４Ａおよび図４Ｂの例は、ライドシェアサービスが要求されたときに、ユーザが送迎完了時間に関して予測可能性を有することを可能にする。送迎完了時間予測４０８は、乗客が輸送要求を行う前に、乗客に対して、例えば、以下のタイプの情報のうちの任意の１つを表示し得る。（ｉ）ライドシェアについての送迎完了時間、（ｉｉ）信頼性の高いまたは保証された最悪のケースの筋書での送迎完了時間の範囲（例えば、２５分間〜３４分間）、（ｉｉｉ）ライドシェアの運転手についての乗車させるための時間および送迎完了時間を考慮した送迎到着時間（範囲および／または最悪のケースを含む）、および／または（ｉｖ）ライドシェアまたは他のタイプの手配された輸送（単独の輸送を含む）の選択肢間の、到着時間および送迎完了時間の両方についての時間の差分。幾つかの変形例では、完了時間または到着時間も価格情報に相関され得るものであり、送迎完了時間予測４０８は、例えば、送迎到着時間、料金価格、車種等の情報の比較を提供し得る。

図４Ａおよび４Ｂの例は、ライド要求が行われた後で表示されるインターフェースの送迎完了時間予測４０８を示しており、複数の変形例は、送迎完了時間予測４０８が、輸送要求が行われる前にユーザに対して表示されるものを含む別のインターフェース上に表示され得るものとしている。そのような変形例では、送迎完了時間予測４０８は、見込みのある乗客−運転手ペアリング（例えば、送迎完了時間予測４０８の値を計算する目的で、ユーザは、輸送要求を受信する可能性の高い運転手とペアリングされると仮定される）または仮定上の乗客−運転手ペアリング（例えば、履歴情報および確率に基づくものであり、ペアリングを受信し得る実際の運転手は考慮しない）に基づく情報を含み得る。

方法論
図５Ａは、輸送シェア提供者を輸送シェア要求とマッチングするための例示的な方法を示す。５Ｂは、所与の送迎についての送迎完了時間を予測するための例示的な方法を示す。幾つかの態様によれば、図５Ａおよび図５Ｂの例は、例えば、サービス２００を用いたおよび／またはクライアント装置１０２に関連した、輸送手配システム１００の一部として実装され得る。更に、図５Ａおよび図５Ｂの例を説明する際に、記載されるステップまたはサブステップを行うための適切な構成要素または要素を例示する目的で、図１〜図４Ｂの例を参照する。

図５Ａの例では、ライドシェアトリガが検出される（５１０）。ライドシェアトリガは、乗客のクライアント装置１０２から生成された輸送シェア要求に対応し得る（５１２）。ライドシェアトリガは、例えば、乗客の輸送が開始する場所についての乗車位置、要求者の現在位置、および／または輸送の降車位置等といった１以上のパラメータを含み得る。

トリガに応答して、輸送手配システム１００は、輸送提供者（例えば、運転手クラスユーザ）を選択する。この決定は、（例えば、シーケンス化された、または反復処理である）マルチ決定シーケンスの一部として実装され得る。１つの実装例において、輸送手配システム１００は、ライドシェアに対する、乗車位置までの閾値以内にいる運転手の候補セット３０５を識別する（５２０）。この閾値は、所与の車輌が乗車位置に到着するための所定の距離または持続時間に対応し得る。

提供者の候補セットには、１以上のフィルタリング処理または重み付け処理が行われ、それによって提供者の１以上の選択が行われ得る。この処理は、距離または時間の閾値を満たす個々の車輌に対する１組の制約の適用を含み得る（５３０）。制約３３７は、輸送トリガの乗客に対してライドシェア輸送を提供するための特定の車輌の好適性に関する規則または条件として実装され得る。一例において、候補セットの提供者の好適性を決定するための１組の制約は、（ｉ）実際の乗客数と比較した、１つの車輌内で輸送可能な乗客数（５３２）、（ｉｉ）提供者が輸送トリガの乗客に対応するために要する（例えば、距離または時間の）逸脱の大きさ（５３４）、（ｉｉｉ）輸送トリガの乗車位置に到着する際の、特定の提供者の計画されたまたは既存の送迎に基づいて別様でとられるルートと比較した、輸送要求者が輸送トリガの乗客に対応するために要する（例えば、距離または時間の）逸脱の大きさ（５３６）を含む。

幾つかの例では、制約の適用は決定力のあるものである。例えば、制約は、候補セットから提供者をフィルタリングによって除外し得る。変形例において、制約の一部または全てを適用することは、提供者を、選択に好適または不適であるとして重み付けし得る。例えば、制約の一部または全ての実装はスコアまたは１組のパラメータ値を反映するよう定量化され、それらに基づいて、個々の提供者が輸送要求とマッチングされ得る。

より詳細には、（５３２）、（５３４）、および（５３６）の各制約の適用は、様々な変形を含み得る。（５３２）の制約の適用が決定力のあるものとして実施される場合には、輸送手配システム１００は、候補セットから、送迎中であり最大数の乗客を有する提供者をフィルタリングによって除外し得る。例えば、幾つかの例では、制約は、２名の乗客を運ぶための提供者の車輌を制限し得る（このケースでは、候補セットのうち、トリガが受信された時間に２名の乗客を有する提供者が、候補セットから除外される）。変形例において、乗客の最大数についての制約は、（例えば、ＳＵＶ等のより大型の車輌については）２名を超えてもよく、考慮中の提供者の車輌内に存在する乗客数は、そのまま望ましさまたは結果となり得る。例えば、３名の乗客に対応できる車輌において、輸送要求のために考慮されている際に２名が存在する車輌は、乗客がいない同等の車輌より低いスコア（または選択に不適）となり得る。

幾つかの例では、逸脱（５３４）および／または（５３６）は、候補セットのうち、少なくとも１名の乗客を運んでおり、もう１名の乗客のための余地がある（５３２）輸送提供者について決定され得る。変形例において、逸脱は、別の乗客がその車輌をシェアするという予測に基づいて、候補セットのうち、複数の乗客に対する利用可能性を有する（例えば、最大乗客数が２名である場合に、乗客がいない）輸送提供者について計算され得る。後者のケースでは、逸脱は予測パラメータを表す。

（５３４）または（５３６）のいずれかにおいて、（トリガが受信されたときに、候補セットの或る輸送提供者の車輌内に１名以上の乗客が存在するという仮定の下で）特定の輸送提供者についての逸脱を決定する際に、輸送手配システム１００は、既存の乗客の降車位置および輸送要求のパラメータ（例えば、乗車位置および降車位置）に対応しつつ、候補の車輌の既存のルートからの最小量の逸脱を提供する代わりのルートを決定し得る。幾つかの例によれば、ルート決定エンジン３３２は、候補セットの提供者の車輌について、変更されたルートを決定し得る。ルート決定エンジン３３２は、ルート計画制約に基づいて、変更されたルートが候補セットの車輌の既存のルートを部分的に含む、またはそれと部分的に重なるように、変更されたルートを決定し得る。１つの実装例において、考慮中の車輌の１以上の既存の乗客について、変更された送迎完了時間および／または逸脱距離が決定される。それに加えて、またはその代わりに、輸送要求ついて、送迎完了時間および逸脱距離は、その輸送要求と関連づけられたパラメータに基づいて決定されてもよく、送迎完了時間および／または距離の逸脱は最適な時間と比較されてもよい。

（５３２）、（５３４）、および／または（５３６）の決定は、輸送シェア要求に対する提供者を選択するために用いられ得る（５４０）。実装に基づき、決定は、候補セットから運転手をフィルタリングによって除外、候補セットの運転手をランク付け、および／または候補セットの個々の運転手についての選択スコアを重み付けし得る。例えば、候補セットの、既存のそれぞれの乗客についての時間または持続時間の制約を満たさない運転手は、候補セットから除外され得る。選択処理は、ランク付けまたはスコアを、例えば、運転手が乗車位置に到着するための近さまたは送迎完了時間等の他の態様と共に用い得る。

図５Ｂを参照すると、例えば、乗車位置および降車位置を指定するパラメータを有する輸送シェア要求（５５０）から、ライドシェアトリガが検出される（５１０）。輸送要求から、推定送迎完了時間が決定され得る（５６０）。様々な例で説明されるように、推定送迎完了時間は、（ｉ）最良のケース（例えば、ライドシェアに他の乗客がいない）、（ｉｉ）最悪のケース（例えば、新たな乗客が加わる最大数のライドシェア）、（ｉｉｉ）最良のケースおよび最悪のケースの送迎完了時間の範囲、および／または（ｉｖ）最良のケースおよび最悪のケースの時間の平均のうちのいずれか１つを含む様々な形態を有し得る。送迎完了時間を決定する文脈において、ライドシェアトリガは、輸送シェア要求の一部として、または対応する要求から独立して、要求者が生成する要求に対応し得る（例えば、乗客は、ライドシェアサービスの要求を行う前に、ライドシェアサービスについての推定送迎完了時間を要求する）。更に、ライドシェアトリガは、要求者に対して割り当てられているまたは選択されている運転手に対応してもよく、ユーザに対して推定送迎完了時間または範囲が表示されるようになっていてもよい。

１つの実装例において、推定送迎完了時間は、実際のサービス情報（５６２）（例えば、所与の領域内にいる運転手の運転手位置情報１０９Ｄおよびサービス状況情報１１９Ｄによって提供される情報等）を用いて決定される。変形例において、推定送迎完了時間は、ライドシェア供給情報および／または履歴情報３４３に基づいて選択を行う処理を含むシミュレーションされた選択処理（５６４）から決定され得る。

シミュレーションされた選択処理に関して、幾つかの実装例では、見込みのある運転手が、要求者の追加後に、最大数より少ない乗客を有する場合には、送迎完了時間は、制約（５３２）〜（５３６）の適用の文脈において、見込みのある追加の乗客（１名または複数）が追加される最悪のケースの筋書の考慮を含み得る。複数の例は、ライドシェアリングにおいて、制約の適用が、例えば、要求者に対して計画されたルートに追加の乗客が追加された場合等の要因に基づいて、異なる結果を生じ得ることを認識したものである。幾つかの例では、（ｉ）要求者の送迎に別の乗客が追加される尤度、および／または（ｉｉ）要求者の送迎に対する別の乗客の影響（例えば、新たな乗客に対応するための変更されたルートが要する時間および／または距離の量）を予測するために、履歴情報３４３が用いられ得る。

その代わりに、またはその変形として、最悪のケースは、送迎完了時間の少なくとも一部分を決定する際に、履歴情報３４３および／または生じ得る最悪の次の乗車を用い得る。履歴データは、地理的領域（例えば、市）、地理的領域内の場所（例えば、市の繁華街部分）、または街区を特定したものであり得る。履歴情報３４３は、地理的領域または場所についてのライドシェアリング測定指標（例えば、ライドシェアの数、ライドシェア毎の乗客数、および／または個々のライドシェアについての手系的な逸脱等）を考慮し得る。より一般的には、履歴情報は、供給（ライドシェアの供給を含む）および需要を反映し得る。変形例において、履歴情報は、曜日、時刻、または他のパラメータにも相関され得る。

従って、提供されている例で説明したように、輸送手配システム１００は、実際の送迎（例えば、要求されている）または仮定上の送迎（例えば、ユーザが、要求を行う前に推定された到着時間を欲する場合）についての予測送迎完了時間を計算する。予測送迎完了時間は、要求者の追加によって既存の送迎が変更される、乗客と実際の運転手との見込みのあるペアリングに基づいてもよい。予測送迎完了時間は、乗客のルートおよびライドシェアに対する影響が履歴情報３４３の統計的解析に基づく、仮定上のペアリングに基づいてもよい。

幾つかの実装例では、輸送手配システム１００、３００は、要求者からの輸送シェアリング要求３０１を遂行するための１名以上の候補の運転手３０５を選択する。候補の運転手３０５の選択は、例えば、要求者についての最悪のケースの送迎完了時間が所定の制約を超えない（例えば、最悪ではないケースと比較して、閾値の分数または持続時間を超えない）ことを必要とする制約等の制約３３７を受け得る。輸送手配システム１００、３００は、選択された運転手を輸送シェア要求に割り当て得る。変形例において、輸送手配システム１００、３００は、要求を行っているユーザに対して、ユーザの選択を容易にするために、推定送迎完了時間の表示を有する利用可能な輸送提供者のリストを表示し得る。

他の変形例において、要求者は、ライドシェア要求についての時間の制約を指定し得る。例えば、要求者は、ライドシェア輸送が、乗客単独の輸送で受け得る時間から５分間を超えて延長されないことを指定し得る。同様にして、要求者は、距離についての制約を指定し得る。乗客によって指定された制約は、輸送手配システム１００、３００のデフォルト設定よりも大きくてもよく、または小さくてもよい。

幾つかの例によれば、車輌の既存の乗客には、ルートに追加され得る追加の乗客を反映するよう更新された推定到着時間が提供され得る。更に、変形例において、推定送迎完了時間は、要求者および／または既存の乗客についての変更されたルートの逸脱に基づく時間遅延の推定を組み込み得る。

本明細書に記載されている実施形態は、本明細書に記載されている他の概念、アイデア、またはシステムから独立して、本明細書に記載されている個々の要素および概念にまで及ぶと共に、例えば、本願のどこかに記載されている要素の組合せを含むことが意図される。本明細書には、添付の図面を参照して複数の実施形態が詳細に記載されているが、本発明は、それらの正確な実施形態に限定されないことを理解されたい。従って、当業者には、多くの変更および変形が自明である。従って、本発明の範囲は、以下の特許請求の範囲およびそれらの等価物によって定められることが意図される。更に、個々にまたは実施形態の一部として記載された特定の特徴は、たとえ他の特徴および実施形態がその特定の特徴に言及していなくても、他の個々に記載された特徴または他の実施形態の一部と組み合わされ得ることが意図される。従って、組合せが記載されていないことによって、本発明がそのような組合せを特許請求する権利を有することを除外すべきではない。

１００、３００ 輸送手配システム
１０１ サーバ
１０２、１０２Ｒ、１０２Ｄ クライアント装置
１０４、２１４ 通信ネットワーク
１０５ 輸送シェアリング論理
１０９Ｒ、１０９Ｄ 位置情報
１１２ サービスアプリケーション
１１９Ｒ、１１９Ｄ サービス状況情報
２００ 輸送手配サービス
２０１ プロセッサ
２０２ メモリ
２０３ ディスプレイ装置
２０４ 入力機構
２０５ 通信インターフェース
２２５、３２０ ライドシェアマッチング構成要素
２２７ 送迎完了時間予測器
２６６、４５０ ライドシェアインターフェース
３３０ ライドシェア推定器
３３２ ルート決定エンジン

Claims (15)

1. サービスの１以上のプロセッサによって指示が実行された際に、該サービスに、
   乗客から、乗車位置および降車位置を含む１組のパラメータを指定している輸送シェア要求を受信する工程と、
   前記乗車位置に対する近さの基準を含む１以上の基準を満たす輸送提供者の候補セットを識別する工程と、
   前記乗客に輸送シェアを提供するための、前記候補セットのうちの１つの候補を選択する工程であって、前記乗客の前記輸送シェアのための前記輸送提供者を選択することが、前記候補セットの個々の運転手のうちのどの運転手が、前記乗客についての予測送迎完了時間に関する第１の制約を含む１以上の制約を満たすかを決定することを含む、工程と
   を含む処理を行わせる指示を格納したことを特徴とする非一過性コンピュータ可読媒体。
2. 前記第１の制約が、前記１組のパラメータに基づく単独の輸送についての送迎完了時間と比較した、前記乗客についての前記予測送迎完了時間に対する制限を設定する、請求項１記載の非一過性コンピュータ可読媒体。
3. 前記制限が、前記予測送迎完了時間と前記単独の輸送との間の送迎完了時間の延長に少なくとも部分的に基づく、請求項２記載の非一過性コンピュータ可読媒体。
4. 前記予測送迎完了時間が、最悪のケースの送迎完了時間に基づくまたは対応する値を含む、請求項２記載の非一過性コンピュータ可読媒体。
5. 前記１以上のプロセッサによって指示が実行された際に、前記サービスに、
   前記予測送迎完了時間を少なくとも部分的に履歴情報から決定する工程
   を含む処理を行わせる指示を更に含む、請求項４記載の非一過性コンピュータ可読媒体。
6. 前記予測送迎完了時間を決定する前記工程が、履歴情報を用いて前記最悪のケースの送迎完了時間を決定することを含む、請求項１記載の非一過性コンピュータ可読媒体。
7. 前記１以上のプロセッサによって指示が実行された際に、前記サービスに、
   前記乗客が前記選択された運転手から前記輸送シェアを受ける際に、前記予測送迎完了時間を用いて、（ｉ）前記乗客の前記降車位置までの推定到着時間もしくは持続時間、または（ｉｉ）最悪のケースの到着時間または最悪のケースの送迎完了時間を識別する時間の値もしくは範囲のうちの少なくとも一方に対応する値を表示する工程
   を含む処理を行わせる指示を更に含む、請求項６記載の非一過性コンピュータ可読媒体。
8. 前記乗客が前記輸送シェア要求をトリガする前に、前記値がインターフェース上に表示される、請求項７記載の非一過性コンピュータ可読媒体。
9. 前記乗客が前記輸送シェア要求をトリガした後、および／または、前記乗客が前記輸送シェア要求を受けている間に、前記値がインターフェース上に表示される、請求項７記載の非一過性コンピュータ可読媒体。
10. 前記乗客の前記輸送シェアのための前記輸送提供者を選択する前記工程が、前記候補セットの個々の運転手のうちのどの運転手が、前記選択された輸送提供者の既存の乗客の送迎完了時間に対する延長に関係する第２の制約を満たすかを決定することを含む、請求項１記載の非一過性コンピュータ可読媒体。
11. 前記候補セットの個々の運転手のうちのどの運転手が１以上の制約を満たすかを決定する前記工程が、前記候補セットの既存の各乗客についての延長を決定するために、複数の運転手の既存の乗客についての代わりのルートを決定することを含む、請求項１０記載の非一過性コンピュータ可読媒体。
12. 前記代わりのルートを決定する前記工程が、前記乗客の前記輸送要求についての前記乗車位置または前記降車位置のうちの少なくとも１つに対応するための、前記複数の運転手のうちの各運転手の既存のルートに対する逸脱を決定することを含む、請求項１１記載の非一過性コンピュータ可読媒体。
13. 前記１以上の制約が、前記候補セットの車輌において許可されている最大乗客数を含む、請求項１記載の非一過性コンピュータ可読媒体。
14. １以上のプロセッサによって実装される、輸送手配サービスを運営する方法において、
    乗客から、乗車位置および降車位置を含む１組のパラメータを指定している輸送シェア要求を受信する工程と、
    前記乗車位置に対する近さの基準を含む１以上の基準を満たす輸送提供者の候補セットを識別する工程と、
    前記乗客に輸送シェアを提供するための、前記候補セットのうちの１つの候補を選択する工程であって、前記乗客の前記輸送シェアのための前記輸送提供者を選択することが、前記候補セットの個々の運転手のうちのどの運転手が、前記乗客についての予測送迎完了時間に関する第１の制約を含む１以上の制約を満たすかを決定することを含む、工程と
    を含むことを特徴とする方法。
15. 輸送サービスを提供するためのシステムにおいて、
    指示を格納するメモリと、
    前記格納されている指示を実行するプロセッサであって、
    乗客から、前記乗車位置および降車位置を含む１組のパラメータを指定している輸送シェア要求を受信する指示と、
    前記乗車位置に対する近さの基準を含む１以上の基準を満たす輸送提供者の候補セットを識別する指示と、
    前記乗客に輸送シェアを提供するための、前記候補セットのうちの１つを選択する指示であって、前記乗客の前記輸送シェアのための前記輸送提供者を選択することが、前記候補セットの個々の運転手のうちのどの運転手が、前記乗客についての予測送迎完了時間に関する第１の制約を含む１以上の制約を満たすかを決定することを含む、指示と
    を実行するプロセッサと
    を含むことを特徴とするシステム。

Images