(57)【要約】【課題】より利便性の高い駐車システムを提供する。【解決手段】管理サーバ１（駐車管理装置）は、施設３（駐車施設）に設けられた複数の各車庫の属性及び利用の状況を示す車庫情報を記憶し、ユーザ端末２によって送信される、車庫の属性を示す属性情報を受信する。管理サーバ１は、この属性情報と車庫の利用の状況に基づいて、ユーザが所望しかつ利用可能である車庫を検索し、この車庫を予約したことを示す予約情報を記憶する。【選択図】        図１
2005043958.tif 000002
【特許請求の範囲】
【請求項１】
駐車施設に設けられた複数の各車庫の属性及び利用の状況を示す車庫情報を記憶する記憶手段と、
ユーザが利用するユーザ端末によって送信される、車庫の属性を示す属性情報を受信する受信手段と、
前記記憶手段に記憶された車庫情報の中から、受信した属性情報が示す属性に合致し且つ前記利用の状況に基づいて利用可能と判断される車庫の車庫情報を検索する検索手段と、
前記検索手段により検索された前記車庫情報に対応付けて、車庫を予約したことを示す予約情報を記憶する予約手段とを備える駐車管理装置。
【請求項２】
前記検索手段が検索した車庫情報によって示される車庫の一覧を示す情報を前記ユーザ端末に送信する一覧送信手段と、
前記ユーザ端末によって送信されてくる車庫を指定する情報を受信する指定車庫受信手段とを備え、
前記予約手段は、前記指定車庫受信手段が受信した情報によって指定される車庫の車庫情報に対応付けて前記予約情報を記憶する請求項１記載の駐車管理装置。
【請求項３】
前記予約手段によって予約された車庫が設けられた駐車施設に対し、当該車庫が予約された旨を通知する予約通知手段を備える請求項１記載の駐車管理装置。
【請求項４】
前記受信手段は前記属性と共に駐車時間に関する時間情報を前記ユーザ端末から受信し、
前記検索手段は前記記憶手段に記憶された車庫情報が示す利用の状況と、前記受信手段によって受信された時間情報とに基づいて利用可能な車庫を判断する請求項１記載の駐車管理装置。
【請求項５】
前記予約手段によって予約された車庫の利用料金を決済するための決済情報を決済機関へ通知する通知手段を備える請求項１記載の駐車管理装置。
【請求項６】
前記予約手段によって予約された車庫の駐車施設における場所を示す情報を前記ユーザ端末へ送信する誘導手段を備える請求項１記載の駐車管理装置。
【請求項７】
通信装置から抽出条件を受信する条件受信手段と、
前記予約手段が前記予約情報に対応付けて記憶している車庫情報の中から、前記条件受信手段が受信した抽出条件に合致する車庫情報を抽出する抽出手段と、
抽出した車庫情報を前記通信装置に送信する送信手段とを備える請求項１記載の駐車管理装置。
【請求項８】
コンピュータに、
ユーザが利用するユーザ端末によって送信されてくる車庫の属性を示す属性情報を受信する受信機能と、
駐車施設に設けられた複数の各車庫の属性及び利用の状況を示す車庫情報を記憶する記憶手段を参照し、記憶されている前記車庫情報の中から、前記受信機能により受信された属性情報が示す属性に合致し且つ前記利用の状況に基づいて利用可能と判断される車庫の車庫情報を検索する検索機能と、
前記検索機能により検索された前記車庫情報に対応付けて、車庫を予約したことを示す予約情報を記憶手段に記憶させる予約機能とを実現させるためのプログラム。
【請求項９】
ユーザが利用するユーザ端末と、当該ユーザ端末と通信可能な駐車管理装置とを備え、
前記ユーザ端末は、
前記ユーザが車庫の属性を示す属性情報を入力するための入力手段と、
入力された前記属性情報を前記駐車管理装置に送信する送信手段とを備え、
前記駐車管理装置は、
前記ユーザ端末によって送信される前記属性情報を受信する受信手段と、
駐車施設に設けられた複数の各車庫の属性及び利用の状況を示す車庫情報を記憶する記憶手段と、
前記記憶手段に記憶された前記車庫情報の中から、受信した属性情報が示す属性に合致し且つ前記利用の状況に基づいて利用可能と判断される車庫の車庫情報を検索する検索手段と、
前記検索手段により検索された前記車庫情報に対応付けて、前記車庫を予約したことを示す予約情報を記憶する予約手段とを備える駐車管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、駐車場を予約するための方法に関する。
【０００２】
【従来の技術】
車両で外出をする場合、駐車場の確保が問題となることが多い。例えば、繁華街などの地域では、まず空いている駐車場を探すこと自体が困難であり、長時間並んで空車待ちをすることもしばしばである。また、仮に空きのある駐車場を見つけたとしても、駐車場が広い場合にはどこに空きスペースがあるのかがわからないことも多い。さらに、見知らぬ土地においては、そもそもどこに駐車場があるのかすらわからない。結果的に、車両を駐車するまでには多くの無駄な時間が費やされてしまうこととなる。そして、そのようなことがしばしば起こる大型店舗や大型娯楽施設には、「駐車するまでに時間がかかる」とか「駐車スペースが見つからない」といった理由により来場者の足が遠のくことにもなりかねず、このような施設を運営する側にとっては大きな機会損失となっている。
【０００３】
このような問題を解決するために、種々の技術が提案されている。例えば、特許文献１には、集中管理センターにおいて駐車場への車両の出入りをカウントし、駐車したい車両に対して無線により空いている駐車場の情報を送信する駐車場管理システムが開示されている。また、特許文献２には、駐車スペースに設けられたセンサにより車両の有無を判断し、空車情報を車両に提供するとともに、駐車場内の表示装置によって空きスペースへ車両を誘導する駐車管理システムが開示されている。
【０００４】
【特許文献１】
特開平８−１２４０８４号公報
【特許文献２】
特開平９−２４５２９６号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、これらの従来技術には以下に示されるような問題が考えられる。
まず、特許文献１に記載の技術においては、空き状況の検索が駐車場単位で行われるため、１台毎の空きスペースの詳細まで知ることはできない。このため、例えば小型車両用の駐車スペースしか空いてないのに大型車両の駐車予約がなされてしまうというように、車庫と車両のミスマッチの問題が起こり得る。また、特許文献２に記載の技術においては、駐車管理システムから運転手に対して一方的に空車情報が提供されるのみであり、車両の運転手から駐車に関するリクエストを出すことができないため、あまり有用ではない。なぜなら、例えば駐車しやすい駐車スペースをあらかじめ予約しておきたいとか、料金の安い駐車場を利用したい、といったような、個々の運転手のニーズに対してきめ細やかに応えることができないからである。
【０００６】
本発明はこのような背景の下になされたものであり、より利便性の高い駐車システムを提供することを目的としている。
【０００７】
【課題を解決するための手段】
上記課題を解決するために、本発明は、駐車施設に設けられた複数の各車庫の属性及び利用の状況を示す車庫情報を記憶する記憶手段と、ユーザが利用するユーザ端末によって送信されてくる、車庫の属性を示す属性情報を受信する受信手段と、前記記憶手段に記憶された車庫情報の中から、受信した属性情報が示す属性に合致し且つ前記利用の状況に基づいて利用可能と判断される車庫の車庫情報を検索する検索手段と、前記検索手段により検索された前記車庫情報に対応付けて、車庫を予約したことを示す予約情報を記憶する予約手段とを備える駐車管理装置を提供する。
この態様によれば、ユーザは自己の所望する属性を有した車庫を検索し、予約することが可能となる。
【０００８】
また、本発明の好ましい態様において、駐車管理装置は、前記検索手段が検索した車庫情報によって示される車庫の一覧を示す情報を前記ユーザ端末に送信する一覧送信手段と、前記ユーザ端末によって送信されてくる車庫を指定する情報を受信する指定車庫受信手段とを備え、前記予約手段は、前記指定車庫受信手段が受信した車庫の車庫情報に対応付けて前記予約情報を記憶する。
この態様によれば、ユーザは指定した条件を満たす複数の車庫の一覧から、さらに好みに応じた車庫を選択し、予約することが可能となる。
【０００９】
また、本発明の好ましい態様において、駐車管理装置は、前記予約手段によって予約された車庫が設けられた駐車施設に対し、当該車庫が予約された旨を通知する予約通知手段を備える。
この態様によれば、駐車施設においても車庫の予約を把握することが可能となる。
【００１０】
また、本発明の好ましい態様において、駐車管理装置は、前記受信手段が前記属性と共に駐車時間に関する時間情報を前記ユーザ端末から受信し、前記検索手段が前記記憶手段に記憶された車庫情報が示す利用の状況と、前記受信手段によって受信された時間情報とに基づいて利用可能な車庫を判断する。
この態様によれば、駐車施設においてより効率的な車庫利用が可能となる。
【００１１】
また、本発明の好ましい態様において、駐車管理装置は、前記予約手段によって予約された車庫の利用料金を決済するための決済情報を決済機関へ通知する通知手段を備える。
この態様によれば、ユーザは予約とともに利用料金の決済を行うことが可能となる。
【００１２】
また、本発明の好ましい態様において、駐車管理装置は、前記予約手段によって予約された車庫の駐車施設における場所を示す情報を前記ユーザ端末へ送信する誘導手段を備える。
この態様によれば、ユーザはユーザ端末に示される駐車施設の場所を参照し、確実に目的の車庫へ到着することが可能となる。
【００１３】
また、本発明の好ましい態様において、駐車管理装置は、通信装置から抽出条件を受信する条件受信手段と、前記予約手段が前記予約情報に対応付けて記憶している車庫情報の中から、前記条件受信手段が受信した抽出条件に合致する車庫情報を抽出する抽出手段と、抽出した車庫情報を前記通信装置に送信する送信手段とを備える。
この態様によれば、駐車管理装置は駐車施設の効果的な運営を補助することが可能となる。
【００１４】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態について説明する。
なお、以下の説明において、「施設」とは各駐車施設を意味し、「車庫」とはその駐車施設に設けられた複数の駐車スペースを意味する。
【００１５】
（１）構成
図１は本実施形態に係る駐車システム１００の全体構成を示す図である。同図に示されるように、駐車システム１００は、通信ネットワーク１０と、この通信ネットワーク１０に接続された管理サーバ１とユーザ端末２ａ〜２ｃと施設３ａ〜３ｃとを有する。通信ネットワーク１０は、インターネット、公衆電話網、移動電話網、或いは無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの各種ネットワークによって構成されている。さらに、駐車システム１００は、決済機関や流通企業を全国レベルで接続するＣＡＦＩＳ（Ｃｒｅｄｉｔ  ａｎｄ  Ｆｉｎａｎｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｙｓｔｅｍ）網４と、このＣＡＦＩＳ網４に接続された決済機関のクレジットサーバ５とを備えている。管理サーバ１は、このＣＡＦＩＳ網４にも接続されている。
なお、この図１においては、説明の便宜のためユーザ端末および施設をそれぞれ３つずつしか図示していないが、実際にはこれらは多数存在する。ユーザ端末２ａ〜２ｃはいずれもほぼ同様の役割を担うから、以下では、これらを特に区別して説明する必要がある場合を除き、ユーザ端末２という用語で総称する。施設３ａ〜３ｃ，および後述する施設３ａ〜３ｃ内のコンピュータ３０ａ〜３０ｃについても、同様に施設３およびコンピュータ３０と総称する。
【００１６】
ユーザ端末２は、システム１００によって提供されるサービスの加入者であるユーザによって利用される通信端末である。ユーザ端末２には、例えば車両に搭載されたカーナビゲーションシステム（ユーザ端末２ａ）の他、携帯電話機（ユーザ端末２ｂ）やパーソナルコンピュータ（ユーザ端末２ｃ）等も含まれる。これらのユーザ端末２はいずれも、端末全体を制御する制御部と、ユーザが入力を行うための入力部と、各種表示を行う表示部と、通信ネットワーク１０を介して管理サーバ１と通信を行う通信部とを備えている。カーナビゲーションシステム２ａや、いくつかの携帯電話機２ｂおよびパーソナルコンピュータ２ｃは、ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）信号を受信して現在地の位置を算出する機能を有している。
【００１７】
施設３には、例えば立体型／平面型や有人型／無人型等の様々なタイプの駐車施設が含まれる。施設３には、管理サーバ１と通信ネットワーク１０を介して通信を行うコンピュータ３０ａ，３０ｂ，３０ｃが備わっている。施設３内の各々の車庫の近傍には、車両の有無を検出する図示せぬセンサが設置されており、これらのセンサは施設内のコンピュータ３０ａ〜３０ｃに接続されている。コンピュータ３０ａ〜３０ｃは、センサによって検出される車両の有無に基づいて施設３内の各車庫の利用状況を管理しており、この利用状況の変化を管理サーバ１に送信したり、或いは管理サーバ１によって通知されてくる予約情報に基づいて、自身が管理している車庫の利用状況を更新したりするようになっている。
各車庫の利用状況としては、「入庫状態」と「空き状態」と「予約状態」とがある。「入庫状態」とは車庫が駐車されている状態であり、「空き状態」とは車庫が駐車されておらず、かつ予約もされていない状態であり、「予約状態」とは車庫に駐車はされていないが、予約がされているため、予約したユーザ以外の入庫が禁止されている状態のことである。
【００１８】
管理サーバ１は、ユーザ端末２や施設３のコンピュータと通信を行いつつ、ユーザに対して駐車場の検索から予約、そして決済に至るまでの手続を支援する機能を備えている。以下では、この管理サーバ１の詳細について説明する。
【００１９】
図２は管理サーバ１の構成を示すブロック図である。管理サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１と、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）１２と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１３と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１４と、通信インターフェース１５とを備えたコンピュータである。ＨＤＤ１２には、ＣＰＵ１１が後述するような動作を行うための手順が記述されたサーバアプリケーションプログラムや、ユーザ端末２において表示するために用意された各種画面データやデータファイルが記憶されている。また、ＨＤＤ１２には、各車庫の属性と利用状況を管理するための管理データベースＤＢ１が記憶されている。
【００２０】
管理データベースＤＢ１には、各ユーザに関するユーザ情報が記述されたユーザ情報テーブルｔｂｌＵｓｅｒと、各施設３に関する施設情報が記述された施設情報テーブルｔｂｌＰａｒｋと、施設３における各々の車庫に関する車庫情報が記述された車庫情報テーブルｔｂｌＧａｒａｇｅと、車庫の予約に関する予約情報が記述された予約情報テーブルｔｂｌＢｏｏｋとが格納されている。
図３にこれらの各テーブルの相関関係を示す。同図において、異なるテーブルの項目間を結ぶ実線は、それらの項目によりテーブルどうしが関連付けられていることを示す。例えば、予約情報テーブルｔｂｌＢｏｏｋとユーザ情報テーブルｔｂｌＵｓｅｒとは、「ユーザＩＤ」によって関連づけられているので、同一の「ユーザＩＤ」に基づいて予約情報テーブルｔｂｌＢｏｏｋから予約に関する情報を検索し、ユーザ情報テーブルｔｂｌＵｓｅｒからユーザに関する情報を検索することができる。以下、各テーブルについて、情報の内容を例示しながら説明する。
【００２１】
図４にユーザ情報テーブルｔｂｌＵｓｅｒの一例を示す。
ｕＩＤ（ユーザＩＤ）には各ユーザを一意に定めるために付与されたＩＤが記述されており、ｕＮａｍｅ（ユーザ名）には各ユーザの名称が記述されている。ｕＡｄｄｒ（ユーザ連絡先）は各ユーザに情報を通知する場合に利用される連絡先（例えばユーザのメールアドレスや電話番号）が記述されている。ｕＩｎｆｏ（ユーザクレジットカード情報）には各ユーザが決済に用いるクレジットカードのカード番号や有効期限等が記述されている。
これらのユーザ情報は、サービス開始に先立ってユーザから管理サーバ１の運営者に通知されることによって、このユーザ情報テーブルｔｂｌＵｓｅｒに記述される。図４に示す例では、例えば「鈴木太郎」というユーザに付与されたＩＤは、「０００１」であり、そのユーザのメールアドレスは「ｔａｒｏ＠ａｂｃ．ｎｅ．ｊｐ」であり、クレジットカード情報は「ＸＸＸＸ」であることを意味している。
【００２２】
図５に施設情報テーブルｔｂｌＰａｒｋを示す。
ｐＩＤ（施設ＩＤ）には各施設３を一意に定めるために付与されたＩＤが記述されており、ｐＮａｍｅ（施設名）には各施設３の名称が記述されている。ｐＰｓｔｎ（施設位置情報）には各施設３の位置を示す緯度および経度が記述されている。ｐＡｄｄｒ（施設住所）には各施設３の住所が記述されており、都道府県や市区町村等の単位で識別可能なように区切り文字が挿入されている。ｐＭａｐ（施設地図データ）には施設３およびその近辺を示した地図データファイルのファイルパスが記述されており、この地図データファイルは管理サーバ１内部のＨＤＤ１２に記憶されている。ｐＬｏｕｔ（施設レイアウトデータ）には当該施設３内部の車庫のレイアウト、および出入口や非常口の位置を示したレイアウトデータファイルのファイルパスが記述されている。このレイアウトデータファイルは管理サーバ１内部のＨＤＤ１２に記憶されている。図５に示す例では、例えば「Ａパーク」という施設に付与されたＩＤは、「０１」であり、その住所は「長野県諏訪市大和３丁目３番５号」であり、その位置は「北緯１３８．０７°／東経３６．０３°」であり、その地図データファイルとレイアウトデータファイルはそれぞれＨＤＤ１２内部の「Ｃ：￥ｍａｐ￥０１．．．」および「Ｃ：￥ｐａｒｋ￥０１．．．」という領域に記憶されていることを意味している。
これらの施設情報は、サービス開始に先立って施設の運営者から管理サーバ１の運営者に通知されることによって、この施設情報テーブルｔｂｌＰａｒｋに記述される。
【００２３】
図６に車庫情報テーブルｔｂｌＧａｒａｇｅを示す。
ｇＩＤ（車庫ＩＤ）には各車庫を一意に定めるために付与されたＩＤが記述されており、各車庫はｐＩＤ（施設ＩＤ）に関連付けられることによりどの施設３に属しているかが特定される。ｇＳｉｔｅ（車庫場所データ）にはその車庫の当該施設３内の所在が、例えば施設３において各車庫に付されている番号等で記述されている。ｇＵｓｅｄ（車庫利用フラグ）は当該車庫が利用されているか否かを示す「０」または「１」の値を持ったフラグであり、値が「１」のとき当該車庫が「利用中」であることを示す。すなわち、「車庫利用フラグ」が「０」であれば当該車庫は「空き状態」または「予約状態」であり、「１」であれば当該車庫は「入庫状態」である。
続いて、車庫属性項目について説明する。車庫属性項目とは、ユーザが車庫を検索する際に用いられる属性を示す項目である。車庫属性項目は提供される検索インターフェースによって異なり、種々の項目が考えられるが、本実施例では以下の通りである。
ｇＦｅｅ（車庫駐車料金）には単位時間当たりの駐車料金が記述されている。ｇＳｉｚｅ（車庫サイズ）は当該車庫のサイズを示しており、「小型車」、「普通車」、「大型車」の３種のうちいずれかが記述されている。ｇＯｕｔ（屋外フラグ）は当該車庫が屋外または屋内のどちらにあるかを示す「０」または「１」の値を持ったフラグであり、値が「１」のとき「屋外」を示す。ｇＨｃａｐ（障害者対応フラグ）は当該車庫が障害者利用に対応しているかどうかを示す「０」または「１」の値を持ったフラグであり、値が「１」のとき障害者利用に対応していることを示す。図６に示す例では、例えば車庫ＩＤが「０１−００１」である車庫は施設ＩＤが「０１」である「Ａパーク」内にある車庫であり、その車庫は「ＸＸＸ」で示される場所にあり、現在は「入庫状態」であることを意味している。
これらの情報は、サービス開始に先立って施設の運営者から管理サーバ１の運営者に通知されることによって、この車庫情報テーブルｔｂｌＧａｒａｇｅに記述され、「車庫利用フラグ」は、車庫の利用状況に応じて更新される。
【００２４】
図７に予約情報テーブルｔｂｌＢｏｏｋを示す。
ｂＩＤ（予約ＩＤ）にはそれぞれの予約情報を一意に定めるために付与されたＩＤが記述されており、それぞれの予約情報はｕＩＤ（ユーザＩＤ）とｇＩＤ（車庫ＩＤ）とに関連付けられることによって「どのユーザ」の「どの車庫」に対する予約であるかが特定される。ｂＳｄａｔ（予約開始日時）とｂＥｄａｔ（予約終了日時）には、それぞれ予約の開始日時および終了日時が記述されている。
これらの予約情報は、ユーザにより予約がなされる毎に予約情報テーブルｔｂｌＢｏｏｋに記述される。図７に示す例では、例えば予約ＩＤ「００００１」が付与された予約情報は、ユーザＩＤ「０００２」である「佐藤花子」によって車庫ＩＤ「０２−００３」である「Ｂ駐車場」内の車庫になされた予約であり、その予約日時は「２００３年７月１日１０時００分」から「２００３年７月１日１５時００分」であることを意味している。
【００２５】
（２）動作
上記構成からなる駐車システム１００の動作について、動作例１から動作例３を例示して説明する。
まず、動作例１では、ユーザが運転中に最寄りの車庫を検索して予約する場合について説明する。この場合に、車庫には比較的短時間（ここでは一律２時間とする）のみ駐車可能であるとし、ユーザが利用するユーザ端末２は、前述のＧＰＳによる測位機能を備えているものとする。
次に、動作例２では、例えばユーザが車両で外出する予定日の前日などに目的地近辺の車庫を予め検索し、ユーザが所望する駐車時間で車庫を予約しておく場合について説明する。この場合、ユーザが利用するユーザ端末２は、必ずしもＧＰＳによる測位機能を備えている必要はない。
最後に、動作例３では、予約情報テーブルｔｂｌＢｏｏｋに記述された情報に基づいて、駐車に関するユーザのニーズを分析する場合について説明する。
【００２６】
（２−１）動作例１
図８は動作例１の処理を説明するためのシーケンス図である。以下、ユーザ端末２によって表示される画面を例示しつつ説明する。
まず、ユーザ端末２がユーザによる所定の動作に応じて管理サーバ１にデータを要求し、これを受信することにより本処理は開始される（ステップＳａ１）。
処理開始時には、通常のログイン処理（特に図示しない）を行うことによりユーザ認証が行われる。管理サーバ１は、前述したサーバアプリケーションプログラムを常時実行しており、ユーザ端末２からの要求に応じて、車庫を検索するための画面を示すデータをＨＤＤ１２から読み出してユーザ端末２に送信する（ステップＳａ２）。
【００２７】
ユーザ端末２は、上記データを受信すると、例えば図９に示すような検索画面を表示する。このような検索画面を用いて、ユーザは所望する車庫の属性を入力する。図中の検索項目のうち、「料金」の項目はテキストボックスとなっており、ユーザは所望の料金範囲を入力する。また、図中の検索項目のうち、「車庫属性１」、「車庫属性２」、および「障害者対応」の項目はラジオボタンとなっており、ユーザは表示された選択肢から所望のものを各項目につき１つだけ選択する。
ここでは、ユーザがこのような検索画面を参照しながらユーザ端末２を操作して、１５時３０分からの２時間、０〜１０００円、屋内、普通車、障害者対応なしという検索条件を入力したとする。
【００２８】
以上に示された各検索条件を入力したら、ユーザは図中の「検索」ボタンをクリックする。これに応じて、ユーザ端末２は上記検索条件を管理サーバ１へと送信する（ステップＳａ３）。このとき、ユーザ端末２は、ＧＰＳ測位機能により測位したユーザ端末２の位置情報を、上記検索条件とともに送信する。
【００２９】
管理サーバ１は上述の検索条件及び位置情報を受信すると、この条件に一致する車庫情報の抽出を行う（ステップＳａ４）。以下においては、管理サーバ１が受信したデータと比較対象となるテーブル項目とについて説明する。
まず、管理サーバ１は、ユーザ端末２の位置情報と、施設情報テーブルｔｂｌＰａｒｋの「位置情報」とを比較し、例えばユーザ端末２の位置から５００ｍ以内などの所定の範囲内にある施設３の施設情報レコードをすべて抽出する。これによって、ユーザの現在位置の近辺にある施設３が抽出されることとなる。続いて、管理サーバ１は、抽出された施設３の車庫情報レコードの「車庫利用フラグ」を参照し、この値が「０」の車庫情報レコード、すなわち「空き状態」か「予約状態」でない車庫情報レコードを抽出する。
次に、管理サーバ１は、上述のように抽出された車庫情報レコードに対して、「料金」と「駐車時間」の検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「駐車料金」を比較する。そして、管理サーバ１は、ユーザによって指定された範囲内の駐車料金（つまり２時間で１０００円以内）に該当する車庫の車庫情報レコードを全て抽出する。
さらに、管理サーバ１は、「車庫属性１」、「車庫属性２」、および「障害者対応」の各検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「車庫サイズ」、「屋外フラグ」、「障害者用フラグ」とをそれぞれ比較し、条件に適合した車庫情報レコードを全て抽出する。
管理サーバ１は、以上のようにして抽出した施設情報レコードと車庫情報レコードの中から、さらに全ての条件に適合する車庫情報レコードを抽出する。
最後に、管理サーバ１は、このようにして抽出した車庫情報レコードについて、ユーザによって指定された時間帯に他のユーザによって予約がなされているかどうかを判断する。具体的には、抽出された車庫情報レコードと同じ「車庫ＩＤ」を有する予約情報レコードを予約情報テーブルｔｂｌＢｏｏｋから抽出し、さらに、この予約情報レコードが「駐車時間」の検索条件で設定された駐車時間（つまり、１５時３０分から２時間）を予約時間に含まないレコードであるかどうかを判断する。この判断が肯定的であれば、この車庫情報レコードに該当する車庫は予約可能である。
【００３０】
このようにしてユーザが指定した条件に適合する車庫が抽出されると、管理サーバ１はユーザ端末２に対して抽出した車庫に関する情報を送信する（ステップＳａ５）。ユーザ端末２は、上記情報を受信すると、例えば図１０のような画面を表示する。同図に示されるように、抽出された車庫情報が、施設毎にまとめて一覧表示され、またユーザの位置からその施設までの所要時間をあわせて表示する。ユーザが図１０中の「詳細」ボタンをクリックすると、ユーザ端末２は、管理サーバ１に対してユーザによって選択された車庫の詳細情報を要求する（ステップＳａ６）。この要求には選択された車庫の「車庫ＩＤ」が含まれている。
【００３１】
ユーザ端末２より車庫の詳細情報が要求されると、管理サーバ１は受信した車庫ＩＤに基づいて当該車庫のレイアウトを示すレイアウトデータファイルをＨＤＤ１２より検索し（ステップＳａ７）、このデータをユーザ端末２へと送信する（ステップＳａ８）。
ユーザ端末２は上記データを受信すると、例えば図１１のような画面を表示する。ユーザ端末２においては、レイアウトデータファイルに示されているそれぞれの車庫のうち、場所データにより示される予約可能な車庫部分を他とは異なる態様（例えば着色、点滅など）にて表示するよう処理を行うことで、このような画面を表示する。
ユーザは、このように表示されたレイアウト情報を参照して、自身が駐車しやすい位置にあるとか、入口或いは出口に近いといった観点から所望の車庫を選択し、選択した車庫の位置をクリックする操作を行う。これに応じて、ユーザ端末２は、管理サーバ１に対してその車庫の予約を要求する（ステップＳａ９）。この要求には選択された車庫の「車庫ＩＤ」が含まれている。
【００３２】
ユーザ端末２より予約が要求されると、管理サーバ１は予約情報テーブルｔｂｌＢｏｏｋに新規レコードを作成する（ステップＳａ１０）。管理サーバ１はどのユーザのどの車庫に対する予約であるかを認識し、加えてユーザにより指定された予約開始日時と予約終了日時（本動作例では予約開始日時の２時間後に固定されている）とに基づいて、新規作成される予約情報レコードに「ユーザＩＤ」、「車庫ＩＤ」、「予約開始日時」、および「予約終了日時」を書き込む。
なお、この予約情報レコードの新規作成がなされると同時に、管理サーバ１は予約された車庫がある施設３のコンピュータ３０に対して、当該車庫を「予約状態」にする要求を送信する。これは、予約なしで来場したユーザに当該車庫が駐車されてしまうことを防ぐためである。
以上の処理によって、ユーザの予約は確定される。予約を確定した後、管理サーバ１は、次のようにして料金決済のための処理を行う。
【００３３】
決済処理においては、はじめに、管理サーバ１から送信されたデータに基づいて、ユーザ端末２はクレジットカード番号や有効期限、或いは駐車料金等の決済情報の確認画面を表示する（ステップＳａ１１）。料金の決済に必要なクレジットカード番号や有効期限等の決済情報は既にユーザ情報テーブルｔｂｌＵｓｅｒに記憶されており、駐車料金については予約情報レコードの「予約開始日時」、「予約終了日時」、および予約する車庫の「車庫駐車料金」より算出できる。管理サーバ１がこれらのデータを抽出してユーザ端末２へと送信するので、ここでは特にユーザによる入力を必要とせず、確認画面によってユーザが確認するだけで良い。しかし、既に登録されている情報をこの画面で適宜変更できるようにすることも、もちろん可能である。
【００３４】
確認画面を閲覧して決済情報を確認したら、ユーザはこの決済を確定させる。このユーザの確定指示を受けて、ユーザ端末２は管理サーバ１に対して決済処理を行うよう要求する（ステップＳａ１２）。管理サーバ１はこの要求を受信すると、ＣＡＦＩＳ網４を介して該当する決済機関のクレジットサーバ５へ決済情報を送信する。
【００３５】
決済処理が終了すると、管理サーバ１は次の誘導処理を開始する（ステップＳａ１３）。誘導処理とは、ユーザを現在地から予約した車庫へと誘導する処理のことである。このときユーザ端末２は、管理サーバ１から送信されたデータに基づいて、例えば図１２のような画面を表示する。同図に示されるように、この画面にはユーザ端末２の現在位置と、予約した車庫のある施設３とが表示されており、ユーザの移動に伴ってこの表示は適宜更新される。施設３の位置表示は施設情報レコードに記述された「施設位置情報」に基づいて行われる。この画面の表示内容にしたがって移動することにより、ユーザは目的地である施設３へと到着することができる。
目的地の施設３へと到着したら、今度は駐車すべき車庫へと誘導するために、ユーザ端末２は表示を切り替える。このときユーザ端末２は、例えば図１３のような画面を表示する。この画面は図１１と同様、当該施設３のレイアウトデータファイルに基づいて作成される。同図において、ユーザ端末２は、当該施設３内の車庫のうちユーザが予約した車庫部分を他とは異なる態様にて表示し、また、当該車庫部分への順路を矢印等で表示する。
以上に示した誘導処理を行うことにより、ユーザはより簡単、迅速、かつ確実に、予約した車庫に駐車することが可能となる。
【００３６】
また、ユーザが予約した駐車時間が経過し、予約終了の時刻が近づいてきたら、管理サーバ１は当該予約情報レコードの「ユーザＩＤ」をもとに当該ユーザの連絡先ｕＡｄｄｒを参照し、ここに記述されている連絡先へ電子メールや電話、或いはショートメッセージサービス等を利用して駐車時間の終了の旨をユーザへ通知することが可能である。
このように、ユーザに対して駐車時間の終了を予め通知することで、以下の効果が期待できる。まず、ユーザにおいては、ユーザの不注意により無用の駐車時間超過がなされることを未然に防ぎ、超過料金を徴収されるような事態も防ぐことができる。また、施設３を運営する側にとっても、駐車時間の超過を防ぐことで、同じ車庫に対して直後に別のユーザが予約をしているような場合でも、予約をしているのに駐車ができないというようなトラブルを防ぐことができ、より円滑な施設運営が可能となる。
【００３７】
以上説明された一連の処理を行うことによって、ユーザは確実に駐車スペースを確保することが可能となり、かつ、その駐車スペースへの移動に際しても、適切な誘導により迷うこともなく、無駄な時間を費やさずに迅速に移動することが可能となる。また、施設３を運営する側にとっても、各車庫を効率的に利用することが可能となり、さらには運営に要する誘導等の人員の削減も可能となるため、より高い利益を得ることが可能となる。
【００３８】
（２−２）動作例２
図１４は動作例２の処理を説明するためのシーケンス図である。以下、ユーザ端末２に表示される画面を例示しつつ説明する。
まず、ユーザ端末２がユーザによる所定の動作に応じて管理サーバ１にアクセスすることにより、本処理は開始される（ステップＳｂ１）。処理開始時には、通常のログイン処理（特に図示しない）を行うことによりユーザ認証が行われる。管理サーバ１は、前述したサーバアプリケーションプログラムを常時実行しており、このアクセスに応じて、車庫を検索するための画面を示すデータをＨＤＤ１２から読み出してユーザ端末２に送信する（ステップＳｂ２）。
【００３９】
ユーザ端末２は、上記データを受信すると、例えば図１５に示すような検索画面を表示する。このような検索画面を用いて、ユーザは所望する車庫の属性を入力する。図中の検索項目のうち、「駐車日時」および「料金」の項目はテキストボックスとなっており、ユーザは所望の駐車日時および料金範囲を入力する。また、「車庫属性１」、「車庫属性２」、および「障害者対応」の項目については、動作例１と同様であるため、説明は省略する。
【００４０】
「駐車場所」項目は複数のプルダウンメニューにより構成される。これらのプルダウンメニューのうち、ＰＤ１は都道府県を選択するプルダウンメニューである。ＰＤ２以降のプルダウンメニューの項目は可変となっており、直前のプルダウンメニューで選択された内容に応じてメニューが生成される。図１５を例に説明すると、ＰＤ１で「長野県」の項目を選択すると、ＰＤ２には長野県下の各市の項目が生成され、ＰＤ２で「諏訪市」の項目を選択すると、ＰＤ３には諏訪市下の各地名の項目が生成される。以下、同様にして、ＰＤ４，ＰＤ５，ＰＤ６にはそれぞれ選択された場所に存在する「丁目」、「番地」、「号」の項目がそれぞれ生成される。これらの項目は全て選択する必要はなく、例えば「長野県諏訪市」を選択したら、以降の項目は未選択のままとしても良い。
「駐車場所」項目をこのような構成とすることで、ユーザは柔軟性のある選択が可能となる。例えば、検索条件を「長野県諏訪市」とすれば長野県諏訪市全体から車庫を検索することができるし、より詳細に場所を特定したければ、検索条件を例えば「長野県諏訪市大和３丁目」とすれば良い。
ここでは、ユーザがこのような検索画面を参照しながらユーザ端末２を操作して、７月３日、長野県諏訪市、０〜１０００円、屋内、普通車、障害者対応なしという検索条件を入力したとする。
【００４１】
以上に示された各検索条件を入力したら、ユーザは図中の「検索」ボタンをクリックする。これに応じて、ユーザ端末２は上記検索条件を管理サーバ１へと送信する（ステップＳｂ３）。管理サーバ１は上述の検索条件を受信すると、この条件に一致する車庫情報の抽出を行う（ステップＳｂ４）。以下においては、管理サーバ１が受信したデータと比較対象となるテーブル項目とについて説明するが、動作例１と同様の部分については、適宜説明を省略する。
管理サーバ１は、「駐車場所」の検索条件と、施設情報テーブルｔｂｌＰａｒｋの「施設住所」とを比較し、検索条件に一致する施設３の施設情報レコードをすべて抽出する。既に述べたように、施設住所ｐＡｄｄｒに記述された住所は都道府県や市区町村の単位で区切り文字が挿入されているので、ユーザが「駐車場所」項目で選択した範囲に応じてレコード比較を行うことが可能である。
次に、管理サーバ１は、上述のように抽出された車庫情報レコードに対して、「料金」の検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「駐車料金」を比較する。そして、管理サーバ１は、ユーザによって指定された範囲内の駐車料金（つまり単位時間当たり１０００円以内）に該当する車庫の車庫情報レコードを全て抽出する。
さらに、管理サーバ１は、「車庫属性１」、「車庫属性２」、および「障害者対応」の各検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「車庫サイズ」、「屋外フラグ」、「障害者用フラグ」とをそれぞれ比較し、条件に適合した車庫情報レコードを全て抽出する。
管理サーバ１は、以上のようにして抽出した施設情報レコードと車庫情報レコードの中から、さらに全ての条件に適合する車庫情報レコードを抽出する。
最後に、管理サーバ１は、このようにして抽出した車庫情報レコードについて、ユーザによって指定された時間帯に他のユーザによって予約がなされているかどうかを判断する。具体的には、抽出された車庫情報レコードと同じ「車庫ＩＤ」を有する予約情報レコードを予約情報テーブルｔｂｌＢｏｏｋから抽出し、さらに、この予約情報レコードが「駐車日時」の検索条件で設定された駐車日時（７月３日）に予約可能なレコードであるかどうかを判断する。この判断が肯定的であれば、この車庫情報レコードに該当する車庫は、少なくともある時間帯は予約可能である。
【００４２】
このようにしてユーザが指定した条件に適合する車庫が抽出されると、管理サーバ１はユーザ端末２に対して抽出した車庫に関する情報を送信する（ステップＳｂ５）。ユーザ端末２は、上記情報を受信すると、動作例１と同様に例えば図１０のような画面を表示する。ユーザが図１０中の「詳細」ボタンをクリックすると、ユーザ端末２は、管理サーバ１に対してユーザによって選択された車庫の詳細情報を要求する（ステップＳｂ６）。この要求には選択された車庫の「車庫ＩＤ」が含まれている。
これに続くステップＳｂ７からステップＳｂ９については、動作例１のステップＳａ６からステップＳａ８と同様であるため、ここでの説明は省略し、ユーザ端末２から予約指示がなされたとして説明を続ける。
【００４３】
ユーザ端末２より予約が要求されると、管理サーバ１は予約情報テーブルｔｂｌＢｏｏｋにある予約情報レコードのうち、当該車庫に関するレコードを検索する（ステップＳｂ１０）。この検索で該当する予約情報レコードが検索されれば、当該車庫はそのレコードに指定された時間帯は予約することができないことを意味している。
【００４４】
このように予約情報レコードを検索したら、この結果に基づいて、管理サーバ１はユーザ端末２に対して当該車庫の予約状況に関する情報を送信する（ステップＳｂ１１）。ユーザ端末２は、上記情報を受信すると、例えば図１６のような画面を表示する。同図に示されるように、ユーザ端末２には予約する車庫についての予約状況が表示され、ユーザは図中の予約不可時間帯を避けて時間を選択し、予約指示を行う。ここでは、ユーザが１０時００分から１２時００分まで予約したとする。するとユーザ端末２は、管理サーバ１に対してその車庫の予約を要求する（ステップＳｂ１２）。
【００４５】
ユーザ端末２より予約が要求されると、管理サーバ１は予約情報テーブルｔｂｌＢｏｏｋに新規レコードを作成する（ステップＳｂ１３）。管理サーバ１はどのユーザのどの車庫に対する予約であるかを認識し、加えてユーザにより指定された予約開始日時（１０時００分）と予約終了日時（１２時００分）とに基づいて、新規作成される予約情報レコードに「ユーザＩＤ」、「車庫ＩＤ」、「予約開始日時」、および「予約終了日時」を書き込む。
以上の処理によって、ユーザの予約は確定される。予約を確定した後、管理サーバ１は料金決済のための処理を行う。本動作例の決済処理（ステップＳｂ１４，Ｓｂ１５）は、動作例１の決済処理（ステップＳａ１０，Ｓａ１１）と同様の処理であるため、ここではその説明を省略し、その後の誘導処理（ステップＳｂ１６）について説明する。
【００４６】
本動作例においては、予約は事前になされるものであるから、ユーザ端末２としては通常のデスクトップ型のコンピュータ等を含み得る構成となっている。そのため、動作例１において説明されたような、ＧＰＳによる測位機能を利用した誘導が行えない場合がある。ユーザ端末２がＧＰＳによる測位機能に対応し、かつ車両とともに移動可能であれば動作例１と同様の誘導処理を行えば良いが、ここではそれ以外の場合について説明する。
このような場合は、管理サーバ１はＨＤＤ１２内部に記憶された地図データファイルまたはレイアウトデータファイルをユーザ端末２に表示させる。これにより、例えばＧＰＳによる測位機能に対応していない携帯電話においては、表示された地図を参照しながら移動することで目的地へと向かえば良く、或いはデスクトップ型のコンピュータにおいては、表示された地図をプリンタ等で適宜出力し、これを持参して目的地へと向かえば良い。
【００４７】
また、本動作例においても、動作例１と同様に、予約終了時刻が近づいてきたら、ユーザの指定した連絡先へ駐車時間の終了の旨の警告を通知することが可能である。
以上のようにして、本動作例においても、動作例１とほぼ同様の効果が得られる。
【００４８】
（２−３）動作例３
上述の２つの動作例によって、「ユーザが確実に駐車スペースを確保し、無駄な時間を費やさずに迅速に目的地へと移動する」という本発明の主要な機能が説明されたが、この他にも本システムは、予約情報を蓄積して集計することで施設３のより効果的な運営を補助することが可能である。以下、この機能について説明する。
【００４９】
既に説明したが、本システムの管理データベースＤＢ１は図３に示されたようなテーブル構造を採っているため、予約情報テーブルｔｂｌＢｏｏｋの各レコードから顧客情報、施設情報、車庫情報の全てが抽出可能である。このため、例えば管理サーバ１に対して所望の抽出条件を指定し、その条件に合致する予約情報を出力させるようにすれば、車庫の稼働率に関する種々の情報を得ることができる。例えば、時間帯別、車庫サイズ別、料金別、或いは地域別等の様々な観点から予約情報を分類することが可能であり、これにより、どのような車庫に対してユーザのニーズが集中しているかということを分析することができる。例えば、単一の施設３の車庫に関してこれらの情報を分析した場合では、当該施設３がどの曜日・時間帯に混雑するか等のデータが得られる。これに基づいて施設の人員や商品の入荷等を調整することで、当該施設の効率的な経営を行うことができる。また、上述のようなデータを施設毎に集計し、分析した場合では、駐車料金による比較や、立地条件による比較も可能である。
【００５０】
これらの具体的な動作は、以下の通りである。
まず、コンピュータ３０は管理サーバ１に対して抽出条件を送信する。抽出条件の指定方法は、時間帯別、車庫サイズ別、或いは料金別等の方法があり、さらに車庫単位、施設単位、或いは地域単位等で絞り込みをすることも可能である。
このような抽出条件を受信したら、管理サーバ１はこれらの抽出条件に基づいて予約情報レコードの抽出を行う。例えば、車庫サイズ別の抽出が指定されていれば、管理サーバ１は車庫情報テーブルｔｂｌＧａｒａｇｅの「車庫サイズ」を参照して抽出し、地域単位での絞り込みが指定されていれば、施設情報テーブルｔｂｌＰａｒｋの「施設住所」を参照して抽出する。
このように予約情報を抽出したら、管理サーバ１はこの抽出結果をコンピュータ３０へと送信する。コンピュータ３０はこの抽出結果を受信し、これを円グラフや棒グラフ、或いは表などの様々な形式にて出力する。
【００５１】
（３）変形例
なお、本発明は上述した実施形態に限定されず、以下のような種々の変更が可能である。
【００５２】
（３−１）変形例１
上述の実施形態においては、本システムによる予約から誘導までの一連の処理を、その理解を容易ならしめるために２つの動作例で説明したが、本発明の実施は上述の２つの動作例に限られるものではない。例えば、それぞれ異なる態様である動作例１，２の動作を、同一施設３内で共に実施することも可能である。すなわち、ある車庫は駐車時間が一定の時間に固定されており、別の車庫は自由に駐車時間を設定できる、というような態様にて実施することももちろん可能である。
また、上述の実施形態においては、ユーザは本システム１００が提供するサービスに予め加入していることを前提としていたが、本発明はこのような態様に限定されず、例えばサービス未加入者の利用であれば、決済処理を行う時点でサービスへの加入処理を行い、ユーザ名やクレジットカード情報を入力させても良い。
【００５３】
（３−２）変形例２
上述の実施形態においては、予約の態様として（予約態様Ａ）ユーザ指定の開始時間から２時間（動作例１）、および（予約態様Ｂ）ユーザ指定の開始時間からユーザ指定の終了時間（動作例２）の２種類とした。しかしながら、車両の駐車においては、入庫した後特に出庫時間を定めないことも一般的であり、このような態様は出庫時間が不確定となるような場合には好適であると言える。
本システム１００は、このような予約態様にて実施することももちろん可能である。例えば、ユーザによる予約指定は開始日時のみとし、ユーザ端末２によりこの予約開始日時が送信されたら、管理サーバ１は自動的に予約終了日時を同日の２４時とする。そして、出庫時間を車庫のセンサにより検知し、駐車していた時間の料金を徴収し、この時点で決済処理を行えば良い（以下、これを予約態様Ｃとする）。
また、本システム１００が提供するサービスにおいて、上述の予約態様Ｃと動予約態様Ａ，Ｂのいずれの態様で予約するかを、ユーザが選択できるインターフェースを提供することにより、ユーザにとってより利便性の高い駐車システムとすることも可能である。
【００５４】
しかし、予約態様Ｃのような予約を可能にした場合、施設を運営する側としては、以下に示されるような不都合がある。それは、このように予約されることにより、当該車庫の車両の出庫時間が確定せず、たとえその車両が早く出庫するとしても、他の車両の予約を入れることができなくなってしまうという不都合である。
このような不都合を解消するには、ユーザに対して予約態様Ｃよりも予約態様Ａ，Ｂの利用を促進させるように工夫することが効果的である。具体的には予約態様Ａ，Ｂのような予約を行うユーザに対しては割引料金を適用することなどが考えられる。
本システム１００においてこのような割引を実現するには、以下のような変形を施せば良い。まず、予約情報テーブルｔｂｌＢｏｏｋの項目として予約態様を記述した項目を設け、ユーザにより選択された予約態様をテーブル内に記憶する。そして、決済処理を行う際にこの予約態様を記述した項目を参照し、予約態様ＡまたはＢであるユーザに対しては一定の割引を施した上で決済処理を行えば良い。
【００５５】
（３−３）変形例３
上述の実施形態においては、本システムは図１に示されるように、ひとつの管理サーバ１に複数の駐車施設３が接続されている構成とした。しかし本発明は、管理サーバ１を複数設け、各管理サーバ１に対してひとつの駐車施設３が接続されている構成とすることも可能であることは言うまでもない。
【００５６】
（３−４）変形例４
上述の実施形態において用いられた車庫属性項目はあくまでも一例であり、他にも種々の項目が考えられる。例えば、機械式か自走式か、縦列駐車か並列駐車か、買い物による割引の有無、屋根の有無等が挙げられる。
このような種々の車庫属性項目を設定し、検索インターフェースを提供することで、ユーザにおいてはより詳細に条件設定し、好みに応じた車庫を選択することが可能となる。
【００５７】
（３−５）変形例５
上述の実施形態においては、車庫の詳細情報を表示する態様は、図１１のようであるとしたが、他の表示態様も考えられる。例えば、車庫属性項目に設定されている車庫属性が画面上で容易に判別可能なように、アイコン表示や色分け表示がなされても良い。
【００５８】
（３−６）変形例６
上述の実施形態においては、決済処理は予約の確定直後に予約した時間分の料金を徴収する態様とした。しかし実際の利用においては、ユーザの予定変更により、結局予約した車庫を利用しなかったり、或いは予定していた時刻よりもかなり早い時間に出庫したりすることがあり得る。このような事態がたびたび起こると、ユーザにおいては、予約できるという利便性よりも支払った料金を無駄にしてしまったという不満のほうが強く印象に残りかねない。
このような不都合を解消するためには、予め徴収する料金は全体の一部とし、残金はユーザの車庫利用後に徴収するという方法を採れば良い。この場合、決済処理は最終的な利用時間が確定してから行われるほうが、よりスムースな処理を実現できる。
或いは、以下のような方法も用いることが可能である。例えば、センサにより入庫を監視し、一定の時間（例えば３０分）を経過しても予約したユーザによる入庫が確認されない場合には予約をキャンセルして料金の一部のみを徴収し、入庫が確認された場合には通常の料金を徴収するといった方法である。また、センサを用いれば出庫の確認もできるので、予約していた駐車時間よりも早く出庫した場合には、早く出庫した分だけ駐車料金から差し引くことも可能である。さらに、このような場合には、当該車庫情報レコードの「車庫利用フラグ」を書き換えることによって当該車庫を予約可能な状態とすることで、当該施設３を運営する側にとっては、車庫を時間的に無駄にせず、より効率的に利用することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るシステム構成図である。
【図２】同実施形態に係る管理サーバの機能を示すブロック図である。
【図３】同実施形態に係る管理データベースに格納されている各テーブルの相関関係を示す図である。
【図４】同実施形態におけるユーザ情報テーブルを示す図である。
【図５】同実施形態における施設情報テーブルを示す図である。
【図６】同実施形態における車庫情報テーブルを示す図である。
【図７】同実施形態における予約情報テーブルを示す図である。
【図８】同実施形態に係る動作例１の処理を説明するためのシーケンス図である。
【図９】動作例１においてユーザ端末に表示される検索画面のイメージ図である。
【図１０】動作例１においてユーザ端末に表示される検索結果表示画面のイメージ図である。
【図１１】動作例１においてユーザ端末に表示される車庫選択画面のイメージ図である。
【図１２】動作例１においてユーザ端末に表示される誘導画面のイメージ図である。
【図１３】動作例１においてユーザ端末に表示される誘導画面のイメージ図である。
【図１４】同実施形態に係る動作例２の処理を説明するためのシーケンス図である。
【図１５】動作例２においてユーザ端末に表示される検索画面のイメージ図である。
【図１６】動作例１においてユーザ端末に表示される予約時間指定画面のイメージ図である。
【符号の説明】
１…管理サーバ、２…ユーザ端末、３…施設、１１…ＣＰＵ、１２…ＨＤＤ、１３…ＲＯＭ、１４…ＲＡＭ、１５…通信インターフェース、３０…コンピュータ（通信装置）。
【図１】
2005043958.tif 000003
【図２】
2005043958.tif 000004
【図３】
2005043958.tif 000005
【図４】
2005043958.tif 000006
【図５】
2005043958.tif 000007
【図６】
2005043958.tif 000008
【図７】
2005043958.tif 000009
【図８】
2005043958.tif 000010
【図９】
2005043958.tif 000011
【図１０】
2005043958.tif 000012
【図１１】
2005043958.tif 000013
【図１２】
2005043958.tif 000014
【図１３】
2005043958.tif 000015
【図１４】
2005043958.tif 000016
【図１５】
2005043958.tif 000017
【図１６】
2005043958.tif 000018