JP2016145512A - 鍵制御装置、その制御方法、及びプログラム、並びに、情報処理システム、その制御方法、及びプログラム - Google Patents

Abstract

【課題】ユーザが運転に適さない状態であったとしても、運転席以外のドアの鍵の制御を可能とする仕組みを提供すること【解決手段】本発明の鍵制御装置は、ユーザの健康状態を取得し、ユーザの健康状態が運転に適しているか否かを判定する。運転に適していると判定された場合はすべてのドアを開錠可能に制御する。ユーザの健康状態が運転に適していないと判定された場合は、荷物の積み下ろしなどが可能なように運転席以外のドアが開錠可能に制御を行う。さらに、エンジンの始動に関する制御も、開錠した鍵と同じＩＤを持つ鍵でなければエンジンを始動することができない仕組みも提供する。【選択図】図７

Description

ユーザの健康状態に応じて車両の鍵の開閉を制御することの可能な鍵制御装置、その制御方法、及びプログラム、並びに、情報処理システム、その制御方法、及びプログラムに関する。

近年、自動車と近距離無線通信を行い、自動車に対して鍵を開けるよう指示したり、エンジンを始動させる指示を行ったりすることの可能な電子鍵が普及してきている。電子鍵は例えばスマートフォンのような情報処理端末に搭載されるアプリケーションを通じて処理されるものである。ユーザは所有しているスマートフォンのアプリケーションを起動させ、車に対して制御指示を行う。このような仕組みにおいては、ユーザの健康状態に関係なく自動車に対して制御指示を行うことが可能である。具体的にはユーザが運転に適さないような健康状態（例えば飲酒状態、高血圧状態など）であっても、ユーザは自動車に対して鍵を開けるよう指示をして運転を開始することができてしまう。

下記の特許文献１には、携帯端末に搭載された呼気収集器により取り込んだユーザの呼気に基づいて携帯端末が運転適否を決定し、運転適となった場合にあらかじめ設定された鍵命令を生成し、自動車に対して送信する仕組みが開示されている。

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

ところで、自動車の鍵を開ける状況は、ユーザが自動車を運転するために鍵を開ける場合だけではなく、ユーザが自動車に荷物を積載するために鍵を開ける場合も考えられる。

上述した特許文献１の仕組みでは、ユーザの健康状態が運転に適さない状態だと判断された場合には、自動車の鍵を開けることができない。そのため、ユーザが自動車に荷物を積載しようと携帯端末で鍵を開ける指示を行った場合であっても、ユーザは自動車の鍵を開けることができず、荷物を自動車に積載することができないという状況が生じていた。

そこで、本発明は、ユーザの健康状態が運転に適さない場合に運転が行われることを防止しつつも、適切に鍵の開閉を制御することが出来る仕組みを提供することを目的とする。

上記の目的を達成するために、本発明の鍵制御システムは複数のドアを備えた車両と、ユーザの健康状態を取得する健康状態取得装置と、前記車両と前記健康状態取得装置と通信可能な鍵制御装置とを備えた鍵制御システムであって、前記健康状態取得装置から、前記ユーザの健康状態を取得する健康状態取得手段と、前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たす場合には、前記複数のドアのいずれの鍵も開くように制御し、前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たさない場合には、前記運転席以外のドアの鍵を開くように制御する制御手段と、を備えていることを特徴とする。

本発明によれば、ユーザの健康状態が運転に適さない場合に運転が行われることを防止しつつも、適切に鍵の開閉を制御することが出来る仕組みを提供することを可能にする。

本発明の実施形態における鍵制御システムのシステム構成の一例を示す図である。 本発明の実施形態におけるスマートフォン１２０のハードウェア構成の一例を示す図である。 本発明の実施形態におけるウェアラブルデバイス１１０のハードウェア構成の一例を示す図である。 本発明の実施形態における自動車１３０のハードウェア構成の一例を示す構成図である。 ウェアラブルデバイス１１０、スマートフォン１２０、自動車１３０の機能構成の一例を示す図である。 本発明の実施形態におけるスマートフォン１２０がウェアラブルデバイス１１０から血圧値を取得するための処理の流れを示すフローチャートである。 本発明の実施形態におけるドアオープン指示の全体の処理の流れを示すフローチャートである。 エンジン始動制御の処理の流れを示すフローチャートである。 図７に示す個別ドア制御処理の詳細な処理の流れを示すフローチャートである。 ウェアラブルデバイス血圧値テーブル１０００の一例を示すデータテーブルである。 スマートフォン血圧値テーブル１１００の一例を示すデータテーブルである。 ドア管理テーブル１２００の一例を示すデータテーブルである。 ウェアラブルデバイス設定テーブル１３００の一例を示すデータテーブルである。 スマートフォン設定テーブル１４００の一例を示すデータテーブルである。 自動車制御画面１５００の画面例である。 設定画面１６００の画面例である。 状態表示画面１７００の画面例である。 エンジン始動成功画面１８００の画面例である。 エンジン始動失敗画面１９００の画面例である。 個別ドア制御画面２０００の画面例である。

以下、図面を参照しながら本発明の実施形態について説明を行う。

図１は、本発明の実施形態における鍵制御システムのシステム構成の一例を示す図である。情報処理システムは、ウェアラブルデバイス１１０（健康状態取得装置に相当する）とスマートフォン１２０（鍵制御装置に相当する）と運転席を含む複数のドアを備えた自動車１３０（車両に相当する）とがそれぞれ通信可能に接続されている。スマートフォン１２０はウェアラブルデバイス１１０と自動車１３０と通信可能である。本実施形態では、例えばスマートフォン１２０が直接ウェアラブルデバイス１１０に接続をしているが、ネットワークを介して接続する構成であってもよい。尚、図１のシステム上に接続される各種端末の構成は一例であり、用途や目的に応じて様々な構成例がある。

スマートフォン１２０は自動車１３０の電子鍵の役割を担い、スマートフォン１２０から自動車１３０に対して鍵を開ける指示を行うと、ウェアラブルデバイス１１０から取得してきた血圧値に応じて運転適否を判定する。運転適否の結果に応じて自動車に対して開錠指示を行い、自動車１３０はスマートフォン１２０の指示に従って鍵を開けるよう制御する。詳細は後述する。なお、本実施形態ではユーザの健康状態を示す項目として血圧値を用いているが、ユーザの健康状態を取得することが可能なウェアラブルデバイスであれば他のデバイスであってもよいものとする。

次に図２を用いてスマートフォン１２０のハードウェア構成の一例について説明する。

スマートフォン１２０は、タッチパネルを備える装置である。タッチパネルを備える装置であれば、パーソナルコンピュータであってもよい。

ＣＰＵ２０１は、システムバスを介してメモリやコントローラを統括的に制御する。ＲＯＭ２０２やＨＤＤ（ハードディスク）２０４には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステム２００が記憶されている。更には、スマートフォン１２０が実行する機能を実現するために必要な、後述する各種プログラム等が記憶されている。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

入力コントローラ２０６は、タッチパネル２０９からの入力を制御する。ディスプレイ２１０は例えば液晶ディスプレイである。また、ディスプレイ２１０の表面にはタッチパネル２０９が備えられている。タッチパネル２０９に対するタッチ操作の検知を入力コントローラ２０６が制御する。入力コントローラ２０６は、タッチパネル２０９に対する複数の箇所に対するタッチ操作（以下、マルチタッチという。）も検知することが可能である。

出力コントローラ２０７は、ディスプレイ２１０の表示を制御する。例えば、例えば自動車制御画面１５００をディスプレイ２１０に表示するよう制御する。

ネットワークコントローラ２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。また、赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの方法を用い、自動車１３０やウェアラブルデバイス１１０と通信する近距離無線通信２１３を制御する。近距離無線通信の方法は通信が可能であればこれに限定されない。

前述したＣＰＵ２０１、各メモリ、各コントローラは、１つのチップ２１５に統合されている。いわゆるＳｏＣ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）の形態でスマートフォン１２０の内部に備えられている。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０での表示を可能としている。

本発明のスマートフォン１２０が後述する各種処理を実行するために用いられる各種プログラム等はＨＤＤ２０４に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルはＨＤＤ２０４に格納されている。以上が、本実施形態におけるハードウェア構成である。尚、このハードウェア構成は一例であり、用途や目的に応じて様々な構成例がある。

次に図３を用いてウェアラブルデバイス１１０のハードウェア構成の一例について説明する。

ＣＰＵ３０１は、システムバス３０４に接続されるコントローラの制御及び演算処理等を行う。

ＲＯＭ３０２には、ＣＰＵ３０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムが記憶されている。

ＲＡＭ３０３は、ＣＰＵ３０１の主メモリ、ワークエリア等として機能する。ＣＰＵ３０１は、処理の実行に際して必要なプログラム等をＲＡＭ３０３にロードして、プログラムを実行することで各種動作を実現するものである。

入力コントローラ３０５は、ウェアラブルデバイス１１０に設けられた血圧センサ３０８からユーザの血圧値の情報を取得する。血圧センサ３０８はユーザの血圧値を取得することが可能であり、例えば、特開２００５−２９６２１４号公報に示されている方法でユーザの血圧値を取得する。本発明において、ユーザが自動車の運転が可能か否かをユーザの血圧値に基づいて判定するものとしたが、一例であり血圧値以外にも心拍数や体温、血糖値など他の指標に基づいて判定してもよい。

出力コントローラ３０６は、血圧センサ３０８で取得した血圧値に基づいて、判定される健康状態をウェアラブルデバイス１１０に備えられたＬＥＤ３０９（発光ダイオード）を発光させる。例えば健康状態が良い場合には青色に発光させ、健康状態がよくない場合には赤色に発光させる。

通信Ｉ／Ｆコントローラ３０７は、近距離無線通信３１０を制御するコントローラであり、近距離無線通信３１０を使用して、スマートフォン１２０と通信をすることが可能である。

以上、本発明におけるウェアラブルデバイス１１０のハードウェア構成の説明を終了する。なお、上述したハードウェア構成は一例であって、用途や目的に応じて様々な構成例がある。

次に図４を用いて自動車１３０のハードウェア構成の一例について説明する。尚、図４に示すハードウェア構成は、自動車１３０のドアオープン・クローズ（ドアの鍵の制御系）の関する領域のみの構成であり、自動車１３０を走行させるためのハードウェア構成の説明は省略する。

ＣＰＵ４０１は、システムバス４０４に接続されるコントローラの制御及び演算処理などを行う。

ＲＯＭ４０２には、ＣＰＵ４０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムが記憶されている。

ＲＡＭ４０３は、ＣＰＵ４０１の主メモリ、ワークエリア等として機能する。ＣＰＵ４０１は、処理の実行に際して必要なプログラム等をＲＡＭ４０３にロードして、プログラムを実行することで各種動作を実現するものである。

出力コントローラ４０５は、ドア鍵制御装置４０７とエンジン制御装置４０８を制御する。スマートフォン１２０からの指示に応じて、ドア鍵制御装置４０７に対してドアの鍵の開閉制御を行う。また、スマートフォン１２０からの指示に応じてエンジン制御装置４０８に対して指示を行い、エンジンを始動させる。

通信Ｉ／Ｆコントローラ４０６は近距離無線通信４０９を制御することによりスマートフォン１２０と通信を行う。

以上で自動車１３０のハードウェア構成の説明を終了する。尚、上述したハードウェア構成は一例であって、用途や目的に応じて様々な構成例がある。

次に図５を用いてスマートフォン１２０、ウェアラブルデバイス１１０、自動車１３０のモジュール構成について説明する。なお、図５の装置のモジュール構成は一例であり、用途や目的に応じて様々な構成例がある。

ウェアラブルデバイス１１０は、通信部１５０、健康状態取得部１５１、ＬＥＤ制御部１５２を備える。

通信部１５０は、スマートフォン１２０と通信を行う機能部である。

健康状態取得部１５１は、ユーザの健康状態を示す血圧値を取得する機能部である。

ＬＥＤ制御部１５２は、ウェアラブルデバイス１１０に備えられたＬＥＤの発光を制御する機能部である。

スマートフォン１２０は、通信部２５０、健康状態取得部２５１、健康状態判定部２５２、鍵制御部２５３、エンジン制御部２５４、アプリケーション部２５５、表示制御部２５６を備える。

通信部２５０は、ウェアラブルデバイス１１０や自動車１３０と通信を行う機能部である。健康状態取得部２５１は、ウェアラブルデバイス１１０から血圧値等の健康状態を示す値を取得する機能部である。健康状態判定部２５２は、健康状態取得部２５１で取得した血圧値等の健康状態を示す値に基づいて自動車の運転が可能か否かを判定する機能部である。鍵制御部２５３は、自動車１３０の鍵の開閉を制御する機能部である。エンジン制御部２５４は自動車１３０のエンジンを始動させる機能部である。アプリケーション部２５５は、血圧アプリケーションや自動車制御アプリケーションの制御を行う機能部である。表示制御部２５６はスマートフォン１２０に備えられたディスプレイ２１０の表示を制御する機能部である。

自動車１３０は、通信部３５０、鍵管理部３５１、エンジン管理部３５２を備える。

通信部３５０はスマートフォン１２０との通信を制御する機能部である。鍵管理部３５１は、自動車１３０のドアに備えられている鍵の開閉を制御することにより管理する機能部である。エンジン管理部３５２は自動車１３０のエンジンの動作を管理する機能部である。

次に本発明の実施形態について図６のフローチャートを用いて説明する。図６ではスマートフォン１２０がウェアラブルデバイス１１０から健康状態を示す値として血圧値を取得する際の処理の流れを示すフローチャートである。

ステップＳ６０１では、ウェアラブルデバイス１１０のＣＰＵ３０１が、血圧ＡＰＬ（アプリケーション）を起動する。

ステップＳ６０２では、ウェアラブルデバイス１１０のＣＰＵ３０１が、近距離無線通信３１０を起動する。

ステップＳ６０３では、ウェアラブルデバイス１１０のＣＰＵ３０１が、血圧センサ３０８で血圧値を測定し、ユーザの血圧値１００１を取得する。詳細な処理の方法は上述した方法で行う。取得した血圧値は、図１０に示すウェアラブルデバイス血圧値テーブル１０００に格納する。ウェアラブルデバイス血圧値テーブル１０００には血圧値１００１が記憶され、ユーザの血圧値（図１０では血管収縮期の血圧を示す）を格納している。

ステップＳ６０４では、ウェアラブルデバイス１１０のＣＰＵ３０１が、ステップＳ６０３で取得した血圧値１００１と図１３に示すウェアラブルデバイス設定テーブル１３００に記憶される血管収縮期の血圧指標値（正常）１３０１とに基づいて、血管収縮期の血圧値が正常な範囲であるかを判断する。血圧指標値（正常）１３０１を血圧値１００１が超えていると判定した場合には正常な範囲外であるため処理をステップＳ６０６に進め、血圧指標値（正常）１３０１を血圧値１００１が超えていないと判定した場合は正常な範囲内であるため、処理をステップＳ６０５に進める。

図１３に示すウェアラブルデバイス設定テーブル１３００に格納される血圧指標値（正常）１３０１は、スマートフォン１２０からユーザにより設定されるものであり、スマートフォンのディスプレイに表示した設定画面１６００の血圧指標値１６０１への指標値の入力を受け付け、登録ボタン１６０６の押下を受け付けることでウェアラブルデバイス１１０の設定が更新される。なお、血圧指標値１３０１はユーザが設定しなくても、過去の血圧値の変移から自動で設定されるようにしてもよい。

ステップＳ６０５では、ウェアラブルデバイス１１０のＣＰＵ３０１が、ウェアラブルデバイス１１０の備えるＬＥＤを青色に発光させる。ユーザに健康状態を通知するために発光するためであり、色はこれに限定されない。

ステップＳ６０６では、ウェアラブルデバイス１１０のＣＰＵ３０１が、ウェアラブルデバイス１１０の備えるＬＥＤを赤色に発光させる。ユーザに健康状態を通知するために発光するためであり、色はこれに限定されない。

ステップＳ６０７では、ウェアラブルデバイス１１０のＣＰＵ３０１が、スマートフォン１２０から接続要求を受け付けたか否かを判定する。接続要求とは、近距離無線通信による接続の要求であり、血圧値の取得要求を意味するものである。スマートフォン１２０から接続要求を受け付けたと判定した場合は処理をステップＳ６１２に進める。スマートフォン１２０から接続要求を受け付けないと判定した場合は処理をステップＳ６０８に進める。

ステップＳ６０８では、ウェアラブルデバイス１１０のＣＰＵ３０１が、タイマー（５分）経過したか否かを判定する。本発明の実施形態では、ウェアラブルデバイス１１０は血圧値を定期的に（５分おき）取得し、取得した血圧値に応じてＬＥＤの色を変化させる。そのため、前回血圧値を測定して取得した時間を起点としてタイマーを設定する。このタイマーが経過した場合に再度血圧値を取得する。タイマーが経過したと判定した場合は処理をステップＳ６０３に戻し、タイマーが経過しないと判定した場合は、タイマーが経過するまで待機する。

ステップＳ６０９では、スマートフォン１２０のＣＰＵ２０１が、血圧ＡＰＬ（アプリケーション）を起動する。

ステップＳ６１０では、スマートフォン１２０のＣＰＵ２０１が、近距離無線通信を起動させる。

ステップＳ６１１では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ６１０で起動した近距離無線通信によりウェアラブルデバイス１１０に対して接続要求を行う。例えば図１５に示す設定画面１６００の接続先（Ｗ）１６０２の入力欄にウェアラブルデバイス１１０の識別番号の入力をユーザから受け付け、登録ボタン１６０６の押下を受け付けることで、スマートフォン１２０の接続先が決定される。

ステップＳ６１２では、ウェアラブルデバイス１１０のＣＰＵ３０１が、ウェアラブルデバイス血圧値テーブル１０００の血圧値１００１を取得する。

ステップＳ６１３では、ウェアラブルデバイス１１０のＣＰＵ３０１が、ステップＳ６１３で取得した血圧値１００１を、ステップＳ６０７で接続要求を受け付けたと判定したスマートフォン１２０に対して送信する。

ステップＳ６１４では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ６１３で送信された血圧値１００１を受信する。（健康状態取得手段に相当する）

ステップＳ６１５では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ６１４で受信した血圧値１００１を図１１に示すスマートフォン血圧値テーブル１１００に格納する。

図１１のスマートフォン血圧値テーブル１１００には、血圧値１１０１、血圧値取得時間１１０２、スマートフォンＩＤ１１０３、オープンドアＮｏ１１０４が格納されている。血圧値１１０１は、ウェアラブルデバイス１１０から取得した血圧値である。血圧値取得時間１１０２はスマートフォン１２０がウェアラブルデバイス１１０から血圧値１００１を取得した時間を格納している。スマートフォンＩＤ１１０３は、スマートフォン１２０を識別するためのＩＤである。オープンドアＮｏ１１０４は、自動車１３０から取得するドアの鍵の制御結果を示す情報である。

以上で、図６に示すフローチャートの説明を終了する。

次に図７に示すフローチャートを用いて本実施形態におけるユーザの健康状態に応じたドアの開閉制御に関する一連の処理の流れを説明する。図７に示すフローチャートは自動車制御アプリケーションが起動した状態における処理の流れを説明するフローチャートとなっている。

ステップＳ７０１では、スマートフォン１２０のＣＰＵ２０１が、自動車制御画面１５００をディスプレイ２１０に表示する。図１５に示す自動車制御画面１５００には、自動車１３０の鍵を制御するためのボタンであるＯＰＥＮボタン１５０１、ＣＬＯＳＥＤボタン１５０２、ドア毎に鍵の開閉制御を行うための詳細ボタン１５０３、自動車１３０のエンジンの始動を制御するＳＴＡＲＴボタン１５０４、ＳＴＯＰボタン１５０５が配置されている。

ステップＳ７０２では、スマートフォン１２０のＣＰＵ２０１が、鍵を制御するためのボタンであるＯＰＥＮボタン１５０１、詳細ボタン１５０３のいずれが押下されたかを判定する（受付手段に相当する）。全ドアオープンを示すＯＰＥＮボタン１５０１が押下されたと判定した場合、処理をステップＳ７０３に進める。個別ドアオープンを示す詳細ボタン１５０３が押下されたと判定した場合、処理をステップＳ７２２に進める。

ステップＳ７０３では、スマートフォン１２０のＣＰＵ２０１が、スマートフォン血圧値テーブル１１００の血圧値取得時間１１０２を参照する。

ステップＳ７０４では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ７０３で参照した血圧値取得時間１１０２が所定の値（本発明の実施形態では１０分とするが、これに限定されない）を超えているか否かを判定する。所定の値を超えていると判定した場合、処理をステップＳ６１１に戻す。所定の値を超えていないと判定した場合は処理をステップＳ７０５に進める。

ステップＳ７０５では、スマートフォン１２０のＣＰＵ２０１が、スマートフォン血圧値テーブル１１００の血圧値１１０１を取得する。

ステップＳ７０６では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ７０５で取得した血管収縮期の血圧値１１０１が正常な血圧の範囲内であるかを判定する。具体的には、図１４に示す血圧指標値１４０１を超えている場合には正常な血圧の範囲内にないと判定する。ステップＳ７０５で取得した血圧値１１０１が正常な血圧の範囲内であると判定した場合、処理をステップＳ７０７に進め、ステップＳ７０５で取得した血圧値１１０１が正常な血圧の範囲内ではないと判定した場合、処理をステップＳ７０８に進める。なお、本実施形態では、血圧が基準値を超えている場合に正常でないと判断したが、血圧が基準値を下回る（低血圧）場合に正常でないと判断するような構成としてもよいし、上限値の基準値と下限値の基準値の両方で判断するような構成としてもよい。

ステップＳ７０７では、正常な血圧の範囲内であるため当該ユーザは運転を適切に行えるといえるため、スマートフォン１２０のＣＰＵ２０１が、自動車１３０のすべてのドアの鍵を開ける指示を示す、全ドアオープン設定を取得する。全ドアオープン設定は、ＨＤＤ２０４に記憶されている。

ステップＳ７０８では、正常な血圧の範囲内ではなく運転を適切に行えない状態である可能性があるため、スマートフォン１２０のＣＰＵ２０１が、自動車の運転席以外のドアの鍵を開ける指示を示す、運転席以外ドアオープン設定を取得する。この運転席以外ドアオープン設定を含むドア開錠指示を受け付けると、自動車１３０は運転席以外のドアの鍵を開けるようドアの鍵を制御する。

ステップＳ７０９では、スマートフォン１２０のＣＰＵ２０１が、通信Ｉ／Ｆコントローラを通じて、近距離無線通信を起動する。

ステップＳ７１０では、スマートフォン１２０のＣＰＵ２０１が、図１４に示すスマートフォン設定テーブル１４００の接続先ＩＤ２−１４０３が示す自動車１３０に接続要求を送信する（制御手段に相当する）。

図１４に示すスマートフォン設定テーブル１４００には、血圧指標値１４０１、接続先ＩＤ１―１４０２、接続先ＩＤ２―１４０３、スマートフォンＩＤ１１０３が対応付けられて記憶されている。血圧指標値１４０１はスマートフォン１２０が管理する正常な血圧の範囲内かを判定する際に用いる血圧の閾値（上限値）であり、例えば血管収縮期血圧がこの値を超える場合にはユーザは運転に適さない状態であると判定させることができる。接続先ＩＤ１―１４０２はスマートフォン１２０が接続するウェアラブルデバイス１１０を識別可能にするＩＤである。接続先ＩＤ２―１４０３は自動車１３０を識別可能にするためのＩＤである。血圧指標値１４０１、接続先ＩＤ１―１４０２、接続先ＩＤ２―１４０３はいずれも、設定ボタン１５０６を押下されると表示される、図１６に示す設定画面１６００を通じて設定される。血圧指標値１６０１、接続先１６０２、接続先１６０３、スマートフォンＩＤ１６０４に入力を受け付け、登録ボタン１６０６の押下を受け付けると、血圧指標値１６０１が血圧指標値１４０１に、接続先１６０２が接続先ＩＤ１―１４０２に、接続先１６０３が接続先ＩＤ２―１４０３に、スマートフォンＩＤ１６０４がスマートフォンＩＤ１１０３にそれぞれ格納される。

ステップＳ７１１では、自動車１３０のＣＰＵ４０１が、スマートフォン１２０から送信される接続要求を受信する。

ステップＳ７１２では、自動車１３０のＣＰＵ４０１が、ステップＳ７１１で受信した接続要求が成功したことを示す接続ステータスをスマートフォン１２０に対して送信する。

ステップＳ７１３では、スマートフォン１２０のＣＰＵ２０１が、接続ステータスを受信する。

ステップＳ７１４では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ７１３で接続が成功したことを示す接続ステータスを受信すると、ステップＳ７０７またはステップＳ７０８で取得したドアオープン設定と共にドアオープン指示を自動車１３０に対して送信する。

ステップＳ７１５では、自動車１３０のＣＰＵ４０１が、ステップＳ７１４で送信されたドアオープン設定とドアオープン指示を受信する。

ステップＳ７１６では、自動車１３０のＣＰＵ４０１が、ステップＳ７１５で受信したドアオープン設定に基づいてドアの鍵を制御する。より具体的には、ステップＳ７１５で受信したドアオープン設定が自動車１３０のすべてのドアのオープン設定（全ドアオープン設定）であれば運転席も含めたすべてのドアの鍵を開けるよう制御する。ステップＳ７１５で受信したドアオープン設定が、自動車１３０の運転席以外のドアの鍵を開ける設定である運転席以外ドアオープン設定であれば、自動車１３０の運転席以外のドアの鍵を開けるよう制御する。このようにすることで、仮に運転するつもりの無い場合であっても荷物の積み下ろしのために必要なドアの鍵を開けることを可能にする。本実施形態では、運転席以外のドアの鍵を開けるように制御したが、荷物の積み下ろしのため自動車１３０のトランクの鍵を開けるだけでもよい。

ドアの鍵の制御結果は自動車１３０がドア管理テーブル１２００として管理している。図１２に示すドア管理テーブル１２００には、ドアＮｏ１２０１、スマートフォンＩＤ１２０２、オープンフラグ１２０３が対応付けられて記憶されている。ドアＮｏ１２０１は自動車１３０が備えるドアを識別可能な番号である。本発明の実施形態では、ドアＮｏ１２０１が「１」のドアが運転席のドアを示している。スマートフォンＩＤ１２０２は、開錠指示を受け付けたスマートフォンのＩＤであるスマートフォンＩＤ１２０２である。オープンフラグ１２０３はドアの鍵が開いているか否かを示すフラグであり、「０」は鍵が閉まっている状態、「１」は鍵が開いている状態を示す。

ステップＳ７１７では、自動車１３０のＣＰＵ４０１が、すべてのドアの鍵が開いているか否かを示すドアステータスをスマートフォン１２０に送信する。

ステップＳ７１８では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ７１７で送信されたドアステータスを受信する。

ステップＳ７１９では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ７１８で受信したドアステータスに基づいて全ドアがオープンしているか否かを判定する。すべてのドアがオープンしていると判定した場合にステップＳ７２０に処理を進め、すべてのドアがオープンしていない（運転席は鍵が閉まっている）と判定した場合は、ステップＳ７２１に処理を進める。

ステップＳ７２０では、スマートフォン１２０のＣＰＵ２０１が、すべてのドアがオープンしたことをディスプレイ２１０に表示する。例えば図１７に示す状態表示画面１７００−ａである。状態表示画面１７００−ａにはすべてのドアがオープンしたことを示す表示１７０６が表示されている。表示をしたのち、処理をステップＳ８０１に移す。

ステップＳ７２１では、スマートフォン１２０のＣＰＵ２０１が、すべてのドアがオープンしていない旨の表示をディスプレイ２１０に表示する。例えば図１７に示す状態表示画面１７００−ｂである。状態表示画面１７００−ｂにはすべてのドアがオープンしていないこと（運転席は閉まっていること）を示す表示１７０７が表示されている。表示をしたのち、処理をステップＳ８０１に移す。

ステップＳ７２２では、スマートフォン１２０のＣＰＵ２０１が、個別ドア制御画面２０００をディスプレイ２１０に表示する。個別ドア制御画面２０００には自動車１３０のすべてのドア（１７０１乃至１７０５）の鍵を個別に制御することが可能な画面である。個別のドアを押下されると、対応するドアの鍵の開閉制御指示を自動車１３０に対して送信する。

ステップＳ７２３では、スマートフォン１２０のＣＰＵ２０１が、個別にドアを制御する処理である個別ドア制御処理を行う。具体的な処理の流れは、のちの図９を用いて詳細に説明を行う。
なお、本実施形態ではユーザが自動車の運転が可能か否かをユーザの血圧値に基づいて判定する例を説明したが、心拍数や体温、血糖値など他の指標に基づいて判定してもよい。具体的には、特開２００９−３４３６６に開示されるような脈拍計からユーザの脈拍数や体温を、スマートフォン１２０が取得する。脈拍数がスマートフォン１２０に記憶される閾値を超えている（または、下回っている）場合には心臓疾患の恐れがあり、危険であると判断できる。すなわち、心拍数が閾値を超えている（または、下回っている）場合には、ドアの開錠指示を受け付けたとしても、運転席のドアを開けないように制御したり、エンジンを始動させないように制御させればよい。
また、体温が閾値を超えている（または、下回っている）場合には、ユーザに何らかの異常が生じている可能性が高く、車両の運転を始めたとしても危険が生じてしまう可能性が高いため、このようなユーザからドアの開錠指示を受け付けたとしても、運転席のドアを開けないように制御したり、エンジンを始動させないように制御させたりする。
さらに、例えば米国出願番号１４／２８９，３６２に記載されているようなデバイスからユーザの血液を採取し、採取された血液の血糖値がスマートフォン１２０に記憶される閾値を下回っている場合には、ユーザの健康状態が運転に適さないと判断できる。すなわち、血糖値が所定の閾値を超えている場合には、ドアの開錠指示を受け付けたとしても、運転席のドアを開けないように制御したり、エンジンを始動させないように制御させたりする。また、血液の赤血球やヘモグロビンの濃度が閾値より低い場合に、ユーザの健康状態が運転に適しているか否かを判断してもよい。（低血糖や、貧血による失神の恐れがあるため）
また、ウェアラブルデバイス１１０とスマートフォン１２０とが別の筐体として本実施形態では記載しているが、同一の筐体であってもよい。

以上で、図７に示すフローチャートの説明を終了する。

次に図８のフローチャートを用いて、エンジン始動制御の処理の流れの説明を行う。

ステップＳ８０１では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ７０１で表示されている自動車制御画面１５００のエンジン制御ボタンであるＳＴＡＲＴボタン１５０４が押下されたか否かを判定する（開始指示受付手段に相当する）。ＳＴＡＲＴボタン１５０４が押下されたと判定した場合には処理をステップＳ８０２に進め、ＳＴＡＲＴボタン１５０４が押下されないと判定した場合には処理をＳＴＡＲＴボタン１５０４が押下されるまで待機する。

ステップＳ８０２では、スマートフォン１２０のＣＰＵ２０１が、血圧値取得時間１１０２を参照する。

ステップＳ８０３では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ８０２で参照した血圧値取得時間が所定の値（本発明の実施形態では１０分とするが、これに限定されない）を超えているか否かを判定する。所定の値を超えていると判定した場合処理をステップＳ６１１に戻す。所定の値を超えていないとは判定した場合は処理をステップＳ８０４に進める。なお、本実施形態では、所定時間おきにユーザの健康状態を取得し、自動車１３０の鍵の制御の判断を行ったが、リアルタイムにユーザの健康状態を取得して自動車１３０の鍵の制御の判断を行うようにしてもよい。

ステップＳ８０４では、スマートフォン１２０のＣＰＵ２０１が、スマートフォン血圧値テーブル１１００の血圧値１１０１を取得する。

ステップＳ８０５では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ８０４で取得した血圧値１１０１が正常な範囲内か否かを判定する。具体的には、血圧値１１０１が血圧指標値１４０１を超えている場合に正常な範囲内にないと判定する。血圧値１１０１が正常な範囲内であると判定した場合、処理をステップＳ８０７に進め、血圧値１１０１が正常な範囲内ではないと判定した場合、処理をステップＳ８０６に進める。

ステップＳ８０６では、スマートフォン１２０のＣＰＵ２０１が、自動車１３０のエンジンを掛けることができなかったことを示すエラー画面をディスプレイ２１０に表示する。例えば図１９に示すエンジン始動失敗画面１９００である。エンジン始動失敗画面１９００にはエンジンを始動することができなかった旨を示す表示１９０１が表示されている。これによりユーザはエンジンが始動することができなかったことを認識することができる。

ステップＳ８０７では、スマートフォン１２０のＣＰＵ２０１が、近距離無線通信を起動する。

ステップＳ８０８では、スマートフォン１２０のＣＰＵ２０１が、図１４に示すスマートフォン設定テーブル１４００の接続先ＩＤ２―１４０３が示す接続先の自動車１３０に接続要求を送信する。

ステップＳ８０９では、自動車１３０のＣＰＵ４０１が、スマートフォン１２０から送信される接続要求を受信する。

ステップＳ８１０では、自動車１３０のＣＰＵ４０１が、ステップＳ８０９で受信した接続要求が成功したことを示す接続ステータスをスマートフォン１２０に対して送信する。

ステップＳ８１１では、スマートフォン１２０のＣＰＵ２０１が、接続ステータスを受信する。

ステップＳ８１２では、スマートフォン１２０のＣＰＵ２０１が、エンジン始動要求を自動車１３０に対して送信する。

ステップＳ８１３では、自動車１３０のＣＰＵ４０１が、スマートフォン１２０から送信されたエンジン始動要求を受信する。

ステップＳ８１４では、自動車１３０のＣＰＵ４０１が、ドア管理テーブル１２００のドアＮｏ１２０１が「１」（運転席）に対応するスマートフォンＩＤ１２０２を参照する。

ステップＳ８１５では、自動車１３０のＣＰＵ４０１が、エンジン始動要求を送信したスマートフォン１２０のスマートフォンＩＤが、ステップＳ８１４で参照したスマートフォンＩＤ１２０２と一致するか否かを判定する。エンジン始動要求を送信したスマートフォン１２０のスマートフォンＩＤが、ステップＳ８１４で参照したスマートフォンＩＤ１２０２と一致すると判定した場合は、処理をステップＳ８１６に進める。エンジン始動要求を送信したスマートフォン１２０のスマートフォンＩＤが、ステップＳ８１４で参照したスマートフォンＩＤ１２０２と一致しないと判定した場合は処理をステップＳ８１７に進める。

このように自動車１３０のドアの鍵を開けるよう開錠指示を行ったスマートフォン１２０とは異なるスマートフォン１２０でエンジンの始動要求を行った場合、エンジンを始動させないようにすることができる。これにより、運転に適さない状態のユーザが自動車１３０の鍵を開けたあと、運転に適さない状態のユーザと同乗する運転に適する状態のユーザが代わりにエンジンを始動させることを防止することができる。

ステップＳ８１６では、自動車１３０のＣＰＵ４０１が、エンジンを始動させるよう制御する。

ステップＳ８１７では、自動車１３０のＣＰＵ４０１が、エンジンを始動させず、エラー表示を自動車１３０の表示部（不図示）に表示させる。

ステップＳ８１８では、自動車１３０のＣＰＵ４０１が、ステップＳ８１６またはステップＳ８１７の結果（エンジンを始動できたか否かを示す情報）をスマートフォン１２０に対して送信する。

ステップＳ８１９では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ８１６またはステップＳ８１７の結果（エンジンを始動できたか否かを示す情報）を受信する。

ステップＳ８２０では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ８１９で受信した結果に基づいてエンジンの始動が成功したか否かを判定する。エンジンの始動が成功したと判定した場合には処理をステップＳ８２１に進める。エンジンの始動が成功していないと判定した場合には処理をステップＳ８２２に進める。

ステップＳ８２１では、スマートフォン１２０のＣＰＵ２０１が、エンジンの始動が成功したことを示す表示をディスプレイ２１０に表示させる。例えば図１８に示すエンジン始動成功画面１８００である。エンジン始動成功画面１８００にはエンジンが動作していることを示す表示１８０１とエンジンが開始したことを示す表示１８０２を表示する。

ステップＳ８２２では、スマートフォン１２０のＣＰＵ２０１が、エンジンの始動に失敗したことを示す表示であるエンジン始動失敗画面１９００をディスプレイ２１０に表示する。エンジン始動失敗画面１９００にはエンジンの始動ができなかった旨の表示１９０１が表示される。

以上で、図８に示すフローチャートの説明を終了する。

次に図９に示すフローチャートを用いて、図６に示す個別ドア制御処理の詳細な処理の流れを説明する。個別ドア制御処理は、自動車１３０の鍵を個別に制御する処理である。例えば、助手席の鍵だけを開ける指示などを行うことができる。

ステップＳ９０１では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ７２２で表示した個別ドア制御画面２０００のドアの領域（１７０１乃至１７０５）の押下を受け付けたか否かを判定する。運転席である１７０１の押下を受けつけたと判定した場合は処理をステップＳ９０２に進め、それ以外のドアの押下を受け付けたと判定した場合は処理をステップＳ９０７に進める。このように運転席の開錠指示の場合にのみ、ユーザの健康状態によって運転席を開錠するか否かを判定する。荷物の積みおろしの際に健康状態によってドアが開けられなくなるということを防ぐ効果がある。

ステップＳ９０２では、スマートフォン１２０のＣＰＵ２０１が、スマートフォン血圧値テーブル１１００の血圧値取得時間１１０２を参照する。

ステップＳ９０３では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ９０２で参照した血圧値取得時間１１０２が所定の時間（本発明の実施形態では１０分とするが、これに限定されない）を超えているか否かを判定する。所定の時間を超えていると判定した場合、処理をステップＳ６１１に戻す。所定の時間を超えていないと判定した場合は処理をステップＳ９０４に進める。

ステップＳ９０４では、スマートフォン１２０のＣＰＵ２０１が、スマートフォン血圧値テーブル１１００の血圧値１１０１を取得する。

ステップＳ９０５では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ９０４で取得した血圧値１１０１が正常な範囲内か否かを判定する。より具体的には血圧値１１０１が血圧指標値１３０１を超えている場合に正常な範囲内ではないと判定する。ステップＳ９０４で取得した血圧値１１０１が正常な範囲内ではない（血圧指標値１３０１を超えている）と判定した場合、処理をステップＳ９０６に進め、ステップＳ９０４で取得した血圧値１１０１が正常な範囲内である（血圧指標値１３０１を超えていない）と判定した場合、処理をステップＳ９０７に進める。

ステップＳ９０６では、スマートフォン１２０のＣＰＵ２０１が、血圧値が血圧指標値を超えている旨のエラー表示をディスプレイ２１０に表示する。

ステップＳ９０７では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ９０１でタッチされたと判定したドアに対応するドアオープン設定を設定する。具体的にはドアＮｏ１２０１に対するドアオープン設定を設定する。

ステップＳ９０８では、スマートフォン１２０のＣＰＵ２０１が、通信Ｉ／Ｆコントローラを通じて、近距離無線通信を起動する。

ステップＳ９０９では、スマートフォン１２０のＣＰＵ２０１が、図１４に示すスマートフォン設定テーブル１４００の接続先ＩＤ２―１４０３が示す自動車１３０に接続要求を送信する。

ステップＳ９１０では、自動車１３０のＣＰＵ４０１が、スマートフォン１２０から送信される接続要求を受信する。

ステップＳ９１１では、自動車１３０のＣＰＵ４０１が、ステップＳ９１０で受信した接続要求が成功したことを示す接続ステータスをスマートフォン１２０に対して送信する。

ステップＳ９１２では、スマートフォン１２０のＣＰＵ２０１が、接続ステータスを受信する。

ステップＳ９１３では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ９１２で接続が成功したことを示す接続ステータスを受信すると、ステップＳ９０７で設定したドアオープン設定と共にドアオープン指示を自動車１３０に対して送信する。

ステップＳ９１４では、自動車１３０のＣＰＵ４０１が、ステップＳ９１３で送信されたドアオープン設定とドアオープン指示を受信する。

ステップＳ９１５では、自動車１３０のＣＰＵ４０１が、ステップＳ９１４で受信したドアオープン設定に基づいてドアの鍵を制御する。より具体的には、ドアオープン設定に設定されたドアＮｏ１２０１に対応するドアの鍵を開けるよう制御する。対応するドアの鍵を開けると、ドア管理テーブル１２００のオープンフラグ１２０３を立てる。

ステップＳ９１６では、自動車１３０のＣＰＵ４０１が、ドアの開錠状態を示すドア管理テーブル１２００をスマートフォン１２０に対して送信する。

ステップＳ９１７では、スマートフォン１２０のＣＰＵ２０１が、ドア管理テーブル１２００を受信する。

ステップＳ９１８では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ９１７で受信したドア管理テーブル１２００を参照し、ステップＳ９０７で設定したドアのドアＮｏ１２０１のオープンフラグ１２０３が立っているか否かを判定する。オープンフラグ１２０３が立っていると判定した場合には処理をステップＳ９１９に進める。オープンフラグ１２０３が立っていないと判定した場合には処理をステップＳ９２０に進める。

ステップＳ９１９では、スマートフォン１２０のＣＰＵ２０１が、ディスプレイ２１０に表示される個別ドア制御画面２０００のステップＳ９０１で押下されたドアに対応する表示をドアが開いているよう表示を制御する。表示したのち、処理を終了する。例えば図２０の１７０１を１７０２のような状態に変化させる。これにより、ユーザはドアの鍵が開いたことを視認することができる。

ステップＳ９２０では、スマートフォン１２０のＣＰＵ２０１が、ステップＳ９０１で押下されたドアの開錠に失敗したことを示す通知をディスプレイ２１０に表示する。そののち、処理をステップＳ７０２に戻す。

以上で、図９に示すフローチャートの説明を終了する。

以上、本発明によれば、ユーザの健康状態が運転に適さない場合に運転が行われることを防止しつつも、適切に鍵の開閉を制御することが出来る仕組みを提供することを可能にする。

本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１１０ ウェアラブルデバイス
１２０ スマートフォン
１３０ 自動車
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ ＨＤＤ
２０５ システムバス
２０６ 入力コントローラ
２０７ 出力コントローラ
２０８ ネットワークコントローラ
２０９ タッチパネル
２１０ ディスプレイ
２１３ 近距離無線通信
３０１ ＣＰＵ
３０２ ＲＯＭ
３０３ ＲＡＭ
３０４ システムバス
３０５ 入力コントローラ
３０６ 出力コントローラ
３０７ 通信Ｉ／Ｆコントローラ
３０８ 血圧センサ
３０９ 発光ダイオード（ＬＥＤ）
３１０ 近距離無線通信
４０１ ＣＰＵ
４０２ ＲＯＭ
４０３ ＲＡＭ
４０４ システムバス
４０５ 出力コントローラ
４０６ 通信Ｉ／Ｆコントローラ
４０７ ドア鍵制御装置
４０８ エンジン制御装置
４０９ 近距離無線通信

Claims (10)

1. 複数のドアを備えた車両と、ユーザの健康状態を取得する健康状態取得装置と、前記車両と前記健康状態取得装置と通信可能な鍵制御装置とを備えた鍵制御システムであって、
   前記健康状態取得装置から、前記ユーザの健康状態を取得する健康状態取得手段と、
   前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たす場合には、前記複数のドアのいずれの鍵も開くように制御し、前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たさない場合には、前記運転席以外のドアの鍵を開くように制御する制御手段と、
   を備えていることを特徴とする鍵制御システム。
2. ユーザから前記車両のドアの鍵を開く指示を受け付ける受付手段を更に備え、
   前記制御手段は、前記受付手段で指示を受け付けた際に、ドアの鍵を開く制御を行うことを特徴とする請求項１に記載の鍵制御システム。
3. 前記車両のエンジンを開始する指示を受け付ける開始指示受付手段を更に備え、
   前記制御手段は、前記開始指示受付手段でエンジンを開始する指示を受け付けた際に、前記健康状態取得手段で取得した前記ユーザの健康状態が所定の条件を満たさない場合にはエンジンを始動させず、当該健康状態が所定の条件を満たす場合にはエンジンを始動させるよう制御すること
   を特徴とする請求項１または２に記載の鍵制御システム。
4. 前記所定の条件とは、ユーザの健康状態が運転に適する条件であることを特徴とする請求項１乃至３のいずれか１項に記載の鍵制御システム。
5. 前記健康状態取得装置で取得される健康状態は、ユーザの血圧値、脈拍数、体温、血液の血糖値、赤血球、ヘモグロビンの濃度のうち、少なくとも１つのいずれかであることを特徴とする請求項１乃至４のいずれか１項に記載の鍵制御システム。
6. 複数のドアを備えた車両と、ユーザの健康状態を取得する健康状態取得装置と、前記車両と前記健康状態取得装置と通信可能な鍵制御装置とを備えた鍵制御システムの制御方法であって、
   前記鍵制御システムが、
   前記健康状態取得装置から、前記ユーザの健康状態を取得する健康状態取得ステップと、
   前記健康状態取得ステップで取得した前記ユーザの前記健康状態が所定の条件を満たす場合には、前記複数のドアのいずれの鍵も開くように制御し、前記健康状態取得ステップで取得した前記ユーザの前記健康状態が所定の条件を満たさない場合には、前記運転席以外のドアの鍵を開くように制御する制御ステップと、
   を備えていることを特徴とする鍵制御システムの制御方法。
7. 複数のドアを備えた車両と、ユーザの健康状態を取得する健康状態取得装置と、前記車両と前記健康状態取得装置と通信可能な鍵制御装置とを備えた鍵制御システムで実行可能なプログラムであって、
   前記鍵制御システムを、
   前記健康状態取得装置から、前記ユーザの健康状態を取得する健康状態取得手段と、
   前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たす場合には、前記複数のドアのいずれの鍵も開くように制御し、前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たさない場合には、前記運転席以外のドアの鍵を開くように制御する制御手段
   として機能させることを特徴とするプログラム。
8. 複数のドアを備えた車両と、ユーザの健康状態を取得する健康状態取得装置と、前記車両と前記健康状態取得装置と通信可能な鍵制御装置であって、
   前記健康状態取得装置から、前記ユーザの健康状態を取得する健康状態取得手段と、
   前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たす場合には、前記複数のドアのいずれの鍵も開くように制御し、前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たさない場合には、前記運転席以外のドアの鍵を開くように制御する制御手段と、
   を備えていることを特徴とする鍵制御装置。
9. 複数のドアを備えた車両と、ユーザの健康状態を取得する健康状態取得装置と、前記車両と前記健康状態取得装置と通信可能な鍵制御装置の制御方法であって、
   前記鍵制御装置が、
   前記健康状態取得装置から、前記ユーザの健康状態を取得する健康状態取得ステップと、
   前記健康状態取得ステップで取得した前記ユーザの前記健康状態が所定の条件を満たす場合には、前記複数のドアのいずれの鍵も開くように制御し、前記健康状態取得ステップで取得した前記ユーザの前記健康状態が所定の条件を満たさない場合には、前記運転席以外のドアの鍵を開くように制御する制御ステップと、
   を備えていることを特徴とする鍵制御装置の制御方法。
10. 複数のドアを備えた車両と、ユーザの健康状態を取得する健康状態取得装置と、前記車両と前記健康状態取得装置と通信可能な鍵制御装置で実行可能なプログラムであって、
    前記鍵制御装置を、
    前記健康状態取得装置から、前記ユーザの健康状態を取得する健康状態取得手段と、
    前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たす場合には、前記複数のドアのいずれの鍵も開くように制御し、前記健康状態取得手段で取得した前記ユーザの前記健康状態が所定の条件を満たさない場合には、前記運転席以外のドアの鍵を開くように制御する制御手段
    として機能させることを特徴とするプログラム。

Images