JP2021170264A - 運行管理装置、運行管理システム、運行管理方法、及び車両 - Google Patents

Abstract

【課題】種々の目的に対応した運行を実現できる運行管理装置、運行管理システム、運行管理方法及び車両を提供する。
【解決手段】運行管理システム１において、運行管理装置１０は、車両２０の運行を管理する制御部を備える。制御部は、ユーザの端末装置３０からユーザの希望条件を含む乗車申込情報を受信し、ユーザが希望条件に基づいて車両２０に乗車できるように、車両２０の運行スケジュールを決定し、車両２０に対する運行要求が生じた場合、運行要求に基づいて運行スケジュールを変更し、運行要求に基づく運行スケジュールの変更によってユーザが希望条件で車両２０に乗車できなくなった場合、ユーザの端末装置３０に対してユーザに付与するインセンティブに関する情報を送信する。
【選択図】図１

Description

本開示は、運行管理装置、運行管理システム、運行管理方法、及び車両に関する。

従来、ユーザからの要求に応じて運行する車両が知られている。例えば特許文献１には、運行効率を向上させる運行管理方法が開示されている。

特開２０１９−１６２９０号公報

ユーザからの要求に応じて運行する車両は、公共交通機関としての性格を有する。車両は、公共交通機関として公共目的に応えるように運行することが求められる。また、公共目的に限られず種々の目的に応えるように運行することが求められる。

かかる事情に鑑みてなされた本開示の目的は、種々の目的に対応した運行を実現することにある。

本開示の一実施形態に係る運行管理装置は、車両の運行を管理する制御部を備える。前記制御部は、ユーザの端末装置から前記ユーザの希望条件を含む乗車申込情報を受信し、前記ユーザが前記希望条件に基づいて前記車両に乗車できるように、前記車両の運行スケジュールを決定し、前記車両に対する運行要求が生じた場合、前記運行要求に基づいて前記運行スケジュールを変更し、前記運行要求に基づく前記運行スケジュールの変更によって前記ユーザが前記希望条件で前記車両に乗車できなくなった場合、前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信する。

本開示の一実施形態に係る運行管理システムは、前記運行管理装置と、前記車両とを備える。

本開示の一実施形態に係る運行管理方法は、車両の運行を管理する運行管理装置によって実行される。前記運行管理方法は、ユーザの端末装置から前記ユーザの希望条件を含む乗車申込情報を受信することと、前記ユーザが前記希望条件に基づいて前記車両に乗車できるように、前記車両の運行スケジュールを決定することと、前記車両に対する運行要求が生じた場合、前記運行要求に基づいて前記運行スケジュールを変更することと、前記運行要求に基づく前記運行スケジュールの変更によって前記ユーザが前記希望条件で前記車両に乗車できなくなった場合、前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信することとを含む。

本開示の一実施形態に係る車両は、運行スケジュールに基づいて運行し、ユーザを乗車させ、前記運行スケジュールが運行要求に基づいて変更された場合に、乗車しているユーザに途中で降車する要請を報知する。

本開示の一実施形態に係る運行管理装置、運行管理システム、運行管理方法、及び車両によれば、種々の目的に対応した運行が実現され得る。

一実施形態に係る運行管理システムの構成例を示す模式図である。 一実施形態に係る運行管理システムの構成例を示すブロック図である。 サーバが実行する手順の一例を示すフローチャートである。

図１及び図２に示されるように、一実施形態に係る運行管理システム１は、サーバ１０と、車両２０と、端末装置３０とを備える。運行管理システム１は、必須ではないが、データベース（ＤＢ）１５をさらに備える。サーバ１０と、車両２０と、端末装置３０と、ＤＢ１５とは、ネットワーク４０に接続されており、互いに通信可能である。サーバ１０、車両２０、端末装置３０、及びＤＢ１５それぞれの数は、１つに限られず、２つ以上であってよい。

運行管理システム１は、車両２０にユーザを乗車させて少なくとも２つの地点の間を移動してユーザを輸送するオンデマンドバスサービスを提供する。運行管理システム１は、車両２０がユーザを輸送できるように車両２０の運行を管理する。

ユーザは、端末装置３０を所持し、端末装置３０からサーバ１０にアクセスすることによって、車両２０が提供するオンデマンドバスサービスの利用を申し込んでよい。

サーバ１０は、ユーザからの乗車の申し込みを受け付け、申し込みに基づいて車両２０の運行ルート又は運行スケジュールを決定してよい。サーバ１０は、車両２０の運行状況に基づいてユーザからの申し込みを受け付け可能か決定してもよい。サーバ１０は、ユーザからの申し込みの状況に基づいて、車両２０の運行ルート又は運行スケジュールを決定してよい。サーバ１０は、運行管理装置とも称される。

車両２０の運行を管理する運行管理システム１は、オンデマンドバスサービスを提供する主体によって運用されてよいし、他の異なる主体によって運用されてもよい。

サーバ１０は、１つ又は互いに通信可能な複数のサーバ装置を含んでよい。サーバ１０は、ユーザから受け付けた申し込みを管理する。サーバ１０は、車両２０との間でオンデマンドバスサービスの提供に関する種々の情報を送受信してよい。サーバ１０は、これらの処理だけでなく、オンデマンドバスサービスの提供に関する種々の処理を実行可能に構成されてよい。サーバ１０は、車両２０の運行を管理する。サーバ１０は、車両２０と通信することによって、例えば、車両２０の位置又は速度等の車両２０に関する種々の情報を取得してよい。サーバ１０は、これらの処理だけでなく、車両２０の運行を管理するための種々の処理を実行可能に構成されてよい。

サーバ１０は、サーバ制御部１２と、サーバ通信部１４とを備える。サーバ制御部１２は、１つ以上のプロセッサを含んでよい。サーバ制御部１２は、単に制御部とも称される。本実施形態において「プロセッサ」は、汎用のプロセッサ、特定の処理に特化した専用のプロセッサ等であるが、これらに限られない。サーバ制御部１２は、１つ以上の専用回路を含んでもよい。専用回路は、例えば、ＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit）を含んでよい。サーバ制御部１２は、プロセッサの代わりに専用回路を含んでもよいし、プロセッサとともに専用回路を含んでもよい。サーバ通信部１４は、通信モジュールを含み、車両２０と通信してよい。サーバ１０は、記憶部をさらに備えてよい。記憶部は、例えば半導体メモリ、磁気メモリ、又は光メモリ等であるが、これらに限られない。記憶部は、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。記憶部は、磁気ディスク等の電磁記憶媒体を含んでよい。記憶部は、非一時的なコンピュータ読み取り可能な媒体を含んでよい。記憶部は、サーバ１０の動作に用いられる任意の情報を格納する。例えば、記憶部は、システムプログラム、又はアプリケーションプログラム等を格納してもよい。サーバ１０は、ＤＢ１５を記憶部として、プログラム又は情報等を格納してもよい。

車両２０は、ユーザを乗車させて運行する。車両２０は、ユーザを乗車させるように構成されてよい。例えば、車両２０は、ユーザを着席させるための座席等を備えてよい。車両２０の数は、１台に限られず、２台以上であってもよい。

車両２０は、自動運転によって運行可能に構成されてもよい。自動運転は、例えばＳＡＥ（Society of Automotive Engineers）において定義されるレベル１からレベル５までのいずれかのレベルで実施されてよい。自動運転は、例示した定義に限られず、他の定義に基づいて実施されてもよい。

車両２０は、制御装置２２と、通信装置２４とを搭載している。制御装置２２と、通信装置２４とは、例えばＣＡＮ（Controller Area Network）等の車載ネットワーク又は専用線を介して、互いに通信可能に接続されている。

制御装置２２は、車両２０が備える各構成部を制御する。制御装置２２は、１つ以上のプロセッサを含んでよい。制御装置２２は、プロセッサの代わりに１つ以上の専用回路を含んでもよいし、プロセッサとともに１つ以上の専用回路を含んでもよい。制御装置２２は、記憶部をさらに含んでよい。

通信装置２４は、ネットワーク４０を介して、サーバ１０と通信する。通信装置２４は、ネットワーク４０を介して端末装置３０と通信してもよいし、ネットワーク４０を介さずに端末装置３０と通信してもよい。通信装置２４は、例えば車載通信機であってよい。通信装置２４は、ネットワーク４０に接続する通信モジュールを含んでよい。通信モジュールは、例えば４Ｇ（4th Generation）及び５Ｇ（5th Generation）等の移動体通信規格に対応する通信モジュールを含んでよいが、これらに限られない。

車両２０は、必須ではないが、位置情報取得装置２５を更に備える。位置情報取得装置２５は、車両２０に搭載されている他の構成部とＣＡＮ等の車載ネットワーク又は専用線を介して互いに通信可能に接続されている。位置情報取得装置２５は、車両２０の位置情報を取得する。位置情報取得装置２５は、衛星測位システムに対応する受信機を含んでよい。衛星測位システムに対応する受信機は、例えばＧＰＳ（Global Positioning System）受信機を含んでもよい。本実施形態において、車両２０は、位置情報取得装置２５を用いて、車両２０自身の位置情報を取得できるとする。車両２０は、車両２０自身の位置情報をサーバ１０又は端末装置３０に出力してよい。

端末装置３０は、ネットワーク４０を介して、又は、ネットワーク４０を介さずに、車両２０と通信する。端末装置３０は、ネットワーク４０を介してサーバ１０と通信する。端末装置３０は、例えばスマートフォン等の携帯端末を含んでよい。

端末装置３０は、ユーザが乗車を申し込むために用いるアプリケーションを動作させてよい。端末装置３０は、サーバ１０と通信し、乗車の申し込みに関する情報を送受信してよい。端末装置３０は、ユーザが車両２０に乗車する際に車両２０と通信し、その車両２０がユーザの申し込みに割り当てられている車両２０であるか認証する情報を送受信してよい。

端末装置３０は、例えば、車両２０が備える位置情報取得装置２５と同一又は類似の構成を備えることによって、端末装置３０自身の位置情報を取得してよい。端末装置３０は、端末装置３０自身の位置情報をサーバ１０又は車両２０に出力してもよい。

（運行管理システム１の動作例）
＜乗車の申し込み＞
端末装置３０は、ユーザが乗車を申し込む入力を受け付ける。端末装置３０は、ユーザの入力に基づいて乗車申込情報を生成し、サーバ１０に送信する。乗車申込情報は、ユーザが車両２０に乗車することを希望する地点又はエリアと、ユーザが車両２０から降車することを希望する地点又はエリアとを含む。ユーザが車両２０に乗車することを希望する地点又はエリアは、希望出発地とも称される。ユーザが車両２０から降車することを希望する地点又はエリアは、希望目的地とも称される。乗車申込情報は、ユーザが車両２０に乗車することを希望する時刻若しくは時間帯、又は、ユーザが車両２０から降車することを希望する時刻若しくは時間帯を更に含んでもよい。ユーザが車両２０に乗車することを希望する時刻若しくは時間帯は、希望出発時刻とも称される。ユーザが車両２０から降車することを希望する時刻若しくは時間帯は、希望到着時刻とも称される。ユーザが乗車する車両２０に希望する条件は、希望条件とも称される。

＜車両２０の決定＞
サーバ１０のサーバ制御部１２は、１人又は複数のユーザの端末装置３０から受信した乗車申込情報に基づいて車両２０の運行を管理する。サーバ制御部１２は、１台又は複数台の車両２０の運行を管理する。サーバ制御部１２は、１人又は複数のユーザの希望条件に基づいて、車両２０の運行ルート又は運行スケジュールを決定する。

サーバ制御部１２は、乗車申込情報に含まれるユーザの希望条件を満たす車両２０を抽出する。サーバ制御部１２は、ユーザの希望条件を満たす車両２０が存在しない場合、ユーザの希望条件を一部満たさない車両２０を抽出してもよい。サーバ制御部１２は、ユーザの希望条件を満たす車両２０が存在しない場合、希望条件の変更をユーザに提案する情報を端末装置３０に送信してもよい。端末装置３０は、ユーザが希望条件の変更を受け入れるかの入力を受け付ける。端末装置３０は、ユーザが希望条件の変更を受け入れる場合、変更する条件の入力も受け付ける。端末装置３０は、ユーザが入力した情報をサーバ１０に送信する。サーバ制御部１２は、ユーザが希望条件を変更した場合、変更後の希望条件を満たす車両２０を抽出する。

サーバ制御部１２は、抽出した車両２０の情報を端末装置３０に送信する。端末装置３０は、抽出された車両２０の情報をユーザに通知し、ユーザがその車両２０に乗車することを承諾するか拒否するかの入力を受け付け、入力結果をサーバ１０に送信する。サーバ制御部１２は、抽出された車両２０への乗車をユーザが承諾した場合、その車両２０にユーザを乗車させると決定する。ユーザを乗車させると決定した車両２０は、乗車車両とも称される。サーバ制御部１２は、抽出された車両２０への乗車をユーザが拒否した場合、異なる車両２０を抽出して、その情報を端末装置３０に送信する。サーバ制御部１２は、抽出した車両２０をそのまま乗車車両として決定してもよい。

サーバ制御部１２は、決定した乗車車両にユーザを乗車させることができるように運行スケジュールを決定する。サーバ制御部１２は、運行スケジュールを含む制御指示を乗車車両に送信する。サーバ制御部１２は、運行スケジュールに基づいて定まる乗車地点及び乗車時刻の情報をユーザの端末装置３０に送信する。

＜運行要求への対応＞
ユーザを乗車させている車両２０は、種々の目的に対応する運行を要求されることがある。種々の目的に対応する運行は、ユーザからの乗車申込情報に関係なく要求され得る。車両２０は、例えば、公共目的に対応する運行を要求されることがある。公共目的に対応する運行は、例えば、災害、又は、事件若しくは事故等の緊急事態が発生した場合に、緊急事態への対応のために必要とされる運行を含んでよい。緊急事態への対応のために必要とされる運行は、緊急運行とも称される。緊急運行は、例えば、救急車、消防車又は警察車両等の緊急車両が通行する道路を通らないように車両２０が運行することを含んでよい。緊急運行は、例えば、避難対象者又は救護対象者等の緊急に移動する必要がある人を輸送するために車両２０が運行することを含んでよい。緊急運行の要求は、緊急運行要求とも称される。

サーバ制御部１２は、サーバ通信部１４を介して、例えば、政府又は自治体等が管理する外部装置から車両２０に対する緊急運行要求を受信してよい。サーバ制御部１２は、災害、又は、事件若しくは事故等の緊急事態の発生に関する情報に基づいて、車両２０に対する緊急運行要求を生成してもよい。

公共目的に対応する運行は、例えば、乳幼児及び乳幼児を連れた親、高齢者、又は障碍者等の社会的弱者を優先して輸送するための運行を含んでもよい。

サーバ制御部１２は、車両２０に対する運行要求として、公共目的だけでなく、例えば、商業的な目的に対応する運行要求を受信したり生成したりしてもよい。商業的な目的に対応する運行は、例えば、追加運賃を支払う等の種々の条件を満たすユーザを優先して乗車させることを含んでもよい。商業的な目的に対応する運行は、優先的に車両２０に乗車する権利を有するユーザを乗車させることを含んでもよい。

サーバ制御部１２は、受信したり生成したりした車両２０への運行要求に基づいて、車両２０の運行スケジュールを変更する。車両２０の運行スケジュールの変更は、車両２０に既に乗車しているユーザが希望目的地に希望降車時刻までに到着できない事態を生じさせ得る。また、車両２０の運行スケジュールの変更は、車両２０に既に乗車しているユーザが希望目的地にすら到着できない事態を生じさせ得る。また、車両２０の運行スケジュールの変更は、車両２０への乗車の申し込みが受け付けられたユーザが希望出発地で乗車できない事態を生じさせ得る。つまり、車両２０は、その運行スケジュールの変更によって、車両２０への乗車を申し込んだユーザの希望条件に合わせて運行できなくなることがある。

サーバ制御部１２は、ユーザの端末装置３０に、運行要求に基づく運行スケジュールの変更によって、ユーザの希望条件に合わせて車両２０が運行できなくなる旨の情報を送信する。ユーザが既に車両２０に乗車している場合、サーバ制御部１２は、ユーザを途中で降車させたり到着の遅れを受諾させたりする処理を実行する。サーバ制御部１２は、ユーザに降車してもらう要請、又は、到着の遅れを受諾してもらう要請をユーザの端末装置３０に送信してもよい。車両２０への乗車の申し込みが受け付けられているユーザがまだ車両２０に乗車していない場合、サーバ制御部１２は、ユーザに乗車の申し込みをキャンセルさせたりサーバ制御部１２自身でユーザの申し込みをキャンセルしたりする処理を実行する。サーバ制御部１２は、ユーザに乗車の申し込みをキャンセルしてもらう要請をユーザの端末装置３０に送信してもよい。

＜＜既に車両２０に乗車しているユーザへの要請＞＞
サーバ制御部１２は、ユーザに希望目的地までの途中で降車するように促すために、途中降車の要請をユーザの端末装置３０に送信してよい。また、サーバ制御部１２は、ユーザに到着遅れの受諾の要請をユーザの端末装置３０に送信してよい。

サーバ制御部１２は、既に車両２０に乗車しているユーザの端末装置３０に対して、途中で降車することの承諾、又は、希望降車時刻より遅い時刻に到着することの承諾を求める情報を送信してもよい。端末装置３０は、ユーザが承諾するか拒否するかの入力を受け付け、入力結果をサーバ１０に送信してよい。サーバ制御部１２は、ユーザが承諾した場合に、そのユーザが承諾した内容に基づいて運行スケジュールを変更する。サーバ制御部１２は、ユーザが途中で車両２０から降車する場合、ユーザが降車できるように車両２０を運行させる。

サーバ制御部１２は、ユーザが拒否した場合、そのユーザを希望到着時刻までに希望目的地に到着させるようにしつつ、運行要求に基づいて運行スケジュールを変更してもよい。この場合、サーバ制御部１２は、他のユーザの端末装置３０に対して、そのユーザの希望条件に合わせて運行できないことの承諾を求める情報を送信してもよい。サーバ制御部１２は、ユーザが拒否した場合でも、そのユーザの希望条件を満たして運行することが不可能である場合、途中降車又は到着遅延のいずれかを選択することを求める情報をユーザの端末装置３０に送信してよい。端末装置３０は、ユーザから選択の入力を受け付け、入力結果をサーバ１０に送信してよい。サーバ制御部１２は、端末装置３０から受信したユーザの入力結果に基づいて、ユーザが途中降車又は到着遅延を受諾したとして車両２０の運行スケジュールを変更してよい。サーバ制御部１２は、ユーザが選択しない場合、ユーザが到着遅延を受諾したとみなして車両２０の運行スケジュールを変更してもよい。

既にユーザが乗車している車両２０は、運行要求に基づいて変更された運行スケジュールを受信し、ユーザの希望条件にかかわらず、受信した運行スケジュールに従って運行してもよい。この場合、車両２０の制御装置２２は、既に乗車しているユーザの中に、変更された運行スケジュールで希望目的地に到着できなかったり希望到着時刻までに到着できなかったりする条件を満たすユーザが存在するか判定してよい。希望目的地に到着できない等の条件を満たすユーザが存在する場合、制御装置２２は、条件を満たすユーザに対して途中降車を要請する情報を報知してもよい。車両２０は、ユーザに対して情報を報知するためのディスプレイ又はスピーカ等の出力デバイスを備えてもよい。制御装置２２は、出力デバイスによって、条件を満たすユーザに対して途中降車を要請する情報を報知してもよい。ユーザは、車両２０からの報知に基づいて途中降車又は到着遅延のいずれかを選択してもよい。端末装置３０は、ユーザから選択する入力を受け付けて、入力結果をサーバ１０に送信してもよい。サーバ制御部１２は、端末装置３０から受信したユーザの入力結果に基づいて、ユーザが途中降車又は到着遅延を受諾したとして車両２０の運行スケジュールを変更してよい。サーバ制御部１２は、ユーザが選択しない場合、ユーザが到着遅延を受諾したとみなして車両２０の運行スケジュールを変更してもよい。

＜＜まだ車両２０に乗車していないユーザへの要請＞＞
サーバ制御部１２は、乗車の申し込みのキャンセルの要請をユーザの端末装置３０に送信してよい。サーバ制御部１２は、要請することなく、乗車の申し込みをサーバ制御部１２自身でキャンセルし、キャンセルした旨の情報をユーザの端末装置３０に送信してもよい。

サーバ制御部１２は、まだ車両２０に乗車していないユーザの端末装置３０に対して、車両２０への乗車の申し込みのキャンセルの承諾を求める情報を送信してもよい。端末装置３０は、ユーザが承諾するか拒否するかの入力を受け付け、入力結果をサーバ１０に送信してよい。サーバ制御部１２は、ユーザが承諾した場合に、そのユーザが乗車しないことを考慮して運行スケジュールを変更し、変更した運行スケジュールで車両２０を運行させる。

サーバ制御部１２は、ユーザが拒否した場合、そのユーザが乗車できるようにしつつ、運行要求に基づいて運行スケジュールを変更してもよい。この場合、サーバ制御部１２は、他のユーザの端末装置３０に対して、そのユーザの希望条件に合わせて運行できないことの承諾を求める情報を送信してもよい。サーバ制御部１２は、ユーザが拒否した場合でも、希望条件に合わせてユーザを車両２０に乗車させることが不可能である場合、乗車の申し込みをサーバ制御部１２自身で強制的にキャンセルし、キャンセルした旨をユーザの端末装置３０に送信してよい。

＜ユーザへのインセンティブの付与＞
サーバ制御部１２は、運行要求に基づいて車両２０の運行スケジュールを変更したことによってユーザが希望条件で乗車できなくなった場合、そのユーザにインセンティブを付与する。サーバ制御部１２は、そのユーザの端末装置３０に対して、付与するインセンティブに関する情報を送信する。

サーバ制御部１２は、インセンティブとして、例えば、ユーザが次回の乗車を申し込むときに他のユーザよりも優先的に乗車の申し込みが受け付けられる権利を付与してもよい。サーバ制御部１２は、ユーザが次回の乗車を申し込むときに指定する希望条件が他のユーザの希望条件よりも優先される権利を付与してもよい。

インセンティブは、例えば、車両２０の運賃をユーザに還元する形式で付与されてよい。インセンティブは、車両２０の運賃の支払いに適用できるポイントとして付与されてもよい。つまり、インセンティブは、車両２０の運賃に関する権利として付与されてもよい。インセンティブは、電子マネーとして付与されてもよい。インセンティブは、有価物又は有償サービスと交換可能なポイントとして付与されてもよい。

サーバ制御部１２は、ユーザがインセンティブの付与の対象となったことを確認できた後で、ユーザに対してインセンティブを付与してもよい。サーバ制御部１２は、ユーザが途中で降車したり到着の遅れを受諾したり乗車の申し込みをキャンセルしたりしたことを確認できた場合に、ユーザをインセンティブの付与の対象としてよい。

サーバ制御部１２は、既に車両２０に乗車しているユーザが要請に応じて車両２０から降車したか、又は、ユーザが希望到着時刻より遅れて希望目的地に到着したか確認してよい。サーバ制御部１２は、ユーザが車両２０から降車した情報、又は、ユーザが希望到着時刻より遅れて希望目的地に到着した情報を、車両２０又はユーザの端末装置３０から受信してよい。サーバ制御部１２は、車両２０又はユーザの端末装置３０から受信した情報に基づいて、ユーザの途中降車又は到着遅延を確認してよい。サーバ制御部１２は、ユーザの途中降車又は到着遅延の確認後、ユーザをインセンティブの付与の対象とし、ユーザに付与するインセンティブに関する情報を端末装置３０に送信してよい。

サーバ制御部１２は、まだ車両２０に乗車していなかったユーザが車両２０への乗車をキャンセルしたか確認してよい。サーバ制御部１２は、ユーザが車両２０への乗車をキャンセルした情報を、車両２０又はユーザの端末装置３０から受信してよい。サーバ制御部１２は、ユーザの端末装置３０から受信した情報に基づいて、ユーザの乗車のキャンセルを確認してよい。サーバ制御部１２は、サーバ制御部１２自身でユーザの乗車をキャンセルすることによってキャンセルを確認してもよい。サーバ制御部１２は、ユーザの乗車のキャンセルの確認後、ユーザをインセンティブの付与の対象とし、ユーザに付与するインセンティブに関する情報を端末装置３０に送信してよい。

＜小括＞
以上説明してきたように、本実施形態に係る運行管理システム１において、サーバ１０は、車両２０に対して公共目的等の種々の目的に対応する運行が要求された場合に、車両２０の運行スケジュールを運行要求に基づいて変更する。そして、サーバ１０は、希望条件で車両２０に乗車できなくなったユーザにインセンティブを付与する。このようにすることで、サーバ１０は、車両２０を運行要求に基づいて運行させやすくなる。その結果、公共目的等の種々の目的に対応した運行が実現され得る。

（運行管理方法のフローチャートの例）
運行管理システム１に含まれるサーバ１０のサーバ制御部１２は、図３に例示されるフローチャートの手順を含む運行管理方法を実行してもよい。運行管理方法は、サーバ制御部１２等のプロセッサに実行させる運行管理プログラムとして実現されてもよい。運行管理プログラムは、非一時的なコンピュータ読み取り可能な媒体に格納されてよい。

サーバ制御部１２は、車両２０に対する運行要求を受信する（ステップＳ１）。具体的には、サーバ制御部１２は、外部装置から車両２０に対する運行要求を受信してよい。サーバ制御部１２は、災害、又は、事件若しくは事故等の情報に基づいて、サーバ制御部１２自身で車両２０に対する運行要求を生成してもよい。

サーバ制御部１２は、運行要求に基づいて車両２０の運行スケジュールを変更する（ステップＳ２）。サーバ制御部１２は、変更した運行スケジュールを車両２０に送信してもよい。ここで、後述するステップＳ３又はＳ５の手順において、運行スケジュールがさらに変更されることがある。したがって、サーバ制御部１２は、ステップＳ３又はＳ５の手順における判定結果を待ってから運行スケジュールを車両２０に送信してもよい。つまり、サーバ制御部１２は、運行スケジュールの送信を保留しておいてよい。

サーバ制御部１２は、ユーザに対して降車又はキャンセル等の要請が必要であるか判定する（ステップＳ３）。具体的には、サーバ制御部１２は、車両２０に既に乗車しているユーザの中で、運行スケジュールの変更によって、希望目的地に到着できなくなるユーザ、又は、希望到着時刻までに希望目的地に到着できなくなるユーザが生じるか判定してよい。サーバ制御部１２は、まだ車両２０に乗車していないユーザの中で、運行スケジュールの変更によって、希望条件で車両２０に乗車できなくなるユーザが生じるか判定してよい。

サーバ制御部１２は、ユーザに対する要請が必要でない場合（ステップＳ３：ＮＯ）、図３のフローチャートの手順の実行を終了する。サーバ制御部１２は、変更した運行スケジュールの送信をステップＳ２の手順において保留していた場合、ステップＳ３の手順において実行してよい。

サーバ制御部１２は、ユーザに対する要請が必要である場合（ステップＳ３：ＹＥＳ）、ユーザの端末装置３０に対して要請を送信する（ステップＳ４）。具体的には、車両２０に既に乗車しているユーザがいる場合、サーバ制御部１２は、そのユーザの端末装置３０に対して、途中降車を要請する情報、又は、到着遅延の受諾を要請する情報を送信してよい。車両２０に乗車する予定でまだ乗車していないユーザがいる場合、サーバ制御部１２は、そのユーザの端末装置３０に対して、乗車のキャンセルを要請する情報を送信してよい。

サーバ制御部１２は、ユーザの端末装置３０からユーザが要請を受諾したか拒否したかを表す情報を受信し、ユーザが要請を受諾したか判定する（ステップＳ５）。サーバ制御部１２は、ユーザが要請を受諾しなかった場合（ステップＳ５：ＮＯ）、つまりユーザが要請を拒否した場合、ステップＳ２の手順に戻って運行スケジュールを再度変更する。

サーバ制御部１２は、ユーザが要請を受諾した場合（ステップＳ５：ＹＥＳ）、ユーザに付与するインセンティブを決定し、ユーザの端末装置３０に対してインセンティブに関する情報を送信する（ステップＳ６）。サーバ制御部１２は、変更した運行スケジュールの送信をステップＳ２の手順において保留していた場合、ステップＳ６の手順において実行してよい。サーバ制御部１２は、ステップＳ６の手順の実行後、図３のフローチャートの手順の実行を終了する。

以上説明してきたように、本実施形態に係る運行管理方法又は運行管理プログラムによれば、車両２０に対して公共目的等の種々の目的に対応する運行が要求された場合に、車両２０の運行スケジュールが運行要求に基づいて変更される。そして、希望条件で車両２０に乗車できなくなったユーザにインセンティブが付与される。このようにすることで、車両２０が運行要求に基づいて運行しやすくなる。その結果、公共目的等の種々の目的に対応した運行が実現され得る。

（他の実施形態）
＜要請の対象とするユーザの決定＞
サーバ１０のサーバ制御部１２は、車両２０に対する運行要求に基づいて運行スケジュールを変更する際に、希望条件で車両２０に乗車できなくなることを受諾するようにユーザに対して要請する。サーバ制御部１２は、要請の対象とするユーザを、車両２０に既に乗車しているユーザ、又は、申し込みが受け付けられているもののまだ車両２０に乗車していないユーザから決定する。

サーバ制御部１２は、ユーザの属性に基づいて、要請の対象となるユーザを決定してよい。サーバ制御部１２は、ユーザの属性として、例えば、ユーザが乳幼児及び乳幼児を連れた親、高齢者、又は障碍者等の社会的弱者であるかを表す情報を設定してもよい。サーバ制御部１２は、途中降車等の要請を、社会的弱者に該当しないユーザに対して優先して実施してよい。つまり、サーバ制御部１２は、社会的弱者に該当するユーザに対して、できるだけ途中降車等を要請しないようにしてよい。このようにすることで、社会的弱者に該当するユーザが保護され得る。

サーバ制御部１２は、ユーザが車両２０に乗車した実績に基づいてユーザの属性を設定してよい。

サーバ制御部１２は、ユーザの属性として、例えば、ユーザが車両２０に所定回数以上乗車したことを表す情報を設定してもよい。サーバ制御部１２は、途中降車等の要請を、車両２０に所定回数未満しか乗車していないユーザに対して優先して実施してよい。つまり、サーバ制御部１２は、車両２０に所定回数以上乗車したことがあるユーザに対して、できるだけ途中降車等を要請しないようにしてよい。このようにすることで、ユーザに車両２０の利用を促すことができる。

サーバ制御部１２は、ユーザの属性として、例えば、ユーザが以前に途中降車等の要請を受諾したことがあるかを表す情報を設定してもよい。サーバ制御部１２は、途中降車等の要請を、要請を受諾したことがないユーザに対して優先して実施してよい。つまり、サーバ制御部１２は、途中降車等の要請を受諾したことがあるユーザに対して、できるだけ要請しないようにしてよい。このようにすることで、ユーザに対して公平感が与えられ得る。

サーバ制御部１２は、ユーザの属性として、例えば、ユーザが乗車の申し込みを無断でキャンセルしたり乗車直前にキャンセルしたりしたことが所定回数以上あったかを表す情報を設定してもよい。サーバ制御部１２は、途中降車等の要請を、無断又は直前のキャンセルを所定回数以上行ったユーザに対して優先して実施してよい。つまり、サーバ制御部１２は、無断又は直前のキャンセルを所定回数未満しか行っていないユーザに対して、できるだけ途中降車等を要請しないようにしてよい。このようにすることで、ユーザによる無断又は直前のキャンセルに対してペナルティが与えられ得る。その結果、ユーザによる無断又は直前のキャンセルが低減され得る。

サーバ制御部１２は、ユーザの属性に基づいて、要請の対象となる優先度をユーザに設定してもよい。サーバ制御部１２は、例えば、優先して要請の対象になるユーザに、高い優先度を設定してもよい。このようにすることで、サーバ制御部１２は、要請を実施しやすくなる。

＜運行要求の発生予測＞
サーバ１０のサーバ制御部１２は、ユーザの端末装置３０から乗車申込情報を受信して、ユーザからの乗車の申し込みを受け付ける。サーバ制御部１２は、乗車の申し込みが多すぎて車両２０の運行スケジュールを生成できない場合、運行スケジュールを生成できる範囲内の一部の申し込みだけを受け付けて、他の申し込みを受け付けない。

ここで、サーバ制御部１２は、公共目的等の種々の目的に対応する運行要求の発生を予測し、その予測結果に基づいて乗車申込情報を受け付けるか決定してよい。例えば、サーバ制御部１２は、緊急事態の発生に関する情報を受信した場合、緊急車両が通行する道路を空けるための運行要求が発生すると予測してよい。サーバ制御部１２は、その予測結果に基づいて、緊急車両が通行しない道路を通行する運行スケジュールを生成し、その運行スケジュールに適合する乗車申込情報を受け付けてよい。また、サーバ制御部１２は、その予測結果に基づいて、乗車の申し込みを受け付けるユーザの数をあらかじめ減らしてよい。

また、サーバ制御部１２は、例えば、車両２０に優先的に乗車する権利を有するユーザの数が増えている情報を受信した場合、車両２０に優先的に乗車する権利が行使されることによる運行要求が発生すると予測してよい。サーバ制御部１２は、その予測結果に基づいて、乗車の申し込みを受け付けるユーザの数をあらかじめ減らしてよい。

以上述べたように、サーバ制御部１２は、運行要求の発生を予測して乗車申込情報を受け付けてよい。このようにすることで、サーバ制御部１２は、申し込みが受け付けられた後で、希望条件で車両２０に乗車できなくなるユーザの数を減らすことができる。その結果、サーバ制御部１２は、車両２０を運行要求に基づいて運行させやすくなる。また、ユーザに付与するインセンティブが減らされ得る。

本開示に係る実施形態について、諸図面及び実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形及び修正を行うことが容易であることに注意されたい。したがって、これらの変形及び修正は本開示の範囲に含まれることに留意されたい。例えば、各手段又は各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段又はステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。

１ 運行管理システム
１０ サーバ（１２：サーバ制御部、１４：サーバ通信部）
１５ データベース（ＤＢ）
２０ 車両（２２：制御装置、２４：通信装置、２５：位置情報取得装置）
３０ 端末装置
４０ ネットワーク

Claims (20)

1. 車両の運行を管理する制御部を備え、
   前記制御部は、
   ユーザの端末装置から前記ユーザの希望条件を含む乗車申込情報を受信し、
   前記ユーザが前記希望条件に基づいて前記車両に乗車できるように、前記車両の運行スケジュールを決定し、
   前記車両に対する運行要求が生じた場合、前記運行要求に基づいて前記運行スケジュールを変更し、
   前記運行要求に基づく前記運行スケジュールの変更によって前記ユーザが前記希望条件で前記車両に乗車できなくなった場合、前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信する、
   運行管理装置。
2. 前記制御部は、前記ユーザが前記車両に既に乗車していた場合、前記ユーザに対する途中降車の要請を前記ユーザの端末装置に送信し、前記ユーザが要請に応じて前記車両から降車した場合に前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信する、請求項１に記載の運行管理装置。
3. 前記制御部は、前記ユーザが前記車両にまだ乗車していない場合、前記ユーザの乗車のキャンセルの要請を前記ユーザの端末装置に送信し、前記ユーザが要請に応じて前記車両への乗車をキャンセルした場合に前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信する、請求項１又は２に記載の運行管理装置。
4. 前記制御部は、前記ユーザの属性に基づいて、前記ユーザに対して前記要請を行うか決定する、請求項２又は３に記載の運行管理装置。
5. 前記ユーザの属性は、前記ユーザが前記車両に乗車した実績を含む、請求項４に記載の運行管理装置。
6. 前記制御部は、前記ユーザの属性に基づいて、前記ユーザに対して前記要請を行う優先度を決定する、請求項４又は５に記載の運行管理装置。
7. 前記制御部は、前記運行要求の発生を予測し、予測結果に基づいて前記乗車申込情報を受け付ける、請求項１から６までのいずれか一項に記載の運行管理装置。
8. 前記インセンティブは、前記ユーザによる前記車両への乗車の申し込みが優先的に受け付けられる権利を含む、請求項１から７までのいずれか一項に記載の運行管理装置。
9. 前記インセンティブは、前記車両の運賃に関する権利を含む、請求項１から８までのいずれか一項に記載の運行管理装置。
10. 請求項１から９までのいずれか一項に記載の運行管理装置と、前記車両とを備える運行管理システム。
11. 車両の運行を管理する運行管理装置が実行する運行管理方法であって、
    ユーザの端末装置から前記ユーザの希望条件を含む乗車申込情報を受信することと、
    前記ユーザが前記希望条件に基づいて前記車両に乗車できるように、前記車両の運行スケジュールを決定することと、
    前記車両に対する運行要求が生じた場合、前記運行要求に基づいて前記運行スケジュールを変更することと、
    前記運行要求に基づく前記運行スケジュールの変更によって前記ユーザが前記希望条件で前記車両に乗車できなくなった場合、前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信することと
    を含む、運行管理方法。
12. 前記ユーザが前記車両に既に乗車していた場合、前記ユーザに対する途中降車の要請を前記ユーザの端末装置に送信することと、
    前記ユーザが要請に応じて前記車両から降車した場合に前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信することと
    を更に含む、請求項１１に記載の運行管理方法。
13. 前記ユーザが前記車両にまだ乗車していない場合、前記ユーザの乗車のキャンセルの要請を前記ユーザの端末装置に送信することと、
    前記ユーザが要請に応じて前記車両への乗車をキャンセルした場合に前記ユーザの端末装置に対して前記ユーザに付与するインセンティブに関する情報を送信することと
    を更に含む、請求項１１又は１２に記載の運行管理方法。
14. 前記ユーザの属性に基づいて、前記ユーザに対して前記要請を行うか決定することを更に含む、請求項１２又は１３に記載の運行管理方法。
15. 前記ユーザの属性は、前記ユーザが前記車両に乗車した実績を含む、請求項１４に記載の運行管理方法。
16. 前記ユーザの属性に基づいて、前記ユーザに対して前記要請を行う優先度を決定することを更に含む、請求項１４又は１５に記載の運行管理方法。
17. 前記運行要求の発生を予測し、予測結果に基づいて前記乗車申込情報を受け付けることを更に含む、請求項１１から１６までのいずれか一項に記載の運行管理方法。
18. 前記インセンティブは、前記ユーザによる前記車両への乗車の申し込みが優先的に受け付けられる権利を含む、請求項１１から１７までのいずれか一項に記載の運行管理方法。
19. 前記インセンティブは、前記車両の運賃に関する権利を含む、請求項１１から１８までのいずれか一項に記載の運行管理方法。
20. 運行スケジュールに基づいて運行し、ユーザを乗車させる車両であって、
    前記運行スケジュールが運行要求に基づいて変更された場合に、乗車しているユーザに途中で降車する要請を報知する、車両。

Images