(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-09
(45)【発行日】2024-10-18
(54)【発明の名称】配車方法及び配車装置
(51)【国際特許分類】
G08G 1/127 20060101AFI20241010BHJP
G08G 1/00 20060101ALI20241010BHJP
G08G 1/123 20060101ALI20241010BHJP
G06Q 50/40 20240101ALI20241010BHJP
【FI】
G08G1/127 A
G08G1/00 D
G08G1/123 A
G06Q50/40
(21)【出願番号】P 2021042149
(22)【出願日】2021-03-16
【審査請求日】2023-11-07
(73)【特許権者】
【識別番号】000003997
【氏名又は名称】日産自動車株式会社
(73)【特許権者】
【識別番号】507308902
【氏名又は名称】ルノー エス.ア.エス.
【氏名又は名称原語表記】RENAULT S.A.S.
【住所又は居所原語表記】122-122 bis, avenue du General Leclerc, 92100 Boulogne-Billancourt, France
(74)【代理人】
【識別番号】100083806
【氏名又は名称】三好 秀和
(74)【代理人】
【識別番号】100101247
【氏名又は名称】高橋 俊一
(74)【代理人】
【識別番号】100095500
【氏名又は名称】伊藤 正和
(74)【代理人】
【識別番号】100098327
【氏名又は名称】高松 俊雄
(72)【発明者】
【氏名】岩崎 英城
(72)【発明者】
【氏名】費 霄霄
(72)【発明者】
【氏名】千葉 光太郎
(72)【発明者】
【氏名】御厨 裕
【審査官】佐藤 吉信
(56)【参考文献】
【文献】特表2016-509287(JP,A)
【文献】特開2020-119441(JP,A)
【文献】特開2000-067389(JP,A)
【文献】特開2021-018694(JP,A)
【文献】特開2020-187520(JP,A)
【文献】特開2004-070481(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G08G 1/00-99/00
G06Q 10/00-10/30
G06Q 30/00-30/08
G06Q 50/00-50/20
G06Q 50/26-99/00
(57)【特許請求の範囲】
【請求項1】
ユーザの輸送に用いる車両の配車を要求するユーザの端末から、現在地及び目的地を含む予約情報を取得し、
配車可能な前記車両の供給量に対する前記車両の配車の需要量が、所定の過剰状態であるか否かを判定し、
前記供給量に対する前記需要量が前記所定の過剰状態でない一般的な配車処理では、前記ユーザの端末から前記予約情報を含む配車要求を取得すると、配車可能な前記車両をその都度前記ユーザに配車し、
前記供給量に対する前記需要量が前記所定の過剰状態である場合に、前記予約情報を前記端末から取得したユーザを、前記予約情報の前記目的地までの経路に共通の区間を含み、かつ、前記予約情報の前記現在地が所定の広さの同じ領域内に存在するユーザ毎にグループ分けし、
前記グループ分けした各グループのうちユーザ数が多いグループほど、前記配車可能な車両を優先して配車する、
配車方法。
【請求項2】
前記予約情報を前記端末から取得したユーザを、前記配車可能な車両の乗車可能人数以下のユーザ数のグループにグループ分けする請求項1に記載の配車方法。
【請求項3】
前記車両に関する配車の可否状態を含む運行情報を取得し、前記運行情報に基づいて前記供給量を特定し、前記予約情報に基づいて前記需要量を特定する請求項1又は2に記載の配車方法。
【請求項4】
同一の前記グループにグループ分けされた各ユーザの前記端末に、配車候補のグループとしてグループ単位の行動を要請する案内情報を送信する請求項1~3のうちいずれか1項に記載の配車方法。
【請求項5】
前記案内情報は、前記配車可能な車両の配車候補地への経路案内情報を含んでいる請求項4に記載の配車方法。
【請求項6】
前記共通の区間の距離又は乗車時間が長いグループほど、前記配車可能な車両を優先して配車する請求項1~5のいずれか1項に記載の配車方法。
【請求項7】
前記予約情報の取得からの経過時間が長いユーザを含むグループほど、前記配車可能な車両を優先して配車する請求項1~6のいずれか1項に記載の配車方法。
【請求項8】
前記予約情報は、前記ユーザの乗車要求度の高さに関する属性情報を含んでおり、前記乗車要求度が高いユーザを含むグループほど、前記配車可能な車両を優先して配車する請求項1~7のいずれか1項に記載の配車方法。
【請求項9】
ユーザの輸送に用いる車両の配車を要求するユーザの端末から、現在地及び目的地を含む予約情報を取得する予約情報取得部と、
配車可能な前記車両の供給量に対する前記車両の配車の需要量が、所定の過剰状態であるか否かを判定する過剰判定部と、
前記供給量に対する前記需要量が前記所定の過剰状態である場合に、前記予約情報を前記端末から取得したユーザを、前記予約情報の前記目的地までの経路に共通の区間を含み、かつ、前記予約情報の前記現在地が所定の広さの同じ領域内に存在するユーザ毎にグループ分けするグルーピング部と、
前記グループ分けした各グループのうちユーザ数が多いグループほど、前記配車可能な車両を優先して配車する配車制御部と、
を備え
、
前記配車制御部は、前記供給量に対する前記需要量が前記所定の過剰状態でない一般的な配車処理では、前記ユーザの端末から前記予約情報を含む配車要求を取得すると、配車可能な前記車両をその都度前記ユーザに配車する
配車装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、配車方法及び配車装置に関する。
【背景技術】
【0002】
出発地点から目的地点までの経路として、自動車移動区間を含む経路を探索し案内する技術が提案されている(特許文献1)。この技術では、交通機関が利用できず徒歩移動となる区間がある場合に、徒歩移動区間の代わりに、自動車との乗り換えに適した交通機関の駅、バス停等を乗換地とする自動車移動区間を含む経路を探索し案内する。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1の技術では、案内された経路で出発地点から目的地点に移動するユーザは、例えば、自動車移動区間で利用するタクシーの配車を手配する。交通機関の最終便の終了後、不通時等の場面では、多数のユーザが同じ乗換地を乗車地又は降車地とするタクシーの配車をそれぞれ手配する。この場面では、多数のユーザがそれぞれに配車されたタクシーに乗車するので、タクシーの需要は過多になり利用率は上がるが、配車されたタクシーの乗車率は上がりにくい。したがって、長時間配車待ちするユーザがなかなか減らない可能性がある。
【0005】
本発明は前記事情に鑑みなされたもので、本発明の目的は、ユーザの輸送に用いる車両の需要が高い場面で配車される車両の運用効率を向上させることにある。
【課題を解決するための手段】
【0006】
上述した課題を解決するために、本発明の一つの態様に係る配車方法では、配車可能な車両の供給量に対する車両の配車の需要量が、所定の過剰状態である場合に、車両の配車を要求するユーザをグループ分けする。各グループには、ユーザの端末から取得した予約情報の現在地が所定の広さの同じ領域内に存在し、かつ、予約情報の目的地までの経路に共通の区間を含むユーザを、グループ分けする。グループ分けした各グループのうちユーザ数が多いグループほど、配車可能な車両を優先して配車する。
【発明の効果】
【0007】
本発明によれば、ユーザの輸送に用いる車両の需要が高い場面で配車される車両の運用効率を向上させることができる。
【図面の簡単な説明】
【0008】
【
図1】
図1は、本発明の一実施形態に係る配車システムの概略図である。
【
図2】
図2は、
図1の配車システムによる予約配車処理手順の一例を示すフローチャートである。
【
図3】
図3は、
図1の配車システムによって配車された車両が配車対象のグループに属する各ユーザをグループの配車候補地で乗車させる配車パターンの説明図である。
【発明を実施するための形態】
【0009】
以下、本発明の実施形態について、図面を参照して説明する。図面の記載において同一部分には同一符号を付して説明を省略する。
【0010】
図1を参照して配車システム10の構成を説明する。
図1に示すように、本実施形態に係る配車システム10は、配車サーバ20(配車装置)と、通信ネットワーク40と、車両のナビゲーション端末50と、ユーザ60が所持する端末装置70(ユーザの端末)を含む。本発明の実施形態に係る配車方法は、配車サーバ20が行う処理によって実施することができる。
【0011】
この配車システム10では、配車サーバ20が、通信ネットワーク40を介して、車両のナビゲーション端末50と通信する。また、配車サーバ20は、通信ネットワーク40を介して、ユーザ60の輸送に用いる車両の配車を要求するユーザ60の端末装置70と通信する。
【0012】
本実施形態の車両は、複数のユーザ60が同乗できる乗合車両であり、ユーザ60が利用可能なユーザ用座席を複数有している。したがって、配車サーバ20は、ユーザ用座席の席数の範囲内(乗車可能人数以下のユーザ数)で、複数のユーザ60に同じ車両を配車することができる。
【0013】
配車サーバ20は、例えば、汎用コンピュータで構成することができる。配車サーバ20は、通信部21、経路探索部22、経路案内部23、表示部24及びネットワークデータ編集部25を備える。また、配車サーバ20は、探索用道路ネットワークデータベース(DB)部26、探索用交通ネットワークデータベース(DB)部27及び制御部28を備える。これらの各部21~28は、一般的な配車処理に利用することができる。
【0014】
一般的な配車処理では、ユーザ60から配車要求があると、配車可能な車両がその都度ユーザ60に配車される。
【0015】
配車サーバ20は、需要供給情報取得部31、需要判定部32、ユーザ位置取得部33、ユーザ共通経路抽出部34、ユーザ属性取得部35、優先利用ユーザ特定部36、乗車地設定部37及び属性情報データベース(DB)部38をさらに備える。これらの各部31~38は、ユーザ60からの配車の需要が所定の過剰状態であるときの配車処理のために配車サーバ20に追加した構成である。上述した各部21~28は、ユーザ60からの配車の需要が所定の過剰状態であるときの配車処理にも利用される。
【0016】
配車の需要が所定の過剰状態であるときの配車処理では、配車可能な車両が、運用効率を向上させることができるように配車される。車両の運用効率は、満席率としてのユーザ60の乗車率、ユーザ60を乗せて輸送している時間の割合である実車率を含むものとすることができる。
【0017】
通信部21は、通信ネットワーク40に接続してデータを送受信するインターフェースである。通信部21は、各車両のナビゲーション端末50から送信される運行データと経路探索要求データとを受信する。また、通信部21は、各ユーザ60の端末装置70から送信される、車両の配車を要求する各ユーザ60の予約データを受信する。
【0018】
ナビゲーション端末50からの運行データは、運行情報を含んでいる。運行情報は、例えば、車両の空車又は実車の状態と現在地とを含むものとすることができる。空車はユーザ60を乗せていない車両、実車はユーザ60を乗せている車両である。空車の車両はユーザ60に配車可能である。実車の車両は、乗せているユーザ60を目的地で下ろした後に、次のユーザ60に配車可能な状態となる。
【0019】
ナビゲーション端末50からの経路探索要求データは、経路探索要求情報を含んでいる。経路探索要求情報は、車両の乗務員がナビゲーション端末50に入力した目的地を含むものとすることができる。
【0020】
端末装置70からの予約データは、予約情報を含んでいる。予約情報は、例えば、ユーザ60を識別するためのユーザ名、ユーザ60の現在位置(以下、現在地という。)及び目的地、乗車人数、ユーザ60の属性等、予約に係る情報を含むものとすることができる。通信部21は、端末装置70から受信したユーザ60の予約データを、そのユーザ60に配車する車両のナビゲーション端末50に送信する。
【0021】
各データベース(以下、「データベース」を「DB」と略記することがある。)部26,27,38は、アクセス可能な記憶装置で構成することができる。記憶装置は、例えば、SSD(Solid State Drive )又はHDD(Hard Disk Drive )によって構成することができる。この記憶装置には、後述する仮予約データベースの記憶領域が設けられる。
【0022】
探索用道路ネットワークDB部26は、車両が走行可能な道路を、ノード及びノード間を接続するリンクの組合せとした、探索用道路ネットワークデータのDBを記憶している。探索用交通ネットワークDB部27は、鉄道、バス等の公共交通機関の路線及び駅(又はバス停)を、道路ネットワークと同じくノード及びノード間を接続するリンクの組合せとした、探索用交通ネットワークデータのDBを記憶している。
【0023】
属性情報DB部38は、通信部21が端末装置70から受信した予約データのうち、配車条件を承諾したユーザ60の予約データの予約情報における、ユーザ60の属性情報を記憶する。また、属性情報DB部38は、ユーザ60の属性情報のうち、配車の優先度を高くする優先情報の項目を定義したテーブルを記憶している。
【0024】
経路探索部22は、通信部21が端末装置70から受信した予約データの予約情報におけるユーザ60の現在地から目的地までの経路を探索する。経路探索部22は、通信部21がナビゲーション端末50から受信した運行データ及び経路探索要求データの運行情報及び経路探索要求情報における、車両の現在地から目的地までの経路を探索する。経路探索部22は、各DB部26,27のDBを参照し、参照したDBのネットワークデータをネットワークデータ編集部25で編集させて、経路を探索する。
【0025】
経路案内部23は、経路探索部22が探索した経路を表示部24に表示させ、あるいは、ナビゲーション端末50に向けて通信部21に送信させる。
【0026】
需要供給情報取得部31(運行情報取得部、予約情報取得部)は、配車可能な車両の供給量と車両の配車の需要量とに関する情報を取得する。供給量の情報は、通信部21が各車両のナビゲーション端末50から受信した運行データに含まれる運行情報の、配車の可否状態を示す空車又は実車の状態から取得することができる。需要量の情報は、通信部21が各ユーザ60の端末装置70から受信した予約データに含まれる予約情報から取得することができる。
【0027】
需要判定部32は、配車可能な車両の供給量に対する車両の配車の需要量が、所定の過剰状態であるか否かを判定する。配車の需要量が所定の過剰状態であるか否かは、例えば、数値化した供給量と需要量との比較に基づいて行うことができる。供給量は、例えば、需要供給情報取得部31が運行情報から取得した供給量の情報を用いて数値化することができる。需要量は、例えば、需要供給情報取得部31が予約情報から取得した需要量の情報を用いて数値化することができる。数値化した供給量と需要量とを比較することで、実際の需給状態に基づいて配車の需要量の過剰状態を判定することができる。
【0028】
数値化した供給量と需要量とを比較する際、供給量を、空車の車両の台数とし、需要量を、通信部21が予約データを受信したユーザ60からの配車要求の件数としてもよい。あるいは、供給量について、各車両の乗車可能人数を考慮した数値とし、需要量について、各ユーザ60の配車要求における乗車人数を考慮した数値としてもよい。
【0029】
需要判定部32(過剰判定部)は、数値化した供給量と需要量との比較に代えて、特定のイベントの発生の有無によって、需要量が供給量に対して所定の過剰状態であることを、推定により判定してもよい。特定のイベントは、例えば、配車可能な車両の供給量に対する車両の配車の需要量が大きく上回ることが予想される、鉄道、バス等の公共交通機関の最終便の終了後、トラブルによる不通等とすることができる。
【0030】
ユーザ位置取得部33は、通信部21が受信した予約データから、ユーザ60の現在地の情報を取得する。ユーザ共通経路抽出部34(グルーピング部)は、経路探索部22が現在地から目的地までの経路を探索したユーザ60の中から、経路に共通の区間を含んでいるユーザ60を抽出する。
【0031】
ユーザ共通経路抽出部34は、抽出したユーザ60を、ユーザ位置取得部33が取得した現在地が所定の広さの同じ領域内に存在するユーザ60毎にグループ分けする。所定の広さは、例えば、10メートル四方の面積とすることができる。ユーザ共通経路抽出部34は、各グループに、車両の乗車可能人数以下のユーザ数のユーザ60をグループ分けする。
【0032】
ユーザ属性取得部35は、ユーザ共通経路抽出部34がグループ分けしたグループ毎に、そのグループに属するユーザ60の属性情報を、そのユーザ60の端末装置70から通信部21が受信した予約データから取得する。
【0033】
優先利用ユーザ特定部36は、ユーザ属性取得部35が取得した属性情報中に、属性情報DB部38のテーブルに定義された優先情報があるユーザ60が、グループ内に存在する場合に、そのグループを優先利用ユーザとして特定する。
【0034】
また、ユーザ属性取得部35は、通信部21による予約データの受信(取得)からの経過時間が所定の基準時間以上に長いユーザ60が、グループ内に存在する場合に、そのグループを優先利用ユーザとして特定することができる。
【0035】
さらに、ユーザ属性取得部35は、ユーザ共通経路抽出部34が抽出した経路に含まれる共通の区間の距離又は乗車時間が長いグループを、優先利用ユーザとして特定することができる。
【0036】
なお、属性情報DB部38のテーブルにおいて、優先利用ユーザとする理由となった事項毎に優先順位の高低を定義してもよい。その場合は、特定の理由で優先利用ユーザとなったユーザ60又はグループに車両を配車する優先順位を、他の理由で優先利用ユーザとなったユーザ60又はグループよりも高くすることができる。
【0037】
乗車地設定部37は、ユーザ共通経路抽出部34がグループ分けした各グループを、配車候補のグループとし、配車候補のグループ毎に、配車可能な車両を配車しやすい場所を、配車候補地として設定する。乗車地設定部37は、配車候補のグループ毎に設定した配車候補地を記載した配車の仮受付メールを、通信部21から各グループのユーザ60の端末装置70に送信する。乗車地設定部37は、ユーザ60に送信する仮受付メールにおいて、同じグループの他のユーザ60についてユーザ位置取得部33が取得した位置を通知してもよい。
【0038】
制御部28(配車制御部)は、各DB部26,27,38を除く配車サーバ20の各部21~25,31~37の動作を制御する。
【0039】
通信ネットワーク40は、無線又は有線のいずれかの方式、あるいは両方の方式によって構成されてもよく、通信ネットワーク40には、インターネットが含まれてもよい。本実施形態では、配車サーバ20、ナビゲーション端末50及び端末装置70は、無線通信方式によって通信ネットワーク40と接続する。
【0040】
ナビゲーション端末50は、通信ネットワーク40を介して配車サーバ20と通信する通信部51を有する。ナビゲーション端末50は、CPU及びメモリを含むプロセッサを備える。メモリは、ROM及びRAMを含む。ナビゲーション端末50は、複数の情報処理回路として機能する。ナビゲーション端末50の情報処理回路機能は、ソフトウェアによって実現してもよく、専用のハードウェアによって実現してもよい。ナビゲーション端末50の情報処理回路は、位置検出部52及び経路探索要求編集部53を含む。
【0041】
ナビゲーション端末50は、案内データ記憶部54を有する。案内データ記憶部54は、アクセス可能な記憶装置で構成することができる。記憶装置は、例えば、SSD(Solid State Drive )又はHDD(Hard Disk Drive )によって構成することができる。ナビゲーション端末50は、操作・表示部55を有する。操作・表示部55は、タッチセンサ付きのディスプレイ、スイッチ類等で構成することができる。
【0042】
通信部51は、車両の運行情報を含む運行データを、通信ネットワーク40を介して配車サーバ20に送信する。運行情報に含まれる車両の空車又は実車の状態は、例えば、ナビゲーション端末50を搭載した車両又は車両に搭載された外部機器から取得することができる。運行情報に含まれる車両の現在地は、位置検出部52がGNSS(Global Navigation Satellite System/全球測位衛星システム)センサの出力を用いて検出する。GNSSセンサは、ナビゲーション端末50が有していてもよく、ナビゲーション端末50を搭載した車両が有していてもよい。
【0043】
通信部51は、ナビゲーション端末50を搭載した車両を配車するユーザ60の予約データを、配車サーバ20から受信する。通信部51は、車両の目的地を含む経路探索要求情報を、配車サーバ20に送信する。経路探索要求情報は、乗務員が操作・表示部55から入力した目的地に基づいて、経路探索要求編集部53で生成することができる。
【0044】
ナビゲーション端末50は、制御部56を有する。制御部56は、案内データ記憶部54を除くナビゲーション端末50の各部51~53,55の動作を制御する。
【0045】
端末装置70は、通信ネットワーク40を介して配車サーバ20と通信する。端末装置70は、ユーザが持ち運び可能な装置であって、例えば、スマートフォン、タブレット等で構成することができる。
【0046】
配車システム10では、車両の配車を要求するユーザ60が、端末装置70にインストールされたアプリケーションソフトウェア(以下、アプリという)を起動させて、車両の配車に必要な予約情報の入力を行うことができる。この場合は、端末装置70にネイティブアプリをインストールし、端末装置70内の演算装置に直接演算処理を行わせる。
【0047】
また、ネイティブアプリの代わりに、PWA(Progressive Web Apps)技術を利用し、インターネット上のクラウドサーバに構築したモバイル向けWebサイトを、端末装置70にインストールしたアプリのように使えるようにすることも可能である。この場合は、例えば、インターネット上のクラウドサーバに端末装置70がアクセスし、端末装置70において表示させたクラウドサーバのコンソール画面上で、車両の配車要求に必要な予約情報の入力を行ことができる。ここで言うクラウドサーバの機能は、配車サーバ20に持たせてもよく、配車サーバ20と連携する他のサーバ(図示せず)に持たせてもよい。
【0048】
以下の実施形態では、ネイティブアプリをインストールした端末装置70、あるいは、ネイティブアプリの代わりにPWA技術を利用した端末装置70が、配車サーバ20にアクセスする場合について説明する。
【0049】
ユーザ60の現在地は、例えば、住所等によって指定できる任意の場所でもよく、端末装置70がGNSS(Global Navigation Satellite System/全球測位衛星システム)センサを用いて検出した場所でもよい。ユーザ60の目的地は、例えば、住所等によって指定できる任意の場所でもよく、予め定められた選択肢からユーザ60が選択した目的地の最寄りの場所等でもよい。ユーザ60の属性は、例えば、ユーザ60の優先情報を含んでいてもよい。優先情報は、例えば、妊婦、障害者、高齢者、子供連れ、年齢等、車両の乗車要求度の高低を判断する材料となり得る情報とすることができる。
【0050】
以上の構成を有する本実施形態の配車システム10では、ユーザ60が端末装置70を用いて予約情報を入力すると、予約情報を含む予約データが、端末装置70から通信ネットワーク40を介して配車サーバ20に送信される。そして、配車サーバ20では、制御部28の制御により以下の処理が実行される。
【0051】
配車サーバ20は、端末装置70からの予約データを通信部21により受信する。
図2に示すように、配車サーバ20は、需要供給情報取得部31において、配車可能な車両の供給量と車両の配車の需要量とに関する情報を取得する(ステップS1)。配車サーバ20は、需要判定部32において、配車可能な車両の供給量に対する車両の配車の需要量が、所定の過剰状態であるか否かを判定する(ステップS3)。
【0052】
供給量に対する需要量が所定の過剰状態でない場合は(ステップS3でNO)、配車サーバ20は、通常時であるものとして、受信した予約データの予約情報による車両の配車予約を確定させる(ステップS5)。配車予約の確定により、配車サーバ20は、通信部21により、予約データの送信元の端末装置70に予約確定メールを送信する。
【0053】
また、配車サーバ20は、ユーザ60の現在地に配車可能な車両を配車処理し(ステップS7)、一連の処理を終了する。配車処理では、配車サーバ20は、配車する車両のナビゲーション端末50に、ユーザ60の予約データを送信する。配車された車両の乗務員は、配車サーバ20から受信した予約データの内容をナビゲーション端末50の操作・表示部55に表示させて、ユーザ60の現在地に車両を移動させることができる。
【0054】
供給量に対する需要量が所定の過剰状態である場合は(ステップS3でYES)、配車サーバ20は、通信部21により、受信した予約データの送信元の端末装置70に、需要過剰である非日常時の配車条件の承諾を求める確認メールを送信する。確認メールで承諾を求める配車条件は、例えば、車両を必ず配車することを保障できないこと、目的地が同じ方向の他のユーザ60と乗合になること、配車までの間、目的地に向けて徒歩移動してもらうこと等とすることができる。
【0055】
確認メールを送信した端末装置70から、非日常時の配車条件を承諾しないとの回答を受け取ると(ステップS11でNO)、配車サーバ20は、予約不可処理を行い(ステップS13)、一連の処理を終了する。予約不可処理では、配車サーバ20は、受信した予約データの予約情報による車両の配車予約を受け付けられないとの通知メールを、通信部21により予約データの送信元の端末装置70に送信する。
【0056】
確認メールを送信した端末装置70から、非日常時の配車条件を承諾するとの回答を受け取ると(ステップS11でYES)、配車サーバ20は、配車条件を承諾したユーザ60の予約データを仮予約データベースに登録する(ステップS15)。仮予約データベースは、配車サーバ20の記憶装置に設けられている。この登録により、仮予約データベースには、車両が配車されるまでの間、非日常時の配車条件を承諾したユーザ60の現在地、目的地等の最新情報が、仮予約データベースに登録される。
【0057】
配車サーバ20は、仮予約データベースに予約データが登録されたユーザ60を、現在地と目的地とに応じて、ユーザ位置取得部33及びユーザ共通経路抽出部34によりグループ分けする(ステップS17)。配車サーバ20は、各グループのユーザ60の予約情報に基づいて、車両の運用効率が向上する配車計画を導出する(ステップS19)。
【0058】
配車サーバ20は、目的地までの経路に共通の区間を含むユーザ60の人数(ユーザ数)が最も多いグループに、配車可能な車両を優先して配車することで、車両の乗車率を向上させることができる。ユーザ共通経路抽出部34は、1つのグループにグループ分けするユーザ60を、車両の乗車可能人数以下とすることで、1つのグループに2台以上の車両を配車する必要をなくし、車両の配車効率をよくすることができる。
【0059】
配車サーバ20は、グループ分けした各グループのユーザ60に、乗車地設定部37がグループ毎に設定した配車候補地を記載した配車の仮受付メールを、通信部21から各グループのユーザ60の端末装置70に送信する。
【0060】
配車サーバ20は、仮受付メールにおいて、配車候補のグループに属していることを通知し、さらに、同じグループの他のユーザ60の位置を通知することができる。この場合、仮受付メールにより、同じグループの他のユーザ60とグループ単位で徒歩移動することを要請することができる。よって、仮受付メールは、配車候補のグループとしてグループ単位の行動をユーザ60に要請する案内情報となる。
【0061】
仮受付メールには、配車候補地への道順を示す経路案内情報を記載することができる。経路案内情報を仮受付メールに記載することで、グループの各ユーザ60を確実に配車候補地に誘導することができる。
【0062】
配車サーバ20は、各車両のナビゲーション端末50から通信部21が受信する運行データにより、配車可能な車両(空車車両)が発生したか否かを確認する(ステップS23)。空車車両が発生していない場合は(ステップS23でNO)、ステップS17にリターンする。空車車両が発生した場合は(ステップS23でYES)、配車サーバ20は、優先利用ユーザ特定部36が特定した優先利用ユーザの中で優先順位が一番高いユーザ60が属するグループに配車処理する(ステップS25)。
【0063】
配車サーバ20は、特定のグループのユーザ60への配車を決定した場合、配車処理として、配車する車両を識別するための車両IDと、グループに属する各ユーザ60の端末装置70から受け取った予約データとを関連付ける。そして、配車サーバ20は、配車する車両のナビゲーション端末50に、グループ内の各ユーザ60の予約データを送信する。
【0064】
車両の不図示の乗務員は、配車サーバ20から受信したユーザ60の予約データの予約情報を、例えば、車両内のナビゲーション端末50における表示で確認することができる。確認した予約情報に基づいて、乗務員は、
図3に示すように、配車対象のグループのユーザ61,62の配車候補地80,90に車両100,110を移動させる。乗務員は、グループに属するユーザ61,62を配車候補地80,90で車両100,110に乗車させ、各ユーザ61,62に共通する経路を通って各ユーザ61,62を目的地まで輸送することができる。
【0065】
1つの配車サーバ20が配車を決定する車両100,110は2台に限定されない。配車システム10は、1台又は3台以上の車両の配車を1つの配車サーバ20で決定する構成としてもよい。
【0066】
本実施形態では、配車可能な車両100,110の供給量に対する配車の需要量が所定の過剰状態であると、配車サーバ20が、目的地までの経路に共通の区間を含むユーザ60が多くグループ分けされたグループに、車両100,110を優先して配車する。このため、配車された車両100,110の乗車率を高めて運用効率を向上させることができる。
【0067】
また、本実施形態では、配車サーバ20が、予約データの受信(取得)からの経過時間が長いユーザ60~62への配車を優先することで、予約データの送信後の徒歩移動距離が長いユーザ60~62に、車両100,110を優先して配車することができる。さらに、配車サーバ20が、ユーザ共通経路抽出部34が抽出した経路に含まれる共通の区間の距離又は乗車時間が長いグループへの配車を優先することで、ユーザ60~62に配車した車両100,110の実車率を向上させることができる。
【0068】
また、配車サーバ20が、属性情報中に優先情報があるユーザ60への配車を優先することで、妊婦、障害者、高齢者、子供連れ、年齢等、車両の乗車要求度の高いユーザ60~62に車両100,110を優先して配車することができる。
【0069】
また、配車サーバ20が、仮受付メールにおいて、グループ単位で徒歩移動することを要請することで、そのグループに車両100,110を配車する際に、グループの各ユーザ60を、全員揃って配車候補地80,90に移動させることができる。
【0070】
なお、上述の実施形態は本発明の一例である。このため、本発明は、上述の実施形態に限定されることはなく、この実施形態以外の形態であっても、本発明に係る技術的思想を逸脱しない範囲であれば、設計などに応じて種々の変更が可能であることは勿論である。
【符号の説明】
【0071】
10 配車システム
20 配車サーバ(配車装置)
28 制御部(配車制御部)
31 需要供給情報取得部(運行情報取得部、予約情報取得部)
32 需要判定部(過剰判定部)
34 ユーザ共通経路抽出部(グルーピング部)
60~62 ユーザ
70 端末装置(ユーザの端末)
80,90 配車候補地
100,110 車両