JP2020061163A - 車両遠隔制御システム、車載器、車両、サーバ、車両遠隔制御方法、車両遠隔制御プログラム及び記憶媒体 - Google Patents

Abstract

【課題】税金、保険、車検等の情報提供サービスから得られる情報が限られている条件の中でも、税金、保険、車検及び車両規制等の問題に対処し得る車両遠隔制御システム、車載器、車両、サーバ、車両遠隔制御方法、車両遠隔制御プログラム及び記憶媒体を提供する。【解決手段】本発明の実施形態の車両遠隔制御システムは、車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御する車載器と、前記車両情報に基づき前記車両のユーザに対する義務に関する義務情報を演算するサーバと、からなる車両遠隔制御システムであって、前記サーバは、前記車両情報を入力する入力手段と、前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、前記義務情報に基づいて遠隔制御指令を出力する出力手段と、を有し、前記車載器は前記サーバから出力される前記遠隔制御指令に基づき制御されることを特徴とする。【選択図】図１

Description

本発明の実施形態は、車載器を搭載する車両に対して適用される車両遠隔制御システム、車載器、車両、サーバ、車両遠隔制御方法、車両遠隔制御プログラム及び記憶媒体に関するものである。

車両の規制を行う国や自治体にとって、車両のユーザの行動を管理することは難しく、違法ないし不適切な車両の運行がなされる状況があることが課題とされている。途上国においても車両の運行は、ユーザが収入を得るために重要な手段となっているが、必ずしも、この車両の運行が法令を遵守した運用になっていない場合もある。例えば、定められた各種税金を納付していない者でも自由に車両を使用できる状況が発生すると、税金未納者が納税を行わない状況が放置されるおそれがあるうえ、車両を使用している納税者にとっては納税義務に対する意識が希薄になりかねない。

また、ユーザに車両の保険への加入を法令により義務づけている場合でも、保険未加入であっても車両を運転可能な状況であると、保険未加入者による車両の運行を効果的に阻止することは難しい。

また、ユーザに車両の定期点検（以下「車検」という。）を義務づけている場合でも、未車検の車両が運行可能な状態であると、ユーザが車検を受けないままの状態が放置されるおそれがある。

また、法令により、ナンバープレートのナンバーに応じて特定エリアへの車両の進入を規制する場合でも、ユーザが規制を守る保証はなく、また、ユーザにその規制内容が周知されていなければ、特定エリアへの車両の進入を規制することは難しい。

近年では、車両の運行状況を監視したり、あるいは、車両を遠隔制御したりする技術が知られている。車両の運行を監視する技術としては、特許文献１〜特許文献３が挙げられる。特許文献１には、車両の走行状況、走行場所、走行時刻に応じて事故発生のリスクを定量化して収集する運行状況監視システムが記載されている。

特許文献２には、車両の形式、ユーザの等級や属性を基に、保険料を計算すると共に、車両の形式や位置データを基に、自動車取得税、自動車重量税等を計算する方法が記載されている。

特許文献３には、車両種別やナンバープレートのナンバー等による時間規制が行われている道路または区域を示す情報である通行規制情報に基づき、規制されている道路または区域を避ける経路を検索し、規制対象車両となってる場合には規制対象車両であること及び通行規制解除までの時間を報知するナビゲーション装置が記載されている。

車両を遠隔制御する技術としては、特許文献４及び特許文献５が挙げられる。特許文献４には、車両の起動不可状態と起動可能状態とを切り替える外部リレーを制御する車載器を、サーバからのリレー制御指令により遠隔制御する車両遠隔制御システムが記載されている。

特許文献５には、車検が無効な場合や免許証が無効な場合には、車両のエンジンの始動を禁止する手段を設けると共に、保険の適用の可否を表示する運転許可装置が記載されている。

特開２００４−２４０６８８号公報 特開２００４−２１３１６３号公報 特開２０１０−２０４００１号公報 特許第６２３８０３８号公報 特開２０１７−０４３１９０号公報

特許文献１〜特許文献３の技術では、車両の運行を監視するものではあるが、車両を遠隔制御するものではない。特許文献１のシステムでは、事故発生のリスクを定量化して収集することはできるが、車両の遠隔制御を行うことはできないシステムであり、また、特許文献１には、このリスクをどのように活用するかまでは記載されいない。

特許文献２の方法では、保険料の計算や、自動車取得税、自動車重量税等の計算はできるが、車両の遠隔制御を行うものではなく、また、特許文献２には保険料や税金の納付を促進することまでは記載されていない。

特許文献３の装置では、規制対象車両となってる場合には規制対象車両であること及び通行規制解除までの時間が報知されるが、車両の遠隔制御を行うものではないため、規制対象車両となっている場合にも当該車両の運行が可能となってしまう。

また、特許文献４のシステムでは、車両の起動不可状態と起動可能状態とを遠隔制御により切り替えるものであり、車両のリース料金やレンタル料金の支払いに応じた車両の起動不可状態と起動可能状態との切り替えについては実現可能であるが、特許文献４には、税金や保険や車検や車両規制等の問題についてまでは記載されていない。

また、特許文献５の装置では、免許証がＩＣ運転免許証である必要があると共に、車検協会が正確な車検情報を一元管理していることが必須の条件となるが、例えば途上国の状況を踏まえた場合、必ずしもＩＣ運転免許証の普及や、車検情報の一元管理が望めない場合もある。

このような従来の問題点に鑑み、本願の実施形態の課題は、税金、保険、車検等の情報提供サービスから得られる情報が限られている条件の中でも、税金、保険、車検及び車両規制等の問題に対処し得る車両遠隔制御システム、車載器、車両、サーバ、車両遠隔制御方法、車両遠隔制御プログラム及び記憶媒体を提供することにある。

本発明の実施形態の課題は、以下の構成によって達成できる。すなわち、本発明の第１の態様の車両遠隔制御システムは、
車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御する車載器と、
前記車載器から受信した前記車両情報に基づき前記車両のユーザに対する義務に関する義務情報を演算するサーバと、
からなる車両遠隔制御システムであって、
前記サーバは、
前記車載器により収集された前記車両情報を入力する入力手段と、
前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
を有し、
前記車載器は前記サーバから出力される前記遠隔制御指令に基づき制御されることを特徴とする。

また、本発明の第２の態様の車両遠隔制御システムは、前記サーバは、税金管理システムと通信可能であり、
前記義務情報は、ユーザの税金に関する情報を含み、
前記税金管理システムは、税金納付の有無を含む税金納付情報を前記サーバに提供することを特徴とする。

また、本発明の第３の態様の車両遠隔制御システムは、第２の態様の車両遠隔制御システムにおいて、前記義務情報演算手段は、前記入力手段により入力された前記車両情報に基づき前記ユーザの収入を予測する収入予測手段を備え、
前記収入予測手段において予測された前記ユーザの収入は、前記義務情報演算手段及び／又は前記税金管理システムにおいて税金額に関する演算に用いられることを特徴とする。

また、本発明の第４の態様の車両遠隔制御システムは、第１の態様の車両遠隔制御システムにおいて、前記サーバは、保険管理システムと通信可能であり、
前記義務情報は、保険料に関する情報を含み、
前記保険管理システムは、保険料納付の有無を含む保険料納付情報を前記サーバに提供することを特徴とする。

また、本発明の第５の態様の車両遠隔制御システムは、第４の態様の車両遠隔制御システムにおいて、前記入力手段により入力された前記車両情報は、前記義務情報演算手段及び／又は前記保険管理システムにおいて前記保険料に関する演算に用いられることを特徴とする。

また、本発明の第６の態様の車両遠隔制御システムは、第１の態様の車両遠隔制御システムにおいて、前記義務情報は、前記車両の車検に関する車検情報を含み、
前記義務情報演算手段は、前記車検情報に基づき前記車両の車検が有効であるか否かを判断することを特徴とする。

また、本発明の第７の態様の車両遠隔制御システムは、第６の態様の車両遠隔制御システムにおいて、前記車両情報には前記車検情報が含まれ、前記車載器により収集された前記車検情報は、前記サーバに送信されることを特徴とする。

また、本発明の第８の態様の車両遠隔制御システムは、第６又は第７の態様の車両遠隔制御システムにおいて、前記サーバは、車検管理システムとの間で、前記車検情報を通信可能であることを特徴とする。

また、本発明の第９の態様の車両遠隔制御システムは、第１の態様の車両遠隔制御システムにおいて、前記義務情報は車両規制に関する車両規制情報を含み、
前記サーバには、車両規制データベースから前記車両規制情報が提供され、
前記車両情報には、少なくとも前記車両の位置情報、及び、前記車両の属性情報が含まれることを特徴とする。

また、本発明の第１０の態様の車載器は、
車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御し、かつ、前記車両のユーザに対する義務に関する義務情報を演算するサーバに前記車両情報を送信する車載器であって、
前記サーバは、
前記車載器により収集された前記車両情報を入力する入力手段と、
前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
を有し、
前記サーバから出力される前記遠隔制御指令に基づき制御されることを特徴とする。

また、本発明の第１１の態様の車両は、第１０の態様の車載器を備えることを特徴とする。

また、本発明の第１２の態様のサーバは、
車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御する車載器から受信した前記車両情報に基づき前記車両のユーザに対する義務に関する義務情報を演算するサーバであって、
前記車載器により収集された前記車両情報を入力する入力手段と、
前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
を有し、
前記遠隔制御指令に基づき前記車載器を制御することを特徴とする。

また、本発明の第１３の態様の車両遠隔制御方法は、
車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御する車載器から受信した前記車両情報に基づき前記車両のユーザに対する義務に関する義務情報を演算する車両遠隔制御方法であって、
前記車載器により収集された前記車両情報を入力する入力手段と、
前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
を有し、
前記遠隔制御指令に基づき前記車載器を制御することを特徴とする。

また、本発明の第１４の態様の車両遠隔制御プログラムは、第１３の態様の車両遠隔制御方法の各手段をコンピュータによって実行することを特徴とする。

また、本発明の第１５の態様の記憶媒体は、第１４の態様の車両遠隔制御プログラムを記憶したことを特徴とする。

本発明の第１の態様の車両遠隔制御システムによれば、税金、保険、車検等の情報提供サービスから得られる情報が限られている条件の中でも、税金、保険、車検及び車両規制等の問題に対処し得る車両遠隔制御システムを提供することができる。

本発明の第２の態様の車両遠隔制御システムによれば、税金納付の有無に応じて車両を起動可能状態ないし起動不可状態に切り替える制御を行うことができる。

本発明の第３の態様の車両遠隔制御システムによれば、サーバにおいて車両情報からユーザの収入額を予測し、この予測された収入額に応じた税金額を税金管理システムが把握することができる。

本発明の第４の態様の車両遠隔制御システムによれば、保険料納付の有無に応じて車両を起動可能状態ないし起動不可状態に切り替える制御を行うことができる。

本発明の第５の態様の車両遠隔制御システムによれば、車両情報から保険料を演算することにより、保険管理システムにおいて車両情報に対応して適切な保険料を把握することができる。

本発明の第６の態様の車両遠隔制御システムによれば、車検が有効であるか否かに応じて車両を起動可能状態ないし起動不可状態に切り替える制御を行うことができる。

本発明の第７の態様の車両遠隔制御システムによれば、車載器において車検情報を収集することができる。

本発明の第８の態様の車両遠隔制御システムによれば、車載器において収集された車検情報を車検管理システムに提供することができる。また、車検管理システムが有する車検情報をサーバに提供することができる。

本発明の第９の態様の車両遠隔制御システムによれば、車両情報に含まれる位置情報及び車両の属性情報、例えば車両のナンバープレートの番号等と、車両規制データベースの車両規制情報とから、車両が規制対象かどうか判断して、この判断結果に応じて車両を起動可能状態ないし起動不可状態に切り替える制御を行うことができる。

本発明の第１０の態様の車載器によれば、税金、保険、車検等の情報提供サービスから得られる情報が限られている条件の中でも、税金、保険、車検及び車両規制等の問題に対処し得る車載器を提供することができる。

本発明の第１１の態様の車両によれば、第１０の態様の車載器と同様の効果を奏する車両を提供することができる。

本発明の第１２の態様のサーバによれば、税金、保険、車検等の情報提供サービスから得られる情報が限られている条件の中でも、税金、保険、車検及び車両規制等の問題に対処し得るサーバを提供することができる。

本発明の第１３の態様の車両遠隔制御方法によれば、税金、保険、車検等の情報提供サービスから得られる情報が限られている条件の中でも、税金、保険、車検及び車両規制等の問題に対処し得る車両遠隔制御方法を提供することができる。

本発明の第１４の態様の車両遠隔制御プログラムによれば、第１３の態様の車両遠隔制御方法と同様の効果を奏する車両遠隔制御プログラムを提供することができる。

本発明の第１５の態様の記憶媒体によれば、第１３の態様の車両遠隔制御方法と同様の効果を奏する車両遠隔制御プログラムを記憶した記憶媒体を提供することができる。

本発明の第１実施形態に係る車両遠隔制御システムの全体図である。 車載器とその配線の説明図である。 与信情報演算のフロー図である。 リレー値の説明図であり、図４Ａは起動制御線が１本の車種の場合の説明図であり、図４Ｂは起動制御線が２本の車種の場合の説明図である。 リレーの配線の説明図である。 メモリ内の構成の説明図である。 リレー制御部のフローチャートである。 リレー監視部のフローチャートである。 エンジン連動制御部のフローチャートである。 車種ごとの起動不可状態の説明図である。 本発明の第２実施形態に係る車両遠隔制御システムの全体図である。 車両起動制御のフロー図である。

以下、図面を参照して本発明の実施形態に係る車両遠隔制御システム、車載器、車両、サーバ、車両遠隔制御方法、車両遠隔制御プログラム及び記憶媒体について説明する。但し、以下に示す各実施形態は本発明の技術思想を具体化するための車両遠隔制御システム、車載器、車両、サーバ、車両遠隔制御方法、車両遠隔制御プログラム及び記憶媒体を例示するものに過ぎず、本発明をこれらに特定するものではなく、特許請求の範囲に含まれる他の実施形態のものにも等しく適用し得るものである。

[実施形態１]
実施形態１に係る車両遠隔制御システムを図１〜図１０を用いて説明する。図１は、車両遠隔制御システムの全体図である。ユーザに提供される車両２には、車載器１が設置されている。サーバ３は車載器１と通信して各車両を管理する。サーバ３は、送受信部３３、遠隔制御指示部３１、車両情報収集部３２及び義務情報演算手段７１を備えている。

車載器１は、１台の車両に１個設置される。車載器１の車両への設置場所は、車両のどの場所でも構わない。車載器１が後付けの場合には、助手席のシートの下等の設置作業が容易な場所に配置することができる。また、盗難防止の観点から、車載器１を取り外しにくい場所、例えばエンジンルームの下部やインパネの内部に配置することもできる。さらには、車載器１を車両２の製造時に予め内蔵しておくこともできる。車載器１は、車両情報検出手段により収集した車両２の車両情報を、無線通信ネットワーク３４を介してサーバ３に送信すると共に、サーバ３から無線通信ネットワーク３４を介して遠隔制御指令としてのリレー制御信号を受信して、後述する車両２の外部リレー２０（図２参照）を制御する。なお、車載器１は、データ通信モジュール（Data Communication Module、以下「ＤＣＭ」という。）として構成されていてもよい。

以下、図２を参照して車両情報について説明する。図２は車載器１と車両２との配線説明図である。車両情報には、例えば、車両２に搭載されたＧＰＳ２４からの位置情報、外部バッテリ２１の電源入力の情報、及び、走行状態識別線（ＡＣＣ線、ＩＧ線）２２からのＩＧＮ入力情報だけではなく、図示省略されているが、車両２の起動状態を制御する外部リレー２０の情報、速度情報、タコメータの情報、タコグラフの情報、ドアロックの情報、イモビライザーの情報、エンジンスタートボタンの情報、タクシーの料金メータの情報、アクセルペダルの踏み込み量の情報（例えばスロットルバルブの開度の情報等も含む。以下、同様。）、電子ナンバープレート情報、ナビゲーションシステムの情報（例えば位置情報ないし経路情報等）、車載記憶手段の情報、及び、その他車両の稼働状況を把握できる各種情報等が含まれる。外部リレー２０を制御することにより、車両の起動不可状態と起動可能状態とを切り替えることができる。内燃機関自動車の場合、起動不可状態ではエンジンを始動することができず（起動中のエンジンを切るものではなく、エンジンの再始動を禁じるものである。）、起動可能状態ではエンジンを始動することができる。送受信部３３は無線通信ネットワーク３４を介して、複数の車載器１と無線通信を行うことができる。ここで、無線通信ネットワーク３４としては任意のものでよく、例えば２Ｇ、３Ｇ、４Ｇ、５Ｇ、Ｗｉ−Ｆｉ（登録商標）、ＷｉＭＡＸ（登録商標）、無線ＬＡＮ、ビーコン、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）等が挙げられる。

サーバ３は、車載器１に対して遠隔制御指令としてリレー制御指令を生成する遠隔制御指示部３１、車載器１からの車両情報を収集する車両情報収集部３２、及び、車載器１との間でデータの送受信を行う送受信部３３を備えている。また、サーバ３は入力手段としての車両情報収集手段３２により収集された車両情報に基づいて義務情報を演算するための義務情報演算手段７１を備えている。義務情報演算手段７１で演算された義務情報に基づき、出力手段としての遠隔制御指令部３１は、送受信部３３及び無線通信ネットワーク３４を介して、遠隔制御指令を車載器１へ出力する。また、義務情報演算手段７１は、後述の収入予測部６１を備えていてもよい。また、サーバ３は、管理者端末３５、税金管理システム８１、保険管理システム８２、車検管理システム８３、車両規制データベース８４、及び、ユーザ端末３７と接続されている。ユーザ端末３７は例えばパーソナルコンピュータ（以下「ＰＣ」という。）や携帯電話やスマートフォン等からなる。管理者端末３５は、管理者に情報を表示するためのディスプレーと、管理者からの情報を入力する情報入力手段を備えており、例えばＰＣ、タブレット端末、携帯端末等からなる。情報入力手段としては、タッチパネル式ディスプレー、キーボード、マウス等を用いることができ、タッチパネル式ディスプレーの場合には別途のキーボード等を省略できる。

後述のように、義務情報演算手段７１で演算された義務情報の一部は税金管理システム８１、保険管理システム８２、車検管理システム８３、車両規制データベース８４へ入力されると共に、税金管理システム８１、保険管理システム８２、車検管理システム８３、車両規制データベース８４から出力される情報は、義務情報演算手段７１でのさらなる義務情報の演算に用いることができる。例えば、税金管理システム８１からはユーザの税金納付の有無を含む税金納付情報が出力され、また、保険管理システム８２からはユーザの保険料納付の有無を含む保険料納付情報を出力される。車載器１は電子ナンバープレート等から車検情報を収集し、車両情報をサーバ３に送信することにより、サーバ３の義務情報演算手段７１では車検が有効であるか否かを判断することができ、この車検に関する情報は、車検管理システム８３に提供することができる。あるいは、例えば車検管理システム８３において一元的に車検情報が管理されている場合等には、サーバ３は車検管理システム８３から車検情報を得ることも可能である。義務情報演算手段７１は、サーバ車両規制データベース８４から取得された車両規制情報及び車載器１から収集された車両情報から、車両規制に関する車両規制情報を把握することができる。

サーバ３は、車載器１から定期的に受信する車両情報から車両の稼働状況を把握することができる。サーバ３は、車載器１から車両情報を受信することにより、必要に応じて、駐車状況、すなわち、所定の駐車場に車両を駐車中であるか、所定の駐車場以外の場所に車両を駐車中であるか、車両２の稼働状況、車両２による通勤での使用状況、車両２がタクシーである場合には車両２の稼働状況、車両２が営業用車両である場合には車両２の稼働状況、車両２が運送用車両である場合には車両２の稼働状況、車両２が建設機械である場合には車両２の稼働状況、及び、車両が盗難された可能性を示す情報等を把握することができる。収入予測部６１では後述のように、これらの車両２の稼働状況から各ユーザの収入を予測することができ、この予測された収入に関する情報、あるいは、予測された収入に基づく税金に関する情報は、税金管理システムに提供される。また、車両情報から保険料金に関する情報を得ることができるため、この保険料金に関する情報は、保険管理システムに提供される。

対応する車両を起動可能状態ないし起動不可状態へ変更するか否かの判断、後述の車両の運行状態の判断、後述の盗難発生時や異常発生時のユーザへの問い合わせ及び警察への通報等は、サーバ３により自動的に行うようにしてもよいし、その一部又は全部を管理者がマニュアルで行うようにしてもよい。これらの判断をサーバ３により自動的に行う場合には、管理者の負担を軽減することが可能である。一方、これらの判断の一部又は全部を管理者がマニュアルで行うようにした場合には、サーバ３において複雑な条件判断を行う必要がないため、サーバ３の構成を簡略化できる。

サーバ３では、車両２の起動不可状態ないし起動可能状態への制御に際して、例えば、図３のような演算が行われている。ステップＣ１で演算がスタートする。ステップＣ２では、税金納付情報によりユーザによる税金納付があるか否かを判定し、イエスの場合にはステップＣ３へ進み、ノーの場合ステップＣ７へ進む。なお、ステップＣ２においては、併せて、ユーザの収入予測や税金額を税金管理システム８１に提供することができる。ステップＣ３では、保険料納付情報によりユーザによる保険料納付があるか否かを判定し、イエスの場合にはステップＣ４へ、ノーの場合にはステップＣ７へ進む。なお、ステップＣ３においては、併せて、ユーザの保険料金に関する情報を保険管理システム８２に提供することができる。ステップＣ４では、車検が有効であるか否かを判定し、イエスの場合にはステップＣ５へ、ノーの場合にはステップＣ７へ進む。なお、ステップＣ４においては、併せて、車検情報を車検管理システム８３に提供することができる。ステップＣ５では、車両が車両規制対象でないことを確認し、イエスの場合、すなわち、車両規制対象でない場合には、ステップＣ６へ進み、ノーの場合、すなわち、車両規制対象である場合には、ステップＣ７へ進む。ステップＣ６では、車両２は、起動可能状態となるように制御される。一方、ステップＣ７では、車両２は、起動不能状態となるように制御される。以下、各ステップについて詳細に説明する。

［税金に関する演算］
ステップＣ２では、義務情報演算手段７１の収入予測演算手段７２においてユーザの収入を予測し、この予測した収入額に基づいて、義務情報演算手段７１において、税金、例えば所得税の金額を計算し、税金管理システムに出力することができる。車両情報収集部３２では、車載器１から無線通信ネットワーク３４及び送受信部３３を介して、車両２の車両情報を収集し、この車両情報は、義務情報演算手段７１に送信され、収入予測部６１に提供される。車両情報には、例えば、車両２に搭載されたＧＰＳ２４からの位置情報、外部バッテリ２１の電源入力の情報、及び、走行状態識別線（ＡＣＣ線、ＩＧ線）２２からのＩＧＮ入力情報だけではなく、図示省略されているが、車両２の起動状態を制御する外部リレー２０の情報、速度情報、タコメータの情報、タコグラフの情報、ドアロックの情報、イモビライザーの情報、エンジンスタートボタンの情報、タクシーの料金メータの情報、アクセルペダルの踏み込み量の情報（例えばスロットルバルブの開度の情報等も含む。以下、同様。）、電子ナンバープレート情報、ナビゲーションシステムの情報（例えば位置情報ないし経路情報等）、車載記憶手段の情報、及び、その他車両の稼働状況を把握できる各種情報等が含まれるため、収入予測演算手段７２では、この車両情報を用いて、ユーザの収入を予測することができる。

例えば、車両が運送用トラックのである場合には、車両の稼働時間が長いことは運送に係る受注が順調であることを示すため、車両の稼働時間をユーザの収入と関連する指標として収入を予測することができる。また、車両の稼働時間の全てが積み荷を運ぶための走行とは限らない。そこで、ＧＰＳによる位置情報やタコグラフの情報を併せて分析すれば、特定の配送ルートを把握でき、収入に結び付く車両の稼働状況を分析することが可能である。また、複数の車載器１から収集された車両情報を、車両やユーザの区分ごとに分析することにより、各車両のさまざま稼働状況の中から収入に結び付く車両の稼働状況をより適切に把握することができるようになる。なお、サーバ３は税金管理システム８１に接続されているため、ユーザの税金及び収入に関する情報を入手するできる場合もあり、これらの情報は収入予測部６１におけるユーザの収入予測に用いることもできる。例えば、サーバ３においては、過去の税金及び収入に関する情報は税金管理システム８１から入手可能である。

多数の車載器１からの膨大な車両情報を分析するためには、ＡＩを用いた機械学習を用いることも有用である。車両情報収集部３２において収集された車両情報と、これに関連したユーザの収入情報（例えば、過去の税金及び収入に関する情報は税金管理システム８１から入手可能である。）とにより、教師あり学習によってＡＩを学習することにより、収入予測部における収入情報の予測精度を向上すことが可能である。また、車両の車両情報とユーザとの収入との間には、車両２及びユーザのカテゴリーに応じて、さまざまな相関があり、統計分析が可能なものもある。これらの統計分析の結果をＡＩによる学習に利用することにより、より収入情報の予測精度を向上することができる。機械学習に使われるアルゴリズムとしては、例えばニューラルネットワークを用いることができ、特に、ディープラーニングを採用することも可能である。車両情報は時系列データであることから、例えば再帰型ニューラルネットワークを用いることができる。

また、収入情報には、税金の計算に必要となる経費に関する情報も含まれる。ユーザの所得税は、収入情報に従って、経費情報も考慮されたうえで、演算される。ここでは、収入予測部６１が収入情報を演算するものとして説明したが、収入予測部６１が独立したものである必要はない。義務情報演算手段７１において、車両情報に基づく所得税演算を一体的に行うこと、例えば、車両情報に基づいてＡＩによる機械学習によって、所得税を演算するようにすることもできる。

義務情報演算手段によって演算される税金は、所得税だけに限定されるものでは無い。例えば、自動車税、自動車取得税、自動車重量税等の車両２に関する税金も演算することが可能である。また、車両情報には例えばＧＰＳからの位置情報や経路情報、電子ナンバープレートからの登録情報等も含まれていることから、車両２の管理場所が把握できる。車両２に関する税金が地方税である場合には、自動車の登録場所ないし管理場所における税金が計算され、その税金の納付先も決定される。電子ナンバープレートの登録情報、車検情報等により車両２のカテゴリー、大きさ、重量、登録日、車両装備品、所有者及び使用者等の情報が把握されているため、自動車税、自動車取得税、自動車重量税等を正確に計算することができる。電子ナンバープレートの登録情報、車検情報等には、車両２の所有者、使用者、納税義務者等の情報、すなわちユーザの情報も含まれているため、常に車両２のユーザを正確に特定することが可能であり、税金額だけではなく、納税義務者を正確に把握することも可能である。また、車両２に関する税金を従量制とすること、すわなち、車両２の走行距離に応じた税額とすること等も可能となる。

サーバ３において、車両２のユーザの情報を把握できるため、例えばユーザに関する住民税等の計算をすることも可能である。さらに、サーバ３では、書類上の住所だけではなく、実際に、定常的に使用している駐車場の位置も把握できる。

さらに、法人が車両２を所有している場合には、車両２の車両情報から、法人税を予測することも可能である。例えば、法人がタクシー会社、運送会社等の場合には、車両２の車両情報から法人の売り上げが予想できるため、収入予測部６１においては法人の売り上げを予測し、この金額から法人税を演算することが可能である。なお、ここでは税金に関する演算に着目したが、サーバ３においては、法人が所有している各車両の車両情報を収集して把握することが可能である。このため、例えばタクシー会社においては、各車両のドライバーの売り上げを正確に把握することができ、これにより各ドライバーに対する適切な給与計算も可能となる。

義務情報演算手段７１において演算された税金情報は、税金管理システム８１に提供される。税金管理システム８１においては、義務情報演算手段７１から提供された税金情報を用いて、納税義務者に対する課税管理を行う。納税管理システム８１において、義務情報演算手段７１から提供された税金情報を利用できる範囲は、車両２やユーザのカテゴリーによっても異なる。例えば、車両２がタクシー、運送用トラック、建設機械等である場合には、かなり正確にユーザの収入を予測できるため、ユーザの所得税を正確に演算できる。実際のユーザによる納税額と義務情報演算手段７１で演算された当該ユーザに対する税金の金額とが異なっている場合には、税金管理システム８１において納税義務者による納税に誤りがある可能性を把握することができる。例えば税務署の担当者は、税金管理システム８１を用いることにより、納税義務者にもかかわらず税金の納付がないことや、納税額に誤りの可能性があることを把握することができるため、必要に応じて当該納税義務者による税金の納付を再確認することが可能となる。さらに、必要な場合には適切に税務調査等を行うことができる。特に途上国において、政府が住民や法人ないし団体等の収入状況を把握しにくい状況にあっては、車両２が普及している状況を鑑みると、車載器１から収集した車両情報に基づく税金額の把握は、政府にとって極めて有用である。

ここでは義務情報演算手段７１が所得税の金額などを含む税金情報を演算するものとして説明したが、本実施形態はこれに限定されるものではなく、例えば義務情報演算手段７１は、ユーザの収入情報を演算し、義務情報演算手段７１から税金管理システム８１へはこの収入情報を提供するようにしてもよく、この場合には税金管理システム８１において収入情報を基にユーザの所得税等の金額が演算される。また、税額演算の一部を義務情報演算手段７１において行うこととしもよく、この場合、サーバ３においては車載器１から収集した全ての車両情報を把握しているため、データに関する制約等がなく、より迅速な演算が可能となるケースがある。

税金管理システム８１を用いることにより政府は課税管理を容易かつ的確に行うことができる。政府が管理する住民、法人ないし団体等の戸籍情報、住民情報、登記情報、所得情報、収入情報及び資産情報等と、税金管理システム８１とを連携させることにより、税金管理システム８１によって、住民、法人ないし団体等に関する全ての種類の税金を管理することができる。したがって、税金管理システム８１は、車両２のユーザの全ての税金を把握すると共に、納税の有無を含む税金納税情報を管理することができる。サーバ３は、税金管理システム８１に接続されているため、ユーザの納税の有無を含む税金納税情報を取得することができる。納税管理システム８１への接続の方式は、特に限定されているものではないが、例えば納税管理システム８１にＡＰＩ（アプリケーション・プログラミング・インタフェース、Application Programing Interface）を設けることもできる。また、サーバ３側にもＡＰＩを設けておく場合には、税金管理システム８１からだけではなく、保険管理システム８２、車検管理システム８３、車両規制データベース８４からもサーバ３で管理する情報、例えば車両情報、収入情報、税金情報を、ＡＰＩを介して取得することが可能である。

義務情報演算手段７１では、税金管理システム８１から取得した税金納付情報により、ユーザの納税の有無を把握することができる。政府としては、納税を適切に行っていないユーザに対して税金の適切な納付を促す仕組みがあると有効である。そこで、ユーザの納税がない場合には、車両２を起動不可能状態とすることが考えられる。これは、図３において、ステップＣ２の判断がノーの場合である。ただし、何の猶予もなく突然に車両２が使用できなくなると、交通手段や収入を得るための手段が使えなくなることになるため、ユーザにとって酷な状況が予想される。そこで、ステップＣ２における税金納付無しの判断にあたっては、車両２のユーザに対して、ユーザ端末３７を介して、事前に所定の期間内に所定の税金納付を行わないと車両２を起動不可状態にする旨の警告を行い、所定の期間待って、それでも税金の納付がない場合には、車両２を起動不可状態に切り替えるようにしてもよい。また、税金の滞納金額が少額にもかかわらず一律に車両２を起動不可状態とすると、ユーザにとっては酷な状況ともなるため、滞納額が所定の金額を超えている場合にのみ、車両２を起動不可状態とするようにしてもよい。車両２の起動可能状態ないし起動不可状態の切替制御は、遠隔制御指令３１からの遠隔制御指令として、送受信部３３及び無線通信ネットワーク３４を介して車載器１に送られ、後述のように車両２の起動状態が制御される。なお、税金管理システムにおける税金の支払いの確認に、金融システム３６のＡＰＩ３９(図１１参照。)を用いるようにしてもよい。

図３では、ステップＣ２でイエスの場合には、ステップＣ３の保険料の判定を行うものとして説明されているが、これは単なる例示であり、各ステップの判断は、単独の判断であっても、あるいは、任意の２以上の判断であってもよく、さらには、この判断の順序は任意である。例えば、ステップＣ２の税金納付の判断だけで、イエスの場合にはステップＣ６へ進み、車両２を起動可能状態とし、ノーの場合にはステップＣ７へ進み、車両２を起動不可能状態としてもよい。また、２つの判断を行う例としては、ステップＣ２の税金納付についてのイエスの判定の後に、ステップＣ４へ進み、車検が有効であるか否かを判断し、イエスの場合には、ステップＣ６へ進み、車両２を起動可能状態とし、ステップＣ２でノーの場合あるいはステップＣ４でノーの場合には、ステップＣ７へ進み、車両２を起動不可能状態としてもよい。さらに、ここでは４種類の判定を例示したが、これ以外の判定を追加することもでき、例えば、車両２をリースする場合においては、リース料金の支払いの有無に関する判定を加えること（後述の実施形態２を参照）、また、例えば、車両２をレンタルする場合においては、レンタル料金の支払いの有無に関する判定を加えること、また、例えば、車両２をカーシェアリングする場合においては、車両利用料金の支払いの有無に関す判定を加えること等も可能である。

前述の収入予測部６１においては、車両２及びユーザのカテゴリーに応じて、さまざまな予測手法が採用されるところ、次に、この予測手法を（イ）〜（ホ）に例示する。また、前述のようにこれらの予測手法に対して機械学習を適用することにより、より正確な収入情報の予測が可能となる。

（イ）個人タクシーの例
車両が個人タクシーである場合には、賃走の区間が長い程、ユーザの収入が多いことが予想できる。例えば、タクシーメータが、「空車」「賃走」「回送」「迎車」の４種類からなる場合を説明するが、本発明はタクシーメータの形式を限定するものではなく、「賃走」に相当する区間を把握できるものであれば、どのような車両情報を用いてもかまわない。ここで各メータの表示と、収入の状態は次のとおりである。「空車」は、乗客を乗せていない場合であって、乗車が可能な状態である。この状態では収入は見込めない。「賃走」は、乗客を乗せて走っている状態で、収入が発生している状態である。この賃走の区間が長い程、収入が高くなる。「回送」は、運転手の仕事終わり車庫に帰る時や、休憩の時等で乗客を乗せられない状態である。この状態では収入は見込めない。「迎車」は予約の乗客を迎えに行くときであり、課金が可能であるため、収入が発生している状態である。賃走及び迎車の状態の走行時間及び走行距離を算出することにより、ユーザの収入を予測することが可能である。

また、より正確にユーザの収入を予測するためには、例えば、
・走行距離に対する空車率や賃走率を求めて、効率よく収入を得ることができているかを把握すること、
・営業運転状態（空車、賃走、迎車）の走行距離及び走行時間から、労働時間を把握すること、
・ＧＰＳの位置情報、速度情報、タコメータの情報、タコグラフの情報、アクセルペダルの踏み込み量の情報等を用いて、燃費を計算することにより経費を予測すること、
・ＧＰＳの位置情報、速度情報、タコメータの情報、タコグラフの情報等を用いて、ユーザが走行している地域の需要を予測すること、
等も可能である。

（ロ）運送用トラックの例
車両が運送用トラックである場合には、走行距離が長い方が輸送用トラックにより積み荷を搬送している区間が長いこと、すなわち、運送に係る受注が順調であることを示すため、走行距離は収入を予測する指標となる。また、ユーザが複数台の運送用トラックを所有する運送会社の場合には、各車両の稼働状況を把握することにより、ユーザの全体の収入を予測することができる。より正確にユーザの収入を予測するためには、例えば、
・走行距離や走行時間から、車両の稼働率を把握すること、
・ＧＰＳの位置情報を用いて、特定の配送ルートを運行しているかどうかを把握すること、
・ＧＰＳの位置情報、速度情報、タコメータの情報、タコグラフの情報、アクセルペダルの踏み込み量の情報等から、積み荷の状況、積み荷の量、積み荷の有無等を把握すること、
・ＧＰＳの位置情報、速度情報、タコメータの情報、タコグラフの情報、アクセルペダルの踏み込み量の情報等から、積み荷の状況を推定し、走行距離に占める積み荷の積載区間、あるいは、積み荷の積載率を把握すること、
・ＧＰＳの位置情報、速度情報、タコメータの情報、タコグラフの情報、アクセルペダルの踏み込み量の情報等を用いて、燃費を計算することにより経費を予測すること、
等も可能である。

（ハ）建設機械の例
車両がショベルカーやクレーン車等の建設機械の場合には、車両の稼働時間は車両が所定の作業のために利用されている期間を示すため、車両の稼働時間はユーザの収入を予測する指標となる。また、ユーザが複数の建設機械を所有する会社である場合には、各建設機械の稼働状況を把握することにより、ユーザの全体の収入を予測することができる。より正確に収入を予測するためには、例えば
・ＧＰＳの位置情報、速度情報、タコメータの情報、タコグラフの情報等から、待機位置から作業現場までの移動距離を把握すること、
・建設機械のアワーメーター情報、ＩＧＮ入力情報、エンジンスタートボタンの情報等から、特定の作業現場における作業期間や作業内容を把握すること、
・建設機械のアワーメーター情報、ＩＧＮ入力情報、エンジンスタートボタンの情報、燃料計情報等を用いて、燃費を計算することにより経費を予測すること、
等も可能である。

（ニ）通勤のために車両を利用する例
車両を通勤に利用しているユーザは、車両の稼働状況から通勤しているかどうかを判断できるため、車両の稼働状況はユーザの収入を予測する指標となる。ユーザは通勤以外にも車両を利用することもあるため、ユーザの収入をより正確に予測するためには、車両が通勤に利用されている状況を把握する必要がある。例えばＧＰＳの位置情報を用いれば、特定の駐車場から、出勤に関連する所定の場所（例えば職場の駐車場）までの車両の移動が出勤に関連するものであると把握することができる。

（ホ）営業用車両の例
車両が営業用車両の場合には、車両は専ら営業活動のために利用され、車両の稼働状況から営業活動の状況を判断できるため、車両の稼働状況はユーザの収入を予測する指標となる。また、例えばＧＰＳの位置情報を用いれば、営業活動を行っている地域や範囲を特定することもできるため、営業活動の状況をより正確に把握することも可能である。

ここでは義務情報演算手段７１が収入予測部６１を備える場合の例を説明したが、本実施形態はこれに限定されるものではなく、必ずしも収入予測部６１を有する必要はない。例えば、車両情報収集部３２で収集された車両情報を用いて、義務情報演算手段により義務情報を演算することも可能である。例えば上記（イ）の車両が個人タクシーである場合には、賃走の区間の長さがほぼユーザの収入を決定づけるため、賃走の合計距離データ等の車両情報から収入情報ないし税金情報を演算することができる。また、上記（ロ）の車両が運送用トラックである場合には、積み荷を積んで走行している走行距離等の車両情報から直接収入情報ないし税金情報を演算することができる。

また、税金管理システムにおいて税金額を演算する場合においては、税金管理システム８１に対して、サーバ３から収入情報ないし税金情報だけではなく、車両情報収集部３２で収集された車両情報を提供することも可能である。あるいは、税金管理システム８１において税金額を演算する場合においては、税金管理システム８１に対して、サーバ３から車両情報収集部３２で収集された車両情報だけを提供することも可能である。さらに、税金管理システム８１に対して、サーバ３からは情報提供を行わない場合もあり得るが、この場合、税金管理システムにおいて、ユーザの収入情報ないし税金情報の演算が行われる。すなわち、税金管理システム８１においてユーザの税金納付情報が適切に把握できている場合においては、サーバ３から税金管理システム８１の対しての情報提供は必須ではない。一方、税金管理システム８１からサーバ３に対しては、ユーザの税金の支払いの有無を含む税金納付情報が提供される。そして、例えばこの税金管理システム８１からサーバ３に対しての税金納付情報の提供がＡＰＩ連携により行われる場合には、サーバ３における義務情報演算手段７１において、迅速に納税の有無を判断することができるため、税金納付に伴う車両２の起動可能状態への切替制御を迅速に実施することが可能となる。

［保険料に関するの演算］
ステップＣ３では、義務情報演算手段７１においてユーザに対する車両２の保険情報が演算され、この保険情報が保険管理システム８２に提供される。保険情報としては、保険料に関する情報を含めることができる。車両２に関する保険には法令により強制的に加入が義務付けられるものと、任意加入のものとに分けられる。例えば、日本では、自賠責保険への加入が義務付けられており、さらに、任意保険への加入も推奨されている。例えば、途上国においても車両２に関する保険を義務付けている場合が多く、この場合、保険に未加入である車両２が運行されると、事故が起こった場合に被害者への補償がなされないおそれがあるため、保険に未加入の車両の運行を禁じることが望ましい。このような観点から、車両２に関する強制保険の保険料が納付されているかどうか、義務情報演算手段により判断し、所定の保険料が納付されていない場合には、遠隔制御指令部３１から車載器１に車両２を起動不可状態に切り替えるための遠隔制御指令を送信する必要がある。また、義務情報演算手段においては、任意保険の保険料金を含む保険情報を演算することも可能である。なお、強制的に加入が義務付けられる保険の範囲については、政府の定め、ないし、法令の定めによる。また、車両２についての保険は、車両２に掛けられる場合もあるが、車両２のユーザに掛けられる場合や、車両２とユーザ（運転者）との組み合わせに対して掛けられる場合もある。サーバ３においては、車両２の車両情報、及び、後述のユーザ情報管理部３８によるユーザ情報との両方を把握しているため、車両２に関する保険情報を適切に管理することが可能である。

そして、義務情報演算手段７１は、車両情報収集部３２で収集された車両情報を把握することができるため、この車両情報を利用したきめ細やかな保険料演算が可能となり、これにより、車両２のカテゴリーやユーザの使用状況に適した保険の設定が可能となる。保険料の演算に当たっては、例えば次のような情報を参酌することができる。
・車両のカテゴリー（車種、車両の大きさ、重量、用途）
・走行距離、走行時間
・走行速度、制限速度
・加速度
・位置情報、走行経路、走行時間帯

車両のカテゴリーに応じた保険料を設定することができる。例えば、車種、車両の大きさ、重量、用途に応じて、保険料を設定することができる。例えば、小型車と大型車とでは保険料の設定が異なり、また、自家用車、タクシー、配送用車両及び建築機械等の用途の違いによっても保険料の設定は異なる。

走行距離や走行時間によっても保険料の設定は異なる。例えば、車両２の走行距離や走行時間が大きくなるほど、事故のリスクは高まるため、所定の期間における走行距離や走行時間を特定して保険料を設定しておくことができる。車両２の走行距離や走行時間は車両情報として収集されているので、所定の期間における当該車両の走行距離や走行時間は予想できる。ただし、納車時にはまだ走行距離や走行時間等は収集されていないため、ユーザが見込みの走行距離や走行時間を設定する必要がある。所定の期間における走行距離や走行時間が予め設定した範囲を超えそうな場合には、予めユーザ端末３７を介してユーザに報知して、追加の保険料の支払いをユーザに促し、あるいは、保険の契約によっては自動的にユーザに追加の保険料の支払いを求める。

走行速度及び制限速度の情報を保険料に反映することも可能である。制限速度の情報は例えばナビゲーションシステムの地図情報、道路に設置されたビーコン等からの情報、あるいは、道路交通情報通信システム（Vehicle Information and Communication System、VICS（登録商標））等に含まれている。この制限速度と車両２の速度とを対比することにより、車両２のユーザが制限速度をどの程度守っているかを把握することができる。例えば、制限速度を遵守しているユーザは、制限速度を守っていないユーザよりも、安全運転を行っていると判断し、安全運転を行っているユーザ（そのユーザに係る車両２）の保険料を割り引くことが可能である。一方、速度順守の観点から危険運転であると判断されたユーザの保険料は割増しにすることも考えらえられる。この時の保険料の割引額ないし割増額は、どの程度制限速度を遵守しているかという程度を、車両情報、例えば、制限速度及び走行速度から段階的に、あるいは、一定の数式により定量化することによって決定することができる。

車両の加速度情報から、ユーザの運転の特性を推定し、安全運転かどうかを判断することができる。急加速、急減速、急ハンドルが少ないユーザは、これが多いユーザよりも安全運運転であると判断することができ、この判断により安全運転を行っているユーザ（そのユーザに係る車両２）の保険料を割り引くことが可能である。一方、急加速、急減速、急ハンドルの観点から危険運転であると判断されたユーザの保険料は割増しにすることも考えらえられる。この時の保険料の割引額ないし割増額は、どの程度の急加速、急減速、急ハンドルが検出されたかという程度を、車両情報、例えば、車両２の加速度、あるいは、アクセルセンサ、ブレーキセンサ、ステアリングセンサ等から段階的に、あるいは、一定の数式により定量化することによって決定することができる。

車両２の位置情報、走行経路、及び、走行時間帯から、事故のリスクを推定して、保険料に反映させることもできる。位置情報、走行経路、及び、走行時間帯等からは、車両２が市街地にいるのか郊外にいるのか、車両２が交通量の多い道路を走行しているかどうか、事故の発生確率が高い状況にあるかどうか等を推定し、事故のリスクを段階的に、あるいは、一定の数式により定量化して、保険料の割引額ないし割増額を計算することができる。

義務情報演算手段７１において演算された保険情報は保険管理システム８２に提供される。保険情報としては、車両２ないしユーザに関する保険料の情報を含むものとすることができるが、これに限らず、保険料の情報までは含まず、保険情報として保険料を演算するための車両情報を含むようにすることができ、保険情報として車両情報を保険管理システム８２に提供する場合には、保険管理システム８２において車両２ないしユーザに対する保険料を含む保険情報が演算される。保険料を含む保険情報はユーザ端末３７を介してユーザに提供される。保険料の中、加入が法令で義務図けられている強制保険については、ユーザ端末３７を介して必ずユーザに加入するように報知される。例えば、日本においては、自賠責保険は車検の際に強制加入されるため、後述の車検の有効期限と共に、強制保険の加入がユーザ端末３７によって報知されるようにしてもよい。

ユーザにより強制保険の保険料が適正に支払われたかどうかは保険管理システム８２により把握される。例えば保険管理システム８２は、金融システム３６のＡＰＩを利用して、ユーザにより保険料金が支払われたことをリアルタイムで把握することができる。義務情報演算手段７１においては、保険管理システム８２から保険料納付情報を受信し、車両２ないしユーザが強制保険の保険料を支払っているかどうか、すなわち、強制保険に加入しているか否かを判定し、強制保険に加入していない場合（図３のステップＣ３においてノーの場合）には、該当するユーザによる車両２の利用を禁止するために、遠隔制御指示部３１から、車載器１に対して該当車両２を起動不可状態に切り替えるための遠隔制御指令を送信する。一方、強制保険に加入している場合、すなわち、図２のステップＣ３においてイエスの場合には、他に必要な条件の判断を行う。なお、上述のステップＣ２の税金に関する判定の場合と同様に、ステップＣ３の保険に関する判断だけを単独で行い、イエスの場合には車両２を起動可能状態に制御し、ノーの場合には車両２を起動不可状態に制御するようにしてもよい。また、車両の起動状態の制御に際し、ステップＣ３の保険に関する判定に加えて、他の１又は複数の判定を加えてもよい。ただし、何の猶予もなく突然に車両２が使用できなくなると、交通手段や収入を得るための手段が使えなくなることになるため、ユーザにとって酷な状況が予想される。そこで、ステップＣ３における税金納付無しの判断にあたっては、車両２のユーザに対して、ユーザ端末３７を介して、事前に所定の期間内に所定の保険料を行わないと車両２を起動不可状態にする旨の警告を行い、所定の期間待って、それでも保険料の納付がない場合には、車両２を起動不可状態に切り替えるようにしてもよい。

任意保険の保険料についても、上述のとおり車両情報を用いて、義務情報演算手段７１又は保険管理システム８２において演算することが可能である。義務情報演算手段７１において任意保険の保険料を含む保険情報が演算される場合においては、その保険情報は保険管理システム及びユーザ端末３７に送信され、ユーザに対して推奨される任意保険への加入を促すことができる。保険管理システム８２において任意保険の保険料を含む保険情報が演算される場合には、この保険情報はサーバ３を介してユーザ端末３７に送信され、ユーザに対して推奨される任意保険への加入を促すことができる。保険管理システム８２はユーザにより任意保険の保険料が支払われたかどうかを把握することができる。また、任意保険への加入の可否の情報についても、サーバ３に提供されるようにしてもよい。ただし、任意保険の保険料が支払われない場合には、強制保険の場合とは異なり、車両２を起動不可状態へ切り替える遠隔制御指令を送信することは行わない。

［車検に関する判定］
図３のステップＣ４では、義務情報演算手段７１において車検が有効であるか否かを判定し、車検が有効であるか否かを判定し、車検が有効でない場合には、ノーの判定となり、ステップＣ７で、遠隔制御指令部３１から車両２を起動不能状態に切り替えるための遠隔制御指令が送信される。また、ステップＣ４でイエスの場合には、他の条件の判定を行う。なお、上述のステップＣ２の税金に関する判定の場合と同様に、ステップＣ４の車検に関する判断だけを単独で行うようにしてもよい。また、車両２の車検の判定に加え、他の１又は複数の判定を加えてもよい。法令によって車検が義務付けられている場合には、車両２のユーザに車両２の車検を受けることを促すことが必要である。義務情報演算手段７１において、車検の有効性を判断し、車検が有効でない場合に、当該車両を起動不能状態に切り替えるようにすると、車両２を利用したいユーザに対して、車検を受けるように促すことができる。一方、予告なしに車両２が起動不能状態に制御されてしまうと、ユーザにとっては酷な状況ともなるため、車両２を起動不可状態に切り替える前には事前に車検を受ける期限を所定期間前にユーザ端末３７を介してユーザに報知し、期限までにユーザが車両２の車検を受けるように促すようにする。また、車検の期限が切れた場合には、車両２は起動不可状態となるが、車検を受けるための移動及び車検のための走行試験に際しては、ユーザ端末３７からサーバ３への申請によって、あるいは、ユーザから管理者（管理者端末３５）への申請によって、一時的に車両２を起動可能状態に切り替えることにより、車検を受けることが可能となる。

車検を受けた車両２には、例えば電子ナンバープレート、車載記憶装置、車載器１のメモリまたはＩＣカード等に少なくとも車検を受けたことを示す車検情報が記録される。この車検情報には、車検証の情報、車検を受けた期日、次回の車検期限、所有者、使用者、納税義務者、車両番号、型式、自動車の種別、車体の形状、長さ、幅、高さ、重量、定員、積載量、排気量、燃料の種類、点検項目とその結果、及び、部品交換や故障の履歴等の情報が含まれる。これらの情報を電子ナンバープレート等の記憶手段に記憶することにより、車検期限の情報、点検結果の情報、部品交換や故障履歴の情報を容易に読み出すことができるため、車両のメンテンナンス等にも有用である。

電子ナンバープレート等に記憶された車検情報は、車両情報として車載器１を介して車両情報収集部３２に収集され、義務情報演算手段７１において、車検が有効かどうかの判断に用いられる。そして、図３のＣ４の車検が有効であるか否かの判断において、ノーの場合には、遠隔制御指令部３１から車両２を起動不可状態に切り替えるための遠隔制御指令が車載器１へ送信される。図３のＣ４の判断がイエスの場合には、例えばステップＣ５に進む等の他の条件の判断が行われる。

車検が有効か否かの判断結果を含む車検情報は、義務情報演算手段７１から車検管理システム８３に提供されることにより、車検管理システム８３において車載器１により収集された車検情報が利用される。車検管理システム８３において全ての車両２の全ての車検情報が把握できているとは限らないので、この場合には、車載器１により車検情報を収集することは有効である。なお、車検管理システム８３において、車両２の車検情報が適切に収集されているような状況においては、義務情報演算手段７１は車検管理システム８３から提供された車検情報に基づいて車両２の車検が有効か否かを判断することもできる。

［ナンバープレート番号などによる車両規制］
車両２のナンバープレート番号に応じて、例えば都心部など、特定の地域への車両２の乗り入れを禁止する時間帯を法令により定める場合がある。車両２のナンバープレート番号は電子ナンバープレート、車載記憶装置、車載器１のメモリ等に記憶されておくこができ、車両２が駐車されている状態であっても、これらの車両２のナンバープレート番号の情報は、車両情報として車載器１を介して車両情報収集部３２により事前に収集され、義務情報演算手段７１に送られている。また、駐車時に車両２の位置情報は、車両２のＧＰＳから車両情報として車載器１を介して、車両情報収集部３２により収集され、義務情報演算手段７１に送られている。さらに、サーバ３に接続された車両規制データベース８４からは、関連する車両規制データが取得され、義務情報演算手段７１に提供される。サーバ３から車両規制データベース８４への接続は例えばＡＰＩを用いることができる。車両２のナンバープレート番号、車両２の位置が、車両規制データにより規制対象となっている場合には、図３のステップＣ５において車両規制対象でないとの判定で、ノーとなり、遠隔制御指令部３１において車両２を起動不可状態に変更するための遠隔制御指令が車載器１に送られるので、この場合には、ユーザは駐車中の車両２を起動することはできない。

また、車両２の予定している経路が、車両２の通過予定時刻において車両規制地域に含まれる場合にも、車両は車両規制の対象になる。そこで、駐車中の車両２を使用する前にユーザはユーザ端末３７から車両２の目的地及び予定経路を登録する。義務情報演算手段では、登録された車両２の予定経路が、車両規制に含まれる場合には、図２のステップＣ５において車両規制対象でないとの判定で、ノーとなり、遠隔制御指令部３１において車両２を起動不可状態に変更するための遠隔制御指令が車載器１に送られるので、この場合には、ユーザは駐車中の車両２を起動することはできない。図２のステップＣ５において車両規制対象でないとの判定で、ノーとなった場合には、サーバ３はユーバ端末３７を介してユーザに対して車両２が車両規制の対象となっていること、及び、車両２の車両規制の範囲を報知する。サーバ３から車両規制の報知を受け取った後に、ユーザはユーザ端末３７から車両２の目的地及び予定経路を再度登録することができ、この再登録された目的地及び予定経路が規制対象の範囲に含まれなければ、図２のステックＣ５ではイエスの判断となり、ステップＣ５において遠隔制御指令部３１から車載器１に対して車両２を起動可能状態に切り替える遠隔制御指令が送信される。ユーザによるユーザ端末３７を介したサーバ３への目的地及び予定経路の再登録は何度でも受け付けられるようにしておくことが望ましい。それにより、車両規制が行われている状態であっても、ユーザの車両２利用の利便性を保つことができる。また、駐車中にユーザによりユーザ端末３７から登録された目的地及び走行経路の情報は、サーバ３から車載器１へ送られ、車両２のナビゲーション装置に登録しておくことができる。

車両２の起動後に目的地や走行経路を変更したりする場合も起こり得る。起動後に車両２のナビゲーション装置に新たな目的地ないし走行経路が入力された場合には、この新たな目的地ないし走行経路の情報がサーバ３へ送信され、義務情報演算手段７１において、車両規制データベース８４からの情報と照合し、車両２の走行経路が車両規制に含まれていないか否かを判定し、その判定結果をユーザ端末３７及び／又は車載器１に対して、送信する。車載器１に送られた判定結果は、例えばナビゲーション装置のディスプレイに表示するようにしてもよい。判定結果が車両規制対象である場合には、判定結果と共に、車両規制の範囲と期間がユーザ端末３７、ナビゲーション装置のディスプレイ等に報知される。また、この報知と併せて、迂回経路や経路沿いの駐車場の情報を提供するようにしてもよい。

ナビゲーション装置に新たな目的地ないし走行経路が設定されることなく、ユーザが目的地や走行経路を変更することも起こり得る。ナビゲーション装置に新たな目的地ないし走行経路が設定されることなく、ユーザが目的地や走行経路を変更した場合には、すなわち、車両２の走行経路がナビゲーション装置に設定された経路あるいはユーザ端末３７から事前に登録された経路から外れた場合には、ナビゲーション装置からの現在位置及び登録経路を外れていることの情報が車載器１からサーバ３に送られ、義務情報演算手段７１において、車両位置、予想経路、車両規制情報等に基づいて車両２の予想経路が車両規制に含まれるか否かを判断し、その判定結果をユーザ端末３７及び／又は車載器１に対して、送信する。車載器１に送られた判定結果は、例えばナビゲーション装置のディスプレイに表示するようにしてもよい。判定結果が車両規制に含まれている場合には、判定結果と共に、車両規制の範囲と期間がユーザ端末３７、ナビゲーション装置のディスプレイ等に報知される。また、この報知と併せて、迂回経路や経路沿いの駐車場の情報を提供するようにしてもよい。なお、車両規制データベース８４から得られた車両規制情報は、随時、車載器１に送信し、車両２のナビゲーション装置のディスプレイ等に表示するようにしてもよい。車両２が起動中である場合には、車両２の走行経路が車両規制に含まれることが判定されたても、車両２を起動不能状態に切り替えることはできないが、車両規制の範囲と期間をユーザ端末３７、ナビゲーション装置のディスプレイ等を介してユーザに報知することによって、ユーザに対して車両規制情報を報知することにより、車両規制を遵守するように促すことが可能である。

［サーバ３における車両２の運行管理］
次に、サーバ３により自動的に車両の運行状況を判別する方法について詳細に説明する。事前に登録された駐車場に相当する場所で、所定時間以上、車両の動力がオフ状態となっている場合には、所定の駐車場に車両を駐車中であると判断する。また、事前に登録された駐車場以外の場所で、所定時間以上、車両の動力がオフ状態となっている場合には、所定の駐車場以外の場所に車両を駐車中であると判別する。さらに、車両が事前に登録された駐車場以外の場所にあり、車両の動力が所定の時間以上オフ状態とはなっていない場合にはユーザが車両を利用して移動中であると判別する。

また、車両がユーザの事前登録した範囲から所定期間以上外れていた場合には、車両が盗難された可能性があると判別する。車両が盗難された可能性があると判別された場合には、ユーザが事前に登録している連絡先にその車両運行状況を通知すると共に、盗難の有無の問い合わせを行う。所定の期間内にユーザからの回答がない場合、及び、ユーザから盗難である旨の回答があった場合には、管理者に盗難の発生を報知すると共に、車載器１に対して起動不可状態に対応するリレー制御指令を送信する。管理者は、サーバ３から盗難発生の報知があった場合には、ユーザに連絡を取って盗難の発生状況を確認した上で、必要に応じて警察に車両の盗難を通報する。

さらに、車載器１には、車載器１を車両２から抜去、又は、車載器１に接続されている配線の切断若しくは引抜の異常を検出する手段が設けられており、これらの異常を検出すると車載器１はサーバ３にかかる異常の発生を報知する。この報知が発生するとサーバ３は速やかに管理者に報知を行う。管理者は、サーバ３からこの異常の報知があった場合には、ユーザに連絡を取って盗難の発生状況を確認した上で、必要に応じて警察に車両の盗難を通報する。

車載器１を車両２から抜去する場合として、例えば、（１）窃盗犯による盗難の場合、（２）ユーザによる車両の悪用の場合、及び、（３）未払いユーザによるやむを得ない緊急時の車両利用の場合、が想定される。（１）及び（２）のような盗難や悪用の場合を想定した場合には、車両を起動不可状態にすることが望ましい。一方、（３）のような緊急時の場合、例えば急病人の搬送を想定した場合には、車両を起動可能状態とすることが望ましい。後述のように、外部リレー２０は、その接続を切り替えることにより、配線の切断若しくは引抜時に、起動不能状態とするモードにするのか、それとも、起動可能状態とするモードにするのかを選択することができる。そこで、車載器１が前記異常の検出した場合、及び、外部リレー２０の配線の切断若しくは引抜時に、管理者が（１）及び（２）のような盗難や悪用の場合を想定する場合には外部リレー２０を起動不可状態になるように予め設定し、管理者が（３）のような緊急時の場合を想定する場合には外部リレー２０を起動可能状態になるように予め設定しておけばよい。

次に図２を参酌して車載器１の構成と車両２への接続を説明する。図２は内燃機関車両に接続する場合の例である。なお、図１と同一の部位については同一の符号を付し、詳細な説明は省略する。１１は演算処理を行うＣＰＵ、１２は無線通信ネットワークを介してサーバ３の送受信部と無線通信を行う無線通信モジュール、１３はリレーの状態等を記憶するメモリであり、例えば不揮発性メモリとして構成されており、１４は車載器の各種設定を行うコンソール、１５は車両２の外部バッテリ２１からの電力により充電される車載器内部のバッテリである内部バッテリ、１６は車両２の外部バッテリ２１からの電源入力を検知する電源入力検知部、１７は車両２の走行状態識別線（ＡＣＣ線、ＩＧ線）２２に接続されてエンジンのオン・オフ状態を検知するＩＧＮ入力検知部、１８は外部リレー２０に接続されるリレー入出力部、１９は車両２のＧＰＳ２４に接続されて車両の位置情報を検出するＧＰＳ入出力部である。また、図示されていないが、車載器１では加速度センサの情報、車速パルスの情報、燃料センサの情報、速度情報、タコメータの情報、タコグラフの情報、ドアロックの情報、イモビライザーの情報、エンジンスタートボタンの情報、タクシーの料金メータの情報、アクセルペダルの踏み込み量の情報（例えばスロットルバルブの開度の情報等も含む。以下、同様。）、及び、その他車両の稼働状況を把握できる各種情報を検出して収集できるようにしてもよい。これらの各種情報を車両情報として利用することも可能である。ここで、外部バッテリ２１とは、車載器１内部の内部バッテリ１５と区別した用語であり、車載バッテリのことを意味する。外部リレー２０は車両２のエンジン起動制御線（ＳＴ線）に接続されており、図３では外部リレー２０は車両２と車載器１との間に示されているが、実際には車両２のエンジンルームの内部に設けられており、外部リレーは外部から目視することはできない場所に配置されている。したがって、窃盗者あるいはユーザが故意に外部リレー２０を取り外すことはできない構造となっている。リレー入出力部１８は、外部リレー２０が起動不可状態にあるか起動可能状態にあるかを検出すると共に、リレー制御指令に基づいて外部リレー２０を起動不可状態又は起動可能状態に切り替える制御を行う。

電源入力検知部１６と外部バッテリ２１、ＩＧＮ入力検出部１７と走行状態識別線２２、リレー入出力部１８と外部リレー２０、ＧＰＳ入出力部１９とＧＰＳ２４は、ＣＡＮ等の車両ＬＡＮを介することなく、それぞれ直接個別の配線で接続されている。これにより、ＣＡＮ等の車両ＬＡＮを用いることがないので、ＣＡＮ等の車両ＬＡＮによるセキュリティに対しては脆弱であるという問題が生じることはない。

車載器１は内部バッテリ１５の電力により駆動される。内部バッテリは常に車両２の外部バッテリ２１の電力により充電されており、車載器１が抜去された場合、充電ラインが切断又は引抜された場合等の異常時であっても、所定の時間、車載器を駆動し続けることができ、このため、かかる異常の発生を現在地情報と共にサーバ３へ報知することができる。なお、直近の現在地情報その他の情報はメモリ１３に格納されている。

ＣＰＵ１１は、無線通信モジュール１２、メモリ１３、コンソール１４、内部バッテリ１５、電源入力検知部１６、ＩＧＮ入力検知部１７、リレー入出力部１８、ＧＰＳ入出力部１９、及び、図示されない加速度センサ等に接続されている。車両情報検出手段としては、電源入力検知部１６、ＩＧＮ入力検知部１７、ＧＰＳ入出力部１９、及び、加速度センサ等を備えている。リレー入出力部１８は、外部リレー２０の状態を検出すると共に、外部リレー２０を起動不可状態か起動可能状態かのいずれか一方に制御するものであり、外部リレー２０の状態も車両情報として使用可能である。

ＣＰＵ１１は、メモリ１３に格納されたプログラムによって、外部リレー２０の制御及び車両情報の収集を行う。以下、車載器１の動作について説明する。
［車両情報の収集について］
車載器１は所定の周期、例えば３０秒おきに、又は、車両動力のオン等の特定のイベント発生時に、あるいは、その両方で車両情報の収集を行い、サーバ３へその車両情報を送信する。この時の車両情報としては、電源入力検出部１６で検出される外部バッテリ２１からの電源入力の情報、ＩＧＮ入力検知部１７で検出される走行状態識別線（ＡＣＣ線、ＩＧ線）の情報、例えばエンジンのオン、オフの状態を示す情報、リレー入出力部１８で検出される外部リレー２０の状態、ＧＰＳ入出力部１９で検出されるＧＰＳからの位置情報、図示しない加速度センサから検出される加速度の情報、車速パルスの情報、燃料センサの情報、及び、車両情報を取得した時刻の情報の中の少なくとも１つを含んでいる。なお、ＧＰＳの位置情報から速度を演算することも可能である。サーバ３では、これらの車両情報を基づいて、車両の運行状況を把握する。

［外部リレーの制御について］
車載器１がサーバ３からリレー制御指令を受信すると、その制御値をメモリ１３に記憶し、その値に対応する状態になるように外部リレー２０を制御する。車両情報連動制御手段は、ＣＰＵ１１、メモリ１３、ＩＧＮ入力検知部１７及びリレー入出力部１８を含み、外部リレー２０を切り替える際に、後述のように、車両の動力のオン、オフ切替タイミングを考慮して、リレー制御指令を採用する場合と、採用しない場合（リレー制御指令を無視する場合）とを判別する。内燃機関車両の場合には動力のオン、オフは、例えばＩＧＮ入力検知部１７で検出される走行状態識別線（ＡＣＣ線、ＩＧ線）の情報、例えばエンジンのオン、オフの状態を示す情報により検出する。

次に図４を参照して、内燃機関車両におけるエンジン起動制御線（ＳＴ線）を外部リレー２０でカットする場合（図３の場合）のリレーの制御値（ＳＴ線リレーの制御値）について説明する。図４Ａはエンジン起動制御線が１本の車種の場合を示し、図４Ｂはエンジン起動制御線が２本の車種の場合を示している。初めに図４Ａのエンジン起動制御線が１本の車種の場合について説明する。リレーＡのリレー値はオープンの時"０"であり、クローズのとき"１"である。外部リレー制御値は、"００"と"０１"の２種類となる。外部リレー制御値が"００"の時は、ステータスは起動可能状態（通常）、車両状態は起動可となる。一方、外部リレー制御値が"０１"の時は、ステータスは起動不可状態、車両状態は起動不可となる。

次に図４Ｂのエンジン起動制御線が２本の車種の場合について説明する。リレーＡ、リレーＢ共に、リレー値はオープンの時"０"であり、クローズのとき"１"である。外部リレー制御値は、"００" と"０１"と"１０" と"１１"の４種類となる。外部リレー制御値が"００"の時は、ステータスは起動可能状態（通常）、車両状態は起動可となる。外部リレー制御値が"０１"の時は、ステータスは意図しない値、車両状態は起動可となる。外部リレー制御値が"１０"の時は、ステータスは意図しない値、車両状態は起動可となる。外部リレー制御値が"１１"の時は、ステータスは起動不可状態、車両状態は起動不可となる。

リレー監視部は、ＣＰＵ１１とメモリ１３とリレー入出力部１８とを含み、後述のように、ファームウエアの不具合により、外部リレー制御値が本来起動可能状態であるときにリレー状態を監視し、当該監視によりリレー状態が起動可能状態以外になっていた場合にはリレー状態を起動可能状態、すなわち、外部リレー制御値を"００"とし、外部リレー２０を起動可能状態とする。

さらに、図５を参照して、外部リレー２０の配線について説明する。外部リレー２０は、接続状態を変更することにより、ノーマルオープンとノーマルクローズとを選択することができる。４１は電磁石のコイル、４２はスイッチ、４３と４４はリレー入出力部１８側の端子、４５はエンジン起動制御線（ＳＴ線）側の一方の端子、４６はノーマルクローズ端子、４７はノーマルオープン端子である。スイッチ４２はノーマルクローズ端子４６側にバネで付勢されているので、コイル４１に通電していない時にはスイッチ４２はノーマルクローズ端子４６側に接触している。コイル４１に通電した時には、スイッチ４２は電磁石に吸い付けられ、ノーマルオープン端子４７に接触する。したがって、外部リレー２０をノーマルクローズ型として使用したい場合には、ＳＴ線の他方の端子をノーマルクローズ端子４６に接続し、逆に、外部リレー２０をノーマルオープンズ型として使用したい場合には、ＳＴ線の他方の端子をノーマルオープン端子４７に接続する。

図２を参酌して、外部リレー２０をノーマルクローズ型として使用したい場合と、外部リレー２０をノーマルオープンズ型として使用したい場合との違いを説明する。電源入力検出部１６、ＩＧＮ入力検知部１７、リレー入出力部１８、及び、ＧＰＳ入出力部１９のいずれか少なくとも１つには、配線の切断又は引抜を検出する手段（図示省略）が設けられている。配線の切断又は引抜を検出する手段としては、例えば特許文献２に開示されているような配線の切断又は引抜に伴う配線の電圧変化を利用するという公知の手段を用いることができる。また、電源入力検知部１６が外部バッテリ２１からの電源入力を検知しない場合には、電源入力検知部１６と外部バッテリ２１との間の配線に切断又は引抜が生じたと判断することもできる。車載器の抜去についても、これらの配線の切断又は引抜に基づいて検出することができる。配線の切断又は引抜を検出した場合には、後述のように、外部リレー２０を起動不可状態（オープン）にするか、あるいは、起動可能状態（クローズ）にするかのどちらかに制御するように決めておく。

また、配線の切断又は引抜を検出した場合には、前述のとおり外部リレー２０を制御すると共に、無線通信モジュール１２を介してサーバ３にその異常を報知する。サーバ３がその異常の報知を受信すると、サーバ３は速やかに管理者に報知を行う。管理者は、サーバ３からこの異常の報知があった場合には、ユーザに連絡を取って盗難の発生状況を確認した上で、必要に応じて警察に車両の盗難を通報する。一方、車載器１は、前記異常を報知すると共に、車載器１に搭載された警報器（図示省略）により警報音を鳴らす。また、車載器１に警報器を搭載する代わりに、車両の警笛、ヘッドランプ、ウインカー、ハザードランプ等を利用して警報を行うことができるように、これらの制御回路の入力端子に車載器１の警報出力の出力信号を入力するように配線することもできる。

ここでは、異常の報知として、配線の切断又は引抜を検出した場合を例にして説明したが、車載器１にさらに故障検出手段を設け、当該故障検出手段が車載器１の故障を検出した場合に、無線通信モジュール１２を介してサーバに対して車載器１の故障を報知するようにしてもよい。サーバ３が車載器１の故障の報知を受信すると、サーバはかかる故障の発生を管理者に通報し、かかる通報を受けた管理者は該当する車両のユーザに連絡をとって、車載器１を修理又は交換するように手配する。

リレー入出力部１８と外部リレー２０との間の配線の切断又は引抜が生じた場合には、外部リレー２０のコイル４１への電流供給が停止するため、ノーマルクローズ型の場合には外部リレー２０はクローズとなり、ＳＴ線が接続された状態となり、ノーマルオープン型の場合には外部リレー２０はオープンとなり、ＳＴ線は遮断（カット）された状態となる。

前述のように、管理者が車載器１を車両２から抜去する場合としては、（１）窃盗犯による盗難の場合、（２）ユーザによる車両の悪用の場合、及び、（３）未払いユーザによるやむを得ない緊急時の車両利用の場合、が想定されるところ、（１）及び（２）のような盗難や悪用の場合を想定した場合には、車両を起動不可状態にすることが望ましいので、外部リレー２０としてノーマルオープン型を採用し、配線の切断又は引抜を検出した場合にも外部リレー２０を起動不可状態（オープン）に制御するように予め決めておくとよい。一方、（３）のような緊急時の場合、例えば急病人の搬送を想定した場合には、車両を起動可能状態とすることが望ましいので、外部リレー２０としてノーマルクローズ型を採用し、配線の切断又は引抜を検出した場合にも外部リレー２０を起動可能状態（クローズ）に制御するように予め決めておくとよい。

また、車載器１は電波状況が悪い場合であって、サーバ３からのリレー制御指令がなくとも、スタンドアローンでフェイルセイフに動作をすることができる。例えば、電波状況が悪い場所で車両が起動不可状態となり、起動可能情報に対応するリレー制御指令を受け取ることができなくなる事態を回避することができる。車載器は、電波状況が悪い時には通信のリトライを繰り返して、通信を確立しようとする。所定回数、例えば２０回以上、連続してリトライしても通信が確立できない場合には、通信不能と判断し、外部リレー２０の状態が起動不可状態のときには、起動可能状態に切り替える。これにより、電波状況が悪い時に、サーバ3から起動可能状態へ変更するリレー制御信号を送信できないために、車両が起動不能状態のまま放置される事態を避けることができる。この通信不能のときに車両を起動可能状態に切り替える処理を採用するか否かについては、車両の出荷時等に切り替えることができる。

［省電力モードについて］
内燃機関車両のエンジンがオフの時には、エンジンがオフしてから所定の時間、例えば１０分が経過した後には、外部バッテリ２１の電力の消耗を防ぐために、車載器は省電力モードに移行し、電源管理のような最低限の機能以外を停止する。省電力モードでは、電源入力検知部１６とＩＧＮ入力検知部１７とリレー入出力部１８と計時回路（図示省略）は常に起動しているが、その他の回路は停止状態となっている。省電力モードの時には、車載器１はサーバ３とは通信を行っていない。省電力モードの時に、電源入力検出部が電源入力の喪失を検出した場合、ＩＧＮ入力検知部１７がエンジンのオン状態（ＡＣＣオンやＩＧオン）を検出した場合、及び、計時回路が所定の時間を計時した場合（例えば、１時間おきに）には、省電力モードのときでも常に起動している対応する回路がＣＰＵに割り込みをかけて車載器１を省電力モードから通常モードに切り替える。また、省電力モードの時にもリレー入出力部には常に電力が供給されているため、外部リレー２０の状態を常に保持することができる。

［無線通信モジュールについて］
前述のように車載器１は通常モードにおいては所定の周期、例えば３０秒おきに、又は、車両動力のオン等の特定のイベント発生時に、あるいは、その両方で車両情報の収集を行い、サーバ３へその車両情報を送信する。常に起動している対応する回路がＣＰＵに割り込みをかけて車載器１を省電力モードから通常モードに切り替える際には、車載器１を起点としてサーバ３と通信を行い、リレー制御指令の受信や車両情報の送信を行う。通常モードにおいては、車載器１起点の通信に加え、サーバ３起点の通信が可能であり、車載器１はリレー制御指令等の情報を受信可能である。電波状況が悪い時には、通信を確立するまでに、複数回、例えば５回程度の通信を繰り返すことがある。電波状況が悪く通信が確立できない場合でも、車載器１は、直近の通信によりサーバ３から受信したリレー制御指令をメモリに記憶しているので、車載器１はスタンドアローンで動作することが可能である。また、車載器１は収集した車両情報をメモリに記憶しているので、通信回線が回復したときにそれらをまとめてサーバ３へ送信することができる。なお、電波状況が悪い場合には、起動不可状態に対応するリレー制御指令を送信又は受信しないようにしておくこともでき、この場合には、電波状況が悪いために、起動不可状態から起動可能状態への変更ができなくなる不都合を回避することができる。

次に、図６を参酌して、メモリ１３内の構成を説明する。メモリ１３は、通信部５０、リレー制御部５１、リレー監視部５５及びエンジン連動制御部５７からなる４つの処理部を含んでいる。また、リレー制御部５１はリレー設定値５２、車種毎起動不可リレー値５３及び車種毎起動可能リレー値５４を含み、リレー監視部５５はリレー監視実行フラグ５６を含み、エンジン連動制御部５７はリレー変更禁止期間５８、エンジン停止時刻５９及びエンジン状態再評価期間を含んでいる。

通信部５０は、サーバ３との通信のためのデータ領域である。無線通信モジュール１２を介して、車両情報のサーバ３への送信、サーバ３からのリレー制御指令の受信を行うために用いられる。リレー制御部は、サーバ３からのリレー制御指令により与えられたリレー値に対応する状態へ外部リレー２０を変更するためのデータ領域である。リレー監視部５５は、後述のように設定された起動不可状態・起動可能状態のリレー状態値に基づき、リレー状態が起動可能状態でなければならない状況、すなわち、初期状態又はサーバ３からの最後のリレー変更要求が起動可能状態への変更である場合には、外部リレー２０の状態を定期的に監視し、この監視の結果、外部リレー２０が起動可能状態以外のリレー状態になっている場合は、起動可能状態に変更する。エンジン連動制御部５７は、サーバ３からリレー制御指令を受信した際、過去Ｘ分（例えば２分）の間にエンジンがオンになっていた場合は、リレー制御指令を無視し、起動不可状態へのリレー制御指令を実行してからＹ秒（例えば５秒）の間にエンジンのオンを検出した場合には、リレーを起動可能状態に変更する。

ここで、Ｘ分を例えば２分としたことの根拠を説明する。エンジン停止後１０分程度で車載器１は省電力モードに切り替えられ、電力の消費を抑える。省電力モードの状態でユーザが車両に乗り込みエンジンを始動すべくキーをシリンダーに差し込み、イグニッションオン状態にすると、ＩＮＧ入力検知部１７は走行状態識別線（ＡＣＣ線、ＩＧ線）２２からエンジンがオン状態になったことを検出して、ＣＰＵ１１に対して割り込みをかけて、車載器１を通常モードに切り替える。車載器１が通常モードに切り替えられたことをサーバ３が認識するまでには、電波状況が良い時には１分程度、電波状況が悪く通信を５回程度繰り返す必要がある場合には１分３０秒程度かかる。車両の動力がオフにされてからある程度の期間は起動不可状態への切り替えを指示するリレー制御指令を採用しない（無視する）ことにより、車両の動力をオフにした後すぐに再度車両の動力をオンにするような場合にも、不用意に車両が起動不可状態に切り替えられてしまうことを防止することができる。例えば、駐車場においてトランクや座席から荷物を積み下ろしするまでの間、車両を駐車スペースから少しずらした位置で一端停車させた状態で車両の動力をオフにし、荷物の積み下ろしの後、再び車両の動力をオンにして車両を駐車スペースに入れなおすような場合に、不用意に車両が起動不可状態に切り替えられてしまうことを防止することができる。逆にＸ分が長すぎる場合には、車両を起動不可状態に切り替えることができなくなってしまうケースが発生することから、過去２分間の間にエンジンがオンになっていた場合には、リレー制御指令を無視することとした。

次に、Ｙ秒を例えば５秒としたことの根拠を説明する。車載器１は、車両の動力がオンの間にリレー制御指令を受け取った場合には、安全を考慮してリレー制御指令を受け付けない（リレー制御指令を無視する）。車両の動力がオンである間は、ユーザが車両で移動中であるため、例えば電波状況が悪いために車両を起動不可状態へ変更するリレー制御指令の受信が遅延されてしまった場合等、不用意に車両が起動不可状態となることを防止している。一方、車載器１が車両の起動を認識するまでには、実際に車両が起動をしてから3秒程度かかる。車両を起動した直後に、車載器１がリレー制御指令を受信した場合、車載器１は車が起動していないと判断し、リレー制御指令を採用してしまい、車両が起動しているにも関わらず、車両が起動不可状態に切り替えられる状況が発生する。後述のように、イグニッションスイッチがプッシュ式の場合、起動不可状態にする方法として、プッシュボタンを無効にする方法と、イモビライザーを発動（認証用の線をカット）する方法とがあるが、この中、プッシュボタンを無効にするものの場合、前記３秒間の間に起動不可状態に切り替えられると、エンジンを切れなくなってしまう不具合が生じる。一方、イモビライザーを発動する方法の場合、前記３秒間の間に起動不可状態に切り替えられると、プッシュボタンは効くので、エンジンをオフすることはできる状態であるが、ギアがドライブＤには入らなくなるという不具合が生じる。以上のことから、Ｙ秒として、３秒よりも余裕を持たせた５秒を採用した。

次に、図６に示されているメモリ１３の各変数について説明する。リレー設定値５２は、現在の外部リレー２０の状態に対応するリレー値である。車種毎起動不可リレー値５３は、車両を起動不可状態にする外部リレー２０の状態に対応する車種毎の設定値である。車種毎起動可能リレー値５４は、車両を起動可能状態にする外部リレー２０の状態に対応する車種毎の設定値である。リレー監視実行フラグ５６は、外部リレー２０の監視を実行させるか否かを決定するフラグであり、初期状態（車両の出荷時）、又は、サーバ３からの最後のリレー制御指令が起動可能状態への変更である場合にオンとなる。リレー変更禁止期間は、エンジンが停止された後、外部リレー２０の変更を禁止する期間（Ｘ分、例えば２分）である。エンジン停止時刻は、前回エンジン停止を検出した時刻である。エンジン状態再評価期間は、起動不可状態への制御を行った後、エンジンのオンを再評価する期間（Ｙ秒、例えば５秒）である。

車種毎起動不可リレー値５３及び車種毎起動可能リレー値５４は、車両の車種に応じて１つだけ記憶しておいてもよいし、あるいは、複数車種の値を記憶しておき、車両の車種に応じて選択するようにしてもよい。また、車種毎起動不可リレー値５３及び車種毎起動可能リレー値５４は、コンソール１４から設定するようにしてもよいし、サーバ３から設定するようにしてもよいが、ノイズによるファイルセーフの観点からはサーバ３から設定することが望ましい。

次に、メモリ１３の各処理部の動作について図７〜図９のフローチャートを参照して説明する。まず、図７を参照してリレー制御部５１の動作について説明する。Ｓ１１でリレー制御部処理が開始されると、まずＳ１２でリレー設定値５２を与えられたリレー値で上書きする、次にＳ１３でリレー状態をリレー設定値５２の状態へ変更する。続いてＳ１４でリレー制御指令のリレー値が車種毎起動可能リレー値５４と同一か否か判断し、Ｙｅｓの場合はＳ１５に進み、リレー監視実行フラグ５６をオンにし、Ｓ１６に進む。Ｓ１４の判断でＮｏの場合はＳ１６に進み、通信部を呼び出し、サーバ３へリレー状態変更完了を通知し、続いて、Ｓ１７でリレー制御部処理を終了する。リレー制御部５１は、後述する図８のリレー監視部５５のＳ２５、及び、後述する図９のエンジン連動制御部５７のＳ３６により呼び出されて処理が開始される。

次に、図８を参照して、リレー監視部の動作を説明する。Ｓ２１でリレー監視部処理が開始されると、まずＳ２２でリレー監視実行フラグ５６がオンであるか否かを判断する。上述のように、リレー監視実行フラグ５６は、外部リレー２０の監視を実行させるか否かを決定するフラグであり、初期状態（車両の出荷時）、又は、サーバ３からの最後のリレー制御指令が起動可能状態への変更である場合にオンとなる。Ｓ２２の判断がＹｅｓの場合にはＳ２３に進み、外部リレー２０のリレー状態を取得した後、Ｓ２４に進む。一方、Ｓ２２の判断がＮｏの場合にはＳ２６に進み、リレー監視部処理を終了する。Ｓ２４では、Ｓ２３で取得したリレー値が車種毎起動可能リレー値５４以外の値であるか否かを判断し、Ｙｅｓの場合にはＳ２５に進み、リレー制御部５１を呼び出し、リレー設定値５２を起動可能状態に対応する車種毎起動可能リレー値５４で上書きした上で、外部リレー２０の状態を車種毎起動可能リレー値５４に対応する状態へ変更した後、Ｓ２６に進み、リレー監視処理を終了する。一方、Ｓ２４の判断でＮｏの場合には、そのままＳ２６に進み、リレー監視処理を終了する。

リレー監視部の動作は、定期的に行われ、例えば通常モードでは３０秒毎、省電力モードでは１時間毎に行われる。このリレー監視部の動作により、本来起動可能状態であるとき（リレー監視実行フラグがオンのとき）には、車載器のファームウェアの不具合によりメモリ１３が本来の数値と異なる数値に書き換えられてしまった場合でも、常に車両が起動可能状態となるように外部リレー２０を制御することにより、意図せずに車両が起動不可状態になってしまい、正当な車両の利用を妨げてしまうことを防止できる。例えば、車載器のファームウェアの不具合によりメモリ１３のリレー設定値５２の値が意図しない値に書き換えられてしまったような場合でも、リレー監視実行フラグがオンのときには、常に車両が起動可能状態となるように外部リレー２０を制御することにより、車両を起動可能状態に維持することができる。

続いて、図９を参酌してエンジン連動制御部５７の動作を説明する。Ｓ３１でエンジン連動制御部処理が開始されると、Ｓ３２に進み、通信部５０を通してリレー制御指令を受け取り、次にＳ３３に進み、現在のエンジン状態がオフか否かを判断する。Ｓ３３の判断でＹｅｓの場合はＳ３４に進み、Ｓ３４では現在時刻とエンジン停止時刻の差分がリレー変更禁止期間５８（Ｘ分）以上か否かを判断する。Ｓ３３の判断でＮｏの場合及びＳ３４の判断でＮｏの場合には、Ｓ３５へ進み通信部５０を呼び出してサーバ３へリレー制御指令無視を通知した後、Ｓ４１へ進み、エンジン連動制御部の処理を終了する。Ｓ３４の判断でＹｅｓの場合には、Ｓ３６へ進み、リレー制御部５１を呼び出し、外部リレー２０の状態をリレー制御指令に対応する状態へ変更し、Ｓ３７へ進む。Ｓ３７ではエンジン状態再評価期間６０（Ｙ秒）だけ待機した後、Ｓ３８へ進み、Ｓ３８では実行したリレー制御指令は起動不可状態への変更であり、かつ、現在のエンジン状態はオンであるか否かを判断する。Ｓ３８の判断でＹｅｓの場合には、Ｓ３９へ進み、Ｓ３９ではリレー制御部５１を呼び出し、外部リレー２０の状態を車種毎起動可能リレー値５４に対応する状態へ変更した後、Ｓ４０に進む。Ｓ４０では、通信部５０を呼び出し、サーバ３へリレー制御指令無視を通知した後、Ｓ４１へ進み、エンジン連動制御部の処理を終了する。一方、Ｓ３８の判断でＮｏの場合には、そのままＳ４１へ進み、エンジン連動制御部の処理を終了する。

エンジン連動制御部５７の動作は、定期的に行われ、例えば通常モードでは３０秒毎、省電力モードでは１時間毎に行われる。Ｓ３５及びＳ４０では、通信部５０を呼び出してサーバ３へリレー制御指令無視を通知しているところ、サーバ３はこのリレー制御指令が無視されたことを受信すると、図７のＳ１６でリレー状態変更完了が通知されるまで、繰り返し、リレー制御指令を送信する。このエンジン連動制御部５７の動作により、サーバからの指示により車両を起動不可状態に変更する際、車両の安全を考慮し、車両が危険な場所又は他人の迷惑になる場所におかれた状態で起動不可状態になってしまうことを防止できる。リレー変更禁止期間５８（Ｘ分、例えば２分）を考慮することにより、車両の動力をオフにした後すぐに再度車両の動力をオンにするような場合にも、不用意に車両が起動不可状態に切り替えられてしまうことを防止することができる。また、エンジン状態再評価期間６０（Ｙ秒、例えば５秒）を考慮することにより、車両の動力がオンになった直後（Ｙ秒以内）に車載器１が起動不可状態に対応するリレー制御指令を受け取った場合には、リレー制御指令を採用しない（リレー制御指令を無視する）ことにより、車両の動力がオン時に起動不可状態に切り替わるという不具合を防止することができる。

ここまでは、内燃機関車両へ適用し、外部リレーにより内燃機関のエンジン起動制御線（ＳＴ線）を切断することにより起動不可状態へ切り替える車両遠隔制御システムの態様を説明したが、以下では、図１０を参照して、内燃機関車両以外の動力を用いた車両、例えば電気自動車（以下「ＥＶ車両」という。）やハイブリッド電気自動車（以下「ＨＥＶ車両」という。）を含む車両に適用し、起動不可状態へ切り替えるためにＳＴ線制御以外の制御を含む車両遠隔制御システムの態様を説明する。なお、図１〜図９と同様な構成については、同一の符号を用いて、その説明は省略する。

図１０は起動不可状態の制御方式を説明したものである。図１０は、車両の種類として、内燃機関車両、ＥＶ車両、パラレル方式ＨＥＶ車両、シリーズ方式ＨＥＶ車両及びシリーズ・パラレル方式ＨＥＶ車両に分類すると共に、イモビライザを搭載しているか否かに区分した上で、さらに、起動方式をキー式とプッシュ式に区分した上で、起動不可状態の制御方式としてＡ方式、Ｂ方式及びＣ方式の３つの方式の中からどの方式を採用可能かをまとめたものである。３つの制御方式としては、Ａ方式はＳＴ線をカットするもの、Ｂ方式は鍵認証を不可とするもの、Ｃ方式はプッシュボタンを無効化するものである。

キー式及びプッシュ式は、動力を始動するための操作方法で分けたものである。キー式とは、動力を始動するためにキーシリンダにキーを差し込み、ＯＦＦ、ＡＣＣ、ＩＧＮ及びＳＴＡＲＴを切り替える方式のものである。プッシュ式とは、スマートキー式の場合の方式であり、動力始動用プッシュボタンを押すことにより、動力をオンとする方式のものである。

なお、ＨＥＶ車両の定義は、次のとおりである。パラレル方式は、モータとエンジンで車輪を駆動する方式であり、モータを使ってバッテリを充電する方式である。シリーズ方式は、エンジンで発電機を駆動して充電し、モータで車輪を駆動する方式である。シリーズ・パラレル方式は、モータとエンジンで車輪を駆動すると共に、エンジンで発電機を駆動して充電してモータを駆動することができる方式である。

ここで、車載器１の構成は、ＥＶ車両及びＨＥＶ車両に対しても図３で示した内燃機関車両用のものと共通の部分が多いが、ＥＶ車両には内燃機関が無い点、及び、ＨＥＶ車両ではモータだけで走行できるモードが存在する点で内燃機関車両の場合と相違する。ＥＶ車両の場合には、ＩＧＮ入力検知部１７に替えて、プッシュボタンが押されて動力がオンとなっていることを検知する手段を設けることが望ましく、また、外部リレー２０については、後述のように、電子的な手段に置き換えてもかまわない。ＨＥＶ車両の場合には、ＩＧＮ入力検知部１７に替えて、動力がオンとなっていることを検知する手段を設けることが望ましく、また、外部リレー２０については、後述のように、電子的な手段に置き換えてもかまわない。

以下、Ａ方式、Ｂ方式及びＣ方式の３つの制御方式について詳細に説明する。各方式によって、外部リレー２０を挿入する配線が異なるが、いずれの方式の場合にも、起動不可状態のときには動力を始動することが不可能であり、起動可能状態のときには動力を始動することが可能である。

Ａ方式は、本実施形態として、先に説明した方式であり、外部リレー２０によって内燃機関のエンジン起動制御線（ＳＴ線）を切断することにより起動不可状態へ切り替える方式であり、内燃機関車両に適用できる。Ａ方式ではＳＴ線に外部リレー２０が挿入されており、起動不可状態の時に、外部リレー２０を開とすることにより、セルモータへの電力供給を遮断するため、エンジンの始動を阻止することができる。

Ｂ方式は、本実施形態の別の実施例であり、イモビライザーを搭載した車両で採用する方式である。イモビライザーとは、キーに埋め込まれたトランスポンダーと呼ばれるＩＣチップに固有のＩＤコードを記録させておき、トランスポンダーのＩＤコードを車両本体の電子制御装置に登録されているＩＤコードにより認証して、認証が成立した場合にのみエンジンを始動させることできる装置である。Ｂ方式では、イモビライザーにおける車両がトランスポンダーから受け取ったトランスポンダー側のＩＤコードの信号線、又は、イモビライザーにおける車両側のＩＤコードの信号線に対して外部リレー２０を挿入し、起動不可状態では外部リレー２０を開とすることにより、ＩＤコードの認証が不成立となるため、起動不可状態ではエンジンを始動することができない。ここでは、外部リレー２０を用いて起動不可状態とする例を説明したが、起動不可状態のときに、ＩＤコードの認証を不成立とさせれば、どのような手段を用いてもよく、例えば電子的な手段を用いてもよい。なお、電子的な手段を用いる場合にも、リレー入出力部１８（図３を参照。）で、起動不可状態であるか起動可能状態であるのかを検出できるようにしておくことが望ましい。

Ｃ方式は、本実施形態のさらに別の実施例であり、スマートキー式の場合の動力始動用プッシュボタンを備えた車両に採用する方式である。スマートキー式の車両では、動力始動用のキーシリンダーは無く、プッシュボタンが押されたことを電子制御装置へ伝えることによって動力を始動する。例えば、ＥＶ車両にはキー式のものは存在せず、全てプッシュ式である。Ｃ方式は、外部リレー２０をプッシュボタンの配線に挿入し、起動不可状態では外部リレー２０を開とすることにより、起動不可状態ではプッシュボタンを操作しても動力がオンとならない。ここでは、外部リレー２０を用いて起動不可状態とする例を説明したが、起動不可状態のときに、プッシュボタンが押されたことを電子制御装置へ伝えなくすれば、どのような手段を用いてもよく、例えば電子的な手段を用いてもよい。なお、電子的な手段を用いる場合にも、リレー入出力部１８（図３を参照。）で、起動不可状態であるか起動可能状態であるのかを検出できるようにしておくことが望ましい。

イモビライザーありで、キー式の場合、内燃機関車両ではＡ方式又はＢ方式、ＥＶ車両は存在せず、パラレル方式ＨＥＶ車両、シリーズ方式ＨＥＶ車両及びシリーズ・パラレル方式ＨＥＶ車両ではいずれもＢ方式である。

イモビライザーありで、プッシュ式の場合、内燃機関車両ではＡ方式、Ｂ方式又はＣ方式、ＥＶ車両ではＢ方式又はＣ方式、パラレル方式ＨＥＶ車両、シリーズ方式ＨＥＶ車両及びシリーズ・パラレル方式ＨＥＶ車両ではいずれもＢ方式又はＣ方式である。

イモビライザー無しで、キー式の場合、内燃機関車両ではＡ方式、ＥＶ車両は存在せず、パラレル方式ＨＥＶ車両、シリーズ方式ＨＥＶ車両及びシリーズ・パラレル方式ＨＥＶ車両ではいずれの方式も対応不可である。

イモビライザー無しで、プッシュ式の場合、内燃機関車両ではＡ方式又はＣ方式、ＥＶ車両ではＣ方式、パラレル方式ＨＥＶ車両、シリーズ方式ＨＥＶ車両及びシリーズ・パラレル方式ＨＥＶ車両ではいずれもＣ方式である。

［実施形態２］
実施形態１では、図２のステップC２〜Ｃ５の判定を行う例を説明したが、実施形態２では、さらに、カーリースのリース料の支払いの有無の判定を追加した例を、図１１〜図１２を参酌して説明する。なお、図１１〜図１２においては、図１〜図１０と同一の構成については同一の符号を用い、その説明を省略する。実施形態２では、カーリースの場合を例に挙げて、ユーザによる車両についての所定の支払が行われなかった場合に車両を起動不可状態に切り替える制御、及び、ユーザによる所定の支払がなされた場合に車両を再び起動可能状態に切り替える制御について説明する。図１１は、第２実施形態に係る車両遠隔制御システムのブロックであり、図１２は、車両起動制御のフロー図である。

サーバ３は、ユーザ情報管理部３８及び支払状況監視部３０を備えている。支払状況監視部３０は、金融システム３６のＡＰＩ３９を用いてユーザの支払状況を監視する。支払状況監視部３０において監視されたユーザの支払情報は、ユーザ情報管理部３８に送られるので、ユーザ情報管理部３８は、リアルタイムでのユーザの支払状況を把握することができる。ユーザ情報管理部３８は義務情報演算手段７１と接続され、義務情報演算手段７１にて演算された各種義務情報はユーザ情報管理部３８へ送られる。また、ユーザ情報管理部３８はユーザ端末３７と通信可能である。図１１では、無線通信ネットワーク３４による通信、及び、ユーザ情報管理部３８とユーザ端末３７との間の通信を別々に描いているが、無線通信ネットワーク３４により、ユーザ情報管理部３８とユーザ端末３７との間の通信を行うようにしてもよい。すなわち、ユーザ情報管理部３８とユーザ端末３７との間の通信も、例えば２Ｇ、３Ｇ、４Ｇ、５Ｇ、Ｗｉ−Ｆｉ（登録商標）、ＷｉＭＡＸ（登録商標）、無線ＬＡＮ、ビーコン、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）等が挙げられる。

また、ユーザ情報管理部３８には、税金管理システム８１、保険管理システム８２、車検管理システム８３、車両規制データベース８４の情報が提供されており、各ユーザに対応する情報の管理が可能である。このユーザ情報管理部３８を用いることにより、例えば、実施形態１と同様に、図３のＣ２の税金納付の判定の際に、車両２のユーザに対して、ユーザ端末３７を介して、事前に所定の期間内に所定の税金納付を行わないと車両２を起動不可状態にする旨の警告を行い、所定の期間待って、それでも税金の納付がない場合には、車両２を起動不可状態に切り替えるような管理を行うことができる。

図１２を用いて、車両２をリースする場合における、リース料金の支払いの有無に関する判定について詳細に説明する。なお、リース料金支払いに関する判定は、実施形態１の図３のＣ２〜Ｃ５の判定に加えることができる。
ステップＡ１でフローがスタートする。ステップＡ２では、車両の納車時（出荷時）には、車両の起動が可能となるように、車両のエンジン起動外部リレー２０は起動可能状態に設定されている。ステップＡ３では、支払状況監視部３０は、金融システム３６のＡＰＩ３９を用いてユーザの支払状況をリアルタイムで監視して、ステップＡ４では、各車両のユーザから所定の期間内に利用料金の支払いがあったか否か（滞納があるか否か）を判断する。所定の期間内に利用料金の支払いがない際（ステップＡ４でＹｅｓの場合）にはステップＡ５に進む。ステップＡ５では、ユーザに対して料金未納であるため、所定の期間に料金を支払わないと車両を起動不可状態に切り替える旨を警告して、ステップＡ６へ進む。ステップＡ４でＮｏの場合には、ステップＡ３に戻る。

ステップＡ６では、支払状況監視部３０は、金融システム３６のＡＰＩ３９を用いてユーザの支払状況をリアルタイムで監視して、ステップＡ７では、各車両のユーザから所定の期間内に利用料金の支払いがあったか否かを判断する。ステップＡ７の判断がＮｏの場合には、ステップＡ８へ進む。ステップＡ８では、車両の運行状況を確認した上で、所定の条件を満たしている場合には、対応する車両２を起動不可状態とするために、サーバ３は遠隔制御指示部３１から起動不可状態に対応するエンジン起動リレー制御指令を対応する車載器１へ送信して、ステップＡ９へ進む。車載器１は、起動不可状態に対応するエンジン起動リレー制御指令を受け取ると、エンジン起動外部リレー２０を起動不可状態に切り替えるので、対応する車両２は起動不可状態、すなわち、内燃機関車両の場合にはエンジンの始動が不可能な状態となる。本実施形態では、ステップＡ４でＹｅｓの場合（滞納を検出した場合）には、ステップＡ５で一旦ユーザに車両を起動不可状態に切り替える旨の警告を行ったが、本発明はこれに限定されるものでは無く、例えば、ステップＡ４でＹｅｓの場合に、直接ステップＡ８に進み、車両を起動不可状態に切り替えることも可能である。このように、滞納の検出時に直接ステップＡ８に進み車両を起動不可状態に切り替えるか、あるいは、一旦警告を行い車両を起動不可状態に切り替える前に所定の猶予期間を与えるかどうかは、その地域の法令や商慣行等を考慮して決定される。

一方、ステップＡ７の判断がＹｅｓの場合には、ステップＡ３に戻り、支払状況監視部３０は、金融システム３６のＡＰＩ３９を用いてユーザの支払状況をリアルタイムで監視を行う。サーバ３から車載器１へ起動不可状態に対応するエンジン起動リレー制御指令がない状態では、通常、エンジン起動外部リレー２０は起動可能状態に設定されている。したがって、所定の期間内に利用料金の支払いがあった場合（ステップＡ７でＹｅｓの場合）には、サーバ３から車載器１へ起動不可状態に対応するエンジン起動リレー制御指令が送信されないので、エンジン起動外部リレー２０は起動可能状態の設定のままであり、対応する車両２は起動可能状態、すなわち、内燃機関車両の場合にはエンジンの始動が可能な状態となる。

ステップＡ９では、ユーザに対して料金未納のため車両が起動不可状態であることを報知すると共に、所定の期間を指定して所定の料金を支払うように促して、ステップＡ１０へ進む。ステップＡ１０では、支払状況監視部３０は、金融システム３６のＡＰＩ３９を用いてユーザの支払状況をリアルタイムで監視して、ステップＡ１１では、当該車両のユーザから所定の期間内に利用料金の支払いがあったか否かを判断する。ステップＡ１１の判断でＹｅｓの場合（支払い有りの場合）には、サーバ３は対応する車両を再び起動可能状態とするために、遠隔制御指示部３１から起動可能状態に対応するエンジン起動リレー制御指令を対応する車載器１へ送信する。車載器１が起動可能状態に対応するエンジン起動リレー制御指令を受信すると、エンジン起動外部リレー２０は起動可能状態に切り替えられ、対応する車両は再び起動可能状態となる。

利用料金が月額料金の場合には、例えば前月の２５日までに所定の金額が支払われているか否かを確認する（ステップＡ４に対応）。所定の支払が行われていない際には、ユーザに対して滞納であること及び１週間以内に所定の料金の支払いがない場合には車両を起動不能状態にすることのメッセージを送信する（ステップＡ５に対応）。このメッセージの送信から１週間以内に所定の料金の支払いがない場合には、車両の運行状況を確認した上で、所定の条件を満たしていることを条件としてサーバ３は遠隔制御指示部３１から起動不可状態に対応するエンジン起動リレー制御指令を対応する車載器１へ送信する（ステップＡ８に対応）。車両を起動不可能状態にした後、所定の期間例えば1か月が経過してもユーザから所定の料金の支払いがない場合（ステップＡ１１の判断でＮｏの場合）には、管理者は車両情報収集部３２で収集された特定の車両の位置情報を利用して、当該車両の回収する手配を行う（ステップＡ１４に対応、その後はステップＡ１５でエンドとなり、処理を終了する）。

一方、起動不可状態に対応するエンジン起動リレー制御指令を車載器１へ送信した後に、所定の期間内にユーザによる所定の金額の入金が確認された際（ステップＡ１１の判断でｙｅｓの場合）には、サーバ３は遠隔制御指示部３１から起動可能状態に対応するエンジン起動リレー制御指令を対応する車載器１へ送信し、再び、車両を起動可能状態とする（ステップＡ１２に対応）。また、サーバ３から車載器１へ起動不可に対応するエンジン起動リレー制御指令がない状態では、通常、エンジン起動外部リレー２０は起動可能状態に設定されているので、対応する車両は起動可能状態とされる。したがって、毎月２５日までに所定の料金の支払いを済ませていれば、ユーザは車両を起動可能状態のまま利用することができる。

ステップＡ８で車両が起動不可状態に切り替えられ、ステップＡ９でユーザに所定の支払を促した後、ユーザはすぐに車両を使いたければ、速やかに所定の支払を行うことになる。この場合、ユーザはすぐに車両を使いたい状況であるため、所定の支払が行われてから実際に車両が起動不可状態から起動可能状態に切り替えられるまでにタイムラグがると、すぐに車両を使いたいユーザにとっては不利益であり、問題がある。そこで、ステップＡ１０において金融システム３６のＡＰＩ３９を用いてユーザの支払状況をリアルタイムで監視しているため、ステップＡ１１においてはユーザから所定の支払があったことをリアルライムで把握することができ、ステップＡ１２において、所定の支払があってからすぐにサーバ３は遠隔制御指示部３１から起動可能状態に対応するエンジン起動リレー制御指令を対応する車載器１へ送信し、再び、車両を起動可能状態とし、ステップＡ１３でリターンとなる。

車両２を起動不可状態とする際には、車両の運行状態を考慮する必要がある。すなわち、ユーザが車両で移動中に起動不可状態に切り替えた場合には、ユーザにとって過酷な状況が想定されるばかりではなく、他車両の交通を妨害する恐れがあるし、また、後述のように、車両の動力オン状態での外部リレーの起動不可状態への切り替えは車両の種類によっては不具合を生ずる恐れがあり、安全性の観点からも避けるべき条件が存在する。ここで、車両の運行状態をサーバ３が自動的に判断して、車両を起動不可状態に切り替える場合と、起動不可状態への切り替えを見送る場合について例を挙げて説明する。例えば、サーバ３は、車両から収集されたＧＰＳによる位置情報や車両の動力のオン・オフ情報により車両の運行状況を確認し、車両の動力がオフであり、かつ、車両が所定の駐車場にあることを条件として、車両が所定の駐車場に駐車中であると判断し、対応する車両２の車載器１に対して外部リレー２０を起動不可状態にするリレー制御指令を送信して、車両２を起動不可状態に切り替える。この場合には、車両２は所定の駐車場に駐車中であるので、他車両の交通を妨害する恐れがない。また、例えば、サーバ３は、車両の運行状況を確認し、車両の動力がオンであり、かつ、車両が所定の駐車場ではない場所にあるときには、ユーザが車両を利用中であると判断し、対応する車両の車載器１へ外部リレー２０を起動不可状態に切り替えるリレー制御指令を送信することを見送る。このように本発明では、後述のように車載器１が安全性の判断を行うように構成されているため、サーバ３における判断を比較的単純化することができる。

ここでは、各ユーザから所定の期間内に所定の料金の支払いがあったかどうかの判断、ユーザへのメッセージの送信、車両の運行状態の判断、起動不可状態及び起動可能状態に対応するリレー制御指令の送信の判断、並びに、盗難発生時や異常発生時のユーザへの問い合わせ及び警察への通報等を全てサーバで自動的に行う例を説明したが、この判断の中、一部又は全部を管理者が管理者端末３５からマニュアルで行うようにしてもよい。

本実施形態では、車両２をリースする場合を例示したが、本実施形態はリースの場合に限定されるものではなく、例えばカーレンタルやカーシェアの場合にも適用可能である。カーレンタルないしカーシェアの場合には、遠隔制御指令に施錠指令及び解錠指令が含まれ、ユーザ情報管理部３８は、ユーザ端末３７との通信により車両の予約を管理し、予約状況及び支払状況に対応して、ユーザ端末３７へドアロックキー情報を送信すると共に、ユーザ端末３７から施錠指令及び解錠指令を受け付ける。車載器１は、遠隔制御指令としての施錠指令及び解錠指令に基づいて、車両２のドアロックキーの施錠及び解錠を制御する。

１ 車載器
２ 車両
３ サーバ
１１ ＣＰＵ
１２ 無線通信モジュール
１３ メモリ
１４ コンソール入出力
１５ 内部バッテリ
１６ 電源入力検知部
１７ ＩＧＮ入力検知部
１８ リレー入出力
１９ ＧＰＳ入出力
２０ 外部リレー
２１ 外部バッテリ
２２ 走行状態識別線
２３ エンジン起動制御線（ＳＴ線）
２４ ＧＰＳ
３０ 支払状況監視部
３１ 遠隔制御指示部
３２ 車両情報収集部
３３ 送受信部
３４ 無線通信ネットワーク
３５ 管理者端末
３６ 金融システム
３７ ユーザ端末
３８ ユーザ情報管理部
３９ ＡＰＩ
４１ コイル
４２ スイッチ
４３ リレー入出力部側の端子
４４ リレー入出力部側の端子
４５ エンジン起動制御線側の一方の端子
４６ ノーマルクローズ端子
４７ ノーマルオープン端子
５０ 通信部
５１ リレー制御部
５２ リレー設定値
５３ 車種毎起動不可リレー
５４ 車種毎起動可能リレー
５５ リレー監視部
５６ リレー監視実行フラグ
５７ エンジン連動制御部
５８ リレー変更禁止期間
５９ エンジン停止時刻
６０ エンジン状態再評価期間
６１ 収入予測部
７１ 義務情報演算手段
８１ 税金管理システム
８２ 保険管理システム
８３ 車検管理システム
８４ 車両規制データベース

Claims (15)

1. 車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御する車載器と、
   前記車載器から受信した前記車両情報に基づき前記車両のユーザに対する義務に関する義務情報を演算するサーバと、
   からなる車両遠隔制御システムであって、
   前記サーバは、
   前記車載器により収集された前記車両情報を入力する入力手段と、
   前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
   前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
   を有し、
   前記車載器は前記サーバから出力される前記遠隔制御指令に基づき制御されることを特徴とする車両遠隔制御システム。
2. 前記サーバは、税金管理システムと通信可能であり、
   前記義務情報は、ユーザの税金に関する情報を含み、
   前記税金管理システムは、税金納付の有無を含む税金納付情報を前記サーバに提供することを特徴とする請求項１に記載の車両遠隔制御システム。
3. 前記義務情報演算手段は、前記入力手段により入力された前記車両情報に基づき前記ユーザの収入を予測する収入予測手段を備え、
   前記収入予測手段において予測された前記ユーザの収入は、前記義務情報演算手段及び／又は前記税金管理システムにおいて税金額に関する演算に用いられることを特徴とする請求項２に記載の車両遠隔制御システム。
4. 前記サーバは、保険管理システムと通信可能であり、
   前記義務情報は、保険料に関する情報を含み、
   前記保険管理システムは、保険料納付の有無を含む保険料納付情報を前記サーバに提供することを特徴とする請求項１に記載の車両遠隔制御システム。
5. 前記入力手段により入力された前記車両情報は、前記義務情報演算手段及び／又は前記保険管理システムにおいて前記保険料に関する演算に用いられることを特徴とする請求４に記載の車両遠隔制御システム。
6. 前記義務情報は、前記車両の車検に関する車検情報を含み、
   前記義務情報演算手段は、前記車検情報に基づき前記車両の車検が有効であるか否かを判断することを特徴とする請求項１に記載の車両遠隔制御システム。
7. 前記車両情報には前記車検情報が含まれ、前記車載器により収集された前記車検情報は、前記サーバに送信されることを特徴とする請求項６に記載の車両遠隔制御システム。
8. 前記サーバは、車検管理システムとの間で、前記車検情報を通信可能であることを特徴とする請求項６又は７に記載の車両遠隔制御システム。
9. 前記義務情報は車両規制に関する車両規制情報を含み、
   前記サーバには、車両規制データベースから前記車両規制情報が提供され、
   前記車両情報には、少なくとも前記車両の位置情報、及び、前記車両の属性情報が含まれることを特徴とする請求項１に記載の車両遠隔制御システム。
10. 車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御し、かつ、前記車両のユーザに対する義務に関する義務情報を演算するサーバに前記車両情報を送信する車載器であって、
    前記サーバは、
    前記車載器により収集された前記車両情報を入力する入力手段と、
    前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
    前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
    を有し、
    前記サーバから出力される前記遠隔制御指令に基づき制御されることを特徴とする車載器。
11. 請求項１０に記載の車載器を備えたことを特徴とする車両。
12. 車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御する車載器から受信した前記車両情報に基づき前記車両のユーザに対する義務に関する義務情報を演算するサーバであって、
    前記車載器により収集された前記車両情報を入力する入力手段と、
    前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
    前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
    を有し、
    前記遠隔制御指令に基づき前記車載器を制御することを特徴とするサーバ。
13. 車両の車両情報を収集すると共に少なくとも前記車両の起動可能状態ないし起動不可状態を制御する車載器から受信した前記車両情報に基づき前記車両のユーザに対する義務に関する義務情報を演算する車両遠隔制御方法であって、
    前記車載器により収集された前記車両情報を入力する入力手段と、
    前記入力手段により入力された前記車両情報に基づき前記義務情報を演算する義務情報演算手段と、
    前記義務情報に基づいて遠隔制御指令を出力する出力手段と、
    を有し、
    前記遠隔制御指令に基づき前記車載器を制御することを特徴とする車両遠隔制御方法。
14. 請求項１３に記載の車両遠隔制御方法の各手段をコンピュータによって実行することを特徴とする車両遠隔制御プログラム。
15. 請求項１４に記載の車両遠隔制御プログラムを記憶したことを特徴とする記憶媒体。