JP2021009442A - 自動バレーパーキングシステム、自動バレーパーキングプログラムおよび記憶媒体 - Google Patents

Abstract

【課題】システムの安全性を高める。【解決手段】申込情報生成部２０３は、申込情報を生成し、申込情報を駐車場サーバ装置４００およびＯＥＭサーバ装置５００に送信する。要求生成部４０３は、端末装置２００から送信される申込情報を受信すると、一時鍵の生成を要求する一時鍵要求を生成し、一時鍵要求をＯＥＭサーバ装置５００に送信する。検証部５０４は、端末装置２００から送信される申込情報を受信するとともに駐車場サーバ装置４００から送信された一時鍵要求を受信すると、一時鍵要求の真贋を検証する。一時鍵生成部５０６は、検証部５０４による検証結果が真である場合に一時鍵を生成し、一時鍵を自動車３００に送信する。運転計画部４０４は、自動車３００の駐車目標位置までの経路が含まれる運転計画を生成する。自動運転制御部３０６は、ＯＥＭサーバ装置５００から送信された一時鍵を受信すると、運転計画に従って自動運転制御を実行する。【選択図】図２

Description

本発明は、自動運転制御によるバレーパーキングを実現する自動バレーパーキングシステム、自動バレーパーキングプログラムおよび記憶媒体に関する。

従来、自動運転制御によるバレーパーキングシステムに関して、例えば特許文献１に記載されるような技術が提案されている。以下、自動運転制御によるバレーパーキングシステムのことを、自動バレーパーキングシステムとも呼ぶこととする。このような従来技術では、自動バレーパーキングが実施される際、端末装置は、自動運転制御を実施するための権限に相当する一時鍵を生成し、その一時鍵を自動車および駐車場側に設けられるサーバ装置である駐車場サーバ装置へ送信する。そして、上記従来技術では、自動車側において、一時鍵の一致検証を行うことにより、システムの安全性を向上させている。

特開２０１８−０４１３８１号公報

上記従来技術のシステムでは、自動車の操作権限を与えるための一時鍵が、駐車場サーバ装置に与えられるようになっている。一時鍵など、自動車のデジタル的な鍵は、車両情報が含まれているうえ、ドアロックの開閉をはじめとする各種の操作を実行するための権限を有している。したがって、このようなデジタル鍵は、機密性の高いものであり、車両を製造する車両メーカー、いわゆるＯＥＭ毎に独自の生成方法が採用されている。

このような事情から、上記デジタル鍵は、本来、ＯＥＭ以外の第三者に渡してはならないものである。仮に、第三者がデジタル鍵を手にした場合、その第三者は、鍵の仕組みを読み取ってしまう可能性がある。そのため、上記従来技術のシステムは、システムの安全性が十分に高められているとは言い難く、セキュリティの面において課題があった。

本発明は上記事情に鑑みてなされたものであり、その目的は、システムの安全性を高めることができる自動バレーパーキングシステム、自動バレーパーキングプログラムおよび記憶媒体を提供することにある。

請求項１に記載の自動バレーパーキングシステムは、それぞれの間で互いにデータの送受信が可能に構成された端末装置（２００）、車両（３００）、駐車場に設けられる駐車場サーバ装置（４００）および車両の製造者により直接的または間接的に管理されるＯＥＭサーバ装置（５００）を含み、自動運転制御によるバレーパーキングを実行するシステムである。そして、前記端末装置は、申込情報生成部（２０３、２０５）を備え、前記駐車場サーバ装置は、鍵要求生成部（４０３、４０６）を備え、前記ＯＥＭサーバ装置は、鍵要求検証部（５０４、５０９）および一時鍵生成部（５０６）を備え、前記駐車場サーバ装置または前記車両は、運転計画部（３０８、４０４）を備え、前記車両は、自動運転制御部（３０６、３０９）を備える。

前記申込情報生成部は、前記バレーパーキングの申し込みに関する情報である申込情報を生成し、その申込情報を前記駐車場サーバ装置および前記ＯＥＭサーバ装置に送信する。前記鍵要求生成部は、前記端末装置から送信される前記申込情報を受信すると、一時鍵の生成を要求する一時鍵要求を生成し、その一時鍵要求を前記ＯＥＭサーバ装置に送信する。前記鍵要求検証部は、前記端末装置から送信される前記申込情報を受信するとともに前記駐車場サーバ装置から送信された前記一時鍵要求を受信すると、その一時鍵要求の真贋を検証する。前記一時鍵生成部は、前記鍵要求検証部による検証結果が真である場合に前記一時鍵を生成し、その一時鍵を前記車両に送信する。前記運転計画部は、前記車両の駐車目標位置までの経路が含まれる運転計画を生成する。前記自動運転制御部は、前記ＯＥＭサーバ装置から送信された前記一時鍵を受信すると、前記運転計画部により生成された前記運転計画に従って自動運転制御を実行する。

上記構成の自動バレーパーキングシステムでは、車両のデジタル的な鍵である一時鍵の受け渡しが、ＯＥＭサーバ装置と車両との間で直接行われるようになっており、一時鍵が駐車場サーバ装置に与えられることはない。そのため、仮に、駐車場サーバ装置が悪意のある第三者によりハッキングされるなどしても一時鍵が取得されることはなく、車両のデジタル的な鍵の仕組みが読み取られるおそれもない。このように、上記構成によれば、車両のデジタル的な鍵の仕組みの機密性が高められることから、システムの安全性を高めることができるという優れた効果が得られる。

第１実施形態に係る自動バレーパーキングシステムの全体構成を模式的に示す図 第１実施形態に係る自動バレーパーキングシステムの各部の詳細構成を模式的に示す図 第１実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図その１ 第１実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図その２ 第２実施形態に係る自動バレーパーキングシステムの各部の詳細構成を模式的に示す図 第２実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図その１ 第２実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図その２ 第３実施形態に係る自動バレーパーキングシステムの各部の詳細構成を模式的に示す図 第３実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図 第４実施形態に係る自動バレーパーキングシステムの各部の詳細構成を模式的に示す図 第４実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図 第５実施形態に係る自動バレーパーキングシステムの各部の詳細構成を模式的に示す図 第５実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図 第６実施形態に係る自動バレーパーキングが実行される際における各部の処理の流れを示す図

以下、本発明の複数の実施形態について図面を参照して説明する。なお、各実施形態において実質的に同一の構成には同一の符号を付して説明を省略する。
（第１実施形態）
以下、第１実施形態について図１〜図４を参照して説明する。

＜自動バレーパーキングシステム１００の全体構成＞
図１に示す本実施形態の自動バレーパーキングシステム１００は、端末装置２００、車両に相当する自動車３００、駐車場サーバ装置４００、ＯＥＭサーバ装置５００および地図サーバ装置６００を含み、自動運転制御によるバレーパーキングを実行するシステムである。なお、以下の説明などでは、自動バレーパーキングのことをＡＶＰと省略することがある。この場合、自動車３００の所有者は、端末装置２００を所持するユーザである。つまり、本実施形態では、ユーザが自動車３００の持ち主となっている。

端末装置２００は、通信機能を有するとともに、その所有者の認証情報などが格納された機器である。端末装置２００および自動車３００は、それぞれの間でデータの送受信、つまり通信が可能に構成されている。端末装置２００および自動車３００は、図１に破線で示すように、例えば近距離無線通信によりデータの送受信を行う構成でもよいし、ネットワーク７００を介してデータの送受信を行う構成でもよい。ネットワーク７００としては、例えば、無線ＬＡＮ、移動体通信網などを挙げることができる。

端末装置２００と、駐車場サーバ装置４００およびＯＥＭサーバ装置５００とは、ネットワーク７００を介して通信可能に接続されている。また、自動車３００と、駐車場サーバ装置４００およびＯＥＭサーバ装置５００とは、ネットワーク７００を介して通信可能に接続されている。さらに、ＯＥＭサーバ装置５００と、駐車場サーバ装置４００および地図サーバ装置６００とは、ネットワーク７００を介して通信可能に接続されている。このように、ＡＶＰシステム１００では、端末装置２００、自動車３００、駐車場サーバ装置４００、ＯＥＭサーバ装置５００および地図サーバ装置６００は、それぞれの間で互いにデータの送受信が可能に構成されている。

本実施形態では、端末装置２００は、例えばスマートフォン、タブレット端末などのスマートデバイスとなっている。なお、端末装置２００としては、所有者の認証情報などが格納されるとともに通信機能が追加された自動車用電子キーなどであってもよい。自動車３００は、自動運転機能を有する自動車である。駐車場サーバ装置４００は、バレーパーキングサービスを提供する施設の駐車場に設けられるサーバ装置である。駐車場サーバ装置４００は、このような施設または施設と契約している駐車場管理会社により管理および管轄されている。

ＯＥＭサーバ装置５００は、自動車３００の製造者である車両メーカー、いわゆるＯＥＭにより運営されるサーバ装置である。この場合、ＯＥＭサーバ装置５００は、ＯＥＭにより直接的に管理されるようになっている。なお、ＯＥＭサーバ装置５００は、ＯＥＭとの間で秘密保持契約などを締結するとともにＯＥＭより運営を委託された別の会社などにより間接的に管理されるようにすることもできる。

地図サーバ装置６００は、後述する一時鍵の有効区間に関する情報である有効区間情報を取得し、その有効区間情報をＯＥＭサーバ装置５００に送信する。なお、以下の説明では、有効区間のことを有効区画とも称するとともに、有効区間情報のことを有効区画情報とも称する。地図サーバ装置６００は、信頼できる第三者機関、例えば自動運転制御に関する行政、測量などを取り扱う専門の公的機関、国土交通省の関係機関などにより管理および管轄されている。

＜端末装置２００の詳細構成＞
端末装置２００は、その内部に電子鍵が格納されており、電子鍵を用いた認証を行うことにより、自動車３００に自動運転を実行させることができる。しかしながら、このような電子鍵を外部の装置などに対して特段の制限なく送信することは、セキュリティの低下を招くおそれがあることから好ましくない。

そこで、この場合、詳細は後述するが、ＡＶＰが実行される際にだけ、ＯＥＭサーバ装置５００が、電子鍵と同等の鍵として機能する一時鍵Ｄａを生成する。このような一時鍵Ｄａにより電子鍵と同様に所有者の認証を行うことが可能となり、自動車３００に自動運転を実行させることができる。ただし、一時鍵Ｄａは、電子鍵とは異なる条件、例えば予め定められた有効期間を過ぎた場合、自動車３００が有効区間の範囲外に出た場合などに失効するようになっている。

図２に示すように、端末装置２００は、外部の装置との間で各種のデータを送受信するデータ送受信部２０１および各種のデータを記憶する記憶部２０２を備えている。記憶部２０２には、予め格納された各種の情報のほか、データ送受信部２０１を介して受信される各種の情報も記憶される。また、端末装置２００は、申込情報生成部２０３、情報暗号化部２０４などの機能ブロックを備えている。

これら各機能ブロックは、端末装置２００が備えるＣＰＵが非遷移的実体的記憶媒体に格納されているコンピュータプログラムを実行してコンピュータプログラムに対応する処理を実行することにより実現されている、つまりソフトウェアにより実現されている。なお、各機能ブロックのうち少なくとも一部をハードウェアにより実現する構成としてもよい。

申込情報生成部２０３は、バレーパーキングの申し込みに関する情報である申込情報Ｄｂを生成する。申込情報Ｄｂには、ユーザの情報、申込先の駐車場の情報、駐車場の利用時間の情報などが含まれる。申込情報生成部２０３は、生成した申込情報Ｄｂを、データ送受信部２０１を介して駐車場サーバ装置４００およびＯＥＭサーバ装置５００に送信する。申込情報生成部２０３により実行される各処理は、申込情報生成手順に相当する。

この場合、記憶部２０２には、自動車３００に関する情報である車両情報が記憶されている。車両情報には、例えば車種（例えば、普通自動車であるか、軽自動車であるか、など）、車番、車高などのサイズ、車両の持ち主であるユーザの情報などに関する情報が含まれる。車種やサイズなどの情報は、駐車枠の選択に役立つ情報となる。情報暗号化部２０４は、記憶部２０２から車両情報を読み出し、その車両情報を暗号化する。情報暗号化部２０４は、暗号化した車両情報Ｄｃを、データ送受信部２０１を介して駐車場サーバ装置４００およびＯＥＭサーバ装置５００に送信する。

この場合、駐車場サーバ装置４００に対する申込情報Ｄｂおよび車両情報Ｄｃの送信は、同時に行われる。また、この場合、ＯＥＭサーバ装置５００に対する申込情報Ｄｂおよび車両情報Ｄｃの送信は、同時に行われる。なお、ＯＥＭサーバ装置５００に送信される申込情報Ｄｂには、少なくとも申込先の駐車場の情報が含まれていればよい。また、以下の説明では、ＯＥＭサーバ装置５００に送信される申込情報Ｄｂおよび車両情報Ｄｃをまとめて認証情報と呼ぶことがある。

＜自動車３００の詳細構成＞
自動車３００は、外部の装置との間で各種のデータを送受信するデータ送受信部３０１および各種のデータを記憶する記憶部３０２を備えている。記憶部３０２には、予め格納された各種の情報のほか、データ送受信部３０１を介して受信される各種の情報も記憶される。また、自動車３００は、要求生成部３０３、復号部３０４、照合部３０５および自動運転制御部３０６などの機能ブロックを備えている。

これら各機能ブロックは、自動車３００が備えるＣＰＵが非遷移的実体的記憶媒体に格納されているコンピュータプログラムを実行してコンピュータプログラムに対応する処理を実行することにより実現されている、つまりソフトウェアにより実現されている。なお、各機能ブロックのうち少なくとも一部をハードウェアにより実現する構成としてもよい。

要求生成部３０３は、データ送受信部３０１を介してＯＥＭサーバ装置５００から送信された一時鍵Ｄａおよび有効区間情報Ｄｄを受信すると、運転計画の生成を要求する運転計画要求Ｄｅを生成する。なお、ＯＥＭサーバ装置５００による一時鍵Ｄａおよび有効区間情報Ｄｄの送信については後述する。要求生成部３０３は、生成した運転計画要求Ｄｅを、データ送受信部３０１を介して駐車場サーバ装置４００に送信する。

復号部３０４は、ＯＥＭサーバ装置５００から送信された一時鍵Ｄａを受信するとともに駐車場サーバ装置４００から送信されたパスワードＤｆを受信すると、それらの組み合わせが有効であるか否かを検証するものであり、鍵検証部としての機能を有する。なお、駐車場サーバ装置４００によるパスワードＤｆの送信については後述する。復号部３０４は、上記組み合わせが有効である場合、パスワードＤｆを用いて一時鍵Ｄａを解除する、つまり一時鍵Ｄａを有効化する。復号部３０４により実行される各処理は、鍵検証手順に相当する。

照合部３０５は、駐車場サーバ装置４００から送信された運転計画ＤｇとＯＥＭサーバ装置５００から送信された有効区間情報Ｄｄとを照合する。なお、駐車場サーバ装置４００による運転計画Ｄｇの送信については後述する。照合部３０５は、このような照合の結果、運転計画Ｄｇに含まれる経路が、有効区間の範囲内にあるか否かを判定する。自動運転制御部３０６は、データ送受信部３０１を介してＯＥＭサーバ装置５００から送信された一時鍵Ｄａを受信するとともに、データ送受信部３０１を介して駐車場サーバ装置４００から送信された運転計画ＤｇおよびパスワードＤｆを受信すると、運転計画Ｄｇに従って自動運転制御を実行する。

ただし、自動運転制御部３０６は、復号部３０４による検証結果として一時鍵ＤａおよびパスワードＤｆの組み合わせが有効であるという結果が得られた場合に、つまり、復号部３０４により一時鍵Ｄａが有効化された場合に、パスワードＤｆとともに送信された運転計画Ｄｇが利用可能であると判断し、その運転計画Ｄｇに従って自動運転制御を実行する。

また、この場合、自動運転制御部３０６は、照合部３０５による照合結果をも考慮して運転計画Ｄｇが利用可能であるか否かを判断する。具体的には、自動運転制御部３０６は、上記照合の結果、運転計画Ｄｇに含まれる経路の全てが有効区間の範囲内にあると判定される場合には運転計画Ｄｇが利用可能であると判断し、運転計画Ｄｇに含まれる経路の少なくとも一部が有効区間の範囲外にあると判定される場合には運転計画Ｄｇが利用不可能であると判断する。自動運転制御部３０６により実行される各処理は、自動運転制御手順に相当する。

＜駐車場サーバ装置４００の詳細構成＞
駐車場サーバ装置４００は、外部の装置との間で各種のデータを送受信するデータ送受信部４０１および各種のデータを記憶する記憶部４０２を備えている。記憶部４０２には、予め格納された各種の情報のほか、データ送受信部４０１を介して受信される各種の情報も記憶される。また、駐車場サーバ装置４００は、要求生成部４０３および運転計画部４０４などの機能ブロックを備えている。

これら各機能ブロックは、駐車場サーバ装置４００が備えるＣＰＵが非遷移的実体的記憶媒体に格納されているコンピュータプログラムを実行してコンピュータプログラムに対応する処理を実行することにより実現されている、つまりソフトウェアにより実現されている。なお、各機能ブロックのうち少なくとも一部をハードウェアにより実現する構成としてもよい。

要求生成部４０３は、データ送受信部４０１を介して端末装置２００から送信された申込情報Ｄｂおよび暗号化された車両情報Ｄｃを受信すると、一時鍵Ｄａの生成を要求する一時鍵要求Ｄｈを生成するものであり、鍵要求生成部としての機能を有する。要求生成部４０３は、生成した一時鍵要求Ｄｈと、暗号化された車両情報Ｄｃとを、データ送受信部４０１を介してＯＥＭサーバ装置５００に送信する。要求生成部４０３により実行される各処理は、鍵要求生成手順に相当する。

運転計画部４０４は、データ送受信部４０１を介して自動車３００から送信された運転計画要求Ｄｅを受信すると、運転計画Ｄｇを生成する。運転計画Ｄｇには、自動車３００の現在位置、自動車３００の駐車目標位置、現在位置から駐車目標位置までの経路、自動車３００の直進、右左折および後退のタイミング、走行速度などが含まれている。なお、駐車目標位置は、駐車場内の空き状況などを考慮して最適な位置に決定される。運転計画部４０４は、データ送受信部４０１を介してＯＥＭサーバ装置５００から送信されたパスワードＤｆを受信すると、生成した運転計画ＤｇとともにパスワードＤｆを、データ送受信部４０１を介して自動車３００に送信する。運転計画部４０４により実行される各処理は、運転計画手順に相当する。

＜ＯＥＭサーバ装置５００の詳細構成＞
ＯＥＭサーバ装置５００は、外部の装置との間で各種のデータを送受信するデータ送受信部５０１および各種のデータを記憶する記憶部５０２を備えている。記憶部５０２には、予め格納された各種の情報のほか、データ送受信部５０１を介して受信される各種の情報も記憶される。また、ＯＥＭサーバ装置５００は、復号部５０３、検証部５０４、要求生成部５０５および一時鍵生成部５０６などの機能ブロックを備えている。

これら各機能ブロックは、ＯＥＭサーバ装置５００が備えるＣＰＵが非遷移的実体的記憶媒体に格納されているコンピュータプログラムを実行してコンピュータプログラムに対応する処理を実行することにより実現されている、つまりソフトウェアにより実現されている。なお、各機能ブロックのうち少なくとも一部をハードウェアにより実現する構成としてもよい。

復号部５０３は、データ送受信部５０１を介して端末装置２００から送信される暗号化された車両情報Ｄｃを受信すると、その車両情報Ｄｃを復号化する。また、復号部５０３は、データ送受信部５０１を介して駐車場サーバ装置４００から送信される暗号化された車両情報Ｄｃを受信すると、その車両情報Ｄｃを復号化する。検証部５０４は、データ送受信部５０１を介して端末装置２００から送信される申込情報Ｄｂを受信するとともに、データ送受信部５０１を介して駐車場サーバ装置４００から送信された一時鍵要求Ｄｈを受信すると、その一時鍵要求Ｄｈの真贋を検証するものであり、鍵要求検証部としての機能を有する。

具体的には、検証部５０４は、次のようにして端末装置２００および駐車場サーバ装置４００から送信された各情報を検証することにより一時鍵要求Ｄｈの真贋を検証する。すなわち、検証部５０４は、端末装置２００から送信された車両情報Ｄｃと、駐車場サーバ装置４００から送信された車両情報Ｄｃとが一致するか否かを判断する。また、検証部５０４は、端末装置２００から送信された申込情報Ｄｂに含まれる申込先の駐車場と、一時鍵要求Ｄｈの送信元である駐車場サーバ装置４００が設けられた駐車場とが一致するか否か、つまり駐車場情報が一致するか否かを判断する。

検証部５０４は、車両情報Ｄｃが一致するとともに駐車場情報が一致する場合には一時鍵要求Ｄｈが真正であると判断し、車両情報Ｄｃおよび駐車場情報の一方または双方が一致しない場合には一時鍵要求Ｄｈが真正ではないと判断する。検証部５０４により実行される各処理は、鍵要求検証手順に相当する。要求生成部５０５は、有効区間情報Ｄｄの送信を要求する区間情報要求Ｄｉを生成するものであり、区間要求生成部としての機能を有する。

要求生成部５０５は、生成した区間情報要求Ｄｉを、データ送受信部５０１を介して地図サーバ装置６００に送信する。要求生成部５０５により実行される各処理は、区間要求生成手順に相当する。一時鍵生成部５０６は、検証部５０４による検証結果が真である場合に一時鍵Ｄａを生成する。一時鍵生成部５０６は、データ送受信部５０１を介して地図サーバ装置６００から送信された有効区間情報Ｄｄを受信すると、生成した一時鍵Ｄａとともに受信した有効区間情報Ｄｄを、データ送受信部５０１を介して自動車３００に送信する。

この場合、一時鍵生成部５０６は、一時鍵Ｄａを生成する際、一時鍵Ｄａを有効化するためのパスワードＤｆも生成するようになっている。なお、パスワードＤｆとしては、例えば、ワンタイムパスワードを採用することができる。一時鍵生成部５０６は、生成したパスワードＤｆを、駐車場サーバ装置４００を経由して自動車３００に送信する。一時鍵生成部５０６により実行される各処理は、一時鍵生成手順に相当する。

＜地図サーバ装置６００の詳細構成＞
地図サーバ装置６００は、外部の装置との間で各種のデータを送受信するデータ送受信部６０１および各種のデータが蓄積されたデータベース６０２を備えている。また、地図サーバ装置６００は、機能ブロックである有効区画情報検索部６０３を備えている。有効区画情報検索部６０３は、地図サーバ装置６００が備えるＣＰＵが非遷移的実体的記憶媒体に格納されているコンピュータプログラムを実行してコンピュータプログラムに対応する処理を実行することにより実現されている、つまりソフトウェアにより実現されている。なお、有効区画情報検索部６０３をハードウェアにより実現する構成としてもよい。

有効区画情報検索部６０３は、一時鍵Ｄａの有効区間に関する情報である有効区間情報Ｄｄを取得するものであり、有効区間取得部としての機能を有する。なお、有効区間は、一時鍵Ｄａによって自動車３００が走行可能となる範囲である走行可能範囲に相当する。また、有効区間情報は、走行可能範囲に関する情報である走行可能範囲情報に相当する。具体的には、有効区画情報検索部６０３は、データ送受信部６０１を介してＯＥＭサーバ装置５００から送信された区間情報要求Ｄｉを受信すると、データベース６０２に蓄積された各種データを検索することにより有効区間情報Ｄｄを取得する。

有効区画情報検索部６０３は、取得した有効区間情報Ｄｄを、データ送受信部６０１を介してＯＥＭサーバ装置５００に送信する。有効区画情報検索部６０３により実行される各処理は、有効区間取得手順に相当する。有効区間情報Ｄｄは、例えば信頼できる第三者機関により予め準備されているものであり、データベース６０２内に蓄積されている。有効区間情報Ｄｄは、一時鍵Ｄａが有効に使用できる区間である有効区間が記憶された地図情報となっている。なお、有効区間としては、例えばＡＶＰのサービスが提供されるエリア、つまり駐車場内のエリアだけを対象とすることができる。

次に、上記構成の作用について説明する。
本実施形態のＡＶＰシステム１００によりＡＶＰが実行される際、各部の具体的な処理内容は、例えば図３および図４に示すようなものとなる。
＜「ＡＶＰ申し込み」から「走行可能範囲受信」までの処理の流れ＞
ＡＶＰ申し込み〜走行可能範囲受信までの処理は、図３に示すような内容の処理となる。まず、ユーザの操作によりバレーパーキングが申し込まれると、端末装置２００は、ステップＳ２０１において、その申し込みの操作を認識し、その操作内容に応じて申込情報Ｄｂを生成する。

端末装置２００は、ステップＳ２０２において、車両情報Ｄｃの暗号化を行う。端末装置２００は、ステップＳ２０３において、申込情報Ｄｂおよび暗号化された車両情報Ｄｃを、駐車場サーバ装置４００へ送信する。また、端末装置２００は、ステップＳ２０４において、申込情報Ｄｂおよび暗号化された車両情報Ｄｃ、つまりバレーパーキング申し込みの認証情報を、ＯＥＭサーバ装置５００へ送信する。

駐車場サーバ装置４００は、ステップＳ４０１において申込情報Ｄｂおよび暗号化された車両情報Ｄｃを受信すると、ステップＳ４０２に進み、一時鍵要求Ｄｈを生成する。駐車場サーバ装置４００は、ステップＳ４０３において、一時鍵要求Ｄｈおよび暗号化されたままの車両情報Ｄｃを、ＯＥＭサーバ装置５００へ送信する。本実施形態では、端末装置２００により暗号化された車両情報Ｄｃの復号化は、ＯＥＭサーバ装置５００にはできるが、駐車場サーバ装置４００にはできないようになっている。そのため、駐車場サーバ装置４００は、端末装置２００から送信された個人情報などが含まれる車両情報Ｄｃの内容を知ることはできない。

ＯＥＭサーバ装置５００は、ステップＳ５０１において一時鍵要求Ｄｈおよび暗号化された車両情報Ｄｃを受信するとともに、ステップＳ５０２において認証情報を受信すると、ステップＳ５０３進み、車両情報Ｄｃの復号化を行う。ＯＥＭサーバ装置５００は、ステップＳ５０４において、一時鍵要求Ｄｈの真贋の検証を行う。ＯＥＭサーバ装置５００は、一時鍵要求Ｄｈが真正であると判断した場合にだけ、ステップＳ５０５以降の処理を実行する。

ＯＥＭサーバ装置５００は、一時鍵要求Ｄｈが真正ではないと判断した場合、端末装置２００に対してエラーメッセージを送信するなどして、ユーザに対して一時鍵Ｄａを生成することができない、ひいてはＡＶＰを実行することができない旨の報知を行い、これによりＡＶＰシステム１００における一連の処理が終了となる。ＯＥＭサーバ装置５００は、ステップＳ５０５において、区間情報要求Ｄｉを生成する。ＯＥＭサーバ装置５００は、ステップＳ５０６において、区間情報要求Ｄｉを、地図サーバ装置６００へ送信する。

地図サーバ装置６００は、ステップＳ６０１において区間情報要求Ｄｉを受信すると、ステップＳ６０２に進み、データベース６０２に蓄積された各種データを検索することにより有効区間情報Ｄｄ、つまり走行可能範囲情報を取得する。その後、地図サーバ装置６００は、ステップＳ６０３において、有効区間情報ＤｄをＯＥＭサーバ装置５００へ送信する。ＯＥＭサーバ装置５００は、ステップＳ５０７において有効区間情報Ｄｄを受信する。

＜「一時鍵等生成」から「自動運転開始」までの処理の流れ＞
一時鍵等生成〜自動運転開始までの処理は、図４に示すような内容の処理となる。ＯＥＭサーバ装置５００は、前述したように、ステップＳ５０７において有効区間情報Ｄｄ、つまり走行可能範囲情報を受信すると、ステップＳ５０８に進み、一時鍵ＤａおよびパスワードＤｆを生成する。

ＯＥＭサーバ装置５００は、ステップＳ５０９において、一時鍵Ｄａおよび有効区間情報Ｄｄを自動車３００へ送信する。また、ＯＥＭサーバ装置５００は、ステップＳ５１０において、パスワードＤｆを駐車場サーバ装置４００へ送信する。自動車３００は、ステップＳ３０１において一時鍵Ｄａおよび有効区間情報Ｄｄを受信すると、ステップＳ３０２に進み、運転計画要求Ｄｅを生成する。自動車３００は、ステップＳ３０３において、運転計画要求Ｄｅを駐車場サーバ装置４００へ送信する。

駐車場サーバ装置４００は、ステップＳ４０４においてパスワードＤｆを受信するとともに、ステップＳ４０５において運転計画要求Ｄｅを受信すると、ステップＳ４０６に進み、運転計画Ｄｇを生成する。駐車場サーバ装置４００は、ステップＳ４０７において、運転計画ＤｇおよびパスワードＤｆを自動車３００へ送信する。自動車３００は、ステップＳ３０４において、運転計画ＤｇおよびパスワードＤｆを受信すると、ステップＳ３０５に進み、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効であるか否かを検証し、それらの組み合わせが有効であるという検証結果が得られた場合、パスワードＤｆを用いて一時鍵Ｄａを解除する。

自動車３００は、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効ではないという検証結果が得られた場合、端末装置２００に対してエラーメッセージを送信するなどして、ユーザに対して一時鍵Ｄａを解除することができない、ひいてはＡＶＰを実行することができない旨の報知を行い、これによりＡＶＰシステム１００における一連の処理が終了となる。

自動車３００は、ステップＳ３０６において、運転計画Ｄｇおよび有効区間情報Ｄｄを照合し、運転計画Ｄｇに含まれる経路が走行可能範囲内にあるか否かを判定する。自動車３００は、運転計画Ｄｇに含まれる経路の全てが有効区間の範囲内、つまり走行可能範囲内にあると判定される場合には運転計画Ｄｇが利用可能であると判断し、ステップＳ３０７に進み、運転計画Ｄｇに従って自動運転制御を開始する。

自動車３００は、運転計画Ｄｇに含まれる経路の少なくとも一部が有効区間の範囲外、つまり走行可能範囲外にあると判定される場合には運転計画Ｄｇが利用不可能であると判断する。この場合、自動車３００は、端末装置２００に対してエラーメッセージを送信するなどして、ユーザに対して運転計画Ｄｇを利用することができない、ひいてはＡＶＰを実行することができない旨の報知を行い、これによりＡＶＰシステム１００における一連の処理が終了となる。

以上説明したように、本実施形態のＡＶＰシステム１００では、自動車３００のデジタル的な鍵である一時鍵の受け渡しが、ＯＥＭサーバ装置５００と自動車３００との間で直接行われるようになっており、一時鍵が駐車場サーバ装置４００に与えられることはない。そのため、仮に、駐車場サーバ装置４００が悪意のある第三者によりハッキングされるなどしても一時鍵が取得されることはなく、自動車３００のデジタル的な鍵の仕組みが読み取られるおそれもない。このように、本実施形態によれば、自動車３００のデジタル的な鍵の仕組みの機密性が高められることから、システムの安全性を高めることができるという優れた効果が得られる。

ＯＥＭサーバ装置５００は、一時鍵を生成する際、一時鍵を有効化するためのパスワードも生成するようになっている。また、自動車３００は、一時鍵およびパスワードを受信すると、運転計画に従って自動運転制御を実行するようになっている。つまり、この場合、一時鍵およびパスワードの両方が揃って初めて自動車３００の操作権限などが与えられることになる。そして、ＯＥＭサーバ装置５００は、自動車３００に対し、一時鍵を直接送信するとともに、それとは別に、駐車場サーバ装置４００を経由してパスワードを送信するようになっている。

このようにすれば、一時鍵およびパスワードの送信経路が異なることから、悪意のある第三者によるハッキングなどにより一時鍵およびパスワードの双方が取得される可能性を低く抑えることができる。そして、仮に、ハッキングされるなどして一時鍵およびパスワードの一方が取得されたとしても、自動車３００のデジタル的な鍵の仕組みが読み取られるおそれがなく、また、ハッキングした第三者に自動車３００の操作権限が与えられることもない。したがって、ユーザの意図に反して自動車３００が駐車場の外部に導かれて盗難されてしまうといった最悪の事態の発生を確実に防止することができる。

駐車場サーバ装置４００は、生成した運転計画とパスワードをセットにして自動車３００へ送信するようになっている。このようにすれば、自動車３００は、駐車場サーバ装置４００から送信されたパスワードで一時鍵を正常に解除できれば、そのパスワードと一緒に受信した運転計画についても真のもの、つまり駐車場サーバ装置４００から正式に送信されたものであると判断することができる。

言い換えると、このようにすれば、自動車３００は、例えばハッカーなどの悪意のある第三者から偽の運転計画が送信されたとしても、正しいパスワードが一緒についていないことから、その運転計画は偽物であり利用不可能であると判断することができる。したがって、本実施形態によれば、自動車３００は、悪意のある第三者により生成された問題のある運転計画（例えば、意図的に自動車３００を駐車場外へと導くようなものなど）が送信されたとしても、そのような問題のある運転計画に従って自動運転制御を実行することがないため、システムの安全性を良好に維持することができる。

本実施形態のＡＶＰシステム１００は、一時鍵Ｄａの有効区間に関する情報である有効区間情報Ｄｄを取得する有効区画情報検索部６０３を備える地図サーバ装置６００を備えている。有効区画情報検索部６０３は、ＯＥＭサーバ装置５００から送信された区間情報要求Ｄｉを受信すると、有効区間情報Ｄｄを取得し、その有効区間情報ＤｄをＯＥＭサーバ装置５００に送信する。

そして、自動車３００は、駐車場サーバ装置４００から送信された運転計画ＤｇとＯＥＭサーバ装置５００から送信された有効区間情報Ｄｄとを照合した結果をも考慮して運転計画Ｄｇが利用可能であるか否かを判断するようになっている。このような構成によれば、問題のある運転計画Ｄｇ（例えば、駐車場外へ出る軌道を含む計画など）に従って自動運転制御が実行される可能性を低く抑えることができ、その結果、システムの安全性が一層向上する。

（第２実施形態）
以下、第１実施形態に対し各装置の詳細構成が変更された第２実施形態について図５〜図７を参照して説明する。なお、後述する第３実施形態に対して同様の変更を加えることも可能である。
図５に示すように、本実施形態のＡＶＰシステム１２０の駐車場サーバ装置４００は、図２に示した第１実施形態の駐車場サーバ装置４００に対し、緊急停止部４０５が追加されている点などが異なる。

緊急停止部４０５は、駐車場内における自動車３００を含む全ての自動車の走行を緊急停止させるための緊急停止要求Ｄｊを生成し、データ送受信部４０１を介して各自動車に送信する。このような緊急停止要求Ｄｊは、例えば、災害発生時、歩行者の侵入が禁止されているエリアへの歩行者の侵入が検知されたとき、駐車場サーバ装置４００側の電源停止時など、正常にＡＶＰを実行することができなくなるような状況が発生したことをトリガとして生成される。

また、緊急停止部４０５は、緊急停止要求Ｄｊを送信した後、緊急停止に至った原因が解消されると、要求生成部４０３に対して一時鍵要求Ｄｈの再生成を指令する。詳細は後述するが、このように一時鍵要求Ｄｈが再生成されたことをトリガとして各種の処理が実行されることにより、自動車３００の緊急停止が解除されてＡＶＰが再開される。上述した通り、本実施形態では、緊急停止要求Ｄｊの生成および一時鍵要求Ｄｈの再生成の指令は、駐車場側のシステムが自動で判断するようになっているが、これらを、駐車場の管理人などが判断するようにしてもよい。

次に、上記構成の作用について説明する。
本実施形態のＡＶＰシステム１２０によりＡＶＰが実行される際、各部の具体的な処理内容は、例えば図６および図７に示すようなものとなる。
＜「自動運転開始」から「緊急停止実施」までの処理の流れ＞
自動運転開始から緊急停止実施までの処理は、図６に示すような内容の処理となる。図６に示すように、駐車場サーバ装置４００は、前述した各状況が発生したことをトリガとして、ステップＳ４０８において緊急停止要求Ｄｊを生成する。

駐車場サーバ装置４００は、ステップＳ４０９において、生成した緊急停止要求Ｄｊを自動車３００へ送信する。自動車３００は、ステップＳ３０７において運転計画Ｄｇに従った自動運転制御を開始した後、ステップＳ３０８において駐車場サーバ装置４００から送信された緊急停止要求Ｄｊを受信すると、ステップＳ３０９に進む。自動車３００は、ステップＳ３０９において、緊急停止の必要性を判定する。

自動車３００は、緊急停止の必要性があると判断すると、ステップＳ３１０に進み、緊急停止を実施する。この場合、自動車３００は、プリクラッシュセーフティシステムなどの前方に存在する障害物に衝突する前に自動でブレーキが作動する機能を有する。したがって、ＡＶＰ実施中の前方の自動車が急停車したとしても、その後方の自動車は、前方の自動車に衝突することはない。

＜「緊急停止実施」から「自動運転再開」までの処理の流れ＞
緊急停止実施〜自動運転再開までの処理は、図７に示すような内容の処理となる。図７に示すように、駐車場サーバ装置４００は、緊急停止要求Ｄｊを送信した後、ステップＳ４１０において、ＡＶＰの再開が可能であるか否かを判定する。駐車場サーバ装置４００は、緊急停止に至った原因が解消されておりＡＶＰの再開が可能であると判断すると、ステップＳ４１１に進み、一時鍵要求Ｄｈを再度生成する。

駐車場サーバ装置４００は、ステップＳ４１２において、一時鍵要求Ｄｈおよび暗号化されたままの車両情報Ｄｃを、ＯＥＭサーバ装置５００へ送信する。なお、端末装置２００から送信された車両情報Ｄｃは、出庫完了するまでの間、駐車場サーバ装置４００の記憶部４０２に記憶されている。そのため、ステップＳ４１２では、駐車場サーバ装置４００は、記憶部４０２に記憶されている車両情報Ｄｃを読み出したうえで、送信することになる。

ＯＥＭサーバ装置５００は、ステップＳ５１１において一時鍵要求Ｄｈおよび暗号化された車両情報Ｄｃを受信すると、ステップＳ５１２進み、車両情報Ｄｃの復号化を行う。ＯＥＭサーバ装置５００は、ステップＳ５１３において、一時鍵要求Ｄｈの真贋の検証を行う。なお、端末装置２００から送信された認証情報、つまり申込情報Ｄｂおよび車両情報Ｄｃは、入庫完了するまでの間、ＯＥＭサーバ装置５００の記憶部５０２に記憶されている。そのため、ステップＳ５１３では、ＯＥＭサーバ装置５００は、記憶部５０２に記憶された認証情報を読み出したうえで、一時鍵要求Ｄｈの真贋の検証を行うことになる。

ＯＥＭサーバ装置５００は、一時鍵要求Ｄｈが真正であると判断した場合にだけ、ステップＳ５１４以降の処理を実行する。なお、一時鍵要求Ｄｈが真正ではないと判断した場合の処理は第１実施形態で説明した処理と同様である。ＯＥＭサーバ装置５００は、ステップＳ５１４において、一時鍵ＤａおよびパスワードＤｆを生成する。なお、この場合、ＯＥＭサーバ装置５００は、自動車３００に対して有効区間情報Ｄｄを再送信する必要がないため、地図サーバ装置６００とのデータのやり取りは行わない。

ＯＥＭサーバ装置５００は、ステップＳ５１５において、一時鍵Ｄａを自動車３００へ送信する。また、ＯＥＭサーバ装置５００は、ステップＳ５１６において、パスワードＤｆを駐車場サーバ装置４００へ送信する。自動車３００は、ステップＳ３１０において緊急停止を実施した後、ステップＳ３１１において一時鍵Ｄａを受信すると、ステップＳ３１２に進み、運転計画要求Ｄｅを生成する。

自動車３００は、ステップＳ３１３において、運転計画要求Ｄｅを駐車場サーバ装置４００へ送信する。駐車場サーバ装置４００は、ステップＳ４１３においてパスワードＤｆを受信するとともに、ステップＳ４１４において運転計画要求Ｄｅを受信すると、ステップＳ４１５に進み、運転計画Ｄｇを生成する。駐車場サーバ装置４００は、ステップＳ４１６において、運転計画ＤｇおよびパスワードＤｆを自動車３００へ送信する。

自動車３００は、ステップＳ３１４において、運転計画ＤｇおよびパスワードＤｆを受信すると、ステップＳ３１５に進み、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効であるか否かを検証し、それらの組み合わせが有効であるという検証結果が得られた場合、パスワードＤｆを用いて一時鍵Ｄａを解除する。なお、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効ではないという検証結果が得られた場合の処理は第１実施形態で説明した処理と同様である。自動車３００は、ステップＳ３１６において、運転計画Ｄｇおよび有効区間情報Ｄｄを照合し、運転計画Ｄｇに含まれる経路が走行可能範囲内にあるか否かを判定する。

なお、ＯＥＭサーバ装置５００から送信された有効区間情報Ｄｄは、入庫完了するまでの間、自動車３００の記憶部３０２に記憶されている。そのため、ステップＳ３１６では、自動車３００は、記憶部３０２に記憶された有効区間情報Ｄｄを読み出したうえで、運転計画Ｄｇおよび有効区間情報Ｄｄの照合を行うことになる。自動車３００は、上記照合の結果、運転計画Ｄｇが利用可能であると判断すると、ステップＳ３１７に進み、運転計画Ｄｇに従って自動運転制御を再開する。なお、運転計画Ｄｇが利用不可能であると判断した場合の処理は第１実施形態で説明した処理と同様である。

以上説明した本実施形態によれば、次のような効果が得られる。
例えば、災害発生時、歩行者の侵入が禁止されているエリアへの歩行者の侵入が検知されたとき、駐車場サーバ装置４００側の電源停止時など、正常にＡＶＰを実行することができなくなるような状況が発生した場合、駐車場内の全ての自動車を直ちに停車させる必要がある。本実施形態では、このような状況が発生した場合、一時鍵ＤａおよびパスワードＤｆを用いた認証を行うことなく、駐車場サーバ装置４００から自動車３００に対して緊急停止要求Ｄｊが直接送信されるようになっているため、自動車３００を迅速に停車させることができる。

ただし、緊急停止に至った原因が解消されたことにより自動運転を再開する際、駐車場サーバ装置４００から自動車３００に対して緊急停止を解除して自動運転を再開してもよい旨を表す指令を直接送信すると、ハッキングされる危険性が生じる。そこで、本実施形態では、自動運転を再開する際には、最初に自動運転を開始する際に実行された各処理と同様、一時鍵ＤａおよびパスワードＤｆを用いた認証を行うようになっている。このようにすれば、自動運転を再開する際、悪意のある第三者によりハッキングされる可能性を低く抑えることができる。

ユーザは、端末装置２００を用いてＡＶＰを申し込んだ後、駐車場から離れる可能性が高い。そうすると、自動車３００の自動運転制御が開始された後は、自動車３００、駐車場サーバ装置４００およびＯＥＭサーバ装置５００は、端末装置２００との間での通信を行うことができない状態となる可能性が高い。そこで、自動車３００、駐車場サーバ装置４００およびＯＥＭサーバ装置５００は、端末装置２００から送信された各種の情報（申込情報Ｄｂ、車両情報Ｄｃなど）を記憶部３０２、４０２および５０２に保存するようになっている。

このようにすれば、緊急停止後の自動運転再開時、自動車３００、駐車場サーバ装置４００およびＯＥＭサーバ装置５００は、端末装置２００による各種の情報の再送信を必要とすることなく、最初に自動運転を開始する際に実行された各処理と同様の処理を実行することができる。なお、記憶部３０２、４０２および５０２に保存された各種の情報は、ＡＶＰのサービス（入庫または出庫）が完了するまでは保存されるが、そのサービスが完了した後、所定のタイミングで自動的に消去されるようになっている。これにより、申込情報Ｄｂや車両情報Ｄｃに含まれる個人情報などの漏洩を防止することができる。

（第３実施形態）
以下、第１実施形態に対し各装置の詳細構成が変更された第３実施形態について図８および図９を参照して説明する。
図８に示すように、本実施形態のＡＶＰシステム１３０の端末装置２００は、図２に示した第１実施形態の端末装置２００に対し、申込情報生成部２０３に代えて情報生成部２０５を備えている点、情報暗号化部２０４に代えて情報暗号化部２０６を備えている点などが異なる。

この場合、自動車３００は、レンタカー、シェアカーなどであり、端末装置２００を所持するユーザが所有するものではない。そのため、端末装置２００には、車両情報Ｄｃが記憶されていない。したがって、ユーザは、自動車３００を利用してＡＶＰを行う際、ＯＥＭサーバ装置５００に対し、自動車３００の一時所有権の認証情報を要求する必要がある。

そこで、情報生成部２０５は、申込情報生成部２０３と同様に申込情報Ｄｂを生成するとともに、一時所有権の認証情報Ｄｋの生成を要求する認証情報要求Ｄｌを生成する。情報生成部２０５は、生成した認証情報要求Ｄｌを、データ送受信部２０１を介してＯＥＭサーバ装置５００に送信する。情報暗号化部２０６は、データ送受信部２０１を介してＯＥＭサーバ装置５００から送信された一時所有権の認証情報Ｄｋを受信すると、その一時所有権の認証情報Ｄｋを暗号化する。

情報暗号化部２０６は、一時所有権の認証情報Ｄｋを暗号化する際、端末装置２００のユーザの情報も含めて暗号化するようになっている。情報暗号化部２０６は、暗号化した一時所有権の認証情報Ｄｋを、データ送受信部２０１を介して駐車場サーバ装置４００およびＯＥＭサーバ装置５００に送信する。なお、以下の説明では、一時所有権の認証情報Ｄｋのことを、認証情報Ｄｋと省略することがある。

この場合、駐車場サーバ装置４００に対する申込情報Ｄｂおよび認証情報Ｄｋの送信は、同時に行われる。また、この場合、ＯＥＭサーバ装置５００に対する申込情報Ｄｂおよび認証情報Ｄｋの送信は、同時に行われる。なお、以下の説明では、ＯＥＭサーバ装置５００に送信される申込情報Ｄｂおよび認証情報Ｄｋを、まとめて認証情報と呼ぶことがある。

本実施形態の駐車場サーバ装置４００は、図２に示した第１実施形態の駐車場サーバ装置４００に対し、要求生成部４０３に代えて要求生成部４０６を備えている点などが異なる。要求生成部４０６は、データ送受信部４０１を介して端末装置２００から送信された申込情報Ｄｂおよび認証情報Ｄｋを受信すると、一時鍵要求Ｄｈを生成するものであり、鍵要求生成部としての機能を有する。要求生成部４０６は、生成した一時鍵要求Ｄｈと、暗号化された認証情報Ｄｋとを、データ送受信部４０１を介してＯＥＭサーバ装置５００に送信する。

本実施形態のＯＥＭサーバ装置５００は、図２に示した第１実施形態のＯＥＭサーバ装置５００に対し、認証情報生成部５０７が追加されている点、復号部５０３に代えて復号部５０８を備えている点、検証部５０４に代えて検証部５０９を備えている点などが異なる。認証情報生成部５０７は、データ送受信部５０１を介して端末装置２００から送信された認証情報要求Ｄｌを受信すると、一時所有権の認証情報Ｄｋを生成する。

一時所有権の認証情報Ｄｋには、ＡＶＰを申し込んだユーザに対応するユーザＩＤと、そのユーザが自動車３００を利用することができる利用可能時間帯と、を紐付けたような情報、自動車３００の車両情報などが含まれている。また、一時所有権の認証情報Ｄｋは、例えば所定の有効期限を過ぎると、無効化されて使用不可能となるようになっている。認証情報生成部５０７は、生成した一時所有権の認証情報Ｄｋを、データ送受信部５０１を介して端末装置２００に送信する。

復号部５０８は、データ送受信部５０１を介して端末装置２００から送信される暗号化された認証情報Ｄｋを受信すると、その認証情報Ｄｋを復号化する。また、復号部５０８は、データ送受信部５０１を介して駐車場サーバ装置４００から送信される暗号化された認証情報Ｄｋを受信すると、その認証情報Ｄｋを復号化する。検証部５０９は、データ送受信部５０１を介して端末装置２００から送信される申込情報Ｄｂおよび認証情報Ｄｋを受信するとともに、データ送受信部５０１を介して駐車場サーバ装置４００から送信された一時鍵要求Ｄｈを受信すると、その一時鍵要求Ｄｈの真贋を検証するものであり、鍵要求検証部としての機能を有する。

具体的には、検証部５０９は、次のようにして端末装置２００および駐車場サーバ装置４００から送信された各情報を検証することにより一時鍵要求Ｄｈの真贋を検証する。すなわち、検証部５０９は、端末装置２００から送信された認証情報Ｄｋに含まれる車両情報と、駐車場サーバ装置４００から送信された認証情報Ｄｋに含まれる車両情報とが一致するか否かを判断する。

また、検証部５０９は、端末装置２００から送信された申込情報Ｄｂに含まれる申込先の駐車場と、一時鍵要求Ｄｈの送信元である駐車場サーバ装置４００が設けられた駐車場とが一致するか否か、つまり駐車場情報が一致するか否かを判断する。検証部５０９は、車両情報が一致するとともに駐車場情報が一致する場合には一時鍵要求Ｄｈが真正であると判断し、車両情報および駐車場情報の一方または双方が一致しない場合には一時鍵要求Ｄｈが真正ではないと判断する。

なお、認証情報Ｄｋは、元々はＯＥＭサーバ装置５００の認証情報生成部５０７により生成されたものであるため、検証部５０９は、その認証情報Ｄｋに含まれる車両情報を予め取得することができる。そこで、検証部５０９は、予め認証情報取得部５０７から取得した車両情報を含めて、車両情報の一致判断を行うようにしてもよい。この場合、検証部５０９は、３つの車両情報の全ての一致判定を行うようにしてもよいし、いずれか２つの車両情報の一致判定を行うようにしてもよい。

次に、上記構成の作用について説明する。
本実施形態のＡＶＰ申し込み〜走行可能範囲受信までの処理は、図９に示すような内容の処理となる。なお、一時鍵等生成〜自動運転開始までの処理は、図４に示した第１実施形態の処理と同様の処理となるため、説明を省略する。まず、ユーザの操作によりバレーパーキングが申し込まれると、端末装置２００は、ステップＳ２２１において、その申し込みの操作を認識し、その操作内容に応じて申込情報Ｄｂおよび認証情報要求Ｄｌを生成する。

端末装置２００は、ステップＳ２２２において、認証情報要求ＤｌをＯＥＭサーバ装置５００へ送信する。ＯＥＭサーバ装置５００は、ステップＳ５２１において認証情報要求Ｄｌを受信すると、ステップＳ５２２に進み、一時所有権の認証情報Ｄｋを生成する。ＯＥＭサーバ装置５００は、ステップＳ５２３において、一時所有権の認証情報Ｄｋを端末装置２００へ送信する。

端末装置２００は、ステップＳ２２３において一時所有権の認証情報Ｄｋを受信すると、ステップＳ２２４に進み、一時所有権の認証情報Ｄｋの暗号化を行う。端末装置２００は、ステップＳ２２５において、申込情報Ｄｂおよび暗号化された一時所有権の認証情報Ｄｋを、駐車場サーバ装置４００へ送信する。また、端末装置２００は、ステップＳ２２６において、申込情報Ｄｂおよび暗号化された一時所有権の認証情報Ｄｋ、つまりバレーパーキング申し込みの認証情報を、ＯＥＭサーバ装置５００へ送信する。

駐車場サーバ装置４００は、ステップＳ４２１において申込情報Ｄｂおよび暗号化された一時所有権の認証情報Ｄｋを受信すると、ステップＳ４２２に進み、一時鍵要求Ｄｈを生成する。駐車場サーバ装置４００は、ステップＳ４２３において、一時鍵要求Ｄｈおよび暗号化されたままの一時所有権の認証情報Ｄｋを、ＯＥＭサーバ装置５００へ送信する。本実施形態では、端末装置２００により暗号化された一時所有権の認証情報Ｄｋの復号化は、ＯＥＭサーバ装置５００にはできるが、駐車場サーバ装置４００にはできないようになっている。そのため、駐車場サーバ装置４００は、端末装置２００から送信された個人情報などが含まれる認証情報Ｄｋの内容を知ることはできない。

ＯＥＭサーバ装置５００は、ステップＳ５２４において一時鍵要求Ｄｈおよび暗号化された一時所有権の認証情報Ｄｋを受信するとともに、ステップＳ５２５において認証情報を受信すると、ステップＳ５２６に進み、認証情報Ｄｋの復号化を行う。ＯＥＭサーバ装置５００は、ステップＳ５２７において、一時鍵要求Ｄｈの真贋の検証を行う。ＯＥＭサーバ装置５００は、一時鍵要求Ｄｈが真正であると判断した場合にだけ、ステップＳ５０５以降の処理を実行する。

なお、一時鍵要求Ｄｈが真正ではないと判断した場合の処理は第１実施形態で説明した処理と同様である。また、ステップＳ５０５以降の処理、具体的には、ＯＥＭサーバ装置５００により実行される各処理（ステップＳ５０５〜Ｓ５０７）と、地図サーバ装置６００により実行される各処理（ステップＳ６０１〜Ｓ６０３）と、は、第１実施形態で説明した処理と同様の処理である。

以上説明したように、本実施形態では、自動車３００が端末装置２００を所持するユーザが所有するものではないレンタカーやシェアカーなどである場合を想定したシステムとなっている。このような場合でも、第１実施形態と同様、自動車３００のデジタル的な鍵である一時鍵の受け渡しが、ＯＥＭサーバ装置５００と自動車３００との間で直接行われるようになっており、一時鍵が駐車場サーバ装置４００に与えられることはない。したがって、本実施形態によっても、第１実施形態と同様の効果が得られる。

（第４実施形態）
以下、第１実施形態に対し各装置の詳細構成が変更された第４実施形態について図１０および図１１を参照して説明する。なお、第３実施形態に対して同様の変更を加えることも可能である。
図１０に示すように、本実施形態のＡＶＰシステム１４０の自動車３００は、図２に示した第１実施形態の自動車３００に対し、要求生成部３０３に代えて要求生成部３０７を備えている点、運転計画部３０８が追加されている点、自動運転制御部３０６に代えて自動運転制御部３０９を備えている点などが異なる。

要求生成部３０７は、データ送受信部３０１を介してＯＥＭサーバ装置５００から送信された一時鍵Ｄａおよび有効区間情報Ｄｄを受信すると、駐車目標位置の決定を要求する位置決定要求Ｄｍを生成する。要求生成部３０７は、生成した位置決定要求Ｄｍを、データ送受信部３０１を介して駐車場サーバ装置４００に送信する。運転計画部３０８は、データ送受信部３０１を介して駐車場サーバ装置４００から送信された目標位置情報Ｄｎを受信するとともに、復号部３０４による検証結果として一時鍵ＤａおよびパスワードＤｆの組み合わせが有効であるという結果が得られた場合、その目標位置情報Ｄｎに基づいて運転計画Ｄｇを生成する。なお、駐車場サーバ装置４００による目標位置情報Ｄｎの送信については後述する。

この場合、運転計画部３０８は、ＯＥＭサーバ装置５００から送信された有効区間情報Ｄｄを受信すると、その有効区間情報Ｄｄをも考慮して運転計画Ｄｇを生成する。運転計画部３０８は、生成した運転計画Ｄｇを、データ送受信部３０１を介して駐車場サーバ装置４００に送信する。また、運転計画部３０８は、データ送受信部３０１を介して駐車場サーバ装置４００から送信された修正情報Ｄｏおよび利用不可情報Ｄｐを受信すると、その修正情報Ｄｏに基づいて運転計画Ｄｇを再度生成する。なお、駐車場サーバ装置４００による修正情報Ｄｏおよび利用不可情報Ｄｐの送信については後述する。運転計画部３０８は、運転計画Ｄｇを再度生成した場合も、その運転計画Ｄｇを、データ送受信部３０１を介して駐車場サーバ装置４００に送信する。

自動運転制御部３０９は、データ送受信部３０１を介して駐車場サーバ装置４００から送信された利用可能情報Ｄｑを受信すると、運転計画部３０８により生成された運転計画Ｄｇに従って自動運転制御を実行する。なお、駐車場サーバ装置４００による利用可能情報Ｄｏの送信については後述する。

本実施形態の駐車場サーバ装置４００は、図２に示した第１実施形態の駐車場サーバ装置４００に対し、運転計画部４０４が省かれている点、駐車位置決定部４０７および運転計画検証部４０８が追加されている点などが異なる。駐車位置決定部４０７は、データ送受信部４０１を介してＯＥＭサーバ装置５００から送信されたパスワードＤｆを受信するとともに自動車３００から送信された位置決定要求Ｄｍを受信すると、自動車３００の駐車目標位置を決定する。

駐車位置決定部４０７は、決定した駐車目標位置に関する情報である目標位置情報ＤｎとともにパスワードＤｆを、データ送受信部４０１を介して自動車３００に送信する。駐車位置決定部４０７により実行される各処理は、駐車位置決定手順に相当する。目標位置情報Ｄｎには、例えば指定した駐車枠などを表す駐車目標位置に加え、駐車場の地図情報が含まれている。

運転計画検証部４０８は、データ送受信部４０１を介して自動車３００から送信された運転計画Ｄｇを受信すると、その運転計画Ｄｇに問題があるか否かを検証するものであり、計画検証部に相当する。運転計画検証部４０８は、運転計画Ｄｇに問題がない場合、運転計画Ｄｇが利用可能であることを表す利用可能情報Ｄｑを、データ送受信部４０１を介して自動車３００に送信する。

運転計画検証部４０８は、運転計画Ｄｇに問題がある場合、運転計画Ｄｇの修正に関する情報である修正情報Ｄｏを生成する。そして、運転計画検証部４０８は、その修正情報Ｄｏおよび運転計画Ｄｇが利用不可であることを表す利用不可情報Ｄｐを、データ送受信部４０１を介して自動車３００に送信する。なお、運転計画検証部４０８により実行される各処理は、計画検証手順に相当する。

運転計画検証部４０８による運転計画Ｄｇの具体的な検証手法としては、例えば以下のような手法を採用することができる。すなわち、運転計画検証部４０８は、自動車３００が駐車場の外部に導かれることがない計画であるという第１条件を満たす場合に運転計画Ｄｇに問題がないと判断するようになっている。このような第１条件を満たす運転計画Ｄｇであれば、例えば悪意のある第三者によるハッキングなどによってユーザの意図に反して自動車３００が駐車場の外部に導かれて盗難されてしまうといった最悪の事態の発生を防止することができる。

また、運転計画検証部４０８は、上記第１条件に加え、正しい目標位置までの計画であるという第２条件をも満たす場合に運転計画Ｄｇに問題がないと判断するようにしてもよい。具体的には、第２条件としては、運転計画Ｄｇにおける自動車３００の目標位置と目標位置情報Ｄｎが表す駐車目標位置との誤差が所定の閾値誤差未満であるという条件とすることができる。なお、閾値誤差は、駐車場サーバ装置４００の各種性能に応じた値に設定することができる。このような第２条件を満たす運転計画Ｄｇであれば、駐車場サーバ装置４００による駐車枠の管理への悪影響を防止することができる。

さらに、運転計画検証部４０８は、上記第１条件に加え、または、上記第１条件および第２条件に加え、運転計画Ｄｇにおける自動車３００の走行方向が駐車場内の指定走行方向に従った方向となっているという第３条件をも満たす場合に運転計画Ｄｇに問題がないと判断するようにしてもよい。駐車場内においては、複数の自動車が同じ時間帯に走行している可能性が高い。このような前提において、自動車３００が指定走行方向に従わずに走行すると、逆走などとなってしまい、安全性が低下する。上記した第３条件を満たす運転計画Ｄｇであれば、このような逆走などによる安全性の低下を抑制することができる。

第３条件において、走行方向と指定走行方向の一致の判断は、大まかな方向が一致していればよいとすることもできるが、詳細な方向、つまり自動車３００の走行の軌道が問題無い軌道になっているかどうかを判断するようにしてもよい。すなわち、運転計画検証部４０８は、運転計画Ｄｇによる自動車３００の走行の軌道が、駐車場内の柱や駐車中の他の自動車に衝突することが無い軌道になっている場合に運転計画Ｄｇに問題がないと判断するようにしてもよい。ただし、このような判断は、駐車場サーバ装置４００の各種の性能に応じて適宜実施すればよい。

運転計画検証部４０８による修正情報Ｄｏの具体的な生成手法としては、例えば以下の２つの手法のうちいずれかを採用することができる。まず、第１生成手法は、修正情報Ｄｏとして、運転計画Ｄｇの一部をこのように直すと良いといった具体的な指示を生成する手法である。具体的には、第１生成手法は、運転計画Ｄｇにおいて問題のある箇所と、その問題の解消方法と、を対応付けた情報を修正情報Ｄｏとして生成する手法とすることができる。このような第１生成手法によれば、自動車３００側では、問題箇所および問題の解消方法を把握したうえで運転計画Ｄｇを再生成することができるようになる。そのため、第１生成手法によれば、少ない修正回数で問題の無い運転計画Ｄｇを再生成することができ、自動車３００側での処理負荷を軽減することができる。

第２生成手法は、修正情報Ｄｏとして、運転計画Ｄｇに問題があるので最初から計画をやり直すように指示する旨の情報を生成する手法である。このような第２生成手法によれば、駐車場サーバ装置４００側では、問題の解消方法などを作成する必要がないことから、その処理負荷を軽減することができる。なお、運転計画Ｄｇの作成手法、つまりアルゴリズムにもよるが、同じ目標位置へと向かう運転計画Ｄｇを作成する場合であっても、毎回同じ経路などが求められるとは限らず、毎回異なる経路などが求められる可能性が高い。

したがって、単純に、最初から計画をやり直しただけであっても、問題箇所が解消される可能性がある。また、最初に生じた問題がバグに起因するものであった場合、計画を再度生成することにより、そのバグが解消されることも考えられ、そうすると、問題の無い運転計画Ｄｇが作成される可能性がある。このようなことから、第２生成手法により生成された修正情報Ｄｏに基づいて運転計画Ｄｇが再生成された場合であっても、やがては問題の無い運転計画が生成されることになる。

次に、上記構成の作用について説明する。
本実施形態の一時鍵等生成〜自動運転開始までの処理は、図１０に示すような内容の処理となる。なお、ＡＶＰ申し込み〜走行可能範囲受信までの処理は、図３に示した第１実施形態の処理と同様の処理となるため、説明を省略する。

図１０に示す処理においても、ＯＥＭサーバ装置５００により実行されるステップＳ５０８〜Ｓ５１０の処理、駐車場サーバ装置４００により実行されるステップＳ４０４の処理および自動車３００により実行されるステップＳ３０１の処理は、図４に示した第１実施形態の処理と同様の処理となるため、説明を省略する。この場合、自動車３００は、ステップＳ３０１において一時鍵Ｄａおよび有効区間情報Ｄｄを受信すると、ステップＳ３２１に進み、位置決定要求Ｄｍを生成する。自動車３００は、ステップＳ３２２において、位置決定要求Ｄｍを駐車場サーバ装置４００へ送信する。

駐車場サーバ装置４００は、ステップＳ４０４においてパスワードＤｆを受信するとともに、ステップＳ４３１において位置決定要求Ｄｍを受信すると、ステップＳ４３２に進み、自動車３００の駐車目標位置を決定する。駐車場サーバ装置４００は、ステップＳ４３３において、決定した駐車目標位置に関する情報である目標位置情報ＤｎおよびパスワードＤｆを自動車３００へ送信する。

自動車３００は、ステップＳ３２３において、目標位置情報ＤｎおよびパスワードＤｆを受信すると、ステップＳ３２４に進み、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効であるか否かを検証し、それらの組み合わせが有効であるという検証結果が得られた場合、パスワードＤｆを用いて一時鍵Ｄａを解除する。なお、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効ではないという検証結果が得られた場合の処理は第１実施形態で説明した処理と同様である。

自動車３００は、ステップＳ３２５において、有効区間情報Ｄｄ、つまり自動車３００の走行可能範囲を考慮して運転計画Ｄｇを生成する。自動車３００は、ステップＳ３２６において、生成した運転計画Ｄｇを駐車場サーバ装置４００へ送信する。駐車場サーバ装置４００は、ステップＳ４３４において運転計画Ｄｇを受信すると、ステップＳ４３５に進み、運転計画Ｄｇに問題があるか否かを検証する。駐車場サーバ装置４００は、ステップＳ４３６において、運転計画Ｄｇの検証結果に関する情報を自動車３００へ送信する。

駐車場サーバ装置４００は、運転計画Ｄｇに問題がないという検証結果が得られた場合、ステップＳ４３６において利用可能情報Ｄｑを自動車３００へ送信する。駐車場サーバ装置４００は、運転計画Ｄｇに問題があるという検証結果が得られた場合、ステップＳ４３６において、修正情報Ｄｏおよび利用不可情報Ｄｐを自動車３００へ送信する。自動車３００は、ステップＳ３２７において利用可能情報Ｄｑまたは修正情報Ｄｏおよび利用不可情報Ｄｐを受信すると、ステップＳ３２８に進む。

自動車３００は、ステップＳ３２８において、駐車場サーバ装置４００で実行された運転計画Ｄｇの検証結果を判定する。自動車３００は、利用可能情報Ｄｑを受信した場合には運転計画Ｄｇに問題がないと判断し、利用不可情報Ｄｐを受信した場合には運転計画Ｄｇに問題があると判断する。自動車３００は、運転計画Ｄｇに問題がないと判断すると、ステップＳ３２９に進み、運転計画Ｄｇに従って自動運転制御を開始する。自動車３００は、運転計画Ｄｇに問題があると判断すると、ステップＳ３２５に戻り、運転計画Ｄｇを再生成する。

以上説明したように、本実施形態では、自動車３００側を主体として構築されるシステムとなっており、自動車３００が備える運転計画部３０８によって運転計画が生成されている。このような場合でも、駐車場側を主体として構築される第１実施形態と同様、自動車３００のデジタル的な鍵である一時鍵の受け渡しが、ＯＥＭサーバ装置５００と自動車３００との間で直接行われるようになっており、一時鍵が駐車場サーバ装置４００に与えられることはない。したがって、本実施形態によっても、第１実施形態と同様の効果が得られる。

また、この場合、駐車場サーバ装置４００が備える運転計画検証部４０８が、自動車３００が備える運転計画部３０８により生成される運転計画に問題があるか否かを検証するようになっている。すなわち、本実施形態では、自動車３００側で生成された運転計画の妥当性が駐車場に設けられる駐車場サーバ装置４００によって検証されるようになっており、それにより、その運転計画の安全が保証されている。

（第５実施形態）
以下、第４実施形態に対し各装置の詳細構成が変更された第５実施形態について図１２および図１３を参照して説明する。
図１２に示すように、本実施形態のＡＶＰシステム１５０の駐車場サーバ装置４００は、図１０に示した第４実施形態の駐車場サーバ装置４００に対し、第２実施形態において説明した緊急停止部４０５が追加されている点などが異なる。

次に、上記構成の作用について説明する。
本実施形態の緊急停止実施〜自動運転再開までの処理は、図１３に示すような内容の処理となる。なお、本実施形態の自動運転開始から緊急停止実施までの処理は、図６に示した第２実施形態の処理と同様の処理となるため、説明を省略する。

図１３に示す処理においても、ＯＥＭサーバ装置５００により実行されるステップＳ５１１〜Ｓ５１６の処理、駐車場サーバ装置４００により実行されるステップＳ４１０〜Ｓ４１３の処理および自動車３００により実行されるステップＳ３１０、Ｓ３１１の処理は、図７に示した第２実施形態の処理と同様の処理となるため、説明を省略する。この場合、自動車３００は、ステップＳ３１０において緊急停止を実施した後、ステップＳ３３１において一時鍵Ｄａを受信すると、ステップＳ３３２に進み、位置決定要求Ｄｍを生成する。自動車３００は、ステップＳ３３３において、位置決定要求Ｄｍを駐車場サーバ装置４００へ送信する。

駐車場サーバ装置４００は、ステップＳ４０４においてパスワードＤｆを受信するとともに、ステップＳ４４１において位置決定要求Ｄｍを受信すると、ステップＳ４４２に進み、自動車３００の駐車目標位置を決定する。駐車場サーバ装置４００は、ステップＳ４４３において、決定した駐車目標位置に関する情報である目標位置情報ＤｎおよびパスワードＤｆを自動車３００へ送信する。

自動車３００は、ステップＳ３３４において、目標位置情報ＤｎおよびパスワードＤｆを受信すると、ステップＳ３３５に進み、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効であるか否かを検証し、それらの組み合わせが有効であるという検証結果が得られた場合、パスワードＤｆを用いて一時鍵Ｄａを解除する。なお、一時鍵ＤａおよびパスワードＤｆの組み合わせが有効ではないという検証結果が得られた場合の処理は第１実施形態で説明した処理と同様である。

自動車３００は、ステップＳ３３６において、有効区間情報Ｄｄ、つまり自動車３００の走行可能範囲を考慮して運転計画Ｄｇを生成する。なお、ＯＥＭサーバ装置５００から送信された有効区間情報Ｄｄは、入庫完了するまでの間、自動車３００の記憶部３０２に記憶されている。そのため、ステップＳ３３６では、自動車３００は、記憶部３０２に記憶された有効区間情報Ｄｄを読み出したうえで、運転計画Ｄｇの生成を行うことになる。自動車３００は、ステップＳ３３７において、生成した運転計画Ｄｇを駐車場サーバ装置４００へ送信する。

駐車場サーバ装置４００は、ステップＳ４４４において運転計画Ｄｇを受信すると、ステップＳ４４５に進む。ステップＳ４４５と、それ以降に実行される各処理、具体的には、駐車場サーバ装置４００により実行されるステップＳ４４４〜Ｓ４４６の処理および自動車３００により実行されるステップＳ３３８〜ステップＳ３４０の処理は、図１１に示した第４実施形態のステップＳ４３４〜Ｓ４３６およびＳ３３８〜Ｓ３４０の処理と同様である。

以上説明したように、自動車３００側を主体として構築される本実施形態によっても、駐車場側を主体として構築される第２実施形態と同様、正常にＡＶＰを実行することができなくなるような状況が発生した場合、一時鍵ＤａおよびパスワードＤｆを用いた認証を行うことなく、駐車場サーバ装置４００から自動車３００に対して緊急停止要求Ｄｊが直接送信されるようになっているため、自動車３００を迅速に停車させることができる。

また、本実施形態では、第２実施形態と同様、自動運転を再開する際には、一時鍵ＤａおよびパスワードＤｆを用いた認証を行うようになっているため、自動運転を再開する際、悪意のある第三者によりハッキングされる可能性を低く抑えることができる。このように、本実施形態によっても、第２実施形態と同様の効果が得られる。

（第６実施形態）
以下、第１実施形態に対してＡＶＰが実行される際の処理内容が変更された第６実施形態について図１４を参照して説明する。なお、第２〜第５実施形態に対して同様の変更を加えることも可能である。

上記各実施形態では、ユーザが駐車場に到着してからその場でＡＶＰを申し込むような状況、いわゆるオンデマンドでの申し込みを想定した処理内容となっていたが、ＡＶＰシステム１００などは、ユーザがＡＶＰを事前に予約する状況にも対応することができる。なお、以下の説明では、オンデマンドでの申し込みのことを到着後申し込みと呼び、事前の予約による申し込みのことを事前予約申し込みと呼ぶこととする。

この場合、端末装置２００からＯＥＭサーバ装置５００などへ送信される申込情報Ｄｂには、バレーパーキングの実行時間が含まれている。バレーパーキングの実行時間は、到着後申し込みであれば現在時刻となり、事前予約申し込みであればユーザが指定した予定時刻となるものであり、ユーザの申し込み操作に応じて入力される。なお、予定時刻は、入庫の場合にはバレーパーキングの開始時刻、つまり自動車３００が所定の降車場所から発車する時刻となり、出庫の場合にはバレーパーキングの完了時刻、つまり自動車３００が所定の乗車場所に到着して停車する時刻となる。

申し込み情報Ｄｂに上記したような情報が含まれていることから、本実施形態では、申込情報Ｄｂの内容に基づいて、申し込まれたバレーパーキングが、到着後申し込みであるのか、あるいは、事前予約申し込みであるのか、が分かるようになっている。ＯＥＭサーバ装置５００は、情報検証の処理、具体的には、一時鍵要求Ｄｈの真贋を検証するステップＳ５０４の処理が完了すると、次のステップ、つまり区間情報要求Ｄｉを生成するステップＳ５０５の開始時間を判断するようになっている。

到着後申し込みである場合、自動車３００が既に駐車場に到着していることから直ちにバレーパーキングを実行可能であると考えられる。そのため、ＯＥＭサーバ装置５００は、到着後申し込みである場合、情報検証の処理が完了し次第、次のステップへ進む。一方、事前予約申し込みである場合、自動車３００が未だ駐車場に到着していないことからその時点ではバレーパーキングの実行は不可能であると考えられる。そのため、ＯＥＭサーバ装置５００は、事前予約申し込みである場合、ユーザにより指定されたバレーパーキングの予定時刻まで処理を進めることなく待機する。

また、事前予約申し込みで入庫する場合、自動車３００が予定時刻までに駐車場に到着しているかどうかの確認が必要となる。この場合、事前予約申し込みをしたユーザが端末装置２００に対して所定の操作をすることにより、駐車場への到着を確認するようにしている。なお、自動車３００の駐車場への到着の確認としては、駐車場に設けられる入力受付装置によりユーザが予約番号などを入力する方法、自動車３００が駐車場の入場ゲートを通過する際に駐車場サーバ装置４００との間で通信を行うことにより確認する方法など、様々な方法を採用することができる。

一方、事前予約申し込みで出庫する場合、入庫のような確認が必要ないため、ユーザが指定した予定時刻に自動車３００が所定の乗車場所に到着するように処理が進められることになる。この場合、次のステップが実行されるタイミングとしては、予定時刻から自動車３００が駐車枠から乗車場所まで移動するのに要する所要時間を減算した時刻となる。なお、所要時間は、自動車３００がエンジンを始動するのに必要な時間と、自動車３００が発車するための準備に必要な時間と、実際の移動時間と、を加えた時間とすることができる。

例えば、ユーザが指定した予約時刻が「午前１０時３０分」であり、所要時間が「３分」であるとすると、ＯＥＭサーバ装置５００は、「午前１０時２７分」に次のステップを実行することになる。このようにすれば、事前予約で出庫を申し込んだユーザが所定の乗車場所で自動車３００の到着を待つことがなくなる、つまりユーザに待ち時間が発生しなくなるため、その利便性が向上する。

このような本実施形態による各処理のうち、ＡＶＰ申し込み〜走行可能範囲受信までの具体的な処理内容は、図１４に示すような内容となる。本実施形態の処理では、第１実施形態の同処理に対し、端末装置２００により実行されるステップＳ２３１、Ｓ２３２の処理と、ＯＥＭサーバ装置５００により実行されるステップＳ５３１〜Ｓ５３３の処理が追加されている。

この場合、ＯＥＭサーバ装置５００は、ステップＳ５０４において一時鍵要求Ｄｈが真正であると判断すると、ステップＳ５３１に進み、前述した次のステップに相当するステップＳ５０５の処理の開始時間を判断する。すなわち、ＯＥＭサーバ装置５００は、ステップＳ５３１において、申込情報Ｄｂに基づいて事前予約申し込みであるか否かを判断する。ＯＥＭサーバ装置５００は、事前予約申し込みではない、つまり到着後申し込みであると判断すると、ステップＳ５３１で「ＮＯ」となり、ステップＳ５０５に進み、その後は、第１実施形態と同様の処理が行われる。この場合、ユーザは既に駐車場に到着しているため、以降の処理が完了し次第、速やかにバレーパーキングが実行される。

これに対し、ＯＥＭサーバ装置５００は、事前予約申し込みであると判断すると、ステップＳ５３１で「ＹＥＳ」となり、ステップＳ５３２に進み、ユーザにより指定された予定時刻まで待機する。その後、ユーザが駐車場に到着したことにより所定の開始操作が行われると、操作端末２００は、ステップＳ２３１において、その開始操作を認識し、ステップＳ２３２に進む。

端末装置２００は、ステップＳ２３２において、バレーパーキングの開始を要求する開始要求ＤｒをＯＥＭサーバ装置５００へ送信する。ＯＥＭサーバ装置５００は、ステップＳ５３３において開始要求Ｄｒを受信すると、ステップＳ５０５に進み、その後は、第１実施形態と同様の処理が行われる。なお、到着後申し込みである場合、または、事前予約申し込みの出庫である場合、端末装置２００におけるステップＳ２３１、Ｓ２３２の処理およびＯＥＭサーバ装置５００におけるステップＳ５３３の処理が不要となる。

以上説明したように、本実施形態では、ユーザがＡＶＰを事前に予約する状況を想定したシステムとなっている。このような場合でも、第１実施形態と同様、自動車３００のデジタル的な鍵である一時鍵の受け渡しが、ＯＥＭサーバ装置５００と自動車３００との間で直接行われるようになっており、一時鍵が駐車場サーバ装置４００に与えられることはない。したがって、本実施形態によっても、第１実施形態と同様の効果が得られる。

（その他の実施形態）
なお、本発明は上記し且つ図面に記載した各実施形態に限定されるものではなく、その要旨を逸脱しない範囲で任意に変形、組み合わせ、あるいは拡張することができる。
上記各実施形態で示した数値などは例示であり、それに限定されるものではない。
上記各実施形態では、一時鍵ＤａおよびパスワードＤｆを用いた認証を行うようになっていたが、一時鍵Ｄａだけを用いて認証を行うようにしてもよい。

上記各実施形態で説明したように、運転計画部３０８、４０４は、地図サーバ装置６００から与えられる駐車場の周辺地図情報、駐車場と外部との区画を表す情報などの有効区間情報Ｄｄがあれば、自動車３００が駐車場の外部に出ることが無い運転計画Ｄｇを確実に生成することができる。ただし、ＡＶＰシステムとしては、地図サーバ装置６００を省いた構成としてもよい。このような構成であっても、運転計画部３０８、４０４は、駐車場サーバ装置４００に元々記憶されている駐車場内の地図情報に基づいて、自動車３００が駐車場の外部に出ることが無い運転計画Ｄｇを生成することができる。

本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリーを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリーと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

１００、１２０、１３０、１４０、１５０…ＡＶＰシステム、２００…端末装置、２０３…申込情報生成部、２０５…情報生成部、３００…自動車、３０４…復号部、３０６、３０９…自動運転制御部、３０８…運転計画部、４００…駐車場サーバ装置、４０３、４０６…要求生成部、４０４…運転計画部、４０７…駐車位置決定部、４０８…運転計画検証部、５００…ＯＥＭサーバ装置、５０４、５０９…検証部、５０５…要求生成部、５０６…一時鍵生成部、６００…地図サーバ装置、６０３…有効区画情報検索部。

Claims (8)

1. それぞれの間で互いにデータの送受信が可能に構成された端末装置（２００）、車両（３００）、駐車場に設けられる駐車場サーバ装置（４００）および車両の製造者により直接的または間接的に管理されるＯＥＭサーバ装置（５００）を含み、自動運転制御によるバレーパーキングを実行する自動バレーパーキングシステムであって、
   前記端末装置は、申込情報生成部（２０３、２０５）を備え、
   前記駐車場サーバ装置は、鍵要求生成部（４０３、４０６）を備え、
   前記ＯＥＭサーバ装置は、鍵要求検証部（５０４、５０９）および一時鍵生成部（５０６）を備え、
   前記駐車場サーバ装置または前記車両は、運転計画部（３０８、４０４）を備え、
   前記車両は、自動運転制御部（３０６、３０９）を備え、
   前記申込情報生成部は、前記バレーパーキングの申し込みに関する情報である申込情報を生成し、その申込情報を前記駐車場サーバ装置および前記ＯＥＭサーバ装置に送信し、
   前記鍵要求生成部は、前記端末装置から送信される前記申込情報を受信すると、一時鍵の生成を要求する一時鍵要求を生成し、その一時鍵要求を前記ＯＥＭサーバ装置に送信し、
   前記鍵要求検証部は、前記端末装置から送信される前記申込情報を受信するとともに前記駐車場サーバ装置から送信された前記一時鍵要求を受信すると、その一時鍵要求の真贋を検証し、
   前記一時鍵生成部は、前記鍵要求検証部による検証結果が真である場合に前記一時鍵を生成し、その一時鍵を前記車両に送信し、
   前記運転計画部は、前記車両の駐車目標位置までの経路が含まれる運転計画を生成し、
   前記自動運転制御部は、前記ＯＥＭサーバ装置から送信された前記一時鍵を受信すると、前記運転計画部により生成された前記運転計画に従って自動運転制御を実行する、
   自動バレーパーキングシステム。
2. 前記一時鍵生成部は、前記一時鍵を生成する際、前記一時鍵を有効化するためのパスワードも生成し、そのパスワードを、前記駐車場サーバ装置を経由して前記車両に送信し、
   前記自動運転制御部は、前記ＯＥＭサーバ装置から送信された前記一時鍵を受信するとともに前記駐車場サーバ装置から送信された前記パスワードを受信すると、前記運転計画部により生成された前記運転計画に従って自動運転制御を実行する、
   請求項１に記載の自動バレーパーキングシステム。
3. 前記運転計画部（４０４）は、前記駐車場サーバ装置に設けられており、
   前記車両は、さらに、鍵検証部（３０４）を備え、
   前記運転計画部は、前記ＯＥＭサーバ装置から送信された前記パスワードを受信すると、生成した前記運転計画とともに前記パスワードを前記車両に送信し、
   前記鍵検証部は、前記ＯＥＭサーバ装置から送信された前記一時鍵を受信するとともに前記駐車場サーバ装置から送信された前記パスワードを受信すると、それらの組み合わせが有効であるか否かを検証し、
   前記自動運転制御部は、前記鍵検証部による検証結果として前記組み合わせが有効であるという結果が得られた場合、前記パスワードとともに送信された前記運転計画が利用可能であると判断し、その運転計画に従って自動運転制御を実行する、
   請求項２に記載の自動バレーパーキングシステム。
4. 前記運転計画部（３０８）は、前記車両に設けられており、
   前記駐車場サーバ装置は、さらに、駐車位置決定部（４０７）および計画検証部（４０８）を備え、
   前記車両は、さらに、鍵検証部（３０４）を備え、
   前記駐車位置決定部は、前記ＯＥＭサーバ装置から送信された前記パスワードを受信すると、前記駐車目標位置を決定し、その決定した駐車目標位置に関する情報である目標位置情報とともに前記パスワードを前記車両に送信し、
   前記鍵検証部は、前記ＯＥＭサーバ装置から送信された前記一時鍵を受信するとともに前記駐車場サーバ装置から送信された前記パスワードを受信すると、それらの組み合わせが有効であるか否かを検証し、
   前記運転計画部は、前記鍵検証部による検証結果として前記組み合わせが有効であるという結果が得られた場合、前記目標位置情報に基づいて前記運転計画を生成し、その運転計画を前記駐車場サーバ装置に送信し、
   前記計画検証部は、前記車両から送信された前記運転計画を受信すると、その運転計画に問題があるか否かを検証し、前記運転計画に問題がない場合に前記運転計画が利用可能であることを表す利用可能情報を前記車両に送信し、
   前記自動運転制御部は、前記駐車場サーバ装置から送信された前記利用可能情報を受信すると、前記運転計画部により生成された前記運転計画に従って自動運転制御を実行する、
   請求項２に記載の自動バレーパーキングシステム。
5. さらに、前記一時鍵の有効区間に関する情報である有効区間情報を取得する有効区間取得部（６０３）を備える地図サーバ装置（６００）を備え、
   前記ＯＥＭサーバ装置は、さらに、区間要求生成部（５０５）を備え、
   前記区間要求生成部は、前記有効区間情報の送信を要求する区間情報要求を生成し、その区間情報要求を前記地図サーバ装置に送信し、
   前記有効区間取得部は、前記ＯＥＭサーバ装置から送信された前記区間情報要求を受信すると、前記有効区間情報を取得し、その有効区間情報を前記ＯＥＭサーバ装置に送信し、
   前記一時鍵生成部は、前記一時鍵とともに前記有効区間情報を前記車両に送信し、
   前記自動運転制御部は、前記駐車場サーバ装置から送信された前記運転計画と前記ＯＥＭサーバ装置から送信された前記有効区間情報とを照合した結果をも考慮して前記運転計画が利用可能であるか否かを判断する、
   請求項３に記載の自動バレーパーキングシステム。
6. さらに、前記一時鍵の有効区間に関する情報である有効区間情報を取得する有効区間取得部を備える地図サーバ装置を備え、
   前記ＯＥＭサーバ装置は、さらに、区間要求生成部を備え、
   前記区間要求生成部は、前記有効区間情報の送信を要求する区間情報要求を生成し、その区間情報要求を前記地図サーバ装置に送信し、
   前記有効区間取得部は、前記ＯＥＭサーバ装置から送信された前記区間情報要求を受信すると、前記有効区間情報を取得し、その有効区間情報を前記ＯＥＭサーバ装置に送信し、
   前記一時鍵生成部は、前記一時鍵とともに前記有効区間情報を前記車両に送信し、
   前記運転計画部は、前記ＯＥＭサーバ装置から送信された前記有効区間情報を受信すると、その有効区間情報をも考慮して前記運転計画を生成する、
   請求項４に記載の自動バレーパーキングシステム。
7. それぞれの間で互いにデータの送受信が可能に構成された端末装置（２００）、車両（３００）、駐車場に設けられる駐車場サーバ装置（４００）および車両の製造者により直接的または間接的に管理されるＯＥＭサーバ装置（５００）に実行させることにより自動運転制御によるバレーパーキングを実現する自動バレーパーキングプログラムであって、
   前記端末装置に、申込情報生成手順を実行させ、
   前記駐車場サーバ装置に、鍵要求生成手順を実行させ、
   前記ＯＥＭサーバ装置に、鍵要求検証手順および一時鍵生成手順を実行させ、
   前記駐車場サーバ装置または前記車両に、運転計画手順を実行させ、
   前記車両に、自動運転制御手順を実行させ、
   前記申込情報生成手順では、前記バレーパーキングの申し込みに関する情報である申込情報を生成し、その申込情報を前記駐車場サーバ装置および前記ＯＥＭサーバ装置に送信し、
   前記鍵要求生成手順では、前記端末装置から送信される前記申込情報を受信すると、一時鍵の生成を要求する一時鍵要求を生成し、その一時鍵要求を前記ＯＥＭサーバ装置に送信し、
   前記鍵要求検証手順では、前記端末装置から送信される前記申込情報を受信するとともに前記駐車場サーバ装置から送信された前記一時鍵要求を受信すると、その一時鍵要求の真贋を検証し、
   前記一時鍵生成手順では、前記鍵要求検証部による検証結果が真である場合に前記一時鍵を生成し、その一時鍵を前記車両に送信し、
   前記運転計画手順では、前記車両の駐車目標位置までの経路が含まれる運転計画を生成し、
   前記自動運転制御手順では、前記ＯＥＭサーバ装置から送信された前記一時鍵を受信すると、前記運転計画部により生成された前記運転計画に従って自動運転制御を実行する、
   自動バレーパーキングプログラム。
8. 請求項７に記載の自動バレーパーキングプログラムを記憶する、
   コンピュータ読み取り可能な非一時的な記憶媒体。

Images