JP3957649B2 - 予約受付システムおよびコンピュータプログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、遠隔地にいる顧客から要求された予約の受付の処理を行うシステムおよび方法に関する。
【０００２】
【従来の技術】
従来より、遠隔地にいる顧客からの予約の要求を受け付けるためのシステムが提案されまたは実用化されている。例えば、下記の特許文献１〜６に記載されるシステムによると、駐車場またはレストランなどの利用を所望する顧客が携帯電話などを操作することによって予約の要求を行うことができる。また、非特許文献１〜３には、遠隔地にいる顧客からの予約の要求を受け付ける、実用化されたシステムが記載されている。
【０００３】
これらのシステムによると、駐車場またはレストランなどの利用を所望する顧客は、前もって駐車スペースまたは席などの利用権を確保することができるので、その場所に着いてから長い時間待たされることがない。一方、運営者は、早期に需要の予測を行うことができるので、効率的な運営を図るための参考にすることができる。
【０００４】
【特許文献１】
特開平６−１９９２９号公報
【０００５】
【特許文献２】
特開２００１−８４４１８号公報
【０００６】
【特許文献３】
特開２００２−２３６８３２号公報
【０００７】
【特許文献４】
特開２００２−７８２６号公報
【０００８】
【特許文献５】
特許第２８６９５８３号公報
【０００９】
【特許文献６】
特開２００２−２７９２６０号公報
【００１０】
【非特許文献１】
" 「旅の窓口」総合旅行予約システム" 、マイトリップ・ネット株式会社、平成１５年２月２０日、［平成１５年２月２０日検索］、インターネット＜http://www.mytrip.net/＞
【００１１】
【非特許文献２】
"Parking Information" 、ＰＡＲＫ ２４ Ｃｏ．，Ｌｔｄ．、２００２年５月３０日、［平成１５年２月２０日検索］、インターネット＜http://www.times-info.net/pc/reserv/index.html＞
【００１２】
【非特許文献３】
" 精度の高い位置情報を利用した携帯電話向けピンポイント情報配信試行サービス「じゃらんナビ札幌」の実施について" 、ＫＤＤＩ株式会社、株式会社リクルート、日本電気株式会社、２００２年４月１７日、［平成１５年２月２０日検索］、インターネット＜http://www.kddi.com/release/2002/0417-1/＞
【００１３】
【発明が解決しようとする課題】
しかし、顧客からの予約の要求をすべて一律に受け入れてしまうと、かえって運営の効率が悪くなり、利益が減少する場合があり得る。
【００１４】
すなわち、例えば、駐車場のように分刻みでリソース（駐車スペース）を顧客に提供する場合または売上の単価が低い場合において、より多くの利益を得るためには、できるだけ駐車スペースの利用の回転率または稼働率を上げることが必要となる。ところが、遠方にいる顧客からの予約の要求を際限なくどんどん受け入れると、その顧客が駐車場に着くまでの間は、その顧客のためにキープした駐車スペースが利用されないこととなる。また、予期せぬ渋滞などによってその顧客の到着が遅れることがある。よって、リソースの回転率または稼働率が下がり、運営の効率が悪くなってしまう。
【００１５】
予約を行った顧客が駐車場に着くまでの間、その顧客のためにキープした駐車スペースを他の顧客に貸すことが考えられる。しかし、そうすると、予約を行った顧客が駐車場に着くまでに他の顧客の自動車が駐車場の利用をやめて退場しなければ、予約を行った顧客が駐車できなくなるおそれが生じてしまう。
【００１６】
または、特許文献３に記載されるように、いわゆる意味情報ネットワークによって予約依頼を受け付ける方法が考えられる。しかし、そうすると、現在のサービスの提供の形態自体を意味情報ネットワークに適合するように再構築しなければならない。このように再構築することは大掛かりで難しい。また、サービスの提供のための意味情報ネットワークを構築できたとしても、運用のコストが高いという問題点が残る。よって、特に売上単価の低いサービスを提供する者にとっては、意味情報ネットワークを採用することは現実的でない。
【００１７】
本発明は、このような問題点に鑑み、リソースを有する運営者にとって、リソースが効率よく用いられるように顧客からの予約の受付を行うことを目的とする。
【００１８】
【課題を解決するための手段】
本発明に係る予約受付システムは、サービスの今後の需要の量について示すパラメータを有しかつ前記サービスの提供場所の周囲の所定の領域を前記パラメータが示す量が少ないほど広い領域に定める領域情報を記憶する領域情報記憶手段と、顧客が使用する端末装置から、前記サービスの提供を受けたい旨の要求を、通信回線を介して受け付ける、要求受付手段と、前記要求を行った顧客の現在地を示す現在地情報を、通信回線を介して取得する、現在地情報取得手段と、情報提供手段より発信される、前記サービスの提供場所周辺または前記要求を行った顧客の周辺の交通情報を、通信回線を介して取得する、交通情報取得手段と、前記交通情報取得手段によって取得された前記交通情報に基づいて所定の関数によって前記需要の量の予測を行う需要予測手段と、前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を、前記需要予測手段によって予測された前記需要の量と前記領域情報記憶手段に記憶されている前記領域情報とによって定められる領域に前記現在地情報に示される当該顧客の現在地が属するか否かを判別することによって行う、存否判別手段と、前記要求を行った顧客が前記所定の領域の中にいると判別された場合は当該要求に係る前記サービスの予約を受け付けるための処理である予約受付処理を行い、当該顧客が前記所定の領域の中にいないと判別された場合は前記予約受付処理を行わない、予約受付処理手段と、が設けられてなる。
【００２０】
前記サービスとして、駐車場の駐車スペースを提供する場合は、予約受付システムを次のように構成してもよい。すなわち、前記駐車場の今後の需要の量について示すパラメータを有しかつ前記駐車場の周囲の所定の領域を前記パラメータが示す量が少ないほど広い領域に定める領域情報を記憶する領域情報記憶手段と、顧客が使用する端末装置から、前記駐車場に自動車を駐車したい旨の要求を、通信回線を介して受け付ける、要求受付手段と、前記要求を行った顧客の現在地を示す現在地情報を、通信回線を介して取得する、現在地情報取得手段と、情報提供手段より発信される、前記駐車場の周辺または前記要求を行った顧客の周辺の交通情報を、通信回線を介して取得する、交通情報取得手段と、前記交通情報取得手段によって取得された前記交通情報に基づいて所定の関数によって前記需要の量を予測を行う需要予測手段と、 前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を、前記需要予測手段によって予測された前記需要と前記領域情報記憶手段に記憶されている前記領域情報とによって定められる領域に前記現在地情報に示される当該顧客の現在地が属するか否かを判別することによって行う、存否判別手段と、前記要求を行った顧客が前記所定の領域の中にいると判別された場合は当該顧客のために前記駐車場の予約を受け付けるための予約受付処理を行い、当該顧客が前記所定の領域の中にいないと判別された場合は前記予約受付処理を行わない、予約受付処理手段と、によって構成する。
【００２１】
なお、本発明においてサービスとは、例えば、駐車場の駐車スペースを貸すこと、ホテルの部屋を貸すこと、カラオケボックスの部屋を貸すこと、貸しオフィスでＯＡ機器を貸すこと、レストランで食事を提供すること、数に限りのある商品を販売すること、保険などの相談に乗ること、または美容院などで整髪を行うことなどのように、物的なリソース（駐車スペース、部屋、ＯＡ機器、レストランの席、または商品など）または人的なリソース（料理人、相談員、または美容師など）を提供することを意味する。
【００２２】
【発明の実施の形態】
〔第一の実施形態〕
図１は本発明に係る予約受付システム２を有するシステム全体の構成の例を示す図、図２は予約受付システム２のハードウェア構成の例を示す図、図３は予約受付システム２および駐車場利用管理システム３の機能的構成の例を示す図、図４は顧客テーブルＴＬ１の例を示す図、図５は領域条件情報８１の例を示す図、図６は距離条件情報８２の例を示す図、図７は時間条件情報８３の例を示す図、図８は駐車スペーステーブルＴＬ２の例を示す図、図９は予約画面ＨＧ１の例を示す図、図１０は予約テーブルＴＬ３の例を示す図である。
【００２３】
図１に示すように、予約システム１は、本発明に係る予約受付システム２および駐車場利用管理システム３などによって構成される。予約受付システム２と駐車場利用管理システム３とは、ネットワーク６を介して互いに接続可能である。ネットワーク６として、インターネット、イントラネット、専用線、または公衆回線などが用いられる。
【００２４】
駐車場利用管理システム３は、ある駐車場Ａの駐車スペースの管理のための処理などを行う。予約受付システム２は、この駐車場Ａを利用することを希望する自動車の運転手のために、駐車スペースの予約を受け付ける処理を行う。つまり、運転手と駐車場Ａとの仲介を行う。
【００２５】
運転手は、自分の手元の端末装置５を操作することによって、遠隔地より予約を行うことができる。端末装置５として、位置情報を発信することができる装置が用いられる。例えば、ＧＰＳ（Global Positioning System ）機能を有する携帯電話端末、ＰＨＳ端末、ＰＤＡ（Personal Digital Assistant）、携帯型パソコン、またはカーナビゲーションシステム用の端末装置などが用いられる。また、端末装置５では、駐車場Ａに到着するまでの間、予約の必要事項の入力および自らの位置情報の発信などを行うための予約用アプリケーションが起動されている。
【００２６】
予約受付システム２は、図２に示すように、ＣＰＵ２ａ、ＲＡＭ２ｂ、ＲＯＭ２ｃ、磁気記憶装置２ｄ、ディスプレイ装置２ｅ、マウスまたはキーボードなどの入力装置２ｆ、および各種インタフェースなどによって構成される。
【００２７】
磁気記憶装置２ｄには、オペレーティングシステム（ＯＳ）および図３に示す予約要求受信部２０１、位置情報受信部２０２、存否判別部２０３、予約可否判別部２０４、予約受付処理部２０５、利用状況取得部２０６、キャンセル処理部２０７、到着時刻予測部２７１、到着可否判別部２７２、交通情報取得部２０８、受付条件データベース２Ｄ１、および顧客情報データベース２Ｄ２などを実現するためのプログラムおよびデータなどがインストールされている。これらのプログラムおよびデータは、必要に応じてＲＡＭ２ｂにロードされ、ＣＰＵ２ａによってプログラムが実行される。
【００２８】
駐車場利用管理システム３も、予約受付システム２と同様のハードウェア構成をしている。駐車場利用管理システム３の磁気記憶装置には、オペレーティングシステム（ＯＳ）および図３に示す駐車場データベース３Ｄ１および予約情報データベース３Ｄ２などを実現するためのプログラムおよびデータなどがインストールされている。
【００２９】
以下、図３に示す各部の機能および処理内容などについて説明する。顧客情報データベース２Ｄ２は、図４に示すような顧客テーブルＴＬ１を記憶し管理する。この顧客テーブルＴＬ１には、駐車場Ａを利用する顧客（ユーザ）に関する情報が、そのユーザを識別するために発行したユーザＩＤと対応付けられて格納されている。つまり、ユーザ登録に関する情報が格納されている。ユーザＩＤとして、その顧客の端末装置５にユニークに割り当てられている識別子（例えば、携帯電話端末の電話番号など）を用いてもよい。
【００３０】
受付条件データベース２Ｄ１は、図５、図６、および図７にそれぞれ示すような領域条件情報８１、距離条件情報８２、および時間条件情報８３などを記憶する。これらの情報は、駐車場Ａの駐車スペースの予約を行ってもよいか否かを判別するための条件を示している。以下、予約の可否の判別の条件を示すこれらの情報を、「条件情報８」という総称を用いて記載することがある。
【００３１】
駐車場データベース３Ｄ１は、図８に示すような駐車スペーステーブルＴＬ２を記憶し管理する。この駐車スペーステーブルＴＬ２には、駐車場Ａに設けられている駐車スペースごとの空き状況および駐車可能な車種などに関する情報が格納されている。
【００３２】
予約要求受信部２０１は、駐車場Ａに自動車を駐車するための予約の要求を示す予約要求情報７１を端末装置５より受信する。そして、予約要求情報７１に示されるユーザＩＤおよびパスワードに基づいてユーザ認証を行う。予約要求情報７１は、端末装置５において次のような手順で発信される。
【００３３】
駐車場Ａの利用を希望する顧客すなわち運転手は、自分の端末装置５を操作して予約用アプリケーションを起動する。または、予約受付システム２のＵＲＬを指定するなどして、予約用アプリケーションと同等の機能を有するＷｅｂアプリケーションを提供しているＷｅｂページにアクセスする。もちろん、これらの操作および後に説明する各操作は、運転手の代わりに同乗者が行ってもよい。すると、端末装置５には、図９に示すような駐車場予約フォームを有する予約画面ＨＧ１が表示される。
【００３４】
運転手は、各テキストボックスＴＸに自分のユーザＩＤ、パスワード、および利用時間を入力する。「利用時間」とは、駐車場を利用する予定の時間つまり希望時間を意味する。入力後、運転手は、送信ボタンＢＮ１を押す。これにより、入力された内容が予約要求情報７１として予約受付システム２に送信される。予約の要求を取りやめる場合は、中止ボタンＢＮ２を押す。なお、ユーザＩＤとして携帯電話端末などの電話番号や端末ＩＤを用いる場合は、ユーザＩＤに対応するテキストボックスＴＸへの入力を行わずに、端末内に格納されているこれらの情報を読み出して予約受付システム２に知らせるようにしてもよい。これにより、第三者によるユーザＩＤの不正な使用を防止し、セキュリティを高めることができる。
【００３５】
また、端末装置５は、予約要求情報７１とともに、端末装置５の位置つまり顧客の現在地を示す位置情報７２を予約受付システム２に送信する。この位置情報７２は、ＧＰＳ衛星または地上から発信される電波に基づいて求められた緯度および経度を示すものである。または、端末装置５が携帯電話端末またはＰＨＳ端末などである場合は、端末装置５を捉えている基地局（アンテナ局）の位置を自動車の現在の位置とみなしてもよい。「末広町１丁目２−３」のように番地を示すものであってもよい。位置情報７２は、予約受付システム２において、図３の位置情報受信部２０２によって受信される。
【００３６】
存否判別部２０３は、受信した位置情報７２に基づいて、その顧客の自動車が駐車場Ａの近くの所定の範囲（領域）内に位置するか否かの判別を行う。この所定の範囲とは、駐車場Ａに所定の時間以内に着くことができるおよその領域を表すものであり、例えば、図５に示す領域条件情報８１によって定められる。つまり、位置情報７２によって示される位置が領域条件情報８１の条件１〜３に示される範囲（領域）のいずれかに属する場合は、顧客が駐車場Ａの近くに位置すると判別する。いずれの条件の領域にも属さない場合は、近くに位置しないと判別する。判別の結果は、存否判別情報７４として予約可否判別部２０４に出力される。
【００３７】
領域条件情報８１の領域は、図５の条件１、２に示すように四角形または七角形などの多角形の頂点によって定めてもよい。円または楕円などの形を示す関数によって定めてもよい。または条件３に示すように町名または地区名などによって定めてもよい。複雑な形であってもよい。なお、条件１、２に該当するか否かの判別は、位置情報７２が町名などを示す場合は、その町の代表点（例えば町の中心地）を求め、その代表点が条件１、２に示される領域に属するか否かを判別することによって行う。また、条件３に該当するか否かの判定は、位置情報７２が緯度および経度の位置を示す場合は、その位置の属する町名を求め、両者を比較することによって行う。
【００３８】
所定の範囲内に属するか否かの判別を、図６に示す距離条件情報８２に基づいて行ってもよい。すなわち、駐車場Ａの位置と位置情報７２に示される位置との距離が、距離条件情報８２に示される条件１〜３のうちのいずれかに該当する場合は、駐車場Ａの近くに位置すると判別する。
【００３９】
または、図７に示す時間条件情報８３に基づいて行ってもよい。すなわち、位置情報７２に示される位置から駐車場Ａまでの所要時間が時間条件情報８３に示される条件１〜３のうちのいずれかに該当する場合は、駐車場Ａの近くに位置すると判別する。つまり、所定の時間距離の範囲内に位置するか否かを判別する。係る所要時間は、例えば、自動車の平均速度および駐車場Ａの位置と位置情報７２に示される位置との距離に基づいて求められる。ＶＩＣＳ（Vehicle Information and Communication System）などの情報提供システム４（図１参照）から提供される交通渋滞または通行規制などの交通情報または気象情報などを参照して所要時間を求めてもよい。交通情報などは、交通情報取得部２０８によって取得される。
【００４０】
利用状況取得部２０６は、駐車場利用管理システム３の駐車場データベース３Ｄ１にアクセスする。そして、駐車場Ａの駐車スペースのうちの、予約の要求を行った顧客の自動車の車種（図４参照）に合う駐車スペースについての、現在の利用状況を示す利用状況情報７３を取得する。利用状況情報７３には、例えば、駐車スペースの総数、現在空いている駐車スペースの数、または現在の空車率などが示される。
【００４１】
予約可否判別部２０４は、取得した利用状況情報７３および存否判別部２０３による判別結果すなわち存否判別情報７４に基づいて、顧客からの予約の要求を受け入れてもよいか否かの判別を行う。係る判別は、次のように行う。
【００４２】
顧客が駐車場Ａの近くに位置しない旨が存否判別情報７４に示される場合は、顧客からの予約の要求を受け入れないと判別する。近くに位置する旨が示される場合は、さらに、駐車場Ａの利用状況に応じて予約の要求を受け入れるか否かを判別する。
【００４３】
例えば、駐車スペースの空きが所定の数（例えば５つ）以上ある旨が利用状況情報７３に示される場合は、顧客からの予約の要求を受け入れてもよいと判別する。一方、所定の数に満たない場合は、要求を受け入れないと判別する。なお、過去の駐車場Ａの利用実績またはＶＩＣＳなどから提供される交通情報または気象情報などに基づいて今後の需要および退場する自動車の台数などを予測し、今後の需要よりも退場する自動車の台数のほうが多いと予測される場合は、所定の数を「０」としてもよい。つまり、現時点において満車であっても、駐車場の利用が減る傾向にあるのであれば、予約の要求を受け入れてもよいと判別してもよい。
【００４４】
または、所定の数を「駐車場Ａの駐車スペース全体の１０％」のように決めておいてもよい。なお、「駐車スペース全体」は、必ずしも実在する駐車スペースの全部を意味する必要はない。例えば、「実在する駐車スペースのうちの８０％」というように、実在する駐車スペースのうちの一部を駐車スペース全体とみなし、残りの駐車スペースを予備のための駐車スペースまたは予約なしで訪れる顧客のために用いるようにしてもよい。または、キャンセルがあることを見越して、実際よりも多い駐車スペース（例えば、実在する駐車スペースの１０５％）を駐車スペース全体と仮定してもよい。
【００４５】
予約受付処理部２０５は、顧客からの予約の要求を受け入れてもよいと判別された場合に、駐車場利用管理システム３に対して、その予約の登録を行うように依頼する。この際に、予約画面ＨＧ１（図９参照）に入力された内容および顧客テーブルＴＬ１（図４参照）に基づいて、その顧客のユーザＩＤ、利用する予定の時間（利用時間）、および車両ナンバーを通知する。
【００４６】
予約情報データベース３Ｄ２は、図１０に示す予約テーブルＴＬ３を記憶し管理する。予約テーブルＴＬ３には、予約に関する予約情報７５が格納されている。予約情報データベース３Ｄ２は、予約受付システム２からの依頼に従って、予約テーブルＴＬ３に新規のレコード（予約情報７５）を追加する。これにより、顧客から要求された予約の受付が完了する。
【００４７】
予約情報７５が示す「有効期限」とは予約の有効期限のことであり、この期限を過ぎても顧客が駐車場Ａに到着しなければ予約がキャンセルされることを意味する。有効期限は、例えば、利用時間の長さに応じて決定する。例えば、利用時間が１時間の場合の有効期限を現在の時刻の３０分後としておき、利用時間がさらに２時間増えるごとに有効期限を１０分ずつ遅らせるようにする。これにより、より長い時間利用する顧客すなわちより多くの売上が見込める顧客を優先的に確保し、駐車場全体の売上を効率的に上げることができる。
【００４８】
または、位置情報７２によって示される顧客の現在の位置に基づいて、顧客が駐車場Ａに到着するまでに要する時間（到着所要時間）を算出する。そして、到着所要時間と渋滞による時間ロスや誤差などを考慮した予備的な時間（予備時間）とを現在の時刻に加えることによって、予約の有効期限を算出してもよい。例えば、現在の時刻が９時１０分であり、到着所要時間が２０分と算出され、時間ロスや誤差（予備時間）が１０分と算出される場合は、予約の有効期限は９時４０分に決まる。つまり、この場合の有効期限は、多少の時間の余裕を考慮して予測される顧客の到着の時刻を示すものである。
【００４９】
予約の完了後、端末装置５には、予約が受け付けられデータベースに登録された旨のメッセージが予約受付ＩＤとともに送信される。予約可否判別部２０４によって予約の要求を受け入れない旨つまり拒否する旨の判別がなされた場合は、その旨のメッセージが送信される。
【００５０】
キャンセル処理部２０７は、一旦受け付けられ登録された予約のキャンセルの処理を行う。すなわち、顧客の端末装置５から予約のキャンセルの要求があった場合に、顧客が指定した予約受付ＩＤを予約情報データベース３Ｄ２に通知する。すると、予約情報データベース３Ｄ２は、その予約受付ＩＤに対応するレコード（予約情報７５）を図１０の予約テーブルＴＬ３から削除し、予約の登録を取り消す。そして、予約のキャンセルが完了した旨のメッセージを端末装置５に送信する。
【００５１】
また、定期的に予約テーブルＴＬ３の各予約情報７５の有効期限をチェックし、有効期限を過ぎても駐車場Ａに到着しない顧客が見つかった場合は、キャンセルの要求の有無に関わらず、その顧客の予約をキャンセルするようにしてもよい。有効期限のチェックは、キャンセル処理部２０７が主体となって予約情報データベース３Ｄ２に対して定期的に問合せを行うことによって行う。または、予約情報データベース３Ｄ２が主体となって行い、有効期限切れの予約が見つかった場合にキャンセル処理部２０７に通知するようにしてもよい。
【００５２】
有効期限前であっても顧客の自動車が予約の有効期限までに駐車場Ａに到着できないと予測される場合にも、予約のキャンセルの処理を行ってもよい。係る予測は、例えば、到着時刻予測部２７１および到着可否判別部２７２によって次のような手順で行う。
【００５３】
予約の完了後、端末装置５は、所定の時間（例えば５分）ごとに自らの位置情報７２を予約受付システム２に送信する。これにより、予約受付システム２は、顧客の現在地を定期的に把握することができる。到着時刻予測部２７１は、受信した位置情報７２に示される位置、ＶＩＣＳより提供される交通情報、および現在の時刻などに基づいて、現時点における顧客の駐車場Ａへの到着の予測の時刻を算出する。到着可否判別部２７２は、算出された時刻が予約情報７５に示される有効期限を超えている場合は、有効期限内に到着することができないと判別（予測）する。なお、これらの処理は、顧客が駐車場Ａに到着するまでの間または予約がキャンセルされるまでの間、定期的に継続して行われる。
【００５４】
図１１は予約の要求を行う際の端末装置５の処理の流れの例を説明するフローチャート、図１２は予約の要求の受付を行う際の予約受付システム２の処理の流れの例を説明するフローチャート、図１３は変更情報テーブルＴＬ８ａ〜ＴＬ８ｄの例を示す図、図１４はキャンセルの処理を行う際の予約受付システム２の処理の流れの例を説明するフローチャートである。
【００５５】
次に、駐車場Ａの予約を行う際の各装置における処理の流れを、フローチャートを参照して説明する。
図１１において、駐車場Ａの予約を所望する運転手は、自動車の運転を中断し、自分の端末装置５を操作して、予約用アプリケーションを起動させる（＃１１）。または、所定のＵＲＬを入力して予約受付システム２のＷｅｂページにアクセスする。これにより、端末装置５には図９に示す予約画面ＨＧ１が表示される。運転手は、自分のユーザＩＤ、パスワード、および所望する利用時間を入力し、送信ボタンＢＮ１を押す（＃１２）。すると、入力された内容を示す予約要求情報７１および顧客の現在の位置を示す位置情報７２が予約受付システム２に送信される（＃１３）。
【００５６】
一方、予約受付システム２は、図１２に示すように、予約要求情報７１および位置情報７２を受信し（＃２１）、これらの情報および条件情報８（図５、図６、図７参照）に基づいて、予約を受け付けてもよいか否かを判別する（＃２３）。なお、判別を行う前に、必要に応じて、判別に用いる条件情報８を次のように変更してもよい（＃２２）。
【００５７】
例えば、図１３（ａ）に示すような変更情報テーブルＴＬ８ａを用意しておく。この変更情報テーブルＴＬ８ａは、駐車場Ａの駐車スペース全体の空車率に対応した、予約の可否の判別のための条件（領域）を定めるものであって、図６に示す距離条件情報８２のうちの「条件番号＝１」の内容を変更するために用いられる。なお、後に説明する図１３（ｂ）〜（ｄ）に示す各テーブルも、距離条件情報８２のうちの「条件番号＝１」の内容を変更するために用いられる。
【００５８】
変更情報テーブルＴＬ８ａの中から、図３の利用状況取得部２０６によって取得された利用状況情報７３に示される空車率に対応するレベルの条件を選択する。例えば、「空車率＝３％」であれば、レベル１の条件すなわち「距離＝３ｋｍ以内」を選択する。そして、選択した条件を図６の距離条件情報８２の条件番号１の条件すなわち「距離＝１０ｋｍ以内」と置き換える。これにより、判別に用いる条件情報８が変更される。
【００５９】
このように、空車のスペースが多い場合は、顧客を受け入れる範囲（面積）を広げ、より多くの顧客を受け入れることによって、利益を上げることができる。また、空車のスペースが少ない場合は、顧客を受け入れる範囲を狭め、すぐに到着することができる顧客に限定することによって、駐車スペースの回転率および稼働率を高め、効率的に利益を上げることができる。空車率の代わりに、空いている駐車スペースの数に応じて、判別に用いる条件情報８を変更するようにしてもよい。
【００６０】
または、駐車場Ａを利用する予定の時間すなわち図９の予約画面ＨＧ１において指定された利用時間の長さに応じて判別に用いる条件情報８を変更するようにしてもよい。この場合は、図１３（ｂ）に示すような変更情報テーブルＴＬ８ｂに基づいて変更を行う。つまり、利用する予定の時間が長いほど予約を受け付ける条件を緩くし、短いほど厳しくする。
【００６１】
このように、より長い時間駐車場Ａを利用する顧客つまりより多くの売上が見込める顧客については、条件を緩和して予約が受け付けられやすくすることによって、効率的に利益を上げることができる。
【００６２】
または、今後（例えばこれから１時間くらい後）に駐車場Ａに訪れる顧客の数の予測に応じて判別に用いる条件情報８を変更するようにしてもよい。この場合は、図１３（ｃ）に示すような変更情報テーブルＴＬ８ｃに基づいて変更を行う。つまり、需要が多いと予想されるほど条件を厳しくし、少ないと予測されるほど緩くする。係る需要は、例えば、過去の駐車場Ａの利用実績またはＶＩＣＳなどから提供される交通情報または気象情報などに基づいて、所定の関数などによって求められる。
【００６３】
または、曜日または時間帯などに応じて判別に用いる条件情報８を変更するようにしてもよい。この場合は、図１３（ｄ）に示すような変更情報テーブルＴＬ８ｄに基づいて変更を行う。つまり、需要の見込みが少ない曜日または時間帯ほど条件を緩くし、多い曜日または時間帯ほど条件を厳しくする。
【００６４】
このように、需要予測または需要見込みが少ないほど条件を緩和することによって、空車率を少なくし、利益を上げることができる。また、需要予測または需要見込みが多いほど条件を厳しくすることによって、駐車場Ａの近くにいる顧客を優先的に受け入れ、回転率および稼働率を高め利益を効率的に上げることができる。
【００６５】
同様に、図６の条件番号２および３の条件を変更するための、図１３（ａ）〜（ｄ）に相当するテーブルを用意しておき、このような条件の置換え（変更）を行う。これらのテーブルの代わりに、空車率をパラメータとする関数を用意しておいてもよい。また、図５の領域条件情報８１および図７の時間条件情報８３についても、それぞれの条件番号１〜３の条件ごとに図１３（ａ）〜（ｄ）に相当するテーブルまたは関数を用意しておいてもよい。図１３（ａ）の空車率すなわちパラメータを、「（駐車スペースが）非常に多い」、「やや多い」、「ほとんどない」などの状況を意味する言葉を用いて表してもよい。同様に、図１３（ｂ）の利用時間を「短い」、「普通」、または「長い」などのように表してもよい。図１３（ｃ）の需要予測を「多い」、「普通」、または「少ない」などのように表してもよい。
【００６６】
なお、判別に用いる条件情報８の変更は、所定の時間ごとに定期的に行うようにしてもよい。または、交通情報や気象情報などの情報が、いわゆるプレゼンスシステムによって更新されるごとに予約受付システム２に送信されてくる場合は、その度に、条件情報８の変更の必要があるか否かを判別し、必要であれば変更を行うようにしてもよい。
【００６７】
図１２に戻って、予約の受付が可能であると判別された場合は（＃２３でＹｅｓ）、予約の登録を行うように駐車場利用管理システム３に対して依頼を行う（＃２４）。この際に、顧客の到着時間を予測するなどして予約の有効期限を求め、これを駐車場利用管理システム３に通知する。これにより、予約テーブルＴＬ３（図１０参照）には、新たに予約情報７５が追加され、予約の受付が完了する。そして、予約の要求元の端末装置５に対して予約が受け付けられた旨を通知する（＃２５）。予約の受付が不可であると判別された場合は（＃２３でＮｏ）、要求元の端末装置５に対してその旨を通知する（＃２５）。
【００６８】
図１１に戻って、端末装置５は、予約の要求を行った後所定の時間内に予約の受付の可否についての通知があった場合は（＃１４でＹｅｓ）、その通知の内容を表示する（＃１５）。所定の時間を過ぎても通知がなかった場合は（＃１４でＮｏ）、予約の要求が受け付けられなかったものとみなし、タイムアウトになった旨を表示する（＃１６）。
【００６９】
予約が受け付けられた後、予約受付システム２は、図１４に示すように、予約のキャンセルのための処理を行う。タイマをリセットし（＃３１）、時間の計測を開始する（＃３２）。所定の時間の経過後、予約に係る顧客の現在の位置を示す位置情報７２を取得する（＃３３）。
【００７０】
位置情報７２に示される位置および現在の時刻などに基づいて、現時点における顧客の駐車場Ａへの到着の時刻を算出（予測）する（＃３４）。予測された現時点における到着の時刻と予約情報７５に示される有効期限（図１０参照）とを比較することによって、予約の有効期限内に到着することができるか否かを判別する（＃３５）。
【００７１】
到着することができないと判別された場合は（＃３５でＮｏ）、予約をキャンセルするように駐車場利用管理システム３に対して依頼する（＃３６）。これにより、その予約に係る予約情報７５が予約テーブルＴＬ３より削除される。そして、キャンセルされた旨が予約の要求元の端末装置５に送信される（＃３７）。到着することができると判別された場合は（＃３５でＹｅｓ）、自動車が駐車場Ａに到着するまでの間、ステップ＃３１〜＃３５の処理を繰り返す（＃３８でＮｏ）。なお、顧客よりキャンセルの申し出があった場合または有効期限が過ぎてしまった場合は、上記の判別の結果に関わらず、ステップ＃３６のキャンセルの依頼を行う。
【００７２】
本実施形態によると、顧客を選別して予約を受け付けることによって、駐車場を運営する運営者にとって、駐車スペースを効率的に顧客に利用させることができる。また、条件情報８の内容を動的にすることによって、駐車スペースの回転率および稼働率をより向上させることができる。
〔第二の実施形態〕
図１５は仮予約の要求を行う際の端末装置５の処理の流れの例を説明するフローチャート、図１６は仮予約時処理の流れの例を説明するフローチャート、図１７は仮予約の要求の受付を行う際の予約受付システム２の処理の流れの例を説明するフローチャート、図１８は仮予約確認画面ＨＧ２の例を示す図、図１９は本予約確認画面ＨＧ３の例を示す図である。
【００７３】
第一の実施形態では、図３の予約受付処理部２０５は、予約の要求を受け入れてもよいと予約可否判別部２０４によって判別された場合にのみ、予約の受付のための処理を行った。第二の実施形態では、予約受付処理部２０５は、予約の要求を受け入れないと判別された場合であっても、係る要求を仮に受け付けておく。そして、その後に予約の受付の条件を満たすようになった場合に、正式に予約を受け付け、予約テーブルＴＬ３に登録するための処理を行う。以下、仮に予約を受け付けることを「仮予約」と記載し、正式に予約を受け付けることを「本予約」と記載することがある。
【００７４】
第二の実施形態における予約システム１、予約受付システム２、駐車場利用管理システム３、および端末装置５の構成は、基本的に第一の実施形態の場合と同様である。ただし、予約受付システム２および端末装置５は、図１５、図１６、および図１７に示すような内容の処理を行う。
【００７５】
図１５において、端末装置５は、図９に示す予約画面ＨＧ１を表示して必要事項の入力を受け付け、予約要求情報７１および位置情報７２を予約受付システム２に送信することによって、予約の要求を行う（＃４１〜＃４３）。これらの処理の内容は、図１１のステップ＃１１〜＃１３の場合と同じである。
【００７６】
予約の要求を行った後所定の時間内に予約の受付の可否についての通知があった場合は（＃４４でＹｅｓ）、その通知の内容を表示する（＃４５）。その通知の内容が予約の受付ができない旨を示す場合は（＃４６でＮｏ）、仮予約の要求のための処理を行う（＃４７）。係る処理は、図１６に示すような手順で行われる。
【００７７】
端末装置５は、図１８に示す仮予約確認画面ＨＧ２を表示することによって、仮予約を行う旨の確認を顧客（運転手）に対して行う（図１６の＃１０１）。了解ボタンＢＮ３が押された場合は、予約を行う旨の確認がなされたものと判別し、予約受付システム２に対して仮予約の要求を行う（＃１０２）。
【００７８】
タイマをリセットし（＃１０３）、時間の計測を開始する（＃１０４）。所定の時間の経過後、その時点における顧客の位置情報７２を予約受付システム２に送信する（＃１０５）。送信後、表示の画面を予約用アプリケーションのトップ画面に戻し、予約受付システム２からの通知を待つ。
【００７９】
一方、予約受付システム２は、図１７に示すように、端末装置５からの仮予約の要求を受け付けると（＃５１）、係る要求を示すレコードを、図示しない仮予約テーブルに登録し（＃５２）、仮予約を受け付けた旨を端末装置５に通知する。この時点では、予約は正式に受け付けられておらず、駐車スペースの確保はなされていない。通知後、端末装置５からの位置情報７２を受信すると（＃５３）、必要に応じて条件情報８（図５、図６、図７、図１３参照）を更新した後（＃５４）、予約を受け付けることができるか否かを判別する（＃５５）。つまり、最新の顧客の位置が所定の領域に含まれかつその顧客の自動車の車種に合った駐車スペースが空いているか否かを判別する。
【００８０】
受け付けることができると判別された場合は（＃５５でＹｅｓ）、本予約が可能になった旨のメッセージを端末装置５に対して送信する（＃５７）。すると、端末装置５には、図１９に示すような本予約確認画面ＨＧ３が表示される（図１６の＃１０６でＹｅｓ、＃１０７）。
【００８１】
顧客は、本予約を所望する場合は、予約ボタンＢＮ５を押す。すると、予約受付システム２は、駐車場利用管理システム３に対して予約の登録の依頼を行う（図１７の＃５６）。これにより、駐車場利用管理システム３において、係る予約のレコード（予約情報７５）が図１０に示す予約テーブルＴＬ３に登録される。登録後、その予約に対応する、仮予約テーブルに登録されていたレコードは削除される。なお、中止ボタンＢＮ６が押された場合は、予約の要求がキャンセルされたものとみなし、本予約の登録は行わない。
【００８２】
受け付けることができないと判別された場合は（＃５５でＮｏ）、その旨を端末装置５に通知する（＃５８）。このとき、端末装置５は、まだ本予約が受け付けられていない旨を必要に応じて表示し（図１６の＃１０７）、ステップ＃１０３からの処理をやり直す（＃１０８でＮｏ）。予約受付システム２は、所定の時間ごとに端末装置５から送信されてくる新たな位置情報７２を待ち、図１７に示すステップ＃５３〜＃５５の処理を繰り返す。つまり、受け付けることができると判別されるまでの間、定期的に位置情報７２を取得し直し、本予約の受付の可否の判断を繰り返し行う。
【００８３】
なお、端末装置５において、所定の時間が経過しても予約受付システム２からの応答がない場合は、タイムアウトとみなし（図１６の＃１０６でＮｏ、＃１０７でＹｅｓ）、予約の要求を中止する。
【００８４】
本実施形態によると、駐車場の利用の希望が強い顧客を仮予約によってキープすることができるので、第一の実施形態の場合よりもさらに効率的に顧客の確保を図ることができる。
【００８５】
第一および第二の実施形態では、駐車場データベース３Ｄ１、予約情報データベース３Ｄ２を駐車場利用管理システム３に設けたが、予約受付システム２に設けてもよい。または、予約受付システム２の一部の機能を駐車場利用管理システム３に設けてもよい。
【００８６】
キャンセルの処理の実行を、利用時間の長さに応じて遅らせるようにしてもよい。例えば、基準の利用時間を１時間と定めておき、利用時間が２時間増えるごとに１０分ずつ遅れてキャンセルの処理を実行するようにしてもよい。
【００８７】
第一および第二の実施形態では、駐車場の予約の受付処理を行う場合の予約システム１を例に説明したが、この予約システム１を、カラオケ店の部屋、数に限りのある商品の取置きサービス、または貸しオフィスに設置されたパソコンやコピー機などのＯＡ機器、または美容院の順番など、種々の予約の受付処理に適用することが可能である。
【００８８】
予約受付システム２を複数の駐車場の予約の受付処理のために用いてもよい。この場合は、駐車場ごとに駐車場利用管理システム３を設けておく。予約受付システム２には、駐車場ごとの条件情報８（図５、図６、図７、および図１３参照）を設けるなどして、予約を受け付けてもよいか否かの条件を決めておく。顧客は、予約の要求を行う際に、所望する駐車場を予約受付システム２に対して指定する。そして、予約受付システム２は、指定された駐車場の条件情報８に基づいて予約の受付処理を行う。
【００８９】
図９の予約画面ＨＧ１において、顧客（ユーザ）は自分のユーザＩＤなどを指定して予約の要求を行ったが、ユーザ登録されていない顧客の場合はユーザＩＤなどの代わりに自分の自動車の車両ナンバーおよび端末装置５の電子メールアドレスなどを指定して予約の要求を行うようにしてもよい。
【００９０】
その他、予約システム１、予約受付システム２、駐車場利用管理システム３、端末装置５の全体または各部の構成、データベースの内容、画面の構成、処理内容、処理順序、判別に用いる条件などは、本発明の趣旨に沿って適宜変更することができる。
（付記１）サービスの提供を受けたい旨の要求を受け付ける要求受付手段と、
前記要求を行った顧客の現在地を示す現在地情報を取得する現在地情報取得手段と、
前記サービスの提供場所の周囲の所定の領域を定める領域情報を記憶する領域情報記憶手段と、
前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を前記現在地情報および前記領域情報に基づいて行う存否判別手段と、
前記要求を行った顧客が前記所定の領域の中にいると判別された場合は当該要求に係る前記サービスの予約を受け付けるための処理である予約受付処理を行い、当該顧客が前記所定の領域の中にいないと判別された場合は前記予約受付処理を行わない、予約受付処理手段と、
を有してなることを特徴とする予約受付システム。
（付記２）前記サービスの提供が可能な数量に関する提供数量情報を取得する提供数量情報取得手段を有し、
前記領域情報は、前記数量について示すパラメータを有し、当該パラメータが示す前記数量が大きいほど前記所定の領域を広い領域に定め、
前記存否判別手段は、前記判別を、前記提供数量情報に示される前記数量および前記領域情報に基づいて定められる領域の中に前記要求を行った顧客がいるか否かを判別することによって行う、
付記１記載の予約受付システム。
（付記３）前記要求受付手段は、前記要求を、前記サービスの提供を受ける所望の時間の指定とともに受け付け、
前記領域情報は、時間について示すパラメータを有し、当該パラメータが示す時間が長いほど前記所定の領域を広い領域に定め、
前記存否判別手段は、前記判別を、前記指定に係る時間および前記領域情報に基づいて定められる領域の中に前記要求を行った顧客がいるか否かを判別することによって行う、
付記１記載の予約受付システム。
（付記４）前記要求を行った顧客が前記所定の領域の中にいない旨の結果が前記判別によって得られた後で、当該顧客から仮予約の依頼を受けた場合に、
前記現在地情報取得手段は、当該顧客の前記現在地情報を新たに取得し、
前記存否判別手段は、新たに取得された前記現在地情報に基づいて前記判別を新たに行い、
前記予約受付処理手段は、新たに行われた前記判別によって当該顧客が前記所定の領域の中にいると判別される場合に前記予約受付処理を行う、
付記１ないし付記３のいずれかに記載の予約受付システム。
（付記５）前記予約受付処理がなされた前記予約に係る前記要求を行った顧客が前記提供場所に到着する到着時刻を予測する到着時刻予測手段と、
前記要求を行った顧客が予測された前記到着時刻までに到着するか否かを、当該到着時刻、現在の時刻、および前記予約受付処理がなされた後で新たに取得された当該顧客の前記現在地情報に基づいて判別する、到着可否判別手段と、
前記要求を行った顧客が予測された前記到着時刻までに到着しないと判別された場合に、当該要求についての前記予約をキャンセルするための処理を行うキャンセル処理手段と、
を有してなる付記１ないし付記４のいずれかに記載の予約受付システム。
（付記６）駐車場の予約を受け付ける予約受付システムであって、
前記駐車場に自動車を駐車したい旨の要求を受け付ける要求受付手段と、
前記要求を行った顧客の現在地を示す現在地情報を取得する現在地情報取得手段と、
前記駐車場の周囲の所定の領域を定める領域情報を記憶する領域情報記憶手段と、
前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を前記現在地情報および前記領域情報に基づいて行う存否判別手段と、
前記要求を行った顧客が前記所定の領域の中にいると判別された場合は当該顧客のために前記駐車場の予約を受け付けるための予約受付処理を行い、当該顧客が前記所定の領域の中にいないと判別された場合は前記予約受付処理を行わない、予約受付処理手段と、
を有してなることを特徴とする予約受付システム。
（付記７）情報提供手段より発信される、前記駐車場の周辺または前記要求を行った顧客の周辺の交通情報を取得する交通情報取得手段と、
取得された前記交通情報に基づいて、前記駐車場の今後の需要の予測を行う需要予測手段と、を有し、
前記領域情報は、前記需要の量について示すパラメータを有し、当該パラメータが示す量が少ないほど前記所定の領域を広い領域に定め、
前記存否判別手段は、前記判別を、予測された前記需要および前記領域情報に基づいて定められる領域の中に前記要求を行った顧客がいるか否かを判別することによって行う、
付記６記載の予約受付システム。
（付記８）
予約の受付を行うコンピュータに用いられるコンピュータプログラムであって、
サービスの提供を受けたい旨の要求を受け付ける処理と、
前記要求を行った顧客の現在地を示す現在地情報を取得する処理と、
前記サービスの提供場所の周囲の所定の領域を定める領域情報を領域情報記憶手段より取得する処理と、
前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を前記現在地情報および前記領域情報に基づいて行う処理と、
を前記コンピュータに実行させ、
前記要求を行った顧客が前記所定の領域の中にいると判別された場合に、当該要求に係る前記サービスを提供するための予約を受け付けるための処理を前記コンピュータに実行させる、
ことを特徴とするコンピュータプログラム。
【００９１】
【発明の効果】
本発明によると、駐車スペースなどのリソースを有する運営者にとって、リソースが効率よく用いられるように顧客からの予約の受付を行うことができる。
【図面の簡単な説明】
【図１】本発明に係る予約受付システムを有するシステム全体の構成の例を示す図である。
【図２】予約受付システムのハードウェア構成の例を示す図である。
【図３】予約受付システムおよび駐車場利用管理システムの機能的構成の例を示す図である。
【図４】顧客テーブルの例を示す図である。
【図５】領域条件情報の例を示す図である。
【図６】距離条件情報の例を示す図である。
【図７】時間条件情報の例を示す図である。
【図８】駐車スペーステーブルの例を示す図である。
【図９】予約画面の例を示す図である。
【図１０】予約テーブルの例を示す図である。
【図１１】予約の要求を行う際の端末装置の処理の流れの例を説明するフローチャートである。
【図１２】予約の要求の受付を行う際の予約受付システムの処理の流れの例を説明するフローチャートである。
【図１３】変更情報テーブルの例を示す図である。
【図１４】キャンセルの処理を行う際の予約受付システムの処理の流れの例を説明するフローチャートである。
【図１５】仮予約の要求を行う際の端末装置の処理の流れの例を説明するフローチャートである。
【図１６】仮予約時処理の流れの例を説明するフローチャートである。
【図１７】仮予約の要求の受付を行う際の予約受付システムの処理の流れの例を説明するフローチャートである。
【図１８】仮予約確認画面の例を示す図である。
【図１９】本予約確認画面の例を示す図である。
【符号の説明】
２ 予約受付システム
７２ 位置情報（現在地情報）
７３ 利用状況情報（提供数量情報）
８１ 領域条件情報（領域情報）
８２ 距離条件情報（領域情報）
８３ 時間条件情報（領域情報）
２０１ 予約要求受信部（要求受付手段）
２０２ 位置情報受信部（現在地情報取得手段）
２０３ 存否判別部（存否判別手段）
２０５ 予約受付処理部（予約受付処理手段）
２０６ 利用状況取得部（提供数量情報取得手段）
２０７ キャンセル処理部（キャンセル処理手段）
２０８ 交通情報取得部（交通情報取得手段）
２７１ 到着時刻予測部（到着時刻予測手段）
２７２ 到着可否判別部（到着可否判別手段）
２Ｄ１ 受付条件データベース（領域情報記憶手段）
ＴＬ８ａ〜ＴＬ８ｄ 変更情報テーブル（領域情報）

Claims (8)

1. サービスの今後の需要の量について示すパラメータを有しかつ前記サービスの提供場所の周囲の所定の領域を前記パラメータが示す量が少ないほど広い領域に定める領域情報を記憶する領域情報記憶手段と、
   顧客が使用する端末装置から、前記サービスの提供を受けたい旨の要求を、通信回線を介して受け付ける、要求受付手段と、
   前記要求を行った顧客の現在地を示す現在地情報を、通信回線を介して取得する、現在地情報取得手段と、
   情報提供手段より発信される、前記サービスの提供場所周辺または前記要求を行った顧客の周辺の交通情報を、通信回線を介して取得する、交通情報取得手段と、
   前記交通情報取得手段によって取得された前記交通情報に基づいて所定の関数によって前記需要の量の予測を行う需要予測手段と、
   前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を、前記需要予測手段によって予測された前記需要の量と前記領域情報記憶手段に記憶されている前記領域情報とによって定められる領域に前記現在地情報に示される当該顧客の現在地が属するか否かを判別することによって行う、存否判別手段と、
   前記要求を行った顧客が前記所定の領域の中にいると判別された場合は当該要求に係る前記サービスの予約を受け付けるための処理である予約受付処理を行い、当該顧客が前記所定の領域の中にいないと判別された場合は前記予約受付処理を行わない、予約受付処理手段と、
   を有してなることを特徴とする予約受付システム。
2. 前記要求を行った顧客が前記所定の領域の中にいない旨の結果が前記判別によって得られた後で、当該顧客から仮予約の依頼を受けた場合に、
   前記現在地情報取得手段は、当該顧客の前記現在地情報を新たに取得し、
   前記存否判別手段は、新たに取得された前記現在地情報に基づいて前記判別を新たに行い、
   前記予約受付処理手段は、新たに行われた前記判別によって当該顧客が前記所定の領域の中にいると判別される場合に前記予約受付処理を行う、
   請求項１記載の予約受付システム。
3. 前記予約受付処理がなされた前記予約に係る前記要求を行った顧客が前記提供場所に到着する到着時刻を予測する到着時刻予測手段と、
   前記要求を行った顧客が予測された前記到着時刻までに到着するか否かを、当該到着時刻、現在の時刻、および前記予約受付処理がなされた後で新たに取得された当該顧客の前記現在地情報に基づいて判別する、到着可否判別手段と、
   前記要求を行った顧客が予測された前記到着時刻までに到着しないと判別された場合に、当該要求についての前記予約をキャンセルするための処理を行うキャンセル処理手段と、
   を有してなる請求項１または請求項２記載の予約受付システム。
4. 駐車場の予約を受け付ける予約受付システムであって、
   前記駐車場の今後の需要の量について示すパラメータを有しかつ前記駐車場の周囲の所定の領域を前記パラメータが示す量が少ないほど広い領域に定める領域情報を記憶する領域情報記憶手段と、
   顧客が使用する端末装置から、前記駐車場に自動車を駐車したい旨の要求を、通信回線を介して受け付ける、要求受付手段と、
   前記要求を行った顧客の現在地を示す現在地情報を、通信回線を介して取得する、現在地情報取得手段と、
   情報提供手段より発信される、前記駐車場の周辺または前記要求を行った顧客の周辺の交通情報を、通信回線を介して取得する、交通情報取得手段と、
   前記交通情報取得手段によって取得された前記交通情報に基づいて所定の関数によって前記需要の量を予測を行う需要予測手段と、
   前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を、前記需要予測手段によって予測された前記需要と前記領域情報記憶手段に記憶されている前記領域情報とによって定められる領域に前記現在地情報に示される当該顧客の現在地が属するか否かを判別することによって行う、存否判別手段と、
   前記要求を行った顧客が前記所定の領域の中にいると判別された場合は当該顧客のために前記駐車場の予約を受け付けるための予約受付処理を行い、当該顧客が前記所定の領域の中にいないと判別された場合は前記予約受付処理を行わない、予約受付処理手段と、
   を有してなることを特徴とする予約受付システム。
5. 駐車場の予約を受け付ける予約受付システムであって、
   駐車時間について示すパラメータを有しかつ前記駐車場の周囲の所定の領域を当該パラメータが示す時間が長いほど広い領域に定める領域情報を記憶する領域情報記憶手段と、
   顧客が使用する端末装置から、前記駐車場に自動車を駐車したい旨の要求を、所望の駐車時間の指定とともに通信回線を介して受け付ける、要求受付手段と、
   前記要求を行った顧客の現在地を示す現在地情報を、通信回線を介して取得する、現在地情報取得手段と、
   前記要求を行った顧客が前記所定の領域の中にいるか否かの判別を、前記要求受付手段によって受け付けられた前記指定に係る駐車時間と前記領域情報記憶手段に記憶されている前記領域情報とによって定められる領域に前記現在地情報に示される当該顧客の現在地が属するか否かを判別することによって行う、存否判別手段と、
   前記要求を行った顧客が前記所定の領域の中にいると判別された場合は当該顧客のために前記駐車場の予約を受け付けるための予約受付処理を行い、当該顧客が前記所定の領域の中にいないと判別された場合は前記予約受付処理を行わない、予約受付処理手段と、
   を有してなることを特徴とする予約受付システム。
6. 前記要求を行った顧客が前記所定の領域の中にいない旨の結果が前記判別によって得られた後で、当該顧客から仮予約の依頼を受けた場合に、
   前記現在地情報取得手段は、当該顧客の前記現在地情報を新たに取得し、
   前記存否判別手段は、新たに取得された前記現在地情報に基づいて前記判別を新たに行い、
   前記予約受付処理手段は、新たに行われた前記判別によって当該顧客が前記所定の領域の中にいると判別される場合に前記予約受付処理を行う、
   請求項４または請求項５記載の予約受付システム。
7. 前記予約受付処理がなされた前記予約に係る前記要求を行った顧客が前記駐車場に到着する到着時刻を予測する到着時刻予測手段と、
   前記要求を行った顧客が予測された前記到着時刻までに到着するか否かを、当該到着時刻、現在の時刻、および前記予約受付処理がなされた後で新たに取得された当該顧客の前記現在地情報に基づいて判別する、到着可否判別手段と、
   前記要求を行った顧客が予測された前記到着時刻までに到着しないと判別された場合に、当該要求についての前記予約をキャンセルするための処理を行うキャンセル処理手段と、
   を有してなる請求項４ないし請求項６のいずれかに記載の予約受付システム。
8. 予約の受付を行うコンピュータに用いられるコンピュータプログラムであって、
   サービスの今後の需要の量について示すパラメータを有しかつ前記サービスの提供場所の周囲の所定の領域を前記パラメータが示す量が少ないほど広い領域に定める領域情報を有する前記コンピュータに、
   顧客が使用する端末装置から、前記サービスの提供を受けたい旨の要求を、通信回線を介して受け付ける処理を実行させ、
   前記要求を行った顧客の現在地を示す現在地情報を、通信回線を介して取得する処理を実行させ、
   情報提供手段より発信される、前記サービスの提供場所周辺または前記要求を行った顧客の周辺の交通情報を、通信回線を介して取得する処理を実行させ、
   取得した前記交通情報に基づいて所定の関数によって前記需要の量の予測を行う処理を実行させ、
   前記要求を行った顧客が前記所定の領域の中にいるか否かの判別の処理を、予測した前記需要の量と前記領域情報とによって定められる領域に前記現在地情報に示される当該顧客の現在地が属するか否かを判別することによって実行させ、
   前記要求を行った顧客が前記所定の領域の中にいると判別した場合に、当該要求に係る前記サービスの予約を受け付けるための処理を実行させる、
   ことを特徴とするコンピュータプログラム。

Images