図面 (/)

この項目の情報は公開日時点(2016年3月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

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

概要

背景

近年、スマートフォンなどの場所認識移動デバイスが一般に広く使用されるようになってきたことに伴い、タクシー手配時及び要求時に経験する問題を改善するために、いくつかのソフトウェアアプリケーション(すなわち「アプリ」)が作られている。その例は、Hailo−http://hailocab.com、myTaxi−http://www.nytaxi.net/及びTaxi Magic−http://taximagic.comなどである。

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

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

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

概要

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

目的

この構成は、異なる基準に関して、例えば以下に説明されるように地理的属性又は他の属性であってもよい特定の属性に関連すると考えられる要求に関して同時にクラスタを生成する機会を提供する

効果

実績

技術文献被引用数
2件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の車両の各々の現在場所を示すデータにアクセス可能サーバ車両要求を管理する方法であって、複数の車両要求をサーバで受信することと、複数の車両要求を各々が含む1つ以上のクラスタを生成することと、このクラスタ又は各クラスタ中の各車両要求と車両をマッチングすることとを備えることを特徴とする方法。

請求項2

前記サーバは、車両要求を行うために使用される複数の第1のデバイス通信し且つ送付される車両要求を遂行するために各車両と関連する複数の第2のデバイスと通信する通信手段を備えることを特徴とする請求項1記載の方法。

請求項3

前記第1のデバイスはそれぞれ関連する場所を有し、前記場所は前記サーバに記憶され、各車両要求は少なくとも第1の場所を含み、前記第1の場所は前記関連する場所に対応することを特徴とする請求項2記載の方法。

請求項4

前記第1のデバイスは、前記デバイスの現在の地理的位置を判定するように構成された場所判定手段を有する移動デバイスを備え、各車両要求は少なくとも第1の場所を含み、前記第1の場所は、前記第1のデバイスの前記現在の地理的位置に対応することを特徴とする請求項2記載の方法。

請求項5

前記車両要求は、乗車場所、並びに目的地の場所、乗車時刻、1つ以上の運転手プリファレンス、1つ以上の車両プリファレンス、乗客の人数及び所望の運転手評価のうち1つ以上を示すデータを含むことを特徴とする請求項1から4のいずれか1項に記載の方法。

請求項6

受信された各車両要求と、前記サーバでの前記要求の受信時刻を示すデータとを関連付けることを更に含むことを特徴とする請求項1から5のいずれか1項に記載の方法

請求項7

前記1つ以上のクラスタを生成するステップは、各車両要求と関連する乗車場所データを使用して判定された前記複数の車両要求の地理的分布、前記車両の現在位置データを使用して判定された前記複数の車両の地理的分布及び前記複数の車両要求の時間的分布のうち1つ以上を考慮に入れることを特徴とする請求項1から6のいずれか1項に記載の方法。

請求項8

生成される各クラスタと関連する車両要求は、1つ以上の関連性尺度に基づいて互いに関連すると考えられることを特徴とする請求項1から7のいずれか1項に記載の方法。

請求項9

各車両要求を所定のクラスタに割り当てることを備え、前記要求をクラスタに割り当てるステップは、前記要求を既存のクラスタに割り当てること又は前記要求を使用して新たなクラスタを生成することを含み、前記要求を使用して新たなクラスタを生成することは、前記車両要求を使用して前記クラスタを開始すること又は複数の既存のクラスタを併合することにより作成されたクラスタに前記車両要求を追加することを含むことを特徴とする請求項1から8のいずれか1項に記載の方法。

請求項10

1つ以上の関連性尺度に基づいて、前記受信された車両要求が既存のクラスタの1つ以上の車両要求とどの程度関連していると考えてよいかを評価することにより、受信された車両要求が既存のクラスタに追加されるのか又は新たなクラスタを生成するために使用されるのかを判定することを更に備えることを特徴とする請求項9記載の方法。

請求項11

前記1つ以上の関連性尺度に基づいて、受信された車両要求が既存のクラスタの既存の要求のうち1つ以上に関連していると考えてもよい場合、前記受信された車両要求を前記既存のクラスタに追加することと、前記1つ以上の関連性尺度に基づいて、受信された車両要求が既存のクラスタの既存の要求のいずれにも関連していないと考えられる場合、前記受信された車両要求を使用して新たなクラスタを生成することと、受信された車両要求が前記複数のクラスタの各クラスタの既存の要求のうち1つ以上に関連していると考えてもよい場合、前記受信された車両要求を使用して、前記複数の既存のクラスタを併合することにより新たなクラスタを作成することとを含むことを特徴とする請求項1から10のいずれか1項に記載の方法。

請求項12

前記1つ以上の関連性尺度は、地理的関係を示す尺度を少なくとも含み、前記尺度は、任意に、車両要求をクラスタに追加するために前記車両要求と関連する乗車場所データにより満たされる距離範囲要件を示すことを特徴とする請求項10又は11記載の方法。

請求項13

車両要求と既存のクラスタの1つ以上の既存の車両要求との関連性を評価するために使用される前記1つ以上の関連性尺度は、前記クラスタと関連する1つ以上の場所に基づく地理的領域内の前記車両要求と関連する場所を使用して判定される前記車両要求の地理的分布、前記クラスタと関連する1つ以上の場所に基づく地理的領域内の車両の現在位置データに基づく前記車両の地理的分布、及び前記クラスタと関連する1つ以上の場所に基づく1つの地理的領域内の車両要求の時間的分布のうち1つ以上に基づいて定義されることを特徴とする請求項10から12のいずれか1項に記載の方法。

請求項14

前記車両をクラスタの各車両要求とマッチングするステップは、時間関連閾値及びクラスタにより含まれる車両要求の数に関連する閾値のうちいずれか一方の閾値を参照することにより前記クラスタが完成したと考えられる場合に限り、車両を前記クラスタ中の各車両要求とマッチングすることを含むことを特徴とする請求項1から13のいずれか1項に記載の方法。

請求項15

前記車両をクラスタの各車両要求とマッチングするステップは、1つ以上の基準に基づいて前記クラスタの前記車両要求を遂行するのに適する車両の集合を判定することを含むことを特徴とする請求項1から14のいずれか1項に記載の方法。

請求項16

各車両要求と関連する第1の場所、すなわち乗車場所への前記車両の推定到着時刻及び1つ以上の更なる基準に基づいて、判定された前記車両の集合からの車両を前記クラスタの前記車両要求の集合とマッチングすることを含み、前記更なる基準は、運転手基準、車両基準、システム基準、並びに運転手挙動履歴及びユーザ挙動履歴に基づく基準のうち1つ以上を含むことを特徴とする請求項15記載の方法。

請求項17

前記サーバは、各車両要求がマッチングされた車両に前記車両要求を提供することを特徴とする請求項1から16のいずれか1項に記載の方法。

請求項18

各クラスタの前記車両要求にマッチングされた前記車両の集合は、前記クラスタの前記車両要求を遂行するための一次車両の集合を提供し、各一次車両の車両要求へのマッチングは、前記クラスタの車両要求を互いに参照することにより実行され、任意に、1台の一次車両が各車両要求とマッチングされ、方法は、前記クラスタ中の他の車両要求を考慮せずに1台の車両を前記クラスタの各車両要求とマッチングすることにより、各車両要求に少なくとも1台の二次車両を割り当てることを更に含み、任意に、各車両要求に複数の二次車両が割り当てられることを特徴とする請求項1から17のいずれか1項に記載の方法。

請求項19

各車両要求をその要求に関する前記一次車両に提供することと、前記車両要求が所定の時点で受け入れられない場合、前記車両要求をその要求に関する各二次車両に提供することとを含むことを特徴とする請求項18記載の方法。

請求項20

複数の車両の各々の現在場所を示すデータにアクセス可能なサーバを備える車両要求管理システムであって、前記サーバは、複数の車両要求を受信するように構成された通信手段と、複数の車両要求を各々が備える1つ以上のクラスタを生成するように構成された処理手段と、1つの車両をこのクラスタ又は各クラスタ中の各々の車両要求とマッチングするように構成された処理手段とを備えることを特徴とするシステム。

請求項21

前記サーバは、各車両要求の受信時刻を示すデータを各車両要求と関連付けるように構成されることを特徴とする請求項20記載のシステム。

請求項22

請求項1から19のいずれか1項に記載の方法を実行するために実行可能なコンピュータ可読命令を備えるコンピュータプログラム

技術分野

0001

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

背景技術

0002

近年、スマートフォンなどの場所認識移動デバイスが一般に広く使用されるようになってきたことに伴い、タクシーの手配時及び要求時に経験する問題を改善するために、いくつかのソフトウェアアプリケーション(すなわち「アプリ」)が作られている。その例は、Hailo−http://hailocab.com、myTaxi−http://www.nytaxi.net/及びTaxi Magic−http://taximagic.comなどである。

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

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

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0091

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

0092

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

0093

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

図面の簡単な説明

0094

以下に、添付の図面を参照して、例示的な例によって、本発明の教示の種々の態様及びそれらの教示を採用する構成を説明する。
図1は、本発明に従って使用されてもよい車両要求管理システムの構造を示す図である。

図2及び図3は、システムにおいて車両要求デバイスとして使用可能な例示的な固定場所デバイスを示す図である。
図4は、システム内で車両と関連するナビゲーションデバイスを提供するように構成された電子構成要素を示す概略図である。
図5は、ナビゲーションデバイスが無線通信チャネルを介して情報を受信する方式を示す概略図である。









図6図15は、システムにおいて使用されるナビゲーションデバイスの表示画面の例を示す図である。
図16は、乗車場所又は降車場所への車両の到着を自動的に判定する方法のステップを示す図である。
図17は、ユーザが携帯する移動デバイスと車両内のナビゲーションデバイスとの関連を形成する方法のステップを示す図である。
図18は、本発明に係る車両を車両要求とマッチングする方法のステップを示す図である。
図19は、車両要求を発生したユーザの待ち時間を最適化するために本発明をどのように使用可能であるかを示す図である。

実施例

0095

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

0096

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

0097

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

0098

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

0099

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

0100

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

0101

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

0102

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

0103

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

0104

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

0105

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

0106

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

0107

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

0108

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

0109

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

0110

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

0111

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

0112

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

0113

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

0114

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

0115

車両要求デバイス12がとることができる別の形は、移動電話、タブレットコンピュータ、ポータブルデジタルアシスタント(PDA)などの移動デバイス22である。

0116

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

0117

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

0118

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

0119

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

0120

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

0121

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

0122

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

0123

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

0124

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

0125

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

0126

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

0127

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

0128

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

0129

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

0130

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

0131

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

0132

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

0133

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

0134

移動デバイス(サービスプロバイダを介する)とサーバ302などの別のデバイスとの間の、例えばインターネット(ワールドワイドウェブなど)を使用するネットワーク接続の確立は、周知のように実行可能である。これは、例えばTCP/IPレイヤープロトコルの使用を含むことができる。移動デバイスは、CDMA、GSM(登録商標)、WANなどの任意の数の通信規格を利用できる。

0135

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

0136

ナビゲーションデバイス200は、例えば既存のBluetooth(登録商標)技術を使用して周知の方法で移動デバイスとのデータ接続、最終的にはインターネット及びサーバ302とのデータ接続を更に完了でき、このデータプロトコルは、例えばGSM規格のデータプロトコル規格であるGRMなどの任意の数の規格を利用できる。

0137

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

0138

GPRS電話設定の場合、移動電話の型式、メーカーなどの絶えず変化する状況に対しても正しく機能できるように、Bluetooth(登録商標)有効化ナビゲーションデバイスが使用されてもよい。型式/メーカー別の特定の設定は、例えばナビゲーションデバイス200に記憶されてもよい。この情報に関して記憶されたデータは更新可能である。

0139

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

0140

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

0141

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

0142

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

0143

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

0144

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

0145

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

0146

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

0147

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

0148

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

0149

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

0150

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

0151

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

0152

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

0153

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

0154

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

0155

運転手が要求を獲得した場合、車両要求の更なる詳細がサーバ10によりナビゲーションデバイス200へ送信される。例えば問題の車両要求の場合、図11に示されるように、要求は、Jonathan Miler Johnsonにより又はその代理の人物により送付されている。要求の詳細は、乗車場所(A)424、この場合はアムステルダム中心のDamrakを少なくとも含む。運転手は、要求の日付425及び乗車場所への推定到着時刻423を見る。乗車場所のETAは、ナビゲーションデバイス200が車両の現在場所から乗車場所までのルートを、好適な実施形態では交通状態履歴、現在の交通状態及び/又は今後の推定交通状態を考慮に入れて計画することにより判定される。図11に示されるように、要求は、ユーザが現在どこにいるかを示すメッセージ、例えば「I‘m standng in front of the yellow phone booth(黄色の電話ボックスの前に立っています)」などのメッセージ及び運転手がユーザと連絡をとれるようにするためのアイコン422を更に含んでもよい。

0156

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

0157

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

0158

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

0159

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

0160

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

0161

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

0162

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

0163

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

0164

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

0165

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

0166

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

0167

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

0168

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

0169

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

0170

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

0171

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

0172

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

0173

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

0174

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

0175

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

0176

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ