JP2020052885A - 情報出力装置 - Google Patents

Abstract

【課題】複数の乗降位置を含む所定のコースを巡回又は往復し複数のユーザが乗降可能な車両の利便性を高める。【解決手段】複数の乗降位置を含む所定のコースを巡回又は往復し複数のユーザが乗降可能な車両に適用可能である情報出力装置であって、車両にユーザが乗車することを要求していることを表す乗車要求を取得する乗車要求取得部と、乗車要求に基づいて、走行予定コースを、所定のコースから他のコースに変更するコース変更部と、所定のコースから他のコースへの変更に基づいて、複数の乗降位置のうちの少なくとも１つの乗降位置に関する時刻表情報であって、車両の到着予定時間を表す時刻表情報を変更し、変更した時刻表情報を出力する出力制御部とを備える、情報出力装置が開示される。【選択図】図２

Description

本開示は、情報出力装置に関する。

移動体通信装置に対して、タクシー会社ごとの空車タクシー情報を提供する技術が知られている。

特開２００９−２１１５８２号公報

しかしながら、上述したような従来技術は、複数の乗降位置を含む所定のコースを巡回又は往復し複数のユーザが乗降可能な車両（以下、「路線車両」と称する）に適用することが難しい。かかる車両は、一般的に、タクシーとは異なり、コースが決められており、配車という概念がない。

ところで、近年、高齢化が進み、路線バスのような路線車両の重要性が増しており、車の利用率が高い地域内での活用が模索されてきている。現在知られている路線車両は、一般的に、決まったコースを走行するだけであるので、ユーザ数の少ない地域では、利便性の改善の余地がある。他方、あるユーザの都合で、コースを変更すると、他のユーザの利便性が損なわれるといった背反も生じる。

そこで、１つの側面では、本発明は、複数の乗降位置を含む所定のコースを巡回又は往復し複数のユーザが乗降可能な車両の利便性を高めることを目的とする。

１つの側面では、以下のような解決手段を提供する。

（１）複数の乗降位置を含む所定のコースを巡回又は往復し複数のユーザが乗降可能な車両に適用可能である情報出力装置であって、
前記車両にユーザが乗車することを要求していることを表す乗車要求を取得する乗車要求取得部と、
前記乗車要求に基づいて、走行予定コースを、前記所定のコースから他のコースに変更するコース変更部と、
前記所定のコースから前記他のコースへの変更に基づいて、前記複数の乗降位置のうちの少なくとも１つの乗降位置に関する時刻表情報であって、前記車両の到着予定時間を表す時刻表情報を変更し、変更した時刻表情報を出力する出力制御部とを備える、情報出力装置。

（２）上記（１）の構成において、前記出力制御部は、更に、前記変更に基づいて、前記他のコースを表す変更コース情報を出力することを特徴とする。

（３）上記（１）又は（２）の構成において、前記乗車要求は、位置を表す位置情報を含み、
前記コース変更部は、前記位置情報の表す位置を通るように、前記他のコースを決定することを特徴とする。

（４）上記（１）から（３）のいずれかの構成において、前記出力制御部は、ユーザの端末の表示装置、及び前記複数の乗降位置のうちの少なくとも１つの乗降位置付近、のうちの少なくともいずれかに、前記時刻表情報を出力することを特徴とする。

（５）上記（１）から（４）のいずれかの構成において、前記コース変更部は、走行予定コースを変更した場合の現在乗車中のユーザの不都合の度合いに基づいて、走行予定コースを変更するか否かを判定することを特徴とする。

（６）上記（５）の構成において、前記コース変更部は、更に、前記乗車要求を行うユーザの不都合の度合いであって走行予定コースを変更しない場合の不都合の度合いに基づいて、走行予定コースを変更するか否かを判定することを特徴とする。

１つの側面では、本発明によれば、複数の乗降位置を含む所定のコースを巡回又は往復し複数のユーザが乗降可能な車両の利便性を高めることが可能となる。

路線バスシステムが適用される地域の区画を模式的に示す図である。 一実施例による路線バスシステムの全体構成を概略的に示す図である。 路線バスの内部を模式的に示す上面図である。 路線バスの制御系の構成の一例を示す概略図である。 処理装置の機能の一例を示す機能ブロック図である。 サーバの機能の一例を示す機能ブロック図である。 予約状態情報の一例の説明図である。 座席状態情報の一例の説明図である。 乗車可能区間情報の一例の説明図である。 コース変更処理部によるコース変更処理の説明図である。 コース変更判定用情報の一例の説明図である。 コース変更判定用情報の他の一例の説明図である。 時刻表情報の一例の説明図である。 広告情報の一例の説明図である。 ユーザ情報の一例の説明図である。 運行情報の出力例の説明図である。 乗車可能区間情報の出力例の説明図である。 複数の路線バスが同時に運行する場合に好適な運行情報の出力例の説明図である。 乗車要求の受付画面の出力例の説明図である。 乗車要求の受付画面の他の出力例の説明図である。 乗車要求の受付画面の他の出力例の説明図である。 ユーザが同伴者を伴う場合の乗車要求の受付画面の出力例の説明図である。 余裕度を含ませる場合の乗車要求の受付画面の出力例の説明図である。 プロジェクタの配置例を示す説明図である。 プロジェクタの構成の一例を示す図である。 プロジェクタの投映方向の制御に用いるマップの一例を示す図である。 変形例によるプロジェクタの搭載例を示す説明図である。 ジェスチャ認識装置のハードウェア構成の一例を示す図である。 プロジェクタ、ジェスチャ認識装置、及びサーバにより実現される予約受付のための情報のやり取りの一例を示すタイミングチャートである。 サーバが情報出力装置として機能するときの動作例を示す概略フローチャートである。 図２２のステップＳ３２２（乗車可否判定処理）の一例を示す概略フローチャートである。 図２２のステップＳ３２２（乗車可否判定処理）の他の一例を示す概略フローチャートである。 図２２のステップＳ３２６（コース変更可否判定処理）の一例を示す概略フローチャートである。 図２５のステップＳ３５２（路線バス間連携処理）の一例を示す概略フローチャートである。 図２５のステップＳ３５２（路線バス間連携処理）の他の一例を示す概略フローチャートである。

以下、添付図面を参照しながら各実施例について詳細に説明する。

図１は、以下の実施例に係る路線バスシステム１（図２参照）が適用される地域の区画を模式的に示す図である。

図１では、６×３＋４×３＝３０区間の地域が示される。地域は、例えば坂道が多い地域であることが好適であるが、平坦な地域であってもよい。なお、区画数や形状等は任意である。各区間には、住人の家や店などが存在しうる。図１には、以下で説明する路線バス（車両の一例）２（図２参照）の停留所Ａ１、Ａ２、Ａ３、Ａ１０が示される。なお、停留所の配置や数は任意である。以下では、一例として、路線バス２は、停留所Ａ１から停留所Ａ１０に向かい、次いで、停留所Ａ１０から停留所Ａ１まで向かい、以下、繰り返すような所定のコースを往復する態様で運行する。ただし、変形例では、路線バス２は、所定のコースを巡回する態様で運行してもよい。

路線バス２は、１台だけ運行してもよいし、複数台が同時に運行してもよい。

図２は、一実施例による路線バスシステム１の全体構成を概略的に示す図である。

本実施例では、一例として、路線バスシステム１は、登録されたユーザが利用可能である。以下では、説明上、ユーザとは、路線バスシステム１のユーザであり、路線バス２内の乗員は、乗車中のユーザを指す。ただし、路線バスシステム１は、登録されたユーザ以外も、例えば登録されたユーザの同伴者である場合等は、利用可能である。なお、変形例では、路線バスシステム１は、登録制ではなく、不特定のユーザが利用可能であってもよい。

路線バスシステム１は、路線バス２と、サーバ４と、ユーザ端末６と、プロジェクタ７と、ジェスチャ認識装置８とを含む。路線バス２、サーバ４、プロジェクタ７、及びユーザ端末６は、ネットワーク９を介して通信可能である。ネットワーク９は、無線通信網を含み、その他、インターネット、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでもよい。

［路線バス］
図３は、路線バス２の内部を模式的に示す上面図であり、ルーフを取り外した状態で示す概略図である。

本実施例では、一例として、路線バス２は、小型のバスであり、定員が８人である。具体的には、路線バス２は、２人掛けの４列シートを備える。図３には、８つの座席Ｓ０〜Ｓ７が示される。なお、座席数や配置等は任意である。

路線バス２は、乗降が容易となるように、例えばスライドドア式である。路線バス２は、各座席へのアクセスが可能な通路を有する。

路線バス２は、室内の前方正面に大型ディスプレイＤ１を備える。また、路線バス２は、各座席の背面に、個別のディスプレイＤ２〜Ｄ７を備える。例えば、ディスプレイＤ２は、座席Ｓ２に座るユーザが利用可能になるように座席Ｓ２の前方の座席、すなわち座席Ｓ０の背面に取り付けられる。なお、変形例では、大型ディスプレイＤ１やディスプレイＤ２〜Ｄ７のうちの一部又は全部に代えて又は加えて、他の形態の表示装置（例えばプロジェクタや空中ディスプレイ）が利用されてもよい。空中ディスプレイとは、光を空気中で結像することで映像を生成する装置である。また、ヘッドアップディスプレイ等が利用されてもよい。

路線バス２は、可動型のスピーカー３ａを備える。スピーカー３ａは、各座席へのアクセスが可能な通路上を移動可能である。スピーカー３ａは、例えばロボット等の形態であってもよく、ロボットの場合、二足歩行型や車輪型であってよい。なお、変形例では、可動型のスピーカー３ａに代えて又は加えて、指向性が可変のスピーカーが使用されてもよい。また、更なる変形例では、可動型のスピーカー３ａは省略されてもよい。また、スピーカー３ａに代えて又は加えて、ディスプレイＤ２〜Ｄ７にスピーカーが内蔵されてもよいし、他の箇所にスピーカーが設けられてもよい。

路線バス２は、車内を撮像するカメラ３ｂを備える。図３では、１つのカメラ３ｂが室内の前方正面に後方向きに取り付けられるが、カメラ３ｂは、複数個設けられてもよい。カメラ３ｂは、乗員を認識するための画像を取得するために設けられる。ただし、カメラ３ｂの画像は、他の用途（例えばセキュリティ等）で利用されてもよい。

図４は、路線バス２の制御系の構成の一例を示す概略図である。

路線バス２の制御系は、処理装置１０を含む。処理装置１０には、ＣＡＮ（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ）などの適切なバスを介して、車両内の各種の電子機器３０（スピーカー３ａ、大型ディスプレイＤ１、ディスプレイＤ２〜Ｄ７、カメラ３ｂ等）が接続されている。

電子機器３０は、上述したスピーカー３ａ、大型ディスプレイＤ１、ディスプレイＤ２〜Ｄ７、及びカメラ３ｂの他、入力装置３と、自律走行用センサ３ｃと、制駆動力制御装置３ｄと、操舵制御装置３ｅと、ＧＰＳ受信機３ｆとを含む。

入力装置３は、乗員が各種指示を入力するための装置である。入力装置３は、リモートコントローラ等の形態であってよく、各座席に設けられてもよい。あるいは、入力装置３は、ディスプレイＤ２〜Ｄ７に内蔵されてよいタッチパネルにより実現されてもよい。あるいは、入力装置３は、路線バス２内に搭載されてもよい音声認識装置やジェスチャ認識装置により実現されてもよい。この場合、音声認識装置やジェスチャ認識装置は、ロボットの形態であるスピーカー３ａにより実現されてもよい。

自律走行用センサ３ｃは、自律走行に必要又は有用なセンサであり、例えばレーダセンサ（例えばミリ波レーダセンサ）、画像センサ（例えばステレオカメラ）、ＬｉＤＡＲ（ライダー）、ジャイロセンサ、加速度センサ等である。電子機器３０は、自律走行用に、自律走行用センサ３ｃに加えて、車々間通信器、路車間通信機等を備えてもよい。

制駆動力制御装置３ｄは、制動力制御装置としてのブレーキＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）、駆動力制御装置としてのエンジンＥＣＵ等を含む。ブレーキＥＣＵは、目標制動力に応じて車輪のマスタシリンダ圧を制御することで、制動力を制御する。エンジンＥＣＵは、目標駆動力に応じてエンジンの燃料噴射量等を制御することで、駆動力を制御する。なお、制駆動力制御装置３ｄは、路線バス２が電動又はハイブリッド式である場合は、駆動力制御装置として走行用モータを制御するＥＣＵを含んでよい。

操舵制御装置３ｅは、目標操舵角に応じて操舵装置を制御する。

ＧＰＳ受信機３ｆは、ＧＰＳ衛星（又はＧＮＳＳ：Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ衛星）からの電波を受信して、路線バス２の位置を算出する。

処理装置１０は、コンピュータの形態であり、例えばＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）として具現化されてもよい。処理装置１０は、図４に示すように、バス１９で接続されたＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１３、補助記憶装置１４、ドライブ装置１５、及び通信インターフェース１７、並びに、通信インターフェース１７に接続された有線送受信部２５及び無線送受信部２６を含む。

補助記憶装置１４は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。

有線送受信部２５は、有線ネットワークを利用して通信可能な送受信部を含む。有線送受信部２５には、電子機器３０が接続される。ただし、電子機器３０の一部又は全部は、バス１９に接続されてもよいし、無線送受信部２６に接続されてもよい。

無線送受信部２６は、ネットワーク９（図２参照）を利用して通信可能な送受信部である。また、無線送受信部２６は、近距離無線通信（ＮＦＣ：Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）部、ブルーツース（Ｂｌｕｅｔｏｏｔｈ、登録商標）通信部、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ−Ｆｉｄｅｌｉｔｙ）送受信部、赤外線送受信部などを含んでもよい。

なお、処理装置１０は、記録媒体１６と接続可能であってもよい。記録媒体１６は、所定のプログラムを格納する。この記録媒体１６に格納されたプログラムは、ドライブ装置１５を介して処理装置１０の補助記憶装置１４等にインストールされる。インストールされた所定のプログラムは、処理装置１０のＣＰＵ１１により実行可能となる。例えば、記録媒体１６は、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的あるいは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等のように情報を電気的に記録する半導体メモリ等であってよい。

図５は、処理装置１０の機能の一例を示す機能ブロック図である。

処理装置１０は、走行予定コース受信部１０２と、時刻表情報受信部１０３と、センサ情報取得部１０４と、車両位置情報取得部１０６と、目標制駆動力決定部１０８と、目標操舵角決定部１１０と、乗員状態検出部１１２と、情報出力制御部１１４と、乗員要求送信部１１６を含む。走行予定コース受信部１０２、時刻表情報受信部１０３、センサ情報取得部１０４、車両位置情報取得部１０６、目標制駆動力決定部１０８、目標操舵角決定部１１０、乗員状態検出部１１２、情報出力制御部１１４、及び乗員要求送信部１１６は、ＣＰＵ１１が記憶装置（例えばＲＯＭ１３）内のプログラムを実行することで実現できる。また、処理装置１０は、走行予定コース記憶部１２０を含む。走行予定コース記憶部１２０は、例えば補助記憶装置１４により実現できる。

走行予定コース受信部１０２は、サーバ４から走行予定コースを表す情報（以下、「コース情報」とも称する）を受信する。本実施例では、走行予定コースは、基本コースで決まっているが、後述するように、所定の場合は基本コースから変更される。なお、サーバ４は、走行予定コースを基本コースから他のコースに変更する場合だけ、変更後のコースを路線バス２に送信してもよい。

時刻表情報受信部１０３は、サーバ４から時刻表を表す情報（以下、「時刻表情報」と称する）を受信する。本実施例では、走行予定コースが基本コース以外のコースに変更される場合がある。このようなコースの変更は、停留所等への到着予定時刻を変化させる場合があるので、かかる到着予定時刻の変化を反映した時刻表は、到着を待つユーザにとって有用となる。

センサ情報取得部１０４は、自律走行用センサ３ｃから各種情報を取得する。

車両位置情報取得部１０６は、ＧＰＳ受信機３ｆから車両位置情報を取得する。車両位置情報取得部１０６は、取得した車両位置情報をサーバ４に送信する。

目標制駆動力決定部１０８は、目標駆動力を決定する。例えば、目標駆動力は、所定の巡航速度（例えば２０ｋｍ／ｈ）で定速走行するように決定される。また、目標制駆動力決定部１０８は、自律走行用センサ３ｃからの各種情報等に基づいて、必要に応じて目標制動力を決定する。例えば、障害物が検出された場合は、障害物の手前で停車するように目標制動力が決定される。目標制駆動力決定部１０８は、目標駆動力や目標制動力を決定すると、決定した目標駆動力及び目標制動力を制駆動力制御装置３ｄに与える。なお、所定の巡航速度は、可変であってもよく、その場合、所定の巡航速度は、サーバ４から指示されてよい。

目標操舵角決定部１１０は、目標操舵角を決定する。目標操舵角は、走行予定コースに沿って延在する道路上の白線等の認識結果に基づいて設定されてもよい。あるいは、目標操舵角は、走行予定コースの軌道と現在の路線バス２の位置や向きとの関係に基づいて決定されてよい。目標操舵角決定部１１０は、目標操舵角を決定すると、決定した目標操舵角を操舵制御装置３ｅに与える。

このようにして、目標制駆動力決定部１０８及び目標操舵角決定部１１０は、制駆動力制御装置３ｄ及び操舵制御装置３ｅと協動して、自律走行用センサ３ｃからの各種情報に基づいて、走行予定コースに沿って路線バス２が走行するように路線バス２の自律走行を実現する。

乗員状態検出部１１２は、カメラ３ｂからの情報に基づいて、路線バス２内の乗員の状態を検出する。検出対象の乗員の状態は、乗員の座席（どの座席が使用されているか）、及び乗員のユーザＩＤである。乗員のユーザＩＤは、あらかじめ登録されたユーザの顔画像とカメラ３ｂからの画像内の各顔画像部とのパターンマッチングにより導出されてもよい。あるいは、乗車及び／又は降車の際にＩＤカードをかざす方法を採用する場合は、ユーザＩＤは、ＩＤカードから取得されてもよい。ＩＤカードは、ユーザ登録の際に作られる磁気カードであってよい。ＩＤカードは、ユーザ端末６内に電子的に記憶されるカードであってもよい。この場合、ユーザ端末６は、近距離通信によりユーザＩＤを路線バス２に設けられる受信機（図示せず）に送信する。

乗員状態検出部１１２は、定期的に又は停留所を含む停車予定位置（乗降用の停車予定位置）ごとに、乗員の状態を検出してもよい。乗員状態検出部１１２は、検出した乗員の状態を表す情報（以下、「乗員状態情報」とも称する）をサーバ４に送信する。

情報出力制御部１１４は、スピーカー３ａや、大型ディスプレイＤ１、ディスプレイＤ２〜Ｄ７等を介して、路線バス２内の乗員に向けて各種情報を出力する。各種情報及びその出力方法等は、後で詳しく説明する。

乗員要求送信部１１６は、乗員からの各種要求（例えば降車予定位置の変更要求）をサーバ４に送信する。乗員からの各種要求は、入力装置３を介して入力されてよい。

走行予定コース記憶部１２０には、コース情報が記憶される。走行予定コース記憶部１２０に記憶されるコース情報のデフォルトは、基本コースを表すが、走行予定コース受信部１０２が上述のように他のコース（変更後のコース）を表すコース情報を受信すると、走行予定コース記憶部１２０内のコース情報は当該受信したコース情報で置換（上書き）される。なお、複数の路線バス２が同時に運行する状況では、複数の路線バス２のそれぞれに対して、コース情報が記憶される。

［サーバ］
サーバ４は、サーバコンピュータから形成される。サーバ４は、複数のサーバコンピュータから形成されてもよい。例えば、サーバ４は、クラウドコンピュータによって実現されてもよい。また、サーバ４は、路線バス２に搭載されたコンピュータによって実現されてもよい。また、サーバ４は、１台の路線バス２に搭載されたコンピュータにより実現されてもよいが、複数の路線バス２のそれぞれに搭載された複数のコンピュータにより協働して実現されてもよい。さらに、また、サーバ４は、路線バス２に搭載のコンピュータと路線バス２に搭載されていないコンピュータとにより協働して実現されてもよい。

図６は、サーバ４の機能の一例を示す機能ブロック図である。

サーバ４は、乗車可能区間導出部４００と、乗車要求受信部４０１と、乗車可否判定部４０２と、ユーザ特定部４０４と、予約受付部４０５と、降車予定位置変更受信部４０６と、コース変更処理部４０７と、時刻表生成部４０８と、車両状態更新部４０９と、座席状態更新部４１０と、出力制御部４１１と、ユーザ登録処理部４１２と、ジェスチャ入力処理部４１４とを含む。乗車可能区間導出部４００、乗車要求受信部４０１、乗車可否判定部４０２、ユーザ特定部４０４、予約受付部４０５、降車予定位置変更受信部４０６、コース変更処理部４０７、時刻表生成部４０８、車両状態更新部４０９、座席状態更新部４１０、出力制御部４１１、ユーザ登録処理部４１２、及びジェスチャ入力処理部４１４は、ＣＰＵ１１のようなＣＰＵが記憶装置（例えばＲＯＭ１３のような記憶装置）内のプログラムを実行することで実現できる。

また、処理装置１０は、予約状態情報記憶部４２０と、乗車可能区間記憶部４２１と、ユーザ情報記憶部４２２と、コース変更判定用情報記憶部４２３と、車両状態情報記憶部４２４と、座席状態情報記憶部４２５と、走行予定コース記憶部４２６と、時刻表情報記憶部４２８と、広告情報記憶部４３０とを含む。予約状態情報記憶部４２０、乗車可能区間記憶部４２１、ユーザ情報記憶部４２２、コース変更判定用情報記憶部４２３、車両状態情報記憶部４２４、座席状態情報記憶部４２５、走行予定コース記憶部４２６、時刻表情報記憶部４２８、及び広告情報記憶部４３０は、例えば補助記憶装置１４のような補助記憶装置により実現できる。なお、予約状態情報記憶部４２０、乗車可能区間記憶部４２１、ユーザ情報記憶部４２２、コース変更判定用情報記憶部４２３、車両状態情報記憶部４２４、座席状態情報記憶部４２５、走行予定コース記憶部４２６、時刻表情報記憶部４２８、及び広告情報記憶部４３０のうちの、任意の２つ以上の記憶部は、１つの記憶部として統合されてもよい。

なお、複数の路線バス２が同時に運行可能な構成では、乗車可能区間導出部４００、乗車要求受信部４０１、乗車可否判定部４０２、予約受付部４０５、降車予定位置変更受信部４０６、コース変更処理部４０７、時刻表生成部４０８、車両状態更新部４０９、座席状態更新部４１０、出力制御部４１１、予約状態情報記憶部４２０、乗車可能区間記憶部４２１、コース変更判定用情報記憶部４２３、車両状態情報記憶部４２４、座席状態情報記憶部４２５、走行予定コース記憶部４２６、時刻表情報記憶部４２８、及び広告情報記憶部４３０は、路線バス２ごとに機能する。ただし、後述するが、コース変更処理部４０７は、複数の路線バス２の運行状態を考慮するために、複数の路線バス２に対して共通に機能してもよい。

乗車可能区間導出部４００は、予約状態情報記憶部４２０内の予約状態情報（図７Ａ参照）及び座席状態情報記憶部４２５内の座席状態情報（図７Ｂ参照）に基づいて、路線バス２に対してユーザが乗車可能な区間である乗車可能区間を導出する。例えば、乗車可能区間は、現在、路線バス２が満席である場合は、路線バス２が満席でなくなる位置（ある乗員が降車する降車予定位置）から始まる。乗車可能区間は、基本的には、終点までであるが、複数のユーザ間の優先度の調整のために、終点よりも前の位置までとなる場合もある。例えば、ユーザＡが先に停車予定位置Ａ３からの乗車を予約しており、ユーザＡが停車予定位置Ａ３で乗車することで路線バス２が満席となる場合、ユーザＡよりも後に予約するユーザＢに対しては、乗車可能区間は、位置Ａ３までとなる。なお、路線バス２が満席でなく先の予約ユーザも存在しない場合は、乗車可能区間は、全区間となる。

乗車可能区間導出部４００は、乗車可能区間を導出すると、当該乗車可能区間を表す情報（以下、「乗車可能区間情報」と称する）（図７Ｃ参照）を生成し、乗車可能区間記憶部４２１内に記憶する。図７Ｃでは、乗車可能区間とともに乗車可能人数が記憶されている。この場合、乗車可能区間導出部４００は、乗車可能区間とともに、乗車可能区間ごとに乗車可能人数を算出する。

乗車要求受信部４０１は、後述のユーザ端末６から送信される乗車要求を受信する。乗車要求は、乗車を希望するユーザからの要求を表し、後述するように、乗車予定位置（乗車希望位置）及び降車予定位置（降車希望位置）を表す情報を含む。乗車を希望するユーザは、乗車予定位置及び降車予定位置を指定する態様で乗車要求を発生させる。また、乗車要求は、後述するように、降車予定位置への到着希望時刻（例えば許容できる最も遅い時刻）を表す情報や、同伴者がいる場合は同伴者の人数を表す情報のような、他の情報を任意的に含めることができる。なお、以下では、乗車要求に係るユーザとは、乗車要求を出したユーザ（当該乗車要求により乗車予約をしようとしているユーザ）を指す。

乗車可否判定部４０２は、乗車要求が取得されると、乗車要求に係るユーザの乗車（路線バス２への乗車）が可能であるか否かを判定する乗車可否判定処理を行う。例えば、乗車可否判定部４０２は、乗車要求に含まれる乗車予定位置及び降車予定位置に基づいて、ユーザの乗車の可否を判定する。この場合、乗車可否判定部４０２は、乗車可能区間記憶部４２１内の乗車可能区間情報（図７Ｃ参照）を利用できる。すなわち、乗車可否判定部４０２は、乗車予定位置及び降車予定位置が乗車可能区間内に属する場合は、乗車要求に係るユーザの乗車が可能であると判定する。

ここで、上述のように、乗車可能区間は、座席状態情報記憶部４２５内の座席状態情報（図７Ｂ参照）に基づいて導出される。従って、乗車可能区間記憶部４２１内の乗車可能区間情報を利用する場合は、路線バス２に乗車可能なユーザの数の上限値（座席数）と、現在の乗員の数と、乗員の降車予定位置とに基づいて、乗車可否判定処理が実行されることになる。これにより、乗員の降車による空席の増加を加味できる態様、乗車可否判定処理を行うことができるので、乗車可否の判定精度が向上する。

また、上述のように、乗車可能区間は、予約状態情報記憶部４２０内の予約状態情報（図７Ａ参照）に基づいて導出される。従って、乗車可能区間記憶部４２１内の乗車可能区間情報を利用する場合は、今後路線バス２に乗車することになるユーザの数、当該ユーザの降車予定位置をも考慮して、乗車可否判定処理が実行されることになる。これにより、乗車可否判定処理での乗車可否の判定精度が更に向上する。

また、乗車可否判定部４０２は、乗車要求に同伴者の情報が含まれる場合は、同伴者を含む全員が乗車できるか否かを判定する。なお、予約状態情報記憶部４２０内の予約状態情報（図７Ａ参照）の場合は、乗車可能人数が記憶されているので、かかる乗車可能人数の情報を利用して、同伴者を含む全員が乗車できるか否かを判定することができる。

また、乗車可否判定部４０２は、乗車要求に到着希望時刻や余裕度の情報が含まれる場合は、時刻表情報記憶部４２８内の時刻表情報に基づいて、到着希望時刻を考慮した態様で、乗車可否判定処理を行うこととしてもよい。具体的には、乗車可否判定部４０２は、降車予定位置での到着予定時間と到着希望時刻との関係に基づいて、ユーザの乗車の可否を判定する。この場合、到着予定時間が到着希望時刻よりも前である場合は、ユーザの乗車が可能であると判定する。更に、乗車可否判定部４０２は、降車予定位置での到着予定時間と到着希望時刻との関係と、余裕度とに基づいて、ユーザの乗車の可否を判定してもよい。この場合、乗車可否判定部４０２は、余裕度が高いほど、到着予定時間に対する到着希望時刻の遅れが許容されやすくなる態様で、乗車可否判定処理を行うこととしてもよい。

なお、乗車可否を判定する際、複数のユーザ間の優先度が考慮されてもよい。この場合、複数のユーザ間の優先度は、乗員＞ユーザ（予約中のユーザ）であり、予約中のユーザ間では、先に予約したユーザ＞後に予約するユーザであるが、例外があってもよい。例えば、ユーザの属性（車いす使用や、松葉づえ使用、目が見えない等）が考慮され、例えば年配者や身体障害者が優先されてもよい。

また、複数の路線バス２が同時に運行する状況において、特定の路線バス２を指定しない乗車要求に対しては、乗車可否判定部４０２は、複数の路線バス２の乗車可能区間情報に基づいて、複数の路線バス２のうちの、どの路線バス２に乗車可能であるかを判定してもよい。

ユーザ特定部４０４は、乗車要求に係るユーザＩＤなど、予約状態情報の更新の際に利用されるユーザＩＤ（乗車要求を送信したユーザに係るユーザＩＤ）を特定する。ここで、乗車要求は、後述するように、ユーザ端末６から送信される乗車要求と、ジェスチャ認識装置８から送信されるジェスチャ認識結果に基づいてジェスチャ入力処理部４１４により生成される乗車要求とがある。ユーザ端末６から送信される乗車要求の場合は、ユーザ特定部４０４は、例えばユーザ端末６からの送信データのヘッダ情報等に基づいて、ユーザＩＤを特定してよい。また、ジェスチャ入力処理部４１４により生成される乗車要求の場合、ユーザ特定部４０４は、後述するカメラ８ｂの画像に含まれるユーザの画像と、ユーザ情報記憶部４２２内のユーザ情報（図１１Ｂ参照）とに基づいて、ユーザＩＤを特定してよい。この場合、ユーザ情報として各ユーザの顔画像（登録画像）が利用されてよい。

予約受付部４０５は、乗車可否判定部４０２により乗車要求に係るユーザの乗車が可能であると判定されると、ユーザによる路線バス２への乗車予約を受け付ける。予約受付部４０５は、乗車予約を受け付けると、対応する乗車予約に基づいて、予約状態情報記憶部４２０内の予約状態情報（図７Ａ）を更新する。図７Ａでは、ユーザＩＤに対応付けて、降車予定位置、乗車予定位置、余裕度、及び到着希望時刻が記憶されている。この場合、対応する乗車要求に含まれる降車予定位置及び乗車予定位置に基づいて、予約状態情報が更新される。余裕度は、乗員の余裕度（遅延に対する余裕度）を表し、後述のように乗車要求に含められる場合がある。余裕度の情報が、対応する乗車要求に含まれる場合は、当該余裕度の情報も格納される。予約状態情報の更新の際に利用されるユーザＩＤは、ユーザ特定部４０４により特定される。なお、余裕度は、“低い”場合（すなわち急いでいる場合のみ）乗車要求に含められてもよいし、多段階で指定されてもよい。また、余裕度は、降車予定位置での許容遅れ時間の形態等でユーザにより指定されてもよい。

降車予定位置変更受信部４０６は、後述のユーザ端末６や路線バス２の処理装置１０（乗員要求送信部１１６）から降車予定位置の変更要求を受信する。降車予定位置変更受信部４０６は、ある乗員に係る降車予定位置の変更要求を受信すると、当該乗員に関して、座席状態情報記憶部４２５内の座席状態情報（図７Ｂ参照）のうちの、降車予定位置を変更する。

コース変更処理部４０７は、ユーザからの乗車要求に基づいて、走行予定コースを、基本コースから他のコースに変更する。なお、コース変更処理部４０７は、走行予定コースを他のコースに変えた後、他のユーザからの乗車要求に基づいて、更に、走行予定コースを、他のコースから更なる他のコース（基本コースを含む）に変更してもよい。すなわち、コース変更が可能な回数は、２回以上であってもよいし、１回だけに限られてもよい。以下では、特に言及しない限り、コース変更が可能な回数は無制限であるとする。

具体的には、コース変更処理部４０７は、乗車要求に含まれる乗車予定位置や降車予定位置が走行予定コース外である場合、走行予定コースを変更する。なお、後述のように、コース変更処理部４０７は、乗車要求に含まれる乗車予定位置や降車予定位置が走行予定コース外である場合であっても、走行予定コースを変更しない場合もありうる。

図８は、コース変更処理部４０７によるコース変更処理の説明図である。図８には、基本コースとして、コースＲ１が示されるとともに、他のコースＲ２、Ｒ３が示される。例えば、位置Ｘ１を乗車予定位置として指定する乗車要求が発生した場合を想定する。この場合、コース変更処理部４０７は、走行予定コースを、コースＲ１から、位置Ｘ１を通る他のコースＲ２に変更する場合がある。

なお、コース変更処理部４０７は、停車予定位置Ａ２を降車予定位置とする乗員が存在せず、かつ、停車予定位置Ａ２を乗車予定位置とするユーザ（乗車要求を出しているユーザ）が存在しない場合は、走行予定コースを、コースＲ１から、位置Ｘ１を通る他のコースＲ３（停車予定位置Ａ２を通らないコースＲ２）に変更してもよい。この場合、コース変更処理に起因した次の停車予定位置Ａ３に対する到着予定時刻の遅れを、低減できる。

本実施例では、一例として、コース変更処理部４０７は、変更コスト算出部４０７１と、変更可否判定部４０７２と、コース変更反映部４０７４とを含む。

変更コスト算出部４０７１は、走行予定コースを現在のコースから変更予定のコース（変更した場合の走行予定コース）に変更した場合のコスト（以下、「変更コスト」と称する）を算出する。変更予定のコースは、乗車要求に含まれる乗車予定位置及び降車予定位置を通るコースである。また、変更予定のコースは、すでに乗車予約済のユーザや乗員の乗車予定位置及び降車予定位置を通るコースである。変更コストは、走行予定コースを現在のコースから変更予定のコースに変更した場合の損失を表す指標値であり、本実施例では、一例として、損失が大きいほど高くなる。

変更コストは、例えば、変更による遅延時間が長くなるほど高くなり、変更による遅延が影響する乗員（例えば現在の乗員の数）が多いほど高くなり、乗員の余裕度（遅延に対する余裕度）が低いほど高くなる態様で算出されてもよい。なお、乗員の余裕度は、乗車要求に含まれる態様でサーバ４に送信されてもよい。

変更コスト算出部４０７１は、例えば、コース変更判定用情報記憶部４２３に記憶されるコース変更判定用情報に基づいて、変更コストを算出してもよい。図９Ａには、コース変更判定用情報の一例が示される。図９Ａでは、乗員のユーザＩＤごとに、降車予定位置と、乗車予定位置と、余裕度（遅延に対する余裕度）とが記憶される。この場合、変更コスト算出部４０７１は、各乗員の降車予定位置での到着予定時間に係る遅延時間の合計又は平均を、変更コストとして算出してもよい。この場合、変更コスト算出部４０７１は、余裕度が低い乗員に係る遅延時間に対しては、重み付け（例えば２倍）して算出してもよい。また、変更コストは、ユーザの属性が考慮される態様で算出されてもよい。例えば、変更コストの算出の際、ユーザの属性以外が同一の条件下において、例えば年配者や身体障害者の変更コストの方が、他のユーザの変更コストよりも大きくなる態様で重み付けされてもよい。

また、変更コストは、（現在のコース上に存在しない）乗車予定位置及び／又は降車予定位置の属性（特徴）が考慮される態様で算出されてもよい。乗車予定位置及び／又は降車予定位置の属性は、例えば坂道にある（停車が困難な位置にある）ことや、狭い道（すれ違いが困難な道）にあること、通学路であること等であってもよい。例えば、変更コストの算出の際、乗車予定位置及び／又は降車予定位置の属性以外が同一の条件下において、例えば坂道や狭い道、通学路に乗車予定位置及び／又は降車予定位置が位置する場合の方が、そうでない場合よりも大きくなる態様で重み付けされてもよい。この場合、坂道や狭い道に乗車予定位置及び／又は降車予定位置が位置する場合に変更コストを過大にすることで、実質的に坂道や狭い道のような、停車や通過が困難な乗車予定位置及び／又は降車予定位置に対応するためのコース変更が禁止されてもよい。

なお、変形例では、変更コスト算出部４０７１は、変更コストに代えて又は加えて、走行予定コースを変更しなかった場合のコスト（非変更コスト）を算出してもよい。非変更コストは、例えば、変更しないことによる各停留所用での到着予定時刻のずれ（定刻の到着予定時刻に対するずれ）が大きくなるほど高くなり、乗車を希望するユーザの余裕度（遅延に対する余裕度）が低いほど高くなる態様で算出されてもよい。また、複数の路線バス２が同時に運行する状況では、非変更コストは、乗車を希望するユーザの次の路線バス２の到着までの待機時間が長くなるほど高くなる態様で算出されてもよい。

変更可否判定部４０７２は、変更コスト算出部４０７１により算出された変更コストに基づいて、走行予定コースを現在のコースから変更予定のコースに変更するか否かを判定する。例えば、変更可否判定部４０７２は、変更コスト算出部４０７１により算出された変更コストが所定閾値Ｔｈ１以下である場合に、変更を許可する。所定閾値Ｔｈ１は、ユーザの利便性等を考慮して適合される値である。所定閾値Ｔｈ１は、時間帯や曜日に応じて可変とされてもよい。

なお、変更コスト算出部４０７１が非変更コストを算出する変形例では、変更可否判定部４０７２は、変更コスト算出部４０７１により算出された非変更コストに基づいて、走行予定コースを現在のコースから変更予定のコースに変更するか否かを判定してもよい。例えば、変更可否判定部４０７２は、変更コスト算出部４０７１により算出された非変更コストが所定閾値Ｔｈ２以上である場合に、変更を許可する。所定閾値Ｔｈ２は、ユーザの利便性等を考慮して適合される値である。所定閾値Ｔｈ２は、時間帯や曜日に応じて可変とされてもよい。

また、変更コスト算出部４０７１が変更コスト及び非変更コストを算出する変形例では、変更可否判定部４０７２は、変更コスト算出部４０７１により算出された変更コストと非変更コストとに基づいて、走行予定コースを現在のコースから変更予定のコースに変更するか否かを判定してもよい。例えば、変更可否判定部４０７２は、変更コスト算出部４０７１により算出された非変更コストが変更コストよりも大きければ、変更を許可する。なお、この場合、変更コスト及び非変更コストは、正規化された上で比較されることが望ましい。例えば、変更コスト及び非変更コストは、ユーザ当たりのコストで比較されてもよい。また、変更コストの方が非変更コストよりも重視されるように重み付けされてもよい。これは、現在の乗員の方を優先する方が理にかなっているためである。

なお、変形例では、変更コスト算出部４０７１を省略して、より簡易な態様でコース変更処理部４０７を実現してもよい。

例えば、変更可否判定部４０７２は、余裕度が低い乗員に係る降車予定位置での到着予定時間に対して、遅延時間を算出し、遅延時間が所定閾値Ｔｈ３以下である場合に、変更を許可してもよい。あるいは、到着希望時刻を指定している乗員が存在する場合、変更可否判定部４０７２は、コース変更を行っても到着希望時刻以前に到着可能である場合に、変更を許可してもよい。

あるいは、変更可否判定部４０７２は、上述のような変更コスト、非変更コスト、余裕度、到着希望時刻等の複数の要素を総合的に評価する態様で、走行予定コースを現在のコースから変更予定のコースに変更するか否かを判定してもよい。

コース変更反映部４０７４は、変更可否判定部４０７２により変更が許可された場合に、コース変更を反映するための処理を行う。具体的には、コース変更反映部４０７４は、走行予定コース記憶部４２６内の走行予定コースを表す情報（コース情報）を更新する。すなわち、コース変更反映部４０７４は、走行予定コース記憶部４２６内のコース情報を、変更後のコースを表す情報へと書き換える。

なお、コース変更処理部４０７は、上述のように、複数の路線バス２の運行状態を考慮するために、複数の路線バス２に対して共通に機能してもよい。

例えば、複数の路線バス２が同時に運行する状況では、コース変更処理部４０７は、複数の路線バス２の間の位置的な関係に基づいて、複数の路線バス２のうちの１つ以上の路線バス２に係る走行予定コースを変更するか否かを判定してもよい。例えば、複数の路線バス２が循環している場合、所定の停留所に係る到着予定時間の間隔が均一化するように、複数の路線バス２のうちの１つ以上の路線バス２に係る走行予定コースを変更してもよい。なお、このようなコース変更は、ユーザからの乗車要求を契機とせずに実行されてもよい。

また、複数の路線バス２が同時に運行する状況では、コース変更処理部４０７は、複数の路線バス２の間の位置的な関係に基づいて、複数の路線バス２のうちの、どの路線バス２の走行予定コースを変更するかを判定してもよい。

この場合、例えば、コース変更処理部４０７は、複数の路線バス２のうちの、第１の路線バス２と、第１の路線バス２に後続する第２の路線バス２との間の間隔（走行予定コースに沿った車間距離又は車間時間）に基づいて、第２の路線バス２に係る走行予定コースを変更するか否かを判定してもよい。この場合、コース変更処理部４０７は、間隔が所定閾値Ｔｈ４よりも短い場合に、第２の路線バス２に係る走行予定コースの変更を行うこととしてよい。所定閾値Ｔｈ４は、適正な間隔の範囲の下限値に対応してよく、運行台数等に基づいて適合される。より具体的には、例えば図９Ｂには、第１の路線バス２及び第２の路線バス２のそれぞれの運行状態（各停車予定位置に係る到着予定時刻、及び定刻に対する遅れが示される。かかる運行状態では、第１の路線バス２及び第２の路線バス２の間隔は、適正な間隔の範囲内であるので、第１の路線バス２及び第２の路線バス２のいずれの走行予定コースも変更されないこととしてよい。あるいは、コース変更処理部４０７は、第２の路線バス２が定刻よりも早めに運行していることに基づいて、第２の路線バス２に係る走行予定コースを変更することとしてよい。また、図９Ｂの状況とは異なり、第１の路線バス２が定刻よりも早めに運行している場合は、コース変更処理部４０７は、第１の路線バス２に係る走行予定コースを変更することとしてよい。

あるいは、コース変更処理部４０７は、複数の路線バス２のうちの、コース変更による遅延時間が最も短い路線バス２から順に、走行予定コースを変更するか否かを判定してもよい。なお、複数の路線バス２のうちに、もともと走行予定コース上であり、コース変更が必要でない路線バス２が存在する場合、出力制御部４１１は、乗車要求に係るユーザに対して、当該路線バス２に対する乗車要求を生成するように促す通知を行ってもよい。

ここで、コース変更処理部４０７と上述した乗車可否判定部４０２とは、互いに連携して動作してもよい。例えば、コース変更処理部４０７が、ある路線バス２の走行予定コースを変更すると判定した場合、当該路線バス２について乗車可否判定部４０２が乗車の可否を判断してもよい。また、乗車可否判定部４０２が路線バス２に乗車可能なユーザの数の上限値（座席数）と、現在の乗員の数と、乗員の降車予定位置に基づいてのみ乗車可否を判定しかつ乗車可能であると判定した場合に、当該路線バス２についてコース変更処理部４０７がコース変更の可否を判断してもよい。

時刻表生成部４０８は、走行予定コース記憶部４２６内の走行予定コースが更新されると、時刻表情報記憶部４２８内の時刻表情報を更新する。図１０には、時刻表情報記憶部４２８内の時刻表情報の一例が示される。図１０には、説明用に、走行予定コースの変更前の時刻表情報Ｄ８０１と、走行予定コースの変更後の時刻表情報Ｄ８０２が示される。時刻表情報Ｄ８０２では、停車予定位置Ｘ１が追加された場合のデータである。なお、停車予定位置Ｘ１は、前出の図８に示すように、基本コースであるコースＲ１上に存在しない位置である。時刻表情報は、過去の実績（統計的なデータ）に基づいて導出されてもよいし、巡航速度と各停留所までの距離（既知）に基づいて計算により導出されてもよい。

車両状態更新部４０９は、路線バス２の車両状態を表す情報を更新する。車両状態は、路線バス２の位置を含み、路線バス２の他の状態（例えばブレーキの作動の有無等）を含んでよい。例えば、車両状態更新部４０９は、路線バス２の処理装置１０の車両位置情報取得部１０６から車両位置情報を受信すると、車両状態情報記憶部４２４内の車両状態情報を更新する。

また、車両状態更新部４０９は、後述する街モビアプリ５（ユーザ端末６に実装されるアプリケーション）又はプロジェクタ７からの要求に応じて、車両位置情報をユーザ端末６又はプロジェクタ７に向けて送信する。なお、車両状態更新部４０９は、予約中のユーザに係るユーザ端末６又はプロジェクタ７に対して、プッシュ型の通知態様で、車両位置情報を送信してもよい。

座席状態更新部４１０は、路線バス２の座席の状態を表す情報を更新する。座席の状態は、各座席の占有の有無、座席を占有しているユーザの識別情報等を含んでよい。座席状態更新部４１０は、路線バス２の処理装置１０の乗員状態検出部１１２から乗員状態情報を受信すると、座席状態情報記憶部４２５内の座席状態情報を更新する。図７Ｂには、座席状態情報記憶部４２５内の座席状態情報の一例が示される。図７Ｂでは、座席ごとに、乗員の有無、乗員が存在する場合は、当該乗員のユーザＩＤ、降車予定位置、及び余裕度（余裕度は、取得された場合のみ）が、座席に対応付けて記憶されてもよい。なお、降車予定位置及び余裕度は、乗車予約に含まれる情報であるので、当該情報は、座席状態情報を生成する際に、乗員のユーザＩＤに紐付けられる態様で利用できる。

出力制御部４１１は、路線バス２、ユーザ端末６、及びプロジェクタ７を介して、ユーザに対して各種情報を出力する。

出力制御部４１１は、乗車可能区間通知部４１１０と、時刻表通知部４１１２と、コース情報通知部４１１４と、乗車要求変更依頼部４１１６と、ジェスチャ入力案内部４１１８と、車内広告出力部４１２０と、降車案内出力部４１２２とを含む。

乗車可能区間通知部４１１０は、必要に応じて、乗車可能区間記憶部４２１内の乗車可能区間情報を、後述のユーザ端末６やプロジェクタ７に送信してよい。例えば、乗車可能区間通知部４１１０は、プッシュ型の通知態様で、乗車可能区間記憶部４２１内の乗車可能区間情報をユーザ端末６又はプロジェクタ７に向けて送信してもよい。例えば、乗車可能区間通知部４１１０は、上述のように乗車可能区間導出部４００が乗車可能区間記憶部４２１内の乗車可能区間情報を更新すると（すなわち乗車可能区間の変更があった場合に）、ユーザ端末６又はプロジェクタ７に向けて送信してもよい。乗車可能区間情報がユーザ端末６やプロジェクタ７に受信され出力されると、ユーザは、どの区間で乗車が可能かを容易に把握できるので、利便性が向上する。

時刻表通知部４１１２は、時刻表生成部４０８が時刻表情報記憶部４２８内の時刻表情報を更新すると、更新後の時刻表情報を処理装置１０に向けて送信する。時刻表情報は、上述のように、路線バス２の処理装置１０の時刻表情報受信部１０３により受信されることになる。時刻表情報受信部１０３により受信された時刻表情報は、処理装置１０の情報出力制御部１１４により、路線バス２内で大型ディスプレイＤ１やディスプレイＤ２〜Ｄ７を介して出力される。これにより、路線バス２内の乗員は、時刻表情報の変化等を適宜把握できるので、利便性が向上する。

また、時刻表通知部４１１２は、後述する街モビアプリ５（ユーザ端末６に実装されるアプリケーション）又はプロジェクタ７からの要求に応じて、時刻表情報記憶部４２８内の時刻表情報をユーザ端末６又はプロジェクタ７に向けて送信する。なお、時刻表通知部４１１２は、プッシュ型の通知態様で、時刻表情報記憶部４２８内の時刻表情報をユーザ端末６又はプロジェクタ７に向けて送信してもよい。例えば、時刻表通知部４１１２は、時刻表生成部４０８が時刻表情報記憶部４２８内の時刻表情報を更新すると（すなわち走行予定コースの変更があった場合に）、ユーザ端末６又はプロジェクタ７に向けて送信してもよい。時刻表情報がユーザ端末６やプロジェクタ７に受信され出力されると、ユーザは、時刻表情報の変化等を適宜把握できるので、利便性が向上する。

コース情報通知部４１１４は、上述のようにコース変更処理部４０７により更新したコース情報を処理装置１０に向けて送信する。当該コース情報は、上述のように、路線バス２の処理装置１０の走行予定コース受信部１０２により受信されることになる。走行予定コース受信部１０２により受信されたコース情報は、処理装置１０の情報出力制御部１１４により、路線バス２内で大型ディスプレイＤ１やディスプレイＤ２〜Ｄ７を介して出力される。これにより、路線バス２内の乗員は、走行予定コースの変更を適宜把握できるので、利便性が向上する。ここで、処理装置１０の情報出力制御部１１４は、走行予定コースが基本コースから変更された場合は、走行予定コースが基本コースから変更されていることがわかる態様で、走行予定コースを出力してもよい。例えば、走行予定コースが基本コースから変更されている場合は、所定のマークを付与したり、表示の色を異ならせたり、“変更しています”といった文字情報や音声情報を付加したり等することで、乗員にとって、走行予定コースが基本コースから変更されていることが分かりやすくなり、利便性が向上する。

また、コース情報通知部４１１４は、後述する街モビアプリ５（ユーザ端末６に実装されるアプリケーション）又はプロジェクタ７からの要求に応じて、変更後のコースを表すコース情報をユーザ端末６又はプロジェクタ７に向けて送信する。なお、コース情報通知部４１１４は、プッシュ型の通知態様で、走行予定コース記憶部４２６内のコース情報をユーザ端末６又はプロジェクタ７に向けて送信してもよい。例えば、コース情報通知部４１１４は、走行予定コース記憶部４２６内のコース情報を更新すると（すなわち走行予定コースの変更があった場合に）、ユーザ端末６又はプロジェクタ７に向けて送信してもよい。コース情報がユーザ端末６やプロジェクタ７に受信され出力されると、ユーザは、走行予定コースの変更を適宜把握できるので、利便性が向上する。ここで、ユーザ端末６やプロジェクタ７は、走行予定コースが基本コースから変更された場合は、走行予定コースが基本コースから変更されていることがわかる態様で、走行予定コースを出力してもよい。例えば、走行予定コースが基本コースから変更されている場合は、所定のマークを付与したり、表示の色を異ならせたり、“変更しています”といった文字情報や音声情報を付加したり等することで、ユーザにとって、走行予定コースが基本コースから変更されていることが分かりやすくなり、利便性が向上する。

乗車要求変更依頼部４１１６は、上述のコース変更処理部４０７の変更可否判定部４０７２により変更が許可されない場合に、対応するユーザに対して、その旨の情報を通知するとともに、新たな乗車要求（乗車予定位置及び／又は降車予定位置を変更した乗車要求）を要求する。なお、かかる通知及び要求は、後述のユーザ端末６やプロジェクタ７を介して実現されてよい。この場合、ユーザは、走行予定コースの変更ができなかった旨を把握し、新たな乗車要求のための入力等を行うことができる。

また、乗車要求変更依頼部４１１６は、複数の路線バス２が同時に運行している状況において、他の路線バス２への乗車が可能な場合等に、ユーザに他の路線バス２への乗車要求に変更等を要求してよい。同様に、かかる要求は、後述のユーザ端末６やプロジェクタ７を介して実現されてよい。

ジェスチャ入力案内部４１１８は、後述のジェスチャ入力処理部４１４と協動して、プロジェクタ７及びジェスチャ認識装置８に対して各種情報を出力する。これについては後述する。

車内広告出力部４１２０は、路線バス２の情報出力制御部１１４と協動して、路線バス２内の乗員に対して各種広告情報を出力する。出力対象の広告情報は、広告情報記憶部４３０内に記憶される。図１１Ａには、広告情報記憶部４３０内に記憶される広告情報の一例が示される。図１１Ａでは、停留所又は停車予定位置（コース変更に伴う臨時的な停留所）ごとに、広告主の情報と広告データとが対応付けられている。なお、広告データは、音声データや映像データの形式であってよい。

車内広告出力部４１２０は、車両状態情報記憶部４２４内の車両状態情報に基づいて、所定の広告出力タイミングを検出すると、広告情報記憶部４３０内の広告情報に基づいて、次の停車予定位置に対応付けられている広告データを抽出する。所定の広告出力タイミングは、任意であるが、次の停車予定位置に向けて路線バス２が出発したタイミングに同期してよい。そして、車内広告出力部４１２０は、抽出した広告データを出力するように処理装置１０に指示する。処理装置１０の情報出力制御部１１４は、当該指示を受けると、大型ディスプレイＤ１及び内蔵のスピーカーを介して、及び／又は、スピーカー３ａを介して、広告データを出力する。

また、車内広告出力部４１２０は、上述のコース変更処理部４０７によりコース変更があった場合に、次の停車予定位置（例えば変更前には停車予定位置ではなかったが、コース変更に伴う新たな停車予定位置）に対応付けられている広告データを抽出し、抽出した広告データを出力するように処理装置１０に指示する。処理装置１０の情報出力制御部１１４は、当該指示を受けると、大型ディスプレイＤ１及び内蔵のスピーカーを介して、及び／又は、スピーカー３ａを介して、広告データを出力する。例えば、前出の図８で示すような状況において、走行予定コースがコースＲ１からコースＲ２（又はコースＲ３）に変更された場合を想定する。この場合、次の停車予定位置が停留所Ａ２から位置Ｘ１に変更されることになり、図１１Ａでは、位置Ｘ１に対応付けられた広告データ（「広告データ００Ｘ０」）が出力されることになる。

降車案内出力部４１２２は、路線バス２の情報出力制御部１１４と協動して、路線バス２内の乗員に対して降車案内を出力する。具体的には、降車案内出力部４１２２は、車両状態情報記憶部４２４内の車両状態情報に基づいて、次の停車予定位置に路線バス２が近くなることを検出すると、座席状態情報記憶部４２５内の座席状態情報に基づいて、次の停車予定位置を降車予定位置とする乗員を探索する。そして、降車案内出力部４１２２は、次の停車予定位置を降車予定位置とする乗員に対して、降車案内を個別的に行うように処理装置１０に指示する。処理装置１０の情報出力制御部１１４は、当該指示を受けると、ディスプレイＤ２〜Ｄ７のうちの、当該乗員に対応付けられたディスプレイ及び内蔵のスピーカーを介して、及び／又は、スピーカー３ａを介して、降車案内を出力する。例えば、図７Ｂに示す例の場合、次の停車予定位置が停留所Ａ３であるとすると、停留所Ａ３を降車予定位置とする乗員は、座席Ｓ２、Ｓ３に着席している。この場合、座席Ｓ２、Ｓ３に対応付けられたディスプレイＤ４、Ｄ５を介して降車案内が実現されてよい。

ここで、スピーカー３ａを利用する場合は、スピーカー３ａは、当該乗員の近くまで移動した上で、降車案内を音声で出力する。例えば、図７Ｂに示す例の場合、次の停車予定位置が停留所Ａ３であるとすると、停留所Ａ３を降車予定位置とする乗員は、座席Ｓ２、Ｓ３である。この場合、スピーカー３ａは、座席Ｓ２、Ｓ３の近くまで移動した上で、降車案内を出力する。なお、指向性が可変のスピーカーを用いる場合は、対応する乗員付近が最も指向性が高くなるように、指向性を設定した上で降車案内を音声で出力してもよい。この場合、指向性が可変のスピーカーは、各座席に対応できるように、路線バス２の天井に設けられてもよいし、複数個設けられてもよい。

降車案内の態様は任意であるが、本実施例では、座席状態情報に基づく乗員の名前を利用して、親近感のある降車案内を実現してもよい。例えば、「ゲンさん、次ですよ！」といった具合である。例えば、図７Ｂに示す例の場合、次の停車予定位置が停留所Ａ３であるとすると、停留所Ａ３を降車予定位置とする乗員は、乗員のユーザＩＤは“０００１”及び“０００２”である。乗員のユーザＩＤ“０００１”及び“０００２”は、ユーザ情報記憶部４２２内のユーザ情報（図１１Ｂ）から、名前が“ゲン”及び“ハナ”である。従って、この場合、例えば、「ゲンさんとハナさん、次、降りますよ！」といったメッセージが出力される。

なお、変形例では、座席に設けられる振動体（又はマッサージ器）を利用して、当該乗員が寝ている場合などに、当該乗員を起こすようにしてもよい。あるいは、香り等を噴出することで、当該乗員の覚醒を誘引してもよい。

ユーザ登録処理部４１２は、路線バスシステム１のユーザ登録のための処理を実行する。なお、ユーザは、複数の地域に対してそれぞれ存在しうる路線バスシステム１ごとに登録されてもよいし、全ての路線バスシステム１に共通に登録されてもよい。図１１Ｂには、ユーザ情報記憶部４２２に記憶されるユーザ情報の一例が示される。図１１Ｂでは、ユーザＩＤごとに、ユーザの名前、ユーザの顔の画像データが記憶されている。なお、上述のように、ＩＤカードを利用するユーザは、顔の画像データの登録は省略されてもよい。ただし、この場合、どのユーザがどの座席に座っているかが判定不能となるので、かかる判定が可能となるように、例えば座席ごとに、ＩＤカードをかざすための受信機が設けられてもよい。なお、ユーザの名前は、ニックネームであってもよいし、名字を含むフルネームであってもよい。また、後述の降車位置の案内サービスが不要なユーザは、ユーザの名前の登録は省略されてもよい。

ジェスチャ入力処理部４１４は、出力制御部４１１のジェスチャ入力案内部４１１８とともに、後述のプロジェクタ７及びジェスチャ認識装置８と協動して、ジェスチャ入力が可能なユーザインターフェースを実現する。具体的には、ジェスチャ入力処理部４１４は、ジェスチャ認識装置８から取得するジェスチャ認識結果に基づいて、ユーザの乗車要求を生成する。ジェスチャ入力処理部４１４の更なる詳細は、後で行うジェスチャ認識装置８の説明の際に併せて説明する。

予約状態情報記憶部４２０には、上述のように、予約状態情報（図７Ａ参照）が記憶される。なお、予約状態情報は、現在の予約中のユーザだけを示し、当該ユーザが乗車すると当該ユーザに係る情報は削除される。図７Ａでは、ユーザＩＤが“０００５”及び“０００４”の２人が予約中であることが示されている。

乗車可能区間記憶部４２１には、上述のように、乗車可能区間情報（図７Ｃ参照）が記憶される。図７Ｃでは、乗車区間ごとに乗車可能人数が対応付けられている。“１”以上の乗車可能人数が対応付けられている乗車区間は、乗車可能区間である。なお、乗車可能区間情報は、新たな乗車要求が受信されると（乗車予約が実行されると）更新される。また、乗車可能区間情報は、路線バス２が、ある停留所を通過すると又は当該停留所から発車すると、当該停留所からの乗車区間での乗車が不能となる態様で更新される。図７Ｃでは、路線バス２が例えば停留所Ａ１を出発した後の乗車可能区間情報であり、従って、停留所Ａ１〜停留所Ａ１０までの乗車区間Ａ１−Ａ１０のような、停留所Ａ１から始まる乗車区間に対しては、乗車が不能であることが示される（乗車可能人数が“−”であり、１以上でない）。

ユーザ情報記憶部４２２には、上述のように、ユーザ情報（図１１Ｂ参照）が記憶される。なお、ユーザ情報は、図１１Ｂに示した情報以外にも、年齢、性別、自宅の住所等のような他の情報を含んでもよい。

コース変更判定用情報記憶部４２３には、上述のように、コース変更判定用情報（図９Ａ参照）が記憶される。なお、複数の路線バス２が同時に運行する状況では、図９Ｂに示すような運行状態を示す情報が、コース変更判定用情報としてコース変更判定用情報記憶部４２３に記憶されてもよい。なお、コース変更判定用情報は、座席状態情報記憶部４２５内の座席状態情報や時刻表情報記憶部４２８内の時刻表情報に基づく情報であるので、座席状態情報記憶部４２５内の座席状態情報や時刻表情報記憶部４２８内の時刻表情報が代用されてもよい。この場合、コース変更判定用情報記憶部４２３は省略されてよい。

座席状態情報記憶部４２５には、上述のように、座席状態情報（図７Ｂ参照）が記憶される。

走行予定コース記憶部４２６には、上述のように、現在の走行予定コースを表すコース情報が記憶される。例えば、現在の走行予定コースが図８に示すコースＲ１である場合は、コースＲ１を表すコース情報が記憶される。

時刻表情報記憶部４２８には、上述のように、時刻表情報（図９Ｂ参照）が記憶される。時刻表情報は、図９Ｂに示すように、定刻に対する遅れを表す情報を含んでよい。なお、時刻表情報は、一般的な時刻表情報とは異なり、上述のようにコース変更に伴って動的に変化する。

広告情報記憶部４３０には、上述のように、広告情報（図１１Ａ参照）が記憶される。広告情報は、広告内容の変更等に応じて適宜更新されてよい。

なお、本実施例において、上述したサーバ４の機能のうちの一部又は全部は、路線バス２の処理装置１０により実現されてもよいし、逆に、上述した路線バス２の処理装置１０の機能のうちの一部は、サーバ４により実現されてもよい。例えば、前者の場合として、サーバ４の車内広告出力部４１２０及び広告情報記憶部４３０は、路線バス２の処理装置１０により実現されてもよい。

［ユーザ端末］
ユーザ端末６は、スマートフォン、携帯電話、タブレット端末、ウエアラブル端末、ゲーム端末、ノートパソコン等であってよい。また、ユーザ端末６は、ユーザの自宅等に固定的に設けられる、ラップトップコンピュータのような固定端末であってもよい。

ユーザ端末６には、路線バスシステム１を利用する際に便利なアプリケーション（以下、「街モビアプリ５」とも称する）が実装される。なお、路線バスシステム１のユーザは、街モビアプリ５のダウンロードが推奨される。街モビアプリ５は、ユーザ端末６内の記憶装置（図示せず）に記憶され、ユーザ端末６内のＣＰＵ（図示せず）により実行されることで、後述する各種機能を実現する。

街モビアプリ５は、路線バス２の運行状態を表す情報（以下、「運行情報」と称する）を出力する機能を有する。街モビアプリ５は、サーバ４との通信（ユーザ端末６内の通信機能を介した通信）により、運行情報を取得する。運行情報は、例えば、コース情報と、時刻表情報と、車両位置情報とを含む。また、運行情報は、乗車可能区間情報を含んでもよい。

図１２Ａは、運行情報の出力例の説明図であり、ユーザ端末６のディスプレイ（図示せず）上の画面Ｇ１１を概略的に示す図である。図１２Ａでは、画面Ｇ１１には、現在の日時とともに、地域の区画を表す画像Ｇ１１０と、現在の走行予定コースを表す画像Ｇ１１０１と、現在の路線バス２の位置を表す画像Ｇ１１０２と、路線バス２の各停車予定位置（走行予定コース上の停車予定位置）に係る到着予定時刻を表す画像Ｇ１１０３とが示される。画像Ｇ１１０１は、運行情報に含まれるコース情報に基づいて生成され、画像Ｇ１１０２は、運行情報に含まれる車両位置情報に基づいて生成され、画像Ｇ１１０３は、運行情報に含まれる時刻表情報に基づいて生成される。なお、図１２Ａに示す画面Ｇ１１は、サーバ４から送信される運行情報に基づいて街モビアプリ５により生成されるが、変形例では、サーバ４は、図１２Ａに示す画面Ｇ１１の画像データをユーザ端末６に送信してもよい。この場合、街モビアプリ５は、サーバ４から受信した画像データを、ユーザ端末６のディスプレイ上に表示する。

また、街モビアプリ５は、ユーザ端末６のユーザからの入力に応じて、乗車要求を生成し、サーバ４に送信する機能を有する。また、街モビアプリ５は、ユーザ端末６のユーザからの入力に応じて、降車予定位置の変更要求を生成し、サーバ４に送信する機能を有する。街モビアプリ５は、その他、上述したようなユーザ情報の登録のために利用されてもよい。

このようにしてユーザ端末６上に運行情報が出力されることで、ユーザは、最新の路線バス２の運行状態を把握でき、利便性が向上する。特に、本実施例では、上述のように、路線バス２の走行予定コースが変更される場合があるので、運行情報の出力の有用性が増す。この点、街モビアプリ５は、路線バス２の走行予定コースの変更があるごとに運行情報が出力されるように構成されてもよい。

また、街モビアプリ５は、運行情報の出力に代えて又は加えて、上述した乗車可能区間情報をサーバ４から取得して、ユーザ端末６のディスプレイ（図示せず）上に出力してもよい。図１２Ｂには、乗車可能区間情報（運行情報の一例）の出力例が示される。図１２Ｂでは、路線バス２が停留所Ａ１と停留所Ａ２の間に位置し、停留所Ａ２から停留所Ａ１０までの乗車区間、停留所Ａ２から停留所Ａ３までの乗車区間、及び停留所Ａ３から停留所Ａ１０までの乗車区間が乗車可能であることが示される。これにより、ユーザは、どの区間で乗車が可能であるかを容易に把握でき、利便性が向上する。

また、図１２Ｂでは、画面Ｇ４１は、乗車可能区間情報として、区間を表す矢印の画像部Ｇ１１２０とともに、乗車可能人数を表す画像部分Ｇ１１２１を備える。これにより、ユーザは、どの区間で何人だけ乗車が可能であるかを容易に把握でき、利便性が向上する。これは、特にユーザが同伴者を有する場合に有用となる。

なお、複数の路線バス２が同時に運行する場合は、図１２Ｂに示す画面Ｇ４１は、路線バス２ごとに用意されてもよい。図１２Ａに示す画面Ｇ１１についても同様である。これらの場合、ユーザは、複数の路線バス２のうちの、所望の路線バス２を選択することで、当該路線バス２に係る画面Ｇ４１等が出力される。

図１２Ｃは、複数の路線バス２が同時に運行する場合に好適な運行情報の出力例の説明図であり、ユーザ端末６のディスプレイ（図示せず）上の画面Ｇ５１を概略的に示す図である。

図１２Ｃでは、ある停留所における時刻表情報の出力例が示される。図１２Ｃでは、１０：１５から１５分刻みで路線バス２が、当該停留所に到着する予定であることがわかる。図１２Ｃでは、次発である１０：３０に到着予定の路線バス２と、次々発である１０：４５に到着予定の路線バス２とについて、走行予定コースの情報が併せて出力されている。到着予定時刻１０：３０等は、上述のようにコース変更が発生した場合には変化しうる。なお、現在時刻は例えば１０：２０であり、先発である１０：１５に係る路線バス２は出発済みであるものとする。このようにして、直近に到着する限られた数の路線バス２についてのみ、走行予定コースの情報が表示されてもよい。この場合、限られた表示スペースを効率的に利用しつつ、時刻表情報とともにコース情報を表示でき、ユーザの利便性が向上する。なお、図１２Ｃでは、図示されていないが、路線バス２の現在位置を示す車両位置情報が併せて表示されてもよい。

図１３は、乗車要求の受付画面（予約受付用情報）の出力例の説明図であり、ユーザ端末６のディスプレイ（図示せず）上の画面Ｇ１２〜Ｇ１４を概略的に示す図である。

図１３に示す例では、ユーザ端末６のディスプレイ上の画面は、ユーザによる入力に応じて、画面Ｇ１２〜Ｇ１４間で遷移する。

画面Ｇ１２は、乗車予定位置を入力する画面であり、例えば図１２Ａに示す画面Ｇ１１の「予約画面へ」ボタンを操作することで遷移される画面であってもよいし、街モビアプリ５を起動すると表示される初期画面であってもよい。画面Ｇ１２には、乗車予定位置として、３つの候補「停留所Ａ２」、「自宅」及び「その他」が示される。乗車予定位置の候補は、サーバ４から送信される乗車可能区間情報に基づいて表示されてよい。この場合、画面Ｇ１２において、乗車予定位置の候補は、当該ユーザが当該候補の位置で路線バス２に乗車可能な場合に限り表示されることになる。従って、例えば路線バス２が満席である場合は、乗車予定位置の候補は、路線バス２が満席でなくなる場所（いずれかの乗員の降車予定位置）よりも先の位置（走行予定コースで走行した場合に今後到達することになる位置）から決定される。なお、変形例では、乗車可能区間情報に代えて、乗車予定位置の候補を表す情報がサーバ４から街モビアプリ５に送信されてもよい。

３つの候補「停留所Ａ２」、「自宅」及び「その他」を示す各画面部は、例えばタッチスイッチの形態のボタン部であってよい。この場合、ユーザは、３つの候補「停留所Ａ２」、「自宅」及び「その他」のうちから所望の乗車予定位置を選択することで、乗車予定位置を入力できる。なお、「その他」を操作すると、他の停留所等が候補として表示されてもよい。この場合、候補は、所定条件を満足する位置としてあらかじめ規定されていてよい。所定条件は、上述した変更コストが高くならないようにする条件であってよい。例えば、所定条件は、狭い道や坂道など路線バス２が停車や通過が困難な位置が除外されるような条件である。なお、この場合、候補は、道路状況等の変化に応じて可変であってもよい。例えば、工事や落石のような、臨時的な走行不能又は走行困難な道上の候補は、一時的に候補から除外されてもよい。画面Ｇ１２で乗車予定位置を入力すると、画面Ｇ１２は、画面Ｇ１３に遷移する。

画面Ｇ１３は、降車予定位置を入力する画面であり、上述のように画面Ｇ１２で乗車予定位置を入力することで遷移される画面であってもよい。画面Ｇ１３には、乗車予定位置として、複数の候補「停留所Ａ３」、・・・、「その他」が示される。停留所Ａ３は、現在の走行予定コースに沿って停車予定の停留所であってよい。複数の候補「停留所Ａ３」、・・・、「その他」を示す各画面部は、例えばタッチスイッチの形態であってよい。この場合、ユーザは、複数の候補「停留所Ａ３」、・・・、「その他」のうちから所望の降車予定位置を選択することで、降車予定位置を入力できる。画面Ｇ１３で降車予定位置を入力すると、画面Ｇ１３は、画面Ｇ１４に遷移する。

画面Ｇ１４は、予約完了画面であり、図１３に示す例では、１分後の１１：５０の時刻に乗車予定位置に路線バス２が到着することを示している。

なお、街モビアプリ５は、画面Ｇ１３から画面Ｇ１４に遷移させる際に、入力された乗車予定位置及び降車予定位置を表す情報を含む乗車要求をサーバ４に送信する。

図１４Ａは、乗車要求の受付画面の他の出力例の説明図であり、ユーザ端末６のディスプレイ（図示せず）上の画面Ｇ１１１を概略的に示す図である。

図１４Ａに示す例では、簡易な乗車要求の受付画面を実現する場合を示し、例えば高齢者等にとって使いやすい態様となりうる。具体的には、画面Ｇ１１１は、画面の大部分を占める態様で、タッチスイッチの形態の乗車ボタンを示す画面部Ｇ１５１を含む。画面Ｇ１１１は、例えば図１２Ａに示す画面Ｇ１１の「予約画面へ」ボタン（タッチスイッチの形態）を操作することで遷移される画面であってもよいし、街モビアプリ５を起動すると表示される初期画面であってもよい。ユーザは、画面部Ｇ１５１を操作することで、簡易に予約を行うことができる。この場合、街モビアプリ５は、画面部Ｇ１５１が操作されると、乗車予定位置及び降車予定位置を表す情報を含む乗車要求をサーバ４に送信する。この場合、乗車要求に含まれる乗車予定位置としては、現在のユーザの位置（ユーザ端末６のＧＰＳ受信機により測位される位置）に最も近い停留所が自動的に選択され、乗車要求に含まれる降車予定位置としては、終点が自動的に選択されてもよい。なお、図１４Ａに示す例で、画面部Ｇ１５１が操作されると、画面Ｇ１１１は、図１３に示した画面Ｇ１４のような予約完了画面に遷移されてよい。

図１４Ｂは、乗車要求の受付画面の他の出力例の説明図であり、ユーザ端末６のディスプレイ（図示せず）上の画面Ｇ１１３を概略的に示す図である。

図１４Ｂに示す画面Ｇ１１３は、複数の路線バス２が同時に運行している状況下で好適である。画面Ｇ１１３では、複数の路線バス２（３台分だけ図示）の予約が可能であり、路線バス２ごとに、コースアイコンＧ１２０と、予約ボタンＧ１２２と、到着予定時刻表情報を示す画面部Ｇ１２３と、到着順序を示す画面部Ｇ１２４とが対応付けられている。画面Ｇ１１３は、ユーザが街モビアプリ５を起動し、乗車予定位置を入力した場合に表示される画面であってよい。この場合、画面部Ｇ１２３が示す到着予定時刻表情報は、入力した乗車予定位置での到着予定時刻である。

ユーザは、画面Ｇ１１３における一のコースアイコンＧ１２０を操作することで、対応する路線バス２の現在の走行予定コースを表示させることができる。この場合、例えば、図１２Ａに示した画面Ｇ１１のような画面が表示されてもよい。これにより、ユーザは、各路線バス２の現在の走行予定コースを容易に確認できる。

ここで、上述のコース変更があった路線バス２に係るコースアイコンＧ１２０には、コース変更があったことを示すマークＭ１が付与されてもよい。これにより、ユーザは、当該路線バス２の走行予定コースが基本コースから変更されていることを容易に把握できる。

このようにして乗車要求の受付画面（予約受付用情報）は多様な態様で実現できる。例えば、図１２Ｂに示した画面Ｇ４１は、乗車要求の受付画面（予約受付用情報）として機能してもよい。この場合、画像部Ｇ１１２０がタッチスイッチの形態であり、画像部Ｇ１１２０を操作することで、当該画像部Ｇ１１２０に対応付けられた乗車区間に対する乗車要求が生成されてもよい。この場合、ユーザは、乗車予定位置等を入力しなくてよいので、利便性が向上する。

図１５Ａは、ユーザが同伴者（ユーザ登録されていない同伴者）を伴う場合に同伴者の人数の情報を含めるための乗車要求の受付画面の他の出力例の説明図であり、ユーザ端末６のディスプレイ（図示せず）上の画面Ｇ１３０を概略的に示す図である。

画面Ｇ１３０は、単独の画面であり、乗車要求の受付画面中の同伴者ボタン（図示せず）を操作することで表示されてもよい。あるいは、画面Ｇ１３０は、例えば図１３に示した画面Ｇ１２の一部に組み込まれてもよい。画面Ｇ１３０では、同伴者の人数を表す画面部Ｇ１３１と、同伴者の人数を増やすボタン部Ｇ１３２と、同伴者の人数を減らすボタン部Ｇ１３３とを含む。かかる画面Ｇ１３０を利用することで、ユーザは、同伴者の人数を容易に指定できる。なお、同伴者の人数を表す情報は、乗車要求とともにサーバ４に送信されてよい。

図１５Ｂは、余裕度の情報や到着希望時刻の情報を含める場合の乗車要求の受付画面の他の出力例の説明図であり、ユーザ端末６のディスプレイ（図示せず）上の画面Ｇ１４０を概略的に示す図である。

画面Ｇ１４０は、単独の画面であり、乗車要求の受付画面中の余裕度ボタン（図示せず）を操作することで表示されてもよい。あるいは、画面Ｇ１４０又は後出のボタン部Ｇ１４１やボタン部Ｇ１４２は、例えば図１３に示した画面Ｇ１２の一部に組み込まれてもよい。画面Ｇ１４０では、余裕度が低いことを表すボタン部Ｇ１４１と、到着希望時刻を指定するためのボタン部Ｇ１４２を含む。ボタン部Ｇ１４２は、操作されると、時間及び分のスクロールが可能なインターフェースとなり、時間が指定できるように構成される。かかる画面Ｇ１４０を利用することで、ユーザは、時間に対する余裕度や、到着希望時刻を容易に指定できる。

なお、本実施例において、上述したサーバ４の機能のうちの一部は、街モビアプリ５により実現されてもよいし、逆に、上述した街モビアプリ５の機能のうちの一部は、サーバ４により実現されてもよい。

また、本実施例では、ユーザ端末６を入出力媒体（各種情報の入出力の媒体）として説明したが、入出力媒体として空中ディスプレイ、ショーウィンドウのディスプレイを用いてもよい。

［プロジェクタ］
図１６は、プロジェクタ７の配置例を示す説明図であり、配置場所の住宅地を模式的に示す図である。図１７は、プロジェクタ７の構成の一例を示す図である。図１８は、プロジェクタ７の投映方向の制御に用いるマップの一例を示す図である。

プロジェクタ７は、投映画像を投映する装置である。プロジェクタ７は、例えばプロジェクションマッピングを利用する装置であってもよい。プロジェクタ７は、路線バス２の運行状態を示す情報（運行情報）を壁面及び路面の少なくともいずれか一方を投映面として投映する。プロジェクタ７は、通信モジュール７ａを備え、通信モジュール７ａによるサーバ４との通信により、サーバ４から運行情報を取得する。運行情報は、例えば、コース情報と、時刻表情報と、車両位置情報とを含む。

プロジェクタ７は、基本コース上の停留所や、基本コース又はそれ以外のコース上の停留所となりうる位置に設けられる。すなわち、プロジェクタ７は、停留所又は停留所となりうる位置付近に投映画像が出力されるように設けられる。これにより、ユーザは、停留所又は停留所となりうる位置で路線バス２を待ちながら、投映画像を見ることができる。なお、プロジェクタ７は、運行情報等に係る投映画像以外にも、エンターテイメント系の投映画像を出力してもよい。この場合、路線バス２を待つユーザに待機時間を長く感じさせないようにすることができる。

図１６では、プロジェクタ７は、電柱のような高所に設置されている。プロジェクタ７は、好ましくは、投映方向が可変となるようにモータ７ｂ（図１７参照）を備える。モータ７ｂは、例えばマイクロコンピュータ７０（図１７では、「マイコン」と表記）により制御される。なお、モータ７ｂに代えて、他のアクチュエータが使用されてもよい。

マイクロコンピュータ７０は、日射方向に応じてモータ７ｂを制御することで、投映面を変化させる。具体的には、マイクロコンピュータ７０は、日射方向によって影となる領域（又は日射量が比較的低い領域）が投映面となるように、モータ７ｂを制御することでプロジェクタ７の投映方向を変化させる。例えば、マイクロコンピュータ７０は、図１８に示すようなマップを用いて、投映面を決定してもよい。図１８では、時間帯ごとに、投映面が対応付けられている。日射方向は、時間帯に応じて変化するためである。なお、図１８に示す壁面Ｗ１等は、図１６に示されるような、塀や道路上の面であってよい。図１６に示す例では、壁面Ｗ１は、ある家の塀の壁面であり、壁面Ｗ２は、他の家の壁面であり、約９０度異なる向きである。また、路面Ｗ３は、壁面Ｗ１及び壁面Ｗ２に対して９０度異なる向きである。このような角度の異なる面を投映面として利用することで日射方向に影響され難い鮮明な投映画像の出力が容易となる。なお、図１８に示すマップは、あくまで一例であり、より細かい時間帯ごとに投映面が対応付けられてもよいし、季節ごと天気ごとに投映面が変化するような態様で生成されてもよい。また、天気が雨や曇り等のように、日射量が少ない場合は、投映面は固定されてもよい。

なお、本実施例では、マイクロコンピュータ７０が投映面を決定するが、変形例では、サーバ４が投映面を決定してもよい。この場合、プロジェクタ７は、サーバ４から運行情報を受信するとともにその投映方向を表す情報を受信してもよい。

なお、マイクロコンピュータ７０は、日射量に応じてプロジェクタ７の光源７ｃを制御してもよい。この場合、マイクロコンピュータ７０は、日射量が大きいほど光源７ｃの発光強度が高くなるように光源７ｃを制御してもよい。なお、光源７ｃは、任意であるが、高輝度キセノンランプ等が使用されてもよい。

プロジェクタ７による運行情報の出力例は、上述したユーザ端末６による運行情報の出力例と同様であってよく（図１２Ａ参照）、ここでは詳説しない。

このようにして、本実施例では、プロジェクタ７により運行情報が出力されるので、ユーザは、投映画像を見ることで、路線バス２の運行状態を容易に把握できる。従って、ユーザは、ユーザ端末６を有していなくても、路線バス２の運行状態を把握できる。運行情報は、リアルタイムに更新できるので、この場合、ユーザは、常に最新の運行状態を把握できる。また、本実施例では、プロジェクタ７を用いることで、例えばディスプレイ等を設置する場合とは異なり、街並みを阻害せずに（既存の街並みを利用して）運行情報をユーザに通知できる。

本実施例では、更に、プロジェクタ７は、路線バス２への乗車予約（路上にいるユーザによる予約）を可能とするための予約受付用情報を壁面及び路面の少なくともいずれか一方を投映面として投映する。予約受付用情報は、上述した運行情報と同様、日射方向に応じて決定された投映面に出力されてよい。

プロジェクタ７による予約受付用情報の出力例は、上述したユーザ端末６による乗車要求の受付画面の出力例と同様であってよく（図１３〜図１５Ｂ参照）、ここでは詳説しない。なお、プロジェクタ７による投映画像は、一般的に、ユーザ端末６のディスプレイ上の画像よりも大きいため、上述したユーザ端末６による乗車要求の受付画面よりも細かい情報を含んでもよい。ただし、好ましくは、後述のジェスチャ入力を可能とするために、プロジェクタ７による投映画像は、比較的簡易な（シンプルな）情報のみを含む。

また、プロジェクタ７は、上述した乗車可能区間情報をサーバ４から取得し、投映画像として出力してもよい。プロジェクタ７による乗車可能区間情報の出力例は、上述したユーザ端末６による乗車可能区間情報の出力例と同様であってよい（図１２Ｂ参照）。上述のようにユーザ端末６による乗車可能区間情報の画面が乗車要求の受付画面として機能できるのと同様、プロジェクタ７により出力される乗車可能区間情報についても、予約受付用情報として機能してもよい。

ジェスチャ認識装置８に関連して後述するように、予約受付用情報は、ジェスチャ認識装置８によるジェスチャ認識と連携することで、ユーザインターフェースとして機能する。すなわち、ユーザは、予約受付用情報を見ながら、所定のジェスチャを行うことで、路線バス２への乗車予約が可能となる。

このようにして、本実施例では、プロジェクタ７により予約受付用情報が出力されるので、ユーザは、当該位置で乗車予約を行うことができる。従って、ユーザは、ユーザ端末６を有していなくても、乗車予約を行うことができる。また、本実施例では、プロジェクタ７を用いることで、例えばディスプレイ等を設置する場合とは異なり、街並みを阻害せずに（既存の街並みを利用して）予約受付用情報を出力できる。

ここで、本実施例では、プロジェクタ７は、電柱のような固定物に設置されるが、これに限られない。例えば、図１９に示すように、ドローンのような飛行体６０にプロジェクタ７が搭載されてもよい。この場合、飛行体６０の向きを変化させることで、プロジェクタ７による投映方向を変化させることができる。従って、この場合は、モータ７ｂが省略されてもよい。飛行体６０は、例えば、電柱の上部に設けられるドック（図示せず）に位置してよく、稼働時のみ（運行情報や予約受付用情報を出力する際だけ）飛行してもよい。なお、ドックには充電器が設置され、飛行体６０は、自律的に充電されるように構成されてもよい。また、飛行体６０に代えて、歩行型ロボットや走行型ロボットにプロジェクタ７が搭載されてもよい。また、プロジェクタ７は、電柱以外にも、建物の壁面等を当該建物の所有者に借りて設置されてもよい。

また、本実施例では、光源７ｃの輝度を利用して投映画像を壁面Ｗ１等に投映しているが、太陽光をバックライトとして影を壁面Ｗ１等に投影する装置であってもよい。この場合、影が運行情報や予約受付用情報等を表す。なお、かかる影による投影は、例えば液晶層を備える投影装置を用いて実現できる。液晶層は、画素ごとに、印加電圧に応じて透過状態が制御可能である。液晶層は、影を形成するための画素部分がシャッタとなるように制御される。あるいは、有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）パネルを利用して、黒の画素に対応した影の投影を伴いつつ、色付きの画像を投映してもよい。あるいは、立体物の影によって運行情報や予約受付用情報を表現してもよい。この場合、形状が変化できる立体物の形状を変化させることで、当該立体物の影によって表現される運行情報や予約受付用情報等を変化させてもよい。また、複数の立体物を用意し、利用する立体物を入れ替えることで、当該立体物の影によって表現される運行情報や予約受付用情報等を変化させてもよい。この場合、立体物としては針金等を用いることができる。すなわち、いわゆる「シャドウアート」の分野で知られている表現を利用することができる。

なお、本実施例において、上述したサーバ４の機能のうちの一部は、プロジェクタ７のマイクロコンピュータ７０により実現されてもよいし、逆に、上述したプロジェクタ７のマイクロコンピュータ７０の機能のうちの一部は、サーバ４により実現されてもよい。

また、本実施例において、プロジェクタ７に代えて又は加えて、他の形態の表示装置（例えば通常の専用ディスプレイや、ショーウィンドウのディスプレイ、空中ディスプレイ）が利用されてもよい。あるいは、近くの住人（協力者）の家の中のディスプレイが利用されてもよい。

また、本実施例では、プロジェクタ７が可動することで投映面が日射方向に応じて変化されているが、これに限られない。例えば、投映面が互いに異なる複数のプロジェクタ７が設置され、複数のプロジェクタ７のうちから、日射方向に応じて選択された１つのプロジェクタ７が動作する態様であってもよい。

［ジェスチャ認識装置］
図２０は、ジェスチャ認識装置８のハードウェア構成の一例を示す図である。

ジェスチャ認識装置８は、マイクロコンピュータ８０（図２０では、「マイコン」と表記）を含み、マイクロコンピュータ８０には、通信モジュール８ａと、カメラ８ｂとが接続される。

通信モジュール８ａは、サーバ４との双方向の通信を行う。

カメラ８ｂは、プロジェクタ７が上述のように予約受付用情報を投映する投映面の近傍に位置するユーザを撮像する。すなわち、カメラ３ｂは、プロジェクタ７が投映する投映画像（予約受付用情報）を見てジェスチャを行うユーザを撮像できるような位置に設けられる。カメラ３ｂは、例えば図１６等に示すように、投映面となる壁の塀に設けられてもよいし、電柱等に設けられてもよい。この場合、カメラ８ｂは、建物の壁面等を当該建物の所有者に借りて設置されてもよい。また、カメラ３ｂは、図１９を参照して説明したような飛行体６０に実装されてもよいし、歩行型ロボットや走行型ロボットに実装されてもよい。また、カメラ８ｂは、マイクロコンピュータ８０が実装される筐体に組み込まれてもよいし、当該筐体から離れて配置されてもよい。この場合、カメラ８ｂは、マイクロコンピュータ８０との間で通信が可能となるように、通信モジュール（図示せず）を別途有する。

カメラ３ｂは、ジェスチャ認識用の画像を取得できるものであれば任意であり、例えば、ＣＣＤ（Ｃｈａｒｇｅ Ｃｏｕｐｌｅｄ Ｄｅｖｉｃｅ）やレンズを備える汎用的なカメラであってよい。あるいは、カメラ３ｂは、距離画像を取得可能なカメラであってもよい。すなわち、カメラ３ｂは、３次元画像センサであり、空間全体のセンシングを行って距離を計測し、デジタル画像のように画素ごとに距離情報を持つ距離画像を取得してもよい。この場合。距離情報の取得方式は任意である。例えば、距離情報の取得方式は、特定のパターンを対象に投影してそれをイメージセンサで読み取り、投影パターンの幾何学的な歪みから三角測量の方式により距離を取得するアクティブステレオ方式であってもよい。また、レーザー光を照射してイメージセンサで反射光を読み取り、その位相のずれから距離を計測するＴＯＦ（Ｔｉｍｅ−ｏｆ−Ｆｌｉｇｈｔ）方式であってもよい。

マイクロコンピュータ８０は、カメラ３ｂからの画像に基づいて、ユーザのジェスチャを認識する。画像に基づくジェスチャの認識方法は、広く知られており、任意の方法（例えばパターンマッチングや機械学習）を用いることができる。なお、距離画像に基づくジェスチャの認識方法は、ユーザの関節を認識した上で、関節の動きに基づいてジェスチャを認識する態様であってよい。認識対象のジェスチャは、任意であるが、あらかじめ指定されていてもよいし、プロジェクタ７が出力する投映画像内で指示されてもよい。例えば、認識対象のジェスチャは、「画像出力」、「戻る」、「ＯＫ」、「カーソル移動（移動方向を指示）」等の指令に対応するジェスチャであってよい。あるいは、認識対象のジェスチャは、ユーザの指や手の指す方向（投映画像に対する指す方向）であってよい。

マイクロコンピュータ８０は、ジェスチャの認識結果をサーバ４に送信する。サーバ４のジェスチャ入力処理部４１４は、ジェスチャ認識装置８からのジェスチャ認識結果に基づいて、プロジェクタ７と協動しながら、ユーザからの予約受付のための各種処理等を行う。

例えば、マイクロコンピュータ８０は、カメラ３ｂからの画像に基づいて、起動指示用の所定ジェスチャを認識すると、ユーザからの乗車要求を受け付けるための各種投映画像の投映が可能となるように、起動指示用の所定ジェスチャが認識されたことを表すジェスチャ認識結果をサーバ４に送信する。この際、マイクロコンピュータ８０は、カメラ３ｂの画像（ユーザの顔が映る画像）をサーバ４に送信してよい。これにより、サーバ４のユーザ特定部４０４がジェスチャを行うユーザを特定できる。

図２１は、プロジェクタ７、ジェスチャ認識装置８、及びサーバ４（ジェスチャ入力処理部４１４）により実現される予約受付のための情報のやり取りの一例を示すタイミングチャートである。なお、プロジェクタ７及びジェスチャ認識装置８は、複数組（例えば、複数の停留所）で設けられる場合がある。この場合、図２１に示すやり取りは、ある一の組のプロジェクタ７及びジェスチャ認識装置８に関する。なお、図２１に示すやり取りのうち、サーバ４からプロジェクタ７又はジェスチャ認識装置８への情報（指示を含む）の出力（送信）は、サーバ４の出力制御部４１１により実現される。

まず、ジェスチャ認識装置８は、人を検知し、当該人による起動指示用の所定ジェスチャ（例えば手を上げるジェスチャ）を認識すると、サーバ４に、当該人の顔の画像データとともに起動指示（ジェスチャ認識結果）を送信する（Ｓ２１０）。

サーバ４は、顔の画像データと起動指示を受信すると（Ｓ２１２）、画像データに基づいてユーザを特定するとともに、プロジェクタ７に起動指示を送信する（Ｓ２１４）。また、この際、サーバ４は、特定したユーザを表す情報（例えば、ユーザ情報に含まれる名前や、顔の画像データ等）を、プロジェクタ７に送信してもよい。なお、ユーザを特定できない場合は、その旨の情報をプロジェクタ７に送信してもよい。その場合、プロジェクタ７は、再度、起動指示用の所定ジェスチャを行うように促す情報を投映画像により出力してもよい。

プロジェクタ７は、起動指示を受信すると、予約受付用情報を投映画像により出力する（Ｓ２１６）。なお、ユーザを表す情報が上述のようにサーバ４からプロジェクタ７に送信される場合は、投映画像には、特定されたユーザの名前の情報が含められてもよい。例えば、かかる情報は、「ゲンさん、こんにちは」といったような挨拶文の形式であってよい。あるいは、顔の画像が出力されてもよいし、他の情報（例えばユーザＩＤ等の固有の情報）が出力されてもよい。これにより、ユーザは、自身が認識されていることを把握でき、安心感が増す。

予約受付用情報に係る投映画像は、例えば図１３〜図１５Ｂに示したような画面と同様であってよい。ユーザは、かかる投映画像を見ながら、各種のジェスチャを行うことで、予約手続きを進めることができる。

具体的には、ジェスチャ認識装置８は、認識対象の全てのジェスチャのうちの任意のジェスチャを認識すると、当該ジェスチャ認識結果をサーバ４に送信する（Ｓ２２０）。

サーバ４は、ジェスチャ認識結果を受信すると（Ｓ２２２）、現在の投映画像とジェスチャ認識結果との関係に基づいて、ユーザの指示を認識するとともに当該指示に応じた投映画像の遷移をプロジェクタ７に指示する（Ｓ２２４）。このようなやり取りの結果、各種の入力（例えば、上述したような降車予定位置、同伴者等）が進むと、サーバ４は、最終的には、予約確定を行うための投映画像を出力するようにプロジェクタ７に指示する。なお、プロジェクタ７を介した予約受付の場合、乗車予定位置は、当該プロジェクタ７の設置位置に係る停留所であるとして、ユーザからの指示不要とされてもよい。ただし、プロジェクタ７（及びジェスチャ認識装置８）が停留所とは関係のない場所に設置される場合は、乗車予定位置の指示が必要となりうる。

プロジェクタ７は、サーバ４からの指示に応じて、予約確定を行うための投映画像を出力する（Ｓ２２６）。予約確定を行うための投映画像は、例えば、予約内容（降車予定位置等）の情報を含むとともに、予約確定のためのジェスチャを要求する情報を含んでもよい。

ユーザは、かかる投映画像を見て予約内容が問題なければ、予約確定のためのジェスチャ（例えばＯＫを指示するジェスチャ）を行うことになる。なお、ユーザは、予約内容に誤り等があれば、やり直しのためのジェスチャを行うことになる。かかるジェスチャは同様にジェスチャ認識装置８により認識される。この場合、ジェスチャ認識装置８は、ジェスチャ認識結果をサーバ４に送信する（Ｓ２２８）。サーバ４は、ジェスチャ認識結果を受信すると（Ｓ２３０）、現在の投映画像とジェスチャ認識結果との関係に基づいて、ユーザの指示を認識するとともに当該指示に応じた投映画像の遷移をプロジェクタ７に指示する（Ｓ２３２）。例えば、今回のジェスチャ認識結果が、予約確定のためのジェスチャである場合は、予約完了を知らせるための投映画像を出力するようにプロジェクタ７に指示する。この場合、プロジェクタ７は、予約完了を知らせるための投映画像を出力し（Ｓ２３４）、今回の予約受付のためのプロジェクタ７の処理は終了となる。

また、サーバ４は、予約確定のためのジェスチャを示すジェスチャ認識結果を受信すると、予約内容に基づく乗車要求を生成する（Ｓ２３６）。乗車要求は、上述のように、ユーザＩＤ、乗車予定位置、降車予定位置等を含む。このようにして乗車要求が生成（取得）されると、サーバ４の予約受付部４０５に与えられる。

なお、本実施例では、ジェスチャ入力が利用されるが、これに代えて又は加えて、音声入力が利用されてもよい。この場合、音声認識装置が投映面の近傍に設けられる。

なお、本実施例において、上述したサーバ４の機能のうちの一部は、ジェスチャ認識装置８のマイクロコンピュータ８０により実現されてもよいし、逆に、上述したジェスチャ認識装置８のマイクロコンピュータ８０の機能のうちの一部は、サーバ４により実現されてもよい。

［路線バスシステムの動作例］
次に、上述した路線バスシステム１における幾つかの動作例を、フローチャートを用いて説明する。以降の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

図２２は、サーバ４が情報出力装置として機能するときの動作例を示す概略フローチャートである。図２２に示す処理は、路線バス２の運行中に所定周期ごとに繰り返し実行される。

ステップＳ３２０では、サーバ４は、乗車要求を取得したか否かを判定する。乗車要求は、上述のように、乗車要求受信部４０１が受信することで取得される場合と、ジェスチャ入力処理部４１４により生成（取得）される場合とがある。判定結果が“ＹＥＳ”の場合は、ステップＳ３２１に進み、それ以外の場合は、そのまま終了する。

ステップＳ３２１では、サーバ４は、ステップＳ３２０で得た乗車要求に含まれる乗車予定位置及び降車予定位置が走行予定コース上であるか否かを判定する。例えば乗車予定位置が、乗車要求に係るユーザの自宅の位置であり、当該自宅の位置が走行予定コース外である場合は、判定結果が“ＮＯ”となる。判定結果が“ＹＥＳ”の場合は、ステップＳ３２２に進み、それ以外の場合は、ステップＳ３２６に進む。

なお、変形例では、判定結果が“ＮＯ”の場合、ステップＳ３２６に進むのに代えて、複数の路線バス２が同時に運行している場合において、他の路線バス２の走行予定コース上に、ステップＳ３２０で得た乗車要求に含まれる乗車予定位置及び降車予定位置が位置するか否かを判定してもよい。ここで、複数の路線バス２が同時に運行している場合、乗車要求は、特定の路線バス２を指定する態様で生成される場合（図１４Ｂ参照）と、特定の路線バス２を指定せずに生成される場合（図１４Ａ参照）とがありうる。乗車要求が、特定の路線バス２を指定する態様で生成される場合、他の路線バス２は、特定の路線バス２以外の路線バス２のうちの、次に乗車予定位置に到着する路線バス２である。他方、乗車要求が、特定の路線バス２を指定せずに生成される場合、他の路線バス２は、複数の路線バス２のうちの、２番目に乗車予定位置に到着する路線バス２である（この場合、複数の路線バス２のうちの、１番目に乗車予定位置に到着する路線バス２が、第１候補の路線バス２として扱われる）。そして、他の路線バス２の走行予定コース上に、ステップＳ３２０で得た乗車要求に含まれる乗車予定位置及び降車予定位置が位置する場合は、図２３のステップＳ３４６（○２参照）に進み、サーバ４の出力制御部４１１は、他の路線バス２に対する乗車要求への変更を促す情報を、今回の乗車要求を行ったユーザに通知してもよい。他方、他の路線バス２の走行予定コース上に、ステップＳ３２０で得た乗車要求に含まれる乗車予定位置及び降車予定位置が位置しない場合は、ステップＳ３２５に進む。

ステップＳ３２２では、サーバ４は、ステップＳ３２０で得た乗車要求に係るユーザが乗車可能であるか否かの乗車可否判定処理を行う。乗車可否判定処理の例は、図２３及び図２４を参照して後述する。乗車可否判定処理の結果、ステップＳ３２０で得た乗車要求に係るユーザが乗車可能である場合（Ｓ３２３で“ＹＥＳ”）、ステップＳ３２４に進み、それ以外の場合は、ステップＳ３３９に進む。

ステップＳ３２４では、サーバ４の予約受付部４０５は、ステップＳ３２０で得た乗車要求に基づいて、当該乗車要求に係るユーザによる路線バス２への乗車予約を受け付ける。この結果、予約状態情報記憶部４２０内の予約状態情報が更新される。

ステップＳ３２５では、サーバ４のコース変更処理部４０７は、乗車可能区間情報等に基づいて、コース変更の余地があるか否かを判定する。例えば、ステップＳ３２０で得た乗車要求に含まれる乗車予定位置に到達するまでに路線バス２が満席になる場合や、予約済みのユーザの乗車予定位置及び降車予定位置と乗員の降車予定位置を通りつつ乗車要求に係る乗車予定位置及び降車予定位置を通るようなコースが成立しない場合等は、コース変更の余地がないと判定する。コース変更の余地がある場合は、ステップＳ３２６に進み、それ以外の場合は、ステップＳ３３９に進む。なお、変形例では、後出のコース変更可否判定処理において、コース変更の余地があるか否かが併せて判定されてもよい。

ステップＳ３２６では、サーバ４のコース変更処理部４０７は、コース変更が可能であるか否かのコース変更可否判定処理を実行する。コース変更可否判定処理の一例は、図２５を参照して後述する。コース変更可否判定処理の結果、コース変更が可能である場合（Ｓ３２７で“ＹＥＳ”）、ステップＳ３２８に進み、それ以外の場合（Ｓ３２７で“ＮＯ”）、ステップＳ３３９に進む。

ステップＳ３２８では、サーバ４の予約受付部４０５は、ステップＳ３２０で得た乗車要求に基づいて、当該乗車要求に係るユーザによる路線バス２への乗車予約を受け付ける。この結果、予約状態情報記憶部４２０内の予約状態情報が更新される。

ステップＳ３３０では、サーバ４のコース変更処理部４０７のコース変更反映部４０７４は、走行予定コース記憶部４２６内の走行予定コースを表す情報（コース情報）を更新する。

ステップＳ３３２では、サーバ４の時刻表生成部４０８は、時刻表情報記憶部４２８内の時刻表情報を更新する。

ステップＳ３３４では、サーバ４の出力制御部４１１は、ステップＳ３３０で更新されたコース情報及びステップＳ３３２で更新された時刻表情報を、路線バス２の処理装置１０、関連するユーザ端末６、及び関連するプロジェクタ７に送信する。関連するユーザ端末６は、コース変更がある路線バス２の予約中のユーザに係るユーザ端末６や、ステップＳ３２０で得た乗車要求に係るユーザのユーザ端末６等を含む。関連するプロジェクタ７は、コース変更がある路線バス２が今後通る停留所等に設置されるプロジェクタ７や、ステップＳ３２０で得た乗車要求がジェスチャ認識装置８を介して生成された場合は当該ジェスチャ認識装置８と対で機能するプロジェクタ７等を含む。

ステップＳ３３６では、サーバ４の出力制御部４１１は、新しい走行予定コース（変更後の走行予定コース）上の次の停車予定位置に関する広告データを広告情報記憶部４３０内から抽出し、抽出した広告データを処理装置１０に送信する。処理装置１０は、広告データを受信すると、当該広告データを、大型ディスプレイＤ１やディスプレイＤ２〜Ｄ７、スピーカー３ａ等を介して出力する。

ステップＳ３３８では、サーバ４の出力制御部４１１は、新しい走行予定コース（変更後の走行予定コース）上の新たな停車予定位置（コース変更前では停車予定位置ではなかった位置）を抽出し、抽出した新たな停車予定位置の情報（例えば名前等）を処理装置１０に送信する。処理装置１０の情報出力制御部１１４は、新たな停車予定位置の情報を受信すると、当該新たな停車予定位置の情報を、大型ディスプレイＤ１やディスプレイＤ２〜Ｄ７、スピーカー３ａ等を介して出力する。この際、処理装置１０の情報出力制御部１１４は、降車予定位置の変更を促す案内を、大型ディスプレイＤ１やディスプレイＤ２〜Ｄ７、スピーカー３ａ等を介して出力してもよい。この場合、新たな停車予定位置の方が都合の良い乗員は、当該新たな停車予定位置へと降車予定位置を変更できるので、利便性が向上する。例えば、乗員は、ユーザ端末６や、ディスプレイＤ２〜Ｄ７（タッチパネル式の場合）を利用して、新たな停車予定位置への降車予定位置の変更要求をサーバ４に送信してもよい。

ステップＳ３３９では、サーバ４の出力制御部４１１は、今回の乗車要求が受け入れられなかった旨を表す情報（例えば、乗車予定位置等の変更を促す情報）を、今回の乗車要求を行ったユーザに通知する。このような通知は、ステップＳ３２０で得た乗車要求に係るユーザのユーザ端末６や、ステップＳ３２０で得た乗車要求がジェスチャ認識装置８を介して生成された場合は当該ジェスチャ認識装置８と対で機能するプロジェクタ７を介して、実現できる。

図２２に示す処理によれば、乗車要求に応じて路線バス２の走行予定コースの変更（コース変更）が行われうるので、ユーザの利便性が向上する。特に、路線バス２が比較的狭い地域（例えば２０ｋｍ未満のコース）で巡回等し、巡航速度が２０ｋｍ程度である場合、時間を気にせずに利用するユーザが多いことが想定される。かかる場合、特にこのような走行予定コースの変更を行ったとしても、乗員等に不満等が発生し難く、利便性が向上する効果が顕著となる。

また、図２２に示す処理によれば、コース変更が行われた場合に、新たなコース情報が、路線バス２の処理装置１０や、ユーザ端末６、プロジェクタ７に送信されるので、新たなコース情報を、乗員やユーザに出力することができる。これにより、路線バス２の運行に遅れが生じた場合でも、原因がコース変更であることが分かりやすくなり、コース変更に対する不満などが発生し難い構成を実現できる。また、変更後のコースが自身の自宅の近傍を通る場合などには、当初は歩くことを考えていたユーザが路線バス２に乗車しようと思い直すこともありうる。このようにして普段あまり路線バス２を利用しないユーザを誘引する効果も期待できる。

また、図２２に示す処理によれば、コース変更が行われた場合に、コース変更に伴って動的に変化しうる時刻表情報が、路線バス２の処理装置１０や、ユーザ端末６、プロジェクタ７に送信されるので、新たなコース情報を、乗員やユーザに出力することができる。これにより、路線バス２の運行に遅れが生じた場合でも、ユーザは時刻表情報に基づきどの程度遅れるか等を確認できるので、コース変更に対する不満などが発生し難い構成を実現できる。

図２３は、図２２のステップＳ３２２（乗車可否判定処理）の一例を示す概略フローチャートである。

ステップＳ３４０では、サーバ４の乗車可能区間導出部４００は、乗車可能区間を導出する。乗車可能区間の導出方法は、上述のとおりである。

ステップＳ３４１では、サーバ４の乗車可否判定部４０２は、ステップＳ３４０で導出された乗車可能区間と、乗車要求に含まれる乗車予定位置及び降車予定位置とに基づいて、乗車予定位置及び降車予定位置が乗車可能区間内であるか否かを判定する。なお、同伴者の人数を表す情報を含む乗車要求がサーバ４に送信される場合は、乗車可否判定部４０２は、同伴者を含めた総数が乗車可能人数（図７Ｃ参照）内であるか否かについても併せて判定してよい。乗車予定位置及び降車予定位置が乗車可能区間内である場合は、ステップＳ３４２に進み、それ以外の場合は、ステップＳ３４３に進む。

ステップＳ３４２では、サーバ４は、乗車が可能であることを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２３での判定は“ＹＥＳ”となる。

ステップＳ３４３では、サーバ４は、複数の路線バス２が同時に運行しているか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ３４４に進み、それ以外の場合は、ステップＳ３４７に進む。

ステップＳ３４４では、サーバ４は、他の路線バス２に係る乗車可能区間情報を取得する。なお、複数の路線バス２が同時に運行している場合、乗車要求は、上述のように、特定の路線バス２を指定する態様で生成される場合と、特定の路線バス２を指定せずに生成される場合とがありうる。乗車要求が、特定の路線バス２を指定する態様で生成される場合、他の路線バス２は、特定の路線バス２以外の路線バス２のうちの、次に乗車予定位置に到着する路線バス２である。他方、乗車要求が、特定の路線バス２を指定せずに生成される場合、他の路線バス２は、複数の路線バス２のうちの、２番目に乗車予定位置に到着する路線バス２である。

ステップＳ３４５では、サーバ４は、ステップＳ３４４で得た他の路線バス２に係る乗車可能区間情報と、乗車要求に含まれる乗車予定位置及び降車予定位置とに基づいて、乗車予定位置及び降車予定位置が乗車可能区間内であるか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ３４６に進み、それ以外の場合は、ステップＳ３４７に進む。

ステップＳ３４６では、サーバ４の出力制御部４１１は、他の路線バス２に対する乗車要求への変更を促す情報を、今回の乗車要求を行ったユーザに通知する。このような通知は、ステップＳ３２０で得た乗車要求に係るユーザのユーザ端末６や、ステップＳ３２０で得た乗車要求がジェスチャ認識装置８を介して生成された場合は当該ジェスチャ認識装置８と対で機能するプロジェクタ７を介して、実現できる。

ステップＳ３４７では、サーバ４は、乗車が可能でないことを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２３での判定は“ＮＯ”となる。

図２３に示す処理によれば、乗員の降車予定位置等を加味して導出された乗車要求可能区間情報を利用して乗車の可否を判定できるので、精度の良い判定を実現できる。すなわち実際には乗車可能であるのに乗車不可と判定されたり、その逆に、実際には乗車不可であるのに乗車可能と判定されたりする可能性を低減できる。この結果、路線バス２による効率的な輸送（人の移動）を実現できる。

また、図２３に示す処理によれば、第１候補の路線バス２に対して乗車が不能と判定された場合、複数の路線バス２が同時に運行していれば、他の路線バス２に対する乗車の可能性が判断されるので、ユーザの利便性が向上する。

図２４は、図２２のステップＳ３２２（乗車可否判定処理）の他の一例を示す概略フローチャートである。

図２４の処理は、図２３に示した処理に対して、ステップＳ３４１がステップＳ３４１Ａで置換された点が異なる。

ステップＳ３４１Ａでは、サーバ４の乗車可否判定部４０２は、乗車予定位置及び降車予定位置が乗車可能区間内であり、かつ、乗車要求に係るユーザの、降車予定位置での到着希望時刻に基づいて、降車予定位置での到着予定時刻の、到着希望時刻に対する遅れ時間が所定閾値Ｔｈ５以下であるか否かを判定する。所定閾値Ｔｈ５は、乗車要求に係るユーザの余裕度に応じて可変されてもよい。例えば、余裕度が低いほど所定閾値Ｔｈ５が小さくなるように可変されてもよい。判定結果が“ＹＥＳ”の場合は、ステップＳ３４２に進み、それ以外の場合は、ステップＳ３４３に進む。

図２４に示す処理によれば、図２３に示した処理による効果に加えて、ユーザの個別的な事情を加味した態様で乗車の可否を判定できる。すなわち、到着希望時刻や余裕度が考慮されるので、ユーザが希望通りの時間で降車予定位置に到着できないような路線バス２に乗車してしまうことによる不都合を防止できる。

なお、図２４のステップＳ３４５においても、他の路線バス２に係る降車予定位置での到着予定時刻の、到着希望時刻（乗車要求に係るユーザの、降車予定位置での到着希望時刻）に対する遅れ時間が所定閾値Ｔｈ５以下であるか否かが判定されてもよい。

なお、図２４に示す処理は、図２３に示した処理の代替例として説明したが、乗車要求に到着希望時刻の情報が含まれるか否かに応じて使い分けられてもよい。

図２５は、図２２のステップＳ３２６（コース変更可否判定処理）の一例を示す概略フローチャートである。

ステップＳ３５０では、サーバ４は、複数の路線バス２が同時に運行しているか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ３５２に進み、それ以外の場合は、ステップＳ３５４に進む。

ステップＳ３５２では、サーバ４のコース変更処理部４０７は、複数の路線バス２が同時に運行している場合のコース変更可否判定処理（以下、「路線バス間連携処理」と称する）を実行する。路線バス間連携処理の一例は、図２６を参照して後述する。

ステップＳ３５４では、サーバ４は、コース変更判定用情報記憶部４２３に記憶されるコース変更判定用情報を読み出す。なお、コース変更判定用情報記憶部４２３が省略される構成では、サーバ４は、座席状態情報記憶部４２５内の座席状態情報や時刻表情報記憶部４２８内の時刻表情報を、コース変更判定用情報として読み出してもよい。

ステップＳ３５６では、サーバ４の変更コスト算出部４０７１は、ステップＳ３５４で得たコース変更判定用情報に基づいて、変更コストを算出する。変更コストの算出方法は、上述のとおりである。

ステップＳ３５８では、サーバ４の変更可否判定部４０７２は、ステップＳ３５６で算出された変更コストに基づいて、走行予定コースを現在のコースから変更予定のコースに変更することが可能であるか否かを判定する。例えば、変更可否判定部４０７２は、変更コストが所定閾値Ｔｈ１以下である場合に、変更を許可する。変更が許可された場合は、ステップＳ３６０に進み、変更が許可されない場合は、ステップＳ３６２に進む。

ステップＳ３６０では、サーバ４の変更可否判定部４０７２は、コース変更が可能であることを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２７での判定は“ＹＥＳ”となる。

ステップＳ３６２では、サーバ４の変更可否判定部４０７２は、コース変更が可能でないことを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２７での判定は“ＮＯ”となる。

図２５に示す処理によれば、コース変更が必要となるような乗車要求が取得された場合に、コース変更判定用情報に基づき算出される変更コストに基づいて、コース変更の可否が判定される。これにより、各乗員の降車予定位置での到着予定時間に係る遅延時間等が考慮されるので、公平性の高い基準で、コース変更の可否を判定できる。この結果、ユーザから不満が出難い利便性の高い路線バスシステム１を実現できる。

図２６は、図２５のステップＳ３５２（路線バス間連携処理）の一例を示す概略フローチャートである。ここでは、一例として、２台の路線バス２が同時に運行している場合を想定する。なお、図２６は、サーバ４が走行支援装置として機能するときの動作例である。

ステップＳ３８０では、サーバ４は、それぞれの路線バス２に係る各種情報（運行情報）を読み出す。読み出す対象の各種情報は、車両状態情報記憶部４２４内の車両状態情報（特に車両位置情報）、及び、走行予定コース記憶部４２６内のコース情報を含む。

ステップＳ３８２では、サーバ４の変更可否判定部４０７２は、ステップＳ３８０で得た各種情報に基づいて、２台の路線バス２の間隔を算出する。２台の路線バス２の間隔は、走行予定コースに沿った間隔であってよい。間隔は、距離（車間距離）で算出されてもよいし、時間（車間時間）で算出されてもよい。時間の場合は、巡航速度で車間距離を割り算することで導出されてもよいし、到着予定時刻の差として算出されてもよい。

ステップＳ３８４では、サーバ４の変更可否判定部４０７２は、ステップＳ３８２で算出した間隔が所定閾値Ｔｈ４より短いか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ３８６に進み、それ以外の場合は、ステップＳ３９２に進む。

ステップＳ３８６では、サーバ４の変更可否判定部４０７２は、２台の路線バス２のうちの後方の路線バス２について、コース変更判定用情報記憶部４２３に記憶されるコース変更判定用情報を読み出す。

ステップＳ３８８では、サーバ４の変更可否判定部４０７２は、ステップＳ３８６で得たコース変更判定用情報に基づいて、路線バス２の走行予定コースの変更が可能であるか否かを判定する。この判定方法自体は、上述のとおりであってよい（例えば、上述のように変更コスト算出部４０７１が算出する変更コストを利用する方法であってよい）。判定結果が“ＹＥＳ”の場合は、ステップＳ３９０に進み、それ以外の場合は、ステップＳ３９２に進む。

ステップＳ３９０では、サーバ４の変更可否判定部４０７２は、２台の路線バス２のうちの後方の路線バス２について、コース変更が可能であることを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２７での判定は“ＹＥＳ”となり、２台の路線バス２のうちの後方の路線バス２について、ステップＳ３２８からステップＳ３３４の各処理が実行されることになる。

ステップＳ３９２では、サーバ４の変更可否判定部４０７２は、コース変更が可能でないことを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２７での判定は“ＮＯ”となる。

図２６に示す処理によれば、２台の路線バス２が同時に運行している場合において、２台の路線バス２間の間隔が所定閾値Ｔｈ４よりも短い場合に、後方の路線バス２に対してコース変更の可否が判定される。これにより、コース変更される場合は、後方の路線バス２の遅れに起因して（コース変更に伴う遅れに起因して）、２台の路線バス２間の間隔が広がりうる。従って、２台の路線バス２間の間隔を広げつつ、コース変更による利便性を高めることができる。

なお、図２６に示す処理では、２台の路線バス２が同時に運行している場合を想定しているが、これに限らない。３台以上の路線バス２が同時に運行している場合であっても同様であってよい。この場合、各路線バス２間の間隔を算出し、間隔が所定閾値Ｔｈ４より短い２台の路線バス２の組（１組以上あってもよい）に対して、後方の路線バス２及び／又は前方の路線バス２についてコース変更が可能であるかを判定してよい。なお、間隔が所定閾値Ｔｈ４より短い２台の路線バス２の組が２組以上存在する場合は、間隔が最も小さい組から順に優先的に判定されてもよい。あるいは、ある１台の路線バス２を対象とし、対象よりも前を走行する路線バス２との間隔が所定閾値Ｔｈ４よりも短く、かつ、対象よりも後を走行する路線バス２との間隔が所定閾値Ｔｈ６よりも長い場合に限り、当該対象の路線バス２についてコース変更が可能であるかを判定してもよい。所定閾値Ｔｈ６は、対象の路線バス２についてコース変更により遅れが生じても、当該対象の路線バス２とその後方の路線バス２との間隔が所定閾値Ｔｈ４以下とならないような観点から設定されてよい。

また、図２６に示す処理では、ステップＳ３８４やステップＳ３８８で判定結果が“ＮＯ”である場合は、ステップＳ３９２に進むが、ステップＳ３９２に進む前に、他の路線バス２に対してコース変更が可能であるかを判定してもよい。この場合、他の路線バス２に対してコース変更が可能である場合は、ステップＳ３９０に進むこととしてよい。この場合、コース変更が可能となる可能性が高くなるので、コース変更を希望するユーザの利便性を高めることができる。

図２７は、図２５のステップＳ３５２（路線バス間連携処理）の他の一例を示す概略フローチャートである。なお、図２７は、サーバ４が走行支援装置として機能するときの動作例である。

ステップＳ４００では、サーバ４は、それぞれの路線バス２に係る各種情報（運行情報）を読み出す。読み出す対象の各種情報は、車両状態情報記憶部４２４内の車両状態情報（特に車両位置情報）、及び、走行予定コース記憶部４２６内のコース情報を含む。

ステップＳ４０２では、サーバ４の変更コスト算出部４０７１は、ステップＳ４００で得た各種情報に基づいて、それぞれの路線バス２に係る変更コストを算出する。変更コストの算出方法は上述のとおりである。

ステップＳ４０４では、サーバ４の変更可否判定部４０７２は、複数の路線バス２のうち、変更コストが所定閾値Ｔｈ１以下となる路線バス２が存在するか否かを判定する。判定結果が“ＹＥＳ”の場合は、ステップＳ４０６に進み、それ以外の場合は、ステップＳ４１２に進む。

ステップＳ４０６では、サーバ４の変更可否判定部４０７２は、変更コストが所定閾値Ｔｈ１以下となる路線バス２ごとに、乗車要求に係るユーザの待機時間（乗車するまでに待機する時間）を算出する。

ステップＳ４０８では、サーバ４の変更可否判定部４０７２は、変更コストが所定閾値Ｔｈ１以下となる路線バス２のうち、待機時間が最小となる路線バス２が、第１候補の路線バス２であるか否かを判定する。第１候補の路線バス２は、上述のように、乗車要求の際に特定の路線バス２が指定された場合は、当該特定の路線バス２である。なお、乗車要求の際に特定の路線バス２が指定されていない場合は、待機時間が最小となる路線バス２が第１候補の路線バス２となり、ステップＳ４０８の判定結果は自動的に“ＹＥＳ”となる。判定結果が“ＹＥＳ”の場合は、ステップＳ４１０に進み、それ以外の場合は、図２３のステップＳ３４６に進む。後者の場合、サーバ４の出力制御部４１１は、他の路線バス２（変更コストが所定閾値Ｔｈ１以下となる路線バス２のうち、待機時間が最小となる路線バス２）に対する乗車要求への変更を促す情報を、今回の乗車要求を行ったユーザに通知する。

ステップＳ４１０では、サーバ４の変更可否判定部４０７２は、コース変更が可能であることを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２７での判定は“ＹＥＳ”となる。

ステップＳ４１２では、サーバ４の変更可否判定部４０７２は、コース変更が可能でないことを示す判定結果を生成する。この場合、前出の図２２のステップＳ３２７での判定は“ＮＯ”となる。

図２７に示す処理によれば、同時に運行している複数の路線バス２のうちから、変更コストが所定閾値Ｔｈ１以下となり、かつ、待機時間が最小となる路線バス２を特定できる。そして、当該路線バス２の走行予定コースを変更できる可能性が高くなるので、コース変更を望むユーザの利便性と、路線バスシステム１の効率的な運行との両立を図ることができる。

なお、図２７では、待機時間を評価しているが、等価的に、乗車予定位置までの各路線バス２の距離（走行予定コースに沿った距離）を評価してもよい。すなわち、路線バス２のそれぞれとユーザの乗車予定位置との関係が評価されるのであれば、時間や距離など、利用するパラメータは任意である。また、上述のように、待機時間は、変更コストを算出する際に加味されてもよい。

なお、上述のように、変形例では、図２２に示す処理（図２３〜図２７に示す処理を含む）の一部や全部は、路線バス２の処理装置１０（複数の路線バス２が同時に運行する場合は、複数の路線バス２のそれぞれの処理装置１０）により実現されてもよい。例えば、複数の路線バス２が同時に運行する場合は、各路線バス２の処理装置１０が図２２に示す処理をそれぞれ実行してもよい。この場合、他の路線バス２からの情報の取得（例えば図２３のステップＳ３４４）は、複数の路線バス２のうちの、マスタとなる一の路線バス２により実現されてもよいし、それぞれにより実現されてもよい。後者の場合、判定結果がサーバ４に供給され、サーバ４側で最終的な判断が実行されてもよい。

以上、各実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせることも可能である。

例えば、上述した実施例では、路線バス２は、自立運転（自動運転）可能な構成であるが、これに限らない。路線バス２は、人の運転者により、制動、駆動、及び操舵の一部又は全部が実現されてもよい。

また、上述した実施例において、ある乗車要求に基づいて走行予定コースを基本コースから他のコースに変更する場合、その原因となった乗車要求の情報を出力してもよい。例えば、路線バス２内において、「ハナさんから自宅近くでの乗車要求が来ましたので本車両は所定ースから変更します」とのアナウンスが実行されてもよい。この場合、ハナさんと知り合いの乗員は、ハナさんの乗車を期待できる。例えば、「そうか。ハナさんが乗って来るんじゃ。ワシの隣を空けておこう。ワクワクじゃ。」といった具合である。また、路線バス２内において、「次の停留所で乗車されるハナさんがケーキ屋さんでの降車を希望されているので、本車両は所定コースから変更します」とのアナウンスが実行されてもよい。この場合、ハナさんと知り合いの乗員は、ハナさんの乗車とともに、降車予定位置の変更を検討できる。例えば、乗客は、「そうか。ハナさんが乗って来るんじゃ。ワシも予定を変更してケーキ屋で降りてハナさんとデートじゃ。」といった具合である。

また、上述した実施例では、コース変更処理部４０７は、ユーザからの乗車要求に基づいて、走行予定コースを、基本コースから他のコースに変更するが、他の要求に基づいて、走行予定コースを、基本コースから他のコースに変更してもよい。例えば、コース変更処理部４０７は、乗員からの降車予定位置の変更要求に基づいて、走行予定コースを、基本コースから他のコースに変更する場合があってもよい。この場合、新たな降車予定位置は、現在の走行予定コース上に存在しない場合に、コース変更処理部４０７は、上述と同様の態様で、走行予定コースを、基本コースから他のコース（新たな降車予定位置を通るコース）に変更するか否かを判定してもよい。

１ 路線バスシステム
２ 路線バス
３ 入力装置
３ａ スピーカー
３ｂ カメラ
３ｃ 自律走行用センサ
３ｄ 制駆動力制御装置
３ｅ 操舵制御装置
３ｆ ＧＰＳ受信機
４ サーバ
５ 街モビアプリ
６ ユーザ端末
７ プロジェクタ
７ａ 通信モジュール
７ｂ モータ
７ｃ 光源
８ ジェスチャ認識装置
８ａ 通信モジュール
８ｂ カメラ
９ ネットワーク
１０ 処理装置
３０ 電子機器
６０ 飛行体
７０ マイクロコンピュータ
８０ マイクロコンピュータ
１０２ 走行予定コース受信部
１０３ 時刻表情報受信部
１０４ センサ情報取得部
１０６ 車両位置情報取得部
１０８ 目標制駆動力決定部
１１０ 目標操舵角決定部
１１２ 乗員状態検出部
１１４ 情報出力制御部
１１６ 乗員要求送信部
１２０ 走行予定コース記憶部
４００ 乗車可能区間導出部
４０１ 乗車要求受信部
４０２ 乗車可否判定部
４０４ ユーザ特定部
４０５ 予約受付部
４０６ 降車予定位置変更受信部
４０７ コース変更処理部
４０７１ 変更コスト算出部
４０７２ 変更可否判定部
４０７４ コース変更反映部
４０８ 時刻表生成部
４０９ 車両状態更新部
４１０ 座席状態更新部
４１１ 出力制御部
４１１０ 乗車可能区間通知部
４１１２ 時刻表通知部
４１１４ コース情報通知部
４１１６ 乗車要求変更依頼部
４１１８ ジェスチャ入力案内部
４１２０ 車内広告出力部
４１２２ 降車案内出力部
４１２ ユーザ登録処理部
４１４ ジェスチャ入力処理部
４２０ 予約状態情報記憶部
４２１ 乗車可能区間記憶部
４２２ ユーザ情報記憶部
４２３ コース変更判定用情報記憶部
４２４ 車両状態情報記憶部
４２５ 座席状態情報記憶部
４２６ 走行予定コース記憶部
４２８ 時刻表情報記憶部
４３０ 広告情報記憶部

Claims (6)

1. 複数の乗降位置を含む所定のコースを巡回又は往復し複数のユーザが乗降可能な車両に適用可能である情報出力装置であって、
   前記車両にユーザが乗車することを要求していることを表す乗車要求を取得する乗車要求取得部と、
   前記乗車要求に基づいて、走行予定コースを、前記所定のコースから他のコースに変更するコース変更部と、
   前記所定のコースから前記他のコースへの変更に基づいて、前記複数の乗降位置のうちの少なくとも１つの乗降位置に関する時刻表情報であって、前記車両の到着予定時間を表す時刻表情報を変更し、変更した時刻表情報を出力する出力制御部とを備える、情報出力装置。
2. 前記出力制御部は、更に、前記変更に基づいて、前記他のコースを表す変更コース情報を出力する、請求項１に記載の情報出力装置。
3. 前記乗車要求は、位置を表す位置情報を含み、
   前記コース変更部は、前記位置情報の表す位置を通るように、前記他のコースを決定する、請求項１又は２に記載の情報出力装置。
4. 前記出力制御部は、ユーザの端末の表示装置、及び前記複数の乗降位置のうちの少なくとも１つの乗降位置付近、のうちの少なくともいずれかに、前記時刻表情報を出力する、請求項１〜３のうちのいずれか１項に記載の情報出力装置。
5. 前記コース変更部は、走行予定コースを変更した場合の現在乗車中のユーザの不都合の度合いに基づいて、走行予定コースを変更するか否かを判定する、請求項１〜４のうちのいずれか１項に記載の情報出力装置。
6. 前記コース変更部は、更に、前記乗車要求を行うユーザの不都合の度合いであって走行予定コースを変更しない場合の不都合の度合いに基づいて、走行予定コースを変更するか否かを判定する、請求項５に記載の情報出力装置。

Images