JP2020160861A

JP2020160861A - 審査サーバ及び審査方法

Info

Publication number: JP2020160861A
Application number: JP2019060405A
Authority: JP
Inventors: 知平増田; Tomohira Masuda
Original assignee: Hatch Work Co Ltd
Current assignee: Hatch Work Co Ltd
Priority date: 2019-03-27
Filing date: 2019-03-27
Publication date: 2020-10-01
Anticipated expiration: 2039-03-27
Also published as: JP2023178426A; JP7378761B2

Abstract

【課題】駐車場の賃貸借契約を締結することを希望する駐車場利用希望者に対して行われる審査を迅速なものとできる仕組みを提供する。【解決手段】駐車場の利用に対する審査を行う審査サーバであって、審査に用いられる情報を取得する情報取得手段と、証明書の画像データを画像解析して文字列情報である証明書情報を抽出する画像解析手段と、車両に関する車両情報と、証明書情報と、利用者の個人又は法人に関連する個人情報と、のうちの少なくとも一つに基づいて審査を行う審査実行手段と、審結果を出力する出力手段と、を有し、出力手段は、審査サーバの審査実行手段が審査を行うクイック審査が実施できる駐車場と、人による判断に基づく通常審査が行われる駐車場とを区別して表示することを特徴とする。【選択図】図３５

Description

本発明は、審査サーバ及び審査方法に関する。

本技術分野の背景技術として、特開２００９−２１７６０１号公報（特許文献１）がある。この公報には、「駐車場の評価を行う駐車場評価システムであって、駐車場を利用する車両の車種を判別する車種判別部と、車両の経済的価値に基づいて予め定められた車両区分毎に、前記判別された車種を集計する集計部と、前記集計の結果に基づいて、前記駐車場の評価を行う評価部とを備える駐車場評価システム。」が記載されている。

特開２００９−２１７６０１号公報

前記特許文献１には、駐車場を利用する車両の経済的価値に基づいて駐車場の評価を行い、この評価結果をユーザに提示することができる駐車場評価システムが記載されている。しかし、特許文献１のシステムでは、駐車場の所有者と賃貸借契約を締結することを希望する駐車場利用希望者に対して行われる審査を迅速にすることについては何ら考慮されていない。

そこで、本発明は、駐車場の賃貸借契約を締結することを希望する駐車場利用希望者に対して行われる審査を迅速なものとできる仕組みを提供する。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、
駐車場の利用に対する審査を行う審査サーバであって、
審査に用いられる情報を取得する情報取得手段と、
証明書の画像データを画像解析して文字列情報である証明書情報を抽出する画像解析手段と、
車両に関する車両情報と、前記証明書情報と、利用者の個人又は法人に関連する個人情報と、のうちの少なくとも一つに基づいて審査を行う審査実行手段と、
審査結果を出力する出力手段と、
を有し、
前記出力手段は、前記審査サーバの前記審査実行手段が審査を行うクイック審査が実施できる駐車場と、人による判断に基づく通常審査が行われる駐車場とを区別して表示することを特徴とする。

本発明によれば、特定の駐車場と賃貸借契約を締結することを希望する駐車場利用希望者に対して行われる審査を迅速なものとできる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

全体のシステム１の構成図の例である。審査サーバ１０１のハードウェア構成の例である。利用者端末１０２のハードウェア構成の例である。オーナー端末１０３のハードウェア構成の例である。審査会社端末１０４のハードウェア構成の例である。審査結果テーブル１０００の例である。免許証テーブル１１００の例である。車検証テーブル１１５０の例である。任意保険証テーブル１２００の例である。在留証明証テーブル１２５０の例である。登記簿謄本テーブル１３００の例である。車両カタログテーブル１３５０の例である。物件テーブル１４００の例である。区画テーブル１４５０の例である。オーナー・管理会社テーブル１５００の例である。予約テーブル１５５０の例である。利用者管理テーブル１６５０の例である利用者契約テーブル１７００の例である請求テーブル１７５０の例である。物件表示モジュール２１２が実施する物件表示フロー２０００の例である。審査実行モジュール２１１が実施する第一審査実行フロー２１００の例である。画像解析データ登録モジュール２１３が実施する画像解析データ登録フロー２２００の例である。審査実行モジュール２１１が実施する証明書データ提出判定フロー２３００の例である。審査実行モジュール２１１が実施するクイック審査フロー２４００の例である。審査実行モジュール２１１が実施する車両カタログ情報取得フロー２５００の例である。審査実行モジュール２１１が実施する提出データ審査フロー２６００の例である。審査実行モジュール２１１が実施する車両審査フロー２７００の例である。審査実行モジュール２１１が実施する第一利用者審査フロー２８００の例である。審査実行モジュール２１１が実施する第二利用者審査フロー２９００の例である。審査管理モジュール２１４が実施する審査管理フロー３０００の例である。審査実行モジュール２１１が実施する第一空き待ち予約フロー３１００の例である。審査実行モジュール２１１が実施する第二空き待ち予約フロー３２００の例である。審査実行モジュール２１１が実施する第二審査実行フロー３３００の例である。審査実行モジュール２１１が実施する空き待ち予約情報入力フロー３４００の例である。利用者端末１０２の出力装置３０５が複数の物件の情報を表示した画面の例である。一つの物件の詳細な情報を利用者端末１０２の出力装置３０５に表示した画面の例である。提出データを審査サーバ１０１に登録する画面の例である支払いについての確認事項及び規約について利用者端末１０２の出力装置３０５に表示させた画面の例である。利用者端末１０２の出力装置３０５に審査結果を表示した画面の例である。特定の審査対象案件の審査状況をオーナー端末１０３の出力装置４０５に表示した画面の例である。特定の審査対象案件の審査状況を審査会社端末１０４の出力装置５０５に表示した画面の例である。一つの物件の詳細な情報を利用者端末１０２の出力装置３０５に表示した画面の例である。

従来は、特定の駐車場の賃貸借契約を締結したい旨の申し込みがあった場合、担当者の判断に基づいて案件毎に車両又は利用者に関する審査（以下、通常審査という場合がある。）を行っていた。例えば、利用者車両が駐車場に収まるかどうかは、実際に駐車場に行って試し入れをして確認して、車両が駐車場に収まるかを審査していた。また、担当者は、利用者が信頼できる者であるかを調査するために、都度、外部情報を確認する作業を行っていた。
それ故、審査にかかる時間が長くなり、即契約を望むユーザのニーズを満たすことができていなかった。特に、審査を要する案件の数が多くなった場合にはこの課題は顕著である。

そこで、当該課題を解決するために、本実施例は以下で説明するシステム又は方法を採用した。これにより、利用者から提出された情報に基づき、審査サーバが自立して審査（以下、クイック審査という場合がある。）を実行してその結果を出力するため、審査速度を向上できる。また、審査の精度も向上できる。
すなわち、契約締結までの期間を短縮でき、利用者に対して大きな付加価値を提供できる。
以下、実施例を説明する。

本実施例では、特定の駐車場の賃貸借契約を締結することを希望する利用者に対して行われるクイック審査の審査システム１の例を説明する。
図１は、全体のシステム１の構成図の例である。
審査システム１は、複数の利用者端末１０２、複数のオーナー端末１０３、複数の審査会社端末１０４、を備え、それぞれがネットワークを介して審査サーバ１０１に接続されている。なお、ネットワークは有線、無線を問わず、それぞれの端末はネットワークを介して情報を送受信することができる。

審査システム１のそれぞれの端末や審査サーバ１０１は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよいし、メガネ型や腕時計型、着衣型などのウェアラブル端末でもよい。また、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。あるいは、これらの複数の端末の組合せであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。またこれら以外の情報処理端末であってもよい。

利用者端末１０２は、駐車場の利用者が使用する端末である。
オーナー端末１０３は、駐車場のオーナーや、駐車場管理会社などが使用する端末である。
審査会社端末１０４は、クイック審査を行う審査会社が使用する端末である。
審査サーバ１０１は、上記それぞれの端末から、審査を行うにあたって必要となる様々な情報の入力を受け付け、これらを審査情報ＤＢ２２１の中に記憶する。

審査システム１のそれぞれの端末や審査サーバ１０１は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置と、を備える。なお、出力装置は、外部のモニタやディスプレイ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。

主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで全体システムの各機能要素が実現される。なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。
本明細書では、各モジュールが、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。

補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、ＸＭＬなどのテキストファイルでもよい。

図２は、審査サーバ１０１のハードウェア構成の例である。
審査サーバ１０１は、例えばクラウド上に配置されたサーバで構成される。
主記憶装置２０１には、審査実行モジュール２１１、画像解析データ登録モジュール２１３、物件表示モジュール２１２、審査管理モジュール２１４等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ２０３が実行することで審査サーバ１０１の各機能要素が実現される。

審査実行モジュール２１１は、利用者端末１０２から受信した各種情報に基づき当該審査実行モジュール２１１がクイック審査を行う。

画像解析データ登録モジュール２１３は、利用者端末１０２から受信した画像データを解析して、クイック審査で必要となる各種の文字列データを抽出して、審査情報ＤＢ２２１に記憶する

物件表示モジュール２１２は、利用者端末１０２から受信した利用者が希望している条件を満たす物件の各種情報を利用者端末１０２やオーナー端末１０３、審査会社端末１０４に表示する。各種情報には物件の空き状況やクイック審査が可能か否かの情報を含む。なお、本明細書においては、駐車場を物件又は区画と表現する場合がある。物件は区画を包括する概念であり、物件は少なくとも１つの区画を有している。すなわち、特定物件が有する１つの区画を特定することで車両一台分の駐車場所を特定できる。

審査管理モジュール２１４は、審査サーバ１０１の補助記憶装置２０２に記憶された利用者ごとの審査状況に関する情報をオーナー端末１０３又は審査会社端末１０４に表示する。

補助記憶装置２０２は、審査情報ＤＢ２２１、物件情報ＤＢ２２２、利用者情報ＤＢ２２３等のデータベースを備える。本実施例においては少なくとも１つの情報を格納する少なくとも１つのテーブルを各データベースに備える。

審査情報ＤＢ２２１は、利用者端末１０２から受信した運転免許証、車検証、任意保険証、在留カード若しくは外国人登録証、又は登記簿謄本（以下、これらを包括して証明書という場合がある。）に関する情報が格納される証明書テーブル１０５０を備える。証明書テーブル１０５０には、免許証テーブル１１００、任意保険証テーブル１２００、車検証テーブル１１５０、在留カード又は外国人登録証（以下で、在留証明書という場合がある。）の情報を格納する在留証明書テーブル１２５０又は登記簿謄本テーブル１３００を含んでいる。また、審査情報ＤＢ２２１は、外部ウェブサイトから受信した車両カタログに関する情報が格納される車両カタログテーブル１３５０を備える。また、審査情報ＤＢ２２１は、審査サーバ１０１で処理した審査結果に関する情報を格納する審査結果テーブル１０００を備える。

物件情報ＤＢ２２２は、物件テーブル１４００、区画テーブル１４５０、オーナー・管理会社テーブル１５００、予約テーブル１５５０を備えており、物件に関連する情報が其々格納される。

利用者情報ＤＢ２２３は、利用者基本テーブル１６００と、請求テーブル１７５０と、を備えており、物件の利用を希望する者に関連する情報がそれぞれ格納される。利用者基本テーブル１６００は利用者の個人情報が格納される利用者管理テーブル１６５０と、賃貸借契約を行うために必要となる利用者に関連する情報が格納される利用者契約テーブル１７００と、を備えている。

図３は、利用者端末１０２のハードウェア構成の例である。
利用者端末１０２は、例えばスマートフォンで構成される。
主記憶装置３０１には、物件表示モジュール３１２が記憶されており、これらのプログラムやアプリケーションをプロセッサ３０３が実行することで利用者端末１０２の各機能要素が実現される。

物件表示モジュール３１２は、利用を希望する物件の条件の情報を審査サーバ１０１へと送信し、条件を満たす物件の各種情報を利用者端末１０２の出力装置３０５に表示する。
補助記憶装置３０２の利用者端末データ３１２は、例えばカメラ部３０６で撮影された利用者の運転免許証の画像データ等の証明書データである。

図４は、オーナー端末１０３のハードウェア構成の例である。
オーナー端末１０３は、例えば据置型コンピュータで構成される。
主記憶装置４０１には、審査管理モジュール４１４が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することでオーナー端末１０３の各機能要素が実現される。

審査管理モジュール４１４は、審査サーバ１０１の補助記憶装置２０２に記憶された利用者ごとの審査状況に関する情報をオーナー端末１０３の出力装置４０５に表示する。
補助記憶装置４０２のオーナー端末データ４２１は、物件のオーナー又は管理会社が所有又は管理する物件の情報である。

図５は、審査会社端末１０４のハードウェア構成の例である。
審査会社端末１０４は、例えば据置型コンピュータで構成される。
主記憶装置５０１には、審査管理モジュール５１４が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで審査会社端末１０４の各機能要素が実現される。

審査管理モジュール２１４は、審査サーバ１０１の補助記憶装置２０２に記憶された利用者ごとの審査状況に関する情報を審査会社端末１０４の出力装置５０５に表示する。
補助記憶装置５０２の審査会社端末データは、取扱う物件に関連する情報を記憶する。
図６〜図１２は審査サーバ１０１の補助記憶装置２０２の審査情報ＤＢ２２１に記憶される各テーブルの例である。

図６は審査結果テーブル１０００の例である。
審査結果テーブル１０００はクイック審査の結果及び理由を記憶している。
審査結果テーブル１０００は、クイック審査ＩＤ１００１、契約ＩＤ１００２、審査番号１００３、提出データ審査結果１００４、提出データ審査結果理由１００５、車両審査結果１００６、車両審査結果理由１００７、利用者審査結果１００８、利用者審査結果理由１００９、確定審査結果１０１０、確定審査結果理由１０１１などの情報を有する。

クイック審査ＩＤは、契約のクイック審査毎に自動的に生成されるユニークなＩＤである。契約ＩＤは、利用者契約テーブル１７００の契約ＩＤを参照しており、クイック審査の対象となる各契約を特定する情報が記憶される。提出データ審査、車両審査、利用者審査の結果及び理由には、それぞれの審査を実施した際のその結果と理由が格納される。確定審査結果には、提出データ審査、車両審査、利用者審査の結果すべてがＯＫだった場合に、ＯＫが記憶される。

図７は免許証テーブル１１００の例である。
免許証テーブル１１００は運転免許証に関する情報を記憶している。
免許証テーブル１１００はＩＤ１１０１、利用者ＩＤ１１０２、免許証写真１１０３、氏名１１０４、住所１１０５、生年月日１１０６、有効期間１１０７などの情報を有する。免許証写真１１０３は画像データである。氏名１１０４、住所１１０５、生年月日１１０６及び有効期間１１０７は免許証画像を解析することで得られる文字列データである。

図８は車検証テーブル１１５０の例である。
車検証テーブル１１５０は車検証に関する情報を記憶している。
車検証テーブル１１５０はＩＤ１１５１、利用者ＩＤ１１５２、車検証写真１１５３、所有者の氏名又は名称１１５４、所有者の住所１１５５、使用者の氏名又は名称１１５６、使用者の住所１１５７、登録番号（ナンバー）１１５８、有効期限１１５９、登録年月日１１６０、種別１１６１、用途１１６２、車体の形状１１６３、車名１１６４、型式１１６５、全長１１６６、全幅１１６７、全高１１６８、重量１１６９、などの情報を有する。本実施例において、全長、全幅、全高の値の単位はｍｍ（ミリメートル）であり、重量の単位はｋｇ（キログラム）である。各テーブルに記憶される対応する各データの値の単位を揃えることで審査速度をより向上できる。

車検証写真１１５３は画像データである。所有者の氏名又は名称１１５４、所有者の住所１１５５、使用者の氏名又は名称１１５６、使用者の住所１１５７、登録番号（ナンバー）１１５８、有効期限１１５９、登録年月日１１６０、種別１１６１、用途１１６２、車体の形状１１６３、車名１１６４、型式１１６５、全長１１６６、全幅１１６７、全高１１６８、重量１１６９、は車検証画像を解析することで得られる文字列データである。

図９は任意保険証テーブル１２００の例である。
任意保険証テーブル１２００は任意保険証に関する情報を記憶している。
任意保険証テーブル１２００はＩＤ１２０１、利用者ＩＤ１２０２、任意保険証写真１２０３、氏名１２０４、住所１２０５、登録番号（ナンバー）１２０６、生年月日１２０７、有効期限１２０８などの情報を有する。
任意保険証写真１２０３は画像データである。
氏名１２０４、住所１２０５、登録番号（ナンバー）１２０６、生年月日１２０７、有効期限１２０８は任意保険証画像を解析することで得られる文字列データである。

図１０は在留証明証テーブル１２５０の例である。
在留証明証テーブル１２５０は在留証明証すなわち在留カード又は外国人登録証に関する情報を記憶している。
在留証明証テーブル１２５０はＩＤ１２５１、利用者ＩＤ１２５２、在留証明証写真１２５３、氏名１２５４、住所１２５５、生年月日１２５６、有効期限１２５７などの情報を有する。
在留証明証写真１２５３は画像データである。
氏名１２５４、住所１２５５、生年月日１２５６、有効期限１２５７は在留証明証画像を解析することで得られる文字列データである。

図１１は登記簿謄本テーブル１３００の例である。
登記簿謄本テーブル１３００は登記簿謄本に関する情報を記憶している。
登記簿謄本テーブル１３００はＩＤ１３０１、利用者ＩＤ１３０２、登記簿謄本写真１３０３、名称１３０４、代表者氏名１３０５、所在地１３０６、謄本発行日１３０７、設立年月日１３０８などの情報を有する。
登記簿謄本写真１３０３は画像データである。
名称１３０４、代表者氏名１３０５、所在地１３０６、設立年月日１３０８は登記簿謄本画像を解析することで得られる文字列データである。

図１２は車両カタログテーブル１３５０の例である。
車両カタログテーブル１３５０は利用者の車両のカタログ情報を記憶している。
車両カタログテーブル１３５０はＩＤ１３５１、利用者ＩＤ１３５２、メーカー名１３５３、車体の形状１３５４、種別１３５５、車種１３５６、型式１３５７、全長１３５８、全幅１３５９、全高１３６０、重量１３６１、最低地上高１３６２などの情報を有する。
メーカー名１３５３、車体の形状１３５４、種別１３５５、車種１３５６、型式１３５７、全長１３５８、全幅１３５９、全高１３６０、重量１３６１、最低地上高１３６２はメーカー名、車種、型式などの情報に基づいてメーカーのウェブサイトから受信したカタログ情報から、各情報を取得して記憶する。本実施例において、最低地上高の値の単位はｍｍ（ミリメートル）である。

図１３〜図１６は審査サーバ１０１の補助記憶装置２０２の物件情報ＤＢ２２２に記憶される各テーブルの例である。
図１３は物件テーブル１４００の例である。
物件テーブル１４００は物件に関する情報を記憶している。
物件テーブル１４００は、システム全体で統一して使用される物件ＩＤ１４０１、物件名称１４０２、物件所在地１４０３、総区画１４０４、空区画数１４０５、埋まり区画数１４０６、物件写真１４０７、オーナー又は管理会社ＩＤ１４０８などの情報を有する。物件ＩＤにより、物件を一意に特定する。

図１４は区画テーブル１４５０の例である。
区画テーブル１４５０は物件のうちの区画に関する情報を記憶している。
区画テーブル１４５０は、システム全体で統一して使用される区画ＩＤ１４５１、区画名称１４５２、物件ＩＤ１４５３、空き状況１４５４、賃料１４５５、全長１４５６、全幅１４５７、全高１４５８、重量１４５９、最低地上高１４６０、クイック審査の可否１４６１、空き待ち予約の可否１４６２などの情報を有する。一つの物件ＩＤで対応付けられた物件に複数の区画が含まれることもある。

図１５はオーナー・管理会社テーブル１５００の例である。
オーナー・管理会社テーブル１５００はオーナー又は管理会社の情報を記憶している。
オーナー・管理会社テーブル１５００はシステム全体で統一して使用される管理者ＩＤ１５０１、氏名又は名称１５０２、住所又は所在地１５０３、電話番号１５０４、メールアドレス１５０５などの情報を有する。

図１６は予約テーブル１５５０の例である。
予約テーブル１５５０は特定区画が空いた場合に当該区画を利用するために空き待ち予約をしている利用者に関する情報を記憶している。
予約テーブル１５５０は予約番号１５５１、利用者ＩＤ１５５２、予約中区画ＩＤ１５５３、利用開始希望日１５５４などの情報を有する。

図１７〜図１９は審査サーバ１０１の補助記憶装置２０２の利用者情報ＤＢ２２３に記憶される各テーブルの例である。
図１７は利用者管理テーブル１６５０の例である
利用者管理テーブル１６５０は利用者の個人情報を記憶している。
利用者管理テーブル１６５０は、審査システム１全体で統一して使用される利用者ＩＤ１６５１、契約主氏名又は名称１６５２、利用者氏名１６５３、契約形態１６５４、利用者住所１６５５、法人所在地１６５６、法人代表者氏名１６５７、電話番号１６５８、メールアドレス１６５９、勤務先１６６０、国籍１６６１、緊急連絡先１６６２、緊急連絡先続柄１６６３などの情報を有する。なお、法人契約である場合には、法人のホームページＵＲＬ情報を記憶してもよい。また、利用者又は法人代表者の生年月日を記憶してもよい。

図１８は利用者契約テーブル１７００の例である
利用者契約テーブル１７００はある利用者がある物件のある区画に契約を申し込んだ場合の、賃貸借契約に関連する情報を記憶している。
利用者契約テーブル１７００は、審査システム１全体で統一して使用される契約ＩＤ１７０１の他、利用者ＩＤ１７０２、審査ＩＤ１７０３、審査結果１７０４、利用開始日１７０５、区画ＩＤ１７０６、賃料１７０７、車両の有無１７０８、車種１７０９、車両特定情報（型式）１７１０、登録番号（ナンバー）１７１１、免許証１７１２、車検証１７１３、任意保険証１７１４、在留カード又は外国人登録証（以下で、在留証明書という場合がある。）の画像データ１７１５、登記簿謄本１７１６などの情報を有する。

契約ＩＤは契約毎に自動的に生成されるユニークなＩＤである。審査ＩＤには、審査結果テーブル１０００のクイック審査ＩＤが記憶されており、審査結果テーブル１０００に記憶された各審査の結果や理由を参照することができる。審査結果には、審査結果テーブル１０００の確定審査結果の情報が記憶されており、同一の契約に対して複数回の審査が実行された場合には、最新の審査結果が記憶される。

図１９は請求テーブル１７５０の例である。
請求テーブル１７５０は利用者に物件利用料を請求するため又は利用者の支払い状況を確認するために必要となる各種情報を記憶している。
請求テーブル１７５０は、請求番号１７５１、契約ＩＤ１７５２、利用者ＩＤ１７５３、入金結果１７５４、入金予定日１７５５、入金日１７５６、請求額１７５７、入金額１７５８などの情報を有する。

図２０〜図３４は審査システム１で実施される各種処理のフローを示す。
図２０は審査サーバ１０１の物件表示モジュール２１２が実施する物件表示フロー２０００の例である。
物件表示モジュール２１２は、利用者端末１０２から利用を希望する駐車場物件の条件の情報を受信する（ステップ２０１０）。例えば、住所・区域等の場所情報、金額情報、空きの有無、サイズ情報等の条件を受信する。

物件表示モジュール２１２は、当該条件を満たす物件があるかを判定する（ステップ２０２０）。すなわち、審査サーバ１０１の物件情報ＤＢ２２２の物件テーブル１４００及び区画テーブル１４５０に記憶された情報と当該物件条件の情報とを突合させる。この判定は、突合された情報同士が完全に一致する場合だけでなく、類似度が高いものがあればそれを表示することとしてよい。例えば、受信した物件条件の情報が特定のエリアの場所情報であり、その場所が物件テーブル１４００に記憶された特定の物件の所在地の周辺であった場合には当該物件を表示する。また、ＡＩや機械学習、ディープラーニングによる反復演算等により、物件テーブル１４００及び区画テーブル１４５０の情報と、受信した物件条件の情報とを突合し、類似するものを抽出してもよい。

条件を満たす物件が存在しない場合には、物件表示モジュール２１２は条件を満たす物件が存在しなかった旨を利用者端末１０２に表示し、処理を終了する（ステップ２０３０）。
条件を満たす物件が存在した場合には、物件表示モジュール２１２は条件を満たす物件が複数存在するかどうかの判定を行う（ステップ２０４０）。
条件を満たす物件が複数存在する場合には、物件表示モジュール２１２は条件を満たす複数の物件の簡易な情報を利用者端末１０２に表示する（ステップ２０５０）。

図３５〜図３８は利用者端末１０２や審査会社端末１０４に表示される画面の例である。図３５は利用者端末１０２の出力装置３０５が複数の物件の情報を表示した画面の例である。当該図の例では、利用者端末１０２が検索ワードを『渋谷』として物件を検索した場合３５１０の例である。当該図の例では、７つの物件の情報を利用者端末１０２の出力装置３０５に表示している。物件毎に、地図上の位置３５２０及び３５５０、所在地と賃料と駐車場名３５３０、空き状況の情報３５４０が表示されている。
一方、条件を満たす物件が複数は存在せず、一つのみ存在する場合には、当該モジュールは条件を満たす一つの物件の詳細な情報を利用者端末１０２に表示する（ステップ２０６０）。一つの物件の情報を表示する場合には、複数の物件を表示する場合より、物件に関連する情報の数を多くして表示する。

図３６は一つの物件の詳細な情報を利用者端末１０２の出力装置３０５に表示する画面の例である。当該図で詳細の情報を表示している物件は図３５で表示した物件のうちの一つである。なお、図３５で表示されている物件情報は、当該物件情報の表示を選択すると図３６の画面に遷移するように、リンク付けされている。すなわち、利用者端末１０２の図３５で表示されている駐車場名などの物件情報表示から特定の物件を選択すると、審査サーバ１０１は利用者端末１０２から利用を希望する物件条件の情報を受信する（ステップ２０１０）。図３６の例は図３５の『渋谷第一駐車場』（駐車場名）の物件の詳細な情報を表示している。
詳細な情報とは、図３６の例では、図３５より狭域な地図上での位置３６１０、名称３６２０、所在地３６２１、空き状況３６２２、敷金や礼金を含む料金情報３６２３、対応車種３６２４、スペック３６２５、屋内外３６２６、入出庫時間制限３６２７である。なお、図３６の例では、一つの物件の詳細な情報のみを表示するだけでなく、周辺に位置する物件３６３０の情報も併せて表示してもよい。

次に物件表示モジュール２１２は利用者端末１０２に表示する物件状況が空き状態かどうかを判定する（ステップ２０７０）。物件の状況が不明である場合には、当該モジュールは物件の審査会社に物件の空き埋まり状況の問い合わせが必要である旨の情報を、物件情報と併せて利用者端末１０２に表示する（ステップ２０７１）。物件の空き状況が不明な場合とは、区画テーブル１４５０の空き状況１４５４が埋まり（空予定）状態である場合を含む。すなわち、将来空き状態となることが予想されるがその時点では未だ埋まり状態である区画である。また、物件の空き状況が不明な場合とは、他の利用者が当該物件を仮押さえしているが、未だ賃貸借契約が締結されていない場合を含んでいてもよい。

なお、物件表示モジュール２１２が行う空き状況の判定は、審査サーバ１０１の物件情報ＤＢの物件情報に紐づいた区画テーブル１４５０の空き状況１４５４を確認することで行うことができる。また、物件が空き状態であるとは、利用可能な区画が少なくとも１つあることであり、物件が埋まり状態であるとは、特定の物件に対して、これに含まれる複数の区画のうち、利用可能な区画が一つもないことである。
物件が空き状態である場合には、物件表示モジュール２１２は、当該物件に対してクイック審査が可能かどうかを判定する（ステップ２０８０）。クイック審査が実行可能である場合（区画テーブル１４５０のクイック審査の可否１４６１が可である場合）には、当該物件が空き状態（募集中）であり、かつクイック審査が実行可能である旨の情報を物件情報と併せて表示する（ステップ２０８１）。

詳細は後述するが、クイック審査とは迅速に審査を行うことができる仕組みである。当該クイック審査が可能であることの情報を他の物件情報と併せて表示することで、迅速に賃貸借契約を締結できる印象を利用者に与えることができる。
クイック審査が可能でない場合（区画テーブル１４５０のクイック審査の可否１４６１が不可である場合）には、クイック審査ではない通常審査が行われることになるため、単に物件が空き状態（募集中）である旨を物件情報と併せて表示する（ステップ２０８２）。なお、物件が空き状態（募集中）である旨だけでなく、積極的にクイック審査可能で無い旨や、通常審査物件である旨などを表示することとしてもよい。
本実施例においては、クイック審査の可否１４６１又は空き待ち予約の可否１４６２は任意に変更することができる。

他の実施例として、物件表示モジュールは、全長、全幅、全高、重量、最低地上高の全ての情報を区画テーブル１４５０に記憶している場合にはクイック審査の可否１４６１に可である旨を記憶し、いずれか１つでも区画テーブル１４５０に記憶していない場合にはクイック審査の可否１４６１に不可である旨を記憶してもよい。物件表示モジュールは、当該処理を所定間隔で又は常時行い、全長、全幅、全高、重量、最低地上高の全ての情報を記憶した場合に初めて利用者端末にクイック審査を実施できる旨を表示する。
他には、クイック審査の可否１４６１の情報には関わらず、全長、全幅、全高、重量、最低地上高の全ての情報に基づいて物件表示モジュールはクイック審査が可であると判定し、いずれか１つでも記憶されていない場合にはクイック審査は不可であると判定してもよい。物件表示モジュールは、当該処理を所定間隔で又は常時行い、全長、全幅、全高、重量、最低地上高の全ての情報が記憶されている場合に初めて利用者端末にクイック審査を実施できる旨を表示する。

物件表示モジュール２１２は、利用者端末１０２に表示する物件が空いておらず、埋まり状態である場合には、当該物件が予約可能であるかを判定する（ステップ２０９０）。当該物件が予約可能である場合（区画テーブル１４５０の空き待ち予約の可否１４６２が可である場合）には、物件表示モジュール２１２は、当該物件が埋まり状態であり、かつ空き待ち予約が可能である旨の情報を当該物件情報と併せて表示する（ステップ２０９１）。

なお、詳細は後述するが、利用者は、空き待ち予約をすることで、埋まり状態の物件が空き状態となった場合に、当該物件が空き状態となった旨の情報を審査サーバ１０１から受信することができる。
当該物件が空き状態ではなく埋まり状態であり、かつ当該物件が予約可能ではない（区画テーブル１４５０の空き待ち予約の可否１４６２が不可である場合）場合には、物件表示モジュール２１２は、当該物件が埋まり状態である旨を当該物件情報と併せて表示する（ステップ２０９２）。なお、物件が埋まり状態である旨だけでなく、積極的に空き待ち予約ができない物件である旨を表示することとしてもよい。

図３５を例に挙げて説明する。図３５の例では７つの物件情報が表示されているが、それぞれ以下のアイコン表示を駐車場名の右横に表示している。
『渋谷第１駐車場』（駐車場名）は物件が空き状態であり、かつクイック審査が実行可能である旨の表示３５４１をしている。
『渋谷第２駐車場』（駐車場名）は空き状況について審査会社に問い合わせが必要である旨の表示３５４２をしている。
『渋谷第３駐車場』（駐車場名）は物件が埋まり状態であり、かつ空き待ち予約が可能である旨の表示３５４３をしている。
『渋谷第４駐車場』（駐車場名）は物件が埋まり状態である旨の表示３５４４をしている。
『渋谷第５駐車場』（駐車場名）は物件が空き状態であり、募集中の表示３５４５をしている。
『渋谷第６駐車場』（駐車場名）は空き状況について審査会社に問い合わせが必要である旨の表示３５４６をしている。
『渋谷第７駐車場』（駐車場名）は物件が空き状態であり、かつクイック審査が実行可能である旨の表示３５４７をしている。

図３６を例に挙げて説明する。当該図の例では渋谷第１駐車場の詳細な情報の一部にこの物件が空き状態であり、かつクイック審査が実行可能である旨のアイコン３６２２を表示している。また、周辺に位置する物件にも空き状況等のアイコン表示３６３１及び３６３２をしている。
図３５及び図３６においては、地図の上に駐車場の位置を示すアイコンを表示しているが、クイック審査が実施できる駐車場のアイコンと、通常審査が行われる駐車場のアイコンとを区別して表示している。具体的には、クイック審査ができる物件にだけ表示番号の横に『Ｑ』を表示３５２０、３５５０及び３６１０している。

図２１は審査サーバ１０１の審査実行モジュール２１１が実施する第一審査実行フロー２１００の例である。
利用者が空き状態である特定の物件を利用しようとする場合、利用者は一定の審査を受けてそれを通過しなければならない。当該フローは、当該審査を迅速に行うために審査実行モジュール２１１が実行するクイック審査のフローである。
審査実行モジュール２１１は、利用を希望する空き状態の物件情報を利用者端末１０２から受信する（ステップ２１１０）。

図３６を例に挙げて説明する。当該図の例では表示画面の上方部及び下方部に其々『クイック審査申込する』と記載されたボタン３６４０が表示されており、当該ボタンをクリック、タップ等により選択することで『渋谷第一駐車場』（駐車場名）の利用申し込みの画面（図３７）に遷移する。利用者が、利用申し込み画面から申し込みに必要な情報を入力し、申し込み実行ボタンを押すことで、審査実行モジュール２１１は利用を希望する空き状態の物件情報及び、審査を受けるために必要となる全ての提出データを受信する（ステップ２１１０）。利用者端末１０２から受信した提出データは、審査サーバ１０１の利用者情報ＤＢ２２３の利用者基本テーブル１６００又は審査情報ＤＢ２２１の証明書テーブル１０５０に記憶される。故に、利用者基本テーブル１６００又は証明書テーブル１０５０に記憶された情報に不足がないかを判定することで、審査実行モジュール２１１は全ての提出テータを受信したかどうかの判定をすることができる。

また、具体的には、提出データは、利用者管理テーブル１６５０に記憶された情報（利用者ＩＤ）の他、職業、勤務先住所、勤務先電話番号、代表電話番号（法人契約の場合）、担当者氏名（法人契約の場合）、担当者電話番号（法人契約の場合）、法人ホームページＵＲＬ（法人契約の場合）、身元引受人氏名（無職の場合）、身元引受人勤務先名称（無職の場合）、身元引受人電話番号（無職の場合）、身元引受人続柄（無職の場合）、利用開始希望日、車庫証明発行希望の有無、駐車場の使用用途、試し入れ希望有無、試し入れ希望日時のすべて又は一部である。

また、具体的には、提出データは、利用者契約テーブル１７００に記憶された情報のうち、車両の有無、車種、車両特定情報（型式）、登録番号（ナンバー）のすべて又は一部である。
また、証明書の提出データは、利用者契約テーブル１７００及び証明書テーブル１０５０にそれぞれ記憶された、免許証の画像データ、車検証の画像データ（車両を所有している場合）、任意保険証の画像データ（車両を所有している場合）、在留証明書の画像データ（国籍が日本国以外の利用者の場合）、登記簿謄本の画像データ（法人契約の場合）のすべて又は一部である。

ここで、図３７を例にあげて説明する。図３７は提出データを審査サーバ１０１に登録する画面の例であり、利用者端末１０２の出力装置３０５に表示される。図３６の『クイック審査申込する』のリンク付けされた表示３６４０を選択することで図３７の画面に遷移する。図３７で表示している入力またはアップロードを要求している項目は上述した提出データの例の一部である。
クイック審査を行うために必須である項目については『必須』と表示３７１０されている。当該図の例では当該『必須』と表示３７１０された項目が入力またはアップロードされていない場合はクイック審査を実行することはできない。なお、当該図で表示している通り自宅電話番号と携帯電話番号のうちいずれか一つが入力されていればよいという意味で『どちらか必須』と表示３７２０している。
図３７の例においては『必須』の項目が全て入力またはアップロードされると図３８に遷移する。

図３８は支払いについての確認事項及び規約について利用者端末１０２の出力装置３０５に表示させた画面の例である。当該図の下方部には同意要求事項３８１０が表示されている。入力が『必須』の項目である各種同意要求事項に同意する旨のチェックが利用者により入力された後、リンク付けされた『申し込む』ボタン３８２０が選択されたときに、全ての入力またはアップロードした情報が利用者端末１０２から審査サーバ１０１に送信され、データベースに記憶される。すなわち、審査実行モジュール２１１は、物件情報及び審査を受けるために必要となる全ての提出データを受信する（ステップ２１１０）。
なお、画像データがアップロードされる免許証、車検証、任意保険証については、『申し込む』ボタンが選択されたときにアップロードしてもよいが、ファイルが選択された際にあらかじめアップロードするという構成にしてもよい。
なお、当該図の例のように、利用者に確認させるために、支払い方法３８３０及び支払い金額３８４０を利用者端末１０２に表示してもよい。

審査実行モジュール２１１はクイック審査を実行する（ステップ２１２０）。詳細は後述するが、クイック審査は三つの審査を含んでいる。三つの審査の其々の結果は審査サーバ１０１の審査情報ＤＢ２２１の審査結果テーブル１０００に記憶される。
当該モジュールはクイック審査のうちの三つの審査結果がすべてＯＫ（審査を通過した）であるかを判定する（ステップ２１３０）。クイック審査のうちの三つの審査結果がすべてＯＫの場合、当該モジュールは審査結果がＯＫである旨を利用者端末１０２に表示する（ステップ２１４０）。その後、利用者は所定の手続きを行うことで、駐車場を利用することができる。
三つの審査結果のうち一つでもＯＫ以外の結果となった場合には、当該モジュールはその旨の結果と、当該結果となった理由を利用者端末１０２に表示する(ステップ２１５０)。その後、当該モジュールは再度新たな提出データを受信した場合には、再度のクイック審査を実行する（ステップ２１６０がＹｅｓ）。

ここで、図３９を例にあげて説明する。図３９は利用者端末１０２の出力装置３０５に審査結果を表示する画面の例である。
当該図の例のように、審査結果３９１０がＮＧの場合には、その理由３９２０も表示する。当該例は、審査結果テーブル１０００の上から二段目の案件（クイック審査ＩＤがＱ１９０００００２の案件）の審査結果を表示している。すなわち、審査結果テーブル１０００の確定審査結果及び理由１０１０及び１０１１に記憶した情報を其々表示している。
図３９の例では、表示画面の下方部に、他の物件を探すための画面に遷移させるためのリンク３９３０を表示しており、当該リンク３９３０を選択すると再度希望の物件を検索する画面に遷移する。

他の例として、審査結果がＮＧであり、その理由がアップロードした免許証画像データが不適正である旨の表示がされている場合には、再度免許証画像をアップロードするための画面に遷移させるためのリンクを表示してもよい。
また他の例として、審査結果がＯＫである場合には、利用を希望する物件について賃貸借契約を締結するための手続きを進めるための画面に遷移させるためのリンクを表示してもよい。

図２２は審査サーバ１０１の画像解析データ登録モジュール２１３が実施する画像解析データ登録フロー２２００の例である。
画像解析データ登録モジュール２１３が実行する画像解析データ登録フロー２２００は、利用者端末１０２から受信した証明書に関連する画像データを解析して文字列データを抽出及び記憶して、解析できない情報がある場合にはエラーを表示するフローである。
当該モジュールは利用者端末１０２から提出データを受信する（ステップ２２１０）。
当該モジュールは受信した提出データが免許証画像データであるかを判定する（ステップ２２２０）。画像データと当該画像データが免許証画像である旨のデータとを併せて受信した場合には当該画像データが免許証画像データであると判定する。また、受信した画像データを画像解析することで免許証画像であることを判定してもよい。当該判定方法は以下のフローにおいても同様とする。

受信した提出データが免許証画像データであると判定した場合には、当該モジュールは免許証画像データから免許証のフォーマットに合わせた読み取り領域の部分画像を画像解析することにより、氏名や住所等の免許証文字列データを抽出して、審査サーバ１０１の審査情報ＤＢ２２１の免許証テーブル１１００に記憶する（ステップ２２２１）。
画像解析では、読み取った部分画像データにＯＣＲ（ＯｐｔｉｃａｌＣｈａｒａｃｔｅｒＲｅｃｏｇｎｉｔｉｏｎ）等の文字認識処理を施し、画像データから文字列データを抽出する。

画像解析データ登録モジュール２１３は、クイック審査を行うために必要となる、画像解析により抽出及び記憶された免許証文字列データが全て揃ったかを判定する（ステップ２２２２）。すなわち、免許証テーブル１１００に記憶された情報が全て揃ったかを判定する。クイック審査に必要な免許証文字列データは、例えば、図７の免許証テーブル１１００で列挙されている、氏名、住所、生年月日、有効期限とすることができる。

免許証文字列データが全て揃っていない場合には、当該モジュールは正常に全ての免許証文字列データを抽出及び記憶できなかった旨のエラーを利用者端末１０２に表示する（ステップ２２８０）。これにより、利用者に再度免許証画像を登録するよう促すことができる。なお、文字列データが全て揃わない場合とは、例えば、受信した画像データの画質が劣悪であり、正常に画像処理ができない場合である。

次に、画像解析データ登録モジュール２１３は受信した提出データが車検証画像データであるかを判定する（ステップ２２３０）。
画像データと当該画像データが車検証画像である旨のデータとを併せて受信した場合や、受信した画像データの画像解析により、受信した提出データが車検証画像データであると判定した場合には、当該モジュールは、車検証画像データから車検証のフォーマットに合わせた読み取り領域の部分画像を画像解析することにより、車種や登録番号（ナンバー）等の車検証文字列データを抽出して、審査サーバ１０１の審査情報ＤＢ２２１の車検証テーブル１１５０に記憶する（ステップ２２３１）。なお、画像解析データ登録モジュール２１３は、抽出した車検証文字列データ（全長、全幅、全高）の単位を変換して記憶する。例えば、抽出した全長に関するデータの値の単位がｃｍ（センチメートル）である場合には、ｍｍ（ミリメートル）に変換して記憶する。

画像解析データ登録モジュール２１３は、クイック審査を行うために必要となる、車検証文字列データが全て揃ったかを判定する（ステップ２２３２）。すなわち、車検証テーブル１１５０に記憶された情報が全て揃ったかを判定する。クイック審査に必要な車検証文字列データは、例えば、車種、全長、全幅、全高などの図８の車検証テーブル１１５０で列挙されている事項とすることができる。
車検証文字列データが全て揃っていない場合には、当該モジュールは正常に全ての車検証文字列データを抽出及び記憶できなかった旨のエラーを利用者端末１０２に表示する（ステップ２２８０）。

画像解析データ登録モジュール２１３は受信した提出データが任意保険証画像データであるかを判定する（ステップ２２４０）。
画像データと当該画像データが任意保険証画像である旨のデータとを併せて受信した場合や、受信した画像データの画像解析により、受信した提出データが任意保険証画像データであると判定した場合には、当該モジュールは、任意保険証画像データから任意保検証のフォーマットに合わせた読み取り領域の部分画像を画像解析することにより、氏名や有効期限等の任意保険証文字列データを抽出して、審査サーバ１０１の審査情報ＤＢ２２１の任意保険証テーブル１２００に記憶する（ステップ２２４１）。

画像解析データ登録モジュール２１３は、クイック審査を行うために必要となる、任意保険証文字列データが全て揃ったかを判定する（ステップ２２４２）。すなわち、任意保険証テーブル１２００に記憶された情報が全て揃ったかを判定する。クイック審査に必要な任意保険証文字列データは、例えば、氏名、住所、登録番号などの図９の任意保険証テーブル１２００で列挙されている事項とすることができる。
任意保険証文字列データが全て揃っていない場合には、当該モジュールは正常に全ての任意保険証文字列データを抽出及び記憶できなかった旨のエラーを利用者端末１０２に表示する（ステップ２２８０）。

次に、画像解析データ登録モジュール２１３は受信した提出データが在留証明書画像データであるかを判定する（ステップ２２５０）。
画像データと当該画像データが在留証明書画像である旨のデータとを併せて受信した場合や、受信した画像データの画像解析により、受信した提出データが在留証明書画像データであると判定した場合には、当該モジュールは、在留証明書画像データから在留証明書のフォーマットに合わせた読み取り領域の部分画像を画像解析することにより、氏名や住所等の在留証明書文字列データを抽出して、審査サーバ１０１の審査情報ＤＢ２２１の在留証明書テーブル１２５０に記憶する（ステップ２２５１）。

画像解析データ登録モジュール２１３は、クイック審査を行うために必要となる、在留証明書文字列データが全て揃ったかを判定する（ステップ２２５２）。すなわち、在留証明書テーブル１２５０に記憶された情報が全て揃ったかを判定する。クイック審査に必要な在留証明書文字列データは、例えば、氏名、住所、生年月日、有効期限などの図１０の在留証明書テーブル１２５０で列挙されている事項とすることができる。
在留証明書文字列データが全て揃っていない場合には、当該モジュールは正常に全ての在留証明書文字列データを抽出及び記憶できなかった旨のエラーを利用者端末１０２に表示する（ステップ２２８０）。

次に、画像解析データ登録モジュール２１３は受信した提出データが登記簿謄本画像データであるかを判定する（ステップ２２６０）。
画像データと当該画像データが登記簿謄本画像である旨のデータとを併せて受信した場合や、受信した画像データの画像解析により、受信した提出データが登記簿謄本画像データであると判定した場合には、当該モジュールは、登記簿謄本画像データから登記簿謄本のフォーマットに合わせた読み取り領域の部分画像を画像解析することにより、社名や所在地等の登記簿謄本文字列データを抽出して、審査サーバ１０１の審査情報ＤＢ２２１の登記簿謄本テーブル１３００に記憶する（ステップ２２６１）。

画像解析データ登録モジュール２１３は、クイック審査を行うために必要となる、登記簿謄本文字列データが全て揃ったかを判定する（ステップ２２６２）。すなわち、登記簿謄本テーブル１３００に記憶された情報が全て揃ったかを判定する。クイック審査に必要な登記簿謄本文字列データは、例えば、名称、代表者氏名、所在地、設立年月日などの図１１の登記簿謄本テーブル１３００で列挙されている事項とすることができる。
登記簿謄本文字列データが全て揃っていない場合には、当該モジュールは正常に全ての登記簿謄本文字列データを抽出及び記憶できなかった旨のエラーを利用者端末１０２に表示する（ステップ２２８０）。

つまり、画像解析データ登録モジュール２１３は、受信した画像データが何の画像データなのか、証明書の種類を特定し、特定した画像データの証明書の種類に対応するフォーマット（証書のレイアウト）を選択し、選択したフォーマットに合わせた１又は複数の読み取り領域の部分画像を取得して、精度の高い画像解析を実施する。
例えば、免許証であれば、免許証のフォーマット（レイアウト）に合わせて、画像の上部の部分画像から氏名情報を取得、上部右部分から生年月日を取得、右側部分から本人の写真情報を取得、というように選択したフォーマットに対応する各部分から、証明書情報を取得することができる。

画像解析は利用者端末１０２側で実施してもよい。この場合、画像解析データ登録モジュール２１３は利用者端末１０２から画像解析後の文字列データと画像データを受信した後、各証明書の証明書文字列データが全て揃ったか判断してもよい。さらに、利用者端末１０２にて各証明書の証明書文字列データが全て揃ったかの判断をしてもよく、この場合には揃った全ての画像データおよび文字列データを利用者端末１０２から受信するのみで、再度全ての文字列データが揃ったかの判定は不要である。

図２３は審査サーバ１０１の審査実行モジュール２１１が実施する証明書データ提出判定フロー２３００の例である。
審査実行モジュール２１１が実行する証明書データ提出判定フロー２３００は、クイック審査を行う前に審査に必要な証明書データが全て揃ったかを判定するフローである。
審査実行モジュール２１１が利用者基本テーブル１６００及び証明書テーブル１０５０のデータを取得する（ステップ２３１０）。
審査実行モジュール２１１がクイック審査を行う対象となる利用者の契約形態が個人契約であるか及び国籍が外国籍かを判定する（ステップ２３２０）。すなわち、当該モジュール２１３は利用者管理テーブル１６５０に記憶された契約形態及び国籍の情報を確認する。

当該利用者が個人契約であり、かつ外国籍である場合には、審査実行モジュール２１１は在留証明書データが全て揃っているか判定する（ステップ２３２１）。すなわち、当該モジュール２１１は在留証明書テーブル１２５０に情報が存在するかを判定する。
在留証明書データが全て揃っていない場合には、審査実行モジュール２１１は在留証明書データが存在しない旨を記憶する（ステップ２３２２）。

審査実行モジュール２１１は当該利用者の契約形態が法人契約であるかを判定する（ステップ２３３０）。
当該利用者が法人契約である場合には、審査実行モジュール２１１は登記簿謄本データが全て揃っているか判定する（ステップ２３３１）。すなわち、当該モジュール２１１は登記簿謄本テーブル１３００に情報が存在するかを判定する。
登記簿謄本データが全て揃っていない場合には、審査実行モジュール２１１は法人ホームページＵＲＬのデータが利用者管理テーブル１６５０に存在するか判定する（ステップ２３３２）。
法人ホームページＵＲＬのデータが存在しない場合には、審査実行モジュール２１１は登記簿データおよび法人ホームページＵＲＬが存在しない旨を記憶する（ステップ２３３３）。

審査実行モジュール２１１は対象となる利用者の免許証データが証明書テーブルに存在するか判定する（ステップ２３４０）。
免許証テーブル１１００に免許証データが存在しない場合には、審査実行モジュール２１１は免許証データが存在しない旨を記憶する（ステップ２３４１）。
審査実行モジュール２１１は当該利用者の車両の有無を判定する（ステップ２３５０）。すなわち、当該モジュール２１１は利用者契約テーブル１７００に記憶された車両の有無の情報を確認する。
当該利用者が車両を所有している場合には、審査実行モジュール２１１は車検証テーブル１１５０に車検証データが存在するか判定する（ステップ２３６０）。
車検証テーブル１１５０に車検証データが存在しない場合には、審査実行モジュール２１１は車検証データが存在しない旨を記憶する（ステップ２３６１）。

次いで、当該利用者が車両を所有している場合には、審査実行モジュール２１１は任意保険証テーブル１２００に任意保険証データが存在するか判定する（ステップ２３７０）。
任意保険証テーブル１２００に任意保険証データが存在しない場合には、審査実行モジュール２１１は任意保険証データが存在しない旨を記憶する（ステップ２３７１）。
当該利用者が車両を所有していない場合には、審査実行モジュール２１１は利用者契約テーブル１７００に車両特定データが存在するかを判定する（ステップ２３５１）。
車両特定データが存在しない場合には、審査実行モジュール２１１は車両特定データが存在しない旨を記憶する（ステップ２３５２）。
車両特定データは、外部のウェブサイトから特定の車両の車両カタログを取得するために利用される。車両特定データは、車両の型式の情報であり、さらにグレードの情報もあると好ましい。

審査実行モジュール２１１は当該利用者がクイック審査を受けるために必要な全ての証明書データ又は車両特定データが存在するかを判定する（ステップ２３８０）。
全て存在する場合には、審査実行モジュール２１１はその旨を記憶する（ステップ２３８１）。その他の提出データも全て揃っている場合には、当該モジュール２１１はクイック審査を実行する。
全て存在しない場合には、当該モジュール２１１は不足するデータを利用者端末１０２に表示する（ステップ２３８２）。
審査実行モジュール２１１が実行する当該フローは利用者端末１０２側で全て実施してもよい。

図２４は審査サーバ１０１の審査実行モジュール２１１が実施するクイック審査フロー２４００の例である。
審査実行モジュール２１１が実行するクイック審査フロー２４００は、審査に必要なデータが全て揃った後に行われる、提出データ審査、車両審査、利用者審査の三つの審査を実行するフローである。
審査実行モジュール２１１は、利用者端末１０２から提出されたデータが適正であるかを審査する提出データ審査を実行する（ステップ２４１０）。
審査実行モジュール２１１は、車両審査で用いるデータが提出データ審査を通過したか（データは適正であったか）を判定する（ステップ２４２０）。当該モジュール２１１は、審査結果テーブル１０００の提出データ審査結果及び理由を確認することで当該判定を行うことができる。車両審査で用いるデータとは、免許証データ、車検証データおよび任意保険証データである。

審査実行モジュール２１１は、車両カタログ情報を受信した場合は次のステップに進む（ステップ２４３０）
車両カタログ情報を受信した場合は、当該モジュール２１１は車両審査を実行する（ステップ２４４０）。
審査実行モジュール２１１は、利用者審査で用いるデータが提出データ審査を通過したかを判定する（ステップ２４５０）。当該モジュール２１１は、審査結果テーブル１０００の提出データ審査結果及び理由を確認することで当該判定を行うことができる。利用者審査で用いるデータとは、免許証データ、在留証明書データ及び登記簿謄本データである。
利用者審査で用いるデータが提出データ審査を通過した場合は、当該モジュールは利用者審査を実行する（ステップ２４６０）。

なお、他の実施例として、物件表示モジュールは、利用者から提出された所定の情報が全て揃っている場合に限り、当該利用者の利用者端末にクイック審査を実施できる旨を表示（クイック審査が可であると判定）してもよい。言い換えれば、事前に全ての所定の情報を提出している利用者の利用者端末にはクイック審査を実施できる旨を表示（クイック審査が可であると判定）し、事前に全ての所定の情報を提出していない利用者の利用者端末には通常審査を行う旨を表示（クイック審査が不可であると判定）してもよい。なお、物件表示モジュールは、当該所定の情報が全て揃っているか否かの情報を記憶してもよい。
具体的には、物件表示モジュールは、利用者がクイック審査を受けるために必要な全ての提出データが揃っている場合には当該利用者の利用者端末にクイック審査を実施できる旨を表示してもよい。ここで、全ての提出データとは、利用者がクイック審査を受けるために必要な車両に関する車両情報、証明書情報、及び利用者の個人又は法人に関連する個人情報である。

他には、物件表示モジュールは、利用者がクイック審査を受けるために必要な全ての提出データが揃っており、かつ全ての提出データが提出データ審査を通過している場合には当該利用者の利用者端末にクイック審査を実施できる旨を表示してもよい。
他には、物件表示モジュールは、利用者がクイック審査を受けるために必要な車両に関する車両情報が全て揃っている場合には当該利用者の利用者端末にクイック審査を実施できる旨を表示してもよい。
他には、物件表示モジュールは、利用者がクイック審査を受けるために必要な証明書情報が全て揃っている場合には当該利用者の利用者端末にクイック審査を実施できる旨を表示してもよい。
他には、物件表示モジュールは、利用者がクイック審査を受けるために必要な利用者の個人又は法人に関連する個人情報が全て揃っている場合には当該利用者の利用者端末にクイック審査を実施できる旨を表示してもよい。

図２５は審査サーバ１０１の審査実行モジュール２１１が実施する車両カタログ情報取得フロー２５００の例である。
審査実行モジュール２１１が実行する車両カタログ情報取得フロー２５００は、審査に必要な車両カタログデータを取得するために行われるフローである。
審査実行モジュール２１１は、審査の対象である利用者が車両を所有しているかを（車両の有無の情報）受信する（ステップ２５１０）。
審査実行モジュール２１１は、審査の対象である利用者が車両を所有しているかを判定する（ステップ２５２０）。当該判定は、利用者契約テーブル１７００の車両の有無１７０８の情報を確認することで実行できる。

車両を所有している場合は、当該モジュールは車検証データが提出審査を通過したかを判定する（ステップ２５３０）。
車検証データが提出審査を通過した場合には、車検証データから車名、型式等の車両特定データを取得して、外部のウェブサイトから、当該車両特定データに対応する車両カタログデータを取得する（ステップ２５５０）。

車両を所有していない場合は、当該モジュール２１１は特定の車両カタログデータを入手するために必要な程度の車両特定データを受信したか判定する（ステップ２５４０）。
図３７の、データ登録画面で、購入予定の車種情報が入力されると、対応する車種の一覧情報を表示する。この一覧情報から、購入予定の車の型番等を選択してもらうことにより、購入予定の車両を特定する車両特定データを決定することができる。
車両特定データを受信した場合には、ウェブサイトから車両カタログデータを取得する（ステップ２５５０）。その後、審査サーバ１０１の審査情報ＤＢ２２１の車両カタログテーブル１３５０に記憶する（ステップ２５６０）。
当該モジュールによる車両カタログ情報取得フロー２５００は車両審査の実行より前に完了していなければならない。

図２６は審査サーバ１０１の審査実行モジュール２１１が実施する提出データ審査フロー２６００の例である。
審査実行モジュール２１１が実行する提出データ審査フロー２６００は、車両審査又は利用者審査に必要なデータが適正なデータであるかを判定するフローである。
審査実行モジュール２１１は証明書テーブル１０５０のデータと利用者基本テーブル１６００のデータとを突合する（ステップ２６１０）。
審査実行モジュール２１１は審査の対象となる証明書テーブル１０５０に含まれる氏名又は名称と、利用者基本テーブル１６００に記憶した氏名又は名称が一致するかを判定する（ステップ２６２０）。完全に一致しない場合であっても、両データが対応していればよい。例えば、異体字でそれぞれ表記される場合には、審査実行モジュール２１１は両データが対応していると判定してもよい。
免許証データの場合には、免許証テーブル１１００の氏名と、利用者管理テーブル１６５０の利用者氏名とを突合させる。

登記簿謄本データの場合には、登記簿謄本テーブル１３００の名称と、利用者管理テーブル１６５０の契約主名称とを突合させる。加えて、登記簿謄本テーブル１３００の代表者氏名と、利用者管理テーブル１６５０の代表者氏名とを突合させてもよい。
在留証明書データの場合には、在留証明書テーブル１２５０の氏名と、利用者管理テーブル１６５０の利用者氏名とを突合させる。
車検証の場合には、車検証テーブル１１５０の所有者又は使用者の氏名又は名称と、利用者管理テーブル１６５０の契約主又は利用者の氏名又は名称とを突合させる。
任意保険証の場合には、任意保険証テーブル１２００の氏名と、利用者管理テーブル１６５０の利用者の氏名とを突合させる。
審査実行モジュール２１１は、其々の氏名等が一致しない場合には、提出データ審査の結果がＮＧである（証明書データが不適正である）こと及びその理由を審査結果テーブル１０００の提出データ審査の結果及び理由に記憶する（ステップ２６６０）。

審査実行モジュール２１１は審査の対象となる証明書テーブル１０５０に含まれる住所または所在地と、利用者基本テーブル１６００に記憶した住所又は所在地が一致するかを判定する（ステップ２６３０）。完全に一致しない場合であっても、両データが対応していればよい。例えば、両データが実質的に同じ住所又は所在地を指している場合には、審査実行モジュール２１１は両データが対応していると判定してもよい。両データが実質的に同じ住所又は所在地を指している場合とは、例えば、一方が「丁目」、「番」若しくは「号」で他方が‐（ハイフン）で表記される場合、異体字でそれぞれ表記される場合、一方が漢数字で他方がローマ数字で表記される場合、又は一方が建物名の記載がなく他方が建物名の記載がある場合、などをいう。

免許証データの場合には、免許証テーブル１１００の住所と、利用者管理テーブル１６５０の利用者住所とを突合させる。
登記簿謄本データの場合には、登記簿謄本テーブル１３００の所在地と、利用者管理テーブル１６５０の法人所在地とを突合させる。
在留証明書データの場合には、在留証明書テーブル１２５０の住所と、利用者管理テーブル１６５０の利用者住所とを突合させる。
車検証の場合には、車検証テーブル１１５０の所有者又は使用者の住所と、利用者管理テーブル１６５０の利用者住所又は法人所在地とを突合させる。
任意保険証の場合には、任意保険証テーブル１２００の住所と、利用者管理テーブル１６５０の利用者の住所とを突合させる。
審査実行モジュール２１１は、其々の住所等が一致しない場合には、提出データ審査の結果がＮＧである（証明書データが不適正である）こと及びその理由を審査結果テーブル１０００の提出データ審査の結果及び理由に記憶する（ステップ２６６０）。

当該モジュールは審査の対象となる証明書が有効かを判定する（ステップ２６４０）。
登記簿謄本データの場合には、登記簿謄本テーブル１３００の謄本発行日が３月以内の発行であるか判定する。
免許証データの場合には、免許証テーブル１１００の有効期限と、利用者契約テーブル１７００の利用開始日とを突合させて、利用開始日において有効かを判定する。
在留証明書データの場合には、在留証明書テーブル１２５０の有効期限と、利用者管理テーブル１６５０の利用開始日とを突合させて、利用開始日において有効かを判定する。
車検証の場合には、車検証テーブル１１５０の有効期限と、利用者契約テーブル１７００の利用開始日とを突合させて、利用開始日において有効かを判定する。
任意保険証の場合には、任意保険証テーブル１２００の有効期限と、利用者契約テーブル１７００の利用開始日とを突合させて、利用開始日において有効かを判定する。

審査実行モジュール２１１は、当該証明書が有効でないと判断した場合には、提出データ審査の結果がＮＧである（証明書データが不適正である）こと及びその理由を審査結果テーブル１０００の提出データ審査の結果及び理由に記憶する（ステップ２６６０）。
審査実行モジュール２１１は、提出データ審査結果がＮＧである証明書データを有していない場合は提出データ審査がＯＫ（提出データは全て適正である）ことを審査結果テーブル１０００の提出データ審査の結果に記憶する（ステップ２６５０）。
審査実行モジュール２１１は、一部の証明書データのみを提出データ審査にかけてもよい。この場合、審査にかけられていない証明書データは審査を通過した（証明書データは適正である）ものとして取り扱うことができる。

図２７は審査サーバ１０１の審査実行モジュール２１１が実施する車両審査フロー２７００の例である。
審査実行モジュール２１１が実行する車両審査フロー２７００は、利用者の車両が利用を希望する駐車場に適合するかを判定するフローである。
審査実行モジュール２１１は、車検証テーブル１１５０又は車両カタログテーブル１３５０の車両データと、区画テーブル１４５０の区画データを取得する（ステップ２７１０）。

審査実行モジュール２１１は、車両データと区画データとを突合させる（ステップ２７２０）。
審査実行モジュール２１１は、利用者の車両が区画のサイズの条件を満たすか判定する（ステップ２７３０）。具体的には、当該モジュールは、車両データのうちの全長、全幅、全高の値が区画データのうちの全長、全幅、全高の値より小さい場合は利用者の車両は区画のサイズの条件を満足していると判定できる。
車両が区画のサイズの条件を満たさない場合は、当該モジュールは車両審査がＮＧである旨及びその理由を審査結果テーブル１０００に記憶する（ステップ２７８０）。

審査実行モジュール２１１は、利用者の車両が区画の重量の条件を満たすか判定する（ステップ２７４０）。具体的には、審査実行モジュール２１１は、車両データのうちの重量の値が区画データのうちの重量の値より小さい場合は利用者の車両は区画の重量の条件を満足していると判定できる。
車両が区画の重量の条件を満たさない場合は、審査実行モジュール２１１は車両審査がＮＧである旨及びその理由を審査結果テーブル１０００に記憶する（ステップ２７８０）。
審査実行モジュール２１１は、利用者の車両が区画の最低地上高の条件を満たすか判定する（ステップ２７５０）。具体的には、当該モジュールは、車両データのうちの最低地上高の値が区画データのうちの最低地上高の値より大きい場合は利用者の車両は区画の最低地上高の条件を満足していると判定できる。
車両が区画の最低地上高の条件を満たさない場合は、審査実行モジュール２１１は車両審査がＮＧである旨及びその理由を審査結果テーブル１０００に記憶する（ステップ２７８０）。

審査実行モジュール２１１は、利用者の車両がその他の条件を満たすか判定する（ステップ２７６０）。その他の条件とは、例えば、車両の用途や、車体の形状などの条件である。
車両が区画のその他の条件を満たさない場合は、当該モジュールは車両審査がＮＧである旨及びその理由を審査結果テーブル１０００の車両審査の結果及び理由に記憶する（ステップ２７８０）。
車両が全ての条件を満たす場合は、当該モジュールは車両審査がＯＫである旨を審査結果テーブル１０００の車両審査の結果及び理由に記憶する（ステップ２７７０）。
すなわち、当該フローにおいて、特定の駐車場に利用者の車両が適合するために満足されなければならない情報（利用条件情報という場合がある）は少なくとも全長、全幅、全高、重量、最低地上高、である。また、特定の駐車場の利用を希望する利用者の車両に関する情報（車両情報という場合がある）は当該利用条件情報と同じカテゴリの情報を含んでいなければならない。例えば、利用条件情報（全長）と同じカテゴリの情報は、車両情報（全長）であるように、それぞれ比較できる情報を同じカテゴリとする。

図２８は審査サーバ１０１の審査実行モジュール２１１が実施する第一利用者審査フロー２８００の例である。
審査実行モジュール２１１が実行する第一利用者審査フロー２８００は、利用者が反社会的勢力に関係する者でないかを審査するためのフローである。
審査実行モジュール２１１はキーワードに基づく記事情報を検索により取得可能であって、具体的には以下のように取得することができる。

審査実行モジュール２１１は、外部のニュースサイトを検索することで、利用者が反社会的勢力に関係していることの証拠となるニュース記事があるかを検索する（ステップ２８１０）。具体的には、個人契約の場合には、利用者氏名又は勤務先名称と反社会的勢力に関連するワードとのどちらも含む記事が存在するかを判定する。法人契約の場合には、法人名称又は代表者氏名と反社会的勢力に関連するワードとのどちらも含む記事が存在するかを判定する。反社会的勢力に関連するワードとは、例えば、暴力団、総会屋、マフィア、ヤミ金融、ヤミ献金、企業舎弟、フロント企業、エセ同和、エセ行為、準構成員、右翼、左翼、圧力団体などである。

審査実行モジュール２１１は、当該ニュース記事が発見されたかを判定する（ステップ２８２０）。
審査実行モジュール２１１は、利用者基本テーブル１６００に記憶した利用者氏名又は勤務先名称以外の利用者データと、当該ニュース記事と、を突合する（ステップ２８３０）。これにより、当該ニュース記事が適正な情報であるかを判定できる。具体的には例えば、当該モジュールは、証明書テーブル１０５０又は利用者管理テーブル１６５０に記憶されている利用者の生年月日（年齢）と、当該ニュース記事に記載された人物の生年月日（年齢）とを突合する。生年月日が同一であれば利用者と当該ニュース記事の人物とが同一人物である可能性が非常に高いため、当該ニュース記事が適正であると判定する。一方、生年月日が異なっていれば当該ニュース記事は不適正であると判定する。名前と生年月日の組み合わせ以外にも、一つ目の個人特定情報に基づいてスクリーニングし、ヒットしたものについては例えば会社名や住所など、第２の個人特定情報に基づいて本人かどうかの適正度チェックを実施することができる。

審査実行モジュール２１１は、当該ニュース記事が適正かどうか判定を行う（ステップ２８４０）。
当該ニュース記事が適正な場合、当該モジュールは当該ニュース記事を審査結果テーブル１０００に記憶する（ステップ２８５０）。その後、審査実行モジュール２１１は審査結果テーブル１０００の利用者審査の結果及び理由に利用者審査は保留である旨及びその理由を記憶する（ステップ２８６０）。当該場合は、その後に人の判断に基づき当該記事が適正なものかを最終的に判定するため審査結果を保留として表示することとしている。
当該ニュース記事が発見されない場合、又は当該ニュース記事が不適正（当該利用者とは無関係の記事）な場合、当該モジュールは第二利用者審査フロー２９００へ移行する。

図２９は審査サーバ１０１の審査実行モジュール２１１が実施する第二利用者審査フロー２９００の例である。
審査実行モジュール２１１が実行する第二利用者審査フロー２９００は、第一利用者審査フロー２８００と同様に利用者が反社会的勢力に関係する者でないかを審査するためのフローである。
第一利用者審査フロー２８００と異なる点のみ説明する。
第二利用者審査フロー２９００おいては、審査実行モジュール２１１は、外部の検索エンジンサイトで検索することで、利用者が反社会的勢力に関係していることの証拠となるニュース記事があるかを検索する（ステップ２９１０）。
第二利用者審査フロー２９００おいて、最後に利用者審査が保留である旨が記憶されているかを判定（ステップ２９７０）し、利用者審査が保留である旨が記憶されていない場合には、資料審査をＯＫとする旨を審査結果テーブル１０００に記憶する（ステップ２９８０）。

なお、図２８、図２９の第一、第二の利用者審査フローでは、審査がＯＫでない場合には審査結果が保留として、その後、人手による詳細確認作業を設けることとしているが、この代わりに、審査がＮＧとすることとしてもよい。
なお、図２８、図２９の第一、第二の利用者審査フローに加えて、もしくはこれらの代わりに、信用情報を用いて利用者に関する審査を実行することとして、信用情報が特定の値以下の場合には利用者審査を保留又はＮＧとすることとしてもよい。
信用情報としては、例えばクレジットカードの信用情報や、家賃や借入金に対する支払情報に基づく信用情報、学歴、勤め先会社名に基づくステータス情報、芝麻信用などのビッグデータに基づく個人信用情報などを用いることができる。

図３０は審査サーバ１０１の審査管理モジュール２１４が実施する審査管理フロー３０００の例である。
ここで、審査会社は、特定の物件を管理するオーナー又は物件管理会社から当該特定の物件の管理をすることを受託する場合がある。この場合にも、審査会社は、受託する物件の利用者が信頼できる者であるかを判定するため、物件を利用している利用者を対象に審査を行う必要がある。すなわち、審査サーバ１０１の審査実行モジュール２１１は上述したクイック審査を含む第一審査実行フロー２１００を実行することができる。ただし、この場合には、審査をするために必要となる提出データはオーナー端末１０３から送信されることとなる。また、既に各物件は利用者に利用されているため、クイック審査のうちの車両審査は行わないこととしてもよい。
オーナー又は物件管理会社は委託した物件毎の利用者が審査を通過したかを確認したい場合がある。また、審査会社は、複数の物件の管理を受託したときには、その審査を一括して行えるよう管理したい場合がある。
審査管理モジュール２１４が実行する審査管理フロー３０００は審査会社又はオーナー若しくは物件管理会社が利用者の審査状況を確認又は管理するためのフローである。

審査管理モジュール２１４は、オーナー端末１０３又は審査会社端末１０４から特定の審査対象案件の審査状況を表示する旨の指示を受信する（ステップ３０１０）。
当該モジュールは、当該特定の審査対象案件の審査状況をオーナー端末１０３又は審査会社端末１０４に表示する（ステップ３０２０）。当該特定の審査対象案件が複数ある場合には複数件表示することができる。審査状況の表示は、審査が終了している場合には審査サーバ１０１の審査情報ＤＢ２２１の審査結果テーブル１０００に記憶した確定審査結果及び理由を表示し、審査が未だ行われていない場合には未審査である旨を表示する。

ここで、図４０を例にあげて説明する。図４０は特定の審査対象案件の審査状況をオーナー端末１０３の出力装置４０５に表示する画面の例である。具体的には、ステータスの項目を『審査待ち』４０１０で絞って検索を行った場合にオーナー端末１０３に表示される画面の例である。当該図の例では下方部に３件の未審査の審査対象案件４０２０が表示されている。オーナーは、当該表示を確認した後、審査状況について審査会社に問い合わせを行いたい場合は、当該図の中央部で表示されているリンク付けされた『お問い合わせ』４０３０の表示を選択することで、審査会社に問い合わせることができる。
審査管理モジュール２１４は、審査会社端末１０４から未審査の案件を一括して審査する旨の指示を受信する（ステップ３０３０）。

ここで、図４１を例にあげて説明する。図４１は特定の審査対象案件の審査状況を審査会社端末１０４の出力装置５０５に表示する画面の例である。図４１は中央部に『クイック審査開始』４１１０の表示がある点が図４０と異なる。『クイック審査開始』４１１０の表示はリンク付けされており、当該表示を選択すると、表示されている未審査の全ての審査対象案件の審査が行われる。
審査管理モジュール２１４は、クイック審査に必要な提出データをオーナー端末１０３から全て受信したか判定する（ステップ３０４０）。
全て受信した場合には、当該モジュールは、当該指示された案件を対象として審査実行モジュール２１１がクイック審査フロー２４００を実行する（ステップ３０５０）。
審査管理モジュール２１４は、未審査である旨の表示に変えて確定審査結果及び理由を表示する（ステップ３０６０）。

図３１は審査サーバ１０１の審査実行モジュール２１１が実施する第一空き待ち予約フロー３１００の例である。
審査実行モジュール２１１が実行する第一空き待ち予約フロー３１００は、埋まり状態である物件を利用者が予約した場合に実行されるフローである。
審査実行モジュール２１１は、埋まり状態である物件に対して利用者端末１０２から空き待ち予約をする旨の指示を受信する（ステップ３１１０）。

ここで、図４２を例にあげて説明する。図４２は一つの物件の詳細な情報を利用者端末１０２の出力装置３０５に表示する画面の例である。当該図で詳細の情報を表示している物件は図３５で表示した物件のうちの一つであり、図３５で表示されているリンク付けされた物件情報の表示を選択することで図４２の画面に遷移する。
図４２の『空き待ち予約する』のリンク付けされた表示４２１０を選択することで、利用者端末１０２から当該物件を予約する旨の情報が送信される。これにより、当該図の例では、当該モジュールは、埋まり状態である当該物件に対して利用者端末１０２から空き待ち予約をする旨の指示を受信したこととなる。
ただし、利用者が空き待ち予約をするためには、最低限の利用者情報を審査サーバ１０１に登録する必要がある。そのため、当該情報を登録していない利用者における利用者端末１０２には当該情報を登録が必要な旨を表示する。最低限の利用者情報とは、例えば、氏名及びメールアドレスなどである。

審査実行モジュール２１１は、当該物件が空き状態となった場合に利用申し込みが可能になった旨の情報を審査サーバ１０１から利用者端末１０２に送信する（ステップ３１２０）。これにより、空き待ち予約を行った利用者は、予約を行っていない者より早く当該物件を利用することの申し込みを行う（クイック審査を行う）ことができる。空き待ち予約を行った利用者が複数いる場合には、審査実行モジュール２１１は、複数の利用者に同時に当該送信をしてもよく、何らかの序列に従って時間差で複数の利用者に当該送信をしてもよい。
この後は、当該モジュールは上述した第一審査実行フロー２１００を実行する。

図３２は審査サーバ１０１の審査実行モジュール２１１が実施する第二空き待ち予約フロー３２００の例である。
審査実行モジュール２１１が実行する第二空き待ち予約フロー３２００は空き待ち待機中にクイック審査を行うフローである。
審査実行モジュール２１１は、埋まり状態であり、かつ空き待ち予約可能である物件に対して利用者端末１０２から空き待ち予約をする旨の指示を受信する（ステップ３２１０）。
審査実行モジュール２１１は、当該物件の予約を行った利用者の数が１０人以上となったかを判定する（ステップ３２２０）。

予約を行った利用者の数が１０人以上となる前に当該物件が空き状態となった場合には、当該モジュールは当該物件が空き状態となった旨（利用申し込みが可能になった旨）の通知を審査サーバ１０１から複数の利用者（予約する全ての利用者）の利用者端末１０２に送信する（ステップ３２８０）。
予約を行った利用者の数が１０人以上となった場合、予約者全員のクイック審査を実行する。まず、審査実行モジュール２１１は予約を行った利用者のうちの１人目（予約テーブル１５５０の予約番号が１番の利用者）の提出データを受信する（ステップ３２３０）。

審査実行モジュール２１１は受信した提出データを用いて１人目のクイック審査を実行する（ステップ３２４０）。
審査実行モジュール２１１は、予約を行った利用者の全員のクイック審査が終わったか判定する（ステップ３２５０）。
全員のクイック審査が終わっていない場合には、当該モジュールは、次の予約を行った利用者（予約テーブル１５５０の予約番号が次の利用者）の提出データを受信（ステップ３２５１）した後にクイック審査を実行する。

全員のクイック審査が終わった場合、当該モジュールはクイック審査の結果がＯＫ（審査結果テーブル１０００の確定審査結果がＯＫ）であった利用者を判定する（ステップ３２６０）。
クイック審査の結果がＯＫであった利用者に対しては、審査実行モジュール２１１は利用者端末１０２に審査結果ＯＫの旨を表示する（ステップ３２７０）。その後、審査実行モジュール２１１、当該物件が空き状態となった場合に利用申し込みが可能になった旨の通知を、複数の利用者のうち、クイック審査の結果がＯＫ（特定の駐車場を利用可能である）とされた利用者（利用者端末１０２）に審査サーバ１０１から送信する（ステップ３２８０）。すなわち、クイック審査の結果がＮＧであった利用者の利用者端末１０２には送信されない。

クイック審査の結果がＮＧ又は保留であった利用者に対しては、審査実行モジュール２１１は当該利用者の利用者端末１０２に当該審査の結果及びその理由を表示する（ステップ３２６１）。なお、提出データが不足しており、審査ができなかった場合には、この旨を表示する。
その後、審査実行モジュール２１１は再度新たな提出データを受信した場合（ステップ３２６２）には、再度のクイック審査を実行する（ステップ３２４０）。

図３３は審査サーバ１０１の審査実行モジュール２１１が実施する第二審査実行フロー３３００の例である。
審査実行モジュール２１１が実行する第二審査実行フロー３３００は、第一審査実行フロー２１００と異なり、利用を希望する物件が空き状態か埋まり状態かに関わらず先に審査が実行されるフローである。
以下では、第一審査実行フロー２１００と異なる点のみ説明する。

審査実行モジュール２１１、利用を希望する物件情報及び全ての提出データを受信する（ステップ３３１０）。当該物件は空き状態であっても埋まり状態であってもよい。
その後、クイック審査を行い（ステップ３３２０）、審査結果がＯＫであるか判定（ステップ３３３０）し、ＯＫの場合、審査実行モジュール２１１は審査結果がＯＫである旨を利用者端末１０２に表示（ステップ３３５０）した後、利用を希望する物件が空き状態か埋まり状態かを判定する（ステップ３３６０）。
空き状態である場合は、審査実行モジュール２１１は利用者端末１０２に当該物件を利用できる旨の表示をする（ステップ３３７０）。
埋まり状態である場合には、審査実行モジュール２１１は当該物件が空き状態となった場合にその旨の情報を、利用者端末１０２に送信する（ステップ３３８０）。

利用を希望する物件情報の受信は、審査実行モジュール２１１が、利用者端末１０２が特定ＵＲＬにアクセスしたことを受信することとすることもできる。特定ＵＲＬは、特定の物件に紐づいており、当該特定ＵＲＬに利用者端末１０２からアクセスすることで、当該物件の利用を希望することができる。特定ＵＲＬは、例えば、特定のＱＲ（ＱｕｉｃｋＲｅｓｐｏｎｓｅ）コード（登録商標）を利用者端末１０２のカメラ部で読み込んだ際に表示されるＵＲＬであってもよい。当該ＱＲコードは、駐車場の場所にある看板や、他の利用者端末１０２の出力装置３０５に表示されていてもよい。また、特定ＵＲＬは、例えば、審査サーバ１０１から利用者端末１０２に送信されたメールに記載されたＵＲＬでもよい。

図３４は審査サーバ１０１の審査実行モジュール２１１が実施する空き待ち予約情報入力フロー３４００の例である。
審査実行モジュール２１１が実行する空き待ち予約情報入力フロー３４００は、空き待ち予約をした物件のクイック審査の可否により利用者に入力を促す情報を変更するフローである。
審査実行モジュール２１１は、利用を希望する埋まり状態の物件情報を受信する（ステップ３４１０）。例えば、利用を希望する物件情報の受信は、図３３の例と同様に、審査実行モジュール２１１が、利用者端末１０２が特定ＵＲＬにアクセスしたことを受信した場合でもよい。
審査実行モジュール２１１は、受信した当該物件がクイック審査可能な物件であるかを判定する（ステップ３４２０）。

クイック審査可能の（区画テーブル１４５０のクイック審査の可否１４６１が可である場合）場合は、審査実行モジュール２１１は、クイック審査に必要な全て提出データを入力するように促す（ステップ３４３０）。例えば、利用者端末１０２に図３７のように全て提出データを入力させる画面を表示させてもよい。
クイック審査不可の（区画テーブル１４５０のクイック審査の可否１４６１が不可である場合）場合は、審査実行モジュール２１１は、名前及びメールアドレスを入力するように促す（ステップ３４４０）。例えば、利用者端末１０２に図３７の画面の例ではなく名前及びメールアドレスを入力させる画面を表示させてもよい。
その後は、上述した、第一空き待ち予約フロー３１００又は第二空き待ち予約フロー３２００に移行することができる。

ここで、他の実施例では、一つのサーバ内に上述する全てのデータベースを有しているが、複数のサーバに分かれて上述するデータベースが存在していてもよい。例えば、審査サーバとその他に二つのサーバがあり、審査サーバに審査情報ＤＢがあり、他の一つ目のサーバに利用者情報ＤＢがあり、他の二つ目のサーバに物件情報ＤＢがあってもよい。より具体的には、審査情報ＤＢを備える審査サーバが審査実行モジュール、物件表示モジュール、画像解析データ登録モジュール及び審査管理モジュールを有していてもよい。この場合には、審査サーバでクイック審査を行い、当該審査で用いられる物件情報ＤＢや利用者情報ＤＢに格納された情報を都度、他のサーバから取得する。審査サーバでの審査が完了すれば、審査で用いた情報のうち物件情報ＤＢや利用者情報ＤＢから取得した情報を消去する。ただし、審査結果などの一部の情報は各サーバのデータベースに共通して格納されていてもよい。これにより、審査サーバのデータベースに格納される情報を少なくすることができるため、より迅速な審査を実行できる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記憶媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１…審査システム、１０１…審査サーバ、１０２…利用者端末、１０３…オーナー端末、１０４…審査会社端末、２１１…審査実行モジュール、２１２…物件表示モジュール、２１３…画像解析データ登録モジュール、２１４…審査管理モジュール、２２１…審査情報ＤＢ、２２２…物件情報ＤＢ、２２３…利用者情報ＤＢ

Claims

駐車場の利用に対する審査を行う審査サーバであって、
審査に用いられる情報を取得する情報取得手段と、
証明書の画像データを画像解析して文字列情報である証明書情報を抽出する画像解析手段と、
車両に関する車両情報と、前記証明書情報と、利用者の個人又は法人に関連する個人情報と、のうちの少なくとも一つに基づいて審査を行う審査実行手段と、
審査結果を出力する出力手段と、
を有し、
前記出力手段は、前記審査サーバの前記審査実行手段が審査を行うクイック審査が実施できる駐車場と、人による判断に基づく通常審査が行われる駐車場とを区別して表示することを特徴とする審査サーバ。
請求項１に記載の審査サーバであって、
前記出力手段は、地図の上に駐車場の位置を示すアイコンを表示し、前記クイック審査が実施できる駐車場のアイコンと、前記通常審査が行われる駐車場のアイコンとを区別して表示する
ことを特徴とする審査サーバ。
請求項１または２に記載の審査サーバであって、
前記情報取得手段は、
特定の駐車場の利用を希望する利用者の車両に関する前記車両情報と、
前記特定の駐車場に前記車両が適合するために満足されなければならない利用条件情報を含む、前記特定の駐車場に関する駐車場情報と、を取得し、
前記審査実行手段は、
前記車両情報が前記利用条件情報を満足する場合には、前記車両は前記特定の駐車場に適合する旨の車両判定をし、
前記車両情報が前記利用条件情報を満足しない場合には、前記車両は前記特定の駐車場に適合しない旨の車両判定をし、
前記出力手段は、前記車両判定の結果を前記クイック審査の結果として出力する
ことを特徴とする審査サーバ。
請求項３に記載の審査サーバであって、
前記証明書は、個人又は法人を証明する証明書であり、
前記審査実行手段は、
前記個人情報と、前記証明書を画像解析することにより抽出された前記証明書情報と、が対応する場合は、前記証明書が適正である旨の提出データ判定をし、
前記個人情報と前記証明書情報とが対応しない場合は、前記証明書が不適正である旨の提出データ判定をし、
前記出力手段は、前記提出データ判定の結果を前記クイック審査の結果として出力する
ことを特徴とする審査サーバ。
請求項３又は４に記載の審査サーバであって、
キーワードに基づく記事情報を検索により取得可能な検索手段を有し、
前記情報取得手段は、前記利用者の個人又は法人を特定できる個人特定情報を取得し、
前記審査実行手段は、
前記利用者の前記個人特定情報と所定のキーワードとのいずれも同一記事内に含む記事情報を前記検索手段により取得した場合は、前記利用者は前記駐車場を利用できる可能性がない旨の利用者判定をし、
前記利用者の前記個人特定情報と前記所定のキーワードとのいずれも同一記事内に含む記事情報を取得できない場合は、前記利用者は前記駐車場を利用できる可能性がある旨の利用者判定をし、
前記出力手段は、前記利用者判定の結果を前記クイック審査の結果として出力する
ことを特徴とする審査サーバ。
請求項４を引用する請求項５に記載の審査サーバであって、
前記審査実行手段が、
前記車両は前記特定の駐車場に適合する旨の車両判定をし、
前記証明書が適正である旨の提出データ判定をし、
かつ、前記利用者が前記駐車場を利用できる可能性がある旨の利用者判定をした場合に、
前記出力手段は、前記利用者が前記特定の駐車場を利用可能である旨を前記クイック審査の結果として出力する
ことを特徴とする審査サーバ。
請求項４を引用する請求項５又は６に記載の審査サーバであって、
前記審査実行手段が、
前記車両は前記特定の駐車場に適合しない旨の車両判定、
前記証明書が適正でない旨の提出データ判定、
又は、前記利用者が前記駐車場を利用できる可能性がない旨の利用者判定、のうち少なくとも１つを行った場合に、
前記出力手段は、前記利用者が前記特定の駐車場を利用可能でない旨を前記クイック審査の結果として出力する
ことを特徴とする審査サーバ。
請求項５〜７のうちいずれかに記載の審査サーバであって、
前記情報取得手段は、
前記利用者の前記個人特定情報と前記所定のキーワードとのいずれも同一記事内に含む記事情報を取得した場合には、前記利用者の他の個人特定情報をさらに取得し、
前記審査実行手段は、
取得した前記記事情報に、前記他の個人特定情報に対応する情報が含まれる場合は、前記記事情報が適正である旨の判定をし、
取得した前記記事情報に、前記他の個人特定情報に対応する情報が含まれない場合は、前記記事情報が不適正である旨の判定をし、
前記出力手段は、
前記記事情報が不適正である旨の判定をした場合は、前記利用者が前記駐車場を利用可能である旨と前記個人特定情報及び前記他の個人特定情報と前記記事情報とを含む情報を前記クイック審査の結果として出力し、
前記記事情報が適正である旨の判定をした場合は、前記利用者が前記駐車場を利用可能でない旨と前記個人特定情報及び前記他の個人特定情報と前記記事情報とを含む情報を前記クイック審査の結果として出力する
ことを特徴とする審査サーバ。
請求項１〜８のうちのいずれかに記載の審査サーバであって、
前記画像解析手段は、前記画像データの証明書の種類を特定し、前記画像データから、特定した画像データの前記証明書の種類に対応するフォーマットに合わせた１又は複数の部分画像を取得し、前記１又は複数の部分画像を画像解析して文字列情報である証明書情報を抽出する
ことを特徴とする審査サーバ。
請求項３又は請求項３を引用する請求項４〜９のうちいずれかに記載の審査サーバであって、
記憶手段をさらに備え、
前記記憶手段が、前記利用者が車両を有していない旨の情報を記憶しており、かつ
前記車両情報を記憶していない場合には、
前記出力手段は、前記車両情報を特定するための車種又は型番の少なくとも一つを選択する選択画面を表示する
ことを特徴とする審査サーバ。
請求項３又は請求項３を引用する請求項４〜１０のうちいずれかに記載の審査サーバであって、
前記利用条件情報は、
前記駐車場の全幅と、
前記駐車場の全高と、
前記駐車場の全長と、
前記駐車場の耐重量と、
前記駐車場の最低地上高と、のうちの少なくとも１つのカテゴリを含んでおり、
前記車両情報は、前記利用条件情報と同じカテゴリの情報を含んでおり、
前記審査実行手段は、
前記利用条件情報が、
前記駐車場の全幅、
前記駐車場の全高、
前記駐車場の全長、
又は前記駐車場の耐重量、のいずれかの場合には
前記車両情報の値が前記利用者情報の値より小さい場合に、前記車両情報が前記利用条件情報を満足すると車両判定し、
前記利用条件情報が、
前記駐車場の最低地上高、の場合には
前記車両情報の値が前記利用者情報の値より大きい場合に、前記車両情報が前記利用条件情報を満足すると車両判定する
ことを特徴とする審査サーバ。
請求項３又は請求項３を引用する請求項４〜１１のうちいずれかに記載の審査サーバであって、
前記駐車場情報が空き状態か埋まり状態かを示す埋まり状態駐車場情報を有し、
前記特定の駐車場が埋まり状態である場合に、利用者から利用申し込みの予約を受け付ける予約受付手段を有し、
前記出力手段は、前記特定の駐車場が空き状態に変わった場合に、予約を行った前記利用者に、利用申し込みが可能になった旨の通知を出力する、
ことを特徴とする審査サーバ。
請求項６又は７を引用する請求項１２に記載の審査サーバであって
前記出力手段は、前記特定の駐車場が空き状態に変わる前に、前記クイック審査の結果を出力する
ことを特徴とする審査サーバ。
請求項１３に記載の審査サーバであって、
複数の利用者から利用申し込みの予約を受け付けた場合に、
前記出力手段は、前記予約数が所定の数を超えた場合に、前記クイック審査の結果を出力し、
前記特定の駐車場が空き状態に変わった場合に、前記複数の利用者のうち、前記クイック審査の結果が前記特定の駐車場を利用可能であるとされた前記利用者に利用申し込みが可能になった旨の前記通知を出力し、
前記予約数が所定の数を超えない場合に、前記複数の利用者に利用申し込みが可能になった旨の前記通知を出力する、
ことを特徴とする審査サーバ。
請求項６又は７に記載の審査サーバであって、
前記情報取得手段が、特定の前記駐車場に関連する前記特定ＵＲＬに特定の前記利用者がアクセスした旨の情報を取得した場合に、
前記出力手段は、前記クイック審査の結果を出力する、
ことを特徴とする審査サーバ。
駐車場の利用に対する審査を行う審査サーバにおける審査実行方法であって、
前記審査サーバは、
審査に用いられる情報を取得する情報取得手段と、
証明書の画像データを画像解析して文字列情報である証明書情報を抽出する画像解析手段と、
車両に関する車両情報と、前記証明書情報と、利用者の個人又は法人に関連する個人情報と、のうちの少なくとも一つに基づいて審査を行う審査実行手段と、
審査結果を出力する出力手段と、
を有しており、
前記審査サーバの前記審査実行手段が審査を行うクイック審査が実施できる駐車場と、人による判断に基づく通常審査が行われる駐車場とを区別して表示する
ことを特徴とする審査実行方法。
請求項１６に記載の審査実行方法であって、
地図の上に駐車場の位置を示すアイコンを表示し、前記クイック審査が実施できる駐車場のアイコンと、前記通常審査が行われる駐車場のアイコンとを区別して表示する
ことを特徴とする審査実行方法。
請求項１６又は１７に記載の審査実行方法であって、
特定の駐車場の利用を希望する利用者の車両に関する前記車両情報と、前記特定の駐車場に前記車両が適合するために満足されなければならない利用条件情報を含む前記特定の駐車場に関する駐車場情報と、を取得し、
前記車両情報が前記利用条件情報を満足する場合には、前記車両は前記特定の駐車場に適合する旨の車両判定をし、
前記車両情報が前記利用条件情報を満足しない場合には、前記車両は前記特定の駐車場に適合しない旨の車両判定をし、
前記車両判定の結果を前記クイック審査の結果として出力する、
ことを特徴とする審査実行方法。
請求項１８に記載の審査実行方法であって、
前記証明書は、個人又は法人を証明する証明書であり、
前記個人情報と、前記証明書を画像解析することにより抽出された前記証明書情報と、が対応する場合は、前記証明書が適正である旨の提出データ判定をし、
前記個人情報と前記証明書情報とが対応しない場合は、前記証明書が不適正である旨の提出データ判定をし、
前記提出データ判定の結果を前記クイック審査の結果として出力する、
ことを特徴とする審査実行方法。
請求項１８又は１９に記載の審査実行方法であって、
前記審査サーバはキーワードに基づく記事情報を検索により取得可能な検索手段を有しており、
前記利用者の個人又は法人を特定できる個人特定情報を取得し、
前記利用者の前記個人特定情報と所定のキーワードとのいずれも同一記事内に含む記事情報を前記検索手段により取得した場合は、前記利用者は前記駐車場を利用できる可能性がない旨の利用者判定をし、
前記利用者の前記個人特定情報と前記所定のキーワードとのいずれも同一記事内に含む記事情報を取得できない場合は、前記利用者は前記駐車場を利用できる可能性がある旨の利用者判定をし、前記利用者判定の結果を前記クイック審査の結果として出力する、
ことを特徴とする審査実行方法。
請求項１９を引用する請求項２０に記載の審査実行方法であって、
前記車両が前記特定の駐車場に適合する旨の車両判定をし、
前記証明書が適正である旨の提出データ判定をし、
かつ、前記利用者が前記駐車場を利用できる可能性がある旨の利用者判定をした場合に、
前記利用者が前記特定の駐車場を利用可能である旨を前記クイック審査の結果として出力する
ことを特徴とする審査実行方法。
請求項１９を引用する請求項２０又は２１に記載の審査実行方法であって、
前記車両が前記特定の駐車場に適合しない旨の車両判定、
前記証明書が適正でない旨の提出データ判定、
又は、前記利用者が前記駐車場を利用できる可能性がない旨の利用者判定、のうち少なくとも１つを行った場合に、
前記利用者が前記特定の駐車場を利用可能でない旨を前記クイック審査の結果として出力する
ことを特徴とする審査実行方法。
請求項２０〜２２のうちのいずれかに記載の審査実行方法であって、
前記利用者の前記個人特定情報と前記所定のキーワードとのいずれも同一記事内に含む記事情報を取得した場合には、前記利用者の他の個人特定情報をさらに取得し、
取得した前記記事情報に、前記他の個人特定情報に対応する情報が含まれる場合は、前記記事情報が適正である旨の判定をし、
取得した前記記事情報に、前記他の個人特定情報に対応する情報が含まれない場合は、前記記事情報が不適正である旨の判定をし、
前記記事情報が不適正である旨の判定をした場合は、前記利用者が前記駐車場を利用できる可能である旨と前記個人特定情報及び前記他の個人特定情報と前記記事情報とを含む情報を前記クイック審査の結果として出力し、
前記記事情報が適正である旨の判定をした場合は、前記利用者が前記駐車場を利用できる可能でない旨と前記個人特定情報及び前記他の個人特定情報と前記記事情報とを含む情報を前記クイック審査の結果として出力する
ことを特徴とする審査実行方法。
請求項１６〜２３のうちのいずれかに記載の審査実行方法であって、
前記画像データの証明書の種類を特定し、
前記画像データから、特定した画像データの前記証明書の種類に対応するフォーマットに合わせた１又は複数の部分画像を取得し、前記１又は複数の部分画像を画像解析して文字列情報である証明書情報を抽出する
ことを特徴とする審査実行方法。
請求項１８又は請求項１８を引用する請求項１９〜２４のうちいずれかに記載の審査実行方法であって、
前記審査サーバは記憶手段をさら有しており、
前記利用者が車両を有していない旨の情報を記憶しており、かつ
前記車両情報を記憶していない場合には、
前記車両情報を特定するための車種又は型番の少なくとも一つを表示する
ことを特徴とする審査実行方法。
請求項１８又は請求項１８を引用する請求項１９〜２５のうちいずれかに記載の審査実行方法であって、
前記利用条件情報は、
前記駐車場の全幅と、
前記駐車場の全高と、
前記駐車場の全長と、
前記駐車場の耐重量と、
前記駐車場の最低地上高と、のうちの少なくとも１つのカテゴリを含んでおり、
前記車両条情報は、前記利用条件情報と同じカテゴリの情報を含んでおり、
前記利用条件情報が、
前記駐車場の全幅、
前記駐車場の全高、
前記駐車場の全長、
又は前記駐車場の耐重量、のいずれかの場合には
前記車両情報の値が前記利用者情報の値より小さい場合に、前記車両情報が前記利用条件情報を満足すると車両判定し、
前記利用条件情報が、
前記駐車場の最低地上高、の場合には
前記車両情報の値が前記利用者情報の値より大きい場合に、前記車両情報が前記利用条件情報を満足すると車両判定する
ことを特徴とする審査実行方法。
請求項１８又は請求項１８を引用する請求項１９〜２６のうちいずれかに記載の審査実行方法であって、
前記駐車場情報が空き状態か埋まり状態かを示す埋まり状態駐車場情報を有し、
前記特定の駐車場が埋まり状態である場合に、利用者から利用申し込みの予約を受け付ける予約受付手段を有し、
前記特定の駐車場が空き状態に変わった場合に、予約を行った前記利用者に、利用申し込みが可能になった旨の通知を出力する、
ことを特徴とする審査実行方法。
請求項２１又は２２を引用する請求項２７に記載の審査実行方法であって
前記特定の駐車場が空き状態に変わる前に、前記クイック審査の結果を出力する
ことを特徴とする審査実行方法。
請求項２８に記載の審査実行方法であって、
複数の利用者から利用申し込みの予約を受け付けた場合に、
前記予約数が所定の数を超えた場合に、前記クイック審査の結果を出力し、
前記特定の駐車場が空き状態に変わった場合に、前記複数の利用者のうち、前記クイック審査の結果が前記特定の駐車場を利用可能であるとされた前記利用者に利用申し込みが可能になった旨の前記通知を出力し、
前記予約数が所定の数を超えない場合に、前記複数の利用者に利用申し込みが可能になった旨の前記通知を出力する、ことを特徴とする審査実行方法。
請求項２１又は２２に記載の審査実行方法であって、
特定の前記駐車場に関連する前記特定ＵＲＬに特定の前記利用者がアクセスした旨の情報を取得した場合に、
前記クイック審査の結果を出力する、
ことを特徴とする審査実行方法。
審査サーバに請求項１６〜３０のいずれかに記載の審査実行方法の各ステップを実行させるためのプログラム。