JP7393144B2 - 駐車場管理システム、情報処理方法、及びプログラム - Google Patents

Description

本発明は、駐車場管理装置、駐車場管理方法、及びプログラムに関する。

特許文献１に記載の駐車場の予約時刻変更システムでは、ネットワークを介して接続されるユーザ端末装置からの予約遂行に際して、道路交通状況に基づいて予約時刻が自動的に変更される。これにより交通渋滞が発生した場合でも、ユーザ側の利便性及び駐車場のサービス向上が図られている（特許文献１の明細書段落［０００９］［０００６０］等）。

特開２００５－３１７６６号公報

このように、駐車場を利用する利用者の利便性を向上させることが可能な技術が求められている。

以上のような事情に鑑み、本発明の目的は、駐車場を利用する利用者の利便性を向上させることが可能な情報処理装置、情報処理方法、及びプログラムを提供することにある。

上記目的を達成するため、本発明の一形態に係る駐車場管理装置は、状況判定部と、算出部とを具備する。
前記状況判定部は、車両の駐車状況が、予約情報通りか否かを判定する。
前記算出部は、前記駐車状況が前記予約情報通りではない場合に、前記駐車状況が前記予約情報通りではない理由の連絡の有無、又は前記駐車状況が前記予約情報通りではない理由の少なくとも一方に基づいて、前記駐車状況に関する料金を算出する。

前記予約情報は、出場予約日時に関する情報を含んでもよい。この場合、前記状況判定部は、前記出場予約日時に前記車両が出場したか否かを判定してもよい。また、前記算出部は、前記出場予約日時に前記車両が出場していない場合に、超過料金を算出してもよい。

前記算出部は、前記理由が所定の分類に含まれる場合は、第１の課金体系に基づいて前記超過料金を算出し、前記理由が前記所定の分類に含まれない場合は、前記第１の課金体系よりも課金レベルが高い第２の課金体系に基づいて前記超過料金を算出してもよい。

前記算出部は、前記理由が利用者に起因しない所定の理由である場合は、前記第１の課金体系に基づいて前記超過料金を算出し、前記理由が利用者に起因しない前記所定の理由でない場合は、前記第２の課金体系に基づいて前記超過料金を算出してもよい。

前記利用者に起因しない所定の理由は、交通機関に関する理由、渋滞に関する理由、又は自然現象に関する理由の少なくとも一方を含んでもよい。

前記第１の課金体系は、前記超過料金が０円となる課金体系であってもよい。

前記算出部は、前記理由の連絡がない場合は、前記第２の課金体系よりも課金レベルが高い第３の課金体系に基づいて、前記超過料金を算出してもよい。

前記駐車場管理装置は、さらに、前記理由の真偽を判定する真偽判定部を具備してもよい。この場合、前記算出部は、前記真偽定部による判定結果に基づいて、前記駐車状況に関する料金を算出してもよい。

前記真偽判定部は、交通機関に関する情報、渋滞に関する情報、又は自然現象に関する情報の少なくとも一方に基づいて、前記理由の真偽を判定してもよい。

前記真偽判定部は、利用者から連絡があった前記理由の真偽に基づいて、他の利用者から連絡があった前記理由の真偽を判定してもよい。

前記駐車場管理装置は、さらに、利用者に、前記駐車状況が前記予約情報通りではない理由の連絡を促す旨の通知を実行する通知部を具備してもよい。

前記通知部は、前記出場予約日時に前記車両が出場していない利用者に前記通知を実行してもよい。

前記駐車場管理装置は、さらに、前記駐車状況が前記予約情報通りにならない可能性の高い前記予約情報である要変更予約情報を抽出する抽出部を具備してもよい。この場合、前記通知部は、前記要変更予約情報に関する前記利用者に前記通知を実行してもよい。

前記抽出部は、交通機関に関する情報、渋滞に関する情報、又は自然現象に関する情報の少なくとも一方に基づいて、前記要変更予約情報を抽出してもよい。

前記抽出部は、利用者から連絡があり真であると判定された前記理由に基づいて、前記要変更予約情報を抽出してもよい。

前記駐車場管理装置は、さらに、前記駐車状況が前記予約情報通りにならない可能性の高い前記予約情報である要変更予約情報を抽出する抽出部を具備してもよい。この場合、前記算出部は、前記要変更予約情報については、前記理由の連絡がない場合でも、前記第１の課金体系又は前記第２の課金体系に基づいて、前記超過料金を算出してもよい。

本発明の一形態に係る情報処理方法は、コンピュータにより実行される情報処理方法であって、車両の駐車状況が、予約情報通りか否かを判定することを含む。
前記駐車状況が前記予約情報通りではない場合に、前記駐車状況が前記予約情報通りではない理由の連絡の有無、又は前記駐車状況が前記予約情報通りではない理由の少なくとも一方に基づいて、前記駐車状況に関する料金が算出される。

本発明の一形態に係るプログラムは、コンピュータに以下のステップを実行させる。
車両の駐車状況が、予約情報通りか否かを判定するステップ。
前記駐車状況が前記予約情報通りではない場合に、前記駐車状況が前記予約情報通りではない理由の連絡の有無、又は前記駐車状況が前記予約情報通りではない理由の少なくとも一方に基づいて、前記駐車状況に関する料金を算出するステップ。

以上のように、本発明によれば、駐車場を利用する利用者の利便性を向上させることが可能となる。

本発明の一実施形態に係る駐車場管理システムの構成例を示す概略図である。 駐車場の具体的な構成例を示す模式図である。 駐車場管理装置の機能的な構成例を示すブロック図である。 駐車場管制装置の機能的な構成例を示すブロック図である。 会員登録ＤＢに格納される会員情報の一例を示す図である。 予約情報ＤＢに格納される予約情報の一例を示す図である。 在車ＤＢに格納される在車情報の一例を示す図である。 超過情報ＤＢに格納される在車情報の一例を示す図である。 課金フラグの設定例を示すフローチャートである。 予約変更の申請用のＷｅｂページの構成例を示す模式図である。 超過料金の算出例を示すフローチャートである。 予約変更の申請を促す旨の通知メールの送信例を示すフローチャートである。 予約変更の申請を促す旨の通知メールの送信例を示すフローチャートである。 精算画面の一例を示す模式図である。 案内画面の一例を示す模式図である。 本実施形態に係る課金フラグの設定例を示すフローチャートである。

以下、本発明に係る実施形態を、図面を参照しながら説明する。

＜第１の実施形態＞
［駐車場管理システムの構成］
図１は、本発明の一実施形態に係る駐車場管理システムの構成例を示す概略図である。
駐車場管理システム５００は、駐車場を利用する利用者から申請される予約の管理、駐車状況の監視、及び駐車場の利用に関する種々の料金の算出等、駐車場に関する種々の処理を実行可能である。
本駐車場管理システム５００を、駐車場予約管理システムということも可能である。

駐車場管理システム５００は、駐車場管制装置５と、利用者端末１０と、駐車場管理装置１５と、管理機関端末２０と、決済機関２５が有する決済サーバ装置と、フライト情報管理サーバ３０とを有する。
これらの端末及び装置は、ネットワーク１を介して相互に通信可能に接続されている。ネットワーク１は、例えばインターネットや広域通信回線網等により構築される。
その他、任意のＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）等が用いられてよく、ネットワーク１を構築するためのプロトコルは限定されない。

駐車場管制装置５は、各駐車場６に設置される。駐車場管制装置５は、駐車場６内に設置される各装置の動作を包括的に制御することが可能である。
また駐車場管制装置５は、駐車場６内に設置される各装置から種々の情報を集約し、駐車場管理装置１５等に送信することが可能である。
また駐車場管制装置５は、駐車場管理装置１５や管理機関端末２０等から種々の情報を受信し、種々の動作を実行することが可能である。

駐車場管制装置５は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）等のコンピュータの構成に必要なハードウェアを有する。
また駐車場管制装置５は、ネットワーク１を介して他の装置と通信するための通信部を有する。通信部としては、例えばＷｉＦｉ等の無線ＬＡＮモジュールや、モデムやルータ等の通信機器が用いられる。
駐車場管制装置５として、例えばＰＣ（Personal Computer）等の任意のコンピュータが用いられる。

図１に示す例では、各駐車場６にゲート装置４８が設置されている。
ゲート装置４８は、車両の入場／出場を規制することが可能である。ゲート装置４８に代えて、未精算での駐車スペースからの出庫を規制するフラップ装置（ロック装置）等が設置されてもよい。
なお、ゲート装置やフラップ装置が設置されない所謂フラップレス式駐車場に対しても、本発明を適用することが可能である。
本実施形態では、各駐車場６は、空港３１が所有する施設として設置される。従って、各駐車場６は、主に、空港３１を利用する人物、あるいは空港３１に対して、知人等を送り／迎えをする人物により利用される。
もちろんこれに限定されず、鉄道や船舶等の他の交通手段を利用するための駅や港等の施設が所有する駐車場に対して、本発明を適用することも可能である。

利用者端末１０は、駐車場６を利用する利用者により使用される端末である。
利用者端末１０として、スマートフォン、タブレット端末、種々のＰＤＡ（Personal Digital Assistant）等の携帯端末や、ノートＰＣ（PersonalComputer）等の、任意のコンピュータが用いられてよい。

駐車場管理装置１５は、本実施形態に係る駐車場管理サービスをＷｅｂサービスとして提供可能である。
本実施形態では、複数のサーバ装置１６と、データベース（ＤＢ）１７とにより駐車場管理装置１５が構成される。
駐車場管理装置１５を、駐車場予約管理装置ということも可能である。

各サーバ装置１６は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＨＤＤ等のコンピュータの構成に必要なハードウェアを有する。
また各サーバ装置１６は、ネットワーク１を介して他の装置と通信するための通信部を有する。通信部としては、例えばＷｉＦｉ等の無線ＬＡＮモジュールや、モデムやルータ等の通信機器が用いられる。
サーバ装置１６として、例えばＰＣ等の任意のコンピュータが用いられる。

ＤＢ１７は記憶部として機能し、本駐車場管理サービスに関する種々の情報を記憶する。
例えばＤＢ１７内には、会員登録ＤＢ（図５参照）、予約情報ＤＢ（図６参照）、在車ＤＢ（図７参照）、及び超過情報ＤＢ（図８参照）が構築される。
その他、例えば駐車場ＤＢ、提携店舗ＤＢ、割引ＤＢ、出庫情報ＤＢ、オーナー情報ＤＢ、種々の履歴ＤＢ、管理情報ＤＢ等の、種々のＤＢが構築されてもよい。
各種のＤＢは、駐車場管理装置１５内のＤＢサーバにより包括的に管理され、例えば駐車場管理サービスを利用する利用者の会員登録及び退会、各利用者から受付けた予約情報の登録、変更及び削除、各駐車場６のオーナー情報の登録及び保管、運営収支情報の記録及び保管等が実行される。

また駐車場管理装置１５内のＷｅｂサーバにより、例えばＷＷＷ（World Wide Web）システムを用いて、本実施形態に係る駐車場管理サービスが提供される。
例えばＷｅｂサーバは、ＨＴＭＬ文書でなる種々のＷｅｂページを作成する。Ｗｅｂページには、他のＷｅｂページへのハイパーリンクや、種々の処理を実行するためのリンク情報（例えば実行ファイル名、ＵＲＬ等）が埋め込まれる。
また駐車場管理装置１５内のＷｅｂ／ＡＰＩサーバにより、種々のリクエストに応じた種々の処理が実行される。例えばＷｅｂ／ＡＰＩサーバにより、各駐車場６の満空車情報の収集及び出力、管理機関端末２０からの遠隔操作の中継等が実行される。
駐車場管理装置１５内により生成されたＷｅｂページは、図１に示す各装置に備えられるＷｅｂブラウザにより画面上に表示される。
例えば駐車場６を利用する利用者は、利用者端末１０を操作することで、種々のＷｅｂページを閲覧したり、種々のＷｅｂアプリケーションを利用することが可能である。
例えば、利用者は、利用者端末１０を操作することで、予約の申請や、予約変更の申請等を行うことが可能である。

管理機関端末２０は、駐車場オーナーから駐車場６の管理業務を委託された管理機関のオペレーターにより使用される。
オペレーターにより、例えば日常の問い合わせ対応、ユーザ対応、駐車場管制装置５の故障時の保守メンテ作業の情報提供等が行われる。
管理機関端末２０としては、ＰＣやタブレット端末等が用いられる。
なお駐車場６を所有するオーナー自身で、駐車場６の管理業務を行う場合もある。この場合、オーナーが所有する端末が管理機関端末２０として機能し得る。
また管理業務を委託された管理機関が駐車場管理装置１５を保有し、本実施形態に係る駐車場管理サービスを提供することもあり得る。

決済機関２５は、例えば銀行や信販会社等であり、銀行振り込みやクレジットカード決済等により駐車料金の決済（精算）を実行する。
駐車場管理装置１５は、決済機関２５の決済サーバ装置に対して、駐車料金の精算の指示や、精算が済んでいるか否か等の精算情報の問い合わせ等を実行する。

フライト情報管理サーバ３０は、空港３１に関連するフライト情報を監視する。
フライト情報は、例えば、空港３１に発着する航空機の便名、行き先、出発予定日時、到着予定日時、各種フライトの運行予定情報、各種フライトの実際の運行情報、遅延情報（遅延到着予定日時等）を含む。

図２は、駐車場６の具体的な構成例を示す模式図である。
駐車場６は、入場口３５及び出場口３６を有する。入場口３５及び出場口３６の間には、中央アイランド３７が設置される。
駐車場６の外部から中央アイランド３７を正面に見て、中央アイランド３７の左右には、所定の距離を空けて、入口アイランド３８及び出口アイランド３９が設置される。
本実施形態では、中央アイランド３７と入口アイランド３８とに挟まれた領域が、駐車場６の入場レーン（入場車路）４０となる。入場口３５から駐車場６の構内４１へ向かう方向が、入場レーン４０における車両の進行方向となる。
また、中央アイランド３７と出口アイランド３９とに挟まれた領域が、駐車場６の出場レーン（出場車路）４２となる。構内４１から出場口３６へ向かう方向が、出場レーン４２における車両の進行方向となる。

駐車場６の構内４１には、事前精算機４３、案内装置４４、駐車場管制装置５、駐車場管理ＰＣ４５、駐車場ＤＢ４６が設置される。
中央アイランド３７には、入場ゲート装置４８ａ、出場ゲート装置４８ｂ、入口カメラ４９ａ、出口カメラ４９ｂ、及びスピーカ５０が設置される。
また入場レーン４０の地面には、第１の入口ループコイル５２、及び第２の入口ループコイル５３が埋設される。出場レーン４２の地面には、第１の出口ループコイル５４、及び第２の出口ループコイル５５が埋設される。

事前精算機４３、案内装置４４、駐車場管制装置５、駐車場管理ＰＣ４５、駐車場ＤＢ４６は、駐車場６の構内４１に設置された図示しない構内ＬＡＮを介して、互いに通信可能に接続されている。
このうち駐車場管制装置５は、ネットワーク１に接続され、駐車場管理装置１５等の他のデバイスと通信可能である。従って、構内ＬＡＮに接続された各デバイスは、駐車場管制装置５を介して、ネットワーク１上のデバイスと通信可能である。

事前精算機４３は、利用者が駐車場６から車両を出場させる前に事前精算を実行することが可能な装置である。例えば、タッチパネル等を有する装置が、事前精算機４３として設置される。
案内装置４４は、駐車場６及び本駐車場管理システム５００に関する種々の情報を案内するための装置である。例えばディスプレイ装置等を有し案内情報を表示可能な装置等が、案内装置４４として用いられる。

駐車場管理ＰＣ４５は、主に駐車場６の係員等により操作され、駐車場６の構内４１の各装置の操作や、駐車場ＤＢ４６に格納された種々のデータの管理等が実行される。
本実施形態では、駐車場管理ＰＣ４５を介して入力された指示等に基づいて、駐車場管制装置５が動作する。そして、各装置の操作やデータ管理等が実行される。
駐車場ＤＢ４６には、駐車場６に関する種々のデータが格納され、例えば在車ＤＢや履歴ＤＢ等の任意のＤＢが構築される。もちろん図１に示す駐車場管理装置１５のＤＢ１７に格納されたデータが共有される場合もあり得る。

上記したように、駐車場管理装置１５は、駐車場管制装置５を介して、駐車場６内に設置される各装置の動作を包括的に制御することが可能である。
例えば入場ゲート装置４８ａ、出場ゲート装置４８ｂ、入口カメラ４９ａ、出口カメラ４９ｂ、及びスピーカ５０は、駐車場管制装置５に接続され、その動作が制御される。
入口カメラ４９ａは、入場レーン４０に進入する入場車両の画像（以下、入車画像と記載する）を撮影することが可能である。
出口カメラ４９ｂは、出場レーン４２に進入する出場車両の画像（以下、出車画像と記載する）を撮影することが可能である。
入口カメラ４９ａ及び出口カメラ４９ｂとしては、例えばＣＭＯＳ（Complementary Metal-Oxide Semiconductor）センサやＣＣＤ（Charge Coupled Device）センサ等のイメージセンサを備えるデジタルカメラが用いられる。その他の種類のカメラが用いられてもよい。
スピーカ５０は、入場レーン４０及び出場レーン４２に進入する車両のドライバーに、音声により種々の情報を通知する。
本実施形態では、駐車場管理装置１５や管理機関端末２０からの遠隔制御信号が、駐車場管制装置５に送信される。これにより入場ゲート装置４８ａ等の各装置の遠隔操作が可能となる。
本実施形態では、駐車場６は、駐車券発券機や出口精算機等が設置されない、所謂チケットレス式の駐車場として構成されている。もちろん駐車券を媒体として駐車場の入場日時や精算日時を記録するチケット式の駐車場に対しても、本発明は適用可能である。

図３は、駐車場管理装置１５の機能的な構成例を示すブロック図である。
駐車場管理装置１５は、車両情報読取部６０、駐車状況監視部６１、予約管理部６２、超過情報管理部６３、料金算出部６４、精算受付部６５、通知部６６、及びフライト情報取得部６７を有する。
これらのブロックは、例えば駐車場管理装置１５内の、ＤＢサーバ、メールサーバ、Ｗｅｂサーバ、Ｗｅｂ／ＡＰＩサーバ等の種々のサーバ装置１６により実現される。
すなわち各サーバ装置１６のＣＰＵが所定のプログラムを実行し、装置内のハードウェア資源と協働することで構成され、本実施形態に係る駐車場管理方法が実現される。
各サーバ装置１６にプログラムをインストールする方法は限定されない。

車両情報読取部６０は、入車画像に基づいて、入場車両に関する車両情報を抽出する。例えば車両情報として、車両ナンバーの少なくとも一部の情報、車両名情報、車体色情報、車両メーカー情報等が抽出される。
車両ナンバー（陸運支局名、分類番号、平仮名、４桁の一連番号等）の少なくとも一部の情報は、例えばナンバープレートの一部分を抽出する画像処理や、ＯＣＲ（Optical Character Recognition）処理等の技術により、読取り可能である。もちろん他の任意の技術が用いられてもよい。
車両情報を抽出するためアルゴリズム等は限定されず、機械学習等、任意のアルゴリズムが用いられてよい。またインターネット等を介して、車両情報の照会等が実行されてもよい。
車両情報として、上記した車両ナンバーの少なくとも一部の情報、車両名情報、車体色情報、車両メーカー情報の少なくとも１つや、これらを組み合わせた情報が抽出されてもよい。もちろんここに挙げた情報とは異なる他の情報が、車両情報として抽出されてもよい。

駐車状況監視部６１は、各駐車場６において、車両の駐車状況を監視する。
駐車状況監視部６１は、車両情報読取部６０により抽出された車両情報に基づいて、車両ごとに駐車状況を監視することが可能である。
例えば、入口カメラ４９ａ及び出口カメラ４９ｂにより撮影された画像に基づいて、駐車状況が監視される。もちろん、駐車状況の監視のために、監視カメラや測距センサ等の任意のデバイスが、構内４１に適宜設置されてもよい。
駐車状況は、例えば、入場日時、出場日時、駐車位置（駐車スペースの位置）、駐車場６内の移動の軌跡等、駐車に関する種々の情報を含み得る。
本実施形態では、駐車状況監視部６１により、予約を申請した利用者の車両（以下、予約車両と記載する）の駐車状況が、予約情報通りか否かが判定される。
例えば、入場予約日時に予約車両が入場したか否かが判定される。また出場予約日時に予約車両が出場したか否かが判定される。その他、駐車スペースを指定した予約である場合には、予約された駐車スペースに予約車両が駐車したか否か等が判定される。

予約管理部６２は、予約情報を管理する。具体的には、利用者からの予約の申請、予約変更の申請等を受付ける。そして、予約情報ＤＢ（図６参照）への予約情報の書き込みや削除等を実行する。
超過情報管理部６３は、超過情報を管理する。具体的には、超過情報ＤＢ（図６参照）への超過情報の書き込みや削除等を実行する。

料金算出部６４は、車両ごとに、駐車状況に関する料金を算出する。例えば料金算出部６４により、入場日時及び出場日時までの駐車時間に応じて、駐車料金が算出される。例えば提携店舗での商品購入による割引サービス等がある場合には、割引額が減算された駐車料金が算出される。
また本実施形態では、料金算出部６４により、超過料金が算出される。例えば、駐車状況監視部６１により、出場予約日時に予約車両が出場していないと判定された場合、当該予約車両に対して超過料金が算出される。
その他、駐車状況に関する種々の料金が算出されてよい。

精算受付部６５は、事前精算機４３や利用者端末１０から送信された精算要求を受付け、駐車料金や超過料金の精算処理を実行する。例えば図１に示す決済機関２５に、駐車料金等の精算の指示が送信される。
事前精算機４３や利用者端末１０から送信される精算要求として、本駐車場管理サービスに関するポイントによる精算が要求されている場合には、利用者ＤＢ内のポイント残高に基づいて、ポイント精算処理が実行される。
その他、駐車料金の精算方法は限定されず、デビッドカード決済や電子マネーによる支払い等、任意の精算方法が採用されてよい。

通知部６６は、各駐車場６を利用する利用者の利用者端末１０に、種々の情報を通知する。通知は、例えば登録メールアドレスへの通知メールの送信や、携帯端末に対するプッシュ通知等により実行される。
本実施形態では、通知部６６により、利用者端末１０に、予約変更の理由を含む予約変更の申請を促す旨の通知メールが送信される。その他、種々の内容の通知が実行されてよい。
フライト情報取得部６７は、フライト情報管理サーバ３０から、フライト情報を取得する。

本実施形態では、駐車状況監視部により、車両の駐車状況が、予約情報通りか否かを判定する状況判定部が実現される。
超過情報管理部６３及び料金算出部６４により、駐車状況が予約情報通りではない場合に、駐車状況が予約情報通りではない理由の連絡の有無、又は駐車状況が予約情報通りではない理由の少なくとも一方に基づいて、駐車状況に関する料金を算出する算出部が実現される。
超過情報管理部６３により、抽出部が実現される。
通知部６６により、利用者に、駐車状況が予約情報通りではない理由の連絡を促す旨の通知を実行する通知部が実現される。
予約変更の理由を含む予約変更の申請は、駐車状況が予約情報通りではない理由の連絡に相当する。予約変更の理由を含む予約変更の申請を促す旨の通知メールは、駐車状況が予約情報通りではない理由の連絡を促す旨の通知に相当する。

図４は、駐車場管制装置５の機能的な構成例を示すブロック図である。
駐車場管制装置５は、車両検知部７０、カメラ制御部７１、ゲート装置制御部７２、画像送信部７３、精算確認部７４、及び入場・出場制御部７５を有する。
これらのブロックは、駐車場管制装置５のＣＰＵが所定のプログラムを実行し、装置内のハードウェア資源と協働することで構成され、本実施形態に係る駐車場管理方法が実現される。
駐車場管制装置５にプログラムをインストールする方法は限定されない。

車両検知部７０は、第１及び第２の入口ループコイル５２及び５３から出力される信号に基づいて、入場レーン４０への車両の進入及び構内４１への車両の進入を検知する。
また第１及び第２の出口ループコイル５４及び５５から出力される信号に基づいて、出場レーン４２への車両の進入及び外部への車両の出場を検知することが可能である。
なお、入場レーン４０及び出場レーン４２に進入する車両を検知する構成として、他の任意の構成が採用されてもよい。例えば赤外線等を利用した光学式センサ等が用いられてもよい。

カメラ制御部７１は、入口カメラ４９ａ及び出口カメラ４９ｂの動作を制御する。
例えばカメラ制御部７１により、撮影のトリガー信号が送信され、入口カメラ４９ａ及び出口カメラ４９ｂにより入場車両及び出場車両が撮影される。これにより入車画像及び出車画像が生成される。
トリガー信号は、例えば第１の入口ループコイル５２及び第１の出口ループコイル５４の出力を、それぞれ入口カメラ４９ａ及び出口カメラ４９ｂ用のトリガー信号として用いてもよいが、別途トリガーセンサを設置してもよい。

画像送信部７３は、入口カメラ４９ａ及び出口カメラ４９ｂにより撮影された入車画像及び出車画像を、駐車場管理装置１５に送信する。
精算確認部７４は、出場レーン４２に進入する出場車両の精算状態について確認する。
本実施形態では、精算確認部７４により、出車画像の照会、及び精算情報の照会が実行される。もちろん、出車画像の照会等が実行される際には、画像送信部７３による出車画像の送信等の、他のブロックによる処理が協働して実行される。

入場・出場制御部７５は、入場の可否、及び出場の可否を判断する。
例えば入場・出場制御部７５により、入場レーン４０に進入する入場車両の入車画像に基づいて、入場の可否が判断される。
また入場・出場制御部７５により、出場車両の精算状態に基づいて、出場の可否が判断される。もちろん精算状態は、精算確認部７４により確認される。
ゲート装置制御部７２は、入場ゲート装置４８ａ、及び出場ゲート装置４８ｂの開閉動作を制御する。例えば、入場・出場制御部７５により判断される、入場の可否、及び出場の可否に基づいて、入場ゲート装置４８ａ、及び出場ゲート装置４８ｂの開閉動作が制御される。

図５は、会員登録ＤＢに格納される会員情報の一例を示す図である。
本実施形態では、本駐車場管理サービスを利用するために、利用者による会員登録が必要である。会員登録に応じて、会員情報７７が生成されて管理される。会員情報７７は、利用者情報ともいえる。
例えば利用者は、利用者端末１０を操作することで、会員登録用の入力フォームを含むＷｅｂページを表示させる。そして、会員登録に必要な情報を入力し、会員登録を行う。
図５に示すように、会員情報７７は、会員ＩＤ、氏名、登録日／更新日、車両ナンバー、車種、メールアドレス、電話番号、及びクレジット情報を含む。
これらの情報のうち、登録日／更新日以外の情報は、会員登録時に利用者により入力される。登録日／更新日は、会員登録が行われた日、及び更新が行われた日が格納される。
会員登録に必要な情報（入力フォーム）や、会員登録の具体的な方法等は限定されず、任意に設定されてよい。例えば、車種として、具体的な車種名が格納されてもよいし、軽自動車、普通車、及び大型車等の区分けが格納されてもよい。

図６は、予約情報ＤＢに格納される予約情報の一例を示す図である。
予約情報７８は、利用者（会員）から申請される予約ごとに管理される情報である。
予約情報７８は、会員ＩＤ、駐車場名、入場予約日時、出場予約日時、予約料金、利用目的、フライト情報（行き）、及びフライト情報（帰り）を含む。
駐車場名は、利用者の予約対象となる駐車場名である。
入場予約日時は、利用者が駐車場への入場を希望する日時であり、駐車場の利用開始日時に相当する。
出場予約日時は、利用者が駐車場からの出場を希望する日時であり、駐車場の利用終了日時に相当する。
予約料金は、予約にかかる料金である。例えば予約時に、デポジットとして、クレジットから引き落とされる等の処理が実行される。デポジットは、典型的には、駐車料金の一部に充当される。
利用目的としては、例えば「利用者自身のフライト」や「送り迎え」等が挙げられる。
フライト情報（行き）は、例えば、利用者自身（あるいは空港まで送った人物）が搭乗する飛行機の情報や出発時刻が入力される。
フライト情報（帰り）は、例えば、利用者自身（あるいは空港まで迎えに来た人物）が搭乗する飛行機の情報や、到着時刻が入力される。
例えば利用者は、利用者端末１０を操作することで、予約申請用の入力フォームを含むＷｅｂページを表示させる。そして、上記の予約情報を入力し、予約を申請する。なお、フライト情報等は未定の場合もあり得る。未定の情報については、ブランクで予約を申請することが可能である。例えば、後ほどフライト情報が確定した場合等は、その際に適宜フライト情報を入力することが可能である。
予約申請に必要な情報（入力フォーム）や、予約申請の具体的な方法等は限定されず、任意に設定されてよい。
例えば、空港等に隣接する駐車場等においては、１日単位で駐車場を利用することも多い。従って予約日時として、「○○○○年○○月○○日」等の入力等もあり得る。このような場合、日にちの入力に応じて、入場予約日時及び出場予約日時が格納される。
例えば、「２０１９年４月２７日から２０１９年４月３０日まで」等の予約申請がされた場合、入場予約日時として「２０１９年４月２７日０時００分」が格納され、出場予約日時として「２０１９年４月３０日２３時５９分」が格納される。
このように、予約申請時に入力される項目として、入場予約日時や出場予約日時が直接的に入力されない場合もあり得る。
なお、予約情報として、入場予約日時や出場予約日時に代えて、「２０１９年４月２７日から２０１９年４月３０日まで」や「当日３時間」等の、駐車時間（駐車期間）の情報が格納されてもよい。このような場合、例えば、駐車時間（駐車期間）の情報に基づいて、入場予約時間及び出場予約時間を算出して、本発明を適用することが可能である。
本実施形態において、入場予約時間に関する情報は、入場予約時間を算出可能な任意の情報を含む。また出場予約時間に関する情報は、出場予約時間を算出可能な任意の情報を含む。もちろん入場予約時間自体及び出場予約時間自体も、入場予約時間に関する情報及び出場予約時間に関する情報に、それぞれ含まれる。

図７は、在車ＤＢに格納される在車情報の一例を示す図である。
在車情報７９は、駐車場に入場した車両ごとに管理される情報である。
在車情報７９は、入場番号、車両ナンバー、入場日時、出場日時、精算ステータス、駐車料金、予約番号を含む。
入場番号は、駐車場ごとで入場順に採番される連番である。
車両ナンバーは、入口カメラ４９ａにより撮影された入車画像から抽出される。
入場日時は、例えば、入口カメラ４９ａにより入車画像が撮影された撮影日時を基準として生成される。撮影日時がそのまま格納されてもよい。
出場日時は、例えば、出口カメラ４９ｂにより出場画像が撮影された撮影日時を基準として生成される。撮影日時がそのまま格納されてもよい。
精算ステータスは、「未精算」「事前精算済」「未収金有り」等を含む。
駐車料金は、事前精算等により確定した駐車料金である。
予約番号は、車両ナンバーに基づいて会員登録ＤＢが参照され、会員情報７７が読みだされる。会員ＩＤに基づいて予約情報ＤＢが参照され、予約情報７８が存在する場合には、予約番号が格納される。なお、複数の予約情報が存在する場合には、予約情報ごとの予約番号がそれぞれ格納される。
各項目について、情報が未確定の場合や情報が存在しない場合は、空欄（ブランク）となる。

図８は、超過情報ＤＢに格納される在車情報の一例を示す図である。
超過情報８０は、利用者（会員）から申請される予約ごとに管理される情報である。
超過情報８０は、予約番号、出場予約日時、超過ステータス、超過理由ステータス、課金フラグ、及び超過料金を含む。
予約番号及び出場予約日時は、予約情報７８から読み出される。
超過ステータスは、「超過確定」「超過可能性あり」「超過なし」等を含む。
例えば出場予約日時に、予約車両が出場していない場合は、超過が確定されたとして「超過確定」のステータスが設定される。なお「超過確定」までに時間的な猶予が設定されてもよい。例えば出場予約日時から所定の猶予時間（例えば１０分等）が経過しても、予約車両が出場していない場合に、「超過確定」のステータスが設定されてもよい。
例えば、出場予約日時前に、超過の可能性がありと判定された場合には、「超過可能性あり」のステータスが設定される。
例えば、出場予約日時前に、出場予約日時を延長する旨を含む予約変更の申請が行われた場合、「超過可能性あり」のステータスが設定される。また例えば、予約情報７８に含まれるフライト情報を参照して、該当する飛行機等に遅延が発生していることが判明した場合、「超過可能性あり」のステータスが設定される。また、ある利用者からフライト都合の予約変更の申請があった場合、同じフライトを利用する他の利用者について、「超過可能性あり」のステータスが設定される。これらのような状況に限定される訳ではない。
例えば、出場予約日時前であり超過の可能性がありとは判定されない場合には、「超過なし」のステータスが設定される。また、出場予約日時前に車両が出場した場合等でも、「超過なし」のステータスが設定される。
超過理由ステータスは、「連絡なし（未届け）」「フライト都合」「個人都合」等を含む。
例えば、変更の理由を含む予約変更の連絡がない場合には、「連絡なし（未届け）」のステータスが設定される。
例えば、変更の理由を含む予約変更の連絡があり、その理由がフライトの遅延等の、フライトの都合による場合には、「フライト都合」のステータスが設定される。
例えば、変更の理由を含む予約変更の連絡があり、その理由がフライトの都合ではない場合には、「個人都合」のステータスが設定される。
課金フラグは、「超過料金なしフラグ」「低超過料金フラグ」「高超過料金フラグ」等を含む。
超過料金は、超過が確定した場合に算出される超過料金が格納される。

本実施形態において、予約変更の理由がフライトの都合による場合は、理由が所定の分類に含まれる場合に相当する。予約変更の理由がフライトの都合ではない場合は、理由が所定の分類に含まれない場合に相当する。
また、予約変更の理由がフライトの都合による場合は、理由が利用者に起因しない所定の理由である場合に相当する。予約変更の理由がフライトの都合ではない場合は、理由が利用者に起因しない所定の理由でない場合に相当する。
なお、図５～図８に例示する各ＤＢに格納される情報のデータ形式等は限定されず、任意に設定されてよい。

［駐車場管理システムの動作］
図９は、課金フラグの設定例を示すフローチャートである。
課金フラグの設定は、超過情報管理部６３により、申請される予約ごとに実行される。
課金フラグの設定を実行するタイミングは限定されない。例えば入場予約日時の経過後に、定期的に課金フラグの設定が実行されてもよい。または所定の時刻に、一斉に課金フラグの設定が実行されてもよい。あるいは、超過の可能性が判定されたタイミング、予約変更の申請を受付けたタイミング、事前精算の要求を受付けたタイミング等、所定の処理が実行されるタイミングをトリガーとして、課金フラグの設定が実行されてもよい。
まず、予約を申請した利用者から変更の理由を含む予約変更の申請があるか否か判定される（ステップ１０１）。

図１０は、予約変更の申請用のＷｅｂページの構成例を示す模式図である。
例えば、利用者はＷｅｂアプリケーションに対して、予約変更の申請をするための操作を実行する。そうすると申請用のＷｅｂページ８２が表示される。
申請用のＷｅｂページ８２には、「予約番号」「車両情報（車両ナンバー）」「駐車場名」「出場予約日時」が表示される。
また申請用のＷｅｂページ８２は、変更出場日時の入力部８３と、変更の理由を選択する選択部８４と、送信ボタン８５とを有する。
利用者は、入力部８３に、予約の変更を希望する変更出場日時を入力する。また選択部８４のラジオボタンを適宜選択することで、変更の理由を選択する。
本実施形態では、「フライトの都合」及び「その他の理由」の２つの選択肢が設定されている。
「フライトの都合」は、変更の理由がフライトの都合である場合に選択される。「フライトの都合」となる理由は、自身が搭乗する、あるいは迎え／送りに来た人物が搭乗する飛行機に関する種々の利用を含む。例えば、フライトの遅延、空港の閉鎖、その他のトラブル等が挙げられる。
「その他の理由」は、「フライトの都合」以外の理由の際に選択される。
送信ボタン８５が押されると、変更出場日時及び変更の理由を含む予約変更の申請が実行される。
なお図１０では、携帯端末を介した予約変更の申請操作を説明した。これに限定されず、ＰＣ等、任意の利用者端末１０から、予約変更の申請を実行することが可能である。また予約変更の申請用のＧＵＩ（Graphical User Interface）等は限定されず、任意に設計されてよい。

図９に戻り、予約変更の申請がない場合には（ステップ１０１のＮＯ）、課金フラグに「高超過料金フラグ」が設定される（ステップ１０２）。また超過理由ステータスが、「連絡なし（未届け）」に設定される。
予約変更の申請がある場合には（ステップ１０１のＹＥＳ）、予約変更の理由が特段の理由であるか否か判定される（ステップ１０３）。本実施形態では、予約変更の理由が「フライトの都合」か「その他の理由」かが判定される。
予約変更の理由が「フライトの都合」である場合には、特段の理由であると判定され（ステップ１０３のＹＥＳ）、「超過料金なしフラグ」が設定される（ステップ１０４）。また超過理由ステータスが、「フライト都合」に設定される。
予約変更の理由が「その他の理由」である場合には、特段の理由ではないと判定され（ステップ１０３のＮＯ）、「低超過料金フラグ」が設定される（ステップ１０５）。また超過理由ステータスが、「個人都合」に設定される。
なお、予約変更の申請が受付けられた場合には、予約情報ＤＢの予約情報７８に、その旨の情報が格納される。例えば、利用者により入力された変更出場日時の情報が格納される。

図１１は、超過料金の算出例を示すフローチャートである。
超過料金の算出は、料金算出部６４により実行される。
まず、超過が確定したか否かが監視される（ステップ２０１）。例えば料金算出部６４は、定期的に、あるはい所定のタイミングで、超過情報８０内の超過ステータスを参照することで、超過が確定したか否かを判定する。もちろん超過が確定した旨が料金算出部６４に出力されてもよい。
超過が確定した場合（ステップ２０１のＹＥＳ）、超過情報８０内の課金フラグが参照される（ステップ２０２）。
課金フラグに基づいた課金体系に基づいて、超過料金が算出される（ステップ２０３）。

本実施形態では、「超過料金なしフラグ」に基づいた課金体系は、超過料金が０円となる課金体系である。従って、課金フラグが「超過料金なしフラグ」である場合は、超過料金が０円となる。本実施形態では、予約変更の申請があり、変更の理由が特段の理由である場合（「フライトの都合」）には、超過料金は０円となる。もちろん、これに限定されず、所定の金額が超過料金として算出されてもよい。
「低超過料金フラグ」に基づいた課金体系は、「超過料金なしフラグ」に基づいた課金体系よりも課金レベルが高い課金体系である。
課金レベルが高いとは、課金体系の設定上算出される料金が高くなることを意味する。本実施形態では、課金体系の設定上算出される超過料金が高くなることを意味し、具体的な課金方法等は限定されず、任意に設定されてよい。例えば固定の所定の金額が超過料金として算出されてもよいし、超過時間に基づいて変更するような超過料金が算出されてもよい。
本実施形態では、所定の金額（１０００円）が、超過料金として算出される。すなわち本実施形態では、予約変更の申請があり、変更の理由が特段の理由でない場合（「その他の理由」）には、超過料金は１０００円となる。
「高超過料金フラグ」に基づいた課金体系は、「低超過料金フラグ」に基づいた課金体系よりも課金レベルが高い課金体系である。本実施形態では、所定の金額（５０００円）が、超過料金として算出される。すなわち本実施形態では、予約変更の申請がない場合には、超過料金は５０００円となる。

本実施形態において、「超過料金なしフラグ」に基づいた課金体系は、第１の課金体系に相当する。
「低超過料金フラグ」に基づいた課金体系は、第１の課金体系よりもレベルの高い第２の課金体系に相当する。
「高超過料金フラグ」に基づいた課金体系は、第２の課金体系よりもレベルの高い第３の課金体系に相当する。

典型的には、予約変更の申請がない場合には、懲罰的な意味合いを込めた金額設定がされる。これにより、無届け／無断の予約超過の防止を図ることが可能となる。
予約変更の申請があり、変更の理由が特段の理由でない場合（「その他の理由」）には、個人都合に対するリーズナブルな金額が設定される。例えば予約の延長による駐車場側の機会損失の補償としての意味合いを込めた金額設定される。なおデポジット（予約料金）を駐車料金の一部に充当しないといった処置もあり得る。
予約変更の申請があり、変更の理由が特段の理由である場合（「フライトの都合」）には、超過課金はされず、延長された分の駐車料金のみ請求する。この場合デポジットは、駐車料金の一部に充当される。

このように本実施形態では、理由が所定の分類に含まれる場合、すなわち理由が利用者に起因しない所定の理由である場合は、第１の課金体系に基づいて超過料金が算出される。理由が所定の分類に含まれない場合、すなわち理由が利用者に起因しない所定の理由でない場合は、第１の課金体系よりも課金レベルが高い第２の課金体系に基づいて超過料金が算出される。
また理由の連絡がない場合は、第２の課金体系よりも課金レベルが高い第３の課金体系に基づいて、超過料金が算出される。

図１２及び図１３は、予約変更の申請を促す旨の通知メールの送信例を示すフローチャートである。以下、予約変更の申請を促す旨の通知メールを、申請促進メールと記載する。申請促成メールを、打診メールということも可能である。
申請促成メールの送信は、フライト情報取得部６７、超過情報管理部６３、通知部６６が連動することにより実行される。
図１２に示す例では、まずフライト情報取得部６７がフライト情報管理サーバ３０から取得したフライト情報が参照される（ステップ３０１）。
フライト情報に基づいて、フライトに関する問題が発生しているか否か判定される（ステップ３０２）。例えば、フライトの遅延、空港の閉鎖、その他のトラブル等が発生しているか否かが判定される。
フライトに関する問題が発生している場合には、超過情報管理部６３により、予約情報ＤＢに記憶されている予約情報７８から、要変更予約情報が抽出される（ステップ３０３）。要変更予約情報は、駐車状況が予約情報通りにならない可能性の高い予約情報である。
例えばフライトの遅延が発生している場合は、該当するフライトの情報が格納されている予約情報７８が、要変更予約情報として抽出される。空港の閉鎖が発生している場合には、閉鎖期間に空港に発着するフライト情報が格納されている予約情報７８が、要変更予約情報として抽出される。その他、駐車状況が予約情報通りにならない可能性の高い予約情報が、適宜要変更予約情報として抽出される。
抽出された要変更予約情報の各々に対して、変更の理由を含む予約変更の申請があるか否か判定される（ステップ３０４）。予約変更の申請があった場合は（ステップ３０４のＹＥＳ）、申請促進メールは送信されずに処理が終了する。
予約変更の申請がない場合は（ステップ３０４のＮＯ）、申請促進メールが送信される（ステップ３０５）。
申請促進メールには、例えば、予約の変更が必要な場合には、変更の理由を含む予約変更の申請をして欲しい旨の内容が含まれる。また申請促進メール内に、図１０に示す予約変更の申請用のＷｅｂページ８２へのリンク情報が含まれていてもよい。その他、予約変更の申請を促すことが可能な任意の内容が含まれてもよい。
申請促進メールに応じて、利用者から予約変更の申請があった場合は、図９に示すステップ１０１の判定がＹＥＳとなり、高い確率でステップ１０３の判定もＹＥＳとなり、「超過料金なしフラグ」が設定される。
このようにフライト都合の理由が発生する可能性が高い利用者に対して、申請促進メールが送信される。すなわち要変更予約情報に関する利用者に、通知が実行される。これにより、利用者は予約変更の申請を容易に行うことが可能となり、超過料金の免除等を容易に受けることが可能となる。この結果、駐車場を利用する利用者の利便性を向上させることが可能となる。
駐車場の管理側から見ても、予約変更の申請を促すことで、駐車状況の予測を立てることが可能となり、効率的な駐車場の運営等が実現可能となる。
なお

図１３に示す例では、超過が確定したか否かが監視される（ステップ４０１）。例えば通知部６６は、定期的に、あるはい所定のタイミングで、超過情報８０内の超過ステータスを参照することで、超過が確定したか否かを判定する。もちろん超過が確定した旨が通知部６６に出力されてもよい。
変更の理由を含む予約変更の申請があるか否か判定される（ステップ４０２）。予約変更の申請があった場合は（ステップ４０２のＹＥＳ）、申請促進メールは送信されずに処理が終了する。
予約変更の申請がない場合は（ステップ４０２のＮＯ）、申請促進メールが送信される（ステップ４０３）。
このように、超過が確定した後に申請促進メールが送信されてもよい。すなわち出場予約日時に車両が出場していない利用者に通知が実行されてもよい。例えば、ユーザがフライト中である場合等では、利用者端末１０が通信不可能な状態である場合もあり得る。すなわち超過が確定する前に、予約変更の申請ができない場合もあり得る。
従って、超過が確定した後であっても、申請促進メールに応じて予約変更の申請があった場合には、超過料金を再計算する。これにより、利用者の利便性を向上させることが可能となる。また駐車場の管理側から見ても、駐車状況の予測を立てることが可能となり、効率的な駐車場の運営等が実現可能となる。
一方で、超過が確定した後の予約変更の申請は無効であるといった運用も可能である。

申請促進メールを送信するタイミング等は、任意に設定されてよい。利用者ごとに個別にメール送信が実行されてもよい。又は所定の時刻にバッチ処理にて、一斉にメール送信が実行されてもよい。また予約の変更の申請があるまで、繰り返し申請促成メールを送信するといったことも可能である。この場合、２回目以降の送信スケジュールは任意に設定されてよい。

図１４及び図１５は、事前精算機４３に表示される情報の例を示す模式図である。
図１４は、精算画面８７の一例を示す模式図である。
精算画面８７は、駐車場名、車両ナンバー、入場日時、予約番号、駐車料金、及び超過料金を含む。図１４に示す例では、予約の申請がない状態で、超過が確定した場合の精算画面８７が図示されている。すなわち超過料金として５０００円が課せられている。

図１５は、案内画面８８の一例を示す模式図である。
例えば、精算画面８７の次へボタンを選択すると、案内画面８８が表示される。あるいは精算画面８７の表示の後に、自動的に案内画面８８が表示される。その他、案内画面８８が表示されるタイミングや方法等は限定されない。
案内画面８８は、申請促進メールを送信した旨、精算前に予約変更の申請をすれば超過料金を再計算する旨が表示される。
例えばフライトに搭乗している利用者は、搭乗中には申請促成メールを読むことが出来ず、事前に予約変更の申請を行うことができない可能性がある。そこで、本発明の駐車場予約管理システムでは、駐車場の事前精算機４３において、事前精算前に申請促進メールの有無を案内し、精算前であれば予約変更の申請を受付ける。
これにより飛行機内にて予約変更の申請ができなかった利用者を効率よく救済することが可能となり、利用者の利便性を向上させることが可能となる。
なお、案内画面８８に表示されているように、本実施形態では、到着日時から所定の期間（本例では１日）経過した後は、予約変更の申請は無効となる。例えば、一旦フライト都合により遅延しても、その後予約変更の申請を行う時間が十分にあったにも関わらずに、予約変更の申請をしない利用者については、特段の便宜を図る必要はない。このような設定も可能である。
到着日時から所定の期間（本例では１日）経過した後は、案内画面８８を表示しないという実施例を実現可能である。また到着後から所定の期間経過した後に代えて、メール受信日から所定の期間の経過後は、予約変更の申請は無効であるといった設定も可能である。
また、事前精算機４３に、予約変更の申請、あるいは超過した理由の入力等を行うことが可能であってもよい。これにより、利用者がフライト中には申請促進メールへの返信ができず、到着後すぐに駐車場から出場する場合に、利用者にとって利便性がよい。
案内画面８８の表示に合わせて、音声により、同じ内容の通知が実行されてもよい。また図２に例示する案内装置４４により、案内画面８８等が表示されてもよい。

以上、本実施形態に関する駐車場管理システム５００及び駐車場管理装置１５では、予約車両の駐車状況が予約情報通りでない場合に、駐車状況が予約情報通りではない理由の連絡の有無、又は駐車状況が予約情報通りではない理由の少なくとも一方に基づいて、駐車状況に関する料金として超過料金が算出される。これにより、駐車場を利用する利用者の利便性を向上させることが可能な情報処理装置、情報処理方法、及びプログラムを提供することにある。

例えば、出場予約日時を利用者が超過した場合、駐車場が予め他の利用者の入場予約を受け付けても、これを受け入れることが出来なくなる可能性がある。従って収容台数に比べて、少ない入場予約の台数のみ予約を受け付けるといったことが必要となることが多い。
又は、出場予約日時に対して、相当の余裕時間を空けてから、入場予約を受付け可能とする必要がある。これは駐車場運営側にとっては非効率であり、経営を圧迫しかねない。
一方で、入場予約日時、出場予約日時とも、時間の超過に対して、追徴金（ペナルティ）を課す運用もある。ただし、入場予約日時の超過はさておき、出場予約日時まで事前に（利用前に）正確に予約しなければならないとすれば、利用者の手間や負担が増加することに繋がる。すなわち利便性の低下を招いてしまう可能性多高い。

これに対して、本発明によれば、利用者の都合やその他の理由により駐車時間が大幅に超過してしまう場合でも、超過料金を課す場合には合理的な理由に従って課金を行うことが可能となる。また利用者の責に拠らない事由の場合には、容易にその旨の申告や確認が可能であり、利用者の負担を軽減することが可能となり、利便性を向上させることが可能となる。
例えば、本駐車場管理システム５００によれば、予約変更の事由により超過金レベルを変更することが可能でるので、超過金額のレベルが合理的で、利用者が納得し易いシステムを構築することが可能となる。
また、予約変更によって超過金が変化するため、利用者が予約変更せずに超過することが抑制され、利用者が適宜予約変更を実施するようになり、駐車場側が予約の状態を把握しやすい。従って、満車台数からの余裕台数を少なく見積もることが出来るので、駐車場側で予約を受け付ける台数を増やすことが可能となる。
また、本駐車場管理システム５００によれば、利用者の責任によらない事由としてフライトの事由が設定されるので、駐車場管理側（運営機関やオーナー）にとっても納得のいく料金徴収が実現される。

＜第２の実施形態＞
本発明に係る第２の実施形態の情報処理装置について説明する。これ以降の説明では、上記の実施形態で説明した駐車場管理システム５００及び駐車場管理装置１５における構成及び作用と同様な部分については、その説明を省略又は簡略化する。

図１６は、本実施形態に係る課金フラグの設定例を示すフローチャートである。ここでは、図９に示すフローチャートと異なる点を中心に説明を行う。
図１６に示すように、ステップ５０３にて、予約変更の理由が「フライトの都合」であり特段の理由であると判定された場合（ＹＥＳ）、その理由の真偽が判定されてもよい（ステップ５０４）。
理由の真偽判定は、例えば超過情報管理部６３が、真偽判定部として機能することで実行される。もちろん真偽判定部として機能するブロックが、個別に構成されてもよい。
例えば、フライト情報取得部６７がフライト情報管理サーバ３０から取得したフライト情報に基づいて、「フライトの都合」となる理由の真偽を判定することが可能である。
「フライトの都合」の理由が真である場合には（ステップ５０４のＹＥＳ）、「超過料金なしフラグ」が設定される（ステップ５０５）。「フライトの都合」の理由が真ではない場合には（ステップ５０４のＮＯ）、「低超過料金フラグ」が設定される（ステップ５０６）。
このように、特段の理由として判定された場合に、真偽判定部により、その理由の真偽が判定されてもよい。そして、真偽判定部による判定結果に基づいて、駐車状況に関する料金が算出されてもよい。これにより不正な申請を防止することが可能となる。
なお、「フライトの都合」の理由が真ではない場合に、「高超過料金フラグ」が設定されてもよい。しかしながら、予約変更の申請があったことや、利用者の誤操作の可能性等を考慮して、「低超過料金フラグ」の設定の方が、利便性の向上には効果的だと思われる。
なお取得されたフライト情報が、超過情報ＤＢ等に格納されてもよい。

＜その他の実施形態＞
本発明は、以上説明した実施形態に限定されず、他の種々の実施形態で実現することができる。
上記では、変更の理由を含む予約変更の申請を、駐車状況が予約情報通りではない理由の連絡の一例として説明を行った。これに限定されず、例えば変更の理由のみが連絡される場合でも、本発明は適用可能である。すなわち変更後の出場予約日時等の連絡等がない場合もあり得る。一方で、変更後の出場予約日時の連絡を必須として、変更後の出場予約日時の連絡がない場合には、課金レベルの変更を行わないといった設定も可能である。
図９等に例示するように、上記では、駐車状況が予約情報通りではない理由の連絡の有無、及び駐車状況が予約情報通りではない理由の両方に基づいて、駐車状況に関する料金が算出された。これに限定されず、駐車状況が予約情報通りではない理由の連絡の有無のみに基づいて、駐車状況に関する料金が算出されてもよい。また駐車状況が予約情報通りではない理由のみに基づいて、駐車状況に関する料金が算出されてもよい。

上記では、第１の分類に含まれる理由として、利用者に起因しない所定の理由を例に挙げた。具体的には、「フライトの都合」となる理由を例に挙げた。これに限定されず、第１の分類に含まれる理由の判定基準として、任意の分類基準が採用されてよい。
また利用者に起因しない所定の理由も、「フライトの都合」となる理由に限定されず、種々の理由が任意に設定されてよい。例えば、鉄道、船舶、バス等の交通機関に関する任意の理由が設定されてもよい。また高速道路、幹線道路、運河等で発生するような、渋滞に関する任意の理由が設定されてよい。台風、天候、大雪、地震、竜巻等、自然現象に関する任意の理由が設定されてもよい。
上記では、フライト情報管理サーバから取得したフライト情報に基づいて、理由の真偽を判定する例を説明した。これに限定されず、第１の分類に含まれる理由や利用者に起因しない所定の理由であるかどうかの真偽を判定可能な任意の方法が採用されてよい。例えば、理由の設定に応じて、交通機関に関する情報、渋滞に関する情報、又は自然現象に関する情報の少なくとも一方に基づいて、理由の真偽が判定されてもよい。
上記では、フライト情報管理サーバから取得したフライト情報に基づいて、要変更予約情報を抽出する例を説明した。これに限定されず、要変更予約情報を抽出可能な任意の方法が採用されてよい。例えば、交通機関に関する情報、渋滞に関する情報、又は自然現象に関する情報の少なくとも一方に基づいて、要変更予約情報が抽出されてもよい。
理由の真偽を判定するための情報、及び要変更予約情報を抽出するための情報を取得する方法も限定されない。上記では、空港のフライト情報管理サーバからフライト情報を取得する例を説明した。これに限定されず、空港とは関係なく、フライト情報を集めて配信するサービスから、フライト情報を取得することも可能である。その他、任意の方法が採用されてよい。
空港等の施設のシステムと、本発明に係る駐車場管理システムとが連携して、運用される場合もあり得るし、連携なしで運用される場合もあり得る。

本駐車場管理システムは、複数の利用者が同時に利用することが可能である。すなわち利用者ごとに、予約の申請や予約変更の申請等、上記した種々の処理を実行することが可能である。
本駐車場管理システムでは、ある利用者に関する情報に基づいて、他の利用者に関する処理を実行することも可能である。すなわち情報の共有化が行われてもよい。
例えば、図１６に例示するステップ５０４の真偽判定ステップにおいて、他の利用者から連絡のあった理由の真偽に基づいて、真偽の判定が実行されてもよい。このことを利用者の立場を変えて言うと、利用者から連絡のあった理由の真偽に基づいて、他の利用者から連絡があった理由の真偽を判定してもよい。
例えば、ある利用者から連絡があった理由が真であると判定された場合、同じ理由を連絡してきた利用者に対して、その理由は真であると判定してもよい。これにより、処理の簡素化や処理時間の短縮化を図ることが可能となり、利用者の利便性も向上させることが可能となる。
また、図１２に例示するステップ３０３の要変更予約情報の抽出ステップにおいて、ある利用者から連絡があり真であると判定された理由に基づいて、要変更予約情報が抽出されてもよい。
例えば、理由としてフライトＡが遅延する旨の連絡があり、その理由が真であると判定されたとする。この場合、同じフライトＡに搭乗する（あるいは送り／迎えをする）利用者の予約情報が、要予約情報として抽出されてもよい。あるいは、真偽を判定することなく、同じフライトＡに搭乗する（あるいは送り／迎えをする）利用者の予約情報が、要予約情報として抽出されてもよい。

図９を参照して、要変更予約情報として抽出された予約情報については、予約変更の申請（理由の連絡）がない場合でも、懲罰的な意味合いが込められた第３の課金体系に基づいた超過料金の算出は行われないといった設定も可能である。すなわち要変更予約情報として抽出された予約情報については、理由の連絡がない場合でも、第１の課金体系又は第２の課金体系に基づいて、超過料金が算出されてもよい。
この場合、要変更の程度の信憑性が判定され、信憑性が高い場合には、第３の課金体系に基づいた超過料金の算出は行われないといった設定も可能である。信憑性の判定として、例えば、要変更予約情報として抽出される原因となる理由の真偽は判定される。もちろんこれに限定される訳ではない。

図８に例示する超過ステータスは、「超過確定」「超過可能性あり」「超過なし」等を含む。要変更予約情報は、超過ステータスが「超過可能性あり」となる予約情報とも言える。この要予約情報を、予約変更の仮申請が実行された予約情報と見做すことも可能である。これに対して、利用者から実際に予約変更の申請があった予約情報は、正式申請が実行された予約情報となる。
例えば、ある利用者から連絡があった理由の内容や、理由の真偽に基づいて、他の利用者の予約情報を仮申請が実行された予約情報として取り扱うことが可能である。例えば、ある利用者から連絡があった理由の内容や、理由の真偽に基づいて、要予約変更情報として抽出された予約情報は、仮申請が実行された予約情報として取り扱うことが可能である。
典型的には、利用者からの予約変更の申請がないと、仮申請が実行された予約情報は、正式申請が実行された予約情報としては取り扱われない。一方で、他の利用者から同じ理由の連絡があり、その理由が真であると判定された場合等においては、本人からの予約変更の申請がなくとも、正式申請が実行された予約情報として取り扱う。このような設定も可能である。
例えば、同じ理由の仮申請を、全て正式申請とするような処理も可能である。例えば、フライトＡの遅延が判明した場合、フライトＡに関する利用者は、連絡の有無にかかわらず、第１の課金体系にて超過料金を算出してもよい。

上記では、駐車状況が予約情報通りではない場合として、出場予約日時からの超過を例に挙げた。これに限定されず、駐車状況が予約情報通りではない他の例についても、本発明は適用可能である。
例えば、状況判定部により、入場予約日時に車両が入場したか否かが判定されてもよい。そして、入場予約日時に車両が入場していない場合に、理由の連絡の有無、又は理由の少なくとも一方に基づいて、違約金（例えば機会損失の補償としての意味合いを込めた金額）が算出されてもよい。
また、駐車場に対する入場／出場に限定されず、駐車スペースに対する入庫／出庫、駐車スペースの移動等について、本発明を適用することも可能である。

上記では、駐車状況が予約情報通りではない理由の連絡を促す旨の通知として、申請促進メールが送信された。これに限定されず、携帯端末へのプッシュ通知等、任意の通知方法が採用されてよい。例えば、ＬＩＮＥ（登録商標）やｆａｃｅｂｏｏｋ（登録商標）等のＳＮＳ（Social Networking Service）を介して通知が実行されてもよい。
上記では、Ｗｅｂアプリケーションを介して、予約の申請や予約変更の申請等が実行される場合を例に挙げた。これに限定されず、本発明に係る駐車場管理サービスを利用するためのネイティブアプリケーションが利用者端末にダウンロードされ、利用者により利用されてもよい。
上記では、予約変更の申請の際に、「フライトの都合」か「その他の理由」かを選択して入力することが可能であった。これに限定されず、テキスト等により、予約変更の理由が入力されてもよい。
例えば、駐車場管理装置側では、機械学習等の任意のアルゴリズムにより、テキストを解析して、理由の分類を判定することが可能である。あるいは、オペレーター等により、理由が判別されてもよい。なお機械学習等の学習アルゴリズムの適用は、テキスト解析等のみに限定されず、理由の分類、理由の真偽等、広く適用可能である。

本発明に係る駐車場管理システムが、ＥＴＣ（Electronic Toll Collection System）システムと連動することで実現されてもよい。ＥＴＣシステムでは、利用者の情報、決済情報、及び車両情報等が適宜管理される。これらの情報を適宜読み出すことで、本発明に係る駐車場管理システムを実現することが可能である。

また、交通手段を利用するための施設ではない施設の駐車場、施設に所有されない駐車場等の、任意の種類の駐車場に対して本発明は適用可能である。

本発明の実施例は、車両として普通自動車や大型自動車等を問わず、または二輪車も併用で管理することもできる。すなわち本開示では、車両は、自動車に限定されず、自転車や二輪車（バイク）等も含む。また駐車場は、自転車や二輪車（バイク）等を駐車するための駐輪場を含む概念である。すなわち本技術は、自動車を駐車可能な駐車場に限定されず、駐輪場等にも適用可能である。

上記で説明した駐車場管理システム５００において、駐車場管制装置５、利用者端末１０、及び駐車場管理装置１５にそれぞれ備えられた機能が、他の装置に備えられてもよい。例えば、図３に示す駐車場管理装置１５の機能の一部が、利用者端末１０や駐車場管制装置５に備えられてもよい。
すなわち本発明に係る駐車場管理システムが備える「状況判定部」「算出部」「真偽判定部」「通知部」「抽出部」等が、駐車場管理システムを構成する各装置のいずれかにより実現されるかは限定されず、任意に設定可能である。また複数の装置が協働することにより、これらの要素が実現されてもよい。

同様に、本発明に係る情報処理方法、及びプログラムは、単体のコンピュータにより実行されてもよいし、複数のコンピュータが連動することで実行されてもよい。すなわち駐車状況の判定、駐車状況に関する料金の算出、理由の真偽判定、要変更予約情報の抽出、理由の連絡を促す旨の通知等が、単体のコンピュータにより実行される場合と、各処理が異なるコンピュータにより実行される場合とのいずれもが有り得る。
また所定のコンピュータによる各処理の実行は、当該処理の一部または全部を他のコンピュータに実行させたその結果を取得することを含む。例えば本技術に係る情報処理方法及びプログラムは、クラウドコンピューティングの構成にも適用することが可能である。

各図面を参照して説明した駐車場、携帯端末、駐車場管制装置、駐車場管理装置、Ｗｅｂページ画像、精算機案内・操作画像、各処理フロー等はあくまで一実施形態であり、本技術の趣旨を逸脱しない範囲で、任意に変形可能である。すなわち本技術を実施するための他の任意の構成やアルゴリズム等が採用されてよい。

以上説明した本発明に係る特徴部分のうち、少なくとも２つの特徴部分を組み合わせることも可能である。すなわち各実施形態で説明した種々の特徴部分は、各実施形態の区別なく、任意に組み合わされてもよい。また上記で記載した種々の効果は、あくまで例示であって限定されるものではなく、また他の効果が発揮されてもよい。

また、本発明は、請求の範囲及び明細書全体から読み取ることのできる発明の要旨又は思想に反しない範囲で適宜変更可能であり、そのような変更を伴う駐車場管理装置・方法・システムもまた本発明の技術思想に含まれる。

本発明の技術は、例えば、空港や鉄道駅に隣接した大規模な駐車場の予約管理システムにおいて、好適に利用できるものである。

５…駐車場管制装置
６…駐車場
１０…利用者端末
１５…駐車場管理装置
１６…サーバ装置
１７…ＤＢ
２０…管理機関端末
２５…決済機関
３０…フライト情報管理サーバ
３１…空港
４３…事前精算機
４５…駐車場管理ＰＣ
７７…会員情報
７８…予約情報
８０…超過情報
８７…精算画面
８８…案内画面
５００…駐車場管理システム

Claims (18)

1. 駐車場の利用者から申請される予約情報を取得する予約管理部と、
   前記利用者の車両である予約車両の駐車状況が、前記予約情報通りか否かを判定する状況判定部と、
   前記駐車状況が前記予約情報通りではない場合に、前記駐車状況が前記予約情報通りではない理由の前記利用者からの連絡の有無、及び前記駐車状況が前記予約情報通りではない理由の少なくとも一方に基づいて、前記駐車状況に関する料金を算出する算出部と、
   取得された前記予約情報の中から、前記駐車状況が前記予約情報通りにならない可能性の高い前記予約情報である要変更予約情報を抽出する抽出部と、
   抽出された前記要変更予約情報を申請した前記利用者が使用する利用者端末に、前記駐車状況が前記予約情報通りではない理由の連絡を促す旨を通知する通知部と
   を具備する駐車場管理システム。
2. 請求項１に記載の駐車場管理システムであって、
   前記通知部は、抽出された前記要変更予約情報を申請した前記利用者からの前記駐車状況が前記予約情報通りではない理由の連絡がない場合に、前記理由の連絡を促す旨を通知する
   駐車場管理システム。
3. 請求項１又は２に記載の駐車場管理システムであって、さらに、
   前記利用者の精算操作を受け付ける精算操作受付部を具備し、
   前記精算操作受付部は、前記利用者の精算操作が前記要変更予約情報に関する精算操作である場合に、前記駐車状況が前記予約情報通りではない理由の連絡を促す旨を出力する
   駐車場管理システム。
4. 請求項３に記載の駐車場管理システムであって、
   前記精算操作受付部は、前記利用者の精算操作が前記要変更予約情報に関する精算操作であり、かつ前記利用者からの前記駐車状況が前記予約情報通りではない理由の連絡がない状態で前記算出部により前記駐車状況に関する料金が算出されている場合に、前記理由の連絡を促す旨を出力する
   駐車場管理システム。
5. 請求項３又は４に記載の駐車場管理システムであって、
   前記精算操作受付部は、前記利用者からの前記駐車状況が前記予約情報通りではない理由の連絡を受け付ける
   駐車場管理システム。
6. 請求項３から５のうちいずれか１項に記載の駐車場管理システムであって、
   前記精算操作受付部は、前記要変更予約情報に関する精算操作を行う前記利用者の前記利用者端末に前記通知部により前記理由の連絡を促す旨が通知された日時から所定の期間が経過した後は、前記理由の連絡を促す旨の出力を実行しない
   駐車場管理システム。
7. 請求項１から６のうちいずれか１項に記載の駐車場管理システムであって、
   前記抽出部は、交通機関に関する情報、渋滞に関する情報、及び自然現象に関する情報の少なくとも一方に基づいて、前記要変更予約情報を抽出する
   駐車場管理システム。
8. 請求項１から７のうちいずれか１項に記載の駐車場管理システムであって、
   前記予約情報は、出場予約日時に関する情報を含み、
   前記状況判定部は、前記駐車状況が前記予約情報通りか否かの判定として、前記出場予約日時に前記予約車両が出場したか否かを判定し、
   前記算出部は、前記駐車状況に関する料金の算出として、前記出場予約日時に前記予約車両が出場していない場合の超過料金を算出する
   駐車場管理システム。
9. 請求項８に記載の駐車場管理システムであって、
   前記算出部は、前記理由が所定の分類に含まれる場合は、第１の課金体系に基づいて前記超過料金を算出し、前記理由が前記所定の分類に含まれない場合は、前記第１の課金体系よりも課金レベルが高い第２の課金体系に基づいて前記超過料金を算出する
   駐車場管理システム。
10. 請求項９に記載の駐車場管理システムであって、
    前記算出部は、前記理由が前記利用者に起因しない理由である場合は、前記第１の課金体系に基づいて前記超過料金を算出し、前記理由が前記利用者に起因しない理由でない場合は、前記第２の課金体系に基づいて前記超過料金を算出する
    駐車場管理システム。
11. 請求項１０に記載の駐車場管理システムであって、
    前記利用者に起因しない理由は、交通機関に関する理由、渋滞に関する理由、及び自然現象に関する理由の少なくとも一方を含む
    駐車場管理システム。
12. 請求項９から１１のうちいずれか１項に記載の駐車場管理システムであって、
    前記第１の課金体系は、前記超過料金が０円となる課金体系である
    駐車場管理システム。
13. 請求項９から１２のうちいずれか１項に記載の駐車場管理システムであって、
    前記算出部は、前記理由の連絡がない場合は、前記第２の課金体系よりも課金レベルが高い第３の課金体系に基づいて、前記超過料金を算出する
    駐車場管理システム。
14. 請求項１から１３のうちいずれか１項に記載の駐車場管理システムであって、さらに、
    前記理由の真偽を判定する真偽判定部を具備し、
    前記算出部は、前記真偽判定部による判定結果に基づいて、前記駐車状況に関する料金を算出する
    駐車場管理システム。
15. 請求項１４に記載の駐車場管理システムであって、
    前記真偽判定部は、前記駐車場の他の利用者から連絡があった前記理由の真偽に基づいて、前記利用者から連絡があった前記理由の真偽を判定する
    駐車場管理システム。
16. 請求項１４又は１５に記載の駐車場管理システムであって、
    前記抽出部は、前記駐車場の他の利用者から連絡があり真であると判定された前記理由に基づいて、前記要変更予約情報を抽出する
    駐車場管理システム。
17. 駐車場の利用者から申請される予約情報を取得し、
    前記利用者の車両である予約車両の駐車状況が、前記予約情報通りか否かを判定し、
    前記駐車状況が前記予約情報通りではない場合に、前記駐車状況が前記予約情報通りではない理由の前記利用者からの連絡の有無、及び前記駐車状況が前記予約情報通りではない理由の少なくとも一方に基づいて、前記駐車状況に関する料金を算出し、
    取得された前記予約情報の中から、前記駐車状況が前記予約情報通りにならない可能性の高い前記予約情報である要変更予約情報を抽出し、
    抽出された前記要変更予約情報を申請した前記利用者が使用する利用者端末に、前記駐車状況が前記予約情報通りではない理由の連絡を促す旨を通知する
    ことをコンピュータが実行する情報処理方法。
18. 駐車場の利用者から申請される予約情報を取得するステップと、
    前記利用者の車両である予約車両の駐車状況が、前記予約情報通りか否かを判定するステップと、
    前記駐車状況が前記予約情報通りではない場合に、前記駐車状況が前記予約情報通りではない理由の前記利用者からの連絡の有無、及び前記駐車状況が前記予約情報通りではない理由の少なくとも一方に基づいて、前記駐車状況に関する料金を算出するステップと、
    取得された前記予約情報の中から、前記駐車状況が前記予約情報通りにならない可能性の高い前記予約情報である要変更予約情報を抽出するステップと、
    抽出された前記要変更予約情報を申請した前記利用者が使用する利用者端末に、前記駐車状況が前記予約情報通りではない理由の連絡を促す旨を通知するステップと
    をコンピュータに実行させるプログラム。

Images