JP2023045937A - 配車管理システム、配車予約管理方法及びコンピュータプログラム - Google Patents

Abstract

【課題】予約に応じて車両を運行するデマンド型の配車管理システムにおいて、ユーザーが予約を行う際の利便性を向上させる配車管理システム、配車予約管理方法及びコンピュータプログラムを提供する。【解決手段】予約に応じて車両を運行するデマンド型の配車管理システム１において、管理サーバは、配車予定を示す配車予定情報を記憶する記憶部と、ユーザーから乗車予約要求を受け付ける受付部と、記憶部内の配車予定情報に基づいて、受付部によって受付けられた乗車予約要求に示される希望条件を満たす配車が可能であるか否かを判定し、希望条件を満たす配車が不可能である場合に、希望条件に対して所定の条件変更を行ってから、再度配車が可能であるか否かを判定し、配車が可能であると判定した配車の情報を前記ユーザーへ応答する配車処理部と、を備える。【選択図】図１

Description

本発明は、配車管理システム、配車予約管理方法及びコンピュータプログラムに関する。

複数のユーザーのデマンドを満たすよう乗合を実現するオンデマンド交通が知られている。オンデマンド交通は、利用者が事前に予約することで、予約に合わせて運行する乗合型の公共交通サービスである。
オンデマンド交通に関して、例えば特許文献１に記載された予約管理技術が知られている。この技術では、複数のユーザーが同じ車両便に乗車することを促すために、過去の乗車履歴から同乗する可能性のあるユーザーへ乗車予約の提案を行っている。予約を行うユーザー端末のインタフェースとしては、希望日時や乗車場所や降車場所等の予約情報を入力及び送信し、座席の予約に成功した場合、予約を確定し予約結果を表示するものが開示されている。

また非特許文献１には、オンデマンド交通において、自動運転車を用いる場合などに特に必要となる、非サービス中の車両を拠点にて待機させる運行を実現するため、拠点からの出発や帰着を考慮したトリップ単位に基づく配車技術が記載されている。

特許第６４３２２０５号公報

恋塚葵、大岸智彦、"自動運転車の利用を見据えたデマンド型交通配車方式の検討"、電子情報通信学会、２０２０年ソサイエティ大会講演論文集、B-15-11、２０２０年９月１日

しかし、上述した従来の技術では、ユーザーが乗車予約要求として出発地や目的地や希望時刻（希望出発時刻や希望到着時刻）等の希望条件を指定して配車検索を行った結果、当該希望条件を満たす配車が見つからなければ配車不可の結果がユーザーへ通知される。すると、ユーザーは、希望条件（例えば希望出発時刻）を再設定して再度配車検索を行う必要があった。さらには、ユーザーが希望条件を再設定して再度配車検索を行っても、当該希望条件を満たす配車が見つかるとは限らず、ユーザーの利便性が悪いという課題があった。

本発明は、このような事情を考慮してなされたものであり、その目的は、予約に応じて車両を運行するデマンド型の配車管理システムにおいて、ユーザーが予約を行う際の利便性を向上させることにある。

（１）本発明の一態様は、予約に応じて車両を運行するデマンド型の配車管理システムにおいて、配車予定を示す配車予定情報を記憶する記憶部と、ユーザーから乗車予約要求を受け付ける受付部と、前記記憶部内の配車予定情報に基づいて、前記受付部によって受付けられた乗車予約要求に示される希望条件を満たす配車が可能であるか否かを判定し、前記希望条件を満たす配車が不可能である場合に前記希望条件に対して所定の条件変更を行ってから再度、配車が可能であるか否かを判定し、配車が可能であると判定された配車の情報を前記ユーザーへ応答する配車処理部と、を備える配車管理システムである。
（２）本発明の一態様は、前記配車処理部は、前記希望条件を満たす配車が不可能である場合に、前記希望条件の希望出発時刻と希望到着時刻とのうち少なくとも一方を所定の時間幅でずらしてから再度、配車が可能であるか否かを判定する、上記（１）の配車管理システムである。
（３）本発明の一態様は、前記配車処理部は、前記希望条件を満たす配車が不可能である場合に、前記希望条件の相乗り拒否を相乗り許可に変更してから再度、配車が可能であるか否かを判定する、上記（１）又は（２）のいずれかの配車管理システムである。
（４）本発明の一態様は、前記配車処理部は、前記希望条件を満たす配車が不可能である場合において、前記希望条件の出発地が既存の配車の出発地から所定の距離以内にあるか、又は前記希望条件の目的地が既存の配車の目的地から所定の距離以内にあるときには、前記希望条件の出発地と目的地とのうち少なくとも一方を既存の配車と同じに変更してから再度、配車が可能であるか否かを判定する、上記（１）から（３）のいずれかの配車管理システムである。
（５）本発明の一態様は、前記配車処理部は、前記希望条件を満たす配車が不可能である場合において、既存の配車の乗車人数に前記希望条件の乗車人数を加算すると乗車定員超過であるときには、前記希望条件の乗車人数を減らしてから再度、配車が可能であるか否かを判定する、上記（１）から（４）のいずれかの配車管理システムである。
（６）本発明の一態様は、前記配車処理部は、前記希望条件とは異なる条件で配車が可能であると判定された複数の配車のうち、前記希望条件の希望出発時刻又は希望到着時刻の前後のそれぞれ直近の配車の情報を前記ユーザーへ応答する、上記（１）から（５）のいずれかの配車管理システムである。

（７）本発明の一態様は、予約に応じて車両を運行するデマンド型の配車管理システムが実行する配車予約管理方法であって、配車予定を示す配車予定情報を記憶部に記憶する記憶ステップと、ユーザーから乗車予約要求を受け付ける受付ステップと、前記記憶部内の配車予定情報に基づいて、前記受付ステップによって受付けられた乗車予約要求に示される希望条件を満たす配車が可能であるか否かを判定し、前記希望条件を満たす配車が不可能である場合に前記希望条件に対して所定の条件変更を行ってから再度、配車が可能であるか否かを判定し、配車が可能であると判定された配車の情報を前記ユーザーへ応答する配車処理ステップと、を含む配車予約管理方法である。

（８）本発明の一態様は、予約に応じて車両を運行するデマンド型の配車管理システムのコンピュータに、配車予定を示す配車予定情報を記憶部に記憶する記憶ステップと、ユーザーから乗車予約要求を受け付ける受付ステップと、前記記憶部内の配車予定情報に基づいて、前記受付ステップによって受付けられた乗車予約要求に示される希望条件を満たす配車が可能であるか否かを判定し、前記希望条件を満たす配車が不可能である場合に前記希望条件に対して所定の条件変更を行ってから再度、配車が可能であるか否かを判定し、配車が可能であると判定された配車の情報を前記ユーザーへ応答する配車処理ステップと、を実行させるためのコンピュータプログラムである。

本発明によれば、予約に応じて車両を運行するデマンド型の配車管理システムにおいて、ユーザーが予約を行う際の利便性を向上させることができるという効果が得られる。

一実施形態に係る配車管理システムの構成例を示すブロック図である。 一実施形態に係るトリップの例を説明するための図である。 一実施形態に係る配車判定方法の手順の一例を示すフローチャートである。 一実施形態に係る配車管理システムの動作の一例を示す図である。 一実施形態に係る配車判定方法の手順の一例を示すフローチャートである。 一実施形態に係る配車判定方法の手順の一例を示すフローチャートである。 一実施形態に係る配車管理システムの動作の一例を示す図である。 一実施形態に係る配車管理システムの動作の一例を示す図である。 一実施形態に係る配車管理システムの動作の一例を示す図である。 一実施形態に係るトリップ（配車）の出力例を示す図である。

以下、図面を参照し、本発明の実施形態について説明する。なお、下付き文字の例えば「ａ」を「＿ａ」と表記する場合がある。

図１は、一実施形態に係る配車管理システムの構成例を示すブロック図である。本実施形態に係る配車管理システム１は、デマンド型の交通管理システムである。デマンド型の交通管理システムは、ユーザーの予約に応じて車両が運行される。

本実施形態では、トリップ単位に基づく配車管理が行われる。トリップとは、車両が拠点出発時刻に拠点を出発し、一又は複数のデマンドの経由地（出発地（乗車場所）または目的地（降車場所））を通り、拠点帰着時刻に拠点に帰着するまでの一車両の一連の運行を言う。

配車管理システム１は、端末装置２０－１と、端末装置２０－２と、端末装置２０－３と、車載器３０と、管理サーバ１００とを備える。端末装置２０－１と、端末装置２０－２と、端末装置２０－３と、車載器３０と、管理サーバ１００とは、ネットワークＮＷを介して接続される。ネットワークＮＷは、無線または有線による通信網である。このネットワークＮＷには、インターネットやイントラネットなどが含まれる。具体的には、ネットワークＮＷは、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）などによって構成される情報通信ネットワークである。このＷＡＮには、例えば、携帯電話網、ＰＨＳ（Personal Handy-phone System）網、ＰＳＴＮ（Public Switched Telephone Network；公衆交換電話網）、専用通信回線網、およびＶＰＮ（Virtual Private Network）などが含まれる。

端末装置２０－１は、ユーザーが使用する。ユーザーは、端末装置２０－１に対して車両を予約する操作を行う。ユーザーは、車両を予約する際に、希望条件を指定する。希望条件として、出発地（乗車場所）、目的地（降車場所）、希望時刻（出発地を出発する希望時刻（希望出発時刻）や目的地に到着する希望時刻（希望到着時刻））、乗車人数、相乗りの可否などがある。端末装置２０－１は、ユーザーの操作に基づいて、乗車予約情報（デマンド）を含む、管理サーバ１００を宛先とする乗車予約要求を作成する。乗車予約情報は、ユーザーの希望条件を示す情報を含む。端末装置２０－１は、作成した乗車予約要求を管理サーバ１００へ送信する。

管理サーバ１００は、端末装置２０－１が送信した乗車予約要求を受信する。管理サーバ１００は、車両を待機させる拠点の位置情報を記憶している。管理サーバ１００は、受信した乗車予約要求に含まれる乗車予約情報を取得し、取得した乗車予約情報と、記憶している拠点の位置情報とに基づいて、第１拠点から、乗車場所と降車場所とを経由して、第１拠点または第２拠点までの経路を検索する。

管理サーバ１００は、経路の検索結果に基づいて、第１拠点を第１時刻に出発し、乗車場所と降車場所とを経由して第２時刻に第１拠点又は第２拠点に帰着するまでの車両の新規運行スケジュールを作成する。管理サーバ１００は、作成した新規運行スケジュールと一又は複数の車両の各々の既存運行スケジュールとに基づいて、ユーザーの希望条件を満たす新規運行スケジュールの運行が可能であるか否かを判定する。このとき、管理サーバ１００は、ユーザーの希望条件を満たす新規運行スケジュールの運行が不可能であると判定した場合には、当該希望条件に対して所定の条件変更を行ってから再度、新規運行スケジュールの運行が可能であるか否かを判定する。

管理サーバ１００は、新規運行スケジュールの運行が可能であると判定した場合には、新規運行スケジュールを含む端末装置２０－１を宛先とする、乗車予約応答を作成する。管理サーバ１００は、作成した乗車予約応答を端末装置２０－１へ送信する。端末装置２０－１は、管理サーバ１００が送信した乗車予約応答を受信し、受信した乗車予約応答に含まれる新規運行スケジュールを表示する。管理サーバ１００は、当該乗車予約応答に対して端末装置２０－１から新規運行スケジュールの確定を受信すると、当該新規運行スケジュールを確定した新規運行スケジュール（既存運行スケジュール）として記録する。

また、管理サーバ１００は、確定した新規運行スケジュールを含む車載器３０を宛先とする、配車要求を作成する。管理サーバ１００は、作成した配車要求を車載器３０へ送信する。車載器３０は、管理サーバ１００が送信した配車要求を受信する。車載器３０は、車載器３０が搭載された車両ＶＥが手動で運転する車両である場合には、受信した配車要求に含まれる新規運行スケジュールを表示する。車載器３０は、車載器３０が搭載された車両ＶＥが自動運転車である場合には、受信した配車要求に含まれる新規運行スケジュールを車両ＶＥの自動運転システムに出力する。

以下、配車管理システム１に含まれる端末装置２０－１と、端末装置２０－２と、端末装置２０－３と、車載器３０と、管理サーバ１００とについて順次説明する。

（端末装置）
端末装置２０－１、端末装置２０－２、端末装置２０－３は、例えば、パーソナルコンピュータ、携帯電話、タブレット、スマートフォン、ＰＨＳ（Personal Handy-phone System）またはＰＤＡ（Personal Digital Assistant）などによって実現される。

端末装置２０－１は、ユーザーが携帯している携帯機器である。ユーザーは、端末装置２０－１を使用して、乗車を予約する。端末装置２０－１には、乗車予約アプリがインストールされている。乗車予約アプリは、端末装置２０－１にユーザーの操作に基づいて、乗車予約情報を作成させる。

乗車予約には、即時予約と事前予約とが含まれる。即時予約は、今すぐ乗車を希望する場合であり、乗車場所や降車場所などが指定される。乗車場所を特定する情報と降車場所を特定する情報との一例は、地名、場所を示す何らかの情報である。即時予約が行われた場合、乗車予約情報には、乗車場所、降車場所、乗車人数、相乗りの可否などを特定する情報が含まれる。

一方、事前予約は、乗車時刻や降車時刻を希望する場合であり、乗車場所や降車場所や希望出発時刻や希望降車時刻などが指定される。事前予約が行われた場合、乗車予約情報には、乗車場所、降車場所、希望時刻（希望出発時刻や希望到着時刻）、乗車人数、相乗りの可否などを特定する情報が含まれる。

乗車予約アプリは、端末装置２０－１に乗車予約情報を含む、管理サーバ１００を宛先とする乗車予約要求を作成させる。乗車予約アプリは、端末装置２０－１に作成させた乗車予約要求を管理サーバ１００へ送信させる。乗車予約アプリは、端末装置２０－１に管理サーバ１００が送信した乗車予約応答を受信させ、受信した乗車予約応答に含まれる乗車予約情報を処理させる。

端末装置２０－２は、例えば車両の運転席に座る者が利用する機器である。例えば、端末装置２０－２は、カーナビのように運転席に固定されていてもよい。車両の運転席に座る者の一例は、運転手である。ただし、車両が自動運転車の場合は車掌が端末装置２０－２を利用してもよい。端末装置２０－２には、運行アプリがインストールされている。運行アプリは、端末装置２０－２に、管理サーバ１００が送信するユーザーの乗車場所を特定する情報、降車場所を特定する情報、経路情報などの車両の運行に関する情報を受信させる。運行アプリは、端末装置２０－２に、受信させた車両の運行に関する情報に基づいて、表示部に表示させている地図上に乗車場所、降車場所、経路情報を表示させる。

運行アプリは、端末装置２０－２に、車両の運行に関する処理を行わせる。運行アプリは、端末装置２０－２において、表示部に表示させている地図上の乗車場所、降車場所に該当する箇所が押された場合に、押された時刻を示す情報と押された箇所に該当する乗車場所又は降車場所を示す情報とを含む、管理サーバ１００を宛先とする運行情報を作成させる。運行アプリは、端末装置２０－２に、作成させた運行情報を管理サーバ１００へ送信させる。

端末装置２０－３は、車両に乗車する者が利用する機器である。例えば、端末装置２０－３は、カーナビのように運転席に固定されていてもよい。端末装置２０－３は、普段スマートフォンやタブレットを携帯しないユーザーに利用させてもよい。端末装置２０－３には、運行状況通知管理アプリがインストールされている。運行状況通知アプリは、端末装置２０－３に、管理サーバ１００が送信するユーザーの乗車情報、降車情報、経路情報を受信させる。運行状況通知アプリは、端末装置２０－３に、受信させたユーザーの乗車情報、降車情報、経路情報に基づいて、表示部に表示させている地図上に乗降場所と経路情報とを表示させる。ただし、端末装置２０－３が利用される環境によっては、プライバシーに配慮して、端末装置２０－３に表示される内容が制限されてもよい。

（車載器）
車載器３０は、車両ＶＥに搭載される。車載器３０には、車載アプリがインストールされている。車載アプリは、車両ＶＥ内で動作するソフトウェアである。車載アプリは、車載器３０に車両ＶＥの位置情報、ＣＡＮ（Controller Area Network）データを管理サーバ１００へ送信させる。車載器３０は、搭載されている車両ＶＥが自動運転車の場合にはその車両ＶＥの自動運転システムと連携する。この場合、車載アプリは、車載器３０に管理サーバ１００が送信した経路情報を受信させ、受信させた経路情報を、自動運転システムへ出力する。

（管理サーバ）
管理サーバ１００は、通信部１０２と、受付部１０４と、配車処理部１０６と、経路検索部１０８と、記憶部１１０とを備える。

管理サーバ１００の各機能は、管理サーバ１００がＣＰＵ（Central Processing Unit：中央演算処理装置）及びメモリ等のコンピュータハードウェアを備え、ＣＰＵがメモリに格納されたコンピュータプログラムを実行することにより実現される。なお、管理サーバ１００として、汎用のコンピュータ装置を使用して構成してもよく、又は、専用のハードウェア装置として構成してもよい。例えば、管理サーバ１００は、パーソナルコンピュータ、サーバー、又は産業用コンピュータ等の装置によって実現されてもよい。例えば、管理サーバ１００は、インターネット等の通信ネットワークに接続されるサーバコンピュータを使用して構成されてもよい。また、管理サーバ１００の各機能はクラウドコンピューティングにより実現されてもよい。また、管理サーバ１００は、単独のコンピュータにより実現するものであってもよく、又は管理サーバ１００の機能を複数のコンピュータに分散させて実現するものであってもよい。また、管理サーバ１００として、例えばＷＷＷシステム等を利用してウェブサイトを開設するように構成してもよい。

通信部１０２は、通信モジュールによって実現される。通信部１０２は、ネットワークＮＷを経由して、端末装置２０－１、端末装置２０－２、端末装置２０－３、車載器３０などの他の装置と通信を行う。通信部１０２は、端末装置２０－１が送信した乗車予約要求を受信する。また、通信部１０２は、配車処理部１０６が出力した乗車予約応答を、端末装置２０－１へ送信する。通信部１０２は、配車処理部１０６が出力した配車要求を、車載器３０へ送信する。

記憶部１１０は、例えば、ＲＡＭ、ＲＯＭ、ＨＤＤ、フラッシュメモリ、又はこれらのうち複数が組み合わされたハイブリッド型記憶装置などにより実現される。記憶部１１０には、管理サーバ１００により実行されるプログラム（配車管理アプリ）が記憶される。また、記憶部１１０には、車両を待機させる拠点の識別情報（以下「拠点ＩＤ」という）と、拠点の位置情報とが関連付けて記憶される。また、記憶部１１０には、管理サーバ１００が車両の配車を行うために必要な様々なデータを保管する。例えば、記憶部１１０は、車両の配車を行うために必要なデータとして、デマンド情報１１０ａと、車両情報１１０ｂと、ユーザー情報１１０ｃとを記憶する。

デマンド情報１１０ａは、ユーザーの識別情報（以下「ユーザーＩＤ」という）とユーザーの端末装置２０－１が送信した乗車予約要求に含まれる乗車予約情報と乗車予約の処理状態とを関連付けたデマンド関連情報を一又は複数有する。

車両情報１１０ｂは、車両の識別情報（以下「車両ＩＤ」という）と、車両の運行スケジュールを示す情報と、車両の収容人数を示す情報と、相乗りの可否を示す情報と、例えば、拠点ＩＤなどの待機場所の拠点を示す情報と、休憩時間情報と、車掌情報と、現在地情報と、状態情報とを関連付けた車両関連情報を一又は複数有する。
本実施形態において、車両情報１１０ｂは、各車両の配車予定を示す配車予定情報に対応する。配車予定情報は、新規の配車が可能か否かを判断するための情報であって、既存運行スケジュールや収容人数や相乗りの可否などを含む情報である。

ユーザー情報１１０ｃは、ユーザーの氏名を示す情報と、ユーザーの性別を示す情報と、ユーザーの年代を示す情報と、ユーザーの状態を示す情報とを関連付けたユーザー関連情報を一又は複数有する。

受付部１０４は、通信部１０２が受信した乗車予約要求を受け付け、受け付けた乗車予約要求に含まれる乗車予約情報を取得する。配車処理部１０６は、受付部１０４が取得した乗車予約情報に基づいて、記憶部１１０に記憶されているデマンド情報１１０ａを更新する。

配車処理部１０６は、車両情報１１０ｂに基づいて、乗車予約情報に示されるユーザーの希望条件を満たす配車が可能であるか否かを判定する。このとき、配車処理部１０６は、ユーザーの希望条件を満たす配車が不可能であると判定した場合には、当該希望条件に対して所定の条件変更を行ってから再度、配車が可能であるか否かを判定する。

配車処理部１０６は、運行中のデマンドがない車両は指定された拠点にて待機することを前提として処理する。配車処理部１０６は、トリップ単位で運行管理を行う。ここで、トリップについて説明する。

図２は、一車両におけるトリップの例を説明するための図である。乗車予約情報（デマンド）に含まれる乗車場所（出発地）をＯ（Ｏｒｉｇｉｎ）とし、降車場所（目的地）をＤ（Ｄｅｓｔｉｎａｔｉｏｎ）とする。乗車場所（出発地）への車両到着時刻をｔ＿Ｏとし、目的地への車両到着時刻をｔ＿Ｄとする。拠点を出発する時刻をｔ＿ＢＳとし、拠点に帰着する時刻をｔ＿ＢＧとする。このように車両が時刻ｔ＿ＢＳに拠点を出発し、各デマンドの経由地（乗車場所、降車場所）を通り、時刻ｔ＿ＢＧに拠点に帰着するまでの一連の運行をトリップと呼ぶ。

図２の例では、トリップ１とトリップ２とが示されている。図２に示されるように、一車両に対して一日の運行時間中に複数のトリップが形成される場合がある。トリップ１は、車両が時刻ｔ＿ＢＳ１に拠点ＢＳ１を出発し、時刻ｔ＿Ｏ１に乗車場所Ｏ１に到着し、時刻ｔ＿Ｄ１に降車場所Ｄ１に到着し、時刻ｔ＿ＢＧ１に拠点ＢＧ１に帰着するまでの一連の運行である。トリップ２は、車両が時刻ｔ＿ＢＧ１よりも遅い時刻である時刻ｔ＿ＢＳ２に拠点ＢＧ２を出発し、時刻ｔ＿Ｏ２に乗車場所Ｏ２に到着し、時刻ｔ＿Ｏ３に乗車場所Ｏ３に到着し、時刻ｔ＿Ｄ２に降車場所Ｄ２に到着し、時刻ｔ＿Ｄ３に降車場所Ｄ３に到着し、時刻ｔ＿ＢＧ２に拠点ＢＧ２に帰着するまでの一連の運行である。

配車処理部１０６は、乗車予約情報に含まれる乗車場所を特定する情報と降車場所を特定する情報とを経路検索部１０８へ出力する。

経路検索部１０８は、配車処理部１０６が出力した乗車場所を特定する情報と降車場所を特定する情報とを取得する。経路検索部１０８は、記憶部１１０に記憶されている車両を待機させる拠点の拠点ＩＤと、拠点の位置情報とを関連付けた情報とを取得する。経路検索部１０８は、取得した乗車場所を特定する情報と降車場所を特定する情報と、車両を待機させる拠点ＩＤと、拠点の位置情報とを関連付けた情報とに基づいて、乗車場所へ配車する車両が待機している拠点の拠点ＩＤと、その車両が降車場所の後に向かう拠点の拠点ＩＤとを選択する。乗車場所へ配車する車両が待機している拠点と降車場所の後に向かう拠点とは同じであってもよいし、異なってもよい。以下、乗車場所へ配車する車両が待機している拠点として第１拠点が選択され、降車場所の後に向かう拠点として第２拠点が選択された場合について説明を続ける。ここで、第１拠点と、第２拠点とは、記憶部１１０に記憶されている。

経路検索部１０８は、取得した乗車場所を特定する情報と降車場所を特定する情報と、車両を待機させる第１拠点の拠点ＩＤと、第１拠点の位置情報とを関連付けた情報とに基づいて、第１拠点から、乗車場所と降車場所とを経由して、第２拠点へ向かう経路（ルート）を検索し、その経路で第１拠点から、乗車場所と降車場所とを経由して、第２拠点へ向かった場合に要する時間を導出する。

例えば、経路検索部１０８は、第１拠点から、乗車場所と降車場所とを経由して、第２拠点へ最短距離で巡回する経路を検索し、その経路で第１拠点から、乗車場所と降車場所とを経由して、第２拠点へ向かった場合に要する時間を導出する。例えば、経路検索部１０８は、第１拠点から乗車場所へ向かった場合に要する時間と、乗車場所から降車場所へ向かった場合に要する時間と、降車場所から第２拠点へ向かった場合に要する時間を導出する。経路検索部１０８は、経路を検索した結果を示す情報と要する時間を導出した結果を示す情報とを配車処理部１０６へ出力する。

配車処理部１０６は、経路検索部１０８が出力した経路を検索した結果を示す情報と要する時間を導出した結果を示す情報とを取得する。配車処理部１０６は、取得した経路を検索した結果を示す情報と要する時間を導出した結果を示す情報等に基づいて、配車が可能であるか否かを判定する。

図３を参照して本実施形態に係る配車判定方法を説明する。図３は、本実施形態に係る配車判定方法の手順の一例を示すフローチャートである。

配車処理部１０６は、全車両のそれぞれに対して、図３の処理を実行する。

（ステップＳ１） 配車処理部１０６は、新規デマンド単体でトリップの形成が可能であるかを判定する。具体的には、配車処理部１０６は、新規デマンド単体で形成したトリップを想定したときに、新規デマンド単体で形成したトリップが時系列的に既存トリップと重複する部分がないかを判定する。配車処理部１０６は、時系列的に既存のトリップと重複する部分がないと判定した場合に、新規のデマンド単体でトリップの形成が可能であると判定する。
以下、配車処理部１０６が時系列的に既存のトリップと重複する部分がないかを判定する処理について説明する。

図４は、本実施形態に係る配車管理システムの動作の一例を示す図である。図４は、トリップの一例を示す。図４に示されるトリップは、車両は時刻ｔ＿Ｏ１ｍｉｎから時刻ｔ＿Ｏ１ｍａｘの間に乗車場所Ｏ１に到着し、時刻ｔ＿Ｏ１ｍａｘに乗車場所Ｏ１を出発しなければならないとする。また、車両は時刻ｔ＿Ｄ１ｍｉｎから時刻ｔ＿Ｄ１ｍａｘの間に降車場所Ｄ１に到着しなければならないとする。ＴＷは、乗車場所を出発する時刻と出発する時刻から所定の時間前の時刻との間の時間である。ＴＷをデマンドの乗車場所（出発地）にて待機可能な時間と定義する。ＴＲは、降車場所への到着を保証する時刻（追加遅延があっても遅くともこの時刻には到着する）とその時刻から所定の時間前の時刻との間の時間である。ＴＲは、今後追加挿入されると想定されるトリップによる遅延を吸収するための時間であり、到着までのゆとり時間と定義する。式（１）と、式（２）とが成り立つ。
ｔ＿Ｏ１ｍａｘ－ｔ＿Ｏ１ｍｉｎ＝ＴＷ （１）
ｔ＿Ｄ１ｍａｘ－ｔ＿Ｄ１ｍｉｎ＝ＴＲ （２）
式（１）から条件ｔ＿Ｏ１の制約条件はｔ＿Ｏ１ｍｉｎ≦ｔ＿Ｏ１≦ｔ＿Ｏ１ｍａｘとなる。式（２）からｔ＿Ｄ１の制約条件はｔ＿Ｄ１ｍｉｎ≦ｔ＿Ｄ１≦ｔ＿Ｄ１ｍａｘとなる。

図５に、ステップＳ１の処理の手順の一例を示す。図５を参照してステップＳ１の処理を説明する。

（ステップＳ１０１） 配車処理部１０６は、車両情報１１０ｂに基づいて、出発拠点（ＢＳ）及び到着拠点（ＢＧ）を決定する。

（ステップＳ１０２） 配車処理部１０６は、新規デマンド単体でトリップを形成したときの各時刻（ｔ＿ＢＳ、ｔ＿Ｏ１、ｔ＿Ｄ１、ｔ＿ＢＧ）を算出する。この各時刻の算出方法は、即時予約の場合と事前予約の場合とで異なる。

（即時予約の場合）
即時予約の場合、車両が最短で拠点を出発可能な時刻をｔ＿ＢＳとし、残りのｔ＿Ｏ１、ｔ＿Ｄ１、ｔ＿ＢＧは、経路検索部１０８が出力した各地点間の移動時間をｔ＿ＢＳに順次加算していくことでトリップを形成する。このとき、配車処理部１０６は、ｔ＿Ｏ１ｍａｘをこの時点のｔ＿Ｏ１とし、ｔ＿Ｄ１ｍｉｎをこの時点のｔ＿Ｄ１とする。
なお、即時予約の場合、トリップ生成時において、拠点出発時刻ｔ＿ＢＳは、予約確定想定時刻「現在時刻＋配車確定猶予時間」よりも後の時刻にする。この即時予約における拠点出発時刻の制約条件は、車両が予定時刻通りに拠点を出発するために必要な条件である。

（事前予約の場合）
事前予約の場合、新規デマンド単体でのトリップの形成ができるか否かに関して、希望出発時刻が指定された場合と、希望到着時刻が指定された場合とに分けて説明する。
希望出発時刻が指定された場合、配車処理部１０６は、希望出発時刻をｔ＿Ｏ１とし、時刻ｔ＿Ｏ１に乗車地点Ｏ１に到着するための拠点の出発時刻をｔ＿ＢＳとする。残りの時刻ｔ＿Ｄ１、ｔ＿ＢＧは即時予約の場合と同様に、経路検索部１０８が出力した各地点間の移動時間を時刻ｔ＿ＢＳに順次加算していくことでトリップを形成する。
希望到着時刻が指定された場合、配車処理部１０６は、希望到着時刻をｔ＿Ｄ１ｍａｘとし、到着時刻ｔ＿Ｄ１ｍａｘによって定まるｔ＿Ｄ１ｍｉｎの時刻をｔ＿Ｄ１とする。残りの時刻ｔ＿ＢＳ、ｔ＿Ｏ１、ｔ＿ＢＧは即時予約の場合と同様に、経路検索部１０８が出力した各地点間の移動時間を時刻ｔ＿Ｄ１から順に減算していくことでトリップを形成する。

以上から、即時予約が指定された場合と事前予約が指定された場合とのいずれの場合も、新規デマンド単体でのトリップ形成は図４の時系列関係で表されることが分かる。

（ステップＳ１０３） 配車処理部１０６は、形成された新規デマンド単体トリップが制約条件一覧を全て満たすかを判定する。

制約条件一覧を以下に示す。

（制約条件ａ）
既存トリップの時間帯と重複していないこと。配車処理部１０６は、新規デマンド単体トリップのｔ＿ＢＳ～ｔ＿ＢＧの時間帯が既存トリップの時間帯と重複していないことを判定する。

（制約条件ｂ）
車両の運行時間外の時間帯や休憩時間と重複していないこと。配車処理部１０６は、新規デマンド単体トリップのｔ＿ＢＳ～ｔ＿ＢＧの時間帯が車両の運行時間外の時間帯や休憩時間と重複していないことを判定する。

（制約条件ｃ）
車両の乗車定員を超過していないこと。配車処理部１０６は、車両毎に定められている乗車定員を超過した乗車を行うトリップではないことを判定する。

（制約条件ｄ）
相乗り拒否の要求が含まれたデマンドのトリップである場合、相乗り拒否の設定が行われていること。配車処理部１０６は、相乗り拒否の要求が含まれたデマンドのトリップである場合に、当該デマンドの乗車人数が乗車定員未満であっても乗車定員分の乗車人数に設定することで、相乗り拒否を実現する。

（制約条件ｅ）
車両が拠点で待機している時間（拠点待機時間）が所定時間確保されていること。配車処理部１０６は、拠点待機時間が所定時間確保されていることを判定する。なお、この制約条件ｅはオプションであり必須ではない。

（ステップＳ１０４） 配車処理部１０６は、制約条件一覧が全て満たされる場合、新規デマンド単体トリップでの配車が可能であると判定する。

（ステップＳ１０５） 配車処理部１０６は、制約条件一覧の制約条件が一つでも満たされない場合、新規デマンド単体トリップでの配車が不可能であると判定する。

説明を図３に戻す。
ステップＳ１の結果、新規デマンド単体トリップでの配車が可能である場合（ステップＳ１、ＹＥＳ）、ステップＳ５に進む。一方、新規デマンド単体トリップでの配車が不可能である場合（ステップＳ１、ＮＯ）、ステップＳ２に進む。

（ステップＳ２） 配車処理部１０６は、ステップＳ１で仮生成した新規デマンド単体トリップと時系列的に重複する既存トリップが存在するかを判定する。この判定の結果、該当する既存トリップが存在する場合（ステップＳ２、ＹＥＳ）、ステップＳ３に進む。一方、該当する既存トリップが存在しない場合（ステップＳ２、ＮＯ）、ステップＳ６に進む。

（ステップＳ３） 配車処理部１０６は、ステップＳ１で仮生成した新規デマンド単体トリップのデマンドについて、当該新規デマンド単体トリップと時系列的に重複する既存トリップへ新規デマンド挿入が可能かを判定する。

図６に、ステップＳ３の処理の手順の一例を示す。図６を参照してステップＳ３の処理を説明する。

（ステップＳ２０１） 配車処理部１０６は、既存トリップへの新規デマンドの挿入を逐次最適挿入法の考え方に基づいて、既存デマンドの順序を変えずに新規デマンドの挿入場所を決定する。ここでの一例として、既存トリップ内に「Ｎ―１」個の既存デマンドがあり、新たにＮ番目のデマンドを挿入する場合について説明を続ける。

（ステップＳ２０２） 配車処理部１０６は、既存トリップの出発拠点ＢＳの出発時刻ｔ＿ＢＳを基準にして、Ｎ番目のデマンドの乗車場所（出発地）Ｏ＿Ｎと降車場所（目的地）Ｄ＿Ｎとを新たな経由地として挿入する場合の各時刻を算出する。

ここで、Ｎ番目のデマンドの乗車場所（出発地）Ｏ＿Ｎと降車場所（目的地）Ｄ＿Ｎとを新たな経由地として挿入する場合の各時刻の算出について、即時予約の場合と、事前予約において希望出発時刻が指定された場合と、事前予約において希望到着時刻が指定された場合との３通りに分けて説明する。但し、各経由地の出発時刻は以下のように定める。
出発拠点：ｔ＿ＢＳ
出発地：ｔ＿Ｏ＜ｔ＿Ｏｍａｘのときは、ｔ＿Ｏｍａｘ
ｔ＿Ｏｍａｘ＜＝ｔ＿Ｏのときは、ｔ＿Ｏ
目的地：ｔ＿Ｄ

（即時予約の場合）
図７を参照して即時予約の場合を説明する。配車処理部１０６は、ｔ＿ＯＮを乗車場所Ｏ＿Ｎの一つ前の経由地の出発時刻に移動時間を加算して算出し、ｔ＿ＤＮを降車場所Ｄ＿Ｎの一つ前の経由地の出発時刻に移動時間を加算して算出する。配車処理部１０６は、ｔ＿ＯＮｍａｘをこの時点のｔ＿ＯＮとし、ｔ＿ＤＮｍｉｎをこの時点のｔ＿ＤＮと定める。

（事前予約において希望出発時刻が指定された場合）
図８を参照して事前予約において希望出発時刻が指定された場合を説明する。配車処理部１０６は、希望出発時刻をｔ＿ＯＮｍａｘに設定する。配車処理部１０６は、ｔ＿ＯＮを乗車場所Ｏ＿Ｎの一つ前の経由地の出発時刻に移動時間を加算して算出し、ｔ＿ＤＮを降車場所Ｄ＿Ｎの一つ前の経由地の出発時刻に移動時間を加算して算出する。

（事前予約において希望到着時刻が指定された場合）
図９を参照して事前予約において希望到着時刻が指定された場合を説明する。配車処理部１０６は、希望到着時刻をｔ＿ＤＮｍａｘに設定する。配車処理部１０６は、ｔ＿ＯＮを乗車場所Ｏ＿Ｎの一つ前の経由地の出発時刻に移動時間を加算して算出し、ｔ＿ＤＮを降車場所Ｄ＿Ｎの一つ前の経由地の出発時刻に移動時間を加算して算出する。

（ステップＳ２０３） 配車処理部１０６は、出発拠点ＢＳと最初の経由地との間への新規デマンド挿入（乗車場所Ｏ＿Ｎ及び降車場所Ｄ＿Ｎの挿入）があるかを確認する。この確認の結果、出発拠点ＢＳと最初の経由地との間への新規デマンド挿入がある場合にはステップＳ２０７へ進み、そうではない場合にはステップＳ２０４へ進む。

（ステップＳ２０４） 配車処理部１０６は、既存トリップへの新規デマンド挿入により制約条件一覧を全て満たすかを判定する。この判定の結果、制約条件一覧が全て満たされる場合にはステップＳ２０５へ進み、そうではない場合にはステップＳ２０６へ進む。

（ステップＳ２０５） 配車処理部１０６は、制約条件一覧が全て満たされる場合、既存トリップへ新規デマンド挿入を行った結果のトリップを出力する。

（ステップＳ２０６） 新規デマンドの挿入場所が他にある場合にはステップＳ２０１へ戻り、そうではない場合には図６の処理を終了する。

（ステップＳ２０７） 配車処理部１０６は、出発拠点ＢＳと最初の経由地との間への新規デマンド挿入がある場合、拠点出発時刻ｔ＿ＢＳを所定の時間幅Ｔｓｈｉｆｔだけ早めて各時刻を再度算出する。

（ステップＳ２０８） 配車処理部１０６は、制約条件一覧を全て満たすかを判定する。この判定の結果、制約条件一覧が全て満たされる場合にはステップＳ２０５へ進み、そうではない場合にはステップＳ２０９へ進む。

（ステップＳ２０９） 配車処理部１０６は、ステップＳ２０７－Ｓ２０８の繰り返し回数が所定値Ｍ＿ｓｈｉｆｔ以下であるか判定する。この判定の結果、所定値Ｍ＿ｓｈｉｆｔ以下である場合にはステップＳ２０７へ戻る。一方、所定値Ｍ＿ｓｈｉｆｔ超過である場合にはステップＳ２０６へ進む。これにより、配車処理部１０６は、制約条件一覧が全て満たされるトリップが見つかるまで、時間幅Ｔｓｈｉｆｔだけ拠点出発時刻ｔ＿ＢＳを早めて各時刻を算出する操作を最大Ｍ＿ｓｈｉｆｔ回実行する。

説明を図３に戻す。
ステップＳ３の結果、ステップＳ１で仮生成した新規デマンド単体トリップのデマンドについて、当該新規デマンド単体トリップと時系列的に重複する既存トリップへ新規デマンド挿入が可能である場合には（ステップＳ３、ＹＥＳ）ステップＳ４に進み、そうではない場合には（ステップＳ３、ＮＯ）ステップＳ８に進む。

（ステップＳ４） 配車処理部１０６は、ステップＳ３（ステップＳ２０５）で出力されたトリップ（配車）の中から、最小遅延コストであるトリップ（配車）を選定する。遅延コストの算出方法の一例を以下に示す。

（即時予約の場合）
遅延コスト＝「新規デマンドの到着時刻」－「現在時刻」＋「既存デマンドの追加遅延の総和」

（事前予約の場合）
遅延コスト＝「新規デマンドの到着時刻」－「新規デマンドの出発時刻」＋「既存デマンドの追加遅延の総和」

但し、既存デマンドの追加遅延とは、既存トリップへの新規デマンド挿入によって新たに生じる既存デマンドの遅延のことを指す。

（ステップＳ５） 配車処理部１０６は、ステップＳ４で決定されたトリップを通常トリップとして出力する。この後、図３の処理を終了する。通常トリップとは、ユーザーの希望時刻（希望出発時刻や希望到着時刻）を変えずに制約条件一覧を全て満たしたトリップのことである。したがって、通常トリップは、ユーザーの希望時刻（希望出発時刻や希望到着時刻）を満たし且つ制約条件一覧を全て満たす。

（ステップＳ６） 配車処理部１０６は、ステップＳ１で仮生成した新規デマンド単体トリップと時系列的に重複する既存トリップが存在しない場合（ステップＳ２、ＮＯ）、ユーザーの希望出発時刻と希望到着時刻とのうち少なくとも一方を所定の時間幅でずらしてから再度、新規デマンド単体トリップでの配車が可能であるかを判定する。ここでの一例として希望出発時刻をずらす場合を挙げて説明する。配車処理部１０６は、希望出発時刻を時間的に前か後ろに所定の時間幅Ｔｎｅａｒでｉ回分（「Ｔｎｅａｒ」×ｉだけ）ずらしてから、上記ステップＳ１を再度実行する。ｉは予め設定される正の整数、ｉ＝１，２，・・・，Ｎ）である。配車処理部１０６は、ｉの最小値「１」から最大値「Ｎ」まで順次設定しながら、希望出発時刻を時間的に前か後ろに「Ｔｎｅａｒ」×ｉだけずらしてから上記ステップＳ１の実行を繰り返す。例えば、「Ｔｎｅａｒ＝１０分」であり、「Ｎ＝２」である場合には、まず「希望出発時刻を前に１０分ずらしてから上記ステップＳ１を実行する」、次いで「希望出発時刻を後ろに１０分ずらしてから上記ステップＳ１を実行する」、次いで「希望出発時刻を前に２０分ずらしてから上記ステップＳ１を実行する」、最後に「希望出発時刻を後ろに２０分ずらしてから上記ステップＳ１を実行する」の合計４回、上記ステップＳ１が繰り返し実行される。このステップＳ１の繰り返し実行において、希望出発時刻を前にずらす場合と希望出発時刻を後ろにずらす場合とでそれぞれに、新規デマンド単体トリップでの配車が可能であると判定されたときにはステップＳ６を終了する。なお、即時予約の場合は、拠点出発時刻に関する制約条件から、希望出発時刻を後へずらすのみとし、希望出発時刻を前にずらすことは行わない。

ステップＳ６の結果、新規デマンド単体トリップでの配車が可能である場合（ステップＳ６、ＹＥＳ）、ステップＳ７に進む。一方、新規デマンド単体トリップでの配車が不可能である場合（ステップＳ６、ＮＯ）、ステップＳ１０に進む。

（ステップＳ７） 配車処理部１０６は、ステップＳ６で配車が可能であると判定された新規デマンド単体トリップを近傍トリップとして出力する。この後、図３の処理を終了する。近傍トリップとは、ユーザーの希望条件のうちいずれかの条件を変えることにより配車が可能になるトリップのことである。したがって、近傍トリップは、ユーザーの全ての希望条件は満たさない。

（ステップＳ８） 配車処理部１０６は、ステップＳ１で仮生成した新規デマンド単体トリップのデマンドについて、当該新規デマンド単体トリップと時系列的に重複する既存トリップへ新規デマンド挿入が不可能である場合（ステップＳ３、ＮＯ）、ステップＳ３で新規デマンド挿入を試みた既存トリップの中に、新規デマンドの制約条件となるユーザーの希望条件「乗車場所（出発地）、降車場所（目的地）、希望時刻（希望出発時刻、希望到着時刻）、乗車人数、相乗り拒否」以外の制約条件を満たすトリップがあるかを判定する。この判定の結果、該当トリップがある場合には（ステップＳ８、ＹＥＳ）、ステップＳ９へ進む。一方、該当トリップがない場合には（ステップＳ８、ＮＯ）、ステップＳ１０へ進む。

（ステップＳ９） 配車処理部１０６は、ステップＳ８で発見された既存トリップを近傍トリップとして出力する。この後、図３の処理を終了する。

ステップＳ９で出力される近傍トリップについて説明する。ステップＳ９で出力される近傍トリップは、ユーザーの希望条件「希望時刻（希望出発時刻、希望到着時刻）、乗車場所（出発地）、降車場所（目的地）、乗車人数、相乗り拒否」の全ては満たさないが、当該満たさない希望条件を変えれば、新規デマンド挿入が可能になる既存トリップである。したがって、ステップＳ９で出力される近傍トリップは、当該満たさない希望条件を変えることによって配車が可能になることをユーザーに提案することができるトリップである。以下に、ユーザーの希望条件の変更を試みる処理について説明する。

（希望時刻が満たされない場合）
配車処理部１０６は、上記ステップＳ６と同様に、ユーザーの希望出発時刻と希望到着時刻とのうち少なくとも一方を所定の時間幅でずらしてから再度、既存トリップへの新規デマンド挿入が可能であるかを判定する。この判定の結果、既存トリップへの新規デマンド挿入が可能である場合に、当該希望時刻を変更した後のトリップを近傍トリップとして出力する。

（乗車場所（出発地）又は降車場所（目的地）が満たされない場合）
配車処理部１０６は、ユーザーの希望条件の乗車場所（出発地）が既存トリップ（既存の配車）の出発地から所定の距離以内にあるか、又はユーザーの希望条件の降車場所（目的地）が既存トリップの目的地から所定の距離以内にあるときには、当該希望条件の出発地と目的地とのうち少なくとも一方を既存トリップと同じに変更してから再度、既存トリップへの新規デマンド挿入が可能であるかを判定する。この判定の結果、既存トリップへの新規デマンド挿入が可能である場合に、当該出発地又は目的地を変更した後のトリップを近傍トリップとして出力する。

（乗車人数が満たされない場合）
配車処理部１０６は、既存トリップ（既存の配車）の乗車人数にユーザーの希望条件の乗車人数を加算すると乗車定員超過であるときには、当該希望条件の乗車人数を減らしてから再度、既存トリップへの新規デマンド挿入が可能であるかを判定する。この判定の結果、既存トリップへの新規デマンド挿入が可能である場合に、当該乗車人数を減らした後のトリップを近傍トリップとして出力する。

（相乗り拒否が満たされない場合）
配車処理部１０６は、ユーザーの希望条件の相乗り拒否を相乗り許可に変更してから再度、既存トリップへの新規デマンド挿入が可能であるかを判定する。この判定の結果、既存トリップへの新規デマンド挿入が可能である場合に、相乗り拒否を相乗り許可に変更した後のトリップを近傍トリップとして出力する。

（ステップＳ１０） 配車処理部１０６は、ユーザーの希望条件を変更しても配車が不可能な場合には（ステップＳ６がＮＯ、又はステップＳ８がＮＯ）、配車が不可能であることを出力する。

以上が図３の配車判定方法の説明である。

上記した図３の配車判定方法は、全車両のそれぞれに対して実行される。配車処理部１０６は、車両毎に図３の配車判定方法によって出力された全ての通常トリップと全ての近傍トリップとの中から、最終的に出力するトリップを選択する。この選択方法を説明する。まず、全車両において、一つでも通常トリップが出力された場合には、通常トリップのうち最小遅延コストである通常トリップを最終的なトリップ（配車）として出力する。一方、一つも通常トリップが出力されなかった場合には、全車両に関する全ての近傍トリップの中から、ユーザーの希望時刻よりも時間的に前の近傍トリップのうち最も希望時刻に近い近傍トリップと、ユーザーの希望時刻よりも時間的に後の近傍トリップのうち最も希望時刻に近い近傍トリップとを最終的な近傍トリップ（近傍配車）として出力する。

図１０に最終的なトリップ（配車）の出力例を示す。図１０中の「配車処理」とは図３の処理である。

図１０（１）の例では、車両１の配車処理によって通常トリップＡが出力され、車両２の配車処理によって近傍トリップＢ，Ｃ，Ｄが出力される。この場合、通常トリップＡが存在するので、通常トリップＡが最終的なトリップ（配車）として出力される。

図１０（２）の例では、車両１の配車処理によって近傍トリップＡ，Ｂが出力され、車両２の配車処理によって近傍トリップＣ，Ｄ，Ｅが出力される。この場合、通常トリップが存在しない。このため、ユーザーの希望出発時刻「１４時００分」よりも時間的に前で最も希望出発時刻「１４時００分」に近い近傍トリップＣ（出発予定「１３時５０分」）と、ユーザーの希望出発時刻「１４時００分」よりも時間的に後で最も希望出発時刻「１４時００分」に近い近傍トリップＢ（出発予定「１４時０５分」）と、が最終的なトリップ（配車）として出力される。

配車処理部１０６は、最終的に出力されたトリップ（配車）の情報と、当該トリップ（配車）で配車が可能であることを示す情報とを含む、端末装置２０－１を宛先とする乗車予約応答を作成する。配車処理部１０６は、作成した乗車予約応答を通信部１０２へ出力する。これにより、ユーザーに対して、当該トリップ（配車）によれば配車が可能であることが通知される。ユーザーに通常トリップが通知された場合、ユーザーは、自己の希望条件が全て満たされている配車が可能であることを認識する。一方、ユーザーに近傍トリップが通知された場合、ユーザーは、自己の希望条件のうち、通知された配車の情報に示される希望条件の変更を承諾すれば、配車が可能であることを認識する。

一方、配車処理部１０６は、全車両について配車が不可能であることが出力された場合、配車が不可能であることを示す情報を含む、端末装置２０－１を宛先とする乗車予約応答を作成する。配車処理部１０６は、作成した乗車予約応答を通信部１０２へ出力する。これにより、ユーザーに対して、配車が不可能であることが通知される。

上述した実施形態によれば、ユーザーの希望条件が全て満たされている配車が不可能であっても、いずれかの希望条件が変更されれば配車可能な配車を提案することができる。これにより、ユーザーが希望条件（例えば希望出発時刻）を再設定して再度配車検索を行う手間が省かれるので、ユーザーが予約を行う際の利便性を向上させる効果が得られる。また、配車サービス事業者にとっては、ユーザーに対して配車を提供する機会が損失されることを防ぐ効果が得られる。

なお、これにより、例えばオンデマンド交通サービスにおける総合的なサービス品質の向上を実現することができることから、国連が主導する持続可能な開発目標（SDGs）の目標９「レジリエントなインフラを整備し、持続可能な産業化を推進するとともに、イノベーションの拡大を図る」に貢献することが可能となる。

以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。

また、上述した各装置の機能を実現するためのコンピュータプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するようにしてもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disc）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

１…配車管理システム、２０－１，２０－２，２０－３…端末装置、３０…車載器、１００…管理サーバ、１０２…通信部、１０４…受付部、１０６…配車処理部、１０８…経路検索部、１１０…記憶部、１１０ａ…デマンド情報、１１０ｂ…車両情報（配車予定情報）、１１０ｃ…ユーザー情報、ＶＥ…車両、ＮＷ…ネットワーク

Claims (8)

1. 予約に応じて車両を運行するデマンド型の配車管理システムにおいて、
   配車予定を示す配車予定情報を記憶する記憶部と、
   ユーザーから乗車予約要求を受け付ける受付部と、
   前記記憶部内の配車予定情報に基づいて、前記受付部によって受付けられた乗車予約要求に示される希望条件を満たす配車が可能であるか否かを判定し、前記希望条件を満たす配車が不可能である場合に前記希望条件に対して所定の条件変更を行ってから再度、配車が可能であるか否かを判定し、配車が可能であると判定された配車の情報を前記ユーザーへ応答する配車処理部と、
   を備える配車管理システム。
2. 前記配車処理部は、前記希望条件を満たす配車が不可能である場合に、前記希望条件の希望出発時刻と希望到着時刻とのうち少なくとも一方を所定の時間幅でずらしてから再度、配車が可能であるか否かを判定する、
   請求項１に記載の配車管理システム。
3. 前記配車処理部は、前記希望条件を満たす配車が不可能である場合に、前記希望条件の相乗り拒否を相乗り許可に変更してから再度、配車が可能であるか否かを判定する、
   請求項１又は２のいずれか１項に記載の配車管理システム。
4. 前記配車処理部は、前記希望条件を満たす配車が不可能である場合において、前記希望条件の出発地が既存の配車の出発地から所定の距離以内にあるか、又は前記希望条件の目的地が既存の配車の目的地から所定の距離以内にあるときには、前記希望条件の出発地と目的地とのうち少なくとも一方を既存の配車と同じに変更してから再度、配車が可能であるか否かを判定する、
   請求項１から３のいずれか１項に記載の配車管理システム。
5. 前記配車処理部は、前記希望条件を満たす配車が不可能である場合において、既存の配車の乗車人数に前記希望条件の乗車人数を加算すると乗車定員超過であるときには、前記希望条件の乗車人数を減らしてから再度、配車が可能であるか否かを判定する、
   請求項１から４のいずれか１項に記載の配車管理システム。
6. 前記配車処理部は、前記希望条件とは異なる条件で配車が可能であると判定された複数の配車のうち、前記希望条件の希望出発時刻又は希望到着時刻の前後のそれぞれ直近の配車の情報を前記ユーザーへ応答する、
   請求項１から５のいずれか１項に記載の配車管理システム。
7. 予約に応じて車両を運行するデマンド型の配車管理システムが実行する配車予約管理方法であって、
   配車予定を示す配車予定情報を記憶部に記憶する記憶ステップと、
   ユーザーから乗車予約要求を受け付ける受付ステップと、
   前記記憶部内の配車予定情報に基づいて、前記受付ステップによって受付けられた乗車予約要求に示される希望条件を満たす配車が可能であるか否かを判定し、前記希望条件を満たす配車が不可能である場合に前記希望条件に対して所定の条件変更を行ってから再度、配車が可能であるか否かを判定し、配車が可能であると判定された配車の情報を前記ユーザーへ応答する配車処理ステップと、
   を含む配車予約管理方法。
8. 予約に応じて車両を運行するデマンド型の配車管理システムのコンピュータに、
   配車予定を示す配車予定情報を記憶部に記憶する記憶ステップと、
   ユーザーから乗車予約要求を受け付ける受付ステップと、
   前記記憶部内の配車予定情報に基づいて、前記受付ステップによって受付けられた乗車予約要求に示される希望条件を満たす配車が可能であるか否かを判定し、前記希望条件を満たす配車が不可能である場合に前記希望条件に対して所定の条件変更を行ってから再度、配車が可能であるか否かを判定し、配車が可能であると判定された配車の情報を前記ユーザーへ応答する配車処理ステップと、
   を実行させるためのコンピュータプログラム。

Images