JP2024166248A - 配車管理システム、配車予約管理方法及びコンピュータプログラム - 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