以下、本発明の例示的ないくつかの実施形態を図面に基づいて詳細に説明する。
<第1の実施形態>
図1には、本発明の例示的な第1の実施形態に従う無人席貸システム(「レンタル・システム管理システム」の一例および「レンタル対象管理システム」の一例であり、以下、単に「システム」という。)10が示されている。このシステム10は、概略的には、ユーザによるレンタル対象の予約を条件に、個別の発信機を用いてレンタル対象の場所認証を行うレンタル対象管理システムの一例である。
このシステム10は、複数の席貸施設20(図1には、それら席貸施設20のうちの代表的な席貸施設Aのみが図示されている)を集中的に管理するためのシステムである。各席貸施設20は、複数の貸席22を有しており、各貸席22は、1人のユーザに一時的に貸与される個別空間であるレンタル・スペースである。
1つの席貸施設20内における複数の貸席22は、概して、互いに詰めて配置されている。それら貸席22は、例えば、携帯端末90のGPS機能(後述)では空間的に互いに識別(分解)できないほどに互いに接近している複数のレンタル対象の一例である。
これに対し、複数の席貸施設20は、携帯端末90のGPS機能(後述)によって空間的に互いに識別(分解)できるほどに互いに離散している複数の施設の一例である。
ここで、貸席22の分類について説明するに、各貸席22は、第1類型のレンタル・スペースに属し、これは、各レンタル・スペースについてのユーザによる使用開始時刻から使用終了時刻までの各回の使用期間のうちの実質的な全体にわたり、そのレンタル・スペースの発信機30に対し、ユーザの携帯端末90が、発信機30との間で近距離通信可能な距離の範囲内に配置されるという特性を有する。同じ第1類型に属する別のレンタル・スペースとしては、滞在施設内の複数の部屋が存在する。
第2類型のレンタル・スペースも存在し、これは、各レンタル・スペースについてのユーザによる使用開始時刻から使用終了時刻までの各回の使用期間のうちの少なくとも開始段階と終了段階とにおいて、そのレンタル・スペースの発信機30に対し、ユーザの携帯端末90が、発信機30との間で近距離通信可能な距離の範囲内に配置されるという特性を有する。この第2類型に属するレンタル・スペースとしては、駐車場(駐輪場を含む)内の複数の車室、複数の貸しロッカールーム、複数の貸し倉庫、および、複数の貸し金庫が存在する。
このシステム10は、本実施形態に従う無人席貸方法を実行するように構成されている。その無人席貸方法は、ユーザに貸与可能な複数のレンタル・スペースを集中的に管理するレンタル・スペース管理方法の一例であり、そのレンタル・スペース管理方法は、ユーザに貸与可能な不動産である複数のレンタル対象を集中的に管理するレンタル対象管理方法の一例である。そのレンタル対象管理方法の別の例は、ユーザに貸与可能な動産である複数のレンタル対象(例えば、レンタカーや貸し自転車)を集中的に管理するレンタル対象管理方法である。
各席貸施設20は、無人式である。さらに、設備の削減・簡素化のため、各席貸施設20には、各貸席22に対する不正な進入および退出を阻止するために適宜開閉する装置(例えば、電子キー)も、ユーザから提示される暗号(例えば、パスワードやバーコード情報)を読み取るための装置も、ユーザがレンタル料を支払うための精算機も、ユーザにチケットを発行するための発券機も設置されていない。
なお、「コード」なる用語は、明細書の全体を通じて、「数字および/または記号の列」を意味し、具体的には、アナログ信号の状態をデジタル化して表現する数値的表記(例えば、2値表現)であって、個々のアナログ信号に固有の数値的表記である。「コード」なる用語は、識別という用途については、例えば、IDすなわち識別子と称される。
ところで、席貸施設20の管理方式として、各席貸施設20ごとに、その席貸施設20に設置された設備のみを用いて自立的に(個別的にないしは自己完結的に)管理される自立管理方式と、複数の席貸施設20が遠隔的にある管理サーバ50(図1参照)と通信することによってそれら席貸施設20を集中的に管理する集中管理方式とが存在する。本実施形態に従うシステム10は、その席貸施設管理方式として前述の集中管理方式を採用している。
具体的には、図1に示すように、このシステム10は、各席貸施設20内の各貸席22に1台ずつ設置される発信機30と、複数の席貸施設20および複数の貸席22を集中的に管理する管理センタ40に設置される管理サーバ50と、ユーザの携帯端末90とを備えている。
<発信機>
本実施形態においては、同じ席貸施設20に複数の貸席22が設置されており、各貸席22ごとに1台の発信機30が使用される。
各発信機30は、自身に固有の発信機ID(前述の「発信機コード」の一例)を表す識別信号を発信するように構成される。1つの発信機IDは、1つの貸席22にとっても固有であるため、後述のように、1つの貸席ID(「席貸コード」の一例)に1対1で対応付けられる。
図2に示すように、このシステム10においては、ユーザが、自身の携帯端末90を用いて、ユーザが現在滞在している貸席22に設置されている発信機30から前述の識別信号を、発信機30との接触状態または非接触状態(携帯端末90を発信機30にかざす状態または携帯端末90が、図5に複数個所で例示するように、発信機30から少し離れた状態)で、近距離一方向無線通信方式で受信するとともに、管理センタ40の管理サーバ50との間で遠距離双方向無線通信を行う。
ユーザの携帯端末90は、ユーザによって携帯されるとともに無線通信機能を有するデバイス、例えば、携帯電話機、スマートフォン、ラップトップ型コンピュータ、タブレット型コンピュータ、PDAなどである。
ここで、図1における複数台の発信機30を代表する1台の発信機30につき、ハードウエア構成(図3参照)およびソフトウエア構成(図4参照)を説明する。
まず、概念的に説明するに、発信機30は、対応する貸席22に少なくとも1台ずつ設置され、対応する貸席22に固有の席貸施設IDを識別し得る識別信号を発信する非接触式または接触式の通信デバイスである。発信機30は、少なくとも送信機能を有すれば足りるが、必要に応じ、受信機能をも併有するように構成してもよい。
次に、作動方式を説明するに、発信機30は、固有の識別信号を外部からのトリガ信号を要することなく能動的に、かつ、供給電力が不足しない限り永続的に発信する。
発信機30は、一般に、識別信号としてのビーコン信号を発信するビーコン装置、無線標識などの名称でも知られている装置である。この発信機30は、一例においては、原信号を変調することにより、対応する席貸施設IDを表す識別信号を生成し、その生成された識別信号を、IR信号、Bluetooth(登録商標)信号、NFC(近距離無線通信)信号などとして発信する。
次に、機能ブロック図である図3を参照してハードウエア構成を説明するに、発信機30は、プロセッサ100およびそのプロセッサ100によって実行される複数のアプリケーションを記憶するメモリ102を有するコンピュータ104を主体として構成されている。
この発信機30は、さらに、電源としての交換可能な使い捨て電池106を有している。電池106に代えて、充電可能な電池を採用したり、外部電源としての商用電源を採用したり、外部の磁界を利用して発電する発電機(例えば、トランスポンダ)を採用することが可能である。
この発信機30は、さらに、識別信号を生成して発信する発信部108を有している。その発信部108は、電池106によって作動させられるとともに、コントローラ110によって制御される。そのコントローラ110は、コンピュータ100によって制御される。
次に、図4を参照して発信機30のソフトウエア構成を説明するに、発信機30のプロセッサ100は、図4にフローチャートで概念的に表されているプログラムを反復的に実行する。
このプログラムの各回の実行時には、まず、ステップS1において、メモリ102から発信機IDが読み込まれる。その発信機IDは、その発信機30が設置される1つの貸席22に割り当てられた貸席IDに1対1に対応する。
続いて、ステップS2において、前記読み込まれた発信機IDが反映されるように、原信号(例えば、搬送信号)を変調するための信号がコントローラ110に対して出力される。そのコントローラ110は、発信部108を制御し、その結果、発信部108は、今回発信すべき識別信号を生成する。その後、ステップS3において、その生成された識別信号が発信部108から発信される。続いて、ステップS1に戻る。
ここで、この発信機30に関連付けてユーザの携帯端末90の一機能を説明するに、その携帯端末90は、発信機30から識別信号を受信している状態で、その携帯端末90のコンピュータ134(図6参照)に予めインストールされているあるプログラムを起動させると、前記受信した識別信号をリアルタイムで復調し、それにより、前記発信機IDをリアルタイムで解読する。
さらに、携帯端末90は、発信機30から識別信号を受信している状態で、その受信した識別信号に基づき、その識別信号を発信したときの発信機30の位置と、その識別信号を受信したときの携帯端末90の位置との間の距離を測定することも行う。
すなわち、携帯端末90は、発信機30から受信した識別信号に基づき、その発信機30に対応する発信機IDと、そのときの発信機30との距離との双方を獲得するようになっているのである。
携帯端末90のユーザは、自身の携帯端末90を持ったまま発信機30に接近するか、または、その携帯端末90を発信機30のうちの発信部108に完全にまたはほぼ接触させると、携帯端末90は、発信機30から識別信号を非接触式または接触式で受信することができる。
これに対し、携帯端末90のユーザが自身の携帯端末90を持ったまま特定の受信エリア内に進入すると、携帯端末90は、発信機30から識別信号を非接触式で受信することができる。
図5に概念的に平面図で示すように、各発信機30には、2種類の受信エリアが割り当てられる。それらは、受信可能エリア(図示しない)と有効受信エリアである。それらエリアは、いずれも、各発信機30を発信源とする円で概して定義され、受信可能エリアは、最大受信半径を有するのに対し、有効受信エリアは、有効受信半径を有する。
しかし、具体的には、受信可能エリアは、各発信機30の電力供給が正常である場合に、その発信機30からの識別信号が到達可能なエリア、すなわち、そのエリア内に存在する限り、携帯端末90がその識別信号を受信可能なエリアを意味する。
これに対し、有効受信エリアは、受信可能エリアの最大受信半径より小さい有効受信半径を有している。最大受信半径は、任意に設定することが不可能であるのに対し、有効受信半径は、例えば携帯端末90の信号処理特性の設定次第で任意に設定することが可能である。
有効受信半径は、後に図5を参照して詳述する貸席22の標準的な寸法・幾何学から自明であるように、例えば、50cmないし3mの範囲内、または、1mないし2mの範囲内にある。また、最大受信半径は、例えば、50mないし70mの範囲内にある。
すなわち、最大受信半径は、ハードウエアによって決まる受信限度を意味するのに対し、有効受信半径は、ソフトウエアによって決まる受信限度を意味するということが可能なのである。
前述のように、携帯端末90は、それが受信した識別信号を発信したときの発信機30との距離を測定する。その距離測定値は、有効受信半径を超えることもあれば、超えないこともある。そして、その距離測定値が受信有効半径を超えないときは、携帯端末90が有効受信エリア(図5参照)内に存在するときであるのに対し、その距離測定値が受信有効半径を超えるときは、携帯端末90が受信可能エリア内には存在するが有効受信エリア内には存在しないときである。
携帯端末90は、発信機30から識別信号を受信した後、前記距離測定値が有効受信半径の設定値以下であるか否かを判定し、その設定値以下であると判定すると、携帯端末90が現在、有効受信エリア内に位置するから、携帯端末90は、「発信機30からの識別信号を有効に受信した(以下、単に「識別信号を受信した」ともいう。)」と判定する。ここに、「有効に受信した」ということは、携帯端末90がいずれかの発信機30を検知した、特定した、または識別したということを意味する。
これに対し、携帯端末90は、前記距離測定値が前記設定値より大きいと判定すると、携帯端末90が現在、有効受信エリア外に位置するから、携帯端末90は、「発信機30からの識別信号を有効に受信していない(以下、単に「識別信号を受信していない」ともいう。)」と判定する。
すなわち、本実施形態においては、携帯端末90が有効受信エリア外に位置する場合には、実際には、携帯端末90が識別信号を受信しているにもかかわらず、みかけ上、携帯端末90は識別信号を受信していないこととしてソフトウエア上で取り扱われることになるのである。
図5には、ユーザ1人(ユーザX)に貸与される貸席22(貸席P)が正面図で示されている。貸席22は、天板23を有する机24と、ユーザが着席可能な椅子26とを有する。一例においては、発信機30が、天板23に設置される。
また、別の例においては、発信機30が、天板23の、互いに前後方向に対向する近位縁27および遠位縁28のうち、ユーザの着席位置から離れた遠位縁28の近傍に設置される。
また、さらに別の例においては、発信機30が、天板23の遠位縁28のうち、それの幅方向中心位置から左寄り(右寄りでも可)に偏った位置に設置される。その結果、ユーザが書類などのアイテムを天板23上に載置しても、そのアイテムによって発信機30が遮蔽されて信号が途絶する事態が可及的に回避される。
図5には、発信機30に割り当てられる有効受信エリアの一例が平面図で示されている。この例においては、ユーザXが椅子26に着席している状態で、携帯端末90がユーザXによって携帯されているか、または、机23の天板27上の任意の位置に置かれていれば、携帯端末90が、発信機30を中心とする大きい有効受信半径の有効受信エリア内に存在するように、発信機30の発信特性および携帯端末90の信号処理特性が設定されている。
この例においては、ユーザXは、自身の携帯端末90をわざわざ自分用の発信機30にかざしたり、自分用の発信機30の近くに置くことを強制されないという利点がある。一方、その携帯端末90は、自分用の発信機30の有効受信エリア内のみならず隣の発信機30の有効受信エリア内にも存在することになる。
しかし、本実施形態によれば、貸席22の予約情報(いずれかの発信機30からの携帯端末90の初回の受信に先立ってユーザによって選択された貸席22の識別情報)に基づき、複数の発信機30が、予約された貸席22に設置されているはずの正規の発信機30(標的発信機)と、それ以外の非正規の発信機30(非標的発信機)とに分類される。ユーザの携帯端末90が選択貸席22において非正規の発信機30からの信号を受信してしまってもその信号は無効化されて参照されず、正規の発信機30からの信号のみが有効化されて参照されることにより、ユーザの現在位置、すなわち、ユーザが真に選択貸席22と同じ位置またはそれの近傍に位置するか否かが推定される。
図5には、小さい有効受信半径の有効受信エリアも示されている。この有効受信エリアを採用すれば、正規の発信機30の有効受信エリアと、隣の発信機30の有効受信エリアとの間にオーバーラップが存在しない。しかし、この態様においては、携帯端末90が発信機30を検知するためにユーザがその都度、わざわざ、携帯端末90を発信機30に接近させてかざすかまたは接触させることを強制される。
<携帯端末>
次に、機能ブロック図である図6を参照してユーザの携帯端末90のハードウエア構成を説明するに、携帯端末90は、プロセッサ130およびそのプロセッサ130によって実行される複数のアプリケーションを記憶するメモリ132を有するコンピュータ134を主体として構成されている。
この携帯端末90は、さらに、情報を、例えば図14において符号「135」で示す画面(面積が有限で可変または不変であるウィンドウを有する)上に表示する表示部(例えば、液晶ディスプレイ)136と、発信機30および管理サーバ50からの信号を受信する受信部138と、信号を生成してその信号を管理サーバ50に送信する送信部140とを有する。
この携帯端末90は、さらに、ユーザからデータやコマンドを入力するための入力部150を有する。その入力部150は、例えば、所望の情報(例えば、コマンド、データなど)を携帯端末90に入力するためにユーザによって操作可能な操作部を有する。その操作部としては、ユーザによって操作可能なアイコン(例えば、仮想的なボタン)を表示するタッチスクリーン、ユーザによって操作可能な物理的な操作部(例えば、キーボード、キーパッド、ボタンなど)、音声を感知するマイクなどがあるが、これらに限定されない。
この携帯端末90は、さらに、GPS(衛星測位システム)受信機152を有する。GPS受信機152は、よく知られているように、複数のGPS衛星から複数のGPS信号を受信し、それらGPS信号に基づき、GPS受信機152の地球上における位置(緯度、経度および高度)を三角測量によって測定する。すなわち、この携帯端末90は、衛星を利用する測位機能を有するのである。
図7に示すように、メモリ132は、地図データメモリ161、席貸施設データメモリ163、貸席データメモリ165および予約状況テーブル・メモリ167を含む複数のデータメモリを有する。
地図データメモリ161には、ユーザの現在位置に応じて、ユーザの携帯端末90が管理サーバ50または別の地図データベース(図示しない)からダウンロードした地図データが一時的に記憶される。その地図データに基づき、表示部136の画面135(図14参照)上に地図(「部分地図」の一例)が表示される。その画面135上に表示される地図は、ユーザが移動するにつれて時々刻々変化する。
図7に概念的に表すように、席貸施設データメモリ163には、複数の席貸施設IDと複数の席貸施設位置データとの対応関係が、管理サーバ50からダウンロードされて記憶されることが可能である。複数の席貸施設IDは、システム10によって集中的に管理される複数の席貸施設20にそれぞれ対応している。また、複数の席貸施設位置データは、それぞれ、対応する席貸施設20の地上位置の経緯度(緯度X,経度Y)を表す。
席貸施設データメモリ163は、各瞬間ごとに、画面135上に表示される地図上に地理的に存在する複数の席貸施設20に対応する複数の席貸施設位置データが、それに対応する複数の席貸施設IDと共に一時的に記憶される。
携帯端末90においては、画面135上に、前記地図データに基づく地図が表示され、さらに、その地図上に、各瞬間ごとに、そのときに席貸施設データメモリ163に記憶されている複数の席貸施設位置データに基づき、前記ダウンロードされた複数の席貸施設20のうち、携帯端末90の現在位置の近傍に位置する少数の候補席貸施設20の各位置がオーバーレイ表示される(図14参照)。
ここに、「少数の候補席貸施設20」は、前記ダウンロードされた複数の席貸施設20のうち、携帯端末90の現在位置に近いという地理上の理由で、画面135上に表示されている複数の席貸施設20を意味し、携帯端末90の現在位置から遠いという地理上の理由で、画面135から外れている席貸施設20は、対象外とされる。
図8に概念的に表すように、図6の貸席データメモリ165には、複数の席貸施設IDと複数の貸席IDと複数の正規発信機IDとの対応関係が、管理サーバ50からダウンロードされて記憶されることが可能である。複数の貸席22のうちのいずれかがユーザによって選択されれば、それに対応する1つの貸席IDが決まり、ひいては、それに対応する1つの正規発信機IDが決まる。
予約状況テーブル・メモリ167には、後述の予約状況テーブルが管理サーバ50から適宜ダウンロードされて保存される。
図10(a)に示すように、携帯端末90のメモリ132には、携帯端末90用の席貸サービス・プログラムが記憶されており、その席貸サービス・プログラムは、次の複数のモジュールを有している。
1)予約モジュール
これは、後に図13を参照して詳述するように、ユーザが、席貸施設20に到着前に、いずれかの貸席22を予約することを支援するモジュールである。ここに、「予約する」とは、ユーザが、希望する席貸施設20の場所および希望する貸席22の場所に関する場所情報ならびに予定開始時刻および予定終了時刻という時間情報を入力する作業と等価である。
2)予約変更モジュール
これは、後に図18を参照して詳述するように、ユーザが、予約した貸席22の使用開始後であって、使用終了前に(予約した貸席22への滞在中に)、その貸席22の位置において、前記予約内容に含まれる予定終了時刻を遅らせるように予約変更することを支援するモジュールである。
3)使用前警告モジュール
これは、図示しないが、各ユーザの予約内容に含まれる予定終了時刻の後に同じ貸席22を予約している別のユーザが存在する場合には、今回のユーザに対し、前記予約の成立後であってその予約内容に含まれる予定開始時刻より前の期間中、「同じ貸席を今回のユーザの使用終了後に別のユーザが使用する予定であるから、予定終了時刻を遅らせるように予約変更することができず、よって、予定終了時刻までに貸席22から退席して欲しい」旨の、ユーザに注意を喚起するメッセージを今回のユーザの携帯端末90に個別に送信するモジュールである。
4)使用開始処理モジュール
これは、後に図15を参照して詳述するように、ユーザが、自身の予約に従って、貸席22の使用を開始することを支援するとともに、ユーザが、予約した貸席22において、その使用の開始に先立ち、前記予約内容に含まれる予定開始時刻を事実上、早めるように予約変更することを支援するモジュールである。
5)滞在判定モジュール
これは、後に図16を参照して詳述するように、ユーザが、貸席22の使用中、貸席22に実際に滞在しているか滞在していないか(不存在であるか)を時々刻々、反復的に判定するモジュールである。
6)使用終了処理モジュール
これは、後に図17を参照して詳述するように、ユーザが、自身の予約に従って、貸席22の使用を終了し、レンタル料金を電子決済することを支援するモジュールである。
<管理サーバ>
次に、機能ブロック図である図9を参照して管理サーバ50のハードウエア構成を説明するに、管理サーバ50は、プロセッサ160およびそのプロセッサ160によって実行される複数のアプリケーションを記憶するメモリ162を有するコンピュータ164を主体として構成されている。
この管理サーバ50は、さらに、情報を表示する表示部(例えば、液晶ディスプレイ)166と、携帯端末90からの信号を受信する受信部168と、信号を生成してその信号を携帯端末90に送信する送信部170と、現在時刻を計測する時計172とを有する。この管理サーバ50は、発信機30からの受信を直接的には行わず、事実上、携帯端末90を介して行うことになる。
図10(b)に示すように、管理サーバ50のメモリ162には、管理サーバ50用の席貸サービス・プログラムが記憶されており、その席貸サービス・プログラムは、次の複数のモジュールを有している。
1)予約モジュール
これは、後に図13を参照して詳述するように、携帯端末90の予約モジュールと同じ機能を有するモジュールである。
2)予約変更モジュール
これは、後に図18を参照して詳述するように、携帯端末90の予約変更モジュールと同じ機能を有するモジュールである。
3)使用前警告モジュール
これは、図示しないが、携帯端末90の使用前警告モジュールと同じ機能を有するモジュールである。
4)使用開始処理モジュール
これは、後に図15を参照して詳述するように、携帯端末90の使用開始処理モジュールと同じ機能を有するモジュールである。
5)滞在判定モジュール
これは、後に図16を参照して詳述するように、携帯端末90の滞在判定モジュールと同じ機能を有するモジュールである。
6)使用終了処理モジュール
これは、後に図17を参照して詳述するように、携帯端末90の使用終了処理モジュールと同じ機能を有するモジュールである。
<予約シーケンスの概要>
図11(a)には、携帯端末90および管理サーバ50による前記予約モジュールの実行により、複数人のユーザによる複数の貸席22の予約状況を管理するための予約状況テーブルの一例が示されている。
この予約状況テーブルは、管理サーバ50において作成・更新され、その最新版が、携帯端末90と共有される。この予約状況テーブルは、各席貸施設20ごとに、かつ、各貸席22ごとに、予約の有無および予定使用時間帯(日時を含む)を表示する。ユーザは、自身の携帯端末90の画面135上でこの予約状況テーブルを目視し、それを参照して、空席のある席貸施設20を探し、その席貸施設20の複数の貸席22のうち、空き時間のあるものを探して、希望する日時および時間帯を指定する。
図11(a)においては、予約状況テーブル中の各貸席22ごとの時間軸(0時0分から23時59分まで)のうち、予約状況テーブルの最新更新時刻において、斜線でハッチングされた水平バーが存在する時間帯が、既に予約が存在する時間帯、すなわち、先約あり時間帯を表示する一方、前記バーが存在しない時間帯が、未だ予約が存在しない時間帯、すなわち、先約なし時間帯を表示している。
ユーザは、自身の携帯端末90に、図14(c)に例示するように、選択した席貸施設20の識別情報と、選択した貸席22の識別情報と、使用開始日時と、使用終了日時とを入力し、それにより、該当する貸席22を予約することになる。
図11(b)には、携帯端末90および管理サーバ50による前記予約モジュールの実行により、複数人のユーザの予約内容を管理するためのユーザ別予約内容ファイルの一例が示されている。
このユーザ別予約内容ファイルは、管理サーバ50において作成・更新される。このユーザ別予約内容ファイルは、各ユーザごとに、本人認証情報(ユーザID,パスワードなど)、選択された席貸施設20の場所を特定するための場所情報(選択施設20に固有のID)、選択された貸席22の場所を特定するための場所情報(選択貸席22に固有のID)、選択貸席22についての予定使用時間帯を定義するための時間情報(予定開始時刻,予定終了時刻,予定使用時間長さなど)、ユーザが今回の席貸サービスを受けるために遵守することを要求される規則をユーザが違反したためにそのユーザに課されるペナルティの種別などを表す。
<全体シーケンスの概要>
図12には、ユーザが貸席22(貸席P)につき、予定開始時刻を15:00、予定終了時刻を18:00として予約した場合を例にとり、主要なシーケンスの概要が複数のタイムチャートで例示されている。
同図(図21においても同じ)において、「受信」というラベルを付したタイムチャートは、携帯端末90が、各瞬間ごとに、正規発信機IDを受信しているか否かを、説明の便宜上、携帯端末90が正規発信機IDを受信していない状態でローレベルとなり、受信したいる状態でハイレベルとなるパルス信号で表現している。
1)使用開始
ユーザがある日の15:30という時刻に貸席22に着席したと仮定すると、ユーザの携帯端末90が必然的に正規発信機30の有効受信エリア内に進入する。このとき、ユーザが携帯端末90を携帯したままか、または、携帯端末90を発信機30にかざすことにより、携帯端末90が発信機30からの受信を開始する。なお、前記使用開始モジュールは、ユーザが席貸施設20に到着する前から起動させられていると仮定する。
その結果、15:30という時刻に、携帯端末90が正規発信機IDを受信しない状態(携帯端末90がいずれかの発信機30から信号を受信したがその信号が正規発信機IDとは異なる実発信機IDを表す非正規ID受信状態と、携帯端末90がいずれの発信機30からも信号を受信しない完全非受信状態との双方を含む)から受信する状態に遷移したという事象(前述の「第1遷移」の一例であり、図12においては、ユーザによる1回の貸席22の使用期間に対応する1個の受信パルス信号のうちの立ち上がりエッジ)が発生したと仮定すると、携帯端末90(または管理サーバ50)が、ユーザが実際に、貸席22に着席した、すなわち、貸席22の使用を開始したと判定する。
なぜなら、携帯端末90が正規発信機IDを受信しない状態から受信する状態に遷移するという事象(すなわち、実発信機IDが正規発信機IDと一致するとの最初の判定)は、本実施形態においては、ユーザが正規の貸席22に着席しない限り発生しない排他的な事象であるからである。
続いて、ユーザは、前記事象の発生時刻から例えば5分という第1制限時間内に使用開始リクエスト(前述の「第1事象」の一例)を携帯端末90に入力する。
その使用開始リクエストに応答し、管理サーバ50は、ユーザによる貸席22の使用開始を許可する。その時刻が、実使用開始時刻であるが、原則として、予定開始時刻である15:00からユーザへの課金が開始される。具体的には、予定開始時刻から、ユーザにとっての最終的なレンタル料金の額を計算するために参照される全使用時間(レンタル時間、貸与時間)のカウントが開始される。
2)使用途中
ユーザは、貸席22の使用開始後、その貸席22から長時間退席することは通常はなく(一時的に中座することはあるにしても)、よって、貸席22の使用中は、携帯端末90が発信機30からの信号を受信し続け(図12においては、前記1個の受信パルス信号のうちのハイレベル継続部)、それにより、携帯端末90(または管理サーバ50)は、ユーザが貸席22に滞在しているとの判定を継続する。
3)使用終了
ユーザが同じ日の17:30という時刻に貸席22から退席したと仮定すると、ユーザの携帯端末90が正規発信機30の有効受信エリアから退出する。このとき、ユーザが携帯端末90を携帯したまま、ユーザの携帯端末90が正規発信機30からの受信を終了する。
その結果、携帯端末90が正規発信機IDを受信する状態から受信しない状態に遷移したという事象(前述の「第2遷移」の一例であり、図12においては、前記1個の受信パルス信号のうちの立ち下がりエッジ)が発生したと仮定すると、携帯端末90(または管理サーバ50)が、ユーザが実際に、貸席22から退席した、すなわち、貸席22の使用を終了したと判定する。
なぜなら、携帯端末90が正規発信機IDを受信する状態から受信しない状態に遷移するという事象は、本実施形態においては、ユーザが正規の貸席22から退席しない限り発生しない排他的な事象であるからである。
続いて、ユーザは、前記事象の発生時刻から例えば5分という第2制限時間内に使用終了リクエスト(前述の「第2事象」の一例)を携帯端末90に入力する。
その使用終了リクエストに応答し、管理サーバ50は、ユーザによる貸席22の使用終了を許可する。その時刻が、実使用終了時刻であるが、原則として、予定終了時刻である18:00までユーザへの課金が継続される。具体的には、予定終了時刻に、ユーザにとっての最終的なレンタル料金の額を計算するために参照される全使用時間(レンタル時間、貸与時間)のカウントが終了する。
レンタル料金の計算が終了すると、ユーザは、携帯端末90を介してレンタル料金を電子的に決済する。
<予約シーケンス>
図13には、ユーザが、予約したい席貸施設20から離れた場所(例えば、図1に示すように、自宅)において、携帯端末90を管理サーバ90に接続し、その席貸施設20内のいずれかの貸席22を予約するために、携帯端末90と、遠隔地に位置する管理サーバ50との間で行われる通信の一例が時系列的にシーケンス・フローで表されている。
携帯端末90において、ユーザにより、前記席貸サービス・プログラム(既に管理サーバ50からダウンロードされて携帯端末90の132にインストールされている)が起動されると、「予約」、「使用開始」、「使用開始リクエスト」、「使用終了リクエスト」および「予約変更」という複数のボタン(ユーザによって選択可能な表示対象)が携帯端末90の画面上に表示される。
今回は、「予約」というボタンがユーザによって選択されると、携帯端末90用の席貸サービス・プログラムのうち前記予約モジュールが携帯端末90のプロセッサ130によって実行されるとともに、管理サーバ50用の席貸サービス・プログラムのうち前記予約モジュールが管理サーバ50のプロセッサ160によって実行される。
携帯端末90用の予約モジュールが携帯端末90のプロセッサ130によって実行されると、まず、ステップ101において、携帯端末90が、GPS受信機152が外部から受信したGPS信号に基づき、ユーザの現在位置(経緯度)が測定されるように作動する。
次に、ステップS102において、その測定されたユーザの現在位置が、地図を表示部136の画面135上に表示するためにプロセッサ130によって参照される基準位置(表示基準点の位置(経緯度))とされる。さらに、全体地図のうち、画面135上のウィンドウ内に一度に表示可能なサイズを有する部分であって前記基準位置が存在するものが、地図の表示範囲(すなわち、前記全体地図のうち、前記ウィンドウ内に各瞬間に表示される領域)に決定される。
図14(a)に例示するように、ユーザが時間と共に地上を移動すると、それに追従するように前記基準位置202(同図において黒色の三角形で示す)も時間と共に移動する。その結果、ユーザの移動に伴い、地図の表示範囲も全体地図上を時間と共に移動し、ひいては、前記ウィンドウ内に表示される地図の画像も時間と共に変化することになる。
続いて、ステップS103において、管理サーバ50にログインするためのログイン・リクエスト(「サービス開始信号」の一例)が、今回のユーザを識別するためのユーザIDおよびパスワードと共に管理サーバ50に送信される。
これに対し、管理サーバ50用の予約モジュールが管理サーバ50のプロセッサ160によって実行されると、管理サーバ50は、ステップS201において、前記ログイン・リクエストをユーザIDおよびパスワードと共に受信し、続いて、ステップS202において、前記複数の席貸施設20に関する施設データ(その施設データの複数の構成要素については、図7参照)と、それら席貸施設20に属する複数の貸席22に関する貸席データ(その貸席データの複数の構成要素については、図8参照)と、前記予約状況テーブル(図11(a)参照)とを管理サーバ50のメモリ162(または別のメモリ)において検索する。
その後、ステップS203において、それら検索された施設データ、貸席データおよび予約状況テーブルが携帯端末90に送信される。
これに対し、携帯端末90は、ステップS104において、それら施設データ、貸席データおよび予約状況テーブルを受信する。受信した施設データは、図7に示す席貸施設データメモリ163に保存され、その結果、図7に示すテーブルが構築される。また、受信した貸席データは、図8に示す貸席データメモリ165に保存され、その結果、図8に示すテーブルが構築される。受信した予約状況テーブル(図11(a)参照)は、予約状況テーブル・メモリ167に保存される。
続いて、ステップS105において、前記保存された施設データに基づき、画面135上に表示されている地図上に、複数の席貸施設20のうち、前記現在位置の近傍に位置するものが少数の候補施設20としてオーバーレイ表示される。
このステップ105においては、画面135上に、受信された複数の施設データによって表される複数の席貸施設20(管理サーバ50のメモリ162に保存されているすべての席貸施設20)のすべてが表示されるわけではない。ユーザの現在位置と画面135のサイズとによって決まる、前記複数の席貸施設20より少数の複数の席貸施設20のみが画面135上に表示される。すなわち、管理サーバ50から受信した複数の席貸施設20が、ユーザの現在位置と画面135のサイズとによってさらに、少数の候補施設20に絞り込まれるのである。
一例においては、図14(a)に示すように、画面135上に表示されている地図上に、ユーザの現在位置が黒色の三角形202を用いてオーバーレイ表示されるとともに、複数の候補施設20が複数の施設アイコン204を用いてオーバーレイ表示される。この例においては、3個の施設アイコン204が、「A」、「B」および「C」というアルファベットが四角形の枠に包囲されて成る図形として構成されている。
続いて、ステップS106において、ユーザが、画面135上において、いずれかの候補施設20の表示位置に指でタッチすることにより、いずれかの席貸施設20を今回の選択施設20として選択する。
具体的には、ユーザが、画面135上において、いずれかの候補施設20の表示位置に指でタッチすると、そのタッチ位置が表示部136のタッチスクリーンによって検出され、そのタッチ位置が、例えば、地図上の経緯度(絶対座標系であるグローバル座標系によって定義される)またはそれに対応するXY座標情報(相対座標系であるデバイス座標系によって定義される)である地図座標情報(位置情報)に変換される。その地図座標情報に基づき、いずれかの候補施設20が特定される。
その後、ステップS107において、図14(b)に例示するように、前記予約状況テーブルが画面135上に表示される。続いて、ステップS108において、ユーザが、図14(c)に例示するように、予約したい席貸施設20の識別情報(例えば、名称)と、予約したい貸席20の識別情報(例えば、番号)と、使用開始日時と、使用終了日時とを入力する。
その後、ステップS109において、携帯端末90が、前記入力された予約内容を管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS204において、前記予約内容を受信する。続いて、管理サーバ50は、ステップS205において、その受信した予約内容を、前記複数のユーザ別予約内容ファイル(図11(b)参照)のうち、今回のユーザに関連付けられているものに登録し、さらに、メモリ162に保存されている予約状況テーブルを、前記受信した予約内容が反映されるように、更新する。
その後、管理サーバ50は、ステップS206において、予約が完了した旨のメッセージを携帯端末90に送信する。
これに対し、携帯端末90は、前記受信したメッセージを画面135上に表示するか音声で出力する。この表示により、ユーザが、自身の予約が成立したことを知らされる。
<使用開始シーケンス>
図15には、ユーザが、予約してあった席貸施設20のうちの予約してあった貸席22(以下、単に「貸席22」ともいう。)に到着して着席した直後に、その貸席22の使用開始を許可してもらうために、その貸席22に位置する発信機30と、ユーザの携帯端末90と、管理サーバ50との間で行われる通信の一例が時系列的にシーケンス・フローで表されている。
発信機30は、自身に固有の識別信号を自発的にかつ継続的に発信する。ユーザが、予約してあった貸席22に着席すれば、携帯端末90が、発信機30の有効受信エリア内に存在することになるため(図5参照)、携帯端末90が発信機30からの識別信号を有効に受信する。
今回は、携帯端末90の画面上において「使用開始」というボタンがユーザによって選択されると、携帯端末90用の使用開始処理モジュールが携帯端末90によって実行される。その実行により、まず、ステップ151において、携帯端末90が、管理サーバ50にログインするためのログイン・リクエストが、今回のユーザを識別するためのユーザIDおよびパスワードと共に管理サーバ50に送信される。
これに対し、管理サーバ50用の使用開始処理モジュールが管理サーバ50によって実行されると、管理サーバ50は、ステップS251において、前記ログイン・リクエストをユーザIDおよびパスワードと共に受信し、続いて、ステップS252において、前記複数のユーザ別予約内容ファイルのうち、今回のユーザに関連付けられているものがメモリ162において検索される。さらに、その検索されたユーザ別予約内容ファイルにおいて、前記複数の席貸施設20のうち、予約された席貸施設20(選択施設)に関する情報と、その席貸施設20の複数の貸席22のうち、予約された貸席22(選択貸席)に関する情報とが、今回のユーザ予約関連情報として検索される。
その後、ステップS253において、その検索された今回のユーザ予約関連情報が携帯端末90に送信される。
これに対し、携帯端末90は、ステップS152において、今回のユーザ予約関連情報を受信する。続いて、ステップS153において、その今回のユーザ予約関連情報において、予約されている貸席22に設置されているはずである正規の発信機30に予め割り当てられている発信機コードが正規発信機コードとして検索される。ユーザにとっての正規発信機コードが取得されるのである。
続いて、ステップS154において、携帯端末90は、いずれかの発信機30からの信号を受信するための受信試行を行う。
一方、前述のように、携帯端末90が現在、前記受信可能エリア外に位置する場合には、携帯端末90は発信機30から識別信号を全く受信できない。これに対し、携帯端末90が現在、前記受信可能エリア内に位置する場合には、携帯端末90は発信機30から識別信号を受信できる。
また、携帯端末90がいずれかの発信機30から識別信号を受信したとしても、携帯端末90が現在、そのいずれかの発信機30にとっての前記有効受信エリア外に位置する可能性もあれば有効受信エリア内に存在する可能性もある。
そこで、ステップS154に引き続き、ステップS154aにおいて、携帯端末90は、携帯端末90がいずれかの発信機30から識別信号を有効に受信したか否かを判定する。
具体的には、携帯端末90は、まず、携帯端末90が何らかの識別信号を受信したかを判定することにより、前記受信可能エリア内に存在するか否かを判定する。受信可能エリア内に存在すると判定した場合には、続いて、携帯端末90は、いずれかの発信機30から識別信号を有効に受信したか否かを判定する。
具体的には、携帯端末90は、その受信した識別信号に基づき、今回の発信機30と携帯端末90との距離を測定する。さらに、携帯端末90は、その距離測定値が前記設定値より小さいか否か、すなわち、携帯端末90が現在、前記有効受信エリア内に位置するか否かを判定する。
前記距離測定値が前記設定値より小さい場合には、ステップS154aの判定がYESとなり、その後、ステップS155に移行するが、そうではない場合には、ステップS154aの判定がNOとなり、その後、ステップS154に戻り、携帯端末90による受信試行が反復される。
ステップS155においては、携帯端末90は、前記受信した識別信号を復調し、続いて、ステップS156において、携帯端末90は、その復調された識別信号によって表される発信機IDを実発信機IDとして解読する。
前記復調された識別信号は、複数桁の二進数で表記されるコードである場合には、例えば、そのコードが、予め準備された変換表(例えば、管理サーバ50から事前にダウンロードされたもの)を用いて、発信機IDに変換される。ただし、用法上、「コード」であるか「ID」であるかという違いは、その用途が識別である以上、重要ではない。
続いて、ステップS157において、携帯端末90は、そのようにして解読された実発信機IDと、ステップS153の実行によって取得された今回の1つの正規発信機IDとが互いに一致するか否かを判定する。すなわち、ID照合が行われるのである。
ここに、「実発信機ID」は、複数の貸席22のうち、ユーザによって実際に選択されて着席されたものに実際に設置されている発信機(選択された実在発信機)30に対応する発信機IDを意味し、一方、「正規発信機ID」は、複数の貸席22のうち、ユーザが携帯端末90を操作することによって仮想的に選択されたものに設置されているはずの発信機(選択された仮想発信機)30に対応する発信機IDを意味する。
その後、ステップS158において、携帯端末90は、実発信機IDと正規発信機IDとが互いに一致したか否か、すなわち、前記ID照合に成功したか否かを判定する。すなわち、携帯端末90が正規発信機IDを表す信号を受信しない状態から受信する状態に遷移する第1遷移が、ユーザによって当該使用開始処理モジュールが起動されてから最初に発生したか否かを判定するのである
前記ID照合に成功しなかった場合には、ステップS158の判定がNOとなり、その後、ステップS159において、携帯端末90は、ユーザに対し、再度、携帯端末90によって発信機30を検出することを再試行することを、例えば画面135上に適切なメッセージを表示するか音声で出力することなどを行うことにより、催促する。その後、ステップS154に戻る。
これに対し、前記ID照合に成功した場合には、ステップS158の判定がYESとなり、その後、ステップS160において、携帯端末90は、現在時刻において、ユーザが今回の貸席22の使用を開始したと判定する。
一例においては、ユーザが当該使用開始処理モジュールを起動させた後、今回の席貸施設20に到着したが、未だ、予約してあった貸席22に到着しないうちは、ステップS154aの判定がNOとなる。ユーザが、やがて、その貸席22に到着して着席すると、そのステップS154aの判定がNOからYESに遷移する。
このとき、携帯端末90が正規発信機IDを表す信号を受信していれば、前記ID照合に成功し、ステップS158の判定がYESとなる。その後、ステップS160において、現在時刻において初回の第1遷移が発生したと判定される。
ここで、ステップS158の判定がYESとなるタイミングは、携帯端末90が正規発信機IDを受信しない状態から受信する状態に遷移するタイミング(図12の例における「立ち上がりエッジ」の時間的位置に一致する)に一致する。
その後、ステップS161において、ユーザから携帯端末90に使用開始リクエストが入力された(例えば、前述の、使用開始リクエストのためのボタンがユーザによって選択された)か否かが判定される。使用開始リクエストが入力された場合には、ステップS161の判定がYESとなり、ステップS162において、ユーザが指定して予定開始時刻より早いか否かが判定される。実際に、ユーザの予定開始時刻より早い時刻に今回の貸席22に到着して使用し始めたか否かが判定されるのである。
今回は、ユーザの実使用開始時刻が予定開始時刻より早くはないと仮定すれば、ステップS162の判定がNOとなり、その後、ステップS163において、今回の課金条件として通常の課金条件(予定開始時刻からの課金開始)が選択される。これに対し、今回は、ユーザの実使用開始時刻が予定開始時刻より早いと仮定すれば、ステップS162の判定がYESとなり、その後、ステップS164において、今回の課金条件として特別の課金条件(実開始時刻からの課金開始)が選択される。
いずれの場合にも、その後、ステップS165において、ユーザが実際に、予約してあった貸席22を使用しているという判定結果と、今回の課金条件とが、ユーザに関連付けて、管理サーバ50に送信される。
以上、携帯端末90が正規の発信機30を有効に受信した直後にユーザから使用開始リクエストが正常に発令された場合を説明したが、発令されなかった場合には、ステップS161の判定がNOとなり、その後、ステップS166において、現在、ステップS160の実行時刻からの経過時間が第1制限時間(例えば、5分)内であるか否かが判定される。第1制限時間内である場合には、ステップS166の判定がYESとなり、ステップS167において、ユーザに対し、使用開始リクエストを入力することが、例えば画面135上に適切なメッセージが表示されるか音声で出力されることなどが行われることにより、催促される。続いて、ステップS161に戻る。
これに対し、現在、ステップS160の実行時刻からの経過時間が第1制限時間を超えている場合には、ステップS166の判定がNOとなり、その後、ステップS168において、ユーザに第1違反行為が発生したと判定される。
続いて、ステップS165において、ユーザに第1違反行為が発生したことが管理サーバ50に送信される。 そのステップS165の実行終了後は、ユーザからの指示を待つことなく自動的に前述の滞在判定シーケンスに移行する。
これに対し、管理サーバ50は、ステップS254において、前記ステップS165の実行によって携帯端末90が送信した情報を受信する。
その後、ステップS255において、携帯端末90から受信した違反行為をユーザに関連付けてメモリ162に記録する。続いて、ステップS256において、時計172を用いて現在時刻を測定する。その後、ステップS257において、その現在時刻を実使用開始時刻として認識する。続いて、ステップS258において、ユーザが今回の貸席22の使用開始を許可する。
その後、ステップS259において、ユーザにつき、課金開始時刻が決定される。課金は、原則として、予定開始時刻から開始され、予定開始時刻からの経過時間(使用時間、貸与時間)の長さに見合う金額がレンタル金額として計算される。
これに対し、例外として、実使用開始時刻が予定使用開始時刻より早いが利用開始リクエストが前記第1制限時間内に正常に発令された場合には、その利用開始リクエストの発令時刻が課金開始時刻に決定される。
なお、実使用開始時刻が予定使用開始時刻より早いうえに利用開始リクエストが第1制限時間内に正常に発令されなかった場合には、今回の予約を強制的に取り消すことや、違反料金などのペナルティがユーザに課される。
その後、ステップS260において、ユーザにつき、前記個別に決定された課金開始時刻と、すべてのユーザに共通に告知される注意書きであって貸席22の使用中は携帯端末90によって常時発信機30を受信することを内容とするものとを反映するように、課金・使用条件に関する警告の内容が決定される。
続いて、ステップS261において、その課金・使用条件に関する警告が携帯端末90に送信され、ユーザに告知される。その後、自動的に前述の滞在判定シーケンスに移行する。
<滞在判定シーケンス>
図16には、ユーザが、予約してあった貸席22に使用を開始した後に、ユーザがその貸席22に実際に滞在しているか(着席しているか)滞在していないか(不存在であるか)を時々刻々、反復的に判定するために、その貸席22に位置する発信機30と、ユーザの携帯端末90と、管理サーバ50との間で行われる通信の一例が時系列的にシーケンス・フローで表されている。
発信機30は、自身に固有の識別信号を自発的にかつ継続的に発信する。ユーザが、予約してあった貸席22に着席しておりさえすれば、ユーザがわざわざ携帯端末90を発信機30にかざすことを必要とすることなく、携帯端末90が発信機30の有効受信エリア内に存在することになるため(図5参照)、携帯端末90が発信機30からの識別信号を有効に受信する。
続いて、ステップS181において、前記ステップS154と同様にして、携帯端末90がいずれかの発信機30から識別信号を有効に受信したか否かが判定される。
携帯端末90がいずれかの発信機30から識別信号を有効に受信したと判定された場合には、その後、ステップS182において、前記受信した識別信号が復調され、続いて、ステップS183において、その復調された識別信号によって表される発信機IDが実発信機IDとして解読される。
続いて、ステップS184において、そのようにして解読された実発信機IDと、前記ステップS153の実行によって取得された今回の1つの正規発信機IDとが互いに一致するか否かが判定される。すなわち、ID照合が行われるのである。
これに対し、実発信機IDと正規発信機IDとが互いに一致する場合、すなわち、前記ID照合に成功した場合には、ステップS185の判定がYESとなり、その後、ステップS186において、ユーザが実際に、現在、正規の貸席22に滞在している(存在している)と判定される。
これに対し、実発信機IDと正規発信機IDとが互いに一致しない場合、すなわち、前記ID照合に成功しなかった場合には、ステップS185の判定がNOとなり、その後、ステップS187において、ユーザが実際に、現在、正規の貸席22に不存在である(滞在していない)と判定される。この不存在判定が、ステップS186での、滞在しているとの判定の直後に行われた場合には、ユーザが貸席22から今まさに、退席したことが検知されたことになる。
いずれの場合にも、その後、ステップS188において、ユーザが実際に、予約してあった貸席22に滞在しているという判定の結果または不存在であるという判定の結果が、ユーザに関連付けて、管理サーバ50に送信される。続いて、ステップS181に戻る。
ステップS181−S188より成るステップ群は、当該席貸サービス・プログラムの実行中、反復的に実行される。
これに対し、管理サーバ50は、ステップS271において、携帯端末90から、ユーザが実際に、予約してあった貸席22に滞在しているという判定の結果または不存在であるという判定の結果を受信する。管理サーバ50は、その受信した判定結果をユーザに関連付けて滞在判定結果情報としてメモリ162に保存する。
<使用終了シーケンス>
図17には、ユーザが、予約してあった貸席22の使用終了を許可してもらうために、ユーザの携帯端末90と管理サーバ50との間で行われる通信の一例が時系列的にシーケンス・フローで表されている。
ユーザが貸席22から退席した可能性があることが携帯端末90によって判定されると、携帯端末90は、自動的に(手動でも可)、携帯端末90用の使用終了処理モジュールを起動させる。その起動により、まず、ステップ301において、携帯端末90が、ユーザが実際に、現在、予約された貸席22に滞在しているか否かの判定結果が、「滞在」から「不存在」に切り換わったか否かを判定する。
ここで、ステップS301の判定がYESとなるタイミングは、携帯端末90が正規発信機IDを受信する状態(すなわち、ユーザが貸席22に滞在している状態)から受信しない状態(すなわち、ユーザが貸席22に不存在である状態)に遷移するタイミング(図12の例における「立ち下がりエッジ」の時間的位置に一致する)に一致する。よって、ステップS301における判定は、厳密には、ユーザが貸席22から退席した直後であるか否かの判定である。
今回は、ステップS301の判定がYESであると仮定すると、ステップS302において、ユーザが貸席22から退席した直後である、すなわち、ユーザが貸席22の使用を終了したと判定される。
続いて、ステップS302において、ユーザから使用終了リクエストが発令された(例えば、前述の、使用終了リクエストのためのボタンがユーザによって選択された)か否かが判定される。発令された場合には、ステップS302の判定がYESとなり、その後、ステップS303において、ユーザから使用終了リクエストが発令されたことが管理サーバ50に送信される。
これに対し、ユーザから使用終了リクエストが発令されなかった場合には、ユーザが貸席22に滞在していると判定され、ステップS302の判定がNOとなり、その後、ステップS304において、現在、ステップS301のYES判定タイミングからの経過時間が第2制限時間(例えば、5分)内であるか否かが判定される。第2制限時間内である場合には、ステップS304の判定がYESとなり、ステップS305において、ユーザに対し、使用終了リクエストを入力することが、例えば画面135上に適切なメッセージが表示されるか音声で出力されることなどが行われることにより、催促される。続いて、ステップS302に戻る。
これに対し、現在、ステップS301のYES判定タイミングからの経過時間が第2制限時間を超えている場合には、ステップS304の判定がNOとなり、その後、ステップS306において、ユーザに第2違反行為が発生したと判定される。
続いて、ステップS307において、ユーザに第2違反行為が発生したことが管理サーバ50に送信される。
これに対し、管理サーバ50用の使用終了処理モジュールが管理サーバ50によって実行されると、管理サーバ50は、ステップS401において、前記ステップS303の実行によって携帯端末90が送信した情報と、前記ステップS307の実行によって携帯端末90が送信した情報とを受信する。
その後、ステップS402において、時計172を用いて現在時刻を測定する。続いて、ステップS403において、その現在時刻を実使用終了時刻として認識する。その後、ステップS404において、ユーザが今回の貸席22の使用終了を許可する。
その後、ステップS405において、ユーザにつき、前述のようにユーザごとに個別に決定された課金開始時刻から課金終了時刻までの時間が全レンタル時間として計算される。ここに、「課金終了時刻」は、通常であれば、予定終了時刻と一致するが、前記第2違反行為が携帯端末90から通知されている場合には、課金終了時刻が実使用終了時刻と一致するように決定されたうえに、予定使用終了時刻から実使用終了時刻までの延長レンタル時間については、通常レートより高額な料金レートを用いてレンタル金額が計算される。
続いて、ステップS406において、図示しない料金テーブルと、発生した違反行為の種別とに従い、前記計算された全レンタル時間の長さと、料金レート(増額率)とに基づいて今回のレンタル金額が計算される。前記料金レートは、後述の予約変更モジュールの実行の結果、割増レートに変更される場合がある。
その後、ステップS407において、前記予約状況テーブルから貸席22についての予約が削除されるように、その予約状況テーブルが更新される。続いて、ステップS408において、前記計算されたレンタル金額などの情報が携帯端末90に送信される。
これに対し、携帯端末90は、ステップS308において、管理サーバ50からレンタル金額などの情報を受信し、続いて、ステップS309において、そのレンタル金額を画面上に表示する。その後、ステップS310において、ユーザによる電子決済が行われる。
続いて、携帯端末90は、ステップS311において、管理サーバ50からのログアウトを要求するログアウト・リクエストを管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS409において、そのログアウト・リクエストを受信する。続いて、ステップS410において、そのログアウト・リクエストの受信が正常に完了したことを表す確認応答信号ACKが携帯端末90に送信される。
これに対し、携帯端末90は、ステップS312において、その確認応答信号ACKを管理サーバ50から受信する。
ところで、ユーザが貸席22の使用期間中、何らかの理由で中座し、その後、同じ貸席22に戻るというシナリオも想定される。このシナリオにおいても、携帯端末90が正規発信機IDを受信する状態から受信しない状態に遷移する(第2遷移が発生する)ため、図17のステップS301の判定がYESとなる。
携帯端末900が、このシナリオを、ユーザが貸席22から退席したというシナリオから区別することが必要である場合には、本実施形態を例えば次のように改良することが可能である。
すなわち、携帯端末90は、ユーザによる貸席22の使用開始後、第2遷移を検出すると、直ちにステップS302に移行して、ユーザに使用終了リクエストの入力を要求するのではなく、それに先立ち、ステップS301a(図示しない)において、ユーザに対し、その後に貸席22に戻る予定なのか退席する予定なのかを確認するための確認メッセージを携帯端末90の画面上に表示するか音声で出力する。
その後、ステップS301b(図示しない)において、ユーザが、前記確認メッセージに応答し、「戻る予定」である旨を携帯端末90に入力すると、ステップS301c(図示しない)において、携帯端末90は、その後に発生する第1遷移、すなわち、携帯端末90が正規発信機IDを受信しない状態から受信する状態に遷移することに備えて、携帯端末90が正規発信機IDを受信したか否かを反復的に判定する。
そのステップS301cにおいて、携帯端末90が正規発信機IDを受信したと判定されると、これは、新たな第1遷移が発生したことを意味するため、続いて、ステップS301に戻る。その結果、ステップS302に移行することが一時的に保留される。
これに対し、前記ステップS301bにおいて、ユーザが、前記確認メッセージに応答し、「退席する予定」である旨を携帯端末90に入力すると、ステップS302に移行する。
<予約変更シーケンス>
図18には、ユーザが、貸席22の使用の途中で、予約の内容を変更するために、ユーザの携帯端末90と管理サーバ50との間で行われる通信の一例が時系列的にシーケンス・フローで表されている。
今回は、携帯端末90の画面上において「予約変更」というボタンがユーザによって選択されると、携帯端末90用の予約変更モジュールが携帯端末90によって実行される。その実行により、まず、ステップ401において、携帯端末90が、前記滞在判定結果情報を管理サーバ50から受信し、さらに、その滞在判定結果情報に基づき、ユーザが実際に、現在、予約された貸席22に滞在しているか否かが判定される。
今回は、滞在中であると判定されると、ステップS401の判定がYESとなり、その後、ステップS402において、ユーザが携帯端末90に延長リクエストを入力したか否かが判定される。今回は、ユーザがその延長リクエストを入力した(例えば、前述の、延長リクエストのためのボタンをユーザが選択した)と判定されると、その後、ステップS403において、携帯端末90が、管理サーバ50から最新の予約状況テーブルを受信し、さらに、その予約状況テーブルが反映されるように、携帯端末90のメモリ132に保存されている予約状況テーブルを更新する。
続いて、携帯端末90は、ステップS404において、その更新された予約状況テーブルを画面上に表示する。その後、ステップS405において、ユーザが、別の予約とオーバーラップしないように、自身の予定終了時刻を遅らせるための入力を携帯端末90に対して行う。さらに、携帯端末90は、その予約変更内容を管理サーバ50に送信し、管理サーバ50は、その予約変更内容を反映するように前記予約状況テーブルを更新する。
その後、携帯端末90は、ステップS406において、今回の予約変更が前記予定使用終了時刻の経過前に行われたか否か、すなわち、本来の予約内容の時間的範囲内で行われたか否かを判定する。今回は、今回の予約変更が前記予定使用終了時刻の経過前に行われたと仮定すると、ステップS407において、課金レートが通常レートに設定され、これに対し、今回は、今回の予約変更が前記予定使用終了時刻の経過後に行われたと仮定すると、ステップS408において、課金レートが割増レートに設定される。
いずれの場合にも、その後、携帯端末90は、ステップS409において、上述のようにして設定された課金レートを管理サーバ50に送信する。
以上の説明から明らかなように、本実施形態においては、対を成す第1遷移および第2遷移(図12における1個の受信パルス信号のうちの立ち上がりエッジおよび立ち下がりエッジ)のうちの一方である第1遷移の出現と、ユーザによる使用開始リクエストの意思表示との組合せに応答し、ユーザによる使用開始が認識される。
さらに、本実施形態においては、対を成す第1遷移および第2遷移のうちの一方である第2遷移の出現と、ユーザによる使用終了リクエストの意思表示との組合せに応答し、ユーザによる使用終了が認識される。
ここに、「対を成す第1遷移および第2遷移」は、ユーザが発信機30に対して行う1つの動作の開始タイミングと終了タイミングとに発生する2つの事象の組合せを意味する。
ところで、本実施形態においては、ユーザXが貸席Pに着席すべきところ、不注意で別の貸席Qに着席してしまうというシナリオも想定される。このシナリオにおいては、ユーザXの携帯端末90が、それにもかかわらず、貸席Pに設置されている発信機30の正規発信機IDを受信する可能性がある。そうすると、携帯端末90および管理サーバ50はは、事実に反し、ユーザXが貸席Pに着席していると認識してしまう。
このような誤認識を回避することが必要である場合には、本実施形態を次の一例に改良することが可能である。
まず、概略的に説明するに、この改良例においては、本実施形態において採用されている第1の技術、すなわち、携帯端末90が同時に複数の発信機30を検知した場合に、携帯端末90が本来受信すべき唯一の発信機90の発信機IDが複数の発信機30からの受信に先立って既知である(対応する貸席22が予約される)ことを条件として、正規の発信機30以外の発信機30からの信号を受信してもそれをソフト的に除外するフィルタリング技術に、第2の技術、すなわち、携帯端末90が広域受信モードで同時に複数の発信機30を検知した場合に、受信モードを広域受信モードから狭域受信モードに自動的に切り換える技術を組み合わせたものに相当する。
次に、具体的に説明するに、この例においては、携帯端末90が、通常の有効受信エリア(図5において、大径の円であって破線で示すもの。前述の「第1の有効受信エリア」の一例)と、通常の有効受信エリアの有効受信半径より小さい有効受信半径を有する縮小有効受信エリア(図5において、小径の円であって破線で示すもの。前述の「第2の有効受信エリア」の一例)とに切換え可能に設計される。
すなわち、この例においては、有効受信半径が可変値であり、それが大きい値を取るときに広域受信モードまたはデフォーカス受信モードが実現され、一方、それが小さい値を取るときに狭域受信モードまたはフォーカス受信モードが実現されるようになっているのである。
さらに、図25に示すように、ステップS700において、携帯端末90は、通常の有効受信エリアの設定値(広域受信モードの有効受信半径)のもとに、1または複数の発信機30からの信号を有効に受信することを試行する。
次に、ステップS701において、携帯端末90は、広域受信モードで、正規発信機IDと一致する実発信機ID−P(貸席Pの発信機30の正規発信機ID)を有効に受信したか否か(携帯端末90が発信機ID−Pを中心とする通常の有効受信エリア内に存在しているか否か)を判定する。受信しなかったと判定すると、ステップS700に戻る。
携帯端末90は、広域受信モードで実発信機ID−Pを受信したと判定すると、ステップS702において、携帯端末90は、広域受信モードで別の実発信機ID−Q(貸席Qの発信機30の正規発信機ID)をも有効に受信しているか否か(携帯端末90が別の発信機ID−Qの前記有効受信エリア内にも存在しているか否か)を判定する。別の実発信機ID−Qは有効に受信しなかったと判定すると、後述のステップS710に移行する。
広域受信モードで別の実発信機ID−Qをも有効に受信していると判定された場合には、ステップS703において、携帯端末90は、その実発信機ID−Qを発信している発信機30との距離DQと、実発信機ID−Pを発信している発信機30との距離DPとを測定する。
さらに、ステップS704において、携帯端末90は、距離DQが距離DPより短いか否かを判定する。短いと判定した場合には、ユーザXが、誤った貸席Qに着席している可能性があると判定する。距離DQが距離DPより短くはないと判定すると、ステップS710に移行する。
距離DQが距離DPより短いと判定すると、ステップS705において、携帯端末90は、有効受信エリアを前記通常の有効受信エリアから前記縮小有効受信エリア(狭域受信モードの有効受信半径)に切り換える。さらに、ステップS706において、携帯端末90は、ユーザXに対し、今度は、携帯端末90を、自身が着席している貸席Qの発信機30に接触させるかまたはかざすことを要求するためのメッセージを画面上に表示するか音声で出力する。
その後、ステップS707において、携帯端末90は、今度は、狭域受信モードで、一または複数の発信機30を有効に受信することを試行する。
続いて、ステップS708において、携帯端末90は、狭域受信モードで、正規発信機IDと一致する実発信機ID−P(貸席Pの発信機30の正規発信機ID)を有効に受信したか否か(携帯端末90が発信機ID−Pを中心とする前記縮小有効受信エリア内に存在しているか否か)を判定する。
そうすると、前述のシナリオにおいては、携帯端末90が、貸席Qの発信機30の実発信機ID−Qを受信することになり、これは、本来の正規発信機ID−Pと一致しないから、ステップS708の判定がNOとなる。
この場合、ステップS709において、携帯端末90は、ユーザXに対し、現に着席している貸席22が間違っていないか否かを確認するためのメッセージを画面上に表示するか音声で出力する。その結果、ユーザは、貸席Qから貸席Pに移動することになる。
その後、ステップS707に戻り、携帯端末90が、狭域受信モードで、貸席Pの発信機30を受信する。そうすると、ステップS708の判定が、今回は、YESとなる。その後、ステップS710において、携帯端末90は、ユーザが正しい貸席Pに着席していると判定する。
図25に示すステップS700−710より成るステップ群は、図15におけるステップS154−S157より成るステップ群、および/または、図16におけるステップS181−S184より成るステップ群を置き換えることが可能である。
図25に示す技術は、後述の第2の実施形態に適用することが可能であり、このことを裏付けるために、図20には、各発信機30の有効受信エリアとして、大径の通常の有効受信エリア(広域受信モード)と、小径の縮小有効受信エリア(狭域受信モード)とが示されている。
以上の説明から明らかなように、本実施形態によれば、携帯端末90および/または管理サーバ50が、携帯端末90が一または複数の発信機30からの信号を受信の有無を時系列的に表す受信信号の時間的変化(例えば図12および図21参照)に基づき、ユーザの選択貸席22に対する着席・退席(接近・離間、到着・退去)の時間的変化(ユーザの静的姿勢ではなく動的姿勢、動きの変化、姿勢の変化など)を監視する。
よって、本実施形態によれば、ユーザが貸席22に実際に着席したタイミングおよび貸席22から実際に退席したタイミングを精度よく検知することが容易となる。
なお、本実施形態は、種々の変更を加えた状態で実施することが可能であり、例えば、携帯端末90によるデータ処理のうちの少なくとも一部と同じデータ処理を管理サーバ50によって実行するように改良したり、逆に、管理サーバ50によるデータ処理のうちの少なくとも一部と同じデータ処理を携帯端末90によって実行するように改良することが可能である。このことは、次の第2の実施形態についても該当する。
<第2の実施形態>
次に、図19−図24を参照することにより、本発明の例示的な第2の実施形態に従う無人の駐車場管理システム300(以下、単に「システム300」という)を説明する。ただし、第1実施形態に従う無人席貸システムと共通する部分については、同じ符号および名称を使用して引用することにより、重複した説明を省略し、異なる部分についてのみ詳細に説明する。
このシステム300は、複数の駐車場20(図19には、それら駐車場20のうちの代表的な3つの駐車場A,BおよびCのみが図示されている)を集中的に管理するためのシステムである。各駐車場20は、複数の車室22を有しており、各車室22は、1人のユーザの1台の車両(自動車、自転車、自動二輪車など)に一時的に貸与される個別空間であるレンタル・スペースである。
第1実施形態と対比して説明するに、複数の駐車場20は、第1実施形態における複数の席貸施設20に相当し、また、複数の車室22は、1つの席貸施設20における複数の貸席22に相当する。
本実施形態においても、1つの駐車場20内における複数の車室22は、概して、互いに詰めて配置されている。それら車室22は、例えば、携帯端末90のGPS機能(前述)では空間的に互いに識別(分解)できないほどに互いに接近している複数のレンタル対象の一例である。
これに対し、複数の駐車場20は、携帯端末90のGPS機能(後述)によって空間的に互いに識別(分解)できるほどに互いに離散している複数の施設の一例である。
このシステム300は、概略的には、ユーザによるレンタル対象の予約を条件に、個別の発信機を用いてレンタル対象の場所認証を行うレンタル対象管理システムの一例である。
このシステム300は、本実施形態に従う駐車場管理方法を実行するように構成されている。その駐車場管理方法は、ユーザに貸与可能な複数の駐車場を集中的に管理するレンタル・スペース管理方法の一例であり、そのレンタル・スペース管理方法は、ユーザに貸与可能な不動産である複数のレンタル対象を集中的に管理するレンタル対象管理方法の一例である。そのレンタル対象管理方法の別の例は、ユーザに貸与可能な動産である複数のレンタル対象(例えば、レンタカーや貸し自転車)を集中的に管理するレンタル対象管理方法である。
各駐車場20は、無人式である。さらに、設備の削減・簡素化のため、各駐車場20には、各車室22に対する不正な進入および退出を阻止する装置(例えば、車両の通過を選択的に阻止するゲート装置や、各駐車場20の表面から突出して車両の車輪が乗り越えることを選択的に阻止する昇降式・フラップ式の車両退出阻止装置)も、ユーザから提示される暗号(例えば、パスワードやバーコード情報)を読み取るための装置も、ユーザがレンタル料を支払うための精算機も、ユーザにチケットを発行するための発券機も設置されていない。
図19に例示するように、各駐車場20においては、各車室22ごとに発信機30が1台ずつ設置されている。
具体的に、設置位置を説明するに、各発信機30は、平面視においては、対応する車室22の領域内に配置されており、また、側面視においては、図示しないが、対応する車室22の表面(例えば、地面、舗装面など)と同じ高さ、それより高い高さ、または、それより低い高さに配置されている。
次に、設置方法を説明するに、各発信機30は、例えば、対応する車室22に設置されている輪止めの内部または外部に装着したり、対応する車室22に設置されているポール、柱など、垂直に延びる構造物に、前記表面から浮上した位置に装着したり、対応する車室22の表面下に埋設することが可能である。
本実施形態においては、図20に例示するように、まず、ユーザが、複数の駐車場20のうちのいずれかを選択し、さらに、その選択駐車場20における複数の車室22のうちのいずれかを選択して、その選択された車室22に自身の車両400(または402)を進入させる。この例においては、車両400が、ある車室22に前向きで駐車されており、一方、別の車両402が、隣の車室22に後向きで駐車されている。
ユーザが自身の車両400または402の車内に居る状態で、ユーザの携帯端末90が、選択車室22に設置されている発信機30(正規の発信機)を受信する可能性がある。さらに、隣の車室22に設置されている発信機30(非正規の発信機)を受信する可能性もある。
図20に例示するように、各発信機30の有効受信エリアが、対応する車室22に駐車する車両内に居るユーザの携帯端末90をカバーするように設定されている。その結果、ユーザは、自身の車両から降りて発信機30に接近することなく、その発信機30を受信できるため、特に天候が不良である場合に、ユーザにとり好都合である。
しかし、そうすると、不可避的に、同じ有効受信エリアが、隣の車室22に駐車する車両内に居るユーザの携帯端末90をも、不必要であるにもかかわらず、カバーしてしまう可能性がある。そのため、本実施形態においても、携帯端末90が正規発信機ID(正確には、正規発信機IDを表す識別信号)を受信したか否かを判定することにより、ユーザが選択車室22に滞在しているか否かを判定するようになっている。
ところで、第1実施形態においては、ユーザが貸席22を使用する1回の期間中、図12に示すように、携帯端末90が1個の受信パルス信号が受信し、その信号の立ち上がりエッジのタイミングが使用開始時刻として認識され、一方、その信号の立ち下がりエッジのタイミングが使用終了時刻として認識される。これは、ユーザが貸席22に着席してから退席するまで、実質的に同じ貸室22に滞在し続け、その間、携帯端末90が正規発信機IDを受信し続けるという通信環境にあることに起因する。
これに対し、本実施形態においては、入庫時と出庫時とには、ユーザが選択車室22に滞在するが、選択車室22に車両が駐車している期間のうちの実質的な全期間中は、ユーザが選択車室22に滞在していないのが通常である。そのため、第1実施形態とは異なる信号処理が必要である。
そこで、本実施形態においては、図21に概念的にタイムチャートで示すように、入庫段階において、携帯端末90が正規発信機ID(正確には、正規発信機IDを表す識別信号)を受信しない状態から受信する状態に遷移する第1遷移(入庫時の1個の受信パルス信号である入庫時パルス信号の立ち上がりエッジ)が発生し、間もなく、携帯端末90が正規発信機IDを受信する状態から受信しない状態に遷移する第2遷移(入庫時パルス信号の立ち下がりエッジ)が発生する。
そうすると、ユーザに対し、入庫の確認のために、入庫リクエスト(前述の「第1事象」の一例)を携帯端末90に対して意思表示することを要求する。実際にユーザから入庫リクエストが出されると、第1遷移のタイミング(または第2遷移のタイミング)が入庫時刻として認識される。
さらに、本実施形態においては、図21に概念的にタイムチャートで示すように、出庫段階において、第1遷移(出庫時の1個の受信パルス信号である出庫時パルス信号の立ち上がりエッジ)が発生し、間もなく、第2遷移(出庫時パルス信号の立ち下がりエッジ)が発生する。
そうすると、ユーザに対し、出庫の確認のために、出庫リクエスト(前述の「第2事象」の一例)を携帯端末90に対して意思表示することを要求する。実際にユーザから出庫リクエストが出されると、第2遷移のタイミング(または第1遷移のタイミング)が出庫時刻として認識される。
図22には、複数の駐車場20を管理するための駐車場管理プログラムのうち、ユーザがいずれかの駐車場20のいずれかの車室22を予約するために携帯端末90および管理サーバ50によって実行される予約シーケンスの一例がフローチャートで概念的に表されている。
まず、前記駐車場管理プログラムがユーザの携帯端末90によって起動されると、ステップS500において、ユーザは、予約モードを選択する。次に、管理サーバ50は、ステップS601において、複数の駐車場20のそれぞれの地図上位置を表す駐車場データ(図7に示す席貸施設データに相当する)と、複数の駐車場20のIDと、複数の車室22のIDと、複数の正規発信機IDとの対応関係を表す車室データ(図8に示す貸席データに相当する)と、予約状況テーブル(図11(a)に示す予約状況テーブルに相当する)とをメモリ162から読み出して携帯端末90に送信する。
続いて、携帯端末90は、ステップS501において、それらデータおよびテーブルを管理サーバ50から受信してメモリ132に保存する。続いて、ステップS502において、携帯端末90は、前記駐車場データと携帯端末90のGPS測位結果とに基づき、前記複数の駐車場20を、ユーザの現在位置の近傍に位置する少数の候補駐車場20に絞り込み、それら少数の候補駐車場20を画面上に表示する。
さらに、このステップS502においては、ユーザが、画面上に表示されている複数の候補駐車場20のうちのいずれかを今回の選択駐車場20として選択するための操作を携帯端末90に対して行う。それに応答し、携帯端末90は、前記予約状況テーブルを画面上に表示し、それにより、ユーザは、その選択駐車場20の複数の車室22の各々につき、空車状態にある時間帯を知ることが可能となる。
その後、ステップS503において、ユーザは、携帯端末90により、それら車室22のいずれかを選択し、続いて、ステップS504において、ユーザは、その選択車室22の予定使用時間帯を携帯端末90に入力する。
その後、携帯端末90が、ステップS505において、ユーザによって指定された予約内容(駐車場20、車室22および使用時間帯)を、ユーザを識別するための個人認証情報と共に管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS602において、ユーザに関連付けて前記予約内容を受信し、その予約内容が反映されるように、前記ユーザ別予約内容ファイルを更新する。
図23には、前記駐車場管理プログラムのうち、ユーザが選択車室22に入庫するために携帯端末90および管理サーバ50によって実行される入庫シーケンスの一例がフローチャートで概念的に表されている。
まず、前記駐車場管理プログラムがユーザの携帯端末90によって起動されると、ステップS520において、ユーザは、入庫モードを選択する。次に、携帯端末90は、ステップS521において、前記車室データに基づき、今回の選択車室22に対応する正規発信機IDを取得する。
続いて、携帯端末90は、ステップS522において、携帯端末90がいずれかの発信機30から識別信号を有効に受信したか否か(前記第1遷移が発生したか否か)を判定し、有効に受信した場合には、ステップS523において、その受信した識別信号によって表される実発信機IDと前記正規発信機IDとが互いに一致するか否かが判定される。
実発信機IDと正規発信機IDとが一致する場合には、ユーザが実際に、現在、選択車室22に滞在していると判定される。その後、携帯端末90は、ステップS524において、携帯端末90が正規発信機IDを受信することが終了すること、すなわち、前記入庫時パルス信号の立ち下がりエッジ(前記第2遷移)が出現することが待たれる。出現すると、ステップS525において、ユーザから携帯端末90に入庫リクエストが入力されることが待たれる。入力されると、携帯端末90が、ステップS526において、入庫リクエストをユーザに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS621において、前記入庫リクエストを受信し、その結果、ユーザによる選択車室22への入庫を許可する。続いて、ステップS622において、現在時刻を入庫時刻としてメモリ162に保存する。
図24には、前記駐車場管理プログラムのうち、ユーザが選択車室22から出庫するために携帯端末90および管理サーバ50によって実行される出庫シーケンスの一例がフローチャートで概念的に表されている。
まず、前記駐車場管理プログラムがユーザの携帯端末90によって起動されると、ステップS540において、ユーザは、出庫モードを選択する。次に、携帯端末90は、ステップS541において、前記車室データに基づき、今回の選択車室22に対応する正規発信機IDを取得する。
続いて、携帯端末90は、ステップS542において、携帯端末90がいずれかの発信機30から識別信号を有効に受信したか否か(前記第1遷移が発生したか否か)を判定し、有効に受信した場合には、ステップS543において、その受信した識別信号によって表される実発信機IDと前記正規発信機IDとが互いに一致するか否かが判定される。
実発信機IDと正規発信機IDとが一致する場合には、ユーザが実際に、現在、選択車室22に滞在していると判定される。その後、携帯端末90は、ステップS544において、携帯端末90が正規発信機IDを受信することが終了すること、すなわち、前記出庫時パルス信号の立ち下がりエッジ(前記第2遷移)が出現することが待たれる。出現すると、ステップS545において、ユーザから携帯端末90に出庫リクエストが入力されることが待たれる。入力されると、携帯端末90が、ステップS546において、出庫リクエストをユーザに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS641において、前記出庫リクエストを受信し、その結果、ユーザによる選択車室22からの出庫を許可する。続いて、ステップS642において、現在時刻を出庫時刻とする。その後、ステップS643において、前記入庫時刻からその出庫時刻までの経過時間として駐車時間を計算する。続いて、ステップS644において、その計算された駐車時間の長さに基づいて駐車料金を計算する。その計算された駐車料金は携帯端末90に送信される。
これに対して、携帯端末90は、ステップS547において、受信した駐車料金の額を画面上に表示し、その後、ユーザは、その駐車料金について電子決済を行う。
以上の説明から明らかなように、本実施形態においては、対を成す第1遷移および第2遷移(図21における1個の入庫時パルス信号のうちの立ち上がりエッジおよび立ち下がりエッジ)の双方の出現と、ユーザによる入庫リクエストの意思表示との組合せに応答し、ユーザによる入庫という動作が認識され、また、対を成す第1遷移および第2遷移(図21における1個の出庫時パルス信号のうちの立ち上がりエッジおよび立ち下がりエッジ)の双方の出現と、ユーザによる出庫リクエストの意思表示との組合せに応答し、ユーザによる出庫という動作が認識される。
これに対し、対を成す第1遷移および第2遷移(図21における1個の入庫時パルス信号のうちの立ち上がりエッジおよび立ち下がりエッジ)のうちの一方の出現と、ユーザによる入庫リクエストの意思表示との組合せに応答し、ユーザによる入庫という動作が認識され、また、対を成す第1遷移および第2遷移(図21における1個の出庫時パルス信号のうちの立ち上がりエッジおよび立ち下がりエッジ)のうちの一方の出現と、ユーザによる出庫リクエストの意思表示との組合せに応答し、ユーザによる出庫という動作が認識される態様で本発明を実施してもよい。
ところで、本実施形態によれば、ユーザの出庫段階においては、携帯端末90が正規発信機IDを受信しなくなるのを待って、出庫が完了したと判定される。一方、ユーザによる入庫操作も出庫操作も必ず、選択車室22に駐車している車両内で行うことを、契約上、ユーザに強制するか、または、ユーザが車内において携帯端末90で発信機30を受信しない限り、その受信をソフトウエア上で無効にするように携帯端末90を設計することが可能である。
そうすれば、ユーザと携帯端末90と車両とが、空間的に同じ位置を共有することになるため、ユーザが選択車室22に進入した行為を携帯端末90が検出することは、車両が選択車室22に入庫したことを携帯端末90が検出することと等価であり、同様に、ユーザが選択車室22から退出した行為を携帯端末90が検出することは、車両が選択車室22から出庫したことを携帯端末90が検出することと等価である。
なお付言するに、上述のいくつかの実施形態は、本発明を、不動産としての席貸施設および駐車場をレンタル対象とするレンタル・サービスに適用した場合のいくつかの具体例であるが、これに代えて、本発明は、例えば、別の不動産、例えば、貸し倉庫、貸し部屋などをレンタル対象とするレンタル・サービスに適用したり、動産、例えば、車両(自動車、自転車、自動二輪車など)などをレンタル対象とするレンタル・サービスに適用することが可能である。さらに、本発明は、レンタル・サービス以外の用途に適用することも可能である。
以上、本発明のいくつかの実施形態を図面に基づいて詳細に説明したが、これらは例示であり、前記[発明の概要]の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。