以下、本発明のさらに具体的な例示的な実施の形態のうちのいくつかを図面に基づいて詳細に説明する。
[第1の実施形態]
まず、図1および図2を参照するに、本発明の例示的な第1の実施形態に従う駐車場管理システム(以下、単に「システム」という。)10は、各々、複数台の車両が駐車可能な複数の駐車場20(図1には、それら駐車場20のうちの代表的な駐車場20のみが図示されている)を管理するためのシステムである。
このシステム10においては、本発明の例示的な実施形態に従う駐車場管理方法であって、複数人のユーザの携帯端末(前記「通信端末」の一例)90との通信により、遠隔地にある管理センタ40によって運営される管理サーバ50が複数の駐車場20を集中的に管理するものが実施される。
一例においては、このシステム10が、ユーザが自身の携帯端末90を駐車券代わりに用い、かつ、予定された駐車時間の長さに見合う額の前払い駐車料金を支払うことを条件に、ユーザが駐車場20を利用することを許可する。別の例においては、このシステム10が、ユーザが自身の携帯端末90を駐車券代わりに用い、かつ、実際に駐車した時間の長さに見合う額の後払い駐車料金を支払うことを条件に、ユーザが駐車場20を利用することを許可する。
図1には、駐車場20が平面図で示されている。その駐車場20は、複数台の車両の同時駐車を可能にする複数の車室(駐車スペースの一例)22を有する。この駐車場20には、唯一の入出庫口24(入庫口でもあるし出庫口でもある)が存在する。
この駐車場20は、無人式であり、さらに、この駐車場20には、駐車場20の入出庫口24からの不正車両の出庫を阻止するために適宜開閉するゲート装置も、車室22からの不正車両の出庫を阻止するために適宜出没する車止め装置も、運転者であるユーザに対し、駐車料金の支払いを条件に駐車券をユーザに対して発行する発券機および精算機も設置されていない。
なお、「車両」なる用語の定義について付言するに、「車両」なる用語は、自動車のみならず、自転車、自動二輪車等、あらゆる種類の移動体を包含する用語として解釈すべきである。
図1に示すように、駐車場20の敷地には、2種類の駐車区画が存在する。それは、各車両のユーザに対し、1日単位で車室22を貸し出すための区画(一時預り区画または日貸し用区画)と、各車両のユーザに対し、事前の契約を前提に、1月単位で車室22を貸し出すための区画(月極用区画)とである。以下、単に「駐車場20」というときには、この駐車場20のうち、一時預り区画のみを意味する。
このシステム10は、その駐車場管理方式として前述の集中管理方式を採用している。具体的には、図2に示すように、このシステム10は、複数の駐車場20の複数の車室22にそれぞれ設置される複数の発信機(駐車場側ユニットの一例)30と、複数の駐車場20を集中的に管理する管理センタ40に設置される管理サーバ(センタ側ユニットの一例)50とを備えている。
本実施形態においては、各駐車場20において、1個の発信機30が、複数の車室22に共通に設置されている。別の例における駐車場20は、図16に例示すように、車室数より少数複数個の発信機30(図示の例においては、2個)が、複数の車室群(図示の例においては、2つの車室群)のそれぞれに関連付けて設置される。また、さらに別の例における駐車場20においては、図17に示すように、車室22と同数の発信機30(図示の例においては、11個)が、車室22ごとに設置される。
いずれの例においても、各発信機30が、固有の発信機IDを表す信号を発信する。
図1に示す例においては、1個の発信機30に、1つの駐車場20が関連付けられ、さらに、すべての車室22も関連付けられる。よって、その発信機30が携帯端末90によって特定されれば、それに関連付けられた駐車場20の場所、すなわち、ユーザによって選択された駐車場20の場所は分かるが、ユーザによって選択された1個の車室22の場所は不明である。
これに対し、図16に示す例においては、複数個の発信機30に、1つの駐車場20が関連付けられ、さらに、発信機30と同数の車室群も関連付けられる。よって、いずれかの発信機30が携帯端末90によって特定されれば、それに関連付けられた駐車場20の場所、すなわち、ユーザによって選択された駐車場20の場所と、複数の車室群のうちユーザによって選択された1つの車室群の場所とが分かるが、ユーザによって選択された1個の車室22の場所は不明である。
これに対し、図17に示す例においては、複数個の発信機30に、1つの駐車場20が関連付けられ、さらに、発信機30と同数の車室22も関連付けられる。よって、いずれかの発信機30が携帯端末90によって特定されれば、それに関連付けられた駐車場20の場所、すなわち、ユーザによって選択された駐車場20の場所と、ユーザによって選択された1個の車室22の場所との双方が分かる。
したがって、図17に示す例における駐車場20に対してこの駐車場管理方法が実施されれば、複数個の発信機30のうちユーザによって選択された1個の発信機30を用いることにより、ユーザが現在利用したい駐車場20と、ユーザによって選択された1個の車室22との双方が自動的に選択されることになる。
なお、図16に示す例においては、いずれの発信機30も、一部の車室22にではなく、すべての車室22に関連付けられてもよい。この場合、2個の発信機30が、同じ用途を有するために、互いに冗長することになるが、仮にいずれかの発信機30が故障しても別の発信機30が正常であれば、その正常な発信機30を用いた駐車場20の選択機能が維持され、当該システム10が、駐車場選択機能に関し、フォールトトレランスが向上する。
図2および図3に示すように、このシステム10においては、ユーザが、自身の携帯端末90を用いて、ユーザが現在滞在している駐車場20に設置されている発信機30から信号を、発信機30との接触状態または近接非接触状態で受信する(近距離一方向無線通信を行う)とともに、管理センタ40の管理サーバ50との間で遠距離双方向無線通信を行う。
ユーザの携帯端末90は、ユーザによって携帯されるとともに無線通信機能を有するデバイス、例えば、携帯電話機、スマートフォン、ラップトップ型コンピュータ、タブレット型コンピュータ、PDAなどである。また、携帯端末90は、ユーザの通信端末の一例であり、その通信端末は、ユーザによって携帯されないもの、例えば、車載通信端末でもよい。
ここで、発信機30につき、ハードウエア構成(図4参照)およびソフトウエア構成(図5参照)を説明する。
まず、概念的に説明するに、発信機30は、固有の発信機IDを識別し得る識別信号を局地的に発信する非接触式または接触(近接)式の通信デバイスである。
発信機30は、通常、対応する駐車場20に移動不能に固定的に設置されるが、随時移動可能であるように可動的に設置することも可能である。また、発信機30は、少なくとも送信機能を有すれば足りるが、必要に応じ、受信機能をも併有するように構成してもよい。
次に、作動方式を説明するに、発信機30は、固有の識別信号を外部からのトリガ信号を要することなく能動的に、局地的に、かつ、供給電力が不足しない限り永続的に発信する。
発信機30は、一般に、識別信号としてのビーコン信号を発信するビーコン装置、無線標識などの名称でも知られている装置である。この発信機30は、一例においては、原信号を変調することにより、対応する発信機IDを表す識別信号を生成し、その生成された識別信号を、IR信号、Bluetooth(登録商標)信号、NFC(近距離無線通信)信号などとして局地的に発信する。
発信機30からの信号がBluetooth(登録商標)信号である場合には、携帯端末90においては、通信モードの設定が、手動で、Bluetooth(登録商標)信号での通信に適したものに変更されることが必要である。
次に、機能ブロック図である図4を参照してハードウエア構成を説明するに、発信機30は、プロセッサ100およびそのプロセッサ100によって実行される複数のアプリケーションを記憶するメモリ102を有するコンピュータ104を主体として構成されている。
この発信機30は、さらに、電源としての交換可能な使い捨て電池106を有している。電池106に代えて、充電可能な電池を採用したり、外部電源としての商用電源または太陽電池を採用することが可能である。
外部電源として太陽電池を採用する場合、昼間に太陽電池を用いて発電された電気エネルギーのうち余剰のものをバッテリに蓄積し、夜間には、そのバッテリから電池エネルギーを取り出して発信機30を作動させてもよい。
この発信機30は、さらに、識別信号を生成して発信する発信部108を有している。その発信部108は、電池106によって作動させられるとともに、コントローラ110によって制御される。そのコントローラ110は、コンピュータ100によって制御される。
次に、図5を参照して発信機30のソフトウエア構成を説明するに、発信機30のプロセッサ100は、図5にフローチャートで概念的に表されているプログラムを反復的に実行する。
このプログラムの各回の実行時には、まず、ステップS1において、メモリ102から発信機IDが読み込まれ、次に、ステップS2において、電池106の残量が推定される。
続いて、ステップS3において、前記読み込まれた発信機IDと、前記推定された電池残量とが反映されるように、原信号(例えば、搬送信号)を変調するための信号がコントローラ110に対して出力される。そのコントローラ110は、発信部108を制御し、その結果、発信部108は、今回発信すべき識別信号を生成する。その後、ステップS4において、その生成された識別信号が発信部108から発信される。続いて、ステップS1に戻る。
なお付言するに、発信機30において、発信機IDと電池残量とが反映されるように識別信号を生成するアルゴリズムまたは手順は、図5に示すアルゴリズムまたは手順とは異なるものを採用することが可能である。
ここで、この発信機30に関連付けてユーザの携帯端末90の一機能を説明するに、その携帯端末90は、発信機30から識別信号を受信している状態で、その携帯端末90のコンピュータに予めインストールされているあるプログラム、すなわち、発信機処理のための専用アプリケーション(以下、「発信機用アプリケーション」という。)を起動させる(ログイン)と、前記受信した識別信号を復調し、それにより、前記発信機IDを解読する。携帯端末90は、さらに、その解読された発信機IDを管理サーバ50に送信する。
さらに、携帯端末90は、発信機30から識別信号を受信している状態で、前記発信機用アプリケーションを起動させると、前記受信した識別信号(例えば、その識別信号の強度)に基づき、その識別信号を発信したときの発信機30の位置と、その識別信号を受信したときの携帯端末90の位置との間の距離を測定することも行う。
すなわち、携帯端末90は、発信機30から受信した識別信号に基づき、その発信機30が実際に設置されている車室22に固有の発信機IDと、そのときの発信機30との距離との双方を獲得するようになっているのである。
携帯端末90のユーザは、自身の携帯端末90を持ったまま発信機30に接近し、その携帯端末90を発信機30のうちの発信部108に完全にまたはほぼ接触させると、携帯端末90は、発信機30から識別信号を接触式で受信することができる。
これに対し、携帯端末90のユーザが自身の携帯端末90を持ったまま特定の受信エリア(受信レンジ)内に進入すると、携帯端末90は、発信機30から識別信号を非接触式で受信することができる。
<携帯端末の可変受信レンジ>
図1に概念的に平面図で示すように、発信機30には、みかけ上、2種類の受信エリアが割り当てられる。それらは、受信可能エリアと有効受信エリア(以下、「受信レンジ」ともいう。)である。
それらエリアは、いずれも、発信機30を発信源とする円で概して定義される。受信可能エリアは、最大受信半径(例えば、約50m)を有するのに対し、有効受信エリアは、有効受信半径(例えば、0mから約50mまでの範囲内の任意の値)を有する。最大受信半径は不変値であるのに対し、有効受信半径は、後述のように、携帯端末90によって随時変更可能な可変値である。
受信可能エリアは、発信機30の電力供給が正常である場合に、発信機30からの識別信号が到達可能なエリア、すなわち、そのエリア内に存在する限り、携帯端末90がその識別信号を受信可能なエリアを意味する。
これに対し、有効受信エリアは、受信可能エリアの最大受信半径より小さい有効受信半径を有している。最大受信半径は、任意に設定することが不可能であるのに対し、有効受信半径は、携帯端末90においてソフト的に任意に設定することが可能である。
すなわち、最大受信半径は、ハードウエアによって決まる受信限度を意味するのに対し、有効受信半径は、ソフトウエアによって決まる受信限度を意味するということが可能なのである。
前述のように、携帯端末90は、それが受信した識別信号を発信したときの発信機30との距離を測定する。その距離測定値は、有効受信半径を超えることもあれば、超えないこともある。そして、その距離測定値が受信有効半径を超えないときは、携帯端末90が有効受信エリア内に存在するときであるのに対し、その距離測定値が受信有効半径を超えるときは、携帯端末90が受信可能エリア内には存在するが有効受信エリア内には存在しないときである。
携帯端末90は、前記発信機処理用アプリケーションを起動させることにより、前記距離測定値が有効受信半径の設定値以下であるか否かを判定し、その設定値以下であると判定すると、携帯端末90が現在、発信機30の有効受信エリア(受信レンジ)内に位置するから、携帯端末90は、「発信機30からの識別信号を有効に受信した(以下、単に「識別信号を受信した」ともいう。)」と判定する。
これに対し、携帯端末90は、前記距離測定値が前記設定値より大きいと判定すると、携帯端末90が現在、発信機30の有効受信エリア外に位置するから、携帯端末90は、「発信機30からの識別信号を有効に受信していない(以下、単に「識別信号を受信していない」ともいう。)」と判定する。
すなわち、本実施形態においては、携帯端末90が有効受信エリア外に位置する場合には、実際には、携帯端末90が識別信号を受信しているにもかかわらず、みかけ上、携帯端末90は識別信号を受信していないこととしてソフトウエア上で取り扱われることになるのである。
本実施形態においては、携帯端末90においては、受信レンジがショート受信レンジとロング受信レンジとの間で自動的に切り換わる。
1)ショート受信レンジ
これは、ユーザが携帯端末90を発信機30のうちの発信部108に接触させるかまたは非接触状態でかざさないと、携帯端末90が発信機30を有効に受信できない受信レンジ(前記設定値が、例えば、約0cmから約30cmの範囲内)である。
このレンジによれば、図16または図17に例示するように、駐車場20に複数個の発信機30が設置されていても、携帯端末90は、ユーザによって選択された1個の発信機30のみからの信号を単独で受信することが可能となる。
2)ロング受信レンジ
これは、ユーザが駐車場20内のいずれかの位置に存在する限り、ユーザが携帯端末90を発信機30のうちの発信部108に接触させることもかざすこともなく、携帯端末90が発信機30を有効に受信できる受信レンジ(前記設定値が、例えば、約0mから約50mの範囲内)である。
このレンジによれば、図16または図17に例示するように、1つの駐車場20に複数個の発信機30が設置している場合に、ユーザが携帯端末90をいずれの発信機30にかざさなくても、携帯端末90は、それら発信機30からの信号を同時に受信することが可能となる。
図1に示す例においては、平面視において、ショート受信レンジが、発信機30の近傍に存在する携帯端末90をカバーするのに対し、ロング受信レンジが、駐車場20内の任意の位置に存在する携帯端末90をカバーする。
ショート受信レンジは、ユーザによる入庫・出庫処理のために使用される駐車用受信レンジすなわち本番用受信レンジである。これに対し、ロング受信レンジは、携帯端末90が、ユーザに気付かれることなく、駐車場20内に存在する少なくとも1個の発信機30(図1に示す例においては、1個の発信機30であるが、図17に示す例においては、車室22と同数の発信機30)が正常であるか故障しているかを診断するために使用される診断用受信レンジである。
<携帯端末>
次に、機能ブロック図である図6を参照してユーザの携帯端末90のハードウエア構成を説明するに、携帯端末90は、プロセッサ130およびそのプロセッサ130によって実行される複数のアプリケーションを記憶するメモリ132を有するコンピュータ134を主体として構成されている。
この携帯端末90は、さらに、情報を、例えば図11において符号135で示す画面(面積が有限で可変または不変であるウィンドウを有する)上に表示する表示部(例えば、液晶ディスプレイ)136と、発信機30および管理サーバ50からの信号を受信する受信部138と、信号を生成してその信号を管理サーバ50に送信する送信部140とを有する。
この携帯端末90は、さらに、ユーザからデータやコマンドを入力するための入力部150を有する。その入力部150は、例えば、所望の情報(例えば、コマンド、データなど)を携帯端末90に入力するためにユーザによって操作可能な操作部を有する。その操作部としては、ユーザによって操作可能なアイコン(例えば、仮想的なボタン)を表示するタッチスクリーン、ユーザによって操作可能な物理的な操作部(例えば、キーボード、キーパッド、ボタンなど)、音声を感知するマイクなどがあるが、これらに限定されない。
この携帯端末90は、さらに、GPS(衛星測位システム)受信機152を有する。GPS受信機152は、よく知られているように、複数のGPS衛星から複数のGPS信号を受信し、それらGPS信号に基づき、GPS受信機152の地球上における位置(緯度、経度および高度)を三角測量によって測定する。
図7に示すように、メモリ132は、地図データメモリ161、駐車場データメモリ163および発信機データメモリ165を含む複数のデータメモリを有する。
地図データメモリ161には、ユーザの現在位置に応じて、ユーザの携帯端末90が管理サーバ50または別の地図データベース(図示しない)からダウンロードした地図データが一時的に記憶される。その地図データに基づき、表示部136の画面135(図11(a)参照)上に地図(「部分地図」の一例)が表示される。その画面135上に表示される地図は、ユーザが移動するにつれて時々刻々変化する。図において、符号202は、携帯端末90の現在位置を示し、また、符号204は、各候補駐車場(現在位置の近傍にある複数の駐車場である近傍駐車場でもある)20を示している。
図7に概念的に表すように、駐車場データメモリ163には、複数の駐車場IDと複数の駐車場位置データとの対応関係が、管理サーバ50からダウンロードされて記憶されることが可能である。複数の駐車場IDは、システム10によって集中的に管理される複数の駐車場20にそれぞれ対応している。また、複数の駐車場位置データは、それぞれ、対応する駐車場20の地上位置(駐車場20の敷地全体を代表する1個の地上位置であって、例えば、概して中心位置)の経緯度(緯度X,経度Y)を表す。
駐車場データメモリ163は、画面135上に表示される地図上に地理的に存在する複数の駐車場20(すなわち、前記複数の駐車場20のうち、ユーザの現在位置の近傍に位置する複数の駐車場20であって、各駐車場20は、ユーザが容易にアクセス可能な駐車場であり、その意味において、各駐車場20は、候補駐車場または近傍駐車場と言える)に対応する複数の駐車場位置データが、それに対応する複数の駐車場IDと共に一時的に記憶される。
携帯端末90においては、画面135上に、前記地図データに基づく地図が表示され、さらに、その地図上に、各瞬間ごとに、そのときに駐車場データメモリ163に記憶されている複数の駐車場位置データに基づき、複数の駐車場(「候補駐車場」)20の各位置がオーバーレイ表示される(図11(a)参照)。
図8に概念的に表すように、図6の発信機データメモリ165には、複数の候補駐車場20につき、各駐車場20ごとに、その駐車場20を表す駐車場IDと、その駐車場20に設置されている発信機30を表す発信機IDとが対応付けて保存される。その対応関係は、管理サーバ50から携帯端末90にダウンロードされる。
<管理サーバ>
次に、機能ブロック図である図9を参照して管理サーバ50のハードウエア構成を説明するに、管理サーバ50は、プロセッサ160およびそのプロセッサ160によって実行される複数のアプリケーションを記憶するメモリ162を有するコンピュータ164を主体として構成されている。
この管理サーバ50は、さらに、情報を表示する表示部(例えば、液晶ディスプレイ)166と、携帯端末90からの信号を受信する受信部168と、信号を生成してその信号を携帯端末90に送信する送信部170と、現在時刻を計測する時計172とを有する。この管理サーバ50は、発信機30からの受信を直接的には行わず、事実上、携帯端末90を介して行うことになる。
<入庫シーケンス>
図10には、ユーザがある駐車場20に自身の車両を入庫する入庫ステージにおいて、その入庫直後に、ユーザの携帯端末90と、共に同じ駐車場20に位置する発信機30と、遠隔地に位置する管理サーバ50との間で行われる通信の一例が時系列的にシーケンス・フローで表されている。
図10を参照した具体的な説明に先立ち、図15に示すフローチャートを参照してこの入庫シーケンスの概略を説明する。この入庫シーケンスは、発信機30の故障診断を行うためのスキャンフェーズ(S1−S4)と、今回の駐車場20を選択するための駐車場選択フェーズ(S5−S14)とが存在する。
スキャンフェーズ(S1)においては、まず、携帯端末90によって現在位置が測定され(S2)、次に、今回の駐車場20に設置されているすべての発信機30が携帯端末90によって疑似的にスキャンされ、それにより、有効受信の成否がスキャン結果として測定される(S3)。続いて、そのスキャン結果が、後述のサンプルデータとして管理サーバ50に報告される(S4)。
本実施形態においては、図16または図17に示す例のように、1つの駐車場20に複数個の発信機30が設置されているわけではなく、図1に示すように、1つの駐車場20に1個の発信機30しか存在しないため、「スキャン」という用語の選択に違和感を覚えるかもしれない。
しかし、スキャンフェーズにおいては、携帯端末90がロング受信レンジですべての発信機30を、設置されている発信機30の個数が1個であるか否かを問わず、広域的に探索するのに対し、駐車場選択フェーズにおいては、携帯端末90がショート受信レンジで1個の発信機30のみを単独で狭域的に探索するというような差異に着目すると、「スキャン」という用語を選択したことの正当性が理解されるであろう。
図15に示すように、駐車場選択フェーズは、通常選択モード(S8−S11)と予備選択モード(S12−S14)とを有する。携帯端末90が管理サーバ50から受信した発信機別診断結果(S6)に従い、今回の駐車場20に設置されていると予想される発信機30が正常であれば(S7)、通常選択モードが起動させられる。これに対し、その発信機30が故障中であれば(S7)、予備選択モードが起動させられる。
通常選択モード(S8)においては、携帯端末90により、発信機30からの有効受信が試行される(S9)。その試行に失敗すれば(S10)、予備選択モードに切り換わるが、成功すれば(S10)、その発信機30から有効に受信した信号によって表される発信機IDに応じて今回の駐車場20が特定される(S11)。
これに対し、予備選択モード(S12)においては、携帯端末90により、GPS位置情報(または、携帯端末90が通信中に使用する複数の基地局の位置情報)を用いて自身の現在位置が測定され(S13)、複数の駐車場20のうちその現在位置に最も地理的に近いものが、今回の駐車場20と推定される。その推定が正しいことがユーザにより確認されると、その推定が採用されて今回の駐車場20が選択される(S14)。
次に、図10に戻ってこの入庫シーケンスを具体的に説明する。
発信機30は、自身に固有の識別信号を自発的にかつ継続的に発信する。駐車場20への入庫に際し、携帯端末90においては、プロセッサ130が、メモリ132に格納されている駐車サービス・アプリケーションのうち、入庫処理に関連する部分(図10におけるステップS101−S137)を実行する。管理サーバ50においては、プロセッサ160が、メモリ162に格納されている駐車場管理プログラムのうち、入庫処理に関連する部分(図10におけるステップS201−S215)を実行する。
具体的には、携帯端末90において、ユーザにより、前記駐車サービス・アプリケーションが起動されると、まず、ステップ101において、GPS受信機152が外部から受信したGPS信号に基づき、ユーザの現在位置(経緯度)が測定される。
次に、ステップS102において、その測定されたユーザの現在位置が、地図を表示部136の画面135上に表示するためにプロセッサ130によって参照される基準位置(表示基準点の位置(経緯度))202とされる。さらに、全体地図のうち、画面135上のウィンドウ内に一度に表示可能なサイズを有する部分であって基準位置202が存在するものが、地図の表示範囲(すなわち、前記全体地図のうち、前記ウィンドウ内に各瞬間に表示される領域)に決定される。
図11に例示するように、ユーザが時間と共に地上を移動すると、それに追従するように基準位置202(同図において黒色の三角形で示す)も時間と共に移動する。その結果、ユーザの移動に伴い、地図の表示範囲も全体地図上を時間と共に移動し、ひいては、前記ウィンドウ内に表示される地図の画像も時間と共に変化することになる。
続いて、ステップS103において、管理サーバ50にログインするためのログイン・リクエスト(「サービス開始信号」の一例)が、前記現在位置(携帯端末90の現在位置を定義する経緯度)および今回のユーザを識別するためのユーザIDと共に管理サーバ50に送信される。
これに対し、管理サーバ50は、ステップS201において、前記ログイン・リクエストを前記現在位置およびユーザIDと共に受信し、続いて、ステップS202において、前記複数の駐車場20のうち、その受信した現在位置202の近傍に位置する(例えば、現在位置202を中心とする半径500mの範囲内に位置する)複数の駐車場20(実際には、1つの駐車場20しか存在しない場合も、いずれの駐車場20も存在しない場合もある)が、複数の候補駐車場として検索される。
その検索のために、前記複数の駐車場20のそれぞれに固有の駐車場IDと、各駐車場20の経緯度との関係が保存されているメモリ162内のデータベースが参照される。
その後、ステップS203において、その検索された複数の候補駐車場20の位置を表す複数の駐車場位置データが、それら候補駐車場20に対応する複数の駐車場IDと共に、携帯端末90に送信される。
したがって、本実施形態においては、前記データベースに保存されている複数の駐車場20に関する位置情報がすべて携帯端末90に送信されるのではなく、その携帯端末90の処理負荷の軽減のために、ユーザによって参照される可能性が高い一部の駐車場20に関する位置情報のみが携帯端末90に送信される。
さらに、このステップS203においては、管理サーバ50が、それら候補駐車場20のそれぞれにつき、空室が存在するかまたは満室であるのかを表す駐車場別の満空情報をメモリ162から読み出し、それら候補駐車場20についての満空情報をそれぞれの駐車場IDに関連付けて携帯端末90に送信する。満空情報は、後述のステップS212および213において作成・更新される。
これに対し、携帯端末90は、ステップS104において、前記複数の駐車場位置データおよび満空情報を複数の駐車場IDと共に受信する。続いて、ステップS105において、その受信された複数の駐車場位置データに基づき、画面135上に表示されている地図上に、複数の候補駐車場20がオーバーレイ表示される。
このステップ105においては、画面135上に、受信された複数の駐車場位置データによって表される複数の候補駐車場20(管理サーバ50のメモリ162に保存されているすべての駐車場20のうち、管理サーバ50がユーザの現在位置に応じて選択したもの)のすべてが表示されるわけではない。ユーザの現在位置と画面135のサイズとによって決まる、前記複数の候補駐車場20より少数の複数の候補駐車場20のみが画面135上に表示される。すなわち、管理サーバ50から受信した複数の候補駐車場20が、ユーザの現在位置と画面135のサイズとによってさらに、少数の候補駐車場20に絞り込まれるのである。
このステップ105においては、さらに、管理サーバ50から受信した複数の駐車場位置データおよび複数の駐車場IDが、互いに関連付けて、図7に示す駐車場データメモリ163に保存される。
一例においては、図11(a)に示すように、画面135上に表示されている地図上に、ユーザの現在位置が黒色の三角形202を用いてオーバーレイ表示されるとともに、複数の候補駐車場20が複数の駐車場アイコン204を用いてオーバーレイ表示される。この例においては、各駐車場アイコン204が、「P」というアルファベットが四角形の枠に包囲されて成る図形として構成されている。
続いて、ステップS106において、携帯端末90が、前記受信した満空情報に基づき、画面135上において、図11(a)に例示するように、各候補駐車場20に関連付けて、その候補駐車場20に空室が存在する場合には、そのことを表す記号や図形(例えば、漢字の「空」を四角形の枠で包囲した図形)を表示し、その候補駐車場20が満室である場合には、そのことを表す記号や図形(例えば、漢字の「満」を四角形の枠で包囲した図形)を表示する。
このとき、ユーザは、画面135上の駐車場案内情報を見ながら、いずれかの駐車場20をユーザが駐車を行いたい駐車場として選択する。その後、ユーザは、車両を運転してその駐車場20に到着する。
スキャンフェーズ
その後、スキャンフェーズに移行し、具体的には、まず、ステップS107において、携帯端末90が、自身の現在位置(GPSによる位置測定結果)を測定し、さらに、前記複数の候補駐車場20の中に、その測定された現在位置との距離が最も短く、かつ、その距離が許容値以下であるものが存在するか否かを判定する。その距離は、GPS情報に基づく経緯度と、図7に示す地図座標との間の距離として計算される。
現在位置との距離が最も短く、かつ、その距離が許容値以下であるいずれかの候補駐車場20は、複数の候補駐車場20のうち、ユーザが滞在している可能性が高い候補駐車場20であり、これは、事実上、通常選択モードにおいて、発信機30を用いて特定される駐車場20と一致する可能性が高い。
しかし、概念的には、ステップS107におけるいずれかの候補駐車場20の特定は、発信機30の故障診断を行うことを主たる用途とするため、発信機30を用いた駐車場20の特定とは異なる。
よって、分類の便宜上、GPS情報を用いて特定されたいずれかの候補駐車場20は、「推定駐車場」といい、発信機30を用いて特定されたいずれかの駐車場20は、「確定駐車場」といい、ユーザが実際に滞在しているいずれかの駐車場20は、「今回の駐車場」または「実際駐車場」というように、それぞれ互いに区別して呼称することが可能である。
このステップS107の判定がNOである場合には、ステップS101に戻り、ユーザが車両を運転して移動した結果、ユーザがいずれかの候補駐車場20に到着するまで、ステップS101−S107の実行が反復される。
やがてユーザがいずれかの候補駐車場20に到着すると、ステップS107の判定がYESとなり、続いて、ステップS108において、携帯端末90が、前記診断用受信レンジ、すなわち、前記ロング受信レンジを選択し、その診断用受信レンジのもと、今回の駐車場20に設置されている少なくとも1個の発信機30からの受信の試行(診断用受信試行)を開始する。
このとき、ユーザは、携帯端末90を発信機30にかざすことを要求されない。ユーザが今回の駐車場20内に滞在しており、かつ、発信機30が正常に作動し、かつ、携帯端末90の通信モードの設定が発信機20の受信に適していれば、携帯端末90は、ユーザの無意識のうちに、発信機30からの信号を有効に受信することになる。
このとき、今回の駐車場20に設置されている発信機30の数が1個であり、かつ、その発信機30が正常に作動している場合には、ロング受信レンジのもとでありながら、携帯端末90は1個の発信機30からしか信号を受信できない。これに対し、今回の駐車場20に設置されている発信機30の数が複数個であり、かつ、それら発信機30がいずれも正常に作動している場合には、携帯端末90は、それら発信機30から信号を同時に受信できる。
その後、ステップS109において、携帯端末90が、今回の駐車場20に設置されているすべての発信機30の各々につき、有効に信号(識別信号)を受信したか否かを判定し、有効に受信した場合には、その信号を発信機IDに変換する。その変換のためのアルゴリズムは、前記駐車サービス・アプリケーションに組み込まれている。
ロング受信レンジのもとに各発信機30から信号を有効に受信したか否かの判定は、例えば、受信した信号が存在し、かつ、その信号の強度が、ロング受信レンジに対応する第1強度しきい値以上である場合に、有効受信に成功したと判定するように行うことが可能である。これに代えて、各発信機30から受信した信号が存在し、かつ、その信号の強度を受信距離に変換し、その受信距離が、ロング受信レンジに対応する第1距離しきい値以下である場合に、有効受信に成功したと判定するように行うことも可能である。
さらに、このステップS109においては、携帯端末90が、取得された発信機ID(いずれの発信機30から信号を有効に受信したのかを表す報告値(すなわち、有効に受信できた発信機30を表す発信機ID)と前記推定駐車場20を表す駐車場IDとの組合せをサンプルデータ(発信機故障診断に関する一人のユーザからのサンプルデータ)として管理サーバ50に送信する。
上記報告値は、有効受信に成功した発信機30を表す発信機IDであるため、有効受信に成功した発信機30については存在し、それに失敗した発信機30については存在しない。よって、すべての発信機30について有効受信に失敗すれば、上記報告値が存在しないことになる。この場合の報告値は、すべての発信機30が故障していることを表す。
これに対し、管理サーバ50は、ステップS204において、携帯端末に90に管理サーバ50からサンプルデータを受信する。続いて、ステップS205において、そのサンプルデータから、駐車場IDと、発信機IDの報告値とを抽出する。
その後、ステップS206において、それらの抽出値を、図12に例示する故障診断テーブル内に組み込み、それにより、その故障診断テーブルを更新する。
具体的には、管理サーバ50は、この故障診断テーブルに、駐車場IDごとに、かつ、発信機IDごとに前記報告値を表すデータ(受信に成功すれば「○」、失敗すれば「×」)を記録する。さらに具体的には、管理サーバ50は、最新のサンプルデータを任意の一人のユーザから受信するごとに、そのサンプルデータのうちの前記報告値に、順次1ずつ増加するサンプル番号を割り当て、現時点までに取得した複数のサンプルデータを時系的に記録する。
図12(a)に示す例においては、駐車場IDが「A」である駐車場20であって、1個の発信機30であって発信機IDが「0001」であるもののみが設置されているものにつき、3個のサンプルデータが順次取得された。1番目のサンプルデータは、その発信機30からの有効受信に成功したことを表し、同様に、2番目のサンプルデータも3番目のサンプルデータも、その発信機30からの有効受信に成功したことを表している。
これに対し、図12(b)に示す例においては、駐車場IDが「B」である駐車場20であって、1個の発信機30であって発信機IDが「0002」であるもののみが設置されているものにつき、3個のサンプルデータが順次取得された。1番目のサンプルデータは、その発信機30からの有効受信に成功したことを表し、2番目のサンプルデータは、その発信機30からの有効受信に失敗したことを表し、3番目のサンプルデータも、その発信機30からの有効受信に失敗したことを表している。
また、図12(c)に示す例においては、駐車場IDが「C」である駐車場20であって、1個の発信機30であって発信機IDが「0003」であるもののみが設置されているものにつき、3個のサンプルデータが順次取得された。1番目のサンプルデータは、その発信機30からの有効受信に成功したことを表し、2番目のサンプルデータは、その発信機30からの有効受信に失敗したことを表し、3番目のサンプルデータは、その発信機30からの有効受信に成功したことを表している。
その後、管理サーバ50は、ステップS207において、複数のサンプルデータに基づき、確率的かつ総合的な故障診断を行う。
具体的には、例えば、図12(a)に示すように、同じ発信機30につき、複数個の報告値が、有効受信に連続して成功していることを表す場合には、その発信機30は正常であることを表す判定値が作成される。
また、例えば、図12(b)および図12(c)に示すように、同じ発信機30につき、2番目のサンプルデータにおいて、対応する発信機30の有効受信に成功した状態から失敗した状態に遷移した場合にも、その発信機30は正常であることを表す判定値が作成される。
しかし、図12(c)に示すように、3番目のサンプルデータにおいて、対応する発信機30の有効受信に連続して失敗した場合には、その発信機30は故障中であることを表す判定値が作成される。
すなわち、判定規則として、所定回数より少ない連続的受信失敗があっても、それが無視されて、発信機30は正常と判定されるが、前記所定回数以上の連続的受信失敗があると、発信機30は故障中であると判定されるというものが例示的に採用されているのである。
その後、管理サーバ50は、前記故障診断テーブルの最新状態に基づき、図13に例示する診断・点検リストを、各駐車場20ごとに、かつ、各発信機30ごとに、最終的な診断結果(前記判定値)と、作業者を現地に派遣して発信機30を点検する作業の要否とを反映するように作成する。前記診断結果は、携帯端末90と管理センタ40とに報告されるのに対し、前記点検の要否は、管理センタ40のみに報告される。
続いて、管理サーバ50は、ステップS208において、前記診断・点検リストを検索して、今回の駐車場20(前記推定駐車場)に対応する最新の発信機別診断結果を取り出す。その後、管理サーバ50は、ステップS209において、その発信機別診断結果を携帯端末90に送信する。
なお、本実施形態においては、スキャンフェーズが、携帯端末90によって測定される自身の現在位置がいずれかの駐車場20内に存在すると、携帯端末90によって自動的に開始されるが、これに代わるかまたはこれに加えて、携帯端末90によって測定される自身の現在位置がいずれかの駐車場20の周辺近傍に存在する(ユーザが偶然にある駐車場20のそばを歩行するか乗車状態で通過する)と、携帯端末90によって自動的に開始されるようにしてもよい。
駐車場選択フェーズ
これに対し、携帯端末90は、ステップS110において、管理サーバ50から最新の発信機別診断結果を受信し、続いて、ステップS111において、その発信機別診断結果に基づき、今回の駐車場20に設置されている発信機30が故障中であると診断されているか否かを判定する。
通常選択モード
今回の発信機30が正常であると管理サーバ50によって診断されている場合には、ステップS111の判定がNOとなり、ステップS112において、携帯端末90が、前記本番用受信レンジ、すなわち、前記ショート受信レンジを選択し、そのショート受信レンジのもと、今回の駐車場20に設置されている少なくとも1個の発信機30であってユーザによって選択されたものからの受信の試行(本番用受信試行)を開始する。
このとき、ユーザは、携帯端末90を1個の発信機30にかざすことを要求される。ユーザが今回の駐車場20内に滞在しており、かつ、発信機30が正常に作動し、かつ、携帯端末90の通信モードの設定が発信機20の通信に適しており、かつ、携帯端末90が発信機30にかざされていれば、携帯端末90は、1個の発信機30からの信号を有効に受信することになる。
その後、ステップS113において、携帯端末90は、ショート受信レンジのもとに各発信機30から信号を有効に受信したか否かを判定する。この判定は、例えば、発信機30から受信した信号が存在し、かつ、その信号の強度が、ショート受信レンジに対応する第2強度しきい値(前記第1強度しきい値より大きい)以上である場合に、有効受信に成功したと判定するように行うことが可能である。これに代えて、発信機30から受信した信号が存在し、かつ、その信号の強度を受信距離に変換し、その受信距離が、ショート受信レンジに対応する第2距離しきい(前記第1強度しきい値より小さい)値以下である場合に、有効受信に成功したと判定するように行うことも可能である。
ステップS113の判定がNOである場合には、予備選択モードを起動させるために、ステップS131に移行するが、ステップS113の判定がYESである場合には、ステップS114に移行する。
そのステップS114においては、携帯端末90が、今回の発信機30から有効に受信した信号(識別信号)を発信機IDに変換する。その変換のためのアルゴリズムは、前記駐車サービス・アプリケーションに組み込まれている。
続いて、携帯端末90は、ステップS115において、図8に示す関係に従い、上記発信機IDを、それに対応する駐車場IDに変換する。これにより、発信機30と携帯端末90とを用いて今回の駐車場30が完全に自動的に選択されることになる。
その後、携帯端末90は、ステップS116において、図11(b)に示すように、画面135上に表示されている地図上に、入庫をリクエストするためにユーザによって操作される入庫ボタン206(文字や記号、画像などで表示される仮想的ボタン)がオーバーレイ表示される。続いて、ユーザは、入庫ボタン206に指でタッチすることにより、その入庫ボタン206を選択して起動させる。
その後、携帯端末90は、ステップS117において、ユーザからの入庫リクエストを、ユーザIDおよび駐車場ID(または、発信機IDも)に関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS210において、携帯端末90から入庫リクエストをユーザIDおよび駐車場ID(または、発信機IDも)と共に受信すると、ユーザが今回の駐車場20に入庫することを許可し、すなわち、今回の駐車場20の利用を開始する権限をユーザに付与する。
続いて、管理サーバ50は、ステップS211において、そのときの時刻を入庫時刻として取得する。その時刻は、時計172を用いて計測される。その取得された入庫時刻は、管理サーバ50のメモリ162に、今回のユーザのユーザIDに関連付けて一時的に保存される。
その後、管理サーバ50は、ステップS212において、図14に例示する駐車管理テーブルを、今回のユーザIDおよび入庫時刻が反映されるように更新する。続いて、管理サーバ50は、ステップS213において、今回の駐車場20につき、満空判定(空室の有無の判定)を行う。
具体的には、管理サーバ50は、入庫リクエストを受け付けるごとに、空室数の現在値を1だけ減算し、また、出庫リクエストを受け付けるごとに、空室数の現在値を1だけ加算する。その結果値が、0になると、管理サーバ50は、今回の駐車場20は満室であると判定し、そうでなければ、今回の駐車場20には空室が存在すると判定する。図14に例示する駐車管理テーブルには、車室数11に対し、空室数が5であることが記録されている。
各駐車場20に空室があるか否かを表す情報は、満空情報として、前述のステップS203において、管理サーバ50から、その情報を必要とする任意のユーザの携帯端末90に送信される。
ところで、図1または図16に示すような駐車場20においては、車室22ごとに発信機30が設置されていないが、図17に示すような駐車場20においては、車室22ごとに発信機30が設置されている。そのため、この駐車場20については、車室22ごとに発信機30が設置されていない駐車場20についての上述の第1形式の満空判定とは異なる第2形式の満空判定を行うことが可能である。
具体的には、上述の第1形式の満空判定と同様に、管理サーバ50が、各駐車場20ごとに、各車室22の稼働状況(入庫前か、入庫後か、出庫後か)を表すデータに基づき、各車室22が空室であるのか満室であるのかを判定し、その判定結果を表す満空情報を作成するとともにその満空情報を複数人のユーザの携帯端末90に配信する。
しかし、上述の第1形式の満空判定とは異なり、管理サーバ50は、さらに、前記最終診断結果に基づいて故障発信機であると診断された発信機30が設置されている車室22については、実際には空室であっても満室であると判定する。その判定結果は、車室22単位で、携帯端末90の画面135上に、満空情報として表示される。よって、その表示により、その車室22をユーザが利用することが阻害され、それにより、故障発信機30をユーザが使用することが回避される。
続いて、管理サーバ50は、ステップS214において、今回のユーザからの入庫リクエストが採用されたことを表す入庫確認データを携帯端末90に送信する。管理サーバ50は、さらに、今回のユーザが今回の駐車場20に駐車した場合にその対価としてユーザに課される駐車料金に関する条件、すなわち、課金条件を表す課金条件データをメモリ162から読み出して携帯端末90に送信する。管理サーバ50は、さらに、今回の駐車場20を特定するための駐車場識別データと入庫時刻(時間情報)とを携帯端末90に送信する。
これに対し、携帯端末90は、ステップS118において、上述の各種のデータ210(上述の課金条件データ、駐車場識別データおよび入庫時刻を含む時間情報)を管理サーバ50から受信する。続いて、携帯端末90は、ステップS119において、その受信したデータ210の内容を、図11(c)に例示するように、画面135上に表示する。その後、携帯端末は、ステップS120において、管理サーバ50からのログアウトを要求するログアウト・リクエストを管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS215において、そのログアウト・リクエストを受信する。
予備選択モード
以上、ステップS111の判定がNOであり、かつ、ステップS113の判定がYESである場合、すなわち、本番用有効受信に成功した場合を説明したが、本番用有効受信に失敗した場合には、ステップS113の判定がNOとなり、ステップS131において、携帯端末90が、本番用有効受信の再試行継続時間であるリトライ時間が所定のリトライ制限時間(前述の「所定時間」の一例)に到達していないか否かを判定する。そのリトライ時間は、ステップS113の判定がYESからNOに遷移した時刻から測定される。
リトライ時間の現在値が制限時間内であると仮定すると、ステップS131の判定がYESとなり、ステップS132において、携帯端末90が、画面135上に、通信モードの設定を発信機30に適した通信モード(例えば、Bluetooth(登録商標))に変更することを催促するための警告メッセージ(前述の「視覚的または聴覚的なメッセージ」の一例)を表示する。その後、ステップS113が再度実行される。
今回は、ステップS111の判定がNOであると仮定されているため、ステップS113の判定がNOとなった原因は、発信機30自体の故障ではなく(故障でも電池切れでもなく)、携帯端末90の通信モードの設定の誤りである可能性が高い。そこで、本実施形態においては、ユーザに対し、通信モードの設定変更を催促し、その結果、その設定が適正化されれば、次回のステップS113の判定がYESとなり、発信機30を用いた駐車場20の選択が予定通り行われることになる。
ステップS112、S113、S131およびS132の実行が反復された結果、リトライ時間の現在値が所定のリトライ制限時間に到達すると、ステップS131の判定がNOとなる。
すなわち、本実施形態においては、本番用有効受信に失敗する(受信不能状態が発生する、すなわち、受信状態(有効受信状態)から受信不能状態(非有効受信状態)に遷移する)と直ちにステップS134に移行して予備選択モードが起動するのではなく、本番用有効受信に失敗する状態が所定時間継続したときにステップS134に移行して予備選択モードが起動するのであるが、本番用有効受信に失敗すると直ちにステップS134に移行して予備選択モードが起動する態様で本発明を実施してもよい。
この場合、携帯端末90は、ステップS134において、GPS(または基地局)を用いて現在位置を測定し、その現在位置に基づき、複数の駐車場20のうちのいずれかを今回の駐車場20として選択する。
第1の例においては、携帯端末90が、すべての駐車場20またはそれより絞り込まれた少数の複数の候補駐車場20のうち、現在位置に最も近いものを今回の駐車場20として選択する。しかし、この場合には、現在位置が、その選択された今回の駐車場20の場内に存在しない可能性もある。
第2の例においては、携帯端末90が、すべての駐車場20またはそれより絞り込まれた少数の複数の候補駐車場20のうち、現在位置に最も近く、かつ、現在位置との距離が設定値以内であるものを今回の駐車場20として選択する。この場合には、現在位置が、その選択された今回の駐車場20の場内に存在しない可能性を低減できる。
第3の例においては、携帯端末90が、上述の第1および第2の例におけるのと同じアルゴリズムに従い、複数の駐車場20のうちのいずれかを今回の駐車場20として選択するが、その選択を暫定的に行う。その暫定的に選択された今回の駐車場20が妥当であるか否かをユーザに確認させ、その確認を待って、その暫定的に選択された今回の駐車場20を最終的に選択された今回の駐車場20として扱う。図15に示すフローは、この例を実現したものである。
第4の例においては、携帯端末90が、複数の候補駐車場20であって画面135上に表示されているもの(管理センタ40が管理しているすべての駐車場20のうち、携帯端末90によって逐次測定される現在位置の近傍に位置するために画面135上に表示されもの)のうち、ユーザによって携帯端末90上で手動で選択されたものを今回の駐車場20として選択する。
それら4つの例のうち、第1および第2の例は、携帯端末90の位置を参照して今回の駐車場20を完全に自動的に選択する例であり、これに対し、第3および第4の例は、携帯端末90の位置を参照して今回の駐車場20を、ユーザの介入を伴って準自動的に選択する例である。しかし、いずれの例も、携帯端末90の位置を参照して今回の駐車場20を選択する例である点で互いに共通する。
そして、図15に示すフローにおいては、携帯端末90が、ステップS134において、複数の候補駐車場20のうち、現在位置に最も近く、かつ、現在位置との距離が設定値以内であるものを今回の駐車場20として暫定的に選択する。その後、携帯端末90は、ステップS135において、今回の駐車場20として暫定的に選択されたものを画面135上に表示し、ユーザに対し、その暫定的選択が正しいか否かの確認を求める。
続いて、ユーザが、その暫定的選択が正しいことを確認したとの意思表示を携帯端末90に対して入力すると、携帯端末90は、ステップS136において、そのことを確認する。その後、携帯端末90は、ステップS137において、そのように確認された今回の駐車場20を表す駐車場IDをユーザIDと共に管理サーバ50に送信する。その後、ステップS116に移行する。
以上、ステップS111の判定がNOである場合、すなわち、発信機30が正常発信機であると診断された場合を説明したが、発信機30が故障発信機であると診断された場合には、ステップS111の判定がYESとなり、直ちに、ステップS133に移行する。
ところで、本実施形態においては、各発信機30の故障モードとして以下のものがある。
(1)発信機30自体が故障しているために作動不能であるという第1の故障モード
(2)発信機30自体は故障していないが、電池切れまたは電池不足のため発信機30の正常作動が不能であるという第2の故障モード
(3)発信機30自体は正常であるが、今回のユーザが携帯端末90の使用に不慣れであるかまたは不注意のため、その携帯端末90の通信モードを発信機30に適合するものに切り替える操作を怠ったために、携帯端末90が発信機30からの信号を受信できないというという第3の故障モード原因
そうすると、通信モードの設定が適切である携帯端末90のユーザXと、通信モードの設定が不適切である携帯端末90のユーザYとが、いずれも、同じ駐車場20に同時にかまたは異なる時刻に滞在していたために同じ発信機30に遭遇していた場合、その発信機30に第1および第2の故障モードのいずれも存在していなかったとすると、ユーザXからの前述のサンプルデータ(個別診断結果)のみという単発の情報に基づく限り、その発信機30は正常であると判定されるのに対し、ユーザYからの前述のサンプルデータ(個別診断結果)のみという単発の情報に基づく限り、その発信機30は故障であると判定されるというように、同じ発信機30について衝突する判定結果が発生してしまう。
このとき、管理サーバ50は、前述のように、発信機30の有効受信失敗が最初に発生すると、発信機30は正常であるとの判定を維持するから、携帯端末90においては、ステップS110の判定がYESとなる。しかし、管理サーバ50は、前述のように、発信機30の有効受信失敗が連続して発生すると、発信機30は故障中であるとの判定に移行するから、携帯端末90においては、ステップS110の判定がNOとなる。
このことから推論できることは、あるユーザの携帯端末90が通信モードの設定が不適切である状態で前記駐車サービス・アプリケーションを起動させた場合、その携帯端末90は、ステップS108において、個別診断結果として、発信機30の受信不能を管理サーバ50に送信することになるとしても、ステップS109において、管理サーバ50から、その発信機30は正常であるとの診断結果を受信することがあり得るということである。
よって、ある発信機30の故障診断を、その発信機30についての有効受信の成否の結果から推定する場合に、一人のユーザの携帯端末90の受信結果のみに依存して、その発信機30の故障診断を行うと、そのユーザの携帯端末90の受信モードの設定がそもそも不適切である可能性がある限り、その診断の信頼性が不足する。
これに対し、同じ発信機30についての他のユーザの携帯端末90の受信結果をも参照してその発信機30の故障診断を行う場合には、その診断の結果が、個人差の影響を受け難くなり、結果として、診断の信頼性が向上する。
<出庫シーケンス>
図18には、ユーザが、先に入庫した駐車場20から出庫する出庫ステージにおいて、その出庫直前に、共に同じ駐車場20に位置する発信機30および携帯端末90と、遠隔地に位置する管理サーバ50との間で行われる通信の一例が時系列的にシーケンス・フローで表されている。
発信機30は、自身に固有の識別信号を自発的にかつ継続的に発信する。駐車場20からの出庫に際し、携帯端末90においては、プロセッサ130が、メモリ132に格納されている前記駐車サービス・アプリケーションのうち、出庫処理に関連する部分(図18におけるステップS501−S520)を実行する。管理サーバ50においては、プロセッサ160が、メモリ162に格納されている前記駐車場管理プログラムのうち、出庫処理に関連する部分(図18におけるステップS601−S610)を実行する。
具体的には、携帯端末90において、ユーザにより、メモリ132に格納されている前記駐車サービス・アプリケーションのうち、出庫処理に関連する部分が起動されると、まず、ステップ101と同様にして、ステップS501において、GPS受信機152が外部から受信したGPS信号に基づき、ユーザの現在位置(経緯度)が測定される。
次に、ステップ101と同様にして、ステップS502において、その測定されたユーザの現在位置が、地図を表示部136の画面上に表示するためにプロセッサ130によって参照される基準位置(表示基準点の位置(経緯度))とされる。さらに、全体地図のうち、画面135上のウィンドウ内に一度に表示可能なサイズを有する部分であって前記基準位置が存在するものが、地図の表示範囲(すなわち、前記全体地図のうち、前記ウィンドウ内に各瞬間に表示される領域)に決定される。
続いて、ステップS503において、管理サーバ50にログインするためのログイン・リクエスト(前述の「サービス開始信号」の一例)が、今回のユーザを識別するためのユーザIDと共に管理サーバ50に送信される。
これに対し、管理サーバ50は、ステップS601において、前記ログイン・リクエストを前記現在位置および前記ユーザIDと共に受信する。
続いて、ステップS602において、前記複数の駐車場20のうち、その受信した現在位置の近傍に位置する(例えば、前記現在位置を中心とする半径500mの範囲内に位置する)複数の駐車場20が、複数の候補駐車場として検索される。その検索のために、前記データベースが参照される。さらに、今回のユーザIDに関連付けてメモリ162に保存されている今回の駐車場IDおよび今回の正規発信機IDが検索される。
その後、ステップS603において、それら検索された複数の候補駐車場20を表す複数の駐車場位置データと、今回の駐車場IDと、今回の正規発信機IDとが携帯端末90に送信される。
これに対し、携帯端末90は、ステップS504において、それら複数の駐車場位置データと、今回の駐車場IDと、今回の正規発信機IDとを受信する。続いて、ステップS105と同様にして、ステップS505において、それら受信された複数の駐車場位置データに基づき、画面135上に表示されている地図上に、複数の候補駐車場20がオーバーレイ表示される。
一例においては、図19(a)に示すように、画面135上に表示されている地図上に、ユーザの現在位置が黒色の三角形202を用いてオーバーレイ表示されるとともに、複数の候補駐車場20が複数の駐車場アイコン204を用いてオーバーレイ表示される。
その後、ステップS506において、図19(b)に示すように、画面135上に表示されている地図上に、出庫をリクエストするためにユーザによって操作される出庫ボタン220(文字や記号、画像などで表示される仮想的ボタン)がオーバーレイ表示される。続いて、ステップS507において、ユーザが、出庫ボタン220を選択する。
続いて、ステップS112と同様にして、ステップS508において、携帯端末90が発信機30から識別信号を有効に受信したか否かが判定される。
その後、ステップS114と同様にして、ステップS509において、前記受信した識別信号が復調され、続いて、ステップS114と同様にして、ステップS510において、その復調された識別信号によって表される発信機IDが実発信機IDとして解読される。すなわち、今回の発信機30が特定されるのである。
続いて、ステップS511において、その解読された実発信機IDと、前記受信した今回の正規発信機IDとが互いに一致するか否かが判定される。
実発信機IDと正規発信機IDとが互いに一致する場合には、ステップ512において、図15(b)に示すように、ユーザが今回の駐車場20から本当に出庫することを確認するためにユーザによって操作される確認ボタン222が画面135上に表示される。
よって、本実施形態においては、出庫のための一連の手続きの開始をユーザが希望することを確認するために選択される出庫ボタン220と、その手続中に、ユーザが最終的に出庫することを希望することを確認するために選択される確認ボタン222とが存在する。
これに対し、実発信機IDと正規発信機IDとが互いに一致しない場合には、今回の駐車場20からの出庫(駐車サービスの終了)がユーザに許可されず(今回の駐車場20の利用を終了する権限がユーザに付与されず)、例えばステップS501に戻る。
続いて、ステップS513において、ユーザが確認ボタン222を選択する。その後、ステップS514において、ユーザによって確認ボタン222が選択されたことを表す最終確認データが管理サーバ50に送信される。
これに対し、管理サーバ50は、ステップS604において、その最終確認データを受信する。その結果、今回の駐車場20からの出庫すなわち駐車サービスの終了がユーザに許可される。
続いて、ステップS605において、そのときの時刻が現在時刻として取得される。その後、ステップS606において、メモリ162に今回のユーザに関連付けて保存されている入庫時刻が読み出され、その入庫時刻から現在時刻までの経過時間が、最終的な駐車時間として取得される。
その後、ステップS607において、その駐車時間の長さに見合う額の駐車料金が計算される。その計算のために、メモリ162に保存されている前記料金計算テーブルが参照される。続いて、ステップS608において、その計算された駐車料金が、関連する情報と共に、携帯端末90に送信される。
これに対し、携帯端末90は、ステップS515において、その駐車料金を、関連する情報と共に、管理サーバ50から受信する。
続いて、ステップS516において、図19(c)に例示するように、受信した駐車料金などの金額情報と、今回の駐車場20の名称、所在地などの駐車場識別情報(場所情報)と、入庫時刻、出庫時刻などの時刻情報とを含む駐車関連情報228が画面135上に表示され、さらに、決済ボタン226も表示される。その決済ボタン226は、画面135上の駐車関連情報228の内容をユーザが確認し、その内容にて電子決済することをユーザが許可したときに、タッチされて選択されることを予定されたアイコンである。
その後、ステップ517において、ユーザが、その決済ボタン226を選択し、続いて、ステップS518において、管理サーバ50からのログアウトを要求するログアウト・リクエストが管理サーバ50に送信される。
これに対し、管理サーバ50は、ステップS609において、そのログアウト・リクエストを受信する。続いて、ステップS610において、確認応答信号ACKが携帯端末90に送信される。
これに対し、携帯端末90は、ステップS520において、その確認応答信号ACKを管理サーバ50から受信する。
なお、この出庫シーケンス・フローにおいては、駐車場選択フェーズに関し、図10および図15を参照して前述した入庫シーケンス・フローとは異なるアルゴリズムが採用されているが、同じアルゴリズムを採用してもよい。また、この出庫シーケンス・フローにおいては、入庫シーケンス・フローとは異なり、スキャンフェーズが存在しないが、存在することがより望ましい。
[第2の実施形態]
次に、本発明の例示的な第2実施形態に従う駐車場管理システムを説明する。ただし、第1実施形態に従う駐車場管理システムと共通する部分については重複した説明を省略し、異なる部分についてのみ詳細に説明する。本実施形態に従う駐車場管理システムは、本実施形態に従う駐車場管理方法を実行するように構成されている。
第1の実施形態においては、図15に概略的に示すように、スキャンフェーズが先に、駐車場選択フェーズが後に実行される順序となっている。すなわち、第1の実施形態においては、発信機30からの有効受信の成否を問わず、スキャンフェーズが行われ、その際、その発信機30が設置されている駐車場20の場所の特定は、携帯端末90の測位結果を利用して行われる。
よって、図1に示すように、1個の発信機30しか駐車場20に設置されておらず、その発信機30が故障している場合でも、その発信機30からの有効受信に失敗したとのサンプルデータを駐車場20の場所(発信機30を用いずに特定される場所)に関連付けて管理サーバ50に報告できる。
これに対し、本実施形態においては、駐車場選択フェーズが先に、かつ、その駐車場選択フェーズのうちの通常選択モードの実行後に限ってスキャンフェーズが実行される順序となっている。すなわち、本実施形態においては、発信機30からの有効受信に成功しない限り、スキャンフェーズが実行されないのである。そのため、本実施形態は、図1に示すように、1個の発信機30しか駐車場20に設置されていない事例には適していないかもしれない。
しかし、図16または図17に示すように、複数個の発信機30が同じ駐車場20に設置されており、それら発信機30が同時に故障するという可能性が低いと仮定することが妥当である場合には、それら発信機30のうちの少なくとも1個であって正常に作動するものから信号を有効に受信できさえすれば、その信号によって表される発信機IDから今回の駐車場20の場所を一義的にかつ正確に特定することができる。第1の実施形態においては、1個の発信機30からの有効受信に失敗した場合に、携帯端末90の測位結果を用いて1つの駐車場20を推定することになるが、その推定精度が常に高いとは限らない。
なお、以上説明したいくつかの実施形態は、種々の変更を加えた状態で実施することが可能であり、例えば、携帯端末90によるデータ処理のうちの少なくとも一部と同じデータ処理を管理サーバ50によって実行するように改良したり、逆に、管理サーバ50によるデータ処理のうちの少なくとも一部と同じデータ処理を携帯端末90によって実行するように改良することが可能である。
以上、本発明の例示的な実施の形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、前記[発明の概要]の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。