JP7604029B2 - Review system and review execution method - Google Patents

Description

The present invention relates to an examination system and an examination method.

JP 2009-217601 A (Patent Document 1) is a background technology in this technical field. This publication describes a "parking lot evaluation system that evaluates parking lots, comprising a vehicle type discrimination unit that discriminates the vehicle types of vehicles using the parking lot, a compilation unit that tallys up the discriminated vehicle types for each vehicle category that is predefined based on the economic value of the vehicle, and an evaluation unit that evaluates the parking lot based on the results of the compilation."

JP 2009-217601 A

The above-mentioned Patent Document 1 describes a parking lot evaluation system that evaluates parking lots based on the economic value of vehicles that use the parking lot and can present the evaluation results to users. However, the system in Patent Document 1 does not take into consideration speeding up the screening process for potential parking lot users who wish to enter into a lease agreement with the owner of the parking lot.

The present invention provides a mechanism for speeding up the screening process for potential parking users who wish to enter into a parking space lease agreement.

In order to solve the above problems, for example, the configurations described in the claims are adopted.
The present application includes a number of means for solving the above problems. To give an example of such means,
An examination server that performs examination for the use of a parking lot,
An information acquisition means for acquiring information used in the examination;
an image analysis means for analyzing the image data of the certificate to extract certificate information, which is character string information;
an examination execution means for performing an examination based on at least one of vehicle information related to the vehicle, the certificate information, and personal information related to the individual or corporation of the user;
An output means for outputting the examination result;
having
The output means is characterized in that it displays parking lots that can be used for a quick inspection, in which the inspection execution means of the inspection server conducts an inspection, and parking lots where normal inspections based on human judgment are conducted.

According to the present invention, screening of a person who wishes to use a parking lot and wishes to enter into a lease agreement with a specific parking lot can be expedited.
Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments.

FIG. 2 is a diagram illustrating an example of a configuration of an entire system 1. 2 is an example of a hardware configuration of the examination server 101. 2 is an example of a hardware configuration of a user terminal 102. 3 is an example of a hardware configuration of the owner terminal 103. 13 is an example of a hardware configuration of the examination company terminal 104. 1 is an example of a review result table 1000. 11 is an example of a license table 1100. 11 is an example of a vehicle inspection certificate table 1150. 12 is an example of a voluntary health insurance card table 1200. 12 is an example of a residence certificate table 1250. 13 is an example of a registry copy table 1300. 13 is an example of a vehicle catalog table 1350. 14 is an example of a property table 1400. 14 is an example of a partition table 1450. 15 is an example of an owner/management company table 1500. 15 is an example of a reservation table 1550. 1 is an example of a user management table 1650. 17 is an example of a user contract table 1700. 17 is an example of a billing table 1750. 2 is an example of a property display flow 2000 implemented by the property display module 212. 2 is an example of a first screening execution flow 2100 executed by the screening execution module 211. 22 is an example of an image analysis data registration flow 2200 implemented by the image analysis data registration module 213. 2 is an example of a certificate data submission determination flow 2300 executed by the examination execution module 211. 2 illustrates an example of a quick screening flow 2400 implemented by the screening execution module 211. 2 is an example of a vehicle catalog information acquisition flow 2500 implemented by the examination execution module 211. 2 illustrates an example of a submitted data review flow 2600 implemented by the review execution module 211. 27 is an example of a vehicle inspection flow 2700 implemented by the inspection execution module 211. 2 is an example of a first user screening flow 2800 implemented by the screening execution module 211. 2 is an example of a second user audit flow 2900 implemented by the audit execution module 211. 3 is an example of a review management flow 3000 implemented by the review management module 214. 3 is an example of a first waiting reservation flow 3100 implemented by the screening execution module 211. 3 is an example of a second vacancy waiting reservation flow 3200 implemented by the examination execution module 211. 3 is an example of a second screening execution flow 3300 implemented by the screening execution module 211. 3 is an example of a waiting reservation information input flow 3400 executed by the examination execution module 211. 1 is an example of a screen on which the output device 305 of the user terminal 102 displays information on a plurality of properties. 13 is an example of a screen showing detailed information about one property displayed on the output device 305 of the user terminal 102. 13 is an example of a screen for registering submitted data in the examination server 101. 13 is an example of a screen displayed on the output device 305 of the user terminal 102, which contains confirmation items and terms of payment. 13 is an example of a screen showing the examination results on the output device 305 of the user terminal 102. 13 is an example of a screen displayed on the output device 405 of the owner terminal 103 showing the review status of a specific review target case. 13 is an example of a screen displayed on the output device 505 of the audit company terminal 104 showing the audit status of a specific audit target case. 13 is an example of a screen showing detailed information about one property displayed on the output device 305 of the user terminal 102.

Previously, when a person applied to enter into a lease agreement for a specific parking lot, the person in charge would conduct an examination of the vehicle or user for each case based on his/her judgment (hereinafter, sometimes referred to as a "regular examination"). For example, to check whether the user's vehicle could fit in the parking lot, the person in charge would actually go to the parking lot and try to drive it in to check whether the vehicle could fit in the parking lot. In addition, the person in charge would check external information each time to investigate whether the user was trustworthy.
This resulted in a long review time, and the needs of users who wanted to sign a contract immediately could not be met. This problem was particularly noticeable when the number of cases requiring review increased.

In order to solve this problem, the present embodiment employs the system or method described below. This allows the screening server to independently perform screening (hereinafter sometimes referred to as quick screening) based on information submitted by users and output the results, thereby improving the screening speed and accuracy.
In other words, the time required to conclude a contract can be shortened, providing significant added value to users.
Examples will be described below.

In this embodiment, an example of an examination system 1 for a quick examination conducted for a user who wishes to enter into a lease contract for a specific parking lot will be described.
FIG. 1 is an example of a block diagram of an entire system 1.
The screening system 1 comprises a plurality of user terminals 102, a plurality of owner terminals 103, and a plurality of screening company terminals 104, each of which is connected to a screening server 101 via a network. Note that the network may be wired or wireless, and each terminal can transmit and receive information via the network.

Each terminal of the screening system 1 and the screening server 101 may be, for example, a mobile terminal such as a smartphone, tablet, mobile phone, or personal digital assistant (PDA), or a wearable terminal such as glasses, wristwatch, or clothing. They may also be stationary or mobile computers, or servers located in the cloud or on a network. Or they may be a combination of multiple of these terminals. For example, a combination of one smartphone and one wearable terminal may logically function as one terminal. They may also be other information processing terminals.

The user terminal 102 is a terminal used by a user of the parking lot.
The owner terminal 103 is a terminal used by the owner of the parking lot, the parking lot management company, etc.
The screening company terminal 104 is a terminal used by a screening company that performs a quick screening.
The examination server 101 accepts input of various information required for the examination from each of the above terminals, and stores this information in the examination information DB 221 .

Each terminal and the examination server 101 of the examination system 1 includes a processor that executes an operating system, applications, programs, etc.; a main storage device such as a RAM (Random Access Memory); an auxiliary storage device such as an IC card, a hard disk drive, an SSD (Solid State Drive), or a flash memory; a communication control unit such as a network card, a wireless communication module, or a mobile communication module; input devices such as a touch panel, a keyboard, a mouse, voice input, or input based on motion detection by capturing images from a camera unit; and an output device such as a monitor or display. The output device may be a device or terminal that transmits information to be output to an external monitor, display, printer, device, etc.

The main memory stores various programs and applications (modules), and the processor executes these programs and applications to realize the various functional elements of the overall system. Each of these modules may be implemented in hardware by integration or the like. Each module may be an independent program or application, or may be implemented as a subprogram or function within a single integrated program or application.
In this specification, each module is described as an entity (subject) that performs processing, but in reality, a processor that processes various programs, applications, etc. (modules) executes the processing.

Various databases (DB) are stored in the auxiliary storage device. A "database" is a functional element (storage unit) that stores a set of data so that it can accommodate any data manipulation (e.g., extraction, addition, deletion, overwriting, etc.) from a processor or an external computer. There are no limitations on how the database is implemented, and it may be, for example, a database management system or a text file such as XML.

FIG. 2 shows an example of the hardware configuration of the examination server 101 .
The examination server 101 is configured, for example, as a server placed on a cloud.
The main memory device 201 stores programs and applications such as an examination execution module 211, an image analysis data registration module 213, a property display module 212, and an examination management module 214, and each functional element of the examination server 101 is realized by the processor 203 executing these programs and applications.

The screening execution module 211 performs a quick screening based on various information received from the user terminal 102.

The image analysis data registration module 213 analyzes the image data received from the user terminal 102, extracts various character string data required for quick screening, and stores it in the screening information DB 221.

The property display module 212 displays various information about properties that meet the user's desired conditions, received from the user terminal 102, on the user terminal 102, the owner terminal 103, and the screening company terminal 104. The various information includes the availability of the property and whether or not a quick screening is possible. In this specification, a parking lot may be referred to as a property or a plot. A property is a concept that encompasses plots, and a property has at least one plot. In other words, a parking space for one vehicle can be identified by identifying one plot that a specific property has.

The review management module 214 displays information about the review status for each user stored in the auxiliary storage device 202 of the review server 101 on the owner terminal 103 or the review company terminal 104.

The auxiliary storage device 202 has databases such as an examination information DB 221, a property information DB 222, and a user information DB 223. In this embodiment, each database has at least one table that stores at least one piece of information.

The screening information DB 221 includes a certificate table 1050 that stores information on the driver's license, vehicle inspection certificate, optional insurance card, residence card or alien registration card, or certified copy of the registry (hereinafter, these may be collectively referred to as certificates) received from the user terminal 102. The certificate table 1050 includes a license table 1100, optional insurance card table 1200, vehicle inspection certificate table 1150, residence certificate table 1250 that stores information on the residence card or alien registration card (hereinafter, these may be referred to as residence certificates), or certified copy of the registry table 1300. The screening information DB 221 also includes a vehicle catalog table 1350 that stores information on the vehicle catalog received from an external website. The screening information DB 221 also includes a screening result table 1000 that stores information on the screening results processed by the screening server 101.

The property information DB222 includes a property table 1400, a partition table 1450, an owner/management company table 1500, and a reservation table 1550, each of which stores information related to the property.

The user information DB 223 includes a user basic table 1600 and a billing table 1750, which store information related to those who wish to use the property. The user basic table 1600 includes a user management table 1650, which stores personal information about users, and a user contract table 1700, which stores information related to users that is necessary to enter into a rental contract.

FIG. 3 shows an example of the hardware configuration of the user terminal 102. As shown in FIG.
The user terminal 102 is, for example, a smartphone.
The main memory device 301 stores a property display module 312, and the processor 303 executes these programs and applications to realize each functional element of the user terminal 102.

The property display module 312 transmits information on the conditions of the property desired to be used to the screening server 101 and displays various information on properties that meet the conditions on the output device 305 of the user terminal 102.
The user terminal data 312 in the auxiliary storage device 302 is, for example, certificate data such as image data of the user's driver's license photographed by the camera unit 306 .

FIG. 4 shows an example of the hardware configuration of the owner terminal 103.
The owner terminal 103 is configured, for example, as a desktop computer.
The main memory device 401 stores an examination management module 414, and each functional element of the owner terminal 103 is realized by the processor executing these programs and applications.

The review management module 414 displays information regarding the review status for each user stored in the auxiliary storage device 202 of the review server 101 on the output device 405 of the owner terminal 103.
The owner terminal data 421 in the auxiliary storage device 402 is information about a property owned or managed by the owner or management company of the property.

FIG. 5 shows an example of the hardware configuration of the examination company terminal 104 .
The examination company terminal 104 is configured, for example, as a stationary computer.
The main memory device 501 stores an examination management module 514, and each functional element of the examination company terminal 104 is realized by the processor executing these programs and applications.

The review management module 214 displays information regarding the review status for each user stored in the auxiliary storage device 202 of the review server 101 on the output device 505 of the review company terminal 104.
The appraisal company terminal data in the auxiliary storage device 502 stores information related to the properties handled.
6 to 12 are examples of tables stored in the examination information DB 221 of the auxiliary storage device 202 of the examination server 101. FIG.

FIG. 6 is an example of the examination result table 1000 .
The screening result table 1000 stores the results and reasons of quick screening.
The review result table 1000 contains information such as a quick review ID 1001, a contract ID 1002, a review number 1003, submitted data review result 1004, reason for submitted data review result 1005, vehicle review result 1006, reason for vehicle review result 1007, user review result 1008, reason for user review result 1009, final review result 1010, and reason for final review result 1011.

The quick review ID is a unique ID that is automatically generated for each quick review of a contract. The contract ID references the contract ID in the user contract table 1700, and stores information that identifies each contract that is the subject of the quick review. The results and reasons for the submitted data review, vehicle review, and user review store the results and reasons for each review that was conducted. The final review result stores "OK" if the results of the submitted data review, vehicle review, and user review are all OK.

FIG. 7 is an example of the license table 1100 .
The license table 1100 stores information about driver's licenses.
The license table 1100 has information such as an ID 1101, a user ID 1102, a license photo 1103, a name 1104, an address 1105, a date of birth 1106, and a validity period 1107. The license photo 1103 is image data. The name 1104, the address 1105, the date of birth 1106, and the validity period 1107 are character string data obtained by analyzing the license image.

FIG. 8 is an example of the vehicle inspection certificate table 1150 .
The vehicle inspection certificate table 1150 stores information related to the vehicle inspection certificate.
The vehicle inspection certificate table 1150 includes information such as ID 1151, user ID 1152, vehicle inspection certificate photo 1153, owner's name or title 1154, owner's address 1155, user's name or title 1156, user's address 1157, registration number (number) 1158, expiration date 1159, registration date 1160, type 1161, use 1162, vehicle body shape 1163, vehicle name 1164, model 1165, overall length 1166, overall width 1167, overall height 1168, and weight 1169. In this embodiment, the units of the values of the overall length, overall width, and overall height are mm (millimeters), and the unit of weight is kg (kilograms). The inspection speed can be further improved by unifying the units of the values of the corresponding data stored in each table.

The vehicle inspection certificate photo 1153 is image data. The owner's name or title 1154, the owner's address 1155, the user's name or title 1156, the user's address 1157, the registration number (number) 1158, the expiration date 1159, the registration date 1160, the type 1161, the purpose 1162, the shape of the vehicle body 1163, the vehicle name 1164, the model 1165, the overall length 1166, the overall width 1167, the overall height 1168, and the weight 1169 are character string data obtained by analyzing the vehicle inspection certificate image.

FIG. 9 is an example of the optional health insurance card table 1200.
The optional health insurance card table 1200 stores information related to optional health insurance cards.
The optional health insurance card table 1200 has information such as an ID 1201, a user ID 1202, an optional health insurance card photo 1203, a name 1204, an address 1205, a registration number 1206, a date of birth 1207, and an expiration date 1208.
The optional health insurance card photo 1203 is image data.
The name 1204, address 1205, registration number 1206, date of birth 1207, and expiration date 1208 are character string data obtained by analyzing the image of the voluntary health insurance card.

FIG. 10 is an example of the residence certificate table 1250 .
The residence certificate table 1250 stores information related to residence certificates, ie, residence cards or alien registration cards.
The residence certificate table 1250 has information such as an ID 1251, a user ID 1252, a residence certificate photo 1253, a name 1254, an address 1255, a date of birth 1256, and an expiration date 1257.
The residence certificate photo 1253 is image data.
The name 1254, address 1255, date of birth 1256, and expiration date 1257 are character string data obtained by analyzing the image of the residence certificate.

FIG. 11 is an example of a register copy table 1300.
The certified copy of the real estate register table 1300 stores information related to certified copies of the real estate register.
The register copy table 1300 includes information such as an ID 1301, a user ID 1302, a register copy photo 1303, a name 1304, a representative's name 1305, a location 1306, a copy issuance date 1307, and a date of establishment 1308.
The photo of the registry copy 1303 is image data.
The name 1304, the representative's name 1305, the location 1306, and the date of establishment 1308 are character string data obtained by analyzing the image of the registry copy.

FIG. 12 is an example of a vehicle catalog table 1350 .
Vehicle catalog table 1350 stores catalog information for a user's vehicle.
The vehicle catalog table 1350 has information such as an ID 1351 , a user ID 1352 , a manufacturer name 1353 , a vehicle shape 1354 , a type 1355 , a vehicle model 1356 , a model number 1357 , an overall length 1358 , an overall width 1359 , an overall height 1360 , a weight 1361 , and a ground clearance 1362 .
The manufacturer name 1353, body shape 1354, type 1355, vehicle model 1356, model type 1357, overall length 1358, overall width 1359, overall height 1360, weight 1361, and minimum ground clearance 1362 are obtained and stored from catalog information received from the manufacturer's website based on information such as the manufacturer name, vehicle model, and model. In this embodiment, the unit of the minimum ground clearance value is mm (millimeters).

13 to 16 are examples of tables stored in the property information DB 222 of the auxiliary storage device 202 of the screening server 101. FIG.
FIG. 13 is an example of a property table 1400 .
The property table 1400 stores information about properties.
The property table 1400 has information such as a property ID 1401, a property name 1402, a property location 1403, a total number of parcels 1404, a number of vacant parcels 1405, a number of filled parcels 1406, a property photo 1407, and an owner or management company ID 1408, which are used uniformly throughout the system. A property is uniquely identified by the property ID.

FIG. 14 is an example of a partition table 1450.
Parcel table 1450 stores information about parcels within a property.
The partition table 1450 has information such as a partition ID 1451, partition name 1452, property ID 1453, availability 1454, rent 1455, overall length 1456, overall width 1457, overall height 1458, weight 1459, minimum ground clearance 1460, whether quick inspection is available 1461, and whether waiting reservations can be made 1462, all of which are used uniformly throughout the system. A property associated with one property ID may include multiple partitions.

FIG. 15 is an example of an owner/management company table 1500 .
The owner/management company table 1500 stores information on the owner or management company.
The owner/management company table 1500 has information such as a manager ID 1501, a name or title 1502, an address or location 1503, a telephone number 1504, and an email address 1505 that are used uniformly throughout the system.

FIG. 16 is an example of the reservation table 1550.
The reservation table 1550 stores information about users who have made a reservation to wait for a specific section to become available and use that section when that section becomes available.
The reservation table 1550 includes information such as a reservation number 1551, a user ID 1552, a reserved partition ID 1553, and a desired start date of use 1554.

17 to 19 are examples of tables stored in the user information DB 223 of the auxiliary storage device 202 of the examination server 101. FIG.
FIG. 17 is an example of the user management table 1650. The user management table 1650 stores personal information of users.
The user management table 1650 includes information such as a user ID 1651, contract owner name or title 1652, user name 1653, contract type 1654, user address 1655, corporate location 1656, corporate representative name 1657, telephone number 1658, email address 1659, place of employment 1660, nationality 1661, emergency contact 1662, and relationship to emergency contact 1663, which are all used uniformly throughout the screening system 1. In addition, in the case of a corporate contract, the URL information of the corporate homepage may be stored. In addition, the date of birth of the user or corporate representative may be stored.

FIG. 18 is an example of the user contract table 1700. The user contract table 1700 stores information related to a rental contract when a certain user applies for a contract for a certain section of a certain property.
The user contract table 1700 contains information such as a contract ID 1701, which is used uniformly throughout the entire screening system 1, as well as a user ID 1702, a screening ID 1703, screening result 1704, start date of use 1705, plot ID 1706, rent 1707, presence or absence of a vehicle 1708, vehicle type 1709, vehicle identification information (model) 1710, registration number (number) 1711, driver's license 1712, vehicle inspection certificate 1713, voluntary insurance certificate 1714, image data 1715 of a residence card or alien registration card (hereinafter sometimes referred to as a residence certificate), and a copy of the registry 1716.

The contract ID is a unique ID that is automatically generated for each contract. The screening ID stores the quick screening ID from screening result table 1000, and allows reference to the results and reasons for each screening stored in screening result table 1000. The screening result stores information on the final screening result from screening result table 1000, and if multiple screenings are performed on the same contract, the most recent screening result is stored.

FIG. 19 is an example of the billing table 1750.
The billing table 1750 stores various information required for billing users for property usage fees or for checking the payment status of users.
The billing table 1750 has information such as a billing number 1751 , a contract ID 1752 , a user ID 1753 , a payment result 1754 , a scheduled payment date 1755 , a payment date 1756 , a billing amount 1757 , and a payment amount 1758 .

20 to 34 show the flow of various processes performed by the examination system 1.
FIG. 20 is an example of a property display flow 2000 implemented by the property display module 212 of the screening server 101 .
The property display module 212 receives information on the conditions of the parking lot property desired to be used from the user terminal 102 (step 2010). For example, the received conditions include location information such as address and area, price information, availability, size information, and the like.

The property display module 212 determines whether there is a property that satisfies the conditions (step 2020). That is, the information stored in the property table 1400 and the section table 1450 of the property information DB 222 of the screening server 101 is matched with the property condition information. This determination may be made not only when the matched information is a perfect match, but also when there is a high degree of similarity, and the information is displayed. For example, if the received property condition information is location information of a specific area, and the location is in the vicinity of the location of a specific property stored in the property table 1400, the property is displayed. In addition, the information in the property table 1400 and the section table 1450 may be matched with the received property condition information by iterative calculations using AI, machine learning, deep learning, etc., to extract similar items.

If there is no property that satisfies the conditions, the property display module 212 displays on the user terminal 102 a message to the effect that there is no property that satisfies the conditions, and ends the process (step 2030).
If a property that satisfies the conditions is found, the property display module 212 determines whether or not there are multiple properties that satisfy the conditions (step 2040).
If there are multiple properties that satisfy the conditions, the property display module 212 displays simple information about the multiple properties that satisfy the conditions on the user terminal 102 (step 2050).

35 to 38 are examples of screens displayed on the user terminal 102 and the screening company terminal 104. Fig. 35 is an example of a screen on which the output device 305 of the user terminal 102 displays information on multiple properties. The example in this figure shows an example of a search 3510 in which the user terminal 102 searches for properties using the search word "Shibuya". In the example in this figure, information on seven properties is displayed on the output device 305 of the user terminal 102. For each property, positions 3520 and 3550 on the map, the address, rent, and parking lot name 3530, and vacancy information 3540 are displayed.
On the other hand, if there is only one property that satisfies the conditions, the module displays detailed information about the property that satisfies the conditions on the user terminal 102 (step 2060). When displaying information about one property, more information related to the property is displayed than when displaying multiple properties.

Figure 36 is an example of a screen that displays detailed information about a property on the output device 305 of the user terminal 102. The property whose detailed information is displayed in this figure is one of the properties displayed in Figure 35. The property information displayed in Figure 35 is linked so that when the display of the property information is selected, the screen transitions to that of Figure 36. In other words, when a specific property is selected from the property information display such as the parking lot name displayed in Figure 35 on the user terminal 102, the screening server 101 receives information on the property conditions desired to be used from the user terminal 102 (step 2010). The example in Figure 36 displays detailed information about the property "Shibuya Daiichi Parking Lot" (parking lot name) in Figure 35.
In the example of Fig. 36, the detailed information includes a position 3610 on a map that is narrower than that of Fig. 35, a name 3620, a location 3621, availability 3622, fee information 3623 including a security deposit and key money, compatible vehicle types 3624, specifications 3625, indoor/outdoor use 3626, and entry/exit time restrictions 3627. Note that in the example of Fig. 36, not only is detailed information about one property displayed, but information about properties 3630 located in the vicinity may also be displayed.

Next, the property display module 212 determines whether the property status displayed on the user terminal 102 is vacant (step 2070). If the property status is unknown, the module displays information on the user terminal 102 together with the property information to the effect that an inquiry should be made to the property screening company regarding the vacancy status of the property (step 2071). A case in which the vacancy status of a property is unknown includes a case in which the vacancy status 1454 in the section table 1450 is filled (scheduled to be vacant). In other words, it is a section that is expected to become vacant in the future, but is still filled at that time. A case in which the vacancy status of a property is unknown may also include a case in which another user has provisionally reserved the property, but a lease contract has not yet been concluded.

The property display module 212 can determine the availability by checking the availability 1454 in the section table 1450 linked to the property information in the property information DB of the screening server 101. A property being available means that there is at least one available section, and a property being full means that there is no available section among the multiple sections contained in a specific property.
If the property is vacant, the property display module 212 determines whether a quick inspection is possible for the property (step 2080). If a quick inspection is possible (if the quick inspection availability 1461 in the partition table 1450 is yes), information that the property is vacant (open for applications) and that a quick inspection is possible is displayed together with the property information (step 2081).

The quick screening is a system that allows for a quick screening, which will be explained in more detail later. By displaying information about the quick screening available along with other property information, users can be given the impression that they can quickly conclude a rental contract.
If a quick inspection is not possible (the quick inspection availability 1461 in the section table 1450 is "no"), a normal inspection, not a quick inspection, will be conducted, and the fact that the property is vacant (open for applications) will be displayed together with the property information (step 2082). Note that in addition to displaying that the property is vacant (open for applications), it may also be possible to actively display that a quick inspection is not possible or that the property is open for normal inspection.
In this embodiment, the quick examination availability 1461 and waiting reservation availability 1462 can be changed arbitrarily.

As another embodiment, the property display module may store "yes" in "quick inspection possible/not possible" 1461 when all of the information on overall length, overall width, overall height, weight, and minimum ground clearance is stored in the section table 1450, and may store "no" in "quick inspection possible/not possible" in "quick inspection possible/not possible" when any of the information is not stored in the section table 1450. The property display module performs this process at predetermined intervals or constantly, and displays on the user terminal that a quick inspection can be performed only when all of the information on overall length, overall width, overall height, weight, and minimum ground clearance has been stored.
Alternatively, the property display module may determine that a quick inspection is possible based on all of the information on overall length, overall width, overall height, weight, and minimum ground clearance, regardless of the information on whether a quick inspection is possible 1461, and may determine that a quick inspection is not possible if any of these information is not stored. The property display module performs this process at predetermined intervals or constantly, and displays on the user terminal that a quick inspection can be performed only when all of the information on overall length, overall width, overall height, weight, and minimum ground clearance is stored.

If the property displayed on the user terminal 102 is not available and is booked, the property display module 212 determines whether the property can be reserved (step 2090). If the property can be reserved (if the availability reservation availability 1462 in the partition table 1450 is available), the property display module 212 displays information that the property is booked and that a reservation can be made together with the property information (step 2091).

Although details will be described later, by making a reservation to wait for a vacancy, when a property that is currently filled becomes vacant, a user can receive information from the screening server 101 that the property has become vacant.
If the property is not vacant but is full and cannot be reserved (if the availability reservation availability 1462 in the partition table 1450 is not available), the property display module 212 displays the fact that the property is full together with the property information (step 2092). Note that it is also possible to display not only that the property is full, but also that the property is not available for reservation.

An example will be described with reference to Figure 35. In the example of Figure 35, seven pieces of property information are displayed, and the following icon display is displayed to the right of each parking lot name.
"Shibuya No. 1 Parking Lot" (parking lot name) displays 3541 that the property is vacant and that a quick inspection is available.
"Shibuya No. 2 Parking Lot" (name of parking lot) displays a notice 3542 indicating that inquiries should be made to the inspection company regarding availability.
"Shibuya No. 3 Parking Lot" (name of parking lot) is currently full, and displays a message 3543 indicating that reservations can be made on a waiting list.
"Shibuya No. 4 Parking Lot" (name of parking lot) has a sign 3544 indicating that the property is full.
"Shibuya Parking Lot No. 5" (parking lot name) is currently vacant and is displaying a sign indicating it is available for hire.
"Shibuya No. 6 Parking Lot" (name of parking lot) displays a notice 3546 stating that inquiries about availability should be made to the inspection company.
"Shibuya No. 7 Parking Lot" (parking lot name) is displaying 3547 that the property is vacant and that a quick inspection is available.

An example will be given in FIG. 36. In the example shown in the figure, a portion of the detailed information for Shibuya No. 1 Parking Lot displays an icon 3622 indicating that the property is vacant and that a quick inspection is possible. In addition, icons 3631 and 3632 indicating the availability of the property are also displayed for properties in the vicinity.
I'm doing 32.
In Figures 35 and 36, icons showing the locations of parking lots are displayed on a map, and icons of parking lots where quick inspections are available are displayed separately from icons of parking lots where normal inspections are conducted. Specifically, only the properties where quick inspections are available have a "Q" displayed next to the display number 3520, 3550, and 3610.

FIG. 21 shows an example of a first screening execution flow 2100 executed by the screening execution module 211 of the screening server 101 .
When a user wishes to use a particular vacant property, the user must undergo and pass a certain screening process. This flow is a quick screening process executed by the screening execution module 211 in order to perform the screening process quickly.
The examination execution module 211 receives information on vacant properties desired to be used from the user terminal 102 (step 2110).

An explanation will be given using FIG. 36 as an example. In the example shown in the figure, buttons 3640 labeled "Apply for quick review" are displayed at the top and bottom of the display screen, and selecting the buttons by clicking, tapping, etc. will transition to the application screen for "Shibuya Daiichi Parking Lot" (parking lot name) (FIG. 37). When the user enters the information required for application on the application screen and presses the application execution button, the examination execution module 211 receives the vacant property information desired for use and all the submitted data required for the examination (step 2110). The submitted data received from the user terminal 102 is stored in the user basic table 1600 of the user information DB 223 of the examination server 101 or the certificate table 1050 of the examination information DB 221. Therefore, by determining whether there is any missing information stored in the user basic table 1600 or the certificate table 1050, the examination execution module 211 can determine whether all the submitted data has been received.

More specifically, the submitted data includes all or part of the information stored in the user management table 1650 (user ID), occupation, work address, work telephone number, main telephone number (in the case of a corporate contract), name of person in charge (in the case of a corporate contract), person in charge telephone number (in the case of a corporate contract), corporate homepage URL (in the case of a corporate contract), name of guarantor (if unemployed), name of guarantor's workplace (if unemployed), guarantor telephone number (if unemployed), relationship to guarantor (if unemployed), desired start date of use, whether or not a garage certificate is requested, use of the parking lot, whether or not a test parking is requested, and desired date and time for test parking.

More specifically, the submitted data is all or part of the information stored in the user contract table 1700, such as the presence or absence of a vehicle, the vehicle type, vehicle identification information (model), and registration number (number).
In addition, the submitted certificate data is all or part of the image data of the driver's license, image data of the vehicle inspection certificate (if the user owns a vehicle), image data of the voluntary insurance card (if the user owns a vehicle), image data of the residence certificate (if the user has a nationality other than Japan), and image data of the certified copy of the registry (in the case of a corporate contract), which are stored in the user contract table 1700 and the certificate table 1050, respectively.

Here, an explanation will be given taking Fig. 37 as an example. Fig. 37 is an example of a screen for registering submitted data in the screening server 101, and is displayed on the output device 305 of the user terminal 102. Selecting the display 3640 linked to "Apply for quick screening" in Fig. 36 transitions to the screen in Fig. 37. The items displayed in Fig. 37 that are requested to be input or uploaded are part of the example of submitted data mentioned above.
Items that are required to perform a quick review are marked as "required" 3710. In the example shown in the figure, if the item marked as "required" 3710 is not entered or uploaded, the quick review cannot be performed. As shown in the figure, "either one is required" 3720 is displayed, meaning that it is sufficient to enter either a home phone number or a mobile phone number.
In the example of FIG. 37, when all the "required" items are input or uploaded, the screen transitions to FIG.

Fig. 38 is an example of a screen displayed on the output device 305 of the user terminal 102 regarding confirmation items and terms regarding payment. Consent requirements 3810 are displayed at the bottom of the figure. After the user checks the various consent requirements, which are "required" items, and then selects the linked "Apply" button 3820, all entered or uploaded information is sent from the user terminal 102 to the screening server 101 and stored in the database. That is, the screening execution module 211 receives the property information and all submitted data required to undergo screening (step 2110).
With regard to the driver's license, vehicle inspection certificate, and optional insurance card to which image data is uploaded, the image data may be uploaded when the "Apply" button is selected, but the image data may also be configured to be uploaded in advance when the file is selected.
As shown in the example of the figure, the payment method 3830 and payment amount 3840 may be displayed on the user terminal 102 for the user to confirm.

The audit execution module 211 executes the quick audit (step 2120). The quick audit includes three audits, which will be described in detail later. The results of each of the three audits are stored in the audit result table 1000 of the audit information DB 221 of the audit server 101.
The module determines whether all three of the quick check results are OK (passed the check) (step 2130). If all three of the quick check results are OK, the module displays on the user terminal 102 that the check results are OK (step 2140). The user can then use the parking lot by following a prescribed procedure.
If any one of the three screening results is other than OK, the module displays that result and the reason for that result on the user terminal 102 (step 2150). After that, if the module receives new submitted data again, it executes another quick screening (step 2160 is Yes).

Here, an example will be described with reference to Fig. 39. Fig. 39 shows an example of a screen displaying the examination results on the output device 305 of the user terminal 102.
As shown in the example of this figure, if the screening result 3910 is NG, the reason 3920 is also displayed. This example displays the screening result of the case in the second row from the top of the screening result table 1000 (case with quick screening ID Q19000002). In other words, the information stored in the final screening result and reasons 1010 and 1011 of the screening result table 1000 is displayed, respectively.
In the example of FIG. 39, a link 3930 for transitioning to a screen for searching for other properties is displayed at the bottom of the display screen, and selecting this link 3930 transitions to a screen for searching again for the desired property.

As another example, if the review result is NG and the reason displayed is that the uploaded license image data is inappropriate, a link may be displayed to transition to a screen for uploading the license image again.
As another example, if the screening result is OK, a link may be displayed to transition to a screen for proceeding with the procedure for concluding a lease agreement for the property desired to be used.

FIG. 22 shows an example of an image analysis data registration flow 2200 implemented by the image analysis data registration module 213 of the examination server 101 .
The image analysis data registration flow 2200 executed by the image analysis data registration module 213 is a flow that analyzes image data related to the certificate received from the user terminal 102, extracts and stores string data, and displays an error if there is information that cannot be analyzed.
The module receives submission data from the user terminal 102 (step 2210).
The module determines whether the received submitted data is driver's license image data (step 2220). When image data is received together with data indicating that the image data is a driver's license image, the module determines that the image data is driver's license image data. Alternatively, the module may perform image analysis on the received image data to determine that the image data is a driver's license image. The same determination method is used in the following flows.

If the module determines that the received submitted data is license image data, it performs image analysis of a partial image of the reading area that matches the license format from the license image data, extracts license character string data such as name and address, and stores the data in the license table 1100 of the examination information DB 221 of the examination server 101 (step 2221).
In the image analysis, character recognition processing such as OCR (Optical Character Recognition) is performed on the read partial image data, and character string data is extracted from the image data.

The image analysis data registration module 213 determines whether all the license string data extracted and stored by image analysis required to perform a quick screening has been collected (step 2222). In other words, it determines whether all the information stored in the license table 1100 has been collected. The license string data required for a quick screening can be, for example, the name, address, date of birth, and expiration date listed in the license table 1100 in FIG. 7.

If all the license character string data is not available, the module displays an error on the user terminal 102 to the effect that all the license character string data could not be extracted and stored properly (step 2280). This makes it possible to prompt the user to register the license image again. Note that an example of a case in which all the character string data is not available is when the image quality of the received image data is poor and image processing cannot be performed properly.

Next, the image analysis data registration module 213 determines whether the received submitted data is vehicle registration certificate image data (step 2230).
When image data is received together with data indicating that the image data is a vehicle inspection certificate image, or when the received submitted data is determined to be vehicle inspection certificate image data by image analysis of the received image data, the module performs image analysis of a partial image of a read area that matches the format of the vehicle inspection certificate from the vehicle inspection certificate image data, extracts vehicle inspection certificate character string data such as the vehicle model and registration number (number), and stores the data in the vehicle inspection certificate table 1150 of the inspection information DB 221 of the inspection server 101 (step 2231). The image analysis data registration module 213 converts the unit of the extracted vehicle inspection certificate character string data (total length, total width, total height) and stores the data. For example, if the unit of the extracted data regarding the total length is cm (centimeter), the data is converted to mm (millimeter) and stored.

The image analysis data registration module 213 determines whether all vehicle inspection certificate character string data required for performing the quick inspection has been collected (step 2232). That is, it determines whether all information stored in the vehicle inspection certificate table 1150 has been collected. The vehicle inspection certificate character string data required for the quick inspection may be items listed in the vehicle inspection certificate table 1150 in FIG. 8, such as the vehicle type, overall length, overall width, and overall height.
If all the vehicle inspection certificate character string data is not available, the module displays an error message on the user terminal 102 indicating that all the vehicle inspection certificate character string data could not be extracted and stored normally (
(Step 2280).

The image analysis data registration module 213 determines whether the received submitted data is voluntary health insurance card image data (step 2240).
If image data is received together with data indicating that the image data is an optional health insurance card image, or if image analysis of the received image data determines that the received submitted data is optional health insurance card image data, the module performs image analysis of a partial image of the reading area from the optional health insurance card image data that matches the format for optional health insurance verification, to extract optional health insurance card character string data such as the name and expiration date, and stores the data in the optional health insurance card table 1200 of the review information DB 221 of the review server 101 (step 2241).

The image analysis data registration module 213 determines whether all of the optional health insurance card character string data required to perform the quick inspection has been collected (step 2242). That is, it determines whether all of the information stored in the optional health insurance card table 1200 has been collected. The optional health insurance card character string data required for the quick inspection may be items listed in the optional health insurance card table 1200 in FIG. 9, such as name, address, and registration number.
If all of the optional health insurance card character string data is not present, the module displays an error on user terminal 102 to the effect that it was not possible to properly extract and store all of the optional health insurance card character string data (step 2280).

Next, the image analysis data registration module 213 determines whether the received submitted data is residence certificate image data (step 2250).
If image data is received together with data indicating that the image data is a residence certificate image, or if image analysis of the received image data determines that the received submitted data is residence certificate image data, the module extracts residence certificate string data such as name and address by image analysis of a partial image of the reading area that matches the format of the residence certificate from the residence certificate image data, and stores the data in the residence certificate table 1250 of the review information DB 221 of the review server 101 (step 2251).

The image analysis data registration module 213 determines whether all the residence certificate character string data required to perform the quick screening has been collected (step 2252). That is, it determines whether all the information stored in the residence certificate table 1250 has been collected. The residence certificate character string data required for the quick screening can be, for example, the items listed in the residence certificate table 1250 in FIG. 10, such as name, address, date of birth, and expiration date.
If all the residence certificate character string data is not available, the module displays an error on the user terminal 102 to the effect that it was not possible to extract and store all the residence certificate character string data normally (step 2280).

Next, the image analysis data registration module 213 determines whether the received submitted data is image data of a copy of the real estate register (step 2260).
When image data is received together with data indicating that the image data is a certified copy of the real estate register, or when image analysis of the received image data determines that the received submitted data is certified copy of the real estate register image data, the module performs image analysis of a partial image of a reading area that matches the format of the certified copy of the real estate register from the certified copy of the real estate register image data, thereby extracting certified copy of the real estate register character string data such as the company name and address, and stores the extracted data in the certified copy of the real estate register table 1300 in the review information DB 221 of the review server 101 (step 2261).

The image analysis data registration module 213 determines whether all the registered copy character string data required for the quick screening has been collected (step 2262). That is, it determines whether all the information stored in the registered copy table 1300 has been collected. The registered copy character string data required for the quick screening can be, for example, the items listed in the registered copy table 1300 in FIG. 11, such as the name, the representative's name, the location, and the date of establishment.
If all the registry certified copy character string data is not available, the module displays an error on the user terminal 102 to the effect that all the registry certified copy character string data could not be extracted and stored normally (step 2280).

In other words, the image analysis data registration module 213 identifies what type of image data the received image data is and the type of certificate, selects a format (certificate layout) corresponding to the certificate type of the identified image data, obtains partial images of one or more reading areas that match the selected format, and performs highly accurate image analysis.
For example, in the case of a driver's license, certificate information can be obtained from each part corresponding to the selected format, such as obtaining name information from the upper partial image of the image, obtaining the date of birth from the upper right part, and obtaining the person's photo information from the right part, in accordance with the format (layout) of the license.

Image analysis may be performed on the user terminal 102 side. In this case, the image analysis data registration module 213 may determine whether all of the certificate string data for each certificate has been collected after receiving the string data after image analysis and image data from the user terminal 102. Furthermore, the user terminal 102 may determine whether all of the certificate string data for each certificate has been collected. In this case, it is only necessary to receive all of the collected image data and string data from the user terminal 102, and there is no need to determine again whether all of the string data has been collected.

FIG. 23 shows an example of a certificate data submission determination flow 2300 executed by the examination execution module 211 of the examination server 101 .
The certificate data submission determination flow 2300 executed by the examination execution module 211 is a flow for determining whether all certificate data required for examination has been prepared before performing a quick examination.
The examination execution module 211 acquires data from the user basic table 1600 and the certificate table 1050 (step 2310).
The screening execution module 211 determines whether the contract type of the user who is the subject of the quick screening is an individual contract and whether the nationality is foreign (step 2320). That is, the module 213 checks the information on the contract type and nationality stored in the user management table 1650.

If the user is an individual contract holder and has foreign nationality, the examination execution module 211 judges whether all the residence certificate data is available (step 2321). That is, the module 211 judges whether information exists in the residence certificate table 1250.
If all the residence certificate data is not available, the examination execution module 211 stores a message indicating that the residence certificate data does not exist (step 2322).

The examination execution module 211 determines whether the contract type of the user is a corporate contract (step 2330).
If the user is a corporate contract user, the examination execution module 211 determines whether all the registry copy data is available (step 2331). That is, the module 211 determines whether information exists in the registry copy table 1300.
If all the registry copy data is not available, the examination execution module 211 determines whether the data of the corporation's homepage URL exists in the user management table 1650 (step 2332).
If the corporate homepage URL data does not exist, the examination execution module 211 stores the fact that the registry data and the corporate homepage URL do not exist (step 2333).

The examination execution module 211 determines whether the license data of the target user exists in the certificate table (step 2340).
If the license data does not exist in the license table 1100, the examination execution module 211 stores the fact that the license data does not exist (step 2341).
The examination execution module 211 determines whether the user has a vehicle (step 2350). That is, the examination execution module 211 checks the information on the vehicle status stored in the user contract table 1700.
If the user owns a vehicle, the examination execution module 211 determines whether vehicle inspection certificate data exists in the vehicle inspection certificate table 1150 (step 2360).
If the vehicle inspection certificate data does not exist in the vehicle inspection certificate table 1150, the examination execution module 211 stores the fact that the vehicle inspection certificate data does not exist (step 2361).

Next, if the user owns a vehicle, the examination execution module 211 determines whether or not optional insurance card data exists in the optional insurance card table 1200 (step 2370).
If the health insurance card data does not exist in the health insurance card table 1200, the examination execution module 211 stores information indicating that the health insurance card data does not exist (step 2371).
If the user does not own a vehicle, the examination execution module 211 determines whether vehicle identification data exists in the user contract table 1700 (step 2351).
If the vehicle identification data does not exist, the examination execution module 211 stores the fact that the vehicle identification data does not exist (step 2352).
The vehicle specific data is used to obtain a vehicle catalog of a specific vehicle from an external website. The vehicle specific data is information on the model of the vehicle, and preferably also includes grade information.

The audit execution module 211 determines whether all the certificate data or vehicle identification data required for the user to undergo the quick audit is present (step 2380).
If all of the submitted data are present, the screening execution module 211 stores the fact (step 2381). If all of the other submitted data are present, the screening execution module 211 executes a quick screening.
If none of the data is present, the module 211 displays the missing data on the user terminal 102 (step 2382).
The flow executed by the examination execution module 211 may be entirely performed on the user terminal 102 side.

FIG. 24 shows an example of a quick audit flow 2400 executed by the audit execution module 211 of the audit server 101 .
The quick audit flow 2400 executed by the audit execution module 211 is a flow for executing three audits: submitted data audit, vehicle audit, and user audit, which are carried out after all data required for the audit has been collected.
The examination execution module 211 executes a submitted data examination to examine whether the data submitted from the user terminal 102 is appropriate (step 2410).
The inspection execution module 211 judges whether the data used in the vehicle inspection has passed the submitted data inspection (whether the data is appropriate) (step 2420). The module 211 can make this judgment by checking the submitted data inspection result and the reason in the inspection result table 1000. The data used in the vehicle inspection are driver's license data, vehicle inspection certificate data, and optional insurance card data.

If the examination execution module 211 receives the vehicle catalog information, it proceeds to the next step (step 2430).
If vehicle catalog information is received, the module 211 performs a vehicle screening (step 2440).
The screening execution module 211 judges whether the data used in the user screening has passed the submitted data screening (step 2450). The module 211 can make this judgment by checking the submitted data screening results and reasons in the screening result table 1000. The data used in the user screening are driver's license data, residence certificate data, and certified copy of real estate registry data.
If the data used in the user authentication passes the submitted data authentication, the module executes the user authentication (step 2460).

As another embodiment, the property display module may display on the user terminal of a user that a quick review can be conducted (determining that a quick review is possible) only when all of the specified information submitted by the user is present. In other words, the property display module may display on the user terminal of a user who has submitted all of the specified information in advance that a quick review can be conducted (determining that a quick review is possible), and display on the user terminal of a user who has not submitted all of the specified information in advance that a normal review will be conducted (determining that a quick review is not possible). The property display module may store information on whether or not all of the specified information is present.
Specifically, the property display module may display on the user's user terminal a message indicating that a quick inspection can be conducted when the user has all the submitted data necessary for the user to undergo the quick inspection, where all the submitted data is vehicle information, certificate information, and personal information related to the user's individual or corporate information necessary for the user to undergo the quick inspection.

Alternatively, the property display module may display on the user's user terminal a message indicating that a quick review can be conducted if the user has all the submitted data required to undergo a quick review and all submitted data has passed the submitted data review.
Alternatively, the property display module may display on the user's user terminal a message indicating that a quick inspection can be performed if the user has all the vehicle information related to the vehicle required to undergo a quick inspection.
Alternatively, the property display module may display on the user's user terminal a message indicating that a quick review can be performed if the user has all the certificate information necessary to undergo a quick review.
Alternatively, the property display module may display on the user's user terminal a message indicating that a quick inspection can be conducted if the user has all the personal information related to the user's individual or corporate identity required to undergo a quick inspection.

FIG. 25 shows an example of a vehicle catalog information acquisition flow 2500 implemented by the inspection execution module 211 of the inspection server 101 .
The vehicle catalog information acquisition flow 2500 executed by the inspection execution module 211 is a flow performed to acquire vehicle catalog data required for the inspection.
The screening execution module 211 receives information on whether the user being screened owns a vehicle (information on whether or not the user owns a vehicle) (step 2510).
The screening execution module 211 determines whether the user being screened owns a vehicle (step 2520). This determination can be made by checking the information in the vehicle presence/absence 1708 in the user contract table 1700.

If the vehicle is owned, the module determines whether the vehicle registration data has passed the submission screening (step 2530).
If the vehicle inspection certificate data passes the submission review, vehicle identification data such as the vehicle name and model are obtained from the vehicle inspection certificate data, and vehicle catalog data corresponding to the vehicle identification data is obtained from an external website (step 2550).

If the vehicle is not owned, the module 211 determines whether it has received enough vehicle specific data to obtain the specific vehicle catalog data (step 2540).
When the vehicle model information of the vehicle to be purchased is input on the data registration screen in Fig. 37, a list of the corresponding vehicle models is displayed. By selecting the model number of the vehicle to be purchased from this list, the vehicle identification data for identifying the vehicle to be purchased can be determined.
When the vehicle identification data is received, the vehicle catalog data is acquired from the website (step 2550), and then stored in the vehicle catalog table 1350 of the inspection information DB 221 of the inspection server 101 (step 2560).
The vehicle catalog information acquisition flow 2500 by this module must be completed before the vehicle inspection is carried out.

FIG. 26 shows an example of a submitted data review flow 2600 executed by the review execution module 211 of the review server 101 .
The submitted data inspection flow 2600 executed by the inspection execution module 211 is a flow for determining whether the data required for vehicle inspection or user inspection is proper data.
The examination execution module 211 checks the data in the certificate table 1050 against the data in the basic user table 1600 (step 2610).
The screening execution module 211 determines whether the name or title included in the certificate table 1050 to be screened matches the name or title stored in the user basic table 1600 (step 2620). Even if they do not match completely, it is sufficient if the two pieces of data correspond. For example, when the names are written in variant characters, the screening execution module 211 may determine that the two pieces of data correspond.
In the case of license data, the name in the license table 1100 is matched with the user name in the user management table 1650 .

In the case of certified copy of the register data, the name in the certified copy of the register table 1300 is matched with the contracting party name in the user management table 1650. In addition, the representative name in the certified copy of the register table 1300 may be matched with the representative name in the user management table 1650.
In the case of residence certificate data, the name in the residence certificate table 1250 is matched with the user name in the user management table 1650 .
In the case of a vehicle inspection certificate, the name or title of the owner or user in the vehicle inspection certificate table 1150 is matched with the name or title of the contractor or user in the user management table 1650 .
In the case of a voluntary health insurance card, the name in the voluntary health insurance card table 1200 is matched with the user's name in the user management table 1650 .
If the names and other details do not match, the review execution module 211 stores the result of the submitted data review as NG (the certificate data is inappropriate) and the reason for this in the result and reason for the submitted data review in the review result table 1000 (step 2660).

The examination execution module 211 judges whether the address or location included in the certificate table 1050 to be examined matches the address or location stored in the user basic table 1600 (step 2630). Even if they do not match completely, it is sufficient that the two data correspond. For example, if the two data indicate substantially the same address or location, the examination execution module 211 may judge that the two data correspond. The cases where the two data indicate substantially the same address or location include, for example, when one is written as "Chome", "Number" or "Number" and the other is written as - (hyphen), when they are written in variant characters, when one is written in Chinese numerals and the other is written in Roman numerals, when one does not have a building name and the other has a building name, etc.

In the case of license data, the address in the license table 1100 is matched with the user address in the user management table 1650 .
In the case of certified copy of the deed register data, the address in the certified copy of the deed register table 1300 is matched with the corporate address in the user management table 1650 .
In the case of residence certificate data, the address in the residence certificate table 1250 is matched with the user address in the user management table 1650 .
In the case of a vehicle inspection certificate, the address of the owner or user in the vehicle inspection certificate table 1150 is matched with the user address or corporate address in the user management table 1650 .
In the case of a voluntary health insurance card, the address in the voluntary health insurance card table 1200 is matched with the user's address in the user management table 1650 .
If the addresses, etc. do not match, the review execution module 211 stores the result of the submitted data review as NG (the certificate data is inappropriate) and the reason for this in the result and reason for the submitted data review in the review result table 1000 (step 2660).

The module determines whether the certificate being examined is valid (step 2640).
In the case of certified copy data of the register, it is determined whether the certified copy issuance date in the certified copy table 1300 is within the past three months.
In the case of license data, the expiration date in the license table 1100 is compared with the usage start date in the user contract table 1700 to determine whether the license data is valid on the usage start date.
In the case of residence certificate data, the expiration date in the residence certificate table 1250 is compared with the use start date in the user management table 1650 to determine whether the data is valid on the use start date.
In the case of a vehicle inspection certificate, the expiration date in the vehicle inspection certificate table 1150 is compared with the usage start date in the user contract table 1700 to determine whether it is valid on the usage start date.
In the case of a voluntary health insurance card, the expiration date in the voluntary health insurance card table 1200 is compared with the start date of use in the user contract table 1700 to determine whether the card is valid on the start date of use.

If the review execution module 211 determines that the certificate is invalid, it stores the result of the submitted data review as NG (the certificate data is inappropriate) and the reason for this in the result and reason for the submitted data review in the review result table 1000 (step 2660).
If the review execution module 211 does not contain any certificate data for which the submitted data review result is NG, it stores the submitted data review as OK (all submitted data is proper) in the review result table 1000 (step 2650).
The examination execution module 211 may subject only a portion of the certificate data to the submitted data examination. In this case, the certificate data that has not been subjected to the examination can be treated as having passed the examination (the certificate data is proper).

FIG. 27 shows an example of a vehicle inspection flow 2700 implemented by the inspection execution module 211 of the inspection server 101 .
The vehicle inspection flow 2700 executed by the inspection execution module 211 is a flow for determining whether the user's vehicle is suitable for the parking lot that the user wishes to use.
The examination execution module 211 obtains the vehicle data from the vehicle inspection certificate table 1150 or the vehicle catalog table 1350, and the partition data from the partition table 1450 (step 2710).

The screening execution module 211 matches the vehicle data with the section data (step 2720).
The inspection execution module 211 determines whether the user's vehicle satisfies the size conditions of the partition (step 2730). Specifically, the module can determine that the user's vehicle satisfies the size conditions of the partition if the overall length, overall width, and overall height values of the vehicle data are smaller than the overall length, overall width, and overall height values of the partition data.
If the vehicle does not meet the lot size requirements, the module records in the inspection result table 1000 that the vehicle inspection was not successful and the reason for this (step 2780).

The screening execution module 211 determines whether the user's vehicle satisfies the weight condition of the section (step 2740). Specifically, the screening execution module 211 can determine that the user's vehicle satisfies the weight condition of the section if the weight value in the vehicle data is smaller than the weight value in the section data.
If the vehicle does not satisfy the weight requirement of the section, the inspection execution module 211 records the fact that the vehicle inspection was not successful and the reason for this in the inspection result table 1000 (step 2780).
The inspection execution module 211 determines whether the user's vehicle satisfies the minimum ground clearance condition of the section (step 2750). Specifically, the module can determine that the user's vehicle satisfies the minimum ground clearance condition of the section if the minimum ground clearance value in the vehicle data is greater than the minimum ground clearance value in the section data.
If the vehicle does not satisfy the minimum ground clearance requirement of the section, the inspection execution module 211 records in the inspection result table 1000 that the vehicle inspection was not successful and the reason for this (step 2780).

The examination execution module 211 determines whether the user's vehicle satisfies other conditions (step 2760). The other conditions include, for example, the use of the vehicle and the shape of the vehicle body.
If the vehicle does not meet the other conditions of the section, the module records the vehicle inspection result and reason as NG in the vehicle inspection result table 1000 (step 2780).
If the vehicle satisfies all the conditions, the module records the fact that the vehicle inspection was OK in the vehicle inspection result and reason field in the inspection result table 1000 (step 2770).
That is, in this flow, the information (sometimes called usage condition information) that must be satisfied in order for a user's vehicle to be suitable for a particular parking lot is at least the overall length, overall width, overall height, weight, and minimum ground clearance. Also, information (sometimes called vehicle information) about the vehicle of a user who wishes to use a particular parking lot must contain information of the same category as the usage condition information. For example, information that can be compared is of the same category, such as information of the same category as usage condition information (overall length) being vehicle information (overall length).

FIG. 28 shows an example of a first user audit flow 2800 implemented by the audit execution module 211 of the audit server 101 .
The first user screening flow 2800 executed by the screening execution module 211 is a flow for screening whether the user has any affiliation with anti-social forces.
The examination execution module 211 can obtain article information based on keywords by searching, and specifically, can obtain the information as follows.

The screening execution module 211 searches external news sites to see if there are any news articles that are evidence that the user is associated with antisocial forces (step 2810). Specifically, in the case of an individual contract, it is determined whether there is an article that includes both the user's name or the name of the employer and a word related to antisocial forces. In the case of a corporate contract, it is determined whether there is an article that includes both the corporate name or the representative's name and a word related to antisocial forces. Words related to antisocial forces include, for example, gangs, corporate racketeers, mafia, illegal lending, illegal donations, corporate yakuza, front companies, pseudo-Dowa, pseudo actions, quasi-members, right wing, left wing, and pressure groups.

The screening execution module 211 determines whether the news article is found (step 2820).
The screening execution module 211 checks the news article against user data other than the user name or place of employment stored in the user basic table 1600 (step 2830). This makes it possible to determine whether the news article is proper information. Specifically, for example, the module checks the birth date (age) of the user stored in the certificate table 1050 or the user management table 1650 against the birth date (age) of the person described in the news article. If the birth dates are the same, it is highly likely that the user and the person in the news article are the same person, so the news article is determined to be proper. On the other hand, if the birth dates are different, the news article is determined to be inappropriate. In addition to the combination of name and birth date, screening can be performed based on the first personal identification information, and for hits, a suitability check can be performed based on the second personal identification information, such as company name or address, to determine whether the person is the person in question.

The examination execution module 211 determines whether the news article is appropriate (step 2840).
If the news article is appropriate, the module stores the news article in the review result table 1000 (step 2850). After that, the review execution module 211 stores the fact that the user review is pending and the reason for this in the user review result and reason section of the review result table 1000 (step 2860). In this case, the review result is displayed as pending so that the article's appropriateness can be finally determined later based on human judgment.
If the news article is not found, or if the news article is inappropriate (an article unrelated to the user), the module proceeds to a second user screening flow 2900 .

FIG. 29 shows an example of a second user audit flow 2900 implemented by the audit execution module 211 of the audit server 101 .
The second user screening flow 2900 executed by the screening execution module 211 is a flow for screening whether or not the user has ties to anti-social forces, similar to the first user screening flow 2800.
Only the points that differ from the first user authentication flow 2800 will be explained.
In the second user screening flow 2900, the screening execution module 211 searches an external search engine site to see if there are any news articles that provide evidence that the user is involved with anti-social forces (step 2910).
In the second user review flow 2900, it is determined whether the user review is currently on hold (step 2970), and if the user review is not currently on hold, a message indicating that the document review is OK is stored in the review result table 1000 (step 2980).

In the first and second user screening flows in Figures 28 and 29, if the screening is not OK, the screening result is put on hold and detailed manual confirmation work is then performed, but instead, the screening may be marked as NG.
In addition to or instead of the first and second user screening flows of Figures 28 and 29, it is also possible to carry out screening of users using credit information, and to suspend or reject user screening if the credit information is below a certain value.
Examples of credit information that can be used include credit card credit information, credit information based on payment information for rent or loans, status information based on educational background and company name, and personal credit information based on big data such as Sesame Credit.

FIG. 30 shows a review management flow 30 executed by the review management module 214 of the review server 101.
This is an example of 00.
Here, the inspection company may be entrusted with managing a specific property by an owner or a property management company that manages the specific property. In this case, the inspection company must also conduct an inspection of the user who is using the property to determine whether the user of the entrusted property is trustworthy. That is, the inspection execution module 211 of the inspection server 101 can execute the first inspection execution flow 2100, which includes the above-mentioned quick inspection. However, in this case, the submission data required for the inspection is transmitted from the owner terminal 103. Also, since each property is already being used by a user, the vehicle inspection part of the quick inspection may not be conducted.
Owners or property management companies may want to check whether users for each entrusted property have passed the screening. Also, when an screening company is entrusted with the management of multiple properties, it may want to manage the screenings in a centralized manner.
The review management flow 3000 executed by the review management module 214 is a flow for the review company, owner, or property management company to check or manage the review status of the user.

The review management module 214 receives an instruction from the owner terminal 103 or the review company terminal 104 to display the review status of a specific review target case (step 3010).
The module displays the review status of the specific case under review on the owner terminal 103 or the review company terminal 104 (step 3020). If there are multiple cases under review, multiple cases can be displayed. When the review has been completed, the review status is displayed by displaying the final review result and reason stored in the review result table 1000 of the review information DB 221 of the review server 101, and when the review has not yet been completed, a message indicating that the review has not been completed is displayed.

Here, an explanation will be given using Fig. 40 as an example. Fig. 40 is an example of a screen that displays the review status of a specific case under review on the output device 405 of the owner terminal 103. Specifically, it is an example of a screen that is displayed on the owner terminal 103 when a search is performed by narrowing the status item to "waiting for review" 4010. In the example of this figure, three cases under review that have not yet been reviewed 4020 are displayed in the lower part. After checking the display, if the owner wishes to inquire of the review company about the review status, the owner can inquire of the review company by selecting the display of the linked "inquiry" 4030 displayed in the center of the figure.
The review management module 214 receives an instruction from the review company terminal 104 to review all unreviewed cases at once (step 3030).

Here, an explanation will be given taking Fig. 41 as an example. Fig. 41 is an example of a screen that displays the review status of a specific case to be reviewed on the output device 505 of the review company terminal 104. Fig. 41 differs from Fig. 40 in that "Start quick review" 4110 is displayed in the center. The display of "Start quick review" 4110 is linked, and when this display is selected, the review of all displayed cases to be reviewed that have not yet been reviewed will be started.
The review management module 214 determines whether all the submitted data required for the quick review has been received from the owner terminal 103 (step 3040).
If all the information has been received, the screening execution module 211 executes the quick screening flow 2400 for the specified case (step 3050).
The review management module 214 displays the final review result and the reason instead of displaying that the item is not yet reviewed (step 3060).

FIG. 31 shows an example of a first vacancy waiting reservation flow 3100 implemented by the screening execution module 211 of the screening server 101 .
The first waiting list reservation flow 3100 executed by the screening execution module 211 is a flow that is executed when a user reserves a property that is fully booked.
The examination execution module 211 receives an instruction from the user terminal 102 to make a waiting reservation for a property that is fully booked (step 3110).

Here, an explanation will be given taking Fig. 42 as an example. Fig. 42 is an example of a screen displaying detailed information of one property on the output device 305 of the user terminal 102. The property whose detailed information is displayed in this figure is one of the properties displayed in Fig. 35, and by selecting the display of linked property information displayed in Fig. 35, the screen of Fig. 42 is displayed.
By selecting the display 4210 linked to "Make a reservation for a vacant lot" in Fig. 42, information to reserve the property is transmitted from the user terminal 102. As a result, in the example shown in Fig. 42, the module receives an instruction from the user terminal 102 to make a reservation for a vacant lot for the property that is in a booked state.
However, in order for a user to make a reservation for a vacant waiting time, the minimum user information must be registered in the examination server 101. Therefore, for a user who has not registered the relevant information, a message is displayed on the user terminal 102 indicating that the information needs to be registered. The minimum user information is, for example, a name and an email address.

When the property becomes available, the screening execution module 211 transmits information to the user terminal 102 from the screening server 101 that a request for use is now possible (step 3120). This allows a user who has made a reservation to apply for use of the property earlier than a user who has not made a reservation (performs a quick screening). When there are multiple users who have made a reservation for a property, the screening execution module 211 may transmit the information to multiple users at the same time, or may transmit the information to multiple users at different times according to some hierarchy.
After this, the module executes the first examination execution flow 2100 described above.

FIG. 32 shows an example of a second vacancy waiting reservation flow 3200 implemented by the screening execution module 211 of the screening server 101 .
The second waiting list reservation flow 3200 executed by the screening execution module 211 is a flow for performing a quick screening while waiting for an available space.
The examination execution module 211 receives an instruction to make a waiting reservation from the user terminal 102 for a property that is filled and available for waiting reservation (step 3210).
The screening execution module 211 determines whether the number of users who have made reservations for the property is 10 or more (step 3220).

If the property becomes available before the number of users who have made reservations reaches 10 or more, the module sends a notification from the review server 101 to the user terminals 102 of multiple users (all users who will make reservations) that the property has become available (that applications for use are now possible) (step 3280).
If the number of users who have made reservations reaches 10 or more, a quick screening is performed for all users who have made reservations. First, the screening execution module 211 receives the submitted data of the first user among those who have made reservations (the user with the reservation number 1 in the reservation table 1550) (step 3230).

The screening execution module 211 executes the first quick screening using the received submitted data (step 3240).
The screening execution module 211 determines whether the quick screening has been completed for all users who have made reservations (step 3250).
If the quick screening has not been completed for all users, the module will perform the quick screening after receiving (step 3251) the submitted data of the user who has made the next reservation (the user with the next reservation number in the reservation table 1550).

When the quick screening for all users is completed, the module judges the users whose quick screening results were OK (the final screening results in the screening result table 1000 are OK) (step 3260).
For users whose quick inspection results are OK, the inspection execution module 211 displays the inspection result OK on the user terminal 102 (step 3270). After that, the inspection execution module 211 sends a notification from the inspection server 101 to users (user terminals 102) whose quick inspection results are OK (the specific parking lot can be used) that it will be possible to apply for use if the property becomes vacant (step 3280). In other words, the notification is not sent to the user terminals 102 of users whose quick inspection results are NG.

For users whose quick screening results are NG or pending, the screening execution module 211 displays the results of the screening and the reasons for it on the user terminal 102 of the user (step 3261). If the submitted data is insufficient and the screening cannot be completed, this fact is displayed.
Thereafter, when the screening execution module 211 receives new submitted data again (step 3262), it executes the quick screening again (step 3240).

FIG. 33 shows an example of a second screening execution flow 3300 performed by the screening execution module 211 of the screening server 101 .
The second screening execution flow 3300 executed by the screening execution module 211 is different from the first screening execution flow 2100 in that the screening is carried out first regardless of whether the property desired to be used is vacant or occupied.
Below, only the differences from the first screening execution flow 2100 will be explained.

The screening execution module 211 receives the property information and all submitted data for use (step 3310). The property may be vacant or filled.
A quick screening is then conducted (step 3320), and it is determined whether the screening results are OK (step 3330). If the results are OK, the screening execution module 211 displays on the user terminal 102 a message indicating that the screening results are OK (step 3350), and then determines whether the property desired to be used is vacant or filled (step 3360).
If the property is vacant, the examination execution module 211 displays on the user terminal 102 a message indicating that the property is available (step 3370).
If the property is full, the examination execution module 211 transmits information to the user terminal 102 when the property becomes vacant (step 3380).

The property information desired to be used can also be received by the screening execution module 211 receiving a notification that the user terminal 102 has accessed a specific URL. The specific URL is linked to a specific property, and the user can request to use the property by accessing the specific URL from the user terminal 102. The specific URL may be, for example, a URL that is displayed when a specific QR (Quick Response) code (registered trademark) is read by the camera unit of the user terminal 102. The QR code (registered trademark) may be displayed on a sign at the parking lot location or on the output device 305 of another user terminal 102. The specific URL may also be, for example, a URL stated in an email sent from the screening server 101 to the user terminal 102.

FIG. 34 shows an example of a waiting reservation information input flow 3400 executed by the screening execution module 211 of the screening server 101 .
The waiting list reservation information input flow 3400 executed by the examination execution module 211 is a flow for changing information that the user is prompted to input depending on whether or not a quick examination of the property for which a waiting list reservation has been made is possible.
The screening execution module 211 receives the filled property information desired for use (step 3410). For example, the reception of the desired property information for use may be performed when the screening execution module 211 receives a notification that the user terminal 102 has accessed a specific URL, as in the example of FIG.
The inspection execution module 211 determines whether the received property is eligible for a quick inspection (step 3420).

If quick screening is possible (if the quick screening availability 1461 in the partition table 1450 is "yes"), the screening execution module 211 prompts the user to enter all the submission data required for the quick screening (step 3430). For example, the user terminal 102 may display a screen for prompting the user to enter all the submission data as shown in FIG.
If quick screening is not possible (if the quick screening availability 1461 in the partition table 1450 is not possible), the screening execution module 211 prompts the user to enter a name and email address (step 3440). For example, the user terminal 102 may display a screen for entering a name and email address instead of the example screen of FIG.
Thereafter, the process can proceed to the first vacancy waiting reservation flow 3100 or the second vacancy waiting reservation flow 3200 described above.

Here, in another embodiment, all the databases described above are included in one server, but the databases described above may be distributed across multiple servers. For example, there may be an examination server and two other servers, with the examination server having an examination information DB, the first other server having a user information DB, and the second other server having a property information DB. More specifically, the examination server with the examination information DB may have an examination execution module, a property display module, an image analysis data registration module, and an examination management module. In this case, a quick examination is performed on the examination server, and information stored in the property information DB and the user information DB used in the examination is obtained from the other servers each time. When the examination on the examination server is completed, the information obtained from the property information DB and the user information DB among the information used in the examination is erased. However, some information such as the examination results may be commonly stored in the databases of each server. This allows the amount of information stored in the examination server's database to be reduced, allowing for a more rapid examination.

The present invention is not limited to the above-described embodiments, but includes various modified examples. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those having all of the configurations described. It is also possible to replace part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

Furthermore, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in hardware, in part or in whole, for example by designing them as integrated circuits. Furthermore, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information on the programs, tables, files, etc. that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a storage medium such as an IC card, an SD card, or a DVD.

In addition, the control lines and information lines shown are those considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be assumed that almost all components are interconnected.

1...Inspection system, 101...Inspection server, 102...User terminal, 103...Owner terminal, 104...Inspection company terminal, 211...Inspection execution module, 212...Property display module, 213...Image analysis data registration module, 214...Inspection management module, 221...Inspection information DB, 222...Property information DB, 223...User information DB

Claims (6)

an examination execution module that performs examination regarding a parking lot contract based on information on the certificate provided by the user ;
An inspection system in which, when the inspection execution module acquires vehicle inspection certificate data as information relating to the certificate, the inspection execution module identifies the vehicle's catalog data based on vehicle identification data contained in the vehicle inspection certificate data . The screening system of claim 1, wherein the screening execution module, when the user does not own a vehicle, obtains vehicle identification data of the vehicle to be purchased, and identifies catalog data of the vehicle to be purchased based on the vehicle identification data of the vehicle to be purchased . The inspection includes an inspection of the vehicle;
The inspection system according to claim 1, wherein the inspection execution module, in inspecting the vehicle, inspects whether the vehicle is suitable for the parking lot based on the catalog data and data of the parking lot for which the user wishes to make a contract . The suitability of the vehicle for the parking lot is determined by matching the size of the vehicle with the size of the parking lot .
The screening system according to claim 3 . The screening includes screening of the user,
The examination execution module, in the examination of the user,
The screening system according to claim 1 , further comprising a search for article information including at least a part of the user's personal information and a predetermined keyword on a news site . A method for executing an audit in an audit system for parking lot use, comprising:
The screening system includes a screening execution step of performing screening regarding a parking lot contract based on information on the certificate provided by the user,
In the inspection execution step, when the inspection system acquires vehicle inspection certificate data as information regarding the certificate, the inspection execution method identifies the vehicle's catalog data based on vehicle identification data contained in the vehicle inspection certificate data.