図1に、開示する主題による総合システム100の例を示す。ネットワーク110は、図1に示す要素間のデータ通信サービスを提供する。以下に限定されるわけではないが、イーサネット(登録商標)、802.11無線及びセルラーデータネットワーキング技術を含む多くのネットワーキング技術が存在し、当業者であれば、図示の要素間のデータ交換のためにこれらの技術を確実に予測通りに統合することができる。ある実施形態では、別個のネットワークを使用することができる。例えば、カメラ120及び125、並びにサーバ140が第1のネットワークを介して通信し、他の要素が公衆インターネットを介して通信することができる。当業者であれば、独立した第1のネットワークを使用することにより、信頼性及び安全性のための所望の目的を実現することができる。
識別カメラ120は、システム100に含まれる複数のこのようなカメラの1つを示すものである。説明の便宜上、図1には1つの識別カメラ120しか示していない。識別カメラ120は、以下に限定されるわけではないが、自動車ナンバープレートなどの車両識別子の画像、或いは車両識別子を提供する、以下に限定されるわけではないが、QRコード(登録商標)又はバーコードなどの形式の、車両に取り付けられたラベルの画像を取り込めるように位置付けられる。識別カメラ120によって取り込まれた画像121などの画像は、1又はそれ以上の目的地カメラ125によって取り込まれた画像と共に、車両130などの個々の車両を識別してこれらの車両による様々な目的地の使用を記録するために使用される。車両の目的地の例としては、以下に限定されるわけではないが、駐車スポットなどの様々な制約を受ける可能性はあるが駐車に適しているとして指定された範囲、及び以下に限定されるわけではないが、バス停、消防車専用車線、消火栓周囲の範囲、歩道、交差点からXフィート以内の範囲、私道、安全地帯、中央分離帯、自転車レーン、横断歩道などの、駐車に適していないとして指定された範囲を含む。例えば、サーバシステム140は、車両がいつバス停に停車したかを特定し、この特定に基づいて、車両の牽引要請又は郵送による違反切符の発行などの要求又は措置を行うように構成することができる。ある実施形態では、指定駐車スペース内に車両が正しく駐車されていないこと、縁石から1フィートを超えて駐車されていること、左側車輪を縁石に向けて駐車している(誤った方向を向いて駐車している)こと、後部からの斜め駐車、放置車両(X日又はそれ以上の日数にわたって特定の場所に放置されていること)などの、その他の駐車違反を識別することができる。ある実施形態では、識別カメラが、例えばスマートフォンに含まれるカメラを含むモバイル又はハンドヘルドカメラを含むこともできる。
目的地カメラ125は、システム100に含まれる複数のこのようなカメラの1つを示すものである。説明の便宜上、図1には1つの目的地カメラ125しか示していない。目的地カメラ125は、以下に限定されるわけではないが、自動車駐車スポットなどの1又はそれ以上の目的地の画像を取り込めるように位置付けられる。通常、目的地カメラ125は、以下に限定されるわけではないが、街灯又は電柱上、或いは建物の表面又は屋上などの高い位置に設置される。目的地カメラ125を高い位置に設置することにより、目的地カメラ125によって取り込まれる画像126などの画像の視野が複数の目的地を含むことができ、従って目的地カメラ125を使用して複数の目的地をモニタすることができる。ある実施形態では、目的地カメラが、例えばスマートフォンに含まれるカメラを含むモバイル又はハンドヘルドカメラを含むこともできる。ある実施形態では、目的地カメラを駐車メータ本体に含めることができる。ある実施形態では、人工衛星撮像カメラによって目的地カメラを提供して、市町村全体に目的地カメラを設置する必要性を潜在的に排除することができる。ある実施形態では、以下に限定されるわけではないが、小型飛行船又はその他の飛行船、或いは無人飛行体などの飛行体に目的地カメラを含めて、飛行時間いっぱいにわたって自律的に動作させることができる。
識別カメラ120及び目的地カメラ125は、各々がそれぞれの通信リンク127及び128を介してネットワーク110と直接通信するように構成することができる。別の実施形態では、識別カメラ120を、通信リンク127を介してネットワーク110と直接通信するように構成するのではなく、通信リンク129を介して目的地カメラ125と通信し、目的地カメラ125が通信リンク128を介してネットワーク110と通信して識別カメラ120との間でデータを中継するように、目的地カメラ125と直接通信して目的地カメラ125を通じてデータを中継するように構成することができる。通信リンク129は、無線ネットワークリンクとすることができる。図1には、2つのカメラ120及び125間に通信リンク129を含めた例を示しているが、この例は、複数のカメラを通じてデータを中継することによって所与のカメラとの間でデータ送信が行われるように拡張することができる。また、複数のカメラ間に無線メッシュネットワークを確立し、これらのカメラ間に耐故障性で自己構成型の無線通信媒体を提供することもできる。配線リンクの代わりに無線通信を使用することにより、システム内の全体的な配線通信リンクの数、並びにこのような配線リンクを設置して維持することに関連する出費及び労力を減少させることができる。また、一般にセルラーデータ通信のコストは配線リンクを介したものよりも大幅に高いので、このことは、例えばネットワーク110にデータを搬送するためにセルラーデータ通信を使用することに代わる有用な選択肢の役割を果たすこともできる。しかしながら、無線通信は必須ではなく、一部又は全部のカメラが配線リンクを介して通信することもできる。
サーバシステム140は、中央データ記憶サービス、データ検索サービス及び処理サービスを提供する1又はそれ以上のコンピュータシステムを含む。一般に、サーバシステム140に含まれるコンピュータシステムの各々は、ランダムアクセスメモリ142及びプロセッサ143を含む。サーバシステム140は、車両による駐車スペースなどの目的地の使用、車両のアカウント情報、識別カメラ画像を介して取得された車両の識別、目的地カメラ画像を介して取得された車両の観察記録、目的地の予約情報、課金情報及び支払情報などの情報を記録するために使用されるデータベース141を含む。データベース141は、例えば、MySQL、Oracle又はDBASEなどのソフトウェアプログラムを用いて実装することができる。データベース141は、複数のコンピュータシステムにわたって実行される複数のデータベースインスタンスを含むことができる。
ある実施形態では、サーバシステム140が、識別カメラ120などの識別カメラ及び目的地カメラ125などの目的地カメラによって取り込まれた画像から車車間識別認識を行うように構成される。さらに、サーバ140は、この認識された情報に基づいて、及び目的地の使用が目的地の使用制限に違反している時に、目的地の使用を決定することなどの意思決定を行うように構成される。画像処理及び意思決定がサーバシステム140に集中するこの実施形態は、マイクロプロセッサ内のトランジスタ数及び対応するデータ処理容量が18カ月毎に倍増するというムーアの法則、及び帯域幅速度が1年に50%ずつ成長すると仮定するニールセンの法則を活用する。この集中化方式によってかなりの利益を実現することができる。これまでの安価で高速なCPUパワーによってサーバアプリケーションの知能/機能の豊富さを急速に高めることができるだけでなく、新たな機能及び用途を現場の「シンクライアント」装置にまで急速に広げることもできる。システム全体を通じてCOTS(民生品)部品を使用することにより、一般に製造コストは削減される。また、ネットワークを介して利用できる技術サービスのアップデートを利用するために、高度にネットワーク化されたシステムが良好に位置付けられる。最後に、マイクロプロセッサ及び帯域幅のコストが減少し続けるので、サイズ又は容量を拡大するコストを下がり続けるコストで実現することができる。
別の実施形態では、いくつかの機能をシステムの他の構成要素に分散させることができる。例えば、識別カメラ120を、取り込み画像内におけるナンバープレート番号などの車両識別情報の存在を識別するように構成することができる。このような実施形態では、識別カメラ120が、例えば画像内の車両の存在を識別でき、画像内の車両識別情報の存在を識別でき、及び/又は画像から車両識別情報を抽出できる画像処理機能を実行することができるさらに高性能な装置である必要があるという点で、識別カメラ120とサーバシステム140の間のデータ通信帯域幅の量、及びサーバシステム140が行わなければならない処理の量をトレードオフによって大幅に削減することができる。別の例として、サーバシステム140を用いて車両画像の特徴を特定するのではなく、以下で図4に関連して詳述するように、識別カメラ及び目的地カメラを、車両画像の特徴を特定するようにプログラムすることもできる。システム全体を通じてどのように機能を分散できるかは、カメラによって取り込まれた画像を処理のために中心位置に搬送するための予想コストに対して重み付けした、(識別及び/又は目的地カメラに必要な処理ハードウェア及びプログラミングを提供することなどの)分散機能を提供する予想コストに依存する。通信ボトルネックに対処するために、サーバシステム140から識別カメラ120へのように1つのコンピュータシステムから別のコンピュータシステムにプログラム機能を移動させ、これらの機能を実行するのに十分な処理リソースが様々なコンピュータシステムに確実に提供されるようにすることは、当技術の範囲内に十分に収まる日常的課題である。
モバイル装置150は、プログラマブルコンピュータ、識別カメラ及びサーバシステム140と通信するための無線データ通信能力を含む。一例では、車両130が目的地を使用しているが、車両130の一意の識別符号が特定されなかった場合、目的地にモバイル装置150を派遣し、車両130の画像151を取り込み、この画像から車両130の一意の識別符号を取得することができる。モバイル装置150は、識別カメラ120が行うようにナンバープレートの画像を取り込むことに加え、車両のVIN識別子タグを取り込むように構成することもでき、このことはナンバープレートのない車両に対して役立つことができる。このことは、車両130が識別カメラ120の視野を通過した時に別の車両によって遮られ、識別カメラ120が車両130を一意に識別するのに効果的な画像を撮影できない場合などの偶発的状況を克服する役に立つ。サーバシステム140によって管理されている全ての目的地にわたるタイムリーな画像の取り込みをさらに確実にするために、システムに複数のモバイル装置を含めることもできる。ある実施形態では、モバイル装置150を、駐車違反取締に役立つ機能を提供するように構成することもできる。例えば、モバイル装置150を、サーバシステム140によって識別された駐車違反について紙の違反切符を印刷するように構成することができる。
オンサイト支払システム160は、一般に1又はそれ以上の目的地の近くに配置される直接的な物理インターフェイスを提供する複数の装置のうちの、エンドユーザが目的地の使用に関する支払い又は支払い同意を提出できるようにするためのものである。支払システム160の例としては、以下に限定されるわけではないが、個々の目的地専用の駐車メータ、複数の路上駐車スペースに関連する支払ステーション、及び駐車区画又は駐車場ビルに設けられた、目的地のための支払ステーションが挙げられる。ある実施形態では、オンサイト支払システム160が、1又はそれ以上の目的地の画像を取り込む目的地カメラを含むことができる。
エンドユーザシステム170は、車両130のドライバーなどのエンドユーザがサーバシステム140とやりとりできるようにするプログラマブルコンピュータシステムである。このようなシステムの例としては、以下に限定されるわけではないが、ウェブブラウザアプリケーションを含むデスクトップコンピュータシステム、ウェブブラウザアプリケーション又は専用駐車アプリケーションを含むスマートフォン、及び車両130に含まれる車載システムが挙げられる。エンドユーザシステム170は、例えば、サーバシステム140と反復的にやりとりするためのエンドユーザアカウントの作成、目的地の使用予約、利用可能な目的地の識別要求、及び目的地の使用に関する支払情報の提出に使用することができる。
ある実施形態では、エンドユーザシステム170を、所与の範囲の利用可能な目的地を記述する情報をサーバシステム140に要求して取得するように構成することができる。一例では、エンドユーザシステム170を、駐車場ビル内の目的地又は路上駐車ではない(駐車区画などの)目的地などの、許容できる目的地のための特定の基準の取得及び/又は要求を行うようにさらに構成することができる。エンドユーザシステム170は、位置情報に加え、以下に限定されるわけではないが、所与の目的地の利用コストなどのその他の情報を取得することもできる。エンドユーザシステム170は、現在利用可能な目的地、及び/又は将来的な指定時刻又は時間範囲に利用可能な目的地の情報を要求して取得するようにさらに構成することができる。エンドユーザシステムは、サーバシステム140から取得された利用可能な目的地のうちの1又はそれ以上の目的地の特定の位置を地図上などに示すグラフィカルユーザインターフェイスをエンドユーザに提供するようにさらに構成することができる。ある実施形態では、(駐車場ビル又は駐車区画などの)駐車施設において複数の目的地が利用可能な場合、エンドユーザシステム170を、各目的地を個別に識別するのではなく、駐車施設における目的地の利用可能性を大まかに示す(場合によっては利用可能な目的地の数を示す)ように構成することができる。エンドユーザシステム170は、選択された目的地の指示をエンドユーザから受け取るように構成することができる。エンドユーザシステム170は、選択された目的地までの、どこで曲がるかの指示などのガイドを行うようにさらに構成することができる。エンドユーザシステム170は、利用可能な目的地の使用を予約するようにサーバシステム140に命令するようさらに構成することができる。
手動再確認システム180は、車両130などの車両を識別するように人間オペレータ181がサーバシステム140を支援するためのプログラムドコンピュータシステムである。例えば、サーバシステム140は、識別カメラ120によって取り込まれた画像121などの画像から、車両130の一意の識別子の自動化された機械ベースの特定を行っている際に、エラーが発生したと判断することがある。サーバシステム140は、このエラーに応答して、車両130のナンバープレート番号などの一意の識別子を特定するように人間オペレータ181による支援を要求することができる。手動再確認システム180は、人間オペレータ181が画像121を、また場合によっては識別カメラ120又はその他のカメラによって取り込まれた他の画像を再確認できるようにするユーザインターフェイスを提供する。例えば、人間オペレータ181は、車両のナンバープレート番号及び州/県の情報を手動で特定するために、手動によるビデオ映像の巻き戻し及び静止画像の早送りを行うことができる。人間オペレータ181は、このインターフェイスを介して車両130の識別符号を提供することができ、或いは人間オペレータ181が車両130の識別符号を特定できなかった旨を示すことができ、この結果、車両130の積極的な識別を行うために目的地にモバイル装置150を派遣することができる。サーバシステム140が処理する情報量に応じて、サーバシステム140が複数の手動再確認システム180を利用できるようにすることもできる。また、人間オペレータ181は、以下でさらに詳細に説明するライブオペレータチームのメンバとすることもできる。
ある実施形態では、識別カメラ及び目的地カメラの1つ又はそれ以上が、これらのカメラからサーバシステム140に送信される画像よりも高いフレーム率及び/又は解像度で画像を取り込む。このようなカメラによって取り込まれた画像データは全てサーバシステム140に送信されるわけではないが、高価な可能性のあるネットワーク通信帯域幅(例えば、セルラーデータネットワーク)及びサーバシステム410において利用できる限られた画像処理リソースを節約するために、このようなカメラは、これらが取り込んだ限られた量のフル画像データを循環バッファなどにバッファリングすることができる。また、このようなカメラは、例えばナンバープレートの認識に役立つことができる高解像度画像の部分を含むこのような追加画像データを求める要求に応答するように構成される。この機構により、サーバシステム140は、車両の識別及び追跡に追加画像が役立つと自動的に判断することができ、或いは手動再確認システム180は、サーバシステム140によって生じたエラーを解決するために様々な画像を要求することができる。
駐車場運営システム190は、駐車施設オペレータがサーバシステム140とやりとりしてサーバシステム140を制御できるようにするプログラムドコンピュータシステムである。サーバシステム140は、時間の大半にわたり、駐車場オペレータによる入力をほとんど必要とせずに自律的に動作すると予想される。しかしながら、時には、駐車施設のオペレータ職員がその動作に積極的に参加する場合もある。例えば、駐車場運営システム190は、どれほどの及びどの目的地が使用中及び/又は利用可能であるかに関するライブ指示を提供することができる。別の例として、駐車場運営システム190は、車両が使用制限に違反している目的地に関するライブ指示を提供し、必要と考えられる時に駐車施設のオペレータ職員がこのような違反に対して対策を取れるようにすることができる。
図2Aに、識別カメラ120によって取り込まれた画像121の例を示しており、この場合、識別カメラ120は、その側を通過する車両の識別情報を効果的に取り込むように配置されている。ある実施形態では、識別カメラ120が、ナンバープレート情報などの識別情報の画像を含むビデオをサーバシステム140にストリーミングする。典型的な街灯の高さは約18フィートであるため、これらの街頭は、木及び近くを通る車両を含む他の障害物から離れた明瞭な見通し線の恩恵を受ける優れた識別カメラ設置位置を提供する。また、既に街灯に電力が供給されている時には、その街灯から電力を引き込むように識別カメラを設置することができる。また、多くの都市条例では、通りの各サイトの1ブロック毎に少なくとも1つの街灯が必要とされているので、街灯に設置された識別カメラは、通りを往来するあらゆる車両のための十分なカバレッジを提供することができる。
識別カメラ120によって取り込まれた識別画像は、(1)車両の前方又は後方に取り付けられたナンバープレートから識別子などを読み取ることなどによって車両の一意の識別符号を取得すること、及び(2)図4に関連して後述するように、別のカメラによって取得された車両の画像が識別車両に対応すると判断できるように車両の様々な特徴を特定すること、という2つの主な目的のために使用される。図2Aに示す識別画像例では、車両のビュー及びそのナンバーをサーバシステム140による処理に利用することができる。複数の識別画像を用いて、移動速度及び移動方向などの車両特徴の特定することができる。
当業では、ナンバープレートリーダの分野において、車両識別子の確実な読み取りに有効な画像を様々な照明及び車両条件下で確実に取り込むための様々な技術が周知である。1つの非限定的な例が米国特許第7,016,518号に記載されており、この特許はその全体が引用により本明細書に組み入れられる。ある実施形態では、夜間に自然照明が存在しないことによって生じる、目的地を使用するための制限が日中にしか有効でないという問題を避けることができる。
ある実施形態では、車両識別子を取得するためのマシンビジョン技術を識別カメラ120によって実行することができる。このような実施形態では、識別画像の代わりに車両識別子を送信できるので、識別カメラ120からサーバシステム140に送信されるデータの量を大幅に削減することができる。しかしながら、サーバシステム140が車両特徴の記憶及び/又は特定を行えるように1又はそれ以上の識別画像をサーバシステム140に送信することもできる(ある実施形態では、これも識別カメラ120によって行うことができる)。
ある実施形態では、サーバシステム140が、場合によっては車両の角度又は後続車両の接近などのいくつかの特定条件の結果として、車両識別子の一部しか取得できていないと認識することができる。このような場合、サーバシステムは、第2の識別カメラによって取り込まれた第2の識別画像にさらに依拠して識別子の残り部分を取得することができる。
図2Bに、識別カメラ120によって取り込まれた画像121の例を示しており、この場合、識別カメラ120は、その視軸に沿って延びる道路を通じて都市交差点に出入りする車両の識別情報を効果的に取り込むように配置されている。この識別画像では、サーバシステム140による処理にとって3台の車両のビューが有効であることにより、1つの画像から3台の車両全ての一意の識別子を取得できるようになる。
ある実施形態では、識別カメラ120が、パン、チルト及び/又はズーム能力を有することができ、これらの能力は、サーバシステム140が車両のより詳細なビューを取得するために使用することができ、或いは駐車施設のオペレータ職員が、駐車場運営システム190のユーザインターフェイスを介して、識別カメラ120から見える特定の関心領域をモニタするために使用することができる。このような実施形態では、サーバシステム140を、識別カメラ120の視野を変更しながら車両特徴を正確に特定するために座標変換を行うように構成することができる。
ある実施形態では、車両が識別カメラ120の視野内に現れた時に、サーバシステム140が6つのタスクのうちの1つ又はそれ以上を実行する。サーバシステム140は、第1のタスクにおいて、識別カメラ120によって取り込まれた1又はそれ以上の画像に基づいて1又はそれ以上の車両の存在を検出する。ある実施形態では、サーバシステム140を、車両と背景の色の違いに基づいて車両の存在を検出し、潜在的な車両の全体的形状のサイズが、あらゆる適用可能なズームレベルに合わせて調整された指定最小車両サイズよりも大きいと判定するように構成することができる。具体的には、このようなアルゴリズムは、画像内の全ての画素の色を互いに比較することができる。画素は、行と列に分割される(例えば、絶対位置21,34は、行21列34に位置する画素を表すことができる)。画像は、以下に限定されるわけではないが、消火栓、歩行者、車、芝生、又は道路標識/道路塗装などの他の非車両物体を含む可能性があるので、このアルゴリズムは、類似色の画素グループを検出するように構成することができる(類似していると見なされる色の範囲はシステム設定において指定することができ、類似色は、カラーチャートによって示される色調を参照して最大で2色調の違いとすることができる)。次に、これらの画素の位置を数学的に計算して、最小車両サイズよりも大きな形状を形成しているかどうかを判定する(例えば、10×30の相対的サイズは、10行×30列の大きさの形状を表すことができる)。識別カメラ120によって取り込まれた画像内に現れる車両は、視野角に起因して矩形よりもむしろ平行四辺形に見える傾向にある。従って、この判定は、この要素を考慮することができる。
例えば、太陽の反射、フロントガラス領域又はルーフラックに起因する、検出された形状内の「穴」又は不完全性に対処するようにさらなる微調整を行うことができる。例えば、このアルゴリズムは、通常は同じ色であるボンネット、屋根及びトランクなどの車両部分に対応することができる、互いに一定距離(又は画素)以下離れた特定の最小サイズの形状の数を指定することができる。
車両が検出されると、例えば、日付、時間、車両の色、車両のサイズ、画素の位置及びズームレベルを含む情報と共に、識別カメラ120に対応するデータベース141の部分にエントリを記録する。この情報を車両の他の検出物と共に使用して車両を識別することができる。或いは、このような情報をRAMなどの揮発性メモリに一時的に記録することもできる。
サーバシステム140は、第2のタスクにおいて、ナンバープレートの存在、及び/又は以下に限定されるわけではないが、識別カメラ120によって取り込まれた画像内の車両のステッカー(decals)などのさらなる識別符号を検出する。ナンバープレート及び/又はさらなる識別符号が検出されると、例えば、日付、時間、ナンバープレート#、州/県、ステッカーの詳細(例えば、種類、識別子及び有効期限)、画素の位置及びズームレベルを含む情報と共に、識別カメラ120に対応するデータベース141の部分にエントリを記録する。この情報を車両の他の検出物と共に使用して、目的地カメラによって取り込まれた画像などの他の画像内で車両を識別することができる。
サーバシステム140は、第3のタスクにおいて、識別カメラ120によって取り込まれた複数の画像に基づいて、動いている車両と止まっている車両を識別する。
サーバシステム140は、第4のタスクにおいて、識別カメラ120によって取り込まれた複数の画像に基づいて、動いているナンバープレート及び/又はさらなる識別符号と止まっているナンバープレート及び/又はさらなる識別符号を識別する。一例では、サーバシステム140を、(1)現在の画像からOCRなどを介して取得されたナンバープレート及び/又はさらなる識別情報に基づいて、(例えば、データベース141又はメモリに記憶されているデータを再検討することによって)前回の画像の対応する一致点を発見し、(2)このような一致点が発見されたら、ズームレベルのあらゆる変化を考慮して現在の画像と前回の画像の間で画素の位置を比較する、ように構成することができる。このような処理に基づいて、以下のシナリオのうちの1つ又はそれ以上を検出することができる。(A)画素の位置が変化しておらず、又は所定の閾値未満しか変化していなかった場合、全てのナンバープレート及び/又はさらなる識別符号を止まったままであると見なす。このシナリオでは、車両のデータベース141又はメモリ内の既存のエントリに対して日付及び時間の単純な更新が行われる。(B)1又はそれ以上のナンバープレート及び/又はさらなる識別符号に関連する画素が新たな位置に存在する場合、1又はそれ以上のナンバープレート及び/又はさらなる識別符号が動いたと判定する。サーバシステム140は、これらの車両の移動速度及び移動方向を計算し、この情報及び更新された位置を用いてデータベース141又はメモリを更新することができる。(C)1又はそれ以上のナンバープレート及び/又はさらなる識別符号が現在の画像から消えた場合、サーバシステム140を、データベース141又はメモリに記録されているこのような車両のためのデータを削除するように構成することができる。(D)1又はそれ以上のナンバープレート及び/又はさらなる識別符号が現在の画像に新たに出現した場合、この新たなナンバープレート及び/又はさらなる識別符号に関連するデータをデータベース141又はメモリに記録することができる。ある実施形態では、サーバシステム140が、新たな車両の1つが、画像から消えたと最近判定されていた車両に対応すると判定し、この車両のビューを一時的に妨害されていたものとして処理することができる。(E)現在の画像から全てのナンバープレート及び/又はさらなる識別符号が消えた場合、前の間隔からのデータベース141又はメモリからのデータを、これらのデータ内のナンバープレート及び/又はさらなる識別符号に関連して削除することができる。しかしながら、上述したように、識別カメラとの間で車両追跡を実行するために一部のデータは保存しておくことができる。
サーバシステム140は、第5のタスクにおいて、識別されたナンバープレート及び/又はさらなる識別符号を、第1のタスクで検出された車両と対にする。例えば、サーバシステム140は、ナンバープレート及び/又はさらなる識別符号の(例えば、絶対的画素位置、移動方向及び速度などの)属性を、可能性のある車両について特定されたこのような特性と比較し、各ナンバープレート及び/又はさらなる識別符号を車両と対にしようと試みるように構成することができる。
サーバシステム140は、第1から第5のタスクにおいて、特定の車両が特定の駐車スペースに駐車するのにふさわしいかどうか、或いは運転免許登録が最新であって有効であるかどうかを確認する目的で、マシンビジョン技術を適用して車両上のさらなる識別符号を識別することができる。これらの他の種類の一意の識別符号としては、以下に限定されるわけではないが、障害者用駐車ステッカー又はミラーハンガー、居住者専用駐車ステッカー、及び通常はナンバープレートに貼り付けられる登録ステッカーを含む。
第1から第5のタスクでは、英数字ナンバープレート番号及び発行した州/県を取得するために、あらゆるナンバープレート画像にOCR(光学文字認識)を実行することができる。なお、観察されるナンバープレートは、前部ナンバープレート又は後部ナンバープレートのいずれであってもよい(通常は、通りの上下両方向を向いた識別カメラが設けられる)。この取得されたナンバープレート情報を用いて、車両に関する情報をデータベース141に記録するために使用する一意の車両識別子を取得する。いくつかの構成では、第1のタスクを識別カメラ上でローカルに実行することができ、この場合、ナンバープレート番号及び州/県データが、簡潔なデータフォーマットでサーバシステム140に送信される。識別カメラ120とサーバシステム140の間の根本的な通信ネットワークが十分な帯域幅をもたらさない(例えば、画像をストリーミングするための最小閾値は1Mb/秒と考えることができる)場合、又はあまりにコストが高い(例えば、$10/MBよりも高い)と考えられる場合には、このことが特に当てはまる。識別画像121内には、複数の車両が同時に存在することがある。ある実施形態では、サーバシステム140が、所与の時点に単一の識別カメラから最大10組の車両ナンバープレート情報を同時に追跡することができる。
第6のタスクでは、識別カメラ120の視野を横切って車両が移動した時に、この車両を「追跡」する。識別カメラ120によって取り込まれる画像と、近隣の目的地カメラ125によって取り込まれる画像との間には、車両が15MPH(約44フィート)の速度において最短2秒にわたって両方のカメラの視界内に存在するように重複部分が存在する。一般に、近隣又は近傍カメラの位置は、この重複部分が確実に生じるように決定される。これらの2つのカメラは独自に異なる画角を有するので、これらのカメラの両方から所与の車両の重複画像を取得することは、車両及び(車両が駐車している場合には)この車両が占めている正確な目的地の(識別画像121から取得されたナンバープレート番号を介した)確実な識別として認識される。
ある実施形態では、識別カメラ120の視野を通過する車両がない時間がかなり存在すると思われるので、予備動き検出を用いて、取り込み及び/又は分析を行う識別画像数を減少させることができる。
OCRレートは、識別性能の評価における有用な測定法の1つにすぎない。例えば、記録された/取り込まれた100個のナンバープレートのうち、サーバシステム140がOCRし損ねた(換言すれば、英数字プレート番号を生成できなかった)のがこれらのナンバープレートのうちのたった1つであれば素晴らしいことであるが、(サーバシステムのプログラミング、識別カメラの配置及び識別カメラの画質などの要素を含む)このような構成が、他の100個のナンバープレートの取り込み/登録に失敗した(換言すれば、サーバシステム140によってさらなるナンバープレート画像がこのように識別されなかった)とすれば、全体的な有効性はたった49.5%である。さらに、通常、ナンバープレート認識システムは、特定の州/県からのナンバープレート、及び複数の周囲の州/県からのナンバープレートを読み取るように調整される。様々な州/県からのナンバープレートは、文字と背景の色及びコントラストが異なる。ある実施形態では、取り込み率が少なくとも95%であってOCR精度が少なくとも95%であり、最低限の全体的有効性が少なくとも90.25%になる。
図3Aに、都市街路の一部を見下ろす建物の表面又は屋上に配置された目的地カメラ125によって取り込まれた画像126の例を示しており、従ってこの画像126では車両の上面ビューが見える。図3Aに示す画像126に対応する視野に関連して、サーバシステム140には、(時間単位の料金で使用できる駐車スポットなどの)9個の適当な目的地310a〜310iが指定されている。これらのうち、目的地310d以外の全ては、車両310a〜310iによって使用中と思われる。サーバシステム140には、(商業的な入口などの)不適当な目的地340も指定される。ある車両が、一定期間にわたって止まったままであることによって目的地340を使用していると判断された場合、この車両は違反していると見なされ、サーバシステム140は、以下に限定されるわけではないが、この違反に対する罰金を課す、又はこの違反を駐車施設オペレータに警告するなどの措置を開始する。いくつかの実施形態では、目的地として識別されていないあらゆる範囲内で止まったままの車両を違反と見なすことができる。画像126では、画像の右から左に移動する車線内の車両330も確認される。この単一の画像のみでは、車両330が動いているか、それとも止まっているかは分からない。例えば、前の画像では、車両330が目的地310dを使用していたかもしれず、従ってサーバシステム140は、その画像によって車両330が目的地310dの使用を終えたばかりであると判断することができる。
目的地カメラ125によって取り込まれた目的地画像は、図4に関連して後述するように、車両がカメラ間を移動した時に、近隣の複数のカメラによって取り込まれた画像から特定される特徴が互いに一致するかどうかを判定することによって車両を追跡できるように、(1)目的地がいつ車両によって使用されているか、又は使用されていないかを識別すること、及び(2)車両の様々な特徴を特定すること、という2つの主な目的のために使用される。
図3Bに、画像126内に車両の側面ビューが示されるように位置付けられた目的地カメラ125によって取り込まれた画像126の例を示す。このようなビューは、駐車メータなどのオンサイト駐車システム160内、或いは1又はそれ以上の関心目的地の向かい側にある建物又は構造物上に目的地カメラ125を配置した場合に得られる。図3Bに示す画像126に対応する視野に関連して、サーバシステム140には、(時間単位の料金で使用できる駐車スポットなどの)4つの適当な目的地350a〜350dが指定されている。これらのうち、目的地350c以外の全ては、車両360a〜360dによって使用中と思われる。
別の例では、図面には示していないが、画像126が1又はそれ以上の目的地の斜視ビューを提供するように目的地カメラ125を位置付けることができる。図3A及び図3Bには、目的地として矩形範囲310及び350の規格を示しているが、多角形などの他の形状を使用することもできる(この形状は、目的地が遠近的に確認されるように目的地カメラ125を位置付ける場合に有用である)。図6A及び図6Bに関連して後述するGUIを、画像フィード上のオーバーレイを用いてカメラの視野内における目的地の位置及び範囲を指定するために使用できるユーザインターフェイス要素を提供するように構成することもできる。また、このGUIは、目的地の識別子、及び場合によっては、以下に限定されるわけではないが、これらの目的地が駐車スペースであるか、「駐車禁止」の場所であるか、並びに時間及び/又は日付に基づく使用制限区域であるかなどの、目的地に関する様々な特徴を割り当てるためのツールを提供することもできる。
ある実施形態では、車両が目的地カメラ125の視野内に現れた時に、サーバシステム140が2つのタスクを実行する。第1のタスクでは、サーバシステム140を、(1)目的地カメラ125の視野内に存在するありとあらゆる車両を認識し、(2)動いている車両と止まっている車両を区別し、(3)動いている車両が、目的地に対応する視野の範囲内で動かなくなった時点を識別し、(4)各止まっている車両がどの(単複の)目的地を使用しているかを識別し、(5)各車両がそのそれぞれの目的地をどれほど使用していたかを追跡し、(6)動いていない車両が、目的地に対応する視野の範囲から立ち去った時点を識別し、(7)目的地の使用が、その目的地に対して設定されている制限にいつ抵触したかを特定し、(8)車両がどの通り又はブロックに不適切に駐車されているかを識別し、(9)各車両が不適切に駐車されている時間を追跡し、(10)車両が違法駐車を止めた時点を追跡する、ように構成することができる。各々が車両に対するそれぞれの制限を有する様々な種類の目的地としては、以下に限定されるわけではないが、駐車禁止区域(常時、消防車専用車線、消火栓)、指定時間及び/又は指定日駐車禁止(例えば、ラッシュアワー時又は街路清掃時)、駐車/停車/一時停車禁止、時間制限駐車(例えば、2時間制限)、車種によって制限された駐車(タクシー乗り場、バス停、荷積み区域/商用車専用)、許可された駐車(障害者又は居住者専用の駐車)、乗車及び降車専用の場所、及び道路交差点(車両の移動方向が赤信号である間に車両が交差点内に残る交通渋滞防止用の「交差点通行妨害」違反)が挙げられる。サーバシステム140は、以下に限定されるわけではないが、交差点から指定距離内における駐車、バイク専用車線又は横断歩道又は他の歩行者専用区域における駐車、単一の目的地用スペースからはみ出た駐車、縁石から指定距離よりも離れた駐車、私道内又は私道前における駐車、安全地帯又は中央分離帯の使用、誤った方向を向いて駐車された車両、(指定日数を上回って止まっている)放置車両、サイズオーバーの車両、(所与の日数における指定時間を越えたキャンピングカー、トレーラ又はボートなどの)不適当な種類の車両などの他の駐車違反を検出するように構成することもできる。目的地は予約することもでき、この場合、エンドユーザは、指定期間にわたる独占的な目的地の使用を予約する。サーバシステム140は、並列駐車車両を検出する一方で、走行状態に起因して車線内に停止している車両と不正に並列駐車している車両とを区別するように構成することもできる。サーバシステム104は、オートバイ、スクータ及び「スマートカー」などの小型車両を認識し、場合によってはこれらを区別するように構成することもできる。
第2のタスクでは、車両が目的地カメラ125の視野を横切って移動した時に、この車両を「追跡」する。目的地カメラ125によって取り込まれる画像と、近隣の識別又は目的地カメラによって取り込まれる画像との間には、車両が15MPH(約44フィート)の速度において最短2秒にわたって両方のカメラの視野内に存在するように重複部分が存在する。一般に、近隣カメラの位置は、この重複部分が確実に生じるように決定される。これらの2つのカメラは独自に異なる画角を有するので、これらのカメラの両方から所与の車両の重複画像を取得することは、車両及び(車両が駐車している場合には)この車両が占めている正確な駐車スペースの(識別画像121から取得されたナンバープレート番号を介した)確実な識別として認識される。
いくつかの構成では、目的地カメラを、サーバシステム140にとっての関心目的地を含まない特定の範囲の車両の動きをモニタするように位置付けることができる。このような範囲は、例えば、各々が関心目的地を含む2つの範囲間に存在することができる。この例では、目的地カメラによって取り込まれた画像が、これらの2つの範囲に対応するカメラによって取り込まれた画像に重複することができ、この目的地カメラによって取り込まれた画像は、後述する図4に示すような「ハンドオフ」手順に使用することができる。
ある実施形態では、目的地カメラ125が、パン、チルト及び/又はズーム能力を有することができ、これらの能力は、サーバシステム140が目的地のより詳細なビューを取得するために使用することができ、或いは駐車施設のオペレータ職員が、駐車場運営システム190のユーザインターフェイスを介して、目的地カメラ125から見える特定の関心領域をモニタするために使用することができる。このような実施形態では、サーバシステム140を、目的地カメラ125の視野を変更しながら目的地の使用をモニタして車両特徴を正確に特定するために座標変換を行うように構成することができる。
ある実施形態では、目的地カメラ125の視野を通過する車両がない時間がかなり存在すると思われるので、予備動き検出を用いて、取り込み及び/又は分析を行う目的地画像数を減少させることができる。
ある実施形態では、後で必要になった場合に記憶された画像を手動で容易に再確認できるように、識別カメラ及び目的地カメラによって取り込まれた全ての画像に正確な日付及びタイムスタンプが含まれる。
ある実施形態では、車両が(駐車禁止区域などの不適当な目的地とは対照的に)適切な目的地内で停止したと判定された後に、この車両に一定の「支払猶予期間」が与えられる。ドライバーが駐車料金を支払うために車両から離れた時には、たとえ車両が支払いを行っていない状態で目的地を使用し始めたと判定された場合でも、支払過程を完了するのに一定の時間が必要であるため、車両が有料使用要件に違反している旨の決定を遅らせるための一定の支払猶予期間が必要である。
図4に、カメラによって重複視野で取り込まれた画像を用いて、いかにして車両を識別し、目的地までの車両の動きを追跡し、車両による目的地の使用を識別するかを示す。図4は縮尺通りに示しておらず、例えば、重複範囲430aは、名目上は垂直方向に44フィート又はそれ以上延びているが、車両410とほぼ同じサイズとして示している。まず、時刻t1に、識別カメラ(図示せず)が、図4に示す視野をカバーする識別画像420を取り込む。識別画像420には、410’で示す位置にある車両410が含まれる。サーバシステム140は、画像420a(及び、恐らくは時刻t1よりも前に識別カメラによって取り込まれた追加画像)に基づいて、車両410の一意の識別子を特定する。例えば、1又はそれ以上の検出されたナンバープレートの画像にOCRを実行することによってナンバープレート番号を取得し、ここから一意の識別子を取得することができる。サーバシステム140は、車両410が識別カメラによって時刻t1に観察されたことを、一意の識別子に関連付けてデータベース141に記録する。別の実施形態では、サーバシステム140が、車両410が識別カメラによって時刻t1に観察されたことを代わりに揮発性メモリに記憶し、識別画像420を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両410がサーバシステム140によって識別される前に車両410が目的地を使用したという判定の後に、このような情報をデータベース141に記録する。
識別カメラは、時刻t2において、410aで示す位置にある車両410の別の識別画像420a’を取り込む。ほぼ時刻t2において、第1の目的地カメラが、(例えば、ほぼ位置410aにおける)重複範囲430a内にある車両410の目的地画像420bを取り込む。いくつかの実施形態では、識別カメラと第1の目的地カメラが同期することにより、画像420a’及び420bの両方が基本的に同時刻t2に取り込まれる。重複範囲430aは、目的地画像420bの視野に重複する識別画像420a’の視野に対応する。両画像420a’及び420bでは、車両410が重複範囲430a内に存在する間に車両410の画像が取り込まれている。
サーバシステム140は、識別カメラによって取り込まれた(識別画像420a’などの)1又はそれ以上の識別画像に基づいて、車両410の複数の特徴Caを特定する。上述したように、Caには、データベース141に記録されている車両410の不変特徴を含めることができる。この特徴の例としては、以下に限定されるわけではないが、車両410の移動速度、車両410の移動方向、(例えば、車両410が走行している車線を含む)車両画像内における車両の位置、車両410の色、及び車両410のサイズ又は寸法が挙げられる。いくつかの特徴は、車両410の静的特徴と見なすことができ、時間と共に変化しないと予想される(例えば、車両の色又はサイズ)。他の特徴は、車両410の動的特徴と見なすことができ、時間と共に大きく変化することがある(例えば、車両速度又は走行車線)。ある実施形態では、静的特徴を車両410の不変特徴として、識別画像420aに基づいて特定された一意の識別子に関連付けてデータベース141に記録することができる。これらの不変特徴は、エンドユーザによって提供される(型式、モデル、年及び色などの)車両情報に基づいて特定することも、或いは車両410とサーバシステム140が以前に遭遇した間に取り込まれた車両画像に基づくこともできる。この不変特徴は、識別画像から特定された静的特徴が不変特徴に対応することを保証することにより、車両410の一意の識別子を特定したことに関連して使用することができる。車両の識別符号が確認された場合には、Ca又はその他の複数の特徴に不変特徴を含めることもできる。サーバシステム140は、目的地画像420b、及び場合によっては第1の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両410の複数の特徴Ca’を特定する。Ca及びCa’は、識別カメラと第1の目的地カメラにおける車両410の異なる画角、及び妨害車両などの要因に起因して、異なるけれども一般的には重複する一連の車両特徴を含むことができる。例えば、第1の目的地カメラの視点からは、時刻t2前後において車両410が部分的に遮られていることにより、Caでは車両の幅を特定することができるが、Ca’では特定できないことがある。また、通常は画像の境界において有意になる画像の歪み又はその他の要因により、速度又はサイズなどのいくつかの車両特徴が近似値のみになることもある。カメラの位置及びズームレベルを補償するために、サイズ、移動速度及び移動方向などの特徴は標準化することができる。
次に、サーバシステム140は、Ca及びCa’の両方に含まれている車両特徴の値を比較することによってCa’がCaに対応又は合致するかどうかを判定する。サーバシステム140によって特定された車両特徴は、車両410の実際の特徴の近似値とすることができるので、比較される特徴の全てに対して値の近似等価を実証すれば、Ca’がCaに対応するという判定を裏付けるのに十分である。Ca’がCaに対応すると判定された場合、サーバシステム140は、車両410が第1の目的地カメラによって時刻t2に観察されたことを一意の識別子に関連付けてデータベース141に記録する。別の実施形態では、サーバシステム140が、車両410が第1の目的地カメラによって時刻t2に観察されたことを代替的に揮発性メモリに記憶し、識別画像420を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両410がサーバシステム140によって識別される前に車両410が目的地を使用したという判定の後に、このような情報をデータベース141に記録する。これにより、車両410によって特定の目的地が使用されていることを実証するために必要のない車両位置情報をデータベース141に書き込むことが避けられる。
第1の目的地カメラは、時刻t3において、410bで示す位置にある車両410の別の目的地画像420b’を取り込む。ほぼ時刻t3において、第2の目的地カメラが、(例えば、ほぼ位置410bにおける)重複範囲430b内にある車両410の目的地画像420cを取り込む。いくつかの実施形態では、第1の目的地カメラと第2の目的地カメラが同期することにより、画像420b’及び420cの両方が基本的に同時刻t3に取り込まれる。重複範囲430bは、目的地画像420cの視野に重複する目的地画像420b’の視野に対応する。両画像420b’及び420cでは、車両410及び440が重複範囲430b内に存在する間に車両410及び440の画像が取り込まれている。
サーバシステム140は、第1の目的地カメラによって取り込まれた(識別画像420b’などの)1又はそれ以上の目的地画像に基づいて、車両410の複数の特徴Cbを特定する。上述したように、Cbには、データベース141に記録されている車両410の不変特徴を含めることができる。サーバシステム140は、目的地画像420c、及び場合によっては第2の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両410の複数の特徴Cb’を特定する。また、目的地画像420cに車両440が含まれていることにより、車両440の複数の車両特徴Cxも特定される。車両440は、異なる車線内を逆方向に走行しているため、Cb’とCxでは動的車両特徴に違いが生じる。次に、サーバシステム140は、あり得ないことではあるが、CxがCbに対応するかどうかを判定する。次に、サーバシステム140は、Cb’がCbに対応するかどうかを判定する。Cb’がCbに対応すると判定された場合、サーバシステム140は、車両410が第2の目的地カメラによって時刻t3に観察されたことを一意の識別子に関連付けてデータベース141に記録する。別の実施形態では、サーバシステム140が、車両410が第2の目的地カメラによって時刻t3に観察されたことを代わりに揮発性メモリに記憶し、識別画像420を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両410がサーバシステム140によって識別される前に車両410が目的地を使用したという判定の後に、このような情報をデータベース141に記録する。
第2の目的地カメラは、時刻t4において、410cで示す位置にある車両410の別の目的地画像420c’を取り込む。ほぼ時刻t4において、第3の目的地カメラが、(例えば、ほぼ位置410cにおける)重複範囲430c内にある車両410の目的地画像420dを取り込む。いくつかの実施形態では、第2の目的地カメラと第3の目的地カメラが同期することにより、画像420c’及び420dの両方が基本的に同時刻t4に取り込まれる。重複範囲430cは、目的地画像420dの視野に重複する目的地画像420c’の視野に対応する。両画像420c’及び420dでは、車両410が重複範囲430c内に存在する間に車両410の画像が取り込まれている。
サーバシステム140は、第2の目的地カメラによって取り込まれた(識別画像420c’などの)1又はそれ以上の目的地画像に基づいて、車両410の複数の特徴Ccを特定する。上述したように、Ccには、データベース141に記録されている車両410の不変特徴を含めることができる。サーバシステム140は、目的地画像420d、及び場合によっては第3の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両410の複数の特徴Cc’を特定する。次に、サーバシステム140は、Cc’がCcに対応するかどうかを判定する。Cc’がCcに対応すると判定された場合、サーバシステム140は、車両410が第3の目的地カメラによって時刻t4に観察されたことを一意の識別子に関連付けてデータベース141に記録する。別の実施形態では、サーバシステム140が、車両410が第3の目的地カメラによって時刻t4に観察されたことを代わりに揮発性メモリに記憶し、識別画像420を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両410がサーバシステム140によって識別される前に車両410が目的地を使用したという判定の後に、このような情報をデータベース141に記録する。ある実施形態では、第2の識別カメラが画像420dの取り込みを行ったものの、車両410のナンバープレートの画像を取得できないこともあり、この場合、第2の識別カメラを介して観察された車両の特徴を用いて、範囲410cの周囲の重複範囲430c内で観察された車両が車両410であることを確認する。このことは、車両410が最初の識別カメラから離れて動いた時に車両410の追跡に使用されるのが目的地カメラであるか、それとも識別カメラであるかは重要でないことを示している。これらのカメラは、このような追跡に関連して使用される場合、広く「追跡カメラ」と呼ばれる。
第3の目的地カメラは、時刻t5において、410dで示す位置にある車両410の別の目的地画像420d’を取り込む。ほぼ時刻t5において、第4の目的地カメラが、(例えば、ほぼ位置410dにおける)重複範囲430d内にある車両410の目的地画像420eを取り込む。いくつかの実施形態では、第3の目的地カメラと第4の目的地カメラが同期することにより、画像420d’及び420eの両方が基本的に同時刻t5に取り込まれる。重複範囲430dは、目的地画像420eの視野に重複する目的地画像420d’の視野に対応する。両画像420d’及び420eでは、車両410が重複範囲430d内に存在する間に車両410の画像が取り込まれている。
サーバシステム140は、第3の目的地カメラによって取り込まれた(識別画像420d’などの)1又はそれ以上の目的地画像に基づいて、車両410の複数の特徴Cdを特定する。上述したように、Cdには、データベース141に記録されている車両410の不変特徴を含めることができる。サーバシステム140は、目的地画像420e、及び場合によっては第4の目的地カメラによって取り込まれた他の目的地画像に基づいて、車両410の複数の特徴Cd’を特定する。次に、サーバシステム140は、Cd’がCdに対応するかどうかを判定する。Cd’がCdに対応すると判定された場合、サーバシステム140は、車両410が第4の目的地カメラによって時刻t5に観察されたことを一意の識別子に関連付けてデータベース141に記録する。別の実施形態では、サーバシステム140が、車両410が第4の目的地カメラによって時刻t5に観察されたことを代わりに揮発性メモリに記憶し、識別画像420を取り込んだ識別カメラ以外の識別カメラから取得された識別画像を介して車両410がサーバシステム140によって識別される前に車両410が目的地を使用したという判定の後に、このような情報をデータベース141に記録する。
図4に示す画像420eの視野に関連して、サーバシステム140には、(時間単位料金で使用できる駐車スポットなどの)4つの適当な目的地450a〜450dが指定されている。時刻t6において、車両410が位置410eに存在する時点で、第4の目的地カメラによって目的地画像420e’が取り込まれる。サーバシステム140は、目的地画像420e’に基づいて、目的地450bとして指定された矩形領域内に車両410が存在すると判定する。時刻t7において、車両410が位置410eに留まったままの状態で、第4の目的地カメラによって目的地画像420e’’が取り込まれる。サーバシステム140は、目的地画像420e’’に基づいて、目的地位置450bとして指定された矩形領域内に車両410が存在すると再び判定し、従って車両410が時刻t6から目的地450bを使用し始めたと判断して、この情報をデータベース141に記録する。時刻t8において、車両410が目的地450bから出た時点で、第4の目的地カメラによって目的地画像420e’’’が取り込まれる。サーバシステム140は、目的地画像420e’’’に基づいて、目的地450bとして指定された矩形領域内にもはや車両410が存在しないと判定し、従って車両410が時刻t8に目的地450bの使用を終了したと判断する。サーバシステム140は、例えば目的地450bの時間毎の使用料金などの、時刻t6〜t8における目的地450bの使用に適用可能な制約に関する情報に基づいて、この目的地450bの使用に対する請求をエンドユーザの口座に行ったり、又は目的地450bの不正使用に対する罰金を課したりなどの動作を開始することができる。
サーバシステム140は、車両が目的地を使用していると最初に判断した場合、目的地を使用している車両を正しく識別するようにも構成され、その後に識別カメラを介して車両識別符号を取り込むことができる。この状況は、例えば、車両が識別カメラの近くを通過した時に車両のビューが遮られた場合、或いはサーバシステム140の再起動によって車両の識別が予め行われなかった場合に生じることがある。一例として、時刻t1よりも前の時刻t0に、最初に第4の目的地カメラが、車両440が目的地450cを使用していると判断したが、車両の440の識別符号を獲得できなかった場合、車両440に一時的な一意の識別子が割り当てられ、この一時的識別子に関連してデータベース141にエントリが記録される。車両440の一連の車両特徴は、車両440が目的地450cを使用している間、並びに車両440が重複範囲430d、430c、430b及び430aを通過した時に特定することができ、これらの一連の特徴の対応付けを、上述した方法と同じ方法で行い、一時的識別子に関連する同じ車両440が依然として観察されていると判断してこれを記録する。車両440が重複範囲430a内に存在する間に第1の識別カメラによって観察されると、サーバシステム140は、車両440の正しい一意の識別子を特定することができる。この時点で、以前に一時的識別子の下でデータベース141に記録されていた記録を修正し、又は目的地450cの使用が識別子に正しく関連付けられた車両440の正しい一意の識別子の下で再び記憶することができる。時刻t0の後に車両440の識別符号を取得するための別の機構は、車両440が目的地450cを使用している間にモバイル装置150を派遣して車両440の1又はそれ以上の識別画像を取り込むことである。車両440による目的地450cの使用が、目的地450cの使用に関連する制約に抵触すると判定される場合、モバイル装置150の派遣を高優先度で指定することができる。
サーバシステム140は、識別カメラ及び目的地カメラから画像を受け取り、駐車車両の識別情報を挿入する。次に、サーバシステム140は、API(アプリケーションプログラミングインターフェイス)を介して第三機関の駐車料金支払システムから(以下に限定されるわけではないが、支払済み駐車の継続時間及び期限切れ時刻などの)駐車料金支払情報を検索することができる。車両の駐車状況が未払い又は期限切れのいずれかであると判定された場合、サーバシステム140は、APIを介してこの情報を第三機関の駐車料金支払システムに送信する。この時、第三機関の支払システムを運営する駐車施設オペレータは、その標準作業手順書(SOP)に従って(以下に限定されるわけではないが、駐車違反切符を郵送すること、車両に車輪止めを装着すること、或いは繰り返しの又は深刻な駐車違反時には車両を牽引することなどの)駐車違反に対する対処を行うことができる。
サーバシステム140による車両検出は、(1)ビデオフレーム内の車両の存在及び位置を検出すること、(2)動いている車両と止まっている車両を区別すること、(3)特定の検出車両が駐車スペース又は駐車禁止範囲などの目的地を使用しているかどうかを識別すること、(4)車両が目的地を使用し始めた時点又は立ち去った時点を特定すること、(5)車両が1つの追跡カメラの視野から別の視野追跡カメラに移動した時にこの車両を追跡し、この追跡においてエラーが生じたと判断された場合には例外を挙げること、などの複数の機能を実行するように構成することができる。ある実施形態では、サーバシステム140を、特定の車両が目的地にアクセスし、又は目的地を使用するための適切な指標を表示しているかどうかを識別するように構成することもできる。このような指標の例としては、以下に限定されるわけではないが、障害者用駐車ハンガー又はステッカー、又は「居住者専用」駐車位置の使用が許可されている旨を示す駐車ハンガー又はステッカーが挙げられる。カメラは、このような指標の画像を鮮明に取り込むようにズームインすることができる。ある実施形態では、ナンバープレートなどの車両識別子を用いて、目的地の適切なアクセス又は使用を判断し、別個の指標の必要性を排除することができる。
ある実装例では、サーバシステム140を、その識別カメラ及び目的地カメラのためのタスクを、スレッドを用いて実行するようにプログラムすることができる。例えば、「video_receiver」スレッドは、識別子又は目的地カメラからのビデオ及び/又は画像ストリームの受信に対処して、未加工のビデオ及び/又は画像情報を記憶することができる。このスレッドは、1つのビデオ及び/又は画像ストリーム、或いは複数のビデオ及び/又は画像ストリームにつき1つのスレッドとすることができる。このスレッドのための設定可能な選択肢は、(1)ファイルに記憶、(2)メモリに記憶、(3)メモリ及びファイルに記憶、(4)ビデオデータの保管時間(例えば、4時間)を含むことができる。別の例は、車両の色、形状、場所、車線位置、移動速度/方向、車両位置がハンドオフゾーン内に存在するかどうか(及びどの車両か)、カメラの識別符号、を検出してこのような情報をデータベース141に記憶するためのスレッドである。このスレッドは、各複数のビデオフレームを分析して、最新の位置及び車両の移動速度/方向を特定し、このような情報をデータベース141に記憶する。このスレッドは、1つのビデオ及び/又は画像ストリーム、或いは複数のビデオ及び/又は画像ストリーム毎に1つ存在することができる。別の例は、ハンドオフゾーンを通って出てきたものとして検出された特定の車両が近くのカメラによって検出されたことを確認するスレッドである。この確認は、特定のカメラのデータベース141を見直すことにより、例えばどのハンドオフゾーン内で車両が検出されたか、及び/又は検出された車両の移動方向に基づいて行うことができる。このスレッドは、1つのビデオ及び/又は画像ストリーム、或いは複数のビデオ及び/又は画像ストリーム毎に1つ存在することができる。別の例は、車両がある目的地において止まったままであること、及び目的地の使用を開始した時点又は立ち去った時点によって、車両がその目的地を使用しているかどうかを判定するためのスレッドである。このスレッドは、1つのビデオ及び/又は画像ストリーム、或いは複数のビデオ及び/又は画像ストリーム毎に1つ存在することができる。
当業では、ビデオフレーム内における車両の存在を検出するために使用することができる多くのマシンビジョン技術が周知である。例えば、車両の存在を検出するために使用できる様々な既知のエッジ検出アルゴリズムが存在する。一例として、あるアルゴリズムは、車両と背景の色の違い、及び全体形状のサイズがズームレベル及び/又は視野内の位置を考慮して予想される最小車両サイズよりも大きいかどうかに基づいて車両の存在を検出することができる。例えば、このアルゴリズムは、ビデオストリームスナップショット内の画素の色を互いに比較することができる。画像は、消火栓、歩行者、芝生、道路標識及び道路塗装などの様々な非車両物体を含む可能性があるので、このアルゴリズムは、(一致すると見なされる色のバリエーション範囲を構成可能な)類似色の画素グループを検出することができる。全体形状が最小車両サイズよりも大きいかどうかを判定するためには、その形状の画素の数及び位置を使用する。このアルゴリズムは、例えば鏡面反射又は強調によって生じる可能性がある、形状の「穴」又は不完全性にさらに対処することができる。また、このアルゴリズムは、それぞれの最小サイズのいくつかの形状が互いに特定の距離内に存在するかどうかを判定することもできる。これらの形状は、例えば、通常は同じ色であるボンネット、屋根及びトランク部分に対応することができる。
車両と背景の間に不十分なコントラスト又は色の違いが存在する場合には、境界条件が発生して検出が上手くいかないことがある。例えば、黒いアスファルトと黒い車両である。この境界条件に対処するために、カメラハードウェア及び/又はアルゴリズムにさらなる微調整を導入することができる。例えば、可視光及び赤外線撮像の両方を行うカメラを用いて、目的地を使用し始めた車両の熱署名を取得することができる。この例では、たとえ車両の色と背景の色が両方とも黒であっても、エンジンルームはその周囲と異なる温度プロファイルを有する。さらなる費用対効果分析は、このような方法から得られる利益が増分コストを正当化するかどうかを判定するとともに、赤外線撮像過程によって生じるあらゆる境界条件を考慮することに(カメラによって取り込まれた可視光などによって)十分に対処することができる。
単一の画像から車両の存在及び多くの特徴を認識することはできるが、例えば車両が動いていないか、それとも止まっているかを判断するには複数の画像が必要であり、従って複数の画像が使用される。一例では、サーバシステム140を、(1)現在の画像内の車両の色及びサイズの特定に基づいて、(例えば、データベース141又はメモリに記憶されているデータを再検討することによって)前回の画像内の対応する一致を発見し、(2)このような一致が発見されたら、ズームレベルのあらゆる変化を考慮して現在の画像と前回の画像の間で画素位置を比較する、ように構成することができる。このような処理に基づいて、以下のシナリオのうちの1つ又はそれ以上を検出することができる。(A)画素の位置が変化しておらず、又は所定の閾値未満しか変化していなかった場合、全ての車両を止まったままであると見なす。このシナリオでは、車両のデータベース141又はメモリ内の既存のエントリに対して日付及び時間の単純な更新が行われる。(B)1又はそれ以上の車両に関連する画素が新たな位置に存在する場合、1又はそれ以上の車両が動いたと判定する。サーバシステム140は、これらの車両の移動速度及び移動方向を計算し、この情報及び更新された位置を用いてデータベース141又はメモリを更新することができる。(C)1又はそれ以上の車両が現在の画像から消えた場合、サーバシステム140を、データベース141又はメモリに記録されているこのような車両のためのデータを削除するように構成することができる。(D)1又はそれ以上の車両が現在の画像に新たに出現した場合、この新たな車両に関連するデータをデータベース141又はメモリに記録することができる。ある実施形態では、サーバシステム140が、新たな車両の1つが、画像から消えたと最近判定されていた車両に対応すると判定することができ、この車両のビューを一時的に妨害されていたものとして処理することができる。(E)現在の画像から全ての車両が消えた場合、前の間隔からのデータベース141又はメモリからのデータを、これらのデータ内の車両に関連して削除することができる。しかしながら、上述したように、識別カメラとの間で車両追跡を実行するために一部のデータは保存しておくことができる。
ある例では、目的地範囲を使用している車両を識別するためのアルゴリズムが、基本車両検出アルゴリズムに類似する。サーバシステム140は、車両の検出が完了すると、車両に対応する画素位置が、事前マッピングした視覚領域のいずれかを占めているかどうかを評価する。重複の程度は設定可能とすることができる。ある実施形態では、垂直オフセットを適用して、車高を補償するとともに、目的地カメラと車両の間の駐車車両などの視覚的障害を補償することができる。このような障害は、例えば混雑した駐車区画では頻繁に生じることがある。サーバシステム140は、車両が少なくとも一定時間にわたって止まったままであったかどうかを判定する。車両が少なくとも一定時間にわたって所与の目的地に存在していたと判定されると、車両の識別情報、目的地、及び車両が目的地を使用し始めた時間及び日付をデータベース141に、好ましくは不揮発性記憶装置に記録する。ある実施形態では、サーバシステム140を、車両が2つの駐車スペースを使用することなどによって複数の目的地を占有している時間を検出するように構成することができる。これにより、例えば1又はそれ以上の駐車違反切符を発行し、又は使用料を割り増しすることができる。サーバシステム140は、車両がいつ目的地から立ち去ったかを特定し、対応する情報をデータベース141に記録することもできる。また、サーバシステム140は、最大駐車時間が2時間の駐車スポット、指定の街路清掃時間後に車両の使用に利用できない目的地、又は車両に提供される資金の枯渇に関連して生じ得るような、車両による目的地の使用が目的地の使用時間を間もなく超過すること、又はいつ超過したかを特定するように構成することもできる。
ある実施形態では、サーバシステム140を、一度に複数の車両によって使用できる1又はそれ以上の複数車両用目的地を認識するように構成することができる。例えば、サーバシステム140を、車両の「ロングブロック」駐車の追跡をサポートするように構成することができ、この場合、例えば、街区の縁石の長さに沿って、単一のペイ・バイ・スペースユニット、ペイ・アンド・ディスプレイユニット、又はペイ・バイ・プレートユニットによって制御される駐車区域は設けられているが、この駐車区域が明確な駐車スペースに分割されておらず、代わりに、車両は、(以下に限定されるわけではないが、荷積み区域及び私道などのいくつかの「駐車禁止」領域を除く)縁石沿いのあらゆる利用可能なスペースを使用することができる。別の例では、サーバシステム140を、例えば単一のペイ・アンド・ディスプレイユニットによって制御される駐車区画の使用を追跡し、内部の複数の個別に明確化されたスペースは追跡しないように構成することができる。サーバシステム140は、複数車両用目的地の使用をスペース毎に追跡するように構成しなくてもよいが、時間に伴う車両の使用状況を追跡し、複数車両用目的地の使用許可時間を超えた車両に違反切符を貼り付けることなどの駐車取締作業を行うために、複数車両用目的地内の車両の位置を特定して記録することができる。ある実施形態では、複数の車両によって使用できたはずのスペースの使用にはより多くの駐車料金及び/又は罰金を課すことができるので、サーバシステム140を、複数車両用目的地を使用している車両の長さを特定するように構成することができる。本出願において説明するサーバシステム140を使用する1つの利点は、従来の制御された駐車区画では、駐車場の使用を制御するために単一の入出地点に依拠することがあるが、カメラを用いた追跡では、車両をフェンスの壁によって取り囲む必要が無いので、複数の入口及び出口を有する「オープン」な設計の駐車区画が可能になる点である。
ある実施形態では、複数の不連続な目的地又は複数車両用目的地を単一の複数車両用目的地に集約することができる。この実施形態は、構成する2つの目的地が異なる目的地カメラによってカバーされる場合を含むことができる。この実施形態は、例えば複数車両用目的地が、街区の長さに沿った様々な「駐車禁止」目的地によって分割される場合に有用となり得る。
ある実施形態では、複数車両用の場所の制約範囲を「分割」するように、複数車両用目的地に重複する「駐車禁止」などの制約された目的地が存在することができる。例えば、上述した「ロングブロック」のシナリオでは、街区の長さ全体に沿って単一の複数車両用目的地を定め、以下に限定されるわけではないが、ブロックの長さに沿った荷積み区域及び私道などの、街区に沿った様々な部分に「駐車禁止」目的地を重複させることができる。サーバシステム140によって「駐車禁止」目的地の1つを使用しているものとして検出された車両は、より大きな複数車両用目的地内に存在していたにも関わらず、サーバシステム140によって駐車違反を犯したと判断される。
ある実施形態では、コンピュータベースの設定ユーティリティを設けることができる。例えば、設定ユーティリティを用いてモバイル装置150又は手動再確認システム180を設定し、現場設定又は遠隔設定を可能にすることができる。例えば、車両の識別、追跡及び/又は検出のためのカメラ設定の効果に関するフィードバックを提供するために、カメラの設置を行う人物がモバイル装置150を使用することができる。この代わりに、又はこれに加えて、手動再確認システム180の使用中に設定不具合が識別された結果として、この手動再確認システム180を介して特定のシステム又はカメラ設定の変更を行うこともできる。ある実施形態では、ウェブブラウザを介してユーザインターフェイスを利用可能にすることができる。設定ユーティリティは、限定するわけではないが、以下のような1又はそれ以上の機能を提供することができる。
・所与のカメラに関する車両検出の較正を行うためのグラフィカルユーザインターフェイス(GUI)を提供すること。
・連続的なカメラの位置合わせを確実にするためのGUIを提供すること。
・最小車両寸法を指定するためのGUIを提供すること。このGUIは、画素に関連することができ、ズームレベルに合わせて調整することができる。
・別のカメラの視野に重複するカメラの視野の一部を識別するためのGUIを提供すること。
・カメラの位置合わせを行うための、及び/又はカメラの向き及び/又は位置合わせを指定するためのGUIを提供すること。
・目的地を事前マッピングするためのGUIを提供すること。
・車両駐車違反と見なされる状況を定義すること。このような状況は、所与の領域又は場所に特定のものとすることができる。
・様々な駐車違反の結果を設定すること。例えば、違反に関する情報を単純に画面上に表示することも、登録所有者情報を取得して違反切符又は請求書を発行することも、或いは警告を印刷して車両に配置しておくこともできる。
・郵送又はそれ以外の方法で駐車違反切符を発行する前の、国営の自動車代理店などに新たな自動車所有者登録情報要求を行わなければならない期限を設定すること。
・その他のシステム設定パラメータを再検討して修正するためのGUIを提供すること。
GUIは、所与のカメラの車両検出の較正を行うために、2つの画像フィードを提示して、管理者が各画像フィードにルーラを重ねられるようにする。ズームレベルを修正する制御ができるように、もしあればズームレベルをGUIの一部として表示することができる。2つの画像フィードは、視野が重複する所与のカメラと別のカメラからのものである(このようなカメラは互いに隣接していることが多い)。較正のためには、画像を同時に取り込んで、車両が2つのカメラの視界の重複範囲を通過した時などにおける各ビデオフィード内の車両の位置を再確認できるように、2つのカメラの画像の取り込みを同期させることが好ましい。設定ユーティリティは、GUIを通じて、一時停止、再生、巻き戻し、早送り、コマ送り、コマ戻し及びフレーム移動機能などの時間的画像制御機能を提供することもできる。
較正では、設定ユーティリティを用いて、一方又は両方の画像フィード内で既知の型式及びモデルの1又はそれ以上の車両(この車両は、例えば設定ユーティリティを操作する技術者が使用している車両を含むことができる)を発見し、GUI内に1又はそれ以上のルーラを位置付けて、測定中の車両の既知の寸法値を参照することによってルーラが正しい車両の長さ、幅及び/又は高さを示すようにすることができる。ある実施形態では、GUIによって提供されるルーラ機能が、カメラによって導入された(例えば、カメラモデルに基づく既知の特徴を有することがある)視覚的歪み、又は取り込み画像の奥行きなどの要因に起因する非線形性を補償するように構成される。例えば、画像の右手側に取り込まれた車両の方が画像の左手側に取り込まれた車両よりもカメラから離れている場合には、距離の単位を示すルーラの線の間隔を画像の右手側において狭めることができる。設定ユーティリティは、画像のマーカーを識別して(他のマーカー及び/又はカメラに対する)位置及び/又は距離を示すことにより、所与のカメラのこのような非線形性を現場で較正できるように構成することができる。このようなマーカーは、一時的なものとすることも、或いは場合によっては、技術者が後で再較正を行えるように恒久的なものとすることもできる。
また、設定ユーティリティを用いて、2つの画像フィードにおける移動方向の関係性を指定するともに、2つの画像フィードにおける共通点に対応する画素又は画像位置を識別することもできる。ある実施形態では、画像フィードの各々における車線/経路に関して移動の位置及び方向を指定して、(例えば、車両が同じ車線/経路内の1つのカメラの視野から別のカメラの視野にいつ通過したかを後で特定できるように)これらの2つの画像フィード間で相関付けることができる。これらの特徴の指定は、GUIを介して、例えば車線/経路の境界を示す画像フィード上に線又はその他の指標が重なり合うようにすることによって行うことができる。図6A及び図6Bに、例示的なGUIの態様を示す。図6Aには、第1のカメラからの画像600aが表示されたGUIの一部を示す。図6Bには、第2のカメラからの画像600bが表示されたGUIの一部を示す。画像600a及び600bの視野は重複しており、重複範囲は、範囲640a及び640bを含む。画像600a及び600bには2つの車線/経路も取り込まれており、図6Aでは車線/経路611a及び612a、図6Bでは車線/経路611b及び612bとして表記している。この図6A及び図6Bに示す特定の例では、車線/経路611a及び611bにおいて交通の流れが(一般には角度θに対応する)同じ方向であるが、同様の例では、車線/経路611a及び611bにおいて交通の流れが逆方向の場合もある。画像600a及びbには、それぞれA、B及びCで表記する3つの車両の画像も取り込まれている。図6Aでは、車線/経路境界が、破線の車線/経路境界指標621a、622a及び623aによって示されており、これらの指標は、GUIの使用によって追加し、配置し、移動させ、ラベル付けし、別様に識別することができる。図6Aには、GUIを用いて、車線/経路境界指標621aと623aの間の車線/経路611a、及び車線/経路境界指標622aと623aの間の車線/経路612aという2つの車線/経路が示されている。図6Aに示す特定の例では、車線/経路611a及び612aにおいて交通の流れが同じ方向θであり、車線/経路境界指標621a及び622aは(同様の破線で示す)第1のタイプであり、車線/経路境界指標623aは第2のタイプであって、車線/経路境界指標621aと622aの間の一方向の交通の流れの範囲が2つの車線/経路611a及び612aに分かれていることを示す。設定ユーティリティは、例えば、図6Bに示す車線/経路611b及び612bなどの、他のカメラに関連して識別される車線と相互参照できるように、指定された車線の識別子を自動的に提供又は提案するように構成することができる。図6Bでは、設定ユーティリティが、車線/経路611b及び612b、並びに上述した図6Aの同等物に対応する車線/経路境界指標線621b、622b及び623bを用いて、車線/経路識別のための同様の機能を提供する。
ある実施形態では、各車線/経路をいくつかの小さなセグメントに分割することができる。これらのセグメントは、例えばセグメントを示す画像フィード上に線又はその他の指標が重なることを可能にすることにより、GUIを介して指定することができる。ある実施形態では、重なり合った線を用いて、画像フィード内の非線形性を自動的に特徴付ける支援を行うことができる。図6Aに、車線/経路セグメント指標631a及びその他の同様のラベル表示していない車線/経路セグメント指標を用いた例を示している。設定ユーティリティは、以前に指定された車線/経路境界指標に基づいて、提案される車線/経路セグメント指標を自動的に生成するとともに、GUIを介して、車線/経路境界指標を望むように調整するためのツールを提供するように構成することができる。また、図6Aに示す車両A、B及びCなどの車両画像を含めることにより、技術者が車線/経路セグメント指標を正確に配置又は調整する支援を行うことができる。図6Bには、車線/経路セグメント指標631b、及び上述した図6Aの同等物に対応するその他の同様のラベル表示していない車線/経路セグメント指標を示している。
設定ユーティリティは、GUIを介して、第2の画像ストリームのそれぞれの範囲と視野が重なり合った画像ストリームの範囲を指定するための同様の機能を提供することもできる。これらの範囲は、車両の検出を1つの追跡カメラから別の追跡カメラに「ハンドオフ」するために使用されるので、「ハンドオフゾーン」と呼ばれる。例えば、図6A及び図6Bには、視野が重なり合ったカメラによって取り込まれた画像を示しており、ハンドオフゾーン640aの視野がハンドオフゾーン640bの視野に重なる。GUIは、図6Aではハンドオフ境界指標651a及び652aの、図6Bではそれぞれのハンドオフ境界指標651b及び652bの指定を可能にするように構成することができる。また、指定されたハンドオフゾーンは、図6A及び図6Bに示すハンドオフセグメント指標611a及び611b(及びその他のラベル表示していないハンドオフセグメント指標)を用いて、いくつかの小さなセグメントに分割することもできる。設定ユーティリティは、以前に指定されたハンドオフ境界指標に基づいて、提案されるハンドオフセグメント指標を自動的に生成するとともに、GUIを介して、ハンドオフ境界指標を望むように調整するためのツールを提供するように構成することができる。また、図6Aに示す車両A、B及びCなどの車両画像を含めることにより、技術者がハンドオフセグメント指標を正確に配置又は調整する支援を行うことができる。ある実施形態では、設定ユーティリティを、ハンドオフ境界指標651a及び652a間の距離を求め、この距離が望ましい最低距離未満ある場合にはGUIのユーザに警告するように構成することができる。
図6A及び図6Bに示すGUIは、GUIによって提供される指標を単純な線として図示し記述しているが、設定ユーティリティ及びGUIは、以下に限定されるわけではないが、曲線及びフリ−ハンド線などのさらに複雑な形状の特徴の指定を可能にすることもできる。また、車線/経路境界指標623aなどの、第1のカメラに関連して指定される指標が、車線/経路境界指標623bなどの、別のカメラに関連する同等の指標を有する場合、GUIを用いてこれらの同等の指標をリンクさせることができる。ある実施形態では、以前に指定された指標、既知のカメラ位置、既知のカメラ配向、並びに車線/経路の数及びこれらの車線/経路内の交通の流れの向きなどの、カメラに近い交通の流れの既知の態様などの情報に基づいて、このようなリンクを自動的に決定又は提案することができる。
ある実施形態では、カメラがズーム及び/又はパン/チルト能力を有する場合、設定ユーティリティを、様々なズームレベル又は配向のカメラを用いて取り込まれた画像内における様々な指標特徴の指定を可能にするように構成することができる。この追加情報を用いて、カメラの全体的な視野をさらに十分に指定することができる。技術者が、カメラの視野を指定するために指標及び/又はルーラをどのように使用するかに納得すると、この情報及び/又はこの情報から得られた他の情報を、例えばサーバシステム140による車両追跡で使用できるようにデータベース141に記憶することができる。
設定ユーティリティは、ビデオカメラの連続位置合わせを行うためのGUIを提供するように構成することができる。この機能は、上述した車線/経路境界を指定するためのGUIに含まれるさらなるユーザインターフェイス要素を介して提供することができる。ビデオカメラの連続位置合わせは、最初のカメラハードウェア取り付け過程中に、或いは既存のカメラハードウェアを後から更新する場合に、カメラがパン、チルト及び/又はズーム(PTZ)機能を備えていれば、図4、図6A及び図6Bに示す重複部分などの十分な重複部分がカメラ間の視界内に確実に存在するようにカメラのパン、チルト及び/又はズーム設定を調整及び/又は較正する必要があるという事実に関するものである。技術者は、GUIを見直して、1対のカメラによって十分なサイズ及び/又は継続時間のハンドオフゾーンが提供されているかどうかを判定することができる。提供されていない場合、パン、チルト及び/又はズーム設定の変更を要求することができ、或いはカメラの物理的な取り付け位置を完全に変更する必要が生じることもある。
設定ユーティリティは、駐車スペース及び「駐車禁止」区域などの目的地の事前マッピングを行うためのGUIを提供するように構成することができる。GUIは、画像フィードを提示し、技術者が、例えば画像フィード上にグレーアウトされたポリゴンを重ね合わせることを可能にする。別の非限定的な例では、駐車スポット#123を、所与のズームレベル及び/又はPTZ配向の特定の目的地カメラによって取り込まれた20画素の集合体にマッピングすることができる。GUIは、カメラの視野内の目的地の位置及び規模を示すように、以下に限定されるわけではないが、このようなポリゴンの移動、サイズ変更及び回転を含む動作を提供するように構成することができる。カメラがPTZ能力を有する場合には、PTZ制御を行うことができる。この機能は、上述した車線/経路境界を指定するためのGUIに含まれるさらなるユーザインターフェイス要素を介して提供することができる。GUIは、例えばサーバシステム140の様々な態様において使用するための共通目的地識別子を提供するために使用できる識別子を目的地に割り当てるインターフェイスを提供することもできる。GUIは、目的地の様々な特徴を指定できるようにするインターフェイス要素を提供することもできるが、直接的な人間の作業を最小限に抑え、設定ユーティリティ又はサーバシステム140の他の態様を利用してこのような特徴を管理し、割り当て、及び/又は修正することが好ましい。
ある実施形態では、設定ユーティリティを、上述した複数車両用目的地の事前マッピングを単一車両用目的地の事前マッピングのための上記説明とほぼ同様に実行するためのGUIを提供するように構成することができる。設定ユーティリティは、複数の目的地又は複数車両用目的地が単一の目的地に集約されるのを可能にするように構成することができる。例えば、構成要素である目的地の各々に、これらが複数車両用目的地を形成していることを示すための共通識別子を割り当てることができる。設定ユーティリティは、制限された目的地が複数車両用目的地に重なり合うことを可能にして、以下に限定されるわけではないが、荷積み区域及び私道などの、駐車制限を受ける部分を広範にわたる範囲から「区分け」するように構成することができる。
設定ユーティリティは、何が駐車違反を構成するかを指定するためのGUIを提供するように構成することができる。第1の例では、GUIを用いて、車両が目的地の使用に関する制限に違反していると見なす前に車両が目的地を使用できる時間を定める支払猶予期間を指定することができる。例えば、車両が駐車メータの地点で停車した時には、車両のドライバーが車両を離れて駐車料金を支払うのに十分な支払猶予期間を与えることが妥当である。異なるタイプ又はグループの目的地には、異なる期間を指定することができる(例えば、「駐車禁止」ゾーンでは、支払猶予期間を短く又はゼロにすることができる)。第2の例では、GUIを用いて、車両が違反であると見なす前に、面積又は範囲カバー率から見て車両がどれほど目的地に重なっているのかに関して車両の重なり量を指定することができる。第3の例では、GUIを用いて、例えば障害者用駐車スペースの使用、居住者専用の駐車、或いは許可証又はステッカーの表示を必要とするその他の駐車に関連する規則を含む駐車許可規則を指定することができる。GUIは、以下に限定されるわけではないが、色、許可証又はステッカー上に描かれている画像、及び許可証又はステッカーの(シリアルナンバーなどの)識別子の位置などの、必要な許可証又はステッカーの特性及び特徴を識別するためのインターフェイスを提供することもできる。第4の例では、GUIを、今月を示すタグを期限切れと見なすかどうかなどの、何が期限切れのナンバープレートタグを構成するかを特定するための規則を定めるように構成することができる。
設定ユーティリティは、目的地の車両不正使用の結果を指定するためのGUIを提供するように構成することができる。例としては、以下に限定されるわけではないが、ナンバープレート情報を画面表示すること、ナンバープレートを検索して登録所有者の名前及び住所を取得すること、取締官を派遣すること、目的地を不正使用している車両にレーザーによる照射を行うこと、ファイル上のクレジットカード又は口座に駐車違反の罰金を課すこと、及び銀行又はその他の金融口座から駐車違反の罰金を引き落とすことが挙げられる。
設定ユーティリティは、検出された駐車違反の結果を修正する対象になる特定の車両を指定するパラメータを受け取って記録するように構成することができる(例えば、警察車両は、指定の違反が適用されないものとして識別することができる)。例えば、このような車両は、ナンバープレート番号によって識別することも、或いはステッカーなどの指定された識別子を有することもできる。
ある実施形態では、サーバシステム140を、商業的データベース又は自治体データベースを通じて取得できる、及び/又は駐車場オペレータが提供できる既存の街路情報及び/又は駐車情報を取得して、目的地及び車線/経路情報を自動的に決定するように構成することができる。ある実施形態では、サーバシステム140を、様々な識別カメラ及び目的地カメラの位置及び配向を示す情報に基づいて、目的地及び/又は車線/経路を自動的に事前マッピングするように構成することができる。ある実施形態では、サーバシステム140を、以下に限定されるわけではないが、識別子、場所(例えば、緯度/経度又は所在地住所)、目的地の使用料、並びに本出願で説明した目的地の時間ベース、日付ベース及びその他の制約などの、データベース141に記録された目的地及び/又は車線/経路の特徴を記録及び/又は更新するように構成することができる。ある実施形態では、サーバシステム140が、目的地情報及び/又はアップデートを駐車プロバイダがさらに容易にまとめてアップロードできるようにするAPIを提供することができる。
別の実施形態では、図1に示すサーバシステム140及びその他の要素が、APIを介して第三機関の駐車料金支払システムと統合する必要がないターンキープラットフォームの形をとる。このような実施形態では、ターンキープラットフォームの一部が、支払ステーション/装置、及び郵送用の駐車違反切符を生成する装置で構成される。
ある実施形態では、オンサイト支払システム160が、ターンキープラットフォームペイ・バイ・フォン機能を含むことができる。最終的に、エンドユーザは、特定のIVR(双方向音声応答)システムによる電話回線に電話し、目的地が道路脇の駐車メータに関連しているか、ペイ・バイ・スペースの駐車スペースに関連しているか、それとも駐車区画に関連しているかに関わらず、目的地識別子又は車両のナンバープレート番号と駐車時間とを入力することによって駐車料を支払うことができる。
ターンキーペイ・バイ・フォンモジュールは、エンドユーザが電話(通常は携帯電話)を使用して駐車料金を支払えるようにする。ターンキーペイ・バイ・フォン機構は、サーバシステム140とのデータベースレベルでの統合を可能にする。データベースレベルでの統合は、より高い柔軟性及び速度を提供するので、APIレベルでの統合よりも優れている。
ターンキーペイ・バイ・フォンモジュールは、ユーザが電話を通じて情報を入力した1又はそれ以上のDTMFトランシーバからデータを受け取る。ターンキーペイ・バイ・フォンモジュールは、正しく動作するためにサーバシステム140からデータを受け取る必要がない。ターンキーペイ・バイ・フォンモジュールは、手動で支払われた駐車料金を検証するためのデータをモバイル装置150に出力するとともに、自力取締のためのデータをサーバシステム140に出力するように構成することができる。全ての自力取締データ処理は、サーバシステム140において行われる。
ある実施形態では、オンサイト支払システム160が、ターンキープラットフォーム上にペイ・オンラインを含むことができる。最終的に、エンドユーザは、ウェブサイトを訪問して、目的地が道路脇の駐車メータに関連しているか、ペイ・バイ・スペースの駐車スペースに関連しているか、それとも駐車区画に関連しているかに関わらず、目的地識別子又は車両のナンバープレート番号と駐車時間とを入力することにより、駐車料金を支払うこと又はこれまでの履歴を見ることができる。この機能は、スマートフォンなどの他のオンラインルートにも拡張され、将来的には自動車内のインターネット対応メディアセンタにも拡張される。
ターンキーペイ・オンラインモジュールは、エンドユーザがインターネットを通じて情報を入力したデータをオンラインで受け取る。ターンキーペイ・オンラインモジュールは、正しく動作するためにサーバシステム140からデータを受け取る必要がない。ターンキーペイ・オンラインモジュールは、手動で支払われた駐車料金を検証するためのデータをモバイル装置150に出力するとともに、自力取締のためのデータをサーバシステム140に出力する。全ての自力取締データ処理は、サーバシステム140において行われる。
ある実施形態では、オンサイト支払システム160が、QRコードを有するペイ・アンド・ディスプレイ機構を含むことができる。QRコードは広まってきており、従ってスマートフォンを大いにサポートする。さらに、QRコードは、通常はペイ・アンド・ディスプレイチケットに含まれる全ての関連情報(以下に限定されるわけではないが、駐車、駐車期限、支払額、日付及び時刻など)を容易に保持することができる。ターンキーペイ・アンド・ディスプレイ機構は、エンドユーザが駐車料金を支払い、QRコード付きのディスプレイチケットを車両のダッシュボード上に置いておくことを可能にする。ターンキーペイ・アンド・ディスプレイ機構は、サーバシステム140とのデータベースレベルでの統合を可能にする。データベースレベルでの統合は、より高い柔軟性及び速度を提供するので、APIレベルでの統合よりも優れている。
ターンキーペイ・アンド・ディスプレイ機構は、内蔵キーパッド、硬貨受け入れ機、クレジットカードリーダ、及びプリンタを介してエンドユーザから支払いを受け取る。文字/グラフィックLCDディスプレイも存在する。ターンキーペイ・アンド・ディスプレイ機構は、正しく動作するためにサーバシステム140からデータを受け取る必要がない。ターンキーペイ・アンド・ディスプレイ機構は、手動で支払われた駐車料金を検証するためのデータをモバイル装置150に出力するとともに、自力取締のためのデータをサーバシステム140に出力する。全ての自力取締データ処理は、サーバシステム140において行われる。
ある実施形態では、オンサイト支払システム160が、ペイ・バイ・スペースターンキー機構を含むことができる。ペイ・バイ・スペースは、稼働歴の長いペイ・アンド・ディスプレイに比べてますます広まりつつある。ペイ・バイ・スペースを用いた駐車場運営は、印刷された使用期限を手動でチェックするために駐車取締職員が各車両まで歩いて行ってフロントガラスに身を乗り出す必要がないので、一般的に効率性が高い。代わりに、駐車取締職員は、パトロール車両を運転して、使用中の駐車スペースの料金が支払われているかどうかを遠くから視覚的にチェックすることができる。また、ペイ・バイ・スペースでは、ドライバーが機械で支払いを行った後に自分の車両に歩いて戻ってチケットを表示する必要がなく、代わりにそのまま自分の目的地に向かうことができるので、ユーザ体験が向上する。
ターンキーペイ・バイ・スペース機構は、内蔵キーパッド、硬貨受け入れ機、クレジットカードリーダ、及びプリンタを介してエンドユーザからの支払いを受ける。文字/グラフィックLCDディスプレイも存在する。ターンキーペイ・バイ・スペース機構は、正しく動作するためにサーバシステム140からデータを受け取る必要がない。ターンキーペイ・バイ・スペース機構は、手動で支払われた駐車料金を検証するためのデータをモバイル装置150に出力するとともに、自力取締のためのデータをサーバシステム140に出力する。全ての自力取締データ処理は、サーバシステム140において行われる。
ある実施形態では、オンサイト支払システム160が、ペイ・バイ・プレートターンキー機構を含むことができる。ターンキーペイ・バイ・プレート機構は、内蔵キーパッド、硬貨受け入れ機、クレジットカードリーダ、及びプリンタを介してエンドユーザからの支払いを受ける。文字/グラフィックLCDディスプレイも存在する。ターンキーペイ・バイ・プレート機構は、正しく動作するためにサーバシステム140からデータを受け取る必要がない。ターンキーペイ・バイ・プレート機構は、手動で支払われた駐車料金を検証するためのデータをモバイル装置150に出力するとともに、自力取締のためのデータをサーバシステム140に出力する。全ての自力取締データ処理は、サーバシステム140において行われる。
第三機関の駐車システムとの統合は、サーバシステム140のための要件ではなく選択肢である。例えば単一の供給業者を通じて駐車施設プラットフォーム全体が提供されるターンキー構成では、第三機関の駐車システムとの統合の必要はない。しかしながら、APIを用いた統合アプローチには多くの利点がある。APIは、外部プログラムがホストシステムの営業秘密を一切曝すことなくホストシステム内の情報にアクセスできるように設計された標準的なソフトウェアプログラミングインターフェイスを提供する。このアプローチは、外部システムが、所定の情報セットがホストシステム自体においてどのように収集、記憶又は計算されるかを一切知ることなくこれらの情報を取得できるように、2つのシステムの境界において明確に定められた機能、オブジェクト及び変数を作成することによって実現される。従って、一般に、企業は、他のシステムがその企業の製品又はサーバに接続できるようにAPIを公開することに対する不安がない。データは、XML、JSON、HTML、MIME、又はAPIによってサポートされる他の符号化又は言語に依拠するSSLなどの暗号化機構によってしばしば保護されるネットワークベースの機構を通じ、APIを介して交換することができる。
サーバシステム140とAPIを統合する方法は2つある。まず、サーバシステム140が、第三機関の駐車システムによって公開されているAPIを使用することによって(以下に限定されるわけではないが、支払済みの期間及びスペース番号などの)車両支払情報にアクセスすることができる。サーバシステム140は、既にサーバシステム140が所有している車両検出情報及び車両識別情報と組み合わせて、詳細な駐車違反情報を含む車両ナンバープレートリストを駐車施設オペレータに対して作成するのに必要な完全な情報を有し、又は容易に取得することができる。駐車施設オペレータは、そのSOPに従って、駐車違反チケットを郵送し、車輪止めを設置し、或いは繰り返しの又は悪質な違反者については牽引を行うことができる。
第2の統合方法は、サーバシステム140がその独自のAPIを公開し、従って第三機関の駐車システムが車両検出及び車両識別に関する情報を取得できるようにすることである。第三機関の駐車システムは、既に第三機関の駐車システムが所有している車両支払情報と組み合わせて、詳細な駐車違反情報を含む車両ナンバープレートリストを含め、駐車場オペレータにシームレスな提示を行うことができる。第三機関の駐車システムプロバイダは、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けるために、このアプローチを好むと思われる。
サーバシステム140は、APIを使用することによって、ペイ・バイ・フォン、ペイ・バイ・スペース、ペイ・アンド・ディスプレイ、道路脇駐車メータ(単一スペース又は二重スペース)、及びライブオペレータによるオプションといったタイプの駐車料金支払システムに統合することができる。
ペイ・バイ・フォンの大前提は、(車両のドライバーなどの)エンドユーザが目的地付近に表示された電話番号に電話することである。通常、この電話番号は、自動メニューを通じて発呼者をガイドするIVR(双方向音声応答)を提供する。エンドユーザは、一意の目的地番号の後に、所望の駐車時間、車両のナンバープレート番号及びクレジットカード情報を入力するように促される。
ペイ・バイ・フォンは、駐車施設オペレータが、道路脇駐車メータ、ペイ・バイ・スペース及びペイ・アンド・ディスプレイ機構にペイ・バイ・フォン機能を追加する評判の良い「オーバーレイ」支払方式として勢いを増し始めている。一般的動機は、駐車場利益を高める目的で、エンドユーザに別の駐車料金支払方法を提供することである。例えば、エンドユーザがクレジットカードでの支払いを電話で行えるようにするために、従来の道路脇駐車メータ(単一スペース又は二重スペース)にペイ・バイ・フォンを追加することができる。
ある実施形態では、サーバシステム140が、自力駐車取締に使用する駐車料金支払情報をサーバシステム140が第三機関の駐車料金支払システムから抽出するソフトウェアコンポーネントとすることができるペイ・バイ・フォン統合モジュールを含むことができる。ペイ・バイ・フォンのための統合モジュールは、(1)第三機関のペイ・バイ・フォンAPIとの接続を確立するステップ、(2)データ要求を発行するステップ、(3)データを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、第三機関のペイ・バイ・フォンAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)ステップ2〜7を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ(1)に関連して、通常、APIは、APIへの接続を確立できる機構を指定する。ペイ・バイ・フォン統合モジュールは、第三機関のペイ・バイ・フォンAPIが必要とするプロトコルを観察して接続を確立するように構成される。
ステップ(2)に関連して、サーバシステム140は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信(IPC)呼出しなどを介してこの事象をペイ・バイ・フォン統合モジュールにシグナリングし、ペイ・バイ・フォン統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関のペイ・バイ・フォンAPIに発行する。第三機関のペイ・バイ・フォンAPIに送信されるデータは、例えば、(プレート番号及び州/県情報を含む)車両ナンバープレート情報、ペイ・バイ・フォンAPIによって認識された目的地識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、及びその特定の車両が目的地から立ち去った日付/時刻を含むことができる。
ステップ(3)に関連して、ペイ・バイ・フォン統合モジュールは、例えば、支払済み駐車開始日/時刻及び支払済み駐車終了日/時刻を含む情報を第三機関のペイ・バイ・フォンAPIから受け取るように構成することができる。ステップ(5)に関連して、ペイ・バイ・フォン統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
サーバシステム140によって提供されるAPIを統合に使用する実施形態では、通常は既にペイ・バイ・フォンシステムが車両ナンバープレート情報を所持しているので、ペイ・バイ・フォンシステムはサーバシステム140から車両検出情報(実際の車両駐車開始及び終了時刻)のみを取得する。最終的に、ペイ・バイ・フォンシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。
通常、ペイ・バイ・フォンシステム又はそのスタッフは、サーバシステム140によって提供されるAPIを使用することに同意できる時には、一般にサーバシステム140から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号又は目的地番号について特定の車両が特定の目的地を使用した実際の時間を示す実際の車両駐車継続時間が有用なデータである。車両ナンバープレート番号又は目的地番号は、一般にエンドユーザ支払処理の一部として取得されるので、一般にペイ・バイ・フォンシステムは、これらの番号を既に有している。
サーバシステム140によって提供されたペイ・バイ・フォンAPIを介した統合は、2つの選択肢のうちの一方に従うことができる。1つ目は、第三機関の駐車料金支払システムがサーバシステム140に情報をプッシュするデータ流入モデルである。2つ目は、サーバシステム140が全ての関連情報をペイ・バイ・フォンシステムにプッシュするデータ流出モデルである。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流入型ペイ・バイ・フォンAPIを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型ペイ・バイ・フォンAPIを介してサーバシステム140に情報をプッシュする。流入型ペイ・バイ・フォンAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムからデータを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、流入型ペイ・バイ・フォンAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型ペイ・バイ・フォンAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流入型ペイ・バイ・フォンAPIを介して、車両/ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、例えば(プレート番号及び州/県情報を含む)車両ナンバープレート情報、この特定の車両に関連して支払いが受け取られた目的地の識別子(サーバシステム140が内部的に使用する識別子への変換を必要とすることがある)、支払済み駐車開始日/時刻及び支払済み駐車終了日/時刻を含むことができる。ステップ(5)に関連して、サーバシステム140に含まれるペイ・バイ・フォン統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流出型ペイ・バイ・フォンAPIを含むことができ、この場合、サーバシステム140が、全ての関連情報を第三機関のペイ・バイ・フォンシステムにプッシュする。流出型ペイ・バイ・フォンAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムにデータをアップロードするステップ、(4)アップロードされたデータに対する確認応答を受け取るステップ、(5)第三機関の駐車料金支払システムからの「キープアライブ」/「ピン」要求に応答するステップ、及び(6)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型ペイ・バイ・フォンAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流出型ペイ・バイ・フォンAPIを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、特定の車両が目的地の使用を開始した実際の日付/時刻、及び特定の車両が目的地から立ち去った実際の日付/時刻を含むことができる。
別の実施形態では、ペイ・バイ・フォンシステムとサーバシステム140の統合が2ステップで行われる。まず、サーバシステム140が、ペイ・バイ・フォンシステムから提供されたAPIを使用することにより、ペイ・バイ・フォンシステムから(支払済み駐車の開始及び終了時刻、駐車スペース番号、車両ナンバープレート番号などの)車両支払情報を取得する。この段階で、サーバシステム140は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム140が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム140によって提供されるAPIを用いて車両違反データをペイ・バイ・フォンシステムに送信することによって行うことができる。この時、ペイ・バイ・フォンシステムは、(例えば、ペイ・バイ・フォンシステムの業者によって開発されたカスタムソフトウェアアプリケーションを通じて)「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。
この統合方法と、サーバシステム140によって提供されるAPIを介した統合のみに依拠することの大きな相違点は、この統合方法では、ペイ・バイ・フォンシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム140によって提供されるAPIによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。
ペイ・バイ・スペースの前提は、エンドユーザが車両を駐車したら駐車スポットのスペース番号を控えることである。エンドユーザは、ペイ・バイ・スペース機構で駐車料金を支払う場合、区画番号を入力した後に所望の駐車期間を入力する。支払いが完了すると、エンドユーザは車内にチケットを置いておく必要はなく、代わりにそのまま行きたい所に行くことができる。ペイ・バイ・スペースは、道路脇の路上駐車及び路外の駐車区画/駐車場ビルの両方において同様に良好に機能する。
ペイ・バイ・スペースは、稼働歴の長いペイ・アンド・ディスプレイに比べてますます広まりつつある。ペイ・バイ・スペースを用いた駐車場経営は、印刷された使用期限を手動でチェックするために駐車取締職員が各車両まで歩いて行ってフロントガラスに身を乗り出す必要がないので、一般的に効率性が高い。代わりに、駐車取締職員は、パトロール車両を運転して、使用中の駐車スペースの料金が支払われているかどうかを遠くから視覚的にチェックすることができる。また、ペイ・バイ・スペースでは、エンドユーザが機械で支払いを行った後に自分の車両に歩いて戻ってチケットを表示する必要がなく、代わりにそのまま自分の目的地に向かうことができるので、ユーザ体験が向上する。
上述したペイ・バイ・フォンと同様に、統合は、ペイ・バイ・スペースシステムによって提供されたAPI、又はサーバシステム140によって提供されるAPIのいずれかを使用することによって行うことができる。その目的は、両システムが、駐車違反情報を含む車両ナンバープレートリストを作成するために必要な全ての情報にアクセスできるようにすることである。
ペイ・バイ・スペースシステムによって提供されたAPIを介してサーバシステム140が統合される実施形態では、サーバシステム140が、ペイ・バイ・スペースシステムから(支払済み駐車の開始及び終了時刻、目的地番号、及び車両ナンバープレート番号などの)車両支払情報を取得する。最終的に、サーバシステム140は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。
ある実施形態では、サーバシステム140が、サーバシステム140が自力駐車取締に使用する駐車料金支払情報を第三機関の駐車料金支払システムから抽出するソフトウェアコンポーネントとすることができるペイ・バイ・スペース統合モジュールを含むことができる。ペイ・バイ・スペースのための統合モジュールは、(1)第三機関のペイ・バイ・スペースAPIとの接続を確立するステップ、(2)データ要求を発行するステップ、(3)データを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、第三機関のペイ・バイ・スペースAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)ステップ2〜7を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ(1)に関連して、通常、APIは、APIへの接続を確立できる機構を指定する。ペイ・バイ・スペース統合モジュールは、第三機関のペイ・バイ・スペースAPIが必要とするプロトコルを観察して接続を確立するように構成される。
ステップ(2)に関連して、サーバシステム140は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信(IPC)呼出しなどを介してこの事象をペイ・バイ・スペース統合モジュールにシグナリングし、ペイ・バイ・スペース統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関のペイ・バイ・スペースAPIに発行する。第三機関のペイ・バイ・スペースAPIに送信されるデータは、例えば、ペイ・バイ・スペースAPIによって認識された目的地識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、及びその特定の車両が目的地から立ち去った日付/時刻を含むことができる。
ステップ(3)に関連して、ペイ・バイ・スペース統合モジュールは、例えば、支払済み駐車開始日/時刻及び支払済み駐車終了日/時刻を含む情報を第三機関のペイ・バイ・スペースAPIから受け取るように構成することができる。ステップ(5)に関連して、ペイ・バイ・スペース統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
サーバシステム140によって提供されるAPIを介してサーバシステム140がペイ・バイ・スペースシステムに統合される実施形態では、サーバシステム140が、ペイ・バイ・スペースシステムに(車両ナンバープレート番号、目的地、及び実際の駐車開始及び終了時刻などの)車両情報を送信する。最終的に、ペイ・バイ・スペースシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。
通常、ペイ・バイ・スペースシステム又はそのスタッフは、サーバシステム140によって提供されるAPIを使用することに同意できる時には、一般にサーバシステム140から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号又はスペース番号について特定の車両が特定の目的地を使用した実際の時間である実際の車両駐車継続時間が有用なデータである。一般に、車両ナンバープレート番号又はスペース番号は、エンドユーザ支払処理の一部として取得することができるので、ペイ・バイ・スペースシステムは、これらの番号を既に有している。
サーバシステム140によって提供されたペイ・バイ・スペースAPIを介した統合は、2つの選択肢のうちの一方に従うことができる。1つ目は、第三機関の駐車料金支払システムがサーバシステム140に情報をプッシュするデータ流入モデルである。2つ目は、サーバシステム140が全ての関連情報を第三機関のペイ・バイ・スペースシステムにプッシュするデータ流出モデルである。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流入型ペイ・バイ・スペースAPIを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型ペイ・バイ・スペースAPIを介してサーバシステム140に情報をプッシュする。流入型ペイ・バイ・スペースAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムからデータを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、流入型ペイ・バイ・スペースAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型ペイ・バイ・スペースAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流入型ペイ・バイ・スペースAPIを介して、車両/ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、この特定の車両に関連して支払いが受け取られた目的地の識別子(サーバシステム140が内部的に使用する識別子への変換を必要とすることがある)、支払済み駐車開始日/時刻及び支払済み駐車終了日/時刻を含むことができる。ステップ(5)に関連して、サーバシステム140に含まれるペイ・バイ・スペース統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流出型ペイ・バイ・スペースAPIを含むことができ、この場合、サーバシステム140が、全ての関連情報を第三機関のペイ・バイ・スペースシステムにプッシュする。流出型ペイ・バイ・スペースAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムにデータをアップロードするステップ、(4)アップロードされたデータに対する確認応答を受け取るステップ、(5)第三機関の駐車料金支払システムからの「キープアライブ」/「ピン」要求に応答するステップ、及び(6)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型ペイ・バイ・スペースAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流出型ペイ・バイ・スペースAPIを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、特定の車両が目的地の使用を開始した実際の日付/時刻、及び特定の車両が目的地から立ち去った実際の日付/時刻を含むことができる。
別の実施形態では、サーバシステム140が、ペイ・バイ・スペースシステムに2ステップで統合されるように構成される。まず、サーバシステム140が、ペイ・バイ・スペースシステムから提供されたAPIを使用することにより、ペイ・バイ・スペースシステムから車両支払情報(例えば、支払済み駐車の開始及び終了時刻、駐車スペース番号、車両ナンバープレート番号)を取得する。この段階で、サーバシステム140は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム140が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム140によって提供されるAPIを用いて車両違反データをペイ・バイ・スペースシステムに送信することによって行うことができる。この時、ペイ・バイ・スペースシステムは、(ペイ・バイ・スペースシステムの業者によって開発されたカスタムソフトウェアアプリケーションなどを通じて)「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。
この統合方法と、サーバシステム140によって提供されるAPIを介したペイ・バイ・スペースシステムとの統合の大きな相違点は、この統合方法では、ペイ・バイ・スペースシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム140によって提供されるAPIによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。
ペイ・アンド・ディスプレイの前提は、エンドユーザが駐車料金を支払ったら、駐車取締職員がエンドユーザによる支払いの期間が切れていないことを確実にするためにチケットの目視チェックを行えるように、車内のダッシュボード上にチケットを置いておく必要があることである。
従来、ペイ・アンド・ディスプレイは、路外の駐車区画及び駐車場ビルを独占していた。最近ではペイ・バイ・スペース機構が広まっているにも関わらず、ペイ・アンド・ディスプレイは、依然として広い設置基盤を有している。道路脇の駐車のために配備されたペイ・アンド・ディスプレイシステムも存在する。
サーバシステム140は、自己取締能力を可能にするために、(州/県を含む)車両ナンバープレート情報、実際の駐車開始及び終了時刻、支払済み駐車の継続時間といった情報を必要とする。
サーバシステム140とペイ・アンド・ディスプレイシステムを統合する実施形態では、サーバシステム140が、識別カメラを介して車両ナンバープレート情報を収集し、目的地カメラが、車両がいつ目的地に入っていつ立ち去ったかをサーバシステム140が特定できるようにすることにより、実際の駐車開始及び終了時刻を提供する。支払済み駐車時間は、パン、チルト及びズーム能力を有する目的地カメラを利用してズームインし、エンドユーザが車両のダッシュボード上に置いたディスプレイチケット自体からバーコード又は印刷文字を抽出することによって特定することができる。
ある実施形態では、このような情報の読み取りを容易にするために、ペイ・アンド・ディスプレイ機構を、印刷文字に大きなフォントを使用するように、又はその他の識別特徴を大きく印刷するように構成することができる。別の実施形態では、従来のシステムが、ドライバーが車両を駐車したいと望む時間しか求めないのに対し、ペイ・アンド・ディスプレイ機構は、支払処理の一部としてナンバープレート番号を求めるように構成することができる。ある実施形態では、ペイ・アンド・ディスプレイ機構が、ロール状のディスプレイチケット用紙を利用し、各ディスプレイチケット内にRFIDチップを埋め込むことができる。
ある実施形態では、サーバシステム140を、ペイ・アンド・ディスプレイ機構を視野に含むカメラなどの1又はそれ以上のカメラを介して取り込まれた複数の画像に基づいて、歩行者追跡を行うように構成することができる。歩行者追跡では、サーバシステム140が車両追跡を行うのと同様に、サーバシステム140を、ペイ・アンド・ディスプレイ機構を介して支払いを得る車両との間を行き来する車両のドライバー及び/又は乗客を追跡するように構成することができる。この追跡した歩行者の動きに基づいて、車両の特定の場所に支払いをリンクさせ、ナンバープレート番号などの対応する車両識別子サーバシステム140によって特定することができる。このような実施形態では、印刷されたチケットから直接情報を取り込む必要がない。一例では、サーバシステム140が、ある個人が車両の乗客であったことを立証する1又はそれ以上の画像、及びこの乗客が目的地の使用に対してペイ・アンド・ディスプレイ支払ステーションで支払いを行ったことを立証する1又はそれ以上の画像を含む、1又はそれ以上のカメラによって取り込まれた複数の歩行者画像を受け取ることができる。サーバシステム140は、歩行者画像に取り込まれた歩行者について特定された特徴が時間が経っても一致するかどうかを判定することによって追跡を行い、この乗客が車両と支払ステーションの間を移動して支払いを行ったことを立証するように構成することができる。これに基づき、サーバシステム140は、この支払いをこの車両による特定の目的地の使用に関連付けることができる。
この情報が利用可能になると、サーバシステム140は、詳細な違反情報を含む車両ナンバープレートリストを作成することができる。ペイ・アンド・ディスプレイシステム自体は、この情報を一切処理しないので、このことは、ペイ・アンド・ディスプレイシステムがリアルタイム無線ネットワーキングをサポートしているかどうかに関係なく当てはまる。
サーバシステム140によって提供されるAPIを介してサーバシステム140とペイ・アンド・ディスプレイシステムを統合する実施形態では、サーバシステム140が、自己取締能力を可能にするために、車両ナンバープレート情報(州/県情報を含む)、実際の駐車開始及び終了時刻、及び支払済み駐車の継続時間を必要とする。
サーバシステム140は、識別カメラを介して車両ナンバープレート情報を収集し、目的地カメラは、車両がいつ駐車スペースに入っていつ立ち去ったかを検出することにより、サーバシステム140が実際の駐車開始及び終了時刻を特定できるようにする。支払済み駐車継続時間は、パン、チルト及びズーム機能を有する目的地カメラを使用してズームインを可能にし、エンドユーザが車両のダッシュボード上に置いたディスプレイチケット自体からバーコード又は印刷文字を抽出することによって特定することができる。
サーバシステム140によって提供されるペイ・アンド・ディスプレイAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムにデータをアップロードするステップ、(4)アップロードされたデータに対する確認応答を受け取るステップ、(5)第三機関の駐車料金支払システムからの「キープアライブ」/「ピン」要求に応答するステップ、及び(6)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前にペイ・アンド・ディスプレイAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、ペイ・アンド・ディスプレイAPIを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、特定の車両が目的地の使用を開始した実際の日付/時刻、及び特定の車両が目的地から立ち去った実際の日付/時刻を含むことができる。
サーバシステム140は、このモードで動作するように構成されている場合、(車両ナンバープレート番号、支払済み駐車の開始及び終了時刻、実際の駐車開始及び終了時刻などの)車両駐車違反情報をペイ・アンド・ディスプレイシステムに送信する。最終的に、第三機関のペイ・アンド・ディスプレイシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。
通常、ペイ・アンド・ディスプレイシステム又はそのスタッフは、サーバシステム140によって提供されるAPIを使用することに同意できる時には、一般にサーバシステム140から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号についての支払済み駐車の開始及び終了時刻、並びに実際の車両駐車開始及び終了時刻が有用なデータである。一般に、ペイ・アンド・ディスプレイシステムは(印刷されたディスプレイチケットに依拠するので)紙に基づいており、車両識別情報又は目的地番号に関する情報は一切所有していない。ペイ・アンド・ディスプレイシステムは、支払済み駐車の開始時間及び支払済み駐車の継続時間は所有しているが、これらのシステムは、その支払済み駐車がどの車両に相関するものであるかが分からない。ペイ・アンド・ディスプレイシステムは、サーバシステム140によって提供されるAPIを使用することにより、駐車違反情報を含む車両のリストを駐車場オペレータに提示するという選択肢を有する。ペイ・アンド・ディスプレイシステムは、このAPIを通じてサーバシステム140から関連情報を取得し、この情報をあらゆる所望のフォーマットで提示することができる。
従って、サーバシステム140によって提供されるAPIを介した統合は、サーバシステム140が全ての関連情報をペイ・アンド・ディスプレイシステムに「プッシュ」する「プッシュ」モデルである。その後、ペイ・アンド・ディスプレイシステムは、未払いの又は期限切れ駐車の車両ナンバープレートリストを表示する。換言すれば、サーバシステム140によって提供されるAPIを介したペイ・アンド・ディスプレイの統合は、一般に「プル」モデルでは実現されない。
ある実施形態では、QRコードを含むペイ・アンド・ディスプレイ機構を設けることができる。QRコードは広まってきており、ペイ・アンド・ディスプレイチケットに通常含まれる全ての関連情報(駐車期間、駐車期限、支払額、日付及び時間など)を容易に保持することができる。
ある実施形態では、ペイ・バイ・フォンシステムが、ペイ・アンド・ディスプレイ駐車システムに重なることができ、APIを介してペイ・バイ・フォン支払システムにサーバシステム140を統合することができる。このような事例では、ペイ・バイ・フォンシステムによって提供されるAPIを使用する場合、通常は既にペイ・バイ・フォンシステムが車両ナンバープレート情報を所有しているので、サーバシステム140は、ペイ・バイ・フォンシステムに車両検出情報を送信する。最終的に、ペイ・バイ・フォンシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な情報を有するようになる。
従来の道路脇駐車メータ(単一スペース又は二重スペース)は、硬貨を受け入れるのみであって内蔵知能又はネットワーキング能力を有していないが、ペイ・バイ・フォンは、従来の道路脇駐車メータと共に良好に機能する人気の高い「オーバーレイ」支払方式になってきた。最近では、硬貨とクレジットカードの両方を受け付けネットワーキング能力も内蔵した道路脇駐車メータも出現してきている。
従来の駐車メータは、一般に支払済み駐車期間が過ぎていること、又は単純に駐車料金が支払われていないことを示す機械的な、又はLCDディスプレイによる「期限切れフラグ」を有する。駐車料金が支払われていて時間が残っている時には、機械的期限切れフラグ(通常は赤色)が視界から隠され、LCDディスプレイが、メータの道路に面する側に鮮やかな表示を示す。対照的に、支払済み駐車の期限が切れた時、又は支払いが行われていない時には、赤色の機械的期限切れフラグが「上部」位置に目立つように表示され、道路側に面したLCDディスプレイが、鮮やかな表示と暗い表示を(時には点滅する赤色LEDも用いて)交互に点滅させる。これらは、いずれも一般に期限切れフラグと呼ばれる。
ある実施形態では、サーバシステム140が、識別カメラ及び目的地カメラの両方から収集された情報の組み合わせを用いて、従来の道路脇駐車メータとやりとりすることができる。識別カメラ及び目的地カメラによって取り込まれた画像は、(以下に限定されるわけではないが、駐車開始及び終了時刻などの)車両駐車状況を識別することに加え、駐車メータ上の(以下に限定されるわけではないが、前納時間が切れているかどうかなどの)支払済み駐車状況を示すこともできる。
サーバシステム140は、識別カメラによって取り込まれた画像を通じて車両ナンバープレート情報を収集する一方で、目的地カメラによって取り込まれた画像を通じて車両がいつ駐車スペースに入っていつ駐車スペースを離れたかを検出することにより、実際の駐車開始及び終了時刻を特定することができる。支払済み駐車の期限切れ時間は、位置及び目的地カメラの両方を用いてズームインを行い、各駐車メータ上の目に見える期限切れフラグの状況をモニタすることによって特定される。サーバシステム140は、この情報に基づいて駐車違反状況を特定し、例えば後述する駐車違反前処理ロジックによってさらに処理できるように、データベース141内で目的地の使用に駐車違反としてマーキングすることができる。サーバシステム140が期限切れフラグを確認できない状況では、サーバシステム140を、駐車場オペレータ又はスタッフに例外を示し、及び/又はライブオペレータ(後述)を用いて駐車違反状況及び/又は例外フラグ状況を手動で特定するように構成することができる。
通りの反対側から目的地カメラによって取り込まれた目的地画像は、各駐車メータの期限切れフラグ状況をモニタするのに十分な視野角を有する。また、パン、チルト及びズーム能力を有する識別カメラは、各駐車メータの期限切れフラグ状況をモニタするのにも十分なズームパワー及び視野角を有することができる。上記情報が利用可能になると、サーバシステム140は、詳細な違反情報を含む車両ナンバープレートリストを作成することができる。
サーバシステム140によって提供されるAPIを介してサーバシステム140と従来の道路脇駐車メータシステムを統合する実施形態では、サーバシステム140が、自己取締能力を可能にするために、車両ナンバープレート情報(州/県情報を含む)、実際の駐車開始及び終了時刻、及び支払済み駐車の継続時間を必要とする。
サーバシステム140は、識別カメラによって取り込まれた画像を通じて車両ナンバープレート情報を収集する一方で、目的地カメラによって取り込まれた画像を通じて車両がいつ駐車スペースに入っていつ駐車スペースを離れたかを検出することにより、実際の駐車開始及び終了時刻を特定することができる。支払済み駐車の期限切れ時間は、位置及び目的地カメラの両方を用いてズームインを行い、各駐車メータ上の目に見える期限切れフラグの状況をモニタすることによって特定される。サーバシステム140は、この情報に基づいて駐車違反状況を特定し、例えば後述する駐車違反前処理ロジックによってさらに処理できるように、データベース141内で目的地の使用に駐車違反としてマーキングすることができる。サーバシステム140が期限切れフラグを確認できない状況では、サーバシステム140を、駐車場オペレータ又はスタッフに例外を示し、及び/又はライブオペレータ(後述)を用いて駐車違反状況及び/又は例外フラグ状況を手動で特定するように構成することができる。
サーバシステム140によって提供される従来の道路脇駐車メータAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムにデータをアップロードするステップ、(4)アップロードされたデータに対する確認応答を受け取るステップ、(5)第三機関の駐車料金支払システムからの「キープアライブ」/「ピン」要求に応答するステップ、及び(6)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に従来の道路脇駐車メータAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、従来の道路脇駐車メータAPIを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、特定の車両が目的地の使用を開始した実際の日付/時刻、及び特定の車両が目的地から立ち去った実際の日付/時刻を含むことができる。
サーバシステム140は、このモードで動作するように構成されている場合、通常は実際の道路脇メータとの接続性を有していない支払収集/集計システムである従来の道路脇駐車メータシステムに車両駐車違反情報を送信する。最終的に、従来の道路脇駐車メータシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。
通常、従来の道路脇駐車メータシステム又はそのスタッフは、サーバシステム140によって提供されるAPIを使用することに同意できる時には、一般にサーバシステム140から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号についての期限切れ又は未払い駐車状況、並びに実際の車両駐車開始及び終了時刻が有用なデータである。一般に、従来の道路脇駐車メータシステムは、車両識別情報又はスペース番号に関する情報を一切所有していない。
従って、サーバシステム140によって提供されるAPIを介した統合は、サーバシステム140が全ての関連情報を従来の道路脇駐車メータシステムに「プッシュ」する「プッシュ」モデルである。その後、従来の道路脇駐車メータシステムは、未払いの又は期限切れ駐車の車両ナンバープレートリストを表示する。
ある実施形態では、ペイ・バイ・フォンシステムが、従来の道路脇駐車システムに重なることができ、APIを介してペイ・バイ・フォン支払システムにサーバシステム140を統合することができる。このような事例では、ペイ・バイ・フォンシステムによって提供されるAPIを使用する場合、通常は既にペイ・バイ・フォンシステムが車両ナンバープレート情報を所有しているので、サーバシステム140は、ペイ・バイ・フォンシステムに車両検出情報を送信する。最終的に、ペイ・バイ・フォンシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な情報を有するようになる。
最近では、内蔵型3G又はWiFiモデムを用いてクレジットカード承認を行う道路脇駐車メータ(単一スペース又は二重スペース)が導入されてきている。ある実施形態では、サーバシステム140を、道路脇駐車メータAPIを介してこの種の駐車メータとやりとりするように構成することができる。具体的には、これらの道路脇駐車メータは、無線ネットワーク接続性及び関連するバックエンドサーバを既に組み込んでいるので、サーバシステム140をこの第三機関のバックエンドサーバに統合することは困難ではない。
サーバシステム140がこのモードで動作するように構成されている場合、道路脇駐車メータAPIのための統合モジュールは、(1)第三機関の道路脇駐車メータAPIとの接続を確立するステップ、(2)データ要求を発行するステップ、(3)データを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、道路脇駐車メータAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)ステップ2〜7を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ(1)に関連して、通常、APIは、APIへの接続を確立できる機構を指定する。道路脇駐車メータAPIのための統合モジュールは、道路脇駐車メータAPIが必要とするプロトコルを観察して接続を確立するように構成される。
ステップ(2)に関連して、サーバシステム140は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信(IPC)呼出しなどを介してこの事象を道路脇駐車メータAPIのための統合モジュールにシグナリングし、道路脇駐車メータAPIのための統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関の道路脇駐車メータAPIに発行する。第三機関の道路脇駐車メータAPIに送信されるデータは、例えば、道路脇駐車メータAPIによって認識された目的地識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、及びその特定の車両が目的地から立ち去った日付/時刻を含むことができる。
ステップ(3)に関連して、道路脇駐車メータAPIのための統合モジュールは、例えば、道路脇駐車メータAPIによって認識された目的地の識別子(サーバシステム140が内部的に使用する識別子への変換を必要とすることがある)、支払済み駐車開始日/時刻、及び支払済み駐車終了日/時刻を含む情報を第三機関の道路脇駐車メータAPIから受け取るように構成することができる。ステップ(5)に関連して、道路脇駐車メータAPIのための統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
従って、道路脇駐車メータAPIを介した統合は、第三機関の道路脇駐車メータシステムが出力できる全ての関連情報をサーバシステム140が「プル」し、サーバシステム140によって特定された自動化車両違反情報を加えて未払い又は期限切れ駐車の車両ナンバープレートリストを作成する「プル」モデルである。換言すれば、道路脇駐車メータAPIを介した統合は、一般に「プッシュ」モデルでは実現されない。
サーバシステム140が、サーバシステム140によって提供されるAPIを介して道路脇駐車メータシステムに統合されるように構成される実施形態では、サーバシステム140が、道路脇駐車メータシステムに(車両ナンバープレート番号、目的地、及び実際の駐車開始及び終了時刻などの)車両情報を送信する。最終的に、道路脇駐車メータシステムは、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。
通常、道路脇駐車メータシステム又はそのスタッフは、サーバシステム140によって提供されるAPIを使用することに同意できる時には、一般にサーバシステム140から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号又は目的地番号について特定の車両が特定の目的地を使用した実際の時間である実際の車両駐車継続時間が有用なデータである。一般に、車両ナンバープレート番号又はスペース番号は、一般にエンドユーザ支払処理の一部として取得することができるので、道路脇駐車メータシステムは、この情報を既に有している。
サーバシステム140によって提供される道路脇駐車メータAPIを介した統合は、2つの選択肢のうちの一方に従うことができる。1つ目は、第三機関の駐車料金支払システムがサーバシステム140に情報をプッシュするデータ流入モデルである。2つ目は、サーバシステム140が全ての関連情報を道路脇駐車メータシステムにプッシュするデータ流出モデルである。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流入型道路脇駐車メータAPIを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型道路脇駐車メータAPIを介してサーバシステム140に情報をプッシュする。流入型道路脇駐車メータAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムからデータを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、流入型道路脇駐車メータAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型道路脇駐車メータAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流入型道路脇駐車メータAPIを介して、車両/ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、例えばこの特定の車両に関連して支払いが受け取られた目的地の識別子(サーバシステム140が内部的に使用する識別子への変換を必要とすることがある)、支払済み駐車開始日/時刻及び支払済み駐車終了日/時刻を含むことができる。ステップ(5)に関連して、サーバシステム140に含まれる道路脇駐車メータ統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流出型道路脇駐車メータAPIを含むことができ、この場合、サーバシステム140が、全ての関連情報を第三機関の道路脇駐車メータシステムにプッシュする。流出型道路脇駐車メータAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムにデータをアップロードするステップ、(4)アップロードされたデータに対する確認応答を受け取るステップ、(5)第三機関の駐車料金支払システムからの「キープアライブ」/「ピン」要求に応答するステップ、及び(6)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型道路脇駐車メータAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流出型道路脇駐車メータAPIを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、特定の車両が目的地の使用を開始した実際の日付/時刻、及び特定の車両が目的地から立ち去った実際の日付/時刻を含むことができる。
ある実施形態では、サーバシステム140を、道路脇駐車メータシステムに2ステップで統合されるように構成することができる。まず、サーバシステム140が、道路脇駐車メータシステムから提供されたAPIを使用することにより、道路脇駐車メータシステムから(支払済み駐車の開始及び終了時刻、駐車スペース番号、車両ナンバープレート番号などの)車両支払情報を取得する。この段階で、サーバシステム140は、駐車違反の詳細を含む車両ナンバープレートリストを作成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム140が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム140によって提供されるAPIを用いて車両違反データを道路脇駐車メータシステムに送信することによって行うことができる。この時、道路脇駐車メータシステムは、(道路脇駐車メータシステムの業者によって開発されたカスタムソフトウェアアプリケーションなどを使用して)「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。
この統合方法と、サーバシステム140によって提供されるAPIを介した統合との大きな相違点は、この統合方法では、道路脇駐車メータシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム140によって提供されるAPIによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。
ペイ・バイ・プレートは、(車両が駐車している)特定の番号付き駐車スペースに駐車料金の支払いを関連付けるペイ・バイ・スペースと同様に、駐車スペース内に駐車された特定のナンバープレートの車両に駐車料金の支払いを関連付ける。通常、ペイ・バイ・プレート駐車の手動取締は、取締官が物理的駐車スペースの前を車で通って全ての駐車車両のナンバープレートが支払済み状態のナンバープレートリストに確実に載るようにするものである。逆に言えば、「支払済み」リスト上にないナンバープレートを有するあらゆる駐車車両は、駐車違反切符を受け取ることになる。
上述したペイ・バイ・フォン及びペイ・バイ・スペースと同様に、統合は、ペイ・バイ・プレートシステムによって提供されるAPI又はサーバシステム140によって提供されるAPIのいずれかを使用することによって行うことができる。その目的は、両システムが、駐車違反情報を含む車両ナンバープレートリストを作成するために必要な全ての情報にアクセスできるようにすることである。
ペイ・バイ・プレートシステムによって提供されたAPIを介してサーバシステム140が統合される実施形態では、サーバシステム140が、ペイ・バイ・プレートシステムから(支払済み駐車の開始及び終了時刻、及び車両ナンバープレート番号などの)車両支払情報を取得する。最終的に、サーバシステム140は、駐車違反の詳細を含む車両ナンバープレートリストを生成するために必要な正確な情報を有するようになる。
ある実施形態では、サーバシステム140が、サーバシステム140が自力駐車取締に使用する駐車料金支払情報を第三機関の駐車料金支払システムから抽出するソフトウェアコンポーネントとすることができるペイ・バイ・プレート統合モジュールを含むことができる。ペイ・バイ・プレートのための統合モジュールは、(1)第三機関のペイ・バイ・プレートAPIとの接続を確立するステップ、(2)データ要求を発行するステップ、(3)データを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、第三機関のペイ・バイ・プレートAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)ステップ2〜7を繰り返すステップ又は接続を閉じるステップ、を実行する。ステップ(1)に関連して、通常、APIは、APIへの接続を確立できる機構を指定する。ペイ・バイ・プレート統合モジュールは、第三機関のペイ・バイ・プレートAPIが必要とするプロトコルを観察して接続を確立するように構成される。
ステップ(2)に関連して、サーバシステム140は、特定の車両が目的地から立ち去ったと判断すると、データベース又はプロセス間通信(IPC)呼出しなどを介してこの事象をペイ・バイ・プレート統合モジュールにシグナリングし、ペイ・バイ・プレート統合モジュールは、これに応答して、この特定の車両の駐車料金支払情報を求める要求を第三機関のペイ・バイ・プレートAPIに発行する。第三機関のペイ・バイ・プレートAPIに送信されるデータは、例えば、(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、及び特定の車両が目的地から立ち去った日付/時刻を含むことができる。
ステップ(3)に関連して、ペイ・バイ・プレート統合モジュールは、例えば、支払済み駐車開始日/時刻及び支払済み駐車終了日/時刻を含む情報を第三機関のペイ・バイ・プレートAPIから受け取るように構成することができる。ステップ(5)に関連して、ペイ・バイ・プレート統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
サーバシステム140によって提供されるAPIを介してサーバシステム140がペイ・バイ・プレートシステムに統合される実施形態では、サーバシステム140が、ペイ・バイ・プレートシステムに(車両ナンバープレート番号、目的地、及び実際の駐車開始及び終了時刻などの)車両情報を送信する。最終的に、ペイ・バイ・プレートシステムは、駐車違反の詳細を含む車両ナンバープレートリストを生成するために必要な正確な情報を有するようになる。
通常、ペイ・バイ・プレートシステム又はそのスタッフは、サーバシステム140によって提供されるAPIを使用することに同意できる時には、一般にサーバシステム140から何らかの有用なデータを受け取るために、ある程度のカスタムソフトウェア開発に着手する準備が整っている。この特定の事例では、特定の車両ナンバープレート番号について特定の車両が目的地を使用した実際の時間である実際の車両駐車継続時間が有用なデータである。基本的に、車両ナンバープレート番号は、エンドユーザ支払処理の一部として取得されるので、ペイ・バイ・プレートシステムは、これらの番号を既に有している。
サーバシステム140によって提供されたペイ・バイ・プレートAPIを介した統合は、2つの選択肢のうちの一方に従うことができる。1つ目は、第三機関の駐車料金支払システムがサーバシステム140に情報をプッシュするデータ流入モデルである。2つ目は、サーバシステム140が全ての関連情報を第三機関のペイ・バイ・レートシステムにプッシュするデータ流出モデルである。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流入型ペイ・バイ・プレートAPIを含むことができ、この場合、第三機関の駐車料金支払システムが、この流入型ペイ・バイ・プレートAPIを介してサーバシステム140に情報をプッシュする。流入型ペイ・バイ・プレートAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムからデータを受け取るステップ、(4)データを処理してデータベース141に記憶するステップ、(5)駐車違反状況を特定するステップ、(6)例えば後述する駐車違反前処理ロジックによるさらなる処理のために、駐車違反としての目的地の使用にデータベース141内でマーキングするステップ、(7)以下に限定されるわけではないが、「キープアライブ」/「ピン」メッセージ又はコマンドの使用などにより、流入型ペイ・バイ・プレートAPIが作動中であり有効であることを定期的に確認するステップ、及び(8)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流入型ペイ・バイ・プレートAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流入型ペイ・バイ・プレートAPIを介して、車両/ドライバーが駐車料金を支払う毎に第三機関の駐車料金支払システムから車両駐車情報を受け取るように構成することができる。受け取られる特定の車両の情報は、例えば、(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、支払済み駐車開始日/時刻、及び支払済み駐車終了日/時刻を含むことができる。ステップ(5)に関連して、サーバシステム140に含まれるペイ・バイ・プレート統合モジュールは、ステップ(3)から受け取ったデータによって示される支払済み駐車の継続時間と、サーバシステム140によって特定された実際の駐車継続時間とを比較するように構成することができる。実際の駐車継続時間が支払済み駐車の継続時間を超える場合、ステップ(6)の処理が行われ、そうでなければステップ(6)は行われない。
ある実施形態では、サーバシステム140が、例えばネットワーク110を介して第三機関の駐車料金支払システムによって使用される流出型ペイ・バイ・プレートAPIを含むことができ、この場合、サーバシステム140が、全ての関連情報を第三機関のペイ・バイ・プレートシステムにプッシュする。流出型ペイ・バイ・プレートAPIは、例えば、(1)第三機関の駐車料金支払システムが接続を確立するのを待つステップ、(2)第三機関の駐車料金支払システムの識別情報を認証するステップ、(3)第三機関の駐車料金支払システムにデータをアップロードするステップ、(4)アップロードされたデータに対する確認応答を受け取るステップ、(5)第三機関の駐車料金支払システムからの「キープアライブ」/「ピン」要求に応答するステップ、及び(6)必要時又はタイムアウト時に接続を閉じるステップ、を実行するように構成することができる。ステップ(1)に関連して、このステップでは、第三機関の駐車料金支払システムが接続を確立するためのTCP又はUDPポートをリスンすることができる。ステップ(2)に関連して、第三機関の駐車料金支払システムは、データ交換が許可される前に流出型ペイ・バイ・プレートAPIを介して自らを認証する必要がある。認証できなかった場合にはリトライ機構が提供され、複数回の試みが上手くいかなかった後に接続を切ることができる。ステップ(3)に関連して、サーバシステム140は、流出型ペイ・バイ・プレートAPIを介して、車両が第三機関の駐車料金支払システムに関連する目的地から立ち去る毎に第三機関の駐車料金支払システムに車両駐車情報をアップロードするように構成することができる。アップロードされる特定の車両の情報は、例えば(ナンバープレート番号及び州/県情報を含む)車両ナンバープレート情報、第三機関の駐車料金支払システムによって認識された目的地の識別子(サーバシステム140が内部的に使用する識別子からの変換を必要とすることがある)、特定の車両が目的地の使用を開始した実際の日付/時刻、及び特定の車両が目的地から立ち去った実際の日付/時刻を含むことができる。
別の実施形態では、サーバシステム140が、ペイ・バイ・プレートシステムに2ステップで統合されるように構成される。まず、サーバシステム140が、ペイ・バイ・プレートシステムから提供されたAPIを使用することにより、ペイ・バイ・プレートシステムから車両支払情報(例えば、支払済み駐車の開始及び終了時刻、並びに車両ナンバープレート番号)を取得する。この段階で、サーバシステム140は、駐車違反の詳細を含む車両ナンバープレートリストを生成するために必要な正確な情報を有するようになる。しかしながら、このリストをサーバシステム140が駐車場オペレータに提示する代わりに、在任中の駐車料金支払業者が、駐車違反情報をいかにして駐車場オペレータに戻すかを制御し続けたい場合もある。これは、サーバシステム140によって提供されるAPIを用いて車両違反データをペイ・バイ・プレートシステムに送信することによって行うことができる。この時、ペイ・バイ・プレートシステムは、(ペイ・バイ・プレートシステムの業者によって開発されたカスタムソフトウェアアプリケーションなどを通じて)「違法」車両のリストを駐車場オペレータにどのように表示するかを全体的に制御する。
この統合方法と、サーバシステム140によって提供されるAPIを介したペイ・バイ・プレートシステムとの統合の大きな相違点は、この統合方法では、ペイ・バイ・プレートシステムの業者側に必要な開発努力が最小限に抑えられる点である。駐車場オペレータに提示すべき全ての鍵となる情報は、サーバシステム140によって提供されるAPIによって既に提供されており、さらなる分析を一切必要としないので、この情報は、最低限のソフトウェア開発しか伴わずに、駐車場オペレータに単純に表示又は転送することができる。この統合方法は、「プル」の後に「プッシュ」を行うモデルを表す。
図1に示すシステムの一部としてライブオペレータチームを使用することが検討に値し、予想される駐車場オペレータに付加価値機能として提示すべき実務上の選択肢を提供できる理由は主に2つある。
まず、サーバシステム140は、識別カメラ及び目的地カメラから取得された画像を自律的に受け取って処理するが、通常は、取得された画像、及びサーバシステム140上で実行されるソフトウェアをモニタするライブオペレータが存在する。これらのライブオペレータは、サーバシステム140の動作を再検討し、必要に応じて例外毎に適切な措置を取ることができる。例えば、予想外の問題が生じた場合、ライブオペレータは、その問題に関する画像を見直して、サーバシステム140が対処するように構成されていない可能性がある旨の情報を導出することができる。
サーバシステム140によってサポートされているネットワークアーキテクチャの利点は、複数のサイトの運営を、これらのそれぞれの地理的位置に関わらず、或いは設備の運営が異なる駐車場運営又は競合他社によって所有されている可能性があるという事実に関わらず、単一のライブオペレータチームによって監督又は増強できる点である。この結果、ライブオペレータの選択肢は、駐車場オペレータにとってスケーラブルかつコスト効率の良い方法になり得る。さらに、IPマルチキャスト又は同様の標準的TCP/IPプロトコルを使用することにより、ビデオストリームを複数の目的地に効果的に同時送信することができ、この結果、駐車場オペレータによって配置されたローカルなオンサイトモニタリングに加え、将来的にライブオペレータの選択肢を追加できるようになる。
第2に、上述したペイ・アンド・ディスプレイ構成及び道路脇メータ構成は、利用可能な技術に応じて重大な現実的問題を示すことがある。高レベルのズームを備えたカメラが必要なだけでなく、特定のビデオカメラからの視野角が従来の道路脇駐車メータの期限切れフラグを正しく検出するのに十分でなかったり、或いはダッシュボードの物理的な3次元形状及びチケット自体の配置に起因して、車両のダッシュボード上のペイ・アンド・ディスプレイチケットのバーコードがあらゆるビデオカメラとは違う方向を向いていたりなどの潜在的な問題点もある。
ライブオペレータの選択肢では、サーバシステム140が、ナンバープレート番号、従来の駐車メータ上の期限切れフラグの状態、又はペイ・アンド・ディスプレイチケット上のバーコード/印刷情報などの重要な情報部分を自動的に検出できなかった時に例外事象を生成することがある。ライブオペレータは、このような例外事象により、以下に限定されるわけではないが、識別カメラ及び/又は目的地カメラによって取り込まれた映像の巻き戻し/早送り/一時停止/コマ送り及びコマ戻しを行うこと、取り込まれた映像内の特定の関心領域にズームイン/アウトすること、改善された画像を取得するためにビデオカメラをリアルタイムでパン/チルト/ズームすること、及びサーバシステム140が使用するための改善された画像を取得するために現場係員を派遣して視覚的に又はモバイル装置150を用いて車両又は駐車メータの検査を行うことなどを含むいくつかの特定の対策を取り始めることができる。
ある実施形態では、サーバシステム140が、駐車場オペレータが駐車違反切符の歳入を得られるように、車両の登録所有者の郵送先住所をそのナンバープレート番号に相関付けるように構成される。赤信号カメラシステムは、このような機構を利用して車両の登録所有者に違反チケットを郵送する。このような機能に関連して、駐車場オペレータは、3つの異なるカテゴリに入る。
第1に、駐車場オペレータが、既にDMVの記録にアクセスできている都市/地方自治体の一部である場合、サーバシステム140は、登録所有者に違反切符を郵送するために、州/県情報及び(日付、時間及び場所などの)駐車違反の詳細を含む車両ナンバープレート番号リストを提供するだけでよい。
第2に、DMVの記録に事前にアクセスできない民間駐車場オペレータの場合、車両ナンバープレート番号に関連する名前及び住所を含む個人情報を取得するための法的方法がいくつか存在する。これらの方法は、州(及び県)毎に異なる。一例として、ニューヨーク州では、民間駐車場オペレータが、ドライバー・プライバシー保護法(DPPA)の形式MV−15DPPA:「民間有料交通機関の運営に関連する使用について」、「施設を使用した車両の所有者に通知を行う目的の駐車施設運営会社を含む」を使用することによってこのような情報にアクセスすることができる。管轄によっては、名前及び住所情報をオンラインで公表できるところもあり、従ってサーバシステム140を、このような情報を取得して処理するように構成することができる。管轄によっては、第三者車両所有者の名前及び住所情報をオンラインで公表することができず、代わりに郵便で又は本人が直接取得しなければならないところもある。このような管轄では、民間駐車場オペレータは、(毎日、2、3日毎、又は1週間毎などの)1回毎に名前及び住所情報を取得したいと望むことができる。
第3に、登録所有者情報へのリアルタイムなアクセスを好む民間駐車場オペレータの場合、いくつかの私的な車両ナンバープレートデータベースがインターネットを介して利用可能である。この方法の主な利点は、手動操作を必要とせずに名前及び住所情報を速やかに自動で検索できる点である。
図1に関連して上述したように、エンドユーザシステム170は、車載システムを含むことができる。ある実施形態では、自動車メーカーで製造されたばかりの最新の車両計器盤が、「エンジンチェック」、サイドブレーキ警告、又はクルーズコントロール表示灯などの他の計器灯と同様の表示アイコンを含むことができる。通常、この表示アイコンは、車両130が高速道路を走行中である場合、或いはサーバシステム140が機能する境界内に存在しない場合には点灯しない。車両130が駐車区画又は道路脇駐車区域に近付くと、この表示アイコンが黄色に点灯して、サーバシステム140が提供する自動駐車サービスを利用できることをエンドユーザに通知する。車両130が駐車スペースなどの目的地に入ると、この表示アイコンが赤色に変わって、駐車料金が未納であることをエンドユーザに通知する。(上述したペイ・バイ・フォン、道路脇メータ、ペイ・バイ・スペース、又はその他の技術のいずれによってかに関わらず)駐車料が支払われると、この表示アイコンが緑色になって駐車料が支払われたことを知らせる。ある実施形態では、これらの視覚表示を、単純なチャイム又は音声アナウンスとすることができる音声通知によって実現することができる。音声出力は、車両の娯楽装置に音声情報又はデータを提供することによって行うことができる。
本発明は、駐車料金支払及び取締処理の多くの態様を自動化するので、サーバシステム140が何を行っているか、又はサーバシステム140が車両130に関連付けた特定の状態(例えば、車両130が駐車違反を犯したかどうか)に関するフィードバックをエンドユーザに提供することが重要である。エンドユーザは、この提供されたフィードバックに応じて対応することができる。エンドユーザ又は登録所有者は、高度に自動化された支払及び取締システムの範囲内で活動している間は、軽微な過失又は管理上の過失に関してペナルティを受けることはないと予測するのが当然である。計器盤の表示アイコンなどの単純なインターフェイスを介して提供されるフィードバックは、この問題を大きく軽減することができる。
例えば、車両130が駐車した時に、しばらく経っても表示アイコンが赤色のままである場合、エンドユーザは、例外事象が起きたと自覚する。ファイル上のクレジットカード番号の期限が切れており、従ってサーバシステム140が駐車料金を適用できないのかもしれない。このフィードバックは、エンドユーザに、例えばサーバシステム140によって又はサーバシステム140に関連して提供されるウェブサイトを訪問し、自身のアカウント状況に問い合わせて過失を是正する機会を提供する。
組み込みセルラーデータ又はWiFi車両接続、又はスマートセンサ(後述)を含め、計器盤の表示アイコンが情報を取得できるいくつかの潜在的な情報源が存在する。表示アイコンが出荷時に取り付けられていない古い車両では、Bluetooth(登録商標)、セルラーデータ又はWi−Fi接続を通じて情報を受け取る視覚モジュールの形の改造キットをエンドユーザに提供することができる。
ある実施形態では、この表示アイコン機能が、車両の配線用ハーネスを介して第三機関の車載サブシステムからGPS位置データを受け取る。このGPSデータは、表示アイコン機能が、現在車両130が支払済み駐車ゾーン内に存在するかどうかを判断できるようにする。
車両の計器盤アイコンと同様に、工場で製造されたばかりの新車にスマートセンサを設計することもできる。ZigBeeIEEE802.15.4規格に類似する技術を用いて、車両同士の間、及び車両と駐車施設との間に低コスト、低電力の短距離無線メッシュネットワークを形成することができる。各車両がノードになり、メッシュネットワークを形成することによって中間ノードを介してデータを中継することにより、あるノードが離れたエンドポイントと通信することができる。各スマートセンサが一意の識別子を含むことにより、もはやナンバープレート情報は重要でなくなる。ある実施形態では、スマートセンサを、セルラーデータ接続を介してサーバシステム140と通信し、及び/又はペイ・バイ・フォン機能を提供するように構成することができ、これによって目的地の使用に対する支払いがスマートセンサを介して行われるようになる。
このようなスマートセンサの導入によって多くの応用が可能になる。例えば、スマートセンサは、GPS受信機を含むことにより、又は車載GPSと通信することにより、車両130の現在位置を特定して、この現在位置をサーバシステム140にレポートすることができる。アシスト型GPSなどのいくつかのGPS技術では、GPSを介して特定される位置が、車両が特定の目的地を使用していると判断するのに十分な精度及び正確さを有することができる。これらのセンサは、駐車メータと通信して、基本的に車両の存在及び駐車時間をレポートすることもできる。この駐車情報は、離れた装置/ネットワークにメッシュネットワークを介して中継することができ、従って駐車施設を車両の近くに配置する必要がない。スマートセンサを備えた車両では、既にこの組み込みスマートセンサが車両の一意の識別情報をサーバシステム140に提供しているので、識別カメラ及び目的地カメラを使用する必要がない。
ある実施形態では、車両が、RFIDチップなどの近距離通信(NFC)装置を備えることができる。例えば、このような通信装置をミラーハンガーに含めることができる。別の例では、ペイ・アンド・ディスプレイ装置によって提供されるチケットにRFIDチップを埋め込むことができる。近距離通信装置から車両識別符号を取得することにより、識別カメラによって取り込まれたナンバープレート情報を含む画像などの画像の使用をサーバシステム140が必要としなくなり、及び/又はこれらの画像を用いて、観察車両に対応するNFC装置から受け取った情報を検証することができる。
ある実施形態では、スマートセンサが、近くの他の車両の(以下に限定されるわけではないが、動いているか、それとも駐車中であるか、及び駐車時間などの)状態を感知して、この状態をサーバシステム140にレポートすることができる。最終的に、サーバシステム140は、ほとんど全てのスマートセンサ搭載車両がどこに駐車されているか、及びどれほどの時間駐車されているかを認識するようになる。この情報を第三機関のシステム又はターンキープラットフォームからの駐車料金支払情報と組み合わせることにより、駐車料金が未納の車両又は駐車期限が過ぎている車両の識別情報を特定し、登録所有者に駐車違反チケットを郵送し、或いは(例えば、ファイル上のクレジットカードに課金することによって)現場で駐車違反の罰金を課すことができる。
ある実施形態では、目的地カメラに、レーザー式状態通知を設けることができる。このレーザー式状態通知機能は、ショッピングモール及び小売店で見られるレーザー式ロゴ装置と同様に、駐車車両を包み込む無害な点滅する赤色光を当てて、駐車料金が未納である旨又は期限が過ぎている旨をエンドユーザに通知する。この実施形態は、従来の手動駐車取締モデル下において車両に戻ってフロントガラスのワイパーの下に挟まれた駐車チケットを見ることに類似する。通常、目的地カメラは車両に対して高い位置に配置されるので、含まれているレーザー式状態通知モジュールは、下にある目的地に対して鳥瞰的な視界を有し、車両及び目的地に容易にレーザー通知を当てる。
ある実施形態では、レーザー式状態通知機能が、紙の駐車違反チケットを郵送する必要性に取って代わる。エンドユーザは、駐車違反のレーザー通知を受け取ると、以下に限定されるわけではないが、オンラインウェブサイト又はペイ・バイ・フォンを含むいくつかの媒体を通じて駐車違反の罰金を支払うと予想される。さらに、目的地カメラによってレーザー式状態通知を取り込んで、後で駐車違反及び通知の証拠を提供することもできる。
ある実施形態では、オンライン/電話/スマートフォン駐車スペース予約システムによって可能になる機能に、動的リアルタイム個人駐車スペース予約があり、この機能は、レーザー式状態通知機能を用いてさらに強化することができる。現在では、駐車スペース予約機能を提供する業者も存在するが、1つの特定の駐車スペースを自動化された形で物理的に予約する実用的な方法が存在しないので、この機能は、駐車スペースの近傍(例えば、駐車区画のいずれかの場所)のスペースの予約に制限される。また、スペースを予約したドライバーが駐車をして車を出した後に、予約した駐車スポットがいつ再び利用可能になるかを知る実用的な方法が存在しないので、通常、予約されたスペースは長時間にわたって空いたままになる。
対照的に、動的リアルタイム個人駐車スペース予約機能では、エンドユーザが、望む駐車スペース(例えば、クリスマスの買い物期間中にショッピングモールに最も近いスペース)を指定期間にわたって正確に指定することができる(例えば、将来的な日にちにわたって目的地の使用を予約することができる)。駐車スペースが予約されると、駐車スポットにレーザー通知を当てて、(例えば、他のドライバーへの警告として赤色で)その目的地が予約されていることを示すことができる。予約期間中にその目的地を別の車両が使用すると駐車違反になる。これにより、駐車場オペレータは、段階的な/割増料金の駐車スポット、及び駐車スペースの先行予約を提示することによって収益を増やすことができる。
ある実施形態では、駐車場オペレータが、特定の目的地を、予約を行った車両による使用のみに制限されるものとして指定することができる。この実施形態では、サーバシステム140が、所与の時点で利用可能な予約済み目的地の数を特定し、どれほどの未予約の目的地が利用可能な状態で残っているかに従って価格予約を決定することができる。ある実施形態では、サーバシステム140を、予約済みの目的地の使用に対して購入者が競合入札を提出できるように構成することができる。
ある実施形態では、ターンキープラットフォーム上に直接、又は第三機関の業者との協力によってペイ・バイ・フォン機能を提供することができる。最終的に、エンドユーザは、特定のIVR電話回線に電話し、目的地番号又は車両ナンバープレート番号及び駐車時間を入力することによって駐車料金を支払えるようになる。別の実施形態では、一般にウェブ対応スマートフォンを介してアクセスできるウェブサイトを通じてオンライン駐車料金支払いをサポートするための同じテーマに沿った変形形態がペイ・オンラインである。
ある実施形態では、エンドユーザが車両130を駐車するとすぐに、車両130が目的地を離れるまでの特定の駐車料金を請求するための肯定的な応答を促すテキストメッセージ又はその他の通知を受け取るような「プッシュ」技術の特徴を組み込むことができる。サーバシステム140は、識別カメラを介して車両130を識別し、この車両130が、クレジットカード又はその他の課金情報、及び携帯電話番号又はその他の連絡先が記録されている事前登録されたエンドユーザに関連することをさらに特定する。サーバシステム140は、目的地カメラを介して車両130が目的地に駐車したことを特定すると「プッシュ」シーケンスを開始して、支払い又は支払いの確認に関してドライバーに積極的に通知して関与する。支払処理を単純化することにより、駐車場収入の改善が実現される。
多くの従来の駐車メータシステムでは、エンドユーザが実際に使用したよりも長い時間に対する支払いを行った場合、超過時間がメータ上に残り、これを次のエンドユーザが使用することができる。開示する主題の実施形態では、サーバシステム140が、目的地カメラ125によって車両がいつ目的地を離れたかを正確に特定できるので、「持ち越された」支払済みの駐車時間を全てゼロにリセットすることができる。ただし、従来の道路脇メータは、一般に期限切れ前に期限切れフラグを作動させるための通信能力又はその他の知能を有していないので、これが1つの例外である。
サーバシステム140は、ユーザが駐車料金を支払いに来た時のユーザ経験を向上させるプッシュ技術ソフトウェアコンポーネントを提供するように構成することができる。プッシュ技術は、(1)テキストメッセージを介して支払シーケンスを開始すること、(2)事前登録されたユーザが自身のナンバープレートの写真を撮影し、例えば電子メール又はテキストメッセージを通じてサーバ140に写真を提供できるようにすること、(3)未登録ユーザが自身のナンバープレートの写真を撮影し、電子メール又はテキストメッセージを通じてこの写真をサーバシステム140に提供できるようにすること、及び(4)加入に基づくモデル下においてドライバーが一旦登録したら駐車料金を課されないようにすること、などの機能をサポートする。プッシュ技術のコンポーネントは、車両識別子検出ロジック、車両検出ロジック、データベース141及び支払ゲートウェイとやりとりする。項目(1)に関連して、プッシュ技術のコンポーネントは、駐車スペースなどの目的地の使用を開始したばかりの車両の車両識別子に基づいて、サーバシステム140に登録されている携帯電話番号に目的地の使用を開始したことを示すテキストメッセージをプッシュする。ドライバーが、「はい」で応答することによってテキストメッセージを承認すると、以下に限定されるわけではないが、目的地の使用に関する定額駐車料金などの適当な使用料を、登録口座に関連するクレジットカードに課金することができる。項目(2)に関連して、サーバシステム140に事前登録しているドライバーは、自身のナンバープレートの写真を撮影し、電子メール又はテキストメッセージを介してこの写真をサーバシステム140に送ることができる。この事前登録されているユーザの登録口座に関連するクレジットカードに使用料が課金される。項目(3)に関連して、サーバシステム140に登録されていないナンバープレートを有する車両の場合、ドライバーがナンバープレートの写真を撮影し、電子メール/テキストメッセージを介してこの写真をサーバシステム140に送ることができる。携帯電話サービスプロバイダがこのような課金機能へのアクセスをサポートしていてアクセスできる場合には、ユーザの毎月のモバイル装置の請求書に使用料を追加することができる。項目(4)に関連して、ドライバーが一旦署名すると、全ての使用料(又は少なくとも全ての駐車料)を登録クレジットカードで自動的に支払うことができる。このプッシュ技術のソフトウェアコンポーネントは、「駐車禁止」区域に車両を駐車することなどの不適切な目的地の使用をサーバシステム140が特定した場合、ユーザに自動的にテキストメッセージを送信するように構成することもできる。
サーバシステム140は、新たに違反として識別される目的地の使用の全ての発生状況を調べ、この発生状況を、後述するナンバープレート検索モジュール又はナンバープレート転送モジュールなどのシステム構成において指定される対応する目的地に割り当てる駐車違反前処理ロジックソフトウェアコンポーネントを提供するように構成することができる。駐車違反前処理ロジックソフトウェアコンポーネントは、データベース141、システム設定ユーティリティ、及び第三機関のAPIとやりとりする。駐車違反前処理ロジックソフトウェアコンポーネントは、(1)サーバシステム140に含まれている他のソフトウェア処理によって識別された違反を待ち行列に加え、(2)待ち行列内の次の違反を調べ、(3)目的地及び車両による検出された目的地の使用に関連してシステム設定ユーティリティを通じて設定されている規則を検証することによって目的地の使用が違反であることを検証し、(4)この違反をナンバープレート処理ロジックに割り当て、(5)待ち行列に加えられた他のいずれかの違反を調べ、又はその後の違反の識別を待つように構成することができる。
サーバシステム140は、車両が期限切れタグを有しているかどうかを識別画像から特定するように構成することができる。この識別画像は、固定識別カメラ120を用いて取り込むことができるが、通常の距離及び車両速度、並びにナンバープレート上の通常の小型サイズの期限日インジケータでは、車両が期限切れタグを有しているかどうかを識別画像のみから判定することは一般に不可能である。静止車両のナンバープレートにズームインするPTZ対応カメラを識別カメラ又は目的地カメラのいずれかと共に使用すれば、ナンバープレートにズームインして、車両が期限切れタグを有しているかどうかを判定するのに十分な細部を取得画像のみから取得することができる。ある実施形態では、例えばスマートフォン又はモバイル装置150に含まれているカメラを含むモバイルカメラ又はハンドヘルドカメラを代わりに用いて識別画像を取り込むことができる。多くの場合、このようなソースから取得された識別画像は、車両が期限切れタグを有しているかどうかを識別画像のみから判定するのに十分な細部を有する。ある実施形態では、サーバシステム140を、画像のみを使用してタグが期限切れであるかどうかを判定するのではなく、APIを介して自治体のデータベースに問い合わせ、特定のナンバープレート番号の車両登録が期限切れであるかどうかを判定するように構成することができる。サーバシステム140は、車両が期限切れタグを有していると判定した場合、この車両を自治体に報告するように構成することができる。
サーバシステム140は、駐車違反前処理ロジックコンポーネントによって割り当てられた違反などの、識別された目的地使用違反を取り上げ、これを登録所有者(RO)/目的地使用違反に関与した車両のユーザのいずれか、又は目的地の責任を負う駐車場オペレータに対する対応項目に変換するナンバープレート処理ロジックソフトウェアコンポーネントを提供するように構成することもできる。例えば、この対応項目は、駐車違反切符を登録所有者に自動的に郵送すること、又はナンバープレート番号を駐車場管理局の画面上に表示することなどの形をとることができる。ナンバープレート処理ロジックソフトウェアコンポーネントは、駐車違反前処理ロジックソフトウェアコンポーネント、システム設定ユーティリティ、及びデータベース141とやりとりする。ナンバープレート処理ロジックコンポーネントは、目的地に関連してシステム設定ユーティリティを介して指定されている1又はそれ以上の業務規則をチェックして、適切な対応項目を決定するように構成することができる。例えば、業務規則がナンバープレート検索を指定している場合、自治体又は民間企業によって提供されるAPIなどを介して特定のタイプのナンバープレート検索を指定することもできる。この時、ナンバープレート検索は指定通りに行われる。また、業務規則は、APIを介して登録所有者に駐車チケットを郵送すること、又は登録所有者の郵送先住所、及び違反に関する他のいずれかの関連情報のみを駐車場オペレータに提供することなどの下位選択肢を識別することもできる。別の例では、業務規則がナンバープレート情報の転送を指定している場合、ナンバープレート処理ロジックコンポーネントは、指定されている特定のタイプのナンバープレート情報転送を確認し、これに従ってナンバープレート情報を転送する。
ナンバープレート車両識別子から登録所有者の郵送先住所を識別する目的でナンバープレート検索APIの選択肢を利用するには、民間企業が提供するものなどのナンバープレートデータベースが存在し、ナンバープレートの特定の州/県に属するナンバープレートの検索に利用可能でなければならない。また、このようなデータベースの使用は、このような商業的に実現可能な検索に関連するあらゆる料金の面でも妥当でなければならない。上記のいずれかの条件が実現されない場合、別の選択肢として、通常は地方の警察署などを介してナンバープレート記録にアクセスできる自治体組織に問題のナンバープレートを提供することを挙げることができる。
ナンバープレート処理ロジックソフトウェアコンポーネントは、ナンバープレート検索追跡サブモジュールを含むことができる。ナンバープレート検索追跡サブモジュールは、車両の登録所有者の郵送先住所を検索するためにナンバープレートデータベースに対してAPI呼出しを行うように構成することができる。このようなデータベースの例としては、ニューヨーク州車両関連部局によって提供されるHTTPベースのダイヤルイン検索アカウントAPI、米国自動車管理者協会(AAMVA)又はその他の保険会社によって提供されるデータベースサービス、及びPublicData.comなどの公共記録のオンライン収集物が挙げられる(多くのこのような収集物は政府又は企業によって管理されているデータベースよりも信頼性が低いので、情報が有効かつ正確であることを確実にするためのさらなる努力が必要になる場合もある)。
また、ナンバープレート検索追跡サブモジュールは、目的地を悪用した車両に関連する登録所有者に自動的に駐車違反切符を郵送するように構成することもできる。例えば、この郵送処理は、限定するわけではないが、L−Mail.comなどの印刷/郵送サービスへのAPI呼出しを通じて自動化することができる。
ある実施形態では、ナンバープレート検索追跡サブモジュールを、所与の(ナンバープレートなどの)車両識別子が(例えば、システム設定ユーティリティを介して設定できる)指定期間内における目的地の以前の悪用に関連しているかどうかを確認するために、データベース141内の記録を作成し、維持し、再検討するように構成することができる。関連している場合、ナンバープレート検索追跡サブモジュールは、API呼出しに関連する業務コストを削減するために、以前に取得されたアドレスが有効かつ正確であると想定し、API呼出しをスキップして、システム内の以前に取得された郵送先住所を用いて違反切符を郵送することができる。指定日数後(例えば、やはりシステム設定ユーティリティを介して設定可能な実際の期間)に駐車違反切符の支払いが行われていなかったり、或いは違反切符が配送不可能として戻ってきたりした場合には、次のAPI呼出しを行って現在のアドレスを取得することができる。
ある実施形態では、以下に限定されるわけではないが、支払済み駐車の期限が過ぎている場合、又は車両が未納状態で駐車されている場合などの駐車違反について、サーバシステム140を、1又はそれ以上の取締官に緯度及び経度、又はおおよその所在地住所などの目的地の場所を通知するように構成することができる。この結果、取締官が違反車両に足を運び、現場で違反切符を発行することができる。ある実施形態では、サーバシステム140を、特定の違反車両に対処するのに最も適した個々の取締官を識別し、及び/又は配置するように構成することができる。この識別を行うための要素としては、例えば、違反車両からの取締官の距離又は作業負荷、或いは(例えば、違反車両を速やかに排除しなければならない場合には)違反車両を牽引すべきかどうかを挙げることができる。ある実施形態では、例えば取締官が少なすぎる場合、又は特定の取締官が複数の違反車両に対処している場合には、違反車両を待ち行列に入れる必要が生じることがある。ある実施形態では、複数の取締官に近くの違反車両を通知し、個々の取締官が特定の違反車両の処理を承諾することができる。サーバシステム140は、取締官の成績を追跡し、これを取締官の報酬又は割当制度に関連して使用できるように構成することもできる。ある実施形態では、取締官にモバイル装置150を持たせ、このモバイル装置150を、違反車両に対する違反切符を予め印刷しておいて、車両に違反切符を送付するのに掛かる時間を削減するように構成することができる。
サーバシステム140は、動的可変料率の駐車料金を提供するように構成することができる。ある実施形態では、サーバシステム140が、例えば1日の時間帯及び/又は週の曜日によって変動する、目的地のための異なる駐車料率を記録することができる。第1及び第2の料率が適用される期間にわたって車両が目的地を使用する場合には、サーバシステム140を、目的地の使用開始から第2の料率が適用されるまで適用される第1の料率と、車両が目的地を使用する残りの時間に適用される第2の料率とに基づいて目的地の合計使用料を決定するように構成することができる。ある実施形態では、サーバシステム140を、所与の範囲内の利用可能な目的地が収容できる車両の数を特定し、この特定された車両数に駐車料金又は駐車料率を基づかせるように構成することができる。例えば、サーバシステム140は、(例えば、残りの目的地が少ないという理由で)この数字が減少すると判断した場合、この少ない残り場所を使用し始める車両に高い料率を適用することができる。
サーバシステム140は、駐車場提供者がAPI又は設定ユーティリティを介して指定の目的地に指定駐車料率又は均一料金を適用すべき特定の事象を指定できるように構成することができる。例えば、ある駐車施設に関連する会場又はその近くの会場で午後7時〜11時にコンサートが行われる場合、この駐車施設は、この同じ日の夕方午後4時以降に駐車された車両に一率10ドルの料金を課すことができる。
サーバシステム140は、ドライバーが望む限りの長時間にわたって目的地に車両を駐車できる場合には罰金なし機能を提供し、(以下に限定されるわけではないが、時間当たり料金又は一率の終日料金などの)目的地に設定された規則に従ってクレジットカード又はその他の口座に課金できるように構成することができる。ある実施形態では、目的地に罰金なし機能を利用可能である旨を示すテキストメッセージ又は電子メールをドライバーにプッシュ又はその他の方法で送信し、ドライバーが、「はい」又は「罰金なし」などのメッセージで応答することなどによって罰金なし機能の使用を選択できるようにすることができる。ある実施形態では、サーバシステム140を、指定範囲内の又はサーバシステム140によって追跡される目的地全体にわたる全ての制約のない目的地に対して全体的に罰金なし機能を利用可能にするように構成することができる。一方で、サーバシステム140を、例えば午後3時〜6時のラッシュ時「駐車禁止」制約がある目的地などの制約された目的地に対しては罰金なし機能を提供しないように構成することもできる。
ある実施形態では、サーバシステム140が、車両の3D輪郭に基づいてプロファイリングを行うことができる。例えば、このようなプロファイリングは、以下に限定されるわけではないが、スポーツタイプ車両(SUV)、バン、セダン、クーペ又はオートバイなどのカテゴリに属するものとして車両を大まかにプロファイリングすることができる。また、車両を、明るい又は暗い色として分類することもできる。この車両プロファイリングは、以下に限定されるわけではないが、特定の近隣内における警察による盗難車両の追跡、誘拐事件速報システム、国土安全保障の必要性の支援などの非駐車用途に役立つこともできる。ある実施形態では、車両プロファイリングを用いてさらなる車両の特徴を提供し、車両を追跡する際に1つの追跡カメラと別の追跡カメラの間で比較を行うことができる。ある実施形態では、車両プロファイルが、自動駐車違反切符郵送処理のために車両の識別情報を確認する追加層を提供することができる。ある実施形態では、サーバシステム140に手動3D車両プロファイルが提供される。例えば、シボレーインパラの1つの手動3D車両プロファイルは、ボンネットの高さと乗員室の高さとトランクの高さの比率が1:2:1であることを示すことができる。
ある実施形態では、作動ビーム屈折ミラーに統合できるレーザー送信機を、1又はそれ以上の目的地にレーザービームを当てるように構成することができる。ある実施形態では、目的地又はその周囲に取り付けられた逆反射体にレーザービームを当てて、レーザー送信機に関連する受信機に帰還信号を提供することができる。レーザービームによって照射された目的地を車両が使用すると、レーザービーム又は帰還信号が遮断されることによって車両の存在が検出される。この検出に応答して、サーバシステム140を、付近のカメラによって目的地画像及び/又は識別子画像を取得するように構成することができる。
ある実施形態では、サーバシステム140を、上述した車両識別符号に関連する使用に加え、信号機制御されている交差点内を車両が不正通過した事象を検出するように、識別カメラを「赤信号カメラ」としても使用するように構成することができる。例えば、信号機が黄色から赤に変わった時に黄信号の終盤又は赤信号を不正通過した車両と、取り込まれた車両ナンバープレートとを識別することができ、従ってサーバシステム140は、撮像カメラを両方の目的で同時に利用するように構成される。この代わりに、又はこれに加えて、サーバシステム140は、車両の進行方向が赤信号である間に車両が交差点内に残って交通渋滞状態を引き起こすことがある「交差点通行妨害」違反を、識別カメラを用いて検出するように構成することもできる。
ある実施形態では、サーバシステム140を、以下に限定されるわけではないが、(ローンの支払いが滞っている車両を特定するための)回収会社、法的処置、国土安全保障などの第三機関のためのリアルタイム車両追跡サービスを提供するように構成することができる。サーバシステム140は、このような第三機関団体が、例えばナンバープレートなどの車両識別子によって関心車両を登録できるようにするAPIを提供することができる。サーバシステム140が車両識別子によって車両の存在を特定した場合には、登録団体に通知することができる。通知は、車両を最初に検出したことに関連して、及び/又は車両が停止していると判断される時に提供することができる。ある実施形態では、サーバシステム140が登録車両の移動記録を保存し、例えば、最新情報をリアルタイムで提示するように構成できる地図ベースのウェブインターフェイスを介してこの移動記録にアクセスすることができる。第三機関は、このAPIによって関心範囲を指定することができ、サーバシステム140は、関心範囲に入ったと判定されたあらゆる車両の識別及び追跡を行うように構成される。サーバシステム140は、追跡カメラによって取得された登録車両の画像を提供するように構成することもできる。ある実施形態では、過去の目的地の利用などのあらゆる保存された追跡情報を利用可能にして、ある人物の行方を(この人物が車両に関連すると想定して)経時的に再現することができる。ある実施形態では、サーバシステム140を、ドライバーの顔の画像を含む車両画像を取得するように構成するとともに、顔認識技術を実行して、ドライバーの顔の特徴が関心人物に一致することを確認するようにさらに構成することができる。
ある実施形態では、サーバシステム140を、所与の道路部分を横切ったと判断される車両の数などの交通量情報を特定して提供するように構成することができる。このような情報は、以下に限定されるわけではないが、現在観察されている交通量に応じて信号機などの交通システムを動的に制御すること、及びある期間に観察された交通量に基づいて建設要件を決定することを含む目的で使用することができる。この交通量情報は、時間及び/又は日付、及び/又は以下に限定されるわけではないが、移動方向及び車両のサイズ又は(SUV、トラック、自動車又はオートバイなどの)車種を含む、特定された車両の特徴を含むことができ、及び/又はこれらに基づいてフィルタ処理することができる。また、サーバシステム140は、例えば、各車両が交差点から出る方向に基づいて、どれほどの車両が車道の東向き部分から出た時に北又は南に向かうかなどの、道路の一部の進入及び/又は退出方向に関連する車の量を特定することもできる。ある実施形態では、サーバシステム140を、大型トラックによる指定道路へのアクセスを制御する際に、及び/又は大型トラックによる指定道路の使用料を決定することなどの、車種毎に車両に通行料を課す際に使用されるように構成することができる。
図5は、本発明の態様を実装できるコンピュータシステム500を示すブロック図である。コンピュータシステム500は、情報を伝送するためのバス502又はその他の通信機構、及びバス502に結合された、情報を処理するためのプロセッサ504を含む。コンピュータシステム500は、バス502に結合された、情報及びプロセッサ504が実行すべき命令を記憶するための、ランダムアクセスメモリ(RAM)又はその他の動的記憶装置などのメインメモリ506も含む。メインメモリ506は、プロセッサ504が実行すべき命令の実行中に一時変数又はその他の中間情報を記憶するために使用することもできる。コンピュータシステム500は、バス502に結合された、プロセッサ504の静的情報及び命令を記憶するためのリードオンリメモリ(ROM)508又はその他の静的記憶装置をさらに含む。情報及び命令を記憶するための、磁気ディスク又は光学ディスクなどの記憶装置510も設けられてバス502に結合される。
コンピュータシステム500は、コンピュータユーザに情報を表示するための、ブラウン管(CRT)又は液晶ディスプレイ(LCD)などのディスプレイ512にバス502を介して結合することができる。バス502には、英数字及びその他のキーを含む、プロセッサ504に情報及びコマンド選択を通信するための入力装置514も結合される。別のタイプのユーザ入力装置は、プロセッサ504に方向情報及びコマンド選択を通信してディスプレイ512上のカーソルの動きを制御するための、マウス、トラックボール又はカーソル方向キーなどのカーソル制御516である。通常、この入力装置は、(xなどの)第1の軸及び(yなどの)第2の軸という2つの軸における2つの自由度を有し、装置が平面内の位置を指定できるようにする。別のタイプのユーザ入力装置は、一般にディスプレイ512と、ディスプレイ512上のタッチを登録するハードウェアとを組み合わせたタッチ画面である。
本発明は、本明細書で説明した技術を実装するように集合的に構成及び/又はプログラムされた、コンピュータシステム500などの1又はそれ以上のコンピュータシステムの使用に関連する。本発明の1つの実施形態によれば、これらの技術は、メインメモリ506に含まれる1又はそれ以上の命令の1又はそれ以上のシーケンスをプロセッサ504が実行したことに応答してコンピュータシステム500によって実行される。このような命令は、記憶装置510などの別の機械可読媒体からメインメモリ506に読み込むことができる。メインメモリ506に含まれる命令シーケンスが実行されると、本明細書で説明した処理ステップをプロセッサ504が実行するようになる。別の実施形態では、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合わせて配線回路を用いて本発明を実施することができる。従って、本発明の実施形態は、ハードウェア回路とソフトウェアのいずれかの特定の組み合わせに限定されるものではない。
本明細書で使用している「機械可読媒体」という用語は、機械を特定の形で動作させるデータを提供することに関与するあらゆる媒体を意味する。コンピュータシステム500を用いて実装される実施形態では、例えばプロセッサ504に実行命令を与えることに様々な機械可読媒体が関与する。このような媒体は、以下に限定されるわけではないが、不揮発性媒体、揮発性媒体及び送信媒体を含む多くの形をとることができる。不揮発性媒体は、例えば、記憶装置510などの光学又は磁気ディスクを含む。揮発性媒体は、メインメモリ506などの動的メモリを含む。送信媒体は、バス502を含む電線を含む、同軸ケーブル、銅線及び光ファイバを含む。送信媒体は、無線及び赤外線データ通信中に生成されるもののような音波又は光波の形をとることもできる。全てのこのような媒体は、媒体が運ぶ命令を、機械に命令を読み込む物理的機構が検出できるように、有形及び/又は非一時的なものでなければならない。
一般的な形の機械可読媒体としては、例えば、フロッピー(登録商標)ディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は他のいずれかの磁気媒体、CD−ROM、他のいずれかの光学媒体、パンチカード、紙テープ、穴のパターンを有する他のいずれかの物理的媒体、RAM、PROM及びEPROM、FLASH−EPROM、他のいずれかのメモリチップ又はカートリッジ、後述するような搬送波、又はコンピュータが読み取ることができる他のいずれかの媒体が挙げられる。
1又はそれ以上の実行命令の1又はそれ以上のシーケンスをプロセッサ504に運ぶ際には、様々な形の機械可読媒体が関与することができる。例えば、これらの命令は、最初に遠隔コンピュータの磁気ディスクで運ぶことができる。遠隔コンピュータは、この命令を動的メモリにロードし、モデムを用いて電話回線を通じて送信することができる。コンピュータシステム500のローカルモデムは、電話回線上でデータを受け取り、赤外線送信機を用いてこのデータを赤外線信号に変換することができる。この赤外線信号で運ばれるデータを赤外線検出器が受け取ることができ、このデータを適当な回路がバス502上に配置することができる。バス502は、このデータをメインメモリ506に運び、ここからプロセッサ504が命令を取り出して実行する。任意に、メインメモリ506によって受け取られた命令を、プロセッサ504による実行前又は実行後に記憶装置510に記憶することもできる。
コンピュータシステム500は、バス502に結合された通信インターフェイス518も含む。通信インターフェイス518は、ローカルネットワーク522に接続されたネットワークリンク520に結合する双方向データ通信を提供する。例えば、通信インターフェイス518は、対応する種類の電話回線へのデータ通信接続を提供するための総合デジタル通信網(ISDN)カード又はモデムとすることができる。別の例として、通信インターフェイス518を、互換性のあるLANへのデータ通信接続を提供するためのローカルエリアネットワーク(LAN)カードとすることもできる。無線リンクを実装することもできる。あらゆるこのような実装では、通信インターフェイス518が、様々なタイプの情報を表すデジタルデータストリームを運ぶ電気信号、電磁信号又は光信号の送信及び受信を行う。
通常、ネットワークリンク520は、1又はそれ以上のネットワークを介して他のデータ装置へのデータ通信を提供する。例えば、ネットワークリンク520は、ローカルネットワーク522を介して、ホストコンピュータ524への、又はインターネットサービスプロバイダ(ISP)526が運用するデータ装置への接続を提供することができる。さらに、ISP526は、今では一般に「インターネット」528と呼ばれるワールドワイドパケットデータ通信ネットワークを介してデータ通信サービスを提供する。ローカルネットワーク522及びインターネット528は、いずれもデジタルデータストリームを運ぶ電気信号、電磁信号又は光信号を使用する。コンピュータシステム500との間でデジタルデータを運ぶ、様々なネットワークを介した信号、及びネットワークリンク520上の通信インターフェイス218を介した信号は、情報を伝送する例示的な形の搬送波である。
コンピュータシステム500は、(単複の)ネットワーク、ネットワークリンク520及び通信インターフェイス518を介してメッセージを送信し、プログラムコードを含むデータを受け取ることができる。インターネットの例では、サーバ530が、インターネット528、ISP526、ローカルネットワーク522及び通信インターフェイス518を介して、アプリケーションプログラムのための要求コードを送信することができる。
受け取られたコードは、受信時にプロセッサ204が実行することも、及び/又は後で実行できるように記憶装置510又はその他の不揮発性記憶装置に記憶することもできる。コンピュータシステム500は、このようにして搬送波の形のアプリケーションコードを取得することができる。
上述の明細書では、実装毎に変動し得る数多くの特定の詳細を参照しながら本発明の実施形態を説明した。従って、本発明が何であるか、及び本出願人が発明として意図するものが何であるかについての唯一排他的な指標は、本出願から生じる一連の請求項であり、これらの請求項は、このような請求項が生じる特定の形をとり、後続のあらゆる補正を含む。本明細書に明示的に記載した、このような請求項に含まれる用語のためのあらゆる定義は、請求項において使用するこのような用語の意味を規定するものである。従って、このような請求項の範囲は、請求項に明示的に記載していない限定事項、要素、特性、特徴、利点又は属性によって決して限定すべきではない。従って、本明細書及び図面は、限定的な意味ではなく例示的な意味で捉えるべきである。