JP2009061978A - 車両共有化システム - Google Patents

Abstract

【課題】各ユーザが車両を使用する毎に所望の車内環境に調整する必要が無い車両共有化システムの提供。
【解決手段】本発明は、少なくとも１台の車両を多数のユーザで使用可能とする車両共有化システムであって、各ユーザが設定した車内環境を、各ユーザに対応付けて記憶する車内環境情報記憶手段と、ユーザから車両の使用の予約を受けて予約スケジュールを生成する予約スケジュール生成手段と、前記予約スケジュールに基づいて、車両を予約したユーザ（以下、「予約ユーザ」という）に対応した車内環境情報を前記車内環境情報記憶手段から読み出し、該読み出した車内環境情報に基づいて、該予約ユーザが設定した車内環境へと車内環境を変化させる車内環境調整手段とを備えることを特徴とする。
【選択図】図２

Description

本発明は、少なくとも１台の車両を多数のユーザで使用可能とする車両共有化システム及び車両共有化方法に関する。

従来から、この種の車両共有化システムが知られている（例えば、特許文献１参照）。このシステムでは、ユーザは、自宅ＰＣ等からネットワークを介して車両の予約を行うことができる。

また、トランスポンダ式イモビライザーで使用されるキーのＩＤコードを利用して、キーをキーシリンダに差し込んでＡＣＣへ回すだけで、運転者の好みに応じた車内環境（運転席シート位置、ステアリング位置、ドアミラー位置、ルームミラー位置）を自動設定する技術が知られている（例えば、特許文献２参照）。
特開２００２−０４１６１３号公報 特開平９−１２３９２４号公報

ところで、近年では、マンションや都市の一定地域で、上記の特許文献１に記載のような、車両を多数のユーザで共同利用するカーシェアリングが実用化され始めている。しかしながら、カーシェアリングでは、多数のユーザが同一の車両を使用する関係上、各ユーザは、車両を使用する毎に、いちいち自己の好み等に適合した所望の車内環境に調整する必要があり、不便となりうる。

そこで、本発明は、各ユーザが車両を使用する毎にいちいち所望の車内環境に調整する必要が無い車両共有化システム及び車両共有化方法の提供を目的とする。

上記目的を達成するため、第１の発明は、少なくとも１台の車両を多数のユーザで使用可能とする車両共有化システムであって、
各ユーザが設定した車内環境を、各ユーザに対応付けて記憶する車内環境情報記憶手段と、
ユーザから車両の使用の予約を受けて予約スケジュールを生成する予約スケジュール生成手段と、
前記予約スケジュールに基づいて、車両を予約したユーザ（以下、「予約ユーザ」という）に対応した車内環境情報を前記車内環境情報記憶手段から読み出し、該読み出した車内環境情報に基づいて、該予約ユーザが設定した車内環境へと車内環境を変化させる車内環境調整手段とを備えることを特徴とする。

第２の発明は、第１の発明に係る車両共有化システムにおいて、
前記予約スケジュールに基づいて、車両の使用時の認証を行う認証手段を更に備えることを特徴とする。

第３の発明は、第２の発明に係る車両共有化システムにおいて、
前記予約スケジュールは、予約ユーザと、該予約ユーザが予約した車両の使用可能期間（以下、「予約期間」という）とを特定する情報を含み、
前記認証手段は、認証を求めるユーザ（以下、「認証要求ユーザ」という）から該認証要求ユーザのユーザ特定情報を受信し、該受信したユーザ特定情報が、認証要求時の属する予約期間に対応する予約ユーザに係るユーザ特定情報と照合する場合に、前記認証要求ユーザによる車両の使用を許可することを特徴とする。

第４の発明は、第１〜３のうちのいずれかの発明に係る車両共有化システムにおいて、
前記車内環境情報記憶手段は、車両が所定帰還位置に帰還した際の車内環境を記憶することを特徴とする。

第５の発明は、少なくとも１台の車両を多数のユーザで使用可能とする車両共有化方法であって、
車両の装置が、各ユーザが設定した車内環境を表す車内環境情報を、管理サーバーに送信するステップと、
管理サーバーが、車両から送られてくる車内環境情報を、各ユーザに対応付けて記憶するステップと、
管理サーバーが、ユーザから車両の使用の予約を受けて、車両を予約したユーザ（以下、「予約ユーザ」という）と、該予約ユーザが予約した車両の使用可能期間（以下、「予約期間」という）とを特定する予約スケジュールを生成するステップと、
管理サーバーが、前記予約スケジュールに基づいて、予約ユーザに対応した車内環境情報を前記車内環境情報記憶手段から読み出し、該読み出した車内環境情報を、車両に送信するステップと、
車両の装置が、認証を求めるユーザ（以下、「認証要求ユーザ」という）から該認証要求ユーザのユーザ特定情報を受信するステップと、
車両の装置及び／又は管理サーバーが、前記認証要求ユーザのユーザ特定情報と前記予約スケジュールとに基づいて、前記認証要求ユーザが、認証要求時の属する予約期間に対応する予約ユーザであるか否かを判定する認証ステップと、
車両の装置が、管理サーバーから送られてくる車内環境情報を受信する受信ステップと、
前記認証ステップにおいて、前記認証要求ユーザが、認証要求時の属する予約期間に対応する予約ユーザであると判定された場合に、車両の装置が、前記受信ステップで受信した車内環境情報に対応する車内環境を形成するステップとを備えることを特徴とする。

本発明によれば、各ユーザが車両を使用する毎にいちいち所望の車内環境に調整する必要が無い車両共有化システム及び車両共有化方法が得られる。

以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。

図１は、本発明による車両共有化システム１の一実施例の全体イメージを示す図である。車両共有化システム１は、複数の車両Ｙ１，Ｙ２，．．．を、多数のユーザＸ１，Ｘ２，．．．で使用可能とするシステムである。尚、ユーザＸ１，Ｘ２，．．．は、本システムを運営・管理するサービス提供会社（組合等を含む）と本システムの使用に関して契約を結んだ人を指す。従って、ユーザＸ１，Ｘ２，．．．は、新規契約や契約終了等により増減（変化）しうる。尚、ユーザＸ１，Ｘ２，．．．のそれぞれには、認証に必要な固有のユーザコード（ユーザＩＤ）が割り当てられる。

車両共有化システム１は、サービス提供会社が管理するカーシェアリングシステム管理サーバー１０（以下、単に「管理サーバー１０」という）を中心として構成される。管理サーバー１０は、後に詳説する如く、各ユーザＸ１，Ｘ２，．．．からの車両の予約等を受け付ける共に、各ユーザＸ１，Ｘ２，．．．に適合するように車両Ｙ１，Ｙ２，．．．の車内環境を整備する。

車両Ｙ１，Ｙ２，．．．は、サービス提供会社が実質的に管理するが、所有権は当該サービス提供会社以外に帰属してもよい。車両Ｙ１，Ｙ２，．．．は、後述の車載器４０をそれぞれ有する。

図２は、本実施例の車両共有化システム１の主要な機能を示す図である。図２では、代表として１つの車両のみが示されているが、他の車両の構成も同様であってよい。

予約装置３０は、ユーザＸ１，Ｘ２，．．．のそれぞれが独自に所持するものであってよく、例えば携帯電話やパーソナルコンピューターであってよい。予約装置３０は、通信モジュール３２と、入力手段３４とを有する。ユーザＸ１，Ｘ２，．．．は、自身の予約装置３０の入力手段３４を介して、予約の申し込みに必要な情報（予約要求情報）を入力する。入力された予約要求情報は、発信元の予約装置３０を特定するための情報（例えば、電話番号やｅ−ｍａｉｌアドレス）と共に、通信モジュール３２により管理サーバー１０に送信される。予約装置３０は、管理サーバー１０との双方向通信により、予約の調整（変更・修正）や、予約の受付確認や、現在の予約状況の確認等を実現する機能を有してよい。

車両の車載器４０は、通信モジュール４２、制御ＥＣＵ４４、及び、車両デバイス４６を含む。通信モジュール４２は、以下で説明する各種通信を管理サーバー１０との間で行う。また、制御ＥＣＵ４４は、車両デバイス４６に対して以下で説明する各種制御を実行する。尚、制御ＥＣＵ４４は、複数のＥＣＵにより実現されてもよい。車両デバイス４６は、車内環境を形成するデバイス、及び、以下の説明で登場する他のデバイスを含む。ここで、車内環境とは、車室内の環境を指し、特にユーザにより調整・設定が可能な車室内の環境をいう。例えば、車内環境は、運転席シート位置のようなシート位置、ステアリング位置、ドアミラー（アウターミラー）位置、ルームミラー（インナーミラー）位置、エアコン設定位置、シートベルトアンカー位置、カスタマイズ可能なメータやディスプレイ表示の表示方法、カスタマイズ可能な音声案内の出力方法等を含む。尚、車内環境を形成するデバイスとは、車内環境がシート位置である場合には、シート（より正確にはシート位置を調整するアクチュエータ）である。

キー５０は、ユーザによる所持が可能な形態を有し、車両のドアロックをロック・アンロックしたり、車両の動力源（例えばエンジン）を始動させたりするのに必要なキーである。キー５０は、車両Ｙ１，Ｙ２，．．．のそれぞれに対してしか使用できない専用キーであってもよいし、車両Ｙ１，Ｙ２，．．．のいずれに対しても使用できる汎用キーであってもよい。専用キーの場合、キー５０は、好ましくは、予約確定時に、その都度サービス提供会社から郵送等で送付され、車両使用終了時にサービス提供会社に返却するものであってよい。汎用キーの場合、キー５０は、実質的には、所定の認証を経てから使用可能となる。認証については後に説明する。

管理サーバー１０は、予約管理部１２と、通信モジュール１４と、予約スケジュールデータベース（ＤＢ）１８と、車内環境情報データベース（ＤＢ）１６とを含む。通信モジュール１４は、以下で説明する各種通信を車載器４０や予約装置３０との間で行う。予約スケジュールデータベース１８は、予約管理部１２の管理下で、予約スケジュールを記憶する。予約スケジュールは、車両Ｙ１，Ｙ２，．．．の予約状況を表すスケジュールであり、車両を予約したユーザ（以下、「予約ユーザ」ともいう）と、該予約ユーザが予約した車両の使用可能期間（以下、「予約期間」という）とを特定する情報を含む。従って、予約スケジュールからは、いつどの車両を誰（どのユーザ）が使用するかを把握可能である。予約管理部１２は、ユーザＸ１，Ｘ２，．．．から予約要求情報に応じて、予約スケジュールデータベース１８内の予約スケジュールを調整・更新する。車内環境情報データベース１６は、予約管理部１２の管理下で、ユーザＸ１，Ｘ２，．．．のそれぞれ（各ユーザコード）に対応付けて車内環境情報を記憶する。即ち、各ユーザＸ１，Ｘ２，．．．のそれぞれのユーザ特定情報と対応付けて、各ユーザＸ１，Ｘ２，．．．に係る車内環境情報が記憶される。従って、車内環境情報データベース１６からは、特定のユーザを指定することで、当該ユーザの車内環境情報を抽出可能である。

次に、図３及び図４を参照して、車内環境情報データベース１６の構築方法について説明する。ここでは、一例として、車両Ｙ１をユーザＸ１が使用した場合について説明する。

図３は、車内環境情報データベース１６の構築に関連して車両Ｙ１の車載器４０により実行される処理の一例を示すフローチャートである。

ステップ１００では、制御ＥＣＵ４４は、車両Ｙ１のエンジンが停止されたか否かを判定する。車両Ｙ１のエンジンの停止は、イグニッションスイッチからの信号等に基づいて判定されてもよい。車両Ｙ１のエンジンが停止された場合には、ステップ１０２に進み、それ以外の場合、即ち車両Ｙ１のエンジンが作動中の場合には、今回周期の処理はそのまま終了する。尚、車両Ｙ１が電気自動車やハイブリッド車の場合には、エンジン以外の駆動源（モータ）が停止されたか否かを判定してもよい。

ステップ１０２では、制御ＥＣＵ４４は、車両Ｙ１が所定帰還位置（車庫）に位置するか否かを判定する。所定帰還位置は、予約時に決められた帰還位置（車両の返却位置）であってもよい。車両Ｙ１が所定帰還位置に位置するか否かは、ナビゲーション装置の位置情報（ＧＰＳ信号に基づく位置情報）から判定してもよいし、DSRC（Dedicated Short Range Communication；専用狭域通信）等による車庫の通信機（例えばＲＦタグ）との通信結果から判定してもよい。車両Ｙ１が所定帰還位置に位置する場合には、ステップ１０４に進み、それ以外の場合には、今回周期の処理はそのまま終了する。

ステップ１０４では、制御ＥＣＵ４４は、現時点での車両Ｙ１の最新の車内環境情報（例えば現時点のシート位置等）を、管理サーバー１０に送信する。車内環境情報は、車内環境を形成する車両デバイス４６の現在の状態を検出することで生成してもよいし、当該車両デバイス４６を制御する制御ＥＣＵ４４自身が持つ制御情報に基づいて生成してもよい。この際、車内環境情報は、送信元の車両（即ち車両Ｙ１）を特定するための情報（例えば車両ＩＤ）と共に送信されてよく、必ずしも当該車両の今回のユーザ（即ちユーザＸ１）を特定するためのユーザコードと共に送信される必要はない。

図４は、上述の図３の処理に関連して管理サーバー１０側で実行される処理の一例を示すフローチャートである。

ステップ１０６では、管理サーバー１０の通信モジュール１４は、上記のステップ１０４で車載器４０から送信される車内環境情報を受信する。

ステップ１０８では、管理サーバー１０の予約管理部１２は、現在時刻を把握し、予約スケジュールデータベース１８内の予約スケジュールに基づいて、現在車両Ｙ１を使用している使用ユーザ（本例の場合、ユーザＸ１）を特定する。即ち、予約管理部１２は、予約スケジュール中の車両Ｙ１に係る予約ユーザと予約期間の対応関係に基づいて、現在時刻の属する予約期間の予約ユーザを特定し、当該特定した予約ユーザを使用ユーザと看做す。

ステップ１１０では、予約管理部１２は、上記のステップ１０６で得られた車内環境情報に基づいて、車内環境情報データベース１６内における上記のステップ１０８で特定された使用ユーザに係る車内環境情報を登録・更新する。例えば、本例の場合、使用ユーザＸ１に係る車内環境情報が、既に車内環境情報データベース１６内に存在する場合には、車内環境情報データベース１６内に使用ユーザＸ１に係る車内環境情報を上書き（更新）し、使用ユーザＸ１に係る車内環境情報が、車内環境情報データベース１６内に存在しない場合（使用ユーザＸ１が新規会員の場合）、車内環境情報データベース１６内に使用ユーザＸ１に係る車内環境情報を新規登録する。

このようにして、図３及び図４の処理によれば、各ユーザＸ１，Ｘ２，．．．の好みに応じた所望の車内環境に関する情報が車内環境情報データベース１６内に蓄積されていく。尚、エアコン設定位置のような季節や天候に応じて比較的高い頻度で変化しうる車内環境情報については、季節や天候に対応付けて記憶されてもよい。

尚、図３及び図４に示す処理は、車両使用終了時での車内環境情報が自動的に車内環境情報データベース１６内に記憶されるように構成されているが、例えば車両使用開始後の所定時間経過後（若しくは所定距離走行後）の車内環境情報が自動的に車内環境情報データベース１６内に記憶されてもよく、或いは、ユーザから登録指示入力を受けた場合にその際の車内環境情報が車内環境情報データベース１６内に記憶されることとしてもよい。

次に、図５以降を参照して、本実施例による車内環境調整方法について説明する。

図５は、本実施例による車内環境調整方法の一例を示す図であり、車両の車載器４０側及び管理サーバー１０側で実行される処理の一例をそれぞれのフローチャートで示す。図５に示す車内環境調整方法は、キー５０が専用キーである場合に好適である。ここでは、一例として、車両Ｙ１の予約ユーザがユーザＸ１である場合について説明する。

ステップ２００では、車載器４０の制御ＥＣＵ４４は、キー５０により車両Ｙ１のドアロックがアンロックにされたか否かを判定する。車両Ｙ１のドアロックがアンロックにされたか否かは、ドアロック装置からの信号に基づいて判定されてもよい。車両Ｙ１のドアロックがアンロックにされた場合には、ステップ２０２に進み、それ以外の場合には、今回周期の処理は終了する。

ステップ２０２では、車載器４０の制御ＥＣＵ４４は、通信モジュール４２を介して、管理サーバー１０に対して車内環境情報の要求信号を送信する。この際、要求信号は、要求元の車両（本例の場合、車両Ｙ１）を特定するための情報を含む。

ステップ２０４では、管理サーバー１０の通信モジュール１４は、上記ステップ２０２にて車載器４０から送信された要求信号を受信する。

ステップ２０６では、管理サーバー１０の予約管理部１２は、予約スケジュールデータベース１８内から車両Ｙ１に係る予約スケジュールを読み出し、当該読み出した予約スケジュールに基づいて、現時点の予約ユーザ（現時点が属する予約期間に係る予約ユーザであって、本例では、ユーザＸ１）を特定する。

ステップ２０８では、管理サーバー１０の予約管理部１２は、上記ステップ２０６で特定した予約ユーザ（本例では、ユーザＸ１）に係る車内環境情報を、車内環境情報データベース１６から読み出し、当該読み出した車内環境情報を、通信モジュール１４を介して、車載器４０に送信する。

ステップ２１０では、車載器４０の通信モジュール４２は、上記ステップ２０８にて管理サーバー１０から送信された車内環境情報を受信する。

ステップ２１２では、車載器４０の制御ＥＣＵ４４は、上記ステップ２１０で受信した車内環境情報に基づいて、車内環境を形成する車両デバイス４６を制御して、車内環境情報に従った車内環境を形成する。

従って、図５に示す処理によれば、車両Ｙ１の前のユーザがユーザＸ１以外のユーザである場合でも、ユーザＸ１が、予約期間内に車両Ｙ１に乗り込んだ際に、車両Ｙ１の車内環境が、ユーザＸ１が以前に設定した車内環境に自動的に調整される。これにより、ユーザＸ１は、車両Ｙ１の車内環境を手動設定等でいちいち調整する必要が無くなり、利便性が向上する。

図６は、本実施例による車内環境調整方法のその他の一例を示す図であり、図５と同様、車両の車載器４０側及び管理サーバー１０側で実行される処理のその他の一例をそれぞれのフローチャートで示す。図６に示す車内環境調整方法は、キー５０が汎用キーである場合に好適である。同様に、ここでは、一例として、車両Ｙ１の予約ユーザがユーザＸ１である場合について説明する。また、一例として、キー５０が、認証コードを通信でやり取りするスマートキーの類であるものとし、認証コードは、キー５０毎（即ち、ユーザ毎）に異なるものとする。

ステップ３００では、車載器４０の制御ＥＣＵ４４は、ユーザが車両に接近してきたか否かを判定する。ユーザの車両への接近は、ユーザが所持しているはずのキー５０の接近に基づいて判定されてもよい。例えば、制御ＥＣＵ４４は、キー５０と通信モジュール４２との間の双方向通信（認証コードを含む信号のやり取り）を介して、ユーザの車両への接近を検出してよい。例えばキー５０からのドアアンロック要求信号が受信され、ユーザの車両への接近が検出された場合には、ステップ３０２に進み、それ以外の場合には、今回周期の処理は終了する。

ステップ３０２では、車載器４０の制御ＥＣＵ４４は、通信モジュール４２を介して、管理サーバー１０に対して車内環境情報及び予約ユーザ情報の要求信号を送信する。この際、要求信号は、要求元の車両（本例の場合、車両Ｙ１）を特定するための情報を含む。予約ユーザ情報とは、現時点の予約ユーザを特定するための情報である。

ステップ３０４では、管理サーバー１０の通信モジュール１４は、上記ステップ３０２にて車載器４０から送信された要求信号を受信する。

ステップ３０６では、管理サーバー１０の予約管理部１２は、予約スケジュールデータベース１８内から車両Ｙ１に係る予約スケジュールを読み出し、当該読み出した予約スケジュールに基づいて、現時点の予約ユーザ（現時点が属する予約期間に係る予約ユーザであって、本例では、ユーザＸ１）を特定する。

ステップ３０８では、管理サーバー１０の予約管理部１２は、上記ステップ３０６で特定した予約ユーザ（本例では、ユーザＸ１）に係る車内環境情報を、車内環境情報データベース１６から読み出し、当該読み出した車内環境情報を、通信モジュール１４を介して、車載器４０に送信する。この際、当該車内環境情報と共に、現時点の予約ユーザがユーザＸ１であることを特定できる情報（＝予約ユーザ情報）も、車載器４０に送信する。

ステップ３１０では、車載器４０の通信モジュール４２は、上記ステップ３０８にて管理サーバー１０から送信された車内環境情報及び予約ユーザ情報を受信する。

ステップ３１２では、車載器４０の制御ＥＣＵ４４は、上記ステップ３１０で受信した予約ユーザ情報に基づいて、上記ステップ３００で接近が検出されたユーザが、予約ユーザ（本例では、ユーザＸ１）であるか否かを判定する。この判定（認証）は、上記ステップ３００でユーザの接近を検出する際に受信したキー５０からの信号（認証コード）と、上記ステップ３１０で受信した予約ユーザ情報との対応性を評価することで実現されてもよい。例えば、予約ユーザ情報が、ユーザＸ１のキー５０に割り当てられた認証コードを含む場合には、予約ユーザ情報の認証コードと、キー５０からの信号の認証コードとが一致しているか否かを判定すればよい。或いは、車載器４０の制御ＥＣＵ４４のメモリ若しくはその他の記憶装置に、各ユーザＸ１，Ｘ２，．．．の認証情報を記憶・更新する構成であってもよい。認証情報は、ユーザＸ１，Ｘ２，．．．の指紋等の生体情報や、契約時に設定したパスワードやユーザＩＤ等であってもよい。この場合、車載器４０の制御ＥＣＵ４４は、上記ステップ３１０で受信した予約ユーザ情報に基づいて、ユーザＸ１の認証情報（例えば生体情報）を読み出す。ユーザは、車両に設けられた生体情報入力装置（図示せず）を介して生体情報を入力する。そして、制御ＥＣＵ４４は、当該ユーザにより入力された生体情報と、当該読み出した認証情報（生体情報）と比較して、上記ステップ３００で接近が検出されたユーザが、予約ユーザ（本例では、ユーザＸ１）であるか否かを判定する。

本ステップ３１２において、上記ステップ３００で接近が検出されたユーザが、予約ユーザ（本例では、ユーザＸ１）であると判定された場合には、ステップ３１４に進み、それ以外の場合、即ちユーザＸ１以外のユーザの接近が検出されただけの場合には、今回周期の処理は終了する。

ステップ３１４では、車載器４０の制御ＥＣＵ４４は、上記ステップ３１０で受信した車内環境情報に基づいて、車内環境を形成する車両デバイス４６を制御して、車内環境情報に従った車内環境を形成する。また、車載器４０の制御ＥＣＵ４４は、キー５０を介して操作や指示に従って、車両デバイス４６を制御する。例えば、制御ＥＣＵ４４は、キー５０からの指示に従ってドアロックを解除し、キー５０が車室内に存在している間、エンジンの始動を許可する。

従って、図６に示す処理によれば、車両Ｙ１の前のユーザがユーザＸ１以外のユーザである場合でも、ユーザＸ１が、予約期間内に車両Ｙ１に接近した際に、車両Ｙ１の車内環境が、ユーザＸ１が以前に設定した車内環境に自動的に調整される。これにより、ユーザＸ１は、車両Ｙ１の車内環境を手動設定等でいちいち調整する必要が無くなり、利便性が向上する。また、仮に予約期間内にユーザＸ１以外のユーザが車両Ｙ１を使用しようとする場合には、上記ステップ３１２にて認証が成立しないので、予約していないユーザが他のユーザが予約している車両を予約期間中に使用してしまうことを防止することができる。また、上記ステップ３１２での認証は、予約スケジュールデータベース１８内の予約スケジュールを利用して実現されるので、簡易で信頼性の高い認証を実現することができる。

図７は、本実施例による車内環境調整方法のその他の一例を示す図であり、図５と同様、車両の車載器４０側及び管理サーバー１０側で実行される処理のその他の一例をそれぞれのフローチャートで示す。図７に示す車内環境調整方法は、キー５０が専用キーである場合に好適である。また、ここでは、一例として、車両Ｙ１について説明する。

ステップ４００では、管理サーバー１０は、予約スケジュールデータベース１８内から車両Ｙ１に係る予約スケジュールを読み出し、当該読み出した予約スケジュールに基づいて、車両Ｙ１の予約期間の開始時点（予約開始時間）が到来したか否かを判定する。予約開始時間は、予約期間の１０分前といったように、必ずしも正確な予約期間の開始時点である必要はない。予約開始時間が到来した場合には、ステップ４０２に進み、それ以外の場合、今回周期の処理は終了する。

ステップ４０２では、管理サーバー１０の予約管理部１２は、今回到来した予約開始時間に係る予約ユーザ（本例では、ユーザＸ１）を特定する。

ステップ４０４では、管理サーバー１０の予約管理部１２は、上記ステップ４０２で特定した予約ユーザ（本例では、ユーザＸ１）に係る車内環境情報を、車内環境情報データベース１６から読み出し、当該読み出した車内環境情報を、通信モジュール１４を介して、車載器４０に送信する。

ステップ４０６では、車載器４０の通信モジュール４２は、上記ステップ４０４にて管理サーバー１０から送信された車内環境情報を受信する。

ステップ４０８では、車載器４０の制御ＥＣＵ４４は、上記ステップ４０６で受信した車内環境情報に基づいて、車内環境を形成する車両デバイス４６を制御して、車内環境情報に従った車内環境を形成する。

従って、図７に示す処理によれば、ユーザＸ１が、予約期間内に車両Ｙ１を使用しようとした際には、車両Ｙ１の車内環境が、ユーザＸ１が以前に設定した車内環境に自動的に調整されているので、ユーザＸ１は、車両Ｙ１の車内環境を手動設定等でいちいち調整する必要が無くなり、利便性が向上する。

図８は、本実施例による車内環境調整方法のその他の一例を示す図であり、図５と同様、車両の車載器４０側及び管理サーバー１０側で実行される処理のその他の一例をそれぞれのフローチャートで示す。図８に示す車内環境調整方法は、キー５０が汎用キーである場合に好適である。また、ここでは、一例として、車両Ｙ１について説明する。また、一例として、キー５０が、認証コードを通信でやり取りするスマートキーの類であるものとし、認証コードは、キー５０毎（即ち、ユーザ毎）に異なるものとする。

ステップ５００では、管理サーバー１０は、予約スケジュールデータベース１８内から車両Ｙ１に係る予約スケジュールを読み出し、当該読み出した予約スケジュールに基づいて、車両Ｙ１の予約期間の開始時点（予約開始時間）が到来したか否かを判定する。予約開始時間が到来した場合には、ステップ５０２に進み、それ以外の場合、今回周期の処理は終了する。

ステップ５０２では、管理サーバー１０の予約管理部１２は、今回到来した予約開始時間に係る予約ユーザ（本例では、ユーザＸ１）を特定する。

ステップ５０４では、管理サーバー１０の予約管理部１２は、上記ステップ５０２で特定した予約ユーザ（本例では、ユーザＸ１）に係る車内環境情報を、車内環境情報データベース１６から読み出し、当該読み出した車内環境情報を、通信モジュール１４を介して、車載器４０に送信する。この際、予約管理部１２は、通信モジュール１４を介して、当該車内環境情報と共に、予約ユーザがユーザＸ１であることを特定できる情報（＝予約ユーザ情報）も、車載器４０に送信する。

ステップ５０６では、車載器４０の通信モジュール４２は、上記ステップ５０４にて管理サーバー１０から送信された車内環境情報及び予約ユーザ情報を受信する。

ステップ５０８では、車載器４０の制御ＥＣＵ４４は、上述の図６のステップ３００と同様の態様で、ユーザが車両に接近してきたか否かを判定する。ユーザの車両への接近が検出された場合には、ステップ５１０に進む。

ステップ５１０では、車載器４０の制御ＥＣＵ４４は、上記ステップ５０６で受信した予約ユーザ情報に基づいて、上記ステップ５０８で接近が検出されたユーザが、予約ユーザ（本例では、ユーザＸ１）であるか否かを判定する。この判定は、上述の図６のステップ３１２と同様の態様で実現されてもよい。上記ステップ５０８で接近が検出されたユーザが、予約ユーザ（本例では、ユーザＸ１）であると判定された場合には、ステップ５１２に進み、それ以外の場合には、ステップ５０８に戻る。尚、ステップ５０８及び５１０での否定判定による処理の繰り返しは、ステップ５０６にて新たな情報が受信されるまで（即ち時間の経過により予約ユーザが変化するまで）実行されてよい。

ステップ５１２では、車載器４０の制御ＥＣＵ４４は、上記ステップ５０６で受信した車内環境情報に基づいて、車内環境を形成する車両デバイス４６を制御して、車内環境情報に従った車内環境を形成する。また、車載器４０の制御ＥＣＵ４４は、キー５０を介して操作や指示に従って、車両デバイス４６を制御する。例えば、制御ＥＣＵ４４は、キー５０からの指示に従ってドアロックを解除し、キー５０が車室内に存在している間、エンジンの始動を許可する。

従って、図８に示す処理によれば、車両Ｙ１の前のユーザがユーザＸ１以外のユーザである場合でも、ユーザＸ１が、予約期間内に車両Ｙ１に接近した際に、車両Ｙ１の車内環境が、ユーザＸ１が以前に設定した車内環境に自動的に調整される。これにより、ユーザＸ１は、車両Ｙ１の車内環境を手動設定等でいちいち調整する必要が無くなり、利便性が向上する。また、仮に予約期間内にユーザＸ１以外のユーザが車両Ｙ１を使用しようとする場合には、上記ステップ５１０にて認証が否定されるので、予約していないユーザが他のユーザが予約している車両を使用してしまうことを防止することができる。また、上記ステップ５１０での認証は、予約スケジュールデータベース１８内の予約スケジュールを利用して実現されるので、簡易で信頼性の高い認証を実現することができる。

以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

例えば、上述した実施例は、複数の車両Ｙ１，Ｙ２，．．．が共同使用される例であるが、本発明は、一台の車両を複数のユーザが共同使用するタイプのシステムにも適用可能である。

また、上述した実施例では、各ユーザＸ１，Ｘ２，．．．の車内環境情報は、管理サーバー１０側で一元管理され、必要な際に必要な車両に管理サーバー１０側から提供されるので、車両Ｙ１，Ｙ２，．．．のそれぞれの車載器４０は、各ユーザＸ１，Ｘ２，．．．の車内環境情報を記憶するための特別なメモリを必要としない。しかしながら、車両Ｙ１，Ｙ２，．．．のそれぞれの車載器４０が、各ユーザＸ１，Ｘ２，．．．の車内環境情報を記憶するための特別なメモリを有してもよい。この場合、各車両Ｙ１，Ｙ２，．．．のメモリ内の各ユーザＸ１，Ｘ２，．．．の車内環境情報は、定期的な管理サーバー１０との通信や他の車両との通信を介して更新され、常に最新の情報に維持されるのが望ましい。

また、上述した実施例において、各種実行される上述の各種通信は、一部に有線通信を含むといったように通信形態や通信手段は任意であってよい。

本発明による車両共有化システム１の一実施例の全体イメージを示す図である。 本実施例の車両共有化システム１の主要な機能を示す図である。 車内環境情報データベース１６の構築に関連して車両の車載器４０により実現される処理の一例を示すフローチャートである。 図３の処理に関連して管理サーバー１０側で実行される処理の一例を示すフローチャートである。 本実施例による車内環境調整方法の一例を示す図である。 本実施例による車内環境調整方法のその他の一例を示す図である。 本実施例による車内環境調整方法のその他の一例を示す図である。 本実施例による車内環境調整方法のその他の一例を示す図である。

符号の説明

１ 車両共有化システム
１０ 管理サーバー
１２ 予約管理部
１４ 通信モジュール
１６ 車内環境情報データベース
１８ 予約スケジュールデータベース
３０ 予約装置
３２ 通信モジュール
４０ 車載器
４２ 通信モジュール
４４ 制御ＥＣＵ
４６ 車両デバイス
５０ キー

Claims (5)

1. 少なくとも１台の車両を多数のユーザで使用可能とする車両共有化システムであって、
   各ユーザが設定した車内環境を、各ユーザに対応付けて記憶する車内環境情報記憶手段と、
   ユーザから車両の使用の予約を受けて予約スケジュールを生成する予約スケジュール生成手段と、
   前記予約スケジュールに基づいて、車両を予約したユーザ（以下、「予約ユーザ」という）に対応した車内環境情報を前記車内環境情報記憶手段から読み出し、該読み出した車内環境情報に基づいて、該予約ユーザが設定した車内環境へと車内環境を変化させる車内環境調整手段とを備えることを特徴とする、車両共有化システム。
2. 前記予約スケジュールに基づいて、車両の使用時の認証を行う認証手段を更に備える、請求項１に記載の車両共有化システム。
3. 前記予約スケジュールは、予約ユーザと、該予約ユーザが予約した車両の使用可能期間（以下、「予約期間」という）とを特定する情報を含み、
   前記認証手段は、認証を求めるユーザ（以下、「認証要求ユーザ」という）から該認証要求ユーザのユーザ特定情報を受信し、該受信したユーザ特定情報が、認証要求時の属する予約期間に対応する予約ユーザに係るユーザ特定情報と照合する場合に、前記認証要求ユーザによる車両の使用を許可する、請求項２に記載の車両共有化システム。
4. 前記車内環境情報記憶手段は、車両が所定帰還位置に帰還した際の車内環境を記憶する、請求項１〜３のうちのいずれか１項に記載の車両共有化システム。
5. 少なくとも１台の車両を多数のユーザで使用可能とする車両共有化方法であって、
   車両の装置が、各ユーザが設定した車内環境を表す車内環境情報を、管理サーバーに送信するステップと、
   管理サーバーが、車両から送られてくる車内環境情報を、各ユーザに対応付けて記憶するステップと、
   管理サーバーが、ユーザから車両の使用の予約を受けて、車両を予約したユーザ（以下、「予約ユーザ」という）と、該予約ユーザが予約した車両の使用可能期間（以下、「予約期間」という）とを特定する予約スケジュールを生成するステップと、
   管理サーバーが、前記予約スケジュールに基づいて、予約ユーザに対応した車内環境情報を前記車内環境情報記憶手段から読み出し、該読み出した車内環境情報を、車両に送信するステップと、
   車両の装置が、認証を求めるユーザ（以下、「認証要求ユーザ」という）から該認証要求ユーザのユーザ特定情報を受信するステップと、
   車両の装置及び／又は管理サーバーが、前記認証要求ユーザのユーザ特定情報と前記予約スケジュールとに基づいて、前記認証要求ユーザが、認証要求時の属する予約期間に対応する予約ユーザであるか否かを判定する認証ステップと、
   車両の装置が、管理サーバーから送られてくる車内環境情報を受信する受信ステップと、
   前記認証ステップにおいて、前記認証要求ユーザが、認証要求時の属する予約期間に対応する予約ユーザであると判定された場合に、車両の装置が、前記受信ステップで受信した車内環境情報に対応する車内環境を形成するステップとを備えることを特徴とする、車両共有化方法。

Images