JP2018156197A - 駐車場予約仲介サーバ、駐車場サーバおよびコンピュータプログラム - Google Patents

Abstract

【課題】 仲介サーバを介しての駐車場を簡単に検索し、駐車場の予約を完了させることが可能な技術を提供する。【解決手段】 駐車場データベースにおける各種データをユーザに係る端末で閲覧可能とする閲覧化手段と、所定の車室を特定した詳細データ要請をユーザ端末から受信する詳細要請送受信手段と、その詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得して前記のユーザ端末へを送信する最新データ送受信手段と、予約打診データを受信して予約が可能か否かを駐車場データベースへ打診する予約送受信手段と、予約可否を前記の駐車場データベースから受信して前記のユーザ端末へ送信する予約可否送受信手段と、備える。前記の閲覧化手段は、前記の最新データ送受信手段が受信した最新データをも閲覧可能とする。【選択図】 図２

Description

本発明は、駐車場の貸し出しをしている業者と駐車場を探しているユーザとを仲介し、駐車場を予約できるようにするための情報処理装置およびコンピュータプログラムに関する。

特許文献１には、以下のような技術が開示されている。すなわち、不動産会社が所有している月極駐車場に対する時間や一日単位などの賃貸や、及び月極契約者による転貸を目的として、駐車場の賃貸及びタイムシェアの案内、予約、および電子認証、利用料金の決済を行うための技術である。

特許文献２には、法人の社員用駐車場は、週末（土曜日及び日曜日）や祝日は殆ど使用されておらず、個人の駐車場でも、特定の曜日又は時間帯によって空きがある場合がある点を改善する技術が開示されている。すなわち、手間をかけずに空き駐車場の使用率を向上させることができるようにした駐車場紹介システムが開示されている。

特許文献３には、車両駐車スペースを効率よく活用し、ユーザにとってもオーナーにとっても利便性の高い車両駐車スペースの管理を実現するための技術が開示されている。

特開２００６−２９３９５６号公報 特開２００３−３０６９１号公報 特開２００３−１６５９０号公報

貸し出しに関する管理対象である駐車場について、仲介業者が存在することで、最終的な提供可能な駐車場数が多くなってきた場合に、全てのデータが最新状態であるためには、高い頻度でのデータ更新が必要となる。
一方、駐車場を探しているユーザとしては、最新状態のデータでないと、閲覧したのに予約はできない、といったこととなり、使い勝手が悪くなる。
閲覧や検索に供するデータを高い頻度でデータ更新するのは、ハードウェアへの負荷、通信インフラへの負荷が大きくなる。その負荷を負担しつつビジネス展開しようとすれば、サービスの運営コストが高くなり、ユーザへ利便性を提供できなくなる。

本発明が解決すべき課題は、仲介サーバを介しての駐車場を簡単に検索し、駐車場の予約を完了させることが可能な技術を提供することにある。

前述した課題を解決するため、本願発明者は、駐車場管理サーバ、駐車場予約仲介サーバ、およびその駐車場管理サーバや駐車場予約仲介サーバを制御するコンピュータプログラムを提供する。

（第一の発明）
第一の発明は、多数の駐車場の満空データを蓄積する駐車場データベースの各種データを、ユーザの閲覧に供するための駐車場予約仲介サーバに係る。
すなわち、前記の駐車場データベースから提供された各種データを蓄積する車室データベースと、
その車室データベースに蓄積される各種データをユーザに係る端末で閲覧可能とする閲覧化手段と、
その閲覧化手段にて閲覧可能な各種データをユーザが自らに係るユーザ端末が閲覧して所定の車室を特定した詳細データ要請を受信する詳細要請送受信手段と、
その詳細要請送受信手段が受信した詳細データ要請に係る車室に関する最新データ（たとえば、最新の満／空データ）を前記の駐車場データベースから取得して前記のユーザ端末へ最新データを送信する最新データ送受信手段と、
前記のユーザ端末から所定の車室の駐車予約に必要な所定の予約打診データを受信するとともにその予約打診データによって予約が可能か否かを前記の駐車場データベースへ打診する予約送受信手段と、
その予約送受信手段が打診した結果である予約可否を前記の駐車場データベースから受信して前記のユーザ端末へ送信する予約可否送受信手段と、
を備える（図２参照）。
前記の閲覧化手段は、前記の最新データ送受信手段が受信した最新データをも閲覧可能とする（図４参照）。

（用語説明）
「駐車場データベース」には、駐車場データベースの運営者に対して、自らに係る駐車場の管理（貸し出しや料金徴収など）を委託した駐車場オーナーから提供された駐車場（または車室）に関する住所や場所、駐車料金、貸し出し可能時間などのデータが格納されている。
「駐車場」は、単数または複数の「車室」からなる。ユーザが予約をするのは、「車室」が一単位となっている。駐車場サーバにおいては「駐車場データベース」、駐車場予約仲介サーバにおいては「車室データベース」と使い分けているが、データベースとしての区別を明確にするためであり、予約単位が「車室ごと」である点は変わらない。
「駐車場サーバ」は、カーシェアリング管理サーバ、レンタカー管理サーバなどを含むこととしてもよい。たとえば、駐車場サーバがカーシェアリング管理サーバである場合、本願に係る駐車場予約仲介サーバは、実質的にはカーシェアリング予約仲介サーバとして機能することとなる（図１２参照）。
「ユーザ端末」とは、携帯通信端末、通信機能を備えたパーソナルコンピュータ、通信機能を備えたカーナビゲーション装置などである。
「最新データ」は、予約が入っている「満」、予約が入っていない「空」に関する「満／空データ」が一般的であるが、所定の車室について貸し出しを停止した、といったデータが最新データとなる場合もある。

（作用）
閲覧化手段は、駐車場データベースにおける各種データをユーザ端末で閲覧可能とする。
ユーザ端末にて各種データを閲覧したユーザがユーザ端末へ所定の車室を特定するために入力（タップ、クリックなどで指定）して送信した詳細データ要請を、詳細要請送受信手段が受信する。そして、その詳細データ要請を駐車場データベースへ送信する。
駐車場データベースでは、その詳細データ要請に係る車室の最新データを抽出し、最新データ送受信手段へ送信する。その最新データ送受信手段は、ユーザ端末へ最新データを送信する。
ユーザ端末においては、その最新データに基づいた閲覧が可能となる。そのユーザ端末を閲覧し、希望に合う車室であると判断したユーザは、その車室の駐車予約に必要な所定の予約打診データを送信する。その予約打診データは、予約送受信手段が受信する。そして、その予約打診データによって予約が可能か否かは、駐車場データベースの最新データを要求して確認する。
予約送受信手段が確認した結果は、予約可否送受信手段が駐車場データベースから受信し、前記のユーザ端末へ送信する。

前記の閲覧化手段は、詳細データ要請に係る車室のデータについて、駐車場データベースへアクセスして最新状態としてから当該ユーザ端末での出力が可能となる。したがって、駐車場データベースにおける各種データが更新されるたびに、閲覧化手段においても各種データを閲覧可能とする必要がない。一方、閲覧するユーザにとっては、閲覧するデータについては、最新のデータが閲覧対象となるので、実用上に問題はない。
その結果、ハードウェアや通信インフラへの負担が軽減できる。

（第一の発明のバリエーション）
第一の発明は、駐車場データベースが物理的に複数存在することとしてもよい。
駐車場予約仲介サーバは、それら複数の駐車場データベースを用いて、ユーザ端末からの駐車場予約を仲介する。

（第二の発明）
第二の発明は、多数の駐車場に関する満空データを含む駐車場の各種データを、駐車場予約仲介サーバを介してユーザの閲覧に供するための駐車場サーバに係る。
すなわち、多数の駐車場に関する各種データを前記の駐車場予約仲介サーバへ提供可能な駐車場データベースと、
所定の車室を特定した詳細データ要請を前記のユーザ端末から受信した駐車場予約仲介サーバを介して前記の詳細データ要請を受信する詳細要請受信手段と、
その詳細要請受信手段が受信した詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ前記の最新データを送信する最新データ送信手段と、
所定の車室の駐車予約に必要な所定の予約打診データを前記のユーザ端末から駐車場予約仲介サーバを介して受信する予約受信手段と、
その予約受信手段が受信した予約打診データに係る車室に関する最新データを前記の駐車場データベースから取得して予約可否を判断するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ予約可否を送信する予約可否送信手段と、
を備える（図２、４参照）。

（作用）
仲介サーバにてユーザに係るユーザ端末で閲覧可能とするため、当該駐車場予約仲介サーバへ多数の駐車場に関する各種データを駐車場データベースが提供する。
所定の車室を特定した詳細データ要請を前記のユーザ端末から駐車場予約仲介サーバが受信し、その駐車場予約仲介サーバを介して前記の詳細データ要請を詳細要請受信手段が受信する。 その詳細データ要請に係る車室に関する最新データを、最新データ送信手段が前記の駐車場データベースから取得し、駐車場予約仲介サーバを介して前記のユーザ端末へ前記の最新データを送信する。
所定の車室の駐車予約に必要な所定の予約打診データを、予約受信手段が前記のユーザ端末から駐車場予約仲介サーバを介して受信する。予約打診データに係る車室に関する最新データを、予約可否送信手段が前記の駐車場データベースから取得し、駐車場予約仲介サーバを介して前記のユーザ端末へ予約の可否を送信する。

（第二の発明のバリエーション）
第二の発明は、前記の駐車場予約仲介サーバが物理的に複数存在することとしてもよい。
駐車場サーバは、複数の駐車場予約仲介サーバを介して、ユーザ端末からの駐車場の予約を受け付ける。

（第三の発明）
第三の発明は、多数の駐車場に関する満空データを蓄積する駐車場データベースから提供されて蓄積した車室データベースの各種データを、ユーザの閲覧に供するための駐車場予約仲介サーバを制御するコンピュータプログラムに係る。
そのコンピュータプログラムは、前記の駐車場データベースにおける各種データを前記の車室データベースへ蓄積するデータ蓄積手順と、
そのデータ蓄積手順にて蓄積された各種データをユーザに係る端末で閲覧可能とする閲覧化手順と、
その閲覧化手順にて閲覧可能なデータをユーザが自らに係るユーザ端末が閲覧して所定の車室を特定した詳細データ要請を受信する詳細要請送受信手順と、
その詳細要請送受信手順にて受信した詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得して前記のユーザ端末へ最新データを送信する最新データ送受信手順と、
前記のユーザ端末から所定の車室の駐車予約に必要な所定の予約打診データを受信するとともにその予約打診データによって予約が可能か否かを前記の駐車場データベースへ打診する予約送受信手順と、
その予約送受信手順にて打診した結果である予約可否を前記の駐車場データベースから受信して前記のユーザ端末へ送信する予約可否送受信手順と
前記の最新データ送受信手順において受信した最新データを閲覧可能であるように前記の車室データベースへ蓄積する最新データ閲覧化手順と、
を実行させるように駐車場予約仲介サーバを制御する。

（第四の発明）
第四の発明は、多数の駐車場に関する満空データを含む駐車場の各種データを、駐車場予約仲介サーバを介してユーザの閲覧に供するための駐車場サーバを制御するためのコンピュータプログラムに係る。
そのプログラムは、多数の駐車場に関する各種データを予め駐車場データベースへ蓄積するデータ蓄積手順と、
そのデータ蓄積手順にて蓄積された各種データをユーザに係る端末で閲覧可能とするために前記の駐車場予約仲介サーバへ送信するデータ送信手順と、
所定の車室を特定した詳細データ要請を前記のユーザ端末から受信した駐車場予約仲介サーバを介して前記の詳細データ要請を受信する詳細要請受信手順と、
その詳細要請受信手順にて受信した詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ前記の最新データを送信する最新データ送信手順と、
所定の車室の駐車予約に必要な所定の予約打診データを前記のユーザ端末から駐車場予約仲介サーバを介して受信する予約受信手順と、
その予約受信手順にて受信した予約打診データに係る車室に関する最新データを前記の駐車場データベースから取得して予約可否を判断するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ予約可否を送信する予約可否送信手順と、
駐車場サーバに実行させるように制御する。

（コンピュータプログラムの発明）
第三および第四の発明に係るコンピュータプログラムは、記録媒体に格納して配布すること、および通信設備を介して送信することによって配布することが可能である。

第一および第三の発明によれば、仲介サーバを介しての駐車場を簡単に検索し、駐車場の予約を完了させることが可能な仲介サーバおよびその制御プログラムを提供することができた。
また、仲介サーバを使った駐車場管理サーバにおいて、駐車場を簡単に検索し、駐車場の予約を完了させることが可能な駐車場管理サーバおよびその制御プログラムを提供することができた。

本願発明の全体構成を示すブロック図である。 本願発明の第一の実施形態に係る主要構成を示すブロック図である。 駐車場サーバからのデータ提供から仲介サーバにおける閲覧可能化までの手順を説明する概念図である。 駐車場ユーザによる駐車場物件の閲覧から空き車室の判定までの手順を説明する概念図である。 駐車場ユーザによる駐車場物件の予約打診から予約完了までの手順を説明する概念図である。 駐車場ユーザによる駐車場物件の予約打診をしたものの、予約が失敗となった場合を説明する概念図である。 所定の車室について、公開／非公開の制御について説明するための概念図である。 データベースの同期について説明する概念図である。 複数の駐車場サーバが一つの仲介サーバを利用する場合示す概念図である。 一つの駐車場サーバが複数の仲介サーバを利用する場合示す概念図である。 複数の仲介サーバを統合する仲介サーバが存在する場合を示す概念図である。 本願発明の概念を、カーシェアリング予約仲介サーバとして機能させることを示す概念図である。 ユーザ端末において駐車場を検索する携帯端末における初期画面の一例を示す概念図である。 本願発明における第二の実施形態に係る主要構成を示すブロック図である。 本願発明における第三の実施形態に係る主要構成を示すブロック図である。

本願発明を実施する形態について、図１から図１２を用いて説明する。また、運転者による操作を含めた車載端末および駐車場管理サーバにおける動作、ソフトウェアについても併せて説明する。

以下の実施形態においては、駐車場の提供サービスを前提として説明するが、本発明は駐車場提供サービスに限らない。たとえば、カーシェアリングサービス、レンタカーサービスでも提供可能である（図１２参照）。更に、会議室、不動産などのレンタル予約システムにおいても、本発明は応用可能である。
カーシェアリングを利用する利用者は、カーシェアリングの会員登録を済ませ、カーシェアリング用の自動車を確保している駐車場に出向いて直接利用する。または、携帯電話やパーソナルコンピュータを用いて利用予定の時間帯などを事前に連絡する予約制度を活用する。

（図１）
図１は、駐車場の時間貸しにおけるユーザの閲覧や予約を実現するためのユーザ端末、駐車場サーバ、および駐車場予約仲介サーバ（以下、「仲介サーバ」と略記する）における情報の授受を示したものである。図中に示した括弧書きの数字は、情報授受の順番を示している。また、図中の「ＤＢ」は、データベースを示す。
駐車場を管理している駐車場サーバは、多数の駐車場に関する満空情報、予約情報などを蓄積した駐車場データベースを管理している。

一方、仲介サーバにおいては、空いている車室に関するデータを蓄積する車室データベースを管理している。前記の駐車場サーバは、その駐車場データベースから車室データベースへ検索、閲覧、予約の対象となる駐車場に関するデータを提供する（１）。
仲介サーバは、駐車場を探すユーザからのアクセスがあった場合には、空いている車室の検索や車室に関する各種データの閲覧を可能としている（２）。

駐車場を探すユーザは、自らに係る端末（図中では、「ユーザ端末」と表示）を用いて、仲介サーバが提供する閲覧サイトへアクセスし、駐車場が必要な場所、日時、台数などの検索条件を入力して閲覧する（２）。
条件に合った駐車場が見つかって予約をする場合、予約に必要な情報を登録する（３）。仲介サーバは、予約内容を登録して予約を実行する（４）。

ユーザが予約をキャンセルする場合、自らの端末のキャンセル手段から予約取消しを、仲介サーバへ送信する（５）。キャンセルに係るデータは、仲介サーバから駐車場サーバへ送信され、予約の取消しが駐車場データベースへ登録される（６）。

駐車場サーバにおいて、所定の駐車場が使えなくなったり、新たに貸し出しが可能となった車室が増えたり、といったデータの更新がなされることがある。そうした更新データは、駐車場データベースから仲介サーバの車室データベースへ送信され、データの同期が図られる（７）。

（図２）
図２を用いて、上述した（１）〜（４）までが、各ハードウェアのどのような手段に基づいて実行されているかを説明する。なお、図２においては、図１よりも細かいステップとなるので、括弧書きの数字は一致しない。

駐車場サーバは、貸し出し対象となる車室についてのデータを仲介サーバへ提供する（１）。そのデータは、車室ごとに住所、空いている時間帯、広さなどの情報が含まれている（図３参照）。
仲介サーバにおいては、閲覧化手段を用いて提供されたデータを駐車場ユーザが閲覧したり、検索したりできるように準備する。

駐車場を予約したいと考えるユーザは、自らの端末（以下、「ユーザ端末」）を用いて仲介サーバへアクセスし、閲覧手段（操作画面など）を用いて閲覧する（２）。検索や閲覧が便利であるように、ユーザ端末においては、仲介サーバが用意した「駐車場検索アプリケーション」を予めダウンロードしておいてもよい。
ユーザは、ユーザ端末を用いて、駐車場を必要とする場所、時間帯などの検索条件を入力し、予約できそうな駐車場を検索し、閲覧する（２）。閲覧の初期画面については、図１３を用いて後述する。

ユーザ端末の出力画面には、地図およびその地図上に存在する駐車場を示すアイコンが表示される。
詳細を知りたい駐車場については、そのアイコン（一の車室）をユーザがタップする（３）。この操作を実行する手段を、便宜的に「詳細データ要請手段」として図示している。ユーザが閲覧している端末が画面タッチ対応ではない場合、ポインタを合わせてクリックする、という操作となる。

タップした車室アイコンに対応する車室については、仲介サーバにおける詳細要請送受信手段がその車室を指定して詳細データを要請された旨を駐車場サーバへ送信する。送信された駐車場サーバでは、詳細要請受信手段が受信し、駐車場データベースから最新データ（満／空データ）を引き出す（４）。そして、その最新データを、最新データ送信手段が仲介サーバへ送信する。

仲介サーバにおいては、最新データを最新データ送受信手段が受信し、ユーザ端末へ転送する（５）。
ユーザ端末においては、最新の満／空データが反映された車室についての詳細データが出力される。
なお、最新データは、車室データベースにおける対応する車室データの更新にも用いる（破線で示した矢印における（５）にて示しており、（５）としたのは、満空の返却とデータ更新が同時という趣旨である）。

詳細データを出力した車室がユーザの希望にかなう時間帯において空いており、ユーザが予約を決意したら、予約送信手段を用いて予約日時や駐車予定の車種などのデータを入力し、予約打診データとして仲介サーバへ送信する（６）。
予約打診データは、仲介サーバにおける予約送受信手段が受信し、駐車場サーバへ転送する。

転送された予約打診データは、駐車場サーバにおける予約受信手段が受信する。そして、駐車場サーバでは、転送された予約打診データが予約可能かどうか、その時点での最新データを再び駐車場データベースから取得して判断する。
判断結果（予約の可否）について、予約可否送信手段が仲介サーバへ送信する。この判断結果が予約可能である場合には、駐車場データベースに対して予約を登録する（７）。すなわち、予約打診に係る車室における予約日時については、「空」を「満」に変更する。

仲介サーバへ送信された予約可否については、予約可否送受信手段が受信し、予約が可能であった場合には予約が完了した旨（予約済み）、予約ができなかった場合にはその旨をユーザ端末へ送信する（８）。
なお、詳細データとして「満／空」のデータを受け取ったユーザが、「空」を選んで予約打診データを送信しているにも関わらず、予約ができない場合というのは、他のユーザが一瞬早く、その車室に対する重なる時間帯での予約打診があり、予約が登録される場合が代表的である。

なお、予約が登録された車室についての最新データは、すぐに仲介サーバへ送信することはない。通信総量を抑えるためである。たとえば、ある車室についての予約が登録された車室について、別のユーザ端末から詳細データ要請があるまでは、仲介サーバの車室データベースは更新されない。
しかし、車室データベースを閲覧するユーザとしては、詳細データを要請することで閲覧に供するデータは、最新データとなるので、何ら問題とはならない。別のユーザ端末から詳細データ要請があれば、その詳細データ要請に対応して最新データがユーザ端末へ送信されるからである。

（図３）
図３を用いて、駐車場サーバからのデータ提供から仲介サーバにおける閲覧可能化までの手順を詳述する。
まず、駐車場サーバから、仲介サーバへ貸し出し可能な車室に関するデータ（住所、空き日時、料金など）を最新のものに更新してから提供するために送信し、ファイル連携の準備を実行する。
提供されたデータは、仲介サーバの管理者が内容を確認したり、料金を設定したりするなどして、車室データベースへ格納し、駐車場ユーザの端末から閲覧や検索が可能な状態とする。
閲覧可能なデータは、駐車場ユーザが自らの端末を用いて検索などした場合、その端末の出力画面へ、検索結果に該当する車室に関するデータが地図とともに出力される。

（図４）
図４を用いて、駐車場ユーザによる駐車場物件の閲覧から空き車室の判定までの手順を詳述する。
駐車場ユーザは、自らの端末にて所望する駐車場を検索する。すると仲介サーバの車室データベースへアクセスし、検索条件に合致した物件が地図とともに出力される。端末の画面へ出力された物件についての詳細情報を得たい場合、その物件を表示するアイコンを画面タッチする（詳細データ要請）。

タッチされた物件に関しては、仲介サーバが駐車場サーバへアクセスして、空車室であるか否か、最新のデータを用いて確認する。そして、空車室である場合には、その旨を仲介サーバへ返信する。このとき、最新の満空情報についてのデータ全てを返信するのではなく、空車室であるか否かの照会があった車室に関するデータのみを返信する。地図上の全車室データを更新するわけではない。

図２を用いても説明したが、仲介サーバの車室データベースにおける全ての満空情報が、駐車場サーバにおける最新のデータ（駐車場データベースとの同期が取られている）とは限らない。
しかし、駐車場ユーザがアクセス（詳細データ要請）した車室に関するデータは、前述したように全て最新のデータとなるので、駐車場ユーザにとっては、全ての車室データが最新のデータであることと変わらない。このことで、駐車場サーバおよび仲介サーバにおける最新データの共有（最新データによる同期）に要する通信量やデータ処理に要するハードウェア資源の消耗を削減することができる。

図４では、駐車場ユーザによる検索が地域のみであり、予約を欲する時間帯の指定がなかったことを想定している。 この場合、ユーザが指定（タップ）した車室に関する満空情報として「本日〜１４日後までご利用可能です。」という表記を冒頭として、『「空」 ９／１（木） ９：００〜１７：００・・・「−」９／４（日） 予約不可』といった表示が、ユーザ端末へ出力される。

なお、仲介サーバにおいて、駐車場ユーザの利用履歴や料金支払い記録などのユーザデータベースが存在する場合、予約に係るユーザのデータを照合する。そして、そのユーザが利用料金を滞納しているなどの事情が判明した場合、駐車場サーバからの最新データが「空き」であったとしても、「予約不能」として、係るユーザ端末へ送信する（図１４参照）。

（図５）
図５を用いて、駐車場ユーザによる駐車場物件の予約打診から予約完了までの手順を詳述する。
駐車場ユーザが所望する車室を見つけた場合、その車室についての予約を、仲介サーバへ打診する。このとき、ユーザ名、連絡先、利用料金の支払い方法、駐車予定の車種、なども予約の意思表示と併せて送信する。なお、仲介サーバの運営主体が用意している予め会員登録を済ませておくことで、ユーザ名などの入力を省略できる。

予約に必要なデータとともに予約の意思表示を受信した仲介サーバは、それを駐車場サーバへ転送する。
駐車場サーバでは、駐車場データベースを最新のデータに更新してから、予約に係る車室の満空を判定する。判定の結果、空きであれば、他の予約を受け付けないように、その車室を確保する。そして、予約の確保が成功した旨、およびその予約をキャンセルする場合に必要な手続きなどの情報を仲介サーバへ送信する。

予約確保の成功に関するデータを受信した仲介サーバでは、その車室に関する他の予約を受け付けないように、車室データベースを更新する。また、予約の成功をユーザ端末へ送信する。
「予約の成功をユーザ端末へ送信する」とは、予約に係る車室の住所や車室番号、利用日時、利用台数、予約番号などを送信することも含む。予め会員登録をしていれば、自らが予約している他の情報などを格納したデータベース（マイページ）にも登録される。「送信」の種類としては、会員登録で登録されたメールアドレスへ電子メールにて送信することでもよい。

（図６）
図６を用いて、駐車場ユーザによる駐車場物件の予約打診をしたものの、予約が失敗となった場合を詳述する。
駐車場ユーザが所望する車室を見つけた場合、その車室についての予約を、仲介サーバへ打診し、仲介サーバがその予約を駐車場サーバへ転送するところまでは、同じである。
駐車場サーバにおいて駐車場データベースを最新のデータにしたら、当該予約と同じ車室における同じ時間帯に、別の予約（以下、「一瞬前の予約」と略記する）が完了してしまったという場合があり得る。その場合、予約に係る車室の確保に失敗した旨を、瞬前の予約に係る車室に関するデータとともに駐車場サーバが仲介サーバへ送信する。

仲介サーバにおいては、一瞬前の予約に係る車室に関する最新データを受信し、車室データベースを更新するとともに、予約に失敗した駐車場ユーザに係るユーザ端末へ予約が失敗した旨（図中では、「申し訳ありません。・・・」と吹き出しで図示）を送信する。

なお、「一瞬前の予約」以外にも、予約が失敗する場合がある。たとえば、ユーザのアクセス時間が所定の長さを超えた場合、「タイムアウト」として予約失敗とみなす。
また、別の事情で、所定の車室に関する貸し出しを停止することとなり、その旨が仲介サーバにおける車室データベースの書き換え（更新）前に予約の打診があった場合にも、予約失敗となる。
そのほか、システム障害などハードウェアまたはソフトウェアに関連する異常事態が発生した場合、仲介サーバは、ユーザに対して「予約の失敗」を送信することとしている。

（図７）
図７は、所定の車室について、公開／非公開の制御について説明している。
すなわち、駐車場ユーザによる検索および閲覧の対象となる「公開情報」か、検索および閲覧の対象外となる「非公開情報」かの区別について、駐車場サーバから受信して車室データベースへ反映させる場合を説明している。

駐車場サーバの管理者が、所定の車室について、公開／非公開についての新規入力、または更新を実行する。続いて、仲介サーバの車室データベースへ、そのデータを送信する。車室データベースにおいては、受信したデータに基づいた更新がなされる（仲介サーバの管理者が操作をする必要はない）。
車室データベースが更新されたら、駐車場サーバの管理者は、公開／非公開についてのデータが更新されたか否かを確認する。

（図８）
図８は、駐車場サーバの駐車場データベースと仲介サーバの車室データベースとを同期させる手順について説明したものである。
仲介サーバにおいては、定期的な周期（たとえば毎日）にて、予め設定した時刻（たとえば、ユーザによるアクセス数が減少する深夜）になったら、連携ファイルを駐車場サーバへ自動的に取得しにゆくように、設定してある。
駐車場サーバは、仲介サーバからの連携ファイル取得の直前に、駐車場データベースを更新し、最新の状態としておくとともに、車室について公開／非公開を含む連携ファイルを作成しておく。

仲介サーバからの連携ファイル取得のためのアクセスがあったら、連携ファイルを仲介サーバへ送信する（ＨＴＴＰＳ ＧＥＴ）。
連携ファイルを受信した仲介サーバでは、連携ファイルを用いて車室データベースを点検する。車室についての公開／非公開についても同様である。
仲介サーバは、フォーマットをチェックし、フォーマットエラーの有無を確認する。また、一方のデータベースにしかない車室ファイルが存在したら、その旨を含む結果ファイルを作成し、駐車場サーバへ送信する。フォーマットエラーやデータベースの不一致がなかった場合にも結果ファイルを作成し、送信する。

（図９）
図９は、駐車場サーバが複数存在し、それらの駐車場サーバ（Ｄ，Ｅ，Ｆ）が、ひとつの仲介サーバ（Ｙ）を介して、多数のユーザに対して駐車場（車室）の予約等を受け付けている場合について示している。
ユーザ（Ｐ，Ｑ，Ｒ）については、自らの端末にて仲介サーバ（Ｙ）を介して車室の閲覧、検索や予約をしている。したがって、駐車場サーバ（Ｄ，Ｅ，Ｆ）のいずれが提供する車室であっても車室の閲覧、検索や予約が可能である。ユーザ（Ｐ，Ｑ，Ｒ）は、閲覧、検索、予約の対象となっている車室を、どの駐車場サーバ（Ｄ，Ｅ，Ｆ）が管理しているかを意識する必要はない。

ユーザ（Ｓ）は、駐車場サーバ（Ｆ）が独自に用意している閲覧予約サイトに対して直接アクセスすることとしており、仲介サーバ（Ｙ）を使っていない。したがって、ユーザ（Ｓ）は、駐車場サーバ（Ｄ）や駐車場サーバ（Ｅ）が提供している車室については、閲覧、検索、予約ができない。

（仲介契約のメリット等）
駐車場サーバ（Ｆ）の運営主体が独自に契約したユーザが（Ｓ）しかいなかった場合、仲介サーバ（Ｙ）の運営主体との間で仲介契約を締結した場合、駐車場サーバ（Ｆ）の運営主体としては、仲介サーバ（Ｙ）のユーザ（Ｐ，Ｑ，Ｒ）を潜在顧客として確保できる。
仲介サーバ（Ｙ）の運営主体としては、ユーザ数が直接増えるわけではない。しかし、駐車場サーバ（Ｆ）が提供する車室を、既存のユーザ（Ｐ，Ｑ，Ｒ）に対して提供できることとなり、ユーザの満足度を高めることができる。

（仲介契約の新規締結時の注意点）
仲介サーバ（Ｙ）の運営主体が、駐車場サーバ（Ｄ，Ｅ）の運営主体と既に契約をしており、駐車場サーバ（Ｆ）の運営主体と新たな仲介契約を締結しようという場合、以下のような注意点が考えられる。
たとえば、駐車場サーバ（Ｆ）の運営主体によって既にユーザ（Ｓ）へ提供している閲覧・検索システムが存在する場合、仲介サーバ（Ｙ）の運営主体が既存のユーザ（Ｐ，Ｑ，Ｒ）へ提供している閲覧・検索システムと、様式などが異なることが想定される。そこでたとえば、仲介サーバ（Ｙ）が提供している閲覧・検索システムへ駐車場サーバ（Ｆ）の閲覧・検索システムをＡＰＩ化して統合する。

（図１０）
図１０は、ひとつの駐車場サーバ（Ｅ）に対して、複数の仲介サーバ（Ｙ，Ｚ）が存在する場合について示している。
ユーザ（Ｐ、Ｑ）は、仲介サーバ（Ｙ）へ、ユーザ（Ｒ）は、仲介サーバ（Ｚ）へ、ユーザ（Ｓ）は、仲介サーバを介さずに駐車場サーバ（Ｅ）へ直接アクセスし、駐車場サーバ（Ｅ）が提供している車室について、閲覧、検索、予約を実行する。

たとえば、仲介サーバ（Ｙ）は、日本に住所地を持つユーザ向けの日本語ウェブサイトを管理しているサーバであり、仲介サーバ（Ｚ）は、日本に住所地を持たないユーザ向けのウ英語ウェブサイトを管理しているサーバである。
仲介サーバ（Ｙ）、仲介サーバ（Ｚ）とも、同一の管理主体が運営しているものの、駐車場利用料金の支払いなどの管理の便宜のために、サーバを物理的に分けている、というような場合が想定される。

（仲介契約の新規締結時の注意点）
仲介サーバ（Ｙ）の運営主体が、既に別の仲介サーバ（Ｚ）の運営主体と契約している駐車場サーバ（Ｅ）の運営主体との間で新たな仲介契約を締結しようという場合、以下のような注意点が考えられる。
たとえば、駐車場サーバ（Ｅ）がその独自ユーザ（Ｓ）へ提供している閲覧・検索システムや、仲介サーバ（Ｚ）の運営主体が提供している閲覧・検索システムと、仲介サーバ（Ｙ）の運営主体が既存のユーザ（Ｐ，Ｑ）へ提供している閲覧・検索システムと、様式などが異なることが想定される。
この場合、駐車場サーバ（Ｅ）が提供している閲覧・検索システムを、仲介サーバ（Ｙ）が提供している閲覧・検索システムへ変更して統合することが、仲介サーバ（Ｙ）の運営主体としては望ましい。

（図１１）
図１１は、複数の駐車場サーバ（Ｄ，Ｅ，Ｆ）に対して、複数の仲介サーバ（Ｗ，Ｙ，Ｚ）が存在する場合について示している。
仲介サーバ（Ｙ）は、駐車場サーバ（Ｄ，Ｅ）を、仲介サーバ（Ｚ）は、駐車場サーバ（Ｆ）をそれぞれ仲介している。そして、仲介サーバ（Ｗ）は、仲介サーバ（Ｙ，Ｚ）を束ねた統合仲介サーバとして、ユーザ（Ｐ，Ｑ，Ｒ）の窓口となっている。

ユーザ（Ｓ）は、駐車場サーバ（Ｆ）が独自に用意している閲覧予約サイトに対して直接アクセスすることとしており、仲介サーバ（Ｗ，Ｙ，Ｚ）を使っていない。したがって、ユーザ（Ｓ）は、駐車場サーバ（Ｄ）や駐車場サーバ（Ｅ）が提供している車室については、閲覧、検索、予約ができない。

（図１２）
図１２は、カーシェアリング事業を運営する事業者が、カーシェアリングを利用したいユーザとの間で予約を仲介する仲介サーバの管理者と契約した場合について、概念的に説明している。
図１との相違点は、図１において「駐車場データベース」だったものが「カーシェアデータベース」に、「車室データベース」だったものが「シェアカーデータベース」に変更されているのみである。
ここで示したシステムを利用するユーザは、カーシェアリングにおいてシェアされるシェアカーの選択範囲が広がる、というメリットを享受できる。

（図１３）
図１３は、ユーザ端末において駐車場を検索する携帯端末における初期画面の一例を示す概念図である。
この図１３に示す駐車場検索サイトの初期画面においては、「現在位置から探す」、「目的地周辺から探す」、「場所を入力する」の３つのメニューボタンが用意されている。
なお、駐車したい日時などの時刻データを入力する初期画面は用意されていない。ヒットする件数が多すぎ、他の検索条件である場所のデータを入力せざるを得ないためである。

「現在位置から探す」のボタンをタップした場合、ユーザ端末のＧＰＳ機能にて現在位置データの入力を代行し、その周辺の車室を閲覧対象とする。
「目的地周辺から探す」のボタンをタップした場合、ユーザ端末のナビゲーション機能を使用している場合において、目的地データを入力済みであれば、その目的地の周辺に存在する車室を閲覧対象とする。
なお、検索オプションとしては、以下のような項目を追加して、検索結果を絞り込むことも可能である。たとえば、利用予定日、車種（大型車両なのか、バスなのか、バイクなのかなど）、料金（の上限）などである。

「場所を入力する」のボタンをタップした場合、ユーザは文字入力機能、音声入力機能などを用いて、住所、地名、ランドマークなどを入力する。
図中では、「東京タワー」と入力している。ここで実行ボタンをタップすれば、東京タワーの周辺に存在する車室が東京タワー周辺地図とともに、ユーザ端末の出力画面へ閲覧対象となる。

（図１４）
図１４は、本願発明における第二の実施形態に係る主要構成を示すブロック図である。

図２に示した実施形態との相違点を中心に説明する。
この第二の実施形態においては、閲覧手段において、駐車場を借りたい場所および時間帯を検索条件として入力して閲覧する（２）。その検索条件を受信した仲介サーバにおいては、車室データベースにおいて該当する車室を抽出する。そして、抽出された車室に関する全てのデータを最新データとすべく、駐車場サーバにおける駐車場データベースから最新データを取得する（２）。（閲覧と最新データ取得とは、ほぼ同時に実行されるので（２）としている）
ユーザ端末においては、駐車場を借りたい場所および時間帯に合致した車室のデータが列挙される。

さて、仲介サーバとしては、検索条件に合致した車室のデータは、全て最新データを受信しているので、その最新データに基づいて車室データベースのデータ更新を実行する（３）。第一の実施形態と異なり、データ更新の対象となる車室が複数存在することとなる。しかし、駐車場データベースのデータが更新される度に車室データベースも更新しているわけではないので、第一の実施形態と同じく、ハードウェア負担の軽減や通信総量の抑制には寄与するのである。

ユーザは、検索条件にヒットした車室の中から予約したい車室を選択し、駐車予定の車種などのデータとともに予約打診を仲介サーバへ送信する（６）。以下は、第一の実施形態とほぼ同様であるが、第二の実施形態ではユーザデータベースを備えている。このユーザデータベースとは、ユーザ毎に利用履歴などを蓄積したデータベースである。
予約打診を受信した仲介サーバの予約送受信手段は、このユーザデータベースにて利用料金の滞納などがないかどうかを確認する。滞納があれば、駐車場データベースからの最新データを取得することなく、予約を受け付けない。

（図１５）
図１５は、本願発明における第三の実施形態に係る主要構成を示すブロック図である。
図１４に示した実施形態との相違点を中心に説明する。
この第三の実施形態においては、ユーザにおける予約手続きが二段階となっている点が大きく異なる。

ユーザは、希望にかなう駐車場が見つかったら、予約データ送信手段を用いて予約に必要な予約データとして予約打診を送信する（４）。仲介サーバでは、ユーザ端末から送信されてきた予約データを予約データ送受信手段にて受信し、更に、駐車場サーバへ送信する。
予約データ（予約打診）を受信した駐車場サーバの予約データ確認手段は、駐車場データベースの最新データと照合して予約が可能かどうかを確認する（４）。そして、予約の可否を決定し、予約可否を予約可否送信手段にて仲介サーバへ送信する。

予約の可否に関する結果は、仲介サーバの予約可否送受信手段が受信し、ユーザ端末へ送信する。そして、ユーザ端末における予約可否受信手段が予約の可否に関する結果を受信する（５）。
予約が可能である場合、ユーザは端末を操作し、予約登録の意思表示（予約登録データ）を予約登録送信手段にて送信する（６）。
予約登録データは、仲介サーバの予約登録送受信手段が受信し、駐車場サーバの予約登録手段へ送信する。

予約登録手段は、予約登録データにて特定される予約内容を、駐車場データベースへ登録することで、予約を実行する（７）。
その予約に係る駐車の空き車室に関するデータは、仲介サーバにおける車室データベースへ、データ提供される（１）。その後、別のアクセスによる検索条件によって検索されたとしても、その予約に係る車室は、閲覧対象から外されることとなる。

なお、図示を省略するが、図１４に示したユーザデータベースを、駐車場サーバが備えている場合もある。この場合も、そのユーザデータベースを用いて予約打診に係るユーザが利用料金を滞納しているか否かを確認する。滞納があれば、駐車場データベースからの最新データを取得することなく、予約不可である旨を仲介サーバへ送信する。もちろん、仲介サーバはユーザ端末に対して、図に示した「（６）予約登録」ではなく、予約不可の送信をすることとなる。

前述してきた実施形態によれば、駐車場を探すユーザが自らの端末を用い、仲介サーバを介しての駐車場を簡単に検索し、駐車場の予約を完了させることが可能な技術を提供することができた。
また、駐車場のみならず、カーシェアリングの予約、レンタカーの予約、賃貸式の住居や会議室などの予約においても、この技術を応用できる。

本願発明は、駐車場の管理業、駐車場の紹介をする通信情報業、駐車場管理に関するソフトウェア開発業、カーシェアリングやレンタカーのサービスを提供するサービス業、カーシェアリングやレンタカーのサービスを運用するためのソフトウェアを開発するソフトウェア開発業などにおいて、利用可能性を有する。

Claims (6)

1. 多数の駐車場の満空データを蓄積する駐車場データベースの各種データを、ユーザの閲覧に供するための駐車場予約仲介サーバであって、
   前記の駐車場データベースから提供された各種データを蓄積する車室データベースと、
   その車室データベースに蓄積される各種データをユーザに係る端末で閲覧可能とする閲覧化手段と、
   その閲覧化手段にて閲覧可能な各種データをユーザが自らに係るユーザ端末が閲覧して所定の車室を特定した詳細データ要請を受信する詳細要請送受信手段と、
   その詳細要請送受信手段が受信した詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得して前記のユーザ端末へ最新データを送信する最新データ送受信手段と、
   前記のユーザ端末から所定の車室の駐車予約に必要な所定の予約打診データを受信するとともにその予約打診データによって予約が可能か否かを前記の駐車場データベースへ打診する予約送受信手段と、
   その予約送受信手段が打診した結果である予約可否を前記の駐車場データベースから受信して前記のユーザ端末へ送信する予約可否送受信手段と、
   を備え、
   前記の閲覧化手段は、前記の最新データ送受信手段が受信した最新データをも前記のユーザ端末にて閲覧可能とすることとした
   駐車場予約仲介サーバ。
2. 前記の駐車場データベースが物理的に複数存在することとした
   請求項１に記載の駐車場予約仲介サーバ。
3. 多数の駐車場に関する満空データを含む駐車場の各種データを、駐車場予約仲介サーバを介してユーザの閲覧に供するための駐車場サーバであって、
   多数の駐車場に関する各種データを前記の駐車場予約仲介サーバへ提供可能な駐車場データベースと、
   所定の車室を特定した詳細データ要請を前記のユーザ端末から受信した駐車場予約仲介サーバを介して前記の詳細データ要請を受信する詳細要請受信手段と、
   その詳細要請受信手段が受信した詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ前記の最新データを送信する最新データ送信手段と、
   所定の車室の駐車予約に必要な所定の予約打診データを前記のユーザ端末から駐車場予約仲介サーバを介して受信する予約受信手段と、
   その予約受信手段が受信した予約打診データに係る車室に関する最新データを前記の駐車場データベースから取得して予約可否を判断するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ予約可否を送信する予約可否送信手段と、
   を備えた駐車場サーバ。
4. 前記の駐車場予約仲介サーバが物理的に複数存在することとした
   請求項３に記載の駐車場サーバ。
5. 多数の駐車場に関する満空データを蓄積する駐車場データベースから提供されて蓄積した車室データベースの各種データを、ユーザの閲覧に供するための駐車場予約仲介サーバを制御するコンピュータプログラムであって、
   前記の駐車場データベースにおける各種データを前記の車室データベースへ蓄積するデータ蓄積手順と、
   そのデータ蓄積手順にて蓄積された各種データをユーザに係る端末で閲覧可能とする閲覧化手順と、
   その閲覧化手順にて閲覧可能なデータをユーザが自らに係るユーザ端末が閲覧して所定の車室を特定した詳細データ要請を受信する詳細要請送受信手順と、
   その詳細要請送受信手順にて受信した詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得して前記のユーザ端末へ最新データを送信する最新データ送受信手順と、
   前記のユーザ端末から所定の車室の駐車予約に必要な所定の予約打診データを受信するとともにその予約打診データによって予約が可能か否かを前記の駐車場データベースへ打診する予約送受信手順と、
   その予約送受信手順にて打診した結果である予約可否を前記の駐車場データベースから受信して前記のユーザ端末へ送信する予約可否送受信手順と
   前記の最新データ送受信手順において受信した最新データを閲覧可能であるように前記の車室データベースへ蓄積する最新データ閲覧化手順と、
   を実行させるように駐車場予約仲介サーバを制御することとしたコンピュータプログラム。
6. 多数の駐車場に関する満空データを含む駐車場の各種データを、駐車場予約仲介サーバを介してユーザの閲覧に供するための駐車場サーバを制御するためのコンピュータプログラムであって、
   多数の駐車場に関する各種データを予め駐車場データベースへ蓄積するデータ蓄積手順と、
   そのデータ蓄積手順にて蓄積された各種データをユーザに係る端末で閲覧可能とするために前記の駐車場予約仲介サーバへ送信するデータ送信手順と、
   所定の車室を特定した詳細データ要請を前記のユーザ端末から受信した駐車場予約仲介サーバを介して前記の詳細データ要請を受信する詳細要請受信手順と、
   その詳細要請受信手順にて受信した詳細データ要請に係る車室に関する最新データを前記の駐車場データベースから取得するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ前記の最新データを送信する最新データ送信手順と、
   所定の車室の駐車予約に必要な所定の予約打診データを前記のユーザ端末から駐車場予約仲介サーバを介して受信する予約受信手順と、
   その予約受信手順にて受信した予約打診データに係る車室に関する最新データを前記の駐車場データベースから取得して予約可否を判断するとともに、駐車場予約仲介サーバを介して前記のユーザ端末へ予約可否を送信する予約可否送信手順と、
   を駐車場サーバを実行させることとしたコンピュータプログラム。

Images