特許 5886671 駐車場満空判定装置、判定方法およびそのためのプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5886671

(24)【登録日】2016年2月19日

(45)【発行日】2016年3月16日

(54)【発明の名称】駐車場満空判定装置、判定方法およびそのためのプログラム

(51)【国際特許分類】

   G08G 1/14 20060101AFI20160303BHJP

   G08G 1/13 20060101ALI20160303BHJP

   G01C 21/26 20060101ALI20160303BHJP

【ＦＩ】

   G08G1/14 A

   G08G1/13

   G01C21/26 A

【請求項の数】8

【全頁数】25

(21)【出願番号】特願2012-78837(P2012-78837)

(22)【出願日】2012年3月30日

(65)【公開番号】特開2013-210706(P2013-210706A)

(43)【公開日】2013年10月10日

【審査請求日】2015年3月19日

(73)【特許権者】

【識別番号】597151563

【氏名又は名称】株式会社ゼンリン

(74)【代理人】

【識別番号】110000028

【氏名又は名称】特許業務法人明成国際特許事務所

(72)【発明者】

【氏名】▲高▼木 和之

【審査官】 白石 剛史

(56)【参考文献】

【文献】 特開２００９−１９３２９３（ＪＰ，Ａ）

【文献】 特開２００１−２８３３８７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／０１３３９５７（ＵＳ，Ａ１）

【文献】 特開２０１１−２４２９７８（ＪＰ，Ａ）

【文献】 特開２０００−１３７８９６（ＪＰ，Ａ）

【文献】 特開２０１０−１１７８６４（ＪＰ，Ａ）

【文献】 特開２０１０−２８６９５６（ＪＰ，Ａ）

【文献】 特開２００２−２８６４７１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０８Ｇ １／１４

Ｇ０１Ｃ ２１／２６

Ｇ０８Ｇ １／１３

(57)【特許請求の範囲】

【請求項1】

既存の駐車場の場内情報を記憶する記憶部と、
少なくとも１台の車両の位置を経時的に取得する車両位置取得部と、
前記取得した車両の位置に基づく前記駐車場内での車両の挙動を、前記場内情報に関連づけて、駐車情報として抽出する駐車情報抽出部と、
前記抽出した駐車情報により、前記駐車場の満空状況を判定する判定部と
を備え、
前記駐車情報は、前記駐車場内の駐車位置から歩行者用出入口までの距離である駐車距離を少なくとも含み、
前記満空状況の判定は、前記駐車場内における車両の駐車距離により行なう
駐車場満空判定装置。

【請求項2】

請求項１記載の駐車場満空判定装置であって、
前記記憶部は、前記場内情報として、既存の駐車場内に対応づけて設定された複数のエリアと、前記歩行者用出入口からの距離を含む利便性に基づいて前記エリア毎に設定された指標とを記憶し、
前記駐車情報取得部は、前記駐車情報として、前記車両が前記駐車場内において前記いずれのエリアに駐車したかを示す駐車位置情報を、前記指標と関連づけて取得し、
前記判定部は、前記駐車場の満空状況の判定を、前記駐車位置情報と前記指標とにより行なう
駐車場満空判定装置。

【請求項3】

請求項２記載の駐車場満空判定装置であって、
前記記憶部は、前記場内情報として、前記駐車場の入口を示す情報を記憶し、
前記駐車情報抽出部は、前記駐車情報として、前記駐車場の入口を前記車両が通過してから前記エリアに駐車するまでの経時情報を取得し、
前記判定部は、前記駐車場の満空状況の判定を、前記各エリアにおける前記経時情報により行なう
駐車場満空判定装置。

【請求項4】

前記判定部は、前記満空状況の判定を所定の期間毎に行なうと共に、前記一つの期間における満空の判定を、該期間の前の期間での満空の判定結果により修正する請求項１ないし請求項３のいずれか記載の駐車場満空判定装置。

【請求項5】

請求項１ないし請求項４のいずれか記載の駐車場満空判定装置であって、
前記駐車場は、少なくとも前記車両が進入可能な入口を備えた複数のフロアを備え、前記車両の挙動は、前記各フロア毎に抽出される
駐車場満空判定装置。

【請求項6】

予め関連付けられた複数の駐車場のそれぞれについて満空状況を判定する請求項１ないし請求項５のいずれか記載の駐車場満空判定装置から、前記満空状況の判定結果を受け取る結果受信部と、
前記複数の駐車場満空判定装置のうちの少なくとも一つから受け取った満空状況の判定結果に基づいて、前記予め関連付けられた他の駐車場の満空状況を判定する他駐車場満空判定部と
を備えた地域駐車場満空判定装置。

【請求項7】

少なくとも１台の車両の位置を経時的に取得し、
前記取得した車両の位置に基づく前記駐車場内の車両の挙動を、記憶部に記憶されている既存の駐車場の場内情報に関連づけて、駐車情報として抽出し、
前記抽出した駐車情報により、前記駐車場の満空状況を判定する方法であって、
前記駐車情報は、前記駐車場内の駐車位置から歩行者用出入口までの距離である駐車距離を少なくとも含み、
前記満空状況の判定は、前記駐車場内における車両の駐車距離により行なう
駐車場満空判定方法。

【請求項8】

コンピュータに読み取り実行可能であり、駐車場の満空状況の判定を行なうコンピュータプログラムであって、
少なくとも１台の車両の位置を、ネットワークを介して経時的に取得する機能と、
前記取得した車両の位置から、前記駐車場に対応づけられた領域での車両の挙動を、予めメモリに記憶されている既存の駐車場内のエリアに関する場内情報に関連づけて、駐車情報として抽出する機能と、
前記抽出した駐車情報により、前記駐車場の満空状況を判定する機能と、
判定結果を、ユーザによって認識可能に出力する機能と
を備え、
前記駐車情報は、前記駐車場内の駐車位置から歩行者用出入口までの距離である駐車距離を少なくとも含み、
前記満空状況の判定は、前記駐車場内における車両の駐車距離により行なう
コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、駐車場満空判定を行なう技術に関するものである。

【背景技術】

【0002】

ナビゲーション技術の発達により、車両や歩行者は、運転や移動に関する様々な移動支援のための情報を入手することが可能となった。情報は、車載のカーナビゲーション装置に限らず、携帯端末やコンピュータあるいはスマートフォンなどによっても入手することができる。

【0003】

こうした移動支援のための情報の一つとして、駐車しようとする駐車場が満車か否かといった情報（満空状況）がある。駐車場の満空状況とは、満車か否かの択一的な判定結果の場合のみならず、駐車場の空き具合（何パーセント程度駐車しているか）や駐車可能な台数など、様々な形態の情報として把握することができる。駐車場の満空状況の情報は、目的の施設に付属の、あるいは目的の施設に近接した駐車場に駐車できるかどうかの判断の参考になるから、運転時のみならず、その施設に出掛ける場合の交通機関の選択のために、参照される場合もある。こうした駐車場の満空状況の判定装置としては、下記特許文献に記載の構成などが知られている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００９−１９３２９３号公報

【特許文献2】特開２００３−２６３７００号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

従来の駐車場の満空状況の判定は、駐車場施設側が自らの管理において満車などの情報を出力するか、上記特許文献１に見られるように、駐車場内でプローブ車両が非駐車状態にあることを基づいて、満空状況の判定をしていた。前者の場合、駐車場施設側が設備投資をしなければならず、そうした設備のない駐車場の満空については判断できなかった。後者の場合、プローブ車両の非駐車状態（例えばイグニッションキーのオフ）を見ているに過ぎず、満空状況の判定の精度が高くないという問題があった。駐車場内では、車を停車しただけで、家族の買い物が終わるのを待っているといった場合もあり、非駐車状態だけでは、判定の精度としては不十分であった。

【課題を解決するための手段】

【0006】

本発明は、上述の課題の少なくとも一部を解決することを目的としてなされたものであり、以下の形態又は適用例として実現することが可能である。

【0007】

［１］適用例１の駐車場満空判定装置は、既存の駐車場の場内情報を記憶する記憶部と、少なくとも１台の車両の位置を経時的に取得する車両位置取得部と、前記取得した車両の位置に基づく前記駐車場内での車両の挙動を、前記場内情報に関連づけて、駐車情報として抽出する駐車情報抽出部と、前記抽出した駐車情報により、前記駐車場の満空状況を判定する判定部とを備えたことを要旨とする。この装置では、経時的に取得した車両（プローブ車両）の駐車場内での挙動を、既存の駐車場の場内情報に関連づけて、駐車情報として抽出する。このため、この駐車情報により、駐車場の満空状況を精度良く判定することができる。場内情報としては、例えば車両の駐車スペースと通路の別、あるいは歩行者用出入口の位置、立体駐車場などにおける他の駐車フロアへの出入口や走行路の情報などがある。

【0008】

［２］適用例２の駐車場満空判定装置は、駐車情報として、前記駐車場内の駐車位置から歩行者用出入口までの距離である駐車距離を少なくとも含み、前記満空状況の判定を、前記駐車場内における車両の駐車距離により行なうことを要旨とする。この駐車場満空判定装置は、前記駐車場内の駐車位置から歩行者用出入口までの距離である駐車距離を用いて満空状況の判定を行なうので、精度の高い判断が可能となる。

【0009】

［３］適用例３の駐車場満空判定装置は、前記記憶部が、前記場内情報として、既存の駐車場内に対応づけて設定された複数のエリアと、前記歩行者用出入口からの距離を含む利便性に基づいて前記エリア毎に設定された指標とを記憶し、前記駐車情報取得部が、前記駐車情報として、前記車両が前記駐車場内において前記いずれのエリアに駐車したかを示す駐車位置情報を、前記指標と関連づけて取得し、前記判定部が、前記駐車場の満空状況の判定を、前記駐車位置情報と前記指標とにより行なうことを要旨としている。この装置では、エリア毎に設定された指標と駐車位置情報を用いて満空状況の判定を行なうので、駐車場内で車両が駐車された位置に基づき、きめ細かく満空状況の判定を行なうことができる。

【0010】

［４］ここで、指標は、駐車後の前記エリア毎の利便性の違いにより付与することができる。利便性の違いとは、例えば駐車場から施設入口までの距離、エレベータやエスカレータ、動く歩道などの有無、通路の明るさ、自動販売の有無、など、駐車するユーザがそのエリアに車両を駐車しよう際の動機付けとなる要素である。利便性が高いと多くの利用者において意識されるようなエリアの指標は高く（あるいは低く）しておき、指標が高い（あるいは低い）ところに駐車する車が多いと想定される場合には、駐車場が比較的空いている、と判断するのである。なお、多くの利用者とは、相対的な判断基準であり、必ずしも統計的な処理を施したものでなくて差し支えない。例えば簡易なアンケートの結果や経験者の感覚で、利便性の大小を想定して、指標を決定しても差し支えない。もとより、学習などにより、徐々に指標を修正していくことも可能である。

【0011】

［５］また、指標は、固定的なものである必要は必ずしもなく、例えば日時、時刻、天候、当該駐車場の近隣地域での事故の発生あるいはイベントの開催のうちの少なくとも一つまたは２つ以上の組み合わせにより変更されるものとしても良い。施設に付設または隣接の駐車場では、施設の定休日や利用可能時間により利便性などの指標に影響を与える要因は変化するからである。

【0012】

［６］適用例６の駐車場満空判定装置は、前記記憶部が、前記場内情報として、前記駐車場の入口を示す情報を記憶し、前記駐車情報抽出部が、前記駐車情報として、前記駐車場の入口を前記車両が通過してからエリアに駐車するまでの経時情報を取得し、前記判定部が、前記駐車場の満空状況の判定を、前記経時情報により行なうことを要旨とする。この装置では、単に車両が駐車場内において非駐車状態にあるか否かという点で、駐車場の満空状況を判定しているのではなく、プローブ車両が駐車場の入口を通過してから、エリアに駐車するまでの経時情報により満空状況の判定を行なっている。このため、精度良く判定を行なうことができる。

【0013】

こうした駐車場満空判定装置において、前記判定部が、前記満空状況の判定を所定の期間毎に行なうと共に、前記一つの期間における満空の判定を、該期間の前の期間での満空の判定結果により修正する構成とすることができる。かかる装置では、所定の期間毎の判定を行なう際に、その期間内の判定結果のみならず、前の期間での判定結果を用いた修正を行なうので、満空状況を偶発的な事情によって判定してしまうことがなく、精度よく判定することができる。

【0014】

上記の駐車場満空判定装置では、更に、駐車場に、少なくとも前記車両が進入可能な入口を備えた複数のフロアを備え、前記車両の挙動は、前記各フロア毎に抽出されるものとすることができる。かかる装置では、複数のフロアを有する駐車場の満空状況の判定を精度良く行なうことができる。

【0015】

本発明は、端末装置、地域駐車場満空判定装置、満空状況の判定方法あるいはそのためのコンピュータプログラムとしても把握することができる。例えば、端装置末としては、光学的または音響的に情報を提示する提示部を備えた端末装置であって、駐車場の満空状況の問い合わせを、ネットワークを介して行なう問い合わせ部と、前記問い合わせを受けた駐車場満空判定装置が出力する信号を受け取る受信部と、該受信した信号に基づいて、駐車場の満空状況の判定結果を、前記提示部により外部に提示する提示制御部とを備えた構成とすればよい。かかる端末装置は、駐車場満空判定装置が出力する信号を受けて、駐車場の満空状況を提示部においてユーザに、的確に提示することができる。

【図面の簡単な説明】

【0016】

【図1】実施例としての駐車場満空判定システムの概略構成図。

【図2】地図及び駐車場データベースの概要を示す説明図。

【図3】プローブ車両からセンタサーバに駐車情報を送信する処理の概要を示すフローチャートで。

【図4】プローブ車両から送信される駐車車両データの概要を示す説明図。

【図5】満空状況の判定を行なうタイミングを示す説明図。

【図6】センタサーバ満空判定処理ルーチンを示すフローチャート。

【図7】平地駐車場での駐車の一例を示す説明図。

【図8】エリア満空状況判定処理ルーチンを示すフローチャート。

【図9】満空判定マトリクスの一例を示す説明図。

【図10】駐車場満空状況の問い合わせのやり取り示すフローチャート。

【図11】平地駐車場に複数の車両が駐車する場合の一例を示す説明図。

【図12】複数の車両の駐車状況を満空判定マトリクスにプロットした様子を示す説明図。

【図13】満空判定マトリクスにプローブ車両をブロットした例を示す説明図。

【図14】複数車両の平均駐車時間について説明する説明図。

【図15】複数車両の平均駐車距離について説明する説明図。

【図16】平地駐車場におけるエリアの区分について説明する説明図。

【図17】立体駐車場におけるエリアの区分について説明する説明図。

【図18】立体駐車場に関するデータ構造を説明するための説明図。

【図19】立体駐車場における歩行者用出入口からの距離の概念を示す説明図。

【図20】満空状況判定処理ルーチンを示すフローチャート。

【図21】立体駐車場において割り当てられた満空状況の判定の様子を示す説明図。

【図22】立体駐車場において割り当てられた満空状況の判定の他の様子を示す説明図。

【図23】時系列的に満空状況の判定がなされている様子を示す説明図。

【図24】地域に存在する複数の駐車場間に満空傾向順列が設定される様子を示す説明図。

【図25】複数の施設周辺の複数の駐車場間に満空傾向順列が設定される様子を示す説明図。

【図26】複数の施設周辺の複数の駐車場間に満空傾向順列が設定される様子を示す説明図。

【発明を実施するための形態】

【0017】

本発明の実施の形態について、具体例を挙げて説明する。図１は、駐車場満空判定システムの概略構成図である。図１に示した駐車場満空判定システム１０は、以下に説明するいくつかの実施例に共通で用いられるハードウェア構成を例示している。図示するように、駐車場満空判定システム１０は、プローブ車両ＡＭに搭載された車両ナビゲーションシステム（以下、「ナビゲーション」は単に「ナビ」と記載することがある）２０、車両ナビシステム２０とネットワークＮＷを介して接続されるセンタサーバ５０から構成されている。この駐車場満空判定システム１０は、ネットワークＮＷとして、携帯電話用の３Ｇ回線およびインターネットを用いたネットワークを採用しており、各種端末からアクセス可能となっている。各種端末としては、スマートフォンなどの携帯電話６０、タブレット端末７０、ナビゲーションシステムを搭載した車両８０、一般のコンピュータ９０等がある。これらの端末は、３Ｇ回線用の基地局を介して、ネットワークＮＷに接続される。なお、ネットワークの構成としては、３Ｇ回線を用いたものに限られず、無線ＬＡＮとインターネットを組み合わせた構成、ＦＭ波によるＶＩＣＳ（商標）を一部に用いた構成など、種々の構成が採用可能である。

【0018】

車両ナビシステム２０について説明する。この車両ナビシステム２０は、制御部２１を中心に、地図データベース（以下、「データベース」を「ＤＢ」と略記することがある）２２、ＧＰＳ受信部２４、車載センサ２５、表示部２６、通信部２７などを備えている。地図ＤＢ２２には、少なくとも走行用の道路に関する情報を記憶した地図データと、地域に存在する駐車場の詳細な情報からなる駐車場データ（場内情報に相当するデータ）が含まれる。地図ＤＢ２２に保存されているデータの一例を図２に示した。地図データは、複数のレイヤに別れてデータを管理しており、地域に存在する各種施設のデータを、特定のレイヤに集めて管理している。図２では、商業施設ＳＭとこれに隣接する駐車場ＰＳとが表示されている。これらの施設データは、他のレイヤに記憶された道路のデータや緯度経度のデータと関連づけて記憶されている。また、地図ＤＢ２２に含まれる駐車場データは、駐車場を特定するための駐車場ＩＤと共に、図２の下段に示したように、場内のエリアＡないしＣや、車両出入口の位置情報、歩行者用出入口の位置情報なども記録されている。なお、地図データは、車両ＡＭにおける走行案内（ナビゲーション）にも用いられるが、本実施例では、走行案内自体は、直接関係しないので、走行案内の手法については説明しない。もとより、地図データは、駐車場の位置の表示の際などに参照される。

【0019】

ＧＰＳ受信部２４は、ＧＰＳ測位システムの信号を受信して、現在の位置を特定する機能を有する。制御部２１は、このＧＰＳ受信部２４とデータのやり取りすることで、現在の車両の位置を正確に把握することができる。なお、後述するように、駐車場内での車両ＡＭの位置は、メートル単位で測定される。地下駐車場や都市のビルの林立した地域の駐車場内などで、ＧＰＳ衛星からの電波の受信状態が悪い場合には、駐車場内にＧＰＳ信号と同じ信号を発信する発信装置を設け、いわゆる屋内測位技術（ＩＭＥＳ）を併用する構成とすることも差し支えない。制御部２１は、ＧＰＳにより測定された位置の情報を用いて、後述する駐車場内での走行距離や駐車位置を認識しているが、車両ＡＭに搭載された各種車載センサ２５からの信号を用いたり、併用することも可能である。例えば、各種センサの一つである車輪の回転数センサからの信号を取り込み、車輪の回転数Ｎと車輪の外周長Ｌとから、走行距離を求める構成とすることも可能である。これはいわゆるディップメータとしての機能である。したがって、ディップメータから、直接走行距離のデータを読み込むこととしても良い。

【0020】

車両ナビシステム２０は、走行中の場所の地図や駐車場の満空状況の判定結果などを、表示部２６に表示する。また、通信部２７を用いて、センタサーバ５０とデータのやり取りを行なう。こうした車両ナビシステム２０での各種制御については、後でフローチャートを用いて詳しく説明する。

【0021】

センタサーバ５０は、全体の制御を司るＣＰＵ５１、データを一時的に記憶するメモリ５２、駐車場の所在など駐車場に関する固定的な情報や、車両ナビシステム２０から送られる駐車情報などを蓄積する駐車場データベース５４、ネットワークを介したデータのやり取りを行なう通信部５５などが備えられている。ＣＰＵ５１は、メモリ５２に記憶されたプログラムを実行することにより、駐車場の満空状況の判定処理や車両ナビシステム２０および各種端末との間でデータのやり取りを行なう処理などを行なう。この処理の内容は、フローチャートを用いて後述する。なお、ＣＰＵ５１が実行するプログラムは、図示しないＲＯＭあるいはハードディスクからメモリ５２にロードされて実行される。もとより、ＲＯＭなどから直接実行することも差し支えない。

【0022】

［第１実施例］
次に、駐車場満空判定システム１０の第１実施例について説明する。第１実施例の駐車場満空判定システム１０では、車載の車両ナビシステム２０とセンタサーバ５０とがデータをやり取りして、満空状況の判定に関する処理を行なっている。駐車場満空判定システム１０としての処理は、大きくは、
（Ａ）プローブ車両ＡＭからの情報をセンタサーバ５０が受け取り、
（Ｂ）この情報に基づいて、センタサーバ５０が満空状況の判定を行ない、
（Ｃ）その結果を、各種端末６０ないし９０からの問い合わせに対して出力する、
というものである。第１実施例では、上記（Ａ）の処理を図３に、（Ｂ）の処理を図６および図８に、（Ｃ）の処理を図１０に、それぞれ示した。以下、順次これらの処理について説明する。

【0023】

図３は、プローブ車両ＡＭに搭載された車両ナビシステム２０が行なう制御ルーチンと、車両ナビシステム２０からの情報を受け取るセンタサーバ５０の処理とを対応付けて示すフローチャートである。車両ナビシステム２０は、図３左側に示した処理Ｓ１０２ないしＳ１０８を、所定のインターバルで繰り返し実施している。この処理を開始すると、制御部２１は、ＧＰＳ受信部２４からの信号を受け取り、車両の位置を検出する処理を行なう（ステップＳ１０２）。制御部２１は、検出した位置を用いて地図ＤＢ２２を参照することにより、自身が、いずれかの駐車場内に位置しているか否かについて判断する（ステップＳ１０４）。駐車場内に入ったか否かは、ＧＰＳからの信号のみで判断しても良いし、ＩＭＥＳなどが駐車場に取り付けられていれば、その信号を検出しているか否かの情報を併せて判断しても良い。あるいは、駐車場の入口に設けられたゲートとの間で信号をやり取りすることで、駐車場内への進入を判断するものとしても良い。

【0024】

車両が駐車場内に入っていなければ、制御部２１は、駐車場満空判定に係わる特別な処理を行なわず、ナビ装置としての通常の処理（地図を表示部２６に表示する処理や経路案内の処理など）を行ない（ステップＳ１０６）、その後、「ＮＥＸＴ」に抜けて、本処理ルーチンを一旦終了する。

【0025】

他方、プローブ車両ＡＭが、駐車場内に位置していると判断した場合には（ステップＳ１０４）、制御部２１は、駐車情報を生成する処理を行なう（ステップＳ１０７）。プローブ車両ＡＭにおいて生成される駐車情報の一例を図４に示した。駐車情報は、実際には、車両ＡＭが駐車場内に入った後、駐車された時点で生成される。車両が駐車したか否かは、車両の停車位置およびイグニッションスイッチオフ（あるいはシフトポジションが「パーキング」）などの判定を行なうことにより判断可能である。これらの条件は、各種の車載センサ２５からの信号に基づいて判断可能である。図４に示した例では、駐車情報は、プローブ車両を識別する「車両ＩＤ」、駐車した駐車場を示す「駐車場ＩＤ」、駐車場内の駐車したエリアを示す「エリア番号」、駐車場に入ってから駐車するまでに要した「駐車所要時間」、駐車した位置から歩行者用出入口までの距離を示す「駐車距離」、駐車した時刻を示す「駐車時刻」などのデータから構成されている。なお、第１実施例では、プローブ車両ＡＭが駐車した駐車場は平地の駐車場であり、駐車用のフロアは一つであり、そのフロア内にエリアの区別は特にされていない。図２に即して言えば、符号ＡないしＣの区別はなく、プローブ車両ＡＭは、駐車場内が全てエリア番号Ａとされている駐車場に駐車したものとして以下説明する。駐車場ＩＤやエリア番号、あるいは歩行者用出入口の位置などは、予め地図ＤＢ２２内の駐車場データに記録されている。これらの情報は、予め収集して、地図ＤＢ２２に、駐車場データとして記録しておいたが、車両ＡＭが駐車場内に入ったときに、駐車場側とデータ交換して取得するものとしても良い。

【0026】

車両ナビシステム２０は、ステップＳ１０７において駐車情報を生成すると、これを、センタサーバ５０に向けて送信する処理を行なう（ステップＳ１０８）。車両ナビシステム２０は、駐車場の満空の判定に必要となる駐車情報を、必要があれば、他の情報と共にパケットにまとめ、図４に示した駐車車両データＡ１として、ネットワークＮＷを介してセンタサーバ５０に送信するのである。

【0027】

センタサーバ５０は、図３に示したセンタサーバ受信処理ルーチンを、パケットが通信部５５に到達するたびに繰り返し実行する。プローブ車両ＡＭから送信された駐車車両データＡ１のパケットが通信部５５に到達した場合には、そのデータは、センタサーバ５０により受け取られる（ステップＳ１１０）。ネットワークＮＷに向けて送信されたパケットには、ヘッダ部に、送信先であるセンタサーバ５０のＩＰアドレスなどの情報が付加されているので、センタサーバ５０が、自分宛のパケットを識別してこれを取り込むことは容易である。センタサーバ５０は、プローブ車両ＡＭから送信された駐車車両データＡ１を受け取ると、ここから駐車情報を抽出し、駐車場データベース５４内に記憶した駐車場データのうち、対応する駐車場のデータを更新する処理を行なう（ステップＳ１１２）。なお、こうした駐車場データの更新は、予め駐車場毎に用意されたテーブル内のデータを、受信した駐車車両データにより最新のデータに書き換え、書き換えられた時間を記録することによって行なっても良いし、受信した最新の駐車車両データを、後述する満空判定の処理で用いられるまでバッチファイルとして単に蓄積しておくだけでも良い。本実施例では、後者の態様を採用している。

【0028】

以上の処理の後、図３に示した車両ナビ制御ルーチンおよびセンタサーバ受信処理ルーチンは、それぞれ一旦終了する。プローブ車両ＡＭは、実際には、複数台存在しており、そのうちの１台でもいずれかの駐車場に駐車すれば、図４に例示した駐車車両データを送信してくる。センタサーバ５０は、このデータを順次受け取り、駐車場毎に蓄積していく。その上で、センタサーバ５０は、上述した（Ｂ）の処理、即ち、駐車場の満空状況を判定する処理を実行する。この処理は、第１実施例では、１５分おきに実行されるものとした。図５は、この処理の様子を示す説明図である。センタサーバ５０は、１５分を一つの期間として、各駐車場の満空状況の判定を行なう。図５では、符号Ｔn が、センタサーバ５０が満空状況の判定を行なおうとしているタイミングを示している。センタサーバ５０は、現在の時点Ｔn では、その前の１５分間（Ｔn-1 からＴn まで）に蓄積された駐車情報に基づいて、判定を行なう。１５分前の時刻Ｔn-1 では、同様にその前の１５分間（時刻Ｔn-2 から時刻Ｔn-1 まで）に蓄積された駐車情報に基づいて、判定を行なう。図５では、判定を行なおうとしている駐車場に、直前の１５分間に４台の車両Ｚ１ないしＺ４が駐車した場合を例示している。この場合、各車両Ｚ１ないしＺ４は、それぞれ駐車車両データＡ１ないしＡ４を、センタサーバ５０に送信し、センタサーバ５０は、これを蓄積している。

【0029】

センタサーバ５０が実行するセンタサーバ満空判定処理ルーチンを図６に示した。センタサーバ５０は、１５分毎に、このルーチンを起動すると、まず未処理の駐車情報が存在するか否かの判断を行なう（ステップＳ１２０）。未処理のデータとは、車両から受け取った駐車車両データが、バッチファイルとして蓄積されているか否かにより判断することができる。１５分の間に蓄積された未処理の駐車車両データがあると判断されれば、満空状況の判定を行なおうとしている駐車場に該当する駐車車両データをバッチファイルから全て読み出す処理を行なう（ステップＳ１２２）。判定の対象となる駐車場に関する駐車車両データであるか否かは、駐車場ＩＤにより容易に識別することができる。

【0030】

こうして読み出した駐車車両データから満空状況の判定に必要な駐車情報を抽出し、センタサーバ５０は、満空状況判定処理（ステップＳ１３０）を実行し、判定の対象となった駐車場についての満空状況の判定を行なう。その後、判定の結果を、送信可能に準備し（ステップＳ１５０）、未処理のデータがなくなるまで、上述した処理を繰り返す。バッチファイルに未処理のデータがなくなれば、「ＮＥＸＴ」に抜けて処理を終了する。

【0031】

第１実施例における満空状況判定処理（ステップＳ１３０）について、例を挙げて詳しく説明する。図７は、満空状況の判定を行なう駐車場とブロック車両の駐車の一例を示す平面図である。図７に例示した駐車場は、平地駐車場であり、その内部は一つのエリアしか設定されていない。破線で示された矩形は、各駐車スペースを示す。図示左上に、左から車両が進入可能な車両出入口があり、図示右側下方に歩行者用の出入口がある。満空状況の判定期間（第１実施例では１５分）の間に、この駐車場には、２台の車両ＺＡ，ＺＢが駐車したものとする。図示したように、車両ＺＡは、駐車場内を進行案内方向に沿って約１周半して、歩行者用出入口に近い駐車位置に駐車した。他方、車両ＺＢは、車両出入口から入ってすぐの駐車スペースに駐車した。この結果、車両ＺＡの駐車情報は、駐車所要時間は、例えば６００秒と長く、歩行者用出入口までの駐車距離は５メートルと短いものとなり、車両ＺＢの駐車情報は、駐車所要時間は、例えば４５秒と短く、歩行者用出入口までの駐車距離は２５メートルと長いものとなる。２台のプローブ車両ＺＡ，ＺＢは、この駐車情報を含む駐車車両データを、駐車後、センタサーバ５０に送信している。

【0032】

第１実施例において行なわれる駐車場の満空状況の判定処理の詳細を図８に示した。図８の処理は、図６に示したセンタサーバ満空判定処理ルーチンにおけるステップＳ１３０に相当する。センタサーバ５０が、未処理のデータがあると判定してこれを読み出した後、満空状況判定処理を開始すると、まず駐車車両データから駐車情報を特定する処理を行なう（ステップＳ１３２）。駐車した各プローブ車両は、駐車情報を含む駐車車両データを送信してきているので、駐車車両データから必要な駐車情報を特定するのである。次に、この駐車情報を、満空判定マトリクスにプロットする処理を行なう（ステップＳ１３４）。

【0033】

満空判定マトリクスの一例を図９に示した。第１実施例における満空判定マトリクスは、２軸のうちの一つを駐車所要時間とし、他を歩行者用出入口までの距離（駐車距離）とするものであり、図９では、両軸が直交する二次元マップとして示した。図９において、駐車所要時間は縦軸に割り当てられ、所要時間は下が短く上が長いものとして設定されている。同様に、駐車距離（歩行者用出入口との関係）は、横軸の左が短く（近く）、右が長い（遠い）ものとして設定されている。この満空判定マトリクスには、「空車傾向」「混雑傾向」「満車傾向」の３の領域が設定されている。空車傾向は、図９における左下の領域、即ち駐車所要時間が短くかつ歩行者用出入口が近い（駐車距離が短い）領域として設定されている。満車傾向は、空車傾向の領域とはほぼ正反対の性質を持つ領域として設定されているが、空車傾向の領域より広く、駐車所要時間が長いものの歩行者用出入口が近い（駐車距離が短い）という条件や、逆に、駐車所要時間が短いものの歩行者用出入口が遠い（駐車距離が長い）という条件を含む領域として設定されている。混雑傾向の領域は、空車傾向と満車傾向の領域の中間の帯域として設定されている。

【0034】

第１実施例における駐車情報は、この駐車所要時間と駐車距離とが含まれている。即ち、第１実施例では、この２つの情報を、駐車場内における車両の挙動として扱っている。図７に示した例では、各車両の挙動を示す駐車情報は以下の通りであった。
（１）車両ＺＡについての駐車情報
・駐車所要時間：６００秒
・駐車距離：５メートル
（２）車両ＺＢについての駐車情報
・駐車所要時間：４５秒
・駐車距離：２５メートル
この両データを、図９に示した満空判定マトリクス上にプロットすると、車両ＺＡについては、図９左上の満車傾向の領域の端に、車両ＺＢについては、図９右下の満車傾向の領域の端に、それぞれプロットされる。その上で、センタサーバ５０は、この駐車場の満空状況を判定する処理を行なう（ステップＳ１３６）。この例では、２台のプローブ車両ＺＡ，ＺＢは、いずれも満車傾向の領域にブロットされたので、この駐車場は、満車傾向にあるとして記録する。以上で、一つの駐車場についての満空状況判定処理を完了する。なお、複数台のプローブ車両からの駐車情報を満空判定マトリクスにプロットした結果が一致しない場合には、本実施例では、最も満車傾向側の傾向を、その駐車場についての満空状況として判定するものとしている。例えば、車両ＺＡが満車傾向を示し車両ＺＢが混雑傾向を示せば「満車傾向」と判定し、車両ＺＡが混雑傾向を示し車両ＺＢが空車傾向を示せば、「混雑傾向」と判定するのである。

【0035】

以上説明した満空状況判定処理（図６、ステップＳ１３０）を完了すると、既に、図６を用いて説明したように、その結果を送信可能に準備し（ステップＳ１５０）、全ての駐車場についての処理が完了するまで、図６に示した処理を繰り返す。

【0036】

以上説明した処理により、１５分おきに、各駐車場についての満空状況の判定結果が用意され送信可能に準備されるから、図１に示した各種端末６０ないし９０は、この判定結果をいつでも利用することができる。各種端末からの問い合わせとセンタサーバ５０による応答処理を、図１０に示した。

【0037】

端末として車両８０が問い合わせるケースを想定して以下説明する。この車両８０は、説明の都合上、図１のプローブ車両ＡＭと同様のハードウェアを有するものとする。この車両８０における車両ナビシステム２０が図１０に示した処理を開始すると、車両ナビシステム２０は、現在位置を含む近隣地域の地図を表示部２６に表示する（ステップＳ１６０）。現在位置は、ＧＰＳ受信部２４からの信号を処理することにより、取得する。その上で、ユーザからの問い合わせたい駐車場または地域の指定を受け付ける処理を行なう（ステップＳ１６２）。表示部２６に現在車両が所在する地域の地図が表示されるので、ユーザは、この地図を見ながら、例えば表示部２６を直接指でタップするといった手法により、容易に、指定を行なうことができる。車両ナビシステム２０は、指定された駐車場や地域などの情報を、センタサーバ５０に送信する（ステップＳ１６４）。

【0038】

センタサーバ５０は、受信処理を行なって（ステップＳ１７０）、受け取った情報が端末からの問い合わせであると判断すると（ステップＳ１７２）、該当駐車場、つまり問い合わせを受けた駐車場あるいは問い合わせを受けた地域に属する駐車場として、満空状況の判定結果を記憶している駐車場があるか否かを判断する（ステップＳ１７４）。該当駐車場の満空判定結果を記憶している場合には、次に満空状況の判定結果を出力する処理を行なう（ステップＳ１７６）。判定結果を、問い合わせた端末に返送するのである。問い合わせた端末は、ネットワークＮＷ上のアドレスを付けたパケットにより、問い合わせをしてくるので、問い合わせた端末に、判定結果を届けることは容易である。なお、該当駐車場についての判定結果を記憶していない場合には、その旨の回答を行なう。

【0039】

ステップＳ１６４で問い合わせを送信した車両ナビシステム２０は、回答があるまで受信処理を繰り返し（ステップＳ１６５、１６６）、センタサーバ５０からの回答を待つ。回答があれば、その結果を表示部２６に表示する処理を行なう（ステップＳ１６８）。回答の表示は、問い合わせが駐車場に関するものであれば、その駐車場の満空状況の判定結果であり、問い合わせが地域に関するものであれば、その地域に属する駐車場の満空状況の判定結果である。表示は、可読性を高めるために、駐車場毎に「空」（空車傾向）、「混」（混在傾向）、「満」（満車傾向）のように、アイコンにより表示するものとしている。なお、判定結果がないとの回答があった場合には、駐車場毎の表示は行なわず、単に「満車／空車に関する情報はありません」と表示すればよい。もとより音声によって回答するものとしても良い。

【0040】

以上説明した第１実施例の駐車場満空判定システム１０によれば、駐車場の満空状況の判定を、車両駐車場内での挙動を示す駐車情報、即ち駐車所要時間と駐車距離（歩行者用出入口までの距離）との組み合わせにより行なっているので、少ないプローブ車両からの駐車情報しか得られない状況でも、駐車場の満空状況を、精度良く判定することができ、これを問い合わせた端末において表示させることができる。したがって、利用者は、精度の良い満空状況の判定結果を得て、適切な駐車場に駐車したり、車に代わる交通機関を選択するなどの行動をとることができ、高い利便性を得ることができる。図９に示した例では、駐車所要時間のみで判断したのでは、車両ＺＢの駐車情報では、空車傾向と誤って判定してしまいがちである。本実施例によれば、例え車両ＺＢの駐車情報しか得られなかった場合でも、実際の駐車場の満空状況に即した判定結果が得られる可能性が高い。

【0041】

なお、駐車情報の内容は同一でも、その条件が、駐車場における満空判定において持つ意味は駐車場の規模、設置箇所などの駐車場の条件によっても変化する。駅に隣接した大規模駐車場における「歩行者用出入口に近い」という距離と、郊外の小規模駐車場におけるそれとは異なる。したがって、図９に例示した満空判定マトリクスは、駐車場の種別（例えば駐車台数の大中小など）などの条件毎に異なるものとしても良いし、各駐車場毎に個別に用意しても良い。更に、満空状況の判定結果をモニタして、より実情に即した判定結果となるように、満空判定マトリックスにおける空車傾向、混雑傾向、満車傾向などの領域を修正するものとしても良い。モニタによる満空判定マトリクスの修正は、同様に条件を備えた他の駐車場の満空判定マトリクスに反映することも望ましい。

【0042】

［第２実施例］
次に、本発明の第２実施例について説明する。第２実施例では、満空状況の判定を行なう際のインターバル（第１実施例では１５分）間に所定数以上のプローブ車両から駐車車両データが得られるケースを想定した処理を行なっている。第２実施例の駐車場満空判定システム１０は、ハードウェア構成は第１実施例と同一であり、図１１に示した満空状況判定処理（第１実施例では図８）以外は同様の処理がなされている。したがって、プローブ車両が駐車場に入ると駐車情報を生成し、駐車車両データとしてセンタサーバ５０に送信してくることや、センタサーバ５０は、この情報を蓄積し、１５分毎に、満空判定処理ルーチン（図６）を実行して、満空状況判定処理を行ない、端末からの問い合わせに対して満空状況の判定結果を返すといった点では、第１実施例と同様である。そこで、以下、第２実施例に固有の処理を中心に説明する。

【0043】

第２実施例では、端末である車両８０からの問い合わせがあり、満空状況判定処理が開始されると、図１１に示したように、まず駐車車両データから駐車情報を特定する処理を行なう（ステップＳ２１２）。駐車した各プローブ車両は、駐車情報を含む駐車車両データを送信してきているので、駐車車両データから必要な駐車情報を特定するのである。第２実施例で扱う車両駐車データについて図１２を用いて説明する。この例では、判定の期間に、４台のプローブ車両Ｚ１ないしＺ４が、駐車場内に駐車している。なお、駐車場内における駐車スペースや、駐車場の車両出入口と歩行者用出入口の配置などは、第１実施例（図７）と同様である。この４台のプローブ車両Ｚ１ないしＺ４の駐車情報を、第１実施例と同様に満空判定マトリクスにプロットすると、図１３に例示した結果となる。この場合、第１実施例では、最も満車傾向側の傾向をその駐車場についての満空状況として判定することから、車両Ｚ１の満空状況が、「混雑傾向」と判定されるので、駐車場としては、「混雑傾向」と判断される可能性が高い。

【0044】

第２実施例では、こうした複数台からの駐車車両データが蓄積されている場合には、平均駐車所要時間を算出し（ステップＳ２１４）、更に平均駐車距離を算出する（ステップＳ２１６）。平均駐車所要時間は、図１４に示したように、判定のタイミングの前の時間帯Ｔn-1 に駐車した車両の駐車所要時間を、駐車情報から取り出し、これを平均することにより求めるのである。この例では、４台のプローブ車両Ｚ１ないしＺ４の平均駐車所要時間は、単純な算術平均により、３３８秒となった。もとより、単純な算術平均に代えて、重み付け平均や、中央値あるいは最頻値などの統計的処理を施した値を、平均駐車所要時間としても良い。重み付けをする場合には、より直近の駐車情報ほど重み付けを重くしたり、プローブ車両毎に重み付けを変えたりすることが考えられる。後者は、例えば、プローブ機能が高精度な車両ほど重み付けを重くしたり、その駐車場を以前に利用した人ほど重み付けを重くするといった対応が考えられる。走行位置や走行距離の精度が高いほどデータの信頼性が高く、利用経験者や常連ユーザほど、的確に利便性の高い位置に駐車しようとすると想定されるからである。

【0045】

同様に、平均駐車距離は、図１５に示したように、判定のタイミングの前の時間帯Ｔn-1 に駐車した車両の駐車距離を、駐車情報から取り出し、これを平均することで求めるのである。この例では、４台のプローブ車両Ｚ１ないしＺ４の平均駐車距離は、単純な算術平均により、１７．３メートルとなった。平均所要時間同様、単純な算術平均に代えて、重み付け平均や、中央値あるいは最頻値などの統計的処理を施した値を、平均駐車距離としても良い。重み付けをする場合に、より直近の駐車情報ほど、あるいはその駐車場に慣れた人ほど重み付けを重くすると行った手法は、平均駐車所要時間と同様に適用することができる。

【0046】

こうして駐車情報を構成する駐車所要時間と駐車距離とをそれぞれ平均化した平均駐車所要時間と平均駐車距離とにより、満空判定マトリクスへのプロットを行なう（ステップＳ２１７）。このプロットを図１３に符号ＡＶＺとして示した。満空判定マトリクスへのブロットの結果により、満空状況の判定結果を得て、これを記憶する（ステップＳ２１８）。以上の処理により、第２実施例の満空状況判定処理は完了する。この結果、第２実施例では、複数のプローブ車両からの駐車車両データを受け取ると、その駐車情報を平均化して満空状況の判定を行なうので、平均的な状況を反映した的確な判定を行なうことができる。複数のプローブ車両のうちの一台が、何らかの事情で特異な挙動をした場合でも、平均化することにより、特異なデータによる誤判定を行なうことがない。その余の作用効果は、第１実施例と同様である。

【0047】

［第３実施例］
次に本発明の第３実施例を説明する。第３実施例では、第１，第２実施例と同一のハードウェア構成は第１，第２実施例と同一であり、満空状況判定処理（第１実施例では図８、第２実施例では図１１）以外は、ほぼ同様の処理がなされている。したがって、プローブ車両が駐車場に入ると駐車情報を生成し、駐車車両データとしてセンタサーバ５０に送信してくることや、センタサーバ５０は、この情報を蓄積し、１５分毎に、満空判定処理ルーチン（図６）を実行して、満空状況判定処理を行ない、端末からの問い合わせに対して満空状況の判定結果を返すといった点では、第１実施例と同様である。そこで、以下、第３実施例に固有の処理を中心に説明する。

【0048】

第１，第２実施例では、平地駐車時用を例としたが、実際には立体駐車場や平地の駐車場であっても複数のエリアに区分されている駐車場なども少なくない。また、物理的には複数のエリアに区分されていなくても、満空状況の傾向等により、複数のエリアに区分した場内情報を設定して記憶することもできる。こうした場合には、駐車場内にいくつかのエリアを設定し、エリア毎の満空状況を組み合わせることで、満空状況の判定を行なう点で、第１，第２実施例と相違する。例えば図１６に示した平地駐車場では、歩行者用出入口の属する矩形の領域をエリアＡ、その外側の領域をエリアＢ、更にその外側に相当する残余の領域をエリアＣ、としてそれぞれ設定している。符号「○」は車両にとっての駐車場入口を、符号「◎」は歩行者用出入口を、それぞれ示している。その上で、駐車しようとする人は、例えエリアＢやＣに空きがあっても、歩行者用出入口に近いエリアＡに駐車スペースがあれば、エリアＡへの駐車を優先すると想定している。エリアＡへの駐車を優先するとは、図２や図７に例示した駐車場では、通路を何周かしたりエリアＡから出ていく車両があるのを待ってでも、つまり駐車所要時間が長くなっても、エリアＡに駐車しようとすることである。そうした優先度を考慮して、エリアＡ，Ｂ，Ｃ間に、エリア間満空傾向順列として、Ａ＞Ｂ＞Ｃ、を設定する。このエリア間満空傾向順列は、エリアＢがエリアＡより先に満車になることはなく（同様に、エリアＣがエリアＢより先に満車になることはなく）、エリアＣが満車になった時点で、駐車場が満車になったと判断できるということを意味している。これが、本発明における「指標」に相当する。

【0049】

こうした駐車場におけるエリア毎の駐車車両の挙動の違いは、立体駐車場では更に顕著に現われることが多い。図１７は、４つのフロアを有する単独接地の立体駐車場の模式図である。単独接地とは、商業施設などに付設の駐車場ではない、という意味である。図１７に例示した立体駐車場では、各階に各階のエリアＡないしＤと歩行者用出入口が設けられ、１階フロアには更に車両用の入口と２階フロアへの車両出入口とがあり、２、３階には上下階への、４階には下階への車両用出入口が設けられている。こうした立体駐車場では、駐車した利用者は、歩行者用出入口から駐車位置までの平均距離はいずれのフロアでも同じであるが、歩行者用出入口から地上に降りていくため、各フロアの利便性には違いがあり、実際には１階または１階に近いフロアのエリアから順に駐車していく傾向が強い。このため、各階のエリアＡ，Ｂ，Ｃ，Ｄ間に、エリア間満空傾向順列として、Ａ＞Ｂ＞Ｃ＞Ｄ、を設定する。この場合、エリア間満空傾向順列の意味は、エリアＢがエリアＡより先に満車になることはなく（同様に、エリアＣ，ＤがエリアＢ，Ｃより先に満車になることはなく）、エリアＤが満車になった時点で、立体駐車場が満車になったと判断できるということである。なお、商業施設に付設の立体駐車場の場合の扱いや、各フロアの満車・空車情報を示す表示板などが接地されている場合の扱いについては、後で説明する。

【0050】

第３実施例では、図１７に示したエリア間満空傾向順列が設定された立体駐車場についての満空状況の判定処理について説明する。立体駐車場におけるプローブ車両の挙動を検出するためには、各立体駐車場の構造を記述する必要がある。図１８は、立体駐車場内での車両の挙動を解析するために予め駐車場毎に作成された駐車場データの一例を示している。図における各符号の意味は以下の通りである。

【0051】

Ｐａ：エリアを示す。ポリゴンにより事前に定義される。プローブ車両がこのポリゴン内に進入した際に、エリア内での駐車移動中と判断する領域。数字は満空状況を定義されるエリア単位に設定される。
Ｐｅｎ：エリアへの車両にとっての入口を示す。ポリゴン、ポリライン、ポイント等により事前に定義される。エリアに進入後、駐車までの挙動の記録を開始する位置。数字は駐車場への入口が複数ある場合に入口単位に設定される。
Ｐｅｘ：エリアからの出口を示す。ポリゴン、ポリライン、ポイント等により事前に定義されるデータ。エリアに進入後、ここを通過した際にエリア内での記録を破棄する位置である。数字は駐車場への出口が複数ある場合に出口単位に設定される。

【0052】

Ｂｅ：エリアから施設への歩行者用出入口を示す。ポリゴン、ポリライン、ポイント等により事前に定義される。駐車位置までの距離を判定される際に用いる基準となる位置。数字は駐車場への出口が複数ある場合に出口単位に設定される。
Ｐｔｒ：エリア間の満空傾向順列を示す。事前に現地調査、施設管理者へのヒアリングなどにより取得し記憶する。後述する満空状況判定処理で用いられる。この実施例では、エリアＰａ１ないしＰａ４間の満空傾向順列は、Ｐａ１＞Ｐａ２＞Ｐａ３＞Ｐａ４である。
また、図１８らおける矢印付きの太線は、エリアへのエリア外部からの、あるいはエリア外部への車両の進行方向を示している。エリア外部とは、駐車場の外および他のフロアである。

【0053】

図１９は、例示する立体駐車場における車両の挙動を示す駐車情報の一例を示している。図１９における点線は、プローブ車両の挙動を示している。
Ｐｔ：駐車所要時間を示す。各フロアの車両用の出入口から進入後、駐車するまでに要した時間。図１９において、駐車番号ｐ１の駐車スペースに駐車した車両ＺＺ１の駐車所要時間は、Ｐｔ（ｐ１）として表わされる。
Ｐｄ：駐車距離を示す。各フロアにおいて、駐車した位置から歩行者用出入口までの距離。図１９において、駐車番号ｐ１の駐車スペースに駐車した車両ＺＺ１の駐車距離は、Ｐｔ（ｐ１）として表わされる。なお、図１９では、歩行者用出入口Ｂｅは、Ｂｅ１，Ｂｅ２の２つが存在するが、エリアから見た場合、歩行者用出入口Ｂｅ１からの距離だけでほぼ足りるので、本実施例では、歩行者用出入口Ｂｅ１からの距離で、駐車距離Ｐｄを定義している。歩行者用出入口Ｂｅ１、Ｂｅ２が離れているような場合、例えば駐車スペースを挟んで対面しているような場合には、近い出入口Ｂｅ１，Ｂｅ２からの距離を用いて定義すればよい。各駐車番号ｐｎの駐車用スペースには、駐車距離Ｐｄが一義的に与えられる。最も遠いところまでの距離が、最長駐車距離Ｐｄmax であり、最も近いところまでの距離が、最短駐車距離Ｐｄmin である。したがって、番号ｐｎの駐車スペースに停車した車両の駐車距離Ｐｄ（ｐｎ）は、最短駐車距離Ｐｄmin 〜最長駐車距離Ｐｄmaxの間となる。

【0054】

以上説明した駐車場に関する情報は、プローブ車両ＡＭの地図ＤＢ２２内に駐車場データとして記憶されている。したがって、プローブ車両ＡＭは、この駐車場データを利用して、駐車場内で駐車すると、駐車所要時間と駐車距離とを求め、これをセンタサーバ５０に送信する。センタサーバ５０は、これを受け取り、第２実施例と同様の処理を行なって、各フロアのエリアＰ１ないしＰ４での満空状況の判定を行なう。この判定処理を図２０に示した。図２０は第２実施例の図１１の処理（図６に示したステップＳ１３０の処理）の後、ステップＳ１５０の処理の前に実施される処理である。ステップＳ１３０（図１１におけるステップＳ２１２ないしＳ２１８）が実行された後では、プローブ車両が存在したフロアのエリアについては、満空状況の判定処理がなされ、プローブ車両が駐車したエリアの満空状況の判定がなされている。

【0055】

この状態で図２０に示した処理を開始すると、まず満空状況の判定結果が付与されていないエリア、つまり判定結果の未付与のエリアがあるか否かの判断を行なう（ステップＳ３１０）。判定の期間に立体駐車場のすべてのフロアにプローブ車両が駐車するとは限らないから、すべてのエリアに満空状況の判定結果が設定されているとは限らない。例えば図２１に示すように、４フロアある立体駐車場の２階と４階には期間内にプローブ車両が駐車し、２階に設定されたエリアＢと４階に設定されたエリアＤについては、満空状況の判定がなされて、それぞれ「満車」と「混雑」という満空状況の判定結果が設定されていたとする。この場合、エリアＡとＣについては、満空状況の付与はなされていないことになる。

【0056】

そこで、この場合には、満空状況の判定結果が未付与のエリアがあるとして、次に未付与のエリアの一つを選択する処理を行なう（ステップＳ３１２）。未付与のエリアの選択の順序は特に問わないが、例えば満空傾向順列の低い側（図２１の例ではエリアＤの側）から選択しても良いし、その逆でも良い。あるいはランダムに選択するものとしても良い。未付与のエリアを一つ選択すると、次に選択したエリアが満空状況の判定結果が付与されているエリアに挟まれているか否かを判断する（ステップＳ３１５）。選択されたエリアが、エリアＣであったとすると、エリアＣの下層階Ｂと上層階Ｄにはいずれも満空状況の判定結果（エリアＢについては「満車」、エリアＤについては「混雑」）が付与されているから、エリアＣは、挟まれていると言える。そこでこの場合には、未付与のエリアに、満空状況の判定結果として、これを挟んでいる両側の満空状況の中間の状態を仮設定する（ステップＳ３１６）。図２１に示した例では、エリアＣには、「満車」が仮設定される。「中間の状態」とは、満空状況が、「空車」「混雑」「満車」のように３段階で判定されている場合には、「空車」と「満車」であれば中間の「混雑」の状態を意味する。「空車」と「混雑」、「混雑」と「満車」のように隣り合った判定結果の場合には、より満車側の判定結果を「中間の状態」として設定する。なお、この設定は「仮設定」であり、最終的な設定は、後述するように、本ルーチンの最後で行なわれる。

【0057】

他方、ステップＳ３１２で選択したエリアが、図２１に例示したエリアＡのように、「挟まれていない」と判断された場合には（ステップＳ３１５：ＮＯ）、下位に「混雑または満車」に設定されているエリアが存在するか否かについて判断する（ステップＳ３２０）。「下位」とは、エリアの満空傾向における下位である。図２１に示した例では、エリアＡの下位のエリアＢは、「満車」と判定されているので、ステップＳ３２０での判断は「ＹＥＳ」となり、このエリアには、「満車」が仮設定される（ステップＳ３２２）。他方、下位に、「混雑または満車」に設定されているエリアがなければ（ステップＳ３２０：ＮＯ）、「空車」が仮設定される（ステップＳ３２４）。

【0058】

こうして未付与のエリアの一つを選択した上で、そのエリアに判定結果を仮設定するいずれかの処理（ステップＳ３１６、Ｓ３２２、Ｓ３２４）を行なった後、すべてのエリアに判定結果が付与（設定または仮設定）されているか否かについて判断する（ステップＳ３２５）。付与が完了していない場合には（ステップＳ３２５：ＮＯ）、ステップＳ３１２に戻って、上記の処理を繰り返す。

【0059】

すべてのエリアへの判定結果の付与が完了すると（ステップＳ３２５：ＹＥＳ）、次に、各エリアに付与された判定結果に矛盾がないか否かを確認する（ステップＳ３３０）。判定結果の矛盾とは、複数のエリアに付与された判定結果が、エリア間の満空傾向に相反していることを言う。図２１に示した例では、仮設定を含む満空状況の判定結果は、同図下段に示したように、エリアＡ、Ｂが「満車」、エリアＣ、Ｄが「混雑」となり、満空傾向Ａ＞Ｂ＞Ｃ＞Ｄに矛盾しない。しかし、例えばエリア毎に行なわれた最初の満空状況の判定（例えば図１１に示した処理）により、エリアＡにプローブ車両が存在しており、「混雑」との判定結果が記憶されていれば、図２０に示した処理によって各エリアＡないしＤには、「混雑」「満車」「満車」「混雑」のように判定結果が付与される。エリアＢ、ＣはエリアＡより先に満車にならないという満空傾向が付与されていることに、これは矛盾する。

【0060】

そこで、各エリアの満空状況の判定結果に矛盾がある場合には（ステップＳ３３０：有り）、満空傾向順列に従い、これを修正する処理（ステップＳ３３２）を行なう。具体的には、上記の例では、エリアＡの満空状況の判定結果を「混雑」から「満車」に変更するのである。ステップＳ３３０で矛盾はないと判断された場合（ステップＳ３３０：なし）、または矛盾があるとされてステップＳ３３２でこれを修正した場合、満空状況の判定結果を最終的に決定する処理を行ない（ステップＳ３４０）、その後、判定結果を送信可能に準備する既述のステップＳ１５０へと移行する。ステップＳ３４０での処理は、要するに各エリア毎に行なった満空状況判定処理（ステップＳ１３０）による判定結果を、図２０に示した一連の処理により、仮設定を正式の満空状況判定結果とすることを含めて、最終的な判定結果とするものである。

【0061】

以上説明した第３実施例によれば、各エリア毎の満空状況の判定は、第１，第２実施例同様、高い精度で行なうことができ、更にその判定結果を踏まえて、複数のエリアを有する駐車場の満空状況を的確に判定することができる。特に立体駐車場などの大規模駐車場においては、判定期間（実施例では１５分）に、すべてのエリアにプローブ車両が駐車するとは限らないが、そうした場合でも各エリアについての満空状況の判定を行なうことができる。立体駐車場などでは、各フロアに至るスロープなどに各フロアの満車・空車を示す表示設備が設けられていることがあり、一旦満車と判断されて表示が行なわれると、そのフロアに駐車する車両は極端に少なくなる。従って、判定期間内にプローブ車両が駐車しないという状況は生じやすくなるが、本実施例によれば、そうした場合でも、そのエリアを引き続き「満車」と適正に判定することができる。

【0062】

次に第３実施例の変形例として、立体駐車場が商業施設などに付設されており、満空傾向順列が、必ずしも階層の順に一致しない場合について説明する。図２２に例示し駐車場は、図２１と同様、４フロアの立体駐車場ではあるものの、３階フロアに、商業施設への連絡通路が設けられている。つまり、３階フロアに施設への歩行者用出入口が存在する。この駐車場に駐車する人は、通常商業施設に向かうため、利便性の良い３階フロアのエリア駐車しようとする。このためこの駐車場の満空傾向順列は、図２２に示したように、１ないし４階をエリアＡないしＤとすると、Ｃ＞Ｂ＞Ｄ＞Ａとなる。この満空傾向順列は、商業施設に付設されたこの駐車場の実際の駐車状況をモニタした結果により決定している。もとより、駐車状況のモニタがある程度の期間行なわれるまでは、施設設計上の予想により設定しても良いし、他の類似施設でのデータを流用しても良い。

【0063】

図２２に示した駐車場に関して、第３実施例と同様の処理を行なった結果、図２２上段に示した満空状況の判定結果（エリアＡ及びＢが「不明」、エリアＣが混雑、エリアＤが空車）が得られたとする。第３実施例の変形例では、図２０に示したステップＳ３１５、Ｓ３２０における「挟まれている」「下位」は、立体駐車場のフロア順ではなく、満空傾向順列の順序に沿って判断する。このため、満空状況の判定結果が「不明」の２つのエリアＡ、Ｂに関する判断は、エリアＢについては「満空状況の判定結果が得られているエリアに挟まれている」となり（ステップＳ３１５）、エリアＡについては「下位に混在または満車と判断されたエリアはない」（ステップＳ３２０）となる。このため、エリアＢは「混雑」と判断され、エリアＡは「空車」と判断されることになる。

【0064】

以上説明した第３実施例の変形例では、歩行者用の出入口が、途中のフロアにあり、駐車の傾向が階層に従っていない場合でも、立体駐車場の各フロアにおける満空状況を、少数のプローブ車両からの情報により、高い精度で判定することができる。他の作用効果は第３実施例と同様である。

【0065】

［第３実施例の展開］
第３実施例では、ステップＳ３３０ないしＳ３４０の処理により、満空状況の判定結果と、各エリアに付与された満空傾向順列との間に矛盾がないかを判断し、矛盾がある場合には、これを解消するよう、各エリアの満空状況の判定結果を修正している。この手法は、単に立体駐車場など複数のエリアを有する駐車場における判定のみならず、判定期間毎に行なわれた満空状況の判定結果の時系列的な変化にも応用することができる。

【0066】

例えば、判定期間の直前に「満車」と判定されていたエリアが、少ない台数のプローブ車両からの駐車情報により、「空車」と判定された場合、僅かな時間（本実施例では１５分）で「満車」から「空車」に変化することは考えにくいとして、判定結果を直前の判定期間での判定結果「満車」のまま維持する、または「混雑」にするといった態様を採用することができる。このとき、駐車情報を提供するプローブ車両の台数が多ければ、そのまま判定結果を用い、２台以下などの条件で、時系列的な修正を行なうものとしても良い。

【0067】

［変形例］
次に、変形例について説明する。図２３は、時系列的に満空状況の判定がなされている様子を示す説明図である。図示横軸は、各判定期間Ｔｚを示し、縦軸はその判定期間内に得られたプローブ車両からの情報の件数を矩形の領域の数により示す。ハッチングの施されていない領域は「空車」と判定した車両の数を、シングルハッチの施された領域は「混雑」と判定した車両の数を、ダブルハッチの施された領域は「満車」と判定した車両の数を、それぞれ各矩形の高さにより示している。また各期間Ｔｚの下には、修正前の判定結果を「従来」として示し、本実施例で修正された判定結果を「実施例」として示した。

【0068】

第１実施例では複数の満空状況の判定結果が得られた場合には、より混雑している側の駐車情報を用いて判断した。また第２実施例では、複数のプローブ車両からの駐車情報の平均的な値を用いて判断した。これに対して。変形例では、判定結果が最も多いものを採用している。つまり多数決により、満空状況の判定結果を決定している。なお、この判定結果に対して、第３実施例で示した修正の考え方を適用することも可能である。また、判定期間内における全判定結果の数が増加傾向にあると判断できる場合（例えば、判定期間Ｔｚ３、Ｔｚ７）などには、駐車する車両の数が増えつつあるとして、一つ前の期間での判定結果を参照して、最終的な判定結果とすることができる。例えば、判定期間Ｔｚ３であれば、判定結果は「空車」だが、一つ前の期間での判定結果は「混雑」なので、これを採用するものとしても良い。同様に、判定期間Ｔｚ７のように、判定結果が「混雑」であっても、プローブ車両の数が増加傾向にあり、一つの前の期間での判定結果が「満車」であれば、判定結果を「満車」に修正することも好適である。

【0069】

上述した第３実施例では、満空傾向順列は、立体駐車場など一施設内に複数のエリアがある場合を想定して説明したが、複数の駐車場間に満空傾向順列を設定して、複数の駐車場での満空状況の判定を行なうことも可能である。例えば図２４に例示したように、大規模商業施設ＬＳＭの周辺に４つの駐車場（エリア）Ｐ１、Ｐ２、Ｐ３、Ｐ４が存在するとして、これらの駐車場に、満空傾向順列として、
Ｐ２＞Ｐ３＞Ｐ１＞Ｐ４
を設定する。また、この満空傾向順列は、大規模商業施設ＬＳＭからの距離のみに基づいて付与するものではなく、利便性を基準に付与してある。駐車場Ｐ１は、駐車場Ｐ３より直線距離では近いものの、駐車した人は橋を渡って大規模商業施設ＬＳＭに向かうことになるため、歩く時間が長くなり、利便性は、駐車場Ｐ３より低いと判断されている。このように、複数の駐車場Ｐ１〜Ｐ４に、満空傾向順列を設定しておき、第３実施例の手法を適用して、例えばプローブ車両からの情報により、駐車場Ｐ３が「満車」と判定される状況になっていれば、駐車場Ｐ２に関する駐車情報が得られなくても、これを「満車」と判定することができる。

【0070】

図２４に示した複数駐車場の満空傾向の判定は、センタサーバ５０によって行なっても良いが、各駐車場の満空状況の判定を個別に行なう駐車場満空判定装置を駐車場毎に設け、その判定結果を、地域に設けられた地域駐車場満空判定装置に送信し、地域駐車場満空判定装置によって複数の駐車場の満空傾向の判定を行なうものとしても良い。この場合、各駐車場満空判定装置は、インターネットなどの汎用ネットワークあるいは専用回線等により接続され、定期的にあるいは地域駐車場満空判定装置からの問い合わせに応じて、各駐車場の満空状況の判定結果を、地域駐車場満空判定装置に送信するものとすればよい。こうした複数の駐車場満空判定装置構成をネットワークなどで結んだ構成を採用すれば、地域全体の駐車場の満空状況をより的確かつ柔軟に判断することができる。各駐車場における満空状況の判断とは別に、地域全体の車の流れや駐車を生じさせる要因を細かく設定できるからである。また複数の駐車場を対象とすることから、駐車場内に存在するプローブ車両の総数も増加することが期待され、判定の精度向上に資することができる。

【0071】

地域における複数の駐車場の満空傾向順列を設定する場合、近隣の施設としては、単一の施設に限る必要はなく、複数の施設を想定して、満空傾向順列を設定することも差し支えない。例えば、図２５、図２６に示したように、大規模商業施設と野球場のようなスポーツ施設が隣接して存在する場合、両施設にとっての利便性を考えて、満空傾向順列を設定すれば良い。例えば両施設から共に遠い駐車場が「満車」と判定されていれば、両施設に対してその駐車場より近い駐車場を「満車」と判定することは容易である。あるいは、施設の性質によっては、季節や時間帯により、満空傾向順列を変更することも望ましい。図２５、図２６に示した例では、野球場は１１月から２月の利用が少ないこと、また３月から１０月でも昼〜夕方の利用は少ないと想定されることから、各駐車場の満空傾向順列は、ＰＰ１＞ＰＰ２＞ＰＰ３＞ＰＰ４となる。他方、３月〜１０月の夜から深夜にかけては、各駐車場の満空傾向順列を設定は、これとは丁度逆となる。

【0072】

このように、複数の施設に対して季節や時間などの条件により、満空傾向順列を設定を変更すれば、各駐車場の満空状況の判定を更に精度良く行なうことができる。もとより、季節や時間だけでなく、イベントの開催や事故の発生などの事象の有無により、満空傾向順列を設定するようにしても差し支えない。例えば、野球場で、人気タレントの野外コンサートが昼間に行なわれることが分かっていれば、この時間帯について満空傾向順列を、図２６に示したものに設定するなどの対応を取ることができる。また、特定の駐車場の周辺で事故が起きた場合には、その駐車場での満空状況の判定を「満車」側に修正しても良い。事故発生現場の近くに車両を誘導しない方が望ましいからである。こうした種々の対応を行なう場合、各駐車場毎の満空判定を行なう装置と、地域全体の満空判定を行なう地域駐車場満空判定装置とを分けておくと、システム設計やその変更が容易となる。

【0073】

上述した各実施例において、駐車情報は、いずれも駐車所要時間と駐車距離（歩行者用出入口までの距離）としたが、図２に示したように、駐車距離に基づいてエリアを設定しておけば、駐車情報としては駐車所要時間だけで足りる。また、駐車情報は、駐車所要時間と駐車距離に限るものではなく、例えば駐車時刻などの他の情報を加えるものとしても良い。この場合、図９などに示した判定用のマップは、三次元にすればよい。駐車時刻の情報を加えれば、満空傾向順列が利用しやすくなる。あるいは車両ナビシステム２０において目的地として設定された施設名などを含む場合には、図２５、図２６に示した地域における駐車場の満空状況の判定に利用することができる。３月から１０月の間の夜に、駐車場ＰＰ１に駐車した車が、車両ナビシステム２０において、大規模商業施設を目的地に設定していれば、そのプローブ車両の駐車情報を、他の駐車場ＰＰ２ないしＰＰ４の満空状況の判定に反映させる必要はないと判断することができる。また、駐車情報に含まれ、判定に用いられるパラメータがＮ個になれば、Ｎ次元のマップを用意すれば良い。

【0074】

以上本発明のいくつかの実施例について説明したが、本発明はこれらの実施例に限られるものではなく、本発明の要旨を逸脱しない範囲内において種々の態様で実施できることはもちろんである。例えば、上記実施例では、駐車場の満空判定システム１０は、プローブ車両ＡＭとセンタサーバ５０と各種端末とから構成したが、いずれの処理をどの装置において実施するから任意である。例えばプローブ車両では、車両の位置の情報だけを検出するものとし、駐車情報をセンタサーバ５０側で生成するものとしても良い。あるいは逆に、全ての装置構成を、端末、例えば車両８０に集約することも可能である。また、センタサーバ５０は、駐車場についての満空情報の問い合わせを端末から受け取ったか否かに関係なく、満空情報の判定結果の情報を定期的に送信するようにしてもよい。もとより、定期的な送信と共に、端末からの問い合わせを受け取ったときにも送信するものとしても良い。さらにこの場合は、対象となる駐車場付近に設置した路上通信設備から、ＰＨＳや無線ＬＡＮ等の狭域エリア通信を利用して、情報を送受信するものとしても良い。エリアの利便性は、歩行者用出入口からの距離である駐車距離に限らず、例えば施設への移動がエレベータ、エスカレータ、動く歩道などの有無などにより判断するものとしても良い。あるいは駐車料金が駐車場内で相違する場合には、駐車料金を利便性とみて、指標を付与するものとしてもよい。

【符号の説明】

【0075】

１０…駐車場満空判定システム
２０…車両ナビシステム
２１…制御部
２２…地図データベース（地図ＤＢ）
２４…ＧＰＳ受信部
２５…車載センサ
２６…表示部
２７…通信部
５０…センタサーバ
５１…ＣＰＵ
５２…メモリ
５４…駐車場データベース
５５…通信部
６０…携帯電話
７０…タブレット端末
８０…車両
９０…コンピュータ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】