JP6833391B2

JP6833391B2 - 車載通信機器、および該車載通信機器にサービスを提供するサービス提供システム、ならびにプログラム

Info

Publication number: JP6833391B2
Application number: JP2016154577A
Authority: JP
Inventors: 正治明井
Original assignee: Toshiba Corp; Toshiba Digital Solutions Corp
Current assignee: Toshiba Corp; Toshiba Digital Solutions Corp
Priority date: 2016-08-05
Filing date: 2016-08-05
Publication date: 2021-02-24
Anticipated expiration: 2036-08-05
Also published as: JP2018020725A

Description

本発明の実施形態は、車載通信機器、および該車載通信機器にサービスを提供するサービス提供システム、ならびにプログラムに関する。

近年、車両には、機能に密接に関連付けられた各種通信機器が搭載されている。

例えば、ナビゲーションシステムやオーディオシステムに、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信機能等が直接搭載されている。

この種の公知技術としては、例えば、非特許文献１では、通信機能を自動車の１つの機能として、各個の装置ではなく、集約的な広域用車載通信機器としての位置付けで、移動体通信機能を搭載した装置の車両への搭載が進められている。

また、車両等の移動に伴い、周辺の通信環境、すなわち通信状態が変化していく中で、用途に適した通信回線を、複数の通信回路の中から切り替え利用するために、特許文献１には、アプリケーションソフトおよび通信回線に関する条件や情報から、アプリケーションソフトから利用する通信回線の選択制御に関する技術が開示されている。

一方、特許文献２には、複数の通信回線間において送受信内容を中継する場合に、信号のフォーマットを変換したり、または通信回線の品質状況に合わせて信号のフォーマットを制御する技術が開示されている。

さらに、特許文献３には、複数の無線通信の利用可能状態をチェックし、そのチェック結果と複数の無線通信の優先度テーブルとに従い、利用する無線通信を選択および切り替えのための技術が開示されている。

以上のように、車載通信環境は、他の機能や車載装置から切り離され、集約されつつあり、集約された中から、アプリケーションから見た最適な通信回線を選択する機能の提案や、無線通信の状態に合わせて利用する無線通信手段の切り替えの提案が行われている。

特許第３５２４５５９号明細書特許第４４１５０６８号明細書特開２０１１−１８８３９５号公報

後写鏡（間接視界）に関する基準（ＵＮ−Ｒ４６関係）、http://www.mlit.go.jp/common/001123618.pdf、国土交通省ホームページ（２０１６年７月２６日検索）

このように従来技術では、車両における通信環境の変化を、通信手段の制御として利用している。

しかしながら、車両の移動に伴うような通信環境の変化を、利用者のサービス享受のタイミングとして積極的に利用する手法は採用されていない。

本発明はこのような事情に鑑みてなされたものであり、車両の周辺の通信状態の変化を検知し、それに応じて利用者へサービスを提供することが可能なサービス提供システムおよびプログラム、ならびに該サービス提供システムを構成する車載通信機器を提供することを目的とする。

実施形態の車載通信機器は、車両に提供するサービスの内容を記述したサービス情報を、管理サーバから取得する命令取得処理手段と、命令取得処理手段によって取得されたサービス情報に含まれる第１の命令の実行時に、車両に搭載された複数の通信器の通信状態の変化の監視を指示する命令実行処理手段と、命令実行処理手段による指示に基づいて、通信状態の変化を監視し、変化が発生すると、命令実行処理手段へ、変化が発生した通信器の通信状態を送る通信監視制御処理手段とを備える。命令実行処理手段は、通信監視制御処理手段から送られた通信状態を受け取ると、変化が発生した場合に複数の通信器に対して行う処理内容を含む第２の命令に従って、通信監視制御処理手段に対して、変化が発生した通信器に対する処理を指示し、通信監視制御処理手段は、この指示に従って、変化が発生した通信器を制御し、制御された通信器から出力された通知によって、前記通信状態の変化に応じて、サービスが、アプリケーションサーバによって提供される。

本発明の実施形態の車載通信機器が適用される通信環境を説明するための概念図である。同実施形態の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。車載通信機器においてなされる処理の流れを示すフローチャートである。実施例１における処理の流れを示すフローチャートである。実施例１におけるサービス情報の記述例を示す図である。図５のサービス情報が変更されたサービス情報の記述例を示す図である。運転上要求される視界範囲を説明するための模式図である。可能な限り広い視界範囲を説明するための模式図である。実施例２における処理の流れを示すフローチャートである。実施例３の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。実施例３における処理の流れを示すフローチャートである。実施例３におけるサービス情報の記述例を示す図である。図１２のサービス情報に、新たなブロックが追加されたサービス情報の記述例を示す図である。燃料制御から燃料残量を取得し、保存するように指定された命令ブロックｂ４が記述されたサービス情報の記述例を示す図である。燃料残量をＧＳ側通信器へ送るように指定された命令ブロックが記述されたサービス情報の記述例を示す図である。実施例４の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。実施例４における処理の流れを示すフローチャートである。実施例４におけるサービス情報の記述例を示す図である。実施例５の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。実施例５における処理の流れを示すフローチャートである。実施例５におけるサービス情報の記述例を示す図である。実施例６の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。実施例６における処理の流れを示すフローチャートである。実施例６におけるサービス情報の記述例を示す図である。新たなブロックが追加されたサービス情報の記述例を示す図である。実施例７の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。実施例７における処理の流れを示すフローチャートである。実施例７におけるサービス情報の記述例を示す図である。実施例８の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。実施例８における処理の流れを示すフローチャートである。実施例８におけるサービス情報の記述例を示す図である。

本発明の実施形態の車載通信機器について、図面を用いて説明する。

図１は、同実施形態の車載通信機器が適用される通信環境を説明するための概念図である。

同実施形態の車載通信機器１０は、車両５０に搭載される。車載通信機器１０は、移動体通信網５２を用いて無線ネットワーク９０を介して管理サーバ１００と無線通信し、移動体通信網５２、ＷｉＭＡＸ５４、無線ＬＡＮ５６、路車間通信５８、車車間通信６０、およびＤＳＲＣ６２を用いて無線ネットワーク９０を介してアプリケーションサーバ１２０と無線通信する。また、Ｂｌｕｅｔｏｏｔｈ６４と携帯端末６８（＃１）、ＮＦＣ６６と携帯端末６８（＃１）、およびＵＳＢ６９と携帯端末６８（＃２）を用いて無線ネットワーク９０を介してアプリケーションサーバ１２０と無線通信する。車内通信７０は、車内機器７２との間で車内ＬＡＮによる有線通信を行う。このように、車両５０における代表的な通信環境は、無線通信、有線通信、および車内ＬＡＮを含む。

図２は、同実施形態の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。

車載通信機器１０は、命令取得処理部１２、命令データ記憶部１４、命令実行処理部１６、通信監視制御処理部１８、実行監視処理部２０、およびアプリケーション２２を備えている。

また、図２では、図１において移動体通信網５２、ＷｉＭＡＸ５４、無線ＬＡＮ５６、路車間通信５８、車車間通信６０、ＤＳＲＣ６２、携帯端末６８（＃１）、および携帯端末６８（＃２）を用いて示した様々な通信環境を、以降の説明のために代表的な５種類の通信器（通信器０〜４）として示し、それぞれが車載通信機器１０に接続された状態を示している。一例として、通信器０は、移動体通信網５２である。移動体通信網５２は、移動体通信業者により高いセキュリティ環境として提供されているので、管理サーバ１００との通信に適している。また、通信器１〜４は、ＷｉＭＡＸ５４、無線ＬＡＮ５６、路車間通信５８、車車間通信６０、ＤＳＲＣ６２、携帯端末６８（＃１）、および携帯端末６８（＃２）のうちの何れかに相当する。なお、移動体通信網５２と同等のセキュリティ環境を有するものであれば、移動体通信網５２以外のものを通信器０に適用しても良い。

なお、図２では、通信器０〜４は何れも車両５０内であって車載通信機器１０の外部に設置されるように図示されている。しかしながら、通信器０〜４は、このように車載通信機器１０の外部に配置されることに必ずしも限定されず、車載通信機器１０の内部に配置されていても良い。

図３は、車載通信機器１０においてなされる処理の流れを示すフローチャートである。

管理サーバ１００は、技術の進歩および時代の変化とともに、時々刻々と変化していくサービスおよび通信環境に合わせて、検知すべき通信状態の変化内容等に関する情報を管理しており、その変化内容に応じた適切な通知内容（例えば、サービス情報ａ）を、無線ネットワーク９０を介して車両５０へ送信する（Ｓ１）。

通信器０は、このサービス情報ａを受信し、車載通信機器１０へ向けて送信する。

車載通信機器１０では、通信器０から送られたサービス情報ａを、命令取得処理部１２にて受信し、命令データ記憶部１４へ送り、命令データ記憶部１４は、このサービス情報ａを記憶する（Ｓ２）。

サービス情報ａは、表１に示すように、ヘッダー部ａ１と、転送制御命令部ａ２と、データ部ａ３とを備える。ヘッダー部ａ１は、シリアル番号、作成日付、転送制御命令部開始位置、転送制御命令部長さ、データ部開始位置、データ部長さを含む。転送制御命令部ａ２は、表２に示すように、コマンドプロファイルｂ０と、命令ブロック１ｂ１、命令ブロックｂ２、・・・命令ブロックＮｂｎ（以降、これらを総称する場合には「命令ブロックｂ」とする）とを含む。コマンドプロファイルｂ０は、表３に示す処理の並列処理／順処理、繰り返し定義、定数定義を含む。命令ブロックｂは、１つの検知すべき通信状態の変化の定義と複数の通知内容および通知先を定義する。

データ部ａ３は、表４に示すようなｉｎ命令およびｏｕｔ命令で参照されるデータを含む。

命令取得処理部１２によるサービス情報ａの受信は、定期的に特定の時刻または時間間隔で実施してもよいし、車両５０の位置に連動して実施してもよい。また、サービス情報aは、１つであっても、複数であっても良い。

命令実行処理部１６は、命令データ記憶部１４に記憶されたサービス情報ａを読み出し、サービス情報ａの転送制御命令部ａ２の内容（表２参照）に従う処理を実行する（Ｓ３）。なお、命令データ記憶部１４に、サービス情報ａが複数保持されている場合は、各サービス情報aを並列的に処理してもよいし、逐次的に処理してもよい。

転送制御命令部ａ２は、表２に示すようなデータ構造を有し、コマンドプロファイルｂ０には、表２に示す命令ブロックｂに記載された命令実行を制御する内容が記述されており、表３にその一例を示す。各命令ブロックは、通信器１〜４の通信状態の変化またはデータ受信を検知するための１つのｉｎ命令と、通信状態境の変化が検知された場合に、各通信器１〜４に対して行う処理内容を示す複数のｏｕｔ命令とからなり、その一例は、表４に示す通りである。

表２に示される各命令ブロックｂでは、１つのｉｎ命令の条件が成立した場合に、後続するｏｕｔ命令が順次実施される。

命令実行処理部１６は、ｉｎ命令実行時に、通信監視制御処理部１８に対して、制御／送信データｃを送ることによって、監視対象となる通信器１〜４の通信状態の変化の監視を指示する（Ｓ４）。

通信監視制御処理部１８は、制御／送信データｃを受け取ると、指定される通信状態の変化を監視し、変化発生時に、命令実行処理部１６に対して、通信状態／受信データｄを送る（Ｓ５）。

命令実行処理部１６は、通信状態／受信データｄを受け取ると、当該命令ブロックのｉｎ命令に後続するｏｕｔ命令を逐次処理し、通信監視制御処理部１８に対して、制御／送信データｃを送ることによって、ｏｕｔ命令に記載された内容に従い、対象の通信器（通信器１〜４のうちの何れか）に対する処理を指示する（Ｓ６）。

通信監視制御処理部１８は、その指示に従い、対象となる通信器（例えば、通信器２）を制御する。

この制御に応じて、通信器（例えば、通信器２）は、アプリケーションサーバ１２０に対して通知ｆを送信する。アプリケーションサーバ１２０は、この通知ｆを受信し、通知ｆに応じて利用者または車両５０に対してサービス提供を行う（Ｓ７）。

なお、命令実行処理部１６は、サービス情報aの処理において異常状態が発生した場合は、実行監視処理部２０へ、異常状態ｅを通知する。実行監視処理部２０は、異常状態ｅを、通信器０を介して管理サーバ１００へ送る。管理サーバ１００は、異常状態ｅを、サービス情報の内容の修正のために用いる。

上述したように、同実施形態の車載通信機器１０は、指定された各通信器（通信器１〜４）の通信状態の変化を、通信監視制御処理部１８により監視し、通信状態の変化が検知されると、指定された各通信器（通信器１〜４）への処理を実行する。

これにより、１つの通信器（例えば、通信器２）における通信状態の変化を検知し、複数の通信器（通信器１〜４）の状態制御およびデータの送信を実施可能とする。

例えば、移動体通信網５２（通信器０）の切断を監視し、切断時に無線ＬＡＮ用通信器のアクセスポイントの検索を開始し、Ｂｌｕｅｔｏｏｔｈ通信器の検索開始および他の車載機器に対して移動体通信網５２（通信器０）の切断を通知するといった処理が可能となる。つまり、図２に例示されるように、通信器２を制御し、通信器２からアプリケーションサーバ１２０への通知によって、アプリケーションサーバ１２０は、通信状態の変化をきっかけとしたサービス提供、および通信状態の変化に応じたサービス提供を行うことが可能となる。

また、命令実行処理部１６における処理内容は、監視対象となる通信器（通信器１〜４）の指定および監視内容をサービス情報として外部より指定可能とし、移動体通信における基地局または無線ＬＡＮにおけるアクセスポイントの追加削減への対応、およびサービス提供業者の追加削減といった外部の通信環境の変化に、随時対応可能となる。

以下に、具体的な実施例について説明する。なお、以下の各実施例の説明に用いる符号は、前述した図および表と同一なものについては同一符号を付し、重複説明を避ける。

（実施例１）
実施例１は、センター（図示せず）からの遠隔制御方式が採用された自動運転車における車載通信機器１０の適用例である。なお、ここでは自動運転車のレベルについては、特に規定しない。

遠隔制御方式を考えた場合、通信による車両情報の送受は重要な機能であり、車両５０が移動している場合は、常にセンターと車両５０との間の通信が可能であることが必須となる。従って通信器１〜４のうちの１つが利用不可になってから、通信器１〜４のうちの別の通信器を探し、再接続するという状態は避けねばならない。

これに対して、通信状態は、固定の送受信局の新規増設／移動、周辺建築物の影響により、常に変化する。

このような環境下での遠隔制御方式を考えた場合、通信状態を確認しつつ、通信器１〜４の先行的な通信確立、切り替えを行い、途切れのない切り替えを実施するとともに、常に変化していく環境に合わせて動作する切り替え制御が必要となる。

このための制御を、図２に示すような構成を有する実施例１の車載通信機器１０によって実現する処理について説明する。

図４は、実施例１における処理の流れを示すフローチャートである。

まず、管理サーバ１００が、車載通信機器１０の通信器０（例えば、移動体通信網５２）へ、例えば、図５にその内容を示すようなサービス情報ａを送信する。通信器０は、このようなサービス情報ａを、車載通信機器１０の命令取得処理部１２へ送信する（Ｓ１０）。

管理サーバ１００から通信器０へのサービス情報aの送信は、定められた期間による複数のサービス情報aの一括配信、車両位置に合わせた切り替え、管理サーバ１００における車両位置の監視に基づく配信等によって行う。

命令取得処理部１２は、通信器０からサービス情報ａを受信し、命令データ記憶部１４に送る。命令データ記憶部１４は、このサービス情報ａを記憶するとともに、命令実行処理部１６へ送る（Ｓ１１）。

命令実行処理部１６は、命令データ記憶部１４に記憶されたサービス情報ａを読み出し、サービス情報ａの転送制御命令部ａ２の内容（表２参照）に従う通信環境確認処理を実行する（Ｓ１２）。本実施例では、具体的に、図５の第３行目に示されている転送制御命令部ａ２中の＠ｌｏｏｐ命令により、２０００ｍｓ周期で、転送制御命令部ａ２の４個のブロックｂ１〜ｂ４の処理（すなわち、Ｓ１３〜Ｓ１４の処理、Ｓ１５〜Ｓ１６の処理、Ｓ１７〜Ｓ１８の処理、Ｓ１９〜Ｓ２０の処理）を繰り返し実施する。これら４個のブロックｂ１〜ｂ４の処理は、図５の第２行目に示されている転送制御命令部ａ２中の＠ｐａｒａｌｌｅｌ命令により、並列的に実施される。

ブロックｂ１の処理では、通信器０が特定の通信業者（ｍｎｃ＝ＡＡ）の通信局と通信可能であり、利用可能な状態（ｄｔｙｐｅ＝ｅｎａｂｌｅ）であって、２０００ｍｓ以上の時間に連続して受信電力が−９５ｄＢｍ以上あったか否かを確認する（Ｓ１３）。条件が満足された場合（Ｓ１３：通信器０は通信可能）には、ブロックｂ１のｏｕｔ命令を実行する（Ｓ１４）。

ｏｕｔ命令では、指定されるデータ部ａ３の先頭から５Ｂｙｔｅ（ｃｏｍ０１）を、通信器０を使用して、アプリケーションサーバ１２０（ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｓｅｒｖｉｃｅＡ）へ通知する。通知内容に、通信器０からの受信電力および基地局の情報を含めてもよい。応答が２０００ｍｓ以内に受信できなかった場合は、タイムアウトとして、再度ｉｎ命令を実行する。

各ブロックｂ２〜ｂ４についても、通信器１〜３を対象として、同様な処理を行う（Ｓ１５〜Ｓ１６、Ｓ１７〜Ｓ１８、Ｓ１９〜Ｓ２０）。

アプリケーションサーバ１２０は、ステップＳ１４、１６、１８、２０の結果に基づいて、有効な通信回線を判定し、その中からさらに最適と思われる通信回線を選択し、当該通信器を経由して、車載通信機器１０上のアプリケーション２２へ、通信経路の切り替えの指示ｇを送る（Ｓ２１）。例えば、通信器０による通信よりもより通信コストの低い通信器１による通信への切り替えを行う。その後、アプリケーション２２とアプリケーションサーバ１２０は、通信経路を切り替えて通信を継続し、サービスの提供を途切れなく実施する（Ｓ２２）。

サービス情報の更新の具体例について以下に説明する。

例えば、無線ＬＡＮのアクセスポイント「ｗｉｆｉａｐ００２」が新たに新設されたとする。また当該地区の建築物による反射等により、より遠方の基地局が、受信電力が低いにも関わらず有効範囲内となり、通信器２に基地局間の切り替えが頻発する状況が発生したとする。基地局間の切り替えが頻発すると、通信器２を用いた通信の通信速度に悪影響を与えるため、アプリケーションサーバ１２０は、通信器２の使用を停止するように判定したとする。

このような状況に対応するため、実施例１では、管理サーバ１００が、車載通信機器１０へ送信するサービス情報aを、図６に示す内容に変更し、車載通信機器１０へ送信する。

図５では、ブロックｂ３において、通信器２を用いた通信業者がｍｎｃ＝ＸＸとなる通信の監視が定義されているが、図６では、変更されたブロックｂ３’において、通信器１を用いたアクセスポイントとして「ｗｉｆｉａｐ００２」の通信の監視が定義されている。

これによって、通信器１によるアクセスポイント「ｗｉｆｉａｐ００２」の検知が可能となる。

上記のように、実施例１では、管理サーバ１００側においてサービス情報ａの内容（スクリプト）を変更することにより、随時変化する通信状態に柔軟に適応可能なシステム構築が容易となる。

（実施例２）
実施例２は、遠隔制御方式の自動運転において、車両の周辺映像をセンター（図示せず）へ送信する際における車載通信機器１０の適用例である。

具体的には、通常の運転では、例えば図７に示すような、運転上要求される視界範囲α、βに関する周辺映像（非特許文献１参照）を送信し、通信回線容量等の制約条件下で、可能な限りその他の、例えば図８の斜線部分γをも含めた周辺映像を送信することを想定する。

一般に、利用可能な通信環境は、固定の送受信局の新規増設／移動、周辺建築物の影響により、常に変化する。また、各種契約行為等により、使用可能な送受信局が随時、追加／削除される。

このような通信環境の変化に伴う通信状態の変化に合わせて、周辺映像の送受信に用いる通信回線は、通信状態を確認しつつ、追加利用または切り替えを行う必要があり、また、通信状態の確認内容も、通信環境の変化に合わせて更新していく必要がなる。

このための制御を、図２に示すような構成を有する実施例２の車載通信機器１０によって実現する処理について説明する。

図９は、実施例２における処理の流れを示すフローチャートである。

図９のフローチャートに示すステップＳ１０〜Ｓ２０は、図４のフローチャートにおけるステップＳ１０〜Ｓ２０と同様である。

アプリケーションサーバ１２０は、ステップＳ１４、１６、１８、２０の結果に基づいて、有効な通信回線を判定し、１つまたは複数の通信器の情報ｈを、当該通信器経由で、車載通信機器１０上のアプリケーション２２へ通知する（Ｓ３１）。アプリケーション２２は、この情報ｈに従い、通信器の切り替え、または、複数回線を用いて、周辺映像を、アプリケーションサーバ１２０へ送信する（Ｓ３２）。

例えば、図８の斜線部分γの周辺映像を、新たに有効と判断された通信器により送信する。ここで、新たに無線ＬＡＮのアクセスポイント「ｗｉｆｉａｐ００２」が新設されたとする。また当該地区の建築物による反射等により、より遠方の基地局が、受信電力が低いにも関わらず有効範囲内となり、通信器２に基地局間の切り替えが頻発する状況が発生したとする。基地局間の切り替えが頻発すると、通信器２を用いた通信の通信速度に影響を与えるため、アプリケーションサーバ１２０は、通信器２の使用の停止するように判定したとする。

このような状況に対応するため、実施例２では、管理サーバ１００が、車載通信機器１０へ送信するサービス情報aを、図５に示すブロックｂ３の内容から、図６に示すブロックｂ３’の内容に変更し、車載通信機器１０へ送信する。

これによって、実施例２では、遠隔制御方式の自動運転車において、最適な通信環境を選択可能とする情報の収集が容易となり、アプリケーションサーバ１２０側で通信環境に合わせた映像配信制御を行うことが可能となる。

（実施例３）
実施例３は、ガソリンスタンドにおける車種に応じた給油機への誘導における車載通信機器１０の適用例である。

図１０は、実施例３の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。

図１１は、実施例３における処理の流れを示すフローチャートである。

図１２は、実施例３において管理サーバ１００から通信器０へ送信されるサービス情報ａの一例を示す。

図１０に示す車載通信機器１０は、図２に示す車載通信機器１０からアプリケーション２２を削除し、表示処理部２４と表示器２６とを加えた構成としている。また、図１０に示すアプリケーションサーバ１２０は、ガソリンスタンド（ＧＳ）側通信器１３２と、誘導装置１３４との間に、ＧＳシステム１３０の一部として組み込まれている。

ＧＳ側通信器１３２は、無線ＬＡＮにより車両５０と通信するための装置であり、図１２のブロックｂ２に示されているように、例えば「ｗｉｆｉａｐ００１」のような名前が付けられており、その無線有効範囲が、侵入してきた車両５０に対してのみ有効となるように設定されている。

誘導装置１３４は、車両５０をＧＳの給油機（図示せず）へ誘導するための装置である。

次に、実施例３における処理の流れについて説明する。

図１１のフローチャートに示すステップＳ１０〜Ｓ１３は、図４のフローチャートにおけるステップＳ１０〜Ｓ１３と同様である。ただし、ステップＳ１０において、管理サーバ１００が、車載通信機器１０の通信器０（例えば、移動体通信網５２）へ送信するサービス情報ａの例は、図１２に示す通りである。

車載通信機器１０の命令実行処理部１６は、図１２の内容を処理し、ｉｎ命令により、ＧＳ側通信器１３２「ｗｉｆｉａｐ００１」からの無線ＬＡＮの通信を、通信器（例えば、通信器１）および通信監視制御処理部１８によって監視する。そして、車両５０が、ＧＳに侵入し、ＧＳ側通信器１３２の有効範囲内に入った時点で、通信監視制御処理部１８は、ｏｕｔ命令により、通信器（例えば、通信器１）を介してＧＳ側通信器１３２との通信を確立し、通信器（例えば、通信器１）を介してＧＳ側通信器１３２へ車両情報ｉを送信する。ＧＳ側通信器１３２は、車両情報ｉを受信すると、車両情報ｉをアプリケーションサーバ１２０へ送る（Ｓ４１）。

車両情報ｉは、例えば図１２の最終行に記載されているように、車両メーカ（Ｍａｋｅｒ）としての「ＴＴＳＳＳＢＢＢ」、車種（Ｔｙｐｅ）として「Ｘ０００００１」といった情報を含む。なお、車両情報ｉの書式および内容については本実施例では限定せず、その他の必要な情報を、適宜、適切な書式で追加するようにして良い。

アプリケーションサーバ１２０は、ＧＳ側通信器１３２から送られた車両情報ｉに基づいて給油種別を判断し、誘導装置１３４へ、車両を誘導するための誘導指示ｊを送る（Ｓ４２）。

誘導装置１３４は、誘導指示ｊを受け取ると、例えば図示しない給油機上の青色回転灯を点灯させ、当該車両５０を誘導する（Ｓ４３）。

あるいは、それに加えて、または、その代わりに、車載通信機器１０の表示器２６から、青色回転灯の給油機への移動指示ｋを表示するようにしても良い。この場合、アプリケーションサーバ１２０は、誘導指示ｊを、ＧＳ側通信器１３２にも送り、ＧＳ側通信器１３２は、誘導指示ｊに基づいて移動指示ｋを生成し、車両５０に向けて送信する。車両５０では、ＧＳ側通信器１３２から送信された移動指示ｋを通信器１が受信し、通信監視制御処理部１８へ送る。そして、通信監視制御処理部１８は、移動指示ｋを表示処理部２４へ送る。表示処理部２４は、この移動指示ｋを表示器２６へ送り、表示器２６が、移動指示ｋを表示する。

これによって、車両５０は、適切な給油機へ誘導されるようになる。

次に、新たなＧＳがサービスで利用可能となった場合のデータ処理について説明する。例えば、新たなＧＳ側通信器「ｗｉｆｉａｐ００２」が新設されたとする。この状況に対応するため、本発明の方式では管理サーバ１００から車載通信機器１０へ送信するサービス情報ａを、図１３示す内容に変更し、管理サーバ１００から車載通信機器１０へ送信すればよい。すなわち、図１２にはブロックｂ２の内容が定義されているが、図１３にはブロックｂ２に加えて、新設されたＧＳ側通信器に関するブロックｂ３’の内容（スクリプト）が追加されている。

なお、ＧＳ側通信器１３２はＧＳとの立地条件から、有効範囲限定に適した無線装置が選択されればよく、Ｂｌｕｅｔｏｏｔｈ等を用いてもよい。また、車載通信機器１０とＧＳシステム１３０との通信は、図１２、図１３に示すｏｕｔ命令において指定することで、通信器０の移動体通信網５２経由で行ってもよい。

このようなＧＳシステム１３０および給油機を、ＥＶ車向けの充電ステーションおよび充電器に置き換えた場合であっても、本実施例は、適用可能である。

ＧＳシステム１３０および給油機を、ＥＶ車向けの充電ステーションおよび充電器に置き換えた場合は、管理サーバ１００は、図１２または図１３の代わりに、図１４および図１５のようなサービス情報ａを、車載通信機器１０に送信するようにすれば良い。

図１４は、サービス情報ａの一例であり、燃料制御ＥＣＵから燃料残量を取得し、保存するように指定された命令ブロックｂ４が記述されている。

図１５もまた、サービス情報ａの一例であり、燃料残量を、通信器１を介してＧＳ側通信器１３２「ｗｉｆｉａｐ００２」へ送るように指定された命令ブロックｂ２’が記述されている。命令ブロックｂ２’は、図１２に示される命令ブロックｂ２に、燃料残量を、通信器１を介してＧＳ側通信器１３２「ｗｉｆｉａｐ００２」へ送るように指定した部分を加えたものである。

図１４および図１５のようなサービス情報ａの内容に従う通信環境確認処理を、命令実行処理部１６が実行することによって、命令実行処理部１６は、燃料制御ＥＣＵから、燃料残量を取得し、燃料残量を車両情報ｉに含めるように通信監視制御処理部１８に対して指示することができる。そして、このような燃料残量が含まれた車両情報ｉもまた、通信監視制御処理部１８から通信器（例えば、通信器１）を介してＧＳシステム１３０へ通知することができる。

ＧＳシステム１３０側では、車両情報iに含まれる燃料残量に基づいて、車両５０を誘導するための適切な充電器を選定することができる。例えば、ＥＶ車向けの充電器の場合、充電時間を短くし、利用者の利便を図るために、残量が少ない車両は、優先的に急速充電器に割り当てられる。

上記のように、実施例３では、車両５０を、車種情報ｉに含まれる車両メーカや車種に応じて、適切な給油機へ誘導することが可能となる。

また、ＧＳ側の通信環境が変化し通信状態が変化した場合であっても、その変化に合わせてサービス情報aを適宜修正することで、サービス提供が可能となるように、車両通信機器１０を容易に適応させることが可能となる。

さらには、ＧＳシステム１３０および給油機を、ＥＶ車向けの充電ステーションおよび充電器に置き換えた場合であっても、車両情報ｉに燃料残量を含めることによって、車両５０を、適切な充電器へ誘導することが可能となる。

（実施例４）
実施例４は、駐車場における出庫時の精算処理における車載通信機器１０の適用例である。

図１６は、実施例４の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。

図１６に示す車載通信機器１０は、図１０に示す車載通信機器１０と同様の構成をしているが、通信器３はさらに、スマートフォン等の携帯端末４０とも通信可能である。携帯端末４０は、例えばＢｌｕｅｔｏｏｔｈやＮＦＣ等を用いた通信器３を介して車載通信機器１０と通信する一方、アプリケーションサーバ１２０とも通信する。

アプリケーションサーバ１２０は、料金精算器１４２とともに、駐車場システム１４０内に位置しており、携帯端末４０および料金精算器１４２と通信可能である。料金精算器１４２は、例えばＢｌｕｅｔｏｏｔｈや可視光通信等の無線有効範囲が、料金精算器１４２に接近した車両５０に対してのみ有効となるような近距離無線のための機能を備え、通信器１と通信可能である。

次に、実施例４における処理の流れについて説明する。

図１７は、実施例４における処理の流れを示すフローチャートである。

図１７のフローチャートに示すステップＳ１０〜Ｓ１１は、図４のフローチャートにおけるステップＳ１０〜Ｓ１１と同様であるが、図１７のステップＳ１０において管理サーバ１００から送信されるサービス情報ａは、例えば図１８に示す通りである。

次に、利用者は、駐車場からの車両５０の出庫前に、携帯端末４０のアプリケーション４２を用いて、駐車場の料金精算処理を行い（Ｓ５１）、アプリケーションサーバ１２０からチケット情報ｍを受信する。利用者はさらに、携帯端末４０から、例えばＮＦＣを用いた通信器３へチケット情報ｍを送信する。通信器３は、チケット情報ｍを受信すると、通信監視制御処理部１８へ送る（Ｓ５２）。

通信監視制御処理部１８へ送られたチケット情報ｍを、表示処理部２４が表示器２６から表示させることもできる。

なお、チケット情報ｍは、このようにアプリケーションサーバ１２０から受信するものに限定されず、例えば、携帯端末４０のアプリケーション４２を用いて、予め店舗等において購入することによって取得するようにしても良い。

続いて、車載通信機器１０の命令実行処理部１６は、図１８に示すようなサービス情報ａを処理し、ｉｎ命令により、携帯端末４０との通信３経由での通信を監視し（Ｓ５３）、通信器３と携帯端末４０との通信を確立する（Ｓ５４）。

通信器３と携帯端末４０との通信が確立すると、通信監視制御処理部１８は、携帯端末４０かチケット情報を受信し、保存する（Ｓ５５）。続いて、通信監視制御処理部１８は、ｏｕｔ命令によりチケット情報ｍを通信器１に送り、通信器１がチケット情報ｍを料金精算器１４２へ送信する（Ｓ５６）。

料金精算器１４２は、通信器１から送信されたチケット情報ｍを受信し、受信したチケット情報ｍの有効性を確認する（Ｓ５７）。そして、料金精算器１４２は、チケット情報ｍが有効であると判定すると、当該車両５０が通過できるようにゲートを開く操作を行う（Ｓ５８）。

なお、チケット情報ｍは、必要な情報を含み、適切な書式で記述されていれば、具体的な書式や内容については本発明では限定されず、車種情報i等の駐車場の運営に利用可能な情報を適宜含めてもよい。

上記のように、実施例４によれば、車両５０が駐車場の料金精算器１４２を通過する際の手間を削減できると共に、携帯端末４０に備わるＮＦＣのような近距離無線を用いた決済システムを容易に構成することができるようになる。

また、実施例４を応用することによって、店舗に併設される駐車場等では、携帯端末４０を用いることで、店舗内での購入に伴う駐車場料金サービスを用いた事前決済の手法も、容易に構築可能となる。

（実施例５）
実施例５は、レンタカーサービスまたはシェアードカーサービスで、提携駐車場の、駐車料金の無料または減額サービスを行う場合における車載通信機器１０の適用例である。

図１９は、実施例５の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。

図１９に示す車載通信機器１０は、図１６に示す車載通信機器１０と同様の構成をしている。ただし、図１６に示される携帯端末４０は、図１９には存在しない。また、駐車場システム１４１内に設けられたアプリケーションサーバ１２０が、料金精算器１４２と管理サーバ１００との両方と通信可能である。また、駐車場システム１４１に備えられた料金精算器１４２は、例えばＢｌｕｅｔｏｏｔｈや可視光通信等の近距離無線のための機能を備えている。そして、この近距離無線は、その無線有効範囲が、料金精算器１４２に接近した車両５０に対してのみ有効となる。

次に、実施例５における処理の流れについて説明する。

図２０は、実施例５における処理の流れを示すフローチャートである。

図２０のフローチャートに示すステップＳ１０〜Ｓ１１は、図１７のフローチャートにおけるステップＳ１０〜Ｓ１１と同様であるが、図２０のステップＳ１０において管理サーバ１００から送信されるサービス情報ａは、例えば図２１に示す通りであり、チケット情報ｍが含まれている。そして、図１７のフローチャートとは異なり、ステップＳ１０の前にステップＳ６０が実施され、ステップＳ１１の後にステップＳ６３〜Ｓ６７が実施される。

ステップＳ６０では、管理サーバ１００は、アプリケーションサーバ１２０から送信された、図２１に示すようなチケット情報ｍを含むサービス情報ａを受信する（Ｓ６０）。

そして、ステップＳ１０では、管理サーバ１００が、このサービス情報ａを、例えば移動体通信網のような通信器０へ送信する。通信器０は、このサービス情報aを、車載通信機器１０へ送る。このような管理サーバ１００によるサービス情報aの送信は、期間を決めて複数を一括配信し、車載通信機器１０で車両位置に合わせて切り替えて使用してもよいし、車両位置情報を管理サーバ１００で監視し、車両位置に合わせて実施するようにしてもよい。

ステップＳ１１の後、車載通信機器１０の命令実行処理部１６は、図２１に示すようなサービス情報ａを処理し、ｉｎ命令により、料金精算器１４２からの通信を監視し（Ｓ６３）、車両５０が、料金精算器１４２の通信有効範囲に入った時点で、ｏｕｔ命令により、通信器１と料金精算器１４２との通信を確立する（Ｓ６４）。

通信器１と料金精算器１４２との通信が確立されると、命令実行処理部１６は、サービス情報aに含まれるチケット情報ｍ「Ｓｅｒｖｉｃｅ＝Ｔｉｃｋｅｔ：７２９６７６ｂ６ａ８８９０ｅ４５８２ｄ５ｄｅ７ｄ０６０７ｂ８１ａ」を通信器１へ送り、通信器１は、チケット情報ｍを料金精算器１４２へ送信する（Ｓ６５）。

その後、料金精算器１４２は、受信したチケット情報ｍを、アプリケーションサーバ１２０へ送信し、アプリケーションサーバ１２０は、このチケット情報ｍが、ステップＳ１０において送信したサービス情報ａに含まれるチケット情報ｍと同一であることを確認することによって、有効性を確認する（Ｓ６６）。

そして、料金精算器１４２は、アプリケーションサーバ１２０から、有効との結果ｒが返されると、当該車両５０が通過できるようにゲートを開く操作を行う（Ｓ６７）。

なお、チケット情報ｍは、必要な情報を含み、適切な書式であれば、具体的な書式や内容については本発明では限定されず、車種情報ｉ等の駐車場の運営に利用可能な情報を、適宜含めてもよい。

上記のように、実施例５によれば、車両５０が駐車場の料金精算器１４２を通過する際の手間を削減できる。また、サービス情報aの車両５０への送信を、任意のタイミングで実施することが可能となるため、有効期限を短く設定し、更新していくことで、不正利用を未然に防止することも可能となる。

（実施例６）
実施例６は、レンタカーサービスまたはシェアードカーサービス提供システムにおける車載通信機器１０の適用例である。

図２２は、実施例６の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。

図２２に示す車載通信機器１０は、図１６に示す車載通信機器１０と同様の構成をしている。ただし、図２２では、車両５０内に、通信器１〜３と並列して通信器４を備えている。通信器４は、車両５０のエンジンの始動および停止を制御するための車両制御器１５０と通信可能となっている。これによって、車載通信機器１０は、通信器４を介して車両制御器１５０に命令を送ることによって、車両５０のエンジンの始動および停止を制御する。なお、通信器４と車両制御器１５０との通信手段は、無線通信に限定されず、例えば車両５０に予め備えられているＯＤＢ（Ｏｎ−ｂｏａｒｄｄｉａｇｎｏｓｔｉｃｓ）コネクタを経由した有線通信であってもよい。

また、図２２では、図１６における駐車場システム１４０および料金精算器１４２は存在せず、アプリケーションサーバ１２０が管理サーバ１００と携帯端末４０との両方と通信可能となっている。

例えばスマートフォンである携帯端末４０は、サービス利用ためのアプリケーション４３がインストールされている。そして、携帯端末４０は、アプリケーションサーバ１２０に対して、携帯端末４０を識別するための携帯端末情報ｎを送信する。

アプリケーションサーバ１２０は、携帯端末４０から送信された携帯端末情報ｎを受信すると、チケット情報ｍを生成する。そして、チケット情報ｍを携帯端末４０へ返信するとともに、管理サーバ１００に対しては、チケット情報ｍを、携帯端末４０から受信した携帯端末情報ｎとともに送信する。

次に、実施例６における処理の流れについて説明する。

図２３は、実施例６における処理の流れを示すフローチャートである。

まず、サービス利用に先立ち、利用者が自身の携帯端末４０を操作し、アプリケーションサーバ１２０に車両５０の予約操作と同時に利用登録を行う（Ｓ７０）。利用登録操作においては、利用者が、携帯端末４０上の専用のアプリケーション４３を操作し、通信器３との通信確立のための携帯端末情報ｎ、例えばＢｌｕｅｔｏｏｔｈの名前／ハードウェアアドレスを、アプリケーションサーバ１２０に送信する。

アプリケーションサーバ１２０は、携帯端末４０に対してチケット情報ｍ「Ｔｉｃｋｅｔ：７２９６７６ｂ６ａ８８９０ｅ４５８２ｄ５ｄｅ７ｄ０６０７ｂ８１ａ」を送信する。また、携帯端末４０からの携帯端末情報ｎとチケット情報を、管理サーバ１００へ送信する（Ｓ７１）。

携帯端末４０は、アプリケーションサーバ１２０から送信されたチケット情報ｍを受信し、記憶する（Ｓ９０）。

管理サーバ１００は、アプリケーションサーバ１２０から送信された携帯端末情報ｎおよびチケット情報ｍを用いて、図２４に示すようなサービス情報aを生成する（Ｓ７２）。

続いて、管理サーバ１００は、図２４に示すようなサービス情報ａを、例えば移動体通信網５２を用いた通信器０へ送信する。通信器０は、このサービス情報ａを受信し、車載通信機器１０へ送る（Ｓ７３）。管理サーバ１００からのサービス情報aの送信は、例えば、期間を決めた複数の一括配信、管理サーバ１００における車両位置情報の監視に基づく車両位置に合わせた配信等によって行う。

車載通信機器１０は、命令取得処理部１２が、通信器０からサービス情報ａを受信し、命令データ記憶部１４が、サービス情報aを記憶する（Ｓ７４）。

さらに、命令実行処理部１６が、図２４のサービス情報aを処理し、１つ目のブロックｂ１１内のｉｎ命令により、携帯端末４０からの通信器３による通信を監視する（Ｓ７５）。利用者が携帯端末４０を車両５０内に持ち込むことにより、通信器３による通信が検知され（Ｓ７６）、車載通信機器１０は通信器３により、例えばＢｌｕｅｔｏｏｔｈＬＥのＡｄｖｅｒｔｉｓｅ情報「ｈｔｔｐ：／／ａｐｐｌｉｃａｔｉｏｎ０１．ａｄｃｄｅｆ.ｃｏ．ｊｐ／」を送信し、携帯端末４０のアプリケーション４３を起動する（Ｓ７７）。この起動操作は、利用者による操作によって行われてもよい。

すると、アプリケーション４３は、通信器３による車載通信機器１０との通信を確立し、保持しているチケット情報ｍ「Ｔｉｃｋｅｔ：７２９６７６ｂ６ａ８８９０ｅ４５８２ｄ５ｄｅ７ｄ０６０７ｂ８１ａ」を、通信器３を介して車載通信機器１０へ送信し、通信監視制御処理部１８が受信する。

次に、命令実行処理部１６は、図２４の、２つ目のブロックｂ１２内のｉｎ命令により、携帯端末４０からの通信器３経由の受信内容が、サービス情報ａに含まれるチケット情報ｍ「Ｔｉｃｋｅｔ：７２９６７６ｂ６ａ８８９０ｅ４５８２ｄ５ｄｅ７ｄ０６０７ｂ８１ａ」に一致した場合（Ｓ７８）に、通信器４を経由して車両制御器１５０に対してエンジンを始動するように指示する（Ｓ７９）。

一方、一定時間（例えば、図２４の例では３秒）が経過しても、一致するチケット情報ｍが受信されない場合は、例えば０．５秒待って、サービス情報aの１つ目のブロックｂ１１の処理から再開する。そして、この再開を、例えば６回繰り返しても、図２４のサービス情報ａの３つのブロックｂ１１、ｂ１２、ｂ１３の処理が終了しない場合は、命令実行処理部１６は、異常通知ｅを生成し、実行監視処理部２０に送る。実行監視処理部２０は、異常通知ｅを、通信器０を介して管理サーバ１００へ送る。

ステップＳ７９において、エンジンを始動する指示が車両制御器１５０に送られると、車両５０側においてエンジンの始動操作を行うことが可能な状態となる（Ｓ８０）。これに応じて利用者がエンジン始動操作を行い、エンジンを始動させ、車両５０を走行させることにより、利用者はサービスを受けるようになる（Ｓ８１）。

その後、車載通信機器１０は、図２４に示す３つ目のブロック１３内のｉｎ命令により、通信器３による携帯端末４０との通信の切断を監視する（Ｓ８２）。これは、車両５０を停止するなどし、利用者が車外に携帯端末４０を持ち去るなどし、通信器３による携帯端末４０との通信が切断された場合に、車両制御器１５０に対して指示を送り、エンジン始動操作を不可状態とする（Ｓ８３）ことで、利用登録された携帯端末４０の保持者以外の当該車両５０の利用を防止する（Ｓ８４）。

さらに、利用者が携帯端末４０を車内５０に持ち込み、車載通信機器１０が通信器３を経由した携帯端末４０の検出、および携帯端末４０との通信途絶の検知の結果を、アプリケーションサーバ１２０へ送信することで、利用者の挙動のデータを収集する場合は、図２５に示すように、１つ目のブロック２１および３つ目のブロック２３にそれぞれ２つ目のｏｕｔ命令を追加し、アプリケーションサーバ１２０へ通知するように変更すればよい。

上記のように、実施例６によれば、レンタカーサービスまたはシェアードカーサービスにおいて、車両５０の予約操作と同時に利用登録を行い、携帯端末４０を用いた利用者認証を行うシステムを構築することができる。これにより、利用者は、自身の携帯端末４０に専用のアプリケーション４３を導入し、車両５０の予約を行い、携帯端末４０を車両５０の利用のための認証ツールとして使用することが可能となる。

このように、レンタカーサービスまたはシェアードカーサービスにおける認証ツールとしてスマートフォン等の携帯端末４０を使用することは、専用カード等の専用デバイスを用いる場合に比べて、携帯端末４０に備わる個人認証機能との併用による不正利用の防止、決済機能との併用による予約時の決済処理の利用により、利用者の負担を軽減するとともに、利用者の利便性を高めることが可能となる。

（実施例７）
実施例７は、遠隔制御方式を採用した自動運転車両の位置を可能な限り詳細に得るための車載通信機器１０の適用例である。

図２６は、実施例７の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図である。

図２６に示す車載通信機器１０は、図２に示す車載通信機器１０からアプリケーション２２を削除した構成をしている。また、通信器４は、ＧＰＳ装置１６０と通信可能となっており、通信器１は、車両５０の外部にある無線ＬＡＮアクセスポイント１７０と通信可能となっている。また、通信器０は、管理サーバ１００とアプリケーションサーバ１２０との両方と通信可能となっている。

一般に、ナビゲーションシステム等に備えられているＧＰＳ装置１６０は、車両５０の位置把握に利用することが可能である。しかしながら、ＧＰＳ測位は精度が粗く、また、ＧＰＳ衛星からの電波受信状況による影響を受け易いこと等から、位置精度は、通信環境の変動による悪影響を受けやすい。

スマートフォンに代表される携帯端末では、このＧＰＳの欠点を補うために、通信中の移動体通信基地局の位置等の情報の利用に加えて、周辺で検知される無線ＬＡＮアクセスポイントを検知し、その位置推定に利用している。しかし、周辺の無線ＬＡＮアクセスポイントは、新設・削除および周辺建築物の影響を受けやすく、通信状態が随時変化する環境となっており、さらには、無線ＬＡＮアクセスポイントが移動可能である場合には、位置推定精度が低下する恐れがある。

同様に、車両位置把握のために、周辺の無線ＬＡＮアクセスポイントを検知し、利用することを想定した場合、通信状態の変化の、位置精度への影響を排除することが必要となる。無線ＬＡＮの通信状態の変化に対応するためには、例えば予め契約等によりその位置が決定されている無線ＬＡＮアクセスポイントの位置情報を利用することが考えられる。

そのため、本実施例では、通信器１が、周辺の複数の無線ＬＡＮアクセスポイント１７０と通信を行い、無線ＬＡＮ情報ｐを取得して、通信監視制御処理部１８へ送る。無線ＬＡＮ情報ｐは、無線ＬＡＮアクセスポイント１７０の名前と、受信信号強度とを含む。また、通信器４が、車両５０に搭載されたＧＰＳ装置１６０から、ＧＰＳ測位された車両位置情報であるＧＰＳ情報ｑを取得して、通信監視制御処理部１８へ送る。

通信監視制御処理部１８は、無線ＬＡＮ情報ｐおよびＧＰＳ情報ｑを命令実行処理部１６へ送り、命令実行処理部１６は、無線ＬＡＮ情報ｐおよびＧＰＳ情報ｑを通信器０へ送り、通信器０は、無線ＬＡＮ情報ｐおよびＧＰＳ情報ｑをアプリケーションサーバ１２０へ送信する。

アプリケーションサーバ１２０は、無線ＬＡＮ情報ｐおよびＧＰＳ情報ｑを受信する。そして、無線ＬＡＮ情報ｐおよびＧＰＳ情報ｑと、別途用意された無線ＬＡＮアクセスポイント位置情報とに基づき、周知の位置決め手法を用いて、車両位置を推定する。

次に、実施例７における処理の流れについて説明する。

図２７は、実施例７における処理の流れを示すフローチャートである。

図２７のフローチャートに示すステップＳ１０〜Ｓ１１、Ｓ６３〜Ｓ６４は、図２０のフローチャートにおけるステップＳ１０〜Ｓ１１、Ｓ６３〜Ｓ６４と同様であるが、図２７のステップＳ１０において管理サーバ１００から送られるサービス情報ａは、例えば図２８に示す通りであり、予め契約等によりその位置情報が明確化されている無線ＬＡＮアクセスポイントからの信号のみを検知するものとして作成されている。

このように、管理サーバ１００から通信器０へ送信されるサービス情報ａの配信は、期間を決めて複数を一括配信し、車載通信機器１０で車両位置に合わせて切り替えて使用してもよいし、車両位置情報を管理サーバ１００で監視し、車両位置に合わせて配信してもよい。

ステップＳ１００以降、車載通信機器１０の命令実行処理部１６は、図２８のサービス情報ａの第３行目の＠ｐａｒａｒｅｌｌ命令に従い、３つのブロックｂ３１、ｂ３２、ｂ３３の内容を同時並行的に処理し、同第２行目の＠ｌｏｏｐ命令により、６０秒おきに処理を繰り返す。

図２８に示す１つ目のブロックｂ３１では、ｉｎ命令により、「ａ＿ｗｉｆｉａｐ」の後ろに数字が３個続く「ａ＿ｗｉｆｉａｐ￥ｄ￥ｄ￥ｄ」の正規表現に合致するアクセスポイント名が発見された場合（Ｓ１０２）、変数ＳＴ００１にアクセスポイント名および受信信号電力が、続くｏｕｔ命令により「通信器０：ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｓｅｒｖｉｃｅＡ」へ通知される（Ｓ１０３）。

同２つ目のブロックｂ３２では、ｉｎ命令により、「ｂ＿ｗｉｆｉａｐ」の後ろに数字が３個続く「ｂ＿ｗｉｆｉａｐ￥ｄ￥ｄ￥ｄ」の正規表現に合致するアクセスポイント名が発見された場合（Ｓ１０２）、ＳＴ００１にアクセスポイント名および受信信号電力が、続くｏｕｔ命令により「通信器０：ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｓｅｒｖｉｃｅＡ」へ通知される（Ｓ１０３）。

同３つ目のブロックｂ３３では、ｉｎ命令により、「ｃ＿ｗｉｆｉａｐ」の後ろに数字が３個続き、且つその後ろに「＿ｍｏｂｉｌｅ」が続かない「ｃ＿ｗｉｆｉａｐ￥ｄ￥ｄ￥ｄ（？！＿ｍｏｂｉｌｅ）」の正規表現に合致するアクセスポイント名が発見された場合（Ｓ１０２）、変数ＳＴ００１にアクセスポイント名および受信信号電力が、続くｏｕｔ命令により「通信器０：ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｓｅｒｖｉｃｅＡ」へ通知される（Ｓ１０３）。

なお、上記の何れにも合致しないアクセスポイント名を持つ無線ＬＡＮアクセスポイント１７０からの信号は、たとえ検知されても、アプリケーションサーバ１２０へ通知されない。

さらに、利用可能と判断された無線ＬＡＮアクセスポイントが追加された場合や、無効な無線ＬＡＮアクセスポイントが発生した場合は、サービス情報aを修正し、修正されたサービス情報ａを管理サーバ１００から車載通信機器１０へ再送信することで、対応可能となる。

上記のように、実施例７によれば、位置把握に利用する無線ＬＡＮアクセスポイント１７０を、状況に合わせて管理サーバ１００から制御することができ、また、車両５０側で検知した無線ＬＡＮアクセスポイント１７０のうち、必要な無線ＬＡＮアクセスポイント１７０から得られた情報のみを、アプリケーションサーバ１２０へ通知することによって、位置推定精度の確保と、不要な通信を削減することによる通信費の削減との両方を実現することが可能となる。

（実施例８）
実施例８は、ドライブレコーダによって撮影した画像を、アプリケーションサーバへ送信する処理を支援するための車載通信機器１０の適用例である。

通信状態は、車両５０の移動に応じて、随時変化する。また、通信量に応じて費用が発生する。従って、実施例８では、車両５０に搭載されたドライブレコーダ１８０からの画像の送信に、以下の制約を設ける。

すなわち、例えば移動体通信網５２のような通信器０からのアプリケーションサーバ１２０への画像情報ｓの送信は、フレームレートを小さくした低解像度画像によって行うものとする一方、撮影した動画は、後の送信に備えてドライブレコーダ１８０の本体内に記憶する。ドライブレコーダ１８０の本体内に記憶した動画ｖは、無線ＬＡＮによる通信が可能となった時点で、ドライブレコーダ１８０から通信器０を介してアプリケーションサーバ１２０へ送信する。

図２９は、実施例８の車載通信機器の構成例を示す機能ブロック図を含むサービス提供システム全体図であって、前述したような制約を満足している。

図２９に示す車載通信機器１０は、図２６に示す車載通信機器１０に類似しているが、命令実行処理部１６と通信器０との間に、通信器２と、ドライブレコーダ１８０とを設けている。また、通信監視制御処理部１８に通信器２，３，４は接続されておらず、通信器１のみが接続されている。通信器１は、図２６と同様に、無線ＬＡＮアクセスポイント１７０と通信可能であるが、それに加えて、ドライブレコーダ１８０にも接続している。無線ＬＡＮアクセスポイント１７０は、アプリケーションサーバ１２０との通信が可能である。

次に、実施例８における処理の流れについて説明する。

図３０は、実施例８における処理の流れを示すフローチャートである。

図３０のフローチャートに示すステップＳ１０〜Ｓ１１、Ｓ６３は、図２０のフローチャートにおけるステップＳ１０〜Ｓ１１、Ｓ６３と同様であるが、図３０のステップＳ１０において管理サーバ１００から送信されるサービス情報ａは、例えば図３１に示す通りであり、予め契約等により、利用可能となっている無線ＬＡＮアクセスポイント１７０からの信号のみを検知するものとして作成されている。

そして、ステップＳ１０では、管理サーバ１００が、このサービス情報ａを、例えば移動体通信網５２のような通信器０を介して、車載通信機器１０へ送信する。このようなサービス情報aの送信は、例えば、期間を決めた複数の一括配信によって、または、車載通信機器１０で車両位置に合わせて切り替えて使用することによって、あるいは、車両位置情報の管理サーバ１００における監視に基づく車両位置に合わせた配信によっても良い。

ステップＳ１１０以降、車載通信機器１０の命令実行処理部１６は、図３０における２つのブロックｂ４１、ｂ４２を同時並行的に処理し、第２行目の＠ｌｏｏｐ命令により、６０秒おきに処理を繰り返す。

図３０における１つ目のブロックｂ４１では、ｉｎ命令により、「ａ＿ｗｉｆｉａｐ」の後ろに数字が３個続く「ａ＿ｗｉｆｉａｐ￥ｄ￥ｄ￥ｄ」の正規表現に合致するアクセスポイント名が発見された場合、続くｏｕｔ命令により通信器２経由でドライブレコーダ「通信器２：ドライブレコーダ」へ、「ＷＢ」を送信することで、無線ＬＡＮが利用可能となったことが通知される（Ｓ１１１）。

同２つ目のブロックｂ４２では、ｉｎ命令により、「ａ＿ｗｉｆｉａｐ」の後ろに数字が３個続く「ａ＿ｗｉｆｉａｐ￥ｄ￥ｄ￥ｄ」の正規表現に合致するアクセスポイント名の無線ＬＡＮアクセスポイント１７０が、利用不可となった場合、続くｏｕｔ命令により通信器２経由でドライブレコーダ「通信器２：ドライブレコーダ」へ、「ＮＢ」を送信することで、無線ＬＡＮが利用不可能となったことが通知される（Ｓ１１２）。

ステップＳ１１１の後、ドライブレコーダ１８０は、蓄積した動画ｖを、無線ＬＡＮアクセスポイント１７０を経由してアプリケーションサーバ１２０へ送信する（Ｓ１１３）。

一方、ステップ１１２の後、ドライブレコーダ１８０は、画像情報ｓをフレームレートを下げて、通信器０を経由して、アプリケーションサーバ１２０へ送信する（Ｓ１１４）。

上記のように、実施例８によれば、周辺の無線通信環境を検知することによって、ドライブレコーダ１８０において最適な通信回線の選択および送信方法を選択可能とし、また随時変動する通信状態に合わせて、利用する通信経路を車外から制御することも可能となる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

０通信器、１通信器、２通信器、３通信器、４通信器、１０車載通信機器、１２命令取得処理部、１４命令データ記憶部、１６命令実行処理部、１８通信監視制御処理部、２０実行監視処理部、２２アプリケーション、２４表示処理部、２６表示器、４０携帯端末、４２アプリケーション、４３アプリケーション、５０車両、５２移動体通信網、５８路車間通信、６０車車間通信、６４Ｂｌｕｅｔｏｏｔｈ、６８携帯端末、７０車内通信、７２車内機器、９０無線ネットワーク、１００管理サーバ、１２０アプリケーションサーバ、１３０ガソリンスタンドシステム、１３２ガソリンスタンド側通信器、１３４誘導装置、１４０駐車場システム、
１４１駐車場システム、１４２料金精算器、１５０車両制御器、１６０ＧＰＳ装置、１７０アクセスポイント、１８０ドライブレコーダ。

Claims

車両に提供するサービスの内容を記述したサービス情報を、管理サーバから取得する命令取得処理手段と、
前記命令取得処理手段によって取得されたサービス情報に含まれる第１の命令の実行時に、前記車両に搭載された複数の通信器の通信状態の変化の監視を指示する命令実行処理手段と、
前記命令実行処理手段による指示に基づいて、前記複数の通信器の通信状態の変化を監視し、前記変化が発生すると、前記命令実行処理手段へ、前記変化が発生した通信器の通信状態を送る通信監視制御処理手段とを備え、
前記命令実行処理手段は、前記通信監視制御処理手段から送られた通信状態を受け取ると、前記変化が発生した場合に前記複数の通信器に対して行う処理内容を含む第２の命令に従って、前記通信監視制御処理手段に対して、前記変化が発生した通信器に対する処理を指示し、
前記通信監視制御処理手段は、この指示に従って、前記変化が発生した通信器を制御し、
前記制御された通信器から出力された通知によって、前記通信状態の変化に応じて、前記サービスが、アプリケーションサーバによって提供されるようにした、車載通信機器。
前記通信状態の変化は、前記複数の通信器における通信の接続および切断、指定された無線通信端末からの電波の検知および喪失、予め指定される内容のデータの受信、のうちの少なくとも何れかを含む、請求項１に記載の車載通信機器。
前記通知は、前記通信状態の変化を検知した際に実施すべき前記通信器における通信の接続および切断、無線通信端末からの電波の捜索、ならびに指定される内容のデータの送信、のうちの何れかを含んでおり、前記通信監視制御処理手段からの指示に従って、前記制御された通信器から前記アプリケーションサーバへ送信される、請求項１または２に記載の車載通信機器。
車両に提供するサービスの内容を記述したサービス情報を、管理サーバから受信する手順、
前記受信されたサービス情報に含まれる第１の命令の実行時に、前記車両に搭載された複数の通信器の通信状態の変化の監視を指示する手順、
前記指示に基づいて、前記通信状態の変化を監視し、前記変化が発生すると、前記複数の通信器に対して行う処理内容を含む第２の命令に従って、前記変化が発生した通信器に対する処理を指示する手順、
前記指示に従って、前記変化が発生した通信器を制御する手順、
前記制御された通信器から出力された通知によって、前記通信状態の変化に応じて、前記サービスをアプリケーションサーバから取得する手順、
をコンピュータに実行させるプログラム。
車両に提供するサービスの内容を記述したサービス情報を送信する管理サーバと、
前記管理サーバによって送信された前記サービス情報を受信し、
前記受信されたサービス情報に含まれる第１の命令の実行時に、前記車両に搭載された複数の通信器の通信状態の変化の監視を指示し、
前記指示に基づいて、前記通信状態の変化を監視し、前記変化が発生すると、前記変化が発生した場合に前記複数の通信器に対して行う処理内容を含む第２の命令に従って、前記変化が発生した通信器を制御する車載通信機器と、
前記制御された通信器から出力された通知によって、前記通信状態の変化に応じて、前記サービスを前記車載通信機器へ提供するアプリケーションサーバと、
を備えたサービス提供システム。