JP2005043958A

JP2005043958A - Parking management device, parking management system and program

Info

Publication number: JP2005043958A
Application number: JP2003199928A
Authority: JP
Inventors: Sanae Tanaka; 早苗田中; Hideki Tanaka; 英樹田中
Original assignee: Seiko Epson Corp
Current assignee: Seiko Epson Corp
Priority date: 2003-07-22
Filing date: 2003-07-22
Publication date: 2005-02-17

Abstract

<P>PROBLEM TO BE SOLVED: To provide a much higher convenient parking system for allowing a user to retrieve a garage having attributes desired by the user himself or herself in order to reserve it. <P>SOLUTION: A management server 1(parking management device) stores garage information showing the attributes of respective garages installed in a facility 3(parking facility) and the conditions of the use of those garages, and receives the attribute information showing the attributes of the garages transmitted by a user terminal 2. The management server 1 retrieves the available garage desired by the user based on the conditions of the use of the garage shown by the attribute information, and stores reservation information showing that the garage has been reserved. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、駐車場を予約するための方法に関する。
【０００２】
【従来の技術】
車両で外出をする場合、駐車場の確保が問題となることが多い。例えば、繁華街などの地域では、まず空いている駐車場を探すこと自体が困難であり、長時間並んで空車待ちをすることもしばしばである。また、仮に空きのある駐車場を見つけたとしても、駐車場が広い場合にはどこに空きスペースがあるのかがわからないことも多い。さらに、見知らぬ土地においては、そもそもどこに駐車場があるのかすらわからない。結果的に、車両を駐車するまでには多くの無駄な時間が費やされてしまうこととなる。そして、そのようなことがしばしば起こる大型店舗や大型娯楽施設には、「駐車するまでに時間がかかる」とか「駐車スペースが見つからない」といった理由により来場者の足が遠のくことにもなりかねず、このような施設を運営する側にとっては大きな機会損失となっている。
【０００３】
このような問題を解決するために、種々の技術が提案されている。例えば、特許文献１には、集中管理センターにおいて駐車場への車両の出入りをカウントし、駐車したい車両に対して無線により空いている駐車場の情報を送信する駐車場管理システムが開示されている。また、特許文献２には、駐車スペースに設けられたセンサにより車両の有無を判断し、空車情報を車両に提供するとともに、駐車場内の表示装置によって空きスペースへ車両を誘導する駐車管理システムが開示されている。
【０００４】
【特許文献１】
特開平８−１２４０８４号公報
【特許文献２】
特開平９−２４５２９６号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、これらの従来技術には以下に示されるような問題が考えられる。
まず、特許文献１に記載の技術においては、空き状況の検索が駐車場単位で行われるため、１台毎の空きスペースの詳細まで知ることはできない。このため、例えば小型車両用の駐車スペースしか空いてないのに大型車両の駐車予約がなされてしまうというように、車庫と車両のミスマッチの問題が起こり得る。また、特許文献２に記載の技術においては、駐車管理システムから運転手に対して一方的に空車情報が提供されるのみであり、車両の運転手から駐車に関するリクエストを出すことができないため、あまり有用ではない。なぜなら、例えば駐車しやすい駐車スペースをあらかじめ予約しておきたいとか、料金の安い駐車場を利用したい、といったような、個々の運転手のニーズに対してきめ細やかに応えることができないからである。
【０００６】
本発明はこのような背景の下になされたものであり、より利便性の高い駐車システムを提供することを目的としている。
【０００７】
【課題を解決するための手段】
上記課題を解決するために、本発明は、駐車施設に設けられた複数の各車庫の属性及び利用の状況を示す車庫情報を記憶する記憶手段と、ユーザが利用するユーザ端末によって送信されてくる、車庫の属性を示す属性情報を受信する受信手段と、前記記憶手段に記憶された車庫情報の中から、受信した属性情報が示す属性に合致し且つ前記利用の状況に基づいて利用可能と判断される車庫の車庫情報を検索する検索手段と、前記検索手段により検索された前記車庫情報に対応付けて、車庫を予約したことを示す予約情報を記憶する予約手段とを備える駐車管理装置を提供する。
この態様によれば、ユーザは自己の所望する属性を有した車庫を検索し、予約することが可能となる。
【０００８】
また、本発明の好ましい態様において、駐車管理装置は、前記検索手段が検索した車庫情報によって示される車庫の一覧を示す情報を前記ユーザ端末に送信する一覧送信手段と、前記ユーザ端末によって送信されてくる車庫を指定する情報を受信する指定車庫受信手段とを備え、前記予約手段は、前記指定車庫受信手段が受信した車庫の車庫情報に対応付けて前記予約情報を記憶する。
この態様によれば、ユーザは指定した条件を満たす複数の車庫の一覧から、さらに好みに応じた車庫を選択し、予約することが可能となる。
【０００９】
また、本発明の好ましい態様において、駐車管理装置は、前記予約手段によって予約された車庫が設けられた駐車施設に対し、当該車庫が予約された旨を通知する予約通知手段を備える。
この態様によれば、駐車施設においても車庫の予約を把握することが可能となる。
【００１０】
また、本発明の好ましい態様において、駐車管理装置は、前記受信手段が前記属性と共に駐車時間に関する時間情報を前記ユーザ端末から受信し、前記検索手段が前記記憶手段に記憶された車庫情報が示す利用の状況と、前記受信手段によって受信された時間情報とに基づいて利用可能な車庫を判断する。
この態様によれば、駐車施設においてより効率的な車庫利用が可能となる。
【００１１】
また、本発明の好ましい態様において、駐車管理装置は、前記予約手段によって予約された車庫の利用料金を決済するための決済情報を決済機関へ通知する通知手段を備える。
この態様によれば、ユーザは予約とともに利用料金の決済を行うことが可能となる。
【００１２】
また、本発明の好ましい態様において、駐車管理装置は、前記予約手段によって予約された車庫の駐車施設における場所を示す情報を前記ユーザ端末へ送信する誘導手段を備える。
この態様によれば、ユーザはユーザ端末に示される駐車施設の場所を参照し、確実に目的の車庫へ到着することが可能となる。
【００１３】
また、本発明の好ましい態様において、駐車管理装置は、通信装置から抽出条件を受信する条件受信手段と、前記予約手段が前記予約情報に対応付けて記憶している車庫情報の中から、前記条件受信手段が受信した抽出条件に合致する車庫情報を抽出する抽出手段と、抽出した車庫情報を前記通信装置に送信する送信手段とを備える。
この態様によれば、駐車管理装置は駐車施設の効果的な運営を補助することが可能となる。
【００１４】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態について説明する。
なお、以下の説明において、「施設」とは各駐車施設を意味し、「車庫」とはその駐車施設に設けられた複数の駐車スペースを意味する。
【００１５】
（１）構成
図１は本実施形態に係る駐車システム１００の全体構成を示す図である。同図に示されるように、駐車システム１００は、通信ネットワーク１０と、この通信ネットワーク１０に接続された管理サーバ１とユーザ端末２ａ〜２ｃと施設３ａ〜３ｃとを有する。通信ネットワーク１０は、インターネット、公衆電話網、移動電話網、或いは無線ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）などの各種ネットワークによって構成されている。さらに、駐車システム１００は、決済機関や流通企業を全国レベルで接続するＣＡＦＩＳ（ＣｒｅｄｉｔａｎｄＦｉｎａｎｃｅＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍ）網４と、このＣＡＦＩＳ網４に接続された決済機関のクレジットサーバ５とを備えている。管理サーバ１は、このＣＡＦＩＳ網４にも接続されている。
なお、この図１においては、説明の便宜のためユーザ端末および施設をそれぞれ３つずつしか図示していないが、実際にはこれらは多数存在する。ユーザ端末２ａ〜２ｃはいずれもほぼ同様の役割を担うから、以下では、これらを特に区別して説明する必要がある場合を除き、ユーザ端末２という用語で総称する。施設３ａ〜３ｃ，および後述する施設３ａ〜３ｃ内のコンピュータ３０ａ〜３０ｃについても、同様に施設３およびコンピュータ３０と総称する。
【００１６】
ユーザ端末２は、システム１００によって提供されるサービスの加入者であるユーザによって利用される通信端末である。ユーザ端末２には、例えば車両に搭載されたカーナビゲーションシステム（ユーザ端末２ａ）の他、携帯電話機（ユーザ端末２ｂ）やパーソナルコンピュータ（ユーザ端末２ｃ）等も含まれる。これらのユーザ端末２はいずれも、端末全体を制御する制御部と、ユーザが入力を行うための入力部と、各種表示を行う表示部と、通信ネットワーク１０を介して管理サーバ１と通信を行う通信部とを備えている。カーナビゲーションシステム２ａや、いくつかの携帯電話機２ｂおよびパーソナルコンピュータ２ｃは、ＧＰＳ（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ）信号を受信して現在地の位置を算出する機能を有している。
【００１７】
施設３には、例えば立体型／平面型や有人型／無人型等の様々なタイプの駐車施設が含まれる。施設３には、管理サーバ１と通信ネットワーク１０を介して通信を行うコンピュータ３０ａ，３０ｂ，３０ｃが備わっている。施設３内の各々の車庫の近傍には、車両の有無を検出する図示せぬセンサが設置されており、これらのセンサは施設内のコンピュータ３０ａ〜３０ｃに接続されている。コンピュータ３０ａ〜３０ｃは、センサによって検出される車両の有無に基づいて施設３内の各車庫の利用状況を管理しており、この利用状況の変化を管理サーバ１に送信したり、或いは管理サーバ１によって通知されてくる予約情報に基づいて、自身が管理している車庫の利用状況を更新したりするようになっている。
各車庫の利用状況としては、「入庫状態」と「空き状態」と「予約状態」とがある。「入庫状態」とは車庫が駐車されている状態であり、「空き状態」とは車庫が駐車されておらず、かつ予約もされていない状態であり、「予約状態」とは車庫に駐車はされていないが、予約がされているため、予約したユーザ以外の入庫が禁止されている状態のことである。
【００１８】
管理サーバ１は、ユーザ端末２や施設３のコンピュータと通信を行いつつ、ユーザに対して駐車場の検索から予約、そして決済に至るまでの手続を支援する機能を備えている。以下では、この管理サーバ１の詳細について説明する。
【００１９】
図２は管理サーバ１の構成を示すブロック図である。管理サーバ１は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）１１と、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）１２と、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）１３と、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）１４と、通信インターフェース１５とを備えたコンピュータである。ＨＤＤ１２には、ＣＰＵ１１が後述するような動作を行うための手順が記述されたサーバアプリケーションプログラムや、ユーザ端末２において表示するために用意された各種画面データやデータファイルが記憶されている。また、ＨＤＤ１２には、各車庫の属性と利用状況を管理するための管理データベースＤＢ１が記憶されている。
【００２０】
管理データベースＤＢ１には、各ユーザに関するユーザ情報が記述されたユーザ情報テーブルｔｂｌＵｓｅｒと、各施設３に関する施設情報が記述された施設情報テーブルｔｂｌＰａｒｋと、施設３における各々の車庫に関する車庫情報が記述された車庫情報テーブルｔｂｌＧａｒａｇｅと、車庫の予約に関する予約情報が記述された予約情報テーブルｔｂｌＢｏｏｋとが格納されている。
図３にこれらの各テーブルの相関関係を示す。同図において、異なるテーブルの項目間を結ぶ実線は、それらの項目によりテーブルどうしが関連付けられていることを示す。例えば、予約情報テーブルｔｂｌＢｏｏｋとユーザ情報テーブルｔｂｌＵｓｅｒとは、「ユーザＩＤ」によって関連づけられているので、同一の「ユーザＩＤ」に基づいて予約情報テーブルｔｂｌＢｏｏｋから予約に関する情報を検索し、ユーザ情報テーブルｔｂｌＵｓｅｒからユーザに関する情報を検索することができる。以下、各テーブルについて、情報の内容を例示しながら説明する。
【００２１】
図４にユーザ情報テーブルｔｂｌＵｓｅｒの一例を示す。
ｕＩＤ（ユーザＩＤ）には各ユーザを一意に定めるために付与されたＩＤが記述されており、ｕＮａｍｅ（ユーザ名）には各ユーザの名称が記述されている。ｕＡｄｄｒ（ユーザ連絡先）は各ユーザに情報を通知する場合に利用される連絡先（例えばユーザのメールアドレスや電話番号）が記述されている。ｕＩｎｆｏ（ユーザクレジットカード情報）には各ユーザが決済に用いるクレジットカードのカード番号や有効期限等が記述されている。
これらのユーザ情報は、サービス開始に先立ってユーザから管理サーバ１の運営者に通知されることによって、このユーザ情報テーブルｔｂｌＵｓｅｒに記述される。図４に示す例では、例えば「鈴木太郎」というユーザに付与されたＩＤは、「０００１」であり、そのユーザのメールアドレスは「ｔａｒｏ＠ａｂｃ．ｎｅ．ｊｐ」であり、クレジットカード情報は「ＸＸＸＸ」であることを意味している。
【００２２】
図５に施設情報テーブルｔｂｌＰａｒｋを示す。
ｐＩＤ（施設ＩＤ）には各施設３を一意に定めるために付与されたＩＤが記述されており、ｐＮａｍｅ（施設名）には各施設３の名称が記述されている。ｐＰｓｔｎ（施設位置情報）には各施設３の位置を示す緯度および経度が記述されている。ｐＡｄｄｒ（施設住所）には各施設３の住所が記述されており、都道府県や市区町村等の単位で識別可能なように区切り文字が挿入されている。ｐＭａｐ（施設地図データ）には施設３およびその近辺を示した地図データファイルのファイルパスが記述されており、この地図データファイルは管理サーバ１内部のＨＤＤ１２に記憶されている。ｐＬｏｕｔ（施設レイアウトデータ）には当該施設３内部の車庫のレイアウト、および出入口や非常口の位置を示したレイアウトデータファイルのファイルパスが記述されている。このレイアウトデータファイルは管理サーバ１内部のＨＤＤ１２に記憶されている。図５に示す例では、例えば「Ａパーク」という施設に付与されたＩＤは、「０１」であり、その住所は「長野県諏訪市大和３丁目３番５号」であり、その位置は「北緯１３８．０７°／東経３６．０３°」であり、その地図データファイルとレイアウトデータファイルはそれぞれＨＤＤ１２内部の「Ｃ：￥ｍａｐ￥０１．．．」および「Ｃ：￥ｐａｒｋ￥０１．．．」という領域に記憶されていることを意味している。
これらの施設情報は、サービス開始に先立って施設の運営者から管理サーバ１の運営者に通知されることによって、この施設情報テーブルｔｂｌＰａｒｋに記述される。
【００２３】
図６に車庫情報テーブルｔｂｌＧａｒａｇｅを示す。
ｇＩＤ（車庫ＩＤ）には各車庫を一意に定めるために付与されたＩＤが記述されており、各車庫はｐＩＤ（施設ＩＤ）に関連付けられることによりどの施設３に属しているかが特定される。ｇＳｉｔｅ（車庫場所データ）にはその車庫の当該施設３内の所在が、例えば施設３において各車庫に付されている番号等で記述されている。ｇＵｓｅｄ（車庫利用フラグ）は当該車庫が利用されているか否かを示す「０」または「１」の値を持ったフラグであり、値が「１」のとき当該車庫が「利用中」であることを示す。すなわち、「車庫利用フラグ」が「０」であれば当該車庫は「空き状態」または「予約状態」であり、「１」であれば当該車庫は「入庫状態」である。
続いて、車庫属性項目について説明する。車庫属性項目とは、ユーザが車庫を検索する際に用いられる属性を示す項目である。車庫属性項目は提供される検索インターフェースによって異なり、種々の項目が考えられるが、本実施例では以下の通りである。
ｇＦｅｅ（車庫駐車料金）には単位時間当たりの駐車料金が記述されている。ｇＳｉｚｅ（車庫サイズ）は当該車庫のサイズを示しており、「小型車」、「普通車」、「大型車」の３種のうちいずれかが記述されている。ｇＯｕｔ（屋外フラグ）は当該車庫が屋外または屋内のどちらにあるかを示す「０」または「１」の値を持ったフラグであり、値が「１」のとき「屋外」を示す。ｇＨｃａｐ（障害者対応フラグ）は当該車庫が障害者利用に対応しているかどうかを示す「０」または「１」の値を持ったフラグであり、値が「１」のとき障害者利用に対応していることを示す。図６に示す例では、例えば車庫ＩＤが「０１−００１」である車庫は施設ＩＤが「０１」である「Ａパーク」内にある車庫であり、その車庫は「ＸＸＸ」で示される場所にあり、現在は「入庫状態」であることを意味している。
これらの情報は、サービス開始に先立って施設の運営者から管理サーバ１の運営者に通知されることによって、この車庫情報テーブルｔｂｌＧａｒａｇｅに記述され、「車庫利用フラグ」は、車庫の利用状況に応じて更新される。
【００２４】
図７に予約情報テーブルｔｂｌＢｏｏｋを示す。
ｂＩＤ（予約ＩＤ）にはそれぞれの予約情報を一意に定めるために付与されたＩＤが記述されており、それぞれの予約情報はｕＩＤ（ユーザＩＤ）とｇＩＤ（車庫ＩＤ）とに関連付けられることによって「どのユーザ」の「どの車庫」に対する予約であるかが特定される。ｂＳｄａｔ（予約開始日時）とｂＥｄａｔ（予約終了日時）には、それぞれ予約の開始日時および終了日時が記述されている。
これらの予約情報は、ユーザにより予約がなされる毎に予約情報テーブルｔｂｌＢｏｏｋに記述される。図７に示す例では、例えば予約ＩＤ「００００１」が付与された予約情報は、ユーザＩＤ「０００２」である「佐藤花子」によって車庫ＩＤ「０２−００３」である「Ｂ駐車場」内の車庫になされた予約であり、その予約日時は「２００３年７月１日１０時００分」から「２００３年７月１日１５時００分」であることを意味している。
【００２５】
（２）動作
上記構成からなる駐車システム１００の動作について、動作例１から動作例３を例示して説明する。
まず、動作例１では、ユーザが運転中に最寄りの車庫を検索して予約する場合について説明する。この場合に、車庫には比較的短時間（ここでは一律２時間とする）のみ駐車可能であるとし、ユーザが利用するユーザ端末２は、前述のＧＰＳによる測位機能を備えているものとする。
次に、動作例２では、例えばユーザが車両で外出する予定日の前日などに目的地近辺の車庫を予め検索し、ユーザが所望する駐車時間で車庫を予約しておく場合について説明する。この場合、ユーザが利用するユーザ端末２は、必ずしもＧＰＳによる測位機能を備えている必要はない。
最後に、動作例３では、予約情報テーブルｔｂｌＢｏｏｋに記述された情報に基づいて、駐車に関するユーザのニーズを分析する場合について説明する。
【００２６】
（２−１）動作例１
図８は動作例１の処理を説明するためのシーケンス図である。以下、ユーザ端末２によって表示される画面を例示しつつ説明する。
まず、ユーザ端末２がユーザによる所定の動作に応じて管理サーバ１にデータを要求し、これを受信することにより本処理は開始される（ステップＳａ１）。
処理開始時には、通常のログイン処理（特に図示しない）を行うことによりユーザ認証が行われる。管理サーバ１は、前述したサーバアプリケーションプログラムを常時実行しており、ユーザ端末２からの要求に応じて、車庫を検索するための画面を示すデータをＨＤＤ１２から読み出してユーザ端末２に送信する（ステップＳａ２）。
【００２７】
ユーザ端末２は、上記データを受信すると、例えば図９に示すような検索画面を表示する。このような検索画面を用いて、ユーザは所望する車庫の属性を入力する。図中の検索項目のうち、「料金」の項目はテキストボックスとなっており、ユーザは所望の料金範囲を入力する。また、図中の検索項目のうち、「車庫属性１」、「車庫属性２」、および「障害者対応」の項目はラジオボタンとなっており、ユーザは表示された選択肢から所望のものを各項目につき１つだけ選択する。
ここでは、ユーザがこのような検索画面を参照しながらユーザ端末２を操作して、１５時３０分からの２時間、０〜１０００円、屋内、普通車、障害者対応なしという検索条件を入力したとする。
【００２８】
以上に示された各検索条件を入力したら、ユーザは図中の「検索」ボタンをクリックする。これに応じて、ユーザ端末２は上記検索条件を管理サーバ１へと送信する（ステップＳａ３）。このとき、ユーザ端末２は、ＧＰＳ測位機能により測位したユーザ端末２の位置情報を、上記検索条件とともに送信する。
【００２９】
管理サーバ１は上述の検索条件及び位置情報を受信すると、この条件に一致する車庫情報の抽出を行う（ステップＳａ４）。以下においては、管理サーバ１が受信したデータと比較対象となるテーブル項目とについて説明する。
まず、管理サーバ１は、ユーザ端末２の位置情報と、施設情報テーブルｔｂｌＰａｒｋの「位置情報」とを比較し、例えばユーザ端末２の位置から５００ｍ以内などの所定の範囲内にある施設３の施設情報レコードをすべて抽出する。これによって、ユーザの現在位置の近辺にある施設３が抽出されることとなる。続いて、管理サーバ１は、抽出された施設３の車庫情報レコードの「車庫利用フラグ」を参照し、この値が「０」の車庫情報レコード、すなわち「空き状態」か「予約状態」でない車庫情報レコードを抽出する。
次に、管理サーバ１は、上述のように抽出された車庫情報レコードに対して、「料金」と「駐車時間」の検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「駐車料金」を比較する。そして、管理サーバ１は、ユーザによって指定された範囲内の駐車料金（つまり２時間で１０００円以内）に該当する車庫の車庫情報レコードを全て抽出する。
さらに、管理サーバ１は、「車庫属性１」、「車庫属性２」、および「障害者対応」の各検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「車庫サイズ」、「屋外フラグ」、「障害者用フラグ」とをそれぞれ比較し、条件に適合した車庫情報レコードを全て抽出する。
管理サーバ１は、以上のようにして抽出した施設情報レコードと車庫情報レコードの中から、さらに全ての条件に適合する車庫情報レコードを抽出する。
最後に、管理サーバ１は、このようにして抽出した車庫情報レコードについて、ユーザによって指定された時間帯に他のユーザによって予約がなされているかどうかを判断する。具体的には、抽出された車庫情報レコードと同じ「車庫ＩＤ」を有する予約情報レコードを予約情報テーブルｔｂｌＢｏｏｋから抽出し、さらに、この予約情報レコードが「駐車時間」の検索条件で設定された駐車時間（つまり、１５時３０分から２時間）を予約時間に含まないレコードであるかどうかを判断する。この判断が肯定的であれば、この車庫情報レコードに該当する車庫は予約可能である。
【００３０】
このようにしてユーザが指定した条件に適合する車庫が抽出されると、管理サーバ１はユーザ端末２に対して抽出した車庫に関する情報を送信する（ステップＳａ５）。ユーザ端末２は、上記情報を受信すると、例えば図１０のような画面を表示する。同図に示されるように、抽出された車庫情報が、施設毎にまとめて一覧表示され、またユーザの位置からその施設までの所要時間をあわせて表示する。ユーザが図１０中の「詳細」ボタンをクリックすると、ユーザ端末２は、管理サーバ１に対してユーザによって選択された車庫の詳細情報を要求する（ステップＳａ６）。この要求には選択された車庫の「車庫ＩＤ」が含まれている。
【００３１】
ユーザ端末２より車庫の詳細情報が要求されると、管理サーバ１は受信した車庫ＩＤに基づいて当該車庫のレイアウトを示すレイアウトデータファイルをＨＤＤ１２より検索し（ステップＳａ７）、このデータをユーザ端末２へと送信する（ステップＳａ８）。
ユーザ端末２は上記データを受信すると、例えば図１１のような画面を表示する。ユーザ端末２においては、レイアウトデータファイルに示されているそれぞれの車庫のうち、場所データにより示される予約可能な車庫部分を他とは異なる態様（例えば着色、点滅など）にて表示するよう処理を行うことで、このような画面を表示する。
ユーザは、このように表示されたレイアウト情報を参照して、自身が駐車しやすい位置にあるとか、入口或いは出口に近いといった観点から所望の車庫を選択し、選択した車庫の位置をクリックする操作を行う。これに応じて、ユーザ端末２は、管理サーバ１に対してその車庫の予約を要求する（ステップＳａ９）。この要求には選択された車庫の「車庫ＩＤ」が含まれている。
【００３２】
ユーザ端末２より予約が要求されると、管理サーバ１は予約情報テーブルｔｂｌＢｏｏｋに新規レコードを作成する（ステップＳａ１０）。管理サーバ１はどのユーザのどの車庫に対する予約であるかを認識し、加えてユーザにより指定された予約開始日時と予約終了日時（本動作例では予約開始日時の２時間後に固定されている）とに基づいて、新規作成される予約情報レコードに「ユーザＩＤ」、「車庫ＩＤ」、「予約開始日時」、および「予約終了日時」を書き込む。
なお、この予約情報レコードの新規作成がなされると同時に、管理サーバ１は予約された車庫がある施設３のコンピュータ３０に対して、当該車庫を「予約状態」にする要求を送信する。これは、予約なしで来場したユーザに当該車庫が駐車されてしまうことを防ぐためである。
以上の処理によって、ユーザの予約は確定される。予約を確定した後、管理サーバ１は、次のようにして料金決済のための処理を行う。
【００３３】
決済処理においては、はじめに、管理サーバ１から送信されたデータに基づいて、ユーザ端末２はクレジットカード番号や有効期限、或いは駐車料金等の決済情報の確認画面を表示する（ステップＳａ１１）。料金の決済に必要なクレジットカード番号や有効期限等の決済情報は既にユーザ情報テーブルｔｂｌＵｓｅｒに記憶されており、駐車料金については予約情報レコードの「予約開始日時」、「予約終了日時」、および予約する車庫の「車庫駐車料金」より算出できる。管理サーバ１がこれらのデータを抽出してユーザ端末２へと送信するので、ここでは特にユーザによる入力を必要とせず、確認画面によってユーザが確認するだけで良い。しかし、既に登録されている情報をこの画面で適宜変更できるようにすることも、もちろん可能である。
【００３４】
確認画面を閲覧して決済情報を確認したら、ユーザはこの決済を確定させる。このユーザの確定指示を受けて、ユーザ端末２は管理サーバ１に対して決済処理を行うよう要求する（ステップＳａ１２）。管理サーバ１はこの要求を受信すると、ＣＡＦＩＳ網４を介して該当する決済機関のクレジットサーバ５へ決済情報を送信する。
【００３５】
決済処理が終了すると、管理サーバ１は次の誘導処理を開始する（ステップＳａ１３）。誘導処理とは、ユーザを現在地から予約した車庫へと誘導する処理のことである。このときユーザ端末２は、管理サーバ１から送信されたデータに基づいて、例えば図１２のような画面を表示する。同図に示されるように、この画面にはユーザ端末２の現在位置と、予約した車庫のある施設３とが表示されており、ユーザの移動に伴ってこの表示は適宜更新される。施設３の位置表示は施設情報レコードに記述された「施設位置情報」に基づいて行われる。この画面の表示内容にしたがって移動することにより、ユーザは目的地である施設３へと到着することができる。
目的地の施設３へと到着したら、今度は駐車すべき車庫へと誘導するために、ユーザ端末２は表示を切り替える。このときユーザ端末２は、例えば図１３のような画面を表示する。この画面は図１１と同様、当該施設３のレイアウトデータファイルに基づいて作成される。同図において、ユーザ端末２は、当該施設３内の車庫のうちユーザが予約した車庫部分を他とは異なる態様にて表示し、また、当該車庫部分への順路を矢印等で表示する。
以上に示した誘導処理を行うことにより、ユーザはより簡単、迅速、かつ確実に、予約した車庫に駐車することが可能となる。
【００３６】
また、ユーザが予約した駐車時間が経過し、予約終了の時刻が近づいてきたら、管理サーバ１は当該予約情報レコードの「ユーザＩＤ」をもとに当該ユーザの連絡先ｕＡｄｄｒを参照し、ここに記述されている連絡先へ電子メールや電話、或いはショートメッセージサービス等を利用して駐車時間の終了の旨をユーザへ通知することが可能である。
このように、ユーザに対して駐車時間の終了を予め通知することで、以下の効果が期待できる。まず、ユーザにおいては、ユーザの不注意により無用の駐車時間超過がなされることを未然に防ぎ、超過料金を徴収されるような事態も防ぐことができる。また、施設３を運営する側にとっても、駐車時間の超過を防ぐことで、同じ車庫に対して直後に別のユーザが予約をしているような場合でも、予約をしているのに駐車ができないというようなトラブルを防ぐことができ、より円滑な施設運営が可能となる。
【００３７】
以上説明された一連の処理を行うことによって、ユーザは確実に駐車スペースを確保することが可能となり、かつ、その駐車スペースへの移動に際しても、適切な誘導により迷うこともなく、無駄な時間を費やさずに迅速に移動することが可能となる。また、施設３を運営する側にとっても、各車庫を効率的に利用することが可能となり、さらには運営に要する誘導等の人員の削減も可能となるため、より高い利益を得ることが可能となる。
【００３８】
（２−２）動作例２
図１４は動作例２の処理を説明するためのシーケンス図である。以下、ユーザ端末２に表示される画面を例示しつつ説明する。
まず、ユーザ端末２がユーザによる所定の動作に応じて管理サーバ１にアクセスすることにより、本処理は開始される（ステップＳｂ１）。処理開始時には、通常のログイン処理（特に図示しない）を行うことによりユーザ認証が行われる。管理サーバ１は、前述したサーバアプリケーションプログラムを常時実行しており、このアクセスに応じて、車庫を検索するための画面を示すデータをＨＤＤ１２から読み出してユーザ端末２に送信する（ステップＳｂ２）。
【００３９】
ユーザ端末２は、上記データを受信すると、例えば図１５に示すような検索画面を表示する。このような検索画面を用いて、ユーザは所望する車庫の属性を入力する。図中の検索項目のうち、「駐車日時」および「料金」の項目はテキストボックスとなっており、ユーザは所望の駐車日時および料金範囲を入力する。また、「車庫属性１」、「車庫属性２」、および「障害者対応」の項目については、動作例１と同様であるため、説明は省略する。
【００４０】
「駐車場所」項目は複数のプルダウンメニューにより構成される。これらのプルダウンメニューのうち、ＰＤ１は都道府県を選択するプルダウンメニューである。ＰＤ２以降のプルダウンメニューの項目は可変となっており、直前のプルダウンメニューで選択された内容に応じてメニューが生成される。図１５を例に説明すると、ＰＤ１で「長野県」の項目を選択すると、ＰＤ２には長野県下の各市の項目が生成され、ＰＤ２で「諏訪市」の項目を選択すると、ＰＤ３には諏訪市下の各地名の項目が生成される。以下、同様にして、ＰＤ４，ＰＤ５，ＰＤ６にはそれぞれ選択された場所に存在する「丁目」、「番地」、「号」の項目がそれぞれ生成される。これらの項目は全て選択する必要はなく、例えば「長野県諏訪市」を選択したら、以降の項目は未選択のままとしても良い。
「駐車場所」項目をこのような構成とすることで、ユーザは柔軟性のある選択が可能となる。例えば、検索条件を「長野県諏訪市」とすれば長野県諏訪市全体から車庫を検索することができるし、より詳細に場所を特定したければ、検索条件を例えば「長野県諏訪市大和３丁目」とすれば良い。
ここでは、ユーザがこのような検索画面を参照しながらユーザ端末２を操作して、７月３日、長野県諏訪市、０〜１０００円、屋内、普通車、障害者対応なしという検索条件を入力したとする。
【００４１】
以上に示された各検索条件を入力したら、ユーザは図中の「検索」ボタンをクリックする。これに応じて、ユーザ端末２は上記検索条件を管理サーバ１へと送信する（ステップＳｂ３）。管理サーバ１は上述の検索条件を受信すると、この条件に一致する車庫情報の抽出を行う（ステップＳｂ４）。以下においては、管理サーバ１が受信したデータと比較対象となるテーブル項目とについて説明するが、動作例１と同様の部分については、適宜説明を省略する。
管理サーバ１は、「駐車場所」の検索条件と、施設情報テーブルｔｂｌＰａｒｋの「施設住所」とを比較し、検索条件に一致する施設３の施設情報レコードをすべて抽出する。既に述べたように、施設住所ｐＡｄｄｒに記述された住所は都道府県や市区町村の単位で区切り文字が挿入されているので、ユーザが「駐車場所」項目で選択した範囲に応じてレコード比較を行うことが可能である。
次に、管理サーバ１は、上述のように抽出された車庫情報レコードに対して、「料金」の検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「駐車料金」を比較する。そして、管理サーバ１は、ユーザによって指定された範囲内の駐車料金（つまり単位時間当たり１０００円以内）に該当する車庫の車庫情報レコードを全て抽出する。
さらに、管理サーバ１は、「車庫属性１」、「車庫属性２」、および「障害者対応」の各検索条件と、車庫情報テーブルｔｂｌＧａｒａｇｅの「車庫サイズ」、「屋外フラグ」、「障害者用フラグ」とをそれぞれ比較し、条件に適合した車庫情報レコードを全て抽出する。
管理サーバ１は、以上のようにして抽出した施設情報レコードと車庫情報レコードの中から、さらに全ての条件に適合する車庫情報レコードを抽出する。
最後に、管理サーバ１は、このようにして抽出した車庫情報レコードについて、ユーザによって指定された時間帯に他のユーザによって予約がなされているかどうかを判断する。具体的には、抽出された車庫情報レコードと同じ「車庫ＩＤ」を有する予約情報レコードを予約情報テーブルｔｂｌＢｏｏｋから抽出し、さらに、この予約情報レコードが「駐車日時」の検索条件で設定された駐車日時（７月３日）に予約可能なレコードであるかどうかを判断する。この判断が肯定的であれば、この車庫情報レコードに該当する車庫は、少なくともある時間帯は予約可能である。
【００４２】
このようにしてユーザが指定した条件に適合する車庫が抽出されると、管理サーバ１はユーザ端末２に対して抽出した車庫に関する情報を送信する（ステップＳｂ５）。ユーザ端末２は、上記情報を受信すると、動作例１と同様に例えば図１０のような画面を表示する。ユーザが図１０中の「詳細」ボタンをクリックすると、ユーザ端末２は、管理サーバ１に対してユーザによって選択された車庫の詳細情報を要求する（ステップＳｂ６）。この要求には選択された車庫の「車庫ＩＤ」が含まれている。
これに続くステップＳｂ７からステップＳｂ９については、動作例１のステップＳａ６からステップＳａ８と同様であるため、ここでの説明は省略し、ユーザ端末２から予約指示がなされたとして説明を続ける。
【００４３】
ユーザ端末２より予約が要求されると、管理サーバ１は予約情報テーブルｔｂｌＢｏｏｋにある予約情報レコードのうち、当該車庫に関するレコードを検索する（ステップＳｂ１０）。この検索で該当する予約情報レコードが検索されれば、当該車庫はそのレコードに指定された時間帯は予約することができないことを意味している。
【００４４】
このように予約情報レコードを検索したら、この結果に基づいて、管理サーバ１はユーザ端末２に対して当該車庫の予約状況に関する情報を送信する（ステップＳｂ１１）。ユーザ端末２は、上記情報を受信すると、例えば図１６のような画面を表示する。同図に示されるように、ユーザ端末２には予約する車庫についての予約状況が表示され、ユーザは図中の予約不可時間帯を避けて時間を選択し、予約指示を行う。ここでは、ユーザが１０時００分から１２時００分まで予約したとする。するとユーザ端末２は、管理サーバ１に対してその車庫の予約を要求する（ステップＳｂ１２）。
【００４５】
ユーザ端末２より予約が要求されると、管理サーバ１は予約情報テーブルｔｂｌＢｏｏｋに新規レコードを作成する（ステップＳｂ１３）。管理サーバ１はどのユーザのどの車庫に対する予約であるかを認識し、加えてユーザにより指定された予約開始日時（１０時００分）と予約終了日時（１２時００分）とに基づいて、新規作成される予約情報レコードに「ユーザＩＤ」、「車庫ＩＤ」、「予約開始日時」、および「予約終了日時」を書き込む。
以上の処理によって、ユーザの予約は確定される。予約を確定した後、管理サーバ１は料金決済のための処理を行う。本動作例の決済処理（ステップＳｂ１４，Ｓｂ１５）は、動作例１の決済処理（ステップＳａ１０，Ｓａ１１）と同様の処理であるため、ここではその説明を省略し、その後の誘導処理（ステップＳｂ１６）について説明する。
【００４６】
本動作例においては、予約は事前になされるものであるから、ユーザ端末２としては通常のデスクトップ型のコンピュータ等を含み得る構成となっている。そのため、動作例１において説明されたような、ＧＰＳによる測位機能を利用した誘導が行えない場合がある。ユーザ端末２がＧＰＳによる測位機能に対応し、かつ車両とともに移動可能であれば動作例１と同様の誘導処理を行えば良いが、ここではそれ以外の場合について説明する。
このような場合は、管理サーバ１はＨＤＤ１２内部に記憶された地図データファイルまたはレイアウトデータファイルをユーザ端末２に表示させる。これにより、例えばＧＰＳによる測位機能に対応していない携帯電話においては、表示された地図を参照しながら移動することで目的地へと向かえば良く、或いはデスクトップ型のコンピュータにおいては、表示された地図をプリンタ等で適宜出力し、これを持参して目的地へと向かえば良い。
【００４７】
また、本動作例においても、動作例１と同様に、予約終了時刻が近づいてきたら、ユーザの指定した連絡先へ駐車時間の終了の旨の警告を通知することが可能である。
以上のようにして、本動作例においても、動作例１とほぼ同様の効果が得られる。
【００４８】
（２−３）動作例３
上述の２つの動作例によって、「ユーザが確実に駐車スペースを確保し、無駄な時間を費やさずに迅速に目的地へと移動する」という本発明の主要な機能が説明されたが、この他にも本システムは、予約情報を蓄積して集計することで施設３のより効果的な運営を補助することが可能である。以下、この機能について説明する。
【００４９】
既に説明したが、本システムの管理データベースＤＢ１は図３に示されたようなテーブル構造を採っているため、予約情報テーブルｔｂｌＢｏｏｋの各レコードから顧客情報、施設情報、車庫情報の全てが抽出可能である。このため、例えば管理サーバ１に対して所望の抽出条件を指定し、その条件に合致する予約情報を出力させるようにすれば、車庫の稼働率に関する種々の情報を得ることができる。例えば、時間帯別、車庫サイズ別、料金別、或いは地域別等の様々な観点から予約情報を分類することが可能であり、これにより、どのような車庫に対してユーザのニーズが集中しているかということを分析することができる。例えば、単一の施設３の車庫に関してこれらの情報を分析した場合では、当該施設３がどの曜日・時間帯に混雑するか等のデータが得られる。これに基づいて施設の人員や商品の入荷等を調整することで、当該施設の効率的な経営を行うことができる。また、上述のようなデータを施設毎に集計し、分析した場合では、駐車料金による比較や、立地条件による比較も可能である。
【００５０】
これらの具体的な動作は、以下の通りである。
まず、コンピュータ３０は管理サーバ１に対して抽出条件を送信する。抽出条件の指定方法は、時間帯別、車庫サイズ別、或いは料金別等の方法があり、さらに車庫単位、施設単位、或いは地域単位等で絞り込みをすることも可能である。
このような抽出条件を受信したら、管理サーバ１はこれらの抽出条件に基づいて予約情報レコードの抽出を行う。例えば、車庫サイズ別の抽出が指定されていれば、管理サーバ１は車庫情報テーブルｔｂｌＧａｒａｇｅの「車庫サイズ」を参照して抽出し、地域単位での絞り込みが指定されていれば、施設情報テーブルｔｂｌＰａｒｋの「施設住所」を参照して抽出する。
このように予約情報を抽出したら、管理サーバ１はこの抽出結果をコンピュータ３０へと送信する。コンピュータ３０はこの抽出結果を受信し、これを円グラフや棒グラフ、或いは表などの様々な形式にて出力する。
【００５１】
（３）変形例
なお、本発明は上述した実施形態に限定されず、以下のような種々の変更が可能である。
【００５２】
（３−１）変形例１
上述の実施形態においては、本システムによる予約から誘導までの一連の処理を、その理解を容易ならしめるために２つの動作例で説明したが、本発明の実施は上述の２つの動作例に限られるものではない。例えば、それぞれ異なる態様である動作例１，２の動作を、同一施設３内で共に実施することも可能である。すなわち、ある車庫は駐車時間が一定の時間に固定されており、別の車庫は自由に駐車時間を設定できる、というような態様にて実施することももちろん可能である。
また、上述の実施形態においては、ユーザは本システム１００が提供するサービスに予め加入していることを前提としていたが、本発明はこのような態様に限定されず、例えばサービス未加入者の利用であれば、決済処理を行う時点でサービスへの加入処理を行い、ユーザ名やクレジットカード情報を入力させても良い。
【００５３】
（３−２）変形例２
上述の実施形態においては、予約の態様として（予約態様Ａ）ユーザ指定の開始時間から２時間（動作例１）、および（予約態様Ｂ）ユーザ指定の開始時間からユーザ指定の終了時間（動作例２）の２種類とした。しかしながら、車両の駐車においては、入庫した後特に出庫時間を定めないことも一般的であり、このような態様は出庫時間が不確定となるような場合には好適であると言える。
本システム１００は、このような予約態様にて実施することももちろん可能である。例えば、ユーザによる予約指定は開始日時のみとし、ユーザ端末２によりこの予約開始日時が送信されたら、管理サーバ１は自動的に予約終了日時を同日の２４時とする。そして、出庫時間を車庫のセンサにより検知し、駐車していた時間の料金を徴収し、この時点で決済処理を行えば良い（以下、これを予約態様Ｃとする）。
また、本システム１００が提供するサービスにおいて、上述の予約態様Ｃと動予約態様Ａ，Ｂのいずれの態様で予約するかを、ユーザが選択できるインターフェースを提供することにより、ユーザにとってより利便性の高い駐車システムとすることも可能である。
【００５４】
しかし、予約態様Ｃのような予約を可能にした場合、施設を運営する側としては、以下に示されるような不都合がある。それは、このように予約されることにより、当該車庫の車両の出庫時間が確定せず、たとえその車両が早く出庫するとしても、他の車両の予約を入れることができなくなってしまうという不都合である。
このような不都合を解消するには、ユーザに対して予約態様Ｃよりも予約態様Ａ，Ｂの利用を促進させるように工夫することが効果的である。具体的には予約態様Ａ，Ｂのような予約を行うユーザに対しては割引料金を適用することなどが考えられる。
本システム１００においてこのような割引を実現するには、以下のような変形を施せば良い。まず、予約情報テーブルｔｂｌＢｏｏｋの項目として予約態様を記述した項目を設け、ユーザにより選択された予約態様をテーブル内に記憶する。そして、決済処理を行う際にこの予約態様を記述した項目を参照し、予約態様ＡまたはＢであるユーザに対しては一定の割引を施した上で決済処理を行えば良い。
【００５５】
（３−３）変形例３
上述の実施形態においては、本システムは図１に示されるように、ひとつの管理サーバ１に複数の駐車施設３が接続されている構成とした。しかし本発明は、管理サーバ１を複数設け、各管理サーバ１に対してひとつの駐車施設３が接続されている構成とすることも可能であることは言うまでもない。
【００５６】
（３−４）変形例４
上述の実施形態において用いられた車庫属性項目はあくまでも一例であり、他にも種々の項目が考えられる。例えば、機械式か自走式か、縦列駐車か並列駐車か、買い物による割引の有無、屋根の有無等が挙げられる。
このような種々の車庫属性項目を設定し、検索インターフェースを提供することで、ユーザにおいてはより詳細に条件設定し、好みに応じた車庫を選択することが可能となる。
【００５７】
（３−５）変形例５
上述の実施形態においては、車庫の詳細情報を表示する態様は、図１１のようであるとしたが、他の表示態様も考えられる。例えば、車庫属性項目に設定されている車庫属性が画面上で容易に判別可能なように、アイコン表示や色分け表示がなされても良い。
【００５８】
（３−６）変形例６
上述の実施形態においては、決済処理は予約の確定直後に予約した時間分の料金を徴収する態様とした。しかし実際の利用においては、ユーザの予定変更により、結局予約した車庫を利用しなかったり、或いは予定していた時刻よりもかなり早い時間に出庫したりすることがあり得る。このような事態がたびたび起こると、ユーザにおいては、予約できるという利便性よりも支払った料金を無駄にしてしまったという不満のほうが強く印象に残りかねない。
このような不都合を解消するためには、予め徴収する料金は全体の一部とし、残金はユーザの車庫利用後に徴収するという方法を採れば良い。この場合、決済処理は最終的な利用時間が確定してから行われるほうが、よりスムースな処理を実現できる。
或いは、以下のような方法も用いることが可能である。例えば、センサにより入庫を監視し、一定の時間（例えば３０分）を経過しても予約したユーザによる入庫が確認されない場合には予約をキャンセルして料金の一部のみを徴収し、入庫が確認された場合には通常の料金を徴収するといった方法である。また、センサを用いれば出庫の確認もできるので、予約していた駐車時間よりも早く出庫した場合には、早く出庫した分だけ駐車料金から差し引くことも可能である。さらに、このような場合には、当該車庫情報レコードの「車庫利用フラグ」を書き換えることによって当該車庫を予約可能な状態とすることで、当該施設３を運営する側にとっては、車庫を時間的に無駄にせず、より効率的に利用することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るシステム構成図である。
【図２】同実施形態に係る管理サーバの機能を示すブロック図である。
【図３】同実施形態に係る管理データベースに格納されている各テーブルの相関関係を示す図である。
【図４】同実施形態におけるユーザ情報テーブルを示す図である。
【図５】同実施形態における施設情報テーブルを示す図である。
【図６】同実施形態における車庫情報テーブルを示す図である。
【図７】同実施形態における予約情報テーブルを示す図である。
【図８】同実施形態に係る動作例１の処理を説明するためのシーケンス図である。
【図９】動作例１においてユーザ端末に表示される検索画面のイメージ図である。
【図１０】動作例１においてユーザ端末に表示される検索結果表示画面のイメージ図である。
【図１１】動作例１においてユーザ端末に表示される車庫選択画面のイメージ図である。
【図１２】動作例１においてユーザ端末に表示される誘導画面のイメージ図である。
【図１３】動作例１においてユーザ端末に表示される誘導画面のイメージ図である。
【図１４】同実施形態に係る動作例２の処理を説明するためのシーケンス図である。
【図１５】動作例２においてユーザ端末に表示される検索画面のイメージ図である。
【図１６】動作例１においてユーザ端末に表示される予約時間指定画面のイメージ図である。
【符号の説明】
１…管理サーバ、２…ユーザ端末、３…施設、１１…ＣＰＵ、１２…ＨＤＤ、１３…ＲＯＭ、１４…ＲＡＭ、１５…通信インターフェース、３０…コンピュータ（通信装置）。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a method for reserving a parking lot.
[0002]
[Prior art]
When going out by vehicle, securing a parking lot is often a problem. For example, in an area such as a downtown area, it is difficult to find a vacant parking lot, and it is often the case that waiting for an empty car is lined up for a long time. Even if an empty parking lot is found, if the parking lot is large, it is often difficult to know where the empty space is. In addition, in an unknown land, you can't even know where the parking lot is in the first place. As a result, a lot of wasted time is spent before the vehicle is parked. And in large stores and large entertainment facilities where such a thing often happens, it may also cause visitors to go away for reasons such as "it takes time to park" or "parking space is not found" For those who operate such facilities, there is a great opportunity loss.
[0003]
In order to solve such a problem, various techniques have been proposed. For example, Patent Literature 1 discloses a parking lot management system that counts vehicles entering and leaving a parking lot at a centralized management center and transmits information on a vacant parking lot to a vehicle to be parked wirelessly. . Patent Document 2 discloses a parking management system that determines the presence or absence of a vehicle by a sensor provided in the parking space, provides empty vehicle information to the vehicle, and guides the vehicle to the empty space by a display device in the parking lot. Has been.
[0004]
[Patent Document 1]
Japanese Patent Application Laid-Open No. H8-124084
[Patent Document 2]
Japanese Patent Laid-Open No. 9-245296
[0005]
[Problems to be solved by the invention]
However, these conventional techniques have the following problems.
First, in the technique described in Patent Document 1, since the search for the vacant state is performed in units of parking lots, it is impossible to know the details of each vacant space. For this reason, the problem of a mismatch between a garage and a vehicle may occur, for example, a parking reservation for a large vehicle is made even though only a parking space for a small vehicle is available. Further, in the technique described in Patent Document 2, since the parking management system only provides unilateral empty vehicle information to the driver, and the vehicle driver cannot issue a request regarding parking, Not useful. This is because, for example, it is not possible to respond precisely to the needs of individual drivers, such as pre-reserving a parking space that is easy to park or using a low-cost parking lot.
[0006]
The present invention has been made under such a background, and an object thereof is to provide a more convenient parking system.
[0007]
[Means for Solving the Problems]
In order to solve the above-described problems, the present invention is transmitted by storage means for storing garage information indicating the attributes and usage status of a plurality of garages provided in a parking facility, and a user terminal used by a user. And receiving means for receiving attribute information indicating the attribute of the garage, and judging from the garage information stored in the storage means that the attribute matches the attribute indicated by the received attribute information and can be used based on the use situation A parking management device comprising: search means for searching garage information of a garage to be stored; and reservation means for storing reservation information indicating that a garage has been reserved in association with the garage information searched by the search means To do.
According to this aspect, the user can search and reserve a garage having an attribute desired by the user.
[0008]
Also, in a preferred aspect of the present invention, the parking management device is transmitted by the user terminal and a list transmission unit that transmits information indicating a list of garages indicated by the garage information searched by the search unit to the user terminal. A designated garage receiving means for receiving information for designating the coming garage, and the reservation means stores the reservation information in association with the garage information of the garage received by the designated garage receiving means.
According to this aspect, the user can further select and reserve a garage according to his / her preference from a list of a plurality of garages that satisfy the specified condition.
[0009]
In a preferred aspect of the present invention, the parking management device includes reservation notification means for notifying that the garage is reserved to a parking facility provided with the garage reserved by the reservation means.
According to this aspect, it is possible to grasp the reservation of the garage even in the parking facility.
[0010]
Further, in a preferred aspect of the present invention, the parking management device uses the time indicated by the receiving means together with the attribute from the user terminal and the search means indicates the garage information stored in the storage means. The available garage is determined based on the situation and the time information received by the receiving means.
According to this aspect, the garage can be used more efficiently in the parking facility.
[0011]
Further, in a preferred aspect of the present invention, the parking management device includes a notification unit that notifies a settlement organization of settlement information for settlement of a garage usage fee reserved by the reservation unit.
According to this aspect, the user can settle the usage fee together with the reservation.
[0012]
Moreover, the preferable aspect of this invention WHEREIN: A parking management apparatus is provided with the guidance means which transmits the information which shows the location in the parking facility of the garage reserved by the said reservation means to the said user terminal.
According to this aspect, the user can reliably reach the target garage by referring to the location of the parking facility indicated on the user terminal.
[0013]
Further, in a preferred aspect of the present invention, the parking management device includes: a condition receiving unit that receives an extraction condition from a communication device; and the garage information that the reservation unit stores in association with the reservation information. Extraction means for extracting garage information that matches the extraction conditions received by the reception means, and transmission means for transmitting the extracted garage information to the communication device.
According to this aspect, the parking management device can assist the effective operation of the parking facility.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below with reference to the drawings.
In the following description, “facility” means each parking facility, and “garage” means a plurality of parking spaces provided in the parking facility.
[0015]
(1) Configuration
FIG. 1 is a diagram illustrating an overall configuration of a parking system 100 according to the present embodiment. As shown in the figure, the parking system 100 includes a communication network 10, a management server 1, user terminals 2a to 2c, and facilities 3a to 3c connected to the communication network 10. The communication network 10 includes various networks such as the Internet, a public telephone network, a mobile telephone network, or a wireless LAN (Local Area Network). Furthermore, the parking system 100 includes a CAFIS (Credit and Finance Information System) network 4 that connects payment institutions and distribution companies at the national level, and a credit server 5 of a payment agency connected to the CAFIS network 4. The management server 1 is also connected to the CAFIS network 4.
In FIG. 1, only three user terminals and three facilities are shown for convenience of explanation, but there are actually many such terminals. Since the user terminals 2a to 2c all play substantially the same role, hereinafter, the user terminals 2a to 2c are collectively referred to as the user terminal 2 unless it is necessary to particularly distinguish them. Similarly, the facilities 3a to 3c and the computers 30a to 30c in the facilities 3a to 3c described later are collectively referred to as the facility 3 and the computer 30.
[0016]
The user terminal 2 is a communication terminal used by a user who is a subscriber of a service provided by the system 100. The user terminal 2 includes, for example, a mobile phone (user terminal 2b), a personal computer (user terminal 2c) and the like in addition to a car navigation system (user terminal 2a) mounted on a vehicle. All of these user terminals 2 communicate with the management server 1 via the communication network 10, a control unit that controls the entire terminal, an input unit for a user to perform input, a display unit that performs various displays, and the like. And a communication unit. The car navigation system 2a, some mobile phones 2b, and personal computers 2c have a function of receiving a GPS (Global Positioning System) signal and calculating the position of the current location.
[0017]
The facility 3 includes various types of parking facilities such as a three-dimensional / planar type and a manned / unmanned type. The facility 3 includes computers 30 a, 30 b, and 30 c that communicate with the management server 1 via the communication network 10. Sensors (not shown) that detect the presence or absence of a vehicle are installed in the vicinity of each garage in the facility 3, and these sensors are connected to computers 30a to 30c in the facility. The computers 30a to 30c manage the usage status of each garage in the facility 3 based on the presence or absence of a vehicle detected by the sensor, and transmit the change in usage status to the management server 1 or the management server 1 The usage status of the garage managed by itself is updated based on the reservation information notified by.
The usage status of each garage includes “entry state”, “empty state”, and “reserved state”. “Receiving state” means that the garage is parked, “empty state” means that the garage is not parked and not reserved, and “reserved state” means parking in the garage. Although it has not been done, since reservations have been made, warehousing other than the reserved user is prohibited.
[0018]
The management server 1 has a function of supporting a procedure from a search for a parking lot to a reservation and a settlement to the user while communicating with the computer of the user terminal 2 and the facility 3. Below, the detail of this management server 1 is demonstrated.
[0019]
FIG. 2 is a block diagram showing the configuration of the management server 1. The management server 1 is a computer having a CPU (Central Processing Unit) 11, a HDD (Hard Disk Drive) 12, a ROM (Read Only Memory) 13, a RAM (Random Access Memory) 14, and a communication interface 15. is there. The HDD 12 stores a server application program in which a procedure for the CPU 11 to perform an operation described later is described, and various screen data and data files prepared for display on the user terminal 2. Further, the HDD 12 stores a management database DB1 for managing the attributes and usage status of each garage.
[0020]
In the management database DB1, a user information table tblUser describing user information related to each user, a facility information table tblPark describing facility information related to each facility 3, and garage information related to each garage in the facility 3 are described. A garage information table tblgarage and a reservation information table tblBook in which reservation information related to garage reservation is described are stored.
FIG. 3 shows the correlation between these tables. In the figure, solid lines connecting items in different tables indicate that the tables are associated with each other by those items. For example, since the reservation information table tblBook and the user information table tblUser are related by “user ID”, information related to the reservation is searched from the reservation information table tblBook based on the same “user ID”, and the user information table tblUser Information about the user can be retrieved. Hereinafter, each table will be described with reference to information contents.
[0021]
FIG. 4 shows an example of the user information table tblUser.
uID (user ID) describes an ID assigned to uniquely identify each user, and uName (user name) describes the name of each user. In uAddr (user contact information), a contact address (for example, a user's mail address or telephone number) used when notifying each user of information is described. uInfo (user credit card information) describes the card number and expiration date of the credit card used by each user for payment.
The user information is described in the user information table tblUser by notifying the operator of the management server 1 from the user prior to starting the service. In the example illustrated in FIG. 4, for example, the ID given to the user “Taro Suzuki” is “0001”, the mail address of the user is “taro@abc.ne.jp”, and the credit card information is “ "XXXX".
[0022]
FIG. 5 shows a facility information table tblPark.
An ID assigned to uniquely define each facility 3 is described in pID (facility ID), and the name of each facility 3 is described in pName (facility name). In pPstn (facility location information), the latitude and longitude indicating the location of each facility 3 are described. In pAddr (facility address), the address of each facility 3 is described, and a delimiter is inserted so as to be identifiable in units such as prefectures and municipalities. In pMap (facility map data), the file path of a map data file indicating the facility 3 and its vicinity is described, and this map data file is stored in the HDD 12 inside the management server 1. In pLout (facility layout data), the layout of the garage inside the facility 3 and the file path of the layout data file indicating the positions of the entrances and exits are described. This layout data file is stored in the HDD 12 inside the management server 1. In the example shown in FIG. 5, for example, the ID assigned to the facility “A Park” is “01”, the address is “3-5-5 Yamato, Suwa City, Nagano Prefecture”, and the position is “ North latitude is 138.007 ° / East longitude 36.03 °, and the map data file and layout data file are “C: ¥ map ¥ 01...” And “C: ¥ park ¥ 01. "Is stored in the area.
The facility information is described in the facility information table tblPark by being notified from the facility operator to the operator of the management server 1 before starting the service.
[0023]
FIG. 6 shows a garage information table tblgarage.
The ID assigned to uniquely identify each garage is described in gID (garage ID), and each garage is specified to which facility 3 by being associated with the pID (facility ID). In gSite (garage location data), the location of the garage in the facility 3 is described by, for example, a number assigned to each garage in the facility 3. gUsed (garage use flag) is a flag having a value of “0” or “1” indicating whether or not the garage is being used. When the value is “1”, the garage is “in use”. It shows that. That is, if the “garage use flag” is “0”, the garage is “empty” or “reserved”, and if “1”, the garage is “entry state”.
Next, the garage attribute item will be described. A garage attribute item is an item indicating an attribute used when a user searches a garage. The garage attribute item varies depending on the provided search interface, and various items can be considered. In this embodiment, the garage attribute item is as follows.
gFee (garage parking fee) describes a parking fee per unit time. gSize (garage size) indicates the size of the garage, and any one of three types of “small car”, “normal car”, and “large car” is described. gOut (outdoor flag) is a flag having a value of “0” or “1” indicating whether the garage is outdoors or indoors, and indicates “outdoor” when the value is “1”. gHcap (handicapped person handling flag) is a flag having a value of “0” or “1” indicating whether or not the garage supports the use of a handicapped person, and corresponds to the use of a handicapped person when the value is “1”. Indicates that In the example illustrated in FIG. 6, for example, a garage with a garage ID “01-001” is a garage in “A Park” with a facility ID “01”, and the garage is in a location indicated by “XXX”. Yes, it means that it is currently in the “warehousing state”.
The information is described in the garage information table tblgarage by notifying the operator of the management server 1 prior to the start of the service, and the “garage use flag” corresponds to the garage usage status. Updated.
[0024]
FIG. 7 shows the reservation information table tblBook.
In the bID (reservation ID), an ID assigned to uniquely determine each reservation information is described, and each reservation information is associated with a uID (user ID) and a gID (garage ID). It is specified which reservation is for “which garage” of which user. In bSdat (reservation start date and time) and bEdat (reservation end date and time), the start date and time and end date and time of the reservation are described, respectively.
The reservation information is described in the reservation information table tblBook every time a user makes a reservation. In the example shown in FIG. 7, for example, the reservation information given the reservation ID “00001” is the garage in the “B parking lot” with the garage ID “02-003” by “Hanako Sato” with the user ID “0002”. This means that the reservation date and time is “July 1, 2003 10:00” to “July 1, 2003 15:00”.
[0025]
(2) Operation
The operation of the parking system 100 having the above configuration will be described by exemplifying operation examples 1 to 3.
First, in the first operation example, a case will be described in which the user searches for and reserves the nearest garage during driving. In this case, it is assumed that parking is possible only in a garage for a relatively short time (here, uniformly 2 hours), and the user terminal 2 used by the user has the above-described GPS positioning function.
Next, in operation example 2, a case will be described in which, for example, a garage near the destination is searched in advance on the day before the scheduled date when the user goes out by vehicle, and the garage is reserved at a parking time desired by the user. In this case, the user terminal 2 used by the user does not necessarily have a positioning function using GPS.
Finally, in Operation Example 3, a case will be described in which a user's needs regarding parking are analyzed based on information described in the reservation information table tblBook.
[0026]
(2-1) Operation example 1
FIG. 8 is a sequence diagram for explaining the processing of the first operation example. Hereinafter, the screen displayed by the user terminal 2 will be described as an example.
First, the user terminal 2 requests data from the management server 1 according to a predetermined operation by the user and receives the data to start the processing (step Sa1).
At the start of processing, user authentication is performed by performing normal login processing (not shown). The management server 1 always executes the above-described server application program, and in response to a request from the user terminal 2, reads out data indicating a screen for searching a garage from the HDD 12 and transmits it to the user terminal 2 (step). Sa2).
[0027]
When receiving the data, the user terminal 2 displays a search screen as shown in FIG. 9, for example. Using such a search screen, the user inputs desired garage attributes. Among the search items in the figure, the item “charge” is a text box, and the user inputs a desired charge range. In addition, among the search items in the figure, the items “garage attribute 1”, “garage attribute 2”, and “handicapped” are radio buttons, and the user selects each desired item from the displayed options. Select only one per item.
Here, the user operates the user terminal 2 while referring to such a search screen, and inputs a search condition of 2 hours from 15:30, 0 to 1000 yen, indoors, ordinary cars, no disabled persons. And
[0028]
After entering each search condition shown above, the user clicks the “Search” button in the figure. In response to this, the user terminal 2 transmits the search condition to the management server 1 (step Sa3). At this time, the user terminal 2 transmits the position information of the user terminal 2 measured by the GPS positioning function together with the search condition.
[0029]
When the management server 1 receives the above-described search conditions and position information, the management server 1 extracts garage information that matches these conditions (step Sa4). Hereinafter, data received by the management server 1 and table items to be compared will be described.
First, the management server 1 compares the position information of the user terminal 2 with the “position information” of the facility information table tblPark, and the facility of the facility 3 within a predetermined range such as within 500 m from the position of the user terminal 2, for example. Extract all information records. As a result, the facility 3 in the vicinity of the current position of the user is extracted. Subsequently, the management server 1 refers to the “garage use flag” in the extracted garage information record of the facility 3, and this value is “0”, that is, a garage that is not “free” or “reserved”. Extract information records.
Next, the management server 1 compares the search conditions of “charge” and “parking time” with “parking charge” in the garage information table tblgarage for the garage information record extracted as described above. And the management server 1 extracts all the garage information records of the garage corresponding to the parking fee within the range designated by the user (that is, within 1000 yen in 2 hours).
Further, the management server 1 searches each search condition of “garage attribute 1”, “garage attribute 2” and “handicapped person”, “garage size”, “outdoor flag”, “for disabled person” in the garage information table tblgarage. Each of the “flag” is compared, and all garage information records that meet the conditions are extracted.
The management server 1 further extracts a garage information record that meets all conditions from the facility information record and the garage information record extracted as described above.
Finally, the management server 1 determines whether or not the garage information record extracted in this way has been reserved by another user during the time zone specified by the user. Specifically, a reservation information record having the same “garage ID” as the extracted garage information record is extracted from the reservation information table tblBook, and the reservation information record is set by the search condition “parking time”. It is determined whether the record does not include the time (that is, 2 hours from 15:30) in the reservation time. If this determination is affirmative, the garage corresponding to this garage information record can be reserved.
[0030]
When a garage that meets the conditions specified by the user is extracted in this way, the management server 1 transmits information about the extracted garage to the user terminal 2 (step Sa5). Upon receiving the information, the user terminal 2 displays a screen as shown in FIG. As shown in the figure, the extracted garage information is collectively displayed for each facility, and the required time from the user's position to the facility is also displayed. When the user clicks the “detail” button in FIG. 10, the user terminal 2 requests the management server 1 for detailed information on the garage selected by the user (step Sa6). This request includes the “garage ID” of the selected garage.
[0031]
When the detailed information of the garage is requested from the user terminal 2, the management server 1 searches the HDD 12 for a layout data file indicating the layout of the garage based on the received garage ID (step Sa7). (Step Sa8).
When receiving the data, the user terminal 2 displays a screen as shown in FIG. 11, for example. In the user terminal 2, processing is performed to display a reservationable garage portion indicated by the location data in a different aspect (for example, coloring, blinking, etc.) from each garage indicated in the layout data file. By doing so, such a screen is displayed.
The user refers to the layout information displayed in this way, and selects a desired garage from the viewpoint of being in a position where it is easy to park or close to the entrance or exit, and clicking on the position of the selected garage I do. In response to this, the user terminal 2 requests the management server 1 to reserve the garage (step Sa9). This request includes the “garage ID” of the selected garage.
[0032]
When a reservation is requested from the user terminal 2, the management server 1 creates a new record in the reservation information table tblBook (step Sa10). The management server 1 recognizes which user's reservation is for which garage, and in addition, a reservation start date and time and a reservation end date and time specified by the user (in this operation example, fixed 2 hours after the reservation start date and time) Based on the above, “user ID”, “garage ID”, “reservation start date / time”, and “reservation end date / time” are written in the newly created reservation information record.
At the same time that the reservation information record is newly created, the management server 1 transmits a request to put the garage in a “reserved state” to the computer 30 of the facility 3 where the reserved garage is located. This is to prevent the garage from being parked by a user who has visited without reservation.
With the above processing, the user's reservation is confirmed. After confirming the reservation, the management server 1 performs processing for fee settlement as follows.
[0033]
In the settlement process, first, based on the data transmitted from the management server 1, the user terminal 2 displays a confirmation screen for settlement information such as a credit card number, expiration date, or parking fee (step Sa11). Payment information such as the credit card number and expiration date necessary for the payment is already stored in the user information table tblUser, and the parking fee is set in the “reservation start date / time”, “reservation end date / time”, and reservation in the reservation information record. It can be calculated from the “garage parking fee” of the garage to be used. Since the management server 1 extracts these data and transmits them to the user terminal 2, no user input is required here, and the user only has to confirm on the confirmation screen. However, it is of course possible to change the information already registered on this screen as appropriate.
[0034]
After viewing the confirmation screen and confirming the settlement information, the user confirms the settlement. Upon receiving this user confirmation instruction, the user terminal 2 requests the management server 1 to perform a settlement process (step Sa12). Upon receiving this request, the management server 1 transmits settlement information to the credit server 5 of the corresponding settlement organization via the CAFIS network 4.
[0035]
When the settlement process ends, the management server 1 starts the next guidance process (step Sa13). The guidance process is a process for guiding the user from the current location to the reserved garage. At this time, the user terminal 2 displays a screen as shown in FIG. 12, for example, based on the data transmitted from the management server 1. As shown in the figure, the current position of the user terminal 2 and the facility 3 with the reserved garage are displayed on this screen, and this display is appropriately updated as the user moves. The position display of the facility 3 is performed based on “facility position information” described in the facility information record. By moving according to the display content of this screen, the user can arrive at the facility 3 as the destination.
When arriving at the destination facility 3, the user terminal 2 switches the display in order to be guided to the garage to be parked. At this time, the user terminal 2 displays a screen as shown in FIG. 13, for example. This screen is created based on the layout data file of the facility 3 as in FIG. In the figure, the user terminal 2 displays the garage part reserved by the user in the garage in the facility 3 in a different aspect from the others, and displays the route to the garage part with an arrow or the like.
By performing the above-described guidance process, the user can park in the reserved garage more easily, quickly and reliably.
[0036]
When the parking time reserved by the user has elapsed and the reservation end time is approaching, the management server 1 refers to the user's contact uAddr based on the “user ID” of the reservation information record, and It is possible to notify the user of the end of the parking time using an e-mail, a telephone, a short message service, or the like to the contact address described.
Thus, the following effects can be expected by notifying the user of the end of the parking time in advance. First, in the user, it is possible to prevent unnecessary parking time from being exceeded due to carelessness of the user, and it is possible to prevent a situation in which an excessive fee is collected. Also, for the side that operates the facility 3, by preventing the parking time from being exceeded, even if another user makes a reservation immediately after the same garage, parking is performed even though the reservation is made. Troubles that cannot be done can be prevented, and smoother facility management is possible.
[0037]
By performing the series of processes described above, the user can surely secure a parking space, and when moving to the parking space, he / she does not hesitate by appropriate guidance and spends wasted time. It becomes possible to move quickly without spending. In addition, it is possible for the operation side of the facility 3 to use each garage efficiently, and further reduce the number of personnel required for operation, etc., so that higher profits can be obtained. Become.
[0038]
(2-2) Operation example 2
FIG. 14 is a sequence diagram for explaining the processing of the second operation example. Hereinafter, the screen displayed on the user terminal 2 will be described as an example.
First, this process is started when the user terminal 2 accesses the management server 1 in accordance with a predetermined operation by the user (step Sb1). At the start of processing, user authentication is performed by performing normal login processing (not shown). The management server 1 constantly executes the server application program described above, and in response to this access, reads out data indicating a screen for searching a garage from the HDD 12 and transmits it to the user terminal 2 (step Sb2).
[0039]
When receiving the data, the user terminal 2 displays a search screen as shown in FIG. 15, for example. Using such a search screen, the user inputs desired garage attributes. Among the search items in the figure, the items “parking date and time” and “charge” are text boxes, and the user inputs a desired parking date and time and a charge range. Further, the items “garage attribute 1”, “garage attribute 2”, and “handicapped person correspondence” are the same as those in the operation example 1, and thus the description thereof is omitted.
[0040]
The “parking place” item includes a plurality of pull-down menus. Among these pull-down menus, PD1 is a pull-down menu for selecting a prefecture. The items of the pull-down menu after PD2 are variable, and the menu is generated according to the content selected in the previous pull-down menu. Referring to FIG. 15 as an example, when the item “Nagano Prefecture” is selected on PD1, items for each city under Nagano Prefecture are generated on PD2, and when the item “Suwa City” is selected on PD2, Suwa City is displayed on PD3. The item of each local name below is generated. In the same manner, items of “chome”, “address”, and “no.” Existing at the selected locations are respectively generated in PD4, PD5, and PD6. It is not necessary to select all of these items. For example, if “Suwa City, Nagano Prefecture” is selected, the following items may be left unselected.
By configuring the “parking place” item in such a configuration, the user can make a flexible selection. For example, if the search condition is “Suwa City, Nagano Prefecture”, the garage can be searched from the entire Suwa City, Nagano Prefecture, and if you want to specify the location in more detail, the search condition is “Yamato 3 “Chome”.
Here, the user operates the user terminal 2 while referring to such a search screen, and on July 3, the search condition is set to Suwa City, Nagano Prefecture, 0 to 1000 yen, indoors, ordinary cars, no disabled persons. Suppose you enter it.
[0041]
After entering each search condition shown above, the user clicks the “Search” button in the figure. In response to this, the user terminal 2 transmits the search condition to the management server 1 (step Sb3). When the management server 1 receives the search condition described above, the management server 1 extracts garage information that matches this condition (step Sb4). In the following, the data received by the management server 1 and the table items to be compared will be described, but the description of the same parts as in the operation example 1 will be omitted as appropriate.
The management server 1 compares the “parking location” search condition with the “facility address” in the facility information table tblPark, and extracts all the facility information records of the facility 3 that match the search condition. As already mentioned, the address described in the facility address pAddr has a delimiter inserted in units of prefectures and municipalities, so record comparison is performed according to the range selected by the user in the “parking location” item. Is possible.
Next, the management server 1 compares the “charge” search condition with the “parking charge” in the garage information table tblgarage for the garage information record extracted as described above. And the management server 1 extracts all the garage information records of the garage corresponding to the parking fee (that is, within 1000 yen per unit time) within the range designated by the user.
Further, the management server 1 searches each search condition of “garage attribute 1”, “garage attribute 2” and “handicapped person”, “garage size”, “outdoor flag”, “for disabled person” in the garage information table tblgarage. Each of the “flag” is compared, and all garage information records that meet the conditions are extracted.
The management server 1 further extracts a garage information record that meets all conditions from the facility information record and the garage information record extracted as described above.
Finally, the management server 1 determines whether or not the garage information record extracted in this way has been reserved by another user during the time zone specified by the user. Specifically, a reservation information record having the same “garage ID” as the extracted garage information record is extracted from the reservation information table tblBook, and the reservation information record is set by the search condition “parking date and time”. It is determined whether the record can be reserved on the date and time (July 3). If this determination is affirmative, the garage corresponding to this garage information record can be reserved at least for a certain period of time.
[0042]
Thus, when the garage suitable for the conditions specified by the user is extracted, the management server 1 transmits information regarding the extracted garage to the user terminal 2 (step Sb5). When receiving the above information, the user terminal 2 displays a screen as shown in FIG. When the user clicks the “details” button in FIG. 10, the user terminal 2 requests the management server 1 for detailed information on the garage selected by the user (step Sb6). This request includes the “garage ID” of the selected garage.
Subsequent steps Sb7 to Sb9 are the same as steps Sa6 to Sa8 in the first operation example, and therefore description thereof will be omitted, and the description will be continued assuming that a reservation instruction is given from the user terminal 2.
[0043]
When a reservation is requested from the user terminal 2, the management server 1 searches for a record related to the garage among the reservation information records in the reservation information table tblBook (step Sb10). If the corresponding reservation information record is searched by this search, it means that the garage cannot make a reservation in the time zone specified in the record.
[0044]
When the reservation information record is searched in this way, based on this result, the management server 1 transmits information related to the reservation status of the garage to the user terminal 2 (step Sb11). When receiving the above information, the user terminal 2 displays a screen as shown in FIG. 16, for example. As shown in the figure, the user terminal 2 displays the reservation status for the garage to be reserved, and the user selects a time avoiding the reservation unavailable time zone in the figure and issues a reservation instruction. Here, it is assumed that the user makes a reservation from 10:00 to 12:00. Then, the user terminal 2 requests the management server 1 to reserve the garage (step Sb12).
[0045]
When a reservation is requested from the user terminal 2, the management server 1 creates a new record in the reservation information table tblBook (step Sb13). The management server 1 recognizes which user's reservation is for which garage, and based on the reservation start date and time (10:00) and reservation end date and time (12:00) specified by the user, The “user ID”, “garage ID”, “reservation start date / time”, and “reservation end date / time” are written in the reservation information record to be created.
With the above processing, the user's reservation is confirmed. After confirming the reservation, the management server 1 performs processing for payment. Since the settlement process (steps Sb14 and Sb15) in this operation example is the same process as the settlement process (steps Sa10 and Sa11) in the operation example 1, the description thereof is omitted here, and the subsequent guidance process (step Sb16). Will be described.
[0046]
In this operation example, since the reservation is made in advance, the user terminal 2 can be configured to include a normal desktop computer or the like. Therefore, there is a case where guidance using the positioning function by GPS as described in the operation example 1 cannot be performed. If the user terminal 2 corresponds to the GPS positioning function and can move with the vehicle, the same guidance process as in the operation example 1 may be performed, but the other cases will be described here.
In such a case, the management server 1 causes the user terminal 2 to display the map data file or layout data file stored in the HDD 12. Thus, for example, in a mobile phone that does not support the positioning function by GPS, it is only necessary to move to a destination by referring to the displayed map, or in a desktop computer, the displayed map May be output as appropriate using a printer or the like, and brought to the destination.
[0047]
Also in this operation example, as in the case of operation example 1, when the reservation end time approaches, it is possible to notify a warning to the effect that the parking time has ended to the contact point designated by the user.
As described above, also in the present operation example, substantially the same effects as those in the operation example 1 can be obtained.
[0048]
(2-3) Operation example 3
The above-mentioned two operation examples have described the main function of the present invention that “a user can surely secure a parking space and quickly move to a destination without wasting time”. In addition, this system can assist the more effective operation of the facility 3 by accumulating and counting reservation information. Hereinafter, this function will be described.
[0049]
As already explained, since the management database DB1 of this system has a table structure as shown in FIG. 3, all of the customer information, facility information, and garage information can be extracted from each record of the reservation information table tblBook. is there. For this reason, for example, if a desired extraction condition is specified for the management server 1 and reservation information that matches the condition is output, various information related to the garage operating rate can be obtained. For example, it is possible to classify reservation information from various viewpoints, such as by time zone, by garage size, by charge, or by region, etc., so that user needs are concentrated in any garage. Can be analyzed. For example, when these pieces of information are analyzed with respect to a garage of a single facility 3, data such as which day of the week / time zone the facility 3 is congested can be obtained. Based on this, the facility can be efficiently managed by adjusting the personnel of the facility and the arrival of goods. Moreover, when the above data are totaled and analyzed for every facility, the comparison by a parking charge and the comparison by a location condition are also possible.
[0050]
These specific operations are as follows.
First, the computer 30 transmits extraction conditions to the management server 1. The extraction condition designation method includes methods such as time zone, garage size, or fee, and it is also possible to narrow down by garage unit, facility unit, or region unit.
When such extraction conditions are received, the management server 1 extracts reservation information records based on these extraction conditions. For example, if extraction by garage size is specified, the management server 1 extracts by referring to “garage size” of the garage information table tblgarage, and if narrowing down in units of regions is specified, the facility information table tblPark Extract by referring to the "facility address".
When the reservation information is extracted in this way, the management server 1 transmits the extraction result to the computer 30. The computer 30 receives the extraction result and outputs it in various formats such as a pie chart, a bar graph, or a table.
[0051]
(3) Modification
In addition, this invention is not limited to embodiment mentioned above, The following various changes are possible.
[0052]
(3-1) Modification 1
In the above-described embodiment, the series of processing from reservation to guidance by the system has been described in two operation examples in order to facilitate understanding thereof, but the implementation of the present invention is limited to the above-described two operation examples. Is not something For example, the operations of the operation examples 1 and 2 which are different from each other can be performed in the same facility 3 together. That is, it is of course possible to implement in a mode in which a certain garage has a fixed parking time and a different garage can freely set the parking time.
In the above-described embodiment, it is assumed that the user has subscribed to the service provided by the system 100 in advance. However, the present invention is not limited to such a mode. If so, the service subscription process may be performed at the time of the settlement process, and the user name and credit card information may be input.
[0053]
(3-2) Modification 2
In the above-described embodiment, the reservation mode (reservation mode A) is 2 hours from the user-specified start time (operation example 1), and (reservation mode B) is the user-specified start time from the user-specified start time (operation example). 2). However, in parking the vehicle, it is common not to set the delivery time after entering the vehicle, and such an aspect can be said to be suitable when the delivery time is uncertain.
Of course, the present system 100 can be implemented in such a reservation mode. For example, the reservation designation by the user is only the start date and time, and when this reservation start date and time is transmitted by the user terminal 2, the management server 1 automatically sets the reservation end date and time to 24:00 on the same day. Then, the delivery time is detected by a garage sensor, a charge for the parking time is collected, and settlement processing may be performed at this time (hereinafter referred to as reservation mode C).
Further, in the service provided by the system 100, it is more convenient for the user by providing an interface that allows the user to select the reservation mode C and the dynamic reservation modes A and B described above. A high parking system is also possible.
[0054]
However, when a reservation such as the reservation mode C is made possible, there are inconveniences as shown below for the facility manager. It is inconvenient that the reservation time of the vehicle in the garage is not fixed and the reservation of another vehicle cannot be made even if the vehicle leaves early because the reservation is made in this way. .
In order to eliminate such inconvenience, it is effective to devise the user to promote the use of the reservation modes A and B rather than the reservation mode C. Specifically, a discount charge may be applied to a user who makes a reservation such as reservation modes A and B.
In order to realize such a discount in the system 100, the following modifications may be made. First, an item describing a reservation mode is provided as an item of the reservation information table tblBook, and the reservation mode selected by the user is stored in the table. Then, when performing the payment process, the item describing the reservation mode is referred to, and the payment process may be performed after giving a certain discount to the user who is the reservation mode A or B.
[0055]
(3-3) Modification 3
In the above-described embodiment, the system is configured such that a plurality of parking facilities 3 are connected to one management server 1 as shown in FIG. However, it goes without saying that the present invention may be configured such that a plurality of management servers 1 are provided and one parking facility 3 is connected to each management server 1.
[0056]
(3-4) Modification 4
The garage attribute item used in the above embodiment is merely an example, and various other items can be considered. For example, whether it is mechanical or self-propelled, parallel parking or parallel parking, whether or not there is a discount due to shopping, and whether or not there is a roof.
By setting such various garage attribute items and providing a search interface, the user can set conditions in more detail and select a garage according to his / her preference.
[0057]
(3-5) Modification 5
In the above-described embodiment, it is assumed that the detailed information of the garage is displayed as shown in FIG. 11, but other display modes are also conceivable. For example, icon display or color-coded display may be performed so that the garage attribute set in the garage attribute item can be easily discriminated on the screen.
[0058]
(3-6) Modification 6
In the above-described embodiment, the payment processing is configured to collect a fee for the reserved time immediately after the reservation is confirmed. However, in actual use, due to a change in the user's schedule, the reserved garage may not be used, or the car may be released at a time much earlier than the scheduled time. When this happens frequently, the user may be more dissatisfied with the dissatisfaction that the paid fee is wasted than the convenience of being able to make a reservation.
In order to eliminate such an inconvenience, a method may be adopted in which the fee collected in advance is a part of the whole and the remaining amount is collected after the user uses the garage. In this case, smoother processing can be realized if the settlement processing is performed after the final usage time is determined.
Alternatively, the following method can also be used. For example, when the warehousing is monitored by the sensor and the warehousing by the reserved user is not confirmed even after a certain time (for example, 30 minutes), the reservation is canceled and only a part of the fee is collected, and the warehousing is confirmed. In such a case, a normal fee is collected. Further, since the delivery can be confirmed by using the sensor, if the delivery is made earlier than the reserved parking time, it is also possible to deduct from the parking fee by the amount delivered earlier. Further, in such a case, by rewriting the “garage use flag” of the garage information record, the garage can be reserved, so that the side operating the facility 3 can change the garage in terms of time. It can be used more efficiently without being wasted.
[Brief description of the drawings]
FIG. 1 is a system configuration diagram according to an embodiment of the present invention.
FIG. 2 is a block diagram showing functions of a management server according to the embodiment.
FIG. 3 is a diagram showing a correlation between tables stored in a management database according to the embodiment.
FIG. 4 is a diagram showing a user information table in the same embodiment.
FIG. 5 is a diagram showing a facility information table in the same embodiment;
FIG. 6 is a diagram showing a garage information table in the same embodiment.
FIG. 7 is a diagram showing a reservation information table in the same embodiment.
FIG. 8 is a sequence diagram for explaining a process of the operation example 1 according to the embodiment;
FIG. 9 is an image diagram of a search screen displayed on the user terminal in Operation Example 1;
FIG. 10 is an image diagram of a search result display screen displayed on the user terminal in Operation Example 1;
FIG. 11 is an image diagram of a garage selection screen displayed on a user terminal in Operation Example 1;
12 is an image diagram of a guidance screen displayed on a user terminal in Operation Example 1. FIG.
13 is an image diagram of a guidance screen displayed on the user terminal in Operation Example 1. FIG.
FIG. 14 is a sequence diagram for explaining a process of the operation example 2 according to the embodiment;
FIG. 15 is an image diagram of a search screen displayed on the user terminal in the second operation example.
FIG. 16 is an image diagram of a reservation time designation screen displayed on the user terminal in Operation Example 1;
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 ... Management server, 2 ... User terminal, 3 ... Facility, 11 ... CPU, 12 ... HDD, 13 ... ROM, 14 ... RAM, 15 ... Communication interface, 30 ... Computer (communication apparatus).

Claims

Storage means for storing garage information indicating the attributes of each of the plurality of garages provided in the parking facility and the status of use;
Receiving means for receiving attribute information indicating attributes of a garage, transmitted by a user terminal used by a user;
Search means for searching the garage information of the garage that matches the attribute indicated by the received attribute information and is determined to be usable based on the use status, from the garage information stored in the storage means;
A parking management device comprising: reservation means for storing reservation information indicating that a garage is reserved in association with the garage information searched by the search means.

List transmission means for transmitting information indicating a list of garages indicated by the garage information searched by the search means to the user terminal;
Comprising designated garage receiving means for receiving information designating a garage transmitted by the user terminal;
The parking management device according to claim 1, wherein the reservation unit stores the reservation information in association with garage information of a garage designated by information received by the designated garage reception unit.

The parking management device according to claim 1, further comprising reservation notifying means for notifying that the garage has been reserved to a parking facility provided with a garage reserved by the reservation means.

The receiving means receives time information on parking time together with the attribute from the user terminal,
The parking management device according to claim 1, wherein the search unit determines an available garage based on a use situation indicated by the garage information stored in the storage unit and time information received by the receiving unit.

The parking management device according to claim 1, further comprising a notification unit configured to notify a settlement organization of settlement information for settlement of a garage usage fee reserved by the reservation unit.

The parking management apparatus according to claim 1, further comprising a guiding unit that transmits information indicating a place in a parking facility of a garage reserved by the reservation unit to the user terminal.

Condition receiving means for receiving extraction conditions from the communication device;
Extraction means for extracting garage information that matches the extraction condition received by the condition receiving means from garage information stored in association with the reservation information by the reservation means;
The parking management device according to claim 1, further comprising: a transmission unit that transmits the extracted garage information to the communication device.

On the computer,
A receiving function for receiving attribute information indicating attributes of a garage transmitted by a user terminal used by a user;
Referring to the storage means for storing the garage information indicating the attributes and usage status of each garage provided in the parking facility, the attribute information received by the reception function is stored from the stored garage information. A search function for searching for garage information of a garage that matches an attribute to be shown and is determined to be usable based on the use situation;
The program for implement | achieving the reservation function which memorize | stores in the memory | storage means the reservation information which shows having matched the said garage information searched by the said search function and reserved the garage.

A user terminal used by a user, and a parking management device capable of communicating with the user terminal;
The user terminal is
An input means for the user to input attribute information indicating an attribute of the garage;
Transmission means for transmitting the input attribute information to the parking management device,
The parking management device
Receiving means for receiving the attribute information transmitted by the user terminal;
Storage means for storing garage information indicating the attributes of each of the plurality of garages provided in the parking facility and the status of use;
Search means for searching the garage information of the garage that matches the attribute indicated by the received attribute information and is determined to be usable based on the use status, from the garage information stored in the storage means;
A parking management system comprising: reservation means for storing reservation information indicating that the garage has been reserved in association with the garage information searched by the search means.