JP2020052925A - 自動車運行管理システム - Google Patents

Abstract

【課題】所定地域内での運行システムについて、運行負荷を低減できるようにしつつ住民同士の親睦を深めることができるようにする。【解決手段】所定地域内に居住する多数のユーザに対して、運行用車両を用いて定時定路運行やデマンド運行のサービスが行われる。運行管理者によって管理される運行管理装置Ｕ１、Ｕ２は、ユーザ端末（乗客）Ｕ３からの定時定路運行やデマンド運行での乗車予約を受け付ける予約受付機能を有する。運行管理装置Ｕ１は、デマンド運行の乗車予約が行われた際に、あらかじめ乗車予約したユーザについて仲間登録されている他のユーザに対して優先的に、相乗りを希望するか否かの問い合わせを行う。【選択図】図３

Description

本発明は、自動車運行管理システムに関するものである。

最近では、カーシェアリングの一種として、ドライバーが保有する自動車を運行用車両として使用して、このドライバーによる運行用車両の運転によって、不特定多数のユーザを対象にした運行サービスを行うことが増加している。このようなサービスを広い地域範囲に渡って行う場合は、運行に用いる運行用車両が多数用意されるのが一般的である。

特許文献１には、多数の運行用車両の中から、乗車要求に応じた適切な運行用車両を選択する手法が提案されている。特許文献２には、運行用車両の選択に際して、サービス提供者の利益あるいは利用者の満足度を向上させる手法が提案されている。

特開２０１４−２３８８３１号公報 特開２０１６−８５７３４号公報

ところで、地方では、高齢化、人口減少等、多くの問題を抱えており、交通空白地域においては、交通弱者は、通院や買い物等になくてはならない移動が奪われている。このため、交通空白地域の人々に必要不可欠な交通手段として、住民が保有する自動車を運行用車両として利用し、また自動車を保有するドライバーを運行用車両の運転者として利用した運行を行う有償運送が着目されている。このような有償運送は、交通空白地域に、単に、必要不可欠な交通手段を提供するだけでなく、豊かな地域の維持、創造を通じて地域の活性化を図る可能性を秘めており、その有効な活用が望まれている。

上記空白地域での有償運送においては、その基本的な運行サービスとして、定時定路運行を行うことが考えられる。この定時定路運行は、路線バスの運行に対応したもので、決められた路線を決められた時間に走行する運行となる。そして、交通の便をより一層向上させるために、定時定路運行の他に、住民の希望によって運行時間、出発地、目的地さらには経由地等を自由に選択できるデマンド運行（タクシー運行に対応）を行うことも考えられる。

ところで、デマンド運行は、ユーザの要望に応じたきめ細かい運行が可能となるので、ユーザにとっては利便性が高くなる。この一方、デマンド運行は、定時定路運行に比して、運行負荷が相対的に大きいものになるのが通常である。すなわち、デマンド運行は、定時定路運行に比して、例えばドライバーへの報酬が高額になったり、運行用車両の利用人数が少なくてその有効活用という点で劣るものとなる。また、デマンド運行は、乗車予約した者のみが乗車することが多いことから、乗り合いを前提とする定時定路運行に比して、住民同士の親睦（交流）を深めるという点でも劣るものとなる。

本発明は以上のような事情を勘案してなされたもので、その目的は、所定地域内での運行システムについて、運行負荷を低減できるようにしつつ住民同士の親睦を深めることのできるようにした自動車運行管理システムを提供することにある。

前記目的を達成するため、本発明にあっては次のような解決手法を採択してある。すなわち、請求項１に記載のように、
所定地域内に居住する多数のユーザに対して、運行用車両を用いて運行サービスを行うための自動車運行管理システムであって、
運行管理者によって管理され、情報処理装置からなる運行管理装置と、
前記運行管理装置に対して通信可能とされ、ユーザに保持される情報処理装置からなるユーザ端末と、
を有し、
前記運行管理装置は、ユーザに関する情報を登録するユーザ登録機能と、ユーザからの乗車予約を受け付ける予約受付機能と、を有し、
前記ユーザ登録に際して、多数のユーザの中から相乗りの仲間を登録する仲間登録を含むようにされ、
前記運行管理装置は、乗車予約を受け付けたときに、乗車予約したユーザについて仲間登録されているユーザのユーザ端末に対して、相乗りを促すための問い合わせを行う相乗り受付機能を有している、
ようにしてある。

上記解決手法によれば、あるユーザが乗車予約した運行について、相乗りを積極的に行わせるようにして、運行負荷を低減させる上で好ましいものとなる。また、相乗りするユーザは、乗車予約したユーザがあらかじめ仲間として登録されている者なので、親しい者同士の乗り合いとなり、車中での会話も弾んで、運行途中での楽しみが増加すると共に親睦をより深めることができ、地域活性化の上でも好ましいものとなる。

上記解決手法を前提とした好ましい態様は、請求項２以下に記載のとおりである。すなわち、
運行サービスとして定時定路運行とデマンド運行とが行われるようにされて、前記運行管理装置は、前記定時定路運行と前記デマンド運行とのうち該デマンド運行について乗車予約されたときにのみ、相乗りを促すための問い合わせを行う、ようにしてある（請求項２対応）。この場合、乗り合いが基本とされる定時定路運行について、不必要に相乗りの勧誘を行うことを防止できる。また、乗車予約したユーザのみでは多くの乗車人数を期待できないデマンド運行について、相乗りを積極的に行わせるようにすることができる。

前記運行管理装置は、相乗りを促すための問い合わせを行う際に、乗車予約された運行に関する情報をも報知するようにされ、
前記報知される乗車予約された運行に関する情報として、少なくとも走行経路と運行時間に関する情報とが含まれる、
ようにしてある（請求項３対応）。この場合、乗車予約された運行内容を報知して、相乗りするか否かの判断を適切に行わせる上で好ましいものとなる。

前記運行管理装置に対して通信可能とされ、運行用車両を運転するドライバーに保持される情報処理装置からなるドライバー端末をさらに有し、
前記運行管理装置は、前記乗車予約された運行に関する情報と該乗車予約された運行に乗車するユーザに関する情報とを、該乗車予約された運行の運転を担当するドライバーの前記ドライバー端末に報知する、
ようにしてある（請求項４対応）。この場合、乗車予約された運行の運転を担当するドライバーは、乗客情報を含む運行の詳細について事前に十分に把握することができ、運行を適切に行う上で好ましいものとなる。

前記運行管理装置に対して通信可能とされ、運行用車両に搭載された情報処理装置からなる車載端末をさらに有し、
前記運行管理装置は、前記乗車予約された運行に関する情報と該乗車予約された運行に乗車するユーザに関する情報とを、該乗車予約された運行に使用される運行用車両の前記車載端末に報知する、
ようにしてある（請求項５対応）。この場合、運行を担当するドライバーは、運行用車両からも運行に関する詳細情報を知得することができ、運行を間違いなく適切に行う上で好ましいものとなる。

前記運行管理装置は、乗車予約したユーザについて仲間登録されているユーザから相乗りの希望がなかったときに、仲間登録されている以外のユーザに対して相乗りを促すための問い合わせを行う、ようにしてある（請求項６対応）。この場合、相乗りする者をより確実に確保する上で好ましいものとなる。

前記ユーザ登録に際して、多数のユーザの中から相乗りを希望しない相乗り不可のユーザを登録するユーザ除外登録を含むようにされ、
前記運行管理装置は、乗車予約したユーザについてユーザ除外登録されているユーザに対しては、相乗りを促すための問い合わせを行わない、
ようにしてある（請求項７対応）。この場合、乗車予約したユーザの意に沿わない者が相乗り者となってしまう事態を防止することができる。

前記運行管理装置は、乗車予約したユーザが相乗りを許可していることを条件として、相乗りを促すための問い合わせを行う、ようにしてある（請求項８対応）。この場合、乗車予約したユーザが相乗りを希望しない状況のときに、不用意に相乗りさせてしまう事態を防止することができる。

本発明によれば、所定地域内での運行システムについて、運行負荷を低減できるようにしつつ住民同士の親睦を深めることができる。

定時定路運行の路線例を示す図。 デマンド運行の一例を示す図。 本発明によるシステム系統例を示す図。 車載端末での表示例を示す図。 各種登録を行うための制御例を示すフローチャート。 運転担当可能なドライバーの登録を行うための制御例を示すフローチャート。 車載端末の操作に伴う制御例を示すフローチャート。 定時定路運行の乗車予約受付に伴う制御例を示すフローチャート。 デマンド運行の乗車予約受付に伴う制御例を示すフローチャート。 デマンド運行に伴う相乗りに関する制御例を示すフローチャート。 ユーザ登録のうち、仲間登録を行う画面例を示す図。

図１は、定時定路運行が行われる路線例を示すものである。図中、Ｄ１は、片道１車線（往復で２車線）の道路である。この道路Ｄ１は、鉄道路線Ｒにおける所定の駅Ｒａを通るもので、この地域ではメインの道路となっている。駅Ｒａの周辺が、この地域で唯一の繁華街となっており、役場、学校等の公的施設の他、病院や歯医者等の医療施設、スーパマーケット、コンビニエンスストア、カラオケ店等々の商業施設や娯楽施設が存在している。

道路Ｄ１に対しては、駅Ｒａから離れた位置において、道路Ｄ２、Ｄ３が連なっている。道路Ｄ２、Ｄ３は、往復で１車線の対面通行用とされたローカルな道路となっている。この道路Ｄ２、Ｄ３沿いの地域は、山間部にあって、周囲の殆どが山や丘となる辺鄙な地域となっている。

道路Ｄ２のうち、道路Ｄ１から遠く離れた位置において、複数の集落Ａ１〜Ａ３が存在している。集落Ａ１〜Ａ３は、駅Ｒａから１０ｋｍ以上離れた離村となっている、道路Ｄ３は、行き止まりとなっていて、行き止まりの位置には、集落Ａ１〜Ａ３の住民等が集うイベント会場（広場）Ａ４とされている。

集落Ａ１〜Ａ３に居住する住民の総数は、数百名程度であるが、高齢者の割合が大きいものであり、自動車の運転をできない者も多数存在する状況となっている。そして、道路Ｄ２（つまり集落Ａ１〜Ａ３の住民）においては、路線バスの運行はされていないものである。

集落Ａ１〜Ａ３の住民の交通の便を図るために、住民同士の協力によって、定時定路運行とデマンド運行とを行うこととなっている。定時定路運行は、定時に決まった路線を走行するものである．定時定路運行の停留所が、Ｓ１〜Ｓ７として示される。停留所Ｓ１は、出発点となるもので、集落Ａ１の住民用である。停留所Ｓ２は、集落Ａ２の住民用である。停留所Ｓ３は、集落Ａ３の住民用である。

停留所Ｓ４は、道路Ｄ２がメインの道路Ｄ１と交差する位置に設定されている。停留所Ｓ５は、小学校や中学校のある位置付近に設定されている。停留所Ｓ６は、役場付近の位置に設定されている。停留所Ｓ７は、定時定路運行の終点で、駅Ｒａ付近に設定されている。このように、定時定路運行の路線は、停留所Ｓ１から、Ｓ２、Ｓ３、Ｓ４、Ｓ５、Ｓ６を経て、終点のＳ７へ到達する経路とされる。帰りの便は、上記とは逆の経路をたどることになる。なお、定時定路運行の運行便数は、例えば、往復共に、例えば朝２便、昼１便、夕方２便とされている。なお、同一時間に出発する定時定路運行で使用する運行用車両の台数は、１台に限らず、乗車希望者が多いときは複数台となる場合もある（同一便で複数台の運行用車両が稼働される場合あり）。

定時定路運行の変形として、臨時運行（臨時便）が適宜行われる。この臨時運行は、例えば、イベント会場Ａ４で催し物（例えば盆踊り、花火大会、芋煮会等）が開催されるときにのみ行われる。この臨時運行の経路は、停留所Ｓ１から、Ｓ２、Ｓ３、Ｓ４を経て、停留所Ｓ８へ至る経路とされる（復路はこの逆）。臨時運行は、イベント開催日に、あらかじめ設定された定時に停留所Ｓ１を出発する便とされる。

臨時運行を含む定時定路運行とデマンド運行とを行う運行用車両は、集落Ａ１〜Ａ３の住民が保有する自家用自動車を利用する他、自治体や企業からの補助や寄付等で管理を任された専用車両が用いられる。運行用車両の台数は、少なくとも２台以上とされ、好ましくは１０台以上が用意される。

運行用車両の運転を行うドライバーは、集落Ａ１〜Ａ３の住民から選ばれた者とされる。ドライバーとして選択されるには、あらかじめ事前講習（例えば半日〜１日程度の講習）を受けた者であることを条件とされる。すなわち、講習内容としては、例えば、安全運転に関する知識と実技の講習、乗客（特に高齢者や幼児）に対する運行用車両への乗り降りの補助の仕方に関する講習、ドライバーに要求される運行管理に関する知識や取扱い方等についての講習等がある。講習を修了したドライバーは、運行用車両の運転者として、登録される（ドライバーの登録の点については後述する）。

図２は、デマンド運行が行われた場合の一例を示すものである。図中Ｐ１は、デマンド運行を乗車予約した乗客（ユーザ）の住居であり、Ｐ２、Ｐ３は、この乗車予約されたデマンド運行（の運行用車両）に相乗りを希望した乗客（ユーザ）の住居である。デマンド運行は、乗客の希望に応じた出発地と目的地と経路とを自由に選択できる。図２では、乗車予約した乗客Ｐ１の自宅（付近）を出発地として、乗客Ｐ２の自宅付近、乗客Ｐ３の自宅付近を経由して、停留所Ｓ４方向に向かう場合が示される。

乗客Ｐ１の最寄りの停留所はＳ２であり、乗客Ｐ１の自宅から停留所Ｓ２までの徒歩での移動経路α１が破線で示される。同様に、乗客Ｐ２の最寄りの停留所はＳ３であり、乗客Ｐ２の自宅から停留所Ｓ３までの徒歩での移動経路α２が破線で示される。乗客Ｐ３の最寄りの停留所もＳ３であり、乗客Ｐ３の自宅から停留所Ｓ３までの徒歩での移動経路α３が破線で示される。

乗客Ｐ１〜Ｐ３にとって、最寄りの停留所までの移動時間あるいは移動距離が長い場合は、停留所までの歩行が大変となる。このため、停留所までの歩行を避けるためにデマンド運行を要求する可能性がある。また、デマンド運行を要求する場合としては、大きな（重い）荷物を携帯しているとき、どの停留所からも遠い場所へ移動するとき、乗客が車椅子や松葉杖を使用する歩行困難な場合等が考えられる。デマンド運行を利用するときの料金は、定時定路運行を利用するときの料金よりも割高となるが、停留所までの移動時間や移動距離を考慮して、定時定路運行を利用するか、デマンド運行を利用するか判断されることになる。なお、デマンド運行の出発地は、デマンド運行を行うことが許容（許可）される範囲内であれば、例えば駅Ｒａ付近であったり、適宜の停留所（例えばＳ５やＳ６）付近である等、適宜選択できる。

ここで、定時定路運行あるいはデマンド運行を利用するときの料金体系の一例について説明する。まず、定時定路運行を利用するときは、利用距離に応じた金額のみで、単位距離あたりの料金がＥ１（Ｅ１×利用距離）とされる。これに対して、デマンド運行を当初に乗車予約した乗客Ｐ１の利用料金は、利用距離に応じた金額が上記料金Ｅ１よりも若干割高な料金Ｅ２とされると共に、定額の基本料金ＥＢ２が別途徴収される（合計料金は、ＥＢ２＋Ｅ２×利用距離）。さらに、デマンド運行に相乗りを希望した乗客Ｐ２、Ｐ３の利用料金は、上記Ｅ２のみとされる（基本料金ＥＢ２が不要）。このように、定時定路運行を利用する場合がもっとも安価であり、デマンド運行を当初に乗車予約した場合の料金がもっとも高価であり、デマンド運行に相乗りする場合の料金が中間の料金となる。勿論、上記した料金は一例であって、適宜設定できるものである。なお、当初にデマンド運行の乗車予約を行ったユーザについては、相乗り者が増えるほど、料金が安価になるような料金体系を採用することにより、相乗りを積極的に促す上で好ましいものとなる。

デマンド運行に相乗りする場合、当初にデマンド運行を予約した乗客の行き先が、相乗りを希望する乗客の行き先とほぼ同一方向であれば、相乗りするメリットがある。例えば、当初にデマンド運行を予約した乗客の行き先が、例えば停留所Ｓ６付近であるときに、相乗りを希望した乗客が希望する行き先が停留所Ｓ７付近（Ｓ６よりも遠方）やＳ５付近（Ｓ６よりも近場）であるときは、相乗りする利点があるということになる。この一方、デマンド運行を当初に予約した乗客の行き先と、相乗りを考えている乗客が希望する行き先とが例えば反対方向であったり、途中で大きく方向が変わる場合は、相乗りされる可能性が極めて低いものとなる。

次に、定時定路運行とデマンド運行との管理を行う管理システムの一例について、図３を参照しつつ説明する。

まず、Ｕ１は、全体の管理を行う管理サイト（情報処理装置としてのサーバ装置）であり、ＣＰＵ、通信手段、大容量の記憶手段（メモリ等）１０等を有している。この管理サイトＵ１には、管理端末Ｕ２、ユーザ端末Ｕ３、ドライバー端末Ｕ４および車載端末Ｕ５がそれぞれ通信可能として接続されている。なお、管理サイトＵ１と管理用端Ｕ２とが、実質的に運行管理装置を構成するものである。また、各端末Ｕ２〜Ｕ５には、管理サイトＵ１との間で各種情報の授受を行うためのアプリケーションソフトがあらかじめインストールされている。

各端末Ｕ２〜Ｕ４は、それぞれ情報処理装置を利用して構成されて、通信部の他に、表示画面（出力部）や操作部（入力部）を有している。管理用端末Ｕ２は、主として管理サイトＵ１の操作を行うもので、運行管理のための入出力作業が多くなるため、高性能のパーソナルコンピュータを利用して構成するのが好ましい。この管理用端末Ｕ２は、例えば役場に１台のみ設置することもできるが、集落Ａ１〜Ａ３にも設定する等、複数台用意することができる（ただし、ある１台の管理用端末Ｕ２が使用されているときは、他の管理用端末Ｕ２が使用できない設定とするのが好ましい）。

一方、ユーザ端末Ｕ３やドライバー端末Ｕ４は、パーソナルコンピュータを利用する他、スマートフォンやタブレット型のパソコンを利用することができる。車載端末Ｕ５は、図４に示すように表示画面２０を有して、後述するように管理サイトＵ１（管理用端末Ｕ２を操作する管理者）と運行用車両を運転するドライバーとの間での各種の情報交換を行うものである。そして、運行用車両の位置情報が、管理サイトＵ１へ自動的に送信されるものとなっている。なお、ユーザ端末Ｕ３については、スマートフォン等の情報処理装置に代えて、電話等によって管理用端末Ｕ２（の管理者）とやりとりできるものとすることもできる（コンピュータ関係の機器類を扱うのが苦手な高齢者等への対応）。特に、ユーザ端末Ｕ３、ドライバー端末Ｕ４、車載端末Ｕ５については、管理サイトＵ１に対して無線でもって通信可能なものを用いるのが好ましい。

図４は、車載端末Ｕ５の一部を構成する表示画面２０での表示例を示すものである。図４では、定時定路運行とデマンド運行とも実質的に同様な表示態様とされる。表示画面２０に表示される内容としては、ユーザ名（乗客名）、乗車位置および降車位置が表示される。乗客が複数名の場合は、同様の表示が下列に表示される。乗客名の表示は、乗車位置が近い順にから遅い順に、上方から下方へ表示される。なお、乗車位置と降車位置との名称は、定時定路運行の場合は停留所名となるが、デマンド運行の場合は、乗客の要望に応じた乗車位置と降車位置とを示す特有の地名表示とされる。

表示画面２０は、タッチパネル式とされている。ある乗客○○○が乗車位置で乗車すると、ドライバーは表示画面２０中の乗車確認スイッチ２１をタッチ操作する。これにより、ある乗客○○○が乗車したことの情報が、管理サイトＵ１に送信されて、記憶される。同様に、ある乗客○○○が降車位置で降車すると、ドライバーは表示画面２０中の降車確認スイッチ２２をタッチ操作する。これにより、ある乗客○○○が降車したことの情報が、管理サイトＵ１に送信されて、記憶される。他のユーザの乗車、降車についても同様のことが行われる。

全てのユーザが降車した際に、ドライバーは、表示画面２０中に表示されている完了スイッチ２３をタッチ操作する。これにより、運行が完了したことの報告情報が、管理サイトＵ１に送信されて、記憶される。表示画面２０中に表示されている地図表示を要求するスイッチ２４をタッチ操作すると、走行経路が表示される。この走行経路の表示は、特にデマンド運行の際に必要となる可能性が高いもので、例えば図２に示すような地図表示が行われて、走行経路が図２中一点鎖線で示すような態様でもってでもって表示される（走行経路は、ナビゲーション装置で行われる案内経路表示のように、色分け表示とするのが好ましい）。

表示画面２０中に表示される緊急スイッチ２５をタッチ操作すると、管理サイトＵ１を介して、管理用端末Ｕ２（を操作している管理者）に対して、緊急事態の発生を知らせる旨の報知が行われる。これによりドライバーと管理者との間で、緊急事態に対応するための情報交換が行われる。

次に、管理サイトＵ１と管理用端末Ｕ２とによって行われる運行管理の制御例について、図５以下のフローチャートを参照しつつ説明する。

まず、図５は、各種の登録を行う場合が示される。すなわち、Ｑ１において、管理用端末Ｕ２を操作して、管理者の登録が行われる。管理者は、例えば役場の職員や、集落Ａ１〜Ａ３の住民の中から推薦等によって選択されるが、極力多人数を登録しておくのが好ましい。管理者登録に際しては、例えば、氏名、住所、年齢、性別、電話番号等とされる。なお、管理者となる前提としてあらかじめ講習を受講して、本システムの取扱を十分に理解した者とされる。また、管理者については、管理用端末Ｕ２がむやみに操作されないように、あらかじめＩＤとパスワードが各管理者に割り当てられて、ＩＤとパスワードとを入力しない限り、管理用端末Ｕ２を操作できないようにされる。

Ｑ２では、管理用端末Ｕ２を操作して、運行用車両を運転するドライバーの登録が行われる。この登録は、例えば、氏名、住所、年齢、性別、電話番号、運転する運行用車両の種別、乗車定員、運転免許証の有効期限、講習の受講日等が登録される。この登録に際しては、さらに、個々のドライバーの要望に応じて、担当できる運行が、定時定路運行のみであるか、デマンド運行のみであるか、定時定路運行とデマンド運行との両方の運行が可能であるかの登録も行われ、さらに種々の要望事項も登録される。

ドライバー登録されるドライバーの種々の要望事項としては、例えば、次のようなものとすることができる。すなわち、運転担当可能な運転地域の限定、運転拘束時間の限定（例えば４０分以内等）。乗客の居住する地域の限定（例えば普段付き合いのない集落Ａの住民が乗客となる場合は運転不可とする）、乗客の年齢や性別の限定、乗客に乗降の補助等が必要な障害が有る場合の限定（ドライバーが体力的に乗客の補助を行うことが難しい場合）等の場合に、運転担当不可であるという登録内容とすることもできる。このようなドライバーの要望事項を登録しておくことは、条件が合えばドライバーになり得るということで、ドライバーを十分に確保する上で好ましいものとなる。

上述したドライバー登録の内容は、要望事項をも含めて、例えばドライバー端末Ｕ４で入力することにより、ドライバー端末Ｕ４から管理サイトＵ１に送信されて、管理サイトＵ１の記憶手段１０に記憶される（データベース化）。なお、ドライバー登録の内容は、電話、ＦＡＸあるいは紙によって要望事項を受け取って、管理者が管理用端末Ｕ２を操作して入力することもできる。

Ｑ３では、管理用端末Ｕ２を操作して、ユーザの登録が行われる。この登録は、運行用車両を利用する乗客となる予定者の登録である（利用者の会員登録ともいえる）。この登録は、例えば、氏名、住所、年齢、性別、電話番号、自宅からの最寄りの停留所名、最寄りの停留所までの移動時間および移動距離等とされる。

ユーザ登録に際しては、さらに、デマンド運行を乗車予約する際に、相乗り者として希望するユーザを、仲間として仲間登録することが含まれる。具体的には、図１１に示すように、ユーザ端末Ｕ３を操作して、その表示画面３０に表示される仲間登録欄３１に、相乗り者になって欲しいユーザ（仲間）が入力される。また、表示画面３０に表示される除外欄（相乗り不可のユーザを入力する欄）３２には、相乗り者として希望しないユーザ（非仲間）が入力される。その他、自由欄３３には、相乗りに関する希望事項を自由に入力できるようになっている。

仲間登録欄３１は、デマンド運行を乗車予約した際に、親しい仲間が極力同乗できるようにするためのもので、仲間が同乗することにより、車中での会話も弾んで、親睦を深めることができる。また、運行用車両の利用人数を極力増やして、運行負荷を低減させる上でも好ましいものとなる。そして、除外欄３２に特定のユーザを登録しておくことにより、意に沿わない人が同乗してしまうことを確実に阻止することができる。

上述したユーザ登録の内容は、例えばユーザ端末Ｕ３で入力することにより、ユーザ端末Ｕ３から管理サイトＵ１に送信されて、管理サイトＵ１の記憶手段１０に記憶される（データベース化）。なお、ユーザ登録の内容は、電話、ＦＡＸあるいは紙によって要望事項を受け取って、管理者が管理用端末Ｕ２を操作して入力することもできる。

図６は、運行用車両の運転担当が可能なドライバーを登録する処理を示す。すなわち、例えば、翌月の１ヶ月分の各日について、運転担当が可能な日と時間帯が、例えばドライバー端末Ｕ４を介してあるいは管理用端末Ｕ２を操作して、管理サイトＵ１に登録される（記憶手段１０への記憶）。運転担当可能な日や時間帯は、変更取消が可能である。なお、運転担当可能な日と時間帯の登録は、電話やＦＡＸあるいは紙形式でも可能であり、この場合は、管理者が、管理用端末Ｕ２を利用してドライバー登録を行うことになる。

図７は、車載端末Ｕ５での操作に対応した管理サイトＵ１での運行状況の処理内容を示す。すなわち、図４に示すスイッチ２１が操作されることにより、Ｑ１１において乗車の確認が行われる。図４に示すスイッチ２２が操作されることにより、Ｑ１２において降車の確認が行われる。そして、図４に示すスイッチ２３が操作されることにより、Ｑ１３において、乗客全員が降車した運行完了であることが確認される。この図７の処理によって、運行している運行用車両の状況を把握することができる（この運行状況は、管理用端末Ｕ２を操作して、その表示画面でもっていつでも確認することができる）。

図８は、定時定路運行を行うための処理を示すものである。まず、Ｑ２１において、ユーザからの乗車予約の受付が行われる。受付内容は、少なくとも、乗車を希望する日と、定時定路運行の便名と、乗車場所と、降車場所とを含むものとされる。なお、乗車予約は、ユーザ端末Ｕ３を利用して行われることを想定しているが、この他、電話や紙での乗車予約も受付可能とされる（この場合は、管理者が、管理用端末Ｕ２を用いて、乗車予約の内容を管理サイトＵ１に入力することになる）。勿論、乗車予約された内容は、管理サイトＵ１の記憶手段１０に記憶される。なお、乗車予約は、例えば、利用する定時定路運行の前日の午後５時まで等、受付期限を設定しておくのが好ましい。

Ｑ２２では、乗車予約が行われた定時定路運行での運転を担当するドライバーの選択が行われる。ドライバーの選択に際しては、記憶手段１０に記憶（登録）されているドライバーの中から、運転担当することが可能なドライバー（図１１で定時定路運行可否の欄で「○」を入力したドライバー）の中から１名を選択することにより行うこととなる。なお、ドライバーの選択は、運転担当が可能なドライバーの中から順番に自動的に選択することもでき、また管理者が管理用端末Ｕ２を利用して、手動操作によって選択することもできる。なお、ドライバー登録の際に、個々のドライバーが使用する運行用車両が登録されているので、ドライバーの選択に伴って使用される運行用車両が自動的に決定される。

Ｑ２３では、乗車予約した乗客（乗客予定者）に対して予約受付を完了した旨の報知が行われる。また、運転担当として選択されたドライバーに対して、運転担当として選択されたことと、乗車予約された内容とが報知される。この各報知は、ユーザ端末Ｕ３、ドライバー端末Ｕ４に対して行うようにしてある。なお、確認のために、選択されたドライバーから、運転担当を了解した旨の返信を受け取るような処理を行うこともできる（ドライバーと運行用車両を確実に確保して、定時定路運行が確実に行われるようにする）。

Ｑ２４では、車載端末Ｕ５に対して、乗車予約された内容（特に乗客名とその乗車位置と降車位置とに関する情報）が報知される（この報知に基づいて、図４に示すような表示が行われる）。なお、運転担当するドライバーの氏名をも、車載端末Ｕ５に報知することもできる（運転担当者の氏名を、図４の表示画面２０の表示させることもできる）。

図９は、デマンド運行を行うための処理を示すものである。まず、Ｑ３１において、ユーザからのデマンド運行についての乗車予約が受け付けられる。受付内容は、少なくとも、乗車を希望する日と、乗車場所（出発地点）と、乗車時間と、降車場所（降車地点）とを含むものとされる。乗車予約の際に、相乗りを希望（許可）するか否かの情報を含めることができる。すなわち、デマンド運行を乗車予約したユーザが、例えば家族でもって一緒に移動したいとき、プライバシーの観点から同乗者が居ないことを希望するとき、さらには目的地に早く到着したいときは、乗車予約の際に、「相乗り不可」の情報を含めることができる。なお、「相乗り不可」の情報がない限り、「相乗り許可」と自動的に判断することができる。

なお、乗車予約は、ユーザ端末Ｕ３を利用して行われることを想定しているが、この他、電話や紙での乗車予約も受付可能とされる（この場合は、管理者が、管理用端末Ｕ２を用いて、乗車予約の内容を管理サイトＵ１へ入力することになる）。勿論、乗車予約された内容は、管理サイトＵ１の記憶手段１０に記憶される。なお、乗車予約は、例えば、前日の午後５時まで等、受付期限を設定しておくこともできるが、病気や事故の発生等の緊急時に迅速にデマンド運行を行えるように、受付期限は設けない設定とするのが好ましい。

Ｑ３２では、デマンド運行の乗車予約を受け付けたか否かが判別される。このＱ３２の判別でＮＯのときは、リターンされる（デマンド運行なし）。Ｑ３２の判別でＹＥＳのときは、Ｑ３３において、乗車予約された内容（特に乗車位置と降車位置）とに基づいて、デマンド運行での走行経路が決定される。Ｑ３３の後、Ｑ３４において、相乗りの受付処理が行われる。このＱ３４の処理については、後述する。この後、Ｑ３５において、相乗りの乗客が存在するか否かが判別される。このＱ３５の判別でＹＥＳのときは、Ｑ３６において、相乗りの乗客が希望する乗車位置と降車位置とに応じて、Ｑ３３で決定された走行経路が修正される。

Ｑ３６の後、あるいはＱ３５の判別でＮＯのときはそれぞれ、Ｑ３７において、運転を担当するドライバーの選択が行われる。このドライバーの選択に際しては、管理サイトＵ１に記憶されているドライバー登録のデータベースの内容を照合して、運転担当可能なドライバーが選択される。このドライバー選択に際しては、ドライバー登録されたときのドライバーからの各種要望に対応して行われる。例えば、走行経路が、運転担当可能な地域から大きくはずれているドライバーは除外され、走行時間がドライバー登録されている運転拘束時間よりも長くなるドライバーは除外される等のことが行われる。なお、運転担当可能なドライバーが複数存在する場合は、順番にドライバーを選択することもできる。

ドライバー選択の際には、管理用端末Ｕ２を操作する管理者が、走行経路や走行時間を考慮して、また乗車予約された乗客に関する情報を考慮して、管理サイトＵ１に記憶されているドライバー登録の内容を呼び出して（管理用端末Ｕ２の表示画面にドライバー登録されている要望事項を表示させて）、ドライバーの選択を行うことができる。また、管理サイトＵ１において、走行経路、走行時間および乗客に関する情報を、ドライバー登録されているドライバーの要望と照合して、運転担当可能なドライバーを自動選択することもできる（例えば人工知能の利用）。管理サイトＵ１からは、選択されたドライバーのドライバー端末Ｕ４に対して、ドライバーとして選択されたことと、運行内容、乗客情報等が報知（送信）される。

Ｑ３７の後、Ｑ３８において、乗車予約されたデマンド運行に関する情報、例えばデマンド運行での走行経路に関する情報、各乗客に関する情報、乗車位置と降車位置に関する情報が、ユーザ端末Ｕ３、ドライバー端末Ｕ４、車載端末Ｕ５に対して報知（送信）される。なお、使用する運行用車両は、選択されたドライバーに応じて自動的に決定される。

図１０は、図９のＱ３４における相乗りの受付処理を示す。なお、この受付処理の際には、乗車予約した者が相乗りを許可するか否かや、相乗りを登録されている仲間に限定するか否かの情報を含むように行われる。なお、乗車予約の際に相乗りについて特に限定がない場合は、全てのユーザが相乗りの可能性のある者とされる。

以上のことを前提として、まずＱ５１において、デマンド運行を当初に乗車予約した乗客（ユーザ）が、相乗りを許可しているか否かが判別される。このＱ５１の判別でＹＥＳのときは、Ｑ５２において、乗車予約したユーザが、相乗りを登録されている仲間に限定することを希望しているか否かが判別される。このＱ５３の判別でＹＥＳのときは、図１１に示すように仲間登録欄３１に仲間として登録されているユーザ（のユーザ端末Ｕ３）に対してのみ、相乗りを希望するか否かの問い合わせが行われる。

上記Ｑ５２の判別でＮＯのときは、Ｑ５４において、全てのユーザ（のユーザ端末Ｕ３）に対して、相乗りを希望するか否かの問い合わせが行われる（相乗りの受付）。なお、図１１に示すように、除外欄３２において、相乗り不可の人として登録されているユーザが存在するときは、除外欄３２に登録されているユーザを除外した残りのユーザに対して、相乗りを希望するか否かの問い合わせが行われる。

相乗りの受付（問い合わせ）は、管理用端末Ｕ２を操作することにより、デマンド運行の日、時間、乗車位置（出発地）、降車位置（目的地）の他、乗車位置から降車位置までの走行経路を、ユーザ端末Ｕ３に対して報知することにより行われる。そして、この報知された情報に基づいて、相乗り希望者から相乗りの乗車予約を受け付けることになる。相乗り希望者は、少なくとも希望する乗車位置と降車位置とを指定して、相乗りの乗車予約を行うことになる（相乗りの乗車予約は運行管理装置Ｕ１に記憶される）。

上記Ｑ５３後あるいはＱ５４の後はそれぞれ、Ｑ５５において、相乗り希望者が存在するか否かが判別される。すなわち、上記Ｑ５３あるいはＱ５４での問い合わせに対する返信内容から、相乗りすることを希望する者が存在するか否かが判別されることになる。このＱ５５の判別でＹＥＳのときは、相乗りに関する情報が、乗車予約したユーザと相乗りするユーザの全員（のユーザ端末Ｕ３）に対して行われる。この相乗りに関する情報は、走行経路や運行時間の情報および乗客となる全てのユーザ名、各ユーザの乗車位置と降車位置等が含まれる。また、この相乗りに関する情報は、運転担当するドライバー（のドライバー端末Ｕ４）や使用する運行用車両（の車載端末Ｕ５）に対しても行われる。なお、Ｑ５６の処理は、図９のＱ３８の処理に対応しているが、報知を確実に行うために、重複して情報報知するようになっているが、Ｑ５６の処理を無くしてもよい（図９のＱ３８での報知のみとする）。

以上実施形態について説明したが、本発明は、実施形態に限定されるものではなく、特許請求の範囲の記載された範囲において適宜の変更が可能である。
（１）相乗りに関する仲間登録の際には、ユーザ個人を特定する内容に限らず、例えば居住地域で特定したり、性別で特定したり、年齢で特定する等、適宜の内容で特定することもできる。また、相乗りを希望しない除外欄３２に登録するユーザも、ユーザ個人を特定する内容に限らず、例えば居住地域で特定したり、性別で特定したり、年齢で特定する等適宜の内容で特定することもできる。
、
（２）定時定路運行やデマンド運行の他に、複数の停留所を所定順序で走行するが、出発時間が特定されない定路運行を行うものであってもよい。また、定時定路運行の往路便で使用した運行用車両（およびドライバー）を、そのまま復路便用の運行用車両として利用することもできるが、往路便と復路便との運行用車両（およびドライバー）を相違させることもできる。
（３）運行管理装置Ｕ１は、自動化という点では、他の端末Ｕ２〜Ｕ５と情報の授受を自動的に行えるように設定するのが好ましいが（例えばある情報が入力されたときに、これに対応した出力情報を他の端末Ｕ２〜Ｕ５に対して自動的に行う）、管理用端末Ｕ２を積極的に利用することにより、運行管理装置Ｕ１を極力簡単化して、設置コスト低減等を図ることもできる。
（４）車載端末は、そのディスプレイを運行用車両のインストルメントパネル上に配設する一方、その操作部を例えばコンソールボックスあるいはその付近に設けたコマンダスイッチとして構成することもできる（コマンダスイッチによって、表示画面上のカーソルの移動や選択を行う等）。また、ドライバー端末と車載端末とを共通（兼用）とすることもでき、この場合ドライバー端末を運行用車両に設置される態様とすることができ、また車載端末を運行用車両から外部に持ち出すことのできる態様とすることもできる。さらに、ドライバー端末と車載端末とを別途設ける場合、ドライバー端末と車載端末とを同期させて、管理サイトＵ１からの情報をドライバー端末と車載端末とで同じように確認できるようにすることもできる。
（５）フローチャートに示すステップあるいはステップ群は、その機能内容に手段（あるいは機能）の名称を付した表現でもって、例えば管理サイトＵＵ１の有する手段（あるいは機能）として表現することができる。勿論、本発明の目的は、明記されたものに限らず、実質的に好ましいあるいは利点として表現されたものを提供することをも暗黙的に含むものである。

本発明は、過疎地において交通の確保を行うことができる。

Ｕ１：管理サイト（運行管理装置）
Ｕ２：管理用端末（運行管理装置）
Ｕ３：ユーザ端末
Ｕ４：ドライバー端末
Ｕ５：車載端末
Ａ１〜Ａ３：集落
Ａ４：イベント広場
Ｄ１〜Ｄ３：道路
Ｒ：鉄道
Ｒａ：駅
Ｓ１〜Ｓ７：停留所（定時定路運行用）
Ｓ８：停留所（臨時の定時定路運行用）
Ｐ１〜Ｐ３：デマンド運行を希望する乗客の自宅
α１〜α３：自宅から最寄りの停留所までの移動経路

Claims (8)

1. 所定地域内に居住する多数のユーザに対して、運行用車両を用いて運行サービスを行うための自動車運行管理システムであって、
   運行管理者によって管理され、情報処理装置からなる運行管理装置と、
   前記運行管理装置に対して通信可能とされ、ユーザに保持される情報処理装置からなるユーザ端末と、
   を有し、
   前記運行管理装置は、ユーザに関する情報を登録するユーザ登録機能と、ユーザからの乗車予約を受け付ける予約受付機能と、を有し、
   前記ユーザ登録に際して、多数のユーザの中から相乗りの仲間を登録する仲間登録を含むようにされ、
   前記運行管理装置は、乗車予約を受け付けたときに、乗車予約したユーザについて仲間登録されているユーザのユーザ端末に対して、相乗りを促すための問い合わせを行う相乗り受付機能を有している、
   ことを特徴とする自動車運行管理システム。
2. 請求項１において、
   運行サービスとして定時定路運行とデマンド運行とが行われるようにされて、前記運行管理装置は、前記定時定路運行と前記デマンド運行とのうち該デマンド運行について乗車予約されたときにのみ、相乗りを促すための問い合わせを行う、ことを特徴とする自動車運行管理システム。
3. 請求項１または請求項２において、
   前記運行管理装置は、相乗りを促すための問い合わせを行う際に、乗車予約された運行に関する情報をも報知するようにされ、
   前記報知される乗車予約された運行に関する情報として、少なくとも走行経路と運行時間に関する情報とが含まれる、
   ことを特徴とする自動車運行管理システム。
4. 請求項１ないし請求項３のいずれか１項において、
   前記運行管理装置に対して通信可能とされ、運行用車両を運転するドライバーに保持される情報処理装置からなるドライバー端末をさらに有し、
   前記運行管理装置は、前記乗車予約された運行に関する情報と該乗車予約された運行に乗車するユーザに関する情報とを、該乗車予約された運行の運転を担当するドライバーの前記ドライバー端末に報知する、
5. 請求項１ないし請求項４のいずれか１項において、
   前記運行管理装置に対して通信可能とされ、運行用車両に搭載された情報処理装置からなる車載端末をさらに有し、
   前記運行管理装置は、前記乗車予約された運行に関する情報と該乗車予約された運行に乗車するユーザに関する情報とを、該乗車予約された運行に使用される運行用車両の前記車載端末に報知する、
   ことを特徴とする自動車運行管理システム。
6. 請求項１ないし請求項５のいずれか１項において、
   前記運行管理装置は、乗車予約したユーザについて仲間登録されているユーザから相乗りの希望がなかったときに、仲間登録されている以外のユーザに対して相乗りを促すための問い合わせを行う、ことを特徴とする自動車運行管理システム。
7. 請求項６において、
   前記ユーザ登録に際して、多数のユーザの中から相乗りを希望しない相乗り不可のユーザを登録するユーザ除外登録を含むようにされ、
   前記運行管理装置は、乗車予約したユーザについてユーザ除外登録されているユーザに対しては、相乗りを促すための問い合わせを行わない、
   ことを特徴とする自動車運行管理システム。
8. 請求項１なせ請求項７のいずれか１項において、
   前記運行管理装置は、乗車予約したユーザが相乗りを許可していることを条件として、相乗りを促すための問い合わせを行う、ことを特徴とする自動車運行管理システム。

Images