JP7085003B2 - 車両管理システム、車載システム及び車両管理方法 - Google Patents

Description

本発明は、車両の状態、特に、車内の臭いレベルを含む車両の状態を管理する車両管理システム、車載システム及び車両管理方法に関する。

専用のアプリケーションプログラムがインストールされたスマートフォンを用いて、車両のオンボードコンピュータから出力された当該車両の診断データを、通信ネットワークを介して遠隔診断センタに送信する車両遠隔診断システムが知られている（特許文献１参照）。

この車両遠隔診断システムでは、不具合箇所を示すコード（ＤＴＣ）が診断データに含まれていない場合、当該アプリケーションプログラムが、異臭などが発生しているか否かをユーザに問い合わせ、ユーザによって入力された異臭などの有無が遠隔診断センタに送信される。

米国特許出願公開第２０１３／０３０４２７８号明細書

ところで、不特定多数のユーザに同一の車両が順次提供されるタクシー及びカーシェアリングなどでは、車両の提供時には、異臭などが発生しておらず、車内の臭いレベルが所定基準を満たしていることが望ましい。

しかしながら、特許文献１に記載された車両遠隔診断システムは、このような課題の解決方法については、何ら開示も示唆もしていない。

本発明は、このような状況に鑑みてなされたものであり、車内の臭いレベルが所定基準を満たす車両をユーザに提供し得る車両管理システム、車載システム及び車両管理方法の提供を目的とする。

本発明の一態様に係わる車両管理システムは、車両の車内に設けられた臭いセンサから出力された車内臭データを取得し、当該車内臭データに基づいて車内臭の種別を判定する。車両管理システムは、当該車内臭の種別と対応付けられる臭いレベルを車内臭データから取得し、当該臭いレベルが所定基準を満たすか否かを判定する。

本発明の一態様に係わる車両管理システムは、車両の車内に設けられた臭いセンサから出力された車内臭データを取得し、当該車内臭データに基づく臭いレベルが所定基準を満たすか否かを判定する。車両管理システムは、当該臭いレベルが所定基準を満たさないと判定された場合、当該臭いレベルに対応した車両の提供オプションを選択し、当該提供オプションと対応付けられた通知または車両制御を実行する。

図１は、車両管理システム１０の全体概略構成図である。 図２は、車両５０Ａ～車両５０Ｃの機能ブロック構成図である。 図３は、データベースサーバ１００の機能ブロック構成図である。 図４は、車両管理サーバ２００の機能ブロック構成図である。 図５は、車両管理システム１０による配車概略シーケンスを示す図である。 図６は、車内臭の種別判定フローを示す図である。 図７は、臭いレベルの判定フローを示す図である。 図８は、提供オプションの選択フローを示す図である。 図９は、車内臭データベース１４０（車内臭種別データベース）の構成例を示す図である。 図１０は、車内臭データベース１４０（車両別臭いレベルデータベース）の構成例を示す図である。 図１１は、ユーザ情報データベース１５０の構成例を示す図である。 図１２は、ユーザと対応付けられた通信端末４０に表示される配車内容のメッセージ例（その１）を示す図である。 図１３は、ユーザと対応付けられた通信端末４０に表示される配車内容のメッセージ例（その２）を示す図である。

以下、実施形態を図面に基づいて説明する。なお、同一の機能や構成には、同一または類似の符号を付して、その説明を適宜省略する。

（車両管理システムの全体構成）
図１は、本実施形態に係る車両管理システム１０の全体概略構成図である。図１に示すように、車両管理システム１０は、ネットワーククラウド２０上に設けられたデータベースサーバ１００及び車両管理サーバ２００を含む。

ネットワーククラウド２０は、有線通信または無線通信によって情報伝送を可能にする通信ネットワークである。ネットワーククラウド２０は、典型的にはインターネットを含み、インターネット上において提供される各種の情報提供サービス（気象、交通渋滞など）、ストレージサービス、及びアプリケーションサービスなどを含む。

なお、データベースサーバ１００及び車両管理サーバ２００の機能の一部または全部は、ネットワーククラウド２０上で提供される当該サービスによって、仮想的に提供されても構わない。

車両管理システム１０は、車両５０Ａ、車両５０Ｂ及び車両５０Ｃを管理する。なお、車両管理システム１０が管理する車両の台数は例示であり、実際には、さらに多くの車両が管理される。

本実施形態では、車両５０Ａ～車両５０Ｃは、ユーザ３１及びユーザ３２（ユーザ数は、ユーザ３１及びユーザ３２に限定されない）によって利用される営業用自動車、具体的には、タクシーである。特に、本実施形態では、車両５０Ａ～車両５０Ｃは、ドライバーを必要としないレベル４以上の自動運転機能を有する。但し、車両５０Ａ～車両５０Ｃは、必ずしもこのような自動運転機能を有していなくても構わない。

通信端末４０は、ユーザ３１（またはユーザ３２）が使用する携帯型の端末装置であり、典型的には、無線通信機能を有するスマートフォンまたはタブレット端末などである。通信端末４０は、ネットワーククラウド２０を介して車両管理サーバ２００などと通信を実行する。

データベースサーバ１００は、車両及びユーザに関する情報を保持する。具体的には、データベースサーバ１００は、車両５０Ａ～車両５０Ｃの状態、特に、本実施形態では、車内臭に関する情報を保持する。また、データベースサーバ１００は、ユーザ３１及びユーザ３２の属性、特に、車内臭に対する耐性などに関する情報（ユーザ情報）を保持する。

車両管理サーバ２００は、車両の状態を管理するとともに、車両に対する各種制御を実行する。具体的には、車両管理サーバ２００は、車両５０Ａ～車両５０Ｃの車内の臭いレベルを管理し、車両に搭載されている装備（パワーウィンドウ、空調システムなど）、または自動運転機能に対する制御を実行する。

本実施形態では、データベースサーバ１００及び車両管理サーバ２００によって、車両５０Ａ～車両５０Ｃの状態を管理する車両管理システムが構成される。車両管理システムは、車両５０Ａ～車両５０Ｃと通信を行う通信インタフェースを含んでおり、当該車両とは分離されたサーバ、具体的には、サーバコンピュータである。

（車両及び車両管理システムの機能ブロック構成）
次に、車両５０Ａ～車両５０Ｃ、及び車両管理システム１０の機能ブロック構成について説明する。

（１）車両５０Ａ～車両５０Ｃ
図２は、車両５０Ａ～車両５０Ｃの機能ブロック構成図である。具体的には、図２は、車内臭データの取得、及び車両装備の制御に関連する機能ブロックのみを示す。

より具体的には、図２は、プロセッサとメモリとを少なくとも有し、車両に搭載される車載システムを示しており、車載システムは、車両５０Ａの車内臭を検知する臭いセンサ５１と、サーバ（データベースサーバ１００または車両管理サーバ２００）と通信を行う無線通信インタフェースとを有する。

図２に示すように、車両５０Ａ（車両５０Ｂ及び車両５０Ｃも同様、以下同）は、臭いセンサ５１、車両装備５３、通信部５５、装備制御部５７及び送信制御部５９を備える。

臭いセンサ５１は、車両５０Ａの車内の臭い（車内臭）を検出する。具体的には、臭いセンサ５１は、車両５０Ａの客室内または荷室内に設けられる。また、臭いセンサ５１は、客室内のシートポジション毎に設けられてもよい。

臭いセンサ５１の形式は特に限定されず、例えば、半導体式または水晶振動子式を用いることができる。臭いセンサ５１は、臭気センサと呼ばれてもよく、車内の空気中を漂ってきて嗅覚を刺激する臭い成分を検出し、臭い成分毎に数値化されたデータ（車内臭データ）を出力する。つまり、臭いセンサ５１から出力される車内臭データには、各臭い成分の比率と、各臭い成分の強さとが含まれる。

車両装備５３は、車両５０Ａに搭載される各種装備を含む。特に、本実施形態では、車両装備５３には、車両５０Ａの自動運転に関する装備、具体的には、アクセル、ブレーキ、ステアリング関連装備、バッテリなどの電源が含まれる。当該電源は、臭いセンサ５１、車両装備５３、通信部５５、装備制御部５７及び送信制御部５９に含まれる各電子部品に電力を供給する。

また、車両装備５３は、車内の乗客の乗降を検知するためのカメラ、及び座席の着座センサを含む。

また、本実施形態では、車両装備５３には、車内臭の低減に用い得る全ての装備が含まれる。具体的には、車両装備５３には、パワーウィンドウなど、電動で開閉可能なウィンドウ、ドア及びテールゲートが含まれる。また、車両装備５３には、空調システム（ファン、ヒータ、温湿度計及びエアコンディショナ）及び空気清浄機が含まれる。さらに、車両装備５３には、紫外線（ＵＶ）ランプが含まれてもよい。

通信部５５は、車両５０Ａ近傍のアクセスポイント（無線基地局など）と無線信号を送受信し、当該アクセスポイントを経由して各種データを送受信する。

通信部５５は、通信モジュールとして車両５０Ａに備えられてもよいし、スマートフォンなどの通信端末を用いて実現してもよい。典型的には、４Ｇ（ＬＴＥ）または５Ｇなどの移動通信ネットワークの利用が挙げられる。なお、他の無線通信方式（無線ＬＡＮなど）であっても構わない。

装備制御部５７は、車両装備５３を制御する。具体的には、装備制御部５７は、車両管理システム１０（車両管理サーバ２００）からの指示に基づいて、車両装備５３、例えば、ウィンドウの開閉、空調システムの作動を制御する。

また、装備制御部５７は、臭いセンサ５１を制御することによって得られた車内臭データに基づいて車両管理サーバ２００から送信されたコマンド（第２のコマンド）を受信し、空調システム及びウィンドウの開閉の少なくとも何れかを制御することができる。

さらに、装備制御部５７は、車両管理システム１０（車両管理サーバ２００）からの指示に基づいて、自動運転に関する装備（アクセル、ブレーキ、ステアリング関連装備）を制御する。

送信制御部５９は、車内臭データの送信を制御する。具体的には、送信制御部５９は、車両管理サーバ２００から送信されたコマンド（第１のコマンド）を受信し、臭いセンサ５１を制御する。送信制御部５９は、臭いセンサ５１を制御することによって得られた車内臭データを、無線通信インタフェースを経由して車両管理サーバ２００に送信することができる。

（２）データベースサーバ１００
図３は、データベースサーバ１００の機能ブロック構成図である。図３に示すように、データベースサーバ１００は、車内臭データ取得部１１０、車両状態取得部１２０、車内臭種別判定部１３０、車内臭データベース１４０及びユーザ情報データベース１５０を備える。

データベースサーバ１００は、プロセッサ、メモリ、入力デバイス、ディスプレイ（必須ではない）及び通信インタフェース（通信ＩＦ）を備える汎用のサーバコンピュータ上においてプログラム（ソフトウェア）を実行することによって実現される。

車内臭データ取得部１１０は、車両５０Ａの車内に設けられた臭いセンサ５１から出力された車内臭データを取得する。

具体的には、車内臭データ取得部１１０は、車両５０Ａからネットワーククラウド２０を介して送信された車内臭データを取得する。つまり、車内臭データ取得部１１０は、通信インタフェースを経由して車両５０Ａから車内臭データを取得する。

車内臭データ取得部１１０によって取得された車内臭データは、車内臭データベース１４０（車両別臭いレベルデータベース）の構成に用いられる。

また、車内臭データ取得部１１０は、車両５０Ａに対する利用の予約情報が存在することを検知した場合、車両５０Ａに対して車内臭データを要求し、当該車内臭データを取得することができる。

車両状態取得部１２０は、車両５０Ａの状態を取得する。具体的には、車両状態取得部１２０は、車両装備５３の状態を取得する。より具体的には、車両状態取得部１２０は、ウィンドウなどの開閉状態、車内の温湿度、及び空調システムの状態（例えば、空調システムのファン作動のＯＮ／ＯＦＦデータ、設定温度、外気導入の有無、空気清浄機の作動のＯＮ／ＯＦＦデータ）などを取得する。

また、車両状態取得部１２０は、車両５０Ａの現在位置及び走行ルートなどを取得することもできる。

車内臭種別判定部１３０は、車両５０Ａの車内臭の種別を判定する。具体的には、車内臭種別判定部１３０は、車内臭データ取得部１１０によって取得された車内臭データに基づいて、車両５０Ａの車内において発生している車内臭の種別を判定する。

車内臭の種別は、臭いセンサ５１を用いて検出可能な臭いであれば、特に限定されないが、車両５０Ａがタクシーであり、不特定多数のユーザによって利用されることを考慮すると、主な車内臭としては、生花、たばこ（車内での喫煙だけでなく、喫煙者（スモーカー）の乗車に起因する車内臭も含む）、吐しゃ物、汗、ペットに関する臭いなどが挙げられる。

車内臭データベース１４０は、車内臭データに基づいて構成されるデータベースである。本実施形態では、車内臭データベース１４０は、車内臭種別データベースと、車両別臭いレベルデータベースとによって構成される。

図９は、車内臭データベース１４０（車内臭種別データベース）の構成例を示す。また、図１０は、車内臭データベース１４０（車両別臭いレベルデータベース）の構成例を示す。

図９に示すように、車内臭種別データベースは、車内臭の種別と対応付けられた車内臭データ（臭い成分）の比率によって構成される。例えば、「生花」であれば、成分ａ＝６０（％），成分ｂ＝２０（％），成分ｃ＝２０（％）と設定されている。

例えば、ａ，ｂ，ｃは、硫化水素、酢酸、メチルメルカブタンであるが、これに限定されるものではなく、車内臭として乗客に嫌悪感をもたらす成分であり、複数の車内臭の種別を判定するために十分な成分であればよい。

他の車内臭の種別（たばこ、吐しゃ物）についても同様に、成分毎の数値（％）が設定されている。また、「混合１」のように、複数種別（例えば、「生花」と「たばこ」）の車内臭が混合した場合における成分毎の数値（％）が設定されてもよい。

また、車内臭種別データベースを構成する各数値は、車内臭データ取得部１１０によって取得された車内臭データに基づいて適宜更新されてもよい。

図１０に示すように、車両別臭いレベルデータベースは、臭いセンサ５１から出力された車内臭データに基づく車内臭の種別（生花（Ｘ）、たばこ（Ｙ）、吐しゃ物（Ｚ））と対応付けられる臭いレベル、当該種別の臭いレベルの合計値、及び車両装備５３の状態によって構成される。

また、車両別臭いレベルデータベースは、異なる時刻（ｔ１，ｔ２）に臭いセンサ５１から出力された車内臭データに基づく臭いレベルと、当該時刻における車両装備５３の状態を含むことができる。

ユーザ情報データベース１５０は、車両５０Ａ～車両５０Ｃ、つまり、タクシーを利用するユーザ３１及びユーザ３２の情報によって構成されるデータベースである。

図１１は、ユーザ情報データベース１５０の構成例を示す。図１１に示すように、ユーザ情報データベース１５０は、ユーザ毎の臭いに関する情報によって構成される。ユーザ３１は、図中の「ユーザＡＡＡ」と対応し、ユーザ３２は、図中の「ユーザＢＢＢ」と対応する。

具体的には、ユーザ情報データベース１５０は、ユーザが「好きな臭い」、「嫌いな臭い」、臭いに対する「敏感性」、及び「閾値設定レベル」によって構成される。閾値設定レベルは、当該ユーザが許容できる臭いレベルの決定に用いられる。

ユーザ情報データベース１５０を構成する情報は、当該ユーザが事前に登録してもよいし、タクシー利用時（配車要求時）に当該ユーザが通信端末４０を用いて登録してもよい。なお、ここでいう配車とは、当該ユーザが車両（車両５０Ａ～車両５０Ｃの何れか）を利用する予定の時間及び場所に車両を準備することである。つまり、配車によって当該ユーザが車両を利用可能な状態に置かれる。

（３）車両管理サーバ２００
図４は、車両管理サーバ２００の機能ブロック構成図である。図４に示すように、車両管理サーバ２００は、臭いレベル判定部２１０、車両制御部２２０、ユーザ情報取得部２３０、車両情報取得部２４０、オプション選択部２５０、予約情報取得部２５５及びオプション実行部２６０を備える。

車両管理サーバ２００は、プロセッサ、メモリ、入力デバイス、ディスプレイ（必須ではない）及び通信インタフェース（通信ＩＦ）を備える汎用のサーバコンピュータ上においてプログラム（ソフトウェア）を実行することによって実現される。

臭いレベル判定部２１０は、車内臭データに基づく臭いレベルが所定基準を満たすか否かを判定する。

具体的には、臭いレベル判定部２１０は、車内臭の種別と対応付けられる臭いレベルを車内臭データから取得する。さらに、臭いレベル判定部２１０は、取得した臭いレベルが所定基準を満たすか否かを判定する。

より具体的には、臭いレベル判定部２１０は、図１０に示したように、車両毎に、車内臭の種別と対応付けられる臭いレベル、及び当該種別の臭いレベルの合計値を取得する。

臭いレベルは、当該種別の車内臭の強さを示す値である。臭いレベルは、絶対値でもよいし、１００を最大値としたインデックス（指数）でもよい。

本実施形態では、臭いレベル判定部２１０は、図１０に示すように、第１時刻（ｔ１）における臭いレベル（第１臭いレベル）と、第１時刻よりも後の第２時刻（ｔ２）における臭いレベル（第２臭いレベル）とを取得できる。

臭いレベル判定部２１０は、ｔ１における臭いレベルの合計値（図中の「８０」）と、ｔ２における臭いレベルの合計値（図中の「５０」）との変化に基づいて推定される臭いレベル（例えば、ｔ２よりも後の配車時（ｔ３）における臭いレベルの合計値）が所定基準を満たすか否かを判定する。

なお、所定基準は、臭いレベルの合計値に対して設定されてもよいし、車内臭の種別毎に対して設定されてもよい。また、後述するように、ユーザ情報または車両情報に基づいて動的に変化してもよい。

臭いレベル判定部２１０は、車両制御部２２０によって車両５０Ａが制御された後に取得した臭いレベルが所定基準を満たすか否かを判定することができる。つまり、臭いレベル判定部２１０は、車両制御部２２０によって、臭いレベルの低減と対応付けられた制御が車両５０Ａに対して実行された後に、臭いレベルが所定基準を満たすか否かを判定することができる。

また、臭いレベル判定部２１０は、臭いレベルが、ユーザ情報に基づく所定基準を満たすか否かを判定することもできる。具体的には、臭いレベル判定部２１０は、図１１に示したユーザ情報データベース１５０の内容に基づいて、デフォルトで設定されている所定基準を変更することができる。

例えば、図１１に示すように、臭いに対する「敏感性」が高く、閾値設定レベルが低い場合（図中の「４０」）、デフォルトの所定基準を、閾値設定レベルの数値に応じて引き上げる（つまり、許容できる臭いレベルを引き上げる）。

さらに、臭いレベル判定部２１０は、臭いレベルが、車両情報に基づく所定基準を満たすか否かを判定することもできる。具体的には、臭いレベル判定部２１０は、車両５０Ａの種別に基づいて、デフォルトで設定されている所定基準を変更することができる。

例えば、臭いレベル判定部２１０は、車両５０Ａがミニバン型か、またはセダン型かに応じて、当該所定基準を変更する。車両（車内空間）のサイズに応じて、許容可能な臭いレベルが異なり得るためである。なお、臭いレベル判定部２１０は、車両サイズ以外に、車両装備５３の種別、または車両５０Ａの環境（温湿度など）に応じて当該所定基準を変更してもよい。

車両制御部２２０は、車両５０Ａを制御する制御データを車両５０Ａに送信する。特に、本実施形態では、車両制御部２２０は、車内臭の種別と対応付けられる臭いレベル（以下、単に臭いレベル）が所定基準を満たさない場合、当該臭いレベルの低減と対応付けられた制御内容に基づいて、車両５０Ａを制御する制御データを車両５０Ａに送信する。

当該制御内容としては、車内臭の低減を目的とした車両装備５３に対する制御が挙げられる。例えば、ウィンドウの開放、空調システムのファン作動または温度調整、空気清浄機の作動など、空気を入れ替えるための制御または空気を清浄する制御である。なお、制御内容の詳細については、さらに後述する。

また、当該制御内容には、ウィンドウを開けた状態での一定時間の走行などが含まれてもよい。さらに、ウィンドウを開けた状態での臭いレベルと、ウィンドウを閉めた状態での臭いレベルとの比較ができるような制御内容が設定されてもよい。

つまり、制御データは、車両５０Ａの空調システム及びウィンドウの開閉の少なくとも何れかを制御するためのデータである。

なお、車両制御部２２０は、臭いレベルの低減と対応付けられた制御内容とは別に、車両５０Ａのタクシースタンド（タクシー乗り場、図１参照）への配車に必要となる制御内容に基づく制御データを車両５０Ａに送信することもできる。

ユーザ情報取得部２３０は、車両５０Ａ～車両５０Ｃ、つまり、タクシーを利用するユーザ（ユーザ３１またはユーザ３２）のユーザ情報を取得する。具体的には、ユーザ情報取得部２３０は、当該ユーザの車内臭に対する耐性を含むユーザ情報を取得する。

図１１に示したように、ユーザ情報データベース１５０は、ユーザ毎の臭いに関する情報によって構成される。ユーザ情報取得部２３０は、ユーザ情報データベース１５０に含まれる当該ユーザの情報を取得する。

車両情報取得部２４０は、車両５０Ａの種別及び環境の少なくとも何れかを含む車両情報を取得する。具体的には、車両情報取得部２４０は、車両５０Ａの種別（ミニバン型、セダン型など）を取得する。車両５０Ａの種別は、車両管理サーバ２００内に予め保持されていてもよいし、必要に応じてネットワーククラウド２０を介して外部から取得してもよい。

また、車両情報取得部２４０は、車両５０Ａの環境として、車両５０Ａの車外の温湿度、車両５０Ａの車内の温湿度、天候などの情報を取得する。当該情報は、ネットワーククラウド２０を介して外部から取得してもよいし、車両５０Ａの車内の温湿度などについては、データベースサーバ１００の車両状態取得部１２０を介して取得してもよい。

オプション選択部２５０は、臭いレベルが所定基準を満たさないと判定された場合、当該臭いレベルに対応した車両の提供オプションを選択する。

具体的には、オプション選択部２５０は、車両５０Ａを他の車両（例えば、車両５０Ｂ）に代替する提供オプションを選択することができる。

このような提供オプションは、特に、車両装備５３の制御のみでは、臭いレベルが所定基準を満たせない場合と判断された場合に選択される。オプション選択部２５０は、例えば、車内臭の種別に基づいて、車両５０Ａを他の車両に代替する提供オプションを選択することができる。

また、提供オプションは、次のように表現されてもよい。具体的には、車両５０Ａは、将来の利用が所定条件に基づいて予約されており、提供オプションは、当該所定条件のうち少なくとも一部を変更した条件である。或いは、提供オプションは、当該所定条件のうち、車両５０Ａ（を他の車両に変更）、利用料金または配車予定時刻の何れかを変更した条件である。

また、オプション選択部２５０は、車両５０Ａの提供料金を減額する提供オプションを選択することができる。例えば、オプション選択部２５０は、車両５０Ａのデフォルトの提供料金が３００円／ｋｍである場合、車両５０Ａの車内に残存する臭いレベルに応じて、当該提供料金を減額する。

このような提供オプションは、特に、車両装備５３の制御によって臭いレベルを一定レベル以下に低減できる場合、或いは当該ユーザが、残存する車内臭（例えば、たばこ）に対する耐性が高い場合に選択される。

予約情報取得部２５５は、車両５０Ａ（～車両５０Ｃ）の利用の予約情報を取得する。具体的には、予約情報取得部２５５は、車両５０Ａの利用内容（利用開始時刻、人数、目的地など）を示す予約情報を通信端末４０から取得する。

オプション実行部２６０は、オプション選択部２５０によって選択された提供オプションと対応付けられた通知または車両制御を実行する。具体的には、オプション実行部２６０は、提供オプションの内容を当該ユーザと対応付けられた通信端末に通知する。

図１２及び図１３は、ユーザと対応付けられた通信端末４０に表示される配車内容のメッセージ例を示す。オプション実行部２６０は、選択された車両の提供オプションに基づいて、当該メッセージを表示させる配車内容のデータを通信端末４０に送信する。

配車内容としては、例えば、所定場所に車両が到着する予定時刻（配車予定時刻）、車内臭に関するデータ（例えば、種別、臭いレベル）、車内の臭いレベル低減のための制御状況、提供料金、予約時の内容からの変更に関する情報（例えば、提供料金の変更、配車車両の変更など）が挙げられる。また、配車予定時刻は、車両の利用開始時刻ということもできる。

また、オプション実行部２６０は、他の車両に代替する提供オプションが選択された場合、当該他の車両を所定場所（タクシースタンド）に向かわせる車両制御を実行することができる。具体的には、オプション実行部２６０は、車両制御部２２０に対して、当該他の車両（例えば、車両５０Ｂ）のタクシースタンドへの配車を指示する。

さらに、オプション実行部２６０は、他の車両に代替する提供オプションが選択された場合、臭いレベルが所定基準を満たさないと判定された車両５０Ａの清掃を所定宛先（例えば、清掃業者）に対して指示する。具体的には、オプション実行部２６０は、所定宛先と対応付けられている電子メールアドレス、電話番号などに対して、メッセージ（テキストまたは音声）を送信する。

（車両管理システムの動作）
次に、車両管理システム１０の動作について説明する。具体的には、車両管理システム１０による配車概略シーケンス、車内臭の種別判定フロー、臭いレベルの判定フロー、及び提供オプションの選択フローについて説明する。

（１）配車概略シーケンス
図５は、車両管理システム１０による配車概略シーケンスを示す。ここでは、車両５０Ａがユーザ３１に対して配車予定であり、当該配車前にもタクシーとして使用されていたものとする。

車両管理システム１０（データベースサーバ１００）は、車両５０Ａから車内臭データを取得する（Ｓ１０）。具体的には、データベースサーバ１００は、車両５０Ａの車内に設けられた臭いセンサ５１から出力される車内臭データを取得する。

例えば、Ｓ１０の処理では、車両５０Ａが、車両５０Ａから乗客が降車をしたことを検知して、車両管理システム１０に対して車内臭データを送信してもよい。

或いは、車両管理システム１０が、車両５０Ａが所定条件を満たすことを検知したときに、車両５０Ａに対して、車内臭データを送信するように要求する車内臭要求指示を送信し、車内臭要求指示を受信した車両５０Ａが臭いセンサ５１から取得した車内臭データを車両管理システム１０に送信するように構成してもよい。

また、所定条件とは、例えば、車両管理システム１０が車両５０Ａから取得した情報に基づいて、前の乗客が降車し、かつ、次の乗客の配車予約がされている状態である場合である。

データベースサーバ１００は、所得した車内臭データに基づいて、車内臭の種別を判定する（Ｓ１５）。車内臭の種別判定の詳細については、後述する。

データベースサーバ１００は、判定した車内臭種別、及び車内臭データに基づく臭いレベルを車両管理サーバ２００に送信する（Ｓ２０）。

さらに、データベースサーバ１００は、車両５０Ａの状態、具体的には、ウィンドウなどの開閉状態、車内の温湿度、及び空調システムの状態など、車両状態を示す情報を車両５０Ａから取得する（Ｓ２５）。データベースサーバ１００は、車両状態を示す当該情報を車両管理サーバ２００に送信する（Ｓ３０）。

また、車両管理サーバ２００は、ユーザ３１が使用する通信端末４０からの配車要求を受信する（Ｓ４０）。

なお、Ｓ１０～Ｓ４０の動作は、必ずしも図５に示したようなシーケンスに沿っていなくても構わない。例えば、通信端末４０からの配車要求（Ｓ４０）は、車内臭データの取得（Ｓ１０）前に生じても構わない。

車両管理サーバ２００は、車内臭種別、当該車内臭の種別と対応付けられる臭いレベル、及び車両状態に基づいて、臭いレベルを判定する（Ｓ５０）。具体的には、車両管理サーバ２００は、取得した臭いレベルが所定基準を満たすか否かを判定する。臭いレベル判定の詳細については、後述する。

車両管理サーバ２００は、臭いレベルの判定結果に応じた提供オプションを選択する（Ｓ６０）。具体的には、車両管理サーバ２００は、車両５０Ａを他の車両（ここでは、車両５０Ｂ）に代替する提供オプション、または車両５０Ａの提供料金を減額する提供オプションを選択することができる。提供オプション選択の詳細については、後述する。

車両管理サーバ２００は、選択した提供オプションに基づいて、配車内容を示すメッセージを通信端末４０に送信する（Ｓ７０）。

また、車両管理サーバ２００は、車両５０Ａを選択した場合、車両５０Ａに対して、タクシースタンドへの配車を指示する（Ｓ８０）。車両５０Ａは、当該指示に基づいて、タクシースタンド、つまり、ユーザ３１が使用する通信端末４０の近傍まで移動する（Ｓ９０）。

一方、車両管理サーバ２００は、車両５０Ａを車両５０Ｂに代替する提供オプションを選択した場合、車両５０Ｂに対して、タクシースタンドへの配車を指示する（Ｓ８５）。車両５０Ｂは、当該指示に基づいて、通信端末４０の近傍まで移動する（Ｓ９５）。

（２）車内臭の種別判定フロー
図６は、車内臭の種別判定フローを示す。図６に示すように、車両管理システム１０（データベースサーバ１００）は、車両５０Ａから車内臭データを取得する（Ｓ１１０）。

データベースサーバ１００は、取得した車内臭データに基づいて、車内臭データベース１４０を参照し、車内臭の種別を判定する（Ｓ１２０）。

具体的には、データベースサーバ１００は、図９に示した車内臭種別データベースに基づいて、車内臭の種別を判定する。上述したように、車内臭種別データベースは、車内臭の種別と対応付けられた車内臭データ（臭い成分）の比率によって構成される。

データベースサーバ１００は、臭いセンサ５１から出力された各臭い成分の数値（強さ）に基づいて各臭い成分の比率を特定する。データベースサーバ１００は、特定した各臭い成分の比率（％）に基づいて車内臭の種別を判定する。

（３）臭いレベルの判定フロー
図７は、臭いレベルの判定フローを示す。図７に示すように、車両管理システム１０（車両管理サーバ２００）は、車両５０Ａの車両情報を取得する（Ｓ２１０）。具体的には、車両管理サーバ２００は、車両５０Ａの種別、及び車両５０Ａの環境（車内外の温湿度など）を取得する。

なお、上述したように、車両情報の一部は、ネットワーククラウド２０を介して外部から取得したり、車両５０Ａの車内の温湿度などについては、データベースサーバ１００の車両状態取得部１２０を介して取得したりすることができるが、図５の配車概略シーケンスには、このような車両情報の取得に関する詳細シーケンスについては図示されていないことに留意されたい（以下同）。

車両管理サーバ２００は、Ｓ２１０において車両情報を取得した車両について、配車予約の有無を確認する（Ｓ２２０）。

具体的には、車両管理サーバ２００は、ユーザ３１が使用する通信端末４０から、タクシースタンドへの配車要求を受信して、配車要求に含まれる配車時刻、配車場所及びユーザを含む乗客に関する情報と、配車する車両、配車する車両の走行ルートを含む運行計画に関する情報を関連付けて配車予約情報としてメモリに記憶しておき、当該配車予約情報に基づいて、車両の配車予約を確認する。

なお、通信端末４０からの当該配車要求の送信は、電子メール形式でもよいし、通信端末４０にインストールされた専用のアプリケーションを利用する形式でもよい。

車両管理サーバ２００は、通信端末４０からの配車要求に基づいて、通信端末４０と対応付けられているユーザ３１のユーザ情報を取得する（Ｓ２３０）。具体的には、車両管理サーバ２００は、図１１に示したユーザ情報データベース１５０を参照し、ユーザ３１（「ユーザＡＡＡ」）のユーザ情報（ユーザ３１が「好きな臭い」、「嫌いな臭い」、臭いに対する「敏感性」、及び閾値設定レベル）を取得する。

なお、Ｓ２１０～Ｓ２３０の動作も、必ずしも図７に示した順序でなくても構わない。例えば、車両情報は、ユーザ情報よりも後に取得されても構わない。

車両管理サーバ２００は、車内臭の種別毎の臭いレベルを取得する（Ｓ２４０）。具体的には、車両管理サーバ２００は、図１０に示した車両別臭いレベルデータベースを参照し、車内臭の種別と対応付けられる臭いレベル、及び当該種別の臭いレベルの合計値を取得する。

なお、車両管理サーバ２００は、Ｓ２４０の処理を所定の時間間隔（図中のｔ１，ｔ２）毎に繰り返す。

車両管理サーバ２００は、取得した臭いレベル（種別毎または合計値）が所定基準を満たすか否かを判定する（Ｓ２５０）。なお、上述したように、所定基準は、Ｓ２１０において取得した車両情報、またはＳ２３０において取得したユーザ情報の内容に応じて変更することができる。

Ｓ２５０において臭いレベルが所定基準を満足しない場合（例えば、乗員に対して車内臭が嫌悪感を与えるレベルであると判断される場合）、車両管理サーバ２００は、車両装備５３を制御する（Ｓ２６０）。具体的には、車両管理サーバ２００は、臭いレベルの低減と対応付けられた制御内容に基づいて、車両５０Ａを制御する制御データを車両５０Ａに送信する。

車両管理サーバ２００から制御データを受信した車両５０Ａは、当該制御データに基づいて、車内の臭いレベルを低減するために車両装備５３を構成する各種装置を制御する。

なお、本実施形態においては、車両管理サーバ２００が車内の臭いレベルを低減するための制御データを車両５０Ａに送信することとしたが、車両５０Ａに予め車内の臭いレベルを低減するための制御プログラムを記憶しておき、これに従って車両装備５３を構成する各種装置を制御してもよい。

当該制御内容とは、上述したように、ウィンドウの開放、空調システムのファン作動または温度調整、空気清浄機の作動などである。また、制御内容には、電動で開閉可能なウィンドウ、ドア及びテールゲートの制御、紫外線（ＵＶ）ランプ（装備されている場合、かつ乗員が居ない場合）の点灯が含まれる。さらに、車両５０Ａに装備されている場合には、制御内容には、消臭・脱臭装置（科学的反応を利用する装置を含む）、及びイオン発生器の作動が含まれてもよい。

また、制御データは、開放するウィンドウの位置（前方右側、後方左側など）、ウィンドウを開放する時間、ウィンドウを開放する程度（全て開放、半分開放、１／３開放など、窓を開放する面積の大きさに関する情報）に関するデータをさらに含んでもよい。

或いは、制御データは、消臭・脱臭装置及びイオン発生器を作動させる時間、作動強度に関するデータをさらに含んでもよい。

車両管理サーバ２００から制御データを受信した車両５０Ａは、制御データに含まれる指示に基づいて、車両装備５３を構成する各種装置を制御する。

一方、Ｓ２５０において臭いレベルが所定基準を満足する場合、車両管理サーバ２００は、特に車両装備５３を構成する各種装置を制御することなく、処理を終了する。

車両管理サーバ２００は、臭いレベル低減を目的して車両装備５３を構成する各種装置を制御した結果、臭いレベルが所定基準を満たすまで改善するか否かを判定する（Ｓ２７０）。

具体的には、車両管理サーバ２００は、Ｓ２５０と同様に、車両装備５３の制御後に取得した臭いレベル（種別毎または合計値）が所定基準（図中のＴＨ参照）を満たすか否かを判定する。Ｓ２７０の処理は、例えば、次の乗客への配車が行われる配車予定時刻までに実行される。

なお、車両管理サーバ２００は、所定の時間間隔で繰り返し実行される臭いレベルの取得結果に基づいて、臭いレベルが実際に所定基準を満たすまで改善したかを確認してもよいし、図７のフロー外に示すように、ｔ１における臭いレベルと、ｔ２における臭いレベルとの変化（低減程度）に基づいて推定される将来（例えば、配車予定時刻）の臭いレベルが所定基準を満たすまで改善するかを予測処理した上で判定してもよい。

なお、予測処理においては、図７のフロー外に示す、ｔ１における臭いレベルと、ｔ２における臭いレベルとの変化（低減程度）に加えて、ｔ１からｔ２までに車両装備５３を構成する各種装置が実行した臭いレベル低減のための制御内容を考慮して、将来の臭いレベルが所定基準を満たすまで改善するかを予測してもよい。

例えば、車両装備５３を構成する各種装置が実行した臭いレベル低減のための制御内容について、臭いレベル低減に対する寄与レベルに関するデータを予め記憶しておき、当該寄与レベルが小さい制御内容が実行された場合におけるｔ１からｔ２における臭いレベルへの変化値に基づいて、当該寄与レベルが大きい制御内容が実行された場合に見込まれる変化値を予測してもよい。この場合、取得した臭いレベルの変化値と、両方の寄与レベルの比率とに基づいて将来の変化値を予測してもよい。

臭いレベルが所定基準を満たすまで改善する場合、車両管理サーバ２００は、車両５０Ａを予定どおり配車することを決定し、当該フローを終了する。

一方、臭いレベルが所定基準を満たすまで改善しない（または、配車予定時刻までに臭いレベルが所定基準を満たすまで改善しないと推定される）場合、車両管理サーバ２００は、ユーザ３１に対して配車される車両のオプション（提供オプション）の選択フローを実行する（Ｓ２８０）。

（４）提供オプションの選択フロー
図８は、提供オプションの選択フローを示す。図８に示すように、車両管理システム１０（車両管理サーバ２００）は、ユーザ３１に対して配車される車両５０Ａにおいて発生している車内臭の種別を取得する（Ｓ３１０）。具体的には、車両管理サーバ２００は、臭いレベルの判定フロー（図７参照）を実行することによって取得した車内臭の種別を取得する。

車両管理サーバ２００は、車両５０Ａの他の車両（車両５０Ｂ）への代替が必要か否かを判定する（Ｓ３２０）。具体的には、車両管理サーバ２００は、車内臭の種別に基づいて、車両５０Ｂへの代替が必要か否かを判定する。

例えば、車内臭の種別が「吐しゃ物」であった場合、車両５０Ａをそのまま提供することは難しいため、車両５０Ｂへの代替が必要と判定される。一方、車内臭の種別が「たばこ」であった場合、ユーザ３１に車両５０Ａを提供している段階においても、一定の臭いレベルの車内臭が残留するものの、ユーザ３１のユーザ情報（図１１参照）も考慮しつつ、車両５０Ａが提供可能か否か判定される。

車両５０Ｂへの代替が必要な場合、車両管理サーバ２００は、車両５０Ｂに対してタクシースタンドへの配車を指示する（Ｓ３３０）。また、車両管理サーバ２００は、当初配車予定であった車両５０Ａの清掃を所定宛先（例えば、清掃業者）に対して指示する（Ｓ３４０）。車両５０Ａは、吐しゃ物によって車内が汚れていると想定されるためである。

この場合、所定宛先に対して清掃を予約するデータを送信する一方、車両５０Ａに対して、当初の配車予定をキャンセルするデータとともに、所定宛先に対して清掃を予約した時刻に、所定宛先に関連付けられた地理的位置（住所など）に到着するように走行を指示するデータを送信する。

車両５０Ａが提供可能な場合、車両管理サーバ２００は、提供料金の減額要否を決定する（Ｓ３５０）。

具体的には、車両管理サーバ２００は、車両５０Ａの車内臭の種別、臭いレベル、または配車までの所要時間（当初配車予定時刻からの遅延有無を含む）に基づいて、車両５０Ａのデフォルトの提供料金を減額することができる。なお、車両管理サーバ２００は、臭いレベルまたはユーザ情報の内容に応じて、減額率を変更してもよいし、減額を不要としてもよい。

つまり、Ｓ３２０，Ｓ３３０，Ｓ３４０及びＳ３５０においては、既に予約されている配車内容の変更が決定されている。上述の例においては、Ｓ３２０，Ｓ３３０及びＳ３４０において予約されている配車内容のうち、車両の変更が決定されており、Ｓ３５０においては、予約されている配車内容のうち、金額の変更が決定されているが、これに限られない。例えば、配車内容のうち、配車予定時刻を所定時間遅らせて、清掃後の車両５０Ａを配車するよう決定してもよい。

車両管理サーバ２００は、決定した配車内容をユーザ３１が使用する通信端末４０に送信して通知する（Ｓ３６０）。

図１２は、車両５０Ａが提供される場合における配車内容のメッセージ例を示す。具体的には、図１２は、Ｓ３６０の通知結果として通信端末４０に表示されたメッセージ例を示す。

図１２に示すように、通信端末４０には、車内臭の種別（たばこ）、車両５０Ａの状況、配車予定時刻、及び提供料金の減額に関する情報が表示される。

ユーザ３１は、「ＯＫ」ボタンにタッチすれば、車両５０Ａの配車が確定し、「変更」ボタンにタッチすれば、配車条件を変更する画面に遷移することができる。

図１３は、車両５０Ａに代替して車両５０Ｂが提供される場合における配車内容のメッセージ例を示す。図１３に示すように、通信端末４０には、車両が変更されること、配車予定時刻、及び提供料金の減額に関する情報が表示される。ユーザ３１は、「ＯＫ」ボタンにタッチすれば、車両５０Ｂの配車が確定し、「変更」ボタンにタッチすれば、配車条件を変更する画面に遷移することができる。

なお、当該メッセージには、さらに、以下のような項目が含まれてもよい。
・車内臭の種別
・検出された臭いレベル
・配車時（乗車時）の推定臭いレベル
・予定配車時刻からの遅延時間
・提供料金の減額理由

また、当該メッセージは、上述したＳ３６０のタイミング以外に、以下のタイミングで送信されてもよい。
・配車要求時
・所定基準を満たさない臭いレベルの検出時
・配車予定時刻の所定時間（例えば、３０分）前

以上説明した実施形態によれば、以下の作用効果が得られる。具体的には、車両管理システム１０によれば、臭いセンサ５１から出力された車内臭データに基づいて車内臭の種別が判定され、当該車内臭の種別と対応付けられる臭いレベルが車内臭データから取得される。さらに、当該臭いレベルが所定基準を満たすか否かが判定される。

このため、車内の臭いレベルが所定基準を満たさないと判定された場合には、当該車両をユーザに提供しないようにできる。これにより、車内の臭いレベルが所定基準を満たす車両のみをユーザに提供し得る。

また、車両の臭いセンサ５１から出力された車内臭データを遠隔地にあるサーバ（データベースサーバ１００または車両管理サーバ２００）が受信し、車内の臭いレベルが所定基準を満たすか否かを判定し、所定基準を満たさない場合には、当該サーバから車両に対して臭いレベルの低減を行うための制御データを送信することができる。

これにより、乗客が乗車する前に、車両の遠隔地から車両の状態が適切であるか否かを判断することができ、適切でない場合には、不適切な車両に対して配車をキャンセルしつつ、代替車両の配車を手配することができる。

本実施形態では、車両管理システム１０は、第１時刻（ｔ１）における臭いレベルと、第１時刻よりも後の第２時刻（ｔ２）における臭いレベルとの変化づいて推定される臭いレベル（例えば、ｔ２よりも後のｔ３における臭いレベル）が所定基準を満たすか否かを判定することができる。

このため、実際の配車時（車両のタクシースタンドへの到着時）における臭いレベルが所定基準を満たすか否かを判定できる。これにより、車両の稼働率を高めつつ、車内の臭いレベルが所定基準を満たす車両のみをユーザに提供し得る。

本実施形態では、車両管理システム１０は、臭いレベルが所定基準を満たさない場合、当該臭いレベルの低減と対応付けられた制御内容に基づいて、当該車両を制御する制御データを当該車両に送信することができる。

また、本実施形態では、車両管理システム１０は、臭いレベルの低減と対応付けられた制御が当該車両に対して実行された後に、臭いレベルが所定基準を満たすか否かを判定することができる。

このため、臭いレベルの低減が促進される。これにより、車両の稼働率を高めつつ、車内の臭いレベルが所定基準を満たす車両のみをユーザに提供し得る。

本実施形態では、車両管理システム１０は、臭いレベルが、ユーザ情報に基づく所定基準を満たすか否かを判定することができる。つまり、所定基準は、ユーザ情報の内容に応じて変更し得る。このため、ユーザの車内臭に対する満足度の確保と、車両の稼働率の向上とを高い次元で両立し得る。

本実施形態では、車両管理システム１０は、臭いレベルが、車両情報に基づく所定基準を満たすか否かを判定することができる。つまり、所定基準は、車両の種別または環境に応じて変更し得る。このため、より高い精度で、車内の臭いレベルが所定基準を満たす車両のみをユーザに提供し得る。

また、車両管理システム１０によれば、臭いレベルが所定基準を満たさないと判定された場合、当該臭いレベルに対応した車両の提供オプションが選択される。さらに、選択された提供オプションと対応付けられた通知（通信端末４０への配車内容のメッセージ通知など）、または車両に対する車両制御（代替車両のタクシースタンドへの配車）が実行される。

このように、提供予定の車両の臭いレベルが所定基準を満たさないと判定された場合でも、当該臭いレベルに対応した車両の提供オプションが選択されることによって、車内の臭いレベルに応じた適切な条件でユーザに車両を提供し得る。

本実施形態では、車両管理システム１０は、臭いレベルが所定基準を満たさないと判定された車両を他の車両に代替する提供オプションを選択することができる。また、車両管理システム１０は、車内臭の種別に基づいて、他の車両に代替する提供オプションを選択することができる。

さらに、車両管理システム１０は、当該他の車両を所定場所（タクシースタンド）に向かわせる車両制御を実行することができる。

このため、車両装備５３の制御のみでは臭いレベルの低減が不可能な車内臭（吐しゃ物など）の場合には、速やかに他の車両を提供することができる。これにより、車内の臭いレベルが所定基準を満たす車両のみをユーザに提供し得る。

また、本実施形態では、車両管理システム１０は、他の車両に代替する提供オプションを選択した場合、当初配車予定であった車両の清掃を所定宛先（例えば、清掃業者）に対して指示することができる。

このため、車両装備５３の制御のみでは臭いレベルの低減が不可能と判定された車両に対する対策を速やかに講じることができる。これにより、車両の稼働率を高め得る。

本実施形態では、車両管理システム１０は、車両の提供料金を減額する提供オプションを選択することができる。このため、ユーザが許容できる場合には、車両の稼働率を高めつつ、車内の臭いレベルが所定基準を満たす車両のみをユーザに提供し得る。また、ユーザは、安価な料金で当該車両を利用できる。

本実施形態では、車両管理システム１０は、選択した提供オプションの内容を配車予定のユーザと対応付けられた通信端末４０に通知することができる。このため、車両の配車内容に変更が発生した場合でも、ユーザは、速やかに当該配車内容を確認できる。また、ユーザは、当該配車内容を受け入れない場合も、速やかに配車内容の変更を要求し得る。

（その他の実施形態）
以上、実施例に沿って本発明の内容を説明したが、本発明はこれらの記載に限定されるものではなく、種々の変形及び改良が可能であることは、当業者には自明である。

例えば、上述した実施形態では、臭いセンサ５１は、車両５０Ａの車内に設けられることを前提としていたが、車外の臭いを検出する臭いセンサが設けられてもよい。車外の臭いも検出することによって、検出された臭いが、車内または車外の何れで発生しているのかを高い精度で判定し得る。

また、臭いセンサ５１は、客室内のシートポジション毎など、複数設けることができるが、この場合、各臭いセンサは、当該シートポジション、車内／車外を識別可能な識別子（ＩＤ）を有していてもよい。

上述した実施形態では、車両５０Ａ～車両５０Ｃがタクシーである例について説明したが、車両５０Ａ～車両５０Ｃは、カーシェアリグまたはレンタカー用として提供される車両であっても構わない。この場合、車両管理サーバ２００は、ユーザによる車両の利用予定時間を管理することとなる。

さらに、上述した実施形態では、車両５０Ａ～車両５０Ｃは、レベル４以上の自動運転機能を有していたが、車両５０Ａ～車両５０Ｃは、レベル３以下の自動運転機能を有し、ドライバーが乗車してもよい。

上述した実施形態では、車両管理システム１０は、データベースサーバ１００及び車両管理サーバ２００によって構成されていたが、データベースサーバ１００と車両管理サーバ２００と区別されずに、両サーバの機能は、一体的または分散的に提供されてもよい。つまり、上述したように、両サーバの機能は、ネットワーククラウド２０上で提供される各種サービスを用いて、仮想的に実現されてもよい。

上述した実施形態では、ユーザ情報データベース１５０を構成する情報は、当該ユーザが事前に登録してもよいし、タクシー利用時（配車要求時）に当該ユーザが通信端末４０を用いて登録してもよいとしたが、当該ユーザは、さらに、同乗者の有無、或いは配車要求時の気分に応じて、登録内容を変更してもよい。

上述した実施形態では、車両５０Ａの提供料金を減額する提供オプションが選択されていたが、ユーザは、配車された車両の簡単な清掃、車内臭の発生源の特定などの協力を提供することによって、相応の対価（クレジット）を取得するようにしてもよい。

上記のように、本発明の実施形態を記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。

１０ 車両管理システム
２０ ネットワーククラウド
３１，３２ ユーザ
４０ 通信端末
５０Ａ，５０Ｂ，５０Ｃ 車両
５１ 臭いセンサ
５３ 車両装備
５５ 通信部
５７ 装備制御部
５９ 送信制御部
１００ データベースサーバ
１１０ 車内臭データ取得部
１２０ 車両状態取得部
１３０ 車内臭種別判定部
１４０ 車内臭データベース
１５０ ユーザ情報データベース
２００ 車両管理サーバ
２１０ 臭いレベル判定部
２２０ 車両制御部
２３０ ユーザ情報取得部
２４０ 車両情報取得部
２５０ オプション選択部
２５５ 予約情報取得部
２６０ オプション実行部

Claims (9)

1. プロセッサとメモリとを少なくとも含み、車両の状態を管理する車両管理システムであって、
   前記車両管理システムは、前記車両と通信を行う通信インタフェースを含む、前記車両とは分離されたサーバであり、
   前記プロセッサは、
   前記車両の車内に設けられた臭いセンサを制御させて前記臭いセンサから出力された車内臭データを、前記通信インタフェースを経由して取得するデータ取得部と、
   前記車内臭データに基づいて、前記車両を制御する制御データを含むコマンドを前記車両に送信する車両制御部と
   を構成し、
   前記制御データは、前記車両の空調システム及びウィンドウの開閉の少なくとも何れかを制御するためのデータである車両管理システム。
2. 前記車内臭データに基づいて車内臭の種別を判定する種別判定部と、
   前記車内臭の種別と対応付けられる臭いレベルを前記車内臭データから取得し、前記臭いレベルが所定基準を満たすか否かを判定するレベル判定部と
   を備え、
   前記データ取得部は、前記車両に第１のコマンドを送信し、
   前記車両制御部は、前記臭いレベルが前記所定基準を満たさない場合、前記臭いレベルの低減と対応付けられた制御内容に基づいて、前記車両を制御する制御データを含む第２のコマンドを前記車両に送信する請求項１に記載の車両管理システム。
3. 前記プロセッサは、前記車両の利用の予約情報を取得する予約情報取得部を構成し、
   前記データ取得部は、前記車両に対する前記予約情報が存在することを検知した場合、前記車両に対して前記車内臭データを要求し、前記車内臭データを取得する請求項１記載の車両管理システム。
4. 前記レベル判定部は、
   第１時刻における第１臭いレベルと、前記第１時刻よりも後の第２時刻における第２臭いレベルとを取得し、
   前記第１臭いレベルと前記第２臭いレベルとの変化に基づいて推定される前記臭いレベルが前記所定基準を満たすか否かを判定する請求項２に記載の車両管理システム。
5. 前記レベル判定部は、前記車両制御部によって前記車両が制御された後に取得した前記臭いレベルが前記所定基準を満たすか否かを判定する請求項２に記載の車両管理システム。
6. 前記プロセッサは、前記車両を利用するユーザの前記車内臭に対する耐性を含むユーザ情報を取得するユーザ情報取得部を構成し、
   前記レベル判定部は、前記臭いレベルが、前記ユーザ情報に基づく前記所定基準を満たすか否かを判定する請求項２に記載の車両管理システム。
7. 前記プロセッサは、前記車両の種別及び環境の少なくとも何れかを含む車両情報を取得する車両情報取得部を構成し、
   前記レベル判定部は、前記臭いレベルが前記車両情報に基づく前記所定基準を満たすか否かを判定する請求項２に記載の車両管理システム。
8. プロセッサとメモリとを少なくとも有し、車両に搭載される車載システムであって、
   前記車両の車内臭を検知する臭いセンサと、
   サーバと通信を行う無線通信インタフェースと
   をさらに有し、
   前記プロセッサは、
   前記サーバから送信された第１のコマンドを受信し、前記臭いセンサを制御することによって得られた車内臭データを、前記無線通信インタフェースを経由して前記サーバに送信する送信制御部と、
   前記サーバから前記車内臭データに基づいて送信された第２のコマンドを受信し、前記車両の空調システム及びウィンドウの開閉の少なくとも何れかを制御する装備制御部と
   を構成する車載システム。
9. 少なくともプロセッサとメモリと通信インタフェースとを備えたサーバにおける、車両の状態を管理する車両管理方法であって、
   前記通信インタフェースを経由して前記車両に第１のコマンドを送信し、前記車両の車内に設けられた臭いセンサを制御させ、
   前記臭いセンサから出力された車内臭データを、前記通信インタフェースを経由して取得し、
   取得した前記車内臭データから車内臭の種別を判定し、
   前記車内臭の種別と対応付けられる臭いレベルを前記車内臭データから取得し、
   前記臭いレベルが所定基準を満たすか否かを判定し、
   前記臭いレベルが前記所定基準を満たさない場合、前記臭いレベルの低減と対応付けられた制御内容に基づいて、前記車両を制御する制御データを含む第２のコマンドを前記車両に送信し、
   前記制御データは、前記車両の空調システム及びウィンドウの開閉の少なくとも何れかを制御するためのデータである車両管理方法。

Images