JP2016509287A - 車両管理システム - Google Patents

Abstract

複数の車両要求デバイス１２、並びに各々がルート計画機能性及びナビゲーション機能性を有するデバイス２００を装備する複数の車両１４と通信するように構成されたサーバ１０を有する車両要求管理システム。車両要求を受信した時点で、車両要求の既存のクラスタがその要求に関連している場合、サーバはその要求を車両要求の既存のクラスタに割り当てる。車両要求が既存のクラスタに関連していない場合、車両要求は新たなクラスタを生成するために使用される。既存の車両要求の乗車場所に対する新たな車両要求と関連する乗車場所の近接度に基づいて、新たな車両要求と既存のクラスタの車両要求との関連性が評価される。関連性は、クラスタと関連する領域内の車両要求の地理的密度及び時間的密度に基づいて選択されるパラメータを使用して評価される。クラスタと関連する最も古い要求の経過年数に関連する閾値又は最大サイズ閾値にクラスタが適合する場合、その要求を遂行するために車両を各車両要求とマッチングするために、クラスタ中の車両要求はマッチング処理される。

Description

本発明は、ユーザによるタクシー又は他の類似する輸送形態に対する要求などの車両要求を管理する方法及びシステムに関する。特に、本発明は、車両要求を遂行するために車両要求を車両とマッチングする方法及びシステムに関するが、それに限定されない。

近年、スマートフォンなどの場所認識移動デバイスが一般に広く使用されるようになってきたことに伴い、タクシーの手配時及び要求時に経験する問題を改善するために、いくつかのソフトウェアアプリケーション（すなわち「アプリ」）が作られている。その例は、Ｈａｉｌｏ−ｈｔｔｐ：／／ｈａｉｌｏｃａｂ．ｃｏｍ、ｍｙＴａｘｉ−ｈｔｔｐ：／／ｗｗｗ．ｎｙｔａｘｉ．ｎｅｔ／及びＴａｘｉ Ｍａｇｉｃ−ｈｔｔｐ：／／ｔａｘｉｍａｇｉｃ．ｃｏｍなどである。

場所認識移動デバイス、例えばＧＮＳＳ（全地球的航法衛星システム）信号受信及び処理機能性を有する移動デバイスでこのようなアプリを使用することによって、ユーザ自身が周囲の環境を認識していない場合でも、ユーザは容易にタクシーを現在場所まで呼ぶことができる。

例えばＨａｉｌｏアプリの場合、ユーザは、自身の移動デバイスで、ユーザの現在場所を中心とするマップの中に表示され、このマップは、ユーザの現在場所に最も近接する場所にある利用可能タクシーのリアルタイム場所及び各タクシーがその場所に到着するまでに要する推定時間を示す。この情報は、各タクシーの場所認識デバイスから定期的に更新情報を受信するサーバシステムからダウンロードされる。ユーザは、デバイスのタッチスクリーン上のタクシーを表すアイコンをタッチすることによりタクシーを選択でき、その後、選択されたタクシーへサーバを介して手配要求が送信される。運転手がその手配要求を受け入れた場合、確認メッセージがユーザへ送信される。ユーザは、運転手の顔写真、運転手と関連するユーザ評価、選択されたタクシーの詳細及びタクシーが乗車場所に到着する時刻までのリアルタイムカウントダウンを更に提供される。タクシーの遅延を発生させる可能性がある交通事情、道路工事及び他のその種の事象を考慮しないので、この到着時刻は推定である。ユーザは、選択されたタクシーが乗車場所に近づくまでのタクシーの現在位置をマップ上で見ることもできる。タクシーが乗車場所に到着したことを示す通知が同様にサーバを介してユーザへ送信される。クレジットカードの詳細が事前にサーバのアカウントと関連付けられていると想定した場合、走行が完了した後、ユーザはクレジットカード又は類似の形の現金払いではない方法で、それまでの走行に対して料金を支払うことができる。その後、ユーザは、走行の詳細及び支払った金額の受領を確認するメッセージをサーバから受信する。ユーザは、走行完了の後に運転手を評価する機会を得ることもできる。

タクシー要求に関連して、場所認識デバイスを使用することによって改善がなされたにもかかわらず、車両要求を管理する方法及びシステムを更に改善する余地は残されていると出願人は考える。特に車両要求が、例えばタクシーなどの車両とマッチングする方式に関連して、方法及びシステムを更に改善する余地は残されていると出願人は認識した。

本発明の第１の態様によれば、複数の車両の各々の現在場所を示すデータにアクセス可能なサーバで車両要求を管理する方法であって、
複数の車両要求をサーバで受信することと
複数の車両要求を各々が含む１つ以上のクラスタを生成することと、
このクラスタ又は各クラスタ中の各々の車両要求と車両をマッチングすることと
を備える方法が提供される。

本発明は車両要求を管理する方法に関する。方法は、複数の車両要求をサーバで受信することを含む。サーバは、複数の車両、例えばタクシーの各々の現在位置を知っている。まず、車両要求はクラスタに割り当てられ、車両は、クラスタごとに要求とマッチングされる。

少なくとも本発明のこの態様によれば、本発明は、車両要求と関連する場所、例えば所望の乗車場所に対する車両の現在位置の近接度を参照することにより、個別の要求ごとに、すなわち要求が受信されるたびに、車両を車両要求に割り当てるだけではない。単なる割り当てではなく、まず車両はクラスタ化され、クラスタごとに各クラスタ中の要求に車両が割り当てられる。従って、例えば所定のクラスタの中の第１の要求、すなわち最も早い要求でも、クラスタが「完成」するまで車両を割り当てられない。割り当ては、クラスタに割り当てられたすべての要求及びその関連場所を考慮に入れてもよいので、車両と要求とのマッチングを最適化することができる。これは、先に説明したアプリケーションのように、ユーザの現在場所に対するタクシーの近接度に基づいて、ユーザに対して表示された１つ以上の利用可能タクシーの中から１台のタクシーをユーザが選択することが可能である従来のシステムとは対照的である。他の従来のシステムでは、同様に、ユーザの現在位置に最も近接する位置にあるタクシーの現在場所に基づいて、そのタクシーが所定の要求に自動的に割り当てられてもよい。それらのシステムにおいて、タクシーは、他の要求を考慮せずに所定の要求に割り当てられる。

車両を要求に割り当てる、すなわち要求とマッチングする前に、車両要求を車両群にクラスタ化することにより、ユーザ、例えば要求側の待ち時間に関して更なる最適化が実現されるように、車両と要求とのマッチングを実行できることがわかっている。本明細書において説明される特定の基準に従ったクラスタを形成する要求群が受信されるまで待ち、その後、そのクラスタの中の要求に車両を割り当てることにより、要求及び利用可能車両をより高いレベルで概観できるので、ユーザの平均待ち時間は改善される。このように、本発明は、各車両要求が最も近接する利用可能車両に個別にマッチングされる従来の技術と関連する特定の欠陥に対処してもよい。従来の方式では、ユーザによっては待ち時間が短くなるが、他のユーザに迷惑が及ぶ場合もある。そのようなシステムは、多数のユーザの平均待ち時間を短縮するということに関して最適とは言えない。本発明のクラスタ別システムは、例えば車両要求を遂行するために車両の運転手が走行しなければならない距離とユーザの待ち時間とのバランスをとることにより、車両ユーザのニーズと車両の運転手のニーズとのバランスを更に改善することが可能である。これは、要求ごとに最も近接する車両が車両要求に割り当てられ、その結果、一人の運転手は乗車場所まで短い距離を走行するだけでよいが、次は希望に反して長距離を運転しなければならなくなるかもしれず、同じことがユーザの待ち時間に関しても起こりうるようなシステムとは対照的である。

更に、本発明の第２の態様によれば、複数の車両の各々の現在場所を示すデータにアクセス可能なサーバを備える車両要求管理システムであって、サーバは、
複数の車両要求を受信するように構成された通信手段と、
複数の車両要求を各々が含むような１つ以上のクラスタを生成するように構成された処理手段と、
このクラスタ又は各クラスタ中の各々の車両要求と車両をマッチングするように構成された処理手段と
を備える車両要求管理システムが提供される。

この第２の態様において、本発明は、本発明の第１の態様に関連して説明される特徴のいずれか又はすべてを互いに矛盾しない程度に含んでもよく、逆に、第１の態様において、本発明は、第２の態様に関連して説明される特徴のいずれか又はすべてを互いに矛盾しない程度に含んでもよい。従って、本明細書に明示して述べられない場合、本発明のシステムは、先に説明した方法のステップのいずれかを実行する手段を備えてもよい。

コンピュータ実現方法のステップのいずれかを実行する処理手段は、それを実行するように構成された、例えばプログラムされた１つ以上のプロセッサより成るプロセッサの集合を備えてもよい。所定のステップは、他のいずれかのステップと同一のプロセッサの集合により実行されてもよいが、異なるプロセッサの集合により実行されてもよい。所定のステップは、プロセッサの集合の組み合わせを使用して実行されてもよい。

実施形態のいずれかにおいて、本発明は、どの車種の車両に関しても車両と車両要求とのマッチングに適用可能である。車両は、１人以上の乗客を乗車場所から降車場所まで送り届けるために運転手と共に要求可能な車両であるのが好ましい。特に好適な実施形態において、車両はタクシー又はそれに類似する形の輸送形態である。車両は、タクシー、セダン、リムジン又は他の動力車両のような自動車であってもよい。他の実施形態において、車両は自転車又は人力車のような人力車両であってもよい。

先に説明したように、本発明は車両要求管理システムに関する。言い換えれば、人物、通常は複数の異なる人物が特定の場所（「乗車場所」）で、場合によっては更に特定の時刻にその人物が乗車するための車両を求める要求を行うことができるシステムである。システムは、各要求に１台の（又は場合によっては複数台の）車両を割り当てるために使用される。本発明の車両要求システムは、大きな街及び都市などでタクシー要求を管理するために特に適用可能であるが、どのような種類の車両要求に対しても、システムを適宜使用できることは理解されるだろう。

方法は複数の車両要求をサーバで受信することを備え、システムは複数の車両要求を受信する通信手段を有するサーバを備える。本明細書において「サーバ」という場合、適切な何らかの中央制御装置が使用されてもよく、「サーバ」への参照は「中央制御装置」への参照と置き換えられてもよいことが理解されるだろう。

好適な実施形態において、複数の車両要求は、複数の第１のデバイスより成る集合から受信される。第１のデバイスは、車両要求を行うために使用される何らかの適切なデバイスであってもよい。例えば第１のデバイスは、パーソナルコンピュータ又は他の計算資源などの一定の場所にあるデバイスであってもよい。第１のデバイスは、ホテル、バー、レストラン、駅などの建物の中又は屋外の待ち合わせ場所に配置されるように構成され、通常は１つの乗車場所とのみ関連するデバイスであってもよい。しかし、好適な実施形態において、第１のデバイスは、移動電話、ＰＤＡ、タブレットコンピュータなどのユーザにより携帯可能な移動デバイスである。

本発明によれば、サーバは、複数の車両の各々の少なくとも現在場所を示すデータにアクセス可能である。各車両は車両要求を遂行するために利用可能な車両である。いくつかの実施形態において、サーバの通信手段は、複数の車両の各々の少なくとも現在場所を示すデータを受信するように構成される。方法は、サーバが複数の車両の各々の現在場所を示すデータを受信することを含んでもよい。サーバは、複数の車両の各々の少なくとも現在場所を示すデータを記憶するデータ記憶手段を備えてもよい。各車両は運転手と関連付けられるのが好ましい。従って、車両の位置は、運転手の位置に対応するとみなされてもよい。

サーバは、時間の経過に伴う各車両の位置に関連する位置データにアクセス可能であるのが好ましい。複数の車両の各々の現在場所を示すデータは、複数の第２のデバイスより成る集合の各デバイスの現在場所を示すデータであるのが好ましく、第２のデバイスの各々は対応する車両と関連付けられる。例えば第２のデバイスは、対応する車両の中に取り付けられるか、又は第２のデバイスの位置が車両の位置に対応するように何らかの適切な方式で車両と関連付けられてもよい。データは、時間の経過に伴う第２のデバイスの各々の位置に関連する位置データであるのが好ましい。サーバは、各々が車両と関連する複数の第２のデバイスより成る集合の中の各デバイスと通信するのが好ましい。サーバの通信手段は、複数の車両の各々の現在場所を示すデータと、好ましくは複数の第２のデバイスより成る集合の各デバイスの現在場所を示すデータとを受信するように更に構成されるのが好ましく、第２のデバイスの各々は、対応する車両と関連付けられる。サーバ、例えばサーバの通信手段は、時間の経過に伴う第２のデバイス、好ましくは第２のデバイスの各々の位置、従って第２のデバイスと関連する車両に関連する位置データを受信してもよい。

車両の現在場所を示すデータは、そのデータが関連する車両を示すデータと関連付けられるのが好ましい。車両を示すデータは、車両を直接又は間接的に識別してもよく、このデータにより、通信手段は、例えば車両要求を車両へ通信するために車両と通信できる。好適な実施形態において、車両を示すデータは、先に説明したように車両と関連付けられた第２のデバイスを示すデータにより提供される。車両を示すデータは、例えば車両の車種、大きさ又は他の属性を示す付加データを含んでもよい。これにより、以下に説明するように、多数の基準に関連させて、適切な車両への車両要求のマッチングを実行できる。

好適な実施形態において、システムはサーバを備え、サーバは、車両要求を行うために使用される複数の第１のデバイスより成る集合、及び送付された車両要求を遂行するために各車両と関連付けられる複数の第２のデバイスより成る集合と通信する通信手段を備える。第１のデバイスはユーザにより携帯されてもよく、第２のデバイスは車両に取り付けられてもよい。従って、実施形態において、車両要求管理システムは、複数の第１のデバイス及び各々が車両と関連付けられた複数の第２のデバイスと通信するように構成された通信手段を含むサーバを備える。複数の第１のデバイスは複数のそれぞれ異なる第１のデバイスであり、複数の第２のデバイスは複数のそれぞれ異なる第２のデバイスである。従って、サーバと、複数の第１のデバイスより成る集合及び／又は複数の第２のデバイスより成る集合とを適宜備える車両要求管理システムを含むように本発明が拡張されることは理解されるだろう。

本発明によれば、方法は、少なくとも第１の場所を各々が含む複数の車両要求をサーバが受信することを含み、車両要求は第１のデバイスからそれぞれ受信されるのが好ましく、システムのサーバは、そのようなデータを受信する通信手段を備えるのが好ましい。第１の場所は、乗車場所、すなわちユーザが車両に乗車することを希望する場所であるのが好ましい。明示して述べられない場合、第１の場所又はそれに類似する場所を含む車両要求というとき、それは第１の場所又はそれに類似する場所を示すデータを含む要求を表すと理解されてもよいことがわかるだろう。例えば第１のデバイスにより送付され、その後、サーバで受信される車両要求は、第１の場所を示すデータのみを含んでもよい。しかし、車両要求は第１の場所を示すデータに加えて他のデータを含んでもよい。

いくつかの実施形態において、各車両要求は、目的地の場所（すなわち「降車場所」）及び／又は乗車時刻を示すデータを更に含んでもよい。目的地の場所はユーザが車両から降りることを希望する場所を示し、乗車時刻はユーザが車両に乗車することを希望する時刻を示す。本発明は、「即時」乗車を要求する車両要求をマッチングする場合に特に適用可能である。この種の要求は「至急」型要求と呼ばれてもよく、通常は所望の乗車時刻を示すデータを含まない。本発明は、採用されるクラスタ化技術によって待ち時間を全体として最短にするように、多数の至急型要求を更に効率よく遂行することを可能にする。しかし、将来の指定の時刻での乗車を要求するいわゆる「予定」型の要求にも本発明を適用可能であることが理解されるだろう。この場合、車両要求は乗車時刻を示すデータを含む。

前述のように、車両要求は、要求の１つ以上の追加属性を示すデータを含んでもよい。好適な実施形態において、車両要求は、所望の乗車時刻、目的地の場所、１つ以上の運転手プリファレンス、１つ以上の車両プリファレンス、乗客の人数及び／又は所望の運転手評価を示すデータを含む。車両プリファレンスは、例えば車両の大きさ、型式、障害者対応の有無などを含む。以下に更に詳細に説明されるように、このようなデータは、車両を要求にマッチングするときに使用されてもよい。従って、実施形態において、各車両要求は第１の場所、例えば乗車場所を含み、第２の場所、例えば降車場所、乗車時刻、運転手プリファレンス及び車両プリファレンスのうち１つ以上を任意に含む。

サーバが第１のデバイスから車両要求を受信する実施形態において、第１のデバイスは、何らかの適切な所望の形をとることができる。例えば第１のデバイスは、パーソナルコンピュータ又は他の計算資源などの一定の場所にあるデバイスであってもよい。第１のデバイスは、ホテル、バー、レストラン、駅などの建物の中又は屋外の待ち合わせ場所に配置されるように構成され、通常は１つの乗車場所とのみ関連付けられるデバイスであってもよい。それらの実施形態において、第１のデバイスは関連する場所を有する。実施形態において、関連する場所はサーバに記憶される。しかし、好適な実施形態では、第１のデバイスは、移動電話、ＰＤＡ、タブレットコンピュータなどの移動デバイスである。それらの実施形態において、デバイスは、デバイスの現在の地理的位置を判定するように構成された場所判定手段を有する移動デバイスである。好適な実施形態において、車両を要求する側はユーザ、すなわち車両で走行することを希望する人物であるが、他の場合、例えばホテルなどの１つの乗車場所と関連する第１のデバイスを介して要求が行われる場合には、車両を要求するのは、乗車を希望する車両ユーザとは異なっていてもよい。言い換えれば、車両要求は、所期のユーザの代理人により行われるということである。従って、本明細書におけるユーザは、車両で走行することを希望する人物を表す。

従って、いくつかの実施形態において、第１の場所は、第１のデバイスの現在の地理的位置であり、第１のデバイスは、デバイスの現在の地理的位置を判定するように構成された場所判定手段を有する移動デバイスである。他の実施形態では、第１の場所は第１のデバイスと関連する場所に対応し、関連する場所はサーバに記憶される。

第１のデバイスは、デバイスの現在位置を判定可能であるのが好ましく、従って、場所判定手段を備えるのが好ましい。場所判定手段はどのような種類であることも可能だろう。例えば第１のデバイスは、ＷｉＦｉアクセスポイント又は携帯電話通信網にアクセスして、そこから情報を受信し、この情報を使用してデバイスの場所を判定する手段を備えることが可能だろう。しかし、好適な実施形態において、第１のデバイスは、特定の時点における受信機の位置を示す衛星信号を受信するＧＰＳ受信機のような全地球的航法衛星システム（ＧＮＳＳ）受信機を備え、受信機は、定期的に更新位置情報を受信するのが好ましい。

サーバが車両と関連する第２のデバイスと通信している実施形態において、第２のデバイスは、ユーザにより送付される車両要求を受け入れることが可能であり、従って、携帯可能であるか又は車両に乗せて運ぶことができる形であるのが好ましい。第２のデバイスは、例えばハンドヘルド可能なポータブルデバイスであってもよく、例えば車両の中に取り外し可能に取り付けられてもよい。他の実施形態では、第２のデバイスは、車載システム、すなわち永久的に車両の中に取り付けられたシステムであってもよい。

第２のデバイスは、デバイスの現在位置、従って第２のデバイスが関連する車両の現在位置に関連する位置データをサーバへ送信するように構成されるのが好ましい。従って、第２のデバイスは、デバイスの位置を判定することが可能であり、そのため、場所判定手段を備える。場所判定手段は、どのような種類の手段であることも可能だろう。例えば第２の移動デバイスは、ＷｉＦｉアクセスポイント又は携帯電話通信網にアクセスして、そこから情報を受信し、この情報を使用して、デバイスの場所を判定する手段を備えることが可能だろう。しかし、好適な実施形態において、第２のデバイスは、特定の時点における受信機の位置を示す衛星信号を受信するＧＰＳ受信機のような全地球的航法衛星システム（ＧＮＳＳ）受信機を備え、受信機は、定期的に更新位置情報を受信するのが好ましい。

第２のデバイスは、デバイスを搬送している車両の相対的変位を判定し、それにより、例えば任意の時点における車両の速度及び進行方向を判定することが可能な手段を更に含むのが好ましい。この手段は、前述のＧＮＳＳ受信機、デバイス内の１つ以上の電子ジャイロスコープ又は加速度計を備えることが可能だろうが、デバイスは、例えば車両のＣＡＮバスを使用して、車両自体のそのようなセンサにアクセスすることも可能だろう。

従って、好適な実施形態において、本発明において利用される第２のデバイスは、車両又は車載ナビゲーションシステムの中に取り外し可能に取り付けることができ且つＧＮＳＳ信号受信及び処理機能性を含むのが好ましいポータブルナビゲーションデバイス（ＰＮＤ）のようなナビゲーション装置を備える。しかし、第２のデバイスが適切なソフトウェアプログラムを実行する移動電話、ＰＤＡ、タブレットコンピュータなどを備えてもよいことは理解されるだろう。

車両に関連する位置データ、例えば車両と関連する第２のデバイスに関連する位置データは、車両、例えば第２のデバイスの位置を表す何らかの適切な形でサーバへ送信されてもよい。例えば位置データは、１対の経度座標及び緯度座標を含んでもよいが、例えば道路のジャンクションに関するデジタルマップ中の特徴物に対する場所参照を含んでもよい。位置データは、その位置データが車両又は第２のデバイスで生成された時刻を表す時刻データ、例えばタイムスタンプと関連付けられるのが好ましいことが理解されるだろう。位置データは、車両又は第２のデバイスからサーバへ定期的に、例えば少なくとも５分おきに、好ましくは毎分の間隔で、場合によっては更に頻繁にサーバへ送信されるのが好ましい。従って、サーバは、受信された位置データから、特定の時点における第２のデバイスの現在位置を高い精度で判定できる。

本発明のサーバは、デジタルマップデータが記憶されたデータ記憶手段を更に備えてもよい。デジタルマップデータは、マップがカバーする地理的領域内のナビゲーション可能ルートの区間を表す複数のナビゲーション可能区間を有し、従って、ルート計画及びナビゲーションの目的で使用可能である。例えば本発明において、デジタルマップデータは、第１の場所と、車両により走行される目的地の場所との間のルートを計算するために使用される。

本発明において、サーバは、少なくとも第１の場所、例えば乗車場所を含む車両要求を受信するように構成される。車両要求は第１のデバイスから受信されるのが好ましい。第１の場所は何らかの適切な方式で生成されてもよい。例えばユーザは、第１のデバイスのユーザインタフェースで場所を直接入力してもよい。これは、例えばユーザが現在いる場所とは異なる場所で車両に乗車することを望む場合に当てはまるだろう。しかし、好適な一実施形態において、第１の場所は、第１のデバイスの場所判定手段を使用して第１のデバイスで生成される。これは、典型的にはユーザが現在いる場所で車両に乗車することを望む場合だろうということが理解されるだろう。

本発明は、前述のように、可能な限り早く車両が提供されるように車両要求が行われる「即時」遂行型の要求に特に適用可能である。しかし、将来の指定の時刻に車両が提供されるように要求が行われるいわゆる「予定」型の車両要求、又は即時型車両要求と予定型車両要求との組み合わせを含むシステムにも適用可能である。

好適な実施形態において、１つ以上のクラスタを生成するステップは、受信される各車両要求と関連する時刻データを使用する。時刻データは、例えば予定型要求に関して、サーバにより受信された時点で既に要求と関連付けられていたデータ及び／又は要求が受信される時点でサーバにより要求と関連付けられるデータを含んでもよい。１つ以上のクラスタを生成する際に使用される時刻データは、少なくともサーバで車両要求が受信された時刻を示すデータであるのが好ましい。これは、予定型要求又は即時型要求のいずれの場合であってもよい。その代わりに又はこれに加えて、使用される時刻データは要求と関連する所望の乗車時刻を示してもよい。これは、特に予定型要求に適用可能であってもよい。

１つ以上のクラスタを生成する際にデータが使用されるか否かにかかわず、方法は、サーバがサーバで要求が受信された時刻を示すデータを受信された各車両要求と関連付けるステップを更に含むのが好ましい。サーバは、このようなステップを実行する処理手段を備えてもよい。これは、要求が即時型要求であるか又は予定型要求であるかとは関係なく実行されてもよい。サーバにより各車両要求に割り当てられる車両要求の受信時刻を示すデータは、受信時刻を直接又は間接的に示してもよい。データは受信時刻であってもよい。他の実施形態において、データは、例えば要求の時間的順序に関連する識別番号を含んでもよい。

好適な実施形態において、少なくとも第１の車両要求の集合の中の各車両要求は、サーバで受信された時点でクラスタに割り当てられる。この方法は、「即時」型要求に対して最適だろう。従って、第１の要求の集合は、即時に遂行される要求の集合であってもよい。予定型要求に関連する場合、方法は、所望の乗車時刻から所定の長さの時間だけ前の時刻、例えば乗車時刻の３０分前の時刻に基づいて、１つ以上のクラスタを生成すること、例えばそのような要求をクラスタに割り当てることを含んでもよい。いくつかの実施形態において、方法は、少なくとも第２の車両要求の集合の中の各車両要求をサーバでの受信後の所定の時刻に１つ以上のクラスタに割り当てることを含んでもよく、この時刻は、要求と関連する所望の乗車時刻に基づくのが好ましく、例えば乗車時刻から所定の長さの時間だけ前の時刻である。その場合、第２の要求の集合は、将来の指定の時刻に遂行される予定型要求の集合であってもよい。他の構成において、予定型要求は、「即時」型要求とは別に処理されること、例えば別のクラスタの集合に割り当てられることが可能であるか、あるいは個別に処理されることが可能だろう。

本発明によれば、方法は、複数の車両要求を各々が含む１つ以上のクラスタを生成するステップをサーバが実行することを含む。次に、各クラスタの中で、車両と車両要求とのマッチングが実行される。実施形態において、方法は、生成された所定のクラスタを定義する要求のいずれに対しても、要求と車両とのマッチングが実行される前にそのクラスタを完成することを含む。受信された各要求は、車両が要求にマッチングされる前に所定のクラスタに割り当てられる。

「クラスタ」は、車両と要求とをマッチングするステップが実行される場合にまとめて処理される車両要求の群である。本発明は、車両要求をクラスタに割り当てた後にクラスタごとにマッチングを実行することにより、マッチングを実行する前に所定の数の車両要求を受信するのをシステムが待つ時間のバランスを動的に調整することを可能にするので、需要と供給を概観できるという利点が得られ、個別のユーザの過剰な待ち時間を回避しつつ、マッチングを最適にするのを助ける。クラスタは、車両を要求とマッチングするためにそのクラスタに割り当てられた複数の車両要求より成る群を含む。クラスタを生成するステップは、本発明の目的のためにクラスタとして扱われる車両要求群を構成する処理を表す。方法は所定のクラスタに含まれる車両要求の間の関連を作成することを含んでもよい。

実施形態において、本発明の方法は、各要求と関連する時刻データ及び／又は第１の場所データを少なくとも使用して複数の車両要求を含む１つ以上のクラスタを生成することを含む。

一般に、本発明によれば、１つ以上のクラスタを生成するステップは、複数の車両要求及び／又は複数の車両の地理的分布、例えば空間的密度を考慮に入れるのが好ましい。複数の車両要求の地理的分布は、各車両要求と関連する場所を使用して判定される。車両要求の地理的分布は、要求と関連する第１の場所データを使用して判定されるのが好ましい。第１の場所データは、先に述べたように乗車場所を示すのが好ましい。その代わりに又はそれに加えて、車両要求と関連する別の場所、例えば降車場所を使用して地理的分布が判定されてもよい。乗車場所は、待ち時間を最適にするように利用可能車両を車両要求とマッチングすることに最も大きく関係する要因であるので、乗車場所を使用するのが好ましい。領域内における車両の地理的分布は、車両の現在位置データに基づいて判定されてもよい。特に好適な実施形態において、１つ以上のクラスタを生成するステップは、車両の地理的分布、好ましくは車両の空間的密度を考慮に入れる。車両要求を遂行するために利用可能な車両の空間的密度は、互いに離れた場所、例えば離れた乗車場所に関してマッチングを実行する目的で車両要求をどれほどまとめて考慮できるかに影響を与えるので、車両の地理的分布を考慮することはクラスタ生成に際して有用であることがわかっている。車両の空間的密度が高い場合、所定の乗車場所に近接する車両が存在する尤度は高くなるので、相対的に近接している場所、例えば乗車場所に関連する車両要求からクラスタが構成されてもよい。クラスタの要求は群として車両とマッチングされるので、要求がより遠く離れた場所に関連している場合、車両がそのような場合の走行と、より近接した場所に関連する走行の双方に適切にマッチする車両であるということは起こりそうもないため、それらの要求を考慮することは有益ではない。

１つ以上のクラスタを生成するステップは、地理的分布の代わりに又は好ましくはそれに加えて、複数の車両要求の時間的分布を考慮に入れるのが好ましい。

複数の車両要求を各々が含む複数のクラスタが生成されるのが好ましい。好適な実施形態において、複数のクラスタは同時に生成される。生成される各クラスタは、「完成」したと考えられた時点でマッチング段階へ送出されてもよい。この構成は、異なる基準に関して、例えば以下に説明されるように地理的属性又は他の属性であってもよい特定の属性に関連すると考えられる要求に関して同時にクラスタを生成する機会を提供する。クラスタを「生成する」とは、クラスタに車両要求を追加するか又は複数の既存のクラスタから、例えばクラスタを併合することによりクラスタを形成するステップを表す。この生成は、クラスタが「完成」したと考えられ、マッチングを実行可能になる時点までであってもよい。第１の車両要求がクラスタに割り当てられたとき、すなわち、車両要求が既存のクラスタに追加されるのではなく、新たなクラスタを開始するために使用されたときに、クラスタは開始される。

クラスタを生成するステップは、所定のクラスタを示すデータを、そのクラスタを定義する複数の車両要求より成る集合の中の各要求と関連付けることを含んでもよい。従って、所定のクラスタの各車両要求は、その所定のクラスタに属する要求を示すデータと関連付けられる。クラスタを示すデータは、車両マッチングが行われる場合にそのクラスタと関連する車両要求をひとまとめにして処理可能にするためにクラスタを識別するデータであるならば、どのような種類のデータであってもよい。クラスタを示すデータは、マッチングの目的で群の一部を形成するとして要求を識別する。

車両要求の１つ以上のクラスタを生成する場合、受信される各要求はクラスタに割り当てられなければならないことが理解されるだろう。車両要求は、サーバで受信された時点で所定のクラスタに割り当てられるのが好ましい。しかし、前述のように、予定型要求の場合、クラスタへの割り当ては、所望の乗車時刻に関する所定の時刻に行われてもよい。

実施形態において、方法は受信された各車両要求を所定のクラスタに割り当てるステップを含む。所定の要求をクラスタに割り当てるステップは、１つ以上の、好ましくは複数の既存のクラスタより成る集合の中の所定のクラスタに要求を割り当てること、又はその要求を使用して新たなクラスタを生成することを含んでもよい。車両要求を使用して新たなクラスタを生成することは、車両を使用してクラスタを開始すること、又は既存の複数のクラスタを併合することにより作成されるクラスタにその要求を追加することを含んでもよい。従って、方法は、受信された車両要求が既存のクラスタに追加されるか否かを判定し、追加されるのであれば、どのクラスタに追加されるのかを判定し、あるいは新たな要求を使用して新たなクラスタが生成されるべきか否かを判定し、生成されるべきであれば、要求が新たなクラスタを開始するのか、又は複数の既存のクラスタを併合することにより新たなクラスタを形成するために使用されるのかを判定することを含んでもよい。いくつかの実施形態において、方法は、複数の既存のクラスタのうちどのクラスタに、受信された車両要求が割り当てられるのかを判定することを含んでもよい。

実施形態において、方法は、受信された所定の要求を既存のクラスタに割り当てるのか、又は新たなクラスタを生成するのかを判定することと、要求と関連する時刻及び／又は第１の場所を示すデータに少なくとも基づいて新たなクラスタに要求を割り当てることとを含んでもよい。

好適な実施形態において、受信された車両要求が既存のクラスタに追加されるのか、又は新たなクラスタを生成するために使用されるのかを判定するステップは、１つ以上の関連性尺度に基づいて、受信された車両要求が１つ以上の既存のクラスタの１つ以上の車両要求と関連する程度を評価することを含む。方法は、１つ以上の関連性尺度に基づいて、受信された車両要求が１つ以上の既存のクラスタの既存の要求のうち１つ以上の要求に関連すると考えられるか否かを判定することを含んでもよい。実施形態において、方法は、１つ以上の関連性尺度に基づいて、受信された要求がクラスタの既存の要求のうち１つ以上の要求に関連すると考えてもよい場合、受信された車両要求を既存のクラスタに追加することを含む。方法は、１つ以上の関連性尺度に基づいて、受信された車両要求が既存のクラスタの既存の要求のうちいずれとも関連しないと考えられる場合、受信された車両要求を使用して、新たなクラスタを開始することを含んでもよい。方法は、受信された車両要求が複数のクラスタのうち各クラスタの既存の要求のうち１つ以上の要求に関連すると考えてもよいと判定された場合、複数のクラスタを併合することにより作成された新たなクラスタに車両要求を追加することを含んでもよい。

このようにクラスタを生成することにより、受信された車両要求を既存のクラスタに追加できるようになる前に、又は複数の既存のクラスタを併合することにより作成される新たなクラスタに追加できるようになる前に、まず、受信された車両要求と、１つ以上のクラスタの既存の要求との関連性を考慮することによって、１つ以上の関連性尺度に従って関連性があると考えられる車両要求のクラスタを生成することが可能である。これにより、要求に応じるために、類似する車両集合、更には同一の車両集合が使用されると想定できるので、車両と要求とのマッチングが容易になる。従って、異なるクラスタに応じるために異なる運転手集合が使用されてもよいので、マッチング処理が更に単純化される。車両要求が複数のクラスタの既存の要求と関連している場合のクラスタの併合は、クラスタ及びそれらのクラスタの要求の関連性を更に強固にしてもよい。

一般に、好適な実施形態において、方法は、１つ以上のクラスタ、好ましくは複数のクラスタを生成することを含み、各クラスタと関連する車両は、１つ以上の関連性尺度に基づいて互いに関連していると考えられる。

本発明の方法は、車両要求が既存のクラスタに追加される前に、又は既存のクラスタを併合することにより作成される新たなクラスタに追加される前に、車両要求が既存の１つ以上のクラスタの既存の要求のうち１つ又は２つ以上の要求に関連していると考えてよいと判定することを含んでもよいことが理解されるだろう。クラスタに追加されるために又はクラスタを併合することにより作成される新たなクラスタに追加されるために新たな要求が関連性を持つ必要があるこのクラスタ又は各クラスタの既存の要求の数、及び必要とされる関連性の密接度は、所定のレベルの関連性を有する要求を含むクラスタを取得できるように必要に応じて設定されてもよい。以下に説明されるように、好適な実施形態において、必要とされる関連性の程度は、このクラスタ又は各クラスタが関連する１つ以上の場所に基づく地理的領域内の車両要求の時間的分布、車両要求の地理的分布又は車両の地理的分布のうち１つ以上に依存してもよい。

好適な実施形態において、１つ以上の関連性尺度はクラスタと関連付けられる。従って、実施形態において、１つ以上の関連性尺度は、新たな要求がこのクラスタ又は各クラスタの１つ以上の既存の要求に関連しているか否かを判定する際に使用するために、そのクラスタと関連付けられる。方法は、１つ以上の関連性尺度を定義し、この関連性尺度及び各関連性尺度をクラスタと関連付けるステップに拡張されてもよい。関連性尺度は何らかの適切な種類であってもよい。関連性尺度は、適合する関連性閾値を示してもよい。

好適な実施形態において、１つ以上の関連性尺度は、地理的関連性、例えば地理的関連性閾値を示す尺度を少なくとも含む。例えば地理的関連性を示す尺度は、要求がクラスタの１つ以上の既存の車両要求に関連していると考えるために、ある場所、例えば車両要求と関連する第１の場所が適合する距離範囲要件を示してもよい。地理的関連性尺度は、要求の乗車場所、目的地の場所又は何らかの適切な地理的場所を参照してもよい。前述のように、実施形態において、所定の車両要求と関連する第１の場所は、乗車場所、目的地の場所などであってもよく、乗車場所であるのが好ましい。地理的関連性尺度は、乗車場所を参照するのが好ましい。いくつかの好適な実施形態において、地理的関連性尺度は、車両要求がクラスタの一部を形成するために、要求が関連する場所、例えば乗車場所が入っていなければならない距離範囲を示す。距離範囲は、クラスタの既存の要求のうち所定の１つ以上の要求と関連する対応する場所、例えば乗車場所に関する範囲であってもよい（クラスタを開始させた車両要求の乗車場所など）。対応する場所は、クラスタの重心（又は幾何学的中心）であってもよい。従って、方法は、受信された車両要求と関連する第１の場所のデータを使用して、地理的関連性の尺度に基づいて、その車両要求が既存のクラスタの１つ以上の車両要求とどの程度の関連性を有するかを評価することを含んでもよい。いくつかの好適な実施形態において、地理的関連性尺度は、クラスタの１つ以上の既存の要求と関連する乗車場所に対して、車両要求と関連する乗車場所が入っていなければならない最大距離範囲を示す。

他の実施形態において、関連性尺度は、上記の地理的関連性に加えて又はその代わりに、非地理的関連性を示すために使用されてもよい。例えば関連性尺度は、１つ以上の基準、例えば時刻、車種、車両の大きさ、ペット乗車可能な車両が要求されているか否かなどの基準に基づく関連性を示してもよい。それらの基準は、この車両要求及び各車両要求と関連するデータに関する。従って、車両の大きさに基づいて関連性を判定するためには、少なくともいくつかの車両要求が所望の車両の大きさを指定する必要があるだろう。時刻基準は、所望の乗車時刻又は降車時刻に関連してもよいだろう。これは、特に予定型要求に関連する基準であってもよい。尺度は、要求の乗車時刻又は降車時刻がクラスタの要求の対応する乗車時刻又は降車時刻から所定の時間範囲内にあることを要求してもよい。要求と関連する時刻データ、例えば乗車時刻は、１つ以上の尺度に基づいて要求が既存のクラスタの要求に関連していると考えてよいか否かを判定するために使用されてもよい。

複数の関連性尺度が考慮に入れられてもよく、異なる関連性尺度に基づく適切な関数を使用して、異なる尺度に関して所望の重み付けが適宜実現されることは理解されるだろう。

好適な実施形態において、車両要求と既存のクラスタの１つ以上の既存の車両要求との間の関連性を評価するために使用される１つ以上の関連性尺度は、クラスタと関連する１つ以上の場所に基づく地理的領域内の車両要求と関連する場所を使用して判定される車両要求の地理的分布、クラスタと関連する１つ以上の場所を含む地理的領域内の車両の現在位置データに基づく車両の地理的分布、及びクラスタと関連する１つ以上の場所を含む地理的領域内の車両要求の時間的分布のうち１つ以上に基づいて定義される。地理的分布は空間的密度であるのが好ましい。好適な実施形態において、方法は、１つ以上のそのような地位的分布及び時間的分布に基づいて１つ以上の関連性尺度を定義することを含む。これらの実施形態、及び車両要求と関連する場所を使用して地理的分布が判定されるいずれかの実施形態において、場所は、第１の場所、例えば乗車場所であってもよい。車両又は要求の地理的分布又は時間的分布は時間依存であってもよい。従って、関連性尺度は、関連する時間周期に対する要求又は車両の地理的分布又は時間的分布に基づいて定義されてもよい。

このようにしてクラスタを生成することにより、生成されるクラスタの密度及びサイズを制御することが可能である。例えば相対的に混み合っている領域と関連するクラスタの場合、すなわち車両又は車両要求の空間的密度が高い場合、要求を領域内のクラスタに追加させるか又はそのクラスタを別のクラスタと併合することにより形成される新たなクラスタに追加させるために、新たな要求とクラスタの既存の要求との間により密接な関連性を要求するように関連性尺度を設定することにより、より多くのクラスタが生成されるようになるので、クラスタ中の要求と関連する場所、例えば乗車場所の地理的広がりは相対的に狭くなる。逆に、さほど混み合っていない領域と関連するクラスタの場合、クラスタに追加される要求に対してさほど密接な関連性は要求されないので、より広い地理的領域に広がった場所と関連する要求を含めて、生成されるクラスタの数は少なくなってもよい。

方法は、上記の要因のうちいずれか１つ以上に従って、クラスタと関連する１つ以上の関連性尺度を変更することを含んでもよい。方法は、クラスタと関連する１つ以上の場所に基づく地理的領域内で時間の経過に伴って起こる車両要求の時間的分布の変化に従って、１つ以上の関連性尺度を変更することを含んでもよい。方法は、各クラスタと関連する１つ以上の場所に基づく地理的領域内の車両要求の時間的分布に従って、異なる関連性尺度を異なるクラスタと関連付けることを含んでもよい。要求の時間的分布は、単位時間当たりの要求の数を表す。従って、行われる車両要求の単位時間当たりの数が相対的に少ない地理的領域にある場所とクラスタが関連付けられる場合、１つ以上の関連性尺度は、行われる車両要求の単位時間当たりの数が相対的に多い地理的領域、すなわち相対的に混み合っている領域内の場所と関連するクラスタと関連付けられる関連性尺度とは異なるように定義されてもよい。同様に、クラスタと関連する１つ以上の場所に基づく地理的領域内の車両要求の時間的密度が変化した場合、１つ以上の関連性尺度は変更されてもよい。

その代わりに又はそれに加えて、方法は、車両要求と関連する場所の地理的分布及び／又はクラスタと関連する１つ以上の場所に基づく地理的領域内の車両の地理的分布の時間に関する変化に従って、１つ以上の関連性尺度を変更することを含んでもよい。方法は、車両要求と関連する場所の地理的分布及び／又は各クラスタと関連する１つ以上の場所に基づく地理的領域内の車両の地理的分布に従って、異なる関連性尺度を異なるクラスタと関連付けることを含んでもよい。１つ以上の尺度は、クラスタと関連する１つ以上の場所に基づく地理的領域内の車両要求及び／又は車両と関連する場所の空間的分布の時間に関する変化に基づいて変更されるのが好ましい。従って、車両要求が相対的に広く空間的に分布している場所と関連する地理的領域、又は車両が相対的に広く空間的に分布している地理的場所の中の場所とクラスタが関連付けられる場合、１つ以上の関連性尺度は、車両要求又は車両と関連する場所の空間的密度が相対的に高い地理的領域、すなわち相対的に混み合っている領域内の場所と関連するクラスタと関連付けられる関連性尺度とは異なるように定義されてもよい。同様に、クラスタと関連する地理的領域内の車両要求又は車両と関連する場所の空間的密度が変化した場合、１つ以上の関連性尺度は変更されてもよい。

クラスタと関連する場所に基づく地理的領域は、所望の任意の広がりを有してもよい。領域に含まれるクラスタと関連する場所は、そのクラスタの車両要求のうち１つ以上の車両要求と関連する場所であるのが好ましい。場所は第１の場所であるのが好ましく、乗車場所であるのが最も好ましい。簡潔にするため、本明細書において、地理的領域はクラスタと「関連付けられる」ものとして説明されてもよいことが理解されるだろう。地理的領域はこの場所及び各場所を含んでもよく、あるいはそこに基づく他のものでもよい。例えば領域は場所を中心としてもよいが、複数の場所を使用して判定された場所を中心としてもよい。領域は、何らかの適切な大きさであってもよい。領域は、クラスタと関連する１つ以上の場所に基づいてもよいことが理解されるだろう。従って、クラスタが変化するにつれて、例えば更に多くの要求が追加されたためにクラスタが拡大するにつれて、領域の定義も変化してよい。いくつかの構成において、領域は、クラスタに最初に追加される要求と関連する場所、例えば乗車場所に基づいてもよい。領域を適切に選択することにより、システム全体の「混み合い度」のレベルを想定するのではなく、例えば要求又は車両の空間的密度又は時間的密度の局所的変化を考慮に入れて、システムの所定のレベルの分解能が実現されてもよい。

領域は拡張領域であるのが好ましい。地理的領域は、時間的要求分布の相対的に局所的な変化をどの程度まで考慮に入れるのかに従って、どのような大きさであってもよい。例えば地理的領域は、地区、市、地方の領域、田舎などであってもよい。いくつかの実施形態において、地理的領域は、市の中心部又は郊外領域に対応してもよい。クラスタごとに特定の地理的領域が定義されてもよいが、クラスタは、１つ以上の場所に基づいて１組の事前定義済み地理的領域のうち所定の１つの地理的領域と関連すると判定されてもよい。前者の場合、地理的領域は、クラスタの１つ以上の要求と関連する乗車場所からの所定の距離範囲、あるいは複数の要求と関連する場所の中心と考えられる地点からの所定の距離範囲に関して定義されてもよい。

領域は、クラスタと関連するどの場所に関しても同様に定義されることが可能だろうが、地理的領域は、場所に応じて定義されてもよい。地理的領域の広がりは、実施形態においては所定の時間にわたる地理的領域にわたる車両要求又は車両の時間的分布及び地理的分布に基づいて定義されてもよいと考えられる。従って、エリアの異なる部分の車両要求の時間的密度に基づいて、エリアが地理的領域に分割されてもよく、その場合、各クラスタは、例えばそのクラスタの第１の要求が領域内にある場所、例えば乗車場所と関連付けられるのに基づいて、その領域の１つと関連付けられてもよい。地理的領域は、車両要求又は車両の同様の時間的密度を有する場所をそれぞれ含んでもよい。異なる地理的領域は、要求又は運転手の「低い」時間的密度及び「高い」時間的密度と関連付けられてもよく、時間的密度の任意の数の中間レベルが設定されてもよい。不確かさを排除するために、クラスタと関連する１つ以上の場所に基づく地理的領域の定義に関する以上の説明は、クラスタの完成度を評価するために使用される閾値がクラスタと関連する１つ以上の場所に基づく地理的領域内の要求の時間的分布に基づく以下の実施形態にも同等に適用可能である。

本発明によれば、車両とこの車両要求及び各車両要求とのマッチングは、要求が所定のクラスタに割り当てられた後に初めて実行される。方法は、車両を第１のクラスタの車両要求とマッチングし、次に、車両を第２の異なるクラスタの車両要求とマッチングすることを含んでもよい。

車両と所定のクラスタの車両要求とのマッチングをいつ開始するのかに関して判定を実行しなければならないことが理解されるだろう。言い換えれば、クラスタの車両要求がマッチング可能な状態になるように、そのクラスタがいつ「完成」したと考えることができるかが判定されなければならない。本発明によれば、車両と車両要求とのマッチングは、所定のクラスタが完成したと考えられるまで、そのクラスタを形成する車両要求のうちどの車両要求に対しても行われない。クラスタが完成した時点で、そのクラスタに更に車両要求を追加することはない。

クラスタの車両要求は、クラスタが完成したと考えられた後の任意の時点でマッチング処理を受けてもよい。マッチング処理は、いつクラスタが「完成」状態になるかを評価するために使用される１つ以上の要件に適合した後に直ちに実行されてもよいが、その後すぐのいずれかの時点で実行されてもよい。例えば完成したと考えられ、マッチング可能な状態にあるクラスタを識別するために、クラスタは定期的にポーリングされてもよい。

方法は、クラスタの完成度を示す１つ以上の尺度を参照することにより、クラスタが完成したと考えてもよいと判定することを含んでもよい。本発明の好適な実施形態によれば、方法は、１つ以上の閾値を参照することにより、クラスタに要求を追加できなくなった場合にクラスタが完成したと考えられると判定することを含む。１つ以上の閾値は、クラスタに含まれる車両要求の数に関連する閾値及び／又は時間関連閾値を含んでもよい。時間関連閾値及び要求の数に関連する閾値の双方が使用されるのが好ましい。いくつかの実施形態において、第１の閾値及び第２の閾値のうちいずれか一方に一致するか又はそれを超えた場合に、クラスタは完成したと考えられる。第１の閾値は、クラスタに含まれる車両要求の数に関連する閾値であり、第２の閾値は時間関連閾値である。要求の数に関連する閾値は、最大閾値であるのが好ましい。従って、この閾値は、クラスタが含む要求の数に関してクラスタの最大サイズを設定してもよい。時間関連閾値は最大閾値であるのが好ましい。これらの実施形態において、時間関連閾値及び要求数関連閾値は、共にクラスタと関連付けられる。

いくつかの好適な実施形態において、時間関連閾値は、クラスタの車両要求のうち第１のクラスタ化要求がそのクラスタに追加されてから経過した時間に基づく。車両要求は、最初に、その要求をそのクラスタとは異なるクラスタに追加することによりクラスタ化されていたかもしれず、その後、最初のクラスタが１つ以上の他のクラスタと併合されて、そのクラスタを作成したかもしれないことは理解されるだろう。この場合、経過時間は、要求が最初にいずれかのクラスタに追加された時刻に関する。他の実施形態では、第１のクラスタ化車両要求は、問題のクラスタの作成時に最初にクラスタ化されていたかもしれない。従って、経過時間は、クラスタの生成時刻に関してもよい。経過時間は、第１のクラスタ化要求がクラスタ化された時刻を示す何らかの適切な時刻データに基づいてもよい。時刻データは、要求と関連するクラスタ化の時刻又はクラスタの生成時刻であってもよい。いくつかの実施形態において、時刻データは、要求がサーバで受信された時刻である。受信時に要求がクラスタに追加される場合、その時刻は、要求の最初のクラスタ化時刻を示すと考えられてもよい。

クラスタに更に要求を追加することができなくなったためにクラスタは完成したと考えてもよく、クラスタの要求がマッチング可能な状態になったと判定するために使用される時間及びクラスタに含まれる車両要求の数の双方に関連する閾値を指定することにより、本発明は、ユーザの待ち時間が過剰に長くなる事態を回避しつつ、更に最適なマッチングを実現させる十分な数の要求を提供するために、マッチングを実行する前に十分な待ち時間をとるというバランスが維持されるようなクラスタ生成の動的方法を提供する。例えばクラスタ中に存在する要求の数のみを参照して閾値を設定したならば、単位時間当たりの車両要求の数が相対的に少ない地理的領域と関連するクラスタの場合、単位時間当たりの車両要求の数が相対的に多い混み合う地理的領域に関連するクラスタの場合と比較して、クラスタが完成したと考えられ、マッチング可能な状態になるまでにはるかに長い時間待たなければならないだろう。逆に、第１の要求がクラスタに追加されてからの経過時間のみを参照して閾値を設定したならば、単位時間当たりの車両要求の密度が低い地理的領域のクラスタの場合、混み合う領域のクラスタと比較して、車両要求の数が相対的に少ないクラスタに関連してマッチングを実行する必要が生じるだろう。時間関連閾値及び要求数関連閾値のいずれかとの一致を参照することによりクラスタの完成度を判定することにより、それらの状況のバランスが保たれる。従って、それらの好適な実施形態において、本発明の方法は、地理的領域に関する車両要求の時間的分布の変化を考慮に入れてもよい。

クラスタが完成したと考えてもよいと判定する際に使用されるこの閾値及び各閾値は、何らかの適切な方法で判定されてもよい。時間に基づく閾値又は数に基づく閾値は、必要とされる応答性に関する最小限の要件に基づいて判定されてもよい。混み合っているという条件の場合、相対的に小さい数の閾値を選択することにより、システムの応答性は高くなる。すなわち、マッチングは、より迅速に実行される。時間関連閾値は、さほど混み合っていない領域でマッチングが行われる時刻を判定するために使用されてもよく、その場合、数領域と最初に一致することはないので、時間閾値が小さいと、システムの応答性はより高くなる。閾値は包括的に設定されてもよく、クラスタと関連する地理的領域内の車両要求の空間的分布又は時間的分布とは無関係であってもよい。

他の構成において、この閾値及び各閾値は、好ましくはクラスタと関連する地理的領域内の車両要求の時間的分布及び／又は地理的分布に基づいて選択されてもよい。地理的分布は空間的密度であるのが好ましい。地理的領域は、既存のクラスタに追加されてもよい要求の類似性を判定するために関連性尺度が使用される実施形態に関連して先に説明したようないずれかの方法で定義されてもよい。

一般に、一度にマッチングされる車両要求の数が多いほど、すなわちクラスタのサイズが大きいほど、マッチングの最適度は高くなる。しかし、実際には、長すぎる待ち時間は、ユーザが受け入れがたい遅延をもたらすので、それほど長く待つことは不可能である。高い時間的密度で要求が受信される場合、すなわち混み合う時間の場合、クラスタの中の要求の数を著しく増加させ、それによりマッチング効率を改善することは可能であり、その結果発生する待ち時間の延長はそれほど大きくはならないことが理解されるだろう。従って要求の時間的密度が高い場合には、最大サイズ及び／又は時間閾値はユーザに対して待ち時間を長くせずに増加されてもよい。これに対し、時間的密度が低い場合、すなわち要求が少ない場合、クラスタについてマッチングを実行する前に著しく長い時間待ったとしても、延長された時間の中で受信されると期待できる要求はわずかであるので、マッチング効率に与える影響は限られる。従って、時間的密度が低い場合、時間閾値又はサイズ閾値を増加させることは不利になるかもしれない。発明者は、要求の時間的密度は地理的領域に関して変化する場合もあると認識した。そこで、本発明の好適な実施形態は、クラスタと関連する所定の地理的領域に関する要求の時間的分布を考慮に入れる。これにより、全体としての時間的分布を想定するのではなく、要求の時間的分布の局所的な変化を考慮に入れることができるだろう。

いくつかの好適な実施形態において、クラスタと関連する１つ以上の場所に基づく地理的領域と相対的に高い車両要求の時間的密度が関連している場合、クラスタに対して相対的に高い最大サイズ閾値が使用され、及び／又はクラスタと関連する１つ以上の場所に基づく地理的領域と相対的に低い車両要求の時間的密度が関連付けられる場合、クラスタに対して相対的に低い最大サイズ閾値が使用される。その代わりに又はそれに加えて、クラスタと関連する１つ以上の場所に基づく地理的領域と相対的に高い車両要求の時間的密度が関連付けられる場合、クラスタに対して相対的に高い最大時間閾値が使用され、及び／又はクラスタと関連する１つ以上の場所に基づく地理的領域と相対的に低い車両要求の時間的密度が関連付けられる場合、クラスタに対して相対的に低い最大時間閾値が使用される。

好適な実施形態において、クラスタが完成したと考えてもよいと判定する方法は、先に説明した１つ以上の関連性尺度に基づいて要求を既存のクラスタに追加することが可能であるか否かを判定する方法と組み合わせて使用される。これらの方法の組み合わせを使用することにより、すなわち、クラスタを生成する場合に要求の関連性を考慮し、閾値の完成度を考慮する場合に時間閾値及びサイズ閾値を考慮し、各クラスタと関連する地理的領域内の要求の時間的分布を考慮に入れることにより、混み合う領域及びそれほど混み合っていない領域でクラスタをどのように生成し、完成させるかを制御することが可能であり、実施形態において、クラスタのマッチングを行ってもよい状態になる前の最大時間、すなわち待ち時間により制約が課される場合、それほど混み合っていない地理的領域では、関連走行の可能な限り大きいクラスタが生成されてもよく、混み合う領域では、マッチングを行う前の時間を可能な限り短縮して、更に最適度の高いマッチングを提供するために、最大サイズ閾値により指示される関連走行の十分に大きいクラスタが生成されてもよい。

一例として、車両要求の時間及び量の双方の閾値が使用される場合、その結果、生成されるクラスタは、例えば都市の中心地区などの混み合う領域では、量に基づく閾値と一致するか又はそれを超えることに基づいて完成したと考えられる傾向にあるが、町の郊外のそれほど混み合っていない領域では、クラスタは、時間に基づく閾値と一致するか又はそれを超えることに基づいて完成したと考えられる傾向にある。言い換えれば、混み合う領域では、相対的に多くの数の小型のクラスタが生成される傾向にあり、それほど込み合っていない領域では、相対的に少数の大型のクラスタが生成される傾向にあるということになる。

マッチングは、クラスタの一部を形成する要求に関連して何らかの適切な方式で実行されてもよい。実施形態において、車両をクラスタの各車両要求とマッチングするステップは、クラスタの車両要求を互いに参照することにより実行される。すなわち、一度に１つの要求を考慮し、１つ以上の基準に基づいて最適の車両（すべての利用可能車両の中から）を割り当てるのではなく、全体としてクラスタの要求の中で最適のマッチングを実現するために、マッチングは包括的に実行される。クラスタの各要求と１台の車両がマッチングされるのが好ましい。各車両はただ１つの要求とマッチングされるのが好ましい。車両を要求とマッチングするステップは、クラスタの受信された各車両要求のコンテンツをサーバが解析し、車両要求と関連する基準を判定することを含んでもよい。車両を車両要求とマッチングするステップは、複数の利用可能な第２のデバイスの中から第２のデバイスを受信された車両要求とマッチングすることを含んでもよい。サーバは、この選択を以下に説明されるような何らかの適切な所望の方式で実行するように構成されてもよい。

好適な実施形態において、所定のクラスタと関連する車両要求は、何らかの形で互いに関連していることが理解されるだろう。これにより、車両を要求とマッチングするタスクが容易になってもよい。好適な実施形態において、要求は少なくとも地理的に関連し、第１の場所、例えば要求と関連する乗車場所との間に関連性を有するのが好ましい。要求は、要求をクラスタに割り当てる場合に考慮に入れられる１つ以上の他の基準を参照することにより、例えば運転手プリファレンス、車両プリファレンス、乗客の人数、乗車時刻、降車時刻などのうち１つ以上と関連させて関連付けられてもよい。

マッチングは、クラスタの各車両要求の１つ以上の属性、好ましくはクラスタの各車両要求と関連する場所、例えば乗車場所に関連する１つ以上の基準に基づいてもよい。しかし、それに加えて又はその代わりに、ユーザ指定基準を含む他の基準が考慮に入れられてもよい。その代わりに又はそれに加えて、基準は、少なくとも１つの車両プリファレンス、少なくとも１つの運転手プリファレンス、運転手評価、所望の乗車時刻を示すデータ、乗客の人数を示すデータに関する基準を含んでもよい。本明細書で使用される場合の「プリファレンス」は、肯定的又は否定的な希望、すなわち該当する場合又は該当しない場合を示してもよい。

車両を車両要求とマッチングする場合を例にとって、マッチング処理が説明されることが理解されるだろう。車両は、関連する運転手を有し、運転手プリファレンスなどという場合、それは、車両要求に割り当てられる可能性がある車両の運転手を表す。所定の車両が複数の運転手と関連する可能性がある場合の運転手とは、現在の運転手、又は関連する時刻、例えば乗車時刻にその車両を使用していると予測される（又はわかっている）運転手である。

車両をクラスタの各車両要求とマッチングするステップは、１つ以上の基準に基づいてクラスタの要求を遂行するのに適する車両の集合を判定することを含むのが好ましい。車両の集合は複数の車両の中の部分集合であってもよい。それらの車両は、要求を遂行するために利用可能であるとサーバにわかっている車両である。基準は少なくとも１つの地理的基準を含むのが好ましい。基準は、車両の現在位置と、クラスタと関連する１つ以上の場所に基づく１つ以上の場所との間の距離に関連する基準を含むのが好ましく、それらの場所が基づく１つ以上の場所は、クラスタの要求と関連する第１の場所であるのが好ましい。それらの場所は、クラスタの要求のうち１つ以上の要求の乗車場所であるのが好ましい。クラスタと関連する１つ以上の場所に基づく１つ以上の場所は、それらの場所に対応してもよく、あるいはそれらの場所に基づいて判定されてもよく、例えば場所などに関して判定された中心などである。クラスタと関連する場所に基づくこの場所及び各場所に対して、サーバは、対応する場所を含む地理的領域を定義する。地理的領域は何らかの適切な所望の方式で定義されることが可能だろう。例えば領域は、その場所を中心とし、５０〜５００ｍ、好ましくは約２５０ｍの距離などの所定の半径を有する円であることが可能だろう。領域は、どの場所に対しても同様に定義されることが可能だろうし、あるいは場所に依存して定義されてもよい。判定された車両の集合は領域内の車両であってもよい。

上記の基準に加えて又はその代わりに、基準は、少なくとも１つの車両プリファレンス、運転手評価、少なくとも１つの運転手プリファレンス、所望の乗車時刻を示すデータ及び乗客の人数を示すデータのうち１つ以上に関する基準を含んでもよい。基準はユーザ基準を含んでもよい。サーバは、車両要求を遂行するための車両の利用可能度を何らかの適切な方式で判定してもよい。例えばサーバは、第２のデバイスを有し、受信された車両要求に適合する可能性がある複数の車両の各々の位置及び状態の更新情報を継続的に、例えば定期的に受信してもよい。何台かの車両は、例えば先行する走行を完了している途中であるか又は車両の運転手が休息を取っているなどの理由により、受信された車両要求に適合する車両として利用不可能であるかもしれない。従って、サーバは、車両の現在位置に加えて、受信された車両要求を受け入れるために特定の時点で利用可能な車両を認識している。更に、ユーザを直ちに乗車させてほしいことを示すユーザからの車両要求とは対照的に、将来の所定の時刻に関連する車両要求の場合、サーバは、車両が既に行っている走行に基づいて、その将来の時刻における車両の位置及び利用可能度を認識する。

次に車両を車両要求とマッチングするステップは、判定された車両の集合からの車両をクラスタの車両要求の集合とマッチングすることを含んでもよい。いくつかの実施形態において、方法は、各要求と関連する第１の場所、すなわち乗車場所への車両の推定到着時刻を最小にするように車両を車両要求とマッチングすることを含んでもよい。用語「最小にする」は、１つ以上の他の基準により課される他の何らかの制約を受けることを最小限にすることを表す。これは、本明細書において説明されるクラスタ化方法が通常は適用される要求である「即時」型要求に最適である。前述のように、予定型要求は、所望の指定乗車時刻より前の所定の時点でクラスタ化されてもよく、乗車時刻までに即時要求と考えられてもよい。しかし、クラスタが予定型要求のみに基づく場合、クラスタは、類似する指定乗車時刻を有する要求に基づくことになるので、クラスタの要求の中で推定到着時刻を最小にしようとすることは、この場合でも有益だろう。

即時型要求であるか又は予定型要求であるかに関わらず、到着時刻はユーザにとって重要な唯一の要因ではなく、車両が特定の他の基準に適合する場合、ユーザは車両の到着を長い時間待つことを選ぶこともある。その代わりに又はそれに加えて、車両を車両要求とマッチングする場合、１つ以上の他の基準が考慮に入れられてもよい。他の基準は車両運転手のプリファレンスを含んでもよい。これにより、ユーザのプリファレンスと運転手のプリファレンスとのバランスが取れたマッチングが提供されるだろう。マッチングのステップは、運転手のパフォーマンス履歴に基づくプリファレンス、又はシステム全体の動作に基づく他のプリファレンスなどのシステムプリファレンスを更に考慮に入れてもよい。例えばステップは、信頼性の高い運転手により利益の高い走行を提供することを優先してもよい。基準は運転手の挙動又はユーザの挙動の履歴を考慮に入れてもよい。運転手の挙動履歴は、運転スタイルの履歴、例えば荒い運転であるか又は穏やかな運転であるかなどに関連してもよい。ユーザ挙動履歴は、以前に行われた走行、ユーザが表現したプリファレンスの履歴などに関連してもよい。ユーザ挙動履歴は、ユーザが指定するプリファレンス又は以前の走行から推測されるプリファレンスに関連してもよい。実施形態において、ユーザ挙動履歴及び／又は運転手挙動履歴を示すデータは、マッチング処理で使用するために記憶されてもよい。ユーザ又は運転手のアイデンティティは、車両要求と関連する第１のデバイスにより、又は車両と関連する第２のデバイスにより示されてもよい。

好適な実施形態において、方法は、要求と関連する第１の場所、すなわち乗車場所への車両の推定到着時刻及び／又はユーザ基準、運転手基準、車両基準、システム基準並びに運転手挙動履歴及びユーザ挙動履歴に基づく基準のうち１つ以上を含むのが好ましい１つ以上の更なる基準に基づいて、判定された車両の集合からの車両をクラスタの車両の集合とマッチングすることを含む。マッチングは少なくとも推定到着時刻に基づくのが好ましい。ユーザ基準は、１つ以上の運転手プリファレンス、１つ以上の車両プリファレンス、所望の降車時刻又は乗客の人数から選択されてもよい。運転手基準は、乗車に好適な領域又は好適な進行方向を含んでもよい。ユーザ基準又は運転手基準は、ユーザ又は運転手が指定する基準であってもよいが、例えば過去の挙動、あるいはユーザ又は運転手のプロファイルなどから判定されてもよい。

方法は、車両及びクラスタの車両要求より成る各対にマッチ値を割り当て、クラスタの車両要求の中で割り当てられた車両と車両要求の対の間でマッチ値を最大にするように車両を車両要求とマッチングすることを含んでもよい。マッチ値は、マッチング処理で考慮に入れられる種々の要因の関数であるパラメータであってもよい。マッチ値は、要求に関する乗車場所への車両の推定到着時刻及び／又は運転手プリファレンス、ユーザプリファレンス、ユーザ挙動履歴、運転手挙動履歴及びシステムプリファレンスのうち１つ以上に基づいてもよい。これらは、先に説明した種類のうちいずれかであってもよい。マッチ値を判定する場合、異なる要因は異なる重みを割り当てられてもよい。１つ以上の他の要因に対する推定到着時刻に属する重みは、ユーザ及び／又は運転手により指定されてもよい。関数は、互いに矛盾するプリファレンスのバランスを保つように構成されてもよい。

方法は、車両要求を車両に、すなわちその車両要求がマッチングされた運転手に、例えば車両と関連する第２のデバイスに提供することを含んでもよい。方法は、各車両要求を示すデータをその車両要求がマッチングされた車両へサーバが通信することを更に含んでもよい。サーバは、データを車両と関連する第２のデバイスに提供してもよい。車両要求を車両に提供するということは、車両要求を車両の運転手に提供することに置き換え可能であると理解されるべきである。

車両を車両要求とマッチングするステップは、１台の車両を各車両要求とマッチングすることを含むのが好ましい。しかし、すべての車両がマッチングされた車両要求を受け入れるとは限らないと考えられる。いくつかの好適な実施形態において、方法は、少なくとも１台の代替車両を各車両要求に割り当てることを更に含んでもよい。好適な実施形態において、説明される方法に従って割り当てられた車両、すなわち、クラスタ中のすべての要求を考慮に入れることにより車両要求に割り当てられた車両は、一次車両であると考えられてもよい。１台の一次車両が各要求とマッチングされるのが好ましい。いくつかの実施形態において、方法は、クラスタ中の他の要求を考慮せずに車両を各要求とマッチングすることに基づいて、少なくとも１台の二次車両をクラスタの各要求に割り当てることを更に含む。言い換えれば、二次車両は、従来の技術を使用してマッチングされる。二次車両は、先に説明したような１つ以上の基準に基づいて車両要求に最もよくマッチすると判定される車両であってもよい。二次車両は、要求を遂行することに関して、一次車両より低いランクの車両である。三次車両及び四次以降の車両の集合、すなわち更に下位のランクの車両の集合は、要求ごとに従来の技術に基づいて次によくマッチすると判定されてもよい。各次の車両の集合ごとに、各車両要求に一台の車両が割り当てられるのが好ましい。好適な実施形態において、方法は、クラスタの車両要求を遂行するための一次車両の集合を提供するために、クラスタの各車両要求に一台の車両をマッチングすることを含み、各一次車両と車両要求とのマッチングは、クラスタの車両要求を互いに参照することにより実行され、方法は、クラスタの車両要求を遂行するための二次車両の集合を提供するために、クラスタの各車両要求に一台の車両をマッチングすることを更に含み、車両要求への各二次車両のマッチングは、クラスタの他のどの車両要求も参照せずに実行される。例えば所定の順序の複数の車両要求が同一の運転手に割り当てられてもよいか否か、又は１人の運転手が複数の順序に関する車両要求を割り当てられてもよいか否かなどを制御するために、必要に応じて実現形態が構成されてもよい。方法は、最初に各車両要求を割り当てられた各一次車両に提供し、例えば所定の時点で一次車両が要求を受け入れない場合、車両要求をその要求に関する二次車両に提供することを含んでもよい。

第１のデバイス及び／又は第２のデバイスを使用する本発明の態様又は実施形態において、使用される場合の第１のデバイス及び第２のデバイスは、サーバのようなシステムの他の構成要素との間で情報を送受信するための通信手段を備えることが理解されるだろう。情報は、位置データ、表示されるデータ、ルートデータなどを含んでもよい。通信手段は、所望のどのような種類の手段であることも可能である。例えばデバイスは、デバイスとの間でデータ信号の送受信を可能にする一つ以上の物理的コネクタインタフェースを備えてもよい。しかし、好適な実施形態において、通信手段は、セルラ通信及び他の信号・データネットワーク、例えばＷｉＦｉ、ＧＳＭ（登録商標）、ＧＰＲＳなどを介する通信を可能にするための一つ以上の無線送信機／受信機を備える。

前述のように、本発明の態様又は実施形態のいずれかにおいて、車両を車両要求とマッチングするということは、車両と関連する運転手を車両要求とマッチングすることに置き換えられると理解されてもよい。マッチングは関連する時点で車両と関連する所定の運転手に関し、従って、車両及び車両と関連する運転手は互いに互換性を持って使用されてもよい。

本発明は、先に説明したような本発明の態様又は実施形態のいずれかに係る車両要求管理システムと共に動作するように構成された第１のデバイス及び／又は第２のデバイスに拡張される。更に、特定のステップはサーバでのみ実行されるものとして説明されたが、第１のデバイス及び第２のデバイスが使用される場合、それらのステップがサーバではなく、第１のデバイス及び第２のデバイスのいずれか一方又は双方で、あるいは第１のデバイス、第２のデバイス及びサーバの何らかの組み合わせで適宜実行可能であろうということは理解されるだろう。

本発明に係る方法は、少なくとも一部でソフトウェアを使用して実現されてもよい。従って、更なる態様から見た場合、本発明は、サーバなどの適切なデータ処理手段で実行された場合に本明細書において説明される方法のいずれか又はすべてを実行するように適合されたコンピュータ可読命令を含むコンピュータプログラムに拡張される。

本発明は、そのようなソフトウェアを含むコンピュータソフトウェアキャリアにも拡張される。そのようなソフトウェアキャリアは、物理的（又は非一時的）記憶媒体であるか、あるいは配線を介する電子信号、光信号又は衛星などの無線信号のような信号であることも可能だろう。

要求を遂行するために車両に対する要求を利用可能な移動車両とマッチングすることに関連して本発明を説明したが、本発明を更に広い態様で少なくともサービス要求を移動サービスプロバイダとマッチングすることに適用可能であることが理解されるだろう。

また、先に説明した本発明の態様及び実施形態のすべてが本明細書において説明される好適な特徴及び任意の特徴のいずれか１つ以上又はすべてを含むことができ、好ましくは適宜含むことは当業者には理解されるだろう。

以下に、添付の図面を参照して、例示的な例によって、本発明の教示の種々の態様及びそれらの教示を採用する構成を説明する。
図１は、本発明に従って使用されてもよい車両要求管理システムの構造を示す図である。 、 図２及び図３は、システムにおいて車両要求デバイスとして使用可能な例示的な固定場所デバイスを示す図である。 図４は、システム内で車両と関連するナビゲーションデバイスを提供するように構成された電子構成要素を示す概略図である。 図５は、ナビゲーションデバイスが無線通信チャネルを介して情報を受信する方式を示す概略図である。 、 、 、 、 、 、 、 、 、 図６〜図１５は、システムにおいて使用されるナビゲーションデバイスの表示画面の例を示す図である。 図１６は、乗車場所又は降車場所への車両の到着を自動的に判定する方法のステップを示す図である。 図１７は、ユーザが携帯する移動デバイスと車両内のナビゲーションデバイスとの関連を形成する方法のステップを示す図である。 図１８は、本発明に係る車両を車両要求とマッチングする方法のステップを示す図である。 図１９は、車両要求を発生したユーザの待ち時間を最適化するために本発明をどのように使用可能であるかを示す図である。

本発明は、少なくとも好適な実施形態において、車両要求管理システムに関し、特に、乗客と個別のタクシーとの間でタクシーに対する要求を管理するシステムに関する。図１を参照して、本発明と共に使用されてもよいシステムの構造を説明する。

図１に示されるように、システムは３つの主要な構成要素、すなわちサーバ１０、複数の車両要求デバイス１２及び複数の車両１４を備え、各車両はルート計画機能性及びナビゲーション機能性を有するデバイス２００を装備している。

車両要求デバイス１２は、いくつかの異なる形をとることができる。例えば図２及び図３に示されるように、車両要求デバイスは、固定場所デバイス２０の形をとることが可能だろう。固定場所デバイスは、その名が示す通り、ただ１つの場所と関連し、この場所へ車両を要求する目的でのみ使用可能である。車両要求デバイスは、移動電話などの移動デバイス２２の形をとることもできる。以下に更に詳細に説明されるように、そのような移動デバイスは、デバイス自体の場所を判定可能であり、必要に応じて、車両を現在の場所へ又は他のいずれかの場所へ要求するために使用できる。車両要求デバイスは、デバイス自体の場所を判定する手段を含まないが、特定の場所での乗車を要求するために使用可能なデスクトップコンピュータ又はポータブルパーソナルコンピュータなどの計算資源２４であることも可能である。

各車両要求デバイス１２は、タクシーなどの車両に対する要求をサーバ１０へ送信するためにユーザにより使用可能である。通常、要求は乗車場所又は乗車場所を取り出すために使用可能なデータを含み、乗車時刻、降車場所、所望の車種又は車両の大きさ（例えば、乗用車、ミニバン、リムジンなど）、乗客の人数、並びにチャイルドシートの必要性、身体障害者への対応の必要性又は特定の運転手の指名の有無などの付加的なプリファレンスのうち少なくとも１つを更に含んでもよい。車両要求は、移動通信ネットワーク、インターネットなどの何らかの適切な通信手段を使用してサーバ１０へ送信可能である。

サーバ１０で車両要求が受信されると、サーバは要求の中で挙げられている基準に適合する適切な車両１４を選択する。従って、サーバ１０はユーザの要求に基づいて適切な車両を割り当てる配車システムとして機能する。

各車両１４は、場所判定手段及びサーバ１０と通信する通信手段を備えるデバイス２００を装備している。車両のデバイスは何らかの適切な形をとることが可能であるが、例示的な実施形態ではナビゲーション装置である。ナビゲーション装置は、車両に取り外し可能に装着可能なポータブルナビゲーションデバイス（ＰＮＤ）又は車両に組み込まれたナビゲーションデバイスであることが可能である。車両１４の１つに配置できるナビゲーションデバイス２００の例示的な構成が図４に示される。

車両の各デバイスは、デバイスの現在場所、従って車両の場所をサーバ１０へ定期的に送信する。従って、サーバ１０は、どの時点でもシステム内におけるすべての車両の現在位置を少なくとも妥当な正確度で把握している。サーバは、車両の現在の利用可能度、例えば車両が既に要求を完了する段階に入っていること及び車両の運転手が他の何らかの理由で運転できないことなどを更に認識している。この点に関して、各運転手は、要求を受信するために自身の車両が利用可能である時間範囲を入力することが可能であってもよい。あるいは、運転手は、必要に応じてデバイスを起動又は停止できるだけであってもよい。また、運転手は、自身が運転する又は運転しない特定の場所又は領域を入力してもよい。

サーバ１０は、特定の要求に応答して車両１４を選択でき、従って、自動配車システムに従って、要求デバイス１２と車両のデバイス２００との間に一時的関連を形成できる。本発明に係るシステムを後に図１１に関して説明する。運転手の車両がサーバ１０により最適車両として選択された場合であっても、例えば運転手が自身のナビゲーションデバイスで適切なユーザ入力を実行することによって仕事を拒否してもよいことは理解されるだろう。

車両に仕事が与えられ、その仕事が車両の運転手により受け入れられ、状況によっては、その要求を行ったユーザによっても受け入れられたならば、要求デバイスと車両のナビゲーションデバイスとの間に関連が成立する。この関連によって、例えば目的地までの走行が完了して、支払いが行われるまで、２つのデバイスの間でデータが交換される。

車両が仕事を首尾よく完了すると、その仕事の詳細が車両のナビゲーションデバイス２００へ送信される。詳細は乗車場所を含み、要求を行った人物の詳細を更に含んでもよい。ナビゲーションデバイスは、車両の現在位置から乗車場所までのルートを自動的に又は運転手による入力に応じて計算し、その場所まで運転手を案内し始めることができる。あるいは、現時点で車両が仕事を終了しようとしている場合、必要になるまでメモリに一時的に乗車場所を記憶しておくことは可能であるが、現在の仕事の降車場所を中間地点として使用して、乗車場所までのルートを計算することもできる。ルートの計算に従って、乗車場所への推定到着時刻（ＥＴＡ）が生成され、この時刻が要求デバイス１２に供給されることが可能である。必要になるたびに、例えば車両が計算上のルートを走行している間にＥＴＡが変更された場合に、更新ＥＴＡが要求デバイス１２へ送信されることが可能である。

乗車場所でユーザを乗車させた後、車両１４のナビゲーションデバイス２００は、運転手を所望の降車場所まで案内する。降車場所は、当初の車両要求の中でユーザによって提供されていることが可能だろうが、乗車時に乗客により運転手に提供されてもよい。降車場所に到着すると、乗客は料金を支払う。支払いは、キャッシュカード、あるいはクレジットカード又はデビットカードを使用して行われることが可能だろうが、支払いを電子的に実行できるように、それまでの走行を割り当てることができるアカウントを乗客がサーバ１０に有しているのが好ましい。

車両要求デバイス１２がとることができる１つの形は、固定場所デバイス２０である。固定場所デバイスの一実施形態が図２及び図３に示される。

固定場所デバイス２０は、ホテル、バー、レストラン、ショッピングモール、駅などの建物の中又は屋外の待ち合わせ場所に配置され、１つの乗車場所と関連付けられるように構成される。乗車場所は、デバイスの実際の場所であってもよいが、ホテル又はバーの入口付近の街路、あるいはタクシーが安全に停車できる街路の最寄りの地点のようなデバイスの近傍の場所であってもよい。

固定場所デバイス２０は、そのデバイスと関連する乗車場所に対する多数の車両要求を整理し、それらの要求のうち２つ以上の要求を同時に未決にしておくことができるように構成される。図２に示されるように、デバイス２０はユーザが車両要求を行うための第１のボタン１２６を有する。一実施形態において、このボタンは、要求が開始されるまでに１秒などの所定の長さの時間押下されなければならない。デバイス２０は、先に行った車両要求をキャンセルするための第２のボタン１２８を更に有する。デバイス２０の筐体１２２の中には、サーバ１０と通信する手段がある。これは、通常ＧＳＭ（登録商標）又はＧＰＲＳなどの移動通信モジュールである。これに加えて又はその代わりに、デバイス２０は、例えば移動通信サービスエリアが限定されている場合などのためのＷｉＦｉモジュールを含んでもよい。そのようなモジュールは、ケーシング１２２内部のプリント回路基板（ＰＣＢ）１３６に配置されるのが好ましい（図３に示される）。デバイス２０は、インターネットへの物理的接続を更に有してもよいが、そのような構成はデバイス２０を配置できるスペースを制限してしまう。

デバイス２０は外部電源１３８に接続可能であるが、それに加えて又はその代わりに、デバイス２０はバッテリ又は他の内部電源を有してもよいことが理解されるだろう。

デバイス２０は、ＬＥＤ又は他の類似の発光素子１３０及び／又はスピーカなどの出力手段を更に備え、好適な実施形態において、出力手段は、車両が乗車場所から所定の距離内に入ったこと又は車両が乗車場所に到着したことを示すために使用される。

ボタン１２６が押下されると、デバイス２０と関連する参照番号を含む車両要求がサーバ１０へ送信される。サーバ１０は、システム内の固定場所デバイスごとに１つずつ設定された参照番号及び各参照番号と関連する乗車場所のリストを有する。これにより、送信される車両要求に含まれる必要があるデータの量が制限され、デバイス２０と関連する乗車場所を容易に変更できるようになる。

デバイス２０は関連するディスプレイ１２４を有し、ディスプレイ１２４は未決の要求ごとのメッセージを表示するために使用される。メッセージは要求の現在の状態を示す。ディスプレイ１２４は、図２に示されるようにデバイス２０のケーシング２２の中に配置されてもよい。しかし、他の実施形態において、ディスプレイ１２４はデバイスとは別であってもよく、例えば付近の壁面に配置されてもよい。例えばメッセージは、最初に、要求が確認されたことを連絡できる。その後、車両が要求を受け入れ、乗車場所へ向かう途中であることを連絡するために、メッセージは変更される。このメッセージは、車両、運転手及び／又は乗車場所のＥＴＡの詳細を更に含んでもよい。その後、車両が乗車場所に到着したことを示すためにメッセージは変更できる。

要求と関連する車両が乗車場所を離れたことを示す指示がサーバ１０から受信された時点で、メッセージはディスプレイから除去される。この判定は、サーバ１０において、例えば乗車場所を含む領域に車両が所定の長さの時間ととどまっていた後にその領域の外へ移動したことを判定することにより自動的に実行可能である（以下に更に詳細に説明される）。あるいは、乗車場所を離れつつあることを車両の運転手がナビゲーションデバイス２００で指示することも可能であり、この指示はサーバ１０を介してデバイス２０へ送信されることが可能である。

デバイス２０は、テーブル、カウンター又は壁面などの平坦な面１４２に装着されるように構成される。従って、デバイス２０は、デバイスを面１４２に固定するためにねじ１４０を挿入できる開口部１３４を有する。デバイスを１箇所に固着させ、バー又はレストランなどの環境ではよく見られるようなデバイス２０が湿った面の上で動くことを防止するのを助けるために、デバイス２０の底部１３５は、ゴム製１３２の脚のような支持構造を更に有する。このため、デバイスのケーシング１２２は通常は耐水性である。

車両要求デバイス１２がとることができる別の形は、移動電話、タブレットコンピュータ、ポータブルデジタルアシスタント（ＰＤＡ）などの移動デバイス２２である。

移動デバイス２２は、入力デバイスに接続されたプロセッサ及び表示画面を含む筐体の中に配置される。入力デバイスは、情報を入力するために利用されるキーボードデバイス、音声入力デバイス、タッチパネル及び／又は他の既知の入力デバイスを含むことができ、表示画面は、ＬＣＤディスプレイなどの何らかの種類の表示画面を含むことができる。特に好適な構成において、複数の表示選択肢のうち１つを選択するか又は複数の仮想ボタンのうち１つを起動するためにユーザが表示画面の一部に触れるだけでよいように、入力デバイス及び表示画面は、タッチパッド又はタッチスクリーン入力部を含む一体型入力表示デバイスとして一体化される。

移動デバイス２２は、デバイス２２の現在場所を判定可能な場所判定手段を有する。好適な一実施形態において、場所判定手段は、デバイスの現在場所を判定するために、場所データを含む衛星ブロードキャスト信号を受信し且つ処理するＧＰＳ受信機のような全地球的航法衛星システム（ＧＮＳＳ）受信機である。

ユーザが車両要求を作成し、その車両要求をサーバ１０へ送信できるようにするソフトウェアアプリケーションが移動デバイス２２のプロセッサで実行される。車両要求は、ＧＳＭ（登録商標）又はＧＰＲＳモジュールなどの無線通信モジュールを使用してサーバ１０へ送信される。車両要求は乗車場所を含むが、乗車場所は移動デバイス２２の現在場所（ＧＮＳＳ受信機から取得される）であってもよく、あるいはユーザが入力デバイスで入力する場所であることも可能である。車両要求は、同様に入力デバイスでユーザにより選択可能な降車場所を更に含んでもよく、乗車時刻を更に含んでもよい。乗車時刻は、可能な限り早くタクシーが必要であることを示すことができるが、入力デバイスでユーザにより入力される将来の特定の時刻であってもよい。

前述のように、移動デバイス２２からの車両要求がサーバ１０で受信されると、その要求の基準に適合する車両１４が選択される。そこで、サーバ１０において２つのデバイスの間に一時的関連が形成され、すなわち要求された走行が完了するまで、２つのデバイスがシステムで連携されるように、一時的関連が形成される。サーバ１０は選択された車両１４の詳細を移動デバイス２２へ送信する。詳細は、車種、色、登録番号などの車両に関する情報、顔写真、氏名、電話番号などの運転手に関する情報、並びに車両の現在位置及び／又は乗車場所まで車両が走行するルート及び／又は乗車場所への推定到着時刻に関する情報を含むことができる。車両が乗車場所まで走行する間の車両の進行状況をユーザが見ることができるように、サーバ１０は選択された車両１４の位置を移動デバイス２２へ送信し続けてもよい。

ユーザは、要求する走行で運転することを望む１人又は複数の好ましい運転手を、サーバ１０へ送信される要求の中に含めることができる。あるいは、ユーザは、サーバ１０に記憶されるプロファイルと関連する１人又は複数の好ましい運転手を定めていてもよい。サーバ１０は、要求を完了するために車両を選択する場合に好ましい運転手を考慮に入れる。

乗車場所に車両１４が到着したことは移動デバイス２２に送信され、ユーザに対して適切な警報が提供される。警報は、デバイスの表示画面の目に見える警報、聴き取れる警報、触覚による警報又はそれらの何らかの組み合わせであってもよい。乗車場所への車両の到着は、例えば以下に更に詳細に説明されるように、サーバ１０により自動的に判定されてもよい。あるいは、運転手が自身のナビゲーション装置２００で指示を提供した時点で車両の到着が判定されてもよい。このような警報を提供するのに加えて、乗車場所にある車両１４の現在位置に関する指示が移動デバイス２２で提供されてもよい。この指示は、例えば移動デバイス２２の現在場所から見た場合のサーバ１０から受信された車両１４の現在場所を指す方向指示又は矢印であることが可能である。この方向指示は、コンパス、ジャイロスコープ及び加速度計などの移動デバイス２２の中の何らかの適切な手段を使用して生成可能だろう。例えば車両１４が街路上の何台かの他のタクシーの隣に駐車されているために、ユーザがその車両を識別するのが難しい場合でも、このような方向指示又は矢印により、ユーザは車両１４を識別することができる。

選択された車両１４をユーザが発見し、車両１４に乗り込むと、当初の車両要求から降車場所が既に分かっている場合には、車両の運転手は直ちに降車場所に向けて走行を開始してもよい。あるいは、単純にユーザが運転手に降車場所を知らせてもよく、そこで、運転手は自身のナビゲーション装置２００に目的地を入力してもよい。他の実施形態において、サーバ１０で２つのデバイスの間に一時的関連が形成されているため、ユーザは、自身の移動デバイス２２に所望の降車場所を入力し、その目的地を車両のナビゲーションデバイス２００へ送信してもよい。最終的な降車場所が提供される前に運転手が走行を開始できるように、運転手におおよその目的地を提供した後に、ユーザが降車場所の入力と送信を実行してもよい。この機能により、ユーザが途中で必要に応じて降車目的地を変更できるだろうということが理解されるだろう。

走行に対する支払いは、例えばユーザが関連する特定の金額を有する口座をサーバ１０に設定することにより、自動的に実行されてもよい。ユーザの口座から単純に運賃が引き落とされてもよい。これは、自動的に行われてもよいが、支払う金額に関して運転手及び／又はユーザが各々のデバイスから確認した時点で行われてもよい。

走行終了時に、ユーザは、自身の移動デバイス２２を使用して、走行及び／又は運転手の評価を提供することもできる。この評価はサーバ１０へ送信され、サーバ１０で保持されている運転手の関連詳細情報と関連付けられる。先に説明したように、車両要求を完了するための車両を選択する場合に、ユーザ及び／又はサーバ１０は運転手の評価を使用できる。運転手が計算上の最適ルートに従って走らなかったために、ユーザの走行が時間及び／又は距離に関して必要以上に長くなったとサーバ１０が判定した場合、運転手と関連する評価は自動的に下げられてもよい。

図４は、車両１４の１つに配置できるナビゲーションデバイス２００の例示的な図である。ナビゲーションデバイス２００はブロックの形で示される。尚、ナビゲーションデバイス２００のブロック図は、ナビゲーションデバイスのあらゆる構成要素を含むわけではなく、多くの例示的な構成要素を表しているにすぎない。ナビゲーションデバイス２００は、車両に取り外し可能に取り付けることができるポータブルナビゲーションデバイス（ＰＮＤ）であるとして以下に説明される。しかし、他の実施形態において、ナビゲーションデバイス２００が車両に組み込まれることも可能であることは理解されるだろう。

通常ナビゲーションデバイス２００はデジタルマップデータを含み、デジタルマップデータは、マップに対応する地理的領域内のナビゲート可能ルートの複数の区間を表す複数のナビゲート可能区間を有する。デジタルマップデータは、ナビゲーションデバイスを搭載する車両が走行可能な場所の間のルートを計算し且つ計算されたルートに沿って運転手を案内するための適切なナビゲーション命令を運転手に提供するために、ナビゲーションデバイス２００により使用される。

ナビゲーションデバイス２００は、筐体（図示せず）の中に配置される。筐体は、入力デバイス２０４及び表示画面２０６に接続されたプロセッサ２０２を含む。入力デバイス２０４は、キーボードデバイス、音声入力デバイス、タッチパネル及び／又は情報を入力するために利用される他の何らかの既知の入力デバイスを含むことが可能であり、表示画面２０６は、例えばＬＣＤディスプレイのような何らかの種類の表示画面を含むことが可能である。特に好適な実施形態において、表示された複数の選択肢の中から１つを選択するために又は複数の仮想ボタンのうち１つを起動するためにユーザが表示画面２０６の一部をタッチするだけでよいように、入力デバイス２０４及び表示画面２０６は、タッチパッド又はタッチスクリーンを含む一体型入力表示デバイスとして一体化される。

ナビゲーションデバイス２００は、出力デバイス２０８、例えば可聴出力デバイス（例えば、スピーカ）を含んでもよい。出力デバイス２０８は、ナビゲーションデバイス２００のユーザに対して聴き取れる形の情報を生成できるので、入力デバイス２０４は、入力音声コマンドを更に受信するためにマイク及びソフトウェアを含むことができると同様に理解すべきである。

ナビゲーションデバイス２００において、プロセッサ２０２は、接続線２１０を介して入力デバイス２０４に動作可能に接続され且つ入力デバイス２０４から接続線２１０を介して入力情報を受信するように構成されると共に、表示画面２０６及び出力デバイス２０８のうち少なくとも一方へ情報を出力するために、出力接続線２１２を介して表示画面２０６及び出力デバイス２０８のうち少なくとも一方に動作可能に接続される。更に、プロセッサ２０２は、接続線２１６を介してメモリ資源２１４に動作可能に結合され、接続線２２０を介して入出力（Ｉ／Ｏ）ポート２１８との間で情報を送受信するように更に構成され、Ｉ／Ｏポート２１８は、ナビゲーションデバイス２００の外部にあるＩ／Ｏデバイス２２２に接続可能である。メモリ資源２１４は、例えばランダムアクセスメモリ（ＲＡＭ）のような揮発性メモリ及び例えばフラッシュメモリなどのデジタルメモリのような不揮発性メモリを含む。外部Ｉ／Ｏデバイス２２２は、例えばイヤホンなどの外部聴取デバイスを含んでもよいが、それに限定されない。Ｉ／Ｏデバイス２２２への接続は、ハンズフリー動作のため及び／又は例えばイヤホン又はヘッドホンへの接続などの音声起動操作のため及び／又は例えば移動電話への接続のためのカーステレオユニットなどの他の何らかの外部デバイスに対する有線接続又は無線接続であることが可能であり、移動電話接続は、例えばナビゲーションデバイス２００とインターネット又は他の何らかのネットワークとの間でデータ接続を確立し及び／又は例えばインターネット又は他の何らかのネットワークを介するサーバへの接続を確立するために使用されてもよい。

図４は、接続線２２６を介するプロセッサ２０２とアンテナ／受信機２２４との動作接続を更に示し、アンテナ／受信機２２４は、例えばＧＰＳアンテナ／受信機であることが可能である。図示の都合上、図中符号２２４により示されるアンテナ及び受信機は概略的に組み合わされた形であるが、アンテナ及び受信機は個別に配置された構成要素であってもよく、アンテナは、例えばＧＰＳパッチアンテナ又はヘリカルアンテナであってもよいことが理解されるだろう。

更に、図４に示される電子構成要素が従来通り電源（図示せず）により給電されることは当業者には理解されるだろう。当業者には理解されるように、図４に示される構成要素の異なる構成も本出願の範囲内に含まれると考えられる。例えば図４に示される構成要素は、有線接続及び／又は無線接続などを介して互いに通信してもよい。従って、本出願のナビゲーションデバイス２００の範囲は、ポータブル又はハンドヘルドナビゲーションデバイス２００を含む。

また、図４のポータブル又はハンドヘルドナビゲーションデバイス２００は、例えば自転車、バイク、乗用車などの車両又は船に周知のように接続可能、すなわち「ドッキング」可能である。そのようなナビゲーションデバイス２００は、ポータブル又はハンドヘルドナビゲーションで使用するためのドッキング場所から取り外し可能である。

次に図５を参照すると、ナビゲーションデバイス２００は、デジタル接続（例えば、既知のＢｌｕｅｔｏｏｔｈ（登録商標）技術を介するデジタル接続）を成立させる移動デバイス（図示せず）（移動電話、ＰＤＡ及び／又は移動電話技術を伴う何らかのデバイスなど）を介してサーバ３０２との「移動」ネットワーク接続又は通信ネットワーク接続を確立してもよい。その後、ネットワークサービスプロバイダを介して、移動デバイスは、サーバ３０２との間にネットワーク接続（例えば、インターネットを介して）を確立することができる。従って、「リアルタイム」の又は少なくともごく「最新」の情報ゲートウェイを提供するために、ナビゲーションデバイス２００（単独で及び／又は車両に搭載されて走行する間に移動可能であり、多くの場合に移動している）と、サーバ３０２との間に「移動」ネットワーク接続が確立される。

移動デバイス（サービスプロバイダを介する）とサーバ３０２などの別のデバイスとの間の、例えばインターネット（ワールドワイドウェブなど）を使用するネットワーク接続の確立は、周知のように実行可能である。これは、例えばＴＣＰ／ＩＰレイヤードプロトコルの使用を含むことができる。移動デバイスは、ＣＤＭＡ、ＧＳＭ（登録商標）、ＷＡＮなどの任意の数の通信規格を利用できる。

そこで、移動電話又は例えばナビゲーションデバイス２００の中の移動電話技術によるデータ接続を介して実現されるインターネット接続が利用されてもよい。この接続の場合、サーバ３０２とナビゲーションデバイス２００との間のインターネット接続が確立される。これは、例えば移動電話又は他の移動デバイス及びＧＰＲＳ（汎用パケット無線サービス）接続を介して実行可能である（ＧＰＲＳ接続は通信事業者により提供される移動デバイス向け高速データ接続であり、ＧＰＲＳはインターネットに接続するための方法である）。

ナビゲーションデバイス２００は、例えば既存のＢｌｕｅｔｏｏｔｈ（登録商標）技術を使用して周知の方法で移動デバイスとのデータ接続、最終的にはインターネット及びサーバ３０２とのデータ接続を更に完了でき、このデータプロトコルは、例えばＧＳＭ規格のデータプロトコル規格であるＧＲＭなどの任意の数の規格を利用できる。

ナビゲーションデバイス２００は、ナビゲーションデバイス２００に内蔵された独自の移動電話技術を含んでもよい（例えば、アンテナを含むか、又はオプションとしてナビゲーションデバイス２００の内部アンテナを使用する）。ナビゲーションデバイス２００に内蔵された移動電話技術は、先に指定したような内部構成要素を含むことができ、及び／又は例えば必要な移動電話技術及び／又はアンテナによって完成する差し込み式カード（例えば、加入者アイデンティティモジュール（ＳＩＭ）カード）を含むことができる。そのため、ナビゲーションデバイス２００に内蔵された移動電話技術は、例えばインターネットを介して、移動デバイスの場合と同様にナビゲーションデバイス２００とサーバ３０２との間にネットワーク接続を確立することができる。

ＧＰＲＳ電話設定の場合、移動電話の型式、メーカーなどの絶えず変化する状況に対しても正しく機能できるように、Ｂｌｕｅｔｏｏｔｈ（登録商標）有効化ナビゲーションデバイスが使用されてもよい。型式／メーカー別の特定の設定は、例えばナビゲーションデバイス２００に記憶されてもよい。この情報に関して記憶されたデータは更新可能である。

図５には、ナビゲーションデバイス２００は、いくつかの異なる構成のうちいずれかの構成により実現可能な汎用通信チャネル３１８を介してサーバ３０２と通信するものとして示される。サーバ３０２とナビゲーションデバイス２００との間に通信チャネル３１８を介する接続が成立した場合、サーバ３０２及びナビゲーションデバイス２００は通信できる（尚、このような接続は、移動デバイスを介するデータ接続、パーソナルコンピュータを介してインターネットを介する直接接続などである）。

サーバ３０２は、図示されていないかもしれない他の構成要素に加えて、メモリ３０６に動作可能に接続されたプロセッサ３０４を含み、プロセッサ３０４は、有線接続又は無線接続３１４を介して大容量データ記憶デバイス３１２に更に動作可能に接続される。通信チャネル３１８を介してナビゲーションデバイス２００との間で情報を送送信するために、プロセッサ３０４は、送信機３０８及び受信機３１０に更に動作可能に接続される。送受信される信号は、データ信号、通信信号及び／又は他の伝搬信号を含んでもよい。送信機３０８及び受信機３１０は、ナビゲーションシステム２００の通信設計で使用される通信要件及び通信技術に従って選択又は設計されてもよい。更に、送信機３０８及び受信機３１０の機能は１つの信号トランシーバとして組み合わされてもよい。

サーバ３０２は大容量記憶デバイス３１２に更に接続され（又は大容量記憶デバイス３１２を含み）、尚、大容量記憶デバイス３１２は通信リンク３１４を介してサーバ３０２に結合されてもよい。大容量記憶デバイス３１２は、ナビゲーションデータ及びマップ情報を記憶し、サーバ３０２とは別のデバイスであることが可能であるが、サーバ３０２に組み込まれることも可能である。

ナビゲーションデバイス２００は、通信チャネル３１８を介してサーバ３０２と通信するように構成され、先に図４に関して説明したようなプロセッサメモリなど、並びに通信チャネル３１８を介して信号及び／又はデータを送受信するための送信機３２０及び受信機３２２を含み、それらのデバイスはサーバ３０２以外のデバイスと通信するために使用されることも更に可能である。更に、送信機３２０及び受信機３２２は、ナビゲーションデバイス２００の通信設計で使用される通信要件及び通信技術に従って選択又は設計され、送信機３２０及び受信機３２２の機能は、１つのトランシーバとして組み合わされてもよい。

サーバメモリ３０６に記憶されるソフトウェアは、プロセッサ３０４に対する命令を提供し、サーバ３０２がナビゲーションデバイス２００にサービスを提供することができる。サーバ３０２により提供されるサービスの１つは、ナビゲーションデバイス２００からの要求を処理すること及び大容量データ記憶装置３１２からナビゲーションデバイス２００へナビゲーションデータを送信することである。サーバ３０２により提供される別のサービスは、所望のアプリケーションに関する種々のアルゴリズムを使用してナビゲーションデータを処理すること及びそれらの計算の結果をナビゲーションデバイス２００へ送信することである。

通信チャネル３１８は、ナビゲーションデバイス２００とサーバ３０２を接続する伝搬媒体又は伝搬経路を総称して表す。サーバ３０２及びナビゲーションデバイス２００は、共に、通信チャネルを介してデータを送信する送信機及び通信チャネルを介して送信されたデータを受信する受信機を含む。

通信チャネル３１８は特定の通信技術に限定されない。更に、通信チャネル３１８は１つの通信技術に限定されない。すなわち、チャネル３１８は多様な技術を使用するいくつかの通信リンクを含んでもよい。例えば通信チャネル３１８は、電気的通信、光学的通信及び／又は電磁的通信などのための経路を提供するように適合されることが可能である。そのため、通信チャネル３１８は、電気回路、ワイヤ及び同軸ケーブルなどの電気導体、光ファイバケーブル、変換器、無線周波数（ＲＦ）波、大気、空間などのうち１つ又はそれらの組み合わせを含むが、それに限定されない。更に、通信チャネル３１８は、例えばルータ、リピータ、バッファ、送信機及び受信機のような中間デバイスを含むことができる。

１つの例示的な構成において、通信チャネル３１８は電話ネットワーク及びコンピュータネットワークを含む。更に、通信チャネル３１８は、無線周波数通信、マイクロ波周波数通信、赤外線通信などの無線通信に対応可能であってもよい。また、通信チャネル３１８は衛星通信に対応できる。

通信チャネル３１８を介して送信される通信信号は、所定の通信技術に関して必要とされる又は望まれるような信号を含むが、それに限定されない。例えば信号は、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、汎欧州移動電話方式（ＧＳＭ（登録商標））などのセルラ通信技術での使用に適合されてもよい。通信チャネル３１８を介して、デジタル信号及びアナログ信号の双方を送信可能である。それらの信号は、通信技術で望まれるような変調信号、暗号化信号及び／又は圧縮信号であってもよい。

サーバ３０２は、無線チャネルを介してナビゲーションデバイス２００によりアクセス可能な遠隔サーバを含む。サーバ３０２は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、バーチャルプライベートネットワーク（ＶＰＮ）などに配置されたネットワークサーバを含んでもよい。他の実施形態において、サーバ３０２は、デスクトップコンピュータ又はラップトップコンピュータなどのパーソナルコンピュータを含んでもよく、通信チャネル３１８は、パーソナルコンピュータとナビゲーションデバイス２００との間に接続されたケーブルであってもよい。あるいは、サーバ３０２とナビゲーションデバイス２００との間にインターネット接続を確立するために、ナビゲーションデバイス２００とサーバ３０２との間にパーソナルコンピュータが接続されてもよい。あるいは、インターネットを介してナビゲーションデバイス２００をサーバ３０２に接続するために、移動電話又は他のハンドヘルドデバイスにより、インターネットへの無線接続が確立されてもよい。

ナビゲーションデバイス２００は、情報ダウンロードによってサーバ３０２から情報を提供されてもよく、このダウンロードは、自動的に更新されるか又はユーザがナビゲーションデバイス２００をサーバ３０２に接続した時点で定期的に更新されてもよく、及び／又は例えば無線移動接続デバイス及びＴＣＰ／ＩＰ接続を介してサーバ３０２とナビゲーションデバイス２００との間で絶えず又はより頻繁に接続が行われる場合には、更に動的なダウンロードであってもよい。多くの動的計算に対して、サーバ３０２のプロセッサ３０４は大量の処理ニーズを処理するために使用されてもよいが、ナビゲーションデバイス２００のプロセッサ２１０は、多くの場合にサーバ３０２への接続とは無関係に、多くの処理及び計算を処理することができる。

好適な実施形態において、何人かの異なる人物により同一のデバイスを使用できるように、ナビゲーションデバイス２００は、複数のユーザプロファイルを記憶するように構成される。何人かの異なる運転手の間で共有されることが多いタクシー又は他の類似の車両の中でナビゲーションデバイス２００が使用される場合に、これは有益である。例えば「運転手Ａ」アイコン４００にタッチすることにより又は「新規ユーザ」アイコン４０２を使用して詳細情報を入力することにより（図６に示される）、特定のユーザがデバイスにログインすると、この選択の指示がサーバ１０へ送信されるので、サーバはその運転手と車両を関連付けることができる。従って、ユーザから送付された車両要求を完了するために車両が選択された時点で、正確な運転手詳細データ及び／又は運転手評価がユーザに供給されることが可能である。

サーバ１０で車両要求が受信されると、１つ以上の適切な車両１４が選択され、要求は、この車両又は各車両のナビゲーションデバイス２００へ送信される。ナビゲーションデバイス２００に示される画面の一例が図７に示される。この場合、車両要求４０４は、アムステルダムの市の中心にある場所で可能な限り早く車両を必要としている人物に関する。

図７の画面の左下隅には、「Ｂｒｅａｋ（休憩中）」４０６とマークされた選択されたアイコンがある。運転手は、現在の時点では要求に応えられないことを示すためにいつでもこのアイコンにタッチすることができる。アイコン４０６にタッチすると、現在の時点で車両が利用不可能であることをシステムに通知するための指示がナビゲーションデバイス２００からサーバ１０へ送信される。

運転手が車両要求メッセージ４０４にタッチすべきである場合、要求と関連する乗車場所が表示中のマップの中心に来るように、ナビゲーションデバイスは表示中のマップをパンする。画面上で、例えば円４１０により及び／又はマップ表示のそれ以外の部分をフェードさせるか又はグレイで表示することにより乗車場所が強調表示されるので、運転手は、乗車場所を迅速に識別できる。同様に運転手が乗車場所を識別するのを助けるために、画面上に車両４０８の現在位置も示される。運転手が車両要求に応じたい場合、運転手はアイコン４１４にタッチすることができる。あるいは、運転手が車両要求を辞退したい場合、運転手はアイコン４１２にタッチできる。

運転手が車両要求４０４に応じた場合、運転手は、図９に示されるように要求を獲得するか、又は図１０に示されるように要求を失うかのいずれかである。

運転手が要求を獲得した場合、車両要求の更なる詳細がサーバ１０によりナビゲーションデバイス２００へ送信される。例えば問題の車両要求の場合、図１１に示されるように、要求は、Ｊｏｎａｔｈａｎ Ｍｉｌｅｒ Ｊｏｈｎｓｏｎにより又はその代理の人物により送付されている。要求の詳細は、乗車場所（Ａ）４２４、この場合はアムステルダム中心のＤａｍｒａｋを少なくとも含む。運転手は、要求の日付４２５及び乗車場所への推定到着時刻４２３を見る。乗車場所のＥＴＡは、ナビゲーションデバイス２００が車両の現在場所から乗車場所までのルートを、好適な実施形態では交通状態履歴、現在の交通状態及び／又は今後の推定交通状態を考慮に入れて計画することにより判定される。図１１に示されるように、要求は、ユーザが現在どこにいるかを示すメッセージ、例えば「Ｉ‘ｍ ｓｔａｎｄｎｇ ｉｎ ｆｒｏｎｔ ｏｆ ｔｈｅ ｙｅｌｌｏｗ ｐｈｏｎｅ ｂｏｏｔｈ（黄色の電話ボックスの前に立っています）」などのメッセージ及び運転手がユーザと連絡をとれるようにするためのアイコン４２２を更に含んでもよい。

運転手は、図１１に示される走行詳細画面を走行中いつでもアクセス可能であり、現在の走行状態を反映させるために、画面に含まれる情報は更新される。例えばユーザが場所Ａで乗車し、運転手に目的地の場所を告げた場合、画面には、目的地の場所及び関連ＥＴＡの詳細が更に含まれる。運転手は、先に受け入れた走行をキャンセルする場合にも走行詳細画面を使用できる。これは、「走行キャンセル」アイコン４２６を選択することにより実行可能であり、適切なメッセージがサーバ１０へ送信される。メッセージは、交通状態、車両が事故に巻き込まれたこと又は車両が故障したことなどのキャンセルの理由を含んでもよい。そのようなキャンセルメッセージを受信すると、サーバ１０では、別の車両を乗車場所に差し向け、ユーザに適切な通知を送信するか、あるいは現在の車両が故障してしまった場合に別の車両を車両の現在場所へ差し向けるなどの適切な措置を講じることができる。正当な理由なく走行がキャンセルされた場合、運転手の評価が特定の量だけ自動的に下げられることはありうるだろう。

走行が運転手により受け入れられ及び／又は獲得された場合、ナビゲーションデバイス２００は、乗車場所までのルートを自動的に計算し、運転手を案内する。これは、例えば図１２に示される。同様に図１２に示されるように、「乗車場所到着」アイコン４２８を運転手が選択することにより、乗車場所への車両の到着を指示することができる。しかし、乗車場所への車両の到着がサーバ１０で自動的に判定されてもよく、それを示すメッセージがナビゲーションデバイス２００へ送信されることも考えられる。サーバ１０が車両の到着及び／又は特定の場所からの出発を自動的に検出できる方法は、以下に更に詳細に説明される。

車両が乗車場所（Ａ）に到着すると、ナビゲーションデバイス２００は、図１３に示される画面を表示する。この時点でユーザは車両に乗り込んでおり、降車場所がまだ提供されていない場合、すなわち当初の車両要求の中で提供されていない場合、運転手は降車場所をユーザに尋ねる。降車場所は、運転手によりナビゲーションデバイス２００に入力されてもよいが、ユーザにより要求デバイス、例えば移動デバイス２２で提供されてもよい。降車場所が提供されたならば、運転手は「降車場所へ出発」アイコン４３０（図１３に示される）を選択でき、ナビゲーションデバイス２００は、乗車場所（Ａ）から降車場所（Ｂ）までのルートを計算し、運転手に対してナビゲーション案内を提供する。

図１３に示されるように、車両が乗車場所に到着しても、運転手とユーザが直ちに互いの居場所を特定できない場合、運転手は、「顧客に連絡」アイコン４３２を使用してユーザへの連絡を試みることができる。それでも運転手がユーザの居場所を特定できない場合、運転手は「発見できず」アイコン４３４を選択でき、それに応答して、適切なメッセージがサーバ１０へ送信される。サーバ１０は、そのような事象に続いて、ユーザのアカウントと関連するユーザの評価を下げてもよい。これにより、ユーザがシステムを悪用して、無効車両要求を出し続けるという事態が防止される。

運転手が降車場所まで案内されている間、ナビゲーションデバイス２００には、図１４に示されるような画面が表示される。乗車場所への到着の場合と同様に、図１４に示されるように、「降車場所到着」アイコン４３６を運転手が選択することにより、降車場所への車両の到着が指示されることが可能である。しかし、先の場合と同様に、降車場所への車両の到着はサーバ１０で自動的に判定されてもよく、それを示すメッセージがナビゲーションデバイス２００へ送信されることも考えられる。

車両が降車場所（Ｂ）に到着すると、ナビゲーションデバイス２００は、図１５に示される画面を表示する。この画面から、運転手は、走行時間及び走行距離を含む完了した走行４３８の概要を知ることができる。運転手は、「走行終了」アイコン４３９を選択することにより走行を終了でき、その結果、走行の支払いを確認するためのメッセージがサーバ１０によりユーザの移動デバイス２２へ送信されることが可能である。運転手は、走行及び／又はユーザに関する情報を提供するために、「フィードバック」アイコン４４０を選択することもできる。例えば運転手は、今後、そのユーザからの車両要求を受信することを望まないことを示すことができる。

次に、図１６を参照して、サーバ１０が乗車場所へ又は降車場所への車両の到着を自動的に判定できる方法を説明する。

サーバ１０は、乗車場所又は降車場所を含む地理的領域を定義する（５００）。通常この領域は、乗車場所又は降車場所を中心とする半径２５０ｍの円である。次に、定義された領域内で車両が減速し、所定の長さの時間停車していたか否か及び計算上のルートと関連する推定到着時間を含む時間ウィンドウの範囲内の長さの時間停車していたか否かを判定するために、その場所までの車両の走行に関連する位置データを解析することが可能である（５０４）。到着検出アルゴリズムで計算上のルートのＥＴＡを利用することにより、実際には車両が例えば隣接する道路の交通信号で停車しているにもかかわらず、車両が所定の場所に到着したと誤って判定する可能性は大幅に低減される。

上記の説明では、説明される車両要求デバイス１２のうち１つを使用してユーザが車両に対する要求を行ったこと及び車両が要求された乗車場所に到着したときにユーザは車両に乗り込むことを想定している。このシナリオでは、車両要求を送信した結果、サーバ１０において、車両要求デバイス１２と車両１４との間に一時的関連が形成される。その後、この一時的関連を使用して、電子支払い、途中での降車場所の変更、運転手及び／又は乗客の評価及び車両が走行するルートを乗客が観察することなどの本発明と関連する利点の多くを提供できる。しかし、付近を通りかかった車両をユーザが呼び止めた場合、ユーザ及び車両が共に本発明の車両要求管理システムの一部になっていても、そのような一時的関連は形成されない。

図１７に示される方法を使用して、この問題を克服できる。

通りかかったタクシーをユーザが呼び止めた場合、ユーザは、自身の移動デバイス２２を使用して、ユーザが車両１４に乗り込んだか又は乗り込もうとしているという指示をサーバ１０へ送信することができる（６００）。この指示は、例えば単純にユーザの移動デバイス２２で適切なソフトウェアアプリケーションを開くことにより生成可能である。移動デバイス２２からサーバ１０へ送信され、移動デバイス２２の位置及び動きを示す位置データを使用して、サーバ１０は、移動デバイス２２を含む事前定義済み地理的領域の中にある車両を識別できる。この領域は、例えば移動デバイス２２の現在場所を中心とする半径約３０ｍの円であってもよい（６０４）。そのような車両が識別されたならば、サーバ１０において、いずれかの車両が移動デバイス２２と同時に同一の走行経路に沿って移動しているか否かを判定するために、移動デバイス２２から受信された位置データと識別された車両の位置データとの比較を実行できる。そのような同時移動は、類似する速度、加速度、方向転換などにより指示可能である。移動デバイス２２と同時に移動しているとして識別される車両が１台のみである場合、現在の時点でユーザが乗車している車両はこの車両であるに違いないと推測でき、サーバ１０は移動デバイス２２とその車両の中のナビゲーション装置２００との関連を形成する。あるいは、複数の候補車両が識別された場合、適切な識別情報、例えば車両及び／又は運転手の詳細を含む車両のリストがサーバ１０により移動デバイス２２へ送信される（６０８）。そこで、ユーザは移動デバイス２２においてリストから適切な車両を選択でき、この選択はサーバ１０へ返送されることが可能である（６１０）。次に、サーバ１０は、移動デバイス２２を選択された車両の中のナビゲーションデバイス２００と関連付ける（６１２）。

次に、図１８及び図１９を参照して、本発明に従って車両要求に応じるために車両を選択する方法のいくつかの好適な実施形態を説明する。

「即時遂行」型の車両要求、すなわち、将来の指定時刻ではなく可能な限り早く提供されるユーザからの要求に関連して、本発明の好適な一実施形態を説明する。しかし、将来の指定時刻に合わせて予定された車両要求、又は即時型車両要求と予定型車両要求との組み合わせにも方法が適用されてよいことは理解されるだろう。予定型要求を処理するために方法を変形するいくつかの方法の概要は以下に説明される。

図１８のフローチャート、並びにサーバ１０、複数の車両要求デバイス１２及び複数の車両１４を含み、各車両がルート計画機能及びナビゲーション機能を有するデバイス２００を装備する図１に示される種類のシステムに関連させて、方法を説明する。本発明の方法は、車両要求で指定される基準に適合するように適切な車両をサーバが選択する方式に関連する。

サーバ１０は、車両要求デバイス１２からユーザからの車両要求を受信する（図１８のステップ７００）。車両要求デバイスは、先に図１に関連して説明した形態のいずれかであってもよい。車両要求は、乗車場所又は乗車場所を取り出すために使用できるデータを含み、乗車時刻、降車場所、所望の車種又は車両の大きさ（例えば、乗用車、ミニバン、リムジンなど）、乗客の人数、並びにチャイルドシートの必要性、障害者対応の必要性又は運転手の指名の有無などの何らかの付加的プリファレンスのうち少なくとも１つを更に含んでもよい。移動通信ネットワーク、インターネットなどの何らかの適切な通信手段を使用して、車両要求はサーバ１０へ送信可能である。

車両要求を受信すると、サーバは、サーバにおける要求の受信時刻を示すパラメータを要求に割り当てる（７０２）。このパラメータは、時刻又は時刻を示すデータ、例えば先行要求及び後続要求に対して所定の要求が受信された時刻を判定するために使用される番号であってもよい。

従来のシステムでは、車両は、通常は要求と関連する基準、乗車場所及び利用可能な車両の地理的場所を参照することにより、受信後に車両要求に割り当てられるだろう。しかし、発明者は、問題の車両要求に最もよくマッチするということに基づいて各車両要求に車両を割り当てる方式は、システム全体で実現可能なマッチングの程度に関しては不利だろうと認識した。以下の例は、従来の割り当て方法と関連する問題点を示す。

一例として、図１９に示される状況を考える。この場合、道路の所定の長さの部分にタクシーＡ及びタクシーＢの２台の利用可能車両がある。短時間のうちに連続して２つの車両要求が受信される。受信された第１の要求はＴｒｉｐ１であり、第２の要求はＴｒｉｐ２である。従来のシステムは、Ｔｒｉｐ１を受信し、その要求と関連する乗車場所への車両の近接度に基づいて、タクシーＡ及びＢのうち１台をその要求に割り当てるだろう。Ｔｒｉｐ１と関連する乗車場所は、タクシーＡとタクシーＢとの間にあり、タクシーＡから道路に沿って１０分の場所、タクシーＢからは９分の場所であると想定する。従来のシステムは、Ｔｒｉｐ１をタクシーＢに割り当て、待ち時間は９分になるだろう。この例では、次に受信されたＴｒｉｐ２は、道路に沿ってタクシーＡから離れる方向に、タクシーＢから１０分の乗車場所と関連する。Ｔｒｉｐ１はタクシーＢに割り当てられたばかりであるので、この車両は、Ｔｒｉｐ２に応じるために利用できなくなっている。そこで、Ｔｒｉｐ２はタクシーＡに割り当てられなければならず、タクシーＡから道路に沿って合わせて２９分となる。車両の推定到着時刻に従ってベストマッチに基づいて各要求を割り当てる方法は、ユーザによっては、例えばＴｒｉｐ１のユーザの場合は待ち時間が短くなるが、他のユーザ、例えばＴｒｉｐ２と関連するユーザには負担がかかることがわかるだろう。Ｔｒｉｐ１の受信後ただちに割り当てを実行するのではなく、割り当てを猶予していたならば、Ｔｒｉｐ２が受信され、割り当て処理の中でＴｒｉｐ１及びＴｒｉｐ２の双方を考慮に入れることが可能だっただろう。その場合、最良の割り当てはＴｒｉｐ１をタクシーＡに割り当て、Ｔｒｉｐ２をタクシーＢに割り当てることであり、その結果、Ｔｒｉｐ１のユーザの待ち時間は１０分になり、Ｔｒｉｐ２のユーザの待ち時間は１０分になるだろう。従って、Ｔｒｉｐ１及びＴｒｉｐ２の平均待ち時間は、１９分から１０分に短縮される。

発明者は、車両を要求に割り当てる場合に、車両要求のクラスタをまとめて考慮することにより、要求の集合に対して車両をより最適に要求に適応させることができ、平均待ち時間を短縮できると理解した。本発明の方法によれば、車両要求はマッチングを目的として「クラスタ」としてまとめられる。

図１８を参照して説明すると、サーバで新規車両要求が受信され、サーバへの受信時刻を示すパラメータが割り当てられた場合、その車両要求は直ちに要求のクラスタに割り当てられる。要求のクラスタはまとめて車両とマッチングされる要求の群であり、すなわちマッチングはクラスタ中のすべての要求を考慮に入れる。本発明は、クラスタ中の要求が特定の基準に従って関連する結果となるようにクラスタを生成する。

車両要求をクラスタに割り当てるために、要求が既存のクラスタのいずれかの要求に関連するか否かを判定しなければならない（７０４）。これは、既存の各クラスタと関連する「関連性パラメータ」を使用して判定される。一実現形態における、関連性パラメータは、要求が要求の所定の範囲内に乗車場所を有する場合、新規要求は既存のクラスタの要求と関連すると考えることを要求する。

要求がどの既存のクラスタのどの要求とも関連しないことが判明した場合、要求は新たなクラスタを開始するために使用される（７０６）。要求が既存のクラスタの要求と関連することが判明した場合、その要求はそのクラスタに追加される（７０８）。要求が２つ以上の既存のクラスタの要求と関連することが判明した場合、その要求は、既存の各クラスタを併合することにより形成される新たなクラスタに追加される。

各クラスタは作成時刻を割り当てられる。クラスタに第１の要求が割り当てられるときに、その要求がクラスタを開始するように生成されたクラスタの場合、クラスタの作成時刻は、要求がクラスタに追加された時刻に対応する。既存のクラスタを併合することによりクラスタが作成された場合、作成時刻は、新たなクラスタの一部を形成する既存の最も古いクラスタの作成時刻に設定される。

このようにして、関連する要求を含むクラスタが構成される。クラスタが「完成した」とみなされるまで、既存のクラスタに新たな要求を追加できる。クラスタが完成すると、新たな要求は追加されず、クラスタ中の要求は利用可能車両とマッチングされる。

各クラスタは、クラスタが満杯であると判定するために使用される２つの閾値と関連付けられる。第１の閾値（「ｍａｘＳｉｚｅ」）は、クラスタに含むことが可能な要求の最大数、すなわちクラスタの最大サイズに関連する。第２の閾値（「ｍａｘＬａｔｅｎｃｙ」）は、車両要求がマッチング前にシステムにとどまってもよい最長の時間に関連する。この閾値はクラスタの生成時刻を使用して考慮される。要求は受信されると直ちにクラスタに追加されるので、クラスタの生成時刻は、そのクラスタの中の最も古い要求の経過時間を近似すべきである。それらの閾値は、「サイズ」閾値及び「時間」閾値と呼ばれてもよい。これらの閾値のうち一方を超えた場合、クラスタは完成したとみなされ、マッチング段階へ送出される。一般に、定義された関連性パラメータに従ってクラスタに追加できる要求の単位時間当たりの数が多い場合、クラスタは、最大サイズ閾値に達したことに基づいて完成したとみなされる傾向にあり、それほど多くの要求がない場合には、クラスタは、最初に時間閾値に達したことに基づいて完成したとみなされるだろう。

ステップ７１０において、方法は、クラスタがｍａｘＳｉｚｅ又はｍａｘＬａｔｅｎｃｙに達したか否かを判定することを含む。返答がＮＯである場合、アクションは実行されない。返答がＹＥＳである場合、クラスタ中の要求はマッチング段階へ送出される。

ｍａｘＳｉｚｅ閾値又はｍａｘＬａｔｅｎｃｙ閾値を超えたことに基づいてマッチングの準備が整ったクラスタを検索するために、クラスタは定期的にポーリングされてもよい。マッチングを実行する方法は以下に説明される。クラスタが一方の閾値に適合することが判明した場合、そのクラスタ内におけるマッチングが実行される（７１２）。クラスタが閾値に適合しない場合、アクションは実行されない（７１４）。

以上説明した例を参照することにより、特にシステムが混み合っている場合、すなわち要求に応じるために利用可能な車両の空間的密度が高く及び／又は単位時間当たりの要求の数が多い場合、ユーザの平均待ち時間を短縮するようなマッチングの改善は、要求が受信されるたびに各要求に最も近接する車両を単純にマッチングするのではなく、要求群をまとめて考慮できるようにするために、要求と車両とのマッチングを実行する前に少し長く待つことにより実現されてもよいことが理解されるだろう。しかし、要求が果てしなく連続して受信されるオンラインシステムの場合、受信できる要求の数は無制限なので、永久に待ち続けることは不可能である。

一般に、マッチングを実行する前の待ち時間が長いほど、そのマッチングが最適である確率は高くなるだろう。しかし、マッチングが開始される前に、ユーザに更に遅れが生じることに対する待ち時間のバランスをとらなければならない。例として、２つの極端なケースを考える。各走行要求がわかった時点で直ちに要求をマッチングした場合、追加の遅延は起こらないが、全体的に見ると、平均マッチング品質は低下するかもしれない。マッチングを実行する前にすべての走行要求を待っていると、無限の遅延が導入されるが、平均マッチング品質は最適に調整できるだろう。

これらの矛盾する要因の最良のバランスは、所定の時点でシステムがどれほどの量の要求を受信しているか、すなわち走行要求の時間的分布によって決まる。単位時間当たりの要求の数が多い場合、一度でマッチする走行要求の数は追加の遅延を犠牲にして大幅に増加させることができる。これに対し、要求が少ない場合、長時間待っても、追加の走行要求はごくわずかしか受信されないか、まったく受信されないこともありうるので、マッチング品質の改善はほとんど見られず、遅延が著しく長くなるだけである。走行要求の地理的分布も、適切なバランスを実現する上で重要な要因である。例えば、近隣、地方、都市、領域、更には田舎などの１つの地理的領域では、システムは多数の要求を受信するが、別の地理的領域では受信の速度が落ちることもありうる。

本発明は、全体的な状態、例えばシステムがどれほど混み合っているかに基づいてクラスタが生成されるような均一の規則を適用するのではなく、車両要求の時間的分布及び地理的分布及び／又は要求に応じるために利用可能な車両の地理的分布に従属するようにクラスタを生成する。

クラスタが生成される方式、例えばクラスタの相対的サイズ及びクラスタの要求と関連する地理的な場所の広がりは、先に説明した関連性パラメータ、並びに時間閾値及びサイズ閾値（ｍａｘＳｉｚｅ、ｍａｘＬａｔｅｎｃｙ）を使用して制御されてもよい。

この目的のために、車両要求が既存のクラスタに追加されるか否かを判定するために使用されるか、あるいはクラスタを開始することにより又は既存のクラスタを併合することにより新規クラスタを作成するために使用される関連性パラメータは、上記の要因のうち１つ以上に依存する。関連性パラメータは、クラスタと関連する地理的領域内の車両の空間的密度に依存することが望ましい。クラスタと関連する地理的領域は、クラスタが構成されるにつれて変化し、例えば任意の時点でクラスタの一部を形成する要求の乗車場所の概念上の「中心」に基づいて、クラスタの車両要求のうち１つ以上の要求の乗車場所に関して定義される。あるいは、地理的領域は、クラスタに最初に追加された要求と関連する乗車場所に基づいてもよい。領域は、システムの混み合い状態の地理的変化に関して所要のシステムの分解能レベルを提供するために、所望の任意の広がりを有してもよい。例えば領域は、郊外又は市街地の中心であってもよい。

領域内の車両の空間的密度が高い場合、要求と関連する特定の乗車場所にごく近接する場所に車両がある可能性は高い。従って、所定の１台の車両が２つの走行と適切にマッチする車両となる可能性は低いので、まとめてマッチングするために、広い地理的領域に分散した乗車場所と関連する要求を同一のクラスタに含めることは有益ではない。この場合、例えばクラスタ中の要求の乗車場所からの乗車場所の最大距離がごく近くであることを要求する条件を設定することにより、関連性パラメータは、クラスタに追加される要求とクラスタの既存の要求との間に高レベルの関連性を要求するように設定されてもよい。その結果、相対的に狭い地理的領域に制約された乗車場所と関連する要求を含む多数のクラスタが生成されることになる。

同様に、クラスタと関連する地理的領域における要求と関連する乗車場所の空間的密度が高く及び／又はクラスタと関連する地理的領域内の単位時間当たりの要求の数が多い場合、関連性パラメータは、クラスタに追加される要求の間により密接度の高い関連性を要求するように設定されてもよく、その結果、そのような混み合う領域内の狭い地理的広がりと関連する多数のクラスタが生成されることになる。

時間閾値及びサイズ閾値も、同様の要因、すなわちクラスタと関連する地理的領域内の車両又は車両要求の空間的密度及び／又はその領域内の要求の時間的分布に応じて選択されてよい。しかし、他の実施形態において、時間閾値及びサイズ閾値はそのような要因とは無関係である。

時間閾値及びサイズ閾値は、混み合っている場合にシステムの所要の応答性レベルを提供するように設定されてもよい。最大サイズ閾値を低レベルに設定しておけば、システムが更に混み合ってきた場合にこの閾値に到達することになるので、より多くのクラスタが完成したとみなされ、マッチングに利用可能な状態になる。サイズ閾値を高レベルに設定すると、システムがさほど混み合っていない場合でも、時間閾値ｍａｘＬａｔｅｎｃｙに達することに基づいて、より多くのクラスタが完成したとみなされ、マッチングに利用可能な状態になる。時間閾値は、システムに必要とされる所望の応答性レベルを設定するようなレベルに設定されるべきである。

これらの閾値及び関連性パラメータは、所定の時点で混み合っている領域において、可能な限り最短の時間で、すなわち最短の遅延で適切なマッチングレベルを提供するのに十分な大きさの関連走行のクラスタを提供する一方で、所定の時点でさほど混み合っていない地理的領域では、所定の時間閾値、すなわち最大遅延の中で可能な限り大きい関連走行のクラスタ（すなわち、含まれる要求の数に関して大きい）の実現を試行するように設定されるべきである。

一般に、市街地中心型の領域では、すなわちｍａｘＳｉｚｅ閾値を超えるのに基づいてクラスタが完成し、マッチングに利用可能な状態になったとみなされる混み合った領域では、システムは多数の小さなクラスタを提供し、ｍａｘＬａｔｅｎｃｙを超えることに基づいてクラスタが完成し、マッチングに利用可能な状態になったとみなされる混み合い度の低い郊外領域では、システムは少数の大きなクラスタを提供すると予測できる。

関連性パラメータは、地理的要因に基づくだけではなく、要求の関連性を判定するために使用される多数の基準に基づいてもよいことが理解されるだろう。例えば、パラメータは、乗客の人数、車種などの要求と関連するユーザのプリファレンスを考慮に入れてもよいだろう。関連性パラメータにより、同一の車両集合により応じることができると思われる要求のクラスタが形成され、それによりマッチングが容易になるという結果が実現されるべきである。

上記の処理は、即時遂行型要求に関連させることにより説明されたが、システムでは予定型要求にも対応できるだろう。例えば乗車時刻より所定の時間だけ前に、例えば３０分前に要求がクラスタ化処理に導入されてもよく、あるいは専用の個別のクラスタ化システムで要求が処理されることも可能だろう。あるいは、予定型要求は、地理的要因のみに基づく関連性パラメータ、すなわち乗車場所には基づくが、乗車時刻には基づかない関連性パラメータを使用してクラスタ化されることが可能だろう。

次に、各クラスタの要求と車両をマッチングするマッチング段階の動作を説明する。クラスタの完成後、クラスタはマッチングエンジンへ送出される。要求のマッチングはクラスタ内部で実行される。

まず、クラスタ中の車両要求に応じるのに適すると思われる候補車両の集合が選択される。これは、クラスタの１つ以上の要求と関連する乗車場所又は所定の範囲内に現在場所がある車両の部分集合を選択することにより実現される。例えばこの範囲は、１つの乗車場所又は多数の場所の何らかの種類の中心を参照することにより定義されてもよい。これにより、互いにマッチングされる車両の集合及び要求の集合が提供される。

従来のマッチング処理は、乗車場所への車両の推定到着時刻（ＥＴＡ）を最小限にするという目的で実行される。しかし、発明者は、ＥＴＡが運転手及びユーザの双方にとって重要ないくつかの要因のうちの１つであるにすぎないと理解した。本発明のマッチング処理は、そのような付加的基準に関して運転手のニーズとユーザのニーズとのよりよいバランスを実現できる。例えばユーザは、好みの運転手又はブラックリストに載った運転手を承知しているかもしれず、あるいは車両及び／運転手の特性に関して肯定的なプリファレンス又は否定的なプリファレンスを有しているかもしれない。車両と関連する運転手は、好ましい（又はブラックリストに載っている）ユーザを承知しているかもしれず、好ましい乗車エリア、又は運転したい好適な走行方向（例えば、移動の終わりに自宅に近い場所に着くために）を有しているかもしれないだろう。更に、要求管理システムがプリファレンスを有するかもしれない、すなわちシステムは、特に信頼性の高い運転手を特に利益の大きい走行に割り当てることにより、そのような運転手に報いることを望むかもしれない。

そのようなプリファレンスのバランスをとることを試行するために、車両要求と車両とにより形成可能な各対にマッチ値が割り当てられる。この値は、ＥＴＡと考慮に入れられる付加的基準のうちいずれかに関する異なるスコアとの重み付き組み合わせとして計算される。

ユーザは、他の基準との比較で、例えば運転手が高い安全評価を有するか否かなどのＥＴＡに割り当てられる相対的重みを、車両要求ごとに指定可能であってもよい。同様に、運転手は、特定の日時に運転手が自宅の場所により近い場所に移動可能であるような走行を提供することに高い重みが割り当てられるべきであると指定することが可能であってもよい。

マッチング最適化処理は、２部グラフにおいて最大重みマッチング問題としてモデル化されてもよく、この場合、先に説明したマッチ値は、車両と車両要求とを結ぶ辺に対する重みとして機能する。最適の解、すなわちマッチングされる対ごとに最高の平均マッチ値を有するマッチングは、様々な方法で、例えばハンガリー法としても知られるプライマルデュアルアルゴリズムにより計算できる。

適切な運転手、すなわち所定の車両要求を遂行するための車両のランク付けリストを判定するために、費用関数が使用されてもよい。特定の車両が多数の運転手により使用されてもよい場合、マッチング処理における車両のランクは、所定の時点で運転していることがわかっている運転手又は関連する乗車時刻に運転していると予想される運転手に従属する。各パラメータに関して正のグレード又は負のグレードが生成されてもよく、そのパラメータに対して、グレードは顧客プリファレンスの重みと乗算されてもよい。このようにして、ユーザ個々のユーザプリファレンスは、それらのパラメータに対して車両と関連する運転手のパフォーマンスと相関されてもよい。可能なすべての運転手の出力の重み付け及び比較の結果、ベストマッチの運転手のランク付けが生成される。

車両をクラスタの車両要求とマッチングすることに関連して、クラスタ中の車両要求ごとに最適の運転手が識別された後、車両要求は運転手に提供される。これは、乗車場所の詳細及び車両要求と関連する他の何らかの詳細をデバイスへ、例えば車両と関連するナビゲーションデバイスへ送信することにより実行されてもよい。これは、先に説明した方法で実行されてもよい。

マッチングは、地理的要因のみに基づかないように実行されるのが好ましいので、要求は、その要求に最適であると判明した車両の運転手により受け入れられると思われる。しかし、運転手がオファーを拒絶するか又はオファーに応じないこともありうるので、走行要求ごとに１台の車両を選択するだけでは不十分かもしれないと認識される。

いくつかの実施形態において、最初の最適の運転手が要求を受け入れなかった場合に予備の車両に要求を提供するための更なる処理が実現される。

上記の技術に従ってクラスタの車両要求が車両とマッチングされる場合、クラスタ全体にわたり適切なマッチングを提供するために、各車両要求は多くとも１台の車両に割り当てられるのが好ましい。それらの車両はランク１の車両と呼ばれる（あるいは、それらの車両と関連する運転手がランク１の運転手と考えられてもよい）。

ランク１の車両に加えて、予備の運転手、すなわちランク２、ランク３又はランク４以上の運転手が選択される。ランク２の車両は、クラスタのすべての要求に関連して、すなわち１つの車両要求のみを考慮に入れる最適の車両を選択しようとするのではなく、従来の方式でマッチング処理を実行した場合に要求に対して最高のマッチ値を有すると考えられる車両である。ランク２の車両は走行ごとに判定されてもよい。ランク３の車両は、従来の技術などに基づいて次に最適な車両であると考えられてもよい。車両要求ごとにランク２以上の車両は１台ずつ割り当てられてもよく、又は各要求に複数のランク２以上の車両が割り当てられてもよい。例えば、２台のランク２の車両が割り当てられる場合、それらの車両は、従来の技術などに基づいて最高のマッチ値及び次に高いマッチ値を有する車両であってもよい。

各ランクの車両が１つの要求に独占的に割り当てられ、例えば各ランクの車両が他の要求に対して同一のランクの車両としては利用不可能であり及び／又はより高いランクの車両としての走行に利用不可能であるように、種々の構成が考えられてもよい。

特定の一実現形態は、ランク１の車両を完全に排他的に保持し、すなわち車両は、多くとも１つの要求に対してのみランク１の車両であることが可能であり、ランク１の車両は、どの要求に対してもランク２以上の車両になることはありえない。ランク２以上の車両に対するただ１つの制約は、それらの車両が同一の要求に対して車両（どのランクでも）として扱われてよいのは多くとも一度だけであるということである。

車両のランクは、特定の順序で車両に走行を提供するために使用できる。まず、ランク１の車両に対して要求が提供される（又はランク１の車両が数台ある場合、すべての車両に同時に提供される）。ランク１の車両（又はランク１のすべての車両）が所定の長さの時間内にその要求を受け入れない場合、要求はランク２の車両に提供される（又はランク２の車両が数台ある場合、すべての車両に同時に提供される）。ランク３以上の車両に関しても同様である。

この処理のパラメータ、すなわち、車両が提供される「巡回」の回数及びランクごとの車両の台数は、必要に応じて設定されてもよい。特定の一実現形態は、運転手の競合状態を回避するために、１つの要求が数台の車両に同時に提供されないように、ランクごとに１台のみの車両を選択してもよい。

以上、本発明の種々の態様及び実施形態を説明したが、本発明の範囲が本明細書に記載される特定の構成に限定されず、すべての構成並びにその変形及び変更を含むように拡張されることは理解されるだろう。例えば、以上の説明において説明した実施形態はＧＰＳに関連していたが、尚デバイスは、ＧＰＳの代替技術として又は実際にはＧＰＳに加えて、どのような種類の位置感知技術を利用してもよい。例えばデバイスは、ＥＵガリレオ測位システムなどの他の全地球的航法衛星システムを利用してもよい。同様に、システムは衛星利用システムに限定されず、地上設置ビーコン又はデバイスで地理的場所を判定することを可能にする他の種類のシステムを使用して容易に機能できるだろう。

また、好適な実施形態は、特定の機能性をソフトウェアによって実現してもよいが、その機能はハードウェアのみによって（例えば、１つ以上のＡＳＩＣ（特定用途向け集積回路）によって）、又は実際にはハードウェアとソフトウェアとの組み合わせにより同等に実現可能だろうということは当業者には理解されるだろう。

最後に、尚添付の特許請求の範囲は本明細書において説明される特徴の特定の組み合わせを挙げているが、本発明の範囲は、特許請求の範囲に記載される特定の組み合わせに限定されず、この時点で添付の特許請求の範囲に特定の組み合わせが特定して列挙されているか否かに関わらず、開示される特徴又は実施形態のあらゆる組み合わせを含むように拡張される。

Claims (22)

1. 複数の車両の各々の現在場所を示すデータにアクセス可能なサーバで車両要求を管理する方法であって、
   複数の車両要求をサーバで受信することと、
   複数の車両要求を各々が含む１つ以上のクラスタを生成することと、
   このクラスタ又は各クラスタ中の各車両要求と車両をマッチングすることと
   を備えることを特徴とする方法。
2. 前記サーバは、車両要求を行うために使用される複数の第１のデバイスと通信し且つ送付される車両要求を遂行するために各車両と関連する複数の第２のデバイスと通信する通信手段を備えることを特徴とする請求項１記載の方法。
3. 前記第１のデバイスはそれぞれ関連する場所を有し、前記場所は前記サーバに記憶され、各車両要求は少なくとも第１の場所を含み、前記第１の場所は前記関連する場所に対応することを特徴とする請求項２記載の方法。
4. 前記第１のデバイスは、前記デバイスの現在の地理的位置を判定するように構成された場所判定手段を有する移動デバイスを備え、各車両要求は少なくとも第１の場所を含み、前記第１の場所は、前記第１のデバイスの前記現在の地理的位置に対応することを特徴とする請求項２記載の方法。
5. 前記車両要求は、乗車場所、並びに目的地の場所、乗車時刻、１つ以上の運転手プリファレンス、１つ以上の車両プリファレンス、乗客の人数及び所望の運転手評価のうち１つ以上を示すデータを含むことを特徴とする請求項１から４のいずれか１項に記載の方法。
6. 受信された各車両要求と、前記サーバでの前記要求の受信時刻を示すデータとを関連付けることを更に含むことを特徴とする請求項１から５のいずれか１項に記載の方法
7. 前記１つ以上のクラスタを生成するステップは、各車両要求と関連する乗車場所データを使用して判定された前記複数の車両要求の地理的分布、前記車両の現在位置データを使用して判定された前記複数の車両の地理的分布及び前記複数の車両要求の時間的分布のうち１つ以上を考慮に入れることを特徴とする請求項１から６のいずれか１項に記載の方法。
8. 生成される各クラスタと関連する車両要求は、１つ以上の関連性尺度に基づいて互いに関連すると考えられることを特徴とする請求項１から７のいずれか１項に記載の方法。
9. 各車両要求を所定のクラスタに割り当てることを備え、前記要求をクラスタに割り当てるステップは、前記要求を既存のクラスタに割り当てること又は前記要求を使用して新たなクラスタを生成することを含み、前記要求を使用して新たなクラスタを生成することは、前記車両要求を使用して前記クラスタを開始すること又は複数の既存のクラスタを併合することにより作成されたクラスタに前記車両要求を追加することを含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
10. １つ以上の関連性尺度に基づいて、前記受信された車両要求が既存のクラスタの１つ以上の車両要求とどの程度関連していると考えてよいかを評価することにより、受信された車両要求が既存のクラスタに追加されるのか又は新たなクラスタを生成するために使用されるのかを判定することを更に備えることを特徴とする請求項９記載の方法。
11. 前記１つ以上の関連性尺度に基づいて、受信された車両要求が既存のクラスタの既存の要求のうち１つ以上に関連していると考えてもよい場合、前記受信された車両要求を前記既存のクラスタに追加することと、
    前記１つ以上の関連性尺度に基づいて、受信された車両要求が既存のクラスタの既存の要求のいずれにも関連していないと考えられる場合、前記受信された車両要求を使用して新たなクラスタを生成することと、
    受信された車両要求が前記複数のクラスタの各クラスタの既存の要求のうち１つ以上に関連していると考えてもよい場合、前記受信された車両要求を使用して、前記複数の既存のクラスタを併合することにより新たなクラスタを作成することと
    を含むことを特徴とする請求項１から１０のいずれか１項に記載の方法。
12. 前記１つ以上の関連性尺度は、地理的関係を示す尺度を少なくとも含み、前記尺度は、任意に、車両要求をクラスタに追加するために前記車両要求と関連する乗車場所データにより満たされる距離範囲要件を示すことを特徴とする請求項１０又は１１記載の方法。
13. 車両要求と既存のクラスタの１つ以上の既存の車両要求との関連性を評価するために使用される前記１つ以上の関連性尺度は、前記クラスタと関連する１つ以上の場所に基づく地理的領域内の前記車両要求と関連する場所を使用して判定される前記車両要求の地理的分布、前記クラスタと関連する１つ以上の場所に基づく地理的領域内の車両の現在位置データに基づく前記車両の地理的分布、及び前記クラスタと関連する１つ以上の場所に基づく１つの地理的領域内の車両要求の時間的分布のうち１つ以上に基づいて定義されることを特徴とする請求項１０から１２のいずれか１項に記載の方法。
14. 前記車両をクラスタの各車両要求とマッチングするステップは、時間関連閾値及びクラスタにより含まれる車両要求の数に関連する閾値のうちいずれか一方の閾値を参照することにより前記クラスタが完成したと考えられる場合に限り、車両を前記クラスタ中の各車両要求とマッチングすることを含むことを特徴とする請求項１から１３のいずれか１項に記載の方法。
15. 前記車両をクラスタの各車両要求とマッチングするステップは、１つ以上の基準に基づいて前記クラスタの前記車両要求を遂行するのに適する車両の集合を判定することを含むことを特徴とする請求項１から１４のいずれか１項に記載の方法。
16. 各車両要求と関連する第１の場所、すなわち乗車場所への前記車両の推定到着時刻及び１つ以上の更なる基準に基づいて、判定された前記車両の集合からの車両を前記クラスタの前記車両要求の集合とマッチングすることを含み、前記更なる基準は、運転手基準、車両基準、システム基準、並びに運転手挙動履歴及びユーザ挙動履歴に基づく基準のうち１つ以上を含むことを特徴とする請求項１５記載の方法。
17. 前記サーバは、各車両要求がマッチングされた車両に前記車両要求を提供することを特徴とする請求項１から１６のいずれか１項に記載の方法。
18. 各クラスタの前記車両要求にマッチングされた前記車両の集合は、前記クラスタの前記車両要求を遂行するための一次車両の集合を提供し、各一次車両の車両要求へのマッチングは、前記クラスタの車両要求を互いに参照することにより実行され、任意に、１台の一次車両が各車両要求とマッチングされ、方法は、前記クラスタ中の他の車両要求を考慮せずに１台の車両を前記クラスタの各車両要求とマッチングすることにより、各車両要求に少なくとも１台の二次車両を割り当てることを更に含み、任意に、各車両要求に複数の二次車両が割り当てられることを特徴とする請求項１から１７のいずれか１項に記載の方法。
19. 各車両要求をその要求に関する前記一次車両に提供することと、前記車両要求が所定の時点で受け入れられない場合、前記車両要求をその要求に関する各二次車両に提供することとを含むことを特徴とする請求項１８記載の方法。
20. 複数の車両の各々の現在場所を示すデータにアクセス可能なサーバを備える車両要求管理システムであって、前記サーバは、
    複数の車両要求を受信するように構成された通信手段と、
    複数の車両要求を各々が備える１つ以上のクラスタを生成するように構成された処理手段と、
    １つの車両をこのクラスタ又は各クラスタ中の各々の車両要求とマッチングするように構成された処理手段と
    を備えることを特徴とするシステム。
21. 前記サーバは、各車両要求の受信時刻を示すデータを各車両要求と関連付けるように構成されることを特徴とする請求項２０記載のシステム。
22. 請求項１から１９のいずれか１項に記載の方法を実行するために実行可能なコンピュータ可読命令を備えるコンピュータプログラム。