JP6148296B2 - 車両通信 - Google Patents

Description

本発明は、車両通信に関し、限定ではないが、特に、自動車のような車両と離れて相互作用（たとえば通信および／または制御）する装置、システムおよび／または方法に関する。本発明は、また、家や建物のような他の細目、課題または特性と離れて通信または制御するアプリケーションを見いだしてもよい。本発明の形態は、装置、システム、車両および方法に関する。

車両と離れて通信することを可能にするシステムを開発するためのいくつかの試みがなされてきた。それらのシステムは、一般に、従来の通信ネットワークを使用して、運転者の移動通信装置にメッセージを送信する。しかしながら、これまでは、多くの技術的課題がそのようなシステムの広範な利用を阻んできた。

多くの車両の所有者は、彼らの車両の状態を離れて監視および／または制御できることを歓迎する。車両の所有者が、彼らの車両を彼らの通常の居場所以外の場所または離れた場所に駐めさせられることはよくあることである。例えば、電車で通勤する人は、しばしば駅の駐車場に彼らの車両を放置する。運転者が常に彼が見える場所に車両を置いておくことが可能であることは希である。

運転者にとって、彼の車両の状態を確認できること、および、好ましくは車両のある性状を離れて制御できることは、快適である。本発明の目的は、この問題に対処することである。本発明の実施形態は、移動通信装置を使用して車両の状態を監視および／または制御するための改良された装置、システムまたは方法を提供するかもしれない。本発明の他の目的および利点は、以下の説明、特許請求の範囲および図面から明らかとなるであろう。

このため、本発明の形態は、添付の特許請求の範囲に記載した装置、システム、車両、および方法を提供する。

そのための保護が模索される本発明の他の形態によれば、車両の監視および／または制御のためのシステムが提供される。車両ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）バス上において送信される、１以上の車両システムの状態および／または操作に関するデータ信号を受信する制御手段と、前記受信した１以上のデータ信号に関する情報をユーザに表示するための移動通信装置に送信する通信手段とを含む。

通信手段は、受信したデータ信号を標準ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）ネットワークまたは他の移動体通信ネットワークを介して移動通信装置に送信するように構成されてもよい。

１つの実施形態において、通信手段は、通信ネットワークを介して、従来のユーザ対ユーザ構成の方法で、移動通信装置に情報を直接送信するように構成される。代案または追加策として、通信手段は、中間システムを介して移動通信装置に情報を送信するように構成されてもよい。

たとえば、通信手段は、受信したデータ信号に関する情報を、処理および表示のためおよび／または移動通信装置への前方送信のために、これ以降ウェブポータルと呼ぶインターネットに接続したコンピュータシステムに送信するように構成されてもよい。ウェブポータルは、インターネット接続したウェブサーバにより提供され、従来のインターネットブラウザソフトウェアによってアクセス可能なウェブページの形態のグラフィカルユーザインターフェイス（ＧＵＩ）からなってもよい。ウェブポータルは、ＳＭＳメッセージサービスプロバイダ、ＶｏＩＰサービスプロバイダまたはメールサービスプロバイダのような１以上のサードパーティのサービスプロバイダを使用してＧＳＭネットワークを介して通信信号を送信および受信するように構成されてもよい。

１つの実施形態において、通信手段は、受信した制御信号をＣＡＮバスから受信した形態で送信するように構成される。代案または追加策として、制御手段は、ＣＡＮバスからの制御信号を受信し、制御信号を当該制御信号に対応するデータ信号に変換するように構成されてもよい。

例えば、制御手段は、受信した制御信号を、ＮＶＲＡＭのような関連するメモリまたは他のデータ記憶部に記憶したルックアップテーブルの制御信号の参照リストと比較することにより、受信したそれぞれのＣＡＮ信号を特定または解釈するように構成されてもよい。この構成は、認められていない人または悪意ある人に傍受され得る車両外部への具体的な車両ＣＡＮメッセージの送信を有利にも防止するかもしれない。

移動通信装置は、受信したデータに基づく車両の状態および／または操作に関するユーザ情報を表示するためのソフトウェアプログラム、アプリケーションまたはグラフィカルユーザインターフェイスを含んでもよい。データは、Ｅメール、ＳＭＳメッセージ、ＶｏＩＰメッセージ、電話通話またはデータ警報の形態であってもよい。

１つの実施形態において、通信手段は、車両ＣＡＮバス或いは他のデータネットワークまたは通信ネットワークに接続された送信器／受信器（トランシーバ）の構成を含む。通信手段は、従来のＧＳＭ通信ネットワーク上でデータを送受信するように構成されたＧＳＭトランシーバ構成を有してもよい。

制御手段は、他のマイクロプロセッサおよび装置によってＣＡＮバス上に送信されたＣＡＮパケットを受信するだけでなく、前記マイクロプロセッサおよび装置を制御するためのＣＡＮメッセージの生成もするように構成されてもよい。例えば、システムは、車両の状態に関する警告またはメッセージを受け取ったユーザが、移動通信装置を介してウェブポータルに指示をして、ＧＳＭネットワークを介してトランシーバに指示を送信してもよいように構成されるかもしれない。指示がトランシーバに受信されたとき、制御手段は、指示をルックアップテーブル等の手段によって適当なＣＡＮメッセージに変換し、ＣＡＮメッセージをＣＡＮバスに送信する。このメッセージは、関連するプロセッサまたは装置に受信されて作用する。

１つの実施形態において、移動通信装置上のソフトウェアまたはプログラム（ともに、ｉＰｈｏｎｅアプリ、ブラックベリーアプリまたはノキアアプリのように「アプリ」と記載される）は、ＧＵＩによって「エンジン始動」指示をユーザが選択できるようにしてもよい。一度選択がなされると、移動通信装置は、「エンジン始動」指示を通常のＧＳＭネットワークを介してウェブポータルに送信する。そして、指示は、ＧＳＭネットワークによって車両のトランシーバ装置に中継される。トランシーバ装置を備える制御手段は、指示を受信し、制御手段の記憶部に記憶されたルックアップテーブルに含まれる指示の参照リストと比較する。ルックアップテーブルから、制御手段は、「エンジン始動」に対応するＣＡＮ制御信号を特定し、そして、制御信号を生成してＣＡＮバスに送信する。エンジン始動制御信号は、エンジンの始動によって答える車両制御ユニット（ＥＣＵ）によって受信される。

ある分野では、公道で無人の車両のエンジン始動を行うことは非合法である。この場合、例えば、ＧＵＩは、ユーザにこれについての警告を表示してもよく、および／または、エンジン始動意図の確認を要求してもよい。

代案または追加策として、エンジン始動指示を受けると、制御手段は、車両ＧＰＳまたは衛星ナビゲーションシステムに車両位置情報を要求してもよい。代案として、制御手段は、車両位置を決定するためのＧＰＳ受信器を含んでもよい。車両が公道上にあると判断されるのであれば、システムはエンジン始動を防止してもよい。車両の向き、つまり、例えば、ＧＰＳ受信器データから導き出される方向が、車両が公道上にあるのか、道路に隣接する私有地上にあるのかを決定するのに使用されてもよい。例えば、ＧＰＳデータが車両が公道上にあることを示唆しているが、向き（頭の方位）が通常の道路に使用と一致していなければ、システムは、車両は、公道に隣接する私有地にあると判断する。

制御手段は、従来の盗難車両追跡ユニットを含んでもよい。

警告の種類または特性は、ウェブポータルを使用するユーザによって選択されてもよい。例えば、ウェブポータルおと移動通信装置との間の通信は、Ｅメール、ＳＭＳメッセージ、ＶｏＩＰ通話、または、録音音声メッセージ付きの通常の電話通話の形態をとってもよい。

本願の特許請求の範囲内において、上の段落において記載した多様な形態、実施形態、例、特徴および変形が、特許請求の範囲および／または以下の説明および図面の中おいて個別に、または、それらの組み合わせてとしてなされてもよい。

本発明は、例示の方法としてのみ、添付図面を参照して説明される。
本発明の１つの実施形態のシステムの概念図である。 図１のシステムに関連する部分を示す車両データネットワークの概略図である。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するためのウェブポータルおよび／または移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。 本発明のシステムを操作および／または制御するための移動装置のＧＵＩのスクリーンショットである。

最初に図１を参照すると、本発明の１つの形態を実施するシステムは、参照番号１０で概念的に示されている。車両１２は、車両１２にデータを無線受信および車両１２からデータを無線送信できるトランシーバユニットまたはＤＴＵ２２（図２に図示）が装着されている。

車両１２から送信されるデータは、従来のＧＳＭまたは他の無線または移動体ネットワークを介して、インターネットに接続され、外部に開設されたウェブサイトまたはウェブポータル１４に送信される。ウェブポータル１４のグラフィカルユーザインターフェイス（ＧＵＩ）は、受信した車両１２から送信されたデータを、パーソナルコンピュータ１６のような従来のインターネット接続されたいかなる装置を通してもウェブポータルに接続できるユーザに対する表示または提示を可能にする。

加えて、図示した実施形態において、ウェブポータル１４は、自動的または要求に応じて、受信したデータの一部または全部を１以上の移動通信装置１８（以後、便宜上、移動装置と称呼し、スマートフォンおよびラップトップコンピュータを含むものとする）に送信するようになっている。

移動装置１８は、それ自体がユーザフレンドリーな態様でデータを表示可能なＧＵＩを有する。図３（ａ）は、ウェブポータルと通信するように構成されたアプリに対応するアイコン１８ａを表示するＧＵＩを有する移動装置１８を示す。

図３（ｂ）は、アプリが実行されたときに移動装置１８のユーザに提示されるログオン画面のスクリーンショットである。有効なユーザ名およびパスワードが入力された後、移動装置１８は、ウェブポータル１４へのログインが許可され（図３（ｃ））、すると、ホームページがユーザに提示される。図３（ｄ）は、警告、車両１２の状態（この例では、車両１２は、「施錠および警報」状態である）および走行距離計の読みを表示するためにユーザによりカスタマイズされたホームページのスクリーンショットである。

図４は、ユーザにタイヤ圧力が低いとの警告（この例では、左後輪のタイヤ圧力）が表示されているホームページのスクリーンショットである。この車両の型式、登録ナンバー、走行距離計の読み、および、燃料レベルもまた、例示のホームページに表示されている。

一方、ウェブポータル１４は、移動装置１８からのデータ信号を受信し、そして、自動的または要求に応じて、データ信号の一部または全部を車両に送信するようにもなっている。

よって、ウェブポータル１４は、車両とユーザの移動装置１８との間の２方向通信ネットワークの中間ノードとして機能する。それは、標準ＧＳＭ或いは無線または移動体ネットワーク１３を介して車両により送信された無線データを受信し、同じ無線または移動体ネットワーク１３を介して、例えば、ＳＭＳテキスト、ＶｏＩＰまたはＥメールによって、ユーザに表示するために、移動装置１８にデータの選択した部分または全部を再送信するようになっている。一方、ウェブポータル１４は、また、ユーザの移動装置１８から無線または移動体ネットワーク１３を介して制御データを受信し、制御データを車両１２に再送信するようにもなっている。

次に、図２を参照すると、これは、車両通信ネットワーク２０の一部を概略的に示す。ネットワーク２０は、コントローラエリアネットワーク（ＣＡＮ）バス２４の形態の共用データバスにそれぞれ接続されたマイクロコントローラＭＣ１〜ＭＣ３を含む複数の電子装置を有する。ＣＡＮバスネットワークは、車両システムおよびマイクロコントローラがホストコントローラを必要とせずに互いに通信することを可能にするために従来から使用されており、当業者にはよく理解されているであろう。また、市販の車両の多くは、ＣＡＮプロトコルを利用するが、本発明は、他の形態のデータバスまたはプロトコルの使用に等しく適用できることも理解されるであろう。

自動車は、通常、ＣＡＮバス２４に接続された多数のマイクロコントローラまたは電子制御ユニット（ＥＣＵ）を有し、それらの内の３つだけが図２に示されている。それぞれのマイクロコントローラＭＣ１〜ＭＣ３は、エンジンおよびトランスミッションのようなコアシステムと、エアバッグおよびアンチロックブレーキのような安全システムと、ドア施錠、窓、車両アラームおよびイモビライザのようなセキュリティシステムと、加温シート、電動ミラーＨＶＡＣ（空調）、クルーズコントロール等のような利便機能とを含む少なくとも１つの車両サブシステムと通信および／または制御するようになっている。多くの場合、サブシステム間の通信が必要である。

各サブシステムは、それぞれマイクロコントローラを介してＣＡＮバス２４に接続された１以上のセンサ、アクチュエータまたは制御装置を含んでもよい。例えば、車両ドア施錠システムは、それぞれの車両ドアのために、車両ユーザにより操作可能な１以上のドア施錠スイッチの形態の制御装置、ドアの施錠機構を作動または解除するためのアクチュエータ、および、ドアの施錠／解錠状態を検出するセンサを含んでもよい。制御装置およびセンサは、それぞれマイクロプロセッサ上の制御入力に接続されるが、アクチュエータは、マイクロコントローラ上の制御出力に接続される。

多様なサブシステムの間の通信は、マイクロコントローラによってＣＡＮバス２４上に送信されるデータメッセージまたはパケットを介して達成される。一般に、それぞれのメッセージ（以降、ＣＡＮメッセージと称呼する）は、メッセージ形式または送信するサブシステムを特定するための複数バイトを含む識別子（ＩＤ）と、バス上に順番に送信されるメッセージ本体を含むデータパケットとからなる。ＣＡＮプロトコルは、ホストプロセッサによって制御されないマルチマスター送信シリアルバスプロトコルであるので、それぞれのＣＡＮメッセージは、ＣＡＮバス２４の全てのノードに受信され、各ノードは、たとえ同時でなくても、ＣＡＮメッセージを送信できる。

本発明の図示した実施形態によれば、システムは、マイクロコントローラＭＣ１〜ＭＣ３と実質的に同一の方法でＣＡＮバス２４に接続されたデータ転送ユニット（ＤＴＵ）２２の形態のデータコントロールユニットを含む。特に有利な実施形態において、ＤＴＵ２２は、標準アダプタプラグまたはコネクタを使用して車両の診断ポートを介して、ＣＡＮバス２４に取り外し可能に接続できる。これは、システムが車両との間で簡単に転送できるようにする。

ＤＴＵ２２は、ＣＡＮバス２４とＣＡＮコントローラ２８を介して通信するマイクロプロセッサ２６の形態の処理手段を含む。マイクロプロセッサ２６は、無線トランシーバユニット３０の形態の送受信手段と、ＧＰＳ受信器ユニット３２の形態の位置検知手段と、不揮発性ランダムアクセスメモリ（ＲＡＭ）モジュール３４の形態の記憶手段とに接続されている。

無線トランシーバユニット３０は、登録したＳＩＭカードを使用する標準ＧＳＭまたは他の移動体電気通信ネットワークを介してデータを送信および受信できる従来の送信／受信装置である。そのようなトランシーバユニットは、車両追跡または位置探知システムと呼ばれ、当業者にはよく知られているであろう。

ＧＰＳレシーバユニット３２は、車両ナビゲーションシステムまたは盗難車両追尾システムに見られるような従来のＧＰＳ受信器であり、車両１２の地理的位置を測定するようになっている。重ねていうが、そのような装置の機能および動作は、当業者にはよく知られている。

マイクロプロセッサ２６は、ＣＡＮコントローラ２８を介して、車両１２を通してＣＡＮバス２４に送信された全てのＣＡＮメッセージを受信するようになっている。ＣＡＮバス２４からＣＡＮメッセージを受信すると、マイクロプロセッサ２６は、メモリモジュール３４に記憶されたルックアップテーブルにアクセスして、受信したＣＡＮメッセージがテーブルに含まれるＣＡＮメッセージの参照リストに存在するかどうかを判定する。

ルックアップテーブルの中で、参照リスト内の各ＣＡＮメッセージは、とりわけ、車両１２のサブシステムまたは電子装置の中の特定の事象または状態の変化に関連する。よって、マイクロプロセッサ２６は、受信したＣＡＮメッセージをルックアップテーブルに列挙されたＣＡＮメッセージと比較し、事象または状態の変化を特定する（以降、事象メッセージまたは状態メッセージとそれぞれ称呼する）。

ＣＡＮメッセージの特性および以下の他の状態に応じて、マイクロプロセッサ２６はトランシーバユニット３０に、事象メッセージまたは状態メッセージをＧＳＭ移動体電気通信ネットワーク１３を介してウェブポータル１４に送信すべき旨の指示をするようになっている。有利にも、事象メッセージおよび状態メッセージは、ＣＡＮバス２４から受信したＣＡＮメッセージを表す情報を含むが、ＣＡＮメッセージ自体は含まない。これは、通常、生のＣＡＮメッセージを無線送信することが望ましくないので、セキュリティを向上させる。

ウェブポータル１４は、ＧＳＭネットワーク１３を介して送信された事象メッセージまたは状態メッセージを受信し、それに基づいて、以下に記載するように情報を処理する。例えば、ウェブポータル１４は、情報を、ユーザが参照するデータベースに記憶するようになっていてもよい。データは、ウェブポータル１４上で、パーソナルコンピュータ１６または移動通信装置１８のようなインターネット接続されたいかなる装置からも直接見ることができる。

加えて、ＣＡＮメッセージの特性および以下に説明する他の状態に応じて、ウェブポータル１４は、ＧＳＭネットワーク１３上に、例えばＳＭＳテキストメッセージ、ＶｏＩＰまたはＥメールとしてユーザの移動装置１８に、ユーザに車両１２の中の事象または状態の変化を知らせる警告メッセージを送信する。

一方、ＤＴＵ２２内のトランシーバユニット３０は、ＧＳＭ移動体電気通信ネットワーク１３を介してウェブポータル１４から入ってくるデータメッセージを受信するようにもなっている。そのようなメッセージは、車両のシステムまたは機能を離れて制御するための制御メッセージを含んでもよい。

トランシーバユニット３０がＧＳＭネットワーク１３上に送信されたメッセージを受信したとき、メッセージは、マイクロプロセッサ２６に渡され、そして、マイクロプロセッサ２６はＮＶＲＡＭモジュール３４のルックアップテーブルにアクセスして、制御の要求を達成するための正しいＣＡＮメッセージを決定する。

例えば、受信した制御メッセージは、「ドア施錠」の指示を含むかもしれない。この場合、マイクロプロセッサ２６は、「ドア施錠」の指示をルックアップテーブル内で探し、そして、対応するＣＡＮメッセージコードを特定する。つまり、ＣＡＮプロトコル形式は、上述のように、１以上のＩＤビットおよび複数の情報ビットを含む。

受信した制御メッセージに対応する適切なＣＡＮメッセージがルックアップテーブル内で特定されたとき、マイクロプロセッサ２６は、ＣＡＮメッセージを生成し、それをＣＡＮバス２４上に送信する。ＣＡＮメッセージは、ドア監視システムのためのノード（マイクロコントローラ）によって受信され、ドア監視システムは、それに応じてドアを監視する。

受信した制御メッセージに応じてＤＴＵ２２により生成されたＣＡＮメッセージは、通常、指示が関連システムまたはサブシステム自身により開始されたなら生成されるＣＡＮメッセージと区別がつかないか実質的に区別できない。よって、車両ドアを監視すべきマイクロコントローラは、キーフォブ（キーリモコン）またはドア監視スイッチから指示があったのと同様に反応する。これは、ＤＴＵ２２によりＣＡＮバス２４上に送信された全てのＣＡＮメッセージに当てはまる。

したがって、重要にも、ＤＴＵ２２は、ＣＡＮバス２４から受信したＣＡＮメッセージを受信して解釈できるだけでなく、車両システムおよびサブシステムを制御するために、正しいＣＡＮプロトコル形式でＣＡＮメッセージを生成し、それらをＣＡＮバス２４上に送信できる。

ＮＶＲＡＭモジュール３４に記憶されたルックアップテーブルは、ＣＡＮバス２４から受信したＣＡＮメッセージを、ＧＳＭネットワーク１３を介してウェブポータル１４に送信するための事象メッセージまたは状態メッセージに変換、および、ＧＳＭネットワーク１３を介してウェブポータル１４から受信した制御メッセージを、ＣＡＮバス２４上に送信するためのＣＡＮメッセージに変換するための翻訳ツールとして機能する。

以上より、ウェブポータル１４に、それ故ユーザの移動装置１８に送信され得る状態情報および事象情報、並びに、ユーザの移動装置１８からウェブポータル１４を介して車両１２に送信され得る制御情報は、通常、ＣＡＮプロトコルの下で使用可能なＣＡＮメッセージの形式よってのみ限定される。

実質的に、一般に車両ＣＡＮバス２４上においてシステムの間で送信される事象または車両状態に関するいかなるメッセージも、受信、解釈および車両１２からＧＳＭネットワーク１３を介してウェブポータル１４に送信され得る。一度、ウェブポータル１４によって受信されると、情報は、記憶され、従来のユーザフレンドリーおよび／またはユーザが設定可能な方法でユーザに対して表示され得る。

加えて、望むのであれば、事象情報または状態情報は、ＳＭＳテキスト、ＶｏＩＰまたはＥメールのような（ウェブポータル１４のＧＵＩ上でユーザにより選択できる）いかなる所望の方法によっても、車両１２の中の状態または事象の警告をするために、ウェブポータル１４によってユーザの移動装置１８に再送信され得る。

同様に、実質的に、通常、車両ＣＡＮバス２４上においてシステムの間で送信されるＣＡＮメッセージに対応するいかなる制御メッセージも、ウェブポータル１４によって生成されて送信され得、ＧＳＭ移動体ネットワーク１３を介してトランシーバユニット３０に受信され得、マイクロプロセッサ２６によりＮＶＲＡＭモジュール３４のルックアップテーブルを使用して適切なＣＡＮメッセージ（つまり、ＣＡＮプロトコル形式）に変換され得、適切なマイクロコントローラＭＣ１〜ＭＣ３に受信されるためにＣＡＮバス２４上に送信され得る。

ユーザは、インターネット接続されたいかなる装置１６によってもウェブポータル１４にアクセスすること、または、移動装置１８よって所望の制御メッセージをウェブポータル１４にアップロードすることのいずれによって、制御メッセージが車両１２に送信されるかを選択できる。制御装置１８は、ウェブポータル１４と実質的に同じ情報および制御機能を表示できるＧＵＩを含む。

１つの有利な実施形態において、移動装置１８は、実質的にウェブポータル１４の完全な読み書き機能を提供する搭載アプリケーションソフトウェア（一般にアプリとして知られる）を特徴付ける。よって、車両１２からウェブポータル１４を介して受信した事象情報または状態情報は、ユーザに対して映像的または音響的に表示され得、制御メッセージ（例えば、指示）は、ウェブポータル１４を介して車両１２に送信するために、ＧＵＩまたはキーボードを使用して移動装置１８に入力され得る。

１つの例では、ユーザは、車両に「状態要求」メッセージをアップロードすることによって、車両１２からの状態情報を要求できる。この場合、ユーザは、ウェブポータル１４上で直接要求できる。インターネット接続されたコンピュータまたはラップトップ１６を介して（その場合、要求はインターネットを介してウェブポータル１４に送信される）、或いは、移動装置１８上のアプリケーションソフトウェアを使用して（その場合、要求は、ＧＳＭネットワーク１３を介してウェブポータルに送信される）。

ウェブポータル１４がユーザからの状態要求を受信したとき、メッセージは、ＧＳＭ（登録商標）ネットワーク１３上で車両１２に送信され、ＧＳＭ（登録商標）ネットワーク１３では、ＤＴＵ２２のトランシーバユニット３０により受信されて、マイクロプロセッサ２６により適切なＣＡＮメッセージ（つまり、プロトコル形式）に変換される。ＣＡＮメッセージを受け取ると、それぞれのマイクロコントローラＭＣ１〜ＭＣ３は、従来の方法で、多様な車両センサＳ１〜Ｓ３、アクチュエータＡ１〜Ａ３および制御装置Ｃ１〜Ｃ３に問い合わせをし、所定のシステム状態に対応する関連するＣＡＮメッセージをＣＡＮバス２４上に送信する。ＣＡＮメッセージは、ＣＡＮコントローラ２８を介してマイクロプロセッサ２６により連続して受信され、ＧＳＭ（登録商標）ネットワーク１３を介してウェブポータル１４および／またはユーザの移動装置１８に送信するための状態メッセージに変換される。

ユーザにより出された情報要求は、全ての状態情報がＤＴＵ２２によってウェブポータル１４に送信され、そしてユーザの移動装置１８にダウンロードされる全体状態要求、或いは、ドア施錠状態のような特定の車両システムまたはサブシステムの状態要求であり得る。

出願人は、発明の完全に機能および動作する形態の実施を低減した。図３ｂ〜１５は、本発明の実施形態のためのウェブポータルおよび移動装置アプリケーションソフトウェアのＧＵＩスクリーンショットを示す。これらの多くは、図示内容から一目瞭然であるため、当業者には完全に理解されるであろう。

とはいうものの、本発明のある実施形態の様々な有利な特徴が、これより説明される。当然に、説明される特徴は、ユーザの能力に応じて、個別に、または、いかなる組み合わせで取り入れてもよく、それらは、本発明をいかようにも限定することを意図しない。

本願の目的のために、「状態」との用語は、他の定義の中でも、車両システム、サブシステムまたはパラメータの測定した状態を意味する。「事象」との用語は、他の定義の中でも、監視されたシステムまたはサブシステムの状態の変化を意味する。状態または事象の測定値は、自動的、あらかじめ定めたように、選択した基準で、または、要求に応じてのいずれかで、ホストに送信される。

＜車両状態＞
本発明の重要な機能は、ユーザが離れて多様な車両システムおよびサブシステムの状態を判定できることである。本発明の１つの実施形態において、これは、少なくとも２つの方法で達成され得る。

ａ）自動
通常のエンジンが動いている状態の間、車両システムおよびサブシステムによりＣＡＮバス２４上に送信されたＣＡＮメッセージは、ＤＴＵ２２に受信される。本発明のシステムに関係しないあるＣＡＮメッセージは、マイクロプロセッサ２６に無視される。ルックアップテーブルの参照リストに含まれる他のＣＡＮメッセージは、システムに関連し、ＮＶＲＡＭモジュール３４に記憶される。

車両システムまたはサブシステムの状態が変化して、ＣＡＮバス２４上に事象メッセージを生じさせるので、ＮＶＲＡＭモジュール３４に記憶されたメッセージは、更新される。例えば、燃料レベルが５０％から４０％に低下したなら、対応するＣＡＮメッセージがＣＡＮバス２４上に生成され、ＤＴＵ２２に受信されてもよい。マイクロプロセッサは、燃料レベルに関する状態情報をＮＶＲＡＭ３４に書き込む。車両エンジンが停止したときおよび／または始動キー（もしあれば）が取り外されたとき、ＮＶＲＡＭ３４は、複数の車両システムまたはサブシステムの現在の状態情報を含む。

エンジンを停止すると、＜エンジン停止＞事象（ＣＡＮメッセージ）がエンジン制御ユニット（ＥＣＵ）によって生成され、ＣＡＮバス２４上に送信されて他の相互に関連するサブシステムに受信される。本実施形態によれば、＜エンジン停止＞ＣＡＮメッセージを受信すると、ＤＴＵ２２のマイクロプロセッサ２６は、上述のように、トランシーバユニット３０に、エンジンを停止する前の車両システムの最新の状態情報を表す、ＮＶＲＡＭモジュール３４に記憶されている現在の状態情報を、ＧＳＭネットワーク１３を介してウェブポータル１４に送信させる。

このエンジン停止時の車両状態情報のバルクダンプ（一斉送信）は、ウェブポータル１４が、エンジンが停止した時点の車両システムに関する全ての状態情報を受信して記憶することを可能にする。このため、ユーザは、ウェブポータルから車両１２に情報を要求する必要なしに、ウェブポータル１４に車両状態情報を要求できる。これはいくつかの実施形態において車両バッテリの消費を低減するかもしれないという利点を有する。

ｂ）ユーザ要求
とはいえ、ユーザがエンジン停止後に車両システムの状態を確認することを要求する場合があってもよい。代案として、ある車両システムの状態がエンジン停止後に変化してもよいことも可能である。例えば、ユーザは、車両を使用する前に、車両ＨＶＡＣを動作させる制御指示を出すかどうかを決定するために、車室温度を確認したいと望むかもしれない（以下を参照）。

そのような状態情報が必要であれば、ユーザは、インターネット接続されたコンピュータ１６の使用、或いは、移動装置１８のアプリケーションソフトウェアの使用のいずれかにより、ウェブポータル１４と通信して、ウェブポータルに関心のある車両サブシステムの状態要求（制御メッセージ）を生じさせられる。状態要求は、上述のように、ウェブポータル１４により、ＧＳＭネットワーク１３上で車両１２に送信され、ＤＴＵ２２によって受信されて変換されて、プロトコル形式のＣＡＮメッセージとしてＣＡＮバス２４上に送信される。

対応するマイクロコントローラからＣＡＮバス２４上で受信した状態応答（ＣＡＮメッセージ）は、ＤＴＵ２２により対応する状態メッセージに変換され、ＧＳＭネットワーク上でウェブポータル１４に送り返される。そして、ウェブポータルの関連する状態情報は、ユーザに表示するためにデータベースに記憶され、或いは、移動装置１８に何らかの所望の形式で送信される。

＜環境＞
図５（ａ）は、ユーザにより要求された環境状態を表示している移動装置１８のスクリーンショットである。スクリーンショットは、環境制御システムにより選択された運転者および同乗者の空気温度が２３℃であり、ファン速度が低に設定されていることを示す。空調、シートヒータおよびガラスデミスタ（霜取り器）がオンされており、ハンドルヒータがオフされていることも見て取れる。スクリーンショットは、また、外気温度が３℃であり、客室温度が５℃であることも示している。

図５（ｂ）は、車両の環境状態を示す代案の環境データ表示を有する移動装置１８のスクリーンショットである。客室温度が２２℃であり、外気温度が−４℃であることが見て取れる。天気予報を示すアイコンもユーザに提示されている。

いくつかの実施形態において、天気予報は、ウェブポータル１４によって、インターネット上の天気データサーバから取得される。

図５（ｃ）は、ユーザが要求した環境情報を示す移動装置１８のスクリーンショットである。スクリーンショットは、環境制御システムにより選択された運転者空気温度が２３℃であり、ファン速度が低に設定されていることを示す。空調、ハンドルヒータ、前側デミスタおよびガラスデフロスタ（霜取り器）がオフされているが、後側デミスタがオンされていることも見て取れる。

セキュリティ
図６は、車両１２のセキュリティ状態を表示している移動装置１８のＧＵＩのスクリーンショットを示す。図６（ａ）のスクリーンショットは、車両が安全であること、つまり、ドア、ボンネットおよび後部ゲートが施錠されており、窓が閉じられており、警報が発報されていないことを示す。

ユーザが車両状態についてさらなる情報を要求すれば、そのような情報がユーザに提示されてもよい。例えば、さらなる情報は、車両走行距離計の走行距離の読み、タイヤ圧力状態、ライト状態、燃料状態およびオイル状態を含んでもよいが、これらは限定ではない。ユーザは、また、車両が使用されているか、例えば、車両に隠れている侵入者があるか（例えば、人の鼓動を検出するための車両内の音響測定による）に関する情報を要求してもよい。加えて、ユーザは、（適用可能であれば）特定の位置における駐車時間の残りに関する情報、および、車両点検情報、例えば、次の点検期限を要求してもよい。

例えば、車両が図６（ａ）の「安全状態」であれば、ユーザは、車両のセキュリティに関する異なる車両システムの状態の確認をしてもよい。図６（ｂ）は、そのような情報の要求の後の移動装置１８のスクリーンショットである。

この実施形態には、車両の位置を示すようにもなっているＧＵＩのスクリーンショットが示されている。

図６（ｃ）および（ｄ）は、画面解像度の低い移動装置１８上の同様の情報を示すスクリーンショットであり、そこでは、情報はユーザが選択できる２つの異なる画面に提示される。

図７（ａ）は、車両１２が安全でないこと、つまり、少なくとも１つのドア、ボンネット、後部ゲートが施錠されていないこと、および／または、少なくとも１つの窓が閉じられていないことを示すスクリーンショットである。

図７（ｂ）は、車両１２がそのような安全でない状態であり、ユーザが図７（ａ）に提示されたものを超える車両の状態についてのさらなる情報を要求したときの、移動装置１８のスクリーンショットである。図７（ｂ）のスクリーンショットからは、車両１２の窓およびサンルーフが開いており、車両１２の警報機能が有効になっていることが見て取れる。

図８（ａ）は、車両１２が安全でなく、前にユーザが確認してから、車両警報が少なくとも１回作動したことを表示するスクリーンショットである。

図８（ｂ）および（ｃ）は、車両１２についてのさらなる情報を示す対応するスクリーンショットである。図８（ｃ）において、車両１２が、警報が鳴動し、ドアが解錠された状態であることを報告されていることが見て取れる。

車両情報
図９は、車両１２の全体状態および警告情報を示している移動装置１８のＧＵＩのスクリーンショットである。

特に、図９（ａ）は、車両のライト、ブレーキ液、ブレーキパッド摩耗、冷却液レベルおよびウォッシャ液レベルを示す（図に全て図示）。図９（ａ）は、また、燃料レベル状態、バッテリ状態、およびオイルレベル状態も示す。車両タイヤ圧力に関する車両警告も、図９に見られる。図のさらなる情報は、前回および次回の車両点検の日付および次のＭＯＴ（車検）の日付を含む。

図９（ｂ）は、画面解像度の低い移動装置１８上の同様の情報を示すスクリーンショットを図示する。図９（ａ）のように、ライト状態、燃料レベル状態（７３％）、オイルレベル状態、ブレーキ液状態、ブレーキパッド状態、および、冷却液レベルが全てＯＫと示されている一方、車両警告がタイヤ圧力およびバッテリ状態に関して表示されている。

図１０（ａ）は、車両警告のログを表示する移動装置１８のＧＵＩのスクリーンショットであり、特に、図１０（ａ）は、右後輪タイヤ圧力が低く、バッテリが充電されていないことを示す。図１０（ｂ）は、画面解像度の低い移動装置１８上に同様の情報を示すスクリーンショットを図示する。この例において、スクリーンショットは、バッテリ状態警告および右後輪タイヤ圧力が低い旨の警告を示す。

＜事象警報＞
エンジンが停止した後、車両システムまたはサブシステムの中でユーザ告知を要する事象が多分に発生し得る。それらは、安全およびセキュリティ事象、例えば、ドア施錠または解錠、ドア不正操作、車両警報またはイモビライザの発報、タイヤ圧力低下、エンジン始動、車両移動、トランクまたはボンネットの解錠または解放などを含むが、限定ではない。

本発明の実施形態によれば、ＣＡＮメッセージは、車両システムまたはサブシステムの何らかの状態が変化したときにＣＡＮバス上で生成されてもよい。ＣＡＮメッセージは、適当なマイクロプロセッサにより生成されてＣＡＮバス上に送信され、ＤＴＵ２２によって受信される。ＤＴＵ２２は、ルックアップテーブルによってＣＡＮメッセージを対応する事象メッセージに変換し、その事象メッセージをＧＳＭネットワーク１３を介してウェブポータル１４に送信する。

いくつかの実施形態において、事象メッセージは、変化したシステムの新しい状態を示すようになっている。例えば、車両施錠システムの状態の変化の場合、あり得る状態は、解錠、部分施錠、集中施錠、二重施錠および二重施錠されていない盗難防止を含む。

ＣＡＮバス２４上のＣＡＮメッセージのようにシステムの状態にそれぞれの変化が報告されると理解すべきである。例えば、車両が入り口が一カ所に構成され、車両が解錠されていれば、車両が続いて部分施錠されたときにＣＡＮメッセージがＣＡＮバス２４上で生成され、車両が続いて完全に施錠されたとき、さらなるＣＡＮメッセージメッセージが送信される。

いくつかの実施形態において、ＤＴＵ２２は、それぞれのＣＡＮメッセージを検出して、そのようなメッセージをそれぞれウェブポータル１４に報告するようになっている。いくつかの実施形態において、複数のＣＡＮメッセージの中の１つが検出されたとき、単一の事象メッセージが生成されてウェブポータル１４に報告されてもよい。例えば、事象「部分施錠」および「解錠」は、車両が「解錠」状態であることを示す単一の事象メッセージで伝えられてもよい。

同様に、施錠システムの状態の中央施錠状態、二重施錠状態よび二重施錠されていない盗難防止状態への変化に対応するＣＡＮメッセージは、車両が「施錠」状態であることを示す単一の事象メッセージに集約されてもよい。

他のＣＡＮメッセージに対応する他の事象メッセージが生成されてもよいことが理解されるべきである。例えば、事象メッセージは、ドアまたはトランクまたはボンネットのいずれかの状態が変化したときに生成されてもよい。ドアの状態の変化の場合、事象メッセージは、どのドアが解放または閉鎖されたかの表示を含んでもよい。

それぞれの状態変化が事象メッセージとして送信される場合、ドアの開放および続くドアの閉鎖は、２つの事象メッセージの生成を引き起こすであろう。４人の人が別々のドアから車両に搭乗した場合、車両の４つのドアのそれぞれの状態の変化に対応して、８つの事象メッセージが送信されるかもしれない。

いくつかの実施形態において、それぞれのドア、トランク、ボンネットに、それぞれ、事象メッセージが生成される前少なくとも１秒間を新しい状態と推定するようなフィルタが設けられる。これは、ドア、トランクまたはボンネットが閉鎖されたときのスイッチのばたつきによる望まざる事象メッセージの生成を防止する。

いくつかの実施形態において、車両が車両警報の動作している状態であるときのみ、外部からのドア不正操作事象に対応する事象メッセージが生成される。いくつかの実施形態において、事象メッセージは、ドアハンドル入力が２００ｍｓ以上動作したときだけ生成される。

事象メッセージは、ドアまたは後部ゲート開放装置の不正操作の検出に対応して生成されてもよい。

本発明のいくつかの実施形態において、システムは、１以上の警報を送信する前に、車両１２のユーザが車両１２からある距離内にいるか否かを判断するようになっている。例えば、システムが、（例えば、ブルートゥース接続、ＧＰＳおよび／または他の何らかの適当な手段によって）ユーザが車両１２からある距離内にいると判断したなら、ドア不正操作事象に対応するＣＡＮメッセージが検出されたときに、ドア不正操作ＣＡＮメッセージに対応する事象メッセージをウェブポータル１４に送信すべきでないと判断してもよい。

いくつかの実施形態において、ＤＴＵ２２は、対応するＣＡＮメッセージを検出しても、ＣＡＮメッセージが所定時間検出されている間に１以上の他の基準に合致しなければある事象メッセージを送信しないようになっている。

例えば、ある車両においてドアハンドルは、ドアを解錠可能とするために、例えば、ハンドルが動作したときのみアクセス可能な錠にキーまたは他の装置が差し込まれなければならない。そのような実施形態において、ＤＴＵ２２は、ハンドルの動作の後、ドア不正操作事象に対応する事象メッセージを送信する前に、ある秒数のような、あらかじめ定めた時間だけ待つようになっていてもよい。ＤＴＵ２２は、（例えば）２秒のドアハンドルの動作の間に、ドア解錠命令に対応するＣＡＮメッセージが検出されたなら、ドア不正操作に対応する事象メッセージを送信しない。それは、キーに代えて、ＲＦＩＤ（電波方式認識）タグまたは他の適当な手段によってドアが解錠されてもよいと理解されなければならない。

いくつかの実施形態において、事象メッセージは、車両アラームが発報したときに生成されてもよい。事象メッセージは、警報を発報した理由を含んでもよい。例えば、事象メッセージは、警報の発報をもたらした複数の理由の表示を提供してもよい。例えば、事象メッセージは、電力消費の変化による警報が発報したこと、傾斜センサにより提供される車両の傾斜の変化、容積センサにより提供される容積の変化、ドアの開放、トランク（後部ゲート）またはボンネットの解放、サイレンの鳴動、車両始動の試み、モジュールのＣＡＮメッセージバス２４の取り外しおよび／またはラッチ状態の変化の表示を提供してもよい。

さらに、いくつかの実施形態において、複数のＣＡＮメッセージの中の１つがＣＡＮバス２４上に生成されたときに、単一の事象メッセージが生成されてウェブポータル１４に送信されてもよい。例えば、ドア、トランクまたはボンネットが不正操作されたことに対応するＣＡＮメッセージとともに、ドアに起因するというような、警報を発報する理由が送信されてもよい。

「不正操作」との用語は、承認されていない人によって作られた対応するドアハンドルのような解除装置を使用してドアまたは後部ゲートを開放しようとする試みを意味するものと理解しなければならない。

いくつかの実施形態において、ＤＴＵ２２は、車両１２のバッテリ変化の状態を（例えばバッテリの電圧を測定することによって）監視し、電圧が所定の閾値以下に低下したなら、「低バッテリ」事象メッセージを生成するようになっている。閾値は、ＮＶＲＡＭモジュール３４に記憶されてもよい。

いくつかの実施形態において、車両１２は、１以上の推進バッテリを有してもよい。推進バッテリは、車両１２を推進するように構成された電気機械に電力を供給するようになっている。そのような車両は、電気自動車およびハイブリッド電気自動車（ＨＥＶ）を含む。そのような車両において、ＤＴＵ２２が、車両１２の他のいずれかのバッテリに加えてまたは代わりに、充電状態が所定の閾値以下に低下する事象において、ユーザに警告するために、１以上の推進バッテリの変化の状態を監視するように配設されてもよい。

いくつかの実施形態において、イグニッションがオフのとき、ＤＴＵ２２は、間隔を空けて、例えば４時間おきに、バッテリ電圧を監視する。いくつかの実施形態において、イグニッションがオンのとき、バッテリは、実質的に絶えず監視される。

代案または追加として、ＤＴＵ２２は、「低バッテリ」（または同様の）ＣＡＮメッセージがＣＡＮバス２４上に送信されたときを判定し、対応する警報をユーザに提供するようになっている。

いくつかの実施形態において、一度、低バッテリ事象メッセージが生成されたなら、ＤＴＵ２２が、電圧が所定の量、例えば１ボルトだけ閾値より多くなるまで、さらなる低バッテリ事象メッセージを送信することが防止される。

他の事象メッセージがＣＡＮメッセージに対応して生成されてＣＡＮバス２４に送信されてもよい。例えば、粗暴な加速、粗暴な減速、速度超過、車両アイドリング、最適速度での運転、低燃料レベル、急な燃料消費、エンジン故障、ギアボックス故障、低オイルレベル、および／または、ブレーキシステム故障を示す事象も生成されてもよい。

いくつかの実施形態において、車両１２内に侵入者が検出されたなら、ＣＡＮメッセージがＣＡＮバス上に送信される。いくつかの実施形態において、侵入者は、受動赤外（ＰＩＲ）検出器または超音波検出器のような運動センサによって検出されてもよい。いくつかの実施形態において、侵入者の鼓動が例えば音波のような圧力波によって検出される。

ウェブポータル１４は、事象メッセージを受信し、データベースを新しい状態情報に更新する。そして、ウェブポータル１４は、システム構成またはユーザ選択に応じて、警報メッセージを、例えば、ＳＭＳメッセージ、ＶｏＩＰ、Ｅメールなどによって、ユーザの移動装置１８またはパーソナルコンピュータ１６に送信する。

ユーザがいつ、どのように、どの事象の警報が送信されるかを選択できることが予想される。例えば、ユーザは、警報動作或いは承認されていないエンジン始動または車両移動に関する警報を直ちに受信することを望み、ウェブポータルがそのような警報をＳＭＳメッセージにより送信することを選択してもよい。一方、ユーザは、他の優先度の低い事象がＳＭＳ警報として送信されないが、Ｅメールとして送信されることを望むかもしれない。

それぞれのタイプの事象のために複数の警報が生成され得、ユーザに事象毎に１または複数の方法で警告できる。ユーザは、また、警報の好ましいタイミングを設定できる。上述のユーザ設定は、ウェブポータル１４またはＧＳＭネットワーク１３を介してウェブポータル１４にアップロードするための移動装置１８のＧＵＩを使用して設定できる。例として、ユーザ設定を設定するための移動装置１８のＧＵＩのスクリーンショットを示す図１１（ａ）〜１１（ｃ）を参照のこと。

ウェブポータル１４が受信した全ての事象メッセージをユーザが検査するためのログに記録してもよい。図１２（ａ）および１２（ｂ）は、移動装置１８のＧＵＩの事象警報のログを示すスクリーンショットを図示する。

加えて、事象警報が報告される選択可能な方法に加えて、ユーザは、前記警報に関する詳細な連絡先、例えば、ＳＭＳ警報および電話メッセージのための電話番号、或いはＥメール警報のためのＥメールアドレスを修正してもよい。図１３（ａ）および１３（ｂ）は、電話番号およびＥメールアドレスを含むユーザの個人情報を修正するための移動装置１８のＧＵＩのスクリーンショットを図示する。

いくつかの実施形態において、車両が認可されていないユーザによって運転されていると判断された事象において、ＤＴＵ２２は、間隔を空けてまたは実施的に絶え間なく、ウェブポータル１４に位置情報を送信するようになっていてもよい。

いくつかの実施形態において、ＤＴＵ２２は、あらかじめ定めた時刻またはあらかじめ定めた事象が発生したときに、車両状態情報をウェブポータル１４に送信するようになっていてもよい。

例えば、旅程の最後に車両イグニッションがオフされたとき、次の情報がウェブポータル１４に送信されてもよい：車両位置（例えばＧＰＳまたは他の地理的座標）、旅程中に使用した燃料の量、旅程中に達成された燃費（消費燃料のマイル／ガロンまたはキロメータ／リットルの平均値など）、アイドリング時間、最適速度時間、走行距離、走行距離計読み、オイルレベル、燃料レベル、ウォッシャ液レベル、冷却液レベル、または他の何らかの液レベルのような液レベル状態、ライト故障のような外部ライト状態。他の情報が、加えてまたは代わりに送信されてもよい。

走行中に、ウェブポータル１４は、間隔を空けて、車両が止まっているか移動しているか、車両バッテリ電圧、冷却液温度、燃料レベル、オイルレベル、冷却液レベルまたは他の何らかの液レベルのような液レベル、走行距離計読みおよび／またはその旅程開始時からの走行距離、車両施錠状態、ドア状態、タイヤ圧力状態、ライトの故障のような外部ライト状態、および／または、タイヤ圧力状態について、更新してもよい。他の情報が、加えてまたは代わりに送信されてもよい。

いくつかの実施形態において、ウェブポータル１４にアクセスして見ることができる地図上に車両の位置が表示されてもよい。代案または追加として、情報がユーザの地図を見るための移動装置に送信されてもよい。

いくつかの実施形態において、ウェブポータル１４は、音声通話によって事象の発生をユーザに告知するようになっていてもよい。音声通話は、あらかじめ録音したメッセージを再生するようになっていてもよい。メッセージは、発生した事象に特有であってもよい。他の構成も有用である。

システムは、ユーザが１以上の警報のそれぞれが受信され、それにより所定の警報の連絡の彼らが望む方法にしたがってシステム設定をカスタマイズできるような方法を決定できるようになっていてもよい（図１１（ａ）および１１（ｃ）参照）。

ウェブポータル１４は、所定の１以上の警報メッセージおよび／または他のメッセージが複数のユーザに連絡されることを可能にするようになっていてもよい。

例えば、システムは、バッテリ低警報メッセージのような１つの警報を、ユーザおよび例えば保証部門のような自動車メーカーの部門などの第三者に送信するようになっていてもよい。システムは、警報動作警告を、ユーザに送信するが第三者に送信しないようになっていてもよく、或いは、ユーザに送信し、警備会社または自動車を駐車していた駐車場のオペレータのような第三者にも送信するようになっていてもよい。他の構成も有用である。

いくつかの実施形態において、ウェブポータル１４は、例えば駐車場で車両を駐車するために支払った料金の時間のような時間の時間切れについてのリマインダを提供するようになっていてもよい。

いくつかの実施形態において、システムは、車両１２に接続された被牽引車が切り離されるような事象において、警告をユーザに提供するようになっていてもよい。例えば、車両１２が無人で駐車場に残されているが、泥棒によって被牽引車が切り離されているかもしれない。よって、ユーザは、被牽引車の盗難について警告を受け得る。

＜車両制御＞
本発明の実施形態の第三の機能は、車両遠隔操作機能、システムまたはサブシステムである。

例えば、駐車した状態の車両、施錠されたドア、および無人の車両の遠隔制御が可能であってもよい。

この機能の１つの被限定的用途は、使用前の車両の「事前準備」にある。たとえば、ユーザは、車室温度を上昇させるため或いは使用前にガラスの霜取りをするために加温シートまたはＨＶＡＣシステムを動作させたいと望むかもしれない。

まさしく、車両の機能を有効化または操作するためにＣＡＮバス２４上に送信されるかもしれない実質的にいかなる制御命令も、ウェブポータル１４によってＤＴＵ２２に送信されて、適切なＣＡＮメッセージに変換されてＣＡＮバス２４に送信され得る。換言すると、通常、ＣＡＮバス２４上のＣＡＮメッセージに応じて有効化され、制御され、操作される車両１２上の実質的にどのような機能、システム、サブシステム、または装置も、ウェブポータル１４からのＧＳＭネットワーク１３を介した制御メッセージの送信を通して、同様に、有効化され、制御されまたは操作され得る。

これは、重要にも、ＤＴＵ２２２２が制御メッセージを受信でき、それらを対応するプロトコル形式に変換でき、ＣＡＮメッセージを生成してＣＡＮバス２４上に送信できることにより達成され得る。

まさしく、いくつかの実施形態において、ユーザは、ウェブポータル１４または移動装置１８のＧＵＩを使用して、「エンジン始動」命令または指示を生成することもできる。選択または有効化されたとき、「エンジン始動」制御メッセージをＧＳＭネットワーク１３を介してウェブポータル１４に送信するグラフィカルスイッチ、スライダ、またはアイコンがＧＵＩ上に提供される。

ウェブポータル１４は、「エンジン始動」制御メッセージを車両１２にＧＳＭネットワーク１３を介して再送信し、ＤＴＵ２２のトランシーバユニット３０によって受信され、マイクロプロセッサ２６によりＮＶＲＡＭモジュール３４内のルックアップテーブルを使用して適切なＣＡＮメッセージに変換され、ＣＡＮバス２４上に送信され、エンジン制御ユニット（ＥＣＵ）に車両１２の内燃エンジンを始動させる。

出願人は、いくつかの分野において公道うえでの遠隔エンジン始動は不適法であることに気付いている。移動装置１８またはウェブポータル１４のＧＵＩは、それ故、「エンジン始動」制御メッセージを発する前に遠隔エンジン始動の確認または認証の要求が実行されてもよい。

代案または追加として、「エンジン始動」制御メッセージを発する前に、ウェブポータル１４は、ＤＴＵ２２のＧＰＳユニット３２に車両１２の現在の位置を測定するように問い合わせてもよい。車両１２のＧＰＳ座標は、トランシーバユニット３０によりＧＳＭネットワーク１３を介してウェブポータル１４に送信されウェブポータル１４を提供するウェブサーバに記憶された地図データと比較または重ね合わされる。ウェブポータル１４により車両１２が公道に位置すると判断されたなら、車両１２の遠隔始動が防止される。

商業利用可能なＧＰＳデータの限定された解像度に起因し、ＧＰＳユニット３２からの位置予測を有効するために他の車両データが使用されることが予想される。例えば、車両の向きまたは傾きが、車両１２が公道上にあるか、私道上または道路に隣接する駐車場に停車しているかを予測するのに使用されてもよい−公道に対して角度をつけて停車している車両はそれ自体が道路上に位置していそうにない。同様に、車両が非常に長時間停車していれば公道上に残されていそうにないので、エンジンを停止してから経過した時間が車両１２の位置を推測するのに使用され得る。

いくつかの実施形態において、車両エンジンが遠隔始動されたなら、車両は、「遠隔アイドリング」モードにすべきと考える。このモードにおいて、車両１２は、車両を運転することができず、車両を駐車モード以外にするいかなる試みもエンジンの停止を生じさせるように構成されてもよい。

いくつかの実施形態において、車両１２は、ユーザが車両に搭乗し、適当な認証（車両の始動のために必要なキーまたはキーフォブまたは他の必要な品など）を提示したなら、車両が遠隔アイドリングモードから脱し、非遠隔アイドリングモードになるように構成されている。そして、ユーザは、車両を有人および非遠隔で始動したなら、（例えば、車両を運転することで）車両を操作できる。

いくつかの実施形態において、車両１２の位置を判定するため、および、車両１２の現在の向きを知得するために、彼らの移動通信装置１８からウェブポータル１４および／または車両１２に直接に通信してもよい。

移動装置１８は、その現在の位置を装置１８自信の中に設けた位置判定手段により判定してもよい。

移動通信装置１８は、街路地図、街路図（グーグルアース（商標）によるなど）のようなＧＵＩ、または、方位計のような表示を含む他の適当なＧＵＩによって、ユーザの現在の位置からの向きを提供するようになっていてもよい。例えば、装置１８は、ユーザを車両に真っ直ぐに向わせるために、車両１２の方向を指す矢印を表示してもよい。

装置１８は、例えばブルートゥース（登録商標）または他の短距離無線または同様の通信手段によって、車両１２と直接交信するようになっていてもよいことが理解されるべきである。

いくつかの実施形態において、車両は、ＧＳＭネットワーク１３を介して遠隔で解錠されてもよい。解錠命令によってドアが解錠されたが、あらかじめ定めた時間内にドア（またはトランク／後部ゲート）が開放されなかった事象において、車両は自動的に再施錠するようになっていてもよい。

いくつかの実施形態において、システムは、窓が遠隔で開放または閉鎖されることを可能にする。いくつかの実施形態において、全ての窓をそれぞれ開放または閉鎖する包括開放または閉鎖命令が送信されてもよい。包括閉鎖機能は、窓の閉鎖中に窓にものを挟まないことを保証するために、窓上昇システムの作り付けの挟み込み防止機能を利用してもよい。

いくつかの実施形態において、車両１２の開閉屋根が遠隔で開放または閉鎖されてもよい。

いくつかの実施系形態において、車両１２のトランクまたは後部ゲートが遠隔で解放されてもよい。いくつかの実施形態において、車両内に自動トランクまたは後部ゲート閉鎖装置を有し、その装置も遠隔操作されて、トランクまたは後部ゲートを閉鎖してもよい。

いくつかの実施形態において、駐車係モード機能のような他の機能が遠隔で有効化または無効化されてもよい。駐車係モードは、車両のある部分または機能へのアクセスが防止または制限されるモードであってもよい。例えば、最高速および／または最高加速度のような車両性能パラメータが駐車係モードでは制限されてもよい。

いくつかの実施形態において、車両のサスペンションが、遠隔で上昇または下降されてもよい。いくつかの実施形態において、異なる状況における異なる要求に合わせるために車両の外部ライトの設定が代えられてもよい。

例えば、車両が外部ライト設定について異なる法的要求を有する場所の間を走行している事象において、外部ライトは、法適要求に合わせるために、遠隔で変更されてもよい。

よって、車両１２が車が道の異なる側を走行することが要求される国の間を走行するならば、ライトの設定（車両のヘッドランプの光線方向など）が遠隔で変更されてもよい。

いくつかの実施形態において、車両１２の環境制御システムまたはヒータ、換気、および、空調システム（ＨＶＡＣ）が制御されてもよい。例えば、環境制御システムを自動モードにするかどうかを制御してもよい。ブロワ速度、運転者温度選択、同乗者温度選択、および、いずれか／または他の好ましいパラメータが調節可能であってもよい。

いくつかの実施形態において、例えば、車両が大きな駐車場にあるならば、ユーザにより車両の位置を特定するための方法が提供される。よって、いくつかの実施形態において、ユーザは、車両の１以上のライトを点灯させるために、彼の移動通信装置１８を操作してもよい。他の構成も有用である。

いくつかの実施形態において、ユーザは、エンジン停止命令を送信し、それによって車両のエンジンを停止できてもよい。この命令は、遠隔エンジン停止命令と呼ばれるかもしれない。いくつかの実施形態において、エンジン停止命令は、エンジンが遠隔アイドリングモードでアイドリングしていれば、ＤＴＵ２２によって作動するだけであってもよい。換言すると、遠隔エンジン停止命令は、エンジンが遠隔で始動されて、それによりエンジンを遠隔アイドリングモードに移行し、エンジンが始動してから非遠隔アイドルモードには移行していないときだけ動作する。他の構成も有用である。

ＤＴＵ２２は、ある環境において、無線トランシーバユニット３０によって受信されて（対応するＣＡＮメッセージをＣＡＮバス２４上に送信することで）実行されている、ある他の命令を妨げるようになっていてもよい。例えば、ＤＴＵ２２は、もしも車両１２が移動していることが検出されたなら、ドア、トランク／後部ゲートまたはボンネットの遠隔解放を妨げてもよい。

エンジンの始動を許す機能は、エンジンが動作して遠隔操作されることが要求される車両１２の機能を遠隔で有効化する。例えば、窓の霜取り器、車室ヒータ、シータまたはハンドルヒータ、燃料電力ヒータのような加熱システム、または、空調システムのような冷却システムは、それぞれエンジンが動いている必要があるかもしれない。

いくつかの実施形態において、ユーザは、データの車両へのダウンロードを遠隔で開始させてもよい。例えば、ユーザは、目的地および／または経路のようなユーザが行おうと意図する旅程に対応するデータのようなナビゲーションデータ、または、音楽データまたは他の娯楽関連データのような他のデータのダウンロードを開始させてもよい。

車両１２が移動しているのにＤＴＵ２２がエンジンを切るべきとの命令を受信する事象（例えば車両１２が盗まれたことをユーザが気付いたなら）において、ＤＴＵ２２は、車両１２がエンジンを切る前に管理された停止をするように、車両１２を制御するようになっていてもよい。

＜車両位置＞
上述のように、1つの実施形態において、ユーザは、車両の位置の情報を要求できる。その要求は、状態要求に関連して上述のような方法で送信されてもよい。この場合、「車両位置」状態要求は、ユーザがインターネット接続されたコンピュータ１６または移動装置１８上でするそのような要求に応じて、ウェブポータル１４によって生成され、車両１２に送信される。

位置要求は、ＤＴＵ２２のトランシーバユニット３０によって受信され、マイクロプロセッサ２６に送信される。マイクロプロセッサ２６は、ＧＰＳ受信器３２からの現在の車両位置のＧＰＳ座標を要求し、トランシーバユニット３０に、これらの座標をＧＳＭネットワーク１３を介してウェブポータル１４に送信するよう指示する。

ウェブポータル１４によって受信されたＧＰＳ座標は、ウェブポータル１４によってインターネットから抽出したか、或いは、ウェブポータルのサーバに保持された地図データの上に重ね合わされる。車両の位置を重ねて示す地図データは、インターネット接続されたコンピュータ１６を使用してユーザが見ることができる。代案または追加として、車両位置が重ねられた地図データは、ウェブポータル１４によって、ＧＵＩに表示するために（例えば、図１４参照）ユーザの移動装置１８に送信される。

代案の方法において、ＧＰＳレシーバ３２によって判定された車両ＧＰＳ座標は、上述のような、エンジン停止時の車両情報の「バルクダンプ」の間にウェブポータル１４にアップロードされる。これは、位置情報がすでにウェブポータル１４に保有されてアクセス可能であり、それによって、システムの電力管理を改善するので、有利にも、車両１２に「車両位置」状態要求を送信する必要をなくす。

＜旅程監視＞
本発明の実施形態の関連する機能は、ユーザが車両の移動を、目視、追跡または監視できることである。車両のＧＰＳ座標を、上述の方法で、一定間隔でウェブポータル１４に送信することにより、車両１２がたどった経路が、ユーザが見る地図の上にプロットできる。

一方で、旅程の最後に、上述の車両情報の「バルクダンプ」の一部として旅程に関するデータがウェブポータル１４にアップロードされ得る。例えば、経路の始点および終点、距離、走行経路、走行時間、平均速度、最高到達速度、平均燃費および他の情報に関するデータが、ＤＴＵ２２による適当なＣＡＮメッセージ（状態要求）の生成とＣＡＮバス２４上への送信とにより、関連する車両システムおよびサブシステムから取得され得る。

図１５（ａ）〜１５（ｂ）は、車両１２のための走行データを表示する移動装置１８のＧＵＩのスクリーンショットを図示する。具体的には、図１５（ａ）は、日付、開始および終了時刻、時間、距離、燃費、車両走行距離、および、平均速度を含む、車両が行った前回の走行の走行データを示す。スクリーンショットは、地図上に車両１２がたどった経路も示す。図１５（ｂ）は、画面解像度の低い移動装置１８のＧＵＩのそれによってユーザが表示すべき走行データを選択できるメニュー画面を示すスクリーンショットを図示する。図１５（ｃ）は、前回の走行データを示し、地図上に旅程を図示する、画面解像度の低い移動装置１８のＧＵＩのスクリーンショットを図示する。

図１５（ｄ）は、過去の走行データを表示する移動装置１８のＧＵＩのスクリーンショットを図示する。図１５（ｅ）は、車両１２の過去の走行データの合計を示す移動装置１８のＧＵＩのスクリーンショットを図示する。

＜電力管理＞
出願人は、本発明の現実の実施において、電力管理が重要であるかもしれないことに気付いている。トランシーバユニット３０は、ウェブポータル１４によりＧＳＭネットワーク１３を介して送信される状態要求または制御メッセージを傾聴するために、動作状態のままにするのに大きな電力を必要とする。同様に、トランシーバユニット３０による事象メッセージの送信も、間欠的であっても、連続的なものよりも電力を必要とする。トランシーバユニット３０の作動は、ＤＴＵ２２に電力を供給するのに使用される車両バッテリに大きな電流消費をもたらす

この問題に対処するために、ＤＴＵ２２の制御のための多様な電力管理戦略が開発されている。１つの例では、ＤＴＵ２２は、エンジンが停止した後の最初のあらかじめ定めた時間だけ第１のモード、例えば、トランシーバユニット３０が連続受信モードで作動する完全に活動的なモードで作動する。このあらかじめ定めた時間は、時間単位、日単位または週単位であってもよく、ウェブポータル１４または移動装置１８のＧＵＩを使用してユーザが選択できてもよく、マイクロプロセッサ２６がバッテリの充電状態に応じて決定してもよい。

第１のあらかじめ定めた時間が経過すると、第２のあらかじめ定めた時間の間だけ、
トランシーバユニット３０は、間欠モードであるかもしれない第２のモードに切り替えられてもよい。この第２のモードにおいて、トランシーバユニット３０は、ＧＳＭネットワークを介してウェブポータルからの状態要求または制御メッセージを受信するために、
短時間だけあらかじめ定めた間隔で、例えば１時間に一度、起動されてもよい。

第３のモードにおいて、ＤＴＵ２２は、無効化または電源遮断されて、車両１２に送信された状態要求または制御メッセージがトランシーバユニット３０によって受信されない休止状態になる。一方、エンジンを停止した後、事象が発生したなら、自動的に、関連するマイクロコントローラによって、関連するＣＡＮメッセージを生成して、ＣＡＮバス２４上に送信し、ＴＤＴＵ２２のマイクロプロセッサ２６によってそれらが受信されることが開始され、或いは、事象メッセージをウェブポータル１４に送信するためのトランシーバユニット３０を起動する。

代案または追加として、第３のモードにおいて、車両システムの中の重要度の高い事象に関連する事象メッセージだけがユーザに告知されてもよい。例えば、車両警報システムの動作のような、早急な対応または調査が必要とされる事象は、ＤＴＵ２２によりウェブポータル１４に送信される。しかしながら、タイヤ圧力の減少のような、緊急でない事象は、トランシーバユニット３０によりウェブポータル１４に送信されない。

同じまたは他の実施形態において、ＤＴＵ２２の動作は、使用履歴に基づいて判断される。例えば、ＤＴＵ２２は、ユーザが通常、夜中のような特定の時間帯に車両１２に制御または状態要求を行わないと判断してもよい。この場合、ＤＴＵ２２は、夜中に電源が落とされてもよい。

１つの実施形態において、ユーザは、ＤＴＵ２２を手動で休止状態にすることができる。例えば、ユーザは、移動装置１８またはパーソナルコンピュータ１６上でウェブポータル１４にアップロードされる「休暇」フラグを設定してもよい。ユーザが休暇中であり制御または状態要求メッセージを車両１２に送らないであろうことを表示する休暇フラグが設定されたとき、ウェブポータル１４は、ＤＴＵ２２に対する電源遮断命令が生成されて休止状態にする。

ＤＴＵが作動している間、各モードは、ユーザにより設定されてもよく、車両バッテリの充電の状態に応じて自動的に定められてもよい。

ＤＴＵ２２のモードが変更されるときはいつも、トランシーバユニット３０によりＧＳＭネットワークを介してウェブポータル１４に事象メッセージが送信される。これは、例えば制御または状態要求メッセージが受信されないか、或いは、限定された事象メッセージだけが送信されるような、ＤＴＵ２２が機能の制限されるモードに移行する事象において有用である。このようにして、ユーザは、システムの機能の制限を知らされる。

＜カスタマイズ＞
出願人によって開発された試作システムは、ユーザによって全面的にカスタマイズできる。最初に車両１２に組み込まれたとき、ＤＴＵ２２は、それが取り付けられた車両の具体的特徴を認識するようになっている。これは、ＣＡＮバス２４上に送信されてもよい車両１２の設定ファイルにアクセスすることにより達成してもよい。型、形式および車体番号を含む詳細が、車両設定ファイルから取得され、ウェブポータル１４に送信され得る。

加えて、登録番号および色を含む車両の具体的データが、インターネット接続されたコンピュータを使用して直接、または、彼らの移動装置１８によってのいずれかにより、ユーザによりウェブポータル１４に入力されてもよい。

ユーザがウェブポータル１４または移動装置１８上のアプリケーションソフトウェアにアクセスしたとき、システムは、図３（ｂ）に示すように、システムの機能にアクセスを達成するためにユーザ名とパスワードを催促する。複数のユーザ名とパスワードが複数の車両のために採用されてもよい。

図３（ｄ）に示すような、位置、燃料状態、走行距離計読み、セキュリティ状態などの車両１２の絵および主要な車両情報を示す初期画面が表示されてもよい。

ＮＶＲＡＭモジュール３４は、複数の形式の車両のユーザのために、複数のルックアップテーブルを含んでもよい。上述のように、ＤＴＵ２２は、ＣＡＮバス２４上に送信されるかもしれない車両設定ファイルによって車両の型および形式を識別し、ＮＶＲＡＭモジュール３４中の選択すべき適切なルックアップテーブルを利用可能にして、システムをその車両の型および形式に適応させる。この構成は、有利にも、単一のシステムが異なる型式の車両に適用でき、開発および製造コストを低減することを意味する。

本発明は、有利にも、既存の標準的な車両追跡システムに実装されてもよく、ユーザの車両１２の事象情報および状態情報と、ユーザが車両１２の特定の機能を遠隔制御できることとの両方をユーザに提供する。この独創的なシステムのハードウェア要求の殆どは、既存の車両追跡システムのデータ転送ユニットにおいて満たされるとともに、ユニットを車両ＣＡＮバス２４とインターフェイス接続可能とするのに適応するソフトウェアの変更だけが必要である。

システムは、事象に基づくデータを車両ＣＡＮバス２４から直接読み込んで、それらの情報をホスト（ウェブポータル１４）に報告する。すると、ホストは、これらの事象をユーザに警告として、ＳＭＳメッセージ、Ｅメール、ＶｏＩＰにより、または、ユーザ固有のｉＰｈｏｎｅアプリケーションを通して連絡できる。

ユーザと車両１２との間のすべての通信は、ＧＳＭまたは他の移動体ネットワーク上で行われるので、実質的に世界中のどこからでも、従来の移動装置１８またはスマートフォン１８を使用して、車両１２を監視または制御できる。

事象選択−事象は、バッテリ寿命に応じて選択されてもよい。いくつかの事象が優先されてもよい。ユーザは、ＮＶＲＡＭに記憶した設定を介して、または、統合診断サービス（ＵＤＳ）を介して、それぞれの事象を有効化または無効化できる。

システムのホストコントローラとして外部から提供されるウェブポータルの使用により、複数の機能を有効化するために、他のインターネットデータ、或いは、地図情報、ＥメールまたはＳＭＳメッセージのサービスのような配信サービスにアクセスできる。これは、ユーザが彼の移動装置１８から車両１２へ直接通信するシステムでは不可能である。

車両１２のカメラまたはマイクシステムにより収集された動画または音声データがＤＴＵ２２によりウェブポータル１４に送信されてもよいことが予想される。これは、車両１２に戻る前にユーザが周囲をモニターできるようにすることで、個人のセキュリティを向上するかもしれない。

本発明は、車両１２のために遠隔で相互作用するシステムについて説明してきたが、本発明は、建造物のような遠隔で他の対象または所有物と相互作用するための用途を探してもよい。この場合、ＤＴＵ２２は、状態情報または事象情報を離れたユーザに送信するため、または、ＧＳＭネットワーク１３を介してユーザから制御命令を受信するために、建造物セキュリティシステムに組み込まれてもよい。

いくつかの実施形態において、本発明は、非対面取引処理を可能にしてもよい。例えば、本発明の実施形態は、燃料、駐車、高速代金のような商品、および、ファーストフードのような他の商品のためのなすべき支払いを可能にしてもよい。

いくつかの実施形態において、システムは、盗難車両１２の位置の特定に採用されてもよい。システムは、車両１２の位置をユーザ（または警察官のような他の認可された人）に報告するようになっていてもよいことを理解しなければならない。よって、位置が特定されて、回収活動が開始されてもよい。

本発明の同じ実施形態は、車両状態に関するデータがウェブポータル１４に報告されてもよいので、車両１２のＤＴＵ２２が故障したならば、ＤＴＵ２２が故障した時点またはその前の車両１２の位置が測定されてもよいことが理解されなければならない。よって、ユーザは、ウェブポータル１４のデータベースに記録されたデータを参照し、そこに記憶されている前回報告された車両１２の位置によって、この位置を特定してもよい。

いくつかの実施形態において、システムは、キーフォブの位置を特定するようになっていてもよい。

本発明のいくつかの実施形態において、ＤＴＵ２２は、ユーザがカスタマイズした、シート位置のような設定を含む車両１２の設定を特定し、これらの設定に対応するデータをウェブポータル１４のデータベースに記憶するようになっている。設定は、続いて、他の車両１２のＤＴＵ２２にダウンロードされてもよい。例えば、設定は、レンタカーのようにユーザが一時的に運転する車両１２にダウンロードされるかもしれない。

この機能は、ユーザが、他の車両を運転する前に、ユーザによりカスタマイズ可能な車両の設定を調節するために時間を浪費しないので、ユーザの他の車両の楽しみを増大させられる。

上記説明は、装置、システム、方法および車両の多数の実施形態、機能および用途の説明を提供する。しかしながら、それは、これらの実施形態、機能および用途は、明らかに機能が両立しない場合を除いて、いかなる所望の方法でも組み合わせられること、および、それぞれおよびそのような組み合わせは、本願の範囲内として予想され、権利範囲とされることが、当業者には完全に評価され、ここに明言される。

Claims (13)

1. 車両データバス（２４）上に送信された、車両システムまたは装置の状態と動作の少なくとも一方に関する一以上のデータ信号を受信するデータ転送手段（２２）と、
   受信した前記データ信号の少なくとも１つに関する情報を、ユーザに提示するために、ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステム（１４）を介して、移動通信装置（１８）に無線送信する通信手段（３０）を有し、
   前記通信手段は、第１のモードと第２のモードとを有し、
   前記第１のモードにおいて、前記通信手段は、前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステム（１４）から制御メッセージを連続的に受信するように動作可能であり、
   前記第２のモードにおいて、前記通信手段は、前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステム（１４）から前記制御メッセージを間欠的に受信するように動作可能であり、
   前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステムは、移動通信装置から休暇制御メッセージを受信するように構成されており、
   前記休暇制御メッセージは、ユーザが、自身の定義した時間、前記通信手段を前記第２のモードに設定することを望んでいることを示しており、
   前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステムは、前記通信手段に遮断制御メッセージを送信するように構成されており、
   前記遮断制御メッセージが前記通信手段によって受信されると、前記システムは、前記ユーザが定義した時間、前記通信手段を前記第２のモードに設定するように動作可能である、
   車両（１２）を監視および／または制御するためのシステム（１０）。
2. 前記転送手段（２２）は、１以上の車両システム、機能または装置を制御するために、前記車両データバス（２４）上に送信するための前記データ信号を生成するようになっている、請求項１に記載のシステム（１０）。
3. 前記データ転送手段（２２）は、前記データバス（２４）から前記データ信号を受信し、前記データ信号を、前記通信手段（３０）によって送信するために、当該データ信号に対応するデータメッセージに変換するようになっている、請求項１または２のいずれかに記載のシステム（１０）。
4. 前記データ転送手段（２２）は、前記通信手段（３０）によって送信する前に、前記データメッセージを暗号化するようになっている、請求項３に記載のシステム（１０）。
5. 前記車両バス（２４）は、ＣＡＮバスであり、前記データ転送手段（２２）は、前記車両システムまたは前記サブシステムによって前記ＣＡＮバス上に送信されたＣＡＮメッセージを受信し、前記メッセージをメモリ（３４）に記憶するようになっている、請求項１から４のいずれかに記載のシステム（１０）。
6. 前記通信手段（３０）による前記データメッセージの送信および前記制御メッセージの受信は、前記車両のエンジンが停止した後、車両バッテリの電圧があらかじめ定めた閾値に達すると停止される、請求項１から５のいずれかに記載のシステム（１０）。
7. 前記通信手段（３０）による前記データメッセージの送信および前記制御メッセージの受信は、前記車両のエンジンが停止した後、第１のあらかじめ定めた時間が経過すると停止される、請求項１から６のいずれかに記載のシステム（１０）。
8. 前記通信手段（３０）による前記データメッセージの送信および前記制御メッセージの受信は、前記第１のあらかじめ定めた時間が経過した後、第２のあらかじめ定めた時間だけ、間欠的に継続される、請求項７に記載のシステム（１０）。
9. 前記通信手段（３０）は、前記車両のエンジンが停止した後、いつでも、高い重要性を有するデータメッセージを即応して送信する、請求項６から８のいずれかに記載のシステム（１０）。
10. 前記通信手段（３０）は、ユーザによるその使用履歴に基づいて、間欠的に、前記データメッセージを送信し、前記制御メッセージを受信するように動作する、請求項１から９のいずれかに記載のシステム（１０）。
11. 前記通信手段が第２のモードの場合、優先度の高い車両内事象に関連するメッセージだけがユーザに通知される、請求項１から１０のいずれかに記載のシステム（１０）。
12. ａ）ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステムを介して、移動通信装置から車両（１２）の中に配置したトランシーバ（３０）に制御メッセージを遠隔送信し、前記制御メッセージを対応する制御データ信号に変換し、前記制御データ信号を前記車両（１２）の中に配置された車両データバス（２４）上に送信し、それにより、少なくとも１つの車両システム、車両機能または車両装置を制御するステップと、
    ｂ）前記車両（１２）の中に配置された車両データバス（２４）から１以上の前記車両システムまたは装置の状態または動作に関する状態信号を受信し、受信した前記データ信号をデータメッセージに変換し、前記車両（１２）の中に配置したトランシーバ（３０）から離れているユーザに前記状態メッセージを前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステムに無線送信するステップと、
    ｃ）ユーザが、自身の定義した時間、前記通信手段を第２のモードに設定することを望んでいることを示す休暇制御メッセージを、前記移動通信装置から前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステムに送信するステップと、
    ｄ）前記休暇制御メッセージを受信すると、前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステムから遮断制御メッセージを送信するステップと、
    ｅ）前記通信手段が前記遮断制御メッセージを受信すると、前記ユーザが定義した時間、前記通信手段が前記ウェブサーバ、ウェブポータル、またはその他のインターネット接続されたホストシステムから制御メッセージを間欠的に受信するように、前記通信手段を設定するステップ、の少なくとも１つのステップを実行する、車両（１２）と離れて相互作用する方法。
13. 請求項１〜１１のいずれかのシステムを含む車両。

Images