(57)【要約】【課題】二重配車の状態を早期に解消可能な配車システムを提供することである。【解決手段】配車システムは、配車サーバと、複数の車両のおのおのに搭載された車載端末と通信可能な基地局と、を具備する。前記配車サーバは、配車要求に、少なくとも伝票番号と、配車要求毎に連番で付与する代車番号と、を含めて前記車載端末へ送信する。前記車載端末は、前記配車要求を受信すると、動態情報に前記伝票番号と、前記代車番号と、を含めて前記配車サーバへ送信する。前記配車サーバは、前記動態情報から各車載端末の伝票番号を取得し、同じ伝票番号がある場合は二重配車と判定し、二重配車と判定した車載端末の内、前記代車番号が最も大きい車載端末以外の車載端末へ配車キャンセル信号を送付する。【選択図】図６
2019061307.tif 000002
【特許請求の範囲】
【請求項１】
配車サーバと、複数の車両のおのおのに搭載された車載端末と通信可能な基地局と、を具備し、
前記配車サーバは、配車要求に、少なくとも伝票番号と、配車要求毎に連番で付与する代車番号と、を含めて前記車載端末へ送信し、
前記車載端末は、前記配車要求を受信すると、動態情報に前記伝票番号と、前記代車番号と、を含めて前記配車サーバへ送信するものであり、
前記配車サーバは、前記動態情報から各車載端末の伝票番号を取得し、同じ伝票番号がある場合は二重配車と判定し、二重配車と判定した車載端末の内、前記代車番号が最も大きい車載端末以外の車載端末へ配車キャンセル信号を送付する、配車システム。
【請求項２】
請求項１の配車システムにおいて、
前記配車サーバは、前記配車要求に、配車した車両毎に連番で付与する配車連番を含めて前記車載端末へ送信し、
前記車載端末は、前記動態情報に、前記配車連番も含めて前記配車サーバへ送信するものであり、
前記配車サーバは、同じ伝票番号と配車連番がある場合は二重配車と判定する、配車システム。
【請求項３】
配車サーバと、複数の車両のおのおのに搭載された車載端末と通信可能な基地局と、を具備し、
前記配車サーバは、少なくとも伝票番号、配車要求を送信した車載端末、配車が成功したか失敗したかを示す配車ステータスが紐づいたリストを作成し、当該リストの車載端末の内、配車が失敗したことを示す配車ステータスと紐づいた車載端末へ配車キャンセル信号を送付する、配車システム。
【請求項４】
配車サーバと、複数の車両のおのおのに搭載された車載端末と通信可能な基地局と、を具備する配車システムにおいて、多重配車を解消する配車方法であって、
前記配車サーバから前記車載端末へ送信する配車要求に、少なくとも伝票番号と、配車要求毎に連番で付与する代車番号と、が含まれており、
前記車載端末から前記配車サーバへ送信する動態情報に、前記伝票番号と、前記代車番号と、が含まれており、
前記動態情報の内、同じ伝票番号がある場合は二重配車と判定し、二重配車と判定した車載端末の内、前記代車番号が最も大きい車載端末以外の車載端末へ配車キャンセル信号を送付する、配車方法。
【請求項５】
請求項４の配車方法において、
前記配車要求に、配車した車両毎に連番で付与する配車連番が含まれており、
前記動態情報に、前記配車連番が含まれており、
前記動態情報の内、同じ伝票番号と配車連番がある場合は二重配車と判定する、配車方法。
【請求項６】
配車サーバと、複数の車両のおのおのに搭載された車載端末と通信可能な基地局と、を具備する配車システムにおいて、多重配車を解消する配車方法であって、
少なくとも伝票番号、配車要求を送信した車載端末、配車が成功したか失敗したかを示す配車ステータスが紐づいたリストを作成し、
当該リストの車載端末の内、配車が失敗したことを示す配車ステータスと紐づいた車載端末へ配車キャンセル信号を送付する、配車方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は配車システムに関し、特に、タクシー等の配車システムに適用可能である。
【背景技術】
【０００２】
近年、無線移動通信システムの発展と共に、手軽に広域エリアを対象とした移動体データ通信を行うことが可能となっている。また、電波を利用した測位技術の発展に伴い、人工衛星を利用したＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）測位システムにより位置情報を得ることができるようになった。これら無線移動通信システムと測位システムの融合により、移動体のデータ伝送システムや位置管理システムが実用化され、業務用無線や公衆無線を通じてタクシーや運送車両の配車効率向上を目的に利用されている。
【０００３】
業務用無線によるタクシー配車用ＡＶＭ（Ａｕｔｏｍａｔｉｃ  Ｖｅｈｉｃｌｅ  Ｍｏｎｉｔｏｒｉｎｇ）システムは、ＧＰＳ衛星と、移動局（タクシー）と、移動局と無線通信を行う基地局と、基地局と専用線で接続された管理センタとから構成されている。このようなタクシー配車用ＡＶＭシステムでは、顧客が配車センタに連絡して自分の現在位置と必要な車両情報を伝え、配車を要望する。配車センタでは、オペレータが配車端末を操作して、管理センタに対して顧客情報と必要な車両情報を送信する。管理センタでは、顧客の現在位置情報に従い、最適な車両を配車するために、収集されている移動局の位置情報から最適な車両を検索して、検索された車両の中からオペレータが選択した車両を配車する運用を行う。
【０００４】
このようなタクシー配車用ＡＶＭシステムを用い、効率的に配車を行うことのできるタクシー配車システムが提案されている（特許第５３０２８３２号公報参照）。
【０００５】
図３は、上記タクシー配車システムにおける配車の流れを説明するシーケンス図である。図４は、移動局（車載端末）から管理センタ内の配車サーバ（ＡＶＭサーバ）まで信号が届かなかったために配車が失敗した場合を説明するシーケンス図である。図３及び図４では、配車端末と、ＡＶＭサーバと、ＧＷサーバと、車載端末との間の送信および受信のタイミングを示すシーケンス図を示している。
【０００６】
（配車成功シーケンス）
まず、最初に、配車端末は、管理センタのＡＶＭサーバへ配車要求を行う（Ｓ１）。ＡＶＭサーバは、最適な車両を検索し、車両の車載端末に対する配車要求を行う（Ｓ２）。ＧＷサーバは、ＡＶＭサーバからの配信要求に基づいて、車載端末へ配車指示を通知する（Ｓ３）。
【０００７】
配車指示を受けた車載端末は、ＧＷサーバを経由してＡＶＭサーバへ配車情報取得要求を送信する（Ｓ４、Ｓ５）。ＡＶＭサーバは、配車情報取得要求に基づいて、配車情報をＧＷサーバを経由して車載端末へ送信する（Ｓ６、Ｓ７）。
【０００８】
車載端末は、配車情報を受信すると、乗務員へ配車要請が来たことを通知する。乗務員は顧客の位置へ行ける場合、「了解」ボタンを押下する。乗務員が「了解」ボタンを押下すると、車載端末は、配車了解信号を、ＧＷサーバ経由してＡＶＭサーバへ送信する（Ｓ８、Ｓ９）。ＡＶＭサーバは、配車了解信号を受信すると、了解承認信号（了解ＡＣＫ）をＧＷサーバ経由して車載端末へ送信し、配車が完了する（Ｓ１０、Ｓ１１）。
【０００９】
（配車失敗シーケンス）
図４の配車失敗となるケースについて説明する。Ｓ１−Ｓ７までは、図３と同一であり、その説明は省略する。車載端末は、配車情報を受信すると、所定の了解操作を行い、配車了解信号を、ＧＷサーバを経由してＡＶＭサーバへ送信する（Ｓ８）。しかし、移動局が無線不感エリア内（例えば、無線基地局の通信エリア外）に移動すると、ＡＶＭサーバが車載端末からの配車了解情報を受信できなくなる。そのため、ＡＶＭサーバは、了解信号（Ｓ８）を受信できないため、配車情報が車載端末に届いたか判断がつかないため、「配車失敗」と判断する。一方、車載端末は、ＡＶＭサーバからの了解承認信号（了解ＡＣＫ）を受信できないので、ＡＶＭサーバが了解信号を受け取ったか判断がつかないが、顧客の位置へ向かう車両がいなくなることを避けるために「配車完了」と判断する。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特許第５３０２８３２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
タクシー配車用ＡＶＭシステムでは、上記のように管理センタが移動局からの配車了解信号を受信できなかった場合、管理センタは、他の移動局（タクシー）に配車指示を行うようにしていた。そのため、同一顧客の場所へ複数台の移動局（タクシー）が向かってしまうという二重配車ないし多重配車の問題があった。
【００１２】
本開示の課題は、二重配車の状態を早期に解消可能な配車システムを提供することである。
【００１３】
その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１４】
本開示のうち代表的なものの概要を簡単に説明すれば下記の通りである。
【００１５】
すなわち、配車システムは、配車サーバと、複数の車両のおのおのに搭載された車載端末と通信可能な基地局と、を具備する。前記配車サーバは、配車要求に、少なくとも伝票番号と、配車要求毎に連番で付与する代車番号と、を含めて前記車載端末へ送信する。前記車載端末は、前記配車要求を受信すると、動態情報に前記伝票番号と、前記代車番号と、を含めて前記配車サーバへ送信する。前記配車サーバは、前記動態情報から各車載端末の伝票番号を取得し、同じ伝票番号がある場合は二重配車と判定し、二重配車と判定した車載端末の内、前記代車番号が最も大きい車載端末以外の車載端末へ配車キャンセル信号を送付する。
【発明の効果】
【００１６】
上記配車システムによれば、二重配車の状態を早期に解消可能である。
【図面の簡単な説明】
【００１７】
【図１】実施例１に係る配車システムの概略構成を示す図である。
【図２】実施例１に係る管理センタの概略構成を示す図である。
【図３】配車完了を説明するシーケンス図である。
【図４】配車失敗を説明するシーケンス図である。
【図５】実施例１に係る配車シーケンス図である。
【図６】実施例２に係る配車シーケンス図である。
【図７】変形例２に係る配車キャンセル処理フロー図である。
【発明を実施するための形態】
【００１８】
以下、実施例について、図面を用いて説明する。ただし、以下の説明において、同一構成要素には同一符号を付し繰り返しの説明を省略することがある。なお、図面は説明をより明確にするため、実際の態様に比べ、模式的に表される場合があるが、あくまで一例であって、本発明の解釈を限定するものではない。
【実施例１】
【００１９】
本発明の実施例１に係る配車システムの構成図例について、図面を参照して説明する。図１は、実施例１に係る配車システムの概略構成図を示す。
【００２０】
（配車システムの構成）
配車システム１は、無線移動通信システムと測位システムを利用したタクシー配車用ＡＶＭ（Ａｕｔｏｍａｔｉｃ  Ｖｅｈｉｃｌｅ  Ｍｏｎｉｔｏｒｉｎｇ）システムである。配車システム１は、管理センタ１０１と、複数の無線基地局１０２（１０２−１，１０２−２，・・・，１０２−Ｌ）と、複数の移動局（タクシー等の車両）１０４（１０４−１，１０４−２，・・・、１０４−Ｎ）と、ＧＰＳ衛星１０５と、複数の配車端末１０６（１０６−１，１０６−２，・・・，１０６−Ｍ）を有する配車センタ１０７と、を用いて構成されている。
【００２１】
各無線基地局１０２は、自局が通信できる通信エリアを有しており、例えば、無線基地局１０２−１の通信エリア１０３−１は、そのエリア内に存する移動局１０４と無線基地局１０２−１とが通信できることを示している。
【００２２】
各移動局１０４は、ＧＰＳ衛星１０５からの位置情報を受けて、自車両の位置情報（緯度、経度）を入手することができる。移動局１０４により入手された位置情報は、移動局１０４（車両）の動態情報と共に、その車両が存する通信エリア１０３を有する無線基地局１０２を通じて定期的に管理センタ１０１へ送られる。
【００２３】
管理センタ１０１は、複数ある各無線基地局１０２を通じて、その通信エリア１０３内に存する移動局１０４の位置情報と動態情報を収集し、各移動局１０４の管理を行っている。
【００２４】
顧客は、配車センタ１０７に連絡して、配車先の位置（例えば、顧客の現在位置）や所望する車両の情報を伝えることで、配車要求を行う。
【００２５】
配車センタ１０７では、オペレータが配車端末１０６を操作して、管理センタ１０１に対して配車要求（配車先の位置や所望する車両の情報）を送信する。
【００２６】
管理センタ１０１は、配車センタ１０７から受信した配車要求に従い、収集された各移動局１０４の位置情報から配車に適した車両を検索（探車）して、配車先に指示された位置まで車両を配車する運用を行う。
【００２７】
なお、顧客は、タクシー会社のホームページや、一般に市販されている種々の携帯端末（携帯電話端末やタブレット端末）にインストールした配車要求用のアプリケーションを用い、インターネット回線を通じて管理センタ１０１にアクセスすることで、配車センタ１０７を介さずに管理センタ１０１に対して配車要求を行うこともできる。
【００２８】
次に、各車両に配備される移動局１０４について説明する。移動局１０４は、自車両が存する通信エリア１０３を有する無線基地局１０２との無線通信を通じて、管理センタ１０１との間で各種情報の授受を行うことができる。
【００２９】
また、移動局１０４は、定期的に、ＧＰＳ衛星１０５から受信した情報に基づいて自車両の位置情報（緯度、経度）を入手し、該移動局１０４が配備された車両の動態を示す情報および該車両の識別情報と共に管理センタ１０１へ通知する。
【００３０】
車両の動態としては、「実車」、「空車」、「空車予定」、「支払」、「休憩」などがあり、各車両に配備された移動局１０４を乗務員が操作することで設定される。配車候補として検索される車両は基本的に「空車」の車両であるが、実質的に配車が可能な他の動態（「空車予定」、「支払」、「休憩」）の車両についても配車候補の車両として検索するようにしてもよく、どの動態を配車候補の車両として検索するかは、タクシー会社の方針等に従って予め設定しておけばよい。
【００３１】
また、移動局１０４は、自車両が待機場所での待機を開始する際に、乗務員により移動局１０４が操作されたことに応じて、待機場所での待機を開始することを示す情報と該待機場所を特定する情報とを該車両の識別情報と共に管理センタ１０１へ送信する。
【００３２】
また、移動局１０４は、自車両が待機場所での待機を終了する際に、乗務員により移動局１０４が操作されたことに応じて、待機場所での待機を終了することを示す情報と該待機場所を特定する情報とを該車両の識別情報と共に管理センタ１０１へ送信する。
【００３３】
ここで、移動局１０４としては、専用の無線通信端末を用いてもよいが、一般に市販されている携帯電話端末（例えば、スマートフォン）や無線通信機能を持つタブレット端末といった種々の携帯端末に、上記の各機能を実現する配車システム用のアプリケーションをインストールしたものを用いてもよい。
【００３４】
（管理センタの構成）
次に、管理センタ１０１の構成について、図２に示す構成例を参照して説明する。
【００３５】
管理センタ１０１は、データベースサーバ２００と、地図サーバ２２０と、配車サーバ（ＡＶＭサーバ）２４０と、ゲートウェイサーバ２５０と、を備えている。
【００３６】
データベースサーバ２００は、配車システムの運用に係る各種のデータを管理するサーバであり、本例では、個々の配車エリアに関するエリア情報を記憶・管理するエリア情報管理部２０１と、個々の車両に関する車両情報を記憶・管理する車両情報管理部２０２と、を有している。
【００３７】
エリア情報管理部２０１で管理する各配車エリアのエリア情報には、配車エリアの識別情報、該配車エリアの範囲を示す情報、該配車エリアへ配車する車両の検索で適用する優先順序を示す情報、該配車エリアで車両を検索する範囲の優先順序を示す情報、該エリア情報を適用する時間帯（以下、適用時間帯）を示す情報、などが格納される。
【００３８】
車両情報管理部２０２で管理する各車両の車両情報には、車両の識別情報、該車両の現在の位置情報、該車両が待機場所で待機中の場合の該待機場所を示す情報および待機順を示す情報、該車両の動態を示す情報、該車両に関する前付け条件を示す情報、該車両の乗務員／車両のシフトを示す情報、などが格納される。
【００３９】
地図サーバ２２０は、タクシー会社の営業エリアを含む地図情報を管理するサーバであり、本例では、出発地点と到着地点の入力に応じて、これら地点間を結ぶ経路の探索や距離指標（直線距離、経路距離、想定移動時間）の算出を行う経路探索部２２１を有している。
【００４０】
配車サーバ２４０は、配車する車両の検索をデータベースサーバ２００や地図サーバ２２０を利用して行うサーバであり、本例では、顧客からの配車要求に応じて、配車に適した車両を検索（探車）する候補車検索部２４１と、候補車検索部２４１により検索された車両（移動局１０４）に対して配車指示を行う配車指示部２４２と、を有している。
【００４１】
候補車検索部２４１は、顧客からの配車要求を受けると、該配車要求を検索条件に用いてエリア情報管理部２０１および車両情報管理部２０２にアクセスして、該配車要求で指定された配車先の位置を範囲に含む配車エリアのエリア情報であり、且つ、現在の時間（検索の時点）を含む適用時間帯のエリア情報を特定する。候補車検索部２４１は、また、該エリア情報に設定された優先順序および除外エリアに従って、優先順序が最も高い空車車両または待機車両であって除外エリアに存していない車両を検索し、該車両を配車対象の車両（指定された配車先への配車に最も適した車両）に決定する。ここで、配車要求で複数台の配車を指定された場合には、指定された台数の車両を検索して、配車対象の車両に決定する。
【００４２】
なお、配車先の位置と各車両の位置とについての距離指標が必要な場合には、これらの位置情報を地図サーバ２２０に提供して経路探索部２２１により演算させ、その結果を取得して、車両の検索に用いる。
【００４３】
また、配車要求において、車両の特性（車種、車体の色など）や乗務員の特性（性別、年齢など）といった前付け条件についての要望があった場合には、該要望を満たす車両を優先して、車両の検索を行う。
【００４４】
配車指示部２４２は、候補車検索部２４１により検索された車両に配備された移動局１０４に対し、配車要求で指定された配車先の位置を通知して、その位置へ車両を配車させる旨の配車指示を行う。
【００４５】
ゲートウェイサーバ（ＧＷサーバ）２５０は、配車指示部２４２からの配車指示を、車両の移動局１０４が存する通信エリア１０３の無線基地局１０２を経由して、車両の移動局１０４へ送信する。
【００４６】
（配車シーケンス１）
図５は、実施例に係る配車シーケンス図である。図５では、図４で説明された様に、ＡＶＭサーバ２４０が車載端末１０４−１に対して「配車失敗」と判断した後、例えば、車載端末１０４−２に、配信要求を行う場合の配車シーケンスを示している。なお、ステップＳ１−Ｓ８までの説明は、図４と同じであるため、その説明は省略される。
【００４７】
なお、顧客から注文を受け配車端末１０６からＡＶＭサーバ２４０へ配車要求を出す（Ｓ１）が、その後、ＡＶＭサーバ２４０は受付情報を作成し、データベースサーバ２００へ格納し、受付情報に、ＡＶＭシステムで一意となる伝票番号を付与する。ＡＶＭサーバ２４０は、配車情報を作成し配車状態を管理する。配車情報には、伝票番号、注文台数（配車連番）、配車台数（代車番号）、状況（配車ステータス）、配車リスト（車両番号）などが含まれるものとする。
【００４８】
ステップＳ８の後、ＡＶＭサーバ２４０は、車載端末１０４−１からの了解信号の未受信の状態が所定の時間経過した後、車載端末１０４−１からの了解信号の受信をタイムアウト（了解信号タイムアウト）と判断し、次の候補である車載端末１０４−２に対して配車要求を行う（Ｓ２２）。すなわち、管理センタ１０１では顧客の現在位置情報に従い、最適な車両を再検索するために、収集されている移動局１０４（１０４−２、１０４−３、・・、１０４−Ｎ）の位置情報から、最適な車両を再検索して、顧客の現在位置まで、再検索された最適車両を配車する運用を行う。たとえば、移動局（車載端末）１０４−２の車両が、最適な車両として新たに選択されたものとする。なお、車両を検索する際は、注文台数以上の車両を検索するようにしてもよい。検索された複数の車両の中から、優先順位に基づいて選択する又はオペレータの判断により選択されるように構成することもできる。これにより、次の候補の車両も優先順位に基づいて選択する又はオペレータの判断により選択されることができるため、再検索の時間を省くことができる。
【００４９】
ＡＶＭサーバ２４０は、車載端末１０４−２に対する配車要求を行う（Ｓ２２）。ＧＷサーバ２５０は、ＡＶＭサーバ２４０からの配信要求に基づいて、車載端末１０４−２が存する通信エリア１０３の無線基地局１０２を経由して、車両の車載端末１０４−２へ、配車指示を通知する（Ｓ３）。配車指示を受けた車載端末１０４−２は、ＧＷサーバ２５０を経由してＡＶＭサーバ２４０へ配車情報取得要求を送信する（Ｓ２４、Ｓ２５）。ＡＶＭサーバ２４０は、配車情報取得要求に基づいて、配車情報を、ＧＷサーバ２５０及び無線基地局１０２を経由して、車載端末１０４−２へ送信する（Ｓ２６、Ｓ２７）。
【００５０】
車載端末１０４−２は、配車情報を受信すると、乗務員へ配車要請が来たことを通知する。乗務員は行ける場合、「了解」を押下する。(行けない場合は「不可」を押下)。乗務員は行ける場合、「了解」を押下すると、配車了解信号を、ＧＷサーバ２５０経由してＡＶＭサーバ２４０へ送信する（Ｓ２８、Ｓ２９）。ＡＶＭサーバ２４０は、配車了解信号を受信すると、状況（配車ステータス）を配車完了にし、了解承認信号（了解ＡＣＫ（ＯＫ））をＧＷサーバ２５０経由して車載端末１０４−２へ送信し、車載端末１０４−２への配車が完了する（Ｓ３０、Ｓ３１）。これによって、車載端末１０４−２への配車が成立する。
【００５１】
次に、例えば、車載端末１０４−１が無線基地局１０２の通信エリア１０３内に移動し、車載端末１０４−１と無線基地局１０２との通信が回復したとする。この場合、車載端末１０４−１は、ＡＶＭサーバ２４０からの了解承認信号（了解ＡＣＫ（ＯＫ））がタイムアウト（（了解ＡＣＫタイムアウト）と判断し、配車了解信号を、ＧＷサーバ２５０経由してＡＶＭサーバ２４０へ再送信する（Ｓ４０、Ｓ４１）。ＡＶＭサーバ２４０は、二重配車を判定する判定処理を実施する。この場合、車載端末１０４−２への配車が完了している為、二重配車であると判定し、車載端末１０４−１に対して、ＧＷサーバ２５０を経由して、了解承認信号（了解ＡＣＫ（ＮＧ））を送信する。すなわち、ＡＶＭサーバ２４０は、了解承認信号（了解ＡＣＫ（ＮＧ））を送信することで、車載端末１０４−１に対して、配車キャンセル処理を実行する。車載端末１０４−１は、了解承認信号（了解ＡＣＫ（ＮＧ））の受信により、配車不成立と判断し、乗務員へ配車キャンセルの旨を通知する。
【００５２】
以上の説明の様に、管理センタ１０１は、車載端末１０４に対して、第1の了解承認信号「了解ＡＣＫ（ＯＫ）」と、第２の了解承認信号「了解ＡＣＫ（ＮＧ）」とを送付する機能を有する。第1の了解承認信号「了解ＡＣＫ（ＯＫ）」は、配車指示した車載端末（１０４−２）に配車成立を通知する信号である。第２の了解承認信号「了解ＡＣＫ（ＮＧ）」は、一端指示した車載端末（１０４−１）に対して、配車キャンセルを通知する信号である。
【００５３】
これにより、車載端末１０４（１０４−１）から、二重配車になっていないかを、管理センタ１０１のＡＶＭサーバ２４０へ確認することにより、管理センタ１０１と車載端末１０４（１０４−１）の状態の不整合が発生する確率を下げることが出来る。また、二重配車ないし多重配車の状態が早期に解消可能である。
【実施例２】
【００５４】
（配車シーケンス２）
図６は、実施例２に係る配車シーケンス図である。図６において、図５と異なる部分は、ステップＳ４０，Ｓ４１）が削除されて、その代わりとして、ステップＳ５０−ステップＳ５３が追加されている点である。実施例１に記載の様に、車載端末１０４（１０４−１）から、二重配車になっていないかを、管理センタ１０１のＡＶＭサーバ２４０へ確認するだけでは、通信障害で、何回「了解信号」を再送しても、ＡＶＭサーバ２４０へ届かない場合も考えられ、二重配車の可能性は残ってしまう。そこで、本実施例２の様に、管理センタ１０１側で二重配車を監視し、二重配車が発生した場合に、管理センタ１０１側から車載端末１０４へ配車キャンセルする仕組みを追加することが好適である。
【００５５】
図６に示される配車シーケンスは、配車が完了した後、顧客の注文台数以上の配車台数（配車指示）があった場合、配車キャンセル処理が完了していない車両を特定するものである。これにより、配車キャンセル処理を確実に行うことが可能になる。この配車シーケンスは、顧客から注文を受けて配車が完了した（ステップＳ３１）後に、管理センタ１０１のＡＶＭサーバ２４０により自動的に実行させるのが良い。
【００５６】
図６の場合、ＡＶＭサーバ２４０の管理する配車情報（伝票データ）に、代車番号が付加され、配車要求を車両の車載端末（１０４）へ送信する毎に伝票データを作成するようにし、車載端末がＡＶＭサーバ２４０へ送信する動態情報に、車載端末が受領したと認識している伝票番号と、配車連番と、代車番号を含めて送信する。伝票番号、配車連番および代車番号を配車キー情報という事とする。
【００５７】
ここで、伝票番号は、顧客の注文毎に付与される管理番号である。
【００５８】
配車連番は、顧客の注文に対して配車した車両毎に付与される番号である。注文台数が２台であれば、配車連番１，２のデータが生成される。
【００５９】
代車番号は、送信した配車要求毎に付与される番号である。最後に配車した車両に最も大きい番号が付与される。
【００６０】
動態情報は、「実車」「空車」「休憩」等、タクシーの状態を示す。基本的に、ＡＶＭサーバ２４０が配車する車両は、「空車」となっている車両を候補にする（もうすぐ「空車」になる予定の「実車」も候補にすることもある）。
【００６１】
車載端末１０４（１０４−１，１０４−２）は、一定時間経過、一定距離走行、あるいは、動態情報が変更されたタイミングで、ＡＶＭサーバ２４０へ動態情報を送信している（Ｓ５０−Ｓ５３）。車載端末１０４−１の動態情報は、ステップＳ５０，Ｓ５１によりＡＶＭサーバ２４０送信され、車載端末１０４−２の動態情報は、ステップＳ５２，Ｓ５３によりＡＶＭサーバ２４０送信されたものとする。
【００６２】
二重配車が発生すると、同じ伝票番号と配車連番の動態情報が複数の車両の車載端末（１４０）から送信されてくることになる（Ｓ５０−Ｓ５３）。したがって、管理センタ１０１のＡＶＭサーバ２４０にて、定期的(例えば１分毎)に動態情報を監視し、同じ伝票番号と配車連番の動態データが複数の車両で存在しているか否を判定する。すなわち、ＡＶＭサーバ２４０は、動態情報の受信に基づいて、二重配車を判定する判定処理を実施する。判定処理の実施の結果、同じ伝票番号と配車連番の動態データが複数の車両で存在していた場合、代車番号が一番大きなものを残して、配車キャンセル指示を車載端末（１０４−１）へ送信する（Ｓ４２、Ｓ４３）ことで、配車キャンセル処理を実施する。なお、注文台数が１台に限る場合や同じ顧客からの注文でも１台毎に異なる伝票番号を割当てる場合、配車連番を付与せずに二重配車を判定することができる。すなわち、同じ伝票番号の動態情報がある場合に二重配車が発生したと判定し、代車番号が一番大きい車載端末以外の車載端末へ配車キャンセル指示を送信する。
【００６３】
上記構成により、仮に、車載端末１０４−１が配車されていると認識している場合、上記動態情報に、伝票番号、配車連番、代車番号を含めて送信してくるため、ＡＶＭサーバ２４０でも認識可能となる。
【００６４】
実施例２によれば、車載端末１０４は動態情報を定期的に送付する構成であるため、通信環境が改善された時点で、管理センタ１０１のＡＶＭサーバ２４０へ車載端末１０４の状態を送信することが出来る。この動態情報を使うことで、配車シーケンス終了後にも、ＡＶＭサーバ２４０で二重配車ないし多重配車を監視し、二重配車を判定する判定処理を実施することが出来る。ＡＶＭサーバ２４０から、車載端末１０４へ自動で配車キャンセル処理を実施することで、オペレータの手間を省くことが可能である。代車番号で管理することで、単純な判断フローで、配車キャンセルする車両を決めることが可能である。
【００６５】
なお、図５の配車シーケンスと図６の配車シーケンスとを組み合わせることも可能である。
【００６６】
（変形例１）
図７は、変形例１に係る配車キャンセル処理フロー図である。
【００６７】
この場合、ＡＶＭサーバ２４０は、伝票番号と、配車要求を送信した車両と、状況(了解、失敗、タイムアウト等)とを紐づけたリスト（配車情報）を、作成および保持する。状況が「了解」以外の車両に対して配車キャンセル信号を送信する。
【００６８】
まず、顧客から注文を受け、配車端末１０６からＡＶＭサーバ２４０へ配車要求が出される。ＡＶＭサーバ２４０は受付情報を作成し、データベースサーバ２００へ格納し、ＡＶＭシステムで一意となる伝票番号を付与する。ＡＶＭサーバ２４０は、配車情報を作成し配車状態を管理する。配車情報には、伝票番号、注文台数（配車連番）、配車台数（代車番号）、状況（配車ステータス）、配車リスト（車両番号）などが含まれるものとする。
【００６９】
このフローは、例えば、顧客から注文を受けて配車が完了（ステップＳ３１）した後、管理センタ１０１のＡＶＭサーバ２４０により自動的に実行させるのが良い。あるいは、図６のステップＳ５０−ステップＳ５３の受信後に、管理センタ１０１のＡＶＭサーバ２４０により自動的に実行されても良い。ステップＳ３１またはステップＳ５３の後、このフローがスタート（ステップＳ６０）する。
【００７０】
まず、データベースサーバ２００がアクセスされ、配車が完了した配車情報から、伝票番号が取得され、その伝票番号に対する、注文台数、配車台数、配車ステータス、配車リスト（車両番号）を取得する。そして、配車ステータスが了解以外となっている車両の台数を配車台数として、注文台数と配車台数とが一致しているか否かを、判定する（ステップＳ６１）。ステップＳ６１は、二重配車を判定する判定処理と見做すことが出来る。判定の結果、注文台数と配車台数とが一致している場合、正常と判断し、このフローは終了する。なお、ここで、正常とは、二重配車ないし多重配車の状況が発生していないという意味である。
【００７１】
判定の結果、注文台数と配車台数とが不一致の場合、ステップＳ６２へ移行する。
【００７２】
ステップＳ６２では、配車台数から注文台数を引いた値（配車台数−注文台数）が０（ゼロ）か否かが判定される。すなわち、配車キャンセルが未処理の車両の台数が判定される。
【００７３】
（配車台数−注文台数）が０の場合、配車キャンセル処理が完了し、二重配車ないし多重配車の状態が解消されたと判断し、このフローは終了する。
【００７４】
（配車台数−注文台数）が０でない場合（≠０）、配車キャンセル処理が未完了であり、二重配車ないし多重配車の状態であると認識し、ステップＳ６３へ移行する。
【００７５】
ステップＳ６３では、配車リスト内の車両番号（Ｎｏ．ｘｘ）に対する状況が、了解か、了解以外（失敗、タイムアウト）かを判定する。了解の場合、ステップＳ６２へ移行する。了解以外（失敗、タイムアウト等）の場合、ＡＶＭサーバ２４０は、車両番号（Ｎｏ．ｘｘ）に、了解承認信号「了解ＡＣＫ（ＮＧ）」を送付して、配車キャンセル処理を実行する（図７のＳ４２、Ｓ４３参照）。また、車両番号（Ｎｏ．ｘｘ）の状況を、例えば、「了解ＡＣＫ（ＮＧ）」として、配車キャンセル処理が完了した状態へ変更すると共に、動態情報を、例えば「空車」とする。
【００７６】
この後、ステップＳ６２に移行し、（配車台数−注文台数）が０となるまで、ステップＳ６３、Ｓ６４が実行される。
【００７７】
以上のフローを、管理センタ１０１のＡＶＭサーバ２４０により、自動的に実行させることで、配車キャンセル処理が完了していない車両を判定および特定し、配車キャンセル信号「了解ＡＣＫ（ＮＧ）」を送信する。これにより、オペレータの手間を省きつつ、配車キャンセル処理を確実に行うことが可能になるので、二重配車または多重配車の状態を早期に解消することが可能である。
【００７８】
なお、図５の配車シーケンスと図７の配車キャンセル処理フローとを組み合わせることも可能である。
【００７９】
（変形例２）
管理センタ１０１で二重配車ないし多重配車を監視し、オペレータへ通知し、手動で、配車キャンセルすることも可能である。
【００８０】
二重配車ないし多重配車の監視は、上記実施例２と同じ仕組みとすることが可能である。検出した結果は、配車端末１０６へ通知する。通知の方法は、データベースサーバ２００へ検出結果を書き込んでおき、配車端末１０６へその伝票の数を送信する。オペレータ側では、二重配車の伝票が発生した場合、配車端末１０６で伝票を開く処理（二重配車を判定する判定処理）を行う。複数のオペレータが伝票を開かないようデータベースサーバ２００側で排他処理を行い、早い者勝ちで伝票を割り当てていく。
【００８１】
伝票を開き、配車完了している車両と、配車失敗だが、動態データで当該伝票の伝票番号のキーデータを送信している車両を地図上に表示する。そのうち、二重配車になっているものについてはアイコンを赤色にするなどして判別できるようにする。また、各車両から、迎え先までの経路探索を行い、迎え先までの距離と到着予想時間を表示する。
【００８２】
オペレータは、到着予想時間や地図上の位置から一番早く到着しそうな車両を残し、他の車両には、配車キャンセル処理を実施し、配車キャンセルの指示を出す（「了解ＡＣＫ（ＮＧ）」信号の送信）。配車キャンセルした車両に関しては、配車データに配車キャンセル完了を記録しておき、配車キャンセル処理を実行したことを明示的に残しておく。また、配車失敗した車両を残す場合は、配車データの配車状態を配車失敗から、配車完了に変更する。そうすることで、最終的に配車した車両がどれか分かるようにする。
【００８３】
以上、本発明者によってなされた発明を実施例に基づき具体的に説明したが、本発明は、上記実施形態および実施例に限定されるものではなく、種々変更可能であることはいうまでもない。
【符号の説明】
【００８４】
１０１：管理センタ
１０２（１０２−１，２，・・・，Ｌ）：無線基地局
１０３（１０３−１，２，・・・，Ｌ）：通信エリア
１０４（１０４−１，２，・・・Ｎ）：移動局（車両）
１０５：ＧＰＳ衛星
１０６（１０６−１，２，・・・，Ｍ）：配車端末
１０７：配車センタ、
２００、２００ａ：データベースサーバ
２０１：エリア情報管理部
２０２：車両情報管理部
２０３：配車履歴情報格納部
２２０：地図サーバ
２２１：経路探索部
２４０：配車サーバ（ＡＶＭサーバ）
２４１：候補車検索部
２４２：配車指示部
２５０：ゲートウェイサーバ（ＧＷサーバ）
【図１】
2019061307.tif 000003
【図２】
2019061307.tif 000004
【図３】
2019061307.tif 000005
【図４】
2019061307.tif 000006
【図５】
2019061307.tif 000007
【図６】
2019061307.tif 000008
【図７】
2019061307.tif 000009