JP7057018B1 - 運行管理装置、運行管理方法及び運行管理プログラム - Google Patents

Abstract

【課題】旅客輸送における乗車ユーザの利便性及び快適性及び事業者の採算性を確保する運行管理装置を提供する。【解決手段】情報処理システムにおいて、複数のユーザ端末とネットワークを介して接続する運行管理装置であるサーバ３００は、第１地点と第２地点の間を、乗合移動体が１日に複数回往復するよう定めた運行計画を取得する第１取得部３０３１、運行計画を複数のユーザに対して提供する提供部３０３２、運行計画に基づいて運行される乗合移動体に対するユーザからの乗車希望と乗車希望ユーザの識別情報を取得する第２取得部３０３３、乗合移動体の１日の運行における必要乗車人員数と、乗合移動体の１日の運行における乗車希望人数に基づいて、乗合移動体の運行の可否を判定する判定部３０３４及び運行の可否を通知し、乗車希望ユーザに対して乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金する課金処理部３０３５を備える。【選択図】図２

Description

本発明は、一般貸切旅客自動車運送事業に供される運行管理装置、運行管理方法及び運行管理プログラムに関する。

路線バス等の乗合自動車による公共交通機関は、予め定められた運行ルートを予め定められた時刻で運行される。したがって、例えば、過疎地域において、路線バスに乗車する乗客がいないような場合であっても、事業者は、予め定められた運行ルート・時刻で路線バスを運行させる必要があり、旅客輸送の効率向上の妨げとなっていた。これに対して、都市部で運行される路線バスは、特に朝夕の時間帯等において混雑していることが多く、旅客輸送の効率は高いものの乗客の全員が着席することは困難であった。

一方で、ユーザからの運送サービスの予約情報に基づいて運行される車両が知られている。例えば、特許文献１には、所定のエリア内の複数の利用者側から入力される車両利用日時、場所、目的地および単独／乗合希望情報等の複数のサービス予約情報に基づいて、車両が運行される技術が開示されている。この技術では、複数の利用者に対して複数の車両の中の同一の車両を配車可能であるか否かが判断され、同一の車両を配車可能である場合に、予約受付情報が対応する複数の利用者へそれぞれ提供される。

また、特許文献２には、複数の利用者からの要望に基づいてオンデマンド車両の運行スケジュールが作成される技術が開示されている。この技術では、それぞれの利用者によって指定された希望乗車時間帯及び希望降車時間帯の組み合わせを考慮して運行スケジュールが決定される。そうとすると、利用者の都合に応じて長さが増減される希望乗車時間帯及び希望降車時間帯を有効に組み合わせて活用することができ、利用者の利便性を損なうことなく運行便数の増加を適切に抑制することができる。

特開２００１－２２９４９５号公報 特許第５９２８５８８号公報

従来から知られている、ユーザからの運送サービスの予約情報に基づいて運行される車両では、例えば、特許文献１に記載の技術のように、複数の利用者に対して複数の車両の中の同一の車両を配車可能である場合に該車両が運行されるとすると、ユーザの要望に応じて利便性良く車両を運行させることが困難となり得る。また、この場合、仮に、全てのユーザの要望を満たそうとすると、多くの車両が必要となり、事業者の採算性が悪化したり、ユーザが負担する運賃が増大したりする虞がある。つまり、旅客輸送における、乗車ユーザの利便性と事業者の採算性とを確保することが困難であった。

ここで、特許文献２に記載の技術によれば、それぞれの利用者によって指定された希望乗車時間帯及び希望降車時間帯の組み合わせを考慮して運行スケジュールが決定されることで、利用者の利便性が損なわれてしまう事態が抑制されるようにも思われるが、これら希望乗車時間帯及び希望降車時間帯は或る範囲をもった時間的長さであるため、やはり、ユーザの要望に応じて利便性良く車両を運行させることが困難となり得る。一方で、都市部等では、所定の２つの地点間の旅客輸送ニーズが顕在化している場合が多い。そして、このような旅客輸送ニーズに応える形で路線バスが運行されている。しかしながら、都市部で運行される路線バスは、特に朝夕の時間帯等において混雑していることが多く、乗客の全員が着席することは困難であった。つまり、このような路線バスは、乗車ユーザの利便性は比較的高いものの乗車ユーザの快適性が低く、また、同一の運賃にもかかわらず着席できる乗客と着席できない乗客が存在するように、乗車ユーザに対する不公平感が生じていた。

本開示の目的は、旅客輸送における、乗車ユーザの利便性及び快適性と、事業者の採算性と、を確保することができる技術を提供することにある。

本開示の運行管理装置は、ユーザが乗車可能な乗合移動体の運行を管理する運行管理装置である。そして、この運行管理装置は、所定の事業者によって予め定められた地点である所定の第１地点と所定の第２地点との間を前記乗合移動体が１日に複数回往復するように、該事業者によって予め定められた運行計画を取得することと、所定のインタフェースを介して、前記運行計画を複数の前記ユーザに対して閲覧可能に提供することと、前記運行計画に基づいて運行される予定の前記乗合移動体に対する前記ユーザからの乗車希望、及び該乗車希望をしたユーザである乗車希望ユーザを特定するための該乗車希望ユーザについての所定の識別情報を取得することと、前記運行計画に基づいて運行される予定の前記乗合移動体について、１日の運行において必要な乗車人員の延べ人数である必要乗車人員数と、１日の運行における前記乗車希望ユーザの延べ人数である乗車希望人数と、に基づいて、前記乗合移動体の運行の可否を判定することと、前記乗車希望ユーザに前記乗合移動体の運行の可否を通知することと、前記乗車希望人数が前記必要乗車人員数以上であって前記乗合移動体の運行が決定された場合に、前記乗車希望ユーザに対して、該乗車希望ユーザが前記乗合移動体に乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金することと、を実行する制御部を備える。

上記の運行管理装置では、例えば、貸切バスによる旅客輸送ニーズが存在する区間（第１地点と第２地点との間）に、一般貸切旅客自動車運送事業の事業者等によって運行計画が予め定められる。そして、制御部は、このような運行計画を取得し、それを複数のユーザに対して閲覧可能に提供することで、該運行計画に基づいて運行される乗合移動体に対する乗車希望を募ることができる。更に、制御部は、必要乗車人員数と乗車希望人数とを比較し、乗車希望人数が必要乗車人員数以上である場合に、乗合移動体の運行を決定する。ここで、ユーザは、提供された運行計画に基づいて、例えば、自身が希望する区間および時間を選択して乗車希望をすることができ、且つ該乗車希望に対する運行の可否が通知されるため、ユーザの利便性が向上する。また、上記の制御部は、乗車希望ユーザに対して、乗車日の前日までに月極めの乗車料金を課金する。このような課金処理によれば、乗車ユーザは、月極めの乗車料金を定期券のように予め納めることで、乗車の都度に料金を精算する必要がなくなるため、ユーザの利便性が向上する。一方、事業者の視点からみると、事業の運転資金を予め集めることができるため、事業を安定して経営することができる。そして、このような処理に基づいて運行される乗合移動体によれば、乗客の全員が着席することができるため、乗車ユーザの快適性を確保することができるとともに、乗車ユーザに対する不公平感も生じない。

そして、上記の運行管理装置において、前記乗合移動体は、貸切バスであって、前記制御部は、前記貸切バスに対する所定の運賃計算式に基づいて算出される前記貸切バスの１日の運行における運賃の総額の下限である下限総額を、該運賃計算式と前記貸切バスの１日の運行における延べ席数とに基づいて算出される、前記第１地点と前記第２地点との間の往復における往路又は復路の１席あたりの運賃の上限額で除することで、前記必要乗車人員数を算出してもよい。これによれば、１席あたりの運賃の上限額が予め定められるため、ユーザの利便性が向上するとともに、ユーザの経済性にも貢献し得る。一方、事業者の視点からみると、上述した判定とあわせて採算性を確保したうえで乗合移動体の運行を決定することができる。

また、以上に述べた運行管理装置において、前記制御部は、ソーシャル・ネットワーキング・サービスに係るユーザ生成コンテンツの中から、所定の２つの地点間の交通に関連する所定のタグが付けられた前記ユーザ生成コンテンツである第１コンテンツを取得するとともに、前記第１コンテンツから推定される旅客輸送ニーズに基づいて定められた前記運行計画を取得してもよい。これによれば、所定の２つの地点間の旅客輸送ニーズを迅速に且つ比較的簡単に取得することができる。そして、第１コンテンツに基づいて運行計画が設定されることで、該第１コンテンツを投稿したユーザのニーズに直接応えることができ、以て、ユーザの利便性が向上する。

そして、この場合、前記制御部は、前記第１コンテンツに基づいて定められた前記運行計画の情報を表す前記ユーザ生成コンテンツである第２コンテンツを生成し、該第２コンテンツを前記第１コンテンツに対する返答として投稿してもよい。これによれば、ユーザは、自身が使い慣れたサービスプラットフォームを介してタイムリーに、且つ自身の投稿に対する返答で直接的に運行計画に関する情報を取得することができるため、ユーザの利便性が向上する。また、事業者は、ユーザのニーズに返答する形で、運行計画を効果的にユーザに周知させることができ、結果として、該運行計画に基づいて運行される乗合移動体の乗客を集客し易くなる。更に、前記制御部は、前記第２コンテンツが返答として投稿された前記第１コンテンツを投稿した投稿者から前記乗車希望を取得した場合、該投稿者に対して前記乗車料金の割引のインセンティブを付与してもよい。これによれば、ソーシャル・ネットワーキング・サービス（ＳＮＳ）を利用するユーザに対して、第１コンテンツを投稿する動機付けを行うことができるとともに、該第１コンテンツから推定される旅客輸送ニーズに応えて運行される乗合移動体への乗車の動機付けを行うことができる。

また、本開示は、コンピュータによる運行管理方法の側面から捉えることができる。すなわち、本開示の運行管理方法は、ユーザが乗車可能な乗合移動体の運行を管理する運行管理方法であって、コンピュータが、所定の事業者によって予め定められた地点である所定の第１地点と所定の第２地点との間を前記乗合移動体が１日に複数回往復するように、該事業者によって予め定められた運行計画を取得することと、所定のインタフェースを介して、前記運行計画を複数の前記ユーザに対して閲覧可能に提供することと、前記運行計画に基づいて運行される予定の前記乗合移動体に対する前記ユーザからの乗車希望、及び該乗車希望をしたユーザである乗車希望ユーザを特定するための該乗車希望ユーザについての所定の識別情報を取得することと、前記運行計画に基づいて運行される予定の前記乗合移動体について、１日の運行において必要な乗車人員の延べ人数である必要乗車人員数と、１日の運行における前記乗車希望ユーザの延べ人数である乗車希望人数と、に基づいて、前記乗合移動体の運行の可否を判定することと、前記乗車希望ユーザに前記乗合移動体の運行の可否を通知することと、前記乗車希望人数が前記必要乗車人員数以上であって前記乗合移動体の運行が決定された場合に、前記乗車希望ユーザに対して、該乗車希望ユーザが前記乗合移動体に乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金することと、を実行する。

また、本開示は、運行管理プログラムの側面から捉えることができる。すなわち、本開示の運行管理プログラムは、ユーザが乗車可能な乗合移動体の運行を管理する運行管理プログラムであって、コンピュータに、所定の事業者によって予め定められた地点である所定の第１地点と所定の第２地点との間を前記乗合移動体が１日に複数回往復するように、該事業者によって予め定められた運行計画を取得することと、所定のインタフェースを介して、前記運行計画を複数の前記ユーザに対して閲覧可能に提供することと、前記運行計画に基づいて運行される予定の前記乗合移動体に対する前記ユーザからの乗車希望、及び該乗車希望をしたユーザである乗車希望ユーザを特定するための該乗車希望ユーザについての所定の識別情報を取得することと、前記運行計画に基づいて運行される予定の前記乗合移動体について、１日の運行において必要な乗車人員の延べ人数である必要乗車人員数と、１日の運行における前記乗車希望ユーザの延べ人数である乗車希望人数と、に基づいて、前記乗合移動体の運行の可否を判定することと、前記乗車希望ユーザに前記乗合移動体の運行の可否を通知することと、前記乗車希望人数が前記必要乗車人員数以上であって前記乗合移動体の運行が決定された場合に、前記乗車希望ユーザに対して、該乗車希望ユーザが前記乗合移動体に乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金することと、を実行させる。

本開示によれば、旅客輸送における、乗車ユーザの利便性及び快適性と、事業者の採算性と、を確保することができる。

第１実施形態における情報処理システムの概略構成を示す図である。 第１実施形態における、情報処理システムに含まれるサーバの構成要素をより詳細に示すとともに、サーバと通信を行うユーザ端末の構成要素を示した図である。 第１実施形態における運行計画を例示する図である。 乗車希望を入力するためのインタフェースを例示する第１の図である。 乗車希望を入力するためのインタフェースを例示する第２の図である。 第１実施形態における情報処理システムの動作の流れを例示する図である。 第２実施形態における情報処理システムの動作の流れを例示する図である。 第２実施形態における第１コンテンツを説明するための図である。 第２実施形態における第２コンテンツを説明するための図である。

以下、図面に基づいて、本開示の実施の形態を説明する。以下の実施形態の構成は例示であり、本開示は実施形態の構成に限定されない。

＜第１実施形態＞
第１実施形態における情報処理システムの概要について、図１を参照しながら説明する。図１は、本実施形態における情報処理システムの概略構成を示す図である。本実施形態に係る情報処理システム１００は、ネットワーク２００と、サーバ３００と、ユーザ端末４００と、を含んで構成される。なお、本実施形態における情報処理システム１００は、ユーザが乗車可能な乗合移動体の運行を管理するためのシステムであって、該乗合移動体の運行の管理は、サーバ３００によって実行される。また、本実施形態では、上記の乗合移動体は、一般貸切旅客自動車運送事業における貸切バスである。

ネットワーク２００は、例えば、ＩＰネットワークである。ネットワーク２００は、ＩＰネットワークであれば、無線であっても有線であっても無線と有線の組み合わせであってもよく、例えば、無線による通信であれば、ユーザ端末４００は、無線ＬＡＮアクセスポイント（不図示）にアクセスし、ＬＡＮやＷＡＮを介してサーバ３００と通信してもよい。また、ネットワーク２００は、これらの例に限られず、例えば、公衆交換電話網や、光回線、ＡＤＳＬ回線、衛星通信網などであってもよい。

サーバ３００は、ネットワーク２００を介して、ユーザ端末４００と接続される。なお、図１において、説明を簡単にするために、サーバ３００は１台、ユーザ端末４００は４台示してあるが、これらに限定されないことは言うまでもない。

サーバ３００は、データの取得、生成、更新等の演算処理及び加工処理のための処理能力のあるコンピュータ機器であればどの様な電子機器でもよく、例えば、パーソナルコンピュータ、サーバ、メインフレーム、その他電子機器であってもよい。すなわち、サーバ３００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納されている。

また、サーバ３００は、本実施形態に係る情報処理システム１００専用のソフトウェアやハードウェア、ＯＳ等を設けずに、クラウドサーバによるＳａａＳ（Software as a Service）、Ｐａａｓ（Platform as a Service）、ＩａａＳ（Infrastructure as a Service）を適宜用いてもよい。

ユーザ端末４００は、情報処理システム１００を利用するユーザが保有する携帯端末等の電子機器であればよく、例えば、携帯端末、タブレット端末、スマートフォン、ウェアラブル端末、パーソナルコンピュータ等、その他端末機器であってもよい。

次に、図２に基づいて、主にサーバ３００の構成要素の詳細な説明を行う。図２は、第１実施形態における、情報処理システム１００に含まれるサーバ３００の構成要素をより詳細に示すとともに、サーバ３００と通信を行うユーザ端末４００の構成要素を示した図である。

サーバ３００は、機能部として通信部３０１、記憶部３０２、制御部３０３を有しており、補助記憶装置に格納されたプログラムを主記憶装置の作業領域にロードして実行し、プログラムの実行を通じて各機能部等が制御されることによって、各機能部における所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

ここで、通信部３０１は、サーバ３００をネットワーク２００に接続するための通信インタフェースである。通信部３０１は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。サーバ３００は、通信部３０１を介して、ユーザ端末４００やその他の外部装置と通信可能に接続される。

記憶部３０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部３０３によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部３０３において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。また、記憶部３０２は、ユーザ端末４００等から送信されたデータを記憶する。なお、サーバ３００は、通信部３０１を介してユーザ端末４００等から送信されたデータを取得する。更に、記憶部３０２には、後述する運行計画や運賃計算式が記憶される。

制御部３０３は、サーバ３００が行う制御を司る機能部である。制御部３０３は、ＣＰＵなどの演算処理装置によって実現することができる。制御部３０３は、更に、第１取得部３０３１と、提供部３０３２と、第２取得部３０３３と、判定部３０３４と、課金処理部３０３５と、の５つの機能部を有して構成される。各機能部は、記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

第１取得部３０３１は、所定の第１地点と所定の第２地点との間を貸切バスが１日に複数回往復するように定められた運行計画を取得する。このような運行計画は、一般貸切旅客自動車運送事業の事業者によって予め定められる。そして、第１取得部３０３１は、事業者の端末等から送信された運行計画を取得し、これをサーバ３００の記憶部３０２に記憶させる。

ここで、本実施形態における運行計画について、図３に基づいて説明する。図３は、本実施形態における運行計画を例示する図である。本実施形態では、図３（ａ）に示すように、第１駅（本開示の第１地点）と第２駅（本開示の第２地点）との間を貸切バスが運行する。なお、鉄道の駅である第１駅および第２駅は都市部に設けられた駅である。そして、これら駅は、鉄道で直接結ばれていないため、バスによる旅客輸送ニーズが存在する。また、第１駅と第２駅との距離は、例えば、７．７ｋｍである。

そして、本実施形態では、２台のバスが、朝の通勤・通学の時間帯に第１駅と第２駅との間をそれぞれ２往復、夜の通勤・通学の時間帯に第１駅と第２駅との間をそれぞれ２往復する。この場合、朝の通勤・通学の時間帯における貸切バスの運行スケジュールが図３（ｂ）に、夜の通勤・通学の時間帯における貸切バスの運行スケジュールが図３（ｃ）に例示される。図３（ｂ）、（ｃ）に示されるように、第１駅と第２駅との間の所要時間は１５分であって、往復のための折り返しの空き時間が、運転手の休憩や渋滞による遅延を考慮して１５分とされている。このような運行スケジュールでは、営業所と第１駅との間の回送運行を考慮しても１人の運転手による連続運転が４時間を超えないように設定されており、該運転手の良好な労働環境が確保され得る。なお、営業所と第１駅との間の距離は、３０ｋｍであって、片道の回送運行の時間は３０分である。

そして、図２に戻って、提供部３０３２は、所定のインタフェースを介して、上記の運行計画を複数のユーザに対して閲覧可能に提供する。ここで、提供部３０３２は、運行計画を所定のウェブページに表示させることで、該運行計画を複数のユーザに対して閲覧可能に提供することができる。ただし、提供部３０３２による運行計画の提供をこれに限定する意図はなく、運行計画は、ＬＩＮＥ（登録商標）、Ｔｗｉｔｔｅｒ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）、及びＩｎｓｔａｇｒａｍ（登録商標）等のソーシャル・ネットワーキング・サービス（ＳＮＳ）を介して提供されてもよいし、所定の広告媒体を介して提供されてもよい。

第２取得部３０３３は、上記の運行計画に基づいて運行される貸切バスに対するユーザからの乗車希望を取得する。このとき、第２取得部３０３３は、上記の乗車希望をしたユーザである乗車希望ユーザを特定するための該乗車希望ユーザについての所定の識別情報も取得する。そして、第２取得部３０３３は、取得した乗車希望およびその乗車希望をした乗車希望ユーザの識別情報をサーバ３００の記憶部３０２に記憶させる。なお、上記の識別情報とは、例えば、乗車希望ユーザのユーザＩＤであって、該ユーザＩＤには、該乗車希望ユーザの氏名、住所、電話番号、電子メールアドレス等が紐づけられている。

ここで、第２取得部３０３３は、上記の乗車希望および識別情報を、乗車希望ユーザのユーザ端末４００から送信された情報として取得することができる。

本実施形態におけるユーザ端末４００は、機能部として通信部４０１、入出力部４０２、記憶部４０３を有している。通信部４０１は、ユーザ端末４００をネットワーク２００に接続するための通信インタフェースであり、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。入出力部４０２は、通信部４０１を介して外部から送信されてきた情報等を表示させたり、通信部４０１を介して外部に情報を送信する際に当該情報を入力したりするための機能部である。記憶部４０３は、サーバ３００の記憶部３０２と同様に主記憶装置と補助記憶装置を含んで構成される。

入出力部４０２は、更に、表示部４０２１、操作入力部４０２２、画像・音声入出力部４０２３を有している。表示部４０２１は、各種情報を表示する機能を有し、例えば、ＬＣＤ（Liquid Crystal Display）ディスプレイ、ＬＥＤ（Light Emitting Diode）ディスプレイ、ＯＬＥＤ（Organic Light Emitting Diode）ディスプレイ等により実現される。操作入力部４０２２は、ユーザからの操作入力を受け付ける機能を有し、具体的には、タッチパネル等のソフトキーあるいはハードキーにより実現される。画像・音声入出力部４０２３は、静止画や動画等の画像の入力を受け付ける機能を有し、具体的には、Charged-Coupled Devices（ＣＣＤ）、Metal-oxide-semiconductor（ＭＯＳ）あるいはComplementary Metal-Oxide-Semiconductor（ＣＭＯＳ）等のイメージセンサを用いたカメラにより実現される。また、画像・音声入出力部４０２３は、音声の入出力を受け付ける機能を有し、具体的には、マイクやスピーカーにより実現される。

ユーザは、このように構成されたユーザ端末４００を用いて、上記の乗車希望をサーバ３００に送信することができる。図４は、乗車希望を入力するためのインタフェースを例示する第１の図であって、図５は、乗車希望を入力するためのインタフェースを例示する第２の図である。図４および図５に例示する画面ＳＣ１は、ユーザ端末４００の表示部４０２１に表示される。なお、ユーザは、ユーザ端末４００に予めインストールされた所定のアプリを起動することで、または、サーバ３００が提供するウェブページにアクセスすることで、画面ＳＣ１を表示させることができる。

そして、図４に例示する画面ＳＣ１には、ユーザＩＤ表示フィールドＳＣ１１、および乗車希望選択フィールドＳＣ１２が示される。ここで、本実施形態の情報処理システム１００を利用するユーザが事前にシステムへのユーザ登録を行うことで、ユーザＩＤ表示フィールドＳＣ１１に乗車希望を選択しようとしているユーザのＩＤが表示されることになる。そして、ユーザは、操作入力部４０２２を用いて、例えば、乗車を希望する時間帯と地点に対する出発時間の選択肢をプルダウンから選択することで、乗車希望を選択することができる。

図５は、ユーザによって乗車希望が選択された状態を示す図であって、図５に例示する画面ＳＣ１には、ユーザＩＤ表示フィールドＳＣ１１、乗車希望選択フィールドＳＣ１２に加えて、ユーザの選択に対するメッセージＳＣ１３、キャンセルボタンＳＣ１４、および送信ボタンＳＣ１５が示される。図５に示す例では、ユーザが、第１駅を７：００に出発するバスに乗車することを希望していて、ユーザの選択に対するメッセージＳＣ１３には、第２駅への到着予定時間や未だバスの運行が決定していない旨が表示される。そして、ユーザは、キャンセルボタンＳＣ１４を押下することで乗車希望の選択をやり直すことができ、送信ボタンＳＣ１５を押下することで乗車希望を送信することができる。そうすると、第２取得部３０３３は、乗車希望ユーザのユーザ端末４００から送信された乗車希望および該乗車希望ユーザの識別情報を取得することができる。

そして、図２に戻って、判定部３０３４は、上記の貸切バスの１日の運行において必要な乗車人員の延べ人数である必要乗車人員数と、上記の貸切バスの１日の運行における乗車希望ユーザの延べ人数である乗車希望人数と、に基づいて、貸切バスの運行の可否を判定する。そして、判定部３０３４は、乗車希望ユーザに貸切バスの運行の可否を通知する。なお、このような判定部３０３４の処理の詳細は、後述する。

課金処理部３０３５は、貸切バスの運行が決定された場合に、乗車希望ユーザに対して、該乗車希望ユーザが貸切バスに乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金する。

なお、制御部３０３が、第１取得部３０３１、提供部３０３２、第２取得部３０３３、判定部３０３４、および課金処理部３０３５の処理を実行することで、本開示に係る制御部として機能する。

ここで、本実施形態における情報処理システム１００の動作の流れについて説明する。図６は、本実施形態における情報処理システム１００の動作の流れを例示する図である。図６では、本実施形態における情報処理システム１００におけるサーバ３００とユーザ端末４００との間の動作の流れ、およびサーバ３００とユーザ端末４００とが実行する処理を説明する。

本実施形態では、先ず、サーバ３００が、運行計画を取得する（Ｓ１０１）。サーバ３００は、一般貸切旅客自動車運送事業の事業者によって予め定められ、該事業者の端末等から送信された運行計画を取得し、これを記憶部３０２に記憶させる。

そして、サーバ３００は、取得した運行計画を複数のユーザに対して閲覧可能に提供する（Ｓ１０２）。サーバ３００は、所定のインタフェースを介して、運行計画を複数のユーザに対して送信することができる。

ユーザ端末４００は、サーバ３００から送信された運行計画を取得する（Ｓ１０３）。そして、ユーザ端末４００は、乗車希望ユーザから乗車希望の入力を受け付ける（Ｓ１０４）。上述したように、乗車希望ユーザは、乗車希望を入力するためのインタフェースを介してユーザ端末４００に乗車希望を入力し、該乗車希望および該乗車希望ユーザの識別情報をユーザ端末４００からサーバ３００に送信することができる。

サーバ３００は、ユーザ端末４００から送信された乗車希望および乗車希望ユーザの識別情報を取得する（Ｓ１０５）。このとき、サーバ３００は、運行計画を提供した複数のユーザのうち、該運行計画で運行される予定の所定の貸切バスに対して乗車希望をした乗車希望ユーザの複数から上記の情報を取得することができる。

そして、サーバ３００は、必要乗車人員数および乗車希望人数を算出する（Ｓ１０６）。ここで、サーバ３００は、Ｓ１０５の処理で取得した乗車希望に基づいて、貸切バスの１日の運行における乗車希望ユーザの延べ人数である乗車希望人数を算出することができる。例えば、上記の図３において説明を簡単にするために、貸切バスの１日の運行が朝の通勤・通学の時間帯の貸切バスＡの運行のみであって、且つ該貸切バスＡの乗客座席数が４５席であると仮定する。この場合、貸切バスの１日の運行（第１駅と第２駅との間を２往復）における乗客座席の延べ席数は１８０席となる。そして、仮に、第１駅と第２駅との間を２往復するとき、つまり、第１駅と第２駅との間を４回営業運行するときの各回の乗車希望ユーザの人数が４０名であるとすると、乗車希望人数が１６０名であると算出される。

また、サーバ３００は、貸切バスに対する所定の運賃計算式に基づいて算出される貸切バスの１日の運行における運賃の総額の下限である下限総額を、１席あたりの運賃の上限額で除することで、必要乗車人員数を算出する。ここで、１席あたりの運賃の上限額は、第１駅と第２駅との間の往復における往路又は復路の１席あたりの運賃の上限額であって、上記の運賃計算式と貸切バスの１日の運行における延べ席数とに基づいて算出される。このような必要乗車人員数の算出について、以下に詳しく説明する。

上述した貸切バスに対する所定の運賃計算式は、下記式１によって表される。
運賃額＝時間あたり運賃額×算出時間 ＋ キロあたり運賃額×走行距離 ・・・式１
ここで、式１における「時間あたり運賃額」および「キロあたり運賃額」は、貸切バスの乗客座席数に応じて上限と下限が設定されており、上述したとおり貸切バスＡの乗客座席数が４５席である場合、「時間あたり運賃額」の上限が８６６０円、下限が５９９０円であって、「キロあたり運賃額」の上限が１７０円、下限が１２０円である。また、式１における「算出時間」は、営業区間における営業運行の時間と、営業所と営業区間との間の回送運行の時間と、を含んだ時間であって、上述した仮定に基づくと、「算出時間」が、営業運行の時間である２時間と回送運行の時間である１時間とを合算した３時間と算出される。また、式１における「走行距離」は、営業区間における営業運行の走行距離と、営業所と営業区間との間の回送運行の走行距離と、を含んだ距離であって、上述した仮定に基づくと、「算出時間」が、営業運行の距離である３０．８ｋｍ（７．７ｋｍ×４回）と回送運行の距離である６０ｋｍ（３０ｋｍ×２回）とを合算した９０．８ｋｍと算出される。

そうすると、上記の下限総額が下記式２によって表される。
下限総額＝５９９０円×３時間 ＋ １２０円×９０．８ｋｍ ・・・式２
そして、式２に基づいて算出される額に所定の税率を乗算することで、下限総額が３１７５０円と算出される。

また、貸切バスの１日の運行における運賃の総額の上限である上限総額が下記式３によって表される。
上限総額＝８６６０円×３時間 ＋ １７０円×９０．８ｋｍ ・・・式３
そして、式３に基づいて算出される額に所定の税率を乗算することで、上限総額が４５５６０円と算出される。そうすると、上記の１席あたりの運賃の上限額は、この上限総額を上記の延べ席数（１８０席）で除することで、２５０円と算出される。

以上の場合、サーバ３００は、下限総額（３１７５０円）を１席あたりの運賃の上限額（２５０円）で除することで、必要乗車人員数を１２７名と算出する。

次に、サーバ３００は、上述したＳ１０６の処理で算出した必要乗車人員数および乗車希望人数に基づいて、貸切バスの運行の可否を判定する（Ｓ１０７）。このとき、サーバ３００は、乗車希望人数が必要乗車人員数以上である場合に貸切バスの運行を決定する。そして、サーバ３００は、判定した運行の可否を乗車希望ユーザのユーザ端末４００に送信することで、運行の可否を乗車希望ユーザに通知し（Ｓ１０８）、ユーザ端末４００が、サーバ３００から送信された運行の可否に関する情報を取得する（Ｓ１０９）。

このような処理によれば、ユーザは、ユーザ端末４００から自身が希望する区間および時間を選択して乗車希望を送信することができ、且つ該乗車希望に対する運行の可否をユーザ端末４００を介して取得することができるため、ユーザの利便性が向上する。また、上述した例では、１席あたりの運賃の上限額が予め定められるため、ユーザの利便性が向上する。更に、その上限額が比較的安価であるため、ユーザの経済性にも貢献し得る。そして、このような貸切バスによれば、乗客の全員が着席することができるため、乗車ユーザの快適性を確保することができるとともに、乗車ユーザに対する不公平感も生じない。

一方、事業者の視点からみると、乗車希望人数が必要乗車人員数以上である場合に貸切バスの運行を決定することができるため、従来の路線バス（乗車する乗客がいないような場合であっても予め定められた運行ルート・時刻で運行させる必要がある）と比較すると、採算性を確保し易くなる。

そして、サーバ３００は、貸切バスの運行が決定された場合に（Ｓ１１０において肯定判定される場合に）、乗車希望ユーザに対して課金処理を実行する（Ｓ１１１）。ここで、サーバ３００は、乗車希望ユーザに対して、該乗車希望ユーザが貸切バスに乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金する。この場合、サーバ３００は、上記の処理の中で算出される運賃とユーザの乗車日とに基づいて月極めの乗車料金を算出し、該乗車料金の決済情報を乗車希望ユーザのユーザ端末４００に送信することで、課金処理を実行することができる。なお、上記の決済情報は、クレジットカード決済に基づく情報であってもよいし、銀行振込に関する情報であってもよい。

このような課金処理によれば、乗車ユーザは、月極めの乗車料金を定期券のように予め納めることで、乗車の都度に料金を精算する必要がなくなるため、ユーザの利便性が向上する。一方、事業者の視点からみると、事業の運転資金を予め集めることができるため、事業を安定して経営することができる。

以上に述べた情報処理システム１００によれば、旅客輸送における、乗車ユーザの利便性及び快適性と、事業者の採算性と、を確保することができる。

＜第２実施形態＞
上述した第１実施形態では、例えば、鉄道で直接結ばれていないためバスによる旅客輸送ニーズが存在する第１駅と第２駅との間に、一般貸切旅客自動車運送事業の事業者が、貸切バスの運行計画を設定する。これに対して、本実施形態では、情報処理システム１００のサーバ３００が、ソーシャル・ネットワーキング・サービスに係るユーザ生成コンテンツから推定される旅客輸送ニーズに基づいて定められた運行計画を取得する。

詳しくは、サーバ３００は、ソーシャル・ネットワーキング・サービス（ＳＮＳ）に係るユーザ生成コンテンツの中から、所定の２つの地点間の交通に関連する所定のタグが付けられたユーザ生成コンテンツである第１コンテンツを取得する。そして、第１コンテンツから推定される旅客輸送ニーズに基づいて定められた運行計画を取得する。なお、本実施形態では、Ｔｗｉｔｔｅｒ（登録商標）を用いた例について、以下に説明する。

ここで、図７は、本実施形態における情報処理システム１００の動作の流れを例示する図である。図７では、本実施形態における情報処理システム１００における各構成要素間の動作の流れ、および各構成要素が実行する処理を説明する。なお、図７に示す各処理において、上記の図６に示した処理と実質的に同一の処理については、同一の符号を付してその詳細な説明を省略する。

本実施形態では、ユーザ端末４００において、Ｔｗｉｔｔｅｒ（登録商標）に投稿するためのコンテンツが生成される（Ｓ１０１１）。ユーザは、ユーザ端末４００に予めインストールされたＴｗｉｔｔｅｒ（登録商標）のアプリを用いてユーザ生成コンテンツを生成し、それを、ソーシャル・ネットワーキング・サービスを提供するＳＮＳサーバに投稿することができる。

ここで、上記のユーザ生成コンテンツのうち、所定の２つの地点間の交通に関連する所定のタグが付けられたユーザ生成コンテンツが、第１コンテンツとして定義される。ここで、ユーザは、例えば、都市部に設けられた鉄道の駅である第３駅と第４駅との間を鉄道または路線バスで定期的に移動するときに、これら交通機関が乗客で混雑していることに不満をもっていたとすると、それをＴｗｉｔｔｅｒ（登録商標）に投稿することができる。図８は、本実施形態における第１コンテンツを説明するための図である。上述したように、ユーザは自身のＴｗｉｔｔｅｒ（登録商標）アカウントを用いて上記の交通に関する情報を発信することができ、図８に例示する画面ＳＣ２には、ユーザによるツイートＳＣ２１、および該ツイートに含まれるタグ情報ＳＣ２２が示される。図８に示す例では、ユーザが、乗客による混雑の状況をユーザ生成コンテンツとしてツイートしている（ＳＣ２１）。ここで、上記のタグ情報ＳＣ２２は、上記の交通に関する情報を発信するための予め定められた任意の標識であって、ユーザによって入力される。図８に示す例では、タグ情報ＳＣ２２が、「第３駅と第４駅間の鉄道」に関する情報を表している。そうすると、このようなユーザ生成コンテンツは、所定の２つの地点間の交通に関連するタグが付けられているため、第１コンテンツとして定義される。

そして、図７に戻って、サーバ３００は、第１コンテンツを取得する（Ｓ１０１２）。ここで、サーバ３００は、例えば、Ｔｗｉｔｔｅｒ（登録商標）の各種データを取得するＴｗｉｔｔｅｒ（登録商標） ＡＰＩを用いて、第１コンテンツを取得することができる。このとき、サーバ３００は、ＳＮＳサーバにアクセスし、該ＳＮＳサーバに格納されているユーザ生成コンテンツの中から上記のタグが含まれるコンテンツを第１コンテンツとして取得することができる。

そして、サーバ３００は、第１コンテンツから推定される旅客輸送ニーズに基づいて定められた運行計画を取得する（Ｓ１０１）。このとき、サーバ３００は、例えば、「第３駅と第４駅間の交通」に関連するタグが付けられた全ての第１コンテンツのツイートに対して、周知の自然言語処理技術を用いて頻出単語を抽出することができる。そして、この頻出単語に、乗客による混雑に関する情報が含まれる場合には、第３駅と第４駅間に旅客輸送ニーズが存在すると推定することができる。そうすると、この旅客輸送ニーズに基づいて、貸切バスによる運行計画が設定される。なお、このときの運行計画は、一般貸切旅客自動車運送事業の事業者によって設定されてもよいし、サーバ３００によって自動で設定されてもよい。

このような処理によれば、所定の２つの地点間の旅客輸送ニーズを迅速に且つ比較的簡単に取得することができる。そのため、一般貸切旅客自動車運送事業の事業者は、旅客輸送ニーズを調査するためのコストを削減することができる。また、第１コンテンツに基づいて運行計画が設定されることで、該第１コンテンツを投稿したユーザのニーズに直接応えることができ、以て、ユーザの利便性が向上する。

次に、サーバ３００は、第１コンテンツに基づいて定められた運行計画の情報を表すユーザ生成コンテンツである第２コンテンツを生成する（Ｓ１０２０）。そして、その第２コンテンツを上記の第１コンテンツに対する返答としてＳＮＳサーバに投稿する。なお、サーバ３００は、例えば、Ｔｗｉｔｔｅｒ（登録商標） ＡＰＩを用いて、上記を自動で投稿することができる。これにより、サーバ３００は、取得した運行計画を、第１コンテンツを投稿した複数のユーザに対して閲覧可能に提供することができる。

ここで、図９は、本実施形態における第２コンテンツを説明するための図である。図９に例示する画面ＳＣ２には、ユーザによるツイートＳＣ２１、および該ツイートに含まれるタグ情報ＳＣ２２に加えて、サーバ３００により自動投稿されたツイートであって、運行計画の情報を表すウェブページを通知するツイートＳＣ２３が示される。サーバ３００は、例えば、Ｔｗｉｔｔｅｒ（登録商標）の各種データを取得するＴｗｉｔｔｅｒ（登録商標） ＡＰＩを用いて、ユーザによるツイートＳＣ２１に対する返答として、このようなウェブページ通知ツイートを自動投稿することができる。このようにして、サーバ３００は、第２コンテンツを第１コンテンツに対する返答としてＳＮＳサーバに投稿する。

そして、図７に戻って、ユーザ端末４００は、第２コンテンツを取得する（Ｓ１０３０）。このとき、第１コンテンツを投稿したユーザのＴｗｉｔｔｅｒ（登録商標）アカウントに通知が送られることで、ユーザは、ユーザ端末４００を操作して第２コンテンツを取得することができる。

このようにして第２コンテンツが取得されると、ユーザは、ユーザ端末４００を用いて、例えば、上記の図９に示したウェブページにアクセスすることで、乗車希望を入力することができる（Ｓ１０４）。

このような処理によれば、ユーザは、自身が使い慣れたＴｗｉｔｔｅｒ（登録商標）などのようなサービスプラットフォームを介してタイムリーに、且つ自身のツイートに対する返答で直接的に運行計画に関する情報を取得することができる。更に、ユーザは、取得した第２コンテンツを経由して簡単に乗車希望を送ることができる。そのため、ユーザの利便性が向上する。また、事業者は、ユーザのニーズに返答する形で、運行計画を効果的にユーザに周知させることができ、結果として、該運行計画に基づいて運行される貸切バスの乗客を集客し易くなる。そのため、事業者は、採算性を確保し易くなる。更に、運行計画の情報を表す第２コンテンツは、第１コンテンツを投稿したユーザをフォローしているフォロワー等のタイムラインに表示され得る。つまり、第２コンテンツが、第１コンテンツを投稿したユーザ以外の第三者にも閲覧可能に提供される。そして、このように第２コンテンツが拡散されることで、事業者は、運行計画を広く周知させることができる。

そして、本実施形態では、Ｓ１１１の課金処理において、第２コンテンツが返答として投稿された第１コンテンツを投稿した投稿者から乗車希望を取得した場合、該投稿者に対して乗車料金の割引のインセンティブを付与してもよい。これによれば、ＳＮＳを利用するユーザに対して、第１コンテンツを投稿する動機付けを行うことができるとともに、該第１コンテンツから推定される旅客輸送ニーズに応えて運行される貸切バスへの乗車の動機付けを行うことができる。

以上に述べた情報処理システム１００によっても、旅客輸送における、乗車ユーザの利便性及び快適性と、事業者の採算性と、を確保することができる。

＜その他の変形例＞
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

上記の実施形態では、乗客座席数が４５席である比較的大型の貸切バスを仮定して、該貸切バスに対する運賃や必要乗車人員数を算出する例を説明したが、本開示の乗合移動体は、乗客座席数が２０席であるマイクロバスであってもよい。この場合にも、上記の実施形態と同様に運行の可否が判定されることで、乗車ユーザの利便性及び快適性と、事業者の採算性と、を確保することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。例えば、課金処理部３０３５をサーバ３００とは別の演算処理装置に形成してもよい。このとき当該別の演算処理装置はサーバ３００と好適に協働可能に構成される。また、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１００・・・情報処理システム
２００・・・ネットワーク
３００・・・サーバ
３０１・・・通信部
３０２・・・記憶部
３０３・・・制御部
４００・・・ユーザ端末

Claims (7)

1. ユーザが乗車可能な乗合移動体の運行を管理する運行管理装置であって、
   所定の事業者によって予め定められた地点である所定の第１地点と所定の第２地点との間を前記乗合移動体が１日に複数回往復するように、該事業者によって予め定められた運行計画を取得することと、
   所定のインタフェースを介して、前記運行計画を複数の前記ユーザに対して閲覧可能に提供することと、
   前記運行計画に基づいて運行される予定の前記乗合移動体に対する前記ユーザからの乗車希望、及び該乗車希望をしたユーザである乗車希望ユーザを特定するための該乗車希望ユーザについての所定の識別情報を取得することと、
   前記運行計画に基づいて運行される予定の前記乗合移動体について、１日の運行において必要な乗車人員の延べ人数である必要乗車人員数と、１日の運行における前記乗車希望ユーザの延べ人数である乗車希望人数と、に基づいて、前記乗合移動体の運行の可否を判定することと、
   前記乗車希望ユーザに前記乗合移動体の運行の可否を通知することと、
   前記乗車希望人数が前記必要乗車人員数以上であって前記乗合移動体の運行が決定された場合に、前記乗車希望ユーザに対して、該乗車希望ユーザが前記乗合移動体に乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金することと、
   を実行する制御部を備える、運行管理装置。
2. 前記乗合移動体は、貸切バスであって、
   前記制御部は、
   前記貸切バスに対する所定の運賃計算式に基づいて算出される前記貸切バスの１日の運行における運賃の総額の下限である下限総額を、該運賃計算式と前記貸切バスの１日の運行における延べ席数とに基づいて算出される、前記第１地点と前記第２地点との間の往復における往路又は復路の１席あたりの運賃の上限額で除することで、前記必要乗車人員数を算出する、
   請求項１に記載の運行管理装置。
3. 前記制御部は、
   ソーシャル・ネットワーキング・サービスに係るユーザ生成コンテンツの中から、所定の２つの地点間の交通に関連する所定のタグが付けられた前記ユーザ生成コンテンツである第１コンテンツを取得するとともに、
   前記第１コンテンツから推定される旅客輸送ニーズに基づいて定められた前記運行計画を取得する、
   請求項１又は請求項２に記載の運行管理装置。
4. 前記制御部は、
   前記第１コンテンツに基づいて定められた前記運行計画の情報を表す前記ユーザ生成コンテンツである第２コンテンツを生成し、該第２コンテンツを前記第１コンテンツに対する返答として投稿する、
   請求項３に記載の運行管理装置。
5. 前記制御部は、
   前記第２コンテンツが返答として投稿された前記第１コンテンツを投稿した投稿者から前記乗車希望を取得した場合、該投稿者に対して前記乗車料金の割引のインセンティブを付与する、
   請求項４に記載の運行管理装置。
6. ユーザが乗車可能な乗合移動体の運行を管理する運行管理方法であって、
   コンピュータが、
   所定の事業者によって予め定められた地点である所定の第１地点と所定の第２地点との間を前記乗合移動体が１日に複数回往復するように、該事業者によって予め定められた運行計画を取得することと、
   所定のインタフェースを介して、前記運行計画を複数の前記ユーザに対して閲覧可能に提供することと、
   前記運行計画に基づいて運行される予定の前記乗合移動体に対する前記ユーザからの乗車希望、及び該乗車希望をしたユーザである乗車希望ユーザを特定するための該乗車希望ユーザについての所定の識別情報を取得することと、
   前記運行計画に基づいて運行される予定の前記乗合移動体について、１日の運行において必要な乗車人員の延べ人数である必要乗車人員数と、１日の運行における前記乗車希望ユーザの延べ人数である乗車希望人数と、に基づいて、前記乗合移動体の運行の可否を判定することと、
   前記乗車希望ユーザに前記乗合移動体の運行の可否を通知することと、
   前記乗車希望人数が前記必要乗車人員数以上であって前記乗合移動体の運行が決定された場合に、前記乗車希望ユーザに対して、該乗車希望ユーザが前記乗合移動体に乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金することと、
   を実行する運行管理方法。
7. ユーザが乗車可能な乗合移動体の運行を管理する運行管理プログラムであって、
   コンピュータに、
   所定の事業者によって予め定められた地点である所定の第１地点と所定の第２地点との間を前記乗合移動体が１日に複数回往復するように、該事業者によって予め定められた運行計画を取得することと、
   所定のインタフェースを介して、前記運行計画を複数の前記ユーザに対して閲覧可能に提供することと、
   前記運行計画に基づいて運行される予定の前記乗合移動体に対する前記ユーザからの乗車希望、及び該乗車希望をしたユーザである乗車希望ユーザを特定するための該乗車希望ユーザについての所定の識別情報を取得することと、
   前記運行計画に基づいて運行される予定の前記乗合移動体について、１日の運行において必要な乗車人員の延べ人数である必要乗車人員数と、１日の運行における前記乗車希望ユーザの延べ人数である乗車希望人数と、に基づいて、前記乗合移動体の運行の可否を判定することと、
   前記乗車希望ユーザに前記乗合移動体の運行の可否を通知することと、
   前記乗車希望人数が前記必要乗車人員数以上であって前記乗合移動体の運行が決定された場合に、前記乗車希望ユーザに対して、該乗車希望ユーザが前記乗合移動体に乗車する乗車日の前日までに該乗車日が属する月内の月極めの乗車料金を課金することと、
   を実行させる運行管理プログラム。

Images