特許 7037766 自動車運行管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-03-09

(45)【発行日】2022-03-17

(54)【発明の名称】自動車運行管理システム

(51)【国際特許分類】

   G08G 1/00 20060101AFI20220310BHJP

   G08G 1/127 20060101ALI20220310BHJP

   G06Q 50/30 20120101ALI20220310BHJP

【ＦＩ】

G08G1/00 D

G08G1/127 B

G06Q50/30

【請求項の数】 7

(21)【出願番号】P 2018201593

(22)【出願日】2018-10-26

(65)【公開番号】P2020067933

(43)【公開日】2020-04-30

【審査請求日】2021-07-20

(73)【特許権者】

【識別番号】000003137

【氏名又は名称】マツダ株式会社

(74)【代理人】

【識別番号】100080768

【弁理士】

【氏名又は名称】村田 実

(74)【代理人】

【識別番号】100166327

【弁理士】

【氏名又は名称】舟瀬 芳孝

(74)【代理人】

【識別番号】100106644

【弁理士】

【氏名又は名称】戸塚 清貴

(72)【発明者】

【氏名】吉田 真一郎

(72)【発明者】

【氏名】岡村 雅

(72)【発明者】

【氏名】岡田 裕輝

(72)【発明者】

【氏名】西村 一眞

(72)【発明者】

【氏名】丸子 敬生

【審査官】佐藤 吉信

(56)【参考文献】

【文献】特開２０１６－０４２２５１（ＪＰ，Ａ）

【文献】特開２００４－０３８８３９（ＪＰ，Ａ）

【文献】特開２００３－２８５７４１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／００－９９／００

Ｇ０１Ｃ ２１／００－２１／３６

Ｇ０６Ｑ ５０／３０

(57)【特許請求の範囲】

【請求項1】

所定地域内に居住する多数のユーザに対して、運行用車両を用いて運行サービスを行うための自動車運行管理システムであって、
運行管理者によって管理され、情報処理装置からなる運行管理装置と、
前記運行管理装置と通信可能とされ、情報処理装置からなるユーザ端末と、
を備え、
前記運行管理装置が運行便に関する情報を公開することにより、該運行便に関する情報が前記ユーザ端末によって確認可能とされ、
前記運行管理装置は、公開と非公開とを選択する第１選択部と、公開対象となるユーザ範囲を示す公開範囲を選択する第２選択部と、を有し、
前記管理装置は、前記第１選択部によって非公開が選択されているときは運行便に関する情報を公開しない一方、前記第１選択部によって公開が選択されているときは運行便に関する情報を公開するようにされ、
前記運行管理装置は、前記第１選択部によって公開が選択されているときは、前記第２選択部によって選択された公開範囲に属するユーザ範囲に対してのみ該運行便に関する情報を公開する、
ことを特徴とする自動車運行管理装置。

【請求項2】

請求項１において、
運行サービスとして、定時定路運行とデマンド運行とが設定され、
前記運行管理装置は、前記定時定路運行の運行便については常に公開の対象とする一方、前記デマンド運行についてのみ前記第１選択部での選択と前記第２選択部での選択が行われるようにされている、
ことを特徴とする自動車運行管理装置。

【請求項3】

請求項１または請求項２において、
前記第２選択部によって選択される公開範囲として、運行便を乗車予約したユーザについてあらかじめ仲間として登録されているユーザ範囲と、該運行便の出発地付近に居住するユーザ範囲と、該運行便の走行経路付近に居住するユーザ範囲と、該運行便に類似する過去の運行便を利用したユーザ範囲と、該運行便を乗車予約したユーザと同乗したことのあるユーザ範囲と、のうち任意の２以上のユーザ範囲が選択可能として設定されている、ことを特徴とする自動車運行管理装置。

【請求項4】

請求項１ないし請求項３のいずれか１項において、
前記運行便に関する情報の公開が、該運行便の乗車予約を受け付けるための情報とされている、ことを特徴とする自動車運行管理装置。

【請求項5】

請求項１ないし請求項４のいずれか１項において、
運行サービスとしてデマンド運行が設定され、
前記運行管理装置は、過去に実行されたデマンド運行に関する情報を全ユーザに対して公開可能とされている、ことを特徴とする自動車運行管理装置。

【請求項6】

請求項５において、
前記運行管理装置と通信可能とされ、前記運行用車両のドライバーによって使用される情報処理装置からなるドライバー端末を有し、
前記運行管理装置は、過去に実行されたデマンド運行に関する情報を全ドライバーに対して公開可能とされている、
ことを特徴とする自動車運行管理装置。

【請求項7】

請求項５または請求項６において、
過去に実行されたデマンド運行に関する情報として、少なくとも走行経路が含まれる、ことを特徴とする自動車運行管理装置。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１４－２３８８３１号公報

【文献】特開２０１６－８５７３４号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

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

【0006】

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

【0007】

上述した運行サービスを活発に利用してもらうことは、運行サービスの価値を高めて、住民同士の繋がりを深めたり採算性を向上させる等の上で重要となる。この一方、特にデマンド運行の際は、乗客となるユーザ数が少なくなってしまうという傾向が極めて強いものとなり、この点においてなんらかの対策が望まれるものである。

【0008】

なお、デマンド運行について、広くユーザに情報公開して相乗りを促すことは、次のような問題も生じやすいものとなる。すなわち、当初にデマンド運行を乗車予約したユーザにとっては、その意に沿わない場合も生じてしまうこともある（例えば相乗りによって迂回経路を走行することから、目的地への到着時間が遅くなって困る等）。この一方、相乗りを促される多くの他のユーザにとっては、走行経路や利用時間帯等の関係から相乗りすることが事実上不可能であったり、デマンド運行を利用したくないユーザも存在するが、このような他のユーザに対しても不必要に相乗りを促す情報が配信されることになり、他のユーザの迷惑にもなりかねないものとなる。

【0009】

本発明は以上のような事情を勘案してなされたもので、その目的は、運行便の利用を活発化させつつ、運行便を利用するユーザの利便性と運行便を利用する可能性の低いユーザへの不必要な情報配信の抑制とを共に満足できるようにした自動車運行管理システムを提供することにある。

【課題を解決するための手段】

【0010】

前記目的を達成するため、本発明にあっては次のような解決手法を採択してある。すなわち、請求項１に記載のように、
所定地域内に居住する多数のユーザに対して、運行用車両を用いて運行サービスを行うための自動車運行管理システムであって、
運行管理者によって管理され、情報処理装置からなる運行管理装置と、
前記運行管理装置と通信可能とされ、情報処理装置からなるユーザ端末と、
を備え、
前記運行管理装置が運行便に関する情報を公開することにより、該運行便に関する情報が前記ユーザ端末によって確認可能とされ、
前記運行管理装置は、公開と非公開とを選択する第１選択部と、公開対象となるユーザ範囲を示す公開範囲を選択する第２選択部と、を有し、
前記管理装置は、前記第１選択部によって非公開が選択されているときは運行便に関する情報を公開しない一方、前記第１選択部によって公開が選択されているときは運行便に関する情報を公開するようにされ、
前記運行管理装置は、前記第１選択部によって公開が選択されているときは、前記第２選択部によって選択された公開範囲に属するユーザ範囲に対してのみ該運行便に関する情報を公開する、
ようにしてある。

【0011】

上記解決手法によれば、運行便に関する情報の公開と非公開とを選択でき、また公開されるときは公開範囲を選択できるので、運行便に関する情報の必要性が高いと思われるユーザの利便性が確保され、また運行便に関する情報の必要性が低いと思われるユーザには不必要に情報配信されることがなくなる。また、運行便に関する情報を、必要と思われるユーザに積極的に公開できるので、運行サービスの利用を活発化させることができる。さらに、非公開を選択することにより、例えば運行便を利用するユーザのプライバシー保護等の上でも好ましいものとなる。

【0012】

上記解決手法を前提とした好ましい態様は、請求項２以下に記載のとおりである。すなわち、
運行サービスとして、定時定路運行とデマンド運行とが設定され、
前記運行管理装置は、前記定時定路運行の運行便については常に公開の対象とする一方、前記デマンド運行についてのみ前記第１選択部での選択と前記第２選択部での選択が行われるようにされている、
ようにしてある（請求項２対応）。この場合、全てのユーザが利用対象と考えられる定時定路運行については、全て公開として、定時定路運行に関する情報を確実にユーザへ伝えることができる。また、個人の都合で運行されるデマンド運行便については、非公開を選択することによりプライバシーが確実に保護され、また公開が選択されているときでも公開範囲を適切に選択することにより、プライバシーの保護と相乗り等を促すことを高い次元で満足させることができる。

【0013】

前記第２選択部によって選択される公開範囲として、運行便を乗車予約したユーザについてあらかじめ仲間として登録されているユーザ範囲と、該運行便の出発地付近に居住するユーザ範囲と、該運行便の走行経路付近に居住するユーザ範囲と、該運行便に類似する過去の運行便を利用したユーザ範囲と、該運行便を乗車予約したユーザと同乗したことのあるユーザ範囲と、のうち任意の２以上のユーザ範囲が選択可能として設定されている、ようにしてある（請求項３対応）。この場合、公開されるユーザ範囲として適切なものを選択できるようにする上で、特に運行便について乗車を促すための公開範囲として極めて好ましいものである。

【0014】

前記運行便に関する情報の公開が、該運行便の乗車予約を受け付けるための情報とされている、ようにしてある（請求項４対応）。この場合、適切なユーザ範囲への公開によって、運行便を利用するユーザ数（乗客数）を増加させる上で、また運行の採算性向上の上で好ましいものとなる。

【0015】

運行サービスとしてデマンド運行が設定され、
前記運行管理装置は、過去に実行されたデマンド運行に関する情報を全ユーザに対して公開可能とされている、ようにしてある（請求項５対応）。この場合、過去のデマンド運行の情報を広く公開することによって、デマンド運行を利用してもらうことを積極的に促すことができ、運行サービスの利用の活発化やこれに伴う住民同士の繋がりを深めさせる上で好ましいものとなる。

【0016】

前記運行管理装置と通信可能とされ、前記運行用車両のドライバーによって使用される情報処理装置からなるドライバー端末を有し、
前記運行管理装置は、過去に実行されたデマンド運行に関する情報を全ドライバーに対して公開可能とされている、
ようにしてある（請求項６対応）。この場合、デマンド運行を担当する可能性のあるドライバーにとっては、過去に利用されたデマンド運行の内容を十分に把握することができる。これにより、デマンド運行の運転担当となった際の心構えや準備をあらかじめ各ドライバーに対して十分に自覚させておく等の上で好ましいものとなる。

【0017】

過去に実行されたデマンド運行に関する情報として、少なくとも走行経路が含まれる、ようにしてある（請求項７対応）。この場合、過去のデマンド運行で走行された走行経路をあらかじめ把握して、請求項６に対応した効果をより十分に発揮させる上で好ましいものとなる。

【発明の効果】

【0018】

本発明によれば、運行便の利用を活発化させつつ、運行便を利用するユーザの利便性と運行便を利用する可能性の低いユーザへの不必要な情報配信の抑制とを共に満足させることができる。

【図面の簡単な説明】

【0019】

【図1】定時定路運行の路線例を示す図。

【図2】デマンド運行の一例を示す図。

【図3】本発明によるシステム系統例を示す図。

【図4】車載端末での表示例を示す図。

【図5】各種登録を行うための制御例を示すフローチャート。

【図6】運転担当可能なドライバーの登録を行うための制御例を示すフローチャート。

【図7】車載端末の操作に伴う制御例を示すフローチャート。

【図8】定時定路運行の乗車予約受付に伴う制御例を示すフローチャート。

【図9】デマンド運行の乗車予約受付に伴う制御例を示すフローチャート。

【図10】デマンド運行に伴う相乗りに関する制御例を示すフローチャート。

【図11】管理用端末での画面表示例を示すもので、ドライバー毎に運転担当可能な時間帯を示す図。

【図12】管理用端末での画面表示例を示すもので、予約状況と運行の正式公開・仮公開の切換えを行うための表示例を示す図。

【図13】定時定路運行を乗車予約する場合のユーザ端末での表示例を示す図。

【図14】ユーザ端末での画面表示例を示すもので、定時定路運行を休止する旨の報知例を示す図。

【図15】ユーザ端末での画面表示例を示すもので、デマンド運行に対する相乗りの予約を行うための例を示す図。

【図16】管理用端末での画面表示例を示すもので、デマンド運行について公開・非公開と公開範囲とを選択するための例を示す図。

【図17】管理用端末での画面表示例を示すもので、過去に行われたデマンド運行に関する情報を公開するための例を示す図。

【発明を実施するための形態】

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

一方、ドライバーへの報酬としては、例えば、基本報酬＋走行距離に応じた報酬とすることができる。所定の運行便の採算性の判断に際しては、このドライバーへの報酬を考慮して決定することもできる。なお、採算性を満足する場合とは、必ずしも赤字にならないということではなく、赤字であってもその赤字幅（例えば赤字金額あるいは支払う報酬に対する支払い料金の割合）が所定範囲内であれば採算性があると判断することができる。

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

ある運行便の運行が終了する毎に、運行の詳細内容、具体的には例えば運行便（特に走行経路と運行時間帯）と利用者とドライバーとが関連づけられた状態で、管理サイトＵ１の記憶部１０記憶される（データベース化）。この記憶の際に、ドライバーへの報酬、ユーザの支払った料金の他、運行管理者をも対応づけて記憶しておくことができる。記憶されている過去の運行内容の詳細は、今後の運行を行う際の支援情報として利用することができる。

【0044】

次に、管理サイトＵ１と管理用端末Ｕ２とによって行われる運行管理の制御例について、図５以下のフローチャートを参照しつつ説明する。なお、以下の説明では、管理サイトＵ１による公開あるいは報知とは、管理サイトＵ１から他の端末（特にユーザ端末Ｕ３）へ情報送信（特に自動送信）する場合に限らず、他の端末から管理サイトＵ１にアクセスしたときに他の端末で公開あるいは報知の内容を示す情報を確認できることをも含むものである。ただし、実施形態では、管理サイトＵ１による公開は、他の端末から管理サイトＵ１へアクセスしたときに公開している情報を他の端末で確認できる場合としてあり、管理サイトＵ１からの報知は、管理サイトＵ１から他の端末へ積極的に情報送信するようにしてある。

【0045】

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

【0046】

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

【0047】

Ｑ３では、管理用端末Ｕ２を操作して、ユーザの登録が行われる。この登録は、運行用車両を利用する乗客となる予定者の登録である（利用者の会員登録ともいえる）。この登録は、例えば、氏名、住所、年齢、性別、電話番号、自宅からの最寄りの停留所名、最寄りの停留所までの移動時間および移動距離等とされる。また、ユーザ登録に際しては、デマンド運行を乗車予約した際に、相乗り者となる他のユーザを仲間として登録することもできるようになっている（例えば個人名や、居住地域名等での登録）。前述した各登録はそれぞれ、管理サイトＵ１の記憶手段１０に記憶される（データベース化）。

【0048】

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

【0049】

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

【0050】

ここで、管理サイトＵ１に記憶されている情報は、全て管理用端末Ｕ２で呼び出してその表示画面に表示させることができる。この管理用端末Ｕ２で表示される情報は、前述した登録に関する事項のみならず、過去の運行サービスの利用者等に関する情報も表示させることができる。例えば、ある運行便についての利用者の情報を、過去分に渡って表示させることができる。これにより、ある運行便について頻繁に利用するユーザや、たまに利用するユーザ、殆ど利用しないユーザ等を確認することが可能となっている。同様に、過去に実行されたデマンド運行に関する情報も表示させることができる。表示内容は、管理者の操作によって適宜公開することができる。

【0051】

図８は、定時定路運行を行うための処理を示すものであり、実施形態では、採算に応じて運行確定と運行休止との処理を行うようになっている。まず、Ｑ６１において、定時定路運行となるある所定の運行便について、運転担当可能なドライバーが仮に選択されて、この仮に選択されたドライバーのドライバー端末に対して、上記所定の運行便についての運転担当者として仮に決定された旨の報知が行われる。

【0052】

Ｑ６２では、上記所定の運行便について、仮の乗車予約を受け付けるための仮の公開が行われ、これに伴ってＱ６３において乗車予約の受付が行われる。すなわち、乗車予約しようとするユーザは、そのユーザ端末を操作して管理サイトＵ１にアクセスすることにより、所定の運行便について乗車予約することが可能な状況とされる。

【0053】

Ｑ６４では、所定の運行便について、乗車予約の締切時間の所定時間前であるか否かが判別される。締切時間は、例えば所定の運行便の発車時刻の１時間前とか、あるいは前日の夕方６時００分まで等、適宜設定できる。また、上記所定時間は、例えば締切時間の例えば１時間前～２時間前までとされる。

【0054】

上記Ｑ６４の判別でＮＯのときはＱ６３に戻る（仮の乗車予約の受付継続）。Ｑ６４の判別でＹＥＳのときは、仮の乗車予約に基づいて、採算性が判断される。そして、Ｑ６５において、採算性があらかじめ設定された所定の採算条件を満足するか否かが判別される。上記所定の採算条件としては、利用者が所定人数以上（例えば２名以上）とすることができる。

【0055】

また、Ｑ６５、Ｑ６６の処理の少なくとも一方は、管理用端末Ｕ２を操作する運行管理者の判断によって行うことができ、この場合、採算条件を満足すると運行管理者が判断したときは、その旨の操作を運行管理者が行うことになる。勿論、Ｑ６５、Ｑ６６の処理を、管理サイトＵ１で自動的に判断することもできる。採算性の判断に際しては、走行距離をも勘案することができる（走行距離が長いほど、乗車予約したユーザが支払う料金が高額になる）。運行管理者は、乗車予約された内容から、ドライバーへの報酬と乗車予約したユーザが支払う料金とを管理用端末Ｕ２の表示画面に表示させて、この表示画面を見て採算性を判断することができる。この場合、ドライバーへの報酬とユーザが支払う料金を、管理サイトＵ１において自動計算させることもできる。

【0056】

上記Ｑ６６の判別でＹＥＳのとき、つまり採算条件を満足するときは、Ｑ６７において、所定の運行便について運行が確定した旨の処理が行われる。この確定した旨の処理では、少なくとも、Ｑ６１で仮に決定された運転者（のドライバー端末）に対して運行が確定して運転担当として正式に決定された旨の情報が、管理サイトＵ１からドライバー端末Ｕ４に対して行われる。また、仮に乗車予約したユーザのユーザ端末について、運行が確定して正式に乗車予約を受け付けた旨の情報が、仮に乗車予約したユーザのユーザ端末Ｕ３に対して行われる。

【0057】

Ｑ６７の後、Ｑ６８において、管理サイトＵ１によって、所定の運行便について正式に公開が行われ、またＱ６９において乗車予約の受付が行われる。正式の公開では、所定の運行便の運行を行うことが確定している旨の情報がユーザに報知される。この報知の手法は、ユーザ端末Ｕ３を利用したものであれば適宜選択することができる。例えば、管理サイトＵ１から各ユーザ端末Ｕ３に対して情報を送信することにより行うこともでき、またユーザがそのユーザ端末Ｕ２を操作して管理サイトＵ１にアクセスすることにより確認することもできる。

【0058】

Ｑ６９の後、Ｑ７０において、乗車予約の締切時間になったか否かが判別される。このＱ７０の判別でＮＯのときは、Ｑ６９に戻る（乗車予約の受付継続）。Ｑ７０の判別でＹＥＳのときは、Ｑ７１において、乗車予約したユーザのユーザ端末と、運転担当するドライバーのドライバー端末Ｕ４と、車載端末Ｕ５に対して、確定した運行内容の詳細が報知される。この報知の内容は、例えば、ドライバー名や使用する運行用車両の詳細、利用するユーザ名とその乗車位置と降車位置等とされる。

【0059】

前記Ｑ６６の判別でＮＯのときは、Ｑ７２において、管理サイトＵ１から仮の乗車予約したユーザのユーザ端末Ｕ３に対して、このままでは所定の運行便が休止される可能性がある旨の報知と、休止を避けるために割り増し料金を支払う意思があるかの問い合わせが行われる。この後、Ｑ７３において、仮の乗車予約したユーザから割り増し料金の支払いＯＫの旨の返信があったか否かが判別される。このＱ７３の判別でＹＥＳのときは、Ｑ６７に移行する。また、Ｑ７３の判別でＮＯのときは、Ｑ７４において、管理サイトＵ１から、所定の運行便の運行が休止される旨の情報が、少なくとも、運転担当として仮に決定されたドライバーのドライバー端末Ｕ４と、仮の乗車予約を行ったユーザのユーザ端末Ｕ３とに対して報知される。

【0060】

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

【0061】

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

【0062】

Ｑ３２では、デマンド運行の乗車予約を受け付けたか否かが判別される。このＱ３２の判別でＮＯのときは、リターンされる（デマンド運行なし）。Ｑ３２の判別でＹＥＳのときは、Ｑ３３において、運転を担当するドライバーの選択が行われる（使用する運行用車両は、選択されたドライバーに応じて自動的に決定される）。ドライバーの選択に際しては、記憶部１０に記憶（登録）されているドライバーの中から、運転担当することが可能なドライバーの中から１名を選択することにより行うこととなる。ドライバーの選択に際しては、運転担当が可能なドライバーの中から順番に自動的に選択することもできる。また、ドライバーの選択に際しては、管理者が管理用端末Ｕ２を利用して、手動操作によって選択することもでき、この場合、デマンド運行を希望した乗客のドライバー指定に基づく選択とすることもできる。選択されたドライバー（のドライバー端末Ｕ４）に対しては、乗車予約された内容が報知（送信）される。

【0063】

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

【0064】

Ｑ３７の後、あるいはＱ３６の判別でＮＯのときはそれぞれ、Ｑ３８において、デマンド運行での走行経路が、乗客に関する情報や乗車位置と降車位置に関する情報と共に、ドライバー端末Ｕ４や車載端末Ｕ５に対して報知（送信）される（相乗り者の確認等のためにユーザ端末Ｕ３に対して報知することもできる）。

【0065】

図１０は、図９のＱ３５における相乗りの受付処理を示す。まず、Ｑ５１において、デマンド運行を当初に乗車予約した乗客（ユーザ）が、相乗りを許可しているか否かが判別される。このＱ５１の判別でＹＥＳのときは、Ｑ５２において、相乗りの受付が行われる。この相乗り受付は、管理用端末Ｕ２を操作することにより、デマンド運行の日、時間、乗車位置（出発地）、降車位置（目的地）、乗車位置から降車位置までの走行経路を、ユーザ端末Ｕ３に対して報知することにより行われる。そして、この報知された情報に基づいて、相乗り希望者から相乗りの乗車予約を受け付けることになる。相乗り希望者は、希望する乗車位置と降車位置とを指定して、相乗りの乗車予約を行うことになる（相乗りの乗車予約は管理サイトＵ１に記憶される）。なお、相乗りを促す（相乗りの乗車予約を受け付ける）ユーザ範囲については後述する。

【0066】

Ｑ５３では、相乗り希望者が存在するか否かが判別される。このＱ５３の判別でＹＥＳのときは、例えば管理用端末Ｕ２を操作することにより、相乗りに関する情報が、乗車予約されたデマンド運行を利用する全てのユーザ（ユーザ端末Ｕ３）および運転担当のドライバー（のドライバー端末Ｕ４）、および車載端末Ｕ５に対して報知される。相乗りに関する情報としては、少なくとも走行経路とユーザ名と各ユーザ毎の乗車位置および降車位置が含まれるものとされる。

【0067】

上述したような住民自身による運行サービスにおいては、ドライバーは他の仕事の合間に自車等を運転してサービスを提供するのであって、職業ドライバーのように詰め所に常時待機してユーザからの運行要請を待っているわけではない。したがって、ドライバーとユーザとは、サービス提供者とこれを利用するお客様という関係ではなく、運行サービスを成立させ継続ならしめる同等の立場として、運行予告やこれに続く運行確定の通知という利便性を共に受けるようにする必要性が高いものとなる。

【0068】

次に、図１１以下を参照しつつ、前述した各説明の補足説明を行うこととする。まず、図１１は、運行管理者により選択されたある日について、管理用端末Ｕ２の表示画面７０に表示されるドライバーの運転担当可能な時間帯の表示例を示す。図１１の表示は、管理用端末Ｕ２を操作したときの現在時点での表示例となっている。

【0069】

図１１中、ドライバー欄７１には、各ドライバーを識別符号でもって識別する識別欄７１ａと、ドライバーの氏名を記載した氏名欄７１ｂとが表示される。各ドライバー毎に、運転担当可能な時間帯が、横方向に延びる棒グラフ式に表示される。棒グラフは、例えば色分けされて、新たに運転担当させることが可能な時簡帯については例えば白色でもって表示される（図１１ではドット表示としてある）。運転担当することが既に決定されているドライバーについては、例えば緑色で表示されている（図１１ではハッチングを付して示す）。現在運行担当中の場合は例えば赤色で表示される（図１１ではダブルハッチングを付して示す）。

【0070】

図１１に示す例では、ドライバーＡは、ＡＭ６時からＰＭ６時まで運転担当することが可能であり、この時間帯の範囲の任意の時間帯でもって新たに運行担当することが可能な者である。ドライバーＢは、ＡＭ１０時からＰＭ４時まで運転担当可能であるが、ＡＭ１０時からＰＭ１時まで既に運転担当することが決定されている者であり、ＰＭ１時からＰＭ４時までの間であれば新たに運転担当することが可能な者である。ドライバーＣは、ＡＭ８時からＰＭ４時まで新たに運転担当することが可能な者である。ドライバーＤは、ＡＭ６時からＡＭ１０時までの間で運転担当中（運行中）となっている者である。ドライバーＥは、ＡＭ１０時からＰＭ６時まで運転担当可能ではあるが、ＰＭ４時からＰＭ６時までの間は既に運転担当することが決定されている者である。図１１において、例えばＡＭ１０時からＡＭ１２時までの間の時間帯で新たに運転を担当するドライバーを選択する際は、ドライバーＡ、ＣまたはＥから選択することになる。

【0071】

運行管理者は、図１１に示すような表示を見つつ、所定の運行便について運転担当可能なドライバーを選択することになる。例えば画面をタッチ操作することによりドライバーの選択が行われるが、別途各ドライバー毎に選択のためのタッチ式のスイッチを別途表示させておくこともできる。また、各ドライバーについての詳細情報を表示させる例えばタッチ式のスイッチを別途表示させておくこともできる。

【0072】

図１２は、管理用端末Ｕ２の表示画面において、乗車予約状況の表示例を示すものである。図１２に示す例では、停留所Ｓ１を出発地とする定時定路運行便を示すものとなっている。表示は、出発時間を示す欄８１、運行便の識別符号（Ｂ００１、Ｂ００２等）を示す欄８２、便名（上地区朝１便等）を示す欄８３、車両情報（車種、色、ナンバープレート番号、乗車定員）を示す欄８４、担当ドライバーを示す欄８５、乗車予約に関する欄８６、運行便の状況を示す欄８７と、が表示される。予約欄８６において、人形の形態で示すマークは、乗車予約された人数を示し、１つの人形マークが乗車予約数１人を示している。

【0073】

図１２では、識別符号Ｂ００１となる上地区朝１番の運行便については、乗車予約者数が予約欄８６に３名が乗車予約されていて、既に予約終了となっていることが示される。識別符号Ｂ００２、Ｂ００３で示される運行便については、それぞれ２名が乗車予約されていて、運行確定しているために正式公開中であることが示される。識別符号Ｂ００４で示される運行便については、乗車予約数が０でり、仮公開中であることが示される。

【0074】

状況を示す欄８７に表示されている例えばタッチ式のスイッチ８７ａを運行管理者が操作することにより、正式公開（正式の公開）と仮公開（仮の公開）とが切換えられる。このスイッチ８７ａを操作することにより、さらに、非公開も選択可能とされている。非公開が選択されているときは、その運行便については、乗車予約のためにユーザ端末Ｕ３から管理サイトＵ１へアクセスしても、非公開中の運行便についてはユーザ端末Ｕ３にはなんら表示されないものとされる。非公開の運行便は、まだ乗車予約の受付準備段階である等のときとされる。

【0075】

図１３は、定時定路運行を乗車予約する際のユーザ端末Ｕ３の表示画面での基本的な表示例である。例えば、ユーザ端末Ｕ３を操作して、定時定路運行の乗車予約を行う旨の情報を管理サイトＵ１へ送信することにより、その返信として表示画面３０において図１３に示すような表示が行われる。また、管理サイトＵ１からユーザ端末Ｕ３へあらかじめ乗車予約に必要な情報をあらかじめユーザ端末Ｕ３に送信して、送信内容をユーザ端末Ｕ３ｎ意記憶させておくことにより、ユーザ端末Ｕ３にただちに図１３に示すような表示を行わせることもできる。表示画面３０には、表示欄３１において、定時定路運行の乗車予約であること、予約対象となる日（定時定路運行を利用する日）と、ユーザ名とが表示される。なお、乗車予約を確定した際には、表示されたユーザ名でもって乗車予約される。

【0076】

表示画面３０には、定時定路運行の便名（第１便、第２便・・・）が表示されると共に、各便について、出発時間（実施形態では停留所Ｓ１での出発時間）が表示される。また、各便について、乗車位置を選択するタッチ式のボタン表示（スイッチで、以下同じ）３２と、降車位置を選択するタッチ式のボタン表示３３と、利用人数を選択するタッチ式のボタン表示３４と、予約する旨を選択するタッチ式のボタン表示３５とが表示される。

【0077】

乗車位置と降車位置との選択は、それぞれ停留所（Ｓ１～Ｓ７）からの選択となる。すなわち、第１便を例にすると、乗車位置の選択を行うボタン表示３２において、△または▽のボタンを操作することにより、ボタン表示３２に表示される停留所が順次変更される。第１便については、図１３では、乗車位置が停留所Ｓ１とされた状態が示される。同様の操作によって、降車位置の選択が行われ（第１便では停留所Ｓ６が降車位置として選択された状態）、乗車人数の選択が行われる（第１便では１人が選択された状態が示される）。ボタン表示３２～３４の表示内容を確認して、乗車予約を行うためのボタン表示３５を操作することにより、第１便について、表示内容に応じた乗車予約が行われる。

【0078】

乗車予約は、１回に複数の選択が可能であり、例えば、復路の便についても同様にして乗車予約を行うことができる。全ての乗車予約を行った後、ボタン表示３６を操作して予約完了とされる。このボタン表示３６が操作されることにより、乗車予約された内容が、ユーザ端末Ｕ３から管理サイトＵ１へ送信される。

【0079】

図１４は、ある定時定路運行が、採算条件を満足しないことにより運行休止された旨の報知が管理サイトＵ１からユーザ端末Ｕ３へ報知されたときに、ユーザ端末Ｕ３の表示画面３０での表示例を示すものである。この図１４においては、第１便が休止される場合を示し、表示欄４１において、例えば「第１便は休止となりました。」という表示が行われる。図１４では、第１便の表示があるものの、休止であることから、乗車位置、降車位置、利用人数。乗車予約するボタン表示（図１３の３２～３５）は表示されない。

【0080】

ここで、図８におけるＱ７２での問い合わせは、仮の乗車予約したユーザのユーザ端末での表示欄４１において、例えば、「割り増し料金を支払うことにより第１便の運行が確定します。割り増し料金を支払いますか？」という問い合わせの表示が行われる。また、同時に、表示欄４１に、「割り増し料金を支払う」の選択を行うためのタッチ式のボタン表示と、「割り増し料金の支払いを拒否する」の選択を行うためのタッチ式のボタン表示とが合わせて表示される。ユーザが、上記いずれかのボタン表示を操作することにより、選択結果が管理サイトＵ１に送信される。

【0081】

図１５は、デマンド運行での相乗りを促すためのユーザ端末Ｕ３での表示例が示される。表示欄４１に、デマンド運行であること等が表示される。表示欄４２において出発地と出発時間とが表示される。表示欄４３において、目的地と目的地への到着予想時間とが表示される。表示欄４４において、ユーザ端末Ｕ３を操作しているユーザの自宅から最寄りの停留所への到着時間が表示される。表示欄４５において、地図上に走行経路（破線で示される）が表示される。なお、図１５では、走行経路が、停留所Ｓ１を経由する場合が示される。なお、相乗りするユーザの自宅を経由することを許容する場合は、最寄りの停留所への予想到着時間に代えて、自宅への到着予想時間とすればよい。

【0082】

デマンド運行の内容を理解したユーザが、このデマンド運行を乗車予約する（相乗りする）場合は、表示欄４６での表示内容を操作することになる。すなわち、表示欄４６中のタッチ式のボタン表示４７を操作することにより出発地点が選択される。選択可能な出発地点としては、例えば停留所Ｓ１～Ｓ７や自宅を含めることができる。タッチ式のボタン表示４８を操作することにより目的地が選択される。タッチ式のボタン表示４９を操作することにより乗車人数が選択される。ボタン表示４７～４９を利用した選択が終了した後、タッチ式のボタン表示５０を操作することにより、デマンド運行に相乗りする旨の情報が、その予約内容と共に管理サイトＵ１に送信される。

【0083】

図１６は、管理用端末Ｕ２の表示画面７０において、デマンド運行について相乗りを促すための表示例を示す。表示画面７０には、上方から下方へ順に、乗車予約されたデマンド運行便が順次表示される。各デマンド運行便について、欄９１～９８が設定されている。欄９１は、出発時間を示す。欄９２は、便名を示す。欄９３は、出発地を示す。欄９４は、目的地を示す。欄９５は、使用する運行用車両に関する情報が示される。欄９６には、運転担当するドライバー名が示される。

【0084】

欄９７は、デマンド運行便の公開と非公開とを選択する欄である。すなわち、表示されている第１選択部（第１入力部）としてのタッチ式のボタン表示９７ａを操作することにより、公開と非公開とのいずれか一方が選択可能とされる。

【0085】

欄９８は、公開範囲（公開対象となるユーザの範囲）を選択する欄である。すなわち、表示されている第２選択部（第２入力部）としてのタッチ式のボタン表示９８ａを操作することにより、公開範囲が適宜選択される。設定されている公開範囲としては、実施形態では、次のように設定されているが、これに限るものではない。

【0086】

すなわち、選択可能な公開範囲として、（１）デマンド運行を当初に乗車予約したユーザの仲間（ユーザ登録の際に登録されている仲間）、（２）デマンド運行を当初に乗車予約したユーザの近隣地区に居住するユーザ、（３）出発地付近に居住するユーザ、（４）走行経路付近に居住しているユーザ、（５）該運行便に類似する（利用時間帯および利用走行経路が略同じ）過去の運行便を利用したユーザ、（６）該運行便を乗車予約したユーザと同乗したことのあるユーザ、とされている。図１６では、デマンド１便では、非公開であることから、公開範囲は表示はされていない。デマンド２便では、公開が選択されて、公開範囲は、仲間とされている。デマンド３便では、公開が選択されて、公開範囲が近隣地区（に居住するユーザ）とされている。

【0087】

図１０の図５２での相乗りの受付は、上述の欄９８で選択されている公開範囲のユーザに対してのみ行われるものとされる。つまり、管理サイトＵ１は、相乗りを促すためのユーザ端末Ｕ３への報知は、欄９８で選択されている公開範囲のユーザのユーザ端末に対してのみ行うことになる。なお、相乗りを促すための公開は、ユーザ端末Ｕ３から管理サイトＵ１へのアクセスを待つことなく、管理サイトＵ１から選択されたユーザ範囲のユーザ端末Ｕ３全てに対して報知するのが好ましい（相乗りを促す情報をユーザ端末Ｕ３へ送信して、送信されことをユーザ端末Ｕ３のチャイムを鳴らしたりランプを点滅させる等で積極的に知らせる）。

【0088】

図１７は、過去に実行されたデマンド運行に関する情報を、全ユーザと全ドライバーに対して公開する際の表示例が示される。この図１７の表示は、管理用端末Ｕ２の表示画面７０での表示内容となっているが、これと同様の表示が、ユーザ端末Ｕ３およびドライバー端末Ｕ４でも表示可能とされる。具体的には、ユーザ端末Ｕ３あるいはドライバー端末Ｕ４から管理サイトＵ１にアクセスして、管理サイトＵ１に表示されている過去のデマンド運行の情報欄を選択することにより、ユーザ端末Ｕ３やドライバー端末Ｕ４の表示画面に表示される。

【0089】

図１７では、過去のある日に行われたデマンド運行便が上から下への順次表示される。各デマンド運行便について、欄１０１～１０６が表示される。欄１０１は、便名を符号化して示す。欄１０２は、利用時間帯を示す（例えば１１時３０分～１１時５０分等）。欄１０３は、出発地の地点情報を示す（利用者の個人が特定されにくい表示とされる）。欄１０４は、目的地の地点情報を示す（利用者の個人が特定されにくい表示とされる）。欄１０５は、利用人数（ドライバーを除く乗車人数）を示す。欄１０６は、走行経路を示すが、「詳細」という文字が付された選択スイッチを操作することにより、表示画面７０に走行経路が示される。

【0090】

過去に行われたデマンド運行の情報を全ユーザに提供することにより、ユーザにおいては、例えば次のような利点がある。すなわち、短距離あるいは長距離の利用があることを確認すると、いままでは短距離あるいは長距離であるため利用を控えていたユーザが、デマンド運行を利用するようになることが促される。同様に、夜間とは早朝の利用があることを確認すると、いままでは夜間あるいは早朝であるため利用を控えていたユーザが、デマンド運行を利用するようになることが促される。さらに、目的地が遠すぎることや走行経路が複雑であったり走行しにくい経路であるために利用を控えていたユーザが、同様の目的地や走行経路の利用があることを確認すると、デマンド運行を利用するようになることが促される。

【0091】

デマンド運行の運転を担当するドライバーにとっては、どのようなデマンド運行が行われているかを知ることができ、デマンド運行する際にあらかじめ十分な心構えや準備を行うことが可能となる。例えば、あまり走行したことがない走行経路がデマンド運行での利用頻度が高いということが確認されると、機会があれば利用頻度の高い走行経路をあらかじめ走行して、道路状況を十分に確認しておく等の準備を行うことが促されることになる（安全運転にも繋がる）。また、早朝や夜間での利用頻度が高いということが確認されると、早朝や夜間で運転担当することもあり得るということをあらかじめ十分認識しておくことができる。

【0092】

以上実施形態について説明したが、本発明は、実施形態に限定されるものではなく、特許請求の範囲の記載された範囲において適宜の変更が可能であり、例えば次のような場合をも含むものである。

【0093】

（１）定時定路運行の往路便で使用した運行用車両（およびドライバー）を、そのまま復路便用の運行用車両として利用することもできるが、往路便と復路便との運行用車両（およびドライバー）を相違させることもできる。

【0094】

（２）仮の乗車予約の受け付けを終了した段階での採算性が採算条件を満足しないときは、運行管理者は、所定の運行便について過去の利用者を記憶部１０から呼び出して、この呼出した過去の利用者に所定の運行便の利用を促すようにすることもできる。

【0095】

（３）採算の関係から休止されることもある所定の運行便としては、定時定路運行に限らずデマンド運行であってもよい。例えば、デマンド運行の乗車予約人数が１名の場合は、割り増し料金支払いかあるいは相乗りが有る場合を条件として、運行確定する。

【0096】

（４）図８のＱ６６の判別でＮＯのときは、Ｑ７２、Ｑ７３の処理を行うことなく、直ちに所定の運行便を休止させる処理を行うようにしてもよい。また、定時定路運行において仮の乗車予約を設定しないようにすることもできる。この場合、図８において、ドライバーの確保を行った後（Ｑ６１に対応するが正式決定となる）、Ｑ６７～Ｑ７１の処理を行うようにすればよい。

【0097】

（５）定時定路運行についても公開範囲を設定するようにしてもよい。すなわち、ある定時定路運行便について乗車予約の締切時間よりも所定時間前の段階で乗車予約数が少ない場合は、乗車予約を促すための報知をユーザ（のユーザ端末）に行うようにし、この報知されるユーザの範囲を、適宜選択できるようにすることもできる。この場合、報知されるユーザ範囲としては、例えば過去にこの定時定路運行便を利用したユーザや、この定時定路運行便と類似するデマンド運行を過去に利用したユーザ等、適宜設定できる。このように、定時定路運行便については、公開するものの、全ユーザを対象として公開と、特定のユーザに対する公開とを選択可能とするようにすることもできる。

【0098】

（６）管理サイトＵ１は、自動化という点では、他の端末Ｕ２～Ｕ５と情報の授受を自動的に行えるように設定するのが好ましいが（例えばある情報が入力されたときに、これに対応した出力情報を他の端末Ｕ２～Ｕ５に対して自動的に行う）、管理用端末Ｕ２を積極的に利用することにより、管理サイトＵ１を極力簡単化して、設置コスト低減等を図ることもできる。

【0099】

（７）車載端末は、そのディスプレイを運行用車両のインストルメントパネル上に配設する一方、その操作部を例えばコンソールボックスあるいはその付近に設けたコマンダスイッチとして構成することもできる（コマンダスイッチによって、表示画面上のカーソルの移動や選択を行う等）。また、ドライバー端末と車載端末とを共通（兼用）とすることもでき、この場合ドライバー端末を運行用車両に設置される態様とすることができ、また車載端末を運行用車両から外部に持ち出すことのできる態様とすることもできる。さらに、ドライバー端末と車載端末とを別途設ける場合、ドライバー端末と車載端末とを同期させて、管理サイトＵ１からの情報をドライバー端末と車載端末とで同じように確認できるようにすることもできる。

【0100】

（８）フローチャートに示すステップあるいはステップ群は、その機能内容に手段（あるいは機能）の名称を付した表現でもって、例えば管理サイトＵ１の有する手段（あるいは機能）として表現することができる。また、勿論、本発明の目的は、明記されたものに限らず、実質的に好ましいあるいは利点として表現されたものを提供することをも暗黙的に含むものであり、また本発明は運行管理支援システムとして把握することもできる。

【産業上の利用可能性】

【0101】

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

【符号の説明】

【0102】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】