JP2020184220A - 管理システム、および管理方法 - Google Patents

Abstract

【課題】車両の配車を適切に管理することができる。【解決手段】少なくとも１つのプロセッサにより構築された、車両の駐車を管理する管理システムであって、乗車人数、乗車希望地点、および乗車希望時間を含むユーザからの配車リクエストを受信する通信部と、前記配車リクエストに基づいて、前記乗車人数に対応した一台以上の車両を確保する車両選定部と、前記乗車希望地点に対応した駐車候補地に、確保した前記車両の駐車スペースが、前記乗車希望時間に対応した駐車時間帯に割り当てられる場合に、前記駐車時間帯の前記駐車スペースおよび前記車両の予約を割り当てる予約制御部と、を含む。【選択図】図１

Description

本発明は、車両を配車するための管理システム、および管理方法に関する。

従来より、車両を配車するための技術がある。

例えば、特許文献１に記載の車両配車システムにおいては貸出車両の配車先として集合住宅の駐車場を用いている。特許文献１の車両配車システムでは、貸出予約をネットワーク経由で受け付ける配車サーバが、貸出車両が配車される駐車場を有する集合住宅の駐車区画を予約し、配車ができない状況を回避している。

例えば、特許文献２に記載のセンタ装置において、利用者の現在地を表す情報と、車両の現在地及び利用状況を表す情報とを取得し、それらの情報に基づいて利用者に対して配車可能な配車予定車両と乗車場所とを決定する技術がある。センタ装置は、利用者の現在地から乗車場所までの利用者経路と、配車予定車両の現在地から乗車場所までの車両経路とを設定する。

特開２０１４−２１１７７８号公報 特開２０１６−９１４１１号公報

しかし、従来技術では、駐車候補地の駐車スペースが、どの程度の時間利用されるのか、といったことまでは管理されておらず、配車した時間に駐車候補地の駐車スペースが埋まっている、といった問題が生じる。

また、特許文献１では、車両配車システムは、判定時点の駐車区画の空き状況だけを確認している。そのため、車両配車システムの管理下にない車両が、車両配車システムが予約した駐車区画の駐車場を使用してしまった場合に、予約した場所に配車ができないといった問題が生じる。同様に、特許文献２の技術でも、乗車場所に決定した場所が他車両等に塞がれている場合、配車ができなくなる。

このように、車両の配車においては、駐車スペースを効率的に管理する手法も必要となってくる。

本発明は上記事情を鑑みてなされたものであり、車両の配車を適切に管理するための管理システム、および管理方法を提供することを目的とする。

本発明に係る管理システム（１０）は、少なくとも１つのプロセッサにより構築された、車両の駐車を管理する管理システム（１０）であって、乗車人数、乗車希望地点、および乗車希望時間を含むユーザからの配車リクエストを受信する通信部（２０）と、前記配車リクエストに基づいて、前記乗車人数に対応した一台以上の車両を確保する車両選定部（２４）と、前記乗車希望地点に対応した駐車候補地に、確保した前記車両の駐車スペースが、前記乗車希望時間に対応した駐車時間帯に割り当てられる場合に、前記駐車時間帯の前記駐車スペースおよび前記車両の予約を割り当てる予約制御部（２６）と、を含む。

本発明に係る管理方法は、少なくとも１つのプロセッサにより構築された、車両の駐車を管理する管理システムにおける管理方法であって、乗車人数、乗車希望地点、および乗車希望時間を含むユーザからの配車リクエストを受信し、前記配車リクエストに基づいて、前記乗車人数に対応した一台以上の車両を確保し、前記乗車希望地点に対応した駐車候補地に、確保した前記車両の駐車スペースが、前記乗車希望時間に対応した駐車時間帯に割り当てられる場合に、前記駐車時間帯の前記駐車スペースおよび前記車両の予約を割り当てる。

本発明の管理システム、および管理方法によれば、車両の配車を適切に管理することができる。

本発明の第１および第２の実施の形態に係る管理システムの構成を示すブロック図である。 センタとして機能するコンピュータの一例を示す概略ブロック図である。 本発明の実施形態の配車の管理の基本的な考え方を説明するための図である。 駐車候補地と駐車スペースとの関係を示す図である。 本発明の第１の実施の形態の管理システムの予約時の処理ルーチンを示すフローチャートである。 車両仕様が類似する車両間の駐車スペースを重畳させる場合の例を示す図である。 車両仕様が類似する車両間で利用者の割り当てを入れ替えた場合の図である。 乗車人数が相互に受容できる車両間の駐車スペースを重畳させる場合の例を示す図である。 乗車人数が相互に受容できる車両間で利用者の割り当てを入れ替えた場合の図である。 出発時刻の順に車両間の駐車スペースを重畳させる場合の例を示す図である。 本発明の第２の実施の形態の管理システムの予約時の処理ルーチンを示すフローチャートである。 本発明の第２の実施の形態の管理システムの乗車時の処理ルーチンを示すフローチャートである。

以下、本発明の実施の形態について図面を用いて説明する。

本発明の実施の形態に係る手法は、車両の配車を管理するための管理システムに関する。管理システムは、配車時の乗降場所および車両待機場所として利用する駐車スペースを利用時間と共に管理する。管理システムによる管理では、利用時間帯における駐車スペースを他車両が占有しないようにする。

このように、管理システムによる管理を行うことによって、特定の時間帯に特定の場所に対する配車リクエストが集中する場合に、乗降できるスペースがないために、利用者が配車した車両を利用できなくなる状況の発生を抑制できる。例えば、混雑が予想されるラッシュアワー時の駅ロータリー等に、シェアカーを配車するような利用シーンにも対応できる。

また、駐車スペースを効率よく配分することで、駐車候補地内に多くの車両を詰め込めるため、駐車スペースの効率的な利用が可能となる。また、時間帯によって駐車スペースを管理するため、駐車スペースが利用可能になるまで、車道で待機する車両が発生して渋滞が引き起こされるような事態を回避することができる。

＜第１の実施の形態＞
図１を参照して、本発明の第１の実施の形態に係る管理システムの構成について説明する。図１は、本発明の第１の実施の形態に係る管理システム１０の構成を示すブロック図である。図１に示すように、管理システム１０は、センタ１２と、管理対象の複数の車両１４と、複数のユーザ端末１６とを含んで構成されている。なお、センタ１２は一つである場合を例に説明するが、クラウド環境等に複数のセンタ１２を設けて分散処理するようにしてもよい。

図２は、センタ１２として機能するコンピュータの一例を示す概略ブロック図である。例えば、センタ１２は、図２に示すコンピュータ５０で実現することができる。コンピュータ５０はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：プロセッサ）５１、一時記憶領域としてのメモリ５２、及び不揮発性の記憶部５３を備える。また、コンピュータ５０は、入出力装置等（図示省略）が接続される入出力interface（Ｉ／Ｆ）５４、及び記録媒体に対するデータの読み込み及び書き込みを制御するread/write（Ｒ／Ｗ）部５５を備える。また、コンピュータ５０は、インターネット等のネットワークＮに接続されるネットワークＩ／Ｆ５６を備える。ＣＰＵ５１、メモリ５２、記憶部５３、入出力Ｉ／Ｆ５４、Ｒ／Ｗ部５５、及びネットワークＩ／Ｆ５６は、バス５７を介して互いに接続される。

記憶部５３は、Hard Disk Drive（ＨＤＤ）、solid state drive（ＳＳＤ）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部５３には、コンピュータ５０を機能させるためのプログラムが記憶されている。ＣＰＵ５１は、プログラムを記憶部５３から読み出してメモリ５２に展開し、プログラムが有するプロセスを順次実行する。

以上が図２におけるコンピュータの電気的な構成の一例の説明である。

以下、管理システム１０の構成について説明する。

センタ１２は、ユーザ端末１６からの要求に応じて車両の配車を管理するサーバである。センタ１２は、通信部２０と、予約制御部２６とを含んでいる。

車両１４は、ユーザ端末１６を保有するユーザである利用者からの配車リクエストによって配車される車両であり、乗車可能人数等、車両の大きさが定められている。車両１４は、自動運転車（自動運転タクシーまたは自動運転バス）、シェアカー等が想定される。車両１４は、適宜、センタ１２と通信し、車両情報ＤＢ３０の配車の手配状況を参照して、配車先に走行する。なお、センタ１２から配車の手配状況を送信するようにしてもよい。

ユーザ端末１６は、例えばスマートフォン、タブレット等の携帯端末であり、ウェブブラウザや予めインストールされたプログラム等を介して配車リクエストの入力および送信が可能である。ユーザ端末１６を保有する利用者は、配車を希望する場合にはユーザ端末１６に配車リクエストを入力する。利用者は、ユーザ端末１６に、乗車人数、乗車希望地点、および乗車希望時間を含む配車リクエストを入力して、ユーザ端末１６が配車リクエストをセンタ１２に送信する。また、ユーザ端末１６は、利用者が駐車候補地に到着した際に、認証情報を含む到着情報を送信する。なお、以下、単にユーザ端末１６と記載した場合には特定の１台のユーザ端末１６を表している。

センタ１２の各部およびＤＢについて説明する。

車両情報ＤＢ３０には、センタ１２で管理する車両の情報が記憶されている。車両の情報は、車両の乗車可能人数、車種、大きさ、現在地、配車の手配状況といった情報である。現在地は適宜、車両から通知される。配車の手配状況は、車両が予約により占有される時間、および配車される駐車候補地を含む情報である。

予約管理ＤＢ３２には、センタ１２で管理する配車の予約情報、およびユーザ端末１６を保有する利用者の利用者情報が記憶されている。配車の予約情報は、予約制御部２６によって更新される、駐車候補地ごとの車両の各時間帯の配車場所の予約状況を記録した情報である。利用者情報は、ユーザ端末１６の各種ＩＤ、登録情報、配車利用情報であり、適宜、更新される。

通信部２０は、配車リクエストをユーザ端末１６から受信する。また、配車情報を車両１４およびユーザ端末１６に送信する。

利用者情報管理部２２は、予約情報に基づいて配車情報を作成し、通信部２０から配車情報を車両１４およびユーザ端末１６に送信する。配車情報は、例えば「ＸＸ時ＸＸ分ＸＸ地点（地図）にＮｏ．ＸＸＸＸの車両の予約を完了しました」といった通知を含む。また、配車情報には、乗車時に必要となるＱＲまたは認証ＩＤ等の認証情報が含まれる。また、利用者情報管理部２２は、利用者に案内する車両に変更があった場合に、変更後の車両に乗車するように案内する通知をユーザ端末１６に送信する。

車両選定部２４は、配車リクエストに基づいて、車両情報ＤＢ３０の車両から、乗車人数に対応した一台以上の車両を確保する。

予約制御部２６は、乗車希望地点に対応した予約管理ＤＢ３２の駐車候補地に、車両選定部２４で確保した車両の駐車スペースが、乗車希望時間に対応した駐車時間帯に割り当てられるか否か、すなわち配車可能か否かを判定する。判定の条件については作用の説明において後述する。予約制御部２６は、配車可能である場合に、車両選定部２４で確保した車両について、駐車時間帯の駐車スペースの予約を割り当てる。予約制御部２６は、当該予約の内容に基づいて、予約管理ＤＢ３２の駐車候補地の予約情報を更新する。また、予約制御部２６は、確保された車両についての車両情報ＤＢ３０の配車の手配状況を更新する。

ここで車両の配車の管理の方法を説明する。図３は、本発明の実施形態の配車の管理の基本的な考え方を説明するための図である。図３では、駐車候補地Ａに対する１８時〜１９時の間の配車の予約情報を表している。図３に示すように、駐車候補地Ａには１８時過ぎの重畳した時間帯に車両ａおよび車両ｂの予約が入っていることを表している。縦軸が予約で確保される駐車時間帯、横軸が予約で確保される駐車スペースを表している。駐車時間帯は、配車した車両が駐車して出発するまでに必要な時間であり、乗車希望時間に対応した前後の時間が確保される。乗車希望時間を基準としてどの程度の時間を確保するかは管理システム１０の定めに応じて任意に定めておけばよい。駐車スペースは、１台の車両あたり占有部およびアプローチ部を含むスペースとして確保される。占有部は車両が駐車完了状態で占有するスペースである。アプローチ部は、車両の駐車または出発に伴って確保する必要があるスペースである。図３では駐車スペースにアプローチ部を１つ含む場合の例であるが、駐車スペースに含むアプローチ部は、占有部の前後にそれぞれ設けて２つにする場合もある。また、占有部およびアプローチ部の大きさは車両の車種に応じて適切な大きさのスペースを決定しておく。占有部およびアプローチ部について、適切な大きさを定めておくことで、より正確な管理が可能となる。

ここで、アプローチ部の考え方について説明する。図４は、駐車候補地と駐車スペースとの関係を示す図である。図４に示すように、駐車候補地では、前方に詰めるように車両を配車し、前方から出発していくことを想定する。そのため、駐車スペースとしては、発車に必要な前方のアプローチ部および占有部を確保する。なお、駐車候補地の大きさに余裕がある場合には、駐車時に必要なアプローチ部も含めた駐車スペースを確保するようにしてもよい。

上記の前提のもとで、センタ１２の予約制御部２６では、駐車時間帯の単位時間ごとに駐車候補地の大きさ≧駐車スペースとして確保される合計の大きさ、となる条件を満たす場合に予約が可能と判断する。単位時間とは、駐車時間帯の単位時間であり、１分等で定める。

次に、本発明の第１の実施の形態に係る管理システム１０の作用について説明する。図５は、本発明の第１の実施の形態の管理システム１０の予約時の処理ルーチンを示すフローチャートである。

ステップＳ１００で、通信部２０が、配車リクエストをユーザ端末１６から受信する。配車リクエストは、乗車人数、乗車希望地点、および乗車希望時間を含む。

ステップＳ１０２で、車両選定部２４が、配車リクエストに基づいて、車両情報ＤＢ３０の車両のうち、乗車人数に対応した一台以上の車両の確保が可能であるか否かを判定する。車両の確保が可能であれば、ステップＳ１０４へ移行し、可能でなければステップＳ１０６へ移行する。また、確保の判定の対象とする車両は、乗車希望時間に占有されていない車両であって、乗車希望時間に乗車希望地点に到達可能な車両とする。

ステップＳ１０４で、予約制御部２６が、乗車希望地点に対応した予約管理ＤＢ３２の駐車候補地に、車両選定部２４で確保した車両の駐車スペースが、乗車希望時間に対応した駐車時間帯に割り当てられるか否か、すなわち配車可能か否かを判定する。配車可能であればステップＳ１０８へ移行し、配車可能でなければステップＳ１０６へ移行する。配車可能であるか否かは、予約管理ＤＢ３２の予約情報を確認し、駐車時間帯の単位時間ごとに駐車候補地の大きさ≧駐車スペースとして確保される合計の大きさ、の条件を満たす場合には配車可能と判定し、条件を満たさない場合には配車不可と判定する。駐車候補地において、先に複数台の車両を割り当てた予約があったとして、更にステップＳ１０２で確保した車両を割り当てる場合を想定する。駐車スペースとして確保される合計の大きさは、スペースを最大限活用するように計算する場合は、予約される車両の各々の占有部および一つのアプローチ部とする。一つのアプローチ部は出発に伴うアプローチ部である。一つのアプローチ部があれば先頭の車両から順次出発することができるからである。よって、予約制御部２６では、予約される車両の各々の占有部および一つのアプローチ部が少なくとも割り当て可能であれば、配車可能であると判定する。

ステップＳ１０６では、利用者情報管理部２２が、配車不可であるとして、利用者が保有するユーザ端末１６に、乗車希望時間または乗車希望地点の変更を提案する旨の通知を通信部２０から送信する。

ステップＳ１０８では、車両選定部２４が、車両情報ＤＢ３０から配車する車両を確保する。

ステップＳ１１０では、予約制御部２６が、乗車希望地点に対応した予約管理ＤＢ３２の駐車候補地に、確保した車両について、駐車時間帯の駐車スペースの予約を割り当てる。

ステップＳ１１２では、予約制御部２６は、予約の内容に基づいて、予約管理ＤＢ３２の駐車候補地の予約情報、および確保された車両についての車両情報ＤＢ３０の配車の手配状況を更新する。

ステップＳ１１４では、利用者情報管理部２２は、予約情報に基づいてユーザ端末１６に対する配車情報を作成する。

ステップＳ１１６では、通信部２０が、配車情報をユーザ端末１６に送信し、処理を終了する。

以上説明したように、本発明の第１の実施の形態に係る管理システム１０によれば、車両の配車を適切に管理することができる。また、センタ１２により配車を一括管理することで、配車した駐車スペースが利用できないリスクを軽減できる。

＜第２の実施の形態＞
第２の実施の形態は、駐車スペースを重畳させて、最適化する場合を例に説明する。なお、第２の実施の形態の構成は、上記図１に示した第１の実施の形態と同様であるため同一符号として説明する。

予約制御部２６は、条件に応じて駐車スペースを重畳させることが可能である場合には、駐車スペースを重畳させるようにして、駐車候補地の車両の配置を最適化する。予約制御部２６は、重畳する駐車時間帯の複数の配車リクエストに対して、各車両の駐車スペースを非重畳とすると新たに予約を割り当てられない場合に、重畳が可能であるか否かを判断し、重畳が可能である場合には最適化を行う。重畳が可能であるかは、後述する各ケースのいずれかに該当し、駐車候補地のスペースに新たに配車する車両の占有部のスペースが割り当てられる場合である。予約制御部２６は、重畳が可能であると判断した場合には、前方に駐車する車両に割り当てられた駐車スペースの占有部と、前方に駐車する車両の後続として後方に駐車する車両のアプローチ部とが重畳するように、駐車候補地における各車両の配置を最適化する。つまり、駐車スペースの合計は、予約される車両の各々の占有部と、一つ以上の出発に伴うアプローチ部となる。

ここで駐車スペースが重畳できる場合の例として、第１のケース〜第３のケースを説明する。第１〜第３のケースで説明する条件が、所定の条件の一例である。

まず、第１のケースとして、車両間の車両仕様が類似するケースについて説明する。図６は、車両仕様が類似する車両間の駐車スペースを重畳させる場合の例を示す図である。予約制御部２６は、以下に説明するように、車両仕様が類似する車両間において、駐車スペースが重畳するように、駐車候補地における各車両の配置を最適化する。図６に示すように、駐車候補地に、５人乗車可能な車両Ａおよび２人乗車可能な車両Ｂの予約がされていたとする。このとき、新たに、５人乗車可能な車両Ｃ、２人乗車可能な車両Ｄ、車両Ｅの予約が発生したとする。この場合に、５人乗車可能な車両同士について、車両Ａの占有部に同じ５人乗車可能な車両Ｃのアプローチ部を重畳させるように配置する。また、同様に、２人乗車可能な車両同士について、車両Ｂの占有部に車両Ｄのアプローチ部、車両Ｄの占有部に車両Ｅのアプローチ部をそれぞれ重畳させるように配置する。

また、第１のケースにおいては、ユーザ端末１６で予約した利用者の到着時刻に応じて、予約時に割り当てた車両を入れ替えることが可能である。

センタ１２は、通信部２０でユーザ端末１６から乗降場所への到着時刻を受信した場合に、予約制御部２６において、当該入れ替えが可能であるか否かを判定し、可能である場合には予約時に割り当てた車両を入れ替える。利用者情報管理部２２は、通信部２０を介して、入れ替えた車両を予約している利用者のそれぞれのユーザ端末１６に変更後の車両に乗車するように案内する通知を送信する。以下では、予約制御部２６が、車両仕様が類似する車両間において、駐車スペースが重畳するように、駐車候補地における各車両の配置を最適化する場合を説明する。

図７は、車両仕様が類似する車両間で利用者の割り当てを入れ替えた場合の図である。図７に示すように、当初のセンタ１２における予約情報では、ｂさんの配車希望時刻が１０：１０であり、ｄさんの配車希望時刻が１０：１５である。車両Ｂをｂさんの予約に割り当て、車両Ｂに後続する車両Ｄをｄさんの予約を割り当てていたとする。しかし、ｂさんの乗降場所への到着時刻が遅れて１０：１４になり、ｄさんの乗降場所への到着時刻が１０：１１であったとする。この場合に、予約制御部２６は、利用者の乗車場所への到着時刻に応じて、利用者に案内する車両について、車両Ｂと車両Ｄとを入れ替える。つまり、車両Ｄをｂさんに案内し、車両Ｂをｄさんに案内する。車両Ｂ、車両Ｄは車両仕様が類似するため、乗車人数を相互に受容することができるため、入れ替えが可能である。このように車両の入れ替えを行うことで、利用者の到着順に応じてスムーズな出発が可能となり、利用者の利便性が向上する。

次に、第２のケースとして、乗車人数が相互に受容できるケースについて説明する。図８は、乗車人数が相互に受容できる車両間の駐車スペースを重畳させる場合の例を示す図である。予約制御部２６は、以下に説明するように、乗車人数が相互に受容できる車両間において、駐車スペースが重畳するように、駐車候補地における各車両の配置を最適化する。図８に示すように、駐車候補地に、２人乗車予定の車両Ａの予約がされていたとする。このとき、新たに、１人乗車予定の車両Ｂ、２人乗車予定の車両Ｃ、２人乗車予定の車両Ｄの予約が発生したとする。この場合に、車両Ａ〜Ｄは、乗車人数が相互に受容できる。そのため、車両Ａの占有部に車両Ｂのアプローチ部、車両Ｂの占有部に車両Ｃのアプローチ部、車両Ｃの占有部に車両Ｄのアプローチ部をそれぞれ重畳させるように配置する。

また、第２のケースにおいても第１のケースの場合と同様に、ユーザ端末１６で予約した利用者の到着時刻に応じて、予約時に割り当てた車両を入れ替えることが可能である。以下では、予約制御部２６が、乗車人数が相互に受容できる車両間において、駐車スペースが重畳するように、駐車候補地における各車両の配置を最適化する場合を説明する。

図９は、乗車人数が相互に受容できる車両間で利用者の割り当てを入れ替えた場合の図である。図９に示すように、当初のセンタ１２における予約情報では、ａさんの配車希望時刻が１０：１０であり、ｂさんの配車希望時刻が１０：１２であり、ｃさんの配車希望時刻が１０：１５である。車両Ａをａさんの予約に割り当て、後続する車両Ｂをｂさん、車両Ｃをｃさんの予約に割り当てていたとする。しかし、ａさんの乗降場所への到着時刻が遅れて１０：１５になり、ｂさんの乗降場所への到着時刻が１０：１１、ｃさんが１０：１４であったとする。この場合に、予約制御部２６は、利用者の乗車場所への到着時刻に応じて、利用者に案内する車両について、車両Ｃ、車両Ａ、車両Ｂの順になるように入れ替える。つまり、車両Ｃをａさんに案内し、車両Ａをｂさんに案内し、車両ＢをＣさんに案内する。車両Ａ〜Ｃは乗車人数が相互に受容できるため、相互に入れ替えが可能である。このように車両の入れ替えを行うことで、利用者の到着順に応じてスムーズな出発が可能となり、利用者の利便性が向上する。

次に、第３のケースとして、出発予定時刻の順番によるケースについて説明する。図１０は、出発時刻の順に車両間の駐車スペースを重畳させる場合の例を示す図である。予約制御部２６は、以下に説明するように、出発時刻の順に、駐車スペースが重畳するように、駐車候補地における各車両の配置を最適化する。図１０に示すように、駐車候補地に、車両Ａの予約がされ出発予定時刻が１７：０５であったとする。出発予定時刻は、例えば、乗車予定時刻から数分後等、適切な時間単位を予め定めておいて設定すればよい。次に、車両Ｂの予約がされ出発予定時刻が１７：０５であったとする。このとき、予約制御部２６は、車両Ａおよび車両Ｂの駐車スペースの大きさは駐車候補地に収まるため、予約において非重畳に車両を配置する。次に、車両Ｃの予約がされ出発予定時刻が１７：０７であったとする。この場合に、予約制御部２６は、非重畳な配置では駐車候補地に収まらないため、出発時刻の順に車両を重畳するように配置する。例えば、出発予定時刻が重複しない車両同士の駐車スペースを重畳するように配置する。例えば、車両Ａの出発予定時刻よりも車両Ｃの出発予定時刻は後であるため、車両Ａの占有部に車両Ｃのアプローチ部を重畳させるように配置する。

以上が、駐車スペースの重畳が可能な各ケースの説明である。予約制御部２６は、上記第１〜第３のケースについて、１つのケースを適用する場合には、優先順位を定めておき、優先順位が高いケースを適用するようにすればよい。また、複数のケースを同時に適用してもよい。

次に、本発明の第２の実施の形態に係る管理システム１０の作用について説明する。図１１は、本発明の第２の実施の形態の管理システム１０の予約時の処理ルーチンを示すフローチャートである。なお、同様の処理のステップには同一符号を付して説明を省略する。

ステップＳ１０８による車両の確保を経て、ステップＳ２００に遷移する。

ステップＳ２００では、予約制御部２６が、駐車候補地の予約情報に基づいて、駐車スペースが非重畳の場合に、駐車候補地の大きさ≧駐車スペースとして確保される合計の大きさ、の条件を満たすか否かを判定する。条件を満たす場合には、ステップＳ１１０へ移行し、条件を満たさない場合には、ステップＳ２０２へ移行する。

ステップＳ２０２では、予約制御部２６が、上記の第１〜第３のケースのいずれかに該当するか否かを判定し、該当する場合にはステップＳ２０４へ移行し、該当しない場合にはステップＳ１０６へ移行する。

ステップＳ２０４では、駐車スペースを重畳させた場合に、駐車候補地で車両の占有部を確保可能であるか否かを判定し、確保可能な場合にはステップＳ２０６へ移行し、確保可能でない場合にはステップＳ１０６へ移行する。

ステップＳ２０６では、予約制御部２６は、ステップＳ２０２で判定されたケースに応じて、予約管理ＤＢ３２の駐車候補地の予約情報について、該当するケースに従って、駐車スペースが重畳するように各車両の配置を最適化する。ステップＳ２０６の後はステップＳ１１０、Ｓ１１２を経てステップＳ２０８へ移行する。

ステップＳ２０８では、予約制御部２６は、他車両の配置が変更されたか否かを判定し、変更された場合にはステップＳ２１０へ移行し、変更されていない場合にはステップＳ１１４へ移行する。

ステップＳ２１０では、予約制御部２６は、配置が変更された車両１４に変更後の配置を通信部２０から送信し、ステップＳ１１４へ移行する。

次に、第２の実施形態の管理システム１０の乗車時の処理を説明する。図１２は、本発明の第２の実施の形態の管理システム１０の乗車時の処理ルーチンを示すフローチャートである。

ステップＳ３００では、通信部２０が、ユーザ端末１６から認証情報を含む到着情報を受け付ける。なお、到着情報を受け付けた日時を到着時刻とする。

ステップＳ３０２では、予約制御部２６が、認証情報が予約情報と一致するか否かを判定する。一致する場合にはステップＳ３０６へ移行し、一致しない場合にはステップＳ３０４へ移行する。

ステップＳ３０４では、利用者情報管理部２２が、認証情報が不一致である旨の通知を、通信部２０からユーザ端末１６に送信する。

ステップＳ３０６では、予約制御部２６が、予約管理ＤＢ３２の駐車候補地の予約情報について、駐車スペースを重畳させるように最適化しているか否かを判定する。最適化している場合にはステップＳ３０８へ移行し、最適化していない場合にはステップＳ３１０へ移行する。

ステップＳ３０８では、予約制御部２６が、よりスムーズに出発が可能な別車両に案内可能であるか否かを判定する。案内可能である場合にはステップＳ３１２へ移行し、案内可能でない場合にはステップＳ３１０へ移行する。

ステップＳ３１０では、予約制御部２６が、予約管理ＤＢ３２の予約情報の車両に乗車するように案内する通知を通信部２０からユーザ端末１６に送信する。

ステップＳ３１２では、予約制御部２６が、予約管理ＤＢ３２の予約情報について、当該の到着済みユーザに対応する予約を、よりスムーズに出発が可能な別車両に変更するように予約情報を更新する。また、当該の別車両を配車予定だった他のユーザに対応する予約について、当初到着済みのユーザに配車予定であった車両を配車するように予約情報を更新する。

ステップＳ３１４では、利用者情報管理部２２が、ステップＳ３１２で更新された予約情報に基づいて、配車車両が変更されたユーザに対して、変更後の車両に乗車するように案内する通知を、通信部２０から該当するユーザ端末１６に送信する。

以上説明したように、本発明の第２の実施形態に係る管理システム１０によれば、車両の配車を、スペースを効率よく用い、かつ、適切に管理することができる。また、センタ１２により配車を一括管理することで、配車した駐車スペースが利用できないリスクを軽減できる。

なお、本発明は、上述した実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。

例えば、予約制御部２６は、予約が可能な駐車スペースが複数存在する場合に、ユーザ端末１６から駐車スペースの指定を受け付け、受け付けた駐車スペースに予約を割り当てるようにしてもよい。

また、センタ１２では、乗車の配車と同様に、降車の駐車候補地の予約も管理するようにしてもよい。この場合には、通信部２０は、ユーザ端末１６から降車希望地点を受け付ける。予約制御部２６は、乗車希望時間または出発時刻から降車希望地点の到着時刻を予測し、降車希望地点に対応した駐車候補地において、予測した到着時刻に対応した時間帯の駐車スペースの予約を行う。降車の予約の場合においても、配車する場合と同様に、駐車スペースを割り当てられない場合に、変更を提案する旨の通知を送信するようにしてもよい。また、予約可能な駐車スペースが複数存在する場合に、ユーザ端末１６から指定を受け付けるようにしてもよい。

また、管理システム１０において、駐車候補地にセンサを設け、予約済みの駐車スペースが利用可能であるかを監視するようにしてもよい。センサが外的要因（例えば管理システム１０の管理外の車両など駐車スペースに駐車している場合等）を検知すると、予約制御部２６では、予約済みの車両待機場所が利用不能であるか否かを判断する。予約制御部２６は、利用不能であると判断した場合に、乗車希望地点付近の駐車候補地内から新たに空きのある駐車スペースを予約する。利用者情報管理部２２は、ユーザ端末１６に駐車スペースの場所の変更を通知する。また、利用不能であるか否かの判断は、管理者に外的要因の検知情報を通知し、管理者側で判断するようにしてもよい。

また、本願明細書中において、プログラムが予めインストールされている実施形態として説明したが、当該プログラムを、コンピュータ読み取り可能な記録媒体に格納して提供することも可能である。

１０ 管理システム
１２ センタ
１４ 車両
１６ ユーザ端末
２０ 通信部
２２ 利用者情報管理部
２４ 車両選定部
２６ 予約制御部
３０ 車両情報ＤＢ
３２ 予約管理ＤＢ

Claims (13)

1. 少なくとも１つのプロセッサにより構築された、車両の駐車を管理する管理システムであって、
   乗車人数、乗車希望地点、および乗車希望時間を含むユーザからの配車リクエストを受信する通信部と、
   前記配車リクエストに基づいて、前記乗車人数に対応した一台以上の車両を確保する車両選定部と、
   前記乗車希望地点に対応した駐車候補地に、確保した前記車両の駐車スペースが、前記乗車希望時間に対応した駐車時間帯に割り当てられる場合に、前記駐車時間帯の前記駐車スペースおよび前記車両の予約を割り当てる予約制御部と、
   を含む管理システム。
2. 前記駐車スペースは、車両が駐車完了状態で占有するスペースである占有部と、車両の出発に伴って確保する必要があるスペースであるアプローチ部とを含み、
   前記予約制御部は、
   前記駐車時間帯に、前記駐車候補地において、予約される車両の各々の前記占有部および一つ以上の前記アプローチ部が割り当て可能である場合に、前記駐車候補地に、前記確保した前記車両の駐車スペースの前記予約を割り当てる請求項１に記載の管理システム。
3. 前記占有部のスペースおよび前記アプローチ部のスペースは、確保する前記車両の車種に応じて予め定められた大きさのスペースとする請求項２に記載の管理システム。
4. 前記予約制御部は、
   前記駐車候補地において、重畳する駐車時間帯に複数の前記配車リクエストがあり、各車両の前記駐車スペースを非重畳とすると新たに予約を割り当てられない場合に、
   所定の条件に応じて、前方に駐車する車両に割り当てられた前記駐車スペースの前記占有部と、前記前方に駐車する車両の後続として後方に駐車する車両の前記アプローチ部とが重畳するように、前記駐車候補地における各車両の配置を最適化する請求項２または請求項３に記載の管理システム。
5. 前記予約制御部は、
   前記条件を車両仕様が類似する車両間であることとし、前記車両仕様が類似する車両間において、前記重畳するように、前記駐車候補地における各車両の配置を最適化する請求項４に記載の管理システム。
6. 前記予約制御部は、
   前記条件を前記乗車人数が相互に受容できる車両間であることとし、前記乗車人数が相互に受容できる車両間において、前記重畳するように、前記駐車候補地における各車両の配置を最適化する請求項４または請求項５に記載の管理システム。
7. 前記予約制御部は、
   複数の予約が重畳した駐車時間帯にされている場合に、
   前記ユーザの前記駐車候補地への到着時刻が、前記乗車希望時間と異なる場合に、前記ユーザが前記予約した第１の車両とは異なる予約済みの車両であって、前記到着時刻に対応し、かつ、前記乗車人数が受容できる第２の車両がある場合に、前記ユーザの予約を前記第２の車両に変更する請求項５または請求項６に記載の管理システム。
8. 前記予約制御部は、
   前記条件を予め定められた出発時刻の順であることとし、前記出発時刻の順に、前記重畳するように、前記駐車候補地における各車両の配置を最適化する請求項４〜請求項７の何れか１項に記載の管理システム。
9. 前記予約制御部は、
   前記駐車候補地を、予め設置したセンサにより監視し、前記予約した前記駐車スペースが利用可能であるかを監視する請求項１〜請求項８の何れか１項に記載の管理システム。
10. 前記予約制御部は、
    前記駐車候補地において、前記予約が可能な前記駐車スペースが複数存在する場合に、前記ユーザから前記駐車スペースの指定を受け付ける請求項１〜請求項９の何れか１項に記載の管理システム。
11. 前記通信部により、前記駐車候補地において、前記駐車スペースが、前記駐車時間帯に割り当てられない場合に、前記ユーザに前記乗車希望地点または前記乗車希望時間を変更するように通知する請求項１〜請求項１０の何れか１項に記載の管理システム。
12. 前記通信部は、前記ユーザから降車希望地点を受け付け、
    前記予約制御部は、前記乗車希望時間または出発時刻から前記降車希望地点の到着時刻を予測し、前記降車希望地点に対応した駐車候補地において、予測した前記到着時刻に対応した時間帯の前記駐車スペースの予約を割り当てる請求項１〜請求項１１の何れか１項に記載の管理システム。
13. 少なくとも１つのプロセッサにより構築された、車両の駐車を管理する管理システムにおける管理方法であって、
    乗車人数、乗車希望地点、および乗車希望時間を含むユーザからの配車リクエストを受信し、
    前記配車リクエストに基づいて、前記乗車人数に対応した一台以上の車両を確保し、
    前記乗車希望地点に対応した駐車候補地に、確保した前記車両の駐車スペースが、前記乗車希望時間に対応した駐車時間帯に割り当てられる場合に、前記駐車時間帯の前記駐車スペースおよび前記車両の予約を割り当てる
    管理方法。