JP5831917B1 - 通知サーバ、通知方法および通知プログラム - Google Patents

Abstract

【課題】オンデマンド交通を利用する見守対象者に対する見守りを実行することができる通知サーバ、通知方法および通知プログラムを提供する。【解決手段】送受信部１０１は、乗合車両に搭載した情報端末装置から送信される、乗降日時と、停車地点と、乗車者名または降車者名と、からなる乗降情報を受信し、通知情報生成部１０４は、受信した乗車者名または降車者名に対応付けられた通知先を通知先記憶部１４０から取得し、取得した通知先を宛先とした通知情報を生成し、送受信部１０１は、生成された通知情報を送信する。【選択図】図１

Description

本発明は、通知サーバ、通知方法および通知プログラムに関する。

近年、交通機関の少ない地域の住民や自ら車を運転しない高齢者の移動を補助するため、オンデマンド交通を導入している市町村が増えている。オンデマンド交通とは、予め決められた停車場所ではなく、利用者の都合のよい場所で乗車や降車が可能であり、乗降時刻も予約に応じて柔軟に対応し運行する乗合バスやタクシー等の交通機関である。このようなオンデマンド交通では、利用者の予約に応じて運行スケジュールを決定するため、無駄の少ない経路を走行する運行スケジュールの作成が求められる。

オンデマンド交通の効率的な運行スケジュールを生成する技術としては、任意の２地点間の最短経路とその最短経路上の移動所要時間を用いて評価値を算出し、最適な運行スケジュールを生成する技術（特許文献１参照）や、利用者の希望する乗降地点に停車することによって発生する遅延時間が予め設定したバッファ時間以下である場合に運行計画を修正する技術（特許文献２参照）が開示されている。

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

ところで、このようなオンデマンド交通の利用者は、高齢者であることも多く、近年、地域や公共機関による高齢者の日常生活の状況を把握すること、すなわち見守りの重要性が指摘されている。また、遠隔地に住む家族からも高齢者をできる限りきめ細かに見守りたいという要求が高まっている。このような社会的要請に応じ、高齢者に利用されることが多いオンデマンド交通を活用し、高齢者を含む見守対象者に対する見守りを実行することができる技術が求められていた。

本発明は、上記に鑑みてなされたものであり、オンデマンド交通を利用する見守対象者に対する見守りを実行することができる通知サーバ、通知方法および通知プログラムを提供することを目的とする。

上述した課題を解決するために、本発明では、利用者の予約に応じ停車地点および運行時間を柔軟に変更できる乗合車両に搭載した情報端末装置から送信される、乗降日時と、停車地点と、乗車者名と、降車者名と、からなる乗降情報を受信し、乗降情報に含まれる乗車者名と、乗降情報に含まれる乗降日時および停車地点に対応付けられた、運行スケジュール記憶手段に記憶された乗車者名とが合致するか否かを判断し、乗車者名が合致しないと判断した場合、乗車者が予約通りに乗車しなかった旨と、予約情報と、乗降情報とを含み、通知先を宛先とした通知情報を生成し、生成された通知情報を送信することを特徴とする。

上記のように構成した本発明によれば、オンデマンド交通を利用した見守対象者に対する見守りを実行することができるという効果を奏する。

実施例１にかかる運行管理システム１０の構成図である。 実施例１にかかる運行管理サーバ１００の構成を示すブロック図である。 予約情報記憶部１１０のデータ構成の一例を示す説明図である。 運行スケジュール記憶部１２０のデータ構成の一例を示す説明図である。 乗降情報記憶部１３０のデータ構成の一例を示す説明図である。 通知先記憶部１４０のデータ構成の一例を示す説明図である。 運行管理サーバ１００が実行する運行スケジュール生成処理手順を示すフローチャートである。 運行管理サーバ１００、情報端末装置２００、情報端末装置３００が実行する通知処理手順を示すフローチャートである。 運行スケジュールを表示した画面の一例を示す説明図である。 実施例２にかかる通知先記憶部１４０のデータ構成の一例を示す説明図である。 実施例２にかかる運行管理サーバ１００が実行する運行スケジュール生成処理手順を示すフローチャートである。 実施例３にかかる運行管理サーバ５００の構成を示すブロック図である。 実施例３にかかる提供情報記憶部５５０のデータ構成の一例を示す説明図である。 運行管理サーバ５００が実行する運行スケジュール生成処理手順を示すフローチャートである。 実施例４にかかる運行管理サーバ６００の構成を示すブロック図である。 運行管理サーバ６００が実行する運行スケジュール生成処理手順を示すフローチャートである。

以下、添付図面を参照し、本発明の実施例を説明する。なお、以下の説明は、実施の形態の一例であり、本発明は、これらの実施例に限定されるものではない。

図１は、実施例１にかかる運行管理システム１０の構成図である。図１に示すように、運行管理システム１０は、運行管理サーバ１００と、見守者２の操作する情報端末装置２００と、オンデマンドバス２０に搭載されている情報端末装置３００と、オペレータ３の操作する情報端末装置４００とを、ネットワークＮを介して互いに通信可能に接続する。ネットワークＮは、一部または全部が有線あるいは無線であり、インターネット、イントラネット、ＬＡＮ（Local Area Network）、移動体通信網等の通信ネットワークである。

運行管理サーバ１００は、見守対象者１を含む利用者の予約情報に応じオンデマンドバス２０の運行スケジュールを管理するとともに、見守対象者１の乗降情報に基づき、生成した通知情報を通知先に送信するサーバ装置であり、通知サーバの一例である。

ここで、見守対象者１とは、高齢者等の見守りを必要としている人をいう。なお、オンデマンドバス２０に乗降する利用者は、見守対象者１に限る必要はなく、見守りが必要でない人も含む。見守者２は、見守対象者１を見守る人であり、見守対象者１の家族や近親者、地元民生委員、ケアマネージャー等である。また、オンデマンドバス２０とは、利用者の予約に応じ停車地点や運行時間を柔軟に変更できる乗合バスであり、バスのほかにもタクシーその他の車両を利用してもよい。

情報端末装置２００は、見守者２の操作するスマートフォンやパーソナルコンピュータ（以下、ＰＣと示す）、タブレット端末、ゲーム機その他の情報処理装置であり、見守者２が見守対象者１から電話等で依頼されたオンデマンドバス２０の予約情報の入力を受付け、運行管理サーバ１００から送信された見守対象者１に関する通知情報を受信する。

情報端末装置３００は、オンデマンドバス２０に搭載されるＰＣ、タブレット端末、ナビゲーション装置その他の情報処理装置であり、運行管理サーバ１００から送信された運行スケジュールを受信し表示するとともに、オンデマンドバス２０に乗降した利用者に関する情報の入力を受付け、運行管理サーバ１００に送信する。なお、情報端末装置３００は、オンデマンドバス２０に固定されていても、オンデマンドバス２０から持ち出し可能であってもよい。

情報端末装置４００は、オペレータ３の操作するＰＣ、タブレット端末その他の情報処理装置であり、見守対象者１から電話等で依頼されたオンデマンドバス２０の予約情報の入力を受付ける。

図１を用いて、本実施例にかかる運行管理システム１０の大まかな処理の流れについて説明する。見守対象者１は、オンデマンドバス２０の予約を見守者２またはオペレータ３に電話やファクシミリ、面談等で依頼する。これにより、見守対象者１が情報機器の操作が得意ではない場合であってもオンデマンドバス２０の予約を行うことができるとともに、見守者２やオペレータ３とのコミュニケーションによる見守りも実施することができる。

見守者２またはオペレータ３の操作に応じ、情報端末装置２００または情報端末装置４００は、見守対象者１の予約情報の入力を受付け、受付けた予約情報を運行管理サーバ１００に送信する。運行管理サーバ１００は、予約情報から運行スケジュールを生成し、生成した運行スケジュールをオンデマンドバス２０に搭載している情報端末装置３００に送信する。

情報端末装置３００は、運用スケジュールを表示するとともに、見守対象者１がオンデマンドバス２０に実際に乗降した場合に、乗降した利用者に関する情報（以下、乗降情報という）を受付け、受付けた乗降情報を運行管理サーバ１００に送信する。運行管理サーバ１００は、乗降情報と予約情報（具体的には予約情報から生成した運行スケジュール）とを比較し、比較結果に基づく通知情報を生成し、生成した通知情報を見守者２の情報端末装置２００に送信する。

図２は、実施例１にかかる運行管理サーバ１００の構成を示すブロック図である。運行管理サーバ１００は、送受信部１０１、運用スケジュール生成部１０２、乗降実績判断部１０３、通知情報生成部１０４、予約情報記憶部１１０、運行スケジュール記憶部１２０、乗降情報記憶部１３０、通知先記憶部１４０を備える。

図３は、予約情報記憶部１１０のデータ構成の一例を示す説明図である。予約情報記憶部１１０は、オンデマンドバス２０の利用者から受付けた予約情報を記憶する。予約情報記憶部１１０は、予約者名と、乗車日時と、乗車地点と、降車日時と、降車地点とを対応付けた予約情報を記憶する。なお、予約者名は、予約した利用者を識別する情報であり、氏名に限らず、ＩＤやコードであってもよい。後述する乗車者名や降車者名等も同様に、氏名に限る必要はなく、ＩＤやコードであってもよい。

図４は、運行スケジュール記憶部１２０のデータ構成の一例を示す説明図である。運行スケジュール記憶部１２０は、予約情報から生成した運行スケジュールを記憶する。運行スケジュール記憶部１２０は、乗降日時と、停車地点と、乗車者名と、降車者名とを対応付けて記憶する。

図５は、乗降情報記憶部１３０のデータ構成の一例を示す説明図である。乗降情報記憶部１３０は、オンデマンドバス２０に搭載された情報端末装置３００から送信された乗降情報を記憶する。乗降情報記憶部１３０は、乗降日時と、停車地点と、乗車者名と、降車者名とを対応付けた乗降情報を記憶する。

図６は、通知先記憶部１４０のデータ構成の一例を示す説明図である。通知先記憶部１４０は、見守対象者ごとに通知情報を送信する通知先を記憶する。通知先記憶部１４０は、見守対象者名と、１または複数の通知先とを対応付けて記憶する。通知先として記憶する情報は、具体的にはメールアドレスや電話番号等である。

送受信部１０１は、見守者２の情報端末装置２００またはオペレータ３の情報端末装置４００から送信された予約情報を受信する。送受信部１０１は、オンデマンドバス２０の情報端末装置３００に運行スケジュールを送信し、オンデマンドバス２０の情報端末装置３００から乗降情報を受信する。また、送受信部１０１は、通知情報を見守者２の情報端末装置２００に送信する。

運用スケジュール生成部１０２は、予約情報記憶部１１０に記憶された予約情報を用いて、オンデマンドバス２０の運行スケジュールを生成する。より具体的には、運用スケジュール生成部１０２は、所定の時刻までに予約情報記憶部１１０に格納された予約情報に基づき、予約者名ごとの乗車日時、乗車地点、降車日時、降車地点での運行が可能な経路を算出し、算出した経路を辿る運行スケジュールを生成する。運用スケジュール生成部１０２は、生成した運用スケジュールを運行スケジュール記憶部１２０に格納する。

乗降実績判断部１０３は、オンデマンドバス２０に搭載した情報端末装置３００から受信した乗降情報と、運行スケジュール記憶部１２０に記憶する運行スケジュールとを比較する。具体的には、乗降実績判断部１０３は、乗降情報に含まれる乗車者名と、乗降情報に含まれる乗降日時および停車地点に対応する運行スケジュールの乗車者名とが合致するか否かを判断する。また、乗降実績判断部１０３は、乗降情報に含まれる降車者名と、乗降情報に含まれる乗降日時および停車地点に対応する運行スケジュールの降車者名とが合致するか否かを判断する。

通知情報生成部１０４は、運行スケジュールと乗降情報の判断結果に基づいた通知情報を生成する。通知情報生成部１０４は、予約または乗降した見守対象者１それぞれにつき、乗降情報と運行スケジュールとが合致している場合は、予約通り乗降した旨と、見守対象者１に関する乗降情報を含む通知情報を生成する。また、通知情報生成部１０４は、見守対象者１それぞれにつき、乗降情報と運行スケジュールとが合致していない場合は、予約通りに乗降していない旨と、見守対象者１に関する乗降情報を含む通知情報を生成する。なお、通知情報に、さらに見守対象者１に関する予約情報を加えてもよい。

上述のように構成された運行管理システム１０の運行管理サーバ１００で実行する運行スケジュール生成処理について説明する。図７は、運行管理サーバ１００が実行する運行スケジュール生成処理手順を示すフローチャートである。

まず、見守者２またはオペレータ３は、見守対象者１自身が利用するためのオンデマンドバス２０の予約の内容を電話等で受ける。見守者２またはオペレータ３は、情報端末装置２００または情報端末装置４００を操作する。情報端末装置２００または情報端末装置４００は、予約情報の入力を受付け、受付けた予約情報を運行管理サーバ１００に送信する。

運行管理サーバ１００において、送受信部１０１は、情報端末装置２００または情報端末装置４００から送信された予約情報を受信する（ステップＳ７０１）。送受信部１０１は、予約情報を予約情報記憶部１１０に格納する（ステップＳ７０２）。送受信部１０１は、所定時刻を経過したか否かを判断する（ステップＳ７０３）。所定時刻とは、予約情報を受付ける期限となる時刻であり、例えば、運行日の前日１５：００、運行開始時刻の３時間前等のような予め定められた時刻である。所定時刻を経過していない場合は（ステップＳ７０３：Ｎｏ）、ステップＳ７０１に戻り、引き続き予約情報を受信する。

所定時刻を経過した場合（ステップＳ７０３：Ｙｅｓ）、運行スケジュール生成部１０２は、予約情報記憶部１１０から予約情報を取得する（ステップＳ７０４）。運行スケジュール生成部１０２は、予約情報から運行スケジュールを生成する（ステップＳ７０５）。運行スケジュール生成部１０２は、運行スケジュールを運行スケジュール記憶部１２０に格納する（ステップＳ７０６）。送受信部１０１は、運行スケジュールをオンデマンドバス２０の情報端末装置３００に送信する（ステップＳ７０７）。

このように、見守対象者１は、見守者２にオンデマンドバス２０の予約の内容を伝えることにより見守対象者１と見守者２との間に会話が生まれるとともに、見守者２が見守対象者１の予約情報を入力することにより、見守対象者１の行動を把握することができる。

また、見守対象者１に適切な見守者２がいない場合や、見守対象者１が見守者２をいちいち煩わせたくない場合には、オペレータ３に予約の内容を伝えることによってオンデマンドバス２０の予約を行うことができる。

次に、運行管理システム１０で実行する見守処理について説明する。図８は、運行管理サーバ１００、情報端末装置２００、情報端末装置３００が実行する通知処理手順を示すフローチャートである。

オンデマンドバス２０に搭載する情報端末装置３００は、運用管理サーバ１００から送信された運行スケジュールを受信する（ステップＳ８０１）。情報端末装置３００は、運行スケジュールを表示部に表示する（ステップＳ８０２）。図９は、運行スケジュールを表示した画面の一例を示す説明図である。図９に示すように、運行スケジュールとして、運行日付９１、到着時刻９２、出発時刻９３、乗車者名９４、降車者名９５、オンデマンドバス２０が現在走行している地点を示す現在位置９６を表示する。

情報端末装置３００は、乗降情報の入力を受付ける（ステップＳ８０３）。より具体的には、情報端末装置３００は、運行スケジュールを表示するタッチパネルから乗降者名または降車者名をタップすることによって乗降情報の入力を受付ける。また、見守対象者１がＲＦＩＤ（Radio Frequency IDentification）技術を用いた非接触型ＩＣカード等を所持し、ＩＣカードリーダにかざすことによって乗降情報を受付けてもよい。見守対象者１の携帯するビーコン端末から発信された見守対象者１を特定する情報を情報端末装置３００で受信することによって乗降情報を受付けてもよい。情報端末装置３００は、停車地点ごとに、受付けた乗降情報を運行管理サーバ１００に送信する（ステップＳ８０４）。なお、停車地点で乗車者も降車者もなかった場合でも、乗降日時、停車地点、乗車者名‘なし’、降車者名‘なし’の乗降情報を送信する。

運行管理サーバ１００の送受信部１０１は、オンデマンドバス２０の情報端末装置３００から送信された乗降情報を受信する（ステップＳ８０５）。乗降実績判断部１０３は、乗降情報に対応する運行スケジュールを運行スケジュール記憶部１２０から取得する（ステップＳ８０６）。例えば、図５に示すような、乗降日時‘９／２２（水）１１：００’、停車地点‘上野駅’、乗車者‘山田三郎’という乗降情報を受信した場合、図４に示す、運行スケジュール記憶部１２０の乗降日時‘９／２２（水）１１：００’、停車地点‘上野駅’に対応する乗降者‘小川花子，山田三郎’を取得する。なお、乗降情報に含まれる乗降日時が見守対象者１の実際に乗降した日時である場合は、所定の幅を持たせて運行スケジュールを取得する。

乗降実績判断部１０３は、乗降情報と運行スケジュールとを比較する（ステップＳ８０７）。上述した例では、‘山田三郎’は、乗降情報と運行スケジュールのどちらにも乗車者であるため、予約通り乗車したと判断する。一方、‘小川花子’は、運行スケジュールでは乗車者であるが、乗降情報には含まれていないため、予約通りに乗車しなかったと判断する。

通知情報生成部１０４は、乗車実績判断部１０３による判断結果に従って通知情報を生成する（ステップＳ８０８）。具体的には、通知情報生成部１０４は、乗車者名または降車者名に対応付けられた通知先を通知先情報記憶部１４０から取得し、取得した通知先を宛先とした通知情報を生成する。通知情報の内容は、予約通り乗車／降車した旨、または予約通りに乗車／降車しなかった旨、乗降情報を含み、さらに予約情報を含んでもよい。また、通知情報は、予約通り乗車／降車した場合と予定通りに乗車／降車しなかった場合の両方を生成するほか、予定通りに乗車／降車しなかった場合のみ生成してもよい。

送受信部１０１は、通知先に通知情報を送信する（ステップＳ８０９）。通知情報を送信する方法としては、メール送信、ＳＭＳ（Short Message Service）機能等を使用したプッシュ通知、通知内容を読み上げた音声を電話回線を介して送信する自動音声通話等様々な方法を採ることができる。

通知先の情報端末装置２００は、運行管理サーバ１００から送信された通知情報を受信する（ステップＳ８１０）。情報端末装置２００は、通知情報を表示部に表示する（ステップＳ８１１）。なお、音声の場合は、スピーカから音声を出力する。

このように、通知情報が通知先に送信されるため、見守対象者１が予約通りにオンデマンドバス２０に乗車した場合であっても乗車しなかった場合であっても、見守対象者１および見守者２に大きな負担をかけることなく、見守者２はその状況を把握することができる。また、その通知内容によって、見守対象者１が日常生活を無事に過ごせていること、または、異変が起きていることを遠くに離れて暮らしている家族や地域、公共機関が認識することができ、見守対象者１を日々見守ることができる。また、見守対象者１が予約通りにオンデマンドバス２０に乗車しなかった場合は、怪我や病気等の可能性を見守対象者１からの連絡がなくても把握することができ、よりきめ細やかな見守りを実行することができる。

また、従来、高齢者の体調の異常を把握する発明としては、高齢者の動作をセンサで検出しなくなった場合にアラームを通知する等、生命に別状があるような事態を通知するような技術が多く開発されている。しかしながら、このような従来技術では、自分で依頼した予約内容を忘れてしまう等の認知症のような、徐々に現れるような異変については把握することができなかった。かかる課題について、上述した技術では、予約した内容と乗降実績との差異を通知することによって、見守対象者１の認知度の変化についても把握することが可能となるため、上述した技術を活用することで、認知症への早期の対応を採ることにより、症状が重篤化することを防ぐことができ、介護対象者の増加を抑えることができる。

なお、上述した実施例では、見守対象者１は、スマートフォンのような情報端末装置を操作せず、オンデマンドバス２０の予約を見守者２またはオペレータ３に依頼することによって、情報端末装置２００または情報端末装置４００から予約情報を受付けていたが、見守対象者１が情報端末装置を操作可能であれば、見守対象者１の所持する情報端末装置から予約情報の入力を受付けてもよい。

他の実施例として、オンデマンドバス２０の情報端末装置３００から送信された乗降情報を送信部１０１で受信した場合、乗降実績判断部１０３で乗降情報と運行スケジュールとの比較を実施することなく、受信した乗降情報を通知情報として通知先に送信してもよい。

次に、実施例１の処理に加え、見守対象者１の予約の内容を事前に予約確認情報として通知先に送信する実施例２の処理について説明する。

図１０は、実施例２にかかる通知先記憶部１４０のデータ構成の一例を示す説明図である。通知先記憶部１４０は、見守対象者１それぞれにつき、通知情報を送信する通知先を記憶する。通知先記憶部１４０は、見守対象者名と、通知先と、予約確認通知の有無と、乗降実績通知の有無とを対応付けて記憶する。

実施例２にかかる運行管理システム１０の運行管理サーバ１００で実行する運行スケジュール生成処理について説明する。図１１は、実施例２にかかる運行管理サーバ１００が実行する運行スケジュール生成処理手順を示すフローチャートである。なお、運行スケジュール生成処理手順のステップＳ１１０１〜ステップＳ１１０６、ステップＳ１１０８の処理は、図７のステップＳ７０１〜ステップＳ７０７の処理と同様であるため、その説明を参照し、ここでの説明は省略する。

送受信部１０１は、予約確認情報を送信する（ステップＳ１１０７）。具体的には、運用スケジュールに含まれる乗車者名ごとに、乗車日時と、乗車地点と、降車日時と、降車地点とからなる予約確認情報を運用スケジュールから取得し、通知先記憶部１４０に記憶する通知先のうち、予約確認通知欄に‘受け取る’を記憶する通知先に送信する。例えば、図１０に示す、見守対象者名‘田中太郎’の通知先のうち、予約確認通知欄に‘受け取る’を記憶する‘田中太郎（本人）’と‘田中一郎（長男）’に送信する。一方、通知先‘地元民生委員’は、予約確認通知は送信されないが、乗降実績通知、すなわち図８のステップＳ８０９の通知情報は送信される。

また、予約確認情報は、運行スケジュールを生成したときのほか、予め送信日時や送信タイミングを定めておき、例えば、乗車前日２１：００や乗車時刻の３０分前等で送信するようにしてもよい。

このように、見守対象者１および見守者２に予約確認情報を事前に通知することによって、予約したオンデマンドバス２０に乗り忘れや乗り間違いを防止することができる。また、見守者２に予約情報を事前に通知することで見守対象者１の行動を把握することができ、さらに見守対象者１との確認の会話の機会を得ることができる。

他の実施例として、予約情報記憶部１１０に記憶された予約情報から見守対象者１ごとに所定回数繰り返している予約情報を抽出し、所定時刻までに予約情報を受付けていない場合は、予約を忘れていないかを確認する予約確認情報を送信してもよい。

また、予約情報記憶部１１０に記憶された予約情報から見守対象者１ごとの過去の予約情報を抽出し、新たな予約情報の乗車地点または降車地点が過去の予約情報と異なる場合は、過去の予約情報と異なることを確認する予約確認情報を送信してもよい。

さらに、予約情報記憶部１１０に記憶された過去の予約情報から、同一日時および同一乗降地点を予約する複数の予約者の予約情報を抽出し、抽出した予約者名のうちの一部の予約者名での新たな予約情報を受付けている場合、他の利用者に、一部の予約者と同様の予約情報で予約するか否かを確認する予約確認情報を送信してもよい。

実施例３として、見守対象者１に応じた推薦情報を送信する処理について説明する。

図１２は、実施例３にかかる運行管理サーバ５００の構成を示すブロック図である。運行管理サーバ５００は、送受信部１０１、運行スケジュール生成部１０２、乗降実績判断部１０３、通知情報生成部１０４、推薦情報生成部５０５、予約情報記憶部１１０、運行スケジュール記憶部１２０、乗降情報記憶部１３０、通知先記憶部１４０、提供情報記憶部５５０を備える。なお、実施例１、２と同様の機能を有する部分については同一の番号を付しており、ここでの説明は省略する。

図１３は、実施例３にかかる提供情報記憶部５５０のデータ構成の一例を示す説明図である。提供情報記憶部５５０は、提供条件に合致した見守対象者１に対し送信する提供情報を記憶する。提供情報記憶部５５０は、提供条件と、提供情報とを対応付けて記憶する。例えば、図１３に示すように、降車地点が‘上野駅’であるという提供条件に対応付けて、店舗・施設名‘Ａ菓子店’や‘Ｂ美術館’、所在地、紹介文等の提供情報を記憶する。なお、提供条件は、降車地点に代えて、または加えて乗車地点としてもよい。さらに、見守対象者１の属性情報、例えば性別や年代、興味のある事項等を提供条件として加え、対象者を絞り込むことを可能にしてもよい。その場合は、見守対象者名と、属性情報とを対応付けた記憶部を備える。

推薦情報生成部５０５は、見守対象者１の行動や利用者の属性情報に応じた推薦情報を生成する。例えば、推薦情報生成部５０５は、運行スケジュール生成部１０２によって生成された運行スケジュールに記憶された乗車予定の見守対象者１に対し、降車地点に対応付けられた提供情報を提供情報記憶部５５０から取得し、取得した提供情報から推薦情報を生成する。

次に、実施例３にかかる運行管理サーバ５００で実行する運行スケジュール生成処理について説明する。図１４は、運行管理サーバ５００が実行する運行スケジュール生成処理手順を示すフローチャートである。なお、運行スケジュール生成処理手順のステップＳ１４０１〜ステップＳ１４０６、ステップＳ１４１１の処理は、図７のステップＳ７０１〜ステップＳ７０７の処理と同様であるため、その説明を参照し、ここでの説明は省略する。

推薦情報生成部５０５は、運用スケジュールから提供条件に合致する見守対象者名を取得する（ステップＳ１４０７）。一例として、図１３での、提供条件の降車地点が‘浅草駅’である提供条件に対応し、図４で示す運行スケジュールから停車地点‘浅草駅’での降車者名‘田中太郎’を取得する。推薦情報生成部５０５は、提供条件に合致した提供情報を提供情報記憶部５５０から取得する（ステップＳ１４０８）。上述の場合、提供条件の降車地点が‘浅草駅’に対応付けられた提供情報‘Ｃ劇場’、‘Ｄ居酒屋’の情報を取得する。

推薦情報生成部５０５は、推薦情報を生成する（ステップＳ１４０９）。具体的には、推薦情報生成部５０５は、提供情報記憶部５５０から取得した提供情報から、通知先記憶部１４０から取得した見守対象者名に対応付けられた通知先を宛先とする推薦情報を生成する。送受信部１０１は、推薦情報を送信する（ステップＳ１４１０）。なお、通知先記憶部１４０は、実施例１または実施例２のいずれを用いてもよい。

また、推薦情報は、上述したように推薦情報のみを送信するほか、実施例２において説明した予約確認情報に含めて送信してもよい。

このように、提供条件で絞り込むことによって見守対象者１に応じた推薦情報を送信することができるため、見守対象者１の行動範囲や興味の幅を広げることができ、見守対象者１の生活の質の向上を図ることができる。また、見守者２にとっても、見守対象者１との会話の話題を得ることができる。さらに、提供情報を提供する企業や店舗、施設にとっては、オンデマンドバス２０を利用する見守対象者１に対し、見守対象者１に応じた提供情報をオンデマンドバス２０の予約のタイミング、すなわち外出のタイミングで推薦情報として送信することができるため、見守対象者１の関心を引き、集客数の向上を図ることができる。

なお、本実施例で推薦情報を送信する対象者は、見守対象者１に限る必要はなく、予め通知先を登録しておくことによってオンデマンドバス２０を利用する乗降者すべてを対象とすることができる。

次に、外部システムから送信された情報に基づいて予約情報を生成し、生成した予約情報を用いて運用スケジュールを生成する実施例４の処理について説明する。

図１５は、実施例４にかかる運行管理サーバ６００の構成を示すブロック図である。運行管理サーバ６００は、送受信部１０１、運用スケジュール生成部１０２、乗降実績判断部１０３、通知情報生成部１０４、予約情報生成部６０６、予約情報記憶部１１０、運行スケジュール記憶部１２０、乗降情報記憶部１３０、通知先記憶部１４０を備える。なお、実施例１〜３と同様の機能を有する部分については同一の番号を付しており、ここでの説明は省略する。

予約情報生成部６０６は、外部システムから送信された情報に基づいてオンデマンドバス２０の予約情報を生成する。具体的には、予約情報生成部６０６は、外部システム、例えば病院で稼働している診察予約システム７００から送信された診察予約情報に基づき、予約した診察を受診できる日時に病院に到着するように予約情報を生成する。

次に、実施例４にかかる運行管理サーバ６００で実行する運行スケジュール生成処理について説明する。図１６は、運行管理サーバ６００が実行する運行スケジュール生成処理手順を示すフローチャートである。なお、運行スケジュール生成処理手順のステップＳ１６０４〜ステップＳ１６０９の処理は、図７のステップＳ７０２〜ステップＳ７０７の処理と同様であるため、その説明を参照し、ここでの説明は省略する。

送受信部１０１は、診察予約システム７００から診察予約情報を受信する（ステップＳ１６０１）。診察予約情報には、患者名、診察予約日時、乗車地点、病院名を含む。予約情報生成部６０６は、診察予約情報に基づいて予約情報を生成する（ステップＳ１６０２）。具体的には、予約情報生成部６０６は、診察予約日時から逆算した、予約者名、乗車日時、乗車地点、降車日時、降車地点からなる予約情報を生成する。送受信部１０１は、予約情報を診察予約システムに送信する（ステップＳ１６０３）。

このように、病院で診察を受ける見守対象者１に対し、診察を予約する際にオンデマンドバス２０を予約することができるため、見守対象者１自ら予約することなく、病院までの交通手段を確保することができる。また、病院の診察予約システムとオンデマンド交通システムを連係することによって、診察の継続が必要なのにもかかわらず病院に通わなくなることに対し見守者２によるフォローが可能となり、病気の重篤化の防止等さらに手厚い見守りが可能となる。

また、運行管理サーバ６００と連係する外部システムは、病院の診察予約システムに限る必要はなく、鍼灸院、整骨院、スポーツセンタ、飲食店、美容院、理容店等予約して来所するような場所の予約システムと連係することによって、見守対象者１にとっては交通手段を確保する手間がかからず、見守者２にとっては見守対象者１の行動が把握でき、よりきめ細かな見守りが可能となる。また、施設や店舗にとっても、予約者の来所の確率が向上する。

本実施例についても、対象者を見守対象者１に限る必要はなく、オンデマンドバス２０を利用する乗降者すべてを対象とすることができる。

上述した実施例１〜４にかかる運用管理サーバ１００、５００、６００のハードウェア構成は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）等の外部記憶装置、通信制御装置等を備えた通常のコンピュータであり、ＲＯＭやＲＡＭ、ＨＤＤ等に記憶されたプログラムをＣＰＵが読み出し動作させることによって、上述した構成や機能を実現する。

運用管理サーバ１００、５００、６００で動作するプログラムは、インターネット等のネットワークＮに接続されたコンピュータ上に格納しておき、ネットワークＮ経由でダウンロードさせることにより提供したり、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＤＶＤ、ＵＳＢメモリ、ＳＤカード等のコンピュータで読取り可能な記録媒体に記録し提供してもよい。また、上述した機能や処理を実現するプログラムは、ＡＰＩ（Application Programming Interface）やＳａａＳ（Software as a Service）、クラウドコンピューティングという利用形態で提供してもよい。

なお、本発明は、上述した実施例そのままに限定されるものではなく、必ずしも物理的に図示のように構成されている必要はない。また、本発明は、実施例１〜４で説明した構成要素の全部または一部を、各種の負荷や使用状況などに応じ、任意の単位で機能的または物理的に分割、統合、入替、変形または削除して構成することができる。

Ｎ…ネットワーク、１…見守対象者、２…見守者、３…オペレータ、１０…運行管理システム、１００・５００・６００…運行管理サーバ、１０１…送受信部、１０２…運行スケジュール生成部、１０３…乗降実績判断部、１０４…通知情報生成部、５０５…推薦情報生成部、６０６…予約情報生成部、１１０…予約情報記憶部、１２０…運行スケジュール記憶部、１３０…乗降情報記憶部、１４０…通知先記憶部、５５０…提供情報記憶部、２００・３００・４００…情報端末装置、７００…診察予約システム

Claims (9)

1. 利用者の予約に応じ停車地点および運行時間を柔軟に変更できる乗合車両に搭載した情報端末装置とネットワークを介して接続する通知サーバにおいて、
   前記乗合車両に乗降する利用者を識別する利用者名と、前記利用者に対応付けられた１または複数の通知先を記憶する通知先情報記憶手段と、
   乗降日時と、停車地点と、乗車者名と、降車者名とを対応付けた運行スケジュールを記憶する運行スケジュール記憶手段と、
   前記乗合車両の乗降を予約した予約者名と、乗車日時と、乗車地点と、降車日時と、降車地点とを対応付けた予約情報を記憶する予約情報記憶手段と、
   予約者名と、乗車日時と、乗車地点と、降車日時と、降車地点と、からなる予約情報を受信し、受信した前記予約情報を前記予約情報記憶手段に格納する受信手段と、
   前記予約情報記憶手段に記憶された前記予約情報に基づく運行が可能な経路を算出し、算出した経路を辿るための、乗降日時と、停車地点と、乗車者名と、降車者名と、からなる運行スケジュールを生成し、生成した前記運行スケジュールを前記運行スケジュール記憶手段に格納する運行スケジュール生成手段と、
   前記受信手段は、前記情報端末装置から送信される、乗降日時と、停車地点と、乗車者名と、降車者名と、からなる乗降情報を受信し、
   前記乗降情報に含まれる前記乗車者名と、前記乗降情報に含まれる前記乗降日時および前記停車地点に対応付けられた、前記運行スケジュール記憶手段に記憶された前記乗車者名とが合致するか否かを判断する乗降実績判断手段と、
   前記乗降実績判断手段によって前記乗車者名が合致しないと判断した場合、乗車者が予約通りに乗車しなかった旨と、前記予約情報と、前記乗降情報とを含み、前記乗車者名に応じた前記利用者名に対応付けられた通知先を前記通知先情報記憶手段から取得し、取得した前記通知先を宛先とした通知情報を生成する通知情報生成手段と、
   前記通知情報生成手段によって生成された前記通知情報を送信する送信手段と、
   を備えることを特徴とする通知サーバ。
2. 前記乗降実績判断手段は、さらに、前記乗降情報に含まれる前記降車者名と、前記乗降情報に含まれる前記乗降日時および前記停車地点に対応付けられた、前記運行スケジュール記憶手段に記憶された前記降車者名とが合致しているか否かを判断し、
   前記通知情報生成手段は、前記乗降実績判断手段によって前記降車者名が合致しないと判断した場合、降車者が予約通りに降車しなかった旨と、前記予約情報と、前記乗降情報とを含み、前記降車者名に応じた前記利用者名に対応付けられた通知先を前記通知先情報記憶手段から取得し、取得した前記通知先を宛先とした通知情報を生成すること、を特徴とする請求項１に記載の通知サーバ。
3. 前記通知情報生成手段は、前記乗降実績判断手段によって前記乗車者名が合致すると判断した場合、乗車者が予約通りに乗車した旨を含む通知情報を生成すること、を特徴とする請求項１または請求項２に記載の通知サーバ。
4. 前記通知情報生成手段は、前記乗降実績判断手段によって前記降車者名が合致すると判断した場合、降車者が予約通りに降車した旨を含む通知情報を生成すること、を特徴とする請求項１〜３のいずれか１つに記載の通知サーバ。
5. 前記送信手段は、前記運行スケジュール記憶手段に記憶された前記運行スケジュールに含まれる前記乗車者名ごとに、乗車日時と、乗車地点と、降車日時と、降車地点とからなる予約確認情報を前記運行スケジュールから取得し、取得した前記予約確認情報を送信すること、を特徴とする請求項１〜４のいずれか１つに記載の通知サーバ。
6. 提供条件と、提供情報とを対応付けて記憶する提供情報記憶手段と、
   前記運行スケジュール記憶手段に記憶された前記運行スケジュールに含まれる前記乗車者名ごとに、前記提供条件に合致した場合に、前記提供条件に対応付けられた前記提供情報を取得し、取得した前記提供情報を含む推薦情報を生成する推薦情報生成手段と、をさらに備え、
   前記送信手段は、前記推薦情報を送信すること、を特徴とする請求項１〜５のいずれか１つに記載の通知サーバ。
7. 前記受信手段は、外部システムにおいて予約を受付けた外部予約者名と、予約日時と、乗車地点と、降車地点とからなる外部予約情報を前記外部システムから受信し、
   前記外部予約情報に基づき前記予約情報を生成し、生成した前記予約情報を前記予約情報記憶手段に格納する予約情報生成手段、をさらに備えることを特徴とする請求項１〜６のいずれか１つに記載の通知サーバ。
8. 利用者の予約に応じ停車地点および運行時間を柔軟に変更できる乗合車両に搭載した情報端末装置とネットワークを介して接続し、前記乗合車両に乗降する利用者を識別する利用者名と、前記利用者に対応付けられた１または複数の通知先を記憶する通知先情報記憶手段と、乗降日時と、停車地点と、乗車者名と、降車者名とを対応付けた運行スケジュールを記憶する運行スケジュール記憶手段と、前記乗合車両の乗降を予約した予約者名と、乗車日時と、乗車地点と、降車日時と、降車地点とを対応付けた予約情報を記憶する予約情報記憶手段と、を備える通知サーバによって実行される方法であって、
   予約者名と、乗車日時と、乗車地点と、降車日時と、降車地点と、からなる予約情報を受信し、受信した前記予約情報を前記予約情報記憶手段に格納する受信ステップと、
   前記予約情報記憶手段に記憶された前記予約情報に基づく運行が可能な経路を算出し、算出した経路を辿るための、乗降日時と、停車地点と、乗車者名と、降車者名と、からなる運行スケジュールを生成し、生成した前記運行スケジュールを前記運行スケジュール記憶手段に格納する運行スケジュール生成ステップと、
   前記受信ステップは、前記情報端末装置から送信される、乗降日時と、停車地点と、乗車者名と、降車者名と、からなる乗降情報を受信し、
   前記乗降情報に含まれる前記乗車者名と、前記乗降情報に含まれる前記乗降日時および前記停車地点に対応付けられた、前記運行スケジュール記憶手段に記憶された前記乗車者名とが合致するか否かを判断する乗降実績判断ステップと、
   前記乗降実績判断ステップによって前記乗車者名が合致しないと判断した場合、乗車者が予約通りに乗車しなかった旨と、前記予約情報と、前記乗降情報とを含み、前記乗車者名に応じた前記利用者名に対応付けられた通知先を前記通知先情報記憶手段から取得し、取得した前記通知先を宛先とした通知情報を生成する通知情報生成ステップと、
   前記通知情報生成ステップによって生成された前記通知情報を送信する送信ステップと、
   を含むことを特徴とする通知方法。
9. 利用者の予約に応じ停車地点および運行時間を柔軟に変更できる乗合車両に搭載した情報端末装置とネットワークを介して接続し、前記乗合車両に乗降する利用者を識別する利用者名と、前記利用者に対応付けられた１または複数の通知先を記憶する通知先情報記憶手段と、乗降日時と、停車地点と、乗車者名と、降車者名とを対応付けた運行スケジュールを記憶する運行スケジュール記憶手段と、前記乗合車両の乗降を予約した予約者名と、乗車日時と、乗車地点と、降車日時と、降車地点とを対応付けた予約情報を記憶する予約情報記憶手段と、を備えるコンピュータに、
   予約者名と、乗車日時と、乗車地点と、降車日時と、降車地点と、からなる予約情報を受信し、受信した前記予約情報を前記予約情報記憶手段に格納する受信ステップと、
   前記予約情報記憶手段に記憶された前記予約情報に基づく運行が可能な経路を算出し、算出した経路を辿るための、乗降日時と、停車地点と、乗車者名と、降車者名と、からなる運行スケジュールを生成し、生成した前記運行スケジュールを前記運行スケジュール記憶手段に格納する運行スケジュール生成ステップと、
   前記受信ステップは、前記情報端末装置から送信される、乗降日時と、停車地点と、乗車者名と、降車者名と、からなる乗降情報を受信し、
   前記乗降情報に含まれる前記乗車者名と、前記乗降情報に含まれる前記乗降日時および前記停車地点に対応付けられた、前記運行スケジュール記憶手段に記憶された前記乗車者名とが合致するか否かを判断する乗降実績判断ステップと、
   前記乗降実績判断ステップによって前記乗車者名が合致しないと判断した場合、乗車者が予約通りに乗車しなかった旨と、前記予約情報と、前記乗降情報とを含み、前記乗車者名に応じた前記利用者名に対応付けられた通知先を前記通知先情報記憶手段から取得し、取得した前記通知先を宛先とした通知情報を生成する通知情報生成ステップと、
   前記通知情報生成ステップによって生成された前記通知情報を送信する送信ステップと、
   を実行させることを特徴とする通知プログラム。

Images