(58)【調査した分野】(Int.Cl.,DB名)
複数の駐車場オーナーの各々に関するオーナー情報に関連付けて、前記複数の駐車場オーナーの各々が経営する駐車場で発生した事象に関する事象発生情報を記憶する記憶部と、
記憶された前記事象発生情報に基づいて、前記複数の駐車場オーナーの各々に前記駐車場で発生した事象を通知するための事象通知情報を生成して出力する出力部と、
記憶された前記事象発生情報に基づいて、前記複数の駐車場オーナーの各々が経営する前記駐車場で発生した事象が、当該駐車場において初めて発生した初出の事象か否かを判定する判定部と、
前記複数の駐車場オーナーの各々が前記事象通知情報の生成方法及び/又は出力方法を設定するためのWebページを生成する生成部と
を具備し、
前記生成部は、前記判定部の結果に基づいて、前記事象の履歴情報と、前記初出の事象に関する情報とを含むWebページを生成する
情報処理装置。
【発明を実施するための形態】
【0025】
以下、本発明に係る実施形態を、図面を参照しながら説明する。
【0026】
[駐車運営管理支援システム]
図1は、本発明の一実施形態に係る駐車場運営管理支援システムの構成例を示す概略図である。駐車場運営管理支援システム(以下、運営管理支援システムという)500は、本発明に係る情報処理システムの一実施形態として機能する。
【0027】
運営管理支援システム500は、オーナー端末10と、利用者端末15と、管理機関端末20と、保守・点検機関端末25と、駐車場装置30と、運営管理支援装置40とを有する。これらの端末及び装置は、インターネット1及び広域通信回線網5を介して相互に通信可能に接続されている。
【0028】
オーナー端末10は、駐車場31を経営する駐車場オーナーにより使用される。本実施形態では、中小規模の駐車場31の個人オーナーA、B、及びCにより、運営管理支援システム500が利用される。オーナーAにより駐車場Aが経営され、オーナーBにより駐車場B1及びB2が経営される。またオーナーCにより、駐車場Cが経営される。
【0029】
なお運営管理支援システム500を利用可能な駐車場オーナーの数や、駐車場31の所在地等は限定されない。例えば全国に点在する複数の駐車場オーナーが運営管理支援システム500を同時に利用することが可能である。また個人オーナーのみならず、大規模な駐車場を経営する企業等の法人が、運営管理支援システム500を利用することも可能である。
【0030】
利用者端末15は、駐車場31を利用する利用者により使用される。
【0031】
管理機関端末20は、駐車場オーナーから駐車場31の管理業務を委託された管理機関21のオペレーターにより使用される。例えば駐車場31を利用する利用者からの日常の問合せや、駐車場装置30等に関する問い合わせの対応が行われる。
【0032】
保守・点検機関端末25は、駐車場31の保守メンテナンスを担う保守・点検機関26の作業員等により使用される。作業員は、定期的に駐車場装置30を含む駐車場31内の機器等を点検する。また緊急の事象(障害)等が発生した場合には、作業員が駐車場31に急行し、1次対応等を行う。
【0033】
図1では、保守・点検機関端末25が1つ図示されている。実際は、保守・点検機関26は、駐車場オーナーごとに適宜選択されるものである。例えば駐車場31の所在地に応じて、保守・点検機関26が選択され、駐車場オーナーとの間で委託契約等が結ばれる。駐車場オーナーごと(駐車場31ごと)に選択される保守・点検機関端末25が、運営管理支援システム500に通信可能に接続される。同様に管理機関21及び管理機関端末20も、駐車場オーナーごとに適宜選択されてよい。
【0034】
なお駐車場オーナー自身で、駐車場31の管理業務や、保守・点検を行う場合もある。この場合、当該駐車場31に関しては、管理機関21や保守・点検機関26は選択されない。また管理業務と保守・点検の両方を実行する機関が利用される場合もあり得る。
【0035】
オーナー端末10、利用者端末15、及び各機関の端末20及び25としては、ノートPC(Personal Computer)、デスクトップPC、スマートフォン、及びタブレット端末等の任意のコンピュータが用いられてよい。
【0036】
駐車場装置30は、各駐車場31に設置され、駐車場31を利用する利用者への駐車券の発行や駐車料金の精算等を実行する。駐車場装置30の前面には、例えば駐車券の発行口や挿入口、紙幣・硬貨投入口、表示部、領収証ボタン、釣り銭や領収証の取出口等が設けられる。本実施形態では、駐車場装置30として、駐車券発行機50及び出口精算機70が設置される(
図2参照)。
【0037】
運営管理支援装置40は、運営管理支援機関41により使用される装置であり、本実施形態に係る運営管理支援サービスを、Webサービスとして提供可能である。本実施形態では、複数のサーバ装置42と、データベース(DB)43とにより運営管理支援装置40が構成される。
【0038】
各サーバ装置42は、CPU(Central Processing Unit)、ROM(Read Only Memory)、RAM(Random Access Memory)、HDD(Hard Disk Drive)等のコンピュータの構成に必要なハードウェアを有する。CPUが所定のプログラムを実行し、サーバ装置42内のハードウェア資源と協働することで、出力部、生成部、判定部、及び使用判定部が実現される。プログラムは、例えば種々の記録媒体を介して、あるいはインターネット1等を介してサーバ装置42にインストールされる。
【0039】
DB43は、記憶部として機能し、運営管理支援サービスに関する種々の情報を記憶する。例えばDB43内には、オーナー情報DB、駐車場情報DB、在車DB、及び履歴DB等の、種々のDBが構築される。
【0040】
各種のDBは、運営管理支援装置40内のDBサーバにより包括的に管理され、例えば各駐車場オーナーに関するオーナー情報の登録及び保管等が実行される。また各駐車場オーナーが経営する駐車場31に関する駐車場関連情報が記憶される。
【0041】
駐車場関連情報は、駐車場31に関する種々の情報を含む。例えば運営収支情報等の駐車場の経営に関する経営情報、満空車情報等の駐車場の利用状況に関する利用情報、及び釣銭管理状況等の管理情報等が、駐車場関連情報として記憶される。また駐車場装置30から発生した障害等に関する事象発生情報が送信された場合には、当該事象発生情報が駐車場関連情報として記憶される。
【0042】
その他、駐車場装置30、管理機関端末20、保守・点検機関端末25から出力される種々の情報、これらの情報をもとに売上や利用台数等を集計した情報、月報や週報等の帳票のデータ等も、駐車場関連情報として記憶される。
【0043】
図2は、駐車場31に設置される、駐車券発行機、出口精算機、及び通信管理装置の機能的な構成例を示すブロック図である。
【0044】
駐車券発行機50は、駐車場31の入口ゲート33に隣接して設置される。駐車券発行機50は、CPU51と、メモリ52と、これらとバス53を介して接続されるインターフェイス54とを有する。メモリ52は、例えばROM、RAM、フラッシュメモリ等から構成され、種々のプログラムや種々の駐車データ等が記憶される。
【0045】
インターフェイス54には、カードリーダライタ55、カードフィーダ56、表示器/スピーカ57、操作釦58、ゲート開閉機制御部59、車両センサ60、及び通信制御部61が接続される。各ブロックの動作は、プログラムに従って動作するCPU51により制御され、例えば表示器/スピーカ57による表示画面及び音声ガイドに基づいて、利用者は円滑に操作を行うことが可能である。例えば音声ガイド等に従って利用者により操作釦58が押される。これに応じて、ガードフィーダ56が動作し、発行口から駐車券が発行される。
【0046】
カードリーダライタ55は、利用者に供給される駐車券の磁気ストライプに所定の情報を書き込み、また駐車券の表面に所定の情報を印字する。車両センサ60は、所定の場所に埋設されたループコイル35からの信号をもとに、入場レーンへの車両の進入や車両の通過等を検出する。ゲート開閉機制御部59は、入口ゲート33を開閉するゲート開閉機を制御する。通信制御部61は、出口精算機70と通信を行うための通信回路を備え、駐車場31に埋設された内部通信ラインを介して、出口精算機70の通信制御部82と通信可能に接続される。
【0047】
出口精算機70は、駐車場31の出口ゲート34に隣接して設置される。出口精算機70は、バス73を介して互いに接続されるCPU71、メモリ72、及びインターフェイス74を有する。インターフェイス74には、カードリーダライタ75、紙幣・硬貨管理部76、表示器/スピーカ77、領収証プリンタ78、操作釦79、ゲート開閉機制御部80、車両センサ81、及び通信制御部82が接続される。
【0048】
カードリーダライタ75は、挿入口に挿入された駐車券から駐車券情報を読み込み、駐車時間及び割引情報をもとに、精算金額を算出する。紙幣・硬貨管理部76は、紙幣・硬貨投入口に投入された紙幣等を受け取り、計数して投入金額を算出する。また精算により必要となった釣り銭等を計数し、紙幣・硬貨返却口に払い出す。領収証プリンタ78は、領収証に精算額や日時等をプリントして発行する。
【0049】
通信制御部82は、通信管理装置85と通信を行うための通信回路を備え、通信管理装置85の外部通信部93にシリアル通信用の配線を介して通信可能に接続される。また通信制御部82は、駐車券発行機50の通信制御部61と通信可能に接続される。
【0050】
通信管理装置85は、出口精算機70の上部等に取り付けられ、広域通信回線網5及びインターネット1を介して運営管理支援装置40に通信可能に接続される。通信管理装置85は、バス88を介して互いに接続されるCPU86、メモリ87、及びインターフェイス89有する。インターフェイス89には、カメラ90、インターフォン91、データ端末装置(DCE:Data Circuit Terminating Equipment)92、及び外部通信部93が接続される。
【0051】
カメラ90及びインターフォン91は、出口精算機70を操作する利用者と、管理機関端末20を使用するオペレーターとの通話を可能にする。データ端末装置92は、出口精算機70等から送信される信号を広域通信回線用の信号に変換する装置であり、例えばモデムやターミナルアダプタ等が用いられる。外部通信部93は、出口精算機70の通信制御部82と通信可能に接続される。
【0052】
駐車券発行機50及び出口精算機70により取得された情報は、通信管理装置85を介して、運営管理支援装置40に送信される。例えば車両の入庫及び出庫、駐車料金の収支、割引結果、障害発生情報、故障履歴、定期券の更新に関するデータ等が運営管理支援装置40に送信される。
【0053】
また管理機関21のオペレーターが遠隔操作を行う場合には、管理機関端末20から通信管理装置85に遠隔操作信号が送信される。そして通信管理装置85から駐車券発行機50及び出口精算機70に遠隔操作信号が送信され、遠隔操作が実行される。遠隔操作信号が、運営管理支援装置40を介して、通信管理装置85に送信されてもよい。
【0054】
図3は、運営管理支援装置40の機能的な構成例を示すブロック図である。
図4は、運営管理支援装置40により実行可能な運営管理支援サービスの一例である。
【0055】
運営管理支援装置40は、売上集計部101、利用台数集計部102、データ分析部103、事象監視部104、文章自動修正部105、メール配信部106、及びWebページ作成部107を有する。これらのブロックは、例えば運営管理支援装置40内の、DBサーバ、メールサーバ、Webサーバ等の種々のサーバ装置42により実現される。
【0056】
売上集計部101及び利用台数集計部102により、日毎又は月毎(さらに期間毎や年毎)の売上及び利用台数が集計される。データ分析部103は、DB43に記憶された駐車場関連情報を分析し、例えば経営分析結果として出力する。事象監視部104は、駐車場31での障害(エラー)やその他の事象(利用者からの呼び出しや盗難など、障害ではない事柄)の発生を監視する。例えば駐車場31から事象発生情報を受信した場合には、事象を通知するための事象通知情報を生成する。文章自動修正部105は、主に通知情報の生成時に動作するブロックであり、詳しくは後述する。
【0057】
メール配信部106は、駐車場オーナーに通知される種々の通知情報を、メールにて送信する。Webページ作成部107は、例えばWWW(World Wide Web)システムを用いて、運営管理支援サービスを提供するためのWebページを生成する。駐車場オーナー、利用者、及び各機関のオペレーター等は、自身の端末を用いて、Webブラウザを介してWebページにアクセスする。これにより容易に運営管理支援サービスを利用することが可能となる。
【0058】
図4に示すように、具体的なサービス内容としては、例えば「速報サービス」「経営分析サービス」「帳票・明細発行サービス」「駐車場情報配信サービス」「設定機能」「利用履歴」及び「メール配信サービス」が挙げられる。各サービスは、
図3に示す各ブロックが適宜動作することで実現される。もちろんこれらのサービスに限定される訳ではない。また一部のサービスのみが実行可能であってもよい。
【0059】
本実施形態では、運営管理支援装置40により、駐車場オーナーごとに通知情報が生成され、各オーナー端末10に出力される。通知情報は、駐車場に関する種々の通知を含み、DB43に記憶された駐車場関連情報をもとに生成される。例えば
図4に示すサービスにより駐車場オーナーに提供される種々の情報は、通知情報に含まれる。例えば売上や利用台数等を表すグラフ等を含む集計・分析情報、駐車場31で発生した障害等の事象に関する事象通知情報、月報等の帳票データ等が、通知情報として出力される。
【0060】
通知情報の生成方法や出力方法は限定されず、例えば駐車場オーナーごとに独自に設定可能である。通知情報の生成方法とは、どのような内容の通知情報をどのように生成するかを含み、メールの本文やWebページのレイアウト等も含まれる。通知情報の出力方法は、通知情報をどのように出力するかを含み、例えばメールで送信するか、Webページにて端末に表示させるかといったことを含む。またFAXやSNS等により、通知情報が送信されてもよい。また出力方法として、複数の通知情報を所知のタイミングでまとめて出力するか、あるいは通知情報をリアルタイムで出力するか、といったことも設定可能である。
【0061】
例えば運営管理支援装置40のWebページ作成部107により、通知情報の生成方法や出力方法を設定するためのWebページが生成され、各オーナー端末10に送信される。各駐車場オーナーは、その設定用のWebページを用いて、通知情報の内容や通知のタイミング等を自由に設定することが可能である。設定された生成方法及び出力方法は、DB43に記憶される。
【0062】
駐車場オーナーごとに、通知情報の生成方法や出力方法を適宜設定することが可能であるので、例えば駐車場オーナーごとの運営方針や管理方針等に沿った有用な情報を、各々が理解しやすい形で取得することが可能となる。特に駐車場オーナーが個人オーナーである場合等において、独自の情報を取得可能であることは非常に有効である。
【0063】
図1に示すように、本実施形態では、駐車場装置30を製造する装置製造会社により、運営管理支援機関41が構成されている。これにより駐車場装置30が故障した場合等の事象発生時において、事象内容の情報や保守メンテナンス作業の情報等を、迅速また正確に、駐車場オーナーや保守・点検機関26に出力することが可能となる。もちろんこの構成に限定されるわけではない。
【0064】
[障害発生時の動作]
図5は、駐車場31で事象が発生した場合の動作を説明するための模式図である。ここではオーナーAが経営する駐車場Aにて事象として装置の障害が発生した場合を例に挙げて説明する。なお、事象には装置の障害以外に、障害には含まれない事象として、例えば利用者からの問い合わせ、満車情報、満車解除情報、盗難情報などがあるが、これ以降は装置の障害について説明する。駐車場Aで障害が発生した場合、駐車場装置30から運営管理支援装置40へ、事象発生情報として障害発生情報が送信される。障害発生情報には、発生した障害に応じたエラーコードが含まれる。なお運営管理支援装置40側から定期的に障害発生情報の有無が問い合わされてもよい。
【0065】
運営管理支援装置40は、受信した障害事象発生情報を、駐車場関連情報としてDB43に記憶させる。運営管理支援装置40は、記憶された障害発生情報をもとに、駐車場オーナーごとに設定された生成方法及び出力方法に基づいて、障害通知情報を事象通知情報として生成して出力する。
【0066】
本実施形態では、駐車場オーナーごとのオーナー情報と、エラーコードに関連付けられたエラー定義情報とをもとに障害通知情報が生成され、障害通知メール45にて送信される。オーナー情報及びエラー定義情報の中に、生成方法として、どのような文章を作成するかといったことが記憶される。また出力方法として、メール配信の有無や、メール配信の方法等が記憶される。
【0067】
図6は、オーナー情報の一例を示す図である。例えば駐車場オーナーごとのオーナー情報110として、「オーナー基本情報」「駐車場情報」「メンテナンス情報」及び「エラー定義更新情報」が記憶される。「オーナー基本情報」は、駐車場オーナーを識別するためのオーナーIDや、障害通知メール45をメールで送信するためのメールアドレス等を含む。
【0068】
「駐車場情報」は、駐車場オーナーが経営する駐車場31の情報である。「メンテナンス情報」は、駐車場オーナーが委託契約等をしているメンテナンス会社等に関する情報である。すなわち保守・点検機関26の情報が、「メンテナンス情報」に相当する。
【0069】
「エラー定義更新情報」は、エラーコードに関連付けられるエラー定義情報が、駐車場オーナーにより更新されたか否かの情報を含む。
図6に示すように、エラー定義情報が更新されたエラーコードと、更新された内容が記憶されている。
【0070】
図7は、エラー定義情報の保持方法を模式的に示す図である。
図7に示すように、駐車場オーナーごとに、エラーコードに関連付けてエラー定義情報が記憶される。
図7に示す例では、エラー定義情報に含まれる「エラー定義名」(
図8B参照)が、エラー定義情報として図示されている。例えばエラーコード「008」については、オーナーAのオーナー情報に関連付けられて、エラー定義名が「EV充電時間超過車警報」であるエラー定義情報が記憶される。
【0071】
またオーナーBのオーナー情報には、「エラー定義名」が「パーク&チャージ時間超過車警報」であるエラー定義情報が関連付けられて記憶される。オーナーCのオーナー情報には、「エラー定義名」が「EV充電時間超過車警報」であるエラー定義情報が関連付けられて記憶される。他のエラーコードについても同様に、駐車場オーナーごとにエラー定義情報がそれぞれ記憶される。
【0072】
なお上記したように、本実施形態では、駐車場装置30を製造する装置製造会社により、運営管理支援機関41が構成されている。DB43には、エラーコードに関連付けて、運営管理支援機関41が予め定めたエラー定義情報が記憶されている。当該運営管理支援機関41が予め定めたエラー定義情報は、初期情報として記憶されている。
【0073】
図7にて黒文字で示すエラー定義情報は、運営管理支援機関41が予め定めたエラー定義情報であり、駐車場オーナーにより更新が実行されていない情報である。白文字で示すエラー定義情報は、駐車場オーナーにより初期情報が更新されたエラー定義情報である。
【0074】
なお駐車場オーナーが保守・点検機関26を利用する場合には、保守・点検機関26の情報に関連付けて、エラー定義情報がエラーコードごとに記憶される。
【0075】
図8は、エラー定義情報の一例を示す図である。
図8Aに示すエラー定義情報111は、障害通知メール45の配信方法に関する情報である。エラーコードに関連付けられて「エラーレベル」「エラー定義名」「オーナー配信の有無」「メンテ配信の有無」が記憶される。運営管理支援装置40は、エラー定義情報111を参照して、オーナー端末10への障害通知メール45の配信の有無、及び保守・点検機関端末25への障害通知メール45の配信の有無を判定する。
【0076】
駐車場31で発生する障害としては、種々のものが挙げられ、その数は多い。例えば全ての障害について、駐車場オーナーに障害通知メール45を送信すると、大量のメールにより駐車場31の運営管理が妨げられる可能性もある。例えばエラーレベルや緊急性、障害の内容等によっては、駐車場オーナーに障害通知メール45を送信することなく、後に改めて報告するといったことも有効である。
【0077】
図8Aに示すエラー定義情報は、全ての駐車場オーナーに共通の情報として記憶されてもよい。そして駐車場オーナーごとに表示される設定用のWebページをもとに、個別に配信方法の設定が更新されてもよい。
【0078】
図8Bに示すエラー定義情報112は、エラー定義情報の具体例である。本実施形態では、「エラーコード」に関連付けて、以下の情報が記憶される。
「管理番号」:管理用の番号
「分類」:例えば障害内容等による分類を表す情報
「エラーレベル」:障害のレベル、緊急度等をレベル別に表す
「エラー定義名」:障害の名前
「詳細説明」:障害の内容の説明
「モニタ表示」:駐車場装置30のモニタへの表示の有無
「メール配信レベル」:メールの重要度
「メール配信内容」:メールの本文に用いられる文言
「メール送信」:オーナー端末10へのメール送信の有無
「メール同一送信」:所定のタイミングでまとめて送信するか個別に送信するかの情報
「表示形式」:メール内の文章の表示形式
「文言流用許可」:駐車場オーナーが設定した文言を、他の駐車場オーナーへの通知情報として流用してもよいか否かの情報
【0079】
図9は、障害通知メール45の作成の一例を示すフローチャートである。事象監視部104により、駐車場31での障害の発生が監視される(ステップ101)。駐車場装置30から障害発生情報を受信すると障害が発生したと判定され(ステップ101のYes)、障害発生情報に含まれるエラーコードが読み取られる(ステップ102)。
【0080】
エラーコードに関連付けられたエラー定義情報が更新済みか否か判定される(ステップ103)。エラー定義情報が更新済みの場合には(ステップ103のYes)、更新されたエラー定義情報が読み出される(ステップ104)。本実施形態では、エラー定義情報として「メール配信内容」が読み取られる。
【0081】
エラー定義情報が更新されていない場合には(ステップ103のNo)、初期情報として記憶されたエラー定義情報に含まれる「メール配信内容」が読み出される(ステップ105)。そして初期情報のエラー定義情報が、定義更新候補としてセットされる。例えばエラーコードに、更新候補である旨を示すフラグ情報が紐付けられる(ステップ106)。
【0082】
障害発生情報内に他のエラーコードが含まれるか否か判定される(ステップ107)。他のエラーコードが存在する場合には(ステップ107のYes)、当該エラーコードに対して同様の処理が繰り返される(ステップ103〜107)。
【0083】
他のエラーコードが存在しない場合には(ステップ107のNo)、障害通知メール45の内容となるメール文が作成される。メール文は、エラー定義情報に含まれる「メール配信内容」をもとに作成される(ステップ108)。メール文が作成されると、障害通知メール45が送信される(ステップ109)。
【0084】
図10は、障害通知メール45の一例を示す図である。障害通知メール45は、「件名」及び「本文」からなり、「件名」は、エラー通知である旨、エラーレベル、駐車場オーナー名、及び駐車場名を含む。「本文」は、宛名、エラー/アラーム情報115、コード情報、メールアドレス、及びメール説明文を含む。
【0085】
エラー/アラーム情報115は、駐車場名と、駐車場装置30と、エラーの発生時間(又はメール送信時間)と、エラーの内容の説明文とを含む。この中のエラーの内容の説明文には、ステップ105にて読み出された「メール配信内容」が記載される。
【0086】
コード情報は、予め定められた分類コードと、エラーコード及び障害発生回数を表す「008−001」が記載される。「本文」の最後には、アドレス情報及びメール説明文が記載される。これらはテンプレート(定型文)である。
【0087】
図11は、オーナー端末10に表示されるエラー情報画面(Webページ)の一例である。例えば障害通知メール45を受け取った駐車場オーナーは、エラー情報ボタン120を選択することで、エラー情報画面121を表示させることができる。障害通知メール45内に、エラー情報画面121へのリンク(URL等)が表示されてもよい。
【0088】
エラー情報画面121は、履歴タブ122と、エラーコードタブ123とを含む。履歴タブ122が選択されると、現在の障害の発生の有無の情報と、過去に発生した障害の履歴情報とが表示される。
図11に示すように、エラーコードが008、012、023、及び003が、障害の発生時刻とともに表示される。そのうち、エラー定義情報が更新済みのエラーコード003の横には、その旨が表示される。
【0089】
上記したように、未更新のエラー定義情報(エラーコード)は、定義更新候補としてセットされている。定義更新候補として設定された未更新のエラー定義情報については、エラーコードタブ123が形成され、履歴タブ122の横に順に表示される。これにより未更新のエラー定義情報を容易に把握することが可能となる。
【0090】
エラー定義情報が未更新であるエラーコードに対応する障害は、本実施形態において、駐車場31で初めて発生した初出の障害(初出の事象)に相当する。また
図11に示すエラー情報画面121は、障害の履歴情報と、初出の障害に関する情報(エラーコードタブ123)を含むWebページに相当する。
【0091】
本実施形態では、判定部により、エラー定義情報の更新の有無に基づいて、駐車場31で発生した障害が初出の障害か否かが判定される。もちろんこれに限定される訳ではない。
【0092】
駐車場オーナーは、エラーコードタブ123を選択することで、未更新のエラーコードのエラー定義情報の詳細を表示させることができる。すなわち
図11にて履歴情報が表示されている領域に、
図8Bに示すエラー定義情報を表示させることが可能となる。
【0093】
未更新のエラーコードタブ123の中のひとつを選択すると、そのエラーコードのエラー定義情報の設定画面に移動する。すなわち、エラーコードタブ123は、初出の障害に関するエラー定義情報を設定するためのWebページへのリンクとなっている。なお、設定ボタン124を選択した場合は、初出の障害の一覧が表示され、個々のエラー定義情報を設定するためのWebページが選択できる。
【0094】
図12は、エラー定義情報を設定するための定義設定画面の一例を示す図である。定義設定画面130は、定義項目131、保存データ132、及び設定データ133とを含む。定義項目131には、エラー定義情報の各項目が表示される。保存データ132は、記憶されているエラー定義情報が表示される。
図12に示す例では、エラーコード008の、初期情報としてのエラー定義情報が表示される。
【0095】
設定データ133は、駐車場オーナーにより入力される情報である。例えば障害の内容を表現する文言(事象の内容を表現する文言)等について、駐車場オーナーごとに、理解がしやすい文言等が異なる場合が多い。例えば駐車場オーナーごとに、使い勝手がよい文言や馴れ親しんでいる文言等がそれぞれ存在すると考えらえる。本実施形態では、定義設定画面130を用いて、障害の内容を表現する文言を、自由に設定することが可能である。なお定義設定画面130は、障害の内容を表現する文言を設定するためのWebページに相当する。また通知情報の生成方法及び出力方法の少なくとも一方(生成方法及び/又は出力方法)を設定するWebページに含まれる。
【0096】
図12に示す例では、「エラー定義名」及び「エラー配信内容」内の「EV充電」という文言が、「楽Pチャージ」という文言へ変更されている。特に「メール配信内容」の設定データを見てみると、丁度「EV充電」という部分を変更するための入力欄134が表示されている。本実施形態では、この入力欄134に「楽Pチャージ」と入力することで、エラーコード008のエラー情報について、「EV充電」という文言が「楽Pチャージ」という文言に置き換えられる。
【0097】
例えば
図12に示す設定データ133が入力されたとする。すなわち確認ボタン135から確認画面に移動し、そこでOKボタン等が選択されたとする。そうすると設定データ133がエラー定義情報としてDB43に記憶され、エラーコード008のエラー定義情報は、更新済みとなる。ステップ108のメール文作成処理では、
図10に示すエラー/アラーム情報115内の「EV充電:時間超過車両発生」に代えて「楽Pチャージ:時間超過車両発生」が記載される。
【0098】
またエラー/アラーム情報115内[EV充電対応料金精算機]についても、[楽Pチャージ対応料金精算機]と文言が置き換えられる。すなわち定義設定画面130で設定した文言への置き換えが、他の文へも適用される。この際には、
図3に示す文章自動修正部105が動作する。例えば典型的には、エラー通知情報内から「EV充電」という文言が検索され、「楽Pチャージ」という文言に修正される。
【0099】
図13は、運営管理支援装置40により通知情報として生成される売上月報を模式的に示す図である。売上月報140には、駐車場31の経営に関するアドバイス情報141が表示される。
図13に示す例では、アドバイス情報141として、駐車場31のEV充電スタンドの使用率と、充電完了後の駐車時間の超過についての文章(テキスト)が表示されている。
【0100】
エラー定義情報が未更新の場合には、「EV充電での使用率が〜」と記載されるところ、文言が置き換えられて「楽Pチャージでの使用率が〜」という文章が記載される。このようにエラー定義情報として記憶された文言を含むアドバイス情報141が生成されてもよい。これにより駐車場オーナーにとって理解しやすい文言等が使用されることになるので、駐車場31の運営状況や利用状況等を容易に把握することが可能となる。もちろんアドバイス情報141に限定されず、任意の他の通知情報に、エラー定義情報として設定された文言が援用されてもよい。
【0101】
その他、駐車場オーナーは、
図11に示す駐車場選択、在車状況、提携店舗情報、経営分析、帳票出力、メール通知、及びオペレーターとの通話、の各ボタンを適宜操作することで、必要な情報の取得、帳票の出力、メールの送受信等を実行することができる。
【0102】
駐車場オーナーの各ボタンの操作に応じて、運営管理支援装置40は、DB43に記憶された駐車場関連情報をもとに、種々の通知情報を生成して、オーナー端末10に出力する。その際には、例えばエラー定義情報として設定された文言が適宜援用される。なお通知情報の生成方法及び出力方法を設定するためのWebページのレイアウト等は限定されず、適宜設定されればよい。また生成方法のみが設定可能、あるいは出力方法のみが設定可能である場合も考えられる。
【0103】
以上、本実施形態に係る運営管理支援システム500では、複数の駐車場の駐車場オーナーごとに種々の駐車場関連情報が記憶される。そして駐車場オーナーごとに障害通知情報等を含む種々の通知情報が生成されて出力される。これにより駐車場31の運営や管理等を効率的に支援することが可能となる。なお駐車場オーナーとは、必ずしも経営者のトップという意味に限定されるわけではなく、経営機関の運営管理に携わる代表者等も含まれる。
【0104】
また運営管理支援システム500では、複数の駐車場オーナーの各々の運営管理を支援するためのリソースを共有することが可能となる。これによりシステムの構築や開発に係るコストの負担を分散できるので、個々の駐車場オーナーに対してのカスタム仕様の際のシステム開発費などの負担を抑制することができる。この結果、駐車場オーナーにとっては、安価な契約条件で有用な運営管理支援システム500を導入することが可能となる。
【0105】
また障害通知メール45等を含む通知情報内で、駐車場オーナーごとに障害(事象)の内容を表す文言として、独自の技術用語を設定することが可能であるので、緊急を要する保守作業等の発生時に、最も理解しやすい技術用語で情報を取得することが可能となる。この結果、適正な対応や処置等をすばやく講じることが可能となる。
【0106】
例えば
図5に示すように、障害発生時に、障害通知メール45をリアルタイムで駐車場オーナー、保守・点検機関26、及び装置製造会社の対応部門等に、送信することが可能となる。これにより緊急を要する場合でも、迅速に適正に対応することが可能となる。例えば装置製造会社については、初期状態となるエラー定義情報をもとに障害通知メール45が送信される。装置製造会社のオペレーターは、当該障害通知メール45をもとに正確に状況を把握し、保守・点検機関26にメンテナンス作業の情報等を出力することが可能となる。
【0107】
保守・点検機関26は、障害通知メール45をもとに、現場での1次対応等を迅速に実行することが可能となる。必要であれば、電話等を介して装置製造会社のオペレーターや駐車場オーナーから情報を取得することが可能となる。
【0108】
なお保守・点検機関26への障害通知メール45内の文言を、独自の技術用語に置き換えることも可能である。例えば駐車場オーナーにより設定された文言が用いられてもよい。あるいは保守・点検機関26により独自に使用される用語等が用いられてもよい。保守・点検機関26により、初期状態のエラー定義情報を更新することで、簡単に独自の用語を設定することができる。
【0109】
この場合、運営管理支援装置40により、駐車場オーナー用の障害通知メール45(障害通知情報)と、保守・点検機関(メンテナンス機関)26用の障害通知メール45(障害通知情報)とがそれぞれ作成される。これにより、保守・点検機関26にとって、最も理解しやすい技術用語が用いられた障害通知メール45が作成されることになり、さらに迅速な対応が実現される。
【0110】
図11に示すように、初出の障害(事象)については、エラーコードタブ123で表示される。これにより初出の障害の内容を優先的に把握することが可能となる。また初出の障害について、エラー定義情報の設定を簡単に実行することも可能となる。この結果、用語の変更等を簡単に実行することができる。またエラーコードタブ123は、直近に発生した障害から順に表示される。従って発生した障害の内容の記憶が多く残っているうちにエラー定義情報の更新が可能となり、例えば実情に沿ったわかりやすい文言の設定等が可能となる。
【0111】
また
図13に示すように、駐車場オーナーごとに蓄積されたエラー定義情報に含まれる、駐車場オーナーごとの独自の技術用語情報を、経営分析アドバイス等に活用することが可能となる。この作業は、文章自動修正部105により自動に行われるので、例えば運営管理支援機関41のアドバイス情報141の作成者が文言の置き換え等を実行する必要はない。すなわち作成者の負担を増大させることなく、駐車場オーナーにとって有益で理解しやすいアドバイス情報141を作成することが可能となる。
【0112】
<その他の実施形態>
本発明は、以上説明した実施形態に限定されず、他の種々の実施形態で実現することができる。
【0113】
図7に示すように、白文字で示すエラー定義情報は、オーナーA〜Cの各々の独自の文言が設定されている。特に各エラー定義名の1行目の文言が、
図12に示す「メール配信内容」に入力される文言に相当する。例えばエラーコード008について、オーナーBは「パーク&チャージ」という文言を設定している。
【0114】
このような駐車場オーナーごとに設定された文言が、共通使用可能であってもよい。共通使用可能とは、所定の駐車場オーナーが所定のエラーコードに関連付けて設定した文言を、他の駐車場オーナーの同じエラーコードに関連付けて設定可能とすることを意味する。例えば表現上非常に解りやすく広範囲に活用できるものである文言については、その文言を設定した駐車場オーナーのみならず、他の駐車場オーナーの通知情報にも適用させる。典型的には、未更新のエラー定義情報である場合に、他の駐車場オーナーが設定した文言が共通使用の文言として設定される。共通使用の文言が設定されたエラー定義情報は、未更新のエラー定義情報として記憶される(更新済みとはならない)。
【0115】
例えば「パーク&チャージ」という文言が、世間での使用態様や現場の意見等をもとに、非常に解りやすい文言であり使用を求める文言として判定されたとする。この場合、全てのオーナー情報のエラーコード008について、未更新のエラー定義情報については、初期情報である「EV充電」から「パーク&チャージ」に自動的に変更され、DB43に記憶される。これにより初期情報がより解りやすい文言により構成されることとなり、駐車場オーナーや保守・点検機関26による運営管理等に有効となる。
【0116】
なお
図12等に示すエラー定義情報内の「文言流用許可」が不可となっている場合には、共通使用は許可されない。このように駐車場オーナーにより、共通使用を規制することも可能である。共通使用可能な文言であるか否かは、使用判定部により適宜判定される。
【0117】
所定の駐車場オーナーが設定した文言が、登録商標であるか否かが判定されてもよい。文言が登録商標である場合には、当該文言は共通使用が可能な文言ではないと判定される。これにより当該文言が他の駐車場オーナーへの障害通知メール45やアドバイス情報141に広く使用されてしまい、普通名称化してしまうことを回避することが可能となる。その結果、商標登録した駐車場オーナーの権利を尊重することが可能となり、信頼関係を築くことが可能となる。
【0118】
なお文言を設定した駐車場オーナーにより商標登録がなされているか否かは、例えば特許庁の検索システムにアクセスすることが判定可能である。また駐車場オーナーにより商標登録の有無が入力されてもよい。
【0119】
上記では、障害通知情報の生成方法として、障害通知メールの本文に記載される文言の設定方法を説明した。これに限定されず、エラーコードごとに長い文章等が紐付けられ、当該文章等を含む障害通知メールが作成されてもよい。例えば駐車場オーナーには、障害の内容を詳細に説明した文章がメール送信される。駐車場オーナーにより、当該文章はいつでも変更可能である。一方、保守・点検機関26には、障害発生箇所や1次対応の詳細等がメール送信される。その内容等も、保守・点検機関26により、適宜変更されてよい。
【0120】
図1に示す管理機関21にも障害通知メール45を含む通知情報が出力されてよい。当該通知情報に関して、管理機関21ごとに、通知情報の生成方法及び出力方法がカスタマイズ可能であってもよい。例えば管理機関21ごとにエラー定義情報が適宜設定されてもよい。
【0121】
また障害通知メール45の出力方法として、所定のタイミングでまとめて送信するか、個別に送信するかの設定が行われる(
図12参照)。例えばエラーレベルの低い障害については、毎日所定の時間にまとめて障害通知メール45が送信される。一方エラーレベルの高い障害については、障害の発生時にリアルタイムで障害通知メール45が送信される。その他、出力方法として、種々の条件が設定されてよい。
【0122】
本発明が適用可能な駐車場の構成は全く限定されない。駐車券発行機50及び出口精算機70の2つの駐車場装置30が設置される場合のみならず、例えば駐車場装置30として精算機が1つ設置される構成でもよい。またゲート式駐車場にも限定されず、個別ロック式(フラップ式)駐車場や立体式(機械式)駐車場等にも、本発明は適用可能である。また駐車券発行機50及び出口精算機70が出力する情報を管理する駐車場サーバが、駐車場装置30として用いられてもよい。
【0123】
本開示では、車両は、自動車に限定されず、自転車や二輪車(バイク)等も含む。すなわち上記で説明した駐車場は、自転車等を駐車するための駐輪場を含む概念である。
【0124】
以上説明した本発明に係る特徴部分のうち、少なくとも2つの特徴部分を組み合わせることも可能である。すなわち各実施形態で説明した種々の特徴部分は、各実施形態の区別なく、任意に組み合わされてもよい。また上記で記載した種々の効果は、あくまで例示であって限定されるものではなく、また他の効果が発揮されてもよい。
【0125】
また本発明は、請求の範囲及び明細書全体から読み取ることのできる発明の要旨又は思想に反しない範囲で適宜変更可能であり、そのような変更を伴う駐車場運営管理支援システムもまた本発明の技術思想に含まれる。