JP6337344B2 - 複数のカメラを用いた単一の複数車両用駐車スペースの使用制御 - Google Patents

Description

本発明は、カメラを用いて車両を識別し、車両による駐車スペースの使用を追跡して制御することに関する。

様々な公営及び私営の駐車場オペレータは、車両駐車スペースなどの車両の目的地の使用を管理してその使用者から利益が得られるように大規模なレガシー駐車管理システムを有している。従来、このようなレガシーシステムを完全自動化にアップグレードするために必要とされてきた大幅な補修及び出費には相当な先行設備投資が伴い、多くの駐車場オペレータがこのようなアップグレードを行う妨げとなっている。

米国特許第７，０１６，５１８号明細書

既に設置されていてしばらく運用されているシステムを含む既存の駐車場支払システムと容易に統合される、完全に自動化された自律的駐車管理システムが必要とされている。これにより、駐車施設オペレータにとって、これまでに未開発の新たな収入機会及び効率が解き放たれるようになる。

ある実施形態では、少なくとも１つの目的地の使用を追跡する方法が提供され、この方法は、複数のカメラによって取り込まれた複数の車両画像を受け取るステップを含み、各車両画像は、第１の車両の画像を含み、複数のカメラは、第１の識別カメラと目的地カメラとを含み、車両画像は、第１の識別カメラによって取り込まれた１又はそれ以上の第１の識別画像を含み、目的地カメラによって取り込まれた複数の目的地画像は、第１の時刻に取り込まれた第１の目的地画像、第１の時刻よりも後の第２の時刻に取り込まれた第２の目的地画像、及び第２の時刻よりも後の第３の時刻に取り込まれた第３の目的地画像を含み、この方法は、第１の識別画像に基づいて第１の車両の第１の一意の識別子を特定するステップと、第１の識別画像に基づいて第１の車両の第１の複数の特徴を特定するステップと、目的地画像の１つ又はそれ以上に基づいて車両の第２の複数の特徴を特定するステップと、第２の複数の特徴が第１の複数の特徴に対応すると判断するステップと、第２の複数の特徴が第１の複数の特徴に対応するという判断に基づいて、第１の車両の画像が複数の目的地画像に含まれると判断するステップと、第１の目的地画像及び第２の目的地画像に基づいて、第１の車両が第２の目的地位置に停止していると判断するステップと、第３の目的地画像に基づいて、第１の車両が第１の目的地から離れたと判断するステップと、第１の車両が第１の目的地の使用を第１の時刻に開始したことを示すステップと、第１の車両が第１の目的地の使用を第３の時刻に完了したことを示すステップとを含み、上述の受け取るステップ、特定するステップ、判断するステップ及び示すステップは、上述のステップを実行するように集合的にプログラムされた１又はそれ以上のコンピュータによって実行される。

非一時的コンピュータ可読媒体が命令を含み、この命令は、実行時に１又はそれ以上のコンピュータに、複数のカメラによって取り込まれた複数の車両画像を受け取らせ、各車両画像は、第１の車両の画像を含み、複数のカメラは、第１の識別カメラと目的地カメラとを含み、車両画像は、第１の識別カメラによって取り込まれた１又はそれ以上の第１の識別画像を含み、目的地カメラによって取り込まれた複数の目的地画像は、第１の時刻に取り込まれた第１の目的地画像、第１の時刻よりも後の第２の時刻に取り込まれた第２の目的地画像、及び第２の時刻よりも後の第３の時刻に取り込まれた第３の目的地画像を含み、この命令は、第１の識別画像に基づいて第１の車両の第１の一意の識別子を特定させ、第１の識別画像に基づいて第１の車両の第１の複数の特徴を特定させ、目的地画像の１つ又はそれ以上に基づいて車両の第２の複数の特徴を特定させ、第２の複数の特徴が第１の複数の特徴に対応すると判断させ、第２の複数の特徴が第１の複数の特徴に対応するという判断に基づいて、第１の車両の画像が複数の目的地画像に含まれると判断させ、第１の目的地画像及び第２の目的地画像に基づいて、第１の車両が第２の目的地位置に停止していると判断させ、第３の目的地画像に基づいて、第１の車両が第１の目的地から離れたと判断させ、第１の車両が第１の目的地の使用を第１の時刻に開始したことを指示させ、第１の車両が第１の目的地の使用を第３の時刻に完了したことを指示させる。

開示する主題によって得られる様々な利点としては、以下に限定されるわけではないが、（１）干渉不要な自力駐車違反取締の提供、（２）既存の「適所」に存在する駐車料金支払インフラに統合される干渉不要な自力駐車違反取締の提供、（３）駐車区画などの大きな空地内の駐車スペースの管理にとって重要な要素である、たった１つ又は非常にわずかな車両の存在を識別する近接センサに依拠する技術に比べて少ない数のセンサ、及び関連する設置コストの削減、（４）商業的な既存（ＣＯＴＳ）の技術の活用、及び車両検出及び駐車取締のための関連する設備コストの削減、（５）特にカメラから離れて画像処理が行われる実施形態では、ソフトウェアベースの車両検出技術の改善を、システム全体を通じて素早く更新することができ、駐車管理システム全体を通じてハードウェアの変更を伴わずに車両検出の向上を実現すること、及び（６）システム全体にわたって、又はより狭く定められた駐車スペースの一部に関連してシステムの挙動を素早く変更する能力、が挙げられる。

開示する主題による総合システム１００の例を示す図である。 識別カメラによって取り込まれた画像の例を示す図である。 識別カメラによって取り込まれた画像の例を示す図である。 目的地カメラによって取り込まれた画像の例を示す図である。 目的地カメラによって取り込まれた画像の例を示す図である。 視野が重なり合ったカメラによって取り込まれた画像を用いて、いかにして車両を識別し、目的地までの車両の移動を追跡し、車両による目的地の使用を識別するかを示す図である。 本発明の態様を実装できるコンピュータシステム５００を示すブロック図である。 第１のカメラからの画像が表示されたＧＵＩの一部を示す、カメラの視野の特徴を指定するためのグラフィカルユーザインターフェイス（ＧＵＩ）の態様を示す図である。 第２のカメラからの画像が表示されたＧＵＩの一部を示す、カメラの視野の特徴を指定するためのグラフィカルユーザインターフェイス（ＧＵＩ）の態様を示す図である。

図１に、開示する主題による総合システム１００の例を示す。ネットワーク１１０は、図１に示す要素間のデータ通信サービスを提供する。以下に限定されるわけではないが、イーサネット（登録商標）、８０２．１１無線及びセルラーデータネットワーキング技術を含む多くのネットワーキング技術が存在し、当業者であれば、図示の要素間のデータ交換のためにこれらの技術を確実に予測通りに統合することができる。ある実施形態では、別個のネットワークを使用することができる。例えば、カメラ１２０及び１２５、並びにサーバ１４０が第１のネットワークを介して通信し、他の要素が公衆インターネットを介して通信することができる。当業者であれば、独立した第１のネットワークを使用することにより、信頼性及び安全性のための所望の目的を実現することができる。

識別カメラ１２０は、システム１００に含まれる複数のこのようなカメラの１つを示すものである。説明の便宜上、図１には１つの識別カメラ１２０しか示していない。識別カメラ１２０は、以下に限定されるわけではないが、自動車ナンバープレートなどの車両識別子の画像、或いは車両識別子を提供する、以下に限定されるわけではないが、ＱＲコード（登録商標）又はバーコードなどの形式の、車両に取り付けられたラベルの画像を取り込めるように位置付けられる。識別カメラ１２０によって取り込まれた画像１２１などの画像は、１又はそれ以上の目的地カメラ１２５によって取り込まれた画像と共に、車両１３０などの個々の車両を識別してこれらの車両による様々な目的地の使用を記録するために使用される。車両の目的地の例としては、以下に限定されるわけではないが、駐車スポットなどの様々な制約を受ける可能性はあるが駐車に適しているとして指定された範囲、及び以下に限定されるわけではないが、バス停、消防車専用車線、消火栓周囲の範囲、歩道、交差点からＸフィート以内の範囲、私道、安全地帯、中央分離帯、自転車レーン、横断歩道などの、駐車に適していないとして指定された範囲を含む。例えば、サーバシステム１４０は、車両がいつバス停に停車したかを特定し、この特定に基づいて、車両の牽引要請又は郵送による違反切符の発行などの要求又は措置を行うように構成することができる。ある実施形態では、指定駐車スペース内に車両が正しく駐車されていないこと、縁石から１フィートを超えて駐車されていること、左側車輪を縁石に向けて駐車している（誤った方向を向いて駐車している）こと、後部からの斜め駐車、放置車両（Ｘ日又はそれ以上の日数にわたって特定の場所に放置されていること）などの、その他の駐車違反を識別することができる。ある実施形態では、識別カメラが、例えばスマートフォンに含まれるカメラを含むモバイル又はハンドヘルドカメラを含むこともできる。

目的地カメラ１２５は、システム１００に含まれる複数のこのようなカメラの１つを示すものである。説明の便宜上、図１には１つの目的地カメラ１２５しか示していない。目的地カメラ１２５は、以下に限定されるわけではないが、自動車駐車スポットなどの１又はそれ以上の目的地の画像を取り込めるように位置付けられる。通常、目的地カメラ１２５は、以下に限定されるわけではないが、街灯又は電柱上、或いは建物の表面又は屋上などの高い位置に設置される。目的地カメラ１２５を高い位置に設置することにより、目的地カメラ１２５によって取り込まれる画像１２６などの画像の視野が複数の目的地を含むことができ、従って目的地カメラ１２５を使用して複数の目的地をモニタすることができる。ある実施形態では、目的地カメラが、例えばスマートフォンに含まれるカメラを含むモバイル又はハンドヘルドカメラを含むこともできる。ある実施形態では、目的地カメラを駐車メータ本体に含めることができる。ある実施形態では、人工衛星撮像カメラによって目的地カメラを提供して、市町村全体に目的地カメラを設置する必要性を潜在的に排除することができる。ある実施形態では、以下に限定されるわけではないが、小型飛行船又はその他の飛行船、或いは無人飛行体などの飛行体に目的地カメラを含めて、飛行時間いっぱいにわたって自律的に動作させることができる。

識別カメラ１２０及び目的地カメラ１２５は、各々がそれぞれの通信リンク１２７及び１２８を介してネットワーク１１０と直接通信するように構成することができる。別の実施形態では、識別カメラ１２０を、通信リンク１２７を介してネットワーク１１０と直接通信するように構成するのではなく、通信リンク１２９を介して目的地カメラ１２５と通信し、目的地カメラ１２５が通信リンク１２８を介してネットワーク１１０と通信して識別カメラ１２０との間でデータを中継するように、目的地カメラ１２５と直接通信して目的地カメラ１２５を通じてデータを中継するように構成することができる。通信リンク１２９は、無線ネットワークリンクとすることができる。図１には、２つのカメラ１２０及び１２５間に通信リンク１２９を含めた例を示しているが、この例は、複数のカメラを通じてデータを中継することによって所与のカメラとの間でデータ送信が行われるように拡張することができる。また、複数のカメラ間に無線メッシュネットワークを確立し、これらのカメラ間に耐故障性で自己構成型の無線通信媒体を提供することもできる。配線リンクの代わりに無線通信を使用することにより、システム内の全体的な配線通信リンクの数、並びにこのような配線リンクを設置して維持することに関連する出費及び労力を減少させることができる。また、一般にセルラーデータ通信のコストは配線リンクを介したものよりも大幅に高いので、このことは、例えばネットワーク１１０にデータを搬送するためにセルラーデータ通信を使用することに代わる有用な選択肢の役割を果たすこともできる。しかしながら、無線通信は必須ではなく、一部又は全部のカメラが配線リンクを介して通信することもできる。

サーバシステム１４０は、中央データ記憶サービス、データ検索サービス及び処理サービスを提供する１又はそれ以上のコンピュータシステムを含む。一般に、サーバシステム１４０に含まれるコンピュータシステムの各々は、ランダムアクセスメモリ１４２及びプロセッサ１４３を含む。サーバシステム１４０は、車両による駐車スペースなどの目的地の使用、車両のアカウント情報、識別カメラ画像を介して取得された車両の識別、目的地カメラ画像を介して取得された車両の観察記録、目的地の予約情報、課金情報及び支払情報などの情報を記録するために使用されるデータベース１４１を含む。データベース１４１は、例えば、ＭｙＳＱＬ、Ｏｒａｃｌｅ又はＤＢＡＳＥなどのソフトウェアプログラムを用いて実装することができる。データベース１４１は、複数のコンピュータシステムにわたって実行される複数のデータベースインスタンスを含むことができる。

ある実施形態では、サーバシステム１４０が、識別カメラ１２０などの識別カメラ及び目的地カメラ１２５などの目的地カメラによって取り込まれた画像から車車間識別認識を行うように構成される。さらに、サーバ１４０は、この認識された情報に基づいて、及び目的地の使用が目的地の使用制限に違反している時に、目的地の使用を決定することなどの意思決定を行うように構成される。画像処理及び意思決定がサーバシステム１４０に集中するこの実施形態は、マイクロプロセッサ内のトランジスタ数及び対応するデータ処理容量が１８カ月毎に倍増するというムーアの法則、及び帯域幅速度が１年に５０％ずつ成長すると仮定するニールセンの法則を活用する。この集中化方式によってかなりの利益を実現することができる。これまでの安価で高速なＣＰＵパワーによってサーバアプリケーションの知能／機能の豊富さを急速に高めることができるだけでなく、新たな機能及び用途を現場の「シンクライアント」装置にまで急速に広げることもできる。システム全体を通じてＣＯＴＳ（民生品）部品を使用することにより、一般に製造コストは削減される。また、ネットワークを介して利用できる技術サービスのアップデートを利用するために、高度にネットワーク化されたシステムが良好に位置付けられる。最後に、マイクロプロセッサ及び帯域幅のコストが減少し続けるので、サイズ又は容量を拡大するコストを下がり続けるコストで実現することができる。

別の実施形態では、いくつかの機能をシステムの他の構成要素に分散させることができる。例えば、識別カメラ１２０を、取り込み画像内におけるナンバープレート番号などの車両識別情報の存在を識別するように構成することができる。このような実施形態では、識別カメラ１２０が、例えば画像内の車両の存在を識別でき、画像内の車両識別情報の存在を識別でき、及び／又は画像から車両識別情報を抽出できる画像処理機能を実行することができるさらに高性能な装置である必要があるという点で、識別カメラ１２０とサーバシステム１４０の間のデータ通信帯域幅の量、及びサーバシステム１４０が行わなければならない処理の量をトレードオフによって大幅に削減することができる。別の例として、サーバシステム１４０を用いて車両画像の特徴を特定するのではなく、以下で図４に関連して詳述するように、識別カメラ及び目的地カメラを、車両画像の特徴を特定するようにプログラムすることもできる。システム全体を通じてどのように機能を分散できるかは、カメラによって取り込まれた画像を処理のために中心位置に搬送するための予想コストに対して重み付けした、（識別及び／又は目的地カメラに必要な処理ハードウェア及びプログラミングを提供することなどの）分散機能を提供する予想コストに依存する。通信ボトルネックに対処するために、サーバシステム１４０から識別カメラ１２０へのように１つのコンピュータシステムから別のコンピュータシステムにプログラム機能を移動させ、これらの機能を実行するのに十分な処理リソースが様々なコンピュータシステムに確実に提供されるようにすることは、当技術の範囲内に十分に収まる日常的課題である。

モバイル装置１５０は、プログラマブルコンピュータ、識別カメラ及びサーバシステム１４０と通信するための無線データ通信能力を含む。一例では、車両１３０が目的地を使用しているが、車両１３０の一意の識別符号が特定されなかった場合、目的地にモバイル装置１５０を派遣し、車両１３０の画像１５１を取り込み、この画像から車両１３０の一意の識別符号を取得することができる。モバイル装置１５０は、識別カメラ１２０が行うようにナンバープレートの画像を取り込むことに加え、車両のＶＩＮ識別子タグを取り込むように構成することもでき、このことはナンバープレートのない車両に対して役立つことができる。このことは、車両１３０が識別カメラ１２０の視野を通過した時に別の車両によって遮られ、識別カメラ１２０が車両１３０を一意に識別するのに効果的な画像を撮影できない場合などの偶発的状況を克服する役に立つ。サーバシステム１４０によって管理されている全ての目的地にわたるタイムリーな画像の取り込みをさらに確実にするために、システムに複数のモバイル装置を含めることもできる。ある実施形態では、モバイル装置１５０を、駐車違反取締に役立つ機能を提供するように構成することもできる。例えば、モバイル装置１５０を、サーバシステム１４０によって識別された駐車違反について紙の違反切符を印刷するように構成することができる。

オンサイト支払システム１６０は、一般に１又はそれ以上の目的地の近くに配置される直接的な物理インターフェイスを提供する複数の装置のうちの、エンドユーザが目的地の使用に関する支払い又は支払い同意を提出できるようにするためのものである。支払システム１６０の例としては、以下に限定されるわけではないが、個々の目的地専用の駐車メータ、複数の路上駐車スペースに関連する支払ステーション、及び駐車区画又は駐車場ビルに設けられた、目的地のための支払ステーションが挙げられる。ある実施形態では、オンサイト支払システム１６０が、１又はそれ以上の目的地の画像を取り込む目的地カメラを含むことができる。

エンドユーザシステム１７０は、車両１３０のドライバーなどのエンドユーザがサーバシステム１４０とやりとりできるようにするプログラマブルコンピュータシステムである。このようなシステムの例としては、以下に限定されるわけではないが、ウェブブラウザアプリケーションを含むデスクトップコンピュータシステム、ウェブブラウザアプリケーション又は専用駐車アプリケーションを含むスマートフォン、及び車両１３０に含まれる車載システムが挙げられる。エンドユーザシステム１７０は、例えば、サーバシステム１４０と反復的にやりとりするためのエンドユーザアカウントの作成、目的地の使用予約、利用可能な目的地の識別要求、及び目的地の使用に関する支払情報の提出に使用することができる。

ある実施形態では、エンドユーザシステム１７０を、所与の範囲の利用可能な目的地を記述する情報をサーバシステム１４０に要求して取得するように構成することができる。一例では、エンドユーザシステム１７０を、駐車場ビル内の目的地又は路上駐車ではない（駐車区画などの）目的地などの、許容できる目的地のための特定の基準の取得及び／又は要求を行うようにさらに構成することができる。エンドユーザシステム１７０は、位置情報に加え、以下に限定されるわけではないが、所与の目的地の利用コストなどのその他の情報を取得することもできる。エンドユーザシステム１７０は、現在利用可能な目的地、及び／又は将来的な指定時刻又は時間範囲に利用可能な目的地の情報を要求して取得するようにさらに構成することができる。エンドユーザシステムは、サーバシステム１４０から取得された利用可能な目的地のうちの１又はそれ以上の目的地の特定の位置を地図上などに示すグラフィカルユーザインターフェイスをエンドユーザに提供するようにさらに構成することができる。ある実施形態では、（駐車場ビル又は駐車区画などの）駐車施設において複数の目的地が利用可能な場合、エンドユーザシステム１７０を、各目的地を個別に識別するのではなく、駐車施設における目的地の利用可能性を大まかに示す（場合によっては利用可能な目的地の数を示す）ように構成することができる。エンドユーザシステム１７０は、選択された目的地の指示をエンドユーザから受け取るように構成することができる。エンドユーザシステム１７０は、選択された目的地までの、どこで曲がるかの指示などのガイドを行うようにさらに構成することができる。エンドユーザシステム１７０は、利用可能な目的地の使用を予約するようにサーバシステム１４０に命令するようさらに構成することができる。

手動再確認システム１８０は、車両１３０などの車両を識別するように人間オペレータ１８１がサーバシステム１４０を支援するためのプログラムドコンピュータシステムである。例えば、サーバシステム１４０は、識別カメラ１２０によって取り込まれた画像１２１などの画像から、車両１３０の一意の識別子の自動化された機械ベースの特定を行っている際に、エラーが発生したと判断することがある。サーバシステム１４０は、このエラーに応答して、車両１３０のナンバープレート番号などの一意の識別子を特定するように人間オペレータ１８１による支援を要求することができる。手動再確認システム１８０は、人間オペレータ１８１が画像１２１を、また場合によっては識別カメラ１２０又はその他のカメラによって取り込まれた他の画像を再確認できるようにするユーザインターフェイスを提供する。例えば、人間オペレータ１８１は、車両のナンバープレート番号及び州／県の情報を手動で特定するために、手動によるビデオ映像の巻き戻し及び静止画像の早送りを行うことができる。人間オペレータ１８１は、このインターフェイスを介して車両１３０の識別符号を提供することができ、或いは人間オペレータ１８１が車両１３０の識別符号を特定できなかった旨を示すことができ、この結果、車両１３０の積極的な識別を行うために目的地にモバイル装置１５０を派遣することができる。サーバシステム１４０が処理する情報量に応じて、サーバシステム１４０が複数の手動再確認システム１８０を利用できるようにすることもできる。また、人間オペレータ１８１は、以下でさらに詳細に説明するライブオペレータチームのメンバとすることもできる。

ある実施形態では、識別カメラ及び目的地カメラの１つ又はそれ以上が、これらのカメラからサーバシステム１４０に送信される画像よりも高いフレーム率及び／又は解像度で画像を取り込む。このようなカメラによって取り込まれた画像データは全てサーバシステム１４０に送信されるわけではないが、高価な可能性のあるネットワーク通信帯域幅（例えば、セルラーデータネットワーク）及びサーバシステム４１０において利用できる限られた画像処理リソースを節約するために、このようなカメラは、これらが取り込んだ限られた量のフル画像データを循環バッファなどにバッファリングすることができる。また、このようなカメラは、例えばナンバープレートの認識に役立つことができる高解像度画像の部分を含むこのような追加画像データを求める要求に応答するように構成される。この機構により、サーバシステム１４０は、車両の識別及び追跡に追加画像が役立つと自動的に判断することができ、或いは手動再確認システム１８０は、サーバシステム１４０によって生じたエラーを解決するために様々な画像を要求することができる。

駐車場運営システム１９０は、駐車施設オペレータがサーバシステム１４０とやりとりしてサーバシステム１４０を制御できるようにするプログラムドコンピュータシステムである。サーバシステム１４０は、時間の大半にわたり、駐車場オペレータによる入力をほとんど必要とせずに自律的に動作すると予想される。しかしながら、時には、駐車施設のオペレータ職員がその動作に積極的に参加する場合もある。例えば、駐車場運営システム１９０は、どれほどの及びどの目的地が使用中及び／又は利用可能であるかに関するライブ指示を提供することができる。別の例として、駐車場運営システム１９０は、車両が使用制限に違反している目的地に関するライブ指示を提供し、必要と考えられる時に駐車施設のオペレータ職員がこのような違反に対して対策を取れるようにすることができる。

図２Ａに、識別カメラ１２０によって取り込まれた画像１２１の例を示しており、この場合、識別カメラ１２０は、その側を通過する車両の識別情報を効果的に取り込むように配置されている。ある実施形態では、識別カメラ１２０が、ナンバープレート情報などの識別情報の画像を含むビデオをサーバシステム１４０にストリーミングする。典型的な街灯の高さは約１８フィートであるため、これらの街頭は、木及び近くを通る車両を含む他の障害物から離れた明瞭な見通し線の恩恵を受ける優れた識別カメラ設置位置を提供する。また、既に街灯に電力が供給されている時には、その街灯から電力を引き込むように識別カメラを設置することができる。また、多くの都市条例では、通りの各サイトの１ブロック毎に少なくとも１つの街灯が必要とされているので、街灯に設置された識別カメラは、通りを往来するあらゆる車両のための十分なカバレッジを提供することができる。

識別カメラ１２０によって取り込まれた識別画像は、（１）車両の前方又は後方に取り付けられたナンバープレートから識別子などを読み取ることなどによって車両の一意の識別符号を取得すること、及び（２）図４に関連して後述するように、別のカメラによって取得された車両の画像が識別車両に対応すると判断できるように車両の様々な特徴を特定すること、という２つの主な目的のために使用される。図２Ａに示す識別画像例では、車両のビュー及びそのナンバーをサーバシステム１４０による処理に利用することができる。複数の識別画像を用いて、移動速度及び移動方向などの車両特徴の特定することができる。

当業では、ナンバープレートリーダの分野において、車両識別子の確実な読み取りに有効な画像を様々な照明及び車両条件下で確実に取り込むための様々な技術が周知である。１つの非限定的な例が米国特許第７，０１６，５１８号に記載されており、この特許はその全体が引用により本明細書に組み入れられる。ある実施形態では、夜間に自然照明が存在しないことによって生じる、目的地を使用するための制限が日中にしか有効でないという問題を避けることができる。

ある実施形態では、車両識別子を取得するためのマシンビジョン技術を識別カメラ１２０によって実行することができる。このような実施形態では、識別画像の代わりに車両識別子を送信できるので、識別カメラ１２０からサーバシステム１４０に送信されるデータの量を大幅に削減することができる。しかしながら、サーバシステム１４０が車両特徴の記憶及び／又は特定を行えるように１又はそれ以上の識別画像をサーバシステム１４０に送信することもできる（ある実施形態では、これも識別カメラ１２０によって行うことができる）。

ある実施形態では、サーバシステム１４０が、場合によっては車両の角度又は後続車両の接近などのいくつかの特定条件の結果として、車両識別子の一部しか取得できていないと認識することができる。このような場合、サーバシステムは、第２の識別カメラによって取り込まれた第２の識別画像にさらに依拠して識別子の残り部分を取得することができる。

図２Ｂに、識別カメラ１２０によって取り込まれた画像１２１の例を示しており、この場合、識別カメラ１２０は、その視軸に沿って延びる道路を通じて都市交差点に出入りする車両の識別情報を効果的に取り込むように配置されている。この識別画像では、サーバシステム１４０による処理にとって３台の車両のビューが有効であることにより、１つの画像から３台の車両全ての一意の識別子を取得できるようになる。

ある実施形態では、識別カメラ１２０が、パン、チルト及び／又はズーム能力を有することができ、これらの能力は、サーバシステム１４０が車両のより詳細なビューを取得するために使用することができ、或いは駐車施設のオペレータ職員が、駐車場運営システム１９０のユーザインターフェイスを介して、識別カメラ１２０から見える特定の関心領域をモニタするために使用することができる。このような実施形態では、サーバシステム１４０を、識別カメラ１２０の視野を変更しながら車両特徴を正確に特定するために座標変換を行うように構成することができる。

ある実施形態では、車両が識別カメラ１２０の視野内に現れた時に、サーバシステム１４０が６つのタスクのうちの１つ又はそれ以上を実行する。サーバシステム１４０は、第１のタスクにおいて、識別カメラ１２０によって取り込まれた１又はそれ以上の画像に基づいて１又はそれ以上の車両の存在を検出する。ある実施形態では、サーバシステム１４０を、車両と背景の色の違いに基づいて車両の存在を検出し、潜在的な車両の全体的形状のサイズが、あらゆる適用可能なズームレベルに合わせて調整された指定最小車両サイズよりも大きいと判定するように構成することができる。具体的には、このようなアルゴリズムは、画像内の全ての画素の色を互いに比較することができる。画素は、行と列に分割される（例えば、絶対位置２１，３４は、行２１列３４に位置する画素を表すことができる）。画像は、以下に限定されるわけではないが、消火栓、歩行者、車、芝生、又は道路標識／道路塗装などの他の非車両物体を含む可能性があるので、このアルゴリズムは、類似色の画素グループを検出するように構成することができる（類似していると見なされる色の範囲はシステム設定において指定することができ、類似色は、カラーチャートによって示される色調を参照して最大で２色調の違いとすることができる）。次に、これらの画素の位置を数学的に計算して、最小車両サイズよりも大きな形状を形成しているかどうかを判定する（例えば、１０×３０の相対的サイズは、１０行×３０列の大きさの形状を表すことができる）。識別カメラ１２０によって取り込まれた画像内に現れる車両は、視野角に起因して矩形よりもむしろ平行四辺形に見える傾向にある。従って、この判定は、この要素を考慮することができる。

例えば、太陽の反射、フロントガラス領域又はルーフラックに起因する、検出された形状内の「穴」又は不完全性に対処するようにさらなる微調整を行うことができる。例えば、このアルゴリズムは、通常は同じ色であるボンネット、屋根及びトランクなどの車両部分に対応することができる、互いに一定距離（又は画素）以下離れた特定の最小サイズの形状の数を指定することができる。

車両が検出されると、例えば、日付、時間、車両の色、車両のサイズ、画素の位置及びズームレベルを含む情報と共に、識別カメラ１２０に対応するデータベース１４１の部分にエントリを記録する。この情報を車両の他の検出物と共に使用して車両を識別することができる。或いは、このような情報をＲＡＭなどの揮発性メモリに一時的に記録することもできる。

サーバシステム１４０は、第２のタスクにおいて、ナンバープレートの存在、及び／又は以下に限定されるわけではないが、識別カメラ１２０によって取り込まれた画像内の車両のステッカー（ｄｅｃａｌｓ）などのさらなる識別符号を検出する。ナンバープレート及び／又はさらなる識別符号が検出されると、例えば、日付、時間、ナンバープレート＃、州／県、ステッカーの詳細（例えば、種類、識別子及び有効期限）、画素の位置及びズームレベルを含む情報と共に、識別カメラ１２０に対応するデータベース１４１の部分にエントリを記録する。この情報を車両の他の検出物と共に使用して、目的地カメラによって取り込まれた画像などの他の画像内で車両を識別することができる。

サーバシステム１４０は、第３のタスクにおいて、識別カメラ１２０によって取り込まれた複数の画像に基づいて、動いている車両と止まっている車両を識別する。

サーバシステム１４０は、第４のタスクにおいて、識別カメラ１２０によって取り込まれた複数の画像に基づいて、動いているナンバープレート及び／又はさらなる識別符号と止まっているナンバープレート及び／又はさらなる識別符号を識別する。一例では、サーバシステム１４０を、（１）現在の画像からＯＣＲなどを介して取得されたナンバープレート及び／又はさらなる識別情報に基づいて、（例えば、データベース１４１又はメモリに記憶されているデータを再検討することによって）前回の画像の対応する一致点を発見し、（２）このような一致点が発見されたら、ズームレベルのあらゆる変化を考慮して現在の画像と前回の画像の間で画素の位置を比較する、ように構成することができる。このような処理に基づいて、以下のシナリオのうちの１つ又はそれ以上を検出することができる。（Ａ）画素の位置が変化しておらず、又は所定の閾値未満しか変化していなかった場合、全てのナンバープレート及び／又はさらなる識別符号を止まったままであると見なす。このシナリオでは、車両のデータベース１４１又はメモリ内の既存のエントリに対して日付及び時間の単純な更新が行われる。（Ｂ）１又はそれ以上のナンバープレート及び／又はさらなる識別符号に関連する画素が新たな位置に存在する場合、１又はそれ以上のナンバープレート及び／又はさらなる識別符号が動いたと判定する。サーバシステム１４０は、これらの車両の移動速度及び移動方向を計算し、この情報及び更新された位置を用いてデータベース１４１又はメモリを更新することができる。（Ｃ）１又はそれ以上のナンバープレート及び／又はさらなる識別符号が現在の画像から消えた場合、サーバシステム１４０を、データベース１４１又はメモリに記録されているこのような車両のためのデータを削除するように構成することができる。（Ｄ）１又はそれ以上のナンバープレート及び／又はさらなる識別符号が現在の画像に新たに出現した場合、この新たなナンバープレート及び／又はさらなる識別符号に関連するデータをデータベース１４１又はメモリに記録することができる。ある実施形態では、サーバシステム１４０が、新たな車両の１つが、画像から消えたと最近判定されていた車両に対応すると判定し、この車両のビューを一時的に妨害されていたものとして処理することができる。（Ｅ）現在の画像から全てのナンバープレート及び／又はさらなる識別符号が消えた場合、前の間隔からのデータベース１４１又はメモリからのデータを、これらのデータ内のナンバープレート及び／又はさらなる識別符号に関連して削除することができる。しかしながら、上述したように、識別カメラとの間で車両追跡を実行するために一部のデータは保存しておくことができる。

サーバシステム１４０は、第５のタスクにおいて、識別されたナンバープレート及び／又はさらなる識別符号を、第１のタスクで検出された車両と対にする。例えば、サーバシステム１４０は、ナンバープレート及び／又はさらなる識別符号の（例えば、絶対的画素位置、移動方向及び速度などの）属性を、可能性のある車両について特定されたこのような特性と比較し、各ナンバープレート及び／又はさらなる識別符号を車両と対にしようと試みるように構成することができる。

サーバシステム１４０は、第１から第５のタスクにおいて、特定の車両が特定の駐車スペースに駐車するのにふさわしいかどうか、或いは運転免許登録が最新であって有効であるかどうかを確認する目的で、マシンビジョン技術を適用して車両上のさらなる識別符号を識別することができる。これらの他の種類の一意の識別符号としては、以下に限定されるわけではないが、障害者用駐車ステッカー又はミラーハンガー、居住者専用駐車ステッカー、及び通常はナンバープレートに貼り付けられる登録ステッカーを含む。

第１から第５のタスクでは、英数字ナンバープレート番号及び発行した州／県を取得するために、あらゆるナンバープレート画像にＯＣＲ（光学文字認識）を実行することができる。なお、観察されるナンバープレートは、前部ナンバープレート又は後部ナンバープレートのいずれであってもよい（通常は、通りの上下両方向を向いた識別カメラが設けられる）。この取得されたナンバープレート情報を用いて、車両に関する情報をデータベース１４１に記録するために使用する一意の車両識別子を取得する。いくつかの構成では、第１のタスクを識別カメラ上でローカルに実行することができ、この場合、ナンバープレート番号及び州／県データが、簡潔なデータフォーマットでサーバシステム１４０に送信される。識別カメラ１２０とサーバシステム１４０の間の根本的な通信ネットワークが十分な帯域幅をもたらさない（例えば、画像をストリーミングするための最小閾値は１Ｍｂ／秒と考えることができる）場合、又はあまりにコストが高い（例えば、＄１０／ＭＢよりも高い）と考えられる場合には、このことが特に当てはまる。識別画像１２１内には、複数の車両が同時に存在することがある。ある実施形態では、サーバシステム１４０が、所与の時点に単一の識別カメラから最大１０組の車両ナンバープレート情報を同時に追跡することができる。

第６のタスクでは、識別カメラ１２０の視野を横切って車両が移動した時に、この車両を「追跡」する。識別カメラ１２０によって取り込まれる画像と、近隣の目的地カメラ１２５によって取り込まれる画像との間には、車両が１５ＭＰＨ（約４４フィート）の速度において最短２秒にわたって両方のカメラの視界内に存在するように重複部分が存在する。一般に、近隣又は近傍カメラの位置は、この重複部分が確実に生じるように決定される。これらの２つのカメラは独自に異なる画角を有するので、これらのカメラの両方から所与の車両の重複画像を取得することは、車両及び（車両が駐車している場合には）この車両が占めている正確な目的地の（識別画像１２１から取得されたナンバープレート番号を介した）確実な識別として認識される。

ある実施形態では、識別カメラ１２０の視野を通過する車両がない時間がかなり存在すると思われるので、予備動き検出を用いて、取り込み及び／又は分析を行う識別画像数を減少させることができる。

ＯＣＲレートは、識別性能の評価における有用な測定法の１つにすぎない。例えば、記録された／取り込まれた１００個のナンバープレートのうち、サーバシステム１４０がＯＣＲし損ねた（換言すれば、英数字プレート番号を生成できなかった）のがこれらのナンバープレートのうちのたった１つであれば素晴らしいことであるが、（サーバシステムのプログラミング、識別カメラの配置及び識別カメラの画質などの要素を含む）このような構成が、他の１００個のナンバープレートの取り込み／登録に失敗した（換言すれば、サーバシステム１４０によってさらなるナンバープレート画像がこのように識別されなかった）とすれば、全体的な有効性はたった４９．５％である。さらに、通常、ナンバープレート認識システムは、特定の州／県からのナンバープレート、及び複数の周囲の州／県からのナンバープレートを読み取るように調整される。様々な州／県からのナンバープレートは、文字と背景の色及びコントラストが異なる。ある実施形態では、取り込み率が少なくとも９５％であってＯＣＲ精度が少なくとも９５％であり、最低限の全体的有効性が少なくとも９０．２５％になる。

図３Ａに、都市街路の一部を見下ろす建物の表面又は屋上に配置された目的地カメラ１２５によって取り込まれた画像１２６の例を示しており、従ってこの画像１２６では車両の上面ビューが見える。図３Ａに示す画像１２６に対応する視野に関連して、サーバシステム１４０には、（時間単位の料金で使用できる駐車スポットなどの）９個の適当な目的地３１０ａ〜３１０ｉが指定されている。これらのうち、目的地３１０ｄ以外の全ては、車両３１０ａ〜３１０ｉによって使用中と思われる。サーバシステム１４０には、（商業的な入口などの）不適当な目的地３４０も指定される。ある車両が、一定期間にわたって止まったままであることによって目的地３４０を使用していると判断された場合、この車両は違反していると見なされ、サーバシステム１４０は、以下に限定されるわけではないが、この違反に対する罰金を課す、又はこの違反を駐車施設オペレータに警告するなどの措置を開始する。いくつかの実施形態では、目的地として識別されていないあらゆる範囲内で止まったままの車両を違反と見なすことができる。画像１２６では、画像の右から左に移動する車線内の車両３３０も確認される。この単一の画像のみでは、車両３３０が動いているか、それとも止まっているかは分からない。例えば、前の画像では、車両３３０が目的地３１０ｄを使用していたかもしれず、従ってサーバシステム１４０は、その画像によって車両３３０が目的地３１０ｄの使用を終えたばかりであると判断することができる。

目的地カメラ１２５によって取り込まれた目的地画像は、図４に関連して後述するように、車両がカメラ間を移動した時に、近隣の複数のカメラによって取り込まれた画像から特定される特徴が互いに一致するかどうかを判定することによって車両を追跡できるように、（１）目的地がいつ車両によって使用されているか、又は使用されていないかを識別すること、及び（２）車両の様々な特徴を特定すること、という２つの主な目的のために使用される。

図３Ｂに、画像１２６内に車両の側面ビューが示されるように位置付けられた目的地カメラ１２５によって取り込まれた画像１２６の例を示す。このようなビューは、駐車メータなどのオンサイト駐車システム１６０内、或いは１又はそれ以上の関心目的地の向かい側にある建物又は構造物上に目的地カメラ１２５を配置した場合に得られる。図３Ｂに示す画像１２６に対応する視野に関連して、サーバシステム１４０には、（時間単位の料金で使用できる駐車スポットなどの）４つの適当な目的地３５０ａ〜３５０ｄが指定されている。これらのうち、目的地３５０ｃ以外の全ては、車両３６０ａ〜３６０ｄによって使用中と思われる。

別の例では、図面には示していないが、画像１２６が１又はそれ以上の目的地の斜視ビューを提供するように目的地カメラ１２５を位置付けることができる。図３Ａ及び図３Ｂには、目的地として矩形範囲３１０及び３５０の規格を示しているが、多角形などの他の形状を使用することもできる（この形状は、目的地が遠近的に確認されるように目的地カメラ１２５を位置付ける場合に有用である）。図６Ａ及び図６Ｂに関連して後述するＧＵＩを、画像フィード上のオーバーレイを用いてカメラの視野内における目的地の位置及び範囲を指定するために使用できるユーザインターフェイス要素を提供するように構成することもできる。また、このＧＵＩは、目的地の識別子、及び場合によっては、以下に限定されるわけではないが、これらの目的地が駐車スペースであるか、「駐車禁止」の場所であるか、並びに時間及び／又は日付に基づく使用制限区域であるかなどの、目的地に関する様々な特徴を割り当てるためのツールを提供することもできる。

ある実施形態では、車両が目的地カメラ１２５の視野内に現れた時に、サーバシステム１４０が２つのタスクを実行する。第１のタスクでは、サーバシステム１４０を、（１）目的地カメラ１２５の視野内に存在するありとあらゆる車両を認識し、（２）動いている車両と止まっている車両を区別し、（３）動いている車両が、目的地に対応する視野の範囲内で動かなくなった時点を識別し、（４）各止まっている車両がどの（単複の）目的地を使用しているかを識別し、（５）各車両がそのそれぞれの目的地をどれほど使用していたかを追跡し、（６）動いていない車両が、目的地に対応する視野の範囲から立ち去った時点を識別し、（７）目的地の使用が、その目的地に対して設定されている制限にいつ抵触したかを特定し、（８）車両がどの通り又はブロックに不適切に駐車されているかを識別し、（９）各車両が不適切に駐車されている時間を追跡し、（１０）車両が違法駐車を止めた時点を追跡する、ように構成することができる。各々が車両に対するそれぞれの制限を有する様々な種類の目的地としては、以下に限定されるわけではないが、駐車禁止区域（常時、消防車専用車線、消火栓）、指定時間及び／又は指定日駐車禁止（例えば、ラッシュアワー時又は街路清掃時）、駐車／停車／一時停車禁止、時間制限駐車（例えば、２時間制限）、車種によって制限された駐車（タクシー乗り場、バス停、荷積み区域／商用車専用）、許可された駐車（障害者又は居住者専用の駐車）、乗車及び降車専用の場所、及び道路交差点（車両の移動方向が赤信号である間に車両が交差点内に残る交通渋滞防止用の「交差点通行妨害」違反）が挙げられる。サーバシステム１４０は、以下に限定されるわけではないが、交差点から指定距離内における駐車、バイク専用車線又は横断歩道又は他の歩行者専用区域における駐車、単一の目的地用スペースからはみ出た駐車、縁石から指定距離よりも離れた駐車、私道内又は私道前における駐車、安全地帯又は中央分離帯の使用、誤った方向を向いて駐車された車両、（指定日数を上回って止まっている）放置車両、サイズオーバーの車両、（所与の日数における指定時間を越えたキャンピングカー、トレーラ又はボートなどの）不適当な種類の車両などの他の駐車違反を検出するように構成することもできる。目的地は予約することもでき、この場合、エンドユーザは、指定期間にわたる独占的な目的地の使用を予約する。サーバシステム１４０は、並列駐車車両を検出する一方で、走行状態に起因して車線内に停止している車両と不正に並列駐車している車両とを区別するように構成することもできる。サーバシステム１０４は、オートバイ、スクータ及び「スマートカー」などの小型車両を認識し、場合によってはこれらを区別するように構成することもできる。

第２のタスクでは、車両が目的地カメラ１２５の視野を横切って移動した時に、この車両を「追跡」する。目的地カメラ１２５によって取り込まれる画像と、近隣の識別又は目的地カメラによって取り込まれる画像との間には、車両が１５ＭＰＨ（約４４フィート）の速度において最短２秒にわたって両方のカメラの視野内に存在するように重複部分が存在する。一般に、近隣カメラの位置は、この重複部分が確実に生じるように決定される。これらの２つのカメラは独自に異なる画角を有するので、これらのカメラの両方から所与の車両の重複画像を取得することは、車両及び（車両が駐車している場合には）この車両が占めている正確な駐車スペースの（識別画像１２１から取得されたナンバープレート番号を介した）確実な識別として認識される。

いくつかの構成では、目的地カメラを、サーバシステム１４０にとっての関心目的地を含まない特定の範囲の車両の動きをモニタするように位置付けることができる。このような範囲は、例えば、各々が関心目的地を含む２つの範囲間に存在することができる。この例では、目的地カメラによって取り込まれた画像が、これらの２つの範囲に対応するカメラによって取り込まれた画像に重複することができ、この目的地カメラによって取り込まれた画像は、後述する図４に示すような「ハンドオフ」手順に使用することができる。

ある実施形態では、目的地カメラ１２５が、パン、チルト及び／又はズーム能力を有することができ、これらの能力は、サーバシステム１４０が目的地のより詳細なビューを取得するために使用することができ、或いは駐車施設のオペレータ職員が、駐車場運営システム１９０のユーザインターフェイスを介して、目的地カメラ１２５から見える特定の関心領域をモニタするために使用することができる。このような実施形態では、サーバシステム１４０を、目的地カメラ１２５の視野を変更しながら目的地の使用をモニタして車両特徴を正確に特定するために座標変換を行うように構成することができる。

ある実施形態では、目的地カメラ１２５の視野を通過する車両がない時間がかなり存在すると思われるので、予備動き検出を用いて、取り込み及び／又は分析を行う目的地画像数を減少させることができる。

ある実施形態では、後で必要になった場合に記憶された画像を手動で容易に再確認できるように、識別カメラ及び目的地カメラによって取り込まれた全ての画像に正確な日付及びタイムスタンプが含まれる。

ある実施形態では、車両が（駐車禁止区域などの不適当な目的地とは対照的に）適切な目的地内で停止したと判定された後に、この車両に一定の「支払猶予期間」が与えられる。ドライバーが駐車料金を支払うために車両から離れた時には、たとえ車両が支払いを行っていない状態で目的地を使用し始めたと判定された場合でも、支払過程を完了するのに一定の時間が必要であるため、車両が有料使用要件に違反している旨の決定を遅らせるための一定の支払猶予期間が必要である。

図４に、カメラによって重複視野で取り込まれた画像を用いて、いかにして車両を識別し、目的地までの車両の動きを追跡し、車両による目的地の使用を識別するかを示す。図４は縮尺通りに示しておらず、例えば、重複範囲４３０ａは、名目上は垂直方向に４４フィート又はそれ以上延びているが、車両４１０とほぼ同じサイズとして示している。まず、時刻ｔ１に、識別カメラ（図示せず）が、図４に示す視野をカバーする識別画像４２０を取り込む。識別画像４２０には、４１０’で示す位置にある車両４１０が含まれる。サーバシステム１４０は、画像４２０ａ（及び、恐らくは時刻ｔ１よりも前に識別カメラによって取り込まれた追加画像）に基づいて、車両４１０の一意の識別子を特定する。例えば、１又はそれ以上の検出されたナンバープレートの画像にＯＣＲを実行することによってナンバープレート番号を取得し、ここから一意の識別子を取得することができる。サーバシステム１４０は、車両４１０が識別カメラによって時刻ｔ１に観察されたことを、一意の識別子に関連付けてデータベース１４１に記録する。別の実施形態では、サーバシステム１４０が、車両４１０が識別カメラによって時刻ｔ１に観察されたことを代わりに揮発性メモリに記憶し、識別画像４２０を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両４１０がサーバシステム１４０によって識別される前に車両４１０が目的地を使用したという判定の後に、このような情報をデータベース１４１に記録する。

識別カメラは、時刻ｔ２において、４１０ａで示す位置にある車両４１０の別の識別画像４２０ａ’を取り込む。ほぼ時刻ｔ２において、第１の目的地カメラが、（例えば、ほぼ位置４１０ａにおける）重複範囲４３０ａ内にある車両４１０の目的地画像４２０ｂを取り込む。いくつかの実施形態では、識別カメラと第１の目的地カメラが同期することにより、画像４２０ａ’及び４２０ｂの両方が基本的に同時刻ｔ２に取り込まれる。重複範囲４３０ａは、目的地画像４２０ｂの視野に重複する識別画像４２０ａ’の視野に対応する。両画像４２０ａ’及び４２０ｂでは、車両４１０が重複範囲４３０ａ内に存在する間に車両４１０の画像が取り込まれている。

サーバシステム１４０は、識別カメラによって取り込まれた（識別画像４２０ａ’などの）１又はそれ以上の識別画像に基づいて、車両４１０の複数の特徴Ｃａを特定する。上述したように、Ｃａには、データベース１４１に記録されている車両４１０の不変特徴を含めることができる。この特徴の例としては、以下に限定されるわけではないが、車両４１０の移動速度、車両４１０の移動方向、（例えば、車両４１０が走行している車線を含む）車両画像内における車両の位置、車両４１０の色、及び車両４１０のサイズ又は寸法が挙げられる。いくつかの特徴は、車両４１０の静的特徴と見なすことができ、時間と共に変化しないと予想される（例えば、車両の色又はサイズ）。他の特徴は、車両４１０の動的特徴と見なすことができ、時間と共に大きく変化することがある（例えば、車両速度又は走行車線）。ある実施形態では、静的特徴を車両４１０の不変特徴として、識別画像４２０ａに基づいて特定された一意の識別子に関連付けてデータベース１４１に記録することができる。これらの不変特徴は、エンドユーザによって提供される（型式、モデル、年及び色などの）車両情報に基づいて特定することも、或いは車両４１０とサーバシステム１４０が以前に遭遇した間に取り込まれた車両画像に基づくこともできる。この不変特徴は、識別画像から特定された静的特徴が不変特徴に対応することを保証することにより、車両４１０の一意の識別子を特定したことに関連して使用することができる。車両の識別符号が確認された場合には、Ｃａ又はその他の複数の特徴に不変特徴を含めることもできる。サーバシステム１４０は、目的地画像４２０ｂ、及び場合によっては第１の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両４１０の複数の特徴Ｃａ’を特定する。Ｃａ及びＣａ’は、識別カメラと第１の目的地カメラにおける車両４１０の異なる画角、及び妨害車両などの要因に起因して、異なるけれども一般的には重複する一連の車両特徴を含むことができる。例えば、第１の目的地カメラの視点からは、時刻ｔ２前後において車両４１０が部分的に遮られていることにより、Ｃａでは車両の幅を特定することができるが、Ｃａ’では特定できないことがある。また、通常は画像の境界において有意になる画像の歪み又はその他の要因により、速度又はサイズなどのいくつかの車両特徴が近似値のみになることもある。カメラの位置及びズームレベルを補償するために、サイズ、移動速度及び移動方向などの特徴は標準化することができる。

次に、サーバシステム１４０は、Ｃａ及びＣａ’の両方に含まれている車両特徴の値を比較することによってＣａ’がＣａに対応又は合致するかどうかを判定する。サーバシステム１４０によって特定された車両特徴は、車両４１０の実際の特徴の近似値とすることができるので、比較される特徴の全てに対して値の近似等価を実証すれば、Ｃａ’がＣａに対応するという判定を裏付けるのに十分である。Ｃａ’がＣａに対応すると判定された場合、サーバシステム１４０は、車両４１０が第１の目的地カメラによって時刻ｔ２に観察されたことを一意の識別子に関連付けてデータベース１４１に記録する。別の実施形態では、サーバシステム１４０が、車両４１０が第１の目的地カメラによって時刻ｔ２に観察されたことを代替的に揮発性メモリに記憶し、識別画像４２０を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両４１０がサーバシステム１４０によって識別される前に車両４１０が目的地を使用したという判定の後に、このような情報をデータベース１４１に記録する。これにより、車両４１０によって特定の目的地が使用されていることを実証するために必要のない車両位置情報をデータベース１４１に書き込むことが避けられる。

第１の目的地カメラは、時刻ｔ３において、４１０ｂで示す位置にある車両４１０の別の目的地画像４２０ｂ’を取り込む。ほぼ時刻ｔ３において、第２の目的地カメラが、（例えば、ほぼ位置４１０ｂにおける）重複範囲４３０ｂ内にある車両４１０の目的地画像４２０ｃを取り込む。いくつかの実施形態では、第１の目的地カメラと第２の目的地カメラが同期することにより、画像４２０ｂ’及び４２０ｃの両方が基本的に同時刻ｔ３に取り込まれる。重複範囲４３０ｂは、目的地画像４２０ｃの視野に重複する目的地画像４２０ｂ’の視野に対応する。両画像４２０ｂ’及び４２０ｃでは、車両４１０及び４４０が重複範囲４３０ｂ内に存在する間に車両４１０及び４４０の画像が取り込まれている。

サーバシステム１４０は、第１の目的地カメラによって取り込まれた（識別画像４２０ｂ’などの）１又はそれ以上の目的地画像に基づいて、車両４１０の複数の特徴Ｃｂを特定する。上述したように、Ｃｂには、データベース１４１に記録されている車両４１０の不変特徴を含めることができる。サーバシステム１４０は、目的地画像４２０ｃ、及び場合によっては第２の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両４１０の複数の特徴Ｃｂ’を特定する。また、目的地画像４２０ｃに車両４４０が含まれていることにより、車両４４０の複数の車両特徴Ｃｘも特定される。車両４４０は、異なる車線内を逆方向に走行しているため、Ｃｂ’とＣｘでは動的車両特徴に違いが生じる。次に、サーバシステム１４０は、あり得ないことではあるが、ＣｘがＣｂに対応するかどうかを判定する。次に、サーバシステム１４０は、Ｃｂ’がＣｂに対応するかどうかを判定する。Ｃｂ’がＣｂに対応すると判定された場合、サーバシステム１４０は、車両４１０が第２の目的地カメラによって時刻ｔ３に観察されたことを一意の識別子に関連付けてデータベース１４１に記録する。別の実施形態では、サーバシステム１４０が、車両４１０が第２の目的地カメラによって時刻ｔ３に観察されたことを代わりに揮発性メモリに記憶し、識別画像４２０を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両４１０がサーバシステム１４０によって識別される前に車両４１０が目的地を使用したという判定の後に、このような情報をデータベース１４１に記録する。

第２の目的地カメラは、時刻ｔ４において、４１０ｃで示す位置にある車両４１０の別の目的地画像４２０ｃ’を取り込む。ほぼ時刻ｔ４において、第３の目的地カメラが、（例えば、ほぼ位置４１０ｃにおける）重複範囲４３０ｃ内にある車両４１０の目的地画像４２０ｄを取り込む。いくつかの実施形態では、第２の目的地カメラと第３の目的地カメラが同期することにより、画像４２０ｃ’及び４２０ｄの両方が基本的に同時刻ｔ４に取り込まれる。重複範囲４３０ｃは、目的地画像４２０ｄの視野に重複する目的地画像４２０ｃ’の視野に対応する。両画像４２０ｃ’及び４２０ｄでは、車両４１０が重複範囲４３０ｃ内に存在する間に車両４１０の画像が取り込まれている。

サーバシステム１４０は、第２の目的地カメラによって取り込まれた（識別画像４２０ｃ’などの）１又はそれ以上の目的地画像に基づいて、車両４１０の複数の特徴Ｃｃを特定する。上述したように、Ｃｃには、データベース１４１に記録されている車両４１０の不変特徴を含めることができる。サーバシステム１４０は、目的地画像４２０ｄ、及び場合によっては第３の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両４１０の複数の特徴Ｃｃ’を特定する。次に、サーバシステム１４０は、Ｃｃ’がＣｃに対応するかどうかを判定する。Ｃｃ’がＣｃに対応すると判定された場合、サーバシステム１４０は、車両４１０が第３の目的地カメラによって時刻ｔ４に観察されたことを一意の識別子に関連付けてデータベース１４１に記録する。別の実施形態では、サーバシステム１４０が、車両４１０が第３の目的地カメラによって時刻ｔ４に観察されたことを代わりに揮発性メモリに記憶し、識別画像４２０を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両４１０がサーバシステム１４０によって識別される前に車両４１０が目的地を使用したという判定の後に、このような情報をデータベース１４１に記録する。ある実施形態では、第２の識別カメラが画像４２０ｄの取り込みを行ったものの、車両４１０のナンバープレートの画像を取得できないこともあり、この場合、第２の識別カメラを介して観察された車両の特徴を用いて、範囲４１０ｃの周囲の重複範囲４３０ｃ内で観察された車両が車両４１０であることを確認する。このことは、車両４１０が最初の識別カメラから離れて動いた時に車両４１０の追跡に使用されるのが目的地カメラであるか、それとも識別カメラであるかは重要でないことを示している。これらのカメラは、このような追跡に関連して使用される場合、広く「追跡カメラ」と呼ばれる。

第３の目的地カメラは、時刻ｔ５において、４１０ｄで示す位置にある車両４１０の別の目的地画像４２０ｄ’を取り込む。ほぼ時刻ｔ５において、第４の目的地カメラが、（例えば、ほぼ位置４１０ｄにおける）重複範囲４３０ｄ内にある車両４１０の目的地画像４２０ｅを取り込む。いくつかの実施形態では、第３の目的地カメラと第４の目的地カメラが同期することにより、画像４２０ｄ’及び４２０ｅの両方が基本的に同時刻ｔ５に取り込まれる。重複範囲４３０ｄは、目的地画像４２０ｅの視野に重複する目的地画像４２０ｄ’の視野に対応する。両画像４２０ｄ’及び４２０ｅでは、車両４１０が重複範囲４３０ｄ内に存在する間に車両４１０の画像が取り込まれている。

サーバシステム１４０は、第３の目的地カメラによって取り込まれた（識別画像４２０ｄ’などの）１又はそれ以上の目的地画像に基づいて、車両４１０の複数の特徴Ｃｄを特定する。上述したように、Ｃｄには、データベース１４１に記録されている車両４１０の不変特徴を含めることができる。サーバシステム１４０は、目的地画像４２０ｅ、及び場合によっては第４の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両４１０の複数の特徴Ｃｄ’を特定する。次に、サーバシステム１４０は、Ｃｄ’がＣｄに対応するかどうかを判定する。Ｃｄ’がＣｄに対応すると判定された場合、サーバシステム１４０は、車両４１０が第４の目的地カメラによって時刻ｔ５に観察されたことを一意の識別子に関連付けてデータベース１４１に記録する。別の実施形態では、サーバシステム１４０が、車両４１０が第４の目的地カメラによって時刻ｔ５に観察されたことを代わりに揮発性メモリに記憶し、識別画像４２０を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両４１０がサーバシステム１４０によって識別される前に車両４１０が目的地を使用したという判定の後に、このような情報をデータベース１４１に記録する。

図４に示す画像４２０ｅの視野に関連して、サーバシステム１４０には、（時間単位料金で使用できる駐車スポットなどの）４つの適当な目的地４５０ａ〜４５０ｄが指定されている。時刻ｔ６において、車両４１０が位置４１０ｅに存在する時点で、第４の目的地カメラによって目的地画像４２０ｅ’が取り込まれる。サーバシステム１４０は、目的地画像４２０ｅ’に基づいて、目的地４５０ｂとして指定された矩形領域内に車両４１０が存在すると判定する。時刻ｔ７において、車両４１０が位置４１０ｅに留まったままの状態で、第４の目的地カメラによって目的地画像４２０ｅ’’が取り込まれる。サーバシステム１４０は、目的地画像４２０ｅ’’に基づいて、目的地位置４５０ｂとして指定された矩形領域内に車両４１０が存在すると再び判定し、従って車両４１０が時刻ｔ６から目的地４５０ｂを使用し始めたと判断して、この情報をデータベース１４１に記録する。時刻ｔ８において、車両４１０が目的地４５０ｂから出た時点で、第４の目的地カメラによって目的地画像４２０ｅ’’’が取り込まれる。サーバシステム１４０は、目的地画像４２０ｅ’’’に基づいて、目的地４５０ｂとして指定された矩形領域内にもはや車両４１０が存在しないと判定し、従って車両４１０が時刻ｔ８に目的地４５０ｂの使用を終了したと判断する。サーバシステム１４０は、例えば目的地４５０ｂの時間毎の使用料金などの、時刻ｔ６〜ｔ８における目的地４５０ｂの使用に適用可能な制約に関する情報に基づいて、この目的地４５０ｂの使用に対する請求をエンドユーザの口座に行ったり、又は目的地４５０ｂの不正使用に対する罰金を課したりなどの動作を開始することができる。

サーバシステム１４０は、車両が目的地を使用していると最初に判断した場合、目的地を使用している車両を正しく識別するようにも構成され、その後に識別カメラを介して車両識別符号を取り込むことができる。この状況は、例えば、車両が識別カメラの近くを通過した時に車両のビューが遮られた場合、或いはサーバシステム１４０の再起動によって車両の識別が予め行われなかった場合に生じることがある。一例として、時刻ｔ１よりも前の時刻ｔ０に、最初に第４の目的地カメラが、車両４４０が目的地４５０ｃを使用していると判断したが、車両の４４０の識別符号を獲得できなかった場合、車両４４０に一時的な一意の識別子が割り当てられ、この一時的識別子に関連してデータベース１４１にエントリが記録される。車両４４０の一連の車両特徴は、車両４４０が目的地４５０ｃを使用している間、並びに車両４４０が重複範囲４３０ｄ、４３０ｃ、４３０ｂ及び４３０ａを通過した時に特定することができ、これらの一連の特徴の対応付けを、上述した方法と同じ方法で行い、一時的識別子に関連する同じ車両４４０が依然として観察されていると判断してこれを記録する。車両４４０が重複範囲４３０ａ内に存在する間に第１の識別カメラによって観察されると、サーバシステム１４０は、車両４４０の正しい一意の識別子を特定することができる。この時点で、以前に一時的識別子の下でデータベース１４１に記録されていた記録を修正し、又は目的地４５０ｃの使用が識別子に正しく関連付けられた車両４４０の正しい一意の識別子の下で再び記憶することができる。時刻ｔ０の後に車両４４０の識別符号を取得するための別の機構は、車両４４０が目的地４５０ｃを使用している間にモバイル装置１５０を派遣して車両４４０の１又はそれ以上の識別画像を取り込むことである。車両４４０による目的地４５０ｃの使用が、目的地４５０ｃの使用に関連する制約に抵触すると判定される場合、モバイル装置１５０の派遣を高優先度で指定することができる。

サーバシステム１４０は、識別カメラ及び目的地カメラから画像を受け取り、駐車車両の識別情報を挿入する。次に、サーバシステム１４０は、ＡＰＩ（アプリケーションプログラミングインターフェイス）を介して第三機関の駐車料金支払システムから（以下に限定されるわけではないが、支払済み駐車の継続時間及び期限切れ時刻などの）駐車料金支払情報を検索することができる。車両の駐車状況が未払い又は期限切れのいずれかであると判定された場合、サーバシステム１４０は、ＡＰＩを介してこの情報を第三機関の駐車料金支払システムに送信する。この時、第三機関の支払システムを運営する駐車施設オペレータは、その標準作業手順書（ＳＯＰ）に従って（以下に限定されるわけではないが、駐車違反切符を郵送すること、車両に車輪止めを装着すること、或いは繰り返しの又は深刻な駐車違反時には車両を牽引することなどの）駐車違反に対する対処を行うことができる。

サーバシステム１４０による車両検出は、（１）ビデオフレーム内の車両の存在及び位置を検出すること、（２）動いている車両と止まっている車両を区別すること、（３）特定の検出車両が駐車スペース又は駐車禁止範囲などの目的地を使用しているかどうかを識別すること、（４）車両が目的地を使用し始めた時点又は立ち去った時点を特定すること、（５）車両が１つの追跡カメラの視野から別の視野追跡カメラに移動した時にこの車両を追跡し、この追跡においてエラーが生じたと判断された場合には例外を挙げること、などの複数の機能を実行するように構成することができる。ある実施形態では、サーバシステム１４０を、特定の車両が目的地にアクセスし、又は目的地を使用するための適切な指標を表示しているかどうかを識別するように構成することもできる。このような指標の例としては、以下に限定されるわけではないが、障害者用駐車ハンガー又はステッカー、又は「居住者専用」駐車位置の使用が許可されている旨を示す駐車ハンガー又はステッカーが挙げられる。カメラは、このような指標の画像を鮮明に取り込むようにズームインすることができる。ある実施形態では、ナンバープレートなどの車両識別子を用いて、目的地の適切なアクセス又は使用を判断し、別個の指標の必要性を排除することができる。

ある実装例では、サーバシステム１４０を、その識別カメラ及び目的地カメラのためのタスクを、スレッドを用いて実行するようにプログラムすることができる。例えば、「ｖｉｄｅｏ＿ｒｅｃｅｉｖｅｒ」スレッドは、識別子又は目的地カメラからのビデオ及び／又は画像ストリームの受信に対処して、未加工のビデオ及び／又は画像情報を記憶することができる。このスレッドは、１つのビデオ及び／又は画像ストリーム、或いは複数のビデオ及び／又は画像ストリームにつき１つのスレッドとすることができる。このスレッドのための設定可能な選択肢は、（１）ファイルに記憶、（２）メモリに記憶、（３）メモリ及びファイルに記憶、（４）ビデオデータの保管時間（例えば、４時間）を含むことができる。別の例は、車両の色、形状、場所、車線位置、移動速度／方向、車両位置がハンドオフゾーン内に存在するかどうか（及びどの車両か）、カメラの識別符号、を検出してこのような情報をデータベース１４１に記憶するためのスレッドである。このスレッドは、各複数のビデオフレームを分析して、最新の位置及び車両の移動速度／方向を特定し、このような情報をデータベース１４１に記憶する。このスレッドは、１つのビデオ及び／又は画像ストリーム、或いは複数のビデオ及び／又は画像ストリーム毎に１つ存在することができる。別の例は、ハンドオフゾーンを通って出てきたものとして検出された特定の車両が近くのカメラによって検出されたことを確認するスレッドである。この確認は、特定のカメラのデータベース１４１を見直すことにより、例えばどのハンドオフゾーン内で車両が検出されたか、及び／又は検出された車両の移動方向に基づいて行うことができる。このスレッドは、１つのビデオ及び／又は画像ストリーム、或いは複数のビデオ及び／又は画像ストリーム毎に１つ存在することができる。別の例は、車両がある目的地において止まったままであること、及び目的地の使用を開始した時点又は立ち去った時点によって、車両がその目的地を使用しているかどうかを判定するためのスレッドである。このスレッドは、１つのビデオ及び／又は画像ストリーム、或いは複数のビデオ及び／又は画像ストリーム毎に１つ存在することができる。

当業では、ビデオフレーム内における車両の存在を検出するために使用することができる多くのマシンビジョン技術が周知である。例えば、車両の存在を検出するために使用できる様々な既知のエッジ検出アルゴリズムが存在する。一例として、あるアルゴリズムは、車両と背景の色の違い、及び全体形状のサイズがズームレベル及び／又は視野内の位置を考慮して予想される最小車両サイズよりも大きいかどうかに基づいて車両の存在を検出することができる。例えば、このアルゴリズムは、ビデオストリームスナップショット内の画素の色を互いに比較することができる。画像は、消火栓、歩行者、芝生、道路標識及び道路塗装などの様々な非車両物体を含む可能性があるので、このアルゴリズムは、（一致すると見なされる色のバリエーション範囲を構成可能な）類似色の画素グループを検出することができる。全体形状が最小車両サイズよりも大きいかどうかを判定するためには、その形状の画素の数及び位置を使用する。このアルゴリズムは、例えば鏡面反射又は強調によって生じる可能性がある、形状の「穴」又は不完全性にさらに対処することができる。また、このアルゴリズムは、それぞれの最小サイズのいくつかの形状が互いに特定の距離内に存在するかどうかを判定することもできる。これらの形状は、例えば、通常は同じ色であるボンネット、屋根及びトランク部分に対応することができる。

車両と背景の間に不十分なコントラスト又は色の違いが存在する場合には、境界条件が発生して検出が上手くいかないことがある。例えば、黒いアスファルトと黒い車両である。この境界条件に対処するために、カメラハードウェア及び／又はアルゴリズムにさらなる微調整を導入することができる。例えば、可視光及び赤外線撮像の両方を行うカメラを用いて、目的地を使用し始めた車両の熱署名を取得することができる。この例では、たとえ車両の色と背景の色が両方とも黒であっても、エンジンルームはその周囲と異なる温度プロファイルを有する。さらなる費用対効果分析は、このような方法から得られる利益が増分コストを正当化するかどうかを判定するとともに、赤外線撮像過程によって生じるあらゆる境界条件を考慮することに（カメラによって取り込まれた可視光などによって）十分に対処することができる。

単一の画像から車両の存在及び多くの特徴を認識することはできるが、例えば車両が動いていないか、それとも止まっているかを判断するには複数の画像が必要であり、従って複数の画像が使用される。一例では、サーバシステム１４０を、（１）現在の画像内の車両の色及びサイズの特定に基づいて、（例えば、データベース１４１又はメモリに記憶されているデータを再検討することによって）前回の画像内の対応する一致を発見し、（２）このような一致が発見されたら、ズームレベルのあらゆる変化を考慮して現在の画像と前回の画像の間で画素位置を比較する、ように構成することができる。このような処理に基づいて、以下のシナリオのうちの１つ又はそれ以上を検出することができる。（Ａ）画素の位置が変化しておらず、又は所定の閾値未満しか変化していなかった場合、全ての車両を止まったままであると見なす。このシナリオでは、車両のデータベース１４１又はメモリ内の既存のエントリに対して日付及び時間の単純な更新が行われる。（Ｂ）１又はそれ以上の車両に関連する画素が新たな位置に存在する場合、１又はそれ以上の車両が動いたと判定する。サーバシステム１４０は、これらの車両の移動速度及び移動方向を計算し、この情報及び更新された位置を用いてデータベース１４１又はメモリを更新することができる。（Ｃ）１又はそれ以上の車両が現在の画像から消えた場合、サーバシステム１４０を、データベース１４１又はメモリに記録されているこのような車両のためのデータを削除するように構成することができる。（Ｄ）１又はそれ以上の車両が現在の画像に新たに出現した場合、この新たな車両に関連するデータをデータベース１４１又はメモリに記録することができる。ある実施形態では、サーバシステム１４０が、新たな車両の１つが、画像から消えたと最近判定されていた車両に対応すると判定することができ、この車両のビューを一時的に妨害されていたものとして処理することができる。（Ｅ）現在の画像から全ての車両が消えた場合、前の間隔からのデータベース１４１又はメモリからのデータを、これらのデータ内の車両に関連して削除することができる。しかしながら、上述したように、識別カメラとの間で車両追跡を実行するために一部のデータは保存しておくことができる。

ある例では、目的地範囲を使用している車両を識別するためのアルゴリズムが、基本車両検出アルゴリズムに類似する。サーバシステム１４０は、車両の検出が完了すると、車両に対応する画素位置が、事前マッピングした視覚領域のいずれかを占めているかどうかを評価する。重複の程度は設定可能とすることができる。ある実施形態では、垂直オフセットを適用して、車高を補償するとともに、目的地カメラと車両の間の駐車車両などの視覚的障害を補償することができる。このような障害は、例えば混雑した駐車区画では頻繁に生じることがある。サーバシステム１４０は、車両が少なくとも一定時間にわたって止まったままであったかどうかを判定する。車両が少なくとも一定時間にわたって所与の目的地に存在していたと判定されると、車両の識別情報、目的地、及び車両が目的地を使用し始めた時間及び日付をデータベース１４１に、好ましくは不揮発性記憶装置に記録する。ある実施形態では、サーバシステム１４０を、車両が２つの駐車スペースを使用することなどによって複数の目的地を占有している時間を検出するように構成することができる。これにより、例えば１又はそれ以上の駐車違反切符を発行し、又は使用料を割り増しすることができる。サーバシステム１４０は、車両がいつ目的地から立ち去ったかを特定し、対応する情報をデータベース１４１に記録することもできる。また、サーバシステム１４０は、最大駐車時間が２時間の駐車スポット、指定の街路清掃時間後に車両の使用に利用できない目的地、又は車両に提供される資金の枯渇に関連して生じ得るような、車両による目的地の使用が目的地の使用時間を間もなく超過すること、又はいつ超過したかを特定するように構成することもできる。

ある実施形態では、サーバシステム１４０を、一度に複数の車両によって使用できる１又はそれ以上の複数車両用目的地を認識するように構成することができる。例えば、サーバシステム１４０を、車両の「ロングブロック」駐車の追跡をサポートするように構成することができ、この場合、例えば、街区の縁石の長さに沿って、単一のペイ・バイ・スペースユニット、ペイ・アンド・ディスプレイユニット、又はペイ・バイ・プレートユニットによって制御される駐車区域は設けられているが、この駐車区域が明確な駐車スペースに分割されておらず、代わりに、車両は、（以下に限定されるわけではないが、荷積み区域及び私道などのいくつかの「駐車禁止」領域を除く）縁石沿いのあらゆる利用可能なスペースを使用することができる。別の例では、サーバシステム１４０を、例えば単一のペイ・アンド・ディスプレイユニットによって制御される駐車区画の使用を追跡し、内部の複数の個別に明確化されたスペースは追跡しないように構成することができる。サーバシステム１４０は、複数車両用目的地の使用をスペース毎に追跡するように構成しなくてもよいが、時間に伴う車両の使用状況を追跡し、複数車両用目的地の使用許可時間を超えた車両に違反切符を貼り付けることなどの駐車取締作業を行うために、複数車両用目的地内の車両の位置を特定して記録することができる。ある実施形態では、複数の車両によって使用できたはずのスペースの使用にはより多くの駐車料金及び／又は罰金を課すことができるので、サーバシステム１４０を、複数車両用目的地を使用している車両の長さを特定するように構成することができる。本出願において説明するサーバシステム１４０を使用する１つの利点は、従来の制御された駐車区画では、駐車場の使用を制御するために単一の入出地点に依拠することがあるが、カメラを用いた追跡では、車両をフェンスの壁によって取り囲む必要が無いので、複数の入口及び出口を有する「オープン」な設計の駐車区画が可能になる点である。

ある実施形態では、複数の不連続な目的地又は複数車両用目的地を単一の複数車両用目的地に集約することができる。この実施形態は、構成する２つの目的地が異なる目的地カメラによってカバーされる場合を含むことができる。この実施形態は、例えば複数車両用目的地が、街区の長さに沿った様々な「駐車禁止」目的地によって分割される場合に有用となり得る。

ある実施形態では、複数車両用の場所の制約範囲を「分割」するように、複数車両用目的地に重複する「駐車禁止」などの制約された目的地が存在することができる。例えば、上述した「ロングブロック」のシナリオでは、街区の長さ全体に沿って単一の複数車両用目的地を定め、以下に限定されるわけではないが、ブロックの長さに沿った荷積み区域及び私道などの、街区に沿った様々な部分に「駐車禁止」目的地を重複させることができる。サーバシステム１４０によって「駐車禁止」目的地の１つを使用しているものとして検出された車両は、より大きな複数車両用目的地内に存在していたにも関わらず、サーバシステム１４０によって駐車違反を犯したと判断される。

ある実施形態では、コンピュータベースの設定ユーティリティを設けることができる。例えば、設定ユーティリティを用いてモバイル装置１５０又は手動再確認システム１８０を設定し、現場設定又は遠隔設定を可能にすることができる。例えば、車両の識別、追跡及び／又は検出のためのカメラ設定の効果に関するフィードバックを提供するために、カメラの設置を行う人物がモバイル装置１５０を使用することができる。この代わりに、又はこれに加えて、手動再確認システム１８０の使用中に設定不具合が識別された結果として、この手動再確認システム１８０を介して特定のシステム又はカメラ設定の変更を行うこともできる。ある実施形態では、ウェブブラウザを介してユーザインターフェイスを利用可能にすることができる。設定ユーティリティは、限定するわけではないが、以下のような１又はそれ以上の機能を提供することができる。
・所与のカメラに関する車両検出の較正を行うためのグラフィカルユーザインターフェイス（ＧＵＩ）を提供すること。
・連続的なカメラの位置合わせを確実にするためのＧＵＩを提供すること。
・最小車両寸法を指定するためのＧＵＩを提供すること。このＧＵＩは、画素に関連することができ、ズームレベルに合わせて調整することができる。
・別のカメラの視野に重複するカメラの視野の一部を識別するためのＧＵＩを提供すること。
・カメラの位置合わせを行うための、及び／又はカメラの向き及び／又は位置合わせを指定するためのＧＵＩを提供すること。
・目的地を事前マッピングするためのＧＵＩを提供すること。
・車両駐車違反と見なされる状況を定義すること。このような状況は、所与の領域又は場所に特定のものとすることができる。
・様々な駐車違反の結果を設定すること。例えば、違反に関する情報を単純に画面上に表示することも、登録所有者情報を取得して違反切符又は請求書を発行することも、或いは警告を印刷して車両に配置しておくこともできる。
・郵送又はそれ以外の方法で駐車違反切符を発行する前の、国営の自動車代理店などに新たな自動車所有者登録情報要求を行わなければならない期限を設定すること。
・その他のシステム設定パラメータを再検討して修正するためのＧＵＩを提供すること。

ＧＵＩは、所与のカメラの車両検出の較正を行うために、２つの画像フィードを提示して、管理者が各画像フィードにルーラを重ねられるようにする。ズームレベルを修正する制御ができるように、もしあればズームレベルをＧＵＩの一部として表示することができる。２つの画像フィードは、視野が重複する所与のカメラと別のカメラからのものである（このようなカメラは互いに隣接していることが多い）。較正のためには、画像を同時に取り込んで、車両が２つのカメラの視界の重複範囲を通過した時などにおける各ビデオフィード内の車両の位置を再確認できるように、２つのカメラの画像の取り込みを同期させることが好ましい。設定ユーティリティは、ＧＵＩを通じて、一時停止、再生、巻き戻し、早送り、コマ送り、コマ戻し及びフレーム移動機能などの時間的画像制御機能を提供することもできる。

較正では、設定ユーティリティを用いて、一方又は両方の画像フィード内で既知の型式及びモデルの１又はそれ以上の車両（この車両は、例えば設定ユーティリティを操作する技術者が使用している車両を含むことができる）を発見し、ＧＵＩ内に１又はそれ以上のルーラを位置付けて、測定中の車両の既知の寸法値を参照することによってルーラが正しい車両の長さ、幅及び／又は高さを示すようにすることができる。ある実施形態では、ＧＵＩによって提供されるルーラ機能が、カメラによって導入された（例えば、カメラモデルに基づく既知の特徴を有することがある）視覚的歪み、又は取り込み画像の奥行きなどの要因に起因する非線形性を補償するように構成される。例えば、画像の右手側に取り込まれた車両の方が画像の左手側に取り込まれた車両よりもカメラから離れている場合には、距離の単位を示すルーラの線の間隔を画像の右手側において狭めることができる。設定ユーティリティは、画像のマーカーを識別して（他のマーカー及び／又はカメラに対する）位置及び／又は距離を示すことにより、所与のカメラのこのような非線形性を現場で較正できるように構成することができる。このようなマーカーは、一時的なものとすることも、或いは場合によっては、技術者が後で再較正を行えるように恒久的なものとすることもできる。

また、設定ユーティリティを用いて、２つの画像フィードにおける移動方向の関係性を指定するともに、２つの画像フィードにおける共通点に対応する画素又は画像位置を識別することもできる。ある実施形態では、画像フィードの各々における車線／経路に関して移動の位置及び方向を指定して、（例えば、車両が同じ車線／経路内の１つのカメラの視野から別のカメラの視野にいつ通過したかを後で特定できるように）これらの２つの画像フィード間で相関付けることができる。これらの特徴の指定は、ＧＵＩを介して、例えば車線／経路の境界を示す画像フィード上に線又はその他の指標が重なり合うようにすることによって行うことができる。図６Ａ及び図６Ｂに、例示的なＧＵＩの態様を示す。図６Ａには、第１のカメラからの画像６００ａが表示されたＧＵＩの一部を示す。図６Ｂには、第２のカメラからの画像６００ｂが表示されたＧＵＩの一部を示す。画像６００ａ及び６００ｂの視野は重複しており、重複範囲は、範囲６４０ａ及び６４０ｂを含む。画像６００ａ及び６００ｂには２つの車線／経路も取り込まれており、図６Ａでは車線／経路６１１ａ及び６１２ａ、図６Ｂでは車線／経路６１１ｂ及び６１２ｂとして表記している。この図６Ａ及び図６Ｂに示す特定の例では、車線／経路６１１ａ及び６１１ｂにおいて交通の流れが（一般には角度θに対応する）同じ方向であるが、同様の例では、車線／経路６１１ａ及び６１１ｂにおいて交通の流れが逆方向の場合もある。画像６００ａ及びｂには、それぞれＡ、Ｂ及びＣで表記する３つの車両の画像も取り込まれている。図６Ａでは、車線／経路境界が、破線の車線／経路境界指標６２１ａ、６２２ａ及び６２３ａによって示されており、これらの指標は、ＧＵＩの使用によって追加し、配置し、移動させ、ラベル付けし、別様に識別することができる。図６Ａには、ＧＵＩを用いて、車線／経路境界指標６２１ａと６２３ａの間の車線／経路６１１ａ、及び車線／経路境界指標６２２ａと６２３ａの間の車線／経路６１２ａという２つの車線／経路が示されている。図６Ａに示す特定の例では、車線／経路６１１ａ及び６１２ａにおいて交通の流れが同じ方向θであり、車線／経路境界指標６２１ａ及び６２２ａは（同様の破線で示す）第１のタイプであり、車線／経路境界指標６２３ａは第２のタイプであって、車線／経路境界指標６２１ａと６２２ａの間の一方向の交通の流れの範囲が２つの車線／経路６１１ａ及び６１２ａに分かれていることを示す。設定ユーティリティは、例えば、図６Ｂに示す車線／経路６１１ｂ及び６１２ｂなどの、他のカメラに関連して識別される車線と相互参照できるように、指定された車線の識別子を自動的に提供又は提案するように構成することができる。図６Ｂでは、設定ユーティリティが、車線／経路６１１ｂ及び６１２ｂ、並びに上述した図６Ａの同等物に対応する車線／経路境界指標線６２１ｂ、６２２ｂ及び６２３ｂを用いて、車線／経路識別のための同様の機能を提供する。

ある実施形態では、各車線／経路をいくつかの小さなセグメントに分割することができる。これらのセグメントは、例えばセグメントを示す画像フィード上に線又はその他の指標が重なることを可能にすることにより、ＧＵＩを介して指定することができる。ある実施形態では、重なり合った線を用いて、画像フィード内の非線形性を自動的に特徴付ける支援を行うことができる。図６Ａに、車線／経路セグメント指標６３１ａ及びその他の同様のラベル表示していない車線／経路セグメント指標を用いた例を示している。設定ユーティリティは、以前に指定された車線／経路境界指標に基づいて、提案される車線／経路セグメント指標を自動的に生成するとともに、ＧＵＩを介して、車線／経路境界指標を望むように調整するためのツールを提供するように構成することができる。また、図６Ａに示す車両Ａ、Ｂ及びＣなどの車両画像を含めることにより、技術者が車線／経路セグメント指標を正確に配置又は調整する支援を行うことができる。図６Ｂには、車線／経路セグメント指標６３１ｂ、及び上述した図６Ａの同等物に対応するその他の同様のラベル表示していない車線／経路セグメント指標を示している。

設定ユーティリティは、ＧＵＩを介して、第２の画像ストリームのそれぞれの範囲と視野が重なり合った画像ストリームの範囲を指定するための同様の機能を提供することもできる。これらの範囲は、車両の検出を１つの追跡カメラから別の追跡カメラに「ハンドオフ」するために使用されるので、「ハンドオフゾーン」と呼ばれる。例えば、図６Ａ及び図６Ｂには、視野が重なり合ったカメラによって取り込まれた画像を示しており、ハンドオフゾーン６４０ａの視野がハンドオフゾーン６４０ｂの視野に重なる。ＧＵＩは、図６Ａではハンドオフ境界指標６５１ａ及び６５２ａの、図６Ｂではそれぞれのハンドオフ境界指標６５１ｂ及び６５２ｂの指定を可能にするように構成することができる。また、指定されたハンドオフゾーンは、図６Ａ及び図６Ｂに示すハンドオフセグメント指標６１１ａ及び６１１ｂ（及びその他のラベル表示していないハンドオフセグメント指標）を用いて、いくつかの小さなセグメントに分割することもできる。設定ユーティリティは、以前に指定されたハンドオフ境界指標に基づいて、提案されるハンドオフセグメント指標を自動的に生成するとともに、ＧＵＩを介して、ハンドオフ境界指標を望むように調整するためのツールを提供するように構成することができる。また、図６Ａに示す車両Ａ、Ｂ及びＣなどの車両画像を含めることにより、技術者がハンドオフセグメント指標を正確に配置又は調整する支援を行うことができる。ある実施形態では、設定ユーティリティを、ハンドオフ境界指標６５１ａ及び６５２ａ間の距離を求め、この距離が望ましい最低距離未満ある場合にはＧＵＩのユーザに警告するように構成することができる。

図６Ａ及び図６Ｂに示すＧＵＩは、ＧＵＩによって提供される指標を単純な線として図示し記述しているが、設定ユーティリティ及びＧＵＩは、以下に限定されるわけではないが、曲線及びフリ−ハンド線などのさらに複雑な形状の特徴の指定を可能にすることもできる。また、車線／経路境界指標６２３ａなどの、第１のカメラに関連して指定される指標が、車線／経路境界指標６２３ｂなどの、別のカメラに関連する同等の指標を有する場合、ＧＵＩを用いてこれらの同等の指標をリンクさせることができる。ある実施形態では、以前に指定された指標、既知のカメラ位置、既知のカメラ配向、並びに車線／経路の数及びこれらの車線／経路内の交通の流れの向きなどの、カメラに近い交通の流れの既知の態様などの情報に基づいて、このようなリンクを自動的に決定又は提案することができる。

ある実施形態では、カメラがズーム及び／又はパン／チルト能力を有する場合、設定ユーティリティを、様々なズームレベル又は配向のカメラを用いて取り込まれた画像内における様々な指標特徴の指定を可能にするように構成することができる。この追加情報を用いて、カメラの全体的な視野をさらに十分に指定することができる。技術者が、カメラの視野を指定するために指標及び／又はルーラをどのように使用するかに納得すると、この情報及び／又はこの情報から得られた他の情報を、例えばサーバシステム１４０による車両追跡で使用できるようにデータベース１４１に記憶することができる。

設定ユーティリティは、ビデオカメラの連続位置合わせを行うためのＧＵＩを提供するように構成することができる。この機能は、上述した車線／経路境界を指定するためのＧＵＩに含まれるさらなるユーザインターフェイス要素を介して提供することができる。ビデオカメラの連続位置合わせは、最初のカメラハードウェア取り付け過程中に、或いは既存のカメラハードウェアを後から更新する場合に、カメラがパン、チルト及び／又はズーム（ＰＴＺ）機能を備えていれば、図４、図６Ａ及び図６Ｂに示す重複部分などの十分な重複部分がカメラ間の視界内に確実に存在するようにカメラのパン、チルト及び／又はズーム設定を調整及び／又は較正する必要があるという事実に関するものである。技術者は、ＧＵＩを見直して、１対のカメラによって十分なサイズ及び／又は継続時間のハンドオフゾーンが提供されているかどうかを判定することができる。提供されていない場合、パン、チルト及び／又はズーム設定の変更を要求することができ、或いはカメラの物理的な取り付け位置を完全に変更する必要が生じることもある。

設定ユーティリティは、駐車スペース及び「駐車禁止」区域などの目的地の事前マッピングを行うためのＧＵＩを提供するように構成することができる。ＧＵＩは、画像フィードを提示し、技術者が、例えば画像フィード上にグレーアウトされたポリゴンを重ね合わせることを可能にする。別の非限定的な例では、駐車スポット＃１２３を、所与のズームレベル及び／又はＰＴＺ配向の特定の目的地カメラによって取り込まれた２０画素の集合体にマッピングすることができる。ＧＵＩは、カメラの視野内の目的地の位置及び規模を示すように、以下に限定されるわけではないが、このようなポリゴンの移動、サイズ変更及び回転を含む動作を提供するように構成することができる。カメラがＰＴＺ能力を有する場合には、ＰＴＺ制御を行うことができる。この機能は、上述した車線／経路境界を指定するためのＧＵＩに含まれるさらなるユーザインターフェイス要素を介して提供することができる。ＧＵＩは、例えばサーバシステム１４０の様々な態様において使用するための共通目的地識別子を提供するために使用できる識別子を目的地に割り当てるインターフェイスを提供することもできる。ＧＵＩは、目的地の様々な特徴を指定できるようにするインターフェイス要素を提供することもできるが、直接的な人間の作業を最小限に抑え、設定ユーティリティ又はサーバシステム１４０の他の態様を利用してこのような特徴を管理し、割り当て、及び／又は修正することが好ましい。

ある実施形態では、設定ユーティリティを、上述した複数車両用目的地の事前マッピングを単一車両用目的地の事前マッピングのための上記説明とほぼ同様に実行するためのＧＵＩを提供するように構成することができる。設定ユーティリティは、複数の目的地又は複数車両用目的地が単一の目的地に集約されるのを可能にするように構成することができる。例えば、構成要素である目的地の各々に、これらが複数車両用目的地を形成していることを示すための共通識別子を割り当てることができる。設定ユーティリティは、制限された目的地が複数車両用目的地に重なり合うことを可能にして、以下に限定されるわけではないが、荷積み区域及び私道などの、駐車制限を受ける部分を広範にわたる範囲から「区分け」するように構成することができる。

設定ユーティリティは、何が駐車違反を構成するかを指定するためのＧＵＩを提供するように構成することができる。第１の例では、ＧＵＩを用いて、車両が目的地の使用に関する制限に違反していると見なす前に車両が目的地を使用できる時間を定める支払猶予期間を指定することができる。例えば、車両が駐車メータの地点で停車した時には、車両のドライバーが車両を離れて駐車料金を支払うのに十分な支払猶予期間を与えることが妥当である。異なるタイプ又はグループの目的地には、異なる期間を指定することができる（例えば、「駐車禁止」ゾーンでは、支払猶予期間を短く又はゼロにすることができる）。第２の例では、ＧＵＩを用いて、車両が違反であると見なす前に、面積又は範囲カバー率から見て車両がどれほど目的地に重なっているのかに関して車両の重なり量を指定することができる。第３の例では、ＧＵＩを用いて、例えば障害者用駐車スペースの使用、居住者専用の駐車、或いは許可証又はステッカーの表示を必要とするその他の駐車に関連する規則を含む駐車許可規則を指定することができる。ＧＵＩは、以下に限定されるわけではないが、色、許可証又はステッカー上に描かれている画像、及び許可証又はステッカーの（シリアルナンバーなどの）識別子の位置などの、必要な許可証又はステッカーの特性及び特徴を識別するためのインターフェイスを提供することもできる。第４の例では、ＧＵＩを、今月を示すタグを期限切れと見なすかどうかなどの、何が期限切れのナンバープレートタグを構成するかを特定するための規則を定めるように構成することができる。

設定ユーティリティは、目的地の車両不正使用の結果を指定するためのＧＵＩを提供するように構成することができる。例としては、以下に限定されるわけではないが、ナンバープレート情報を画面表示すること、ナンバープレートを検索して登録所有者の名前及び住所を取得すること、取締官を派遣すること、目的地を不正使用している車両にレーザーによる照射を行うこと、ファイル上のクレジットカード又は口座に駐車違反の罰金を課すこと、及び銀行又はその他の金融口座から駐車違反の罰金を引き落とすことが挙げられる。

設定ユーティリティは、検出された駐車違反の結果を修正する対象になる特定の車両を指定するパラメータを受け取って記録するように構成することができる（例えば、警察車両は、指定の違反が適用されないものとして識別することができる）。例えば、このような車両は、ナンバープレート番号によって識別することも、或いはステッカーなどの指定された識別子を有することもできる。

ある実施形態では、サーバシステム１４０を、商業的データベース又は自治体データベースを通じて取得できる、及び／又は駐車場オペレータが提供できる既存の街路情報及び／又は駐車情報を取得して、目的地及び車線／経路情報を自動的に決定するように構成することができる。ある実施形態では、サーバシステム１４０を、様々な識別カメラ及び目的地カメラの位置及び配向を示す情報に基づいて、目的地及び／又は車線／経路を自動的に事前マッピングするように構成することができる。ある実施形態では、サーバシステム１４０を、以下に限定されるわけではないが、識別子、場所（例えば、緯度／経度又は所在地住所）、目的地の使用料、並びに本出願で説明した目的地の時間ベース、日付ベース及びその他の制約などの、データベース１４１に記録された目的地及び／又は車線／経路の特徴を記録及び／又は更新するように構成することができる。ある実施形態では、サーバシステム１４０が、目的地情報及び／又はアップデートを駐車プロバイダがさらに容易にまとめてアップロードできるようにするＡＰＩを提供することができる。

別の実施形態では、図１に示すサーバシステム１４０及びその他の要素が、ＡＰＩを介して第三機関の駐車料金支払システムと統合する必要がないターンキープラットフォームの形をとる。このような実施形態では、ターンキープラットフォームの一部が、支払ステーション／装置、及び郵送用の駐車違反切符を生成する装置で構成される。

ある実施形態では、オンサイト支払システム１６０が、ターンキープラットフォームペイ・バイ・フォン機能を含むことができる。最終的に、エンドユーザは、特定のＩＶＲ（双方向音声応答）システムによる電話回線に電話し、目的地が道路脇の駐車メータに関連しているか、ペイ・バイ・スペースの駐車スペースに関連しているか、それとも駐車区画に関連しているかに関わらず、目的地識別子又は車両のナンバープレート番号と駐車時間とを入力することによって駐車料を支払うことができる。

ターンキーペイ・バイ・フォンモジュールは、エンドユーザが電話（通常は携帯電話）を使用して駐車料金を支払えるようにする。ターンキーペイ・バイ・フォン機構は、サーバシステム１４０とのデータベースレベルでの統合を可能にする。データベースレベルでの統合は、より高い柔軟性及び速度を提供するので、ＡＰＩレベルでの統合よりも優れている。

ターンキーペイ・バイ・フォンモジュールは、ユーザが電話を通じて情報を入力した１又はそれ以上のＤＴＭＦトランシーバからデータを受け取る。ターンキーペイ・バイ・フォンモジュールは、正しく動作するためにサーバシステム１４０からデータを受け取る必要がない。ターンキーペイ・バイ・フォンモジュールは、手動で支払われた駐車料金を検証するためのデータをモバイル装置１５０に出力するとともに、自力取締のためのデータをサーバシステム１４０に出力するように構成することができる。全ての自力取締データ処理は、サーバシステム１４０において行われる。

ある実施形態では、オンサイト支払システム１６０が、ターンキープラットフォーム上にペイ・オンラインを含むことができる。最終的に、エンドユーザは、ウェブサイトを訪問して、目的地が道路脇の駐車メータに関連しているか、ペイ・バイ・スペースの駐車スペースに関連しているか、それとも駐車区画に関連しているかに関わらず、目的地識別子又は車両のナンバープレート番号と駐車時間とを入力することにより、駐車料金を支払うこと又はこれまでの履歴を見ることができる。この機能は、スマートフォンなどの他のオンラインルートにも拡張され、将来的には自動車内のインターネット対応メディアセンタにも拡張される。

ターンキーペイ・オンラインモジュールは、エンドユーザがインターネットを通じて情報を入力したデータをオンラインで受け取る。ターンキーペイ・オンラインモジュールは、正しく動作するためにサーバシステム１４０からデータを受け取る必要がない。ターンキーペイ・オンラインモジュールは、手動で支払われた駐車料金を検証するためのデータをモバイル装置１５０に出力するとともに、自力取締のためのデータをサーバシステム１４０に出力する。全ての自力取締データ処理は、サーバシステム１４０において行われる。

ある実施形態では、オンサイト支払システム１６０が、ＱＲコードを有するペイ・アンド・ディスプレイ機構を含むことができる。ＱＲコードは広まってきており、従ってスマートフォンを大いにサポートする。さらに、ＱＲコードは、通常はペイ・アンド・ディスプレイチケットに含まれる全ての関連情報（以下に限定されるわけではないが、駐車、駐車期限、支払額、日付及び時刻など）を容易に保持することができる。ターンキーペイ・アンド・ディスプレイ機構は、エンドユーザが駐車料金を支払い、ＱＲコード付きのディスプレイチケットを車両のダッシュボード上に置いておくことを可能にする。ターンキーペイ・アンド・ディスプレイ機構は、サーバシステム１４０とのデータベースレベルでの統合を可能にする。データベースレベルでの統合は、より高い柔軟性及び速度を提供するので、ＡＰＩレベルでの統合よりも優れている。

ターンキーペイ・アンド・ディスプレイ機構は、内蔵キーパッド、硬貨受け入れ機、クレジットカードリーダ、及びプリンタを介してエンドユーザから支払いを受け取る。文字／グラフィックＬＣＤディスプレイも存在する。ターンキーペイ・アンド・ディスプレイ機構は、正しく動作するためにサーバシステム１４０からデータを受け取る必要がない。ターンキーペイ・アンド・ディスプレイ機構は、手動で支払われた駐車料金を検証するためのデータをモバイル装置１５０に出力するとともに、自力取締のためのデータをサーバシステム１４０に出力する。全ての自力取締データ処理は、サーバシステム１４０において行われる。

ある実施形態では、オンサイト支払システム１６０が、ペイ・バイ・スペースターンキー機構を含むことができる。ペイ・バイ・スペースは、稼働歴の長いペイ・アンド・ディスプレイに比べてますます広まりつつある。ペイ・バイ・スペースを用いた駐車場運営は、印刷された使用期限を手動でチェックするために駐車取締職員が各車両まで歩いて行ってフロントガラスに身を乗り出す必要がないので、一般的に効率性が高い。代わりに、駐車取締職員は、パトロール車両を運転して、使用中の駐車スペースの料金が支払われているかどうかを遠くから視覚的にチェックすることができる。また、ペイ・バイ・スペースでは、ドライバーが機械で支払いを行った後に自分の車両に歩いて戻ってチケットを表示する必要がなく、代わりにそのまま自分の目的地に向かうことができるので、ユーザ体験が向上する。

ターンキーペイ・バイ・スペース機構は、内蔵キーパッド、硬貨受け入れ機、クレジットカードリーダ、及びプリンタを介してエンドユーザからの支払いを受ける。文字／グラフィックＬＣＤディスプレイも存在する。ターンキーペイ・バイ・スペース機構は、正しく動作するためにサーバシステム１４０からデータを受け取る必要がない。ターンキーペイ・バイ・スペース機構は、手動で支払われた駐車料金を検証するためのデータをモバイル装置１５０に出力するとともに、自力取締のためのデータをサーバシステム１４０に出力する。全ての自力取締データ処理は、サーバシステム１４０において行われる。

ある実施形態では、オンサイト支払システム１６０が、ペイ・バイ・プレートターンキー機構を含むことができる。ターンキーペイ・バイ・プレート機構は、内蔵キーパッド、硬貨受け入れ機、クレジットカードリーダ、及びプリンタを介してエンドユーザからの支払いを受ける。文字／グラフィックＬＣＤディスプレイも存在する。ターンキーペイ・バイ・プレート機構は、正しく動作するためにサーバシステム１４０からデータを受け取る必要がない。ターンキーペイ・バイ・プレート機構は、手動で支払われた駐車料金を検証するためのデータをモバイル装置１５０に出力するとともに、自力取締のためのデータをサーバシステム１４０に出力する。全ての自力取締データ処理は、サーバシステム１４０において行われる。

第三機関の駐車システムとの統合は、サーバシステム１４０のための要件ではなく選択肢である。例えば単一の供給業者を通じて駐車施設プラットフォーム全体が提供されるターンキー構成では、第三機関の駐車システムとの統合の必要はない。しかしながら、ＡＰＩを用いた統合アプローチには多くの利点がある。ＡＰＩは、外部プログラムがホストシステムの営業秘密を一切曝すことなくホストシステム内の情報にアクセスできるように設計された標準的なソフトウェアプログラミングインターフェイスを提供する。このアプローチは、外部システムが、所定の情報セットがホストシステム自体においてどのように収集、記憶又は計算されるかを一切知ることなくこれらの情報を取得できるように、２つのシステムの境界において明確に定められた機能、オブジェクト及び変数を作成することによって実現される。従って、一般に、企業は、他のシステムがその企業の製品又はサーバに接続できるようにＡＰＩを公開することに対する不安がない。データは、ＸＭＬ、ＪＳＯＮ、ＨＴＭＬ、ＭＩＭＥ、又はＡＰＩによってサポートされる他の符号化又は言語に依拠するＳＳＬなどの暗号化機構によってしばしば保護されるネットワークベースの機構を通じ、ＡＰＩを介して交換することができる。

サーバシステム１４０とＡＰＩを統合する方法は２つある。まず、サーバシステム１４０が、第三機関の駐車システムによって公開されているＡＰＩを使用することによって（以下に限定されるわけではないが、支払済みの期間及びスペース番号などの）車両支払情報にアクセスすることができる。サーバシステム１４０は、既にサーバシステム１４０が所有している車両検出情報及び車両識別情報と組み合わせて、詳細な駐車違反情報を含む車両ナンバープレートリストを駐車施設オペレータに対して作成するのに必要な完全な情報を有し、又は容易に取得することができる。駐車施設オペレータは、そのＳＯＰに従って、駐車違反チケットを郵送し、車輪止めを設置し、或いは繰り返しの又は悪質な違反者については牽引を行うことができる。

第２の統合方法は、サーバシステム１４０がその独自のＡＰＩを公開し、従って第三機関の駐車システムが車両検出及び車両識別に関する情報を取得できるようにすることである。第三機関の駐車システムは、既に第三機関の駐車システムが所有している車両支払情報と組み合わせて、詳細な駐車違反情報を含む車両ナンバープレートリストを含め、駐車場オペレータにシームレスな提示を行うことができる。第三機関の駐車システムプロバイダは、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けるために、このアプローチを好むと思われる。

サーバシステム１４０は、ＡＰＩを使用することによって、ペイ・バイ・フォン、ペイ・バイ・スペース、ペイ・アンド・ディスプレイ、道路脇駐車メータ（単一スペース又は二重スペース）、及びライブオペレータによるオプションといったタイプの駐車料金支払システムに統合することができる。

ペイ・バイ・フォンの大前提は、（車両のドライバーなどの）エンドユーザが目的地付近に表示された電話番号に電話することである。通常、この電話番号は、自動メニューを通じて発呼者をガイドするＩＶＲ（双方向音声応答）を提供する。エンドユーザは、一意の目的地番号の後に、所望の駐車時間、車両のナンバープレート番号及びクレジットカード情報を入力するように促される。

ペイ・バイ・フォンは、駐車施設オペレータが、道路脇駐車メータ、ペイ・バイ・スペース及びペイ・アンド・ディスプレイ機構にペイ・バイ・フォン機能を追加する評判の良い「オーバーレイ」支払方式として勢いを増し始めている。一般的動機は、駐車場利益を高める目的で、エンドユーザに別の駐車料金支払方法を提供することである。例えば、エンドユーザがクレジットカードでの支払いを電話で行えるようにするために、従来の道路脇駐車メータ（単一スペース又は二重スペース）にペイ・バイ・フォンを追加することができる。

ある実施形態では、サーバシステム１４０が、自力駐車取締に使用する駐車料金支払情報をサーバシステム１４０が第三機関の駐車料金支払システムから抽出するソフトウェアコンポーネントとすることができるペイ・バイ・フォン統合モジュールを含むことができる。ペイ・バイ・フォンのための統合モジュールは、（１）第三機関のペイ・バイ・フォンＡＰＩとの接続を確立するステップ、（２）データ要求を発行するステップ、（３）データを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、第三機関のペイ・バイ・フォンＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）ステップ２〜７を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ（１）に関連して、通常、ＡＰＩは、ＡＰＩへの接続を確立できる機構を指定する。ペイ・バイ・フォン統合モジュールは、第三機関のペイ・バイ・フォンＡＰＩが必要とするプロトコルを観察して接続を確立するように構成される。

ステップ（２）に関連して、サーバシステム１４０は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信（ＩＰＣ）呼出しなどを介してこの事象をペイ・バイ・フォン統合モジュールにシグナリングし、ペイ・バイ・フォン統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関のペイ・バイ・フォンＡＰＩに発行する。第三機関のペイ・バイ・フォンＡＰＩに送信されるデータは、例えば、（プレート番号及び州／県情報を含む）車両ナンバープレート情報、ペイ・バイ・フォンＡＰＩによって認識された目的地識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、及びその特定の車両が目的地から立ち去った日付／時刻を含むことができる。

ステップ（３）に関連して、ペイ・バイ・フォン統合モジュールは、例えば、支払済み駐車開始日／時刻及び支払済み駐車終了日／時刻を含む情報を第三機関のペイ・バイ・フォンＡＰＩから受け取るように構成することができる。ステップ（５）に関連して、ペイ・バイ・フォン統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

サーバシステム１４０によって提供されるＡＰＩを統合に使用する実施形態では、通常は既にペイ・バイ・フォンシステムが車両ナンバープレート情報を所持しているので、ペイ・バイ・フォンシステムはサーバシステム１４０から車両検出情報（実際の車両駐車開始及び終了時刻）のみを取得する。最終的に、ペイ・バイ・フォンシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。

通常、ペイ・バイ・フォンシステム又はそのスタッフは、サーバシステム１４０によって提供されるＡＰＩを使用することに同意できる時には、一般にサーバシステム１４０から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号又は目的地番号について特定の車両が特定の目的地を使用した実際の時間を示す実際の車両駐車継続時間が有用なデータである。車両ナンバープレート番号又は目的地番号は、一般にエンドユーザ支払処理の一部として取得されるので、一般にペイ・バイ・フォンシステムは、これらの番号を既に有している。

サーバシステム１４０によって提供されたペイ・バイ・フォンＡＰＩを介した統合は、２つの選択肢のうちの一方に従うことができる。１つ目は、第三機関の駐車料金支払システムがサーバシステム１４０に情報をプッシュするデータ流入モデルである。２つ目は、サーバシステム１４０が全ての関連情報をペイ・バイ・フォンシステムにプッシュするデータ流出モデルである。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流入型ペイ・バイ・フォンＡＰＩを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型ペイ・バイ・フォンＡＰＩを介してサーバシステム１４０に情報をプッシュする。流入型ペイ・バイ・フォンＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムからデータを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、流入型ペイ・バイ・フォンＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型ペイ・バイ・フォンＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流入型ペイ・バイ・フォンＡＰＩを介して、車両／ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、例えば（プレート番号及び州／県情報を含む）車両ナンバープレート情報、この特定の車両に関連して支払いが受け取られた目的地の識別子（サーバシステム１４０が内部的に使用する識別子への変換を必要とすることがある）、支払済み駐車開始日／時刻及び支払済み駐車終了日／時刻を含むことができる。ステップ（５）に関連して、サーバシステム１４０に含まれるペイ・バイ・フォン統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流出型ペイ・バイ・フォンＡＰＩを含むことができ、この場合、サーバシステム１４０が、全ての関連情報を第三機関のペイ・バイ・フォンシステムにプッシュする。流出型ペイ・バイ・フォンＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムにデータをアップロードするステップ、（４）アップロードされたデータに対する確認応答を受け取るステップ、（５）第三機関の駐車料金支払システムからの「キープアライブ」／「ピン」要求に応答するステップ、及び（６）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型ペイ・バイ・フォンＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流出型ペイ・バイ・フォンＡＰＩを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、特定の車両が目的地の使用を開始した実際の日付／時刻、及び特定の車両が目的地から立ち去った実際の日付／時刻を含むことができる。

別の実施形態では、ペイ・バイ・フォンシステムとサーバシステム１４０の統合が２ステップで行われる。まず、サーバシステム１４０が、ペイ・バイ・フォンシステムから提供されたＡＰＩを使用することにより、ペイ・バイ・フォンシステムから（支払済み駐車の開始及び終了時刻、駐車スペース番号、車両ナンバープレート番号などの）車両支払情報を取得する。この段階で、サーバシステム１４０は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム１４０が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム１４０によって提供されるＡＰＩを用いて車両違反データをペイ・バイ・フォンシステムに送信することによって行うことができる。この時、ペイ・バイ・フォンシステムは、（例えば、ペイ・バイ・フォンシステムの業者によって開発されたカスタムソフトウェアアプリケーションを通じて）「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。

この統合方法と、サーバシステム１４０によって提供されるＡＰＩを介した統合のみに依拠することの大きな相違点は、この統合方法では、ペイ・バイ・フォンシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム１４０によって提供されるＡＰＩによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。

ペイ・バイ・スペースの前提は、エンドユーザが車両を駐車したら駐車スポットのスペース番号を控えることである。エンドユーザは、ペイ・バイ・スペース機構で駐車料金を支払う場合、区画番号を入力した後に所望の駐車期間を入力する。支払いが完了すると、エンドユーザは車内にチケットを置いておく必要はなく、代わりにそのまま行きたい所に行くことができる。ペイ・バイ・スペースは、道路脇の路上駐車及び路外の駐車区画／駐車場ビルの両方において同様に良好に機能する。

ペイ・バイ・スペースは、稼働歴の長いペイ・アンド・ディスプレイに比べてますます広まりつつある。ペイ・バイ・スペースを用いた駐車場経営は、印刷された使用期限を手動でチェックするために駐車取締職員が各車両まで歩いて行ってフロントガラスに身を乗り出す必要がないので、一般的に効率性が高い。代わりに、駐車取締職員は、パトロール車両を運転して、使用中の駐車スペースの料金が支払われているかどうかを遠くから視覚的にチェックすることができる。また、ペイ・バイ・スペースでは、エンドユーザが機械で支払いを行った後に自分の車両に歩いて戻ってチケットを表示する必要がなく、代わりにそのまま自分の目的地に向かうことができるので、ユーザ体験が向上する。

上述したペイ・バイ・フォンと同様に、統合は、ペイ・バイ・スペースシステムによって提供されたＡＰＩ、又はサーバシステム１４０によって提供されるＡＰＩのいずれかを使用することによって行うことができる。その目的は、両システムが、駐車違反情報を含む車両ナンバープレートリストを作成するために必要な全ての情報にアクセスできるようにすることである。

ペイ・バイ・スペースシステムによって提供されたＡＰＩを介してサーバシステム１４０が統合される実施形態では、サーバシステム１４０が、ペイ・バイ・スペースシステムから（支払済み駐車の開始及び終了時刻、目的地番号、及び車両ナンバープレート番号などの）車両支払情報を取得する。最終的に、サーバシステム１４０は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。

ある実施形態では、サーバシステム１４０が、サーバシステム１４０が自力駐車取締に使用する駐車料金支払情報を第三機関の駐車料金支払システムから抽出するソフトウェアコンポーネントとすることができるペイ・バイ・スペース統合モジュールを含むことができる。ペイ・バイ・スペースのための統合モジュールは、（１）第三機関のペイ・バイ・スペースＡＰＩとの接続を確立するステップ、（２）データ要求を発行するステップ、（３）データを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、第三機関のペイ・バイ・スペースＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）ステップ２〜７を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ（１）に関連して、通常、ＡＰＩは、ＡＰＩへの接続を確立できる機構を指定する。ペイ・バイ・スペース統合モジュールは、第三機関のペイ・バイ・スペースＡＰＩが必要とするプロトコルを観察して接続を確立するように構成される。

ステップ（２）に関連して、サーバシステム１４０は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信（ＩＰＣ）呼出しなどを介してこの事象をペイ・バイ・スペース統合モジュールにシグナリングし、ペイ・バイ・スペース統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関のペイ・バイ・スペースＡＰＩに発行する。第三機関のペイ・バイ・スペースＡＰＩに送信されるデータは、例えば、ペイ・バイ・スペースＡＰＩによって認識された目的地識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、及びその特定の車両が目的地から立ち去った日付／時刻を含むことができる。

ステップ（３）に関連して、ペイ・バイ・スペース統合モジュールは、例えば、支払済み駐車開始日／時刻及び支払済み駐車終了日／時刻を含む情報を第三機関のペイ・バイ・スペースＡＰＩから受け取るように構成することができる。ステップ（５）に関連して、ペイ・バイ・スペース統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

サーバシステム１４０によって提供されるＡＰＩを介してサーバシステム１４０がペイ・バイ・スペースシステムに統合される実施形態では、サーバシステム１４０が、ペイ・バイ・スペースシステムに（車両ナンバープレート番号、目的地、及び実際の駐車開始及び終了時刻などの）車両情報を送信する。最終的に、ペイ・バイ・スペースシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。

通常、ペイ・バイ・スペースシステム又はそのスタッフは、サーバシステム１４０によって提供されるＡＰＩを使用することに同意できる時には、一般にサーバシステム１４０から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号又はスペース番号について特定の車両が特定の目的地を使用した実際の時間である実際の車両駐車継続時間が有用なデータである。一般に、車両ナンバープレート番号又はスペース番号は、エンドユーザ支払処理の一部として取得することができるので、ペイ・バイ・スペースシステムは、これらの番号を既に有している。

サーバシステム１４０によって提供されたペイ・バイ・スペースＡＰＩを介した統合は、２つの選択肢のうちの一方に従うことができる。１つ目は、第三機関の駐車料金支払システムがサーバシステム１４０に情報をプッシュするデータ流入モデルである。２つ目は、サーバシステム１４０が全ての関連情報を第三機関のペイ・バイ・スペースシステムにプッシュするデータ流出モデルである。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流入型ペイ・バイ・スペースＡＰＩを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型ペイ・バイ・スペースＡＰＩを介してサーバシステム１４０に情報をプッシュする。流入型ペイ・バイ・スペースＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムからデータを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、流入型ペイ・バイ・スペースＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型ペイ・バイ・スペースＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流入型ペイ・バイ・スペースＡＰＩを介して、車両／ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、この特定の車両に関連して支払いが受け取られた目的地の識別子（サーバシステム１４０が内部的に使用する識別子への変換を必要とすることがある）、支払済み駐車開始日／時刻及び支払済み駐車終了日／時刻を含むことができる。ステップ（５）に関連して、サーバシステム１４０に含まれるペイ・バイ・スペース統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流出型ペイ・バイ・スペースＡＰＩを含むことができ、この場合、サーバシステム１４０が、全ての関連情報を第三機関のペイ・バイ・スペースシステムにプッシュする。流出型ペイ・バイ・スペースＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムにデータをアップロードするステップ、（４）アップロードされたデータに対する確認応答を受け取るステップ、（５）第三機関の駐車料金支払システムからの「キープアライブ」／「ピン」要求に応答するステップ、及び（６）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型ペイ・バイ・スペースＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流出型ペイ・バイ・スペースＡＰＩを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、特定の車両が目的地の使用を開始した実際の日付／時刻、及び特定の車両が目的地から立ち去った実際の日付／時刻を含むことができる。

別の実施形態では、サーバシステム１４０が、ペイ・バイ・スペースシステムに２ステップで統合されるように構成される。まず、サーバシステム１４０が、ペイ・バイ・スペースシステムから提供されたＡＰＩを使用することにより、ペイ・バイ・スペースシステムから車両支払情報（例えば、支払済み駐車の開始及び終了時刻、駐車スペース番号、車両ナンバープレート番号）を取得する。この段階で、サーバシステム１４０は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム１４０が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム１４０によって提供されるＡＰＩを用いて車両違反データをペイ・バイ・スペースシステムに送信することによって行うことができる。この時、ペイ・バイ・スペースシステムは、（ペイ・バイ・スペースシステムの業者によって開発されたカスタムソフトウェアアプリケーションなどを通じて）「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。

この統合方法と、サーバシステム１４０によって提供されるＡＰＩを介したペイ・バイ・スペースシステムとの統合の大きな相違点は、この統合方法では、ペイ・バイ・スペースシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム１４０によって提供されるＡＰＩによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。

ペイ・アンド・ディスプレイの前提は、エンドユーザが駐車料金を支払ったら、駐車取締職員がエンドユーザによる支払いの期間が切れていないことを確実にするためにチケットの目視チェックを行えるように、車内のダッシュボード上にチケットを置いておく必要があることである。

従来、ペイ・アンド・ディスプレイは、路外の駐車区画及び駐車場ビルを独占していた。最近ではペイ・バイ・スペース機構が広まっているにも関わらず、ペイ・アンド・ディスプレイは、依然として広い設置基盤を有している。道路脇の駐車のために配備されたペイ・アンド・ディスプレイシステムも存在する。

サーバシステム１４０は、自己取締能力を可能にするために、（州／県を含む）車両ナンバープレート情報、実際の駐車開始及び終了時刻、支払済み駐車の継続時間といった情報を必要とする。

サーバシステム１４０とペイ・アンド・ディスプレイシステムを統合する実施形態では、サーバシステム１４０が、識別カメラを介して車両ナンバープレート情報を収集し、目的地カメラが、車両がいつ目的地に入っていつ立ち去ったかをサーバシステム１４０が特定できるようにすることにより、実際の駐車開始及び終了時刻を提供する。支払済み駐車時間は、パン、チルト及びズーム能力を有する目的地カメラを利用してズームインし、エンドユーザが車両のダッシュボード上に置いたディスプレイチケット自体からバーコード又は印刷文字を抽出することによって特定することができる。

ある実施形態では、このような情報の読み取りを容易にするために、ペイ・アンド・ディスプレイ機構を、印刷文字に大きなフォントを使用するように、又はその他の識別特徴を大きく印刷するように構成することができる。別の実施形態では、従来のシステムが、ドライバーが車両を駐車したいと望む時間しか求めないのに対し、ペイ・アンド・ディスプレイ機構は、支払処理の一部としてナンバープレート番号を求めるように構成することができる。ある実施形態では、ペイ・アンド・ディスプレイ機構が、ロール状のディスプレイチケット用紙を利用し、各ディスプレイチケット内にＲＦＩＤチップを埋め込むことができる。

ある実施形態では、サーバシステム１４０を、ペイ・アンド・ディスプレイ機構を視野に含むカメラなどの１又はそれ以上のカメラを介して取り込まれた複数の画像に基づいて、歩行者追跡を行うように構成することができる。歩行者追跡では、サーバシステム１４０が車両追跡を行うのと同様に、サーバシステム１４０を、ペイ・アンド・ディスプレイ機構を介して支払いを得る車両との間を行き来する車両のドライバー及び／又は乗客を追跡するように構成することができる。この追跡した歩行者の動きに基づいて、車両の特定の場所に支払いをリンクさせ、ナンバープレート番号などの対応する車両識別子サーバシステム１４０によって特定することができる。このような実施形態では、印刷されたチケットから直接情報を取り込む必要がない。一例では、サーバシステム１４０が、ある個人が車両の乗客であったことを立証する１又はそれ以上の画像、及びこの乗客が目的地の使用に対してペイ・アンド・ディスプレイ支払ステーションで支払いを行ったことを立証する１又はそれ以上の画像を含む、１又はそれ以上のカメラによって取り込まれた複数の歩行者画像を受け取ることができる。サーバシステム１４０は、歩行者画像に取り込まれた歩行者について特定された特徴が時間が経っても一致するかどうかを判定することによって追跡を行い、この乗客が車両と支払ステーションの間を移動して支払いを行ったことを立証するように構成することができる。これに基づき、サーバシステム１４０は、この支払いをこの車両による特定の目的地の使用に関連付けることができる。

この情報が利用可能になると、サーバシステム１４０は、詳細な違反情報を含む車両ナンバープレートリストを作成することができる。ペイ・アンド・ディスプレイシステム自体は、この情報を一切処理しないので、このことは、ペイ・アンド・ディスプレイシステムがリアルタイム無線ネットワーキングをサポートしているかどうかに関係なく当てはまる。

サーバシステム１４０によって提供されるＡＰＩを介してサーバシステム１４０とペイ・アンド・ディスプレイシステムを統合する実施形態では、サーバシステム１４０が、自己取締能力を可能にするために、車両ナンバープレート情報（州／県情報を含む）、実際の駐車開始及び終了時刻、及び支払済み駐車の継続時間を必要とする。

サーバシステム１４０は、識別カメラを介して車両ナンバープレート情報を収集し、目的地カメラは、車両がいつ駐車スペースに入っていつ立ち去ったかを検出することにより、サーバシステム１４０が実際の駐車開始及び終了時刻を特定できるようにする。支払済み駐車継続時間は、パン、チルト及びズーム機能を有する目的地カメラを使用してズームインを可能にし、エンドユーザが車両のダッシュボード上に置いたディスプレイチケット自体からバーコード又は印刷文字を抽出することによって特定することができる。

サーバシステム１４０によって提供されるペイ・アンド・ディスプレイＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムにデータをアップロードするステップ、（４）アップロードされたデータに対する確認応答を受け取るステップ、（５）第三機関の駐車料金支払システムからの「キープアライブ」／「ピン」要求に応答するステップ、及び（６）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前にペイ・アンド・ディスプレイＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、ペイ・アンド・ディスプレイＡＰＩを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、特定の車両が目的地の使用を開始した実際の日付／時刻、及び特定の車両が目的地から立ち去った実際の日付／時刻を含むことができる。

サーバシステム１４０は、このモードで動作するように構成されている場合、（車両ナンバープレート番号、支払済み駐車の開始及び終了時刻、実際の駐車開始及び終了時刻などの）車両駐車違反情報をペイ・アンド・ディスプレイシステムに送信する。最終的に、第三機関のペイ・アンド・ディスプレイシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。

通常、ペイ・アンド・ディスプレイシステム又はそのスタッフは、サーバシステム１４０によって提供されるＡＰＩを使用することに同意できる時には、一般にサーバシステム１４０から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号についての支払済み駐車の開始及び終了時刻、並びに実際の車両駐車開始及び終了時刻が有用なデータである。一般に、ペイ・アンド・ディスプレイシステムは（印刷されたディスプレイチケットに依拠するので）紙に基づいており、車両識別情報又は目的地番号に関する情報は一切所有していない。ペイ・アンド・ディスプレイシステムは、支払済み駐車の開始時間及び支払済み駐車の継続時間は所有しているが、これらのシステムは、その支払済み駐車がどの車両に相関するものであるかが分からない。ペイ・アンド・ディスプレイシステムは、サーバシステム１４０によって提供されるＡＰＩを使用することにより、駐車違反情報を含む車両のリストを駐車場オペレータに提示するという選択肢を有する。ペイ・アンド・ディスプレイシステムは、このＡＰＩを通じてサーバシステム１４０から関連情報を取得し、この情報をあらゆる所望のフォーマットで提示することができる。

従って、サーバシステム１４０によって提供されるＡＰＩを介した統合は、サーバシステム１４０が全ての関連情報をペイ・アンド・ディスプレイシステムに「プッシュ」する「プッシュ」モデルである。その後、ペイ・アンド・ディスプレイシステムは、未払いの又は期限切れ駐車の車両ナンバープレートリストを表示する。換言すれば、サーバシステム１４０によって提供されるＡＰＩを介したペイ・アンド・ディスプレイの統合は、一般に「プル」モデルでは実現されない。

ある実施形態では、ＱＲコードを含むペイ・アンド・ディスプレイ機構を設けることができる。ＱＲコードは広まってきており、ペイ・アンド・ディスプレイチケットに通常含まれる全ての関連情報（駐車期間、駐車期限、支払額、日付及び時間など）を容易に保持することができる。

ある実施形態では、ペイ・バイ・フォンシステムが、ペイ・アンド・ディスプレイ駐車システムに重なることができ、ＡＰＩを介してペイ・バイ・フォン支払システムにサーバシステム１４０を統合することができる。このような事例では、ペイ・バイ・フォンシステムによって提供されるＡＰＩを使用する場合、通常は既にペイ・バイ・フォンシステムが車両ナンバープレート情報を所有しているので、サーバシステム１４０は、ペイ・バイ・フォンシステムに車両検出情報を送信する。最終的に、ペイ・バイ・フォンシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な情報を有するようになる。

従来の道路脇駐車メータ（単一スペース又は二重スペース）は、硬貨を受け入れるのみであって内蔵知能又はネットワーキング能力を有していないが、ペイ・バイ・フォンは、従来の道路脇駐車メータと共に良好に機能する人気の高い「オーバーレイ」支払方式になってきた。最近では、硬貨とクレジットカードの両方を受け付けネットワーキング能力も内蔵した道路脇駐車メータも出現してきている。

従来の駐車メータは、一般に支払済み駐車期間が過ぎていること、又は単純に駐車料金が支払われていないことを示す機械的な、又はＬＣＤディスプレイによる「期限切れフラグ」を有する。駐車料金が支払われていて時間が残っている時には、機械的期限切れフラグ（通常は赤色）が視界から隠され、ＬＣＤディスプレイが、メータの道路に面する側に鮮やかな表示を示す。対照的に、支払済み駐車の期限が切れた時、又は支払いが行われていない時には、赤色の機械的期限切れフラグが「上部」位置に目立つように表示され、道路側に面したＬＣＤディスプレイが、鮮やかな表示と暗い表示を（時には点滅する赤色ＬＥＤも用いて）交互に点滅させる。これらは、いずれも一般に期限切れフラグと呼ばれる。

ある実施形態では、サーバシステム１４０が、識別カメラ及び目的地カメラの両方から収集された情報の組み合わせを用いて、従来の道路脇駐車メータとやりとりすることができる。識別カメラ及び目的地カメラによって取り込まれた画像は、（以下に限定されるわけではないが、駐車開始及び終了時刻などの）車両駐車状況を識別することに加え、駐車メータ上の（以下に限定されるわけではないが、前納時間が切れているかどうかなどの）支払済み駐車状況を示すこともできる。

サーバシステム１４０は、識別カメラによって取り込まれた画像を通じて車両ナンバープレート情報を収集する一方で、目的地カメラによって取り込まれた画像を通じて車両がいつ駐車スペースに入っていつ駐車スペースを離れたかを検出することにより、実際の駐車開始及び終了時刻を特定することができる。支払済み駐車の期限切れ時間は、位置及び目的地カメラの両方を用いてズームインを行い、各駐車メータ上の目に見える期限切れフラグの状況をモニタすることによって特定される。サーバシステム１４０は、この情報に基づいて駐車違反状況を特定し、例えば後述する駐車違反前処理ロジックによってさらに処理できるように、データベース１４１内で目的地の使用に駐車違反としてマーキングすることができる。サーバシステム１４０が期限切れフラグを確認できない状況では、サーバシステム１４０を、駐車場オペレータ又はスタッフに例外を示し、及び／又はライブオペレータ（後述）を用いて駐車違反状況及び／又は例外フラグ状況を手動で特定するように構成することができる。

通りの反対側から目的地カメラによって取り込まれた目的地画像は、各駐車メータの期限切れフラグ状況をモニタするのに十分な視野角を有する。また、パン、チルト及びズーム能力を有する識別カメラは、各駐車メータの期限切れフラグ状況をモニタするのにも十分なズームパワー及び視野角を有することができる。上記情報が利用可能になると、サーバシステム１４０は、詳細な違反情報を含む車両ナンバープレートリストを作成することができる。

サーバシステム１４０によって提供されるＡＰＩを介してサーバシステム１４０と従来の道路脇駐車メータシステムを統合する実施形態では、サーバシステム１４０が、自己取締能力を可能にするために、車両ナンバープレート情報（州／県情報を含む）、実際の駐車開始及び終了時刻、及び支払済み駐車の継続時間を必要とする。

サーバシステム１４０は、識別カメラによって取り込まれた画像を通じて車両ナンバープレート情報を収集する一方で、目的地カメラによって取り込まれた画像を通じて車両がいつ駐車スペースに入っていつ駐車スペースを離れたかを検出することにより、実際の駐車開始及び終了時刻を特定することができる。支払済み駐車の期限切れ時間は、位置及び目的地カメラの両方を用いてズームインを行い、各駐車メータ上の目に見える期限切れフラグの状況をモニタすることによって特定される。サーバシステム１４０は、この情報に基づいて駐車違反状況を特定し、例えば後述する駐車違反前処理ロジックによってさらに処理できるように、データベース１４１内で目的地の使用に駐車違反としてマーキングすることができる。サーバシステム１４０が期限切れフラグを確認できない状況では、サーバシステム１４０を、駐車場オペレータ又はスタッフに例外を示し、及び／又はライブオペレータ（後述）を用いて駐車違反状況及び／又は例外フラグ状況を手動で特定するように構成することができる。

サーバシステム１４０によって提供される従来の道路脇駐車メータＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムにデータをアップロードするステップ、（４）アップロードされたデータに対する確認応答を受け取るステップ、（５）第三機関の駐車料金支払システムからの「キープアライブ」／「ピン」要求に応答するステップ、及び（６）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に従来の道路脇駐車メータＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、従来の道路脇駐車メータＡＰＩを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、特定の車両が目的地の使用を開始した実際の日付／時刻、及び特定の車両が目的地から立ち去った実際の日付／時刻を含むことができる。

サーバシステム１４０は、このモードで動作するように構成されている場合、通常は実際の道路脇メータとの接続性を有していない支払収集／集計システムである従来の道路脇駐車メータシステムに車両駐車違反情報を送信する。最終的に、従来の道路脇駐車メータシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。

通常、従来の道路脇駐車メータシステム又はそのスタッフは、サーバシステム１４０によって提供されるＡＰＩを使用することに同意できる時には、一般にサーバシステム１４０から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号についての期限切れ又は未払い駐車状況、並びに実際の車両駐車開始及び終了時刻が有用なデータである。一般に、従来の道路脇駐車メータシステムは、車両識別情報又はスペース番号に関する情報を一切所有していない。

従って、サーバシステム１４０によって提供されるＡＰＩを介した統合は、サーバシステム１４０が全ての関連情報を従来の道路脇駐車メータシステムに「プッシュ」する「プッシュ」モデルである。その後、従来の道路脇駐車メータシステムは、未払いの又は期限切れ駐車の車両ナンバープレートリストを表示する。

ある実施形態では、ペイ・バイ・フォンシステムが、従来の道路脇駐車システムに重なることができ、ＡＰＩを介してペイ・バイ・フォン支払システムにサーバシステム１４０を統合することができる。このような事例では、ペイ・バイ・フォンシステムによって提供されるＡＰＩを使用する場合、通常は既にペイ・バイ・フォンシステムが車両ナンバープレート情報を所有しているので、サーバシステム１４０は、ペイ・バイ・フォンシステムに車両検出情報を送信する。最終的に、ペイ・バイ・フォンシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な情報を有するようになる。

最近では、内蔵型３Ｇ又はＷｉＦｉモデムを用いてクレジットカード承認を行う道路脇駐車メータ（単一スペース又は二重スペース）が導入されてきている。ある実施形態では、サーバシステム１４０を、道路脇駐車メータＡＰＩを介してこの種の駐車メータとやりとりするように構成することができる。具体的には、これらの道路脇駐車メータは、無線ネットワーク接続性及び関連するバックエンドサーバを既に組み込んでいるので、サーバシステム１４０をこの第三機関のバックエンドサーバに統合することは困難ではない。

サーバシステム１４０がこのモードで動作するように構成されている場合、道路脇駐車メータＡＰＩのための統合モジュールは、（１）第三機関の道路脇駐車メータＡＰＩとの接続を確立するステップ、（２）データ要求を発行するステップ、（３）データを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、道路脇駐車メータＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）ステップ２〜７を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ（１）に関連して、通常、ＡＰＩは、ＡＰＩへの接続を確立できる機構を指定する。道路脇駐車メータＡＰＩのための統合モジュールは、道路脇駐車メータＡＰＩが必要とするプロトコルを観察して接続を確立するように構成される。

ステップ（２）に関連して、サーバシステム１４０は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信（ＩＰＣ）呼出しなどを介してこの事象を道路脇駐車メータＡＰＩのための統合モジュールにシグナリングし、道路脇駐車メータＡＰＩのための統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関の道路脇駐車メータＡＰＩに発行する。第三機関の道路脇駐車メータＡＰＩに送信されるデータは、例えば、道路脇駐車メータＡＰＩによって認識された目的地識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、及びその特定の車両が目的地から立ち去った日付／時刻を含むことができる。

ステップ（３）に関連して、道路脇駐車メータＡＰＩのための統合モジュールは、例えば、道路脇駐車メータＡＰＩによって認識された目的地の識別子（サーバシステム１４０が内部的に使用する識別子への変換を必要とすることがある）、支払済み駐車開始日／時刻、及び支払済み駐車終了日／時刻を含む情報を第三機関の道路脇駐車メータＡＰＩから受け取るように構成することができる。ステップ（５）に関連して、道路脇駐車メータＡＰＩのための統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

従って、道路脇駐車メータＡＰＩを介した統合は、第三機関の道路脇駐車メータシステムが出力できる全ての関連情報をサーバシステム１４０が「プル」し、サーバシステム１４０によって特定された自動化車両違反情報を加えて未払い又は期限切れ駐車の車両ナンバープレートリストを作成する「プル」モデルである。換言すれば、道路脇駐車メータＡＰＩを介した統合は、一般に「プッシュ」モデルでは実現されない。

サーバシステム１４０が、サーバシステム１４０によって提供されるＡＰＩを介して道路脇駐車メータシステムに統合されるように構成される実施形態では、サーバシステム１４０が、道路脇駐車メータシステムに（車両ナンバープレート番号、目的地、及び実際の駐車開始及び終了時刻などの）車両情報を送信する。最終的に、道路脇駐車メータシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。

通常、道路脇駐車メータシステム又はそのスタッフは、サーバシステム１４０によって提供されるＡＰＩを使用することに同意できる時には、一般にサーバシステム１４０から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号又は目的地番号について特定の車両が特定の目的地を使用した実際の時間である実際の車両駐車継続時間が有用なデータである。一般に、車両ナンバープレート番号又はスペース番号は、一般にエンドユーザ支払処理の一部として取得することができるので、道路脇駐車メータシステムは、この情報を既に有している。

サーバシステム１４０によって提供される道路脇駐車メータＡＰＩを介した統合は、２つの選択肢のうちの一方に従うことができる。１つ目は、第三機関の駐車料金支払システムがサーバシステム１４０に情報をプッシュするデータ流入モデルである。２つ目は、サーバシステム１４０が全ての関連情報を道路脇駐車メータシステムにプッシュするデータ流出モデルである。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流入型道路脇駐車メータＡＰＩを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型道路脇駐車メータＡＰＩを介してサーバシステム１４０に情報をプッシュする。流入型道路脇駐車メータＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムからデータを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、流入型道路脇駐車メータＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型道路脇駐車メータＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流入型道路脇駐車メータＡＰＩを介して、車両／ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、例えばこの特定の車両に関連して支払いが受け取られた目的地の識別子（サーバシステム１４０が内部的に使用する識別子への変換を必要とすることがある）、支払済み駐車開始日／時刻及び支払済み駐車終了日／時刻を含むことができる。ステップ（５）に関連して、サーバシステム１４０に含まれる道路脇駐車メータ統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流出型道路脇駐車メータＡＰＩを含むことができ、この場合、サーバシステム１４０が、全ての関連情報を第三機関の道路脇駐車メータシステムにプッシュする。流出型道路脇駐車メータＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムにデータをアップロードするステップ、（４）アップロードされたデータに対する確認応答を受け取るステップ、（５）第三機関の駐車料金支払システムからの「キープアライブ」／「ピン」要求に応答するステップ、及び（６）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型道路脇駐車メータＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流出型道路脇駐車メータＡＰＩを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、特定の車両が目的地の使用を開始した実際の日付／時刻、及び特定の車両が目的地から立ち去った実際の日付／時刻を含むことができる。

ある実施形態では、サーバシステム１４０を、道路脇駐車メータシステムに２ステップで統合されるように構成することができる。まず、サーバシステム１４０が、道路脇駐車メータシステムから提供されたＡＰＩを使用することにより、道路脇駐車メータシステムから（支払済み駐車の開始及び終了時刻、駐車スペース番号、車両ナンバープレート番号などの）車両支払情報を取得する。この段階で、サーバシステム１４０は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム１４０が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム１４０によって提供されるＡＰＩを用いて車両違反データを道路脇駐車メータシステムに送信することによって行うことができる。この時、道路脇駐車メータシステムは、（道路脇駐車メータシステムの業者によって開発されたカスタムソフトウェアアプリケーションなどを使用して）「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。

この統合方法と、サーバシステム１４０によって提供されるＡＰＩを介した統合との大きな相違点は、この統合方法では、道路脇駐車メータシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム１４０によって提供されるＡＰＩによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。

ペイ・バイ・プレートは、（車両が駐車している）特定の番号付き駐車スペースに駐車料金の支払いを関連付けるペイ・バイ・スペースと同様に、駐車スペース内に駐車された特定のナンバープレートの車両に駐車料金の支払いを関連付ける。通常、ペイ・バイ・プレート駐車の手動取締は、取締官が物理的駐車スペースの前を車で通って全ての駐車車両のナンバープレートが支払済み状態のナンバープレートリストに確実に載るようにするものである。逆に言えば、「支払済み」リスト上にないナンバープレートを有するあらゆる駐車車両は、駐車違反切符を受け取ることになる。

上述したペイ・バイ・フォン及びペイ・バイ・スペースと同様に、統合は、ペイ・バイ・プレートシステムによって提供されるＡＰＩ又はサーバシステム１４０によって提供されるＡＰＩのいずれかを使用することによって行うことができる。その目的は、両システムが、駐車違反情報を含む車両ナンバープレートリストを作成するために必要な全ての情報にアクセスできるようにすることである。

ペイ・バイ・プレートシステムによって提供されたＡＰＩを介してサーバシステム１４０が統合される実施形態では、サーバシステム１４０が、ペイ・バイ・プレートシステムから（支払済み駐車の開始及び終了時刻、及び車両ナンバープレート番号などの）車両支払情報を取得する。最終的に、サーバシステム１４０は、駐車違反の詳細を含む車両ナンバープレートリストを生成するために必要な正確な情報を有するようになる。

ある実施形態では、サーバシステム１４０が、サーバシステム１４０が自力駐車取締に使用する駐車料金支払情報を第三機関の駐車料金支払システムから抽出するソフトウェアコンポーネントとすることができるペイ・バイ・プレート統合モジュールを含むことができる。ペイ・バイ・プレートのための統合モジュールは、（１）第三機関のペイ・バイ・プレートＡＰＩとの接続を確立するステップ、（２）データ要求を発行するステップ、（３）データを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、第三機関のペイ・バイ・プレートＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）ステップ２〜７を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ（１）に関連して、通常、ＡＰＩは、ＡＰＩへの接続を確立できる機構を指定する。ペイ・バイ・プレート統合モジュールは、第三機関のペイ・バイ・プレートＡＰＩが必要とするプロトコルを観察して接続を確立するように構成される。

ステップ（２）に関連して、サーバシステム１４０は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信（ＩＰＣ）呼出しなどを介してこの事象をペイ・バイ・プレート統合モジュールにシグナリングし、ペイ・バイ・プレート統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関のペイ・バイ・プレートＡＰＩに発行する。第三機関のペイ・バイ・プレートＡＰＩに送信されるデータは、例えば、（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、及び特定の車両が目的地から立ち去った日付／時刻を含むことができる。

ステップ（３）に関連して、ペイ・バイ・プレート統合モジュールは、例えば、支払済み駐車開始日／時刻及び支払済み駐車終了日／時刻を含む情報を第三機関のペイ・バイ・プレートＡＰＩから受け取るように構成することができる。ステップ（５）に関連して、ペイ・バイ・プレート統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

サーバシステム１４０によって提供されるＡＰＩを介してサーバシステム１４０がペイ・バイ・プレートシステムに統合される実施形態では、サーバシステム１４０が、ペイ・バイ・プレートシステムに（車両ナンバープレート番号、目的地、及び実際の駐車開始及び終了時刻などの）車両情報を送信する。最終的に、ペイ・バイ・プレートシステムは、駐車違反の詳細を含む車両ナンバープレートリストを生成するために必要な正確な情報を有するようになる。

通常、ペイ・バイ・プレートシステム又はそのスタッフは、サーバシステム１４０によって提供されるＡＰＩを使用することに同意できる時には、一般にサーバシステム１４０から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号について特定の車両が目的地を使用した実際の時間である実際の車両駐車継続時間が有用なデータである。基本的に、車両ナンバープレート番号は、エンドユーザ支払処理の一部として取得されるので、ペイ・バイ・プレートシステムは、これらの番号を既に有している。

サーバシステム１４０によって提供されたペイ・バイ・プレートＡＰＩを介した統合は、２つの選択肢のうちの一方に従うことができる。１つ目は、第三機関の駐車料金支払システムがサーバシステム１４０に情報をプッシュするデータ流入モデルである。２つ目は、サーバシステム１４０が全ての関連情報を第三機関のペイ・バイ・レートシステムにプッシュするデータ流出モデルである。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流入型ペイ・バイ・プレートＡＰＩを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型ペイ・バイ・プレートＡＰＩを介してサーバシステム１４０に情報をプッシュする。流入型ペイ・バイ・プレートＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムからデータを受け取るステップ、（４）データを処理してデータベース１４１に記憶するステップ、（５）駐車違反状況を特定するステップ、（６）例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース１４１内でマーキングするステップ、（７）以下に限定されるわけではないが、「キープアライブ」／「ピン」メッセージ又はコマンドの使用などにより、流入型ペイ・バイ・プレートＡＰＩが作動中であり有効であることを定期的に確認するステップ、及び（８）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型ペイ・バイ・プレートＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流入型ペイ・バイ・プレートＡＰＩを介して、車両／ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、例えば、（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、支払済み駐車開始日／時刻、及び支払済み駐車終了日／時刻を含むことができる。ステップ（５）に関連して、サーバシステム１４０に含まれるペイ・バイ・プレート統合モジュールは、ステップ（３）から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム１４０によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ（６）の処理が行われ、そうでなければステップ（６）は行われない。

ある実施形態では、サーバシステム１４０が、例えばネットワーク１１０を介して第三機関の駐車料金支払システムによって使用される流出型ペイ・バイ・プレートＡＰＩを含むことができ、この場合、サーバシステム１４０が、全ての関連情報を第三機関のペイ・バイ・プレートシステムにプッシュする。流出型ペイ・バイ・プレートＡＰＩは、例えば、（１）第三機関の駐車料金支払システムが接続を確立するのを待つステップ、（２）第三機関の駐車料金支払システムの識別情報を認証するステップ、（３）第三機関の駐車料金支払システムにデータをアップロードするステップ、（４）アップロードされたデータに対する確認応答を受け取るステップ、（５）第三機関の駐車料金支払システムからの「キープアライブ」／「ピン」要求に応答するステップ、及び（６）必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ（１）に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのＴＣＰ又はＵＤＰポートをリスンすることができる。ステップ（２）に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型ペイ・バイ・プレートＡＰＩを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ（３）に関連して、サーバシステム１４０は、流出型ペイ・バイ・プレートＡＰＩを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば（ナンバープレート番号及び州／県情報を含む）車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子（サーバシステム１４０が内部的に使用する識別子からの変換を必要とすることがある）、特定の車両が目的地の使用を開始した実際の日付／時刻、及び特定の車両が目的地から立ち去った実際の日付／時刻を含むことができる。

別の実施形態では、サーバシステム１４０が、ペイ・バイ・プレートシステムに２ステップで統合されるように構成される。まず、サーバシステム１４０が、ペイ・バイ・プレートシステムから提供されたＡＰＩを使用することにより、ペイ・バイ・プレートシステムから車両支払情報（例えば、支払済み駐車の開始及び終了時刻、並びに車両ナンバープレート番号）を取得する。この段階で、サーバシステム１４０は、駐車違反の詳細を含む車両ナンバープレートリストを生成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム１４０が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム１４０によって提供されるＡＰＩを用いて車両違反データをペイ・バイ・プレートシステムに送信することによって行うことができる。この時、ペイ・バイ・プレートシステムは、（ペイ・バイ・プレートシステムの業者によって開発されたカスタムソフトウェアアプリケーションなどを通じて）「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。

この統合方法と、サーバシステム１４０によって提供されるＡＰＩを介したペイ・バイ・プレートシステムとの統合の大きな相違点は、この統合方法では、ペイ・バイ・プレートシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム１４０によって提供されるＡＰＩによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。

図１に示すシステムの一部としてライブオペレータチームを使用することが検討に値し、予想される駐車場オペレータに付加価値機能として提示すべき実務上の選択肢を提供できる理由は主に２つある。

まず、サーバシステム１４０は、識別カメラ及び目的地カメラから取得された画像を自律的に受け取って処理するが、通常は、取得された画像、及びサーバシステム１４０上で実行されるソフトウェアをモニタするライブオペレータが存在する。これらのライブオペレータは、サーバシステム１４０の動作を再検討し、必要に応じて例外毎に適切な措置を取ることができる。例えば、予想外の問題が生じた場合、ライブオペレータは、その問題に関する画像を見直して、サーバシステム１４０が対処するように構成されていない可能性がある旨の情報を導出することができる。

サーバシステム１４０によってサポートされているネットワークアーキテクチャの利点は、複数のサイトの運営を、これらのそれぞれの地理的位置に関わらず、或いは設備の運営が異なる駐車場運営又は競合他社によって所有されている可能性があるという事実に関わらず、単一のライブオペレータチームによって監督又は増強できる点である。この結果、ライブオペレータの選択肢は、駐車場オペレータにとってスケーラブルかつコスト効率の良い方法になり得る。さらに、ＩＰマルチキャスト又は同様の標準的ＴＣＰ／ＩＰプロトコルを使用することにより、ビデオストリームを複数の目的地に効果的に同時送信することができ、この結果、駐車場オペレータによって配置されたローカルなオンサイトモニタリングに加え、将来的にライブオペレータの選択肢を追加できるようになる。

第２に、上述したペイ・アンド・ディスプレイ構成及び道路脇メータ構成は、利用可能な技術に応じて重大な現実的問題を示すことがある。高レベルのズームを備えたカメラが必要なだけでなく、特定のビデオカメラからの視野角が従来の道路脇駐車メータの期限切れフラグを正しく検出するのに十分でなかったり、或いはダッシュボードの物理的な３次元形状及びチケット自体の配置に起因して、車両のダッシュボード上のペイ・アンド・ディスプレイチケットのバーコードがあらゆるビデオカメラとは違う方向を向いていたりなどの潜在的な問題点もある。

ライブオペレータの選択肢では、サーバシステム１４０が、ナンバープレート番号、従来の駐車メータ上の期限切れフラグの状態、又はペイ・アンド・ディスプレイチケット上のバーコード／印刷情報などの重要な情報部分を自動的に検出できなかった時に例外事象を生成することがある。ライブオペレータは、このような例外事象により、以下に限定されるわけではないが、識別カメラ及び／又は目的地カメラによって取り込まれた映像の巻き戻し／早送り／一時停止／コマ送り及びコマ戻しを行うこと、取り込まれた映像内の特定の関心領域にズームイン／アウトすること、改善された画像を取得するためにビデオカメラをリアルタイムでパン／チルト／ズームすること、及びサーバシステム１４０が使用するための改善された画像を取得するために現場係員を派遣して視覚的に又はモバイル装置１５０を用いて車両又は駐車メータの検査を行うことなどを含むいくつかの特定の対策を取り始めることができる。

ある実施形態では、サーバシステム１４０が、駐車場オペレータが駐車違反切符の歳入を得られるように、車両の登録所有者の郵送先住所をそのナンバープレート番号に相関付けるように構成される。赤信号カメラシステムは、このような機構を利用して車両の登録所有者に違反チケットを郵送する。このような機能に関連して、駐車場オペレータは、３つの異なるカテゴリに入る。

第１に、駐車場オペレータが、既にＤＭＶの記録にアクセスできている都市／地方自治体の一部である場合、サーバシステム１４０は、登録所有者に違反切符を郵送するために、州／県情報及び（日付、時間及び場所などの）駐車違反の詳細を含む車両ナンバープレート番号リストを提供するだけでよい。

第２に、ＤＭＶの記録に事前にアクセスできない民間駐車場オペレータの場合、車両ナンバープレート番号に関連する名前及び住所を含む個人情報を取得するための法的方法がいくつか存在する。これらの方法は、州（及び県）毎に異なる。一例として、ニューヨーク州では、民間駐車場オペレータが、ドライバー・プライバシー保護法（ＤＰＰＡ）の形式ＭＶ−１５ＤＰＰＡ：「民間有料交通機関の運営に関連する使用について」、「施設を使用した車両の所有者に通知を行う目的の駐車施設運営会社を含む」を使用することによってこのような情報にアクセスすることができる。管轄によっては、名前及び住所情報をオンラインで公表できるところもあり、従ってサーバシステム１４０を、このような情報を取得して処理するように構成することができる。管轄によっては、第三者車両所有者の名前及び住所情報をオンラインで公表することができず、代わりに郵便で又は本人が直接取得しなければならないところもある。このような管轄では、民間駐車場オペレータは、（毎日、２、３日毎、又は１週間毎などの）１回毎に名前及び住所情報を取得したいと望むことができる。

第３に、登録所有者情報へのリアルタイムなアクセスを好む民間駐車場オペレータの場合、いくつかの私的な車両ナンバープレートデータベースがインターネットを介して利用可能である。この方法の主な利点は、手動操作を必要とせずに名前及び住所情報を速やかに自動で検索できる点である。

図１に関連して上述したように、エンドユーザシステム１７０は、車載システムを含むことができる。ある実施形態では、自動車メーカーで製造されたばかりの最新の車両計器盤が、「エンジンチェック」、サイドブレーキ警告、又はクルーズコントロール表示灯などの他の計器灯と同様の表示アイコンを含むことができる。通常、この表示アイコンは、車両１３０が高速道路を走行中である場合、或いはサーバシステム１４０が機能する境界内に存在しない場合には点灯しない。車両１３０が駐車区画又は道路脇駐車区域に近付くと、この表示アイコンが黄色に点灯して、サーバシステム１４０が提供する自動駐車サービスを利用できることをエンドユーザに通知する。車両１３０が駐車スペースなどの目的地に入ると、この表示アイコンが赤色に変わって、駐車料金が未納であることをエンドユーザに通知する。（上述したペイ・バイ・フォン、道路脇メータ、ペイ・バイ・スペース、又はその他の技術のいずれによってかに関わらず）駐車料が支払われると、この表示アイコンが緑色になって駐車料が支払われたことを知らせる。ある実施形態では、これらの視覚表示を、単純なチャイム又は音声アナウンスとすることができる音声通知によって実現することができる。音声出力は、車両の娯楽装置に音声情報又はデータを提供することによって行うことができる。

本発明は、駐車料金支払及び取締処理の多くの態様を自動化するので、サーバシステム１４０が何を行っているか、又はサーバシステム１４０が車両１３０に関連付けた特定の状態（例えば、車両１３０が駐車違反を犯したかどうか）に関するフィードバックをエンドユーザに提供することが重要である。エンドユーザは、この提供されたフィードバックに応じて対応することができる。エンドユーザ又は登録所有者は、高度に自動化された支払及び取締システムの範囲内で活動している間は、軽微な過失又は管理上の過失に関してペナルティを受けることはないと予測するのが当然である。計器盤の表示アイコンなどの単純なインターフェイスを介して提供されるフィードバックは、この問題を大きく軽減することができる。

例えば、車両１３０が駐車した時に、しばらく経っても表示アイコンが赤色のままである場合、エンドユーザは、例外事象が起きたと自覚する。ファイル上のクレジットカード番号の期限が切れており、従ってサーバシステム１４０が駐車料金を適用できないのかもしれない。このフィードバックは、エンドユーザに、例えばサーバシステム１４０によって又はサーバシステム１４０に関連して提供されるウェブサイトを訪問し、自身のアカウント状況に問い合わせて過失を是正する機会を提供する。

組み込みセルラーデータ又はＷｉＦｉ車両接続、又はスマートセンサ（後述）を含め、計器盤の表示アイコンが情報を取得できるいくつかの潜在的な情報源が存在する。表示アイコンが出荷時に取り付けられていない古い車両では、Ｂｌｕｅｔｏｏｔｈ（登録商標）、セルラーデータ又はＷｉ−Ｆｉ接続を通じて情報を受け取る視覚モジュールの形の改造キットをエンドユーザに提供することができる。

ある実施形態では、この表示アイコン機能が、車両の配線用ハーネスを介して第三機関の車載サブシステムからＧＰＳ位置データを受け取る。このＧＰＳデータは、表示アイコン機能が、現在車両１３０が支払済み駐車ゾーン内に存在するかどうかを判断できるようにする。

車両の計器盤アイコンと同様に、工場で製造されたばかりの新車にスマートセンサを設計することもできる。ＺｉｇＢｅｅＩＥＥＥ８０２．１５．４規格に類似する技術を用いて、車両同士の間、及び車両と駐車施設との間に低コスト、低電力の短距離無線メッシュネットワークを形成することができる。各車両がノードになり、メッシュネットワークを形成することによって中間ノードを介してデータを中継することにより、あるノードが離れたエンドポイントと通信することができる。各スマートセンサが一意の識別子を含むことにより、もはやナンバープレート情報は重要でなくなる。ある実施形態では、スマートセンサを、セルラーデータ接続を介してサーバシステム１４０と通信し、及び／又はペイ・バイ・フォン機能を提供するように構成することができ、これによって目的地の使用に対する支払いがスマートセンサを介して行われるようになる。

このようなスマートセンサの導入によって多くの応用が可能になる。例えば、スマートセンサは、ＧＰＳ受信機を含むことにより、又は車載ＧＰＳと通信することにより、車両１３０の現在位置を特定して、この現在位置をサーバシステム１４０にレポートすることができる。アシスト型ＧＰＳなどのいくつかのＧＰＳ技術では、ＧＰＳを介して特定される位置が、車両が特定の目的地を使用していると判断するのに十分な精度及び正確さを有することができる。これらのセンサは、駐車メータと通信して、基本的に車両の存在及び駐車時間をレポートすることもできる。この駐車情報は、離れた装置／ネットワークにメッシュネットワークを介して中継することができ、従って駐車施設を車両の近くに配置する必要がない。スマートセンサを備えた車両では、既にこの組み込みスマートセンサが車両の一意の識別情報をサーバシステム１４０に提供しているので、識別カメラ及び目的地カメラを使用する必要がない。

ある実施形態では、車両が、ＲＦＩＤチップなどの近距離通信（ＮＦＣ）装置を備えることができる。例えば、このような通信装置をミラーハンガーに含めることができる。別の例では、ペイ・アンド・ディスプレイ装置によって提供されるチケットにＲＦＩＤチップを埋め込むことができる。近距離通信装置から車両識別符号を取得することにより、識別カメラによって取り込まれたナンバープレート情報を含む画像などの画像の使用をサーバシステム１４０が必要としなくなり、及び／又はこれらの画像を用いて、観察車両に対応するＮＦＣ装置から受け取った情報を検証することができる。

ある実施形態では、スマートセンサが、近くの他の車両の（以下に限定されるわけではないが、動いているか、それとも駐車中であるか、及び駐車時間などの）状態を感知して、この状態をサーバシステム１４０にレポートすることができる。最終的に、サーバシステム１４０は、ほとんど全てのスマートセンサ搭載車両がどこに駐車されているか、及びどれほどの時間駐車されているかを認識するようになる。この情報を第三機関のシステム又はターンキープラットフォームからの駐車料金支払情報と組み合わせることにより、駐車料金が未納の車両又は駐車期限が過ぎている車両の識別情報を特定し、登録所有者に駐車違反チケットを郵送し、或いは（例えば、ファイル上のクレジットカードに課金することによって）現場で駐車違反の罰金を課すことができる。

ある実施形態では、目的地カメラに、レーザー式状態通知を設けることができる。このレーザー式状態通知機能は、ショッピングモール及び小売店で見られるレーザー式ロゴ装置と同様に、駐車車両を包み込む無害な点滅する赤色光を当てて、駐車料金が未納である旨又は期限が過ぎている旨をエンドユーザに通知する。この実施形態は、従来の手動駐車取締モデル下において車両に戻ってフロントガラスのワイパーの下に挟まれた駐車チケットを見ることに類似する。通常、目的地カメラは車両に対して高い位置に配置されるので、含まれているレーザー式状態通知モジュールは、下にある目的地に対して鳥瞰的な視界を有し、車両及び目的地に容易にレーザー通知を当てる。

ある実施形態では、レーザー式状態通知機能が、紙の駐車違反チケットを郵送する必要性に取って代わる。エンドユーザは、駐車違反のレーザー通知を受け取ると、以下に限定されるわけではないが、オンラインウェブサイト又はペイ・バイ・フォンを含むいくつかの媒体を通じて駐車違反の罰金を支払うと予想される。さらに、目的地カメラによってレーザー式状態通知を取り込んで、後で駐車違反及び通知の証拠を提供することもできる。

ある実施形態では、オンライン／電話／スマートフォン駐車スペース予約システムによって可能になる機能に、動的リアルタイム個人駐車スペース予約があり、この機能は、レーザー式状態通知機能を用いてさらに強化することができる。現在では、駐車スペース予約機能を提供する業者も存在するが、１つの特定の駐車スペースを自動化された形で物理的に予約する実用的な方法が存在しないので、この機能は、駐車スペースの近傍（例えば、駐車区画のいずれかの場所）のスペースの予約に制限される。また、スペースを予約したドライバーが駐車をして車を出した後に、予約した駐車スポットがいつ再び利用可能になるかを知る実用的な方法が存在しないので、通常、予約されたスペースは長時間にわたって空いたままになる。

対照的に、動的リアルタイム個人駐車スペース予約機能では、エンドユーザが、望む駐車スペース（例えば、クリスマスの買い物期間中にショッピングモールに最も近いスペース）を指定期間にわたって正確に指定することができる（例えば、将来的な日にちにわたって目的地の使用を予約することができる）。駐車スペースが予約されると、駐車スポットにレーザー通知を当てて、（例えば、他のドライバーへの警告として赤色で）その目的地が予約されていることを示すことができる。予約期間中にその目的地を別の車両が使用すると駐車違反になる。これにより、駐車場オペレータは、段階的な／割増料金の駐車スポット、及び駐車スペースの先行予約を提示することによって収益を増やすことができる。

ある実施形態では、駐車場オペレータが、特定の目的地を、予約を行った車両による使用のみに制限されるものとして指定することができる。この実施形態では、サーバシステム１４０が、所与の時点で利用可能な予約済み目的地の数を特定し、どれほどの未予約の目的地が利用可能な状態で残っているかに従って価格予約を決定することができる。ある実施形態では、サーバシステム１４０を、予約済みの目的地の使用に対して購入者が競合入札を提出できるように構成することができる。

ある実施形態では、ターンキープラットフォーム上に直接、又は第三機関の業者との協力によってペイ・バイ・フォン機能を提供することができる。最終的に、エンドユーザは、特定のＩＶＲ電話回線に電話し、目的地番号又は車両ナンバープレート番号及び駐車時間を入力することによって駐車料金を支払えるようになる。別の実施形態では、一般にウェブ対応スマートフォンを介してアクセスできるウェブサイトを通じてオンライン駐車料金支払いをサポートするための同じテーマに沿った変形形態がペイ・オンラインである。

ある実施形態では、エンドユーザが車両１３０を駐車するとすぐに、車両１３０が目的地を離れるまでの特定の駐車料金を請求するための肯定的な応答を促すテキストメッセージ又はその他の通知を受け取るような「プッシュ」技術の特徴を組み込むことができる。サーバシステム１４０は、識別カメラを介して車両１３０を識別し、この車両１３０が、クレジットカード又はその他の課金情報、及び携帯電話番号又はその他の連絡先が記録されている事前登録されたエンドユーザに関連することをさらに特定する。サーバシステム１４０は、目的地カメラを介して車両１３０が目的地に駐車したことを特定すると「プッシュ」シーケンスを開始して、支払い又は支払いの確認に関してドライバーに積極的に通知して関与する。支払処理を単純化することにより、駐車場収入の改善が実現される。

多くの従来の駐車メータシステムでは、エンドユーザが実際に使用したよりも長い時間に対する支払いを行った場合、超過時間がメータ上に残り、これを次のエンドユーザが使用することができる。開示する主題の実施形態では、サーバシステム１４０が、目的地カメラ１２５によって車両がいつ目的地を離れたかを正確に特定できるので、「持ち越された」支払済みの駐車時間を全てゼロにリセットすることができる。ただし、従来の道路脇メータは、一般に期限切れ前に期限切れフラグを作動させるための通信能力又はその他の知能を有していないので、これが１つの例外である。

サーバシステム１４０は、ユーザが駐車料金を支払いに来た時のユーザ経験を向上させるプッシュ技術ソフトウェアコンポーネントを提供するように構成することができる。プッシュ技術は、（１）テキストメッセージを介して支払シーケンスを開始すること、（２）事前登録されたユーザが自身のナンバープレートの写真を撮影し、例えば電子メール又はテキストメッセージを通じてサーバ１４０に写真を提供できるようにすること、（３）未登録ユーザが自身のナンバープレートの写真を撮影し、電子メール又はテキストメッセージを通じてこの写真をサーバシステム１４０に提供できるようにすること、及び（４）加入に基づくモデル下においてドライバーが一旦登録したら駐車料金を課されないようにすること、などの機能をサポートする。プッシュ技術のコンポーネントは、車両識別子検出ロジック、車両検出ロジック、データベース１４１及び支払ゲートウェイとやりとりする。項目（１）に関連して、プッシュ技術のコンポーネントは、駐車スペースなどの目的地の使用を開始したばかりの車両の車両識別子に基づいて、サーバシステム１４０に登録されている携帯電話番号に目的地の使用を開始したことを示すテキストメッセージをプッシュする。ドライバーが、「はい」で応答することによってテキストメッセージを承認すると、以下に限定されるわけではないが、目的地の使用に関する定額駐車料金などの適当な使用料を、登録口座に関連するクレジットカードに課金することができる。項目（２）に関連して、サーバシステム１４０に事前登録しているドライバーは、自身のナンバープレートの写真を撮影し、電子メール又はテキストメッセージを介してこの写真をサーバシステム１４０に送ることができる。この事前登録されているユーザの登録口座に関連するクレジットカードに使用料が課金される。項目（３）に関連して、サーバシステム１４０に登録されていないナンバープレートを有する車両の場合、ドライバーがナンバープレートの写真を撮影し、電子メール／テキストメッセージを介してこの写真をサーバシステム１４０に送ることができる。携帯電話サービスプロバイダがこのような課金機能へのアクセスをサポートしていてアクセスできる場合には、ユーザの毎月のモバイル装置の請求書に使用料を追加することができる。項目（４）に関連して、ドライバーが一旦署名すると、全ての使用料（又は少なくとも全ての駐車料）を登録クレジットカードで自動的に支払うことができる。このプッシュ技術のソフトウェアコンポーネントは、「駐車禁止」区域に車両を駐車することなどの不適切な目的地の使用をサーバシステム１４０が特定した場合、ユーザに自動的にテキストメッセージを送信するように構成することもできる。

サーバシステム１４０は、新たに違反として識別される目的地の使用の全ての発生状況を調べ、この発生状況を、後述するナンバープレート検索モジュール又はナンバープレート転送モジュールなどのシステム構成において指定される対応する目的地に割り当てる駐車違反前処理ロジックソフトウェアコンポーネントを提供するように構成することができる。駐車違反前処理ロジックソフトウェアコンポーネントは、データベース１４１、システム設定ユーティリティ、及び第三機関のＡＰＩとやりとりする。駐車違反前処理ロジックソフトウェアコンポーネントは、（１）サーバシステム１４０に含まれている他のソフトウェア処理によって識別された違反を待ち行列に加え、（２）待ち行列内の次の違反を調べ、（３）目的地及び車両による検出された目的地の使用に関連してシステム設定ユーティリティを通じて設定されている規則を検証することによって目的地の使用が違反であることを検証し、（４）この違反をナンバープレート処理ロジックに割り当て、（５）待ち行列に加えられた他のいずれかの違反を調べ、又はその後の違反の識別を待つように構成することができる。

サーバシステム１４０は、車両が期限切れタグを有しているかどうかを識別画像から特定するように構成することができる。この識別画像は、固定識別カメラ１２０を用いて取り込むことができるが、通常の距離及び車両速度、並びにナンバープレート上の通常の小型サイズの期限日インジケータでは、車両が期限切れタグを有しているかどうかを識別画像のみから判定することは一般に不可能である。静止車両のナンバープレートにズームインするＰＴＺ対応カメラを識別カメラ又は目的地カメラのいずれかと共に使用すれば、ナンバープレートにズームインして、車両が期限切れタグを有しているかどうかを判定するのに十分な細部を取得画像のみから取得することができる。ある実施形態では、例えばスマートフォン又はモバイル装置１５０に含まれているカメラを含むモバイルカメラ又はハンドヘルドカメラを代わりに用いて識別画像を取り込むことができる。多くの場合、このようなソースから取得された識別画像は、車両が期限切れタグを有しているかどうかを識別画像のみから判定するのに十分な細部を有する。ある実施形態では、サーバシステム１４０を、画像のみを使用してタグが期限切れであるかどうかを判定するのではなく、ＡＰＩを介して自治体のデータベースに問い合わせ、特定のナンバープレート番号の車両登録が期限切れであるかどうかを判定するように構成することができる。サーバシステム１４０は、車両が期限切れタグを有していると判定した場合、この車両を自治体に報告するように構成することができる。

サーバシステム１４０は、駐車違反前処理ロジックコンポーネントによって割り当てられた違反などの、識別された目的地使用違反を取り上げ、これを登録所有者（ＲＯ）／目的地使用違反に関与した車両のユーザのいずれか、又は目的地の責任を負う駐車場オペレータに対する対応項目に変換するナンバープレート処理ロジックソフトウェアコンポーネントを提供するように構成することもできる。例えば、この対応項目は、駐車違反切符を登録所有者に自動的に郵送すること、又はナンバープレート番号を駐車場管理局の画面上に表示することなどの形をとることができる。ナンバープレート処理ロジックソフトウェアコンポーネントは、駐車違反前処理ロジックソフトウェアコンポーネント、システム設定ユーティリティ、及びデータベース１４１とやりとりする。ナンバープレート処理ロジックコンポーネントは、目的地に関連してシステム設定ユーティリティを介して指定されている１又はそれ以上の業務規則をチェックして、適切な対応項目を決定するように構成することができる。例えば、業務規則がナンバープレート検索を指定している場合、自治体又は民間企業によって提供されるＡＰＩなどを介して特定のタイプのナンバープレート検索を指定することもできる。この時、ナンバープレート検索は指定通りに行われる。また、業務規則は、ＡＰＩを介して登録所有者に駐車チケットを郵送すること、又は登録所有者の郵送先住所、及び違反に関する他のいずれかの関連情報のみを駐車場オペレータに提供することなどの下位選択肢を識別することもできる。別の例では、業務規則がナンバープレート情報の転送を指定している場合、ナンバープレート処理ロジックコンポーネントは、指定されている特定のタイプのナンバープレート情報転送を確認し、これに従ってナンバープレート情報を転送する。

ナンバープレート車両識別子から登録所有者の郵送先住所を識別する目的でナンバープレート検索ＡＰＩの選択肢を利用するには、民間企業が提供するものなどのナンバープレートデータベースが存在し、ナンバープレートの特定の州／県に属するナンバープレートの検索に利用可能でなければならない。また、このようなデータベースの使用は、このような商業的に実現可能な検索に関連するあらゆる料金の面でも妥当でなければならない。上記のいずれかの条件が実現されない場合、別の選択肢として、通常は地方の警察署などを介してナンバープレート記録にアクセスできる自治体組織に問題のナンバープレートを提供することを挙げることができる。

ナンバープレート処理ロジックソフトウェアコンポーネントは、ナンバープレート検索追跡サブモジュールを含むことができる。ナンバープレート検索追跡サブモジュールは、車両の登録所有者の郵送先住所を検索するためにナンバープレートデータベースに対してＡＰＩ呼出しを行うように構成することができる。このようなデータベースの例としては、ニューヨーク州車両関連部局によって提供されるＨＴＴＰベースのダイヤルイン検索アカウントＡＰＩ、米国自動車管理者協会（ＡＡＭＶＡ）又はその他の保険会社によって提供されるデータベースサービス、及びＰｕｂｌｉｃＤａｔａ．ｃｏｍなどの公共記録のオンライン収集物が挙げられる（多くのこのような収集物は政府又は企業によって管理されているデータベースよりも信頼性が低いので、情報が有効かつ正確であることを確実にするためのさらなる努力が必要になる場合もある）。

また、ナンバープレート検索追跡サブモジュールは、目的地を悪用した車両に関連する登録所有者に自動的に駐車違反切符を郵送するように構成することもできる。例えば、この郵送処理は、限定するわけではないが、Ｌ−Ｍａｉｌ．ｃｏｍなどの印刷／郵送サービスへのＡＰＩ呼出しを通じて自動化することができる。

ある実施形態では、ナンバープレート検索追跡サブモジュールを、所与の（ナンバープレートなどの）車両識別子が（例えば、システム設定ユーティリティを介して設定できる）指定期間内における目的地の以前の悪用に関連しているかどうかを確認するために、データベース１４１内の記録を作成し、維持し、再検討するように構成することができる。関連している場合、ナンバープレート検索追跡サブモジュールは、ＡＰＩ呼出しに関連する業務コストを削減するために、以前に取得されたアドレスが有効かつ正確であると想定し、ＡＰＩ呼出しをスキップして、システム内の以前に取得された郵送先住所を用いて違反切符を郵送することができる。指定日数後（例えば、やはりシステム設定ユーティリティを介して設定可能な実際の期間）に駐車違反切符の支払いが行われていなかったり、或いは違反切符が配送不可能として戻ってきたりした場合には、次のＡＰＩ呼出しを行って現在のアドレスを取得することができる。

ある実施形態では、以下に限定されるわけではないが、支払済み駐車の期限が過ぎている場合、又は車両が未納状態で駐車されている場合などの駐車違反について、サーバシステム１４０を、１又はそれ以上の取締官に緯度及び経度、又はおおよその所在地住所などの目的地の場所を通知するように構成することができる。この結果、取締官が違反車両に足を運び、現場で違反切符を発行することができる。ある実施形態では、サーバシステム１４０を、特定の違反車両に対処するのに最も適した個々の取締官を識別し、及び／又は配置するように構成することができる。この識別を行うための要素としては、例えば、違反車両からの取締官の距離又は作業負荷、或いは（例えば、違反車両を速やかに排除しなければならない場合には）違反車両を牽引すべきかどうかを挙げることができる。ある実施形態では、例えば取締官が少なすぎる場合、又は特定の取締官が複数の違反車両に対処している場合には、違反車両を待ち行列に入れる必要が生じることがある。ある実施形態では、複数の取締官に近くの違反車両を通知し、個々の取締官が特定の違反車両の処理を承諾することができる。サーバシステム１４０は、取締官の成績を追跡し、これを取締官の報酬又は割当制度に関連して使用できるように構成することもできる。ある実施形態では、取締官にモバイル装置１５０を持たせ、このモバイル装置１５０を、違反車両に対する違反切符を予め印刷しておいて、車両に違反切符を送付するのに掛かる時間を削減するように構成することができる。

サーバシステム１４０は、動的可変料率の駐車料金を提供するように構成することができる。ある実施形態では、サーバシステム１４０が、例えば１日の時間帯及び／又は週の曜日によって変動する、目的地のための異なる駐車料率を記録することができる。第１及び第２の料率が適用される期間にわたって車両が目的地を使用する場合には、サーバシステム１４０を、目的地の使用開始から第２の料率が適用されるまで適用される第１の料率と、車両が目的地を使用する残りの時間に適用される第２の料率とに基づいて目的地の合計使用料を決定するように構成することができる。ある実施形態では、サーバシステム１４０を、所与の範囲内の利用可能な目的地が収容できる車両の数を特定し、この特定された車両数に駐車料金又は駐車料率を基づかせるように構成することができる。例えば、サーバシステム１４０は、（例えば、残りの目的地が少ないという理由で）この数字が減少すると判断した場合、この少ない残り場所を使用し始める車両に高い料率を適用することができる。

サーバシステム１４０は、駐車場提供者がＡＰＩ又は設定ユーティリティを介して指定の目的地に指定駐車料率又は均一料金を適用すべき特定の事象を指定できるように構成することができる。例えば、ある駐車施設に関連する会場又はその近くの会場で午後７時〜１１時にコンサートが行われる場合、この駐車施設は、この同じ日の夕方午後４時以降に駐車された車両に一率１０ドルの料金を課すことができる。

サーバシステム１４０は、ドライバーが望む限りの長時間にわたって目的地に車両を駐車できる場合には罰金なし機能を提供し、（以下に限定されるわけではないが、時間当たり料金又は一率の終日料金などの）目的地に設定された規則に従ってクレジットカード又はその他の口座に課金できるように構成することができる。ある実施形態では、目的地に罰金なし機能を利用可能である旨を示すテキストメッセージ又は電子メールをドライバーにプッシュ又はその他の方法で送信し、ドライバーが、「はい」又は「罰金なし」などのメッセージで応答することなどによって罰金なし機能の使用を選択できるようにすることができる。ある実施形態では、サーバシステム１４０を、指定範囲内の又はサーバシステム１４０によって追跡される目的地全体にわたる全ての制約のない目的地に対して全体的に罰金なし機能を利用可能にするように構成することができる。一方で、サーバシステム１４０を、例えば午後３時〜６時のラッシュ時「駐車禁止」制約がある目的地などの制約された目的地に対しては罰金なし機能を提供しないように構成することもできる。

ある実施形態では、サーバシステム１４０が、車両の３Ｄ輪郭に基づいてプロファイリングを行うことができる。例えば、このようなプロファイリングは、以下に限定されるわけではないが、スポーツタイプ車両（ＳＵＶ）、バン、セダン、クーペ又はオートバイなどのカテゴリに属するものとして車両を大まかにプロファイリングすることができる。また、車両を、明るい又は暗い色として分類することもできる。この車両プロファイリングは、以下に限定されるわけではないが、特定の近隣内における警察による盗難車両の追跡、誘拐事件速報システム、国土安全保障の必要性の支援などの非駐車用途に役立つこともできる。ある実施形態では、車両プロファイリングを用いてさらなる車両の特徴を提供し、車両を追跡する際に１つの追跡カメラと別の追跡カメラの間で比較を行うことができる。ある実施形態では、車両プロファイルが、自動駐車違反切符郵送処理のために車両の識別情報を確認する追加層を提供することができる。ある実施形態では、サーバシステム１４０に手動３Ｄ車両プロファイルが提供される。例えば、シボレーインパラの１つの手動３Ｄ車両プロファイルは、ボンネットの高さと乗員室の高さとトランクの高さの比率が１：２：１であることを示すことができる。

ある実施形態では、作動ビーム屈折ミラーに統合できるレーザー送信機を、１又はそれ以上の目的地にレーザービームを当てるように構成することができる。ある実施形態では、目的地又はその周囲に取り付けられた逆反射体にレーザービームを当てて、レーザー送信機に関連する受信機に帰還信号を提供することができる。レーザービームによって照射された目的地を車両が使用すると、レーザービーム又は帰還信号が遮断されることによって車両の存在が検出される。この検出に応答して、サーバシステム１４０を、付近のカメラによって目的地画像及び／又は識別子画像を取得するように構成することができる。

ある実施形態では、サーバシステム１４０を、上述した車両識別符号に関連する使用に加え、信号機制御されている交差点内を車両が不正通過した事象を検出するように、識別カメラを「赤信号カメラ」としても使用するように構成することができる。例えば、信号機が黄色から赤に変わった時に黄信号の終盤又は赤信号を不正通過した車両と、取り込まれた車両ナンバープレートとを識別することができ、従ってサーバシステム１４０は、撮像カメラを両方の目的で同時に利用するように構成される。この代わりに、又はこれに加えて、サーバシステム１４０は、車両の進行方向が赤信号である間に車両が交差点内に残って交通渋滞状態を引き起こすことがある「交差点通行妨害」違反を、識別カメラを用いて検出するように構成することもできる。

ある実施形態では、サーバシステム１４０を、以下に限定されるわけではないが、（ローンの支払いが滞っている車両を特定するための）回収会社、法的処置、国土安全保障などの第三機関のためのリアルタイム車両追跡サービスを提供するように構成することができる。サーバシステム１４０は、このような第三機関団体が、例えばナンバープレートなどの車両識別子によって関心車両を登録できるようにするＡＰＩを提供することができる。サーバシステム１４０が車両識別子によって車両の存在を特定した場合には、登録団体に通知することができる。通知は、車両を最初に検出したことに関連して、及び／又は車両が停止していると判断される時に提供することができる。ある実施形態では、サーバシステム１４０が登録車両の移動記録を保存し、例えば、最新情報をリアルタイムで提示するように構成できる地図ベースのウェブインターフェイスを介してこの移動記録にアクセスすることができる。第三機関は、このＡＰＩによって関心範囲を指定することができ、サーバシステム１４０は、関心範囲に入ったと判定されたあらゆる車両の識別及び追跡を行うように構成される。サーバシステム１４０は、追跡カメラによって取得された登録車両の画像を提供するように構成することもできる。ある実施形態では、過去の目的地の利用などのあらゆる保存された追跡情報を利用可能にして、ある人物の行方を（この人物が車両に関連すると想定して）経時的に再現することができる。ある実施形態では、サーバシステム１４０を、ドライバーの顔の画像を含む車両画像を取得するように構成するとともに、顔認識技術を実行して、ドライバーの顔の特徴が関心人物に一致することを確認するようにさらに構成することができる。

ある実施形態では、サーバシステム１４０を、所与の道路部分を横切ったと判断される車両の数などの交通量情報を特定して提供するように構成することができる。このような情報は、以下に限定されるわけではないが、現在観察されている交通量に応じて信号機などの交通システムを動的に制御すること、及びある期間に観察された交通量に基づいて建設要件を決定することを含む目的で使用することができる。この交通量情報は、時間及び／又は日付、及び／又は以下に限定されるわけではないが、移動方向及び車両のサイズ又は（ＳＵＶ、トラック、自動車又はオートバイなどの）車種を含む、特定された車両の特徴を含むことができ、及び／又はこれらに基づいてフィルタ処理することができる。また、サーバシステム１４０は、例えば、各車両が交差点から出る方向に基づいて、どれほどの車両が車道の東向き部分から出た時に北又は南に向かうかなどの、道路の一部の進入及び／又は退出方向に関連する車の量を特定することもできる。ある実施形態では、サーバシステム１４０を、大型トラックによる指定道路へのアクセスを制御する際に、及び／又は大型トラックによる指定道路の使用料を決定することなどの、車種毎に車両に通行料を課す際に使用されるように構成することができる。

図５は、本発明の態様を実装できるコンピュータシステム５００を示すブロック図である。コンピュータシステム５００は、情報を伝送するためのバス５０２又はその他の通信機構、及びバス５０２に結合された、情報を処理するためのプロセッサ５０４を含む。コンピュータシステム５００は、バス５０２に結合された、情報及びプロセッサ５０４が実行すべき命令を記憶するための、ランダムアクセスメモリ（ＲＡＭ）又はその他の動的記憶装置などのメインメモリ５０６も含む。メインメモリ５０６は、プロセッサ５０４が実行すべき命令の実行中に一時変数又はその他の中間情報を記憶するために使用することもできる。コンピュータシステム５００は、バス５０２に結合された、プロセッサ５０４の静的情報及び命令を記憶するためのリードオンリメモリ（ＲＯＭ）５０８又はその他の静的記憶装置をさらに含む。情報及び命令を記憶するための、磁気ディスク又は光学ディスクなどの記憶装置５１０も設けられてバス５０２に結合される。

コンピュータシステム５００は、コンピュータユーザに情報を表示するための、ブラウン管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）などのディスプレイ５１２にバス５０２を介して結合することができる。バス５０２には、英数字及びその他のキーを含む、プロセッサ５０４に情報及びコマンド選択を通信するための入力装置５１４も結合される。別のタイプのユーザ入力装置は、プロセッサ５０４に方向情報及びコマンド選択を通信してディスプレイ５１２上のカーソルの動きを制御するための、マウス、トラックボール又はカーソル方向キーなどのカーソル制御５１６である。通常、この入力装置は、（ｘなどの）第１の軸及び（ｙなどの）第２の軸という２つの軸における２つの自由度を有し、装置が平面内の位置を指定できるようにする。別のタイプのユーザ入力装置は、一般にディスプレイ５１２と、ディスプレイ５１２上のタッチを登録するハードウェアとを組み合わせたタッチ画面である。

本発明は、本明細書で説明した技術を実装するように集合的に構成及び／又はプログラムされた、コンピュータシステム５００などの１又はそれ以上のコンピュータシステムの使用に関連する。本発明の１つの実施形態によれば、これらの技術は、メインメモリ５０６に含まれる１又はそれ以上の命令の１又はそれ以上のシーケンスをプロセッサ５０４が実行したことに応答してコンピュータシステム５００によって実行される。このような命令は、記憶装置５１０などの別の機械可読媒体からメインメモリ５０６に読み込むことができる。メインメモリ５０６に含まれる命令シーケンスが実行されると、本明細書で説明した処理ステップをプロセッサ５０４が実行するようになる。別の実施形態では、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合わせて配線回路を用いて本発明を実施することができる。従って、本発明の実施形態は、ハードウェア回路とソフトウェアのいずれかの特定の組み合わせに限定されるものではない。

本明細書で使用している「機械可読媒体」という用語は、機械を特定の形で動作させるデータを提供することに関与するあらゆる媒体を意味する。コンピュータシステム５００を用いて実装される実施形態では、例えばプロセッサ５０４に実行命令を与えることに様々な機械可読媒体が関与する。このような媒体は、以下に限定されるわけではないが、不揮発性媒体、揮発性媒体及び送信媒体を含む多くの形をとることができる。不揮発性媒体は、例えば、記憶装置５１０などの光学又は磁気ディスクを含む。揮発性媒体は、メインメモリ５０６などの動的メモリを含む。送信媒体は、バス５０２を含む電線を含む、同軸ケーブル、銅線及び光ファイバを含む。送信媒体は、無線及び赤外線データ通信中に生成されるもののような音波又は光波の形をとることもできる。全てのこのような媒体は、媒体が運ぶ命令を、機械に命令を読み込む物理的機構が検出できるように、有形及び／又は非一時的なものでなければならない。

一般的な形の機械可読媒体としては、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は他のいずれかの磁気媒体、ＣＤ−ＲＯＭ、他のいずれかの光学媒体、パンチカード、紙テープ、穴のパターンを有する他のいずれかの物理的媒体、ＲＡＭ、ＰＲＯＭ及びＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のいずれかのメモリチップ又はカートリッジ、後述するような搬送波、又はコンピュータが読み取ることができる他のいずれかの媒体が挙げられる。

１又はそれ以上の実行命令の１又はそれ以上のシーケンスをプロセッサ５０４に運ぶ際には、様々な形の機械可読媒体が関与することができる。例えば、これらの命令は、最初に遠隔コンピュータの磁気ディスクで運ぶことができる。遠隔コンピュータは、この命令を動的メモリにロードし、モデムを用いて電話回線を通じて送信することができる。コンピュータシステム５００のローカルモデムは、電話回線上でデータを受け取り、赤外線送信機を用いてこのデータを赤外線信号に変換することができる。この赤外線信号で運ばれるデータを赤外線検出器が受け取ることができ、このデータを適当な回路がバス５０２上に配置することができる。バス５０２は、このデータをメインメモリ５０６に運び、ここからプロセッサ５０４が命令を取り出して実行する。任意に、メインメモリ５０６によって受け取られた命令を、プロセッサ５０４による実行前又は実行後に記憶装置５１０に記憶することもできる。

コンピュータシステム５００は、バス５０２に結合された通信インターフェイス５１８も含む。通信インターフェイス５１８は、ローカルネットワーク５２２に接続されたネットワークリンク５２０に結合する双方向データ通信を提供する。例えば、通信インターフェイス５１８は、対応する種類の電話回線へのデータ通信接続を提供するための総合デジタル通信網（ＩＳＤＮ）カード又はモデムとすることができる。別の例として、通信インターフェイス５１８を、互換性のあるＬＡＮへのデータ通信接続を提供するためのローカルエリアネットワーク（ＬＡＮ）カードとすることもできる。無線リンクを実装することもできる。あらゆるこのような実装では、通信インターフェイス５１８が、様々なタイプの情報を表すデジタルデータストリームを運ぶ電気信号、電磁信号又は光信号の送信及び受信を行う。

通常、ネットワークリンク５２０は、１又はそれ以上のネットワークを介して他のデータ装置へのデータ通信を提供する。例えば、ネットワークリンク５２０は、ローカルネットワーク５２２を介して、ホストコンピュータ５２４への、又はインターネットサービスプロバイダ（ＩＳＰ）５２６が運用するデータ装置への接続を提供することができる。さらに、ＩＳＰ５２６は、今では一般に「インターネット」５２８と呼ばれるワールドワイドパケットデータ通信ネットワークを介してデータ通信サービスを提供する。ローカルネットワーク５２２及びインターネット５２８は、いずれもデジタルデータストリームを運ぶ電気信号、電磁信号又は光信号を使用する。コンピュータシステム５００との間でデジタルデータを運ぶ、様々なネットワークを介した信号、及びネットワークリンク５２０上の通信インターフェイス２１８を介した信号は、情報を伝送する例示的な形の搬送波である。

コンピュータシステム５００は、（単複の）ネットワーク、ネットワークリンク５２０及び通信インターフェイス５１８を介してメッセージを送信し、プログラムコードを含むデータを受け取ることができる。インターネットの例では、サーバ５３０が、インターネット５２８、ＩＳＰ５２６、ローカルネットワーク５２２及び通信インターフェイス５１８を介して、アプリケーションプログラムのための要求コードを送信することができる。

受け取られたコードは、受信時にプロセッサ２０４が実行することも、及び／又は後で実行できるように記憶装置５１０又はその他の不揮発性記憶装置に記憶することもできる。コンピュータシステム５００は、このようにして搬送波の形のアプリケーションコードを取得することができる。

上述の明細書では、実装毎に変動し得る数多くの特定の詳細を参照しながら本発明の実施形態を説明した。従って、本発明が何であるか、及び本出願人が発明として意図するものが何であるかについての唯一排他的な指標は、本出願から生じる一連の請求項であり、これらの請求項は、このような請求項が生じる特定の形をとり、後続のあらゆる補正を含む。本明細書に明示的に記載した、このような請求項に含まれる用語のためのあらゆる定義は、請求項において使用するこのような用語の意味を規定するものである。従って、このような請求項の範囲は、請求項に明示的に記載していない限定事項、要素、特性、特徴、利点又は属性によって決して限定すべきではない。従って、本明細書及び図面は、限定的な意味ではなく例示的な意味で捉えるべきである。

１１０ ネットワーク
１２０ 識別カメラ
１２１ 画像
１２５ 目的地カメラ
１２６ 画像
１２７ 通信リンク
１２８ 通信リンク
１２９ 通信リンク
１３０ 車両
１４０ サーバシステム
１４１ データベース
１４２ ランダムアクセスメモリ
１４３ プロセッサ
１５０ モバイル装置
１５１ 画像
１６０ オンサイト支払システム
１７０ エンドユーザシステム
１８０ 手動再確認システム
１８１ 人間オペレータ
１９０ 駐車場運営システム

Claims (15)

1. 単一の複数車両用目的地の使用、及び該単一の複数車両用目的地内の少なくとも１つの制約された場所を追跡する方法であって、
   複数のカメラによって取り込まれた複数の車両画像を受け取るステップを含み、
   前記複数のカメラは、第１の視野を有する第１の識別カメラを含み、
   前記複数のカメラは、第２の視野を有する第１の目的地カメラを含み、前記第２の視野は、前記第１の視野とは異なるとともに、前記第１の視野に部分的に重なり、
   前記複数のカメラは、第３の視野を有する第２の目的地カメラを含み、該第２の目的地カメラは、前記第１の目的地カメラとは異なり、前記第３の視野は、前記第１及び第２の視野とは異なり、前記第３の視野は、複数の直接隣接し合う目的地及びこれら直接隣接し合う目的地内の少なくとも１つの制約された場所を有する前記単一の複数車両用目的地を含み、
   前記複数の車両画像は、
   前記第１の識別カメラによって第１の時刻に取り込まれた、第１の位置における第１の車両を示す第１の識別画像と、
   前記第１の目的地カメラによって前記第１の時刻よりも後の第２の時刻に取り込まれた、前記第１の位置とは異なる第２の位置における前記第１の車両を示す第１の目的地画像と、
   前記第２の目的地カメラによって前記第２の時刻よりも後の第３の時刻に取り込まれた、前記単一の複数車両用目的地の外側の第３の位置における前記第１の車両を示す第２の目的地画像と、
   前記第２の目的地カメラによって前記第３の時刻よりも後の第４の時刻に取り込まれた、前記単一の複数車両用目的地内の第４の位置における前記第１の車両を示す第３の目的地画像と、
   前記第２の目的地カメラによって前記第４の時刻よりも後の第５の時刻に取り込まれた、前記単一の複数車両用目的地の外側の、前記第３の位置とは異なる第５の位置における前記第１の車両を示す第４の目的地画像と、
   前記第１の識別カメラによって第６の時刻に取り込まれた、第６の位置における第２の車両を示す第２の識別画像と、
   前記第２の目的地カメラによって前記第６の時刻よりも後の第７の時刻に取り込まれた、前記単一の複数車両用目的地内の前記少なくとも１つの制約された場所の外側の第７の位置における前記第２の車両を示す第５の目的地画像と、
   前記第２の目的地カメラによって前記第７の時刻よりも後の第８の時刻に取り込まれた、前記単一の複数車両用目的地内の前記少なくとも１つの制約された場所内の第８の位置における前記第２の車両を示す第６の目的地画像と、
   を含み、前記方法はさらに、
   前記第１の識別画像に基づいて、前記第１の車両の第１の一意の識別子及び第１の特徴を特定するステップと、
   前記第１の目的地画像に基づいて、前記第１の車両の第２の特徴を特定するステップと、
   前記第１の車両の前記第２の特徴と前記第１の車両の前記第１の特徴を比較するステップと、
   前記第１の車両の前記第２の特徴と前記第１の車両の前記第１の特徴との比較に基づいて、前記第１の車両が前記第２の視野内に存在すると判断するステップと、
   前記第２の目的地画像に基づいて、前記第１の車両の第３の特徴を特定するステップと、
   前記第１の車両の前記第３の特徴と前記第１の車両の前記第２の特徴を比較するステップと、
   前記第１の車両の前記第３の特徴と前記第１の車両の前記第２の特徴との比較に基づいて、前記第１の車両が前記第３の視野内に存在すると判断するステップと、
   前記第３の目的地画像に基づいて、前記第１の車両が前記単一の複数車両用目的地内に停止していると判断するステップと、
   前記第４の目的地画像に基づいて、前記第１の車両が前記単一の複数車両用目的地から離れたと判断するステップと、
   前記第１の車両が、前記第４の時刻に前記単一の複数車両用目的地の使用を開始したことを示すステップと、
   前記第１の車両が、前記第５の時刻に前記単一の複数車両用目的地の使用を完了したことを示すステップと、
   前記第１の車両の前記第１の一意の識別子を示すステップと、
   前記第２の識別画像に基づいて、前記第２の車両の第２の一意の識別子及び第１の特徴を特定するステップと、
   前記第５の目的地画像に基づいて、前記第２の車両の第２の特徴を特定するステップと、
   前記第２の車両の前記第２の特徴と前記第２の車両の前記第１の特徴を比較するステップと、
   前記第２の車両の前記第２の特徴と前記第２の車両の前記第１の特徴との比較に基づいて、前記第２の車両が前記第３の視野内に存在すると判断するステップと、
   前記第６の目的地画像に基づいて、前記第２の車両の第３の特徴を特定するステップと、
   前記第２の車両の前記第３の特徴と前記第２の車両の前記第２の特徴を比較するステップと、
   前記第２の車両の前記第３の特徴と前記第２の車両の前記第２の特徴との比較に基づいて、前記第２の車両が前記第３の視野内に存在すると判断するステップと、
   前記第６の目的地画像に基づいて、前記第２の車両が前記単一の複数車両用目的地内の前記少なくとも１つの制約された場所内に停止していると判断するステップと、
   前記第２の車両の前記第２の一意の識別子を示すステップと、
   前記第２の車両が前記単一の複数車両用目的地内の前記少なくとも１つの制約された場所に停止することによって駐車違反を犯していることを示すステップと、
   を含み、前記受け取るステップ、前記特定するステップ、前記判断するステップ、及び前記示すステップは、１又はそれ以上のプロセッサによって実行される、
   ことを特徴とする方法。
2. 前記第１の車両が前記第４の時刻から前記第５の時刻まで前記単一の複数車両用目的地を使用するためのコストを決定するステップと、
   前記第１の車両に関連する口座に前記コストを課金するステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
3. 前記第１の車両の前記第１の一意の識別子を特定するステップは、
   前記第１の識別画像に基づく前記第１の車両の前記第１の一意の識別子の特定を、自動化された機械に基づいて行う際にエラーを識別するステップと、
   前記第１の車両の前記第１の一意の識別子を特定するように人間オペレータに支援を求めるステップと、
   前記人間オペレータに前記第１の識別画像を提供するステップと、
   前記第１の車両の識別符号を受け取るステップと、
   前記受け取った識別符号に基づいて、前記第１の車両の第１の一意の識別子を特定するステップと、
   を含むことを特徴とする請求項１に記載の方法。
4. 前記第１の車両が前記単一の複数車両用目的地内に停止していると判断するステップは、前記第１の車両に対応する前記第３の目的地画像の一部が、前記単一の複数車両用目的地に対応する前記第３の目的地画像の一部内に存在することを特定するステップを含む、ことを特徴とする請求項１に記載の方法。
5. 前記第１の車両に関連する電子的連絡アドレスを取得するステップと、
   前記第４の時刻に開始された前記単一の複数車両用目的地の使用に対する料金を決定するステップと、
   前記第５の時刻よりも前に、前記決定された料金の支払確認を要求する通知を前記電子的連絡アドレスに送信するステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
6. 第三機関のペイ・バイ・フォン駐車料金支払システムが前記第１の車両による前記単一の複数車両用目的地の使用についての支払いを受け取った対象の期間を特定した、前記単一の複数車両用目的地に関する支払情報を、前記第三機関のペイ・バイ・フォン駐車料金支払システムから取得するステップと、
   前記第１の車両による前記第４の時刻から前記第５の時刻までの前記単一の複数車両用目的地の使用が、前記第三機関のペイ・バイ・フォン駐車料金支払システムから受け取られた期間以外であることを特定するステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
7. 第三機関のペイ・バイ・スペース駐車料金支払システムが前記単一の複数車両用目的地の使用についての支払いを受け取った対象の期間を特定した、前記単一の複数車両用目的地に関する支払情報を、前記第三機関のペイ・バイ・スペース駐車料金支払システムから取得するステップと、
   前記第１の車両による前記第４の時刻から前記第５の時刻までの前記単一の複数車両用目的地の使用が、前記第三機関のペイ・バイ・スペース駐車料金支払システムから受け取られた期間以外であることを特定するステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
8. 前記第３の目的地画像の一部は、前記第１の車両内又は該第１の車両上に位置する、第三機関のペイ・アンド・ディスプレイ駐車料金支払システムが支払いを受け取った対象の期間を示すディスプレイチケットの画像に対応し、前記方法は、
   前記ディスプレイチケットの画像に対応する前記第３の目的地画像の前記一部に基づいて、前記第三機関のペイ・アンド・ディスプレイ駐車料金支払システムが支払いを受け取った対象の期間を特定するステップと、
   前記第１の車両による前記第４の時刻から前記第５の時刻までの前記単一の複数車両用目的地の使用が、前記第三機関のペイ・アンド・ディスプレイ駐車料金支払システムが支払いを受け取った対象の期間以外であることを特定するステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
9. 第三機関の道路脇駐車メータ支払システムが前記単一の複数車両用目的地の使用についての支払いを受け取った対象の期間を特定した、前記単一の複数車両用目的地に関する支払情報を、前記第５の時刻後に、前記第三機関の道路脇駐車メータ支払システムから取得するステップと、
   前記第１の車両による前記第４の時刻から前記第５の時刻までの前記単一の複数車両用目的地の使用が、前記第三機関の道路脇駐車メータ支払システムから受け取った期間以外であることを特定するステップと、
   を含むことを特徴とする請求項１に記載の方法。
10. 前記第４の時刻後であって前記第５の時刻又はその前に取り込まれた、前記単一の複数車両用目的地の使用に関する期限切れフラグを表示している道路脇駐車メータの部分に対応する部分を含む前記道路脇駐車メータの駐車メータ画像を受け取るステップと、
    前記受け取った駐車メータ画像に基づいて、前記道路脇駐車メータが前記期限切れフラグを表示していたことを特定するステップと、
    前記道路脇駐車メータが前記期限切れフラグを表示していたことの特定に基づいて、前記第１の車両による前記第４の時刻から前記第５の時刻までの前記単一の複数車両用目的地の使用が駐車違反であると判断するステップと、
    をさらに含むことを特徴とする請求項１に記載の方法。
11. 前記第４の時刻又は前記第４の時刻後であって前記第５の時刻又は前記第５の時刻前の第８の時刻に取り込まれた、前記単一の複数車両用目的地の使用に関する期限切れフラグを表示していない道路脇駐車メータの部分に対応する、前記道路脇駐車メータの第１の駐車メータ画像を受け取るステップと、
    前記第８の時刻後であって前記第５の時刻又は該第５の時刻前の第９の時刻に取り込まれた、前記単一の複数車両用目的地の使用に関する期限切れフラグを表示している前記道路脇駐車メータの部分に対応する、前記道路脇駐車メータの第２の駐車メータ画像を受け取るステップと、
    前記第１の駐車メータ画像に基づいて、前記第８の時刻に前記道路脇駐車メータによって前記期限切れフラグが表示されていなかったと判定するステップと、
    前記第２の駐車メータ画像に基づいて、前記第９の時刻に前記道路脇駐車メータによって前記期限切れフラグが表示されていたと判定するステップと、
    前記第９の時刻に前記道路脇駐車メータによって前記期限切れフラグが表示されていたという判定に基づいて、前記第１の車両による前記第４の時刻から前記第５の時刻までの前記単一の複数車両用目的地の使用が駐車違反であると判断するステップと、
    前記第９の時刻に前記道路脇駐車メータによって前記期限切れフラグが表示されていたという判定に応答して、前記第１の車両の前記第１の一意の識別子、前記第４の時刻、前記第５の時刻、前記第８の時刻及び前記第９の時刻を含むデータを第三機関の駐車料金支払システムに提供するステップと、
    を含むことを特徴とする請求項１に記載の方法。
12. 第三機関のペイ・バイ・プレート駐車料金支払システムが前記第１の車両による前記単一の複数車両用目的地の使用についての支払いを受け取った対象の期間、及び前記第１の車両の第１の一意の識別子を特定した、前記単一の複数車両用目的地に関する支払情報を、前記第三機関のペイ・バイ・プレート駐車料金支払システムから取得するステップと、 前記第１の車両による前記第４の時刻から前記第５の時刻までの前記単一の複数車両用目的地の使用が、前記第三機関のペイ・バイ・プレート駐車料金支払システムから受け取った期間以外であることを特定するステップと、
    をさらに含むことを特徴とする請求項１に記載の方法。
13. １又はそれ以上のカメラによって取り込まれた複数の歩行者画像を受け取るステップをさらに含み、
    各歩行者画像は、前記第１の車両の乗客の画像を含み、
    前記複数の歩行者画像は、
    前記第１の車両の画像を含む１又はそれ以上の歩行者車両画像と、
    支払ステーションの画像を含む１又はそれ以上の歩行者支払画像と、
    を含み、前記方法はさらに、
    前記１又はそれ以上の歩行者車両画像に基づいて、前記第１の車両の乗客の第１の特徴を特定するステップと、
    前記１又はそれ以上の歩行者支払画像に基づいて、前記第１の車両の乗客の第２の特徴を特定するステップと、
    前記第１の車両の乗客の前記第２の特徴が、前記第１の車両の乗客の前記第１の特徴に対応すると判断するステップと、
    前記支払ステーションにおいて前記第１の車両の乗客から受け取られた支払いを記述する情報を取得するステップと、
    前記第１の車両の乗客の前記第２の特徴が、前記第１の車両の乗客の前記第１の特徴に対応するという判断に基づいて、前記支払いを前記第１の車両による前記単一の複数車両用目的地の使用に関連付けるステップと、
    を含むことを特徴とする請求項１に記載の方法。
14. 前記第１の車両及び前記第２の車両の前記第１，第２及び第３の特徴は、車両の色，サイズ及び寸法の１つ又はそれ以上を含む不変の特徴を備えることを特徴とする請求項１に記載の方法。
15. 前記第１の車両及び前記第２の車両の前記第１，第２及び第３の特徴は、車両速度及び走行車線の１つ又はそれ以上を含む時間と共に変化する特徴を更に含むことを特徴とする請求項１４に記載の方法。

Images