パーキングメーターシステム
【課題】運用者による適切な運用が容易に維持できるようにしたパーキングメーターシステムを提供すること。
【解決手段】複数台のパーキングメーター１０を、通信網Ｎを介してサーバ２０に接続させ、各パーキングメーター１０から送信される情報をサーバ２０で収集し、パーキングメーター管理テーブルを作成し、これにより、サーバ２０は、このパーキングメーターシステムの運用者から要求があったとき、それに応じて、いつでも各パーキングメーター１０の状態を運用者に提供できるようにする。この結果、当該システムの運用者は、このサーバ２０から提供される情報に基づいて、各パーキングメーター１０の運用を適切に行なうことができる。
【解決手段】複数台のパーキングメーター１０を、通信網Ｎを介してサーバ２０に接続させ、各パーキングメーター１０から送信される情報をサーバ２０で収集し、パーキングメーター管理テーブルを作成し、これにより、サーバ２０は、このパーキングメーターシステムの運用者から要求があったとき、それに応じて、いつでも各パーキングメーター１０の状態を運用者に提供できるようにする。この結果、当該システムの運用者は、このサーバ２０から提供される情報に基づいて、各パーキングメーター１０の運用を適切に行なうことができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パーキングメーターシステムに係り、特に、比較的システム規模の大きな場合に好適なパーキングメーターシステムに関する。
【背景技術】
【０００２】
近代社会は車社会であり、このため都会なら、ほとんどの場合、駐車場問題がささやかれているのが現状であり、従って、或る程度の規模の都会になるとパーキングメーターが珍しくない。
ところで、一般的なパーキングメーターシステムの場合、利用者は、まず、車両を駐車枠内に正しく停車させ、パーキングメーターに車両が停車したことを感知させる。次に、手数料と呼ばれている料金を硬貨(例えば１００円硬貨)等でパーキングメーターに入金し、例えば必要に応じて領収書発行ボタンを手数料投入後２分以内に押すように定められている。
【０００３】
従って、利用者は、これらの手順を踏むことにより、予め定められた駐車時間以内(例えば６０分以内)で駐車することができるが、このとき手数料をパーキングメーターに入金しなかったり、予め定められた駐車時間を越えて駐車したりすると、駐車違反と見做されてしまう。
このときパーキングメーターシステムの適切な運用を維持するためには、駐車違反車両の監視が必要であるが、ここで広範囲に点在するパーキングメーターを係員が巡回して見回るのでは効率が悪い。
【０００４】
しかして駐車違反車両の監視が適切に行われない場合、公平感が損なわれてしまうので、社会通念上、好ましくない。
利用者にしてみても、折悪しく硬貨の持ち合わせがなかったり、気付かない内に駐車制限時間を越えて駐車してしまったなど、やむを得ず違反をしてしまう場合があるが、このとき駐車違反車両の監視がアトランダム(at random)であったとすれば、不公平感が生じてしまうことになり、従って、適切な監視が欠かせないのである。
【０００５】
ここで、或る提案によれば、駐車料金(手数料に相当)の支払いをキャッシュレス化したパーキングメーターシステムが従来から知られている(例えば特許文献１参照)。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−１８７２７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来のパーキングメーターシステムは、駐車違反の監視に配慮がされておらず、このためシステムの適切な運用に問題があった。
すなわち、従来のパーキングメーターシステムの場合、広範囲に点在するパーキングメーターを係員が巡回して見回る必要があり、このためシステムの適切な運用に問題が生じてしまうのである。
【０００８】
本発明は、上記の従来技術の問題点に鑑みてなされたもので、その目的は、運用者による適切な運用が容易に維持できるようにしたパーキングメーターシステムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的は、複数台のパーキングメーターに対応して少なくとも１台のサーバを備えたパーキングメーターシステムにおいて、前記複数台のパーキングメーターの各々に、パーキングメーター情報を送信する端末通信部と、車両が駐車枠内に停車したことを感知して感知情報を出力する車両感知部と、手数料の入金を確認して入金情報を出力する手数料確認部と、前記車両感知部からの入力と前記手数料確認部からの入力とからパーキングメーター情報を作成して前記端末通信部に出力する制御部とを設け、前記サーバには、パーキングメーター情報を受信しパーキングメーターシステムを運用する運用者との送受信を行う通信部と、パーキングメーター情報を格納するデータベース部と、前記データベース部を初期化するデータベース初期化部と、前記通信部が受信したパーキングメーター情報を前記データベース部に格納してパーキングメーターの使用状態を管理する状態管理部と、前記通信部が受信した運用者からの要求に応じて前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する運用制御部とを設け、前記１台のサーバにより、前記複数台のパーキングメーターの一元管理が得られるようにして達成される。
【発明の効果】
【００１０】
本発明によれば、広範囲に点在するパーキングメーターの状態が一元管理され、この結果、システムを管理し運営する運用者は、システムの中央管理部であるサーバに要求するだけで、システム内にある全てのパーキングメーターの使用状態が簡単に把握できる。
従って、本発明によれば、係員の巡回が不要になるので、運用者によるパーキングメーターシステムの適切な運用を容易に得ることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明によるパーキングメーターシステムの実施例１を示すブロック図である。
【図２】本発明によるパーキングメーターシステムの実施例１におけるパーキングメーター管理テーブルの説明図である。
【図３】本発明によるパーキングメーターシステムの実施例１をイメージして示したブロック図である。
【図４】本発明の実施例１における端末通信部の動作を説明するための流れ図である。
【図５】本発明の実施例１における車両感知部の動作を説明するための流れ図である。
【図６】本発明の実施例１における手数料確認部の動作を説明するための流れ図である。
【図７】本発明の実施例１における制御部の動作を説明するための流れ図である。
【図８】本発明の実施例１における状態管理部の全体の動作を説明するための流れ図である。
【図９】本発明の実施例１における状態管理部の空き処理動作を説明するための流れ図である。
【図１０】本発明の実施例１における状態管理部の利用中処理動作を説明するための流れ図である。
【図１１】本発明の実施例１における状態管理部の異常(未納)処理動作を説明するための流れ図である。
【図１２】本発明の実施例１における状態管理部の異常(超過)処理動作を説明するための流れ図である。
【図１３】本発明の実施例１における運用制御部の動作を説明するための流れ図である。
【図１４】本発明によるパーキングメーターシステムの実施例２を示すブロック図である。
【図１５】本発明によるパーキングメーターシステムの実施例２をイメージして示したブロック図である。
【図１６】本発明によるパーキングメーターシステムの実施例２におけるパーキングメーター管理テーブルの説明図である。
【図１７】本発明の実施例２における状態管理部の全体の動作を説明するための流れ図である。
【図１８】本発明の実施例２における状態管理部の利用中処理動作を説明するための流れ図である。
【図１９】本発明の実施例２における会員制御部の動作を説明するための流れ図である。
【発明を実施するための形態】
【００１２】
以下、本発明によるパーキングメーターシステムについて、図示の実施の形態により詳細に説明する。
【実施例１】
【００１３】
図１は、本発明によるパーキングメーターシステムの実施例１で、このシステムの場合、大別して、パーキングメーター１０とサーバ２０で構成されている。
このとき、パーキングメーター１０は、上記したように、通常、システム内に複数台、各駐車場所毎に設置されている。
そこで、これら複数台のパーキングメーター１０を、１台のサーバ２０の管理下に置き、これにより、このシステムにおいては、複数台のパーキングメーター１０がサーバ２０により一元管理できるようにしてある。
そこで、まず、パーキングメーター１０について説明すると、これには端末通信部１１と制御部１２、車両感知部１３、それに手数料確認部１４が備えられている。
【００１４】
そして、まず、端末通信部１１は、一般的な通信網と通信を確立し、制御部１２から入力されたパーキングメーター情報をサーバ２０に送信する働きをする。
このとき制御部１２には、上記したように、当該パーキングメーターを他のパーキングメーターと識別するための固有のＩＤ(パーキングメーターＩＤ：詳しくは後述)が個別に付与されている。
次に、車両感知部１３は、駐車枠内に車両が停車したことを感知する車両感知センサーを有し、車両感知センサーによる感知情報を出力する働きをする。例えば駐車枠内に車両が停車していた場合は感知情報“１”を出力し、駐車枠内に車両が停車していなければ感知情報“０”を出力する。
【００１５】
また、手数料確認部１４は、手数料がパーキングメーター１０に入金されたことを感知する手数料入金センサーを備え、手数料が入金されたら入金情報を出力する働きをする。例えば、手数料がパーキングメーターに入金された場合は入金情報“１”を出力する。
そこで、制御部１２は、パーキングメーター１０の起動に関わる初期設定を行った後、車両感知部１３から入力された感知情報と手数料確認部１４から入力された入金情報にそれぞれパーキングメーターＩＤを付与してパーキングメーター情報とし、それらを端末通信部１１に出力する働きをする。
【００１６】
次に、サーバ２０について説明すると、これには通信部２１と状態管理部２２、運用制御部２３、データベース部２４、それにデータベース初期化部２５が備えられている。
まず、通信部２１は、一般的な通信網と通信を確立し、パーキングメーター１０のそれぞれから送信されたパーキングメーター情報を受信し、状態管理部２２に出力する働きをする。
ここで、この通信部２１は、運用者から要求を受信し、運用制御部２３に出力する働きと、運用制御部２３から入力された運用者への応答を送信する働きもする。
【００１７】
次に、状態管理部２２は、通信部２１から入力されたパーキングメーター情報をデータベース部２４のパーキングメーター管理テーブルに格納し、パーキングメーターの使用状態を管理する働きをし、運用制御部２３は、通信部２１から入力された運用者からの要求に応じてデータベース部２４のパーキングメーター管理テーブルからリストを作成し、運用者に応答するため通信部２１に出力する働きをする。
そして、データベース初期化部２５は、サーバ２０の起動時にデータベース部２４を初期化する働きをするものである。
【００１８】
ここで、上記したデータベース部２４のパーキングメーター管理テーブルについて説明すると、これは、パーキングメーター管理情報をテーブル化したもので、図２に示すように、「パーキングメーターＩＤ」と「感知フラグ」、「入金フラグ」、「カウンタ」、それに「使用状態」の各項目からなる。
ここで、まず、「パーキングメーターＩＤ」とは、各パーキングメーター１０に付与されたＩＤのことである。そして、他の項目は、このパーキングメーターＩＤの各々に対応し、各ＩＤ毎に設定されている。
そして、まず、「感知フラグ」とは、各パーキングメーターの駐車枠内の車両有無を示すフラグのことで、例えば“０”が車両無しを、“１”が車両有りを示す。
【００１９】
次に、「入金フラグ」とは、各パーキングメーターの手数料入金の有無を示すフラグのことで、例えば“０”が未入金を、“１”が入金済を示す。
また、「カウンタ」とは、各パーキングメーターで車両を感知している時間をカウントしたもので、例えば分単位で表した時間となっている。
また、「使用状態」とは、各パーキングメーター２０の使用状態を示し、例えば“空き”状態、“利用中”状態、“異常(未納)”状態、“異常(超過)”状態の夫々を表したものである。
なお、このときの“異常(未納)”とは、手数料の未納による異常(駐車違反となる異常)のことであり、“異常(超過)”とは、駐車時間が超過したことによる異常(同じく駐車違反となる異常)のことである。
【００２０】
次に、この実施例１の動作について説明する。
まず、図３は、この実施例に係るパーキングメーターシステムの構成をイメージしたもので、この場合、パーキングメーター１０は、図示のように、システム内に複数台、設置され、一方、サーバ２０は、システム内に少なくとも１台だけ設置されていて、各パーキングメーター１０は、全てサーバ２０の管理下にあり、従って、従って、このサーバ２０は、いわゆる中央管理部を構成していることになる。
そして、このため、各々のパーキングメーター１０は、例えば電話回線などの一般的な通信網Ｎを介してサーバ２０に接続されるようになっている。
【００２１】
このときパーキングメーター１０は、それぞれ所望の場所に設置された後、通信網Ｎを介して、サーバ２０にパーキングメーター情報を送信する。
そして、サーバ２０は、各パーキングメーター１０から送信される情報を収集し、パーキングメーター管理テーブルを作成する。
この結果、サーバ２０は、このパーキングメーターシステムの運用者から要求があったとき、それに応じて、いつでも各パーキングメーター１０の状態を運用者に提供できるようにする。
そこで、運用者は、このサーバ２０から提供される情報に基づいて、各パーキングメーター１０の運用を適切に行なうことができる。
【００２２】
次に、このパーキングメーター１０の動作について説明する。
いま、ここで、パーキングメーター１０が設置され、電源が投入されたとする。
そうすると、図１に示す端末通信部１１、制御部１２、車両感知部１３、手数料確認部１４がそれぞれ起動される。
そこで、まず、このときの端末通信部１１の動作について、図４により説明する。
端末通信部１１は、起動されると、まず、通信網Ｎとの通信を確立する(処理１１１)。
【００２３】
ここで所定時間、待機(Wait)した後(処理１１２)、制御部１２に、当該端末通信部１１が起動したことを出力する(処理１１３)。
この後、端末通信部１１は、処理１１４から処理１１６までの一連の処理を繰り返す。すなわち、まず、制御部１２からのパーキングメーター情報の入力を確認し(処理１１４)、入力があるか否か判断し(処理１１５)、パーキングメーター情報が入力されたとき、それを送信するのである(処理１１６)。
【００２４】
次に、車両感知部１３の動作について、図５により説明する。
車両感知部１３は、起動後、まず、車両感知センサーを起動させる(処理１３１)。ここで、この車両感知センサーとは、駐車枠内に車両が停車したことを感知するセンサーのことである。
そして、ここで所定時間、待機(Wait)してから(処理１３２)、制御部１２に車両感知部１３が起動したことを出力する(処理１３３)。
この後、車両感知部１３は、処理１３４から処理１３７までの一連の処理を繰り返す。すなわち、まず、車両感知センサーの入力をみて(処理１３４)、車両の駐車枠内への停車を感知したか否か判断し(処理１３５)、ここで感知された場合は感知情報“１”を出力し(処理１３６)、感知されない場合は感知情報“０”を出力するのである(処理１３７)。
【００２５】
次に、手数料確認部１４の動作について、図６により説明する。
手数料確認部１４は、起動されたら手数料入金センサーを起動する(処理１４１)。ここで手数料入金センサーとは、手数料がパーキングメーターに入金されたことを感知するセンサーである。
そして、所定時間、待機(Wait)してから(処理１４２)、制御部１２に手数料確認部１４が起動したことを出力する(処理１４３)。
この後、手数料確認部１４は、処理１４４から処理１４６までの一連の処理を繰り返す。すなわち、まず、手数料入金センサーからの入力を確認し(処理１４４)、入金したか否か判断する(処理１４５)。入金された場合は入金情報“１”を出力するのである(処理１４６)。
【００２６】
次に、制御部１２の動作について、図７により説明する。
制御部１２は、起動されると、まず、当該パーキングメーター１０に設定されているパーキングメーターＩＤを認識し、感知情報と入金情報の初期化を行う(処理１２１)。
なお、図４では処理１１２が、図５では処理１３２が、そして図６では処理１４２が、それぞれ設けてあるのは、この図７の処理１２１が終了する時間を待つためである。
次いで、端末通信部１１と車両感知部１３それに手数料確認部１４の起動を待ち(処理１２２)、この後、制御部１２は、処理１２３から処理１２８までの一連の処理を繰り返す。
【００２７】
すなわち、まず、車両感知部１３からの感知情報があるか否かを判断する(処理１２３)。そして、感知情報があれば、感知情報にパーキングメーターＩＤを付与してパーキングメーター情報とし(処理１２４)、端末通信部１１にパーキングメーター情報を出力する(処理１２５)。続いて手数料確認部１４からの入金情報があるか否かを判断し(処理１２６)、入金情報があれば、入金情報にパーキングメーターＩＤを付与してパーキングメーター情報とし(処理１２７)、当該パーキングメーター情報を端末通信部１１に出力するのである(処理１２８)。
【００２８】
次に、これら端末通信部１１と制御部１２、車両感知部１３、それに手数料確認部１４を備えたことによるパーキングメーター１０の動作について説明する。
いま、ここでパーキングメーターの利用者が駐車枠内に車両を停車したとする。この場合、車両感知部１３は、その車両感知センサーにより車両が駐車枠内に停車されたことを感知し、制御部１２に感知情報“１”を出力する。
そこで、制御部１２は、入力された感知情報にパーキングメーターＩＤを付与し、パーキングメーター情報として端末通信部１１に出力する。
そこで、端末通信部１１は、入力されたパーキングメーター情報を、通信網Ｎを介してサーバ２０に送信する。
【００２９】
次に、パーキングメーター利用者が駐車枠内に車両を停車後、パーキングメーターに手数料を入金したとする。この場合、手数料確認部１４は、手数料入金センサーにより入金を感知し、制御部１２に入金情報“１”を出力する。
そこで、制御部１２は、入力された入金情報にパーキングメーターＩＤを付与してパーキングメーター情報とし、それを端末通信部１１に出力する。
そして、端末通信部１１は、入力されたパーキングメーター情報を、通信網を介してサーバ２０に送信する。
【００３０】
次に、この後、利用者が、パーキングメーターの利用を終えて駐車枠内から車両を移動したときの動作について説明する。
この場合、車両感知部１３が、車両感知センサーにより車両が駐車枠内に停車されていないことを感知し、制御部１２に感知情報“０”を出力する。
そこで、制御部１２は、入力された感知情報にパーキングメーターＩＤを付与してパーキングメーター情報とし、それを端末通信部１１に出力する。
この結果、端末通信部１１は、入力されたパーキングメーター情報を、通信網Ｎを介してサーバ２０に送信するのである。
【００３１】
次に、サーバ２０の動作について説明する。
ここで、いま、サーバ２０の電源が投入されたとすると、まず、データベース初期化部２５が働き、データベース部２４に設定してあるパーキングメーター管理テーブルを初期化する。
このとき、まず、パーキングメーター管理テーブルの項目「パーキングメーターＩＤ」については、サーバ２０の管理下にあるパーキングメーターの各々の“ＩＤ”に初期設定する。
次に、同じく項目「感知フラグ」と「入金フラグ」、それに「カウンタ」の各項目については、それぞれ“０”にクリアして初期設定とする。
そして、同じく項目「使用状態」については、“空き”に初期設定するのである。
【００３２】
次に、通信部２１は、通信網Ｎとの通信を確立し、これによりパーキングメーター１０から送信されるパーキングメーター情報が、サーバ２０において受信できるようにする。
また、この通信部２１は、サーバ２０に対する運用者の要求が有ったとき、運用者から受信できるようにし、その要求に対する応答が運用者に送信できるようにする。
【００３３】
次に、状態管理部２２の動作について説明すると、まず、この状態管理部２２の主要な働きは、データベース部２４に設定してあるパーキングメーター管理テーブルの各項目を、このサーバ２０の管理下にあるパーキングメーター１０の各々から受信される情報に基づいて、逐次、書き替えてゆく処理を実行することである。
そこで、状態管理部２２は、このサーバ２０の管理下にある全てのパーキングメーター１０に順次、アクセスし、各パーキングメーター１０のパーキングメーター情報を受信しては処理してゆく。
このため、状態管理部２２は、図８の処理を実行し、これにより図９〜図１２の何れかの処理を実行するようになっている。
【００３４】
状態管理部２２により図８の処理が開始されると、まず、パーキングメーターＩＤをテーブルの第１番目にあるパーキングメーターのＩＤに設定する(処理３０１)。例えば図２のパーキングメーター管理テーブルの場合、パーキングメーターＩＤはＰ０００１に設定されることになる。
次に、パーキングメーター管理テーブルから、いま、設定されたパーキングメーターＩＤの項目「使用状態」を読み出す(処理３０２)。
次いで、いま読み出した項目「使用状態」が“空き”か否かを判断し(処理３０３)、結果がＹ(肯定)のときは、ここで図９の処理に分岐する。
【００３５】
一方、処理３０３での結果がＮ(否定)のときは、次に、いま読み出した項目「使用状態」が“使用中”か否かを判断する(処理３０４)。
そして、結果がＹ(肯定)のときは、ここで図１０の処理に分岐し、結果がＮ(否定)のときは、次に、いま読み出した項目「使用状態」が“異常(未納)”か否かを判断する(処理３０５)。
そして、結果がＹ(肯定)のときは、ここで図１１の処理に分岐し、結果がＮ(否定)のときは、ここで図１２の処理に分岐するのである。
そこで、次に、図９〜図１２の各々における処理について説明する。
【００３６】
まず、図９の処理について説明する。
この場合、まず、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断する(処理３１１)。
そして、感知情報を受信していなかったら、ここで、直ちに図９の処理３０６に進む。
しかして、感知情報を受信していた場合は、データベース部２４の当該ＩＤのパーキングメーターの感知フラグを更新し(処理３１２)、この後、いま更新した感知フラグが“１”か否か判断し(処理３１３)、感知フラグが“０”の場合、ここで、図８の処理３０６に進む。
しかして、感知フラグが“１”の場合は、パーキングメーター管理テーブルの当該ＩＤの使用状態を“空き”から“利用中”に書き替えてから(処理３１４)、図８の処理３０６に進むのである。
【００３７】
次に、図１０の処理について説明する。
この場合、まず、通信部２１が当該ＩＤのパーキングメーターの入金情報を受信したか否か判断する(処理３３１)。
そして、まず、結果がＹ(肯定)、つまり、入金情報を受信していた場合は、データベース部２４の当該パーキングメーターの入金フラグを更新し(処理３３２)、次いで、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断する(処理３３３)。
ここで、感知情報を受信していた場合は、データベース部２４の当該パーキングメーターの感知フラグを更新し(処理３３４)、次いで、更新した感知フラグが“０”か否か判断する(処理３３５)。
【００３８】
このとき、まず、更新した感知フラグが“０”であれば、ここで感知フラグと入金フラグとカウンタをクリアし(処理３３６)、使用状態を“利用中”から“空き”に書き替えた後(処理３３７)、直ちに図８の処理３０６に進む。
一方、処理３３３で感知情報を受信していなければ、或いは処理３３５で感知フラグが“０”でなければ、ここで、まず、カウンタをカウントアップさせる(処理３３８)。
そして、カウンタ値が入金時間(例えば１０分)を超えたか否か判断し(処理３３９)、超えていた場合には、更に入金フラグが“０”か否か判断し(処理３４０)、入金フラグが“０”であれば使用状態を“利用中”から“異常(未納)に書き替えた後(処理３４１)、図８の処理３０６に進む。
【００３９】
一方、処理３３９でカウンタ値が入金時間を超えていなければ、或いは処理３４０で入金フラグが“０”でなければ、次にカウンタ値が駐車時間(例えば６０分)を超えたか否か判断する(処理３４２)。
そして、カウンタ値が駐車時間(例えば６０分)を超えていなかったら、このまま図８の処理３０６に進む。
しかして、カウンタ値が駐車時間(例えば６０分)を超えていれば、使用状態を“利用中”から“異常(超過)”に書き替えた後(処理３４３)、図８の処理３０６に進むのである。
【００４０】
次に、図１１の処理について説明する。
この場合、まず、通信部２１が当該パーキングメーターの入金情報を受信したか否か判断する(処理３６１)。
ここで入金情報を受信していた場合は、データベース部２４の当該パーキングメーターの入金フラグを更新し(処理３６２)、使用状態を“異常(未納)”から“利用中”に書き替える(処理３６３)。
次に、カウンタをカウントアップし(処理３６４)、次いで、カウンタ値が駐車時間(例えば６０分)を超えたか否か判断する(処理３６５)。
そして、まず、カウンタ値が駐車時間(例えば６０分)を超えていなかった場合、このまま図８の処理３０６に進む。
しかして、超えていた場合、使用状態を“異常(未納)”から“異常(超過)”に、若しくは“利用中”から“異常(超過)”に書き替えた後(処理３６６)、図８の処理３０６に進むのである。
【００４１】
次に、図１２の処理について説明する。
この場合、まず、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断し(処理３７１)、ここで感知情報を受信していなかったら、このまま図８の処理３０６に進む。
しかして、感知情報を受信していた場合は、データベース部２４の当該パーキングメーターの感知フラグを更新し(処理３７２)、次いで、更新した感知フラグが“０”か否か判断する(処理３７３)。
そして、まず、更新した感知フラグが“０”でなかったら、このまま図８の処理３０６に進む。
しかして、“０”であった場合、ここで感知フラグと入金フラグ、それにカウンタをクリアし(処理３７４)、使用状態を“異常(駐車時間超過)”から“空き”に書き替えた後(処理３７５)、図８の処理３０６に進むのである。
【００４２】
そこで、次に、図８の処理３０６以降の処理について説明する。
この場合、まず、このときのパーキングメーターＩＤが、パーキングメーター管理テーブルの最後にあるパーキングメーターのＩＤと同じか否かを判断する。
そして、同じであったときは、図８の処理３０１の前に分岐し、一方、異なっていた場合は、パーキングメーターＩＤを次の番号のパーキングメーターＩＤに設定し、図８の処理３０１の後で処理３０２の前に分岐する。
【００４３】
この結果、図９〜図１２の何れかの処理は、パーキングメーター１０の各々毎に順次、周期的に繰り返され、従って、サーバ２０のパーキングメーター管理テーブルには、各パーキングメーター１０の使用状態が、ほとんどリアルタイムで逐次書き替え設定されていることになる。
そこで、このパーキングメーター管理テーブルをみることにより、各パーキングメーター１０の最新の使用状態を簡単に知ることができる。
【００４４】
次に、運用制御部２３の動作について説明する。
ここで、まず、この運用制御部２３の主要な働きは、このパーキングメーターシステムの管理者に、その管理下にあるパーキングメーター１０の各々の使用状態を、当該管理者の要求に応じで提供することであり、以下、その動作について、図１３により説明する。
この場合、まず、通信部２１が運用者からの要求を受信したか否か判断する(処理４０１)。そして、要求を受信していた場合、その要求内容に応じた処理を実行する(処理４０２)。
【００４５】
まず、運用者の要求が「全リスト」、すなわち全てのパーキングメーターの使用状態を把握したい場合、運用制御部２３は、サーバ２０の管理下にある全てのパーキングメーターの管理情報をデータベース部２４のパーキングメーター管理テーブルから読み出してリストを作成する(処理４０３)。
そして、通信部２１を介して運用者にそのリストを送信するのである(処理４０６)。
次に、運用者の要求が「空きリスト」、すなわち空き状態にあるパーキングメーターを把握したい場合、運用制御部２３は、データベース部２４のパーキングメーター管理テーブルから、使用状態が“空き”になっているパーキングメーターの管理情報を読み出してリストを作成し(処理４０４)、通信部２１を介して運用者にそのリストを送信するのである(処理４０６)。
【００４６】
そして、運用者の要求が「異常リスト」、すなわち異常状態にあるパーキングメーターを把握したい場合、運用制御部２３は、データベース部２４のパーキングメーター管理テーブルから、使用状態が“異常(未納)”及び“異常(超過)”になっているパーキングメーターの管理情報を読み出してリストを作成し(処理４０５)、通信部２１を介して運用者にそのリストを送信するのである(処理４０６)。
従って、この実施例１によれば、中央管理部に相当するサーバ２０に要求するだけで、システム内にある全てのパーキングメーター１０の使用状態が把握でき、この結果、運用者によるパーキングメーターシステムの適切な運用が容易に維持できることになる。
【００４７】
例えば、いま、運用者が、異常状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、駐車違反車両があるパーキングメーターのリストが入手でき、従って、このリストに基づくことにより違反の取り締まりが効率化され、パーキングメーターシステムの適切な運用が維持できる。
また、例えば、運用者が、空き状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、利用者による空きパーキングメーターについての問い合わせに即時、的確に対応でき、パーキングメーターのより一層の効率的な利用に大きく寄与することができる。
【実施例２】
【００４８】
次に、本発明の他の実施例(実施例２)について説明する。
ここで、図１４は、実施例２に係るパーキングメーターシステムであり、そして、この実施例２が、図１〜図１４により説明した実施例１と異なっている主な点は、サーバ２０ａに会員制御部２６が付加され、これに応じて通信部２１ａによる処理が、実施例１の場合の通信部２１と異なっている点にある。
そこで、以下、この実施例２では、システムの中央管理部となるサーバを、サーバ２０ａとし、実施例１のサーバ２０とは異なっている点に重点をおいて説明する。
【００４９】
まず、この実施例２においても、パーキングメーター１０の構成と機能は、実施例１の場合と同じである。
一方、サーバ２０ａの場合、その通信部２１ａは、実施例１の通信部２１による処理に加え、更に利用者や会員からの要求を受信して会員制御部２６に出力する処理と、会員制御部２６から入力された会員への応答を送信する処理とを実行するものとして構成されている。
従って、この実施例２に係るパーキングメーターシステムの構成をイメージした場合は、図１５に示すようになる。
【００５０】
そこで、この場合も、パーキングメーター１０は、実施例１の場合と同様、パーキングメーターシステム内に複数存在し、それぞれ所望の場所に設置された後、一般的な通信網Ｎを介して、サーバ２０ａにパーキングメーター情報を送信する。
このとき、サーバ２０ａも、実施例１のサーバ２０と同じで、パーキングメーターシステム内に少なくとも１台だけ設置され、中央管理部として機能する。そして、各パーキングメーター１０からパーキングメーター情報を収集し、それを管理してデータベース部２４のパーキングメーター管理テーブルに格納し、パーキングメーターシステムを運用する運用者の要求に応じてパーキングメーターの情報が運用者に利用できるようにしている。
【００５１】
従って、これらの点は、実施例１の場合と同じであるが、ここで、このサーバ２０ａの場合、図１５に示されているように、更に、このパーキングメーターシステムの利用者を、希望に応じて会員に登録する処理を行い、会員に登録された場合、その要求に応じてパーキングメーター情報が利用でき、手数料のキャッシュレス化にも対応できるようにしてあり、この点で、実施例１の場合と異なっている。
なお、このパーキングメーターシステムの場合、会員になっていない一般の利用者でも利用できる点は、実施例１のシステムと同じであるが、この場合、パーキングメーター情報の開示を得ることはできない。
【００５２】
このため、このサーバ２０ａの場合、そのデータベース部２４には、図１６に示すように、パーキングメーター毎の管理情報を記憶するパーキングメーター管理テーブル(a)と、会員の情報を記憶する会員管理テーブル(b)の２種のテーブルが設定されている。
そして、まず、パーキングメーター管理テーブル(a)には、「パーキングメーターＩＤ」と「感知フラグ」、「入金フラグ」、「カウンタ」、それに「使用状態」の各項目が設定されるが、これらに加え、更に「会員フラグ」と「会員ＩＤ」を表す項目も設定されている。
【００５３】
ここで、まず、「パーキングメーターＩＤ」と「感知フラグ」、「入金フラグ」、「カウンタ」、それに「使用状態」の各項目は、実施例１の場合と同じである。
そして、「会員フラグ」は、パーキングメーターの利用者が会員であるか否かを表わす。例えば、利用者が非会員なら“０”とし、利用者が会員の場合は“１”とする。
次に、「会員ＩＤ」は、各パーキングメーターを会員が利用している場合、その会員のＩＤが設定される。
なお、これら「会員フラグ」と「会員ＩＤ」は、詳しくは後述するが、会員制御部２６により設定される。
【００５４】
次に、会員管理テーブル(b)は、「会員ＩＤ」と「メールアドレス」、「口座番号」、「利用中のパーキングメーターＩＤ」の各項目で構成される。
そして、まず、「会員ＩＤ」には、会員毎に付与されているＩＤ(例えば、“Ｍ０００１”)が設定される。
次に、「メールアドレス」には、サーバ２０ａから会員にパーキングメーター情報を通知する場合の通知先アドレスが設定される。
また、「口座番号」には、パーキングメーターの手数料を引き落す口座の番号(会員の口座番号)が設定される。
そして、「利用中のパーキングメーターＩＤ」には、このとき会員が利用中のパーキングメーターのＩＤ(例えば、“Ｐ０００１”」)が設定される。
尚、会員管理テーブルには、上記以外にも、電話番号や住所、パスワード等、会員又は個人を特定できる項目が設定されてもよい。
【００５５】
そこで、サーバ２０ａの状態管理部２２は、実施例１の状態管理部２２による処理に加え、更にパーキングメーター状態を会員へ通知する処理を行う。
このとき運用制御部２３とデータベース初期化部２５は、実施例１の場合と同じなので説明は省略し、会員制御部２６ａについて説明すると、これは、通信部２１ａから入力された利用者の会員登録を行い、データベース部２４の会員管理テーブル(b)に格納し、通信部２１ａから入力された会員の要求に応じて、データベース部２４にあるパーキングメーター管理テーブル(a)の各項目から所望のリストを作成し、会員に応答するため通信部２１ａに出力するものである。
【００５６】
次に、サーバ２０ａの動作について、更に詳しく説明する。
まず、サーバ２０ａが備えている状態管理部２２について説明すると、この状態管理部２２の主要な働きは、データベース部２４に設定してあるパーキングメーター管理テーブルの各項目を、このサーバ２０の管理下にあるパーキングメーター１０の各々から受信される情報に基づいて、逐次、書き替えてゆく処理を実行することである。
そこで、状態管理部２２は、このサーバ２０の管理下にある全てのパーキングメーター１０に順次、アクセスし、各パーキングメーター１０のパーキングメーター情報を受信しては処理してゆく。
【００５７】
ここで実施例１の場合の状態管理部２２は、図８の処理を実行し、これにより図９〜図１２の何れかの処理を実行するようになっている。
しかし、このサーバ２０ａの状態管理部２２の場合、実施例１の場合の図８の処理に代えて、図１７に記載の処理を実行するようになっている。
ここで、この図１７の処理が、図８の処理と異なっている点は、処理３０４での結果がＹ(肯定)になった後、分岐先である「使用中」処理が、図１８の処理になっている点だけである。
従って、図１７の処理を実行した後、図９と図１１、それに図１２の処理を実行した場合の動作は、実施例１の場合と同じなので、説明は省略し、図１８の処理が実行された場合についてだけ説明する。
【００５８】
そこで、いま、サーバ２０ａの状態管理部２２が図１７の処理を開始し、処理３０３を実行した結果、図１８の処理に分岐したとする。
この場合、まず、通信部２１が当該ＩＤのパーキングメーターの入金情報を受信したか否か判断する(処理３３１)。
そして、まず、結果がＹ(肯定)、つまり、入金情報を受信していた場合は、データベース部２４の当該パーキングメーターの入金フラグを更新し(処理３３２)、次いで、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断する(処理３３３)。
ここで、感知情報を受信していた場合は、データベース部２４の当該パーキングメーターの感知フラグを更新し(処理３３４)、次いで、更新した感知フラグが“０”か否か判断する(処理３３５)。
【００５９】
このとき、まず、更新した感知フラグが“０”であれば、ここで感知フラグと入金フラグとカウンタをクリアし(処理３３６)、使用状態を“利用中”から“空き”に書き替えた後(処理３３７)、直ちに図１７の処理３０６に進む。
一方、処理３３３で感知情報を受信していなければ、或いは処理３３５で感知フラグが“０”でなければ、ここで、まず、カウンタをカウントアップさせ(処理３３８)、次いで、会員フラグが“１”か否か判断する(処理３５１)。
ここで、会員フラグが“１”で、会員が利用しているときは、次に、カウンタ値が事前通知時間(例えば５０分)を超えたか否か判断し(処理３５２)、超えていた場合、会員に通知し(処理３５３)、超えていなければ、会員に通知する処理(処理３５３)はスキップする。
また、この処理３５１において、会員フラグが“１”のとき、つまり会員が利用しているときは、ここで、予め登録されている当該会員の口座番号から手数料を引き落とす。
【００６０】
処理３５１で会員が利用していなければ、カウンタ値が入金時間(例えば１０分)を超えたか否か判断し(処理３３９)、超えていた場合には、更に入金フラグが“０”か否か判断し(処理３４０)、入金フラグが“０”であれば使用状態を“利用中”から“異常(未納)に書き替えた後(処理３４１)、図１７の処理３０６に進む。
つまり、会員であれば、手数料は予め登録された口座番号から引き落とされるので、処理３３９と処理３４０はスキップされ、この結果、異常(未納)に書き替えられることはない。
【００６１】
一方、処理３３９でカウンタ値が入金時間を超えていなければ、或いは処理３４０で入金フラグが“０”でなければ、又は処理３５１で会員であれば、次に、カウンタ値が駐車時間(例えば６０分)を超えたか否か判断する(処理３４２)。
そして、カウンタ値が駐車時間(例えば６０分)を超えていなかったら、このまま図１７の処理３０６に進む。
しかして、カウンタ値が駐車時間(例えば６０分)を超えていれば、使用状態を“利用中”から“異常(超過)”に書き替えた後(処理３４３)、図１７の処理３０６に進むのである。
【００６２】
このとき、運用制御部２３については、実施例１の場合と同じなので、説明は省略する。
従って、この実施例２によっても、中央管理部に相当するサーバ２０に要求するだけで、システム内にある全てのパーキングメーター１０の使用状態が把握でき、この結果、運用者によるパーキングメーターシステムの適切な運用が容易に維持できるなど、実施例１と同じ利点が得られることになる。
【００６３】
例えば、運用者が、異常状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、駐車違反車両があるパーキングメーターのリストが入手でき、従って、このリストに基づくことにより違反の取り締まりが効率化され、パーキングメーターシステムの適切な運用が維持でき、例えば、運用者が、空き状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、利用者による空きパーキングメーターについての問い合わせに即時、的確に対応でき、パーキングメーターのより一層の効率的な利用に大きく寄与することができる。
【００６４】
次に、サーバ２０ａにおける会員制御部２６の動作について、更に図１９により説明する。
この会員制御部２６は、上記したように、利用者から要求があった場合に対応したもので、このため、定期的に処理を開始する。
そして、まず、通信部２１が利用者からの要求を受信したか否か判断し(処理５０１)、要求が受信されなければ、ここで処理を終わる。
要求が受信されていれば、次に、利用者が登録済みの会員か否か判断し(処理５０２)、登録済みで無ければ会員登録する(処理５０３)。
【００６５】
この会員登録は、利用者に会員ＩＤを付与し、サーバ２０ａが会員に情報を提供するためのメールアドレスと、手数料を引き落とすのに必要な口座番号とをデータベース部２４ａの会員管理テーブル(図１６(b))に格納する処理のことである。
そして、処理５０２での結果が登録済みであれば、或いは処理５０３で会員登録した場合は、ここで会員が要求している内容に応じた処理にそれぞれ分岐をする(処理５０４)。このときに許されている要求とは、「空き検索」と「利用申請」、それに「残り時間照会」の３種である。
【００６６】
そこで、いま、会員の要求が、空いているパーキングメーターを検索すること、すなわち「空き検索」であった場合、会員制御部２６は、データベース部２４のパーキングメーター管理テーブル(図１６(a))から、使用状態が空き状態のパーキングメーターを検索してリストを作成し、そのリストを会員が登録したメールアドレスに、通信部２１ａを介して送信する(処理５０５)。
【００６７】
次に、会員の要求が、パーキングメーターの利用を申請すること、すなわち「利用申請」であった場合、会員は、パーキングメーター１０の駐車枠内に車両を停車して利用を開始する際、そのパーキングメーターのＩＤ、つまりパーキングメーターＩＤをサーバ２０ａに送信する。
そこで、会員制御部２６は、データベース部２４のパーキングメーター管理テーブルの当該パーキングメーターの会員フラグの欄に“１”を設定し、会員ＩＤの欄に利用する会員のＩＤを設定し、会員管理テーブルの当該会員の利用中のパーキングメーターＩＤの欄に申請されたパーキングメーターＩＤを設定するのである(処理５０６)。
【００６８】
また、会員の要求が、利用中のパーキングメーターの残り時間を照会すること、すなわち「残り時間照会」であった場合、会員制御部２６は、データベース部２４の会員管理テーブルの当該会員の利用中のパーキングメーターＩＤの欄に格納されている値を読み取り、パーキングメーター管理テーブルから読み取った値と一致するパーキングメーターＩＤのカウンタ値を読み取り、駐車時間(例えば６０分)から差引いた値(＝残り時間)を、登録されている当該会員のメールアドレスに、通信部２１ａを介して送信するのである(処理５０７)。
【００６９】
従って、この実施例２の場合、利用者は、会員に登録することにより、手数料は自動的に引き落とされ、利用中のパーキングメーターの残り時間も知ることができる。
この結果、この実施例２によれば、硬貨の持ち合わせがなくてもパーキングメーターを利用することができ、気付かない内に駐車制限時間を越えて違反をしてしまう虞もないので、利用者の利便性の向上に大きく寄与することができる。
【００７０】
ここで、この実施例２の場合、以上に説明したことから、その実施態様の一例は、次のように記述できる。
複数台のパーキングメーターに対応して少なくとも１台のサーバを備えたパーキングメーターシステムにおいて、前記複数台のパーキングメーターの各々に、パーキングメーター情報を送信する端末通信部と、車両が駐車枠内に停車したことを感知して感知情報を出力する車両感知部と、手数料の入金を確認して入金情報を出力する手数料確認部と、前記車両感知部からの入力と前記手数料確認部からの入力とからパーキングメーター情報を作成して前記端末通信部に出力する制御部とを設け、前記サーバには、パーキングメーター情報を受信しパーキングメーターシステムを運用する運用者及び当該パーキングメーターシステムを利用する利用者の双方と送受信を行う通信部と、パーキングメーター情報と会員情報を格納するデータベース部と、前記データベース部を初期化するデータベース初期化部と、前記通信部が受信したパーキングメーター情報を前記データベース部に格納してパーキングメーターの使用状態を管理する状態管理部と、前記通信部が受信した運用者からの要求に応じて前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する運用制御部と、前記通信部が受信した利用者からの要求に応じて前記データベース部に会員情報を格納し前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する会員制御部とを設け、少なくとも前記１台のサーバにより、前記複数台のパーキングメーターの一元管理が得られるように構成したことを特徴とするパーキングメーターシステム。
【符号の説明】
【００７１】
１０ パーキングメーター
１１ 端末通信部
１２ 制御部
１３ 車両感知部
１４ 手数料確認部
２０ サーバ(実施例１)
２０ａ サーバ(実施例２)
２１ 通信部(実施例１)
２１ａ 通信部(実施例２)
２２ 状態管理部
２３ 運用管理部
２４ データベース部
２５ データベース初期化部
Ｎ 通信網(電話回線などによる一般の通信網)
【技術分野】
【０００１】
本発明は、パーキングメーターシステムに係り、特に、比較的システム規模の大きな場合に好適なパーキングメーターシステムに関する。
【背景技術】
【０００２】
近代社会は車社会であり、このため都会なら、ほとんどの場合、駐車場問題がささやかれているのが現状であり、従って、或る程度の規模の都会になるとパーキングメーターが珍しくない。
ところで、一般的なパーキングメーターシステムの場合、利用者は、まず、車両を駐車枠内に正しく停車させ、パーキングメーターに車両が停車したことを感知させる。次に、手数料と呼ばれている料金を硬貨(例えば１００円硬貨)等でパーキングメーターに入金し、例えば必要に応じて領収書発行ボタンを手数料投入後２分以内に押すように定められている。
【０００３】
従って、利用者は、これらの手順を踏むことにより、予め定められた駐車時間以内(例えば６０分以内)で駐車することができるが、このとき手数料をパーキングメーターに入金しなかったり、予め定められた駐車時間を越えて駐車したりすると、駐車違反と見做されてしまう。
このときパーキングメーターシステムの適切な運用を維持するためには、駐車違反車両の監視が必要であるが、ここで広範囲に点在するパーキングメーターを係員が巡回して見回るのでは効率が悪い。
【０００４】
しかして駐車違反車両の監視が適切に行われない場合、公平感が損なわれてしまうので、社会通念上、好ましくない。
利用者にしてみても、折悪しく硬貨の持ち合わせがなかったり、気付かない内に駐車制限時間を越えて駐車してしまったなど、やむを得ず違反をしてしまう場合があるが、このとき駐車違反車両の監視がアトランダム(at random)であったとすれば、不公平感が生じてしまうことになり、従って、適切な監視が欠かせないのである。
【０００５】
ここで、或る提案によれば、駐車料金(手数料に相当)の支払いをキャッシュレス化したパーキングメーターシステムが従来から知られている(例えば特許文献１参照)。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−１８７２７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来のパーキングメーターシステムは、駐車違反の監視に配慮がされておらず、このためシステムの適切な運用に問題があった。
すなわち、従来のパーキングメーターシステムの場合、広範囲に点在するパーキングメーターを係員が巡回して見回る必要があり、このためシステムの適切な運用に問題が生じてしまうのである。
【０００８】
本発明は、上記の従来技術の問題点に鑑みてなされたもので、その目的は、運用者による適切な運用が容易に維持できるようにしたパーキングメーターシステムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的は、複数台のパーキングメーターに対応して少なくとも１台のサーバを備えたパーキングメーターシステムにおいて、前記複数台のパーキングメーターの各々に、パーキングメーター情報を送信する端末通信部と、車両が駐車枠内に停車したことを感知して感知情報を出力する車両感知部と、手数料の入金を確認して入金情報を出力する手数料確認部と、前記車両感知部からの入力と前記手数料確認部からの入力とからパーキングメーター情報を作成して前記端末通信部に出力する制御部とを設け、前記サーバには、パーキングメーター情報を受信しパーキングメーターシステムを運用する運用者との送受信を行う通信部と、パーキングメーター情報を格納するデータベース部と、前記データベース部を初期化するデータベース初期化部と、前記通信部が受信したパーキングメーター情報を前記データベース部に格納してパーキングメーターの使用状態を管理する状態管理部と、前記通信部が受信した運用者からの要求に応じて前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する運用制御部とを設け、前記１台のサーバにより、前記複数台のパーキングメーターの一元管理が得られるようにして達成される。
【発明の効果】
【００１０】
本発明によれば、広範囲に点在するパーキングメーターの状態が一元管理され、この結果、システムを管理し運営する運用者は、システムの中央管理部であるサーバに要求するだけで、システム内にある全てのパーキングメーターの使用状態が簡単に把握できる。
従って、本発明によれば、係員の巡回が不要になるので、運用者によるパーキングメーターシステムの適切な運用を容易に得ることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明によるパーキングメーターシステムの実施例１を示すブロック図である。
【図２】本発明によるパーキングメーターシステムの実施例１におけるパーキングメーター管理テーブルの説明図である。
【図３】本発明によるパーキングメーターシステムの実施例１をイメージして示したブロック図である。
【図４】本発明の実施例１における端末通信部の動作を説明するための流れ図である。
【図５】本発明の実施例１における車両感知部の動作を説明するための流れ図である。
【図６】本発明の実施例１における手数料確認部の動作を説明するための流れ図である。
【図７】本発明の実施例１における制御部の動作を説明するための流れ図である。
【図８】本発明の実施例１における状態管理部の全体の動作を説明するための流れ図である。
【図９】本発明の実施例１における状態管理部の空き処理動作を説明するための流れ図である。
【図１０】本発明の実施例１における状態管理部の利用中処理動作を説明するための流れ図である。
【図１１】本発明の実施例１における状態管理部の異常(未納)処理動作を説明するための流れ図である。
【図１２】本発明の実施例１における状態管理部の異常(超過)処理動作を説明するための流れ図である。
【図１３】本発明の実施例１における運用制御部の動作を説明するための流れ図である。
【図１４】本発明によるパーキングメーターシステムの実施例２を示すブロック図である。
【図１５】本発明によるパーキングメーターシステムの実施例２をイメージして示したブロック図である。
【図１６】本発明によるパーキングメーターシステムの実施例２におけるパーキングメーター管理テーブルの説明図である。
【図１７】本発明の実施例２における状態管理部の全体の動作を説明するための流れ図である。
【図１８】本発明の実施例２における状態管理部の利用中処理動作を説明するための流れ図である。
【図１９】本発明の実施例２における会員制御部の動作を説明するための流れ図である。
【発明を実施するための形態】
【００１２】
以下、本発明によるパーキングメーターシステムについて、図示の実施の形態により詳細に説明する。
【実施例１】
【００１３】
図１は、本発明によるパーキングメーターシステムの実施例１で、このシステムの場合、大別して、パーキングメーター１０とサーバ２０で構成されている。
このとき、パーキングメーター１０は、上記したように、通常、システム内に複数台、各駐車場所毎に設置されている。
そこで、これら複数台のパーキングメーター１０を、１台のサーバ２０の管理下に置き、これにより、このシステムにおいては、複数台のパーキングメーター１０がサーバ２０により一元管理できるようにしてある。
そこで、まず、パーキングメーター１０について説明すると、これには端末通信部１１と制御部１２、車両感知部１３、それに手数料確認部１４が備えられている。
【００１４】
そして、まず、端末通信部１１は、一般的な通信網と通信を確立し、制御部１２から入力されたパーキングメーター情報をサーバ２０に送信する働きをする。
このとき制御部１２には、上記したように、当該パーキングメーターを他のパーキングメーターと識別するための固有のＩＤ(パーキングメーターＩＤ：詳しくは後述)が個別に付与されている。
次に、車両感知部１３は、駐車枠内に車両が停車したことを感知する車両感知センサーを有し、車両感知センサーによる感知情報を出力する働きをする。例えば駐車枠内に車両が停車していた場合は感知情報“１”を出力し、駐車枠内に車両が停車していなければ感知情報“０”を出力する。
【００１５】
また、手数料確認部１４は、手数料がパーキングメーター１０に入金されたことを感知する手数料入金センサーを備え、手数料が入金されたら入金情報を出力する働きをする。例えば、手数料がパーキングメーターに入金された場合は入金情報“１”を出力する。
そこで、制御部１２は、パーキングメーター１０の起動に関わる初期設定を行った後、車両感知部１３から入力された感知情報と手数料確認部１４から入力された入金情報にそれぞれパーキングメーターＩＤを付与してパーキングメーター情報とし、それらを端末通信部１１に出力する働きをする。
【００１６】
次に、サーバ２０について説明すると、これには通信部２１と状態管理部２２、運用制御部２３、データベース部２４、それにデータベース初期化部２５が備えられている。
まず、通信部２１は、一般的な通信網と通信を確立し、パーキングメーター１０のそれぞれから送信されたパーキングメーター情報を受信し、状態管理部２２に出力する働きをする。
ここで、この通信部２１は、運用者から要求を受信し、運用制御部２３に出力する働きと、運用制御部２３から入力された運用者への応答を送信する働きもする。
【００１７】
次に、状態管理部２２は、通信部２１から入力されたパーキングメーター情報をデータベース部２４のパーキングメーター管理テーブルに格納し、パーキングメーターの使用状態を管理する働きをし、運用制御部２３は、通信部２１から入力された運用者からの要求に応じてデータベース部２４のパーキングメーター管理テーブルからリストを作成し、運用者に応答するため通信部２１に出力する働きをする。
そして、データベース初期化部２５は、サーバ２０の起動時にデータベース部２４を初期化する働きをするものである。
【００１８】
ここで、上記したデータベース部２４のパーキングメーター管理テーブルについて説明すると、これは、パーキングメーター管理情報をテーブル化したもので、図２に示すように、「パーキングメーターＩＤ」と「感知フラグ」、「入金フラグ」、「カウンタ」、それに「使用状態」の各項目からなる。
ここで、まず、「パーキングメーターＩＤ」とは、各パーキングメーター１０に付与されたＩＤのことである。そして、他の項目は、このパーキングメーターＩＤの各々に対応し、各ＩＤ毎に設定されている。
そして、まず、「感知フラグ」とは、各パーキングメーターの駐車枠内の車両有無を示すフラグのことで、例えば“０”が車両無しを、“１”が車両有りを示す。
【００１９】
次に、「入金フラグ」とは、各パーキングメーターの手数料入金の有無を示すフラグのことで、例えば“０”が未入金を、“１”が入金済を示す。
また、「カウンタ」とは、各パーキングメーターで車両を感知している時間をカウントしたもので、例えば分単位で表した時間となっている。
また、「使用状態」とは、各パーキングメーター２０の使用状態を示し、例えば“空き”状態、“利用中”状態、“異常(未納)”状態、“異常(超過)”状態の夫々を表したものである。
なお、このときの“異常(未納)”とは、手数料の未納による異常(駐車違反となる異常)のことであり、“異常(超過)”とは、駐車時間が超過したことによる異常(同じく駐車違反となる異常)のことである。
【００２０】
次に、この実施例１の動作について説明する。
まず、図３は、この実施例に係るパーキングメーターシステムの構成をイメージしたもので、この場合、パーキングメーター１０は、図示のように、システム内に複数台、設置され、一方、サーバ２０は、システム内に少なくとも１台だけ設置されていて、各パーキングメーター１０は、全てサーバ２０の管理下にあり、従って、従って、このサーバ２０は、いわゆる中央管理部を構成していることになる。
そして、このため、各々のパーキングメーター１０は、例えば電話回線などの一般的な通信網Ｎを介してサーバ２０に接続されるようになっている。
【００２１】
このときパーキングメーター１０は、それぞれ所望の場所に設置された後、通信網Ｎを介して、サーバ２０にパーキングメーター情報を送信する。
そして、サーバ２０は、各パーキングメーター１０から送信される情報を収集し、パーキングメーター管理テーブルを作成する。
この結果、サーバ２０は、このパーキングメーターシステムの運用者から要求があったとき、それに応じて、いつでも各パーキングメーター１０の状態を運用者に提供できるようにする。
そこで、運用者は、このサーバ２０から提供される情報に基づいて、各パーキングメーター１０の運用を適切に行なうことができる。
【００２２】
次に、このパーキングメーター１０の動作について説明する。
いま、ここで、パーキングメーター１０が設置され、電源が投入されたとする。
そうすると、図１に示す端末通信部１１、制御部１２、車両感知部１３、手数料確認部１４がそれぞれ起動される。
そこで、まず、このときの端末通信部１１の動作について、図４により説明する。
端末通信部１１は、起動されると、まず、通信網Ｎとの通信を確立する(処理１１１)。
【００２３】
ここで所定時間、待機(Wait)した後(処理１１２)、制御部１２に、当該端末通信部１１が起動したことを出力する(処理１１３)。
この後、端末通信部１１は、処理１１４から処理１１６までの一連の処理を繰り返す。すなわち、まず、制御部１２からのパーキングメーター情報の入力を確認し(処理１１４)、入力があるか否か判断し(処理１１５)、パーキングメーター情報が入力されたとき、それを送信するのである(処理１１６)。
【００２４】
次に、車両感知部１３の動作について、図５により説明する。
車両感知部１３は、起動後、まず、車両感知センサーを起動させる(処理１３１)。ここで、この車両感知センサーとは、駐車枠内に車両が停車したことを感知するセンサーのことである。
そして、ここで所定時間、待機(Wait)してから(処理１３２)、制御部１２に車両感知部１３が起動したことを出力する(処理１３３)。
この後、車両感知部１３は、処理１３４から処理１３７までの一連の処理を繰り返す。すなわち、まず、車両感知センサーの入力をみて(処理１３４)、車両の駐車枠内への停車を感知したか否か判断し(処理１３５)、ここで感知された場合は感知情報“１”を出力し(処理１３６)、感知されない場合は感知情報“０”を出力するのである(処理１３７)。
【００２５】
次に、手数料確認部１４の動作について、図６により説明する。
手数料確認部１４は、起動されたら手数料入金センサーを起動する(処理１４１)。ここで手数料入金センサーとは、手数料がパーキングメーターに入金されたことを感知するセンサーである。
そして、所定時間、待機(Wait)してから(処理１４２)、制御部１２に手数料確認部１４が起動したことを出力する(処理１４３)。
この後、手数料確認部１４は、処理１４４から処理１４６までの一連の処理を繰り返す。すなわち、まず、手数料入金センサーからの入力を確認し(処理１４４)、入金したか否か判断する(処理１４５)。入金された場合は入金情報“１”を出力するのである(処理１４６)。
【００２６】
次に、制御部１２の動作について、図７により説明する。
制御部１２は、起動されると、まず、当該パーキングメーター１０に設定されているパーキングメーターＩＤを認識し、感知情報と入金情報の初期化を行う(処理１２１)。
なお、図４では処理１１２が、図５では処理１３２が、そして図６では処理１４２が、それぞれ設けてあるのは、この図７の処理１２１が終了する時間を待つためである。
次いで、端末通信部１１と車両感知部１３それに手数料確認部１４の起動を待ち(処理１２２)、この後、制御部１２は、処理１２３から処理１２８までの一連の処理を繰り返す。
【００２７】
すなわち、まず、車両感知部１３からの感知情報があるか否かを判断する(処理１２３)。そして、感知情報があれば、感知情報にパーキングメーターＩＤを付与してパーキングメーター情報とし(処理１２４)、端末通信部１１にパーキングメーター情報を出力する(処理１２５)。続いて手数料確認部１４からの入金情報があるか否かを判断し(処理１２６)、入金情報があれば、入金情報にパーキングメーターＩＤを付与してパーキングメーター情報とし(処理１２７)、当該パーキングメーター情報を端末通信部１１に出力するのである(処理１２８)。
【００２８】
次に、これら端末通信部１１と制御部１２、車両感知部１３、それに手数料確認部１４を備えたことによるパーキングメーター１０の動作について説明する。
いま、ここでパーキングメーターの利用者が駐車枠内に車両を停車したとする。この場合、車両感知部１３は、その車両感知センサーにより車両が駐車枠内に停車されたことを感知し、制御部１２に感知情報“１”を出力する。
そこで、制御部１２は、入力された感知情報にパーキングメーターＩＤを付与し、パーキングメーター情報として端末通信部１１に出力する。
そこで、端末通信部１１は、入力されたパーキングメーター情報を、通信網Ｎを介してサーバ２０に送信する。
【００２９】
次に、パーキングメーター利用者が駐車枠内に車両を停車後、パーキングメーターに手数料を入金したとする。この場合、手数料確認部１４は、手数料入金センサーにより入金を感知し、制御部１２に入金情報“１”を出力する。
そこで、制御部１２は、入力された入金情報にパーキングメーターＩＤを付与してパーキングメーター情報とし、それを端末通信部１１に出力する。
そして、端末通信部１１は、入力されたパーキングメーター情報を、通信網を介してサーバ２０に送信する。
【００３０】
次に、この後、利用者が、パーキングメーターの利用を終えて駐車枠内から車両を移動したときの動作について説明する。
この場合、車両感知部１３が、車両感知センサーにより車両が駐車枠内に停車されていないことを感知し、制御部１２に感知情報“０”を出力する。
そこで、制御部１２は、入力された感知情報にパーキングメーターＩＤを付与してパーキングメーター情報とし、それを端末通信部１１に出力する。
この結果、端末通信部１１は、入力されたパーキングメーター情報を、通信網Ｎを介してサーバ２０に送信するのである。
【００３１】
次に、サーバ２０の動作について説明する。
ここで、いま、サーバ２０の電源が投入されたとすると、まず、データベース初期化部２５が働き、データベース部２４に設定してあるパーキングメーター管理テーブルを初期化する。
このとき、まず、パーキングメーター管理テーブルの項目「パーキングメーターＩＤ」については、サーバ２０の管理下にあるパーキングメーターの各々の“ＩＤ”に初期設定する。
次に、同じく項目「感知フラグ」と「入金フラグ」、それに「カウンタ」の各項目については、それぞれ“０”にクリアして初期設定とする。
そして、同じく項目「使用状態」については、“空き”に初期設定するのである。
【００３２】
次に、通信部２１は、通信網Ｎとの通信を確立し、これによりパーキングメーター１０から送信されるパーキングメーター情報が、サーバ２０において受信できるようにする。
また、この通信部２１は、サーバ２０に対する運用者の要求が有ったとき、運用者から受信できるようにし、その要求に対する応答が運用者に送信できるようにする。
【００３３】
次に、状態管理部２２の動作について説明すると、まず、この状態管理部２２の主要な働きは、データベース部２４に設定してあるパーキングメーター管理テーブルの各項目を、このサーバ２０の管理下にあるパーキングメーター１０の各々から受信される情報に基づいて、逐次、書き替えてゆく処理を実行することである。
そこで、状態管理部２２は、このサーバ２０の管理下にある全てのパーキングメーター１０に順次、アクセスし、各パーキングメーター１０のパーキングメーター情報を受信しては処理してゆく。
このため、状態管理部２２は、図８の処理を実行し、これにより図９〜図１２の何れかの処理を実行するようになっている。
【００３４】
状態管理部２２により図８の処理が開始されると、まず、パーキングメーターＩＤをテーブルの第１番目にあるパーキングメーターのＩＤに設定する(処理３０１)。例えば図２のパーキングメーター管理テーブルの場合、パーキングメーターＩＤはＰ０００１に設定されることになる。
次に、パーキングメーター管理テーブルから、いま、設定されたパーキングメーターＩＤの項目「使用状態」を読み出す(処理３０２)。
次いで、いま読み出した項目「使用状態」が“空き”か否かを判断し(処理３０３)、結果がＹ(肯定)のときは、ここで図９の処理に分岐する。
【００３５】
一方、処理３０３での結果がＮ(否定)のときは、次に、いま読み出した項目「使用状態」が“使用中”か否かを判断する(処理３０４)。
そして、結果がＹ(肯定)のときは、ここで図１０の処理に分岐し、結果がＮ(否定)のときは、次に、いま読み出した項目「使用状態」が“異常(未納)”か否かを判断する(処理３０５)。
そして、結果がＹ(肯定)のときは、ここで図１１の処理に分岐し、結果がＮ(否定)のときは、ここで図１２の処理に分岐するのである。
そこで、次に、図９〜図１２の各々における処理について説明する。
【００３６】
まず、図９の処理について説明する。
この場合、まず、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断する(処理３１１)。
そして、感知情報を受信していなかったら、ここで、直ちに図９の処理３０６に進む。
しかして、感知情報を受信していた場合は、データベース部２４の当該ＩＤのパーキングメーターの感知フラグを更新し(処理３１２)、この後、いま更新した感知フラグが“１”か否か判断し(処理３１３)、感知フラグが“０”の場合、ここで、図８の処理３０６に進む。
しかして、感知フラグが“１”の場合は、パーキングメーター管理テーブルの当該ＩＤの使用状態を“空き”から“利用中”に書き替えてから(処理３１４)、図８の処理３０６に進むのである。
【００３７】
次に、図１０の処理について説明する。
この場合、まず、通信部２１が当該ＩＤのパーキングメーターの入金情報を受信したか否か判断する(処理３３１)。
そして、まず、結果がＹ(肯定)、つまり、入金情報を受信していた場合は、データベース部２４の当該パーキングメーターの入金フラグを更新し(処理３３２)、次いで、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断する(処理３３３)。
ここで、感知情報を受信していた場合は、データベース部２４の当該パーキングメーターの感知フラグを更新し(処理３３４)、次いで、更新した感知フラグが“０”か否か判断する(処理３３５)。
【００３８】
このとき、まず、更新した感知フラグが“０”であれば、ここで感知フラグと入金フラグとカウンタをクリアし(処理３３６)、使用状態を“利用中”から“空き”に書き替えた後(処理３３７)、直ちに図８の処理３０６に進む。
一方、処理３３３で感知情報を受信していなければ、或いは処理３３５で感知フラグが“０”でなければ、ここで、まず、カウンタをカウントアップさせる(処理３３８)。
そして、カウンタ値が入金時間(例えば１０分)を超えたか否か判断し(処理３３９)、超えていた場合には、更に入金フラグが“０”か否か判断し(処理３４０)、入金フラグが“０”であれば使用状態を“利用中”から“異常(未納)に書き替えた後(処理３４１)、図８の処理３０６に進む。
【００３９】
一方、処理３３９でカウンタ値が入金時間を超えていなければ、或いは処理３４０で入金フラグが“０”でなければ、次にカウンタ値が駐車時間(例えば６０分)を超えたか否か判断する(処理３４２)。
そして、カウンタ値が駐車時間(例えば６０分)を超えていなかったら、このまま図８の処理３０６に進む。
しかして、カウンタ値が駐車時間(例えば６０分)を超えていれば、使用状態を“利用中”から“異常(超過)”に書き替えた後(処理３４３)、図８の処理３０６に進むのである。
【００４０】
次に、図１１の処理について説明する。
この場合、まず、通信部２１が当該パーキングメーターの入金情報を受信したか否か判断する(処理３６１)。
ここで入金情報を受信していた場合は、データベース部２４の当該パーキングメーターの入金フラグを更新し(処理３６２)、使用状態を“異常(未納)”から“利用中”に書き替える(処理３６３)。
次に、カウンタをカウントアップし(処理３６４)、次いで、カウンタ値が駐車時間(例えば６０分)を超えたか否か判断する(処理３６５)。
そして、まず、カウンタ値が駐車時間(例えば６０分)を超えていなかった場合、このまま図８の処理３０６に進む。
しかして、超えていた場合、使用状態を“異常(未納)”から“異常(超過)”に、若しくは“利用中”から“異常(超過)”に書き替えた後(処理３６６)、図８の処理３０６に進むのである。
【００４１】
次に、図１２の処理について説明する。
この場合、まず、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断し(処理３７１)、ここで感知情報を受信していなかったら、このまま図８の処理３０６に進む。
しかして、感知情報を受信していた場合は、データベース部２４の当該パーキングメーターの感知フラグを更新し(処理３７２)、次いで、更新した感知フラグが“０”か否か判断する(処理３７３)。
そして、まず、更新した感知フラグが“０”でなかったら、このまま図８の処理３０６に進む。
しかして、“０”であった場合、ここで感知フラグと入金フラグ、それにカウンタをクリアし(処理３７４)、使用状態を“異常(駐車時間超過)”から“空き”に書き替えた後(処理３７５)、図８の処理３０６に進むのである。
【００４２】
そこで、次に、図８の処理３０６以降の処理について説明する。
この場合、まず、このときのパーキングメーターＩＤが、パーキングメーター管理テーブルの最後にあるパーキングメーターのＩＤと同じか否かを判断する。
そして、同じであったときは、図８の処理３０１の前に分岐し、一方、異なっていた場合は、パーキングメーターＩＤを次の番号のパーキングメーターＩＤに設定し、図８の処理３０１の後で処理３０２の前に分岐する。
【００４３】
この結果、図９〜図１２の何れかの処理は、パーキングメーター１０の各々毎に順次、周期的に繰り返され、従って、サーバ２０のパーキングメーター管理テーブルには、各パーキングメーター１０の使用状態が、ほとんどリアルタイムで逐次書き替え設定されていることになる。
そこで、このパーキングメーター管理テーブルをみることにより、各パーキングメーター１０の最新の使用状態を簡単に知ることができる。
【００４４】
次に、運用制御部２３の動作について説明する。
ここで、まず、この運用制御部２３の主要な働きは、このパーキングメーターシステムの管理者に、その管理下にあるパーキングメーター１０の各々の使用状態を、当該管理者の要求に応じで提供することであり、以下、その動作について、図１３により説明する。
この場合、まず、通信部２１が運用者からの要求を受信したか否か判断する(処理４０１)。そして、要求を受信していた場合、その要求内容に応じた処理を実行する(処理４０２)。
【００４５】
まず、運用者の要求が「全リスト」、すなわち全てのパーキングメーターの使用状態を把握したい場合、運用制御部２３は、サーバ２０の管理下にある全てのパーキングメーターの管理情報をデータベース部２４のパーキングメーター管理テーブルから読み出してリストを作成する(処理４０３)。
そして、通信部２１を介して運用者にそのリストを送信するのである(処理４０６)。
次に、運用者の要求が「空きリスト」、すなわち空き状態にあるパーキングメーターを把握したい場合、運用制御部２３は、データベース部２４のパーキングメーター管理テーブルから、使用状態が“空き”になっているパーキングメーターの管理情報を読み出してリストを作成し(処理４０４)、通信部２１を介して運用者にそのリストを送信するのである(処理４０６)。
【００４６】
そして、運用者の要求が「異常リスト」、すなわち異常状態にあるパーキングメーターを把握したい場合、運用制御部２３は、データベース部２４のパーキングメーター管理テーブルから、使用状態が“異常(未納)”及び“異常(超過)”になっているパーキングメーターの管理情報を読み出してリストを作成し(処理４０５)、通信部２１を介して運用者にそのリストを送信するのである(処理４０６)。
従って、この実施例１によれば、中央管理部に相当するサーバ２０に要求するだけで、システム内にある全てのパーキングメーター１０の使用状態が把握でき、この結果、運用者によるパーキングメーターシステムの適切な運用が容易に維持できることになる。
【００４７】
例えば、いま、運用者が、異常状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、駐車違反車両があるパーキングメーターのリストが入手でき、従って、このリストに基づくことにより違反の取り締まりが効率化され、パーキングメーターシステムの適切な運用が維持できる。
また、例えば、運用者が、空き状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、利用者による空きパーキングメーターについての問い合わせに即時、的確に対応でき、パーキングメーターのより一層の効率的な利用に大きく寄与することができる。
【実施例２】
【００４８】
次に、本発明の他の実施例(実施例２)について説明する。
ここで、図１４は、実施例２に係るパーキングメーターシステムであり、そして、この実施例２が、図１〜図１４により説明した実施例１と異なっている主な点は、サーバ２０ａに会員制御部２６が付加され、これに応じて通信部２１ａによる処理が、実施例１の場合の通信部２１と異なっている点にある。
そこで、以下、この実施例２では、システムの中央管理部となるサーバを、サーバ２０ａとし、実施例１のサーバ２０とは異なっている点に重点をおいて説明する。
【００４９】
まず、この実施例２においても、パーキングメーター１０の構成と機能は、実施例１の場合と同じである。
一方、サーバ２０ａの場合、その通信部２１ａは、実施例１の通信部２１による処理に加え、更に利用者や会員からの要求を受信して会員制御部２６に出力する処理と、会員制御部２６から入力された会員への応答を送信する処理とを実行するものとして構成されている。
従って、この実施例２に係るパーキングメーターシステムの構成をイメージした場合は、図１５に示すようになる。
【００５０】
そこで、この場合も、パーキングメーター１０は、実施例１の場合と同様、パーキングメーターシステム内に複数存在し、それぞれ所望の場所に設置された後、一般的な通信網Ｎを介して、サーバ２０ａにパーキングメーター情報を送信する。
このとき、サーバ２０ａも、実施例１のサーバ２０と同じで、パーキングメーターシステム内に少なくとも１台だけ設置され、中央管理部として機能する。そして、各パーキングメーター１０からパーキングメーター情報を収集し、それを管理してデータベース部２４のパーキングメーター管理テーブルに格納し、パーキングメーターシステムを運用する運用者の要求に応じてパーキングメーターの情報が運用者に利用できるようにしている。
【００５１】
従って、これらの点は、実施例１の場合と同じであるが、ここで、このサーバ２０ａの場合、図１５に示されているように、更に、このパーキングメーターシステムの利用者を、希望に応じて会員に登録する処理を行い、会員に登録された場合、その要求に応じてパーキングメーター情報が利用でき、手数料のキャッシュレス化にも対応できるようにしてあり、この点で、実施例１の場合と異なっている。
なお、このパーキングメーターシステムの場合、会員になっていない一般の利用者でも利用できる点は、実施例１のシステムと同じであるが、この場合、パーキングメーター情報の開示を得ることはできない。
【００５２】
このため、このサーバ２０ａの場合、そのデータベース部２４には、図１６に示すように、パーキングメーター毎の管理情報を記憶するパーキングメーター管理テーブル(a)と、会員の情報を記憶する会員管理テーブル(b)の２種のテーブルが設定されている。
そして、まず、パーキングメーター管理テーブル(a)には、「パーキングメーターＩＤ」と「感知フラグ」、「入金フラグ」、「カウンタ」、それに「使用状態」の各項目が設定されるが、これらに加え、更に「会員フラグ」と「会員ＩＤ」を表す項目も設定されている。
【００５３】
ここで、まず、「パーキングメーターＩＤ」と「感知フラグ」、「入金フラグ」、「カウンタ」、それに「使用状態」の各項目は、実施例１の場合と同じである。
そして、「会員フラグ」は、パーキングメーターの利用者が会員であるか否かを表わす。例えば、利用者が非会員なら“０”とし、利用者が会員の場合は“１”とする。
次に、「会員ＩＤ」は、各パーキングメーターを会員が利用している場合、その会員のＩＤが設定される。
なお、これら「会員フラグ」と「会員ＩＤ」は、詳しくは後述するが、会員制御部２６により設定される。
【００５４】
次に、会員管理テーブル(b)は、「会員ＩＤ」と「メールアドレス」、「口座番号」、「利用中のパーキングメーターＩＤ」の各項目で構成される。
そして、まず、「会員ＩＤ」には、会員毎に付与されているＩＤ(例えば、“Ｍ０００１”)が設定される。
次に、「メールアドレス」には、サーバ２０ａから会員にパーキングメーター情報を通知する場合の通知先アドレスが設定される。
また、「口座番号」には、パーキングメーターの手数料を引き落す口座の番号(会員の口座番号)が設定される。
そして、「利用中のパーキングメーターＩＤ」には、このとき会員が利用中のパーキングメーターのＩＤ(例えば、“Ｐ０００１”」)が設定される。
尚、会員管理テーブルには、上記以外にも、電話番号や住所、パスワード等、会員又は個人を特定できる項目が設定されてもよい。
【００５５】
そこで、サーバ２０ａの状態管理部２２は、実施例１の状態管理部２２による処理に加え、更にパーキングメーター状態を会員へ通知する処理を行う。
このとき運用制御部２３とデータベース初期化部２５は、実施例１の場合と同じなので説明は省略し、会員制御部２６ａについて説明すると、これは、通信部２１ａから入力された利用者の会員登録を行い、データベース部２４の会員管理テーブル(b)に格納し、通信部２１ａから入力された会員の要求に応じて、データベース部２４にあるパーキングメーター管理テーブル(a)の各項目から所望のリストを作成し、会員に応答するため通信部２１ａに出力するものである。
【００５６】
次に、サーバ２０ａの動作について、更に詳しく説明する。
まず、サーバ２０ａが備えている状態管理部２２について説明すると、この状態管理部２２の主要な働きは、データベース部２４に設定してあるパーキングメーター管理テーブルの各項目を、このサーバ２０の管理下にあるパーキングメーター１０の各々から受信される情報に基づいて、逐次、書き替えてゆく処理を実行することである。
そこで、状態管理部２２は、このサーバ２０の管理下にある全てのパーキングメーター１０に順次、アクセスし、各パーキングメーター１０のパーキングメーター情報を受信しては処理してゆく。
【００５７】
ここで実施例１の場合の状態管理部２２は、図８の処理を実行し、これにより図９〜図１２の何れかの処理を実行するようになっている。
しかし、このサーバ２０ａの状態管理部２２の場合、実施例１の場合の図８の処理に代えて、図１７に記載の処理を実行するようになっている。
ここで、この図１７の処理が、図８の処理と異なっている点は、処理３０４での結果がＹ(肯定)になった後、分岐先である「使用中」処理が、図１８の処理になっている点だけである。
従って、図１７の処理を実行した後、図９と図１１、それに図１２の処理を実行した場合の動作は、実施例１の場合と同じなので、説明は省略し、図１８の処理が実行された場合についてだけ説明する。
【００５８】
そこで、いま、サーバ２０ａの状態管理部２２が図１７の処理を開始し、処理３０３を実行した結果、図１８の処理に分岐したとする。
この場合、まず、通信部２１が当該ＩＤのパーキングメーターの入金情報を受信したか否か判断する(処理３３１)。
そして、まず、結果がＹ(肯定)、つまり、入金情報を受信していた場合は、データベース部２４の当該パーキングメーターの入金フラグを更新し(処理３３２)、次いで、通信部２１が当該パーキングメーターの感知情報を受信したか否か判断する(処理３３３)。
ここで、感知情報を受信していた場合は、データベース部２４の当該パーキングメーターの感知フラグを更新し(処理３３４)、次いで、更新した感知フラグが“０”か否か判断する(処理３３５)。
【００５９】
このとき、まず、更新した感知フラグが“０”であれば、ここで感知フラグと入金フラグとカウンタをクリアし(処理３３６)、使用状態を“利用中”から“空き”に書き替えた後(処理３３７)、直ちに図１７の処理３０６に進む。
一方、処理３３３で感知情報を受信していなければ、或いは処理３３５で感知フラグが“０”でなければ、ここで、まず、カウンタをカウントアップさせ(処理３３８)、次いで、会員フラグが“１”か否か判断する(処理３５１)。
ここで、会員フラグが“１”で、会員が利用しているときは、次に、カウンタ値が事前通知時間(例えば５０分)を超えたか否か判断し(処理３５２)、超えていた場合、会員に通知し(処理３５３)、超えていなければ、会員に通知する処理(処理３５３)はスキップする。
また、この処理３５１において、会員フラグが“１”のとき、つまり会員が利用しているときは、ここで、予め登録されている当該会員の口座番号から手数料を引き落とす。
【００６０】
処理３５１で会員が利用していなければ、カウンタ値が入金時間(例えば１０分)を超えたか否か判断し(処理３３９)、超えていた場合には、更に入金フラグが“０”か否か判断し(処理３４０)、入金フラグが“０”であれば使用状態を“利用中”から“異常(未納)に書き替えた後(処理３４１)、図１７の処理３０６に進む。
つまり、会員であれば、手数料は予め登録された口座番号から引き落とされるので、処理３３９と処理３４０はスキップされ、この結果、異常(未納)に書き替えられることはない。
【００６１】
一方、処理３３９でカウンタ値が入金時間を超えていなければ、或いは処理３４０で入金フラグが“０”でなければ、又は処理３５１で会員であれば、次に、カウンタ値が駐車時間(例えば６０分)を超えたか否か判断する(処理３４２)。
そして、カウンタ値が駐車時間(例えば６０分)を超えていなかったら、このまま図１７の処理３０６に進む。
しかして、カウンタ値が駐車時間(例えば６０分)を超えていれば、使用状態を“利用中”から“異常(超過)”に書き替えた後(処理３４３)、図１７の処理３０６に進むのである。
【００６２】
このとき、運用制御部２３については、実施例１の場合と同じなので、説明は省略する。
従って、この実施例２によっても、中央管理部に相当するサーバ２０に要求するだけで、システム内にある全てのパーキングメーター１０の使用状態が把握でき、この結果、運用者によるパーキングメーターシステムの適切な運用が容易に維持できるなど、実施例１と同じ利点が得られることになる。
【００６３】
例えば、運用者が、異常状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、駐車違反車両があるパーキングメーターのリストが入手でき、従って、このリストに基づくことにより違反の取り締まりが効率化され、パーキングメーターシステムの適切な運用が維持でき、例えば、運用者が、空き状態にあるパーキングメーターのリストをサーバ２０に要求したとすれば、この場合は、利用者による空きパーキングメーターについての問い合わせに即時、的確に対応でき、パーキングメーターのより一層の効率的な利用に大きく寄与することができる。
【００６４】
次に、サーバ２０ａにおける会員制御部２６の動作について、更に図１９により説明する。
この会員制御部２６は、上記したように、利用者から要求があった場合に対応したもので、このため、定期的に処理を開始する。
そして、まず、通信部２１が利用者からの要求を受信したか否か判断し(処理５０１)、要求が受信されなければ、ここで処理を終わる。
要求が受信されていれば、次に、利用者が登録済みの会員か否か判断し(処理５０２)、登録済みで無ければ会員登録する(処理５０３)。
【００６５】
この会員登録は、利用者に会員ＩＤを付与し、サーバ２０ａが会員に情報を提供するためのメールアドレスと、手数料を引き落とすのに必要な口座番号とをデータベース部２４ａの会員管理テーブル(図１６(b))に格納する処理のことである。
そして、処理５０２での結果が登録済みであれば、或いは処理５０３で会員登録した場合は、ここで会員が要求している内容に応じた処理にそれぞれ分岐をする(処理５０４)。このときに許されている要求とは、「空き検索」と「利用申請」、それに「残り時間照会」の３種である。
【００６６】
そこで、いま、会員の要求が、空いているパーキングメーターを検索すること、すなわち「空き検索」であった場合、会員制御部２６は、データベース部２４のパーキングメーター管理テーブル(図１６(a))から、使用状態が空き状態のパーキングメーターを検索してリストを作成し、そのリストを会員が登録したメールアドレスに、通信部２１ａを介して送信する(処理５０５)。
【００６７】
次に、会員の要求が、パーキングメーターの利用を申請すること、すなわち「利用申請」であった場合、会員は、パーキングメーター１０の駐車枠内に車両を停車して利用を開始する際、そのパーキングメーターのＩＤ、つまりパーキングメーターＩＤをサーバ２０ａに送信する。
そこで、会員制御部２６は、データベース部２４のパーキングメーター管理テーブルの当該パーキングメーターの会員フラグの欄に“１”を設定し、会員ＩＤの欄に利用する会員のＩＤを設定し、会員管理テーブルの当該会員の利用中のパーキングメーターＩＤの欄に申請されたパーキングメーターＩＤを設定するのである(処理５０６)。
【００６８】
また、会員の要求が、利用中のパーキングメーターの残り時間を照会すること、すなわち「残り時間照会」であった場合、会員制御部２６は、データベース部２４の会員管理テーブルの当該会員の利用中のパーキングメーターＩＤの欄に格納されている値を読み取り、パーキングメーター管理テーブルから読み取った値と一致するパーキングメーターＩＤのカウンタ値を読み取り、駐車時間(例えば６０分)から差引いた値(＝残り時間)を、登録されている当該会員のメールアドレスに、通信部２１ａを介して送信するのである(処理５０７)。
【００６９】
従って、この実施例２の場合、利用者は、会員に登録することにより、手数料は自動的に引き落とされ、利用中のパーキングメーターの残り時間も知ることができる。
この結果、この実施例２によれば、硬貨の持ち合わせがなくてもパーキングメーターを利用することができ、気付かない内に駐車制限時間を越えて違反をしてしまう虞もないので、利用者の利便性の向上に大きく寄与することができる。
【００７０】
ここで、この実施例２の場合、以上に説明したことから、その実施態様の一例は、次のように記述できる。
複数台のパーキングメーターに対応して少なくとも１台のサーバを備えたパーキングメーターシステムにおいて、前記複数台のパーキングメーターの各々に、パーキングメーター情報を送信する端末通信部と、車両が駐車枠内に停車したことを感知して感知情報を出力する車両感知部と、手数料の入金を確認して入金情報を出力する手数料確認部と、前記車両感知部からの入力と前記手数料確認部からの入力とからパーキングメーター情報を作成して前記端末通信部に出力する制御部とを設け、前記サーバには、パーキングメーター情報を受信しパーキングメーターシステムを運用する運用者及び当該パーキングメーターシステムを利用する利用者の双方と送受信を行う通信部と、パーキングメーター情報と会員情報を格納するデータベース部と、前記データベース部を初期化するデータベース初期化部と、前記通信部が受信したパーキングメーター情報を前記データベース部に格納してパーキングメーターの使用状態を管理する状態管理部と、前記通信部が受信した運用者からの要求に応じて前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する運用制御部と、前記通信部が受信した利用者からの要求に応じて前記データベース部に会員情報を格納し前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する会員制御部とを設け、少なくとも前記１台のサーバにより、前記複数台のパーキングメーターの一元管理が得られるように構成したことを特徴とするパーキングメーターシステム。
【符号の説明】
【００７１】
１０ パーキングメーター
１１ 端末通信部
１２ 制御部
１３ 車両感知部
１４ 手数料確認部
２０ サーバ(実施例１)
２０ａ サーバ(実施例２)
２１ 通信部(実施例１)
２１ａ 通信部(実施例２)
２２ 状態管理部
２３ 運用管理部
２４ データベース部
２５ データベース初期化部
Ｎ 通信網(電話回線などによる一般の通信網)
【特許請求の範囲】
【請求項１】
複数台のパーキングメーターに対応して少なくとも１台のサーバを備えたパーキングメーターシステムにおいて、
前記複数台のパーキングメーターの各々に、
パーキングメーター情報を送信する端末通信部と、車両が駐車枠内に停車したことを感知して感知情報を出力する車両感知部と、手数料の入金を確認して入金情報を出力する手数料確認部と、前記車両感知部からの入力と前記手数料確認部からの入力とからパーキングメーター情報を作成して前記端末通信部に出力する制御部とを設け、
前記サーバには、
パーキングメーター情報を受信しパーキングメーターシステムを運用する運用者との送受信を行う通信部と、パーキングメーター情報を格納するデータベース部と、前記データベース部を初期化するデータベース初期化部と、前記通信部が受信したパーキングメーター情報を前記データベース部に格納してパーキングメーターの使用状態を管理する状態管理部と、前記通信部が受信した運用者からの要求に応じて前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する運用制御部とを設け、
少なくとも前記１台のサーバにより、前記複数台のパーキングメーターの一元管理が得られるように構成したことを特徴とするパーキングメーターシステム。
【請求項１】
複数台のパーキングメーターに対応して少なくとも１台のサーバを備えたパーキングメーターシステムにおいて、
前記複数台のパーキングメーターの各々に、
パーキングメーター情報を送信する端末通信部と、車両が駐車枠内に停車したことを感知して感知情報を出力する車両感知部と、手数料の入金を確認して入金情報を出力する手数料確認部と、前記車両感知部からの入力と前記手数料確認部からの入力とからパーキングメーター情報を作成して前記端末通信部に出力する制御部とを設け、
前記サーバには、
パーキングメーター情報を受信しパーキングメーターシステムを運用する運用者との送受信を行う通信部と、パーキングメーター情報を格納するデータベース部と、前記データベース部を初期化するデータベース初期化部と、前記通信部が受信したパーキングメーター情報を前記データベース部に格納してパーキングメーターの使用状態を管理する状態管理部と、前記通信部が受信した運用者からの要求に応じて前記データベース部に格納されたパーキングメーター情報を前記通信部に出力する運用制御部とを設け、
少なくとも前記１台のサーバにより、前記複数台のパーキングメーターの一元管理が得られるように構成したことを特徴とするパーキングメーターシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２０１２−４８６４４（Ｐ２０１２−４８６４４Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１０−１９２５３１（Ｐ２０１０−１９２５３１）
【出願日】平成２２年８月３０日（２０１０．８．３０）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願日】平成２２年８月３０日（２０１０．８．３０）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【Ｆターム（参考）】
[ Back to top ]