JP6749359B2 - 車両乗合支援システム - Google Patents

Description

本発明は、ユーザにライドシェアサービスを提供する車両乗合支援システムに関する。

自動車で移動する予定のある運転者と、他人の車に乗り合って到着地まで移動することを希望する乗合者との間で、自動車の乗合（ライドシェア）を支援する車両乗合支援システム（ライドシェアシステム）が公知である（例えば、特許文献１）。乗合を行なうことで自動車の運行台数が減るため、エネルギーの節約やＣＯ_２排出量の削減、交通渋滞の緩和が可能になる。

特許文献１に係る乗合支援システムでは、運転者から運転者の出発地・到着地・出発時刻を含む運転予定情報が送信され、乗合者から乗合者の現在位置・到着地・到着時刻を含む希望乗合条件が送信される。車両乗合支援システムは、運転予定情報と希望乗合条件とを受信すると、両者に基づいて運転者及び乗合者の最適な組み合わせを算出し、両者に合致した乗合の運行予定を作成する。

特開２００２−１４０３９９号公報

しかしながら、乗合者が自身の予定を正しく把握できていない場合や入力ミスが生じた場合など、乗合者が真の要求と合致しない希望乗合条件を車両乗合支援システムに送信する場合がある。その場合には、車両乗合支援システムは乗合者の真の要求に合致しない運行予定を作成するため、乗合のキャンセルが増加し、結果として運転者及び乗合者の組み合わせが最適な組み合わせにならない場合がある。

本発明は、以上の背景を鑑み、乗合支援システムにおいて、ユーザ（乗合者）からの真の要求と合致しない希望乗合条件の送信を防止することを課題とする。

上記課題を解決するために本発明の一態様は、複数のユーザの乗合を支援する車両乗合支援システム（１）であって、入力部（１２Ｂ）と表示部（１２Ａ）とを備えたユーザインタフェース（１２）、及び前記ユーザインタフェースを制御する端末処理部（１１）を備えた端末（２）と、前記ユーザの行動情報を記憶する行動情報管理サーバ（７）と、前記行動情報管理サーバ及び前記端末にネットワーク（３）を介して通信し、前記端末処理部から送信された前記ユーザの出発地、出発時刻、到着地、及び到着時刻の少なくとも１つを含む希望乗合条件に基づいて、所定の実施期間内の乗合の運行予定を作成する乗合管理サーバ（４）とを有し、前記乗合管理サーバは、前記行動情報に基づき、前記ユーザそれぞれに対して、前記ユーザに適した出発地、出発時刻、到着地、及び到着時刻の少なくとも１つを含む推奨乗合条件を生成して、前記端末処理部に送信し、前記端末処理部は、前記ユーザインタフェースに前記推奨乗合条件を前記ユーザの前記希望乗合条件を表示させることを特徴とする。

この態様によれば、ユーザの真の要求を反映した行動情報に基づいて推奨乗合条件が生成され、その推奨乗合条件がユーザインタフェースに表示される。そのため、ユーザの真の要求と合致しない希望乗合条件が送信されることを防止することができる。

上記の態様において、前記端末処理部は前記希望乗合条件を入力可能な入力欄（４０〜４４）と、前記推奨乗合条件とを前記ユーザインタフェースに同時に表示させるとよい。

この態様によれば、ユーザは推奨乗合条件を確認しながら、ユーザが希望乗合条件を入力欄に入力することができる。

上記の態様において、前記端末処理部は、前記推奨乗合条件を前記入力欄内に表示させるとよい。

この態様によれば、推奨乗合条件が入力欄内に表示されているため、推奨乗合条件がユーザの真の要求に合致しているときには、ユーザの入力欄への希望乗合条件の入力を省くことができる。

上記の態様において、前記端末処理部は、前記ユーザインタフェースに、前記推奨乗合条件とともに、前記推奨乗合条件を前記希望乗合条件として前記乗合管理サーバに送信することへの採否を受け付ける採否ボタン（３５）を表示するとよい。

この態様によれば、ユーザは、希望乗合条件が推奨乗合条件に合致するときに、希望乗合条件を入力することなく、採否ボタンに入力を行うことによって、希望乗合条件を乗合管理サーバに容易に送信することができる。

上記の態様において、前記端末処理部は、前記採否ボタンに前記推奨乗合条件を前記希望乗合条件として前記乗合管理サーバに送信しないことに対応する入力があったときに前記ユーザインタフェースに前記ユーザが希望する出発地、出発時刻、到着地、及び到着時刻の少なくとも１つを含む前記希望乗合条件を入力可能な入力欄（４０〜４４）を表示するとよい。

この態様によれば、ユーザは推奨乗合条件を確認しながら、ユーザが希望乗合条件を入力欄に入力することができる。

上記の態様において、前記端末処理部は、前記推奨乗合条件を前記入力欄内に表示させるとよい。

この態様によれば、推奨乗合条件が入力欄内に表示されているため、推奨乗合条件がユーザの真の要求に合致しているときには、ユーザの入力欄への希望乗合条件の入力を省くことができる。

上記の態様において、前記出発地又は前記到着地は全ての前記ユーザに共通の予め定められた場所に設定されているとよい。

この態様によれば、出発地又は到着地を勤務地に設定することによって、乗合支援システムを通勤のための乗合を支援するために利用することができる。出発地又は到着地を学校に設定することによって、乗合支援システムを通学のための乗合を支援するために利用することができる。

上記の態様において、前記行動情報は予め記憶された場所への移動の有無に対応する移動情報を含み、前記乗合管理サーバは、前記乗合の前記実施期間の前記行動情報に移動が無いことに対応する移動情報が含まれるときには、前記推奨乗合条件を生成しないとよい。

この態様によれば、実施期間の行動情報に勤務地等の予め記憶された場所への移動が無いことに対応する移動情報が含まれるときは、推奨乗合条件が生成されない。これによって、ユーザの乗合の利用が想定できないときに、ユーザインタフェースに推奨乗合条件が表示されない。一方、ユーザの乗合の利用が想定できる場合にはユーザインタフェースには推奨乗合条件が表示される。そのため、推奨乗合条件が表示されていないことによって、ユーザは自身の予定が乗合の利用に相応しくないことを認識することができ、ユーザの真の要求と合致しない乗合の申込を防止することができる。

上記の態様において、前記ユーザの出勤時刻を取得する勤怠記録部（１８）を備え、前記行動情報は過去の出勤時刻を含み、前記乗合管理サーバは過去の出勤時刻に基づいて、前記実施期間の前記ユーザの出勤時刻を推定し、推定された出勤時刻に基づいて前記推奨乗合条件の前記到着時刻を生成するとよい。

この態様によれば、推奨乗合条件をよりユーザに適したものにすることができる。

上記の態様において、前記乗合管理サーバは、前記行動情報管理サーバに記憶された前記行動情報のそれぞれに対応する重要度を出力し、前記重要度が高くなるにつれて大きくなるシフト時間を算出し、推定された前記出勤時刻から前記シフト時間だけ早めた時刻に基づいて前記推奨乗合条件の前記到着時刻を生成するとよい。

この態様によれば、実施期間内における行動情報の重要度に合わせて到着時刻を早めることができるため、推奨乗合条件をよりユーザに適したものにすることができる。

上記の態様において、前記ユーザの退勤時刻を取得する勤怠記録部（１８）を備え、前記行動情報は過去の退勤時刻を含み、前記乗合管理サーバは過去の退勤時刻に基づいて、前記実施期間の前記ユーザの退勤時刻を推定し、推定された退勤時刻に基づいて前記推奨乗合条件の前記出発時刻を生成するとよい。

この態様によれば、推奨乗合条件をよりユーザに適したものにすることができる。

以上の構成によれば、車両乗合支援システムにおいて、ユーザからの真の要求と合致しない希望乗合条件の送信を防止することができる。

第１実施形態に係る車両乗合支援システムの構成図 行動情報テーブルに記入されたデータの例 申込情報管理テーブルに記入されたデータの例 重要度算出テーブルに記入されたデータの例 乗合支援処理の手順を示すフロー図 サーバ側申込受付開始処理の手順を示すフロー図 端末側申込受付処理の手順を示すフロー図 端末側申込受付処理時の端末の画面遷移 端末側申込受付処理時の端末の画面遷移 サーバ側申込受付処理の手順を示すフロー図 第２実施形態に係る端末側申込受付処理の手順を示すフロー図 第２実施形態に係る端末側申込受付処理時のユーザ端末の画面表示の説明図

以下、図面を参照して、車両乗合支援システムの実施形態について説明する。本実施形態に係る車両乗合支援システム１は、特定の団体（企業、役所）に所属する複数のユーザ（構成員）によって朝の通勤時間帯（実施期間）に行われる特定の場所（勤務地）への移動に対する乗合を支援する乗合サービス（ライドシェアサービス）を行う。ここでの乗合サービスとは、ユーザから出発地、到着地、出発時刻、及び到着時刻などの各ユーザの希望する希望乗合条件を受信し、受信した希望乗合条件に基づいて、乗合を行うユーザの最適な組み合わせ、最適な車両及び最適な走行経路（例えば、交通渋滞を最も緩和できる経路）を決定して各ユーザに通知することである。

車両乗合支援システム１を利用する団体は、ユーザに使用させる目的で複数の共用車を所有している。車両乗合支援システム１において、複数の共用車と、ユーザが乗合に使用することに同意した自動車（以下、提供車という）とが乗合のために使用される。全てのユーザにはユーザ識別番号が設定され、全ての共用車及び提供車には車両識別番号が設定されている。

＜＜第１実施形態＞＞
（車両乗合支援システムの構成）
図１に示すように、車両乗合支援システム１は、複数のユーザ端末２と、各ユーザの行動情報を管理する行動情報管理サーバ７と、各ユーザの行動情報に基づいて推奨乗合条件を生成して各ユーザ端末２に表示させるとともに、各ユーザ端末２から送信された希望乗合条件を処理して、乗合グループを作成し、各乗合グループの車両の運行予定を決定する乗合管理サーバ４とを有する。ユーザ端末２、行動情報管理サーバ７及び乗合管理サーバ４は互いにネットワーク３を介して接続されている。各ユーザ端末２は各ユーザに所持されており、行動情報管理サーバ７及び乗合管理サーバ４はともに車両乗合支援システム１を運営する企業の建屋内に設けられている。ネットワーク３は例えばインターネットである。

行動情報管理サーバ７は、各ユーザの行動情報が記録された行動情報テーブルＴ１（図２）を保持する行動情報管理部１７を有する。行動情報には日付、その日付における各ユーザの出勤時刻、退勤時刻、イベントの内容、及びイベントの内容に対応する重要度が含まれる。イベントの内容は勤務地への移動の有無に対応する移動情報を含む。本実施形態ではイベントの内容は空欄（通常勤務）であるか、又は、休暇、出張、会議の予定情報を含んでいる。予定情報には会議の開始時刻と終了時刻及び場所の情報が含まれていてもよい。イベントの内容は、ユーザ端末２からネットワーク３を介して書き込み、修正等が行われるとよい。重要度は各イベントの内容に対して定められ、対応するイベントが重要であるほど高くなるように設定された数値である。本実施形態では、重要度は会議が行われる場所に基づいて定められ、０〜５の数値に設定されている。

行動情報管理サーバ７は勤怠取得部１５を備え、各ユーザの出勤時刻及び退勤時刻を記録する勤怠記録部１８（例えば、タイムカードレコーダ）に接続されている。勤怠取得部１５は勤怠記録部１８で記録された各ユーザの出勤時刻及び退勤時刻を受信して、各ユーザの出勤時刻及び退勤時刻を行動情報テーブルＴ１に記録する。

乗合管理サーバ４は、乗合申込の受付処理を行う申込処理部２２と、申込情報を記憶する申込情報管理部２３と、乗合申込があったユーザをグループ化して複数の乗合グループを作成するとともに、地図情報を保持する外部のナビゲーションサーバ５を使って各乗合グループの車両の運行予定情報を作成する運行予定作成部２４と、作成した乗合グループ及び運行予定を記憶する乗合情報管理部２５と、ユーザの属性情報を保持するユーザ属性管理部２６と、登録された車両情報を保持する車両情報管理部２７と、外部の道路情報サーバ６を使って渋滞情報を取得する道路情報取得部２８と、運行予定情報をユーザに通知する処理を行うユーザ通知部２９とを有する。

ユーザ属性管理部２６は、ユーザに関連する情報をユーザ属性情報として記憶している。ユーザ属性情報は、ユーザ識別番号、ユーザ氏名、住所、ユーザの勤務地、及びユーザが所有するユーザ端末２の情報を含む。ユーザ端末２の情報とは行動情報管理サーバ７及び乗合管理サーバ４がユーザ端末２に通信するために要する情報である。本実施形態では、各ユーザの勤務地は、企業や役所等が設けられた全ユーザに共通の一つの敷地内に設定されている。

車両情報管理部２７は、乗合で使用する車両として登録された共用車及び提供車の情報を車両情報として記憶している。車両情報は、登録された車両毎に、車両識別番号、所有者、車種名、乗車定員数の情報を含む。所有者は、提供車においてはその車両を所有する者であり、公用車においてはその車両のキーを所有する者である。所有者は、後述されるように、乗合サービスが実行される毎に更新される。

申込情報管理部２３は、申込情報テーブルＴ２（図３）を保持している。申込情報テーブルＴ２には、申込識別番号と、申込識別番号に対応する申込情報が記録されている。申込情報には申込を行ったユーザのユーザ識別番号と、出発地、到着地、出発時刻、及び到着時刻を含む希望乗合条件と、申込を行ったユーザがキーを所持している提供車又は公用車の車両識別番号とが含まれる。

申込処理部２２は、行動情報テーブルＴ１のイベントの内容から重要度を出力する重要度出力部３１と、イベントの内容に基づいて乗合の要否を判定する要否判定部３２と、各ユーザの行動情報に合致する出発地、到着地、出発時刻及び到着時刻を含む推奨乗合条件を生成するとともに、乗合に適した提供車又は公用車の車両識別番号である推奨車両識別番号とを生成する推奨条件生成部３３と、生成された推奨乗合条件及び推奨車両識別番号とともに、申込の受付を開始したことを示す信号を受付開始信号としてユーザ端末２に送信する受付開始信号送信部３４と、受け付けた申込情報を行動情報テーブルＴ１と比較し、整合していない場合にユーザ端末２にアラート信号を送信する警告部３０とを有している。

重要度出力部３１は、ユーザが行動情報テーブルＴ１にイベントの内容に含まれうるキーワードと、各キーワードに対応するイベントの重要度との関係が記録された重要度算出テーブルＴ３を保持している（図４）。例えば、重要度算出テーブルＴ３には、会議が行われる場所としての「第１会議室」と、その会議に対応する重要度「５」とが対応付けて記録されている。重要度出力部３１は重要度算出テーブルＴ３を参照して、各イベントの内容に対応する重要度を決定し、行動情報テーブルＴ１に記入（出力）する。

要否判定部３２は、各ユーザの行動情報テーブルＴ１の実施期間に対応する日付（本実施形態では翌日の日付）に記載されたイベントの内容を参照して、ユーザが乗合を利用するかを判定する。例えば、要否判定部３２は、イベントの内容に「休暇」の文字が含まれている場合には、乗合の利用の可能性が無いと判定する。要否判定部３２は実施期間に対応する日が出勤日であり、且つイベントの内容が空欄である場合には、乗合の利用の可能性を有りと判定する。

推奨条件生成部３３は行動情報テーブルＴ１に含まれる情報に基づいて、各ユーザの行動情報に合致する出発地、到着地、出発時刻及び到着時刻を含む推奨乗合条件を生成する。また、推奨条件生成部３３は車両情報管理部２７の車両情報を参照して、乗合に利用に適した提供車又は公用車の車両識別番号である推奨車両識別番号を生成する。

より詳細には、推奨条件生成部３３は、実施期間に対応する日付を取得し、行動情報テーブルＴ１を参照してその日付におけるイベントの内容を取得する。イベントの内容に「休暇」又は「出張」が含まれている場合には、推奨条件生成部３３は推奨乗合条件を出力しない。イベントの内容が空欄である場合には、信号を受信した日から１ヶ月前まで出勤時刻を平均して平均出勤時刻を算出する。推奨条件生成部３３は、平均出勤時刻から所定の移動時間を差し引いた時刻（以下、第１時刻とする）を推奨乗合条件の到着時刻として出力する。移動時間としては、後述する推奨乗合条件の到着地から実際の勤務地までに移動するのに要する時間を目安として定めるとよい。

推奨条件生成部３３は、イベントの内容に「会議」が含まれている場合には、推奨条件生成部３３は会議の開始時刻を推定し、開始時刻からイベントの重要度が大きくなるにつれて増加するシフト時間（例えば、重要度と所定の時間（１０分）との積）を引き、更に、移動時間を差し引いた時刻（第２時刻とする）を算出する。次に、上記の第１時刻を算出し、第１時刻と第２時刻とを比較して、早い方を推奨乗合条件の到着時刻として出力する。このように構成することで、ユーザが会議の重要度に合わせて、推奨乗合条件の到着時刻を早めることができ、推奨乗合条件の到着時刻がユーザにとってより適した時刻になる。

推奨条件生成部３３は、更に、ユーザ属性情報を参照して、ユーザの住所を取得し、推奨乗合条件の出発地として出力する。次に推奨条件生成部３３は、ユーザ属性情報の勤務地を取得し、車両の到着地として適切な場所を選定して、推奨乗合条件の到着地として出力する。

次に、推奨条件生成部３３は、出発地及び到着地から到着までに要する所要時間を算出して、推奨乗合条件の到着時刻から所要時間を引き、推奨乗合条件の出発時刻として出力する。

また、推奨条件生成部３３は車両情報から各ユーザのユーザ識別番号を検索することで、各ユーザが共用車又は提供車のキーを所有しているかを判別する。ユーザが共用車のキー及び提供車のキーを両方所有している場合には、その共用車の車両識別番号を推奨車両識別番号として出力する。ユーザが共用車のキーのみを所有し、提供車のキーを所有していない場合にはその共用車の車両番号を推奨車両識別番号として出力する。ユーザが共用車のキーを所有せず、提供車のキーのみを所有している場合にはその提供車の車両番号を推奨車両識別番号として出力する。ユーザがどちらの車両のキーも所有していない場合には、推奨車両識別番号を空欄にして出力する。

警告部３０は、申込情報を受信すると、申込の対象となる実施期間に対応する日付を取得し、各ユーザの申込情報と対応するユーザの行動情報テーブルＴ１の実施期間に対応する日付に記載されたイベントの内容とを比較して整合するかを判定する。例えば、警告部は、申込情報の出発時刻が８：３０であり、且つ、実施期間に対応する日付に記載されたイベントの内容に「休暇」を含まれるときには、申込情報とイベントの内容とが整合しないと判定するとよい。警告部３０は、申込情報とイベントの内容が整合しない場合には、アラート信号をユーザ端末２に送信する。

運行予定作成部２４は、ユーザ属性情報に基づいて所定の運転者候補設定処理を実行することによって、申込情報テーブルＴ２に記録された各ユーザを運転者候補及び乗員候補（運転しない者）のいずれかに設定する。また、運行予定作成部２４は、道路情報取得部２８によって取得される渋滞情報、申込情報テーブルＴ２に書き込まれた情報、ユーザ属性情報及び車両情報に基づき、ナビゲーションサーバ５を用いて、複数の乗合申込を行なったユーザをグループ化し、交通渋滞を最も少なくすることができる複数の乗合グループ、及び各乗合グループの車両の運行予定情報を生成する。運行予定情報には、乗合グループのグループ識別番号、対応する乗合グループに含まれる全ユーザのユーザ識別番号、運転者に設定されたユーザのユーザ識別番号、使用される車両の車両識別番号、車両の走行経路、全ユーザの出発地、到着地、出発時刻、及び到着時刻を含む。

乗合情報管理部２５は、運行予定作成部２４が作成した運行予定情報を記憶する。乗合情報管理部２５は、更に運転者を所有者として車両情報に書き込む。

ユーザ通知部２９は、乗合情報管理部２５に記憶された運行予定情報から各ユーザに対応するユーザ運行予定情報を作成し、各ユーザのユーザ端末２に対応するユーザ運行予定情報を送信する。ユーザ運行予定情報は、ユーザの属する乗合グループのグループ識別番号、その乗合グループの車両の走行経路、その乗合グループに含まれる全ユーザのユーザ識別番号、運転者に設定されたユーザのユーザ識別番号、その乗合に使用される車両の車両識別番号、各ユーザの出発地、到着地、出発時刻、到着時刻を含む。

ユーザ端末２は、例えば、スマートフォンや、タブレットＰＣ、携帯電話、ＰＤＡ等であり、アプリケーションを実行するための端末処理部１１、端末処理部１１によって制御されるユーザインタフェース１２、及びメモリを備えている。ユーザインタフェース１２は、端末処理部１１からの信号に基づいて入力画面やメッセージを表示する表示部１２Ａと、ユーザからの入力を受け付ける入力部１２Ｂとを備えている。ユーザ端末２がスマートフォン、タブレットＰＣ、ＰＤＡであるときには、ユーザインタフェース１２はタッチパネルであり、表示部１２Ａは液晶パネルであり、入力部１２Ｂはタッチセンサである。ユーザ端末２が携帯電話であるときには、ユーザインタフェース１２の表示部１２Ａは液晶パネルであり、入力部１２Ｂは操作ボタンである。

端末処理部１１は受付開始信号を受信すると、後述する端末側申込受付処理を行って、表示部１２Ａに推奨乗合条件を表示するとともに、入力部１２Ｂからの入力に基づいて申込情報を乗合管理サーバ４に送信する。端末処理部１１はユーザ運行予定情報を受信すると、表示部１２Ａにユーザ運行予定情報を表示する。端末処理部１１はアラート信号を受信すると、表示部１２Ａに所定のアラーム表示を行う。

（乗合支援処理）
以下に、車両乗合支援システム１の乗合支援処理の手順について説明する。乗合管理サーバ４は乗合が実施される実施期間を設定し、各実施期間に複数のユーザによって行われる乗合を支援する乗合支援処理を実行する。実施期間は、例えば、平日の朝の通勤帯（６時〜１０時）である。車両乗合支援システム１は、各実施期間に対して乗合支援処理を１回ずつ実行する。各実施期間には、ユーザから乗合の申込の受付を開始する受付開始時刻、及び、受付を締め切る受付終了時刻が定められている。実施期間がある日の６時〜１０時（朝の通勤帯）である場合、受付開始時刻は実施期間がある日の前日の１１時、受付終了時刻は、例えば、その前日の２０時に設定されている。

図５は、乗合支援処理の手順を示すフローである。最初にステップＳ１において、受付開始時刻になると、乗合管理サーバ４の申込処理部２２がサーバ側申込受付開始処理を実行する。サーバ側申込受付開始処理では、乗合を利用する可能性のあるユーザを抽出し、そのユーザが所有するユーザ端末２に受付開始信号を送信する。

ユーザ端末２は受付開始信号を受信すると、図５には図示しない端末側申込受付処理を行う。ユーザ端末２は端末側申込受付処理において、ユーザから希望乗合条件を含む申込情報を受け付け、乗合申込があったときに申込情報を乗合管理サーバ４に送信する。

次に、乗合管理サーバ４の申込処理部２２は申込情報を受信すると、サーバ側申込受付処理（ステップＳ２）を行う。申込処理部２２は、サーバ側申込受付処理において、申込情報を受信した時刻が受付終了時刻以前かを判定し、以前である場合には申込情報管理部２３に保持された申込情報テーブルＴ２に申込情報を書き込む。

次に、運行予定作成部２４は、申込情報テーブルＴ２に基づいて運転者候補設定処理（ステップＳ３）を実行する。この処理によって、乗合申込のあったユーザの内から運転者候補が設定される。この処理において、運転者候補に設定されなかったユーザは、乗員候補（運転しない者）に設定される。運行予定作成部２４は、各ユーザが運転者候補及び乗員候補のいずれであるかを示すユーザ属性情報を申込情報管理部２３に記憶する。

次に、運行予定作成部２４は、運行予定作成処理（ステップＳ４）を実行する。運行予定作成処理によって複数の乗合グループと、各乗合グループの車両の運行予定情報とが設定される。運行予定作成部２４は、設定した運行予定情報を乗合情報管理部２５に記憶する。

次に、ユーザ通知部２９は、乗合情報管理部２５に記憶された運行予定情報からユーザ運行予定情報を作成し、各ユーザ端末２に対応するユーザ運行予定情報を送信する（ステップＳ５）。ユーザ端末２の表示部１２Ａにはユーザ運行予定情報が表示される。これによって、各ユーザは自身のユーザ運行予定情報を確認することができる。

（サーバ側申込受付開始処理）
図６は、サーバ側申込受付開始処理を示すフロー図である。サーバ側申込受付開始処理は、乗合管理サーバ４の申込処理部２２が実行する。サーバ側申込受付開始処理は、登録されたユーザそれぞれに対して実行される。

サーバ側申込受付開始処理では、最初にステップＳ１１において、要否判定部３２が翌日の乗合の利用の可能性の有無を判定する。要否判定部３２が乗合の利用の可能性を有（Ｙｅｓ）と判定したときには、申込処理部２２はステップＳ１２を実行し、無（Ｎｏ）と判定したときには、申込開始処理を完了する。

ステップＳ１２では、重要度出力部３１が申込情報テーブルＴ２を参照して翌日の日付のイベントの内容を取得し、重要度算出テーブルＴ３を参照してそのイベントの内容に対応する重要度を決定する。決定後、行動情報テーブルＴ１の翌日の日付の重要度の欄に重要度を記入する。次に、ステップＳ１３において、推奨条件生成部３３が推奨乗合条件及び推奨車両識別番号を生成する。

次に、ステップＳ１４において、受付開始信号送信部３４が推奨乗合条件及び推奨車両識別番号を含む受付開始信号を対応するユーザ端末２に送信し、サーバ側申込受付開始処理を完了する。

（端末側申込受付処理）
図７は、端末側申込受付処理を示すフロー図である。端末側申込受付処理は受付開始信号を受信した後に端末処理部１１によって実行される。端末側申込受付処理では、最初にステップＳ２１において、端末処理部１１は受信した推奨乗合条件及び推奨車両識別番号をメモリに最新申込情報として保存する。その後、端末処理部１１はステップＳ２２を実行する。

端末処理部１１はステップＳ２２において、ユーザインタフェース１２に、メモリに保存された最新申込情報と、「予約」（予約ボタン）、「キャンセル」（キャンセルボタン）、及び「変更」（変更ボタン）と書かれた３つの入力ボタン３５（採否ボタン）とを同時に表示する（図８（Ａ））。各入力ボタン３５への入力はユーザからの押圧によって行われる。予約ボタンが押圧される（ステップＳ２３）と、端末処理部１１はステップＳ２４を実行し、キャンセルボタンが押圧される（ステップＳ２５）と、端末処理部１１は端末側申込受付処理を終了し、変更ボタンが押圧される（ステップＳ２６）と、ステップＳ２７を実行する。端末処理部１１は、選択ボタンのいずれかが押圧されるまで、ステップＳ２３、Ｓ２５、Ｓ２６を順に実行して待機する。

端末処理部１１はステップＳ２４において、メモリに保存された最新申込情報を申込情報として乗合管理サーバ４に送信する。送信が完了すると、端末処理部１１は端末側申込受付処理を終了する。

端末処理部１１はステップＳ２７において、ユーザインタフェース１２に最新申込情報の出発地を示す目印を地図内に表示した入力欄４０と変更ボタン３６とを表示する（図８（Ｂ））。端末処理部１１は入力欄４０内に押圧があると、目印を押圧された位置に移動させる。端末処理部１１は、変更ボタン３６が押圧されると、最新申込情報の出発地を入力欄４０の目印の位置に更新し、ステップＳ２８を実行する。

端末処理部１１はステップＳ２８において、ユーザインタフェース１２に変更ボタン３６とともに、ユーザの希望する出発時刻を入力するための入力欄４１を最新申込情報の出発時刻を予め入力して表示する（図８（Ｃ））。このとき入力欄４１には最新申込情報の出発時刻が表示される。本実施形態では、入力欄４１としてドラムロール型が用いられている。端末処理部１１は、変更ボタン３６が押圧されると、最新申込情報の出発時刻を入力欄４１に入力された出発時刻に更新し、ステップＳ２９を実行する。

端末処理部１１はステップＳ２９において、ユーザインタフェース１２に最新申込情報の到着地を示す目印を地図内に表示した入力欄４２と変更ボタン３６とを表示する（図９（Ａ））。端末処理部１１は入力欄４２内に押圧があると、目印を押圧された位置に移動させる。端末処理部１１は、変更ボタン３６が押圧されると、最新申込情報の到着地を入力欄４０の目印の位置に更新し、ステップＳ３０を実行する。

端末処理部１１はステップＳ３０において、ユーザインタフェース１２に変更ボタン３６とともに、到着時刻の入力欄４３を最新申込情報の到着時刻を予め入力して表示する（図９（Ｂ））。端末処理部１１は、変更ボタン３６が押圧されると、最新申込情報の到着時刻を入力欄に入力された到着時刻に更新し、ステップＳ２２に戻る。

（サーバ側申込受付処理）
図１０は、サーバ側申込受付処理を示すフロー図である。サーバ側申込受付処理は、乗合管理サーバ４の申込処理部２２が実行する。サーバ側申込受付処理では、最初にステップＳ４１において、申込処理部２２は、現在の時刻が受付終了時刻以前かどうかを判定する。受付終了時刻よりも前である場合には、ステップＳ４２を実行する。現在の時刻が受付終了時刻よりも後である場合には、サーバ側申込受付処理を終了する。

ステップＳ４２において、申込処理部２２はユーザ端末２から申込情報を受信したかを判定する。申込処理部２２は、申込情報を受信したときにはステップＳ４３を実行し、受信していないときはステップＳ４１に戻って待機する。

ステップＳ４３において、警告部３０は受信した申込情報が行動情報テーブルＴ１の実施期間に対応する日付に記載されたイベントの内容に整合しているかを判定する。整合しているときにはステップＳ４５を実行し、整合していないときにはステップＳ４４を実行する。

ステップＳ４４において、警告部３０はユーザ端末２にアラート信号を送信する。ユーザ端末２はアラート信号を受信するとアラート画面を表示する。アラート画面には、申込情報が行動情報テーブルＴ１に記録されたイベントの内容と合致しない旨の警告と、申込情報の再確認を促す表示とが含まれるとよい。送信が完了すると、申込処理部２２は、ステップＳ４５を実行する。

ステップＳ４５において、申込処理部２２は申込情報を申込情報テーブルＴ２に書き込み、ステップＳ４１に戻る。このとき、申込処理部２２は申込情報を送信したユーザから既に申込があった場合には受信した申込情報によって申込情報テーブルＴ２を更新するように構成するとよい。

以上のように構成した車両乗合支援システム１の効果について説明する。推奨乗合条件は実施期間におけるユーザのイベントの内容と、出勤時刻及び退勤時刻とを含む行動情報に基づいて生成されている。そのため、推奨乗合条件はユーザの真の要求に合致し易い。ユーザ端末２は受付開始信号を受信すると、最初に実行されるステップＳ２２において、推奨乗合条件をユーザインタフェース１２に表示する。そのため、ユーザは推奨乗合条件を確認しながら希望乗合条件を入力することができ、ユーザが自身の真の要求に合致しない乗合条件を希望乗合条件として送信することを防止することができる。これによって、ユーザの乗合のキャンセルを減らすことができ、より確実に交通渋滞を緩和することができる。また、推奨乗合条件がユーザの真の要求に合致しているときには、予約ボタンの押すことによって乗合の申込を行うことができ、ユーザの希望乗合条件の入力を省くことができる。

受付開始信号がユーザ端末２に送信された後、初めて乗合の条件を変更するときには、端末処理部１１はメモリから最新申込情報を読み出し、入力欄４０、４１、４２、４３に予め入力して表示する（Ｓ２７、Ｓ２８、Ｓ２９、Ｓ３０）。初めて乗合の条件を変更するときには、推奨乗合条件が最新申込情報としてメモリに保存されているため、入力欄には推奨乗合条件が予め入力されて表示される。そのため、ユーザが希望する乗合条件を入力する手間を省くことができる。

乗合管理サーバ４は、イベントの内容と整合しない乗合の申込が行われると、警告部３０によってアラート信号が送信されて、ユーザ端末２にアラート画面が表示される。そのため、ユーザが自身の真の要求に合致しない乗合の申込を防止することができる。

行動情報テーブルＴ１には、会議、出張及び休暇といったユーザの予定に関する行動情報が含まれているため、ユーザの乗合を利用する可能性を適切に判定することができる。また、行動情報テーブルＴ１には、ユーザの出勤時刻、及び退勤時刻を含むため、ユーザの行動履歴をより正確に把握でき、推奨乗合条件がよりユーザに適したものとなる。行動情報テーブルＴ１には、重要度が含まれ、実施期間内における行動情報の重要度に合わせて到着時刻を早めることができるため、推奨乗合条件がユーザにより適したものとなる。

＜＜第２実施形態＞＞
第２実施形態に係る車両乗合支援システム１は、図１１に示すように、端末側申込受付処理が異なる。端末処理部１１はまずステップＳ５１において受付開始信号を受信する。その後、ステップＳ５２において、端末処理部１１はユーザインタフェース１２に、図１２に示すように、予約ボタン及びキャンセルボタンを含む入力ボタン３５と、ユーザが希望する出発地、出発時刻、到着地、及び到着時刻の少なくとも１つを含む希望乗合条件が入力可能であり、かつ推奨乗合条件が予め入力された入力欄４４とを表示する。ユーザは入力欄４４に入力することによって、希望乗合条件を入力することができる。このとき、推奨乗合条件が入力欄４４に予め入力されているため、希望乗合条件の入力が容易である。予約ボタンが押圧されると、端末処理部１１はステップＳ５４に進み、入力された申込情報を乗合管理サーバ４に送信し、端末側申込受付処理を完了する。キャンセルボタンが押圧された場合（ステップＳ５５）には、端末処理部１１は端末側申込受付処理を終了し、キャンセルボタンが押圧されていない場合はステップＳ５３に戻る。

以上で具体的実施形態の説明を終えるが、本発明は上記実施形態に限定されることなく幅広く変形実施することができる。サーバ側申込受付処理のステップＳ４２の後、ステップＳ４１の前に、警告部３０が要否判定部３２において要と判定され、かつ乗合の申込が完了されていないときに、ユーザ端末２に乗合申込が完了していないことを通知するアラーム画面を表示させる信号を送信するように構成してもよい。これによって、乗合を行うユーザを増やすことができる。

上記実施形態では、車両乗合支援システム１が企業、役所等の団体の通勤のための乗合を支援するために利用されていたが、この態様には限定されない。車両乗合支援システム１は、学校、幼稚園、保育園、スポーツクラブ、介護施設、買物施設等に所属するユーザに利用され、当該施設への移動時間帯や当該施設からの移動時間帯ごとに、乗合サービスを実行してもよい。車両乗合支援システム１が通学のための乗合を支援する目的で利用されるときには、到着地は校門前などの、全てのユーザに共通の予め定められた場所に設定されるとよい。また、イベントの内容は遠足等の情報を含むとよい。車両乗合支援システム１が、通所介護サービス（デイサービス）を利用するための被介護者の介護施設への通所を支援する目的で利用されるときには、イベントの内容は被介護者が受けるサービスの内容を含むとよい。

上記実施形態では、車両乗合支援システム１の乗合サービスの実施期間として朝の出勤時間帯が設定されていたが、午後の退勤時間帯が実施期間として設定されてもよい。その場合は、推奨条件生成部３３は勤怠記録部１８によって取得された各ユーザの過去の退勤時刻に基づいて、その平均を計算することによって実施期間のユーザの退勤時刻を推定する。その後、推奨条件生成部３３は推定された退勤時刻を推奨乗合条件の出発時刻とするとよい。

上記実施形態では、車両乗合支援システム１では交通渋滞を減らすことを目的としていたが、これには限定されず、乗合管理サーバ４は、エネルギーの節約やＣＯ_２排出量の削減を目的として、グループ化するユーザの組み合わせや乗合が行われる車両の走行経路を最適化するように構成してもよい。上記実施形態では、推奨乗合条件及び希望乗合条件は、出発地、出発時刻、到着地、及び到着時刻の全てを含んでいたが、少なくとも１つを含む態様であってもよい。

１ ：車両乗合支援システム
２ ：ユーザ端末
３ ：ネットワーク
４ ：乗合管理サーバ
７ ：行動情報管理サーバ
１１ ：端末処理部
１２ ：ユーザインタフェース
１２Ａ ：表示部
１２Ｂ ：入力部
１８ ：勤怠記録部
３５ ：入力ボタン（採否ボタン）
４０〜４４ ：入力欄

Claims (12)

1. 複数のユーザの乗合を支援する車両乗合支援システムであって、
   入力部と表示部とを備えたユーザインタフェース、及び前記ユーザインタフェースを制御する端末処理部を備えた端末と、
   前記ユーザの行動情報を記憶する行動情報管理サーバと、
   前記行動情報管理サーバ及び前記端末にネットワークを介して通信し、前記端末処理部から送信された前記ユーザの出発地、出発時刻、到着地、及び到着時刻の少なくとも１つを含む希望乗合条件に基づいて、所定の実施期間内の乗合の運行予定を作成する乗合管理サーバとを有し、
   前記乗合管理サーバは、前記行動情報に基づき、前記ユーザそれぞれに対して、前記ユーザに適した出発時刻又は到着時刻を含む推奨乗合条件を生成して、前記端末処理部に送信し、
   前記端末処理部は、前記ユーザインタフェースに前記推奨乗合条件を表示させ、
   前記乗合管理サーバは、前記行動情報に基づいて前記ユーザのそれぞれに対して乗合の利用可能性を判定し、前記利用可能性のある前記ユーザが所有する前記端末に乗合の申込の受付を開始したことを示す受付開始信号を送信することを特徴とする車両乗合支援システム。
2. 前記端末処理部は前記希望乗合条件を入力可能な入力欄と、前記推奨乗合条件とを前記ユーザインタフェースに同時に表示させることを特徴とする請求項１に記載の車両乗合支援システム。
3. 前記端末処理部は、前記推奨乗合条件を前記入力欄内に表示させることを特徴とする請求項２に記載の車両乗合支援システム。
4. 前記端末処理部は、前記ユーザインタフェースに、前記推奨乗合条件とともに、前記推奨乗合条件を前記希望乗合条件として前記乗合管理サーバに送信することへの採否を受け付ける採否ボタンを表示することを特徴とする請求項１に記載の車両乗合支援システム。
5. 前記端末処理部は、前記採否ボタンに前記推奨乗合条件を前記希望乗合条件として前記乗合管理サーバに送信しないことに対応する入力があったときに前記ユーザインタフェースに前記ユーザが希望する出発地、出発時刻、到着地、及び到着時刻の少なくとも１つを含む前記希望乗合条件を入力可能な入力欄を表示することを特徴とする請求項４に記載の車両乗合支援システム。
6. 前記端末処理部は、前記推奨乗合条件を前記入力欄内に表示させることを特徴とする請求項５に記載の車両乗合支援システム。
7. 前記出発地又は前記到着地は全ての前記ユーザに共通の予め定められた場所に設定されていることを特徴とする請求項１〜請求項６のいずれか１つの項に記載の車両乗合支援システム。
8. 前記行動情報は予め記憶された場所への移動の有無に対応する移動情報を含み、
   前記乗合管理サーバは、前記乗合の前記実施期間の前記行動情報に移動が無いことに対応する移動情報が含まれるときには、前記推奨乗合条件を生成しないことを特徴とする請求項１〜請求項７のいずれか１つの項に記載の車両乗合支援システム。
9. 前記ユーザの出勤時刻を取得する勤怠記録部を備え、
   前記行動情報は過去の出勤時刻を含み、
   前記乗合管理サーバは過去の出勤時刻に基づいて、前記実施期間の前記ユーザの出勤時刻を推定し、推定された出勤時刻に基づいて前記推奨乗合条件の前記到着時刻を生成することを特徴とする請求項１〜請求項８のいずれか１つの項に記載の車両乗合支援システム。
10. 前記乗合管理サーバは、前記行動情報管理サーバに記憶された前記行動情報のそれぞれに対応する重要度を出力し、前記重要度が高くなるにつれて大きくなるシフト時間を算出し、推定された前記出勤時刻から前記シフト時間だけ早めた時刻に基づいて前記推奨乗合条件の前記到着時刻を生成することを特徴とする請求項９に記載の車両乗合支援システム。
11. 前記ユーザの退勤時刻を取得する勤怠記録部を備え、
    前記行動情報は過去の退勤時刻を含み、
    前記乗合管理サーバは過去の退勤時刻に基づいて、前記実施期間の前記ユーザの退勤時刻を推定し、推定された退勤時刻に基づいて前記推奨乗合条件の前記出発時刻を生成することを特徴とする請求項１〜請求項８のいずれか１つの項に記載の車両乗合支援システム。
12. 前記ユーザの出勤時刻を取得する勤怠記録部を備え、
    前記行動情報は過去の出勤時刻、及び、予定されたイベントの内容を含み、
    前記乗合管理サーバは過去の出勤時刻を平均して平均出勤時刻を算出し、算出された前記平均出勤時刻の所定の移動時間前の時刻を第１時刻として算出し、対応する前記イベントに対応する重要度を出力し、前記イベントの開始時刻を推定し、前記重要度が高くなるにつれて大きくなるシフト時間を算出し、推定された前記開始時刻の、前記シフト時間及び前記移動時間の合計時間前の時刻を第２時刻として算出し、前記第１時刻及び前記第２時刻の早い方を前記推奨乗合条件の到着時刻として生成することを特徴とする請求項１〜請求項８のいずれか１つの項に記載の車両乗合支援システム。

Images