Untitled record

<a name="caption1"></a>

Controlling the use of a single multi-vehicle parking lot with multiple cameras

CONTROLLING USE OF A SINGLE MULTI-VEHICLE PARKING SPACE

USING MULTIPLE CAMERAS

full description

invention background

This invention relates to the use of cameras to identify vehicles and track and control the use of parking spaces.

The operators of various government and private parking lots own municipal and private parking

extensive legacy parking management operators 5

systems are used to manage the use of destination locations designated for vehicles and to collect any revenues from their users, such as parking for wheeled motor vehicles. The reboot process and high cost that would traditionally be required to improve these legacy systems so that they are fully automated imposes a substantial 10 up-front capital investment that precludes such improvements from being made by several position operators.

There is a need for a fully automated and autonomous parking management system that can be easily integrated with existing parking payment systems, including systems that have already been installed and operated for some time, and this will open up new opportunities and efficiencies to achieve any revenue for operators. Attach parking of vehicles that have not been used 15 in advance.

General description of the invention

In one embodiment, a method is provided to track the use of at least one destination, and the method includes the following: Receiving a set of vehicle images taken from a camart set, wherein each vehicle image includes an image of a first vehicle, and a set of

<p dir="rtl">20 The cam art on a cam, first identification camera, and a destination cam </p>

destination camera, vehicle images include one or more first identification images captured by the first identification cam, a set of destination images captured by the destination cam including a first destination image captured at a first time, a second destination image It is captured at a second time after the first time, and a third destination image is captured

<p dir="rtl">5 Captured at a third time after the second time, determining a first unique identifier for the first vehicle on the basis of the first identification images, determining a first set of characteristics for the first vehicle on the basis of the first identification images, defining a second set of characteristics for the vehicle on the basis of one or more identification images, Determine that the second set of characteristics correspond to the first set of characteristics, determine that the image of the first vehicle is in the set of images of the destination 10 on the basis of determining that the second set of characteristics correspond to the first set of Characteristics, determining that the first vehicle stops at the first destination on the basis of the first destination image and the second destination image; Determining that the first vehicle left the first destination on the basis of the image of the third destination, indicating that the first vehicle started using the first destination at the first time, and indicating that the first vehicle ended using the place</p>

<p dir="rtl">15th The first is meant at the third time, where the previous steps of reception, identification and signaling are carried out by one computer or several computers that are programmed as a group to perform the previous steps.</p>

When executing instructions in a nontransitory computer readable medium, one or more computers receive a set of vehicle images captured by a set of cameras, each vehicle image containing an image of the first 20 vehicles, and the set of cameras includes: A first identification camera and a destination camera The vehicle images include one or more first identification images captured by the first identification camera, a set of destination images captured by the destination camera Including a first destination image captured at a first time, a second destination image captured at a second time after the first time, and a third destination image captured at a third time after time

<p dir="rtl">25 Second, identifying a first unique identifier for the first vehicle based on the first identification images, identifying a first set of characteristics for the first vehicle based on the first identification images, identifying a second set of </p>

Characteristics of the vehicle on the basis of one or more identification images, determining that the second set of characteristics corresponds to the first set of characteristics, determining that the image of the first vehicle is present in the set of images of the destination, on the basis of determining that the second set of characteristics corresponds to the first set of characteristics, Determine that the first vehicle stops at the first destination

<p dir="rtl">5 on the basis of the first destination image and the second destination image; Determining that the first vehicle left the first destination on the basis of the third destination image, indicating that the first vehicle started using the first destination at the first time, indicating that the first vehicle ended using the first destination at the third time.</p>

It includes the various benefits obtained by the present invention disclosed

<p dir="rtl">10 For example, but not limited to: (1) hands-off self-enforcement of parking rules, (2) parking citations, self-implementation of parking rules that are integrated with the pre-existing in-place “in-place” parking payment (3) Infrastructure), the use of fewer sensors, and the accompanying reduction in installation costs, compared to technologies that rely on proximity sensors that</p>

<p dir="rtl">15th Defines the presence of one or very few vehicles - a factor that has proven to be important in the management of parking in large, open areas such as parking lots (4, utilizing COTS (commercial off-the-shelf) technology) and the accompanying reduction of equipment costs for vehicle detection and application of parking rules, (5) the possibility of quickly updating improvements in vehicle detection techniques based on software in the system,</p>

<p dir="rtl">20 Specifically in embodiment where image processing is performed away from the cameras and vehicle detection improvements are achieved without equipment change in the parking management system, (6) the ability to make rapid changes in system-wide performance or in relation to a more narrowly defined subset of parking.</p>

Brief explanation of the drawings

Figure 1: Shows an example of a total system of 100 according to the revealed position.

<p dir="rtl">25 Figures 2A and 2B: Show examples of images taken with the ID camera.</p>

Figures 3A and 3B: Show examples of images taken with the destination camera.

Figure 4: Demonstrates how to use the images captured with the camera with

Overlapping fields of vision to identify the vehicle, follow the vehicle's movement to the destination, and identify the use of the vehicle's intended location.

<p dir="rtl">5 Figure 5: Represents a frame diagram showing the 500 computer system through which</p>

Aspects of the invention may be implemented,

Figures 6a and 6b: show aspects of a graphical user interface (GUI).

interface to set the field-of-view properties of the camcorder. Figure 6a shows a portion of the GUI where an image from a first camera is displayed. Figure shows

<p dir="rtl">10 6b Part of the GUI where an image from a second camcorder is displayed.</p>

Detailed description

Figure 1 shows an example of a total system of 100 according to the revealed subject. Network 110 provides data communication services among the elements shown in Figure 1. There are many networking technologies, including, for example

<p dir="rtl">15th Ethernet, 802.11 wireless architecture, and cellular data networking technologies, whereby a tech-savvy person can reliably and predictably integrate the described elements to exchange data among themselves. In an embodiment, separate networks may be used. For example, the communication between the cameras 120 and 125 and the server may be through a first network, while the communication between the elements is done</p>

<p dir="rtl">20 others via the public Internet. By using an independent first network, a person skilled in technology can realize desired goals in terms of reliability and security.</p>

The identification cam 120 illustrates one of a group of such cameras in the System 100. For ease of discussion, only one identifier 120 is shown in Figure 1. and done

<p dir="rtl">25 Position the camcorder 120 so that it can take pictures of vehicle IDs, for example no </p>

limitation, a vehicle number plate or a sticker attached to a vehicle that provides a vehicle identifier in the form of, but is not limited to, a QR code or a bar code. Images captured with the CCTV Camera 120, for example, Photo 121, are used in conjunction with Images captured by the destination camera 125 are one or more in order to identify separate vehicles, for example

<p dir="rtl">5 Vehicle 130, and recording its use for different destinations. Examples of places intended for wheeled motor vehicles that include designated spaces that are suitable for parking, although they may be subject to various restrictions, include, but are not limited to, parking spaces, designated spaces where they are suitable for parking, Such as but not limited to, bus stops, fire lanes, spaces</p>

<p dir="rtl">10 About fire hydrants, sidewalks, spaces within X feet of intersections, driveways, islands, medians, bicycle lanes, pedestrian crossings. For example, Server System 140 may be set up to determine if a vehicle has stopped at a bus stop, and to request or take action based on that determination, such as a request to tow the vehicle or issue a summons by</p>

<p dir="rtl">15th Mail. And in an embodiment, it is possible to identify other parking violations, for example, a vehicle that is not parked correctly within the parking space designated for it, parking the vehicle more than 1 foot from the edge of the sidewalk, parking the vehicle with the wheels of the left side towards the edge of the sidewalk (parked facing the wrong direction) with the left wheels toward the curb, back-in angle parking, and abandoned vehicles (left in place</p>

<p dir="rtl">20 Defined for a duration of X or more consecutive days (abandoned vehicles). In an embodiment, the ID camera may also include a mobile or handheld camera, which includes, for example, the camera found in smartphones.</p>

The Destination Camera 125 shows one of a group of such cameras in System 100. For ease of discussion, only the identification camera 125 is shown in Figure 1

<p dir="rtl">25 one. The camera is positioned 120 so that it can take pictures of one or more destinations,</p>

For example, but not limited to, parking spaces. Typically, a cam will be installed in place

125 is meant at a height, for example, on a lighting or telephone pole, or on a façade or on the top of a building. By mounting the Destination Cam 125 at a height, the field of view of images, for example, Image 126, captured by the Destination Cam 125, can be included, thus using them so that I do not monitor many places

<p dir="rtl">5 intended. In an embodiment, the destination camera may also include a handheld or handheld camera, which includes, for example, the camera found in a smartphone. In an embodiment, a destination cam may be included in the parking meter body. In an embodiment, a destination camera may be equipped with a space satellite imaging camera, thus potentially obviating the need for space cameras</p>

<p dir="rtl">10 Intended installed throughout the municipality. In an embodiment, a destination camera may be embedded in an air vehicle, including, but not limited to, a blimp or other powered airship, or an unmanned air vehicle, and may operate independently for extended periods of time from folding ring.</p>

Both the identification camera 120 and the destination camera 125 can be configured so that they are connected

<p dir="rtl">15th Directly with network 110 by means of special communication links 127 and 128. In another embodiment, the identification cam 120 can be set up to communicate directly with the destination cam 125 and transmit data to it so that instead of communicating directly with network 110 through communication link 127, it It communicates with the Destination Cam 125 through the communication link 129, and the Destination Cam 125 communicates with the network 110 through the communication link 128 so that</p>

<p dir="rtl">20 The Destination Camera 125 transmits data to and from the ID Camera 120. The communication link 129 can be a wireless networking link. Although Figure 1 shows an example when the communication link is 129 between cameras 120 and 125, this can include data sent to and from a particular camera by transmitting data through multiple cameras. In addition, a wireless mesh network can be installed between</p>

<p dir="rtl">25 A set of cameras, which provides a self-configuring and potentially fault-tolerant wireless communication medium between the two cameras. And by using wireless communication links instead of</p>

Hardwired communications in the device, can reduce the number of hardwired communications links in the system in general, and also reduce the cost and effort associated with the installation and maintenance of these hard links, and these links serve as a useful alternative to the use of cellular data communications links for example, cellular data communications to transfer data to the network 110 Because the cost

<p dir="rtl">5 Cellular data connections are usually much larger than a fixed one. However, a wireless connection is not necessary and some or all of the cameras can be connected via a fixed link.</p>

The 140 server system includes one or more computer systems that provide central data storage services, data retrieval

<p dir="rtl">10 retrieval and data processing. The computer systems embedded in Server System 140 typically include a 142 random access memory and processor 143. Server System 140 includes a 141 database that is used to record information such as the use of intended places such as parking spaces, by vehicles, vehicle account information vehicle account information, identification of the vehicles that are obtained</p>

<p dir="rtl">15th These are provided by ID camera images, vehicle notes obtained by destination camera photos, destination reservation information, billing information, and payment information. Database 141 can be implemented using software programs, such as MySQL, Oracle or DBASE, and database 141 can include multiple instances of databases.</p>

20 Data is carried out in several computer systems.

In one embodiment, the Server 140 system is configured to recognize the vehicle and distinguish the vehicle identification from images captured by the ID cam, such as the ID camcorder 120, and the destination cam, such as the Destination camcorder 125. The server 140 is set up to make decisions on the basis of Distinctive information such as determining the use of the intended places, and when the use of the place is

<p dir="rtl">25 Intended contrary to the restrictions of use of the place of destination. This embodiment in which image processing and decision making is centered on the server system 140 uses Moore's Law which</p>

that the number of transistors in a microprocessor and the corresponding data processing capacity doubles every 18 months and Nielsen's Law, which assumes that bandwidth increases by 50% every year, and important benefits can be achieved from this centralized method, as it is not only possible to raise Level intelligence/feature-rich server applications quickly with a cheap and fast central processing unit (CPU) capability but can also quickly scale applications to include on-site "thin-client" tools. Manufacturing costs are typically reduced by using Commercially Available Components (COTS) in the system. In addition, a highly interconnected system is put in place to take advantage of technical service updates available over the network, and finally because the costs of the microprocessor and bandwidth continue to fall, the expansion of Size 10 or capacity costs less than it is.

In another embodiment, some functions can be distributed to other components of the system, for example, the camcorder 120 can be set up to determine the presence of vehicle identification information, such as license plate numbers, in captured images. In this embodiment, the amount of data communication bandwidth between the ID camera 120 and the server system 140, and the amount of processing performed by the server system 140 is significantly reduced compared to the fact that the ID camera 120 should be a more complex tool to perform image processing functions In order to determine the presence of vehicles in the images, determine the presence of vehicle identification information in the images, and/or extract vehicle identification information from the images. As another example, identification and destination cameras can be programmed to characterize vehicle images, as detailed below in Figure 4, rather than making these determinations using a server system 140. How functions are distributed throughout the system depends entirely on the expected costs of providing the means Distributed functional

necessary and programming processing hardware such as the provision of processing equipment (distributed functionality

ID cameras and/or destination cameras), compared to the expected costs of moving images captured by the cameras to a central location for processing, and the transfer of programmed functions from one computer system to another in order to contain communication bottlenecks eg from a server system 140 to the camcorder 120 and ensuring that appropriate processing resources are provided for various computer systems to perform these functions is a known routine procedure for a person

Technically savvy.

The 150 mobile device includes a programmable computer, an identification camera and the ability to communicate wireless data with the server system 140. In one example, if it is determined that the 130 is using a destination, but no unique identification is given to the 130, 5 can be sent The mobile device 150 will be sent to the destination and a 151 image of the 130 vehicle can be obtained from which a unique identification of the 130 vehicle can be obtained. In addition to taking a picture of the vehicle's number plate, as the R120 does, the Mobile Device 150 can also be configured to take a picture of the Vehicle Identification Number identifier tag, which may be useful for vehicles without number plates. This helps to overcome occasional cases,

<p dir="rtl">10 Such as blocking the road on a vehicle 130 by another vehicle when it passes through the field of view of the camcorder 120, the camcorder of the 120 is unable to effectively capture images to uniquely identify the vehicle 130. Multiple mobile devices can be included in the system in order to ensure that images are captured in time across all destination sites managed by the server system 140. In one embodiment, the 150 mobile device can be configured to provide features useful for enhancing</p>

<p dir="rtl">15th stand up. For example, the Mobile Device 150 can be set up to print paper instructions for parking violations specified by the Server System 140.</p>

A 160 onsite payment system is a multi-device that provides a direct physical interface, usually located near one or more destinations, for the end user to pay or agree to pay for the use of a destination.

<p dir="rtl">20 Examples of payment system 160 include but are not limited to parking meter</p>

A meter designated for a single destination place, a payment station combined with several street parking spaces, and a payment station for the destinations provided in the parking lot or garage. In one embodiment, the on-site propulsion system may include 160 destination cameras that capture images from one or more destinations.

<p dir="rtl">25 The end user system 170 is a programmable computer program that interacts</p>

By the end user such as the driver of the vehicle 130 with the server system 140. Examples of these include

Systems such as but not limited to a desktop computer system with a web browser application, a smartphone with a web browser application or a dedicated parking application, an in-vehicle system located in the vehicle 130 and the end user system 170 can be used for example In order to create an account

<p dir="rtl">5 The end user in order to repeat interactions with the server system 140, and to reserve the right to use the destinations, request the designation of an available destination place and provide payment information for the use of the destination.</p>

In one embodiment, the end user system 170 is set up to request and get information from the server system 140 that describes the available destinations for a given region, and in one

<p dir="rtl">10 For example, the End User System 170 can be further configured to obtain and/or request certain criteria for acceptable destinations such as those in the parking garage rather than on the street (such as a parking lot). In addition to location information, other information can be obtained Such as the cost of using a specific destination place by the end user system 170. The end user system 170 can also be further configured to request and obtain information</p>

<p dir="rtl">15th About currently available destinations and/or destinations that are available at a specific point in time or time span in the future. The end user system can also be further configured to provide a graphical user interface to the end user showing specific places eg on a map of one or more available destination places obtained from the server system 140. In one embodiment, the end user system can be setup 170 where places are available</p>

<p dir="rtl">20 Multiple denotations at a parking facility (such as a parking garage or parking lot) in order to indicate wide availability and possibly indicate the number of destinations available for a destination place at the parking facility rather than identifying each destination independently. The user system can be configured The end user 170 is to receive a signal of a chosen destination from the end user.The end user system 170 can be further configured to provide directives such as</p>

<p dir="rtl">25 turn-by-turn directions to the chosen destination. The end user system 170 can also be configured further to instruct the server system 140 to save the right</p>

Use the available destination.

The 180 manual review system is a programmed computer system by which a human operator 181 provides assistance to a server system 140 to identify vehicles, such as a vehicle 130. For example, a server system 140 can determine that the error has occurred when

<p dir="rtl">5 Performs automated automatic identification of the unique identifier for the vehicle from 130 images, such as image 121 that was made</p>

Captured by Cam ID 120. In response to this error, the server system 140 can request assistance from the human operator 181 to identify the unique identifier such as the vehicle number plate 130. The manual browsing system 180 provides a user interface by which the human operator 181 can view image 121 and possibly Other photos taken with the IR 120 or other cameras. actual

<p dir="rtl">10 For example, a human operator can return 181 retrieval<a href="http://www.proz.com/kudoz/english_to_arabic/cinema_film_tv_drama/1188413-video_footage.html"> Video clips</a> video footage manually and submits and freezes video images for manual vehicle number plate identification and state/province information. With this interface, the human operator 181 can provide the identification of vehicle 130 or indicate that the human operator 181 is unable to determine the identification of vehicle 130, causing the mobile device 150 to be sent to a destination in order to obtain</p>

<p dir="rtl">15th Positive identification of vehicle 130. More than one manual browsing system 180 can be made available for use by the server system 140 depending on the volume of information processed by the server system 140. In addition, the human operator 181 can be a member of the Live Operator team , described in detail below.</p>

In one embodiment, one or more identification and destination cameras capture a compass

<p dir="rtl">20 At a higher frame rate and/or resolution than images sent from the cameras to the server system 140. Although not all image data captured by these cameras is sent to the server system 140, in order to maintain the bandwidth of the connection With potentially costly network (e.g. cellular data network) and limited image processing resources available in a 410 server system, these cameras can cache a small amount of</p>

<p dir="rtl">25 The data of the complete images it has taken, for example in a circular buffer. In addition, these cameras are configured to respond to requests for additional image data, including</p>

This is for example portions of high-resolution images that can be useful for vehicle identification and tracking, or the manual review system can request 180 different images in order to correct errors generated by the server system 140.

The 190 parking operation system is a computer system

<p dir="rtl">5 A programmer by which a stand-alone operator can interact with the control server system 140. It is expected that the server system 140 will operate independently with little input required by the parking operator most of the time. However there are sometimes instances where parking facility operators actively participate in the operation. For example, the parking operating system can provide 190 live signals regarding the number and what destination spaces are used and/or available, and as another example, the parking operating system can provide</p>

<p dir="rtl">10 190 live indications regarding the destinations where the vehicles violate the usage restrictions, allowing</p>

The operators of the parking facility may take measures against these violations as appropriate.

Figure 2a shows an example of image 121 captured by cam 120, where cam cam 120 is placed in order to effectively obtain identification information for vehicles passing through cam cam 120. In one embodiment, camcorder 120 operates on

<p dir="rtl">15th Videos containing images send identifying information such as vehicle number plate information by flowing to the 140 server system. Since typical streetlights have a height of about 18</p>

ft., they provide an excellent mounting location for identification cameras that benefit from a clear line of sight away from trees and other obstacles, including close-in vehicles. Since the street light is pre-powered, a camcorder can also be installed so that it pulls

<p dir="rtl">20 capacity of street light. In addition, because most city regulations require at least one streetlight per housing unit on each street location, a streetlight-mounted identification camera can provide adequate coverage for all vehicles crossing the street.</p>

The ID photos captured by the ID camcorder 120 are used for two main purposes:

<p dir="rtl">(1) Obtaining a unique identification of the vehicle, such as by reading an identifier from the license plate of the vehicle that</p>

<p dir="rtl">25 fitted to the front or rear of a vehicle, and (ii) specifying different characteristics of the vehicle, so that it can be determined that the vehicle image obtained by another camera is compatible with the vehicle </p>

Identification, as will be described below for Figure 4. In the typical identification image shown in Figure 2a, a view of the vehicle and its license to be processed by the 140 server system is available. Several identification images can be used to define vehicle characteristics such as speed and direction of travel.

In the field of license plate readers, various technologies are known

<p dir="rtl">5 In the field it is used to capture images reliably and effectively to read vehicle identifiers under a variety of vehicle and lighting conditions, a non-specific example described in US Patent No. 7016518 which is incorporated herein for full reference. In one embodiment, the problems arising from a lack of natural light at night can be avoided where restrictions on the use of the intended locations are effective only during daylight hours.</p>

<p dir="rtl">10 In one embodiment, machine vision techniques can be performed to obtain vehicle identifiers</p>

with the ID cam 120. In this embodiment, the amount of data sent from the ID camcorder 120 to the server system 140 can be greatly reduced where the vehicle ID can be sent instead of the ID images. However, one or more identification images may be sent to Server System 140 for storage and/or vehicle characterization by Server System 140 (although in one

<p dir="rtl">15th embodiments, this can be done with the camcorder 120).</p>

In one embodiment, the server system 140 could realize that a portion of the vehicle identifier could be obtained possibly as a result of certain conditions such as vehicle angles or a closely following vehicle. In this case, the server system can additionally rely on a second ID image captured by a second ID cam to obtain the remainder of the ID.

20 Figure 2b shows an example of a photo 121 taken with a 120 . IR camera

Where the IR 120 is placed in order to effectively obtain identification information for the vehicles entering and exiting the urban intersection along the road that runs along the axis of view of the camcorder 120. In this identification image, the views of the three vehicles are effective in processing by the server system 140, so that the unique identifiers of the three compounds can be obtained

<p dir="rtl">25 from the single image.</p>

In one embodiment, the camcorder 120 may have pan and/or tilt capabilities

tilt and/or zoom Can be used for the 140 server system to get a more detailed view of the vehicle, or it can be used by parking facility operators via a user interface on the Parking System 190 to monitor specific areas of interest that can be seen with the ID camera 120. In such an embodiment, the server system 140 can be configured to perform a 5 coordinate conversion in order to accurately determine the vehicle's characteristics while changing the field of view of the ID camcorder 120.

In one embodiment, when a vehicle appears in the field of view of the ID camera 120, the server system 140 performs one or more of the following six tasks: In the first task, the server system 140 detects the presence of one or more vehicles on the basis of one or more images that have been Captured with a Camcorder R120. In one embodiment, the Server 140 system can be configured to detect 10 vehicles on the basis of the color difference between the vehicle and the background and determine that the overall shape of the potential vehicle is greater than the minimum specific size of the vehicle is adjusted according to the applicable zoom level. Specifically, this algorithm can compare the colors of all pixels in an image to each other, whereby the pixels are divided into rows and columns (for example, a fixed location can represent 21,34 absolute location pixels located on rows 15 21 and column 34). Since the image may include objects other than the vehicle such as, but not limited to, a fire hydrant, pedestrian, cars, grass or road marking/road paint, the algorithm can be set up to detect groups of pixels of similar colors (a group of colors that are considered similar in the assortment of the system, so that the similar colors have a color gamut difference of a maximum of 2 20, can be specified, referring to the hues shown in the color chart).

The locations of these pixels mathematically to determine if they form a shape that has a size greater than the minimum size of the vehicle (eg a relative size of 10 x 30 could represent a shape that measures 10 rows x 30 columns). The camera profile is 120 parallelograms instead of rectangular due to the 25 viewing angles, so the selection can take this factor into account.

Another refinement can be done to add holes, holes or imperfections in

The exposed shape is caused by the reflection of sunlight, the windshield area or the roof rack. For example, the algorithm can select a number of shapes that have a minimum size up to a certain distance (or pixels) away from each other, which may correspond to parts of the vehicle such as the hood, hood and trunk

<p dir="rtl">5 trunk that usually have the same color.</p>

Once the vehicle is detected, the entries are logged into the part of the database 141 corresponding to the camcorder 120 with information including for example date, time, vehicle color, vehicle size, and zoom level. This information may be used in conjunction with other vehicle-specific information disclosed to identify the vehicle. Alternatively, this information may be recorded in the form of

<p dir="rtl">10 Temporary in a volatile memory such as random access memory</p>

.Memory (RAM)

In the second task, the Server 140 system detects the presence of vehicle license plates and/or additional identifications, such as but not limited to decals on vehicles in the images taken by the camcorder 120. Once the vehicle number plate and/or identifications are detected

<p dir="rtl">15th In addition, the entries are logged into the part of the database 141 corresponding to the camcorder 120 with information including, for example, details of date, time, plate number, state/province, label (eg type, ID and expiration date), pixel locations and zoom level. This information may be used in conjunction with other vehicle-specific information disclosed to identify it, such as images taken by the destination camera.</p>

20 In the third task, Server 140 identifies moving vehicles against

Unmoving vehicles based on the multiple images taken by the camcorder ID 120.

In the fourth task, the server system identifies 140 license plates and/or additional identifications for moving vehicles against vehicle number plates and/or additional identifications for non-moving vehicles based on the multiple images captured by the 120 ID cam. In one example, setting up

<p dir="rtl">25 Server System 140 for: (1) Finding suitable matches in previous images (eg by browsing data stored in the 141 database or memory) based on vehicle number plates </p>

and/or additional identifying information obtained, for example, by Optical Character Recognition (OCR) of the current image, and (2) a comparison of pixel locations, after matches have been found, between the current image and previous images, taking into account any change at the zoom level. On the basis of this processing, one or more of the following 5 scenarios can be detected: (a) If the locations of the pixels do not change or do not change at a level below a predetermined threshold level, all vehicle number plates and/or additional identifications are deemed to be indicative In this scenario, a simple date and time update is performed for the entries in the database 141 or the memory allocated to the vehicles. (B) If the pixels are

Associated with one or more vehicle number plates and/or additional tariffs at new locations, 10 vehicle number plates and/or additional tariffs deemed to indicate that the vehicle has moved. The server system can calculate 140 the speed and direction of movement of these vehicles and update the 141 database or memory based on this information in addition to updating the locations. (c) If one or more of the vehicle number plates and/or additional identifications disappear from the current image, the server system 140 can be set up to delete the data recorded in the database 141 or the memory designated 15 for these vehicles. (d) If one or more license plates appear Vehicle numbers and/or additional tariffs In the current picture, the data associated with new vehicle number plates and/or additional tariffs can be recorded in the 141 database or memory. In one embodiment, the valet 140 can determine that one of the new vehicles is the same as the vehicle identified as recently vanished and the vehicle may be deemed to be temporarily blinded. (e) If all the additional vehicle number plates and/or 20 tariffs disappear from the current image, the data on the additional vehicle number plates and/or tariffs can be deleted from the 141 database or memory from the previous period. However, some data may be retained for Vehicles approaching and moving away from the CamryR follow the identification as described above.

In the fifth task, Server 140 system pairs the vehicle number plates and/or additional identifications with the vehicles that were detected in the first task. Example fixed pixel location, direction of movement and speed) with specific attributes of potential vehicles

It attempts to associate each vehicle number plate and/or additional identification with the vehicle.

In the first to fifth missions, the Server 140 system applies machine vision techniques to identify additional vehicle identification in order to ensure that the specified vehicle is allowed to park in a specific parking spot or that the vehicle's license registration is valid and valid. Other types of unique identification include

<p dir="rtl">5 Example but not limited to decal sticker or mirror-hanger for disabled vehicles parking</p>

resident-only parking decal handicap parking sticker

Registration is usually affixed to vehicle number plates.

In the first to fifth task, the OCR method can be performed

(OCR) on the image(s) of the vehicle number plate(s) in order to obtain the number plate number of 10 vehicles that include numbers and letters with the respective state/province. It is worth noting that the vehicle number plates observed can be the front or back plate (usually done Provide an identification camera that indicates both directions of the street (to and fro). The information obtained on the vehicle number plate is used to obtain a unique identifier for the vehicle that is used to record information about the vehicle in the database 141. In certain configurations, the first task can be performed locally 15 on the identification camera where data on the vehicle number plate and state/province are sent to

Server system 140 in a concise data format. This is especially true when the backbone network between the camcorder 120 and the server system 140 does not provide sufficient bandwidth (eg 1 MB/sec is considered a threshold value for image streaming) or is considered too expensive (eg 1 MB costs more than $10 ((. There can be several compounds in .

<p dir="rtl">20 same time in ID image 121. In one embodiment, Server 140 can track no more than 10 groups of information related to vehicle number plates simultaneously from a single ID cam at any given time.</p>

In the sixth mission, the vehicle is "tracked" as it moves in the field of view of the IR 120 identification cam.

The image captured by the identification camera 120 and the adjacent destination camera 25 125 overlaps, so that the vehicle is within the field of view of the two cameras for a minimum of two seconds and at a speed of

15th miles per hour (approximately 44 feet). The locations of nearby or nearby cameras are generally determined.

to ensure that interference occurs. Because the two cameras have uniquely different viewing angles, acquiring overlapping images for any specific vehicle from these two cameras is a positive identification of the vehicle (by the vehicle plate number obtained from the identification image 121) with the exact intended place that the vehicle occupies (in the case of parking lots). (.

<p dir="rtl">5 In one embodiment, the initial motion detection can be used to reduce the number of identification images</p>

captured and/or analyzed, as there may be significant periods of time during which vehicles do not pass within the camcorder 120’s field of view.

The OCR is one useful metric in evaluating the effectiveness of identification. For example, although it is impressive that 100 license plates are photographed/recorded, the system

<p dir="rtl">10 Server 140 fails to OCR for only one of the boards (in other words, the server system 140 is not able to generate a board number that includes numbers and numbers), and if this combination fails (including factors such as server system programming, cam mode, and the quality of the camcorder image) in recording/taking pictures of 100 other license plates (in other words, no images of additional plates were identified by the server system 140) the overall effectiveness is only 49.5%.</p>

<p dir="rtl">15th Furthermore, license plate recognition systems are usually configured to read license plates from a specific state/province with license plates from several surrounding states/provinces. Vehicle number plates from different states/territories have different colors and a contrast between the letters and the background. In one embodiment, the image capture rate is at least 95% and the OCR accuracy is not less than 95% resulting in a minimum overall effectiveness of at least 90,25%.</p>

<p dir="rtl">20 Figure 3A shows an example of a photo 126 captured by a destination camera 125,</p>

Where the destination camera 125 is placed on the façade or roof of a building and is directed downward on a part of the city street so that the top view of the vehicles is visible in Fig. 126. Combined with the field of view of Fig. 126 shown in Figure 3a, nine destination spots are designated 310a. to 310i (eg hourly rate for use) for the server system

<p dir="rtl">25 140, and these nine places except for the intended place 310d appear to be in use by</p>

Vehicles 310a to 310i. An inappropriate destination location (such as an entrance . 340) is also specified

(commercial) in the valet system 140. If it is found that the vehicle used the intended place by remaining immobile for a period of time, the vehicle is considered a violation and therefore the valet system 140 begins with measures such as, but not limited to, estimating a fine for the violation or alerting the person operating the parking facility about Violation In some embodiments, a vehicle is considered immobile in any unmarked area

<p dir="rtl">5 It is intended as a violation, and 126 vehicles 330 in the lane of cars that move from right to left in the picture also appear in the picture. The singular image alone does not indicate whether vehicle 330 is movable or immobile, for example, in the previous image, vehicle 330 could have used the 310d destination, and this image could make the server system 140 determine that vehicle 330 has just finished use Destination 310 d.</p>

<p dir="rtl">10 Destination images captured by the Camry use Destination 125</p>

It has two main purposes: (1) Determining the time of use and non-use of the intended places by vehicles, (2) Defining different characteristics of the vehicles, so that the vehicles can be tracked as they pass from one camera to another, by determining whether the characteristics identified are from the captured images. By adjacent cams they correspond to each other, as described below with respect to Figure 4.

<p dir="rtl">15th Figure 3b shows an example of a photo 126 captured by the destination camera</p>

125 This cam is positioned so that the side view of the vehicles is seen in Fig. 126. This view can be obtained where the Destination Cam 125 is located in a parking system at position 160, such as a parking meter or on a building or structure corresponding to one or more relevant destinations. In combination with the field of view corresponding to image 126 shown in Figure 3b, 4 locations are identified

20 Suitable destination 350a to 350d (eg hourly fare parking) for server system 140. These places except for destination 350c appear to be in use by vehicles 360a to 360d.

In another example, not shown in the drawings, the Destination Camera 125 can be arranged so that the image 126 provides a perspective drawing of one or more designated locations, and although Figures 3A and 3B show the specifications of the rectangular areas 310 and 350 of the Destination areas, it can be

<p dir="rtl">25 The use of other shapes such as polygons (which are useful in the place where the destination camera 125 is placed so that the destination is seen from a perspective).</p>

The graphical user interface (GUI) described below in conjunction with Figures 6A and 6B provides user interface elements that can be used to customize, superimpose on image feeds, the location and span of destinations within the camera's field of view. Graphical User Tools to assign identifiers to destinations and possibly 5 characteristics different from the intended destinations, such as, but not limited to, parking or “no-parking” and time and/or date based usage restrictions.

In one embodiment, when the vehicle appears in the field of view of the intended destination camcorder 125 the server system 140 performs two tasks: For the first task, the server system 140 is configured so that: (1) Recognizes all vehicles in the field of view of the destination camera 125, (2) distinguishes 10 moving and non-moving vehicles, (3) determines the stopping time of the moving vehicle in the field of view corresponding to the destination, (4) determines the destination which is occupied by a non-moving vehicle, (5) continuously tracks the period of occupancy of the destination by the vehicle, (6) determines the time of evacuation of a non-moving vehicle to the field of view area corresponding to a destination, (7) determines when the use of the destination is considered to be in violation of the restrictions specified for the place of destination, (8) identifies the street or The housing unit in which the vehicle is parked improperly 15, (9) tracks the time period each vehicle is parked incorrectly and (10) tracks the time the illegally parked vehicle has moved. It includes different types of destinations, each with respective restrictions, wheeled motor vehicles, to name a few: No parking areas (at any time anytime, fire lane, fire hydrant), no parking 20 during specified times and/or on specified days (for example, during rush hour or during street cleaning ), no parking/no parking/stops, parking for a specified period (eg, for two hours), parking limited to certain categories of vehicles (taxi stand, bus stop, area download loading zone/ for commercial vehicles only, Parking spaces permitted for certain category 25 permitted parking (handicapped or residents-only parking), pick-up and drop-off locations only, and street intersections

(For traffic violations as a result of “block the box” in order to prevent traffic congestion - anti gridlock where the vehicle remains inside the intersection during the red light of the direction of moving vehicles). The 140 Server system can be set up to detect other parking violations, such as, but not limited to, parking within a specified distance of an intersection, parking 5 vehicles in a bike lane, crosswalk or other areas. designated for walking, located within the space of a single destination, at a distance greater than the specified distance from the curb, parking at or in front of the driveway, using the island or center strip, vehicles parked in the wrong direction, Abandoned vehicle (immobile for more than several days), oversize 10 vehicles, the incorrect category of vehicle (eg camper, trailer, or boat for more than the specified hours in a certain number of days). Destination may also be subject to reservation, whereby the end user reserves exclusive use of the destination for a specified period of time. The 140 server system can be set up to detect double parked vehicles, while distinct vehicles stop in 15 lanes of traffic as a result of driving conditions caused by incorrectly lined vehicles. can be prepared

Server 140 system to identify, and in some cases distinguish, small wheeled vehicles such as motorcycles, scooters, and “smart cars”

. cars

In the second task, the vehicle is "tracked" as it moves through the field of view of the 20 125 destination camera. There is overlap between the image captured by the intended camera 125

The position camera or adjacent intended location where the vehicle is within the field of view of both cameras for less than two seconds at a speed of 15 mph (approximately 44 feet). In general, the locations of the adjacent cameras are mapped to ensure that interference occurs. Since the two cameras have uniquely different viewing angles, the 25 overlapping images obtained for any vehicle involved from both cameras are processed as positive identification with the vehicle (via the license plate number obtained from the identification image).

121 identification image) along with the specified parking space occupied by the vehicle (in the case of vehicle parks).

In some configurations, a place camera can be placed to monitor the movement of the vehicle in a specific space, where the space does not include any intended places of interest for the server system 5 140. This space can be located, for example, between two spaces, each containing places

The target is of interest. In this example, images from the destination camera may overlap with images from the corresponding cameras, and you can use them to perform a "handoff transfer" as shown in Figure 4, described below.

In an embodiment, the destination camera may have pan, tilt, and/or 10 zoom capability, which may be used for a Server 140 system to obtain a more detailed view of the destination, or may be used by the operator who has not attached parking via an interface The user on the Parking System 190 has not monitored a specific area of ​​interest that can be seen by the Destination Cam R125. In this embodiment, the server system 140 may be set up to perform a coordinate transformation with the goal of monitoring the usage of destination locations and accurately determining the characteristics of the vehicle 15 while varying the field of view of the destination camera 125.

In an embodiment, preliminary motion detection may be used to reduce the number of photos of the destination that were captured and/or analyzed, as there may be long periods of time during which no vehicles pass through the field of view of the destination camera 125.

In an embodiment, stamps specifying the exact date and time are included on all 20 images captured by cam and destination cameras to facilitate subsequent manual review of stored images, if needed.

In an embodiment, a "grace period" is given to vehicles after they are determined to have become immobile within the intended location (as opposed to an improper destination, eg a no-parking zone). When the driver leaves the vehicle to pay the parking fare, despite 25 From determining that the vehicle started using the destination without paying the fare, a period is required

Allow to postpone the determination that the vehicle is in a condition in violation of the requirements for paid use since some time is needed to complete the payment process.

Figure 4 shows how to use the images captured by the camera with overlapping fields of vision to identify the vehicle, track the movement of the vehicle to the destination, and define the use of the place.

<p dir="rtl">5 intended by the vehicle. Figure 4 is not displayed as standard; For example, an area of ​​overlap 430a which may extend nominally by 44 feet or more in the vertical direction, but shows roughly the same size as vehicle 410. To begin with, the ID cam (not shown) at time t1 captures an ID image 420 that covers the field of view. The vision shown in Figure 4. In the identification image 420, the vehicle 410 is included at the specified location 410. Depending on the image 420a (and perhaps images</p>

<p dir="rtl">10 Captured by t1 camcorder, the server system identifies 140 unique identifiers to the 410th vehicle. For example, by performing OCR on one or more exposed images of the vehicle number plate to obtain a license plate number. The license by which the unique identifier is obtained.The server system records 140 in the database 141, in connection with the unique identifier that the vehicle 410 was viewed by</p>

<p dir="rtl">15th Cam R-definition at time t1. In an alternative embodiment, the server system 140 instead stores in</p>

volatile memory that vehicle 410 was viewed by the identification cam at time t1, and this information is recorded in database 141 after determining that vehicle 410 used the intended location before vehicle 410 was recognized by the server system 140 through identification images that Obtained from the ID cam except the ID cam which takes a picture

20 Definition 420.

At time t2, the identification camera takes another picture of identification 420a ´ of vehicle 410 at the designated place 410a. At about time t2, a first destination camera takes an image of the destination 420b of a vehicle 410 within an overlapping area of ​​430a (eg, in the vicinity of 410a). In some embodiments, the identification camera and the first destination camera are

<p dir="rtl">25 It was synchronized, so that essentially both images 420a´ and 420b are captured at the same time t2.</p>

The overlapping area is 430a corresponding to the field of view of the identification image 420a´ that overlaps with .

Field of view of the destination image 420b. In both pictures 420a´ and 420b, images are taken of vehicle 410 while vehicle 410 is within the overlapping area of ​​430a.

Depending on one or more ID images captured by the ID cam (eg ID 420a´), the server system identifies 140 sets of Ca characteristics for vehicle 410. As mentioned above, static characteristics of vehicle 410 that are recorded in the database may be included

<p dir="rtl">141 in the Ca. Examples of characteristics include, but are not limited to: the travel speed of the vehicle 410, the travel direction of the vehicle 410, the location of the vehicle in the image of the vehicle (including, for example, the lane for the movement of the vehicle 410 in which it is traveling), the color of the vehicle 410, and the size or Vehicle dimensions 410. Certain characteristics may be considered static characteristics of vehicle 10 410 and are not expected to change with time (for example, vehicle color and size).</p>

Other characteristics are the dynamic characteristics of vehicle 410, and may change substantially over time (for example, vehicle speed or vehicle trajectory). In an embodiment, the static characteristics may be recorded in database 141 as constant characteristics of vehicle 410 in connection with the unique identifier specified depending on On ID 420a. Fixed properties may be specified

<p dir="rtl">15th These are based on vehicle information supplied by the end user (eg make, make, model, year, and color), or may be based on images of the vehicle taken during a previous encounter between the vehicle 410 and the server system 140. Static properties may be used in conjunction with specifying an identifier Unique to Component 410, by ensuring that the static characteristics selected from the identification images correspond to the static properties.The static properties may also be included in Ca or other combinations of 20 properties where the identification of the vehicle is emphasized. Depending on the destination image 420b, and possibly other destination images captured by the first destination camera, the server system identifies 140 sets of Ca' characteristics for the 410. As a result of factors such as the different viewing angles of the vehicle 410 for the identification camera and the first destination camera, an obstruction Compounds, Ca and Ca' may consist of different combinations of compound properties, but they are usually overlapping. actual</p>

<p dir="rtl">25 For example, the vehicle width may be determined for Ca but not for Ca ' as a result of partial obstruction of Compound 410 from the point of view of the first camera to the destination about time t2. In addition, may</p>

Image distortion, which is usually more noticeable at borders or pictures, or other factors, causes certain characteristics of the vehicle, eg speed or size, which are only approximations. Normalization can be performed for features such as size, speed, and direction of travel to compensate for camera positions and zoom level.

<p dir="rtl">5 Hence the 140 server system determines whether 'Ca corresponds to Ca by comparing the values ​​of</p>

Characteristics of the compound included in both Ca and 'Ca. Since the characteristics of the vehicle specified by the server system 140 may represent approximate values ​​of the actual characteristics of the vehicle 410, the approximate equivalence between the values, where this equivalence is shown for all the comparative characteristics, is sufficient to support the determination that the 'Ca corresponds to the Ca. When it is determined that 'Ca corresponds to Ca, then the server system 140

<p dir="rtl">10 Recorded in the database 141, linked with the unique identifier, that vehicle 410 was seen by the first camera of the destination at time t2. In an alternative embodiment, the server system 140 is instead stored in a vanishing memory where that vehicle 410 was viewed by the first camera of the destination at time t2, and this information is recorded in database 141 after determining that the vehicle 410 has made use of the destination Before the vehicle is recognized 410</p>

<p dir="rtl">15th By the server system 140 through the identification images obtained from the identification cam instead of the identification cam that captured the identification image 420. This avoids writing information about the location of the vehicle in the database 141 that is not required to prove that it has been used Destination specified by vehicle 410.</p>

At time t3, the first camera of the destination takes another picture of identification 420b´

<p dir="rtl">20 By vehicle 410 at the designated place 410b. At approximately time t3, a second destination camera captures an image of the destination 420c of vehicle 410 within an overlapping area of ​​430b (for example, in the vicinity of 410b). In some embodiments, the identification camera and the second destination camera are synchronized, such that Basically, images 420b´ and 420c are captured at the same time t3. The overlapping area of ​​430b corresponds to the field of view of the identification image.</p>

<p dir="rtl">25 420b ´ which interferes with the field of view of the image of the destination, 420c. It is done in both pictures</p>

420b' and 420c, take pictures of vehicles 410 and 440 while vehicles 410 and 440 are within the overlapping area of ​​430b.

Depending on one or more ID images captured by the first camera of the destination (eg ID 420b´), the server system assigns 140 sets of Cb 5 characteristics to the 410. As mentioned above, the fixed characteristics of the 410 registered in the Database 141 is in Cb. Based on the ID image 420G, and possibly other images of the destination location captured by the second camera of the destination, the server system identifies 140 sets of 'Cb' characteristics for the vehicle 410. In addition, as a result of including the inclusion of vehicle 440 in the image of the destination 420c, a set of Cx10 properties of vehicle 440 is determined. Discrepancies in the motor vehicle properties between 'Cb' and Cx may result from vehicle 440 traveling in the opposite direction in a different travel lane. . Hence the 140 server system determines whether Cx corresponds to Cb, which should not happen. Hence the 140 server system determines whether 'Cb' corresponds to Cb. When it is determined that 'Cb' corresponds to Cb, then the server system 140 records in the database 141, associated with the unique identifier, that vehicle 410 has been seen

<p dir="rtl">15th By the second camera to the destination at time t3. In an alternative embodiment, the 140 server system instead stores in vanishing memory that vehicle 410 was seen by the destination's second camera at time t3, and this information is recorded in database 141 after determining that vehicle 410 made use of the destination The vehicle 410 is prior to identification by the server system 140 through identification images obtained from the ID camera instead of the ID camera R20 which captures the ID photo 420.</p>

At time t4, the second camera of the destination will take another photo to identify the 410 ´ vehicle at the designated location 410 ´. At approximately t4, a third camera of destination captures an image of the destination 420d of vehicle 410 within an overlapping area of ​​430ac (eg, in the vicinity of 410g). In some embodiments, the second camera of 25 times, so that basically both 420º and 420º images are taken at the same time t4. The overlapping area is 430 g corresponding to a field of .

Vision for the identification image 420 d ´ which overlaps with the field of view of the image of the destination 420 d. In both pictures 420° and 420°, pictures of vehicle 410 are taken, while vehicle 410 is within the overlapping area of ​​430 s.

Depending on one or more identification images taken by the second camera of the location

<p dir="rtl">5 Intended (eg ID image 420C´), the server system defines 140 sets of Cc characteristics for vehicle 410. As noted above, the fixed characteristics of vehicle 410 registered in database 141 may be included in Cc. Depending on ID image 420D, and possibly other Destination images captured by the third camera of destination, the valet system 140 identifies a set of characteristics 'Cc' for the vehicle 410. The valet system 140 then determines whether 'Cc 10' corresponds to a cc. When it is determined that 'Cc' corresponds to Cc, then the server system 140 records in the database 141, associated with the unique identifier, that vehicle 410 has been viewed by</p>

The third cam is to the destination at time t4. In an alternative embodiment, the server system 140 instead of

It is in storage in a vanishing memory that this vehicle 410 was seen by the third camera

to the destination at time t4, and this information is recorded in database 141 after determining that

<p dir="rtl">15th Vehicle 410 made use of the destination location before Vehicle 410 was recognized by the server system 140 through identification images obtained from the ID cam instead of the ID cam taking ID 420. In an embodiment, a second ID camera may be responsible for capturing the 420d image, but is unable to obtain an image of the vehicle number plate 410, in which case the characteristics of the vehicle viewed via the second ID camera are used to prove 20 that the vehicle seen in Overlapping area 430 around area 410c is vehicle 410. This indicates that it does not matter whether the destination cam or identification cam is used to track vehicle 410 as it moves away from the primary identification cam. When used in conjunction with said tracking, these cameras may be broadly referred to as a “tracking camera.”</p>

.tracking cameras

<p dir="rtl">25 At time t5, the third camera of the destination takes another image to identify the vehicle at 420 m</p>

410 At the designated place 410 d. Approximately at t5, a camcorder R4 picks up its destination

An image of the destination 420H of a vehicle 410 within a 430d overlapping area (for example, in the vicinity of 410d). In some embodiments, the third camera of the destination and the four cameras of the destination are synchronized, so that essentially both images are captured 420 d' and 420 AH at the same time t5 The overlapping area is 430 d corresponding to the field of view 5 of the identification image 420 d' which overlaps with the field of view of the image of the destination image 420 AH. In both pictures 420 d and 420 AH, pictures of vehicle 410 are taken, while vehicle 410 is within the overlapping area of ​​430 d.

Depending on one or more ID images captured by the third camera of the destination (eg ID 420d´), the server system defines 140 sets of Cd 10 characteristics for vehicle 410. As mentioned above, fixed characteristics of vehicle 410 that are registered in the database may be included 141 at Cd. Depending on the identification image 420H, and possibly other images of the destination location captured by the four cams of the destination, the server system identifies 140 sets of characteristics 'Cd' for the vehicle 410. Hence the 140 server system determines whether 'Cd' corresponds to Cd. When it is determined that 'Cd' corresponds to Cd, then the server system 140 records in database 15 the 141 data, connected with the unique identifier, that vehicle 410 was viewed by the four cameras of the destination at time t5. In an alternate embodiment, the 140 server system instead stores in vanishing memory that vehicle 410 was viewed by the four-camera camcorder of its destination at time t5, and this information is recorded in database 141 after determining that vehicle 410 made use of The destination before the vehicle 410 is recognized by the system

<p dir="rtl">20 Server 140 through meta images obtained from CAM R ID instead of CAM R</p>

The profile that takes the profile picture 420.

In combination with the field of view of image 420e shown in Figure 4, four suitable destination locations 450a to 450d (eg hourly car parking spaces) are assigned to the server system 140. At time t6, an image of the destination 420 ´ is captured by the camera 25 Four for the destination, at the time when vehicle 410 is in place 410. Depending on the image of the destination 420 AH, the server system 140 determines that vehicle 410 is within the area

The rectangular region marked for the destination 450b. At the time t7, a picture of the destination 420 AH is taken by the four cams of the destination, while the vehicle 410 remains at the place 410 AH. Depending on the image of the destination 420 AH, the server system 140 determines that the vehicle 410 is located within the rectangular area specified for the destination 450b, and accordingly, 5 determines that the vehicle 410 has started using the destination 450b starting from time t6, and records

This information is in the database 141. At time t8, a photo of the destination 420´´´ is taken by the four cams of the destination, while the vehicle 410 leaves the destination 450b. Depending on the image of the destination 420´´´, the server system 140 determines that vehicle 410 is no longer located within the specified rectangular area of ​​destination 10 450b, and accordingly, it is determined that vehicle 410 has finished using the destination 450b.

at time t8. Depending on information about restrictions on the use of destination 450b during the time period from t6 to t8, such as, for example, an hourly rate of use for the use of the destination 450b, the 140 server system can start taking actions such as billing the end user account For use of the place of destination 450b, or, for example, imposing a fine 15 for improper use of the place of destination 450b.

The Server 140 system is set up to properly identify a vehicle that is taking advantage of the destination location. The Server 140 system initially determines that the vehicle is taking advantage of the destination, and is then able to later capture the identification of the vehicle through the identification camera. This situation can occur, for example, when the vehicle's visibility is obstructed by the camcorder in transit, or when the vehicle is restarted.

<p dir="rtl">20 Server 140 system that leads to a vehicle identification that has not been performed previously. As an example, where at time t0, prior to time t1, the four cams of the destination initially determine that vehicle 440 has used the destination 450c, but does not contain an identification of vehicle 440, a temporary unique identifier may be assigned to vehicle 440, and enter The information recorded in database 141 is in connection with the temporary identifier. Vehicle-specific combinations of vehicle characteristics may be specified</p>

<p dir="rtl">25 440 while benefiting from the intended area 450 c, as well as when passing through the overlapping space</p>

430d, 430c, 430b, and 430a, matching these sets of properties can be done by

Very similar to that described above, to identify and record that the same vehicle 440 associated with the temporary identifier, can still be seen. Once viewed by the first identification camera while in nested space 430a, the server system 140 will be able to assign a valid unique identifier to vehicle 440. At this point, records previously recorded in database 140 under the temporary identifier can be modified or stored back in the identifier. The correct uniqueness of the vehicle 440, where the use of the destination 450c is correctly associated with that identifier. An alternative mechanism for obtaining identification of vehicle 440 after time t0 is to send a 150 mobile device to take one or more identification images of vehicle 440 while it is in use at the destination 450 A. Mobile device transmission 150 may assign the highest priority where destination use is determined

10 450 EGP by the vehicle in contravention of the restrictions related to the use of the place of destination 450 EGP.

The server system receives 140 images from the identification camera and the destination and completes the identifications of the vehicles parked in the parking lot. Server 140 may retrieve information about the parking fare payment (including but not limited to, paid parking duration and expiry time) from the third-party parking fare payment system

<p dir="rtl">15th Via the API (application programming interface). Once the parking status is determined to be either unpaid or expired, the server system 140 transmits this information to the third-party parking fare payment system via the API. Vehicles that operate a third party fare payment system follow their own Standard Operating Procedures (SOP) to deal with parking violations (eg.</p>

<p dir="rtl">20 For example, but not limited to, sending by post a parking violation card, installing a wheel clamp on the vehicle, or towing the vehicle in case of repeated and severe parking violations.</p>

Vehicle detection can be set by System 140 to perform several functions: (1) detecting the presence and location of vehicles in video frames; (2) distinguishing moving vehicles from non-moving vehicles; (3) identifying whether specific detected vehicles are

<p dir="rtl">25 Occupying intended spaces, for example car parks or no-parking spaces; (4) Determining the time at which the vehicle begins to occupy or leave the place of destination; (5) Track the vehicles while they are moving from a range of</p>

Visibility of the R-cam tracking one to the other, and an exception is raised when an error has occurred in this tracking. In an embodiment, the Server System 140 may also be set up to identify whether the specified vehicles display an appropriate indication of access to or use of the intended location. Examples of such indicators include, but are not limited to, a handicapped parking hanger or poster.

<p dir="rtl">5 decal , a parking suspension or poster indicating an authorized use of a parking space "for residents only". Zoomed into the camera can be done to take clearer pictures of these indicators. In an embodiment, the vehicle identifier may be used, for example, a vehicle number plate, to identify appropriate arrival or use of the destination, and to avoid the need for a separate indication.</p>

In an example implementation, the 140 server system might be programmed to use threads

<p dir="rtl">10 To carry out its tasks for the identification cameras and the destination. For example, the string “Future .” can</p>

video_receiver Dealing with the reception of the video and/or image stream from the identifier or camera of the destination and storing the raw information of the video and/or image. This can happen with one cascade per stream of video and/or image or several streams of video and/or Configuration options for this succession may include (1) store in a file, (2) store in memory, (3)

<p dir="rtl">15th Store in memory and file, (4) the retention time of video data (eg, 4 hours). Another example is a cascade to detect the color, size, location, lane location, speed/direction of travel, whether location The vehicle is in the transport area (which represents one area), an identification camera, and stores this information in the database 141. This cascade can scan all multiple video image frames for updated positioning and speed/direction of the vehicle's travel and store these</p>

<p dir="rtl">20 Information in the database 141. There may be one cascade per video and/or image stream or several video and/or image streams. Another example represents a cascade where it asserts that the specific revealed vehicle was detected as it departed through the transfer area by a nearby cam. This can happen, by browsing the database 141 for a specific camera on which it depends where the vehicle is detected in the transmission area and/or the direction of travel of the vehicle is detected. There may be</p>

<p dir="rtl">25 There is one cascade for each video and/or image stream or several video and/or image streams. Another example is a cascade to determine whether a vehicle occupies its destination by</p>

Remaining immobile at that place of destination, throughout the period of time when the vehicle begins to occupy or leave the place of destination. There may be one cascade per video and/or image stream or several video and/or image streams.

There are many well-known machine vision techniques in the technology that may be used to detect

<p dir="rtl">5 Presence of vehicles in video picture frames. For example, there are many well-known edge detection algorithms that may be used to detect the presence of compounds. As an example, the algorithm may detect the presence of the vehicle depending on the color tolerances between the vehicle and the background, and whether the overall shape size is greater than the minimum expected vehicle size when considering zoom level and/or location in the field of view. For example, the algorithm may compare colors</p>

<p dir="rtl">10 The pixels in a video stream snapshot are opposite each other. Since the image is likely to include non-vehicle objects such as fire hydrants, pedestrians, grass, road markings, and paint, the algorithm can detect groups of pixels of the same color (with a modal range of color variation that is considered identical). The number and location of pixels in the overall shape is used to determine if the shape is .</p>

<p dir="rtl">15th greater than the minimum vehicle size. The algorithm may also accommodate "holes" or shape defects, which may occur as a result of specular reflections or light sources, for example. In addition, the algorithm may determine whether a number of shapes with relevant minimum sizes lie within certain distances from each other. These shapes may correspond to, for example, the hood, roof, and parts of the vehicle's trunk, which are usually of the same colour.</p>

<p dir="rtl">20 A boundary condition may occur where there is an insufficient variance or difference in</p>

The color between the vehicle and the background, so that a failure occurs in the detection process. For example, black asphalt vs. black asphalt. Additional improvements may be made to the camera equipment and/or the algorithm to address this limiting circumstance. For example, you may use a camera that performs both visible light and thermal imaging.

<p dir="rtl">25 Obtain a heat signature for the vehicle that started occupying the intended location. In this example, the engine compartment has a different side heat from the surrounding area</p>

Its out though that both the composite and the background are in black. A feasibility analysis can determine whether the benefits gained from this approach justify the additional cost, as well as take into account the limiting conditions resulting from the thermal imaging process that can be adequately addressed (eg by visible light captured by the camera).

<p dir="rtl">5 Although the existence of the vehicle and the many characteristics of the vehicle can be identified from the</p>

A single image, several images are required and used to determine, for example, whether a vehicle is immobile or mobile. In an example, the 140 server system can be set up to: (1) find, based on color and size selections, compounds in the current image, a meaningful match in previous images (for example, by browsing data stored in the 141 database or memory); and 2) Once the match is found, the pixel locations are compared between the current image and the previous images, taking into account any change in the zoom level. Depending on this processing, one or more of the following scenarios may be detected. (a) When the locations of the pixels are immutable or have an unchanging value less than a predetermined threshold value, all compounds are considered immobile. In this scenario, a simple date and time update of the cells in the database is performed.

<p dir="rtl">15th 141 or vehicle memory. (b) When the paired pixels of one or more compounds are</p>

It is located in a new place, then it is determined that one or more vehicles have moved. Server 140 calculates the speed and direction of travel for these vehicles and updates the 141 database or memory with this information, along with the updated locations. (c) When one or more vehicles disappear from the current image, the 140 server system may be set up to remove the data registered in the database

<p dir="rtl">20 Data 141 or memory for these compounds. (d) When one or more vehicles newly appear in the current image, data associated with the new vehicles may be recorded in the database 141 or memory. In an embodiment, the server system 140 may determine that one of the new vehicles corresponds to a vehicle whose disappearance was recently identified, (e) When all vehicles disappear from the current image, data may be removed from the database 141 or memory from the separator</p>

<p dir="rtl">25 Previous timeline relevant to the vehicles in it. However, some data may be retained to perform vehicle tracking to or from the ID camcorder, as previously discussed.</p>

In an example, the algorithm for identifying vehicles that occupy the destination spaces is similar to the algorithm for detecting the base vehicle. Once vehicle detection is complete, Server 140 assesses whether pixel locations correspond to the vehicle occupying any of the pre-mapped visual regions. Some degree of overlap may be formed. In an embodiment, a 5 vertical offset offset may be applied to compensate for the vehicle's height and to compensate for a visual obstruction, eg a vehicle parked in a parking lot, between the destination camera and the vehicle. These obstructions may occur frequently, for example, in dense parking lots. Also, Server 140 determines that the vehicle has been in the immobile position for at least a certain amount of time. Once it is determined that the vehicle has settled in the intended destination at least 10 for a certain amount of time, the vehicle identification information, the destination place, and the time and date at which the vehicle started using the intended location is recorded in the database 140, preferably in a permanent storage medium. In an embodiment, the Server 140 system may be set up to detect that the vehicle occupies multiple intended locations, eg by occupying two parking lots. This may result in, for example, the issuance of one or more parking certificates or an increase in usage fees. The 140 server system can also determine when a vehicle has evacuated its destination, and records information about it in the 141 database. Also, the valet system 140 may be set up to determine that the user of the destination by the vehicle will soon exceed, or has exceeded, the time period specified for the use of the place of destination, and this may occur with a parking place that has a maximum parking time of two hours, and is not The destination is available to use 20 vehicles after the specified time for sweeping streets and roads, or the available funds for the vehicle have been exhausted.

In an embodiment, a server system 140 may be configured to recognize one or more multi-vehicle destination locations, which may be used by one or more vehicles at a time. For example, a server system 140 may be configured to support tracking of a "long block" of vehicle parking, such that the exact parking space is supplied, for example, by a single Pay-by-Space unit, Pay-and-Display unit, or Pay-by-Plate unit along the sidewalk edge of residential units, but not

dividing the parking space into marked parking spaces; Alternatively, vehicles can make use of any available space along the edge of the curb (except for certain “no-parking” areas, such as but not limited to loading areas and vehicle lanes). In another example, the Server 140 system might be set up to track the use of parking lots. Art, but not a bunch of places

<p dir="rtl">5 tagged separately, which is set, for example, by a single drive-and-display. Although the Server 140 system is not set up to track the use of the intended place designated for several vehicles depending on the space, the Server 140 system may identify and record the position of the vehicle within a destination place designated for several vehicles to track the use of the vehicle over time and for parking implementation activities, for example attaching Recall for a vehicle that exceeds the permitted use</p>

<p dir="rtl">10 To use the intended destination for multiple vehicles. In an embodiment, the valet system 140 may be set up to limit the length of time a vehicle can use its intended destination for multiple vehicles, since a large and/or moderate vehicle parking fee may be charged for use of a space that otherwise may be occupied by one or more vehicles. One benefit of using the 140 server system in this application is that while conventional controlled parking lots may rely on a single point</p>

<p dir="rtl">15th Ingress and egress To control the use of the parking lot, the tracking by using a cam takes into account the parking lot that has multiple entrances and exits and a more “open” design, since the vehicles do not need to be confined to the wall of fencing.</p>

In an embodiment, multiple noncontiguous destinations or multivehicle destinations may be grouped into a single multivehicle destination. has

<p dir="rtl">20 This includes where the two primary destinations are covered by different destination cameras. This may be useful, for example, where the destination space for several vehicles is separated by several "no-parking areas" along the length of the housing units.</p>

In one embodiment, there may be a restricted destination place (eg “no standing is prohibited”).

<p dir="rtl">25 “parking”) overlaps with a multi-vehicle destination site, so that the restricted areas in the multi-vehicle site are “excluded”. For example, in the “long units” scenario</p>

The block” that was discussed above, may specify one destination place designated for several vehicles along the entire length of the residential units, including “no parking” destinations in which there are different types of housing units in the city. loading zones and driveways for vehicles along the unit. A vehicle that has been detected by the Server System 140 as having used a “no-parking” destination is determined by Server System 140 to be committing a parking violation, even though the vehicle is within the largest multi-vehicle destination.

In one embodiment, a computer-based configuration utility is provided. For example, a 150 mobile device or a 10 180 manual review system may be equipped with the configuration services software, allowing on-site or remote configuration. For example, the Handheld 150 may be used by a person installing a camera, in order to provide feedback on the effectiveness of the camera configuration for vehicle identification, tracking, and/or detection. Instead, or in addition to, certain may be Egg metamaterials Ngaa Art on the system range or CAMI R through the system Asta Land Manual 180 result of inadequate selection identified during the 15-use system Alasta manual land 180. In one instantiations, the user interface is available through web browser. Forming services may provide one or more of the following features, including but not limited to:

<p dir="rtl">• Provide a graphical user interface (GUI) to perform vehicle detection calibration for a specific camera.</p>

<p dir="rtl">• Provide a graphical user interface to ensure the alignment of an adjacent camcorder.</p>

<p dir="rtl">20 • Providing a graphical user interface for determining minimum vehicle dimensions. This may be done in a meaningful way</p>

Pixels and adjusts the zoom level.

<p dir="rtl">• Provide a graphical user interface to define the part of the camera's field of view that overlaps the field of view of another camera.</p>

<p dir="rtl">• Provide a graphical user interface for camera alignment and/or camera orientation and/or alignment.</p>

<p dir="rtl">25 • Providing a graphical user interface for the destinations in the pre-planning stage.</p>

<p dir="rtl">• Determining the circumstances that are considered parking violations for vehicles. These circumstances may be specific to a particular region or place.</p>

<p dir="rtl">• Configure results for various stopping violations. For example, information about a violation may simply be displayed on a screen, and information about the registered owner may be obtained for a release</p>

<p dir="rtl">5 An invoice or recall, or an alert may be printed and placed on the vehicle.</p>

<p dir="rtl">• Configure an expiration period after which a new application should be submitted to obtain information on the vehicle owner's registration, for example, the agency for state-run vehicles, before issuing a position via e-mail or otherwise.</p>

<p dir="rtl">• Providing a graphical user interface for other modulation media in the system to be reviewed and modified.</p>

<p dir="rtl">10 To perform a vehicle detection calibration for a particular cam, the graphical user interface displays</p>

A two-image feed, allowing the administrator to install rulers on each image. The zoom level, if any, is displayed as part of the GUI, as a control for adjusting the zoom level. The two feeds consist of images from one camera and another with an overlapping field of view (for example, cameras that are often adjacent to each other).

<p dir="rtl">15th It has two cameras so that images are taken at the same time, which allows viewing of the location of a vehicle in each video feed, for example when it passes through an overlapping area of ​​view for two of the two cameras. The formatting services program may also provide, via the graphical user interface, the functions of controlling the temporary image, such as pause, play, rewind, forward, image forward, freeze, image move, reverse and rewind.</p>

<p dir="rtl">20 For the purpose of calibration, configuration services software may be used to find one or more compounds</p>

of known manufacture (this may include, for example, a tool used by a technician operating the shaping service software), and the location of one or more rulers in the GUI where the rulers refer to the known length/width and width of the compound In one embodiment, the function of the ruler provided by means of an interface

<p dir="rtl">25 Graphics are used to compensate for nonlinearities due to factors such as visual distortion caused by the camera (which may have characteristics known on the basis of a model</p>

camera, for example) or the perspective of the captured image. For example, ruler marks for distance units are placed closer to the right-hand side of the image where the vehicles in the area where the image was taken are farther from the camera than those 5 Modulation services software may be configured to allow on-site calibration of such deviations for a particular camera by specifying marks in an image, and determining locations and/or distances (in relation to other marks).

and/or for the camera). These marks may be placed temporarily, or in some cases permanently, for the purpose of subsequent re-calibration, by a technician.

Also, software may use shaping services to determine the relationships between the transition directions in the two images, as well as to determine the pixels or locations in the image corresponding to the common points in the image.

<p dir="rtl">10 The two pictures. In an embodiment, the locations and travel directions of the traffic lanes/paths in each image may be identified, and the two images correlate (allowing, for example, a later determination of the time a vehicle passes from the range of one cam to another within the same lane/ Traffic path). These attributes may be specified by the GUI, for example, by allowing lines or other indicators to be superimposed in the image that indicate a path/path boundary.</p>

<p dir="rtl">15th Figures 6a and 6b illustrate an example of a GUI. Figure 6a shows the part of the GUI where an image 600a from a first camera is displayed. Figure 6b shows a portion of the GUI where a 600b image of a second camera is displayed. The field of view for images 600a and 600b overlaps, such that the overlap area includes regions 640a and 640b. Also, as shown in Figures 600a and 600b, two lanes of traffic, called</p>

<p dir="rtl">20 Corridors/paths 611a and 612a in Figure 6A, and corridors/paths 611b and 612b in</p>

Figure 6b. In this particular example shown in Figures 6a and 6b, the movement continues in the same direction (generally corresponding to the angles) in lanes/paths 611a and 611b, although in a similar example the movements may proceed in opposite directions ـــ Routes 611A and 611B. Also, pictures of three vehicles were taken in Figures 600A and 600B, named, respectively, A, B,

<p dir="rtl">25 and c. In Figure 6a, lane/path boundaries are defined by dashed lane/path boundaries indicators 621A, 622A, and 623A, which can be added, placed, moved, named, and otherwise specified using</p>

Graphical user interface. In Figure 6a, two motion paths are identified using the GUI: lane 611a between lane boundary indicators 621a and 623a, and lane boundary indicators 612a between lane boundary indicators 622 or 623a. . In a special example illustrated in Figure 6a, traffic in lanes/lanes 611a and 612a continues in

<p dir="rtl">5 The corridor/path boundary indicators are 621A and 622A of the first type (illustrated by similar dashed lines), and the corridor/track boundary indicators 623A of the second type are corridor-flow boundary indicators of the second type in the same direction. Route 621a and 622a to lanes 611a and 612a The modulation services software may be set up to automatically provide or suggest identifiers for specific transit corridors by reference, for example, to corridors specified in relation to</p>

<p dir="rtl">10 With other cameras, for example lanes 611b and 612b shown in Figure 6b. and loyal</p>

Figure 6B, the shaping service software is provided with similar facilities to define the corridor/path, so that the lanes/paths are 611b and 612b, and the lanes boundary indicator lines are described in the corresponding Fig. 621, 662b, above.

In one embodiment, each of the traffic lanes/paths can be divided into a number of 15 smaller parts. These parts can be identified through the graphical user interface, for example

For example, by allowing lines or other indicators to be superimposed on the image indicating parts. In one embodiment, superimposed fonts may be used to help distinguish aberrations in the image automatically. Figure 6A shows an example, which includes an indicator for part of the corridor/pathway 631a and other similar unnamed corridor part indicators. The formation services programs have been prepared to form part of the indicators.

<p dir="rtl">20 The proposed lane/path is automatically based on the predefined lane/path boundary indicators, and is provided by GUI tools to set the lane/path boundary indicators as desired. Also, inserting images of vehicles, for example vehicles A, B and C shown in Technical Figure 6A, may help in setting or adjusting the lane/track part indicators accurately. Figure 6b shows the corridor/path segment indicator 631b and other similar unlabeled corridor/path indicators corresponding to its counterpart in</p>

<p dir="rtl">25 Figure 6a described above.</p>

Shaping service software may also provide similar features via the graphical user interface to define the region of the image stream with a field of view overlapping with a given image stream area. Where these areas are used to 'transfer' vehicle detection from one tracking camera to the other, these areas may be referred to as 'handoff zones'. For example,

<p dir="rtl">5 Figures 6a and 6b show compasses taken with cameras with overlapping fields of view, in which they overlap</p>

The field of view of the carriage area 640a with the field of view of the carriage area 640b. The GUI may be set up to allow for the specification of the transport boundary pointers 651a and 652a in Figure 6a, and the respective transport boundary pointers 651b and 652b in Figure 6b. Also, the defined no-interference area can be divided into a number of smaller parts, using the non-interference portion indicators 611a and 611b.

<p dir="rtl">10 (and the other non-labeled non-intervention part indicators) shown in Figures 6a and 6b.</p>

Configuration services to automatically configure the indicators of the proposed laissez-faire part based on the previously defined laissez-faire indicators, and provide, via the GUI, tools to set the laissez-passer indicators as desired. Also, inserting images of the vehicle, eg Vehicles A, B and C as shown in Figure 6A, may help the technician to precisely set or adjust the latitude part indicators. And in one

<p dir="rtl">15th Avatars, modulation services may be set up to determine the distance between the 651a and 652a non-interference boundary indicators, and alert the GUI user if the distance is less than the minimum desired distance.</p>

Although the graphical user interface shown in Figures 6 A and 6 B shows and describes indicators Art that was provided by the graphical user interface simple lines, it may provide 20 to Armj configuration services and user interface GUI also identify features with more complex forms,

To name a few, free curves and lines. Also, where a specific indicator with respect to a first camera, such as the lane limit indicator 623a, includes a corresponding indicator in relation to other cameras, for example the lane limit indicator 623b, these corresponding indicators may be related to the sensor. In an embodiment, such links may be automatically selected or suggested based on

<p dir="rtl">25 to information such as pre-set pointers, a known position of the camera, a known orientation of the camera, and faces </p>

Known to the traffic near the cam, such as the number of lanes/lanes and the directions of traffic flow within those lanes/lanes.

In one embodiment, where the camera provides the ability to zoom and/or pan/tilt, shaping software may be set up to allow different attributes of the pointer to be defined in images captured in 5 different levels of zoom or camera directions. This additional information may be used to better define the overall field of view of the camera. Once the technician is satisfied with how indicators and/or rulers are used to determine the field of view of a camcorder, this information and/or other information derived from it may be stored in a database 141 for use, for example, in tracking vehicles by the server system 140.

<p dir="rtl">10 Shaping services software may be set up to provide a graphical user interface for performing a contiguous alignment</p>

for cam r video. This functionality can be provided by additional UI elements included in the GUI described above for defining path/path boundaries. Adjacent alignment of the camcorder indicates that during the process of installing the initial camcorders, or if the available camcorders are subsequently updated, if the camcorder is equipped with a pan and/or tilt function, the camcorder needs to be rotated and/or tilted.

<p dir="rtl">15th and/or calibrate the pan, tilt and/or zoom settings of the camera to ensure there is sufficient field-of-view overlap between</p>

Camart, for example, the interference shown in Figures 4, 6a, and 6b. The technician can review the GUI to determine if a non-interference zone of sufficient size and/or duration has been provided by the pair of cameras. If not, the pan, tilt and/or zoom settings may require changes to be made, or the actual mounting location of the camera may need to be completely changed.

<p dir="rtl">20 Shaping services software may be prepared to provide a graphical user interface for planning</p>

Pre-positioning of destination locations, such as car parks and “no-stop” areas. The graphic user interface displays an image and allows the technician to superimpose shaded polygons, for example, in a supplied image. In another example, parking spot #123 might be mapped to a group of 20 pixels as captured by a particular camera for the intended location with a particular zoom level and/or direction of PTZ. An interface has been prepared

<p dir="rtl">25 The graphic user provides operations including, but not limited to, moving, moving, resizing, and orienting these polygons to indicate the location and extension of intended places within the camera's field of view. </p>

Where the camera has PTZ capabilities, PTZ controls may be equipped. This functionality can be provided via additional UI widgets listed in the GUI described above to define path/path boundaries. The GUI may also provide an interface to assign a destination location identifier that can be used, for example, to provide a common destination location identifier5 for use in various aspects of the 140 server system. A GUI may also provide interface elements that allow for defining the various characteristics of a destination site, although it may be preferable to assign these minimum features to the management of the operations/computer functions, or to modify the minimum 140 functionalities/functionalities of the operating system. direct.

In one embodiment, the configuration services software may be set up to provide a graphical user interface to perform preplanning for multi-vehicle destination pre-planning 10, described above, in the same manner as described above for vehicle pre-planning. Forming service programs may be designed to allow multiple destination locations or multiple destination locations for vehicles to be assembled in one destination. For example, each primary destination may be assigned a common identifier indicating that it constitutes a destination for multiple vehicles. The program has prepared 15 formation services to allow restricted destination places to be added to the designated places for multiple vehicles, for “carve” restrictions in a wide area, free loading zones, for example, free loading zones. and driveways.

Configuration services software may be set up to provide a graphical user interface for identifying parking violations. In a first example, the grace period can be set through the graphical user interface, which limits 20 the amount of time the vehicle continues to occupy a destination that violates the restrictions on the use of the destination. For example, when a vehicle is parked in a parking lot, it is reasonable to provide sufficient grace period for the vehicle's driver to leave the vehicle and pay for parking. Different time periods can be specified for different types or groups of destinations (eg a 'non-stop' zone may have a small or zero grace period). In a second example, the amount of overlap of 25 vehicles might be specified by the graphic user interface, in terms of the amount of space in square feet or as a percentage of the vehicle that covers the location of the offence. In an example

Third, the rules for permitting stops can be specified using the GUI, including rules relating to, for example, the use of a vehicle stopping barrier, resident-only parking, or other situations that require a permit or badge to be displayed. The GUI may provide an interface for defining the characteristics of the necessary permissions or emblems, for example, but not limited to, a color, an image that shows

<p dir="rtl">5 on the permit or badge, and the location of the identifier (eg a serial number) of the permit or badge. In example four, a graphical user interface might be set up to define rules for defining what constitutes an expired license plate tag, eg a flag denoting a tag Expired.</p>

Configuration services software has been designed to provide a graphical user interface to identify the consequences of abuse.

<p dir="rtl">10 Using the vehicle for the intended location. Examples include, but are not limited to, a display of license plate information to obtain the name and address of the registered owner, dispatching a law enforcement officer, providing laser-based illumination to a vehicle misusing the place of destination, debiting or filing an account, and applying a file or application. Parking fine from another cash or money account.</p>

Configuration services software may be set up to receive and record media specifying specific compounds that should be used

<p dir="rtl">15th Modify parking violations detected in the parking lot (for example, a police vehicle can be identified as exempt from specific violations). For example, such vehicles are identified by a license plate number, or bear a specific identifier eg one of the badges.</p>

In one embodiment, the server system may be 140 to obtain pre-existing street and/or vehicle parking information, which may be obtained through a commercial database

<p dir="rtl">20 or municipality and/or provided by an operator in a parking lot, specifying information about the stopping place and the traffic lane/lane. In one embodiment, based on the information indicating the location and orientation of the various identification and destination cameras, the Server 140 system is set up to automatically predetermine the destinations and/or paths of movement. In one embodiment, a server system 140 may be set up to register and/or update the properties of destination sites and/or paths.</p>

<p dir="rtl">25 Recorded in database 141, but not limited to, identifiers, locations (eg, width/length or street address), destination usage rates, time, date </p>

and other restrictions for the intended destinations described in this application. In one embodiment, the server system provides 140 APIs to allow the parking service provider to load and/or update the destination information in bulk.

In an alternative embodiment, the server system 140 and other elements illustrated in Figure 1 5 would be an integrated platform where the integration is not with the payment systems rather than the standby API. In these embodiments, part of the integrated platform consists of payment terminals/equipment, and equipment that supplies vehicle tickets for mailing.

In one embodiment, the on-site payment system 160 incorporates the turnkey platform Pay-by-Phone feature. The end result is that

<p dir="rtl">10 End users can pay instead stop by dialing a phone line run by the system) voice response interactive interactive voice response (automated to respond to a special insert ID of the place intended or vehicle license plate number vehicle and the duration of the vehicle stopped, regardless of whether the intended location associated with the meter parking vehicles in parallel, curbside parking meter, pay-by-space parking space, or parking spaces vehicles parking lot.</p>

<p dir="rtl">15th The integrated pay-by-phone allows end-users to pay for parking.</p>

Vehicles using a phone - a cell phone usually. The pay-by-phone enables database-level integration with the server system 140. Database-level integration is superior to API-level integration because database-level integration provides more flexibility and speed.

The integrated telephone payment module receives data from one or more 20 DTMF receivers where users enter the information via the telephone. There is no requirement for the payment unit by phone to receive data from the server system 140 in order to operate the payment unit by phone properly. The integrated pay-by-telephone module may be set up to output data on the mobile device 150 for hand-driven parking fines, as well as for the server system 140 for self-execution. The data is self-processed by the 140 server system.

<p dir="rtl">25 In one embodiment, an on-site payment system 160 includes online payment in a platform</p>

integrated. The end result is that end users can pay for parking or

View the previous parking history by visiting a website and entering the destination ID or vehicle license plate number, and the period of parking the vehicle regardless of whether the destination is connected to a parking lot or parking lot. This extends to other channels on the Internet, such as smart phones.

<p dir="rtl">5 phones, and in the future, Internet-enabled media centers</p>

centers in vehicles.

The online payment unit receives the data via the internet where end users can enter the information online. There is no requirement for the online payment unit to receive data from the server system 140 in order to operate the online payment unit.

<p dir="rtl">10 The right way to the Internet. The online payment unit is ready to output data to the mobile device 150 to pay parking fines by hand, in addition to the server system 140 for self-implementation. All self-executing data is processed on the 140 server system.</p>

In one embodiment, the on-site payment system may include 160 payment and display machines containing QR codes. QR codes have become popular and, accordingly, are widely supported by smartphones. and bonus

<p dir="rtl">15th Therefore, QR codes can easily address all relevant information normally found on the payment card and the Pay-and-Display ticket (for example, but not limited to, parking time, parking permits, notices, expiry time). An integrated Pay-and-Display machine for end-users paying for parking, and leaving a display ticket with a QR code on the vehicle's dashboard. The integrated payment and display machine allows the integration of a level of</p>

<p dir="rtl">20 Database with server system 140. Database level integration is superior to API level integration as database level integration provides more flexibility and speed.</p>

The turnkey Pay-and-Display machine receives payment from end users via its built-in keypad, coin acceptor, credit card reader and credit card reader. There is also an offer

<p dir="rtl">25 for text/graphics on LCD screens. There is no requirement for the payment and display machine to be ready to receive data from the server system 140 in order for the payment and display machine to operate properly. And a machine comes out</p>

150 Integrated payment and display of data on mobile device for hand-paid stop violations, as well as for system 140 for self-implementation. Autonomous data processing is performed by server system 140.

In one embodiment, the at-position 160 payment system comprises an integrated machine for pay-as-you-go.

<p dir="rtl">5 space. Pay-as-you-go is becoming increasingly popular compared to push-and-play, which has a longer history of being launched. Pay-per-spatal stops are generally considered more efficient because parking enforcement personnel no longer have to walk each vehicle and turn to the windshield in order to manually check the printed expiration time. Alternatively, they can walk into a patrol car and perform visual checks from a distance to see if they have paid for their parking space.</p>

<p dir="rtl">10 vehicle. In addition, Pay by Space provides an improved user experience as drivers no longer have to walk back to their car to view tickets after paying at the machine. Instead, they can continue on to their destination.</p>

The integrated pay-as-you-go machine receives payment from end-users via its built-in keypad, coin-receiver device, credit card reader, and printer. There is also

<p dir="rtl">15th Display of texts/graphs on LCD screens. There is no requirement for the payment and display machine to be ready to receive data from the 140 server system in order for the payment and display machine to operate properly. The integrated payment and display machine outputs data to the mobile device 150 for hand-driven stop violations, as well as for System 140 for self-executing. Autonomous data processing is carried out by the 140 server system.</p>

<p dir="rtl">20 The on-site payment system may include 160 integrated pay-per-board machines. The machine receives the payment</p>

Payment from end-users via the built-in keypad, currency receiving device, credit card reader, and printer. There is also text/graphic display on the LCD screens. There is no requirement for the plate payment machine to receive data from the server system 140 in order to operate the plate payment machine correctly. And the payment machine goes out

<p dir="rtl">25 According to the integrated panel of data on the mobile device 150 for parking fines that are paid by hand, </p>

The same applies to System 140 for self-implementation. Autonomous data processing is performed by server system 140.

Integration with third-party parking systems is an option rather than the need for a server system 140. In an integrated lineup, a complete parking equipment platform is provided, for example, through 5 single provider, ie without integration with rack systems. However, there are many advantages to the integrated method using the API. The API provides a standard programming interface designed to allow an external program to access information on the host system without exposing any trade secrets from the host system. This is achieved by creating clearly defined tasks, goals, and variables at the borders between the two systems, so that the external system can obtain a pre-knowledge set of 10 information that the host knows without any information being stored in the host system itself. As such, companies generally have no reservations about deploying APIs for other systems on the interface of their products or services. Data may be exchanged via the API via network-based mechanisms, often protected by encryption mechanisms such as SSL, based on JSON, XML, MIME, HTML, or other API-supported codes or languages.

<p dir="rtl">15th There are two ways for Server System 140 to integrate with the API. First, using the advertised API</p>

By system of parking for a third party, the system can server 140 access to payment information on the vehicle), for example, is not limited to, the period paid about, number space (. In built with the disclosure of information about the vehicle and the identity of the vehicle, a server already 140 system has, the system may own Server 140 may easily obtain all the information needed to create a list of license plates.

<p dir="rtl">20 Vehicles with detailed information on the parking violation of the parking facility operator. The parking facility operator then follows the SOP system, emails parking tickets, fixes wheel clamps, or tow vehicles with severe or repeated offences.</p>

Using the APIs, the Server 140 system can be combined with the following types of parking pay systems: pay by phone, pay by space, pay and display, parallel 25 parking meter (single or double space), and an active operator option.

The basic premise of pay-by-phone is for an end-user (eg a driver of a vehicle) to request a telephone number displayed around the destination. The unique mean, followed by the time required to park, the vehicle's license plate number, and the credit card information.

Telephone payment is beginning to gain traction as a popular “mounted” payment method, where parking facility operators add the ability to pay by phone for parking meters in parallel, pay-as-you-go and pay-and-display machines. The typical motive is to provide end users with an alternative way of paying for parking in an effort to increase parking revenue. For example, a method can be added

<p dir="rtl">10 Pay by phone for a traditional parallel parking meter (single or double space) in order to allow end users to pay by credit card over the phone.</p>

In one embodiment, the server system may include 140 integrated pay-by-telephone units, which may be a component of software that extracts pay-to-park information. The integrated unit is implemented

<p dir="rtl">15th Pay by phone using the following steps: (1) establishing a connection with a third party payment API by phone; (2) issuing a request for data; (3) receiving data; (4) processing and storing data on the database) (5) setting a violation; The intended location as a parking offense in database 141 to be further processed, for example, by the preprocessing logic of the parking offense described below; (7) periodic check that it is a parking counter</p>

<p dir="rtl">20 vehicles in parallel with an effective and valid API, for example, but not limited to, by using "keep-alive"/"ping" commands or messages; and (8) repeat steps 2-7 or end the connection. For step (1), the API usually specifies the mechanism by which a connection is established with it. .</p>

<p dir="rtl">25 Regarding step (2), the server system 140 specifies that a specified vehicle has evacuated</p>

That is, the server system 140 sends a signal with this event to the payment IMMU.

By phone, for example via a database or an Inter Processes Connection (IPC) call, where in response the phone payment integrator issues a command to the 3rd party phone payment API to get the parking payment information for the specified parking API. By phone To a third party, for example, a destination identifier marked 5 by the Telephone Payment API (which may need to be converted from an internally used identifier by

Server system 140), and the date/time of evacuation of the specified vehicle to the destination.

With regard to step (3), the integration module for phone payment is prepared so that it receives information from the phone payment API for the third party, which includes, for example, the start date/time of the paid parking, and the date/time of expiry of the paid parking. Regarding step (5) , initializes the integration unit

<p dir="rtl">10 For payment by phone, comparing the paid parking period shown in the data received from step (3) with the actual parking period determined by the server system 140. In the event that the actual parking period exceeds the paid paid parking period (6), Otherwise, step (6) is not performed.</p>

In one embodiment, the API provided by the server system 140 is used for integration,

<p dir="rtl">15th The payment system by phone only obtains information related to the detection of the vehicle (the start and end time of the actual vehicle parking) from the server system 140, where the information about the vehicle's license plate is usually present in the payment system by phone. Telephone The exact information needed to compose a list of vehicle plate numbers with details of a parking violation.</p>

<p dir="rtl">20 It is usual that when the payment system by telephone or its sign is suitable for the use of the</p>

API provided by the server system 140, the payment system is set up by the phone or its character to take a certain degree of software development according to specifications in general for the purpose of receiving useful data from the parking system 140. The actual time during which a specific vehicle occupied a specific destination place,

<p dir="rtl">25 For a specific vehicle plate number or the number of the intended place. Generally, payment systems have</p>

The phone presets the vehicle plate number or the lot number, where this information can be obtained as part of the payment process for the end user.

The integration may occur by means of the API of the phone payment system supplied by the server system 140 according to one of two options. The first is the data inflow model, in which the third party payment system 5 sends the information to the server system 140. The second is the data outflow model in which the server system 140 sends all the relevant information to the phone payment system.

The system may, in one embodiment, include an inflow-based Pay-by-Phone API that is used by the third party standby payment system, for example

<p dir="rtl">10 Example, over network 110, in which a third party parking payment system sends information to server system 140 via a data entry based phone payment system API. An API is set up for the phone payment system based on data entry to perform steps including, (1) waiting for the third party parking payment system to find a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system The third; (4) processing and storage</p>

15th data in database 141; (5) Determining the status of the parking violation; (6) Marking the use of the intended location as a parking violation in database 141 for further processing, for example, by the parking violation pre-processing logic described below; (7) Periodically checking that the API for the phone payment system which is based on effective and valid data entry, for example, but not limited to, by using messages or commands to “keep in touch” or “ping”, and (8) terminate the connection when

<p dir="rtl">20 request or expiration date. Regarding step (1), this step may include listening to the third party parking payment system via a TCP-powered port gateway.</p>

User Datagram or Transmission Control Protocol

In order to find the connection. For step (2), the third party parking payment system may require authentication of itself through the entry-based phone payment system API.

<p dir="rtl">25 data before data exchange is permitted. If authentication fails, a retry mechanism can be provided, and after several unsuccessful attempts the communication can be broken. Regarding</p>

Step (3) The server system 140 can be set up to receive, via the data entry phone payment API, the parking information of the vehicle from the third-party parking payment system every time the driver of the vehicle makes a parking payment. . receives for a specific vehicle, for example, vehicle number plate information and vehicle parking information (including

<p dir="rtl">5 This includes vehicle number plate and state/province information), an identifier for the destination location in which the payment for the specific vehicle was received (as it may need to be converted from an ID used internally by the server system 140), date/time for which parking was paid, and date/time for parking to end For step (5), the Telephone Payment Logic Module included in the server system 140 can be set up to compare the paid parking period indicated by the data</p>

<p dir="rtl">10 Received from step (3) with the actual standby time that is determined by the server system 140. Whereas if the actual standby time exceeds the standing time, then step (6) is executed, and if this is not done, step (6) is not executed .</p>

Server System 140 may include, in one embodiment, an outflow-based Pay-by-Phone API that is used by the third-party standby payment system,

<p dir="rtl">15th For example, over the 110 network, in which the server system 140 sends the relevant information to the third-party phone payment system. A data-output API can be set up to perform the following steps: (1) wait for the third party parking system to find a connection, (2) authenticate the identity of the third-party parking payment system; and (3) upload data to the parking payment system the third; (4) receiving an acknowledgment of the uploaded data;</p>

<p dir="rtl">20 (5) respond to “keep in touch” and “ping” requests from the third party standby payment system;</p>

<p dir="rtl">(6) Terminate the connection on demand or time out. For step (1), this step may involve listening to the third party parking payment system through a TCP or UDP-powered gateway to find a connection. For step (2), the payment system may require Standing for the third party to authenticate itself through the API of the phone-based payment system that outputs data before data exchange is allowed.</p>

<p dir="rtl">25 If authentication fails, a retry mechanism can be provided, and after several unsuccessful attempts the connection can be lost. Concerning step (3), the server system 140 can be configured to load by</p>

API for a phone payment system whose basis is to output data, vehicle parking information to the third-party parking payment system every time the vehicle leaves the intended location that the third-party parking payment system accompanies it. Information uploaded to a specific vehicle may include, for example, vehicle number plate information, vehicle parking information (including vehicle number plate 5 and state/province information), an intended location identifier that is accessed via a third-party parking payment system (where Its conversion from an identifier used internally by the server system (140), may entail an actual date/time for the specified vehicle to begin use of the destination location the actual date/time that the specified vehicle vacates the intended location.

In another embodiment, the integration of the phone payment system and the server system 140 may be done in 10 two steps. First, Server 140 obtains vehicle payment information from the phone payment system (such as paid parking start and end times, parking lot number, vehicle number plate) by using an API with a phone payment system. At this point, the server system will contain 140 Accurate information is required to form a list of vehicle number plates that include details of a parking violation. However, instead of the server system 140 showing this list to the parking 15 operator, there are cases where the incumbent parking payment vendor wants to maintain control over how parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the phone payment system by using the API that is supplied by the server system 140. The mobile payment system will then fully control how the list of “offending” vehicles is displayed to 20 parking operators (for example, by means of a custom software application being developed

by the telephone payment system provider).

The main difference between this integration method and the integration that relies solely on the API provided by the server system 140 is that this method of integration requires minimal development effort from the mobile payment system provider. This is because all the key information that is given on the server 25 positions is supplied from the ground up by the API supplied by the 140 server system without the need for

No further analysis, and this information can be easily viewed or forwarded to the situation operator with minimal software development. This integration methodology provides a 'pull' followed by a 'push' model.

The idea of ​​the Pay-by-Space system is that as soon as the end user stops the vehicle, they will notice that there is a space number for the parking spot. When the end user pays 5 to stand in the payment machine according to the space, the end user will enter the stall number, followed by the required parking period. And when the payment is made, the end user will not have to leave a ticket in the vehicle, but will continue on their way easily. The space-based payment method works well in both cases of on-street curbside parking and off-street parking lots/parking garages.

<p dir="rtl">10 The method of payment by space is becoming more popular as compared to the method of payment and display,</p>

which has a longer operating history. Parking lots using the pay-per-space system are often more efficient as it is not necessary for enforcement personnel to walk to each vehicle and bend into the windshield area in order to manually check the printed expiration time. Alternatively, they may drive a patrol vehicle and perform a visual distance check to ensure that the

<p dir="rtl">15th The parking lot has been paid for. In addition, the pay-as-you-go method offers a good user experience because the end users will not have to walk back to their vehicles to display tickets after paying the fare at the machine but can continue on their way to their destination.</p>

Similar to the mobile payment method described above, the integration can be achieved by using either the API provided with a push-to-slot system or the API provided by the server system 20 140. The goal is for each system to be able to access all the required information

To prepare a list of vehicle number plates including parking violation information.

In an embodiment in which the Server 140 system is integrated via the Space Push API, the Server 140 system obtains vehicle propulsion information from the Space Pay system (such as the paid parking start and end times, destination location number, and vehicle plate number).

<p dir="rtl">25 The end result will be that the Server 140 system contains accurate information required to produce a list of vehicle number plates that includes details of the parking violation.</p>

In one embodiment, the server system may include a parking payment system 140 logical integration module which may be a software component that extracts the parking payment information from the third-party parking payment system and in which the server system 140 uses the parking self-executing system. The drive system logical integrator 5 by space includes the following steps: (1) Establishing a connection with the API of the third party space payment system; (2) issuing a request for data; (3) receiving the data; (4) processing and storing the data in a 141 database; (5) determining a parking violation case; (6) marking use the intended location as a parking violation in database 141 for further processing, for example, by the parking violation pre-processing logic described below; (vii) periodically ensuring that the 10 third party space payment system API is effective and valid, ie, but not limited to , by using messages or commands to 'stay in a state' 'connection' or 'ping', and (8) repeat steps 2-7 or terminate the connection. For step (1), the API often defines the mechanism by which the connection is created. The logical integrator of the push-to-plot system is set up to monitor the protocol Required API for the 3rd party space payment system that triggers the connection.

<p dir="rtl">15th For step (2), when the server system 140 determines that a specific vehicle has left the site</p>

In other words, the server system 140 sends a signal of this event to the SPLI, for example, via a database or an IPC call, where the SPLI in response issues a request to API for a third-party space-based payment system for payment information for parking a specific vehicle. 20 Data sent to the 3rd Party Payment API may include, for example, an identifier of a destination site accessed via the 3rd Party Payment API, (as it may need to be converted from an identifier used internally by the server system 140), and date/ The time of evacuation of the vehicle specified for the intended location.

For step (3), the logical integrator of the pay-as-you-go system can be set up

<p dir="rtl">25 To receive information from the API of a third party space payment system, including, for example, the paid parking start date/time and the paid parking expiry date/time. Regarding the step</p>

<p dir="rtl">(5) The logical integrator of the pay-as-you-go system can be set up to compare the paid parking period indicated by the data received from step (3) with the actual parking period determined by the server system 140. If the actual parking period exceeds the paid parking period, The processing is performed in step (6), otherwise step (6) is not performed.</p>

<p dir="rtl">5 And in one embodiment where the 140 server system is combined with the pay-as-you-go API</p>

To the third party space Via the API provided by the server system 140, the server system 140 transmits vehicle information to the space payment system (such as the plate number, destination location number, and actual parking start and end times). The end result will be that the space payment system contains Accurate information required to prepare a list of vehicle number plates including 10 parking violation details.

Often when a pay-as-you-go system or its crew can use the API provided by the server system 140, the pay-as-you-go system and its crew are set up to, to a certain degree, develop custom software generally in order to receive some useful data from the server system 140. Useful data in This specific case, the actual vehicle parking time, the actual amount of time that the vehicle occupies a specified destination location, for a specified vehicle number plate or specified parking lot number. Generally, space-based payment systems already contain the vehicle number plate or parking lot number, which can be obtained as part of the payment process by the end user.

The integration via the push-to-space API provided by the server system may be 140 20 depending on one of two options. The first is a data entry form, in which the 3rd party parking payment system sends information to the server system 140. The second is a data output form in which the server system 140 sends all the relevant information to the 3rd party space pay system.

The system may, in one embodiment, include a data-entry-based space-push system API 25 that is used by the third-party parking payment system, for example, over a network 110, in which the third-party parking payment sends information to the server system 140

Via an API for a data-entry based payment-as-you-go system. The space-based payment system API is set up based on data entry to perform steps that include, for example: (1) waiting for the third party parking payment system to find a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system . Payment to stand up to a third party; (4) the processing and storage of data in

<p dir="rtl">5 database 141; (5) Determining the status of the parking violation; (6) Marking the use of the intended location as a parking violation in database 141 for further processing, for example, by the pre-processing logic of the parking violation described below; (7) Periodically checking that the API of the payment-by-spatial system is which is based on effective and valid data entry, for example, but not limited to, by using messages or commands to “keep in touch” or “ping”, and (8) termination of communication on demand or termination of</p>

<p dir="rtl">10 time. For step 1, this step may involve listening to the 3rd party standby via a TCP or UDP port to find the connection. For step (2), the 3rd party standby may require the authentication of itself from Through the API system of the pay-as-you-go data entry before the data exchange is allowed. If authentication fails, a retry mechanism can be provided, and after several unsuccessful attempts the connection can be lost.</p>

<p dir="rtl">15th Regarding step (3), the server system 140 can be set up to receive, via the data-entry-based space payment API, the parking information of the vehicle from the third-party parking payment system every time the driver of the vehicle makes a parking payment. Received for a specific vehicle, for example, an identifier for a destination location in which the payment for the specified vehicle was received (which may need to be converted from an identifier used internally by the server system</p>

<p dir="rtl">20 140), the paid parking start date/time, and the paid parking end date/time. Regarding step</p>

<p dir="rtl">(5) The telephone payment logical integrator included in the server system 140 can be set up to compare the paid parking period indicated by the data received from step (3) with the actual parking period determined by the server system 140. If the parking time is increased For the actual paid parking period, the treatment is performed in step (6), otherwise the step is not performed.</p>

25 )6(.

Server system 140 may, in one embodiment, include an API for a space-based, data-output payment system that is used by the third-party parking payment system, for example, over Network 110, in which server system 140 sends all relevant information to the payment system via third party phone. An API can be set up for a payment system based on space based data output

<p dir="rtl">5 To perform the following steps, for example: (1) wait for the 3rd party Payment to find a connection, (2) authenticate the identity of the 3rd Party Pay for parking; (3) Upload data to the 3rd Party Pay for parking; (4) receive an acknowledgment of receipt of the data (5) Respond to “keep in touch” and “ping” requests from the third-party payment system; (6) terminate the connection on demand or time out. For step (1), this step may include listening to the third-party payment system</p>

<p dir="rtl">10 Paying a third party to stand by a TCP or UDP-powered gateway to find a connection. Regarding step (2), the 3rd party parking payment system may require authenticating itself through the space payment system API to output data before data exchange is allowed. If the authentication fails, a retry mechanism can be provided, after several unsuccessful attempts The connection can be lost. For step (3), the server system 140 can be configured to load via the API</p>

<p dir="rtl">15th For the space-based payment system, whose basis is to output data, the vehicle's parking information to the third-party parking payment system every time the vehicle leaves the intended location, which is attached to the third-party parking payment system. Information uploaded to a specific vehicle may include, for example, vehicle number plate information (including vehicle number plate and state/province information), an identifier for a destination location that is accessed via a third-party parking payment system (where it may require</p>

<p dir="rtl">20 Converted from an identifier used internally by the server system (140), actual date/time when the specified vehicle begins use of the destination location The actual date/time that the specified vehicle vacates the intended location.</p>

In another embodiment, the server system 140 can be configured to integrate with the pay-as-you-go system in two steps. First, the server system 140 obtains the vehicle's payment information from the pay-by system

<p dir="rtl">25 space (such as paid parking start and end times, parking lot number, vehicle number plate) using an API with a space-based payment system. At this point, the server system will contain 140 </p>

Accurate information is required to form a list of vehicle number plates that include details of a parking violation. However, rather than presenting Server System 140 of this list to the parking operator, there are instances where the fee-paying parking provider wants to maintain control over how parking violation information flows back to the parking operator. This can be achieved by sending infringing data

<p dir="rtl">5 The vehicle is then transferred back to the space pay system by using the API that is provided by the server system 140. The space pay system will then completely control how the list of “violating” vehicles is displayed to the parking operator (for example, by means of a custom application software developed by by the pay-as-you-go system provider).</p>

The main difference between this method of embedding and merging is by means of a pay-as-you-go system

<p dir="rtl">10 Via the API provided by Server System 140 that this integration method requires minimal development effort for the pay-as-you-go system provider. This is because all the basic information that is provided on the parking trigger is provided by the API provided by the 140 server system without the need for any additional analysis, and this information can be displayed in a simple form or transmitted to the situation trigger with minimal software development. This consolidation methodology provides a 'withdraw' form followed by a 'submit'.</p>

<p dir="rtl">15th The idea of ​​the payment and display system is that as soon as the end user stands up, he will have to</p>

To leave a ticket inside the vehicle on the dashboard for enforcement personnel to conduct a visual verification to ensure that the time period for which the end user has paid has not expired.

The method of payment and display largely dominated the parking lots away from the street and the car garages. Although push-to-space machines are very popular today,20 the method of payment and display is still firmly entrenched. There are also propulsion and display systems that are used to stand in parallel.

In order to provide self-executing capability, Server 140 requires the following information: vehicle number plate information (including state/province), actual parking start and end times, and paid parking time.

<p dir="rtl">25 In one embodiment where the 140 server system is combined with the push and display system, the . system</p>

Server 140 collects vehicle number plate information with an identification cam, while the cam provides R

Destination Actual parking start and end times by allowing the Server 140 system to determine when the vehicle arrives at its destination and when it departs. Paid parking times can be determined by using destination cameras that have the ability to rotate, tilt and zoom, and zoom them to capture a barcode or printed characters from the same displayed ticket as

<p dir="rtl">5 The end user places it on the vehicle's dashboard.</p>

In an embodiment, in order to facilitate the readability of this information, the push-and-display machine may be set up to use a large font for printed characters or to print large copies of other identifying features. In another embodiment, the pay-and-display machine can be set up to request the vehicle number as part of the payment process, since the traditional system would only require the amount of time during which the driver wishes to park the vehicle. has

<p dir="rtl">10 The push and display system uses rolls to display the ticket via a radio-frequency identification chip (RFID) inserted into each of the displayed tickets.</p>

In one embodiment, the Server System 140 can be configured to perform pedestrian tracking based on multiple images captured by one or more cameras, such as a camera that includes a push-and-play machine within its field of view. Where by pedestrian tracking, the 140 . server system can be set up

<p dir="rtl">15th To track a driver and/or passenger of the vehicle as he or she walks to and/or from the vehicle being pushed by the push and display machine, as far as the Server System 140 tracks the vehicle. Depending on the movement of the tracked pedestrian, the amount paid and the exact location of the vehicle can be associated with a matching vehicle identifier, such as the vehicle number plate, which is identified by the server system 140. In one example, the server system could receive 140 sets of images of pedestrians Captured by one or more</p>

<p dir="rtl">20 cam art, which includes one or more images that show the person riding the vehicle, and one</p>

One or more pictures that show the passenger while he is paying the payment station and the display to use the destination place. The Server 140 system can be set up to perform tracking by determining whether the characteristics identified for the pedestrians photographed are compatible with each other over time, showing the passenger traveling between the vehicle and the payment terminal, and paying the fare. Where, on this basis, can

<p dir="rtl">25 The 140 server system associates the amount paid with the use of a specific destination place by the vehicle.</p>

The Server 140 system, through the information provided above, is able to prepare a list of vehicle number plates that includes accurate details of the violations. This remains true regardless of whether the push and display system provides real-time wireless networking because the push and display system itself does not process the said information.

<p dir="rtl">5 In one embodiment, the server system 140 is combined with the payment and display system via a provider API</p>

With Server System 140, to provide self-executing capability, Server System 140 requires vehicle license plate information (including state/provincial information), actual parking start and end times, and paid parking time.

The Server 140 system collects the vehicle number plate information via an identification camera.

<p dir="rtl">10 The Destination Cam for the Server System 140 allows the identification of actual parking start and end times by detecting when the vehicle arrives at the parking spot and when it departs. The paid parking time is determined by rotating, tilting and zooming destination cameras, allowing them to be magnified to capture the barcode or printed characters from the same display ticket that the end user places on the vehicle's dashboard.</p>

<p dir="rtl">15th In one embodiment, the API can be set up for the payment and display system supplied by the server system</p>

140 To perform the following steps, for example: (1) waiting for the 3rd party payment to find a connection, (2) authenticating the identity of the 3rd party parking payment; (3) uploading data to the 3rd party payment for parking; (4) receiving an acknowledgment of receipt of the data (v) responding to “keep in touch” and “ping” requests from the third party parking payment system; (6) terminating

<p dir="rtl">20 Call on demand or out of time. For step (1), this may involve listening for the 3rd party parking payment via a TCP or UDP-powered gateway to find a connection. For step (2), the 3rd party parking payment may require authenticating itself through the display and push system API Before the data exchange is allowed. If the authentication fails, a retry mechanism can be provided, and after several unsuccessful attempts the connection can be broken.</p>

<p dir="rtl">25 (3) The server system 140 can be configured to upload, via the push and display system API, information</p>

Parking the vehicle to the third-party parking payment system every time the vehicle leaves the site

What is meant by the payment system to stand for the third party. Information uploaded to a specific vehicle may include, for example, vehicle number plate information (including vehicle number plate and state/province information), an identifier for a destination location that is accessed via a third-party parking payment system (which may need to be converted from an identifier Internally used by the server system 140), 5 Actual date/time for the specified vehicle to start using the destination location The actual date/time that the specified vehicle vacates the intended location.

And when it is set up server 140 for a working system in this mode, the server 140 system transfer violation information and parking the vehicle to the payment system and the display) , such as number plate mounted, start times and the end of the stand paid up , start times and the end of the stand paid (. The end result will be that contain 10 Server 140 contains accurate information required to prepare a list of vehicle number plates that includes details of a parking violation.

Often when the push and display system or its crew is capable of using the API supplied by the server system 140, the push and display system and its crew are set up to, to a certain degree, develop generic custom software in order to receive some useful data from the server system 140. The 15 useful data is in the case These specified, start and end times for paid parking, and the start and end times for actual parking for a specific vehicle plate number. In general, payment and display systems are paper-based (i.e. based on a printed display ticket) and do not include any information regarding vehicle identity or destination number. While payment and display systems include the start time of the paid parking and the duration of the paid parking, they do not Through these systems it is possible to know which vehicle the paid parking spot belongs to 20. The display and payment system has the option to display the list of vehicles that include information about the parking violation to the parking operator by using the API provided by the server system 140. Through the API, the push and display system can get printed information from the server system 140 and display it in any convenient way.

As such, the integration via the API provided by the server system 140 is 25 "submit" form where the server system 140 "sends" all the relevant information to the push and display system. Where the payment and display system subsequently displays a list of the vehicle number plates that have been

Suspended without payment or those whose paid parking has expired. In other words, the integration is not achieved via the API provided by the 140 server system in the "pull" model.

In one embodiment, a payment and display machine that includes QR codes can be provided. QR codes have become popular, and are able to convey all the information often found in a payment system ticket and display5 (such as parking time, parking expiry time, amount paid, date and time) with ease.

The phone payment system can, in one embodiment, be combined with a pay and display parking system, whereby the server system 140 can be combined with the phone payment system by API. In this case, where an API with a phone payment system is used, the server system 140 transmits the vehicle detection information to the phone payment system because the 10 vehicle number plate information is often contained in the phone payment system. The end result is that the phone payment system contains the information required to prepare a list of vehicle number plates that includes the details of the parking violation.

Whereas traditional parallel parking meters (either in a single or double space) accept coins only and without the use of intelligence or a built-in 15 network connection method, the mobile payment method has become a common method of “carpooling” and works smoothly. Good in traditional parallel parking meters The parallel vehicle parking meters have recently grown, which accept both coins and credit cards, and have a network connection capability installed in them.

Conventional parking meters generally have a mechanical "expired flag" 20 or displayed on the LCD screen indicating that the parking period has expired or that the parking has not been paid for. In the event that the payment is made to stop and there is a little time left, the mechanical sign of expiration (often in red) disappears, as the LCD screen shows a clear display on the side of the meter opposite the road. Conversely, when paid parking is expired or if payment has not been made, the red mechanical expiration mark 25 is clearly visible in the “upper” position, while the LCD screen flashes alternately between a blank screen and a dim screen dark display )which sometimes contains a screen with

LED Light emitting diode (red flash). Both states are indicated by an expiration mark.

In one embodiment, the server system 140 can overlap with conventional parallel parking meters by using a combination of information collected from both cam

<p dir="rtl">5 Identification and Destination Cam. In addition to defining the parking status of the vehicle (including, but not limited to, the start and end times of parking), images captured by the identification camera and the destination camera can also identify the paid parking status (eg, but not limited to, while If the prepaid period has expired (on the parking meters.</p>

The server system 140 collects vehicle number plate information by means of images that are captured

<p dir="rtl">10 Captured by the identification cam, while images captured by the destination cam allow the Server System 140 to determine actual parking start and end times by detecting when the vehicle arrives at the parking space and when it departs. The paid parking expiry time is determined by zooming in on both the identification camera and the destination camera and by monitoring the visual status of the expiry mark on each parking meter. Based on this information, the system can be determined</p>

<p dir="rtl">15th The server has 140 parking violation cases, and marks the use of the destination location as a parking violation in database 141 for further processing, eg via the parking violation preprocessing logic described below. In cases where the expiration flag is not readable by the server system 140, the server system 140 can be set up to indicate an exceptional case to the parking operator or crew and/or use an active trigger (described below) to identify a violation case</p>

<p dir="rtl">20 Stand and/or manually state the exception flag.</p>

The destination image captured by the Destination Camera across the street will have sufficient angles of view to display the status of the expiry sign on each parking meter. In addition, a pan-tilt-zoom camcorder with sufficient zoom power and viewing angles can be provided to display the status of the expiration mark on each

<p dir="rtl">25 parking meter. Through the information provided above, the server system 140 is capable of producing a list of vehicle number plates that includes detailed information about the violation.</p>

In one embodiment, the Server System 140 is combined with a conventional parallel parking meter system via the API supplied by the Server System 140, to provide a self-executing capability, the Server System 140 requires information about the vehicle number plate (including state/provincial information), Actual parking start and end times, and paid parking period.

<p dir="rtl">5 The server system 140 collects vehicle number plate information by means of images that are captured</p>

Captured by the identification cam, while images captured by the destination cam allow the Server System 140 to determine the actual start and end times of parking by detecting when the vehicle arrives at the parking space and when it departs. The paid parking expiry time is determined by zooming in by both the identification camera, the destination camera, and the visual status monitor.

<p dir="rtl">10 Expiry sign on each parking meter. Based on this information, the server system can identify 140 parking violation cases, and indicate the use of the intended location as a parking violation in the 141 database for further processing, eg via the parking violation pre-processing logic described below. In cases where the expiration flag is not readable by Server System 140, Server System 140 can be set up to indicate a status</p>

<p dir="rtl">15th Exception to the parking operator or crew and/or the use of an active operator (described below) to manually determine the parking violation status and/or exception flag status.</p>

The API can be set up for a traditional parallel parking meter system to perform the following steps, for example: (1) waiting for the third party parking payment system to find a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the parking meter system payment for parking to a third party;

<p dir="rtl">20 (4) receive an acknowledgment of the uploaded data; (5) respond to requests to “keep in touch”</p>

the “ping” of a third-party payment system; and (6) terminate the connection on demand or time out. For step (1), this step may involve listening to the third party standby payment system through a TCP or UDP-powered gateway to find a connection. For step (2), the system may require Pay for parking for the third party to authenticate themselves via the API of the parking meter system in a form

<p dir="rtl">25 Conventional parallel before data exchange was allowed. If authentication fails, a reset mechanism can be provided</p>

Attempt, after several unsuccessful attempts the connection can be lost. Regarding step (3),

The Server 140 system can be configured to upload, via the API of a traditional parallel parking meter system, information about the vehicle's parking to the third-party parking payment system each time the vehicle leaves the intended location that the third-party parking payment system accompanies it. Information uploaded to a specific vehicle may include, for example, vehicle number plate information

<p dir="rtl">5 parking information (including vehicle plate number and state/province information), an identifier for a destination location that is accessed via a third-party parking payment system (which may need to be converted from an identifier used internally by the server system 140), an actual date/time when the use of The specified vehicle of the destination location The actual date/time that the specified vehicle vacates the intended location.</p>

10

15

20

When Server 140 is set up to operate in this mode, Server 140 transmits the parking violation information to a traditional parallel parking meter system, which is often a non-paid payment collection/tallying system Conventional parallel parking. The end result will be that the traditional parallel parking meter system contains accurate information required to prepare a list of vehicle number plates that includes the details of the parking violation.

Often when a conventional parallel parking meter system or its crew is capable of using the API supplied by the server system 140, the conventional parallel parking meter system and its crew are set up to perform, to a certain degree, the development of generic custom software in order to receive some useful data from the server system 140. The data useful in this specific case is the start and end times of paid parking, and the actual start and end times of parking for a specific vehicle plate number. In general, conventional parallel parking meters do not include any information regarding vehicle identification or parking lot number.

As such, the integration via the API supplied by the Server System 140 is a "send" model where the Server System 140 "sends" all relevant information to the traditional parallel parking meter system. And then displays the parking meters system

25

In parallel, the traditional list of license plates of vehicles that have been parked without payment or those whose paid parking has expired.

In one embodiment, the phone payment system can be placed on top of the traditional parallel parking system, and the server system 140 can be integrated with the phone payment system by API.

<p dir="rtl">5 In such a case, where an API with a phone payment system is used, the server system 140 transmits the vehicle detection information to the phone payment system principals because the information about the vehicle number plates of the phone payment system is usually in advance. The end result is that the phone payment system has the information needed to form a list of vehicle number plates with details of the parking violation.</p>

<p dir="rtl">10 Recently, parking meters have been introduced in parallel (single or dual modes).</p>

space) that makes a credit card authorization using a built-in 3G modem or Wi-Fi. In one embodiment, the 140 server system could be configured to interact with this type

of parking meters by parallel API parking meters. In particular, because the parking meters in parallel already have built-in wireless network connectivity and an associated backend server 15, it is not difficult for the 140 server system to integrate with this third-party backend server.

When server system 140 is configured to run in this mode, an integration module in the API

For parallel parking meters, the steps include: (1) Establishing a connection with the API

for parallel parking meters for a third party; (2) Issuing a request for data; (3) receiving 20 data; (4) processing and storing data on the database 141; (5) identifying a case of violation.

stand up; (6) Teach the use of the intended place as a parking violation in Database 141 to be further processed, for example, by the pre-processing logic of the parking violation described below; (7) periodically ensure that the parallel parking meter API is effective and valid, for example, but without . is limited to, by using “keep ping” commands or messages; and (8) resetting

<p dir="rtl">25 Steps 2-7 or end the connection. For step (1), the API usually defines the mechanism by which a connection is established with it. The integration module used in the API is configured for parking meters.</p>

Vehicles in Parallel To monitor the protocol required by the API for parallel parking meters and to establish a connection.

For step (2), when the server system 140 determines that a specified vehicle has evacuated, the server system 140 sends a signal with this event to the integration module 5 in the parking meters in parallel API, for example via a database or call to operations communication Interface (IPC), where in response the parking meter API's integrator module in parallel issues a command to a third-party parallel parking meter API to get the parking payment information for the specified vehicle. Data sent to the parking meters API in parallel to a third party may include, for example, a destination identifier marked 10 by the parallel parking meter API (which may need to be converted from an identifier used internally by the server system 140), and the date/time of evacuation The vehicle specified for the destination.

For step (3), define the parking meter API's integration module

15

20

Parallel so that it receives information from the parking meter API in parallel to a third party that includes, for example, a destination identifier that has been identified by the parking meter API in parallel (which may need to be converted from an identifier used internally by the server system 140), date/ The start time of the paid parking, and the date/time the paid parking ends. With regard to step (5), the integration module in the parking meters API is configured in parallel so that the paid parking period shown in the data received from step (3) is compared with the actual parking period specified by the server system 140. If the actual parking period is increased For the period of paid parking, the treatment is carried out in step (6), otherwise, step (6) is not performed.

Thus, the integration via the parallel parking meters API represents a “pull” model where the server system 140 pulls all relevant information that the third-party parking meters system in parallel can output, and adds the information on the automated parking violation identified by the server system 140 to obtain A list of vehicle number plates with unpaid or expired parking. In other words, the parking meters API's integration is not usually performed in parallel in the "Submit" model.

25

10

15

In an embodiment in which the Server 140 system is configured to integrate with the parking meter system in parallel by means of the API supplied by the Server System 140, the Server System 140 transmits information about the vehicle to the parking meter system in parallel (such as the number on the vehicle number plate, the location The end result is that the parking meter system has in parallel the exact information needed to compose a list of vehicle plate numbers with the parking violation details.

It is usual that when the parallel parking meters system or its sign is suitable for using the API provided by the server system 140, then the parallel parking meters system or its sign is set up to take a certain degree of software development according to the specifications in general in order to receive some useful data from Server system 140. In this specific case, the useful data represents the actual parking time of the vehicle, the actual amount of time during which a specified vehicle occupied a specified destination, relative to a specified vehicle plate number or destination number. Generally, parking meter systems in parallel already have the vehicle plate number or the lot number, and this information can be obtained as part of the payment process for the end user.

The integration via API for parallel parking meters supplied by Server 140 can be according to one of the following two options: The first option is a data entry form, where

The third-party parking payment system sends the information to the server system 140. The second option is a data output model, where the server system 140 sends all relevant information to the parking meter system in parallel.

20 In one embodiment, the valet system may include API 140 for parking meters as

Parallel based data entry for use by a third party pay for parking system via, for example, Network 110, where the third party pay for parking system sends information to the server system 140 via the parking meters API in parallel that is based on data entry. The parking meters API can be configured in parallel based on data entry

<p dir="rtl">25 To perform steps that include, for example: (1) Waiting for the standby payment system</p>

a third to find contact with him; (2) Verify the identity of the third-party parking payment system; (3) receive

data from a third-party parking payment system; (4) processing and storing data on database 141; (5) determining the status of a parking violation; (6) marking the use of the intended place as a parking violation in database 141 for further processing, for example, by the pre-processing logic for the parking violation described below; (7) periodically ensuring that the parking meter API 5 is in parallel effective and valid, for example, but not limited to, by using “keep-ping” commands or messages; and (8) terminating the call when requested or when time limit. For step (1), this may include listening on a TCP or UDP gateway to a standby payment system

Third to find contact. For step (2), the parking pay system requires a third party to verify its identity via the parking meters API in parallel based on data entry prior to allowing data exchange. If the verification fails, a retry mechanism can be provided, and after failed attempts Many can give up contact. Regarding step (3), the payment system 140 can be configured so that, via the parallel data entry API, it receives information about the parking of the vehicle from the third-party pay-per-park system every time the vehicle/driver pays for parking This may include information that is provided

<p dir="rtl">15th It is received for a specific vehicle, for example, an identifier of the destination where payment was received according to the specific vehicle (which may need to be converted to an identifier used internally by the server system 140), the date/time of start of the paid parking, and the date/time of expiry of the paid parking. Step (5), the parking meter integration module can be configured in parallel in the server system 140 to compare the paid parking time indicated by the data generated</p>

<p dir="rtl">20 It is received from step (3) with the actual parking period specified by the server system 140. If the actual parking period exceeds the paid parking period, the processing is performed in step (6), otherwise, step (6) is not performed.</p>

In one embodiment, the API 140 server system for parking meters may include a parallel based data output for use by a third party pay-for-parking system via, on

<p dir="rtl">25 For example, network 110, where the server system 140 pays for parking to a third party sending information to the server system 140 via the parking meter API in parallel that is based </p>

Data Entry. The parking meter API can be configured in parallel based on data entry to perform steps that include, for example: (1) waiting for a third party pay for parking system to make contact with it; (2) verifying the identity of the third party pay for parking; (3) receiving data from a third-party parking payment system; (4) processing and storing data on

<p dir="rtl">5 database 141; (5) Determining the status of the parking violation; (6) Marking the use of the intended location as a parking violation in Database 141 to be further processed, for example, by the pre-processing logic of the parking violation described below; (7) Periodically checking that it is parallel to the API of the parking meters effective and valid, for example, but not limited to, by the use of “stay online” commands or messages;</p>

<p dir="rtl">10 For step (1), this might involve listening on a TCP or UDP gateway for a third party pay-per-parking system to find the connection. For step (2), the pay-for-parking requires a third-party to verify its identity via the parking meter API in parallel with an input If the validation fails, a retry mechanism can be provided, and after several failed attempts the connection can be abandoned.</p>

<p dir="rtl">15th The payment system 140 so that, via a parallel data-entry parking meter API, receives parking information from a third-party pay-per-parking system every time the vehicle/driver pays for parking. The information received for a specific vehicle may include, for example, an identifier of the destination where payment was received according to the particular vehicle (which may need to be converted to an identifier used internally by the server system 140),</p>

<p dir="rtl">20 The date/time the paid parking starts and the date/time the paid parking ends. For step (5), the parking meter integration module in parallel can be configured in the server system 140 to compare the paid parking time indicated by the data received from step (3) with the actual parking time specified by the 140 server system. If the actual parking period exceeds the paid parking period, the treatment will be carried out in step (6), otherwise it is not</p>

<p dir="rtl">25 Perform step (6).</p>

In one embodiment, the valet system may include API 140 for parking meters as

Parallel based data output for use by a third party pay-for-parking system via, for example, network 110, where the server system 140 sends all the information to the third-party parking meter system in parallel. The parking meter API can be configured in parallel with the data output to perform steps that include, for example: (1) waiting for the parking system 5 for a third party to make contact with it; (2) verifying the identity of the parking meter for a third party a third; (3) upload data to a third party pay-per-view system; (4) receive an acknowledgment of the uploaded data; (5) respond to “ping” requests from a third party pay-per-view system; and (6) terminate Call when requested or on timeout. For step (1), this may include listening on a TCP or UDP gateway to a standby payment system

<p dir="rtl">10 Third to find contact. Regarding step (2), the parking payment system requires a third party to verify its identity by the parking meters API in parallel based on data output before data exchange is allowed. If the verification process fails, a retry mechanism can be provided, and after several failed attempts a Give up contact. Regarding step (3), the payment system 140 can be configured so that, via the parallel parking meters API that is based on data output,15 the information about the parking of the vehicle is uploaded to the third-party parking payment system every time the vehicle evacuates the destination In contrast, this system. The information received for a specific vehicle may include, for example, an identifier of the destination where payment was received according to the specific vehicle (which may need to be converted to an identifier used internally by the server system 140), the actual date/time of commencement of use of the specified vehicle of the destination, and date/time</p>

<p dir="rtl">20 Actual to evacuate the vehicle specified for the destination.</p>

In one embodiment, the valet 140 can be configured to integrate with the parking meter system in parallel by two steps. First, the Server 140 system obtains the vehicle payment information from the parallel parking meter system (such as the paid parking start and end times, parking space number, vehicle plate number) by using the parallel parking meter API. At this point, the server has Server system 140 exact information needed to configure a list of

Vehicle plates with parking violation details. However, instead of the server system showing this 140

Based on the parking regulating factor, there may be instances where the incumbent parking payment vendor wants to retain control over how information about a parking violation flows back to the parking regulating agent. This can be done by sending the vehicle violation data back to the parking meter system in parallel by using API 5 provided by the server system 140. Hence, the parking meter system in parallel has complete control over how the list of vehicles “committing” is displayed to the parking regulator (eg by using a specification software application developed by the parking meter vendor in parallel).

The big difference between this integration method and the API integration provided by the 10 Server 140 system is that this integration method requires minimal development effort by the parking meter system vendor in parallel). Parking is pre-arranged by the API provided by the server system 140. Without any additional analysis needed, this information can be displayed or transferred to the parking regulator at minimum software development.This integration method is a “pull” followed by a “push” model.

<p dir="rtl">15th Similar to the pay-per-space system, where the payment for parking is associated with the numbered parking space</p>

The specified (where the vehicle is parked) and the pay-per-plate system pairs the parking payment for a vehicle with the license plate number of the specific vehicle that is in the parking lot. Manual implementation of the plate-pay system usually includes driving the enforcement officer behind the actual parking space to ensure that the number plates of all parked vehicles are on the list Paid vehicle number plates Conversely, 20 any parked vehicles whose number plates are not on the “paid vehicles” list will receive a parking violation.

Similarly to the pay-as-you-go and Pay-to-Space systems mentioned above, the integration can be done using the Pay-by-Panel API or the API provided by the Server System 140. The goal of both systems is to access all the information needed to create a list of 25 vehicle number plates with information on parking violation.

In one embodiment where the 140 server system is integrated via the Pay-by-Pay API

By plate, the Server 140 system obtains information about vehicle payment from the Payment by Plate system (such as the start and end times for paid parking and vehicle plate numbers). The end result is that the Server 140 system will have the exact information needed to generate a list of vehicle number plates with violation details stand up.

<p dir="rtl">5 In one embodiment, the server system may include 140 pay-per-board integration modules</p>

Pay-by-Plate integration module, which may be a software component that extracts payment information from a third party parking payment system that Server 140 uses during parking self-execution. The Pay-by-Panel Integration Module performs the steps that include: (1) finding

<p dir="rtl">10 connection with the third-party Pay-by-Plate API; (2) Issuing a request for data; (3) receiving data; (4) processing and storing data on the 141 database; (5) determining the case of a parking violation; (6) teaching the use of the intended place as a parking violation in the 141 database for further processing, for example , by the parking violation pre-processing logic described below; (vii) periodically making sure that it is the API of the party's pay-per-board system</p>

<p dir="rtl">15th The third is effective and valid, for example, but not limited to, by the use of "keep-ping" commands or messages; and (8) repeat steps 2-7 or terminate the connection. For step (1), the API usually defines the mechanism by which a connection is established with it. The PPI is configured to monitor the protocol required by the 3rd party PPay API and find a connection.</p>

<p dir="rtl">20 . Regarding step (2), when the server system 140 determines that a specific vehicle has</p>

With an intentional space, the server system 140 sends a signal of this event to the integrator for the pay-as-you-go module, such as via a database or an IPC call, and in response the integrator issues the pay-per-plate command To the third-party plate payment system API for parking payment information

<p dir="rtl">25 for the specified vehicle. Data sent to the third-party PPC API may include, for example, vehicle license plate information (including plate number, vehicle information</p>

State/province), and the date/time of evacuation of the specified vehicle to the destination.

For step (3), the Pay-by-Pay Integration Module can be configured to receive information from the 3rd party Pay-to-Pay System API, for example, the paid parking start date/time and the paid parking expiry date/time. Regarding step (5) , can prepare

<p dir="rtl">5 The integration module prepared for payment by plate to compare the paid parking period shown by the data received from step (3) with the actual parking period specified by the server system 140. If the actual parking period exceeds the paid parking period, the processing is performed in step ( 6), etc. Step (6) is not performed.</p>

In one embodiment where the 140 server system is integrated with the pay-per-board system via

<p dir="rtl">10 The API supplied by the server system 140, and the server system 140 sends information about the vehicle to the plate payment system (such as plate number, destination, and actual start and end times of parking). The end result is that the plate pay system has the exact information needed To form a list of vehicle number plates with parking violation details.</p>

It is customary that when the payment system by plate or its sign is appropriate to use the

<p dir="rtl">15th API supplied by the server system 140, the drive-by-plate system or its character is set up to take a certain degree of software development as per the specifications generally in order to receive some useful data from the server system 140. In this specific case, the useful data represents the actual parking time of the vehicle, the amount The actual time during which a specified vehicle occupied a specified destination place, in relation to a specified vehicle plate number. Of course, pay-per-plate systems already have a number</p>

<p dir="rtl">20 Vehicle plate, which can be obtained as part of the payment process for the end user.</p>

The integration via the API of the third-party pay-per-board system supplied by the server system 140 can be according to one of the following two options: the first option is a data entry form, where the third-party pay-per-park system sends information to the server system 140. The second option is an output form Data, where the 140 server system sends all the information

<p dir="rtl">25 Related to the third-party pay-per-board system.</p>

In one embodiment, the server system may include a pay-per-board API 140 as its base

Data entry for use by a third party pay-per-park system via, for example, network 110, where the third-party pay-per-park system sends information to the server system 140 via the data-entry-based pay-per-board API. The API can be configured for the pay-by-board system that is based on data entry to perform steps that include, at

<p dir="rtl">5 Example: (1) Waiting for the third party Pay for Parking to find contact with it; (2) Verifying the identity of the Third Party Pay for Parking; (3) Receiving data from the Third Party Pay for Parking; (4) Processing and storing data on the Database 141; (5) Determination of the case of a parking violation; (6) Teach the use of the intended place as a parking violation in Database 141 to be further processed, for example, by the pre-processing logic for the parking violation described below; (7) Verification</p>

<p dir="rtl">10 periodically ensuring that the API for the pay-as-you-go data entry system is effective and valid, for example, but not limited to, by the use of "stay online" commands or messages; and (8) terminate the connection on request or when timed out. For step (1), this may involve listening on the TCP or UDP gateway of the third party pay-per-park system to find the connection. For step (2), the pay-to-park system is required For the third party to verify their identity by API</p>

<p dir="rtl">15th For a pay-per-board system that is based on data entry before data exchange is allowed. If the verification process fails, a retry mechanism can be provided, and after several failed attempts the connection can be abandoned. With regard to step (3), the payment system 140 can be configured so that, through the API of the payment-by-plate system that is based on data entry, it receives information about the parking of the vehicle from the third-party parking payment system every time the vehicle/driver pays for parking. It may include</p>

<p dir="rtl">20 Information received for a specific vehicle, for example, vehicle plate information (including plate number and state/provincial information), start date/time for paid parking, and date/time for paid parking to end. Regarding step (5) In the server system 140, the pay-to-board integration module can be configured to compare the paid parking time indicated by the data received from step (3) with the specified actual parking time</p>

<p dir="rtl">25 By the server system 140. If the actual parking period exceeds the paid parking period, the processing is performed in step (6), otherwise, step (6) is not performed.</p>

In one embodiment, the server system 140 may include a push-to-plate API based on data output for use by a third-party standby payment system via, for example, network 110, whereby the server system 140 sends all relevant information to the pay-as-you-go system for the third party. The API can be configured for the payment system by plate based on data output

<p dir="rtl">5 To perform steps that include, for example: (1) Waiting for the payment system to stand by</p>

the third to find contact with him; (2) Verify the identity of the third-party Pay-to-Park system; (3) Upload data to the Third-Party Pay-to-Park system; (4) receive an acknowledgment of the uploaded data; Paying for parking to the third party;

<p dir="rtl">10 This listening involves a TCP or UDP-operated gateway for a third-party pay-per-view to find the connection. Regarding step (2), the parking payment system requires the third party to verify its identity by the API of the pay-as-you-go API before allowing data exchange. If the verification process fails, a retry mechanism can be provided, and after several failed attempts it can Give up contact.</p>

<p dir="rtl">15th With regard to step (3), the payment system 140 can be configured so that, through the API of the payment-by-plate system that is based on data output, the information about the parking of the vehicle is uploaded to the third-party parking payment system every time the vehicle vacates the intended place in conjunction with the The information received for a specific vehicle may include, for example, an identifier of the destination where payment was received according to the specific vehicle (where a transfer may be required</p>

<p dir="rtl">20 (for an identifier used internally by the server system 140), the actual date/time for starting use of the specified vehicle for the destination, and the actual date/time for evacuating the specified vehicle for the destination.</p>

In another embodiment, the server system 140 is configured to integrate with a two-step data-out based pay-per-board system. For starters, the server system 140 obtains payment information from the pay-per-plate system (for example, actual parking start and end times, plate number

<p dir="rtl">25 vehicle) by using the API provided by the pay-per-plate system. At this point, the server system 140 has the exact information needed to generate a list of vehicle plate numbers with</p>

Parking violation details. However, instead of Server System 140 showing this list to the parking regulator, there may be instances where a vendor paying for the mandatory parking would want to retain control over how information about the parking violation flows back to the parking regulator. This can be done by sending the vehicle violation data back to the pay-per-plate system by using the API provided by the server system 140. Hence, Pay-per-Plate has complete control over how the list of “violating” vehicles is presented to the parking regulator (eg by using a specification software application developed by the Pay-by-Panel vendor).

The big difference between this method of integration and the integration with Pay-per-Panel by API provided by Server System 140 is that this integration method requires minimal development effort from 10 Pay-per-Panel vendors. Since all the key information to be presented to the parking regulator is pre-provisioned by the API supplied by the 140 server system without any additional analysis required, this information can be simply displayed or sent to the parking regulator with minimal software development. This integration method is represented by a 'pull model' followed by a 'submit' model.

There are two main reasons why the use of a team of personnel directly as part of the system shown in Figure 1 is worth considering and could provide a practical option for future presentation to parking operators as an additional feature.

First, although the server system 140 independently receives and processes comics obtained from the identification and mapping cameras, there are usually direct operators who monitor the images obtained and implement software by the server system 140. Live operators can 20 Review the operation of the server system 140 and take appropriate actions on an exceptional basis as required. For example, when an unexpected problem occurs, live workers can review images related to the problems and infer information that Server System 140 cannot be configured for use.

The benefit of the network architecture supported by the 140 server system is that a single team of 25 workers can directly inspect or enhance operations at multiple locations regardless of their respective geographical locations or the fact that the facility's operations can be traced back to standby operations.

different or even to competitors. As a result, straightforward staffing can represent an economically viable and scalable method for parking operators. In addition, by using a similar standard TCP/IP protocol or IP multicast, a video stream can be sent synchronously to multiple destinations, allowing for the future addition of the live operator option5 in addition to local on-site spatial monitoring. -site monitoring provided by the parking regulator.

Second, depending on the technology available, the parallel, thrust and display combinations described above may present significant actual duration challenges. Not only do cameras with a high level of zoom require, but there are also potential issues such as the specified angle of 10 of view of a video camera may not be sufficient to adequately detect the expiration flag of a familiar parallel parking meter. , or it may be a bar code on the payment ticket and displayed on the car dashboard pointing away from either camcorder in view of the 3D shape of the car dashboard and the ticket location itself.

Using the Live Workers option, Server 140 can generate exceptional events 15 for a worker directly when Server 140 fails automatically to detect key pieces of information such as the license plate number, the status indicating the expiration mark on a traditional parking meter, or a bar code/ Information printed on the payment and display ticket. This exceptional event can directly prompt the agent to take a number of specific actions, including specific rewind/fast forward/stop/frame hold RWD &amp; FWD shots captured by 20 cameras and/or mapping, zoom focused on areas Specific involved in the shots

captured, pan/tilt/zoom camcorders in real time to obtain enhanced images, and send people to the site to check a vehicle or parking meter, but by viewing it or using a mobile device 150 to obtain images optimized for use by the server system 140.

In one embodiment, the server system 140 is configured to associate the registered owner's mailing address

<p dir="rtl">25 For a vehicle with its own vehicle plate number, which allows the parking regulator to collect any incoming parking fines. Red-light camera systems like these are used</p>

The mechanism for sending tickets for violations to the registered owners of vehicles. With regard to this job, parking regulators are divided into three different categories.

First, in the case where the parking regulator is part of a city/municipality where it may already have access to DMV records, the 140 server system may require the provision of just a list

<p dir="rtl">5 From vehicle plate numbers with state/provincial information along with parking violation details (such as time, date, and location) in order to mail the fines to registered owners.</p>

Second, for private parking operators who do not have prior permission to access DMV records, there are a number of authorized ways to obtain personal information, including name and address, linked to

<p dir="rtl">10 Vehicle plate number. These methods vary from state to state (and county). For example, in New York state, private parking regulators are allowed to obtain permission to access this information by using the Driver's Privacy Protection Act (DPPA) Form MV-15DPPA to "use In accordance with the process of operating a fee-based transportation facility, “including companies that operate parking facilities for the purpose of providing an indication to vehicle owners who</p>

<p dir="rtl">15th Use the Facility.” For some jurisdictions, name and address information can be displayed online, and a server system 140 can be configured to obtain and process this information. In some jurisdictions, name and address information for a third party vehicle owner may not be displayed over the Internet, Instead, it should be obtained by mail or in person.In these jurisdictions, parking operators may wish to obtain information on</p>

<p dir="rtl">20 Name and address in batches (for example, daily, every 2 or 3 days, or weekly).</p>

And third, for private parking workers who prefer to access information on the registered owner in real time, a number of databases of private vehicle plate numbers are available online. The main benefit of this method is that the name and address information can be retrieved directly or automatically without the need for any manual operation.

<p dir="rtl">25 As indicated in Figure 1, end-user systems can include systems</p>

inside vehicles. In one embodiment, it could include the dashboards of new vehicles that…

Bought directly from car manufacturers, an indicator icon, on other vehicle dashboard lights such as "Check Engine", parking brake warning, or cruise control indicator lights. Normally, this indicator symbol is not illuminated when vehicle 130 is traveling on a highway or within an area not serviced by the valet system 140. When approaching

<p dir="rtl">5 Vehicle 130 from the parking lot or parallel parking areas, the indicator symbol may light up in yellow to notify the end user of the availability of automatic parking services provided by</p>

Prior to the server system 140. When the 130 is towed to an intended location, such as a parking lot, the indicator icon turns red to inform the end user that parking has not been paid. Once payment is made for parking (either by phone payment system, parallel parking meter, system

<p dir="rtl">10 Pay by space, or other techniques), the indicator symbol becomes green to indicate that you have been paid to stop. In one embodiment, these visual cues can be accompanied by audible notifications, which may be simple chimes or voice announcements The audio output can be done by supplying audio data or information to a vehicle entertainment unit.</p>

<p dir="rtl">15th Whereas, this invention enables the automation of many aspects of the implementation and payment processes</p>

When parking, it is important to provide results to end users regarding how a server system 140 works or associate a state server 140 system with vehicle 130 (for example, regarding vehicle 130 who committed a parking violation). Hence, end users can respond accordingly to the results. While operating within a highly automated execution and payment system,

<p dir="rtl">20 It is reasonable to expect that end users or registered owners will not be penalized for insignificant or administrative errors. The results provided via a simple interface such as the vehicle dashboard indicator can alleviate this a lot.</p>

For example, when vehicle 130 is stopped, if the red indicator symbol remains after

Over time, the end user realizes that an extraordinary event has occurred. It may be an extraordinary event

<p dir="rtl">25 In that it is possible that the registered credit card number has expired and therefore the 140 server system is not able to charge a parking fee. These results provide the end user with the opportunity to,</p>

For example, by visiting a website provided by or according to server system 140 to inquire about his/her account and correct the error.

There are a number of potential sources of information from which the dashboard can obtain its information, including 5 built-in cellular data or WiFi vehicle connectivity.

connectivity, or smart sensors (described below). For older, factory-installed non-indicator coded vehicles, end users can be equipped with an upgraded retrofit kit in the form of a visual module that receives information via Bluetooth, cellular data or connect via Wi-Fi.

<p dir="rtl">10 In one embodiment, the pointer symbol parameter receives GPS location data from systems</p>

A subsection inside the vehicles for a third party to determine if the 130 vehicle is currently in a paid parking zone.

Similar to a vehicle's dashboard symbol, smart sensors can be built into the interior of new vehicles that it gets directly from the factory. Using a technique similar to the IEEE ZigBee scale

15th 802.15.4, it can create short-range, low-power and low . wireless lattice networks

Within and between vehicles cost, low power, short range wireless mesh networks

and stand equipment. Each component becomes a node, and the junction can communicate with a distant end point by transmitting data through intermediate nodes by forming a lattice. Each smart probe contains a unique identifier, so that information about

<p dir="rtl">20 The vehicle plate is important then. In one embodiment, the smart probes may be configured to communicate with the server system 140 via a cellular data connection and/or provide a telephone payment function, so that payment for the use of a destination can be made via the smart probe.</p>

Many applications are possible with the introduction of such smart sensors. For example, smart sensors could include a global positioning system receiver

in- Vehicle GPS or can connect with GPS receiver (GPS) Positioning System 25

vehicle GPS to determine the current location of the vehicle 130 and inform the server system 140 of the current location.

With the use of some GPS technologies, such as GPS, GPS assisted GPS, the location determined by the GPS may have sufficient accuracy to determine that the vehicle is making use of the specified destination. These sensors can also communicate with the parking meters and essentially inform the presence of the vehicle and the length of time the vehicle has been parked. This parking information can be sent to a remote network/device through capillary 5 so that the parking equipment does not need to be placed inside the vehicle. For vehicles equipped with smart sensors, the use of identification cameras is not necessary, as the smart sensor inside provides the unique identity of the vehicle to the server system in advance.

In one embodiment, vehicles may be equipped with a near-field NFC (communication) device, eg an RFID chip. For example, 10 such communication device may be in a mirror holder. The RFID chip is embedded in a card supplied through a payment and display device. By obtaining vehicle identification from a NFC device, camcorder images, such as images that include vehicle number plate information, may not need to be used by the server system 140 and/or may be used to verify information received from a vehicle identification device. 15 NFC corresponding to the vehicle being monitored.

In one embodiment, smart sensors can sense the status of other vehicles nearby (eg, are the vehicles moving or in a queued position, how long they have been lined up) and report the status to the server system 140. The end result is that the server system 140 Knows where and for how long a vehicle with a Smart Sensor is parked. By combining this information with parking payment information from either third-party systems or key-delivery platforms, identities can be determined for vehicles that have not paid for parking, have an expired parking period, have parking tickets emailed to their owners or that have been e-mailed to their owners. She was charged with parking tickets at the site (for example, debiting a credit card on file).

In one embodiment, the destination camera can be provided with a laser 25 status notification. Similar to the laser notification devices in shopping malls and retail stores, where the laser status notification feature lights up with a red light and a harmless flash around

The parked vehicle to inform a consumer upon his return that parking has not been paid for or that the parking period has expired. This is as close as possible to returning to the car and finding the ticket under the car's wipers, according to the traditional manual parking law enforcement model. Since the destination camera is usually placed at a high position in relation to the vehicles, the presence of a laser status notification unit for it

<p dir="rtl">5 A panoramic view of the bottom of the destination locations It is easy to illuminate the laser warning at the destination locations of the vehicles.</p>

In one embodiment, the laser status reporting feature replaces the posting of a paper parking violation. If the user receives a laser notification of a parking violation, the user can be expected to pay the parking fine through a number of means including, but not limited to,

<p dir="rtl">10 Website or pay by phone. Furthermore, laser status notifications can be captured by the destination camera to provide final evidence of a parking violation and notification.</p>

In one embodiment, a single real-time dynamic parking reservation is a feature made available by the online/telephone/smartphone parking reservation system, and can be further enhanced with the laser status notification feature. Although some sellers offer

<p dir="rtl">15th The car parking reservation feature, however, this feature is limited to reserving parking in public places surrounding car parks (for example, somewhere in a car park), due to the lack of a practical way to automatically reserve one specific car park. In addition, Reserved parking spaces usually remain available for a long time because there is also no practical way of knowing when a parking space will be available again after the parking driver has lined up and left.</p>

<p dir="rtl">20 On the other hand, the single parking lot reservation feature in dynamic real time allows users to</p>

Finalists specify the exact car park they want (for example, the one closest to the mall during the holiday shopping period), for a specific time period (for example, a destination place can be reserved for use some day in the future). Parking Reservation, the laser notice can illuminate at the parking spot to indicate that the intended location is reserved (on

<p dir="rtl">25 For example, it gives a red color as a warning to other drivers.) It results from the use of the intended location </p>

During the period of being impounded by another vehicle in violation and parking, which allows the parking operator to increase his profit by offering graded/premium priced parking, and pre-booking parking.

In one embodiment, the parking operator can designate specific destination places as prohibited locations that are used only by the vehicles that have booked them. In this embodiment, 5 the 140 server system can determine that a number of reserved destinations are available for a given period, and sets the reservation price based on the number of available unreserved destinations remaining. In one embodiment, the 140 server system can be configured to allow buyers to bid competitively for the use of the reserved destination sites.

In one embodiment, the pay-by-phone feature can be provided either directly, through a 10 key-delivery platform, or through partnership with a third-party vendor. The end result is that the end user can pay for the parking by calling a specific IVR phone line, entering the destination location number or vehicle plate numbers, and the duration of the parking. In another embodiment, online payment is a variant of the same format to support online payment for parking, usually via a website accessible via a smartphone-enabled Internet (web)-enabled smartphone.

.enabled smartphone 15

In one embodiment, the push" technology feature" could be incorporated where once the end user parks the 130 in the parking lot, the end user receives a text message or other notification prompting him to respond positively to charge a certain price until the vehicle leaves the destination. The server system 140 identifies the vehicle 130 through the identification cam, and further identifies that the vehicle 130 is associated with a pre-registered end user using a credit card or billing information and a cell phone number or other contact information in the registry. Once the Server 140 system determines via the destination cam that the 130 has lined up at the intended location, the Server System 140 creates a series of "data flows" in order to effectively inform and engage the driver for payment or payment confirmation. By simplifying the payment process, an improved parking profit is achieved.

<p dir="rtl">25 In many traditional parking meter systems, if the end user pays for a period</p>

Longer than the actual period that the end user has used the stand, the redundant time remains displayed

over the counter to be used by the next end user. In one embodiment of the invention, the destination cam 125 allows the servo system 140 to accurately determine when the vehicle will leave the destination location, and any "residual amount" of paid parking time is zeroed. Parallel alignment meters are excluded from this, as these meters do not have any communication or intelligence ability to activate

<p dir="rtl">5 Expiry notice before the time expires.</p>

The Server System 140 can be configured to provide a software component of data flow technology that improves the user experience in terms of push-to-position. The information flow technology supports functions such as: (1) creating a payment sequence through a text message; (2) allowing a pre-registered user to take a picture of the license plate, and then supplying the image to the 140 server system by,

<p dir="rtl">10 For example, an email or text message; (3) allowing an unregistered user to take a picture of their license plate, and then supplying the image to the 140 server system via, for example, email or text message; and (4) allowing drivers to register one time to not get fines Standing within the subscription-based model, the data propulsion technology component interacts with the vehicle identifier detection logic, a detection logic</p>

<p dir="rtl">15th Vehicle detection logic, 141 database, and payment gateway. Regarding clause (1), based on the ID of the vehicle that has just started using the destination, eg parking, the data flow component sends a text message indicating that the destination is started to the cell phone number registered using the server system 140. When the driver authenticates the message text by replying “Yes”, the appropriate usage fee can be charged from the card</p>

<p dir="rtl">20 The credit associated with the registered account includes, but is not limited to, a flat rate parking fee for use of the destination. Regarding clause (2), a driver who has previously registered using the server system can take 140 images of his license plate, and then send it by e-mail or text message to the server system 140. The usage fee is then calculated from the associated credit card With the registered account of the pre-registered user</p>

<p dir="rtl">25 (3) For vehicles with number plates not registered in the 140 server system,</p>

The driver takes a picture of the license plate, and then sends it by e-mail/message

text to the server system 140. If the telephone service provider supports or provides access to this bill payment feature, the amount of use can be added to the monthly cell phone bill of the user. With respect to clause (4), the driver may register for a one-time automatic payment of all usage charges (or at least all parking charges) using a registered credit card.

<p dir="rtl">5 And the data flow technology software can be configured to work on automatically sending a text message to a user in the case where the server system 140 determines that an inappropriate use of the intended place occurred, for example parking the vehicle in a “no parking” place.</p>

The Server System 140 can be configured to provide a component logic software with a parking violation pre-processing logic that examines all newly created destination use cases.

<p dir="rtl">10 They are considered violations and assigned to the corresponding driving location as specified in the system definitions, for example the license plate search unit or the license plate transmitter unit, mentioned below. The parking violation preprocessing logical software component interacts with database 141, service programs that supply system definitions, or third-party APIs. The parking violation preprocessing logic component can be configured to: (1) insert violations into the enqueue queue</p>

<p dir="rtl">15th violations identified by other software processes in the server system 140; (ii) Examine the next offense queue; (iii) Verify that the use of the destination is an offense by checking the rules established by service programs that provide system definitions related to the destination and specify the use of the destination by the vehicle; 4) converting the violation to the vehicle number plate processing logic; and (5) checking for any other violations in the waiting list or</p>

20 Waiting for the definition of the last fear.

Server System 140 can be configured to determine if a vehicle has an ID image expiration mark. The identification image can be captured using a fixed ID camera 120, however at typical vehicle distances and speeds, and the size of the small Typical Expiry Date indicator on the vehicle number plate, determining that the vehicle is marked with the identification image alone is a matter.

<p dir="rtl">25 impossible. Using a pan-tilt-zoom camera capable camera (PTZ-) that zooms in on the license plate of a fixed vehicle, it is possible, either by using</p>

Identification cam or destination cam, zooms the lens to the license plate for sufficient detail to determine if a vehicle has an expiration mark from the image obtained alone. In one embodiment, the image may alternatively be captured by a hand-held or portable camera, for example, a cellular phone camera or a mobile device 150. An identification image obtained from these sources usually carries sufficient detail to determine that the vehicle is marked Expiration of profile picture alone. In one embodiment, instead of using the image alone to determine the presence of an expiration mark, the server system 140 can be configured to query, through a municipality database API, whether a vehicle registration for a specific vehicle number plate has expired. The server system 140 can be configured to report the vehicle to the municipality in 10 cases if it is determined to carry the expiration mark.

Server System 140 can be configured to provide a vehicle number plate processing logic component that transforms a specified destination use violation, eg an offense identified by the parking violation pre-processing logic component, into an executable component for the registered owner (RO)/participating vehicle user 15 In violation of the use of the destination, or the operator of the car park responsible for the destination. For example, the actionable element may take

The form of an automatic parking violation notice to the registered owner, or the vehicle plate number displayed on a screen at the car park operation office. A vehicle number plate processing logic software component interacts with a parking violation preprocessing logic software component, a service program that supplies system definitions, and a 141 database. The vehicle number plate processing logic component can be configured to verify one or more 20 or more business rules defined by Program services that provide system definitions connected to a destination to select the appropriate executable. For example, if the business rule stipulates the search for the vehicle number plate, a specific type of vehicle number plate search can also be specified, such as the API provided by the municipality, or the API provided by a private business. The vehicle number plate search is carried out as stipulated in the rule. Also, business rules can specify secondary options such as mailing parking violations to the registered owner through the API, or just providing the registered owner's address and any other information relevant to the violation to

Car parking operator. In another example, if the business rules state that the license plate information is to be sent, if it specifically states that the license plate processing logic component checks to see a specific type of the license plate information to be sent, the license plate information is sent accordingly.

<p dir="rtl">5 And in order to use the API search option for a vehicle number plate in order to locate an address</p>

Sent to the registered owner from the vehicle identifier using the license plate vehicle identifier, a database of vehicle number plates, such as those supplied by a private business, must be present and available for vehicle number plate searches belonging to a specific state/province. Also, the use of this database should make sense in terms of the fees charged

<p dir="rtl">10 So that the research process is commercially viable. In the event that neither of the above-mentioned circumstances is met, an alternative option could include providing the vehicle number plate to the municipal authority, which is usually able to access vehicle number plate records through the local police branch or the like.</p>

A logical software component for handling vehicle number plate data can include searching for

<p dir="rtl">15th Vehicle number plate and follow-up secondary module. The secondary module can be configured to follow an API connection with the license plate database to retrieve the dispatch address of the registered owner of the vehicle. Examples of this database include an HTTP-based phone API search account provided by the New York State Department of Motor Vehicles, database services provided by<a href="http://www.aamva.org/"> American Association of Mobile Transportation Managers</a> American Association of</p>

<p dir="rtl">20 (AAMVA Motor Vehicle Administrators) or other insurance companies, and online collections of public records, eg, PublicData.com (but these collections are considered less reliable than commercial or government databases, so they require extra effort to ensure that the information is accurate and reliable (.</p>

Also, the vehicle number plate search mechanism and the secondary unit can be configured for follow-up

<p dir="rtl">25 The infringement notice is automatically mailed to the registered owner of the vehicle that misused the place of destination. For example, the process of sending mail can be automated through</p>

Make contact with the API to get it to print/send a service, including but not limited to, -L

.Mail.com

In one embodiment, the vehicle number plate lookup mechanism and the secondary unit can be configured to continue to form, maintain and review records in the database to determine if the vehicle identifier in question (such as the vehicle number plate) is associated with a previous misuse of the destination within a specified time period (configurable through, for example, service programs that supply system definitions), and if the identifier is linked to past abuse, the vehicle number plate lookup mechanism and secondary tracking module can assume that the address The previously obtained 10 remains true and accurate, communication with the API is skipped, and the notes are sent by mail to the previously obtained 10 dispatched address in the system in order to reduce the costs associated with communication

with API. In the case where the parking violation is not paid after a specified number of days (the actual duration can also be determined by, for example, service programs that supply system definitions) the violation note is returned as an undelivered message, and an API call can be made suffix to get the current address.

<p dir="rtl">15th In one embodiment, in the event of a parking violation, including but not limited to, when you terminate</p>

If the paid parking is valid or the vehicle has lined up without being paid, Server 140 can be set up to inform enforcement officers of the location of the destination, eg latitude and longitude or the address of the nearest street. Then the enforcement officer can go to the violating vehicle and issue a violation note against it at the site. In one embodiment, the Server 140 system can be configured to identify and/or locate 20 single enforcement officers that are most appropriate to deal with the offending vehicle. Factors influencing this determination include, for example, the distance of the offending vehicle or the workload of a sentencing officer, or whether the offending vehicle must be towed (for example, in the case where the offending vehicle must be removed from the back). , it may be necessary to add the offending vehicle to a waiting list, for example, since the number of enforcement officers is very few or one of the

<p dir="rtl">25 Officers have multiple offending vehicles to deal with. In one embodiment, a number of enforcement officers may be notified near the offending vehicle, and one of the officers accepts handling of the offending vehicles.</p>

specific. Server System 140 can be configured to track the performance of a sentencing officer, and can be used in conjunction with the sentencing officer's reward or quota system. In one embodiment, the enforcement officer can be equipped with a mobile device 150, whereby the mobile device 150 can be configured to pre-print the violation note to the violating vehicle to reduce the time it takes to deliver the note

5 to the vehicle.

The 140 server system can be configured to provide dynamic variable rate parking fees. In one embodiment, the server system can record 140 different parking fares for a destination that vary by times of day/or days of the week, for example. In the case in which the vehicle occupies a destination place for a period to which the first and second tariffs apply, the server system can be configured to determine the total fees resulting from the use of the destination based on the first tariff that it operates from from the beginning of the use of the destination to the beginning of the period in which work begins on it with the tariff The second, and the second tariff shall be applied to the remainder of the time period during which the vehicle operates at the destination. In one embodiment, the 140 server system can be configured to limit the number of vehicles that are available for destination locations in a given area,

<p dir="rtl">15th The parking fee or tariff depends on the number of vehicles specified. For example, if the 140 server system specifies that this number of parking lots is reduced (eg, because there are fewer destinations left), a higher tariff can be charged at which it operates in the few remaining locations.</p>

The Server 140 system can be configured to allow the parking provider, through an API or tariff-providing service programs, to identify specific instances in which a specific parking fee or 20 flat fee is applied to specific destination locations. For example, if a concert is held from 7 p.m. to 11 p.m. at a location near or connected to a parking facility, the parking facility may charge a flat fee of $10 for vehicles that park after 4 p.m. Today.

The 140 server system can be configured to provide parking feature free of charge, where the driver can

<p dir="rtl">25 He leaves the parked vehicle at the destination as much as he likes, and the bill is paid through a credit card or other account according to the rules set for the destination (including but not limited to, </p>

per hour or a flat rate of charge per day). In one embodiment, a message or e-mail may be sent to the driver indicating that a no-fine feature is in place, for example a reply with the word “yes” or “no fine.” In In one embodiment, Server System 140 can generally be configured to make the null feature available to all non-restricted destinations in specific regions or within locations

<p dir="rtl">5 destination tracked by the server system 140. However, the server system 140 can be configured so that it does not provide the null feature of a prohibited destination, for example, a destination subject to the busy hour traffic jam law from 3 pm to 6 pm .</p>

In one embodiment, the 140 server system may be able to implement a dependent classification

<p dir="rtl">10 On a 3D outline of the vehicle. For example, this classification could roughly categorize the vehicle into categories such as, but not limited to, an SUV (sport utility vehicle), van, sedan, coupe, or d. In addition, the vehicle may be categorized by color as dark or light.The classification of vehicles may be useful for applications other than parking including, but not limited to</p>

<p dir="rtl">15th inventory, assisting police in tracking stolen vehicles within a given perimeter, or Amber alert, national security needs. In one embodiment, vehicle classification can be used to provide additional vehicle characteristics for comparisons performed to track vehicles from Camry In one embodiment, the vehicle classification can provide an additional layer of vehicle identity confirmation for a parking violation notice.</p>

<p dir="rtl">20 automated. In one embodiment, a manual 3D vehicle profile is provided to the valet system 140. For example, a manual 3D vehicle profile can describe a Chevrolet Impala by a ratio of 1:2:1 hood height:cabin height Passengers: The height of the trunk.</p>

In one embodiment, a laser transmitter may be configured, which may be compactly combined with a mirror

<p dir="rtl">25 An actuated beam-deflecting mirror, in which a laser beam is directed at one of the intended locations. In one embodiment, the laser beam may be projected onto a back reflector</p>

A retroreflector is mounted on or around the intended location to provide a return signal to a receiver associated with a laser transceiver. When a vehicle occupies a destination space illuminated by the laser beam, the presence of the vehicles is determined by the laser beam interruption or return signal. In response to this determination, the 140 server system can be configured to obtain an image of the location

<p dir="rtl">5 The intended identifier image and/or identifier image captured by a nearby camera.</p>

In one embodiment, the Server 140 system can also be configured to, in addition to previous uses involving vehicle identification, also use an identification camera such as a "red light camera" to detect instances where the vehicle continues to erroneously advance at an intersection It is regulated by a traffic light. For example, when a traffic light 10 changes from red or amber, it is possible to identify the vehicles that are wrongly continuing their lead during the last phases of the red light period, as well as take a picture of the vehicle number plate, where the server system 140 is configured to use A camera that shoots for both purposes at the same time. Alternatively or in addition to this, the Server 140 system can be configured to use the identification cam to identify a "close-the-box" traffic violation, in which the vehicle remains at the intersection during the signal period.

<p dir="rtl">15th red flags for vehicles in the direction the vehicle is moving, which may lead to traffic jams</p>

high.

In one embodiment, the Server 140 system can be configured to provide real-time vehicle tracking services to third parties including, but not limited to, repossession companies (to locate vehicles with unpaid premiums), law enforcement, and national security purposes.

<p dir="rtl">20 Server system 140 API through which third party authorities can register the vehicles concerned by, for example, a vehicle identifier such as a vehicle number plate. In the event that the server system 140 identifies a vehicle with a vehicle identifier, the registration party can be notified. Notifications may be provided in conjunction with the initial vehicle identification and/or when the vehicle has been parked. In one embodiment, records of vehicle movements recorded by the server system may be maintained, made available,</p>

<p dir="rtl">25 For example, via a map-based web interface, it can be configured to provide up-to-date information in real time. The API can also allow a third party to specify</p>

A specific area, where the server system 140 is configured to perform identification and tracking of any vehicle whose entry into the relevant area is limited. The Server 140 system can also be configured to provide images of registered vehicles that are acquired by a tracking cam. In one embodiment, any archived tracking information could be made available, eg previous use of destinations, reconfiguration of a place of residence

<p dir="rtl">5 Person over time (assuming the person is related to the vehicle). In one embodiment, the Server 140 system can be configured to obtain images of the vehicle including an image of the driver's face, and can also be configured to implement facial recognition technologies to confirm the driver's facial features corresponding to the person in question.</p>

In one embodiment, the Server 140 system can be configured to identify and supply traffic census information, such as the number of vehicles assigned to vehicles that crossed a particular section of the road. 10 This information may be used for purposes including, but not limited to, dynamic control of traffic systems such as traffic lights in response to currently observed traffic statistics, and to determine structural requirements based on traffic statistics observed over a period of time. Traffic statistics information may include and/or disaggregate by time and/or date, and/or specific vehicle characteristics, including, but not limited to,

<p dir="rtl">15th The direction of travel and the size and type of the vehicle (eg, SUV, truck, car, motorcycle). Additionally, Server 140 can determine vehicle statistics relating to the direction of entry and/or exit of a portion of the road, eg the number of vehicles traveling north or south at Exit from an eastern section of the road, depending on the direction of each vehicle leaving the intersection.In one embodiment, the valet 140 system can be configured to be used to control access to and/or charge vehicles by type, eg assessment</p>

<p dir="rtl">20 Fees for the use of specific routes by large trucks.</p>

Figure 5 shows a framework diagram illustrating the 500 Computer system through which aspects of the invention can be implemented. The 500 computer system includes a 502 bus or other communication mechanism to transmit information, and a 504 processor coupled to the 502 to process the information. The computer system includes 500 main memory, 506 main memory

<p dir="rtl">25 For example, a random access memory (RAM) or other dynamic storage device, coupled to the 502 bus to store information and instructions to be executed by the 504 processor. It can also be </p>

Use the 506 main memory to store temporary variables or intermediate information during the execution of instructions that the 504 processor will execute. A 510 storage device, for example a magnetic disk or optical disk, is provided and coupled to the 502 bus to store information and instructions.

And the 500 computer system can be paired through the bus 502 with a 512 display

<p dir="rtl">5 For example, a cathode ray tube (CRT) or liquid crystal LCD (LCD display) is used to display information to a computer user. The input device 514, which includes an alphanumeric keyboard and other switches, is coupled to the 502 bus to transmit selected information and commands. to the 504 processor. Another example of a user input device is a 516 cursor control, eg mouse, trackball,</p>

<p dir="rtl">10 or cursor direction keys to transmit direction information and command choices to the 504 processor and to control the movement of the cursor on the 512 display. This input device usually has two degrees of freedom in two axes, a first axis (for example, the x axis) and a second axis (for example, the x axis) y), allows the device to locate positions in a plane. Another type of input device for the user is a touch screen, which typically includes a 512 display and equipment that records</p>

15th Touch that occurs on the 512 display.

The invention relates to the use of one or more computer systems, eg Computer System 500, that are collectively formed and/or programmed to implement the techniques described herein. According to one embodiment, these technologies are implemented by a computer system 500 in response to a 504 processor that executes one or more series of instructions in 506 main memory. These instructions can be read in memory

<p dir="rtl">20 main 506 from a machine-readable medium, such as the 510 storage device. Executing the instruction chain in the 506 main memory prompts the 504 processor to perform the process steps described here. In alternative embodiments, a hard-wired circuitry may be used in place of or with the code to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware and software.</p>

<p dir="rtl">25 And the term “machine-readable medium” as used here means any medium that can contribute to data</p>

Induces the machine to operate in a specific manner. And in one embodiment it is implemented using the system

The 500 computer, the machine-readable media participates in, for example, providing instructions to the 504 processor for execution. This medium can be, but is not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, for example

<p dir="rtl">5 510 storage device. Volatile media include dynamic . memory</p>

memory, such as 506 main memory. Transmission media include coaxial cables, copper wire and fiber optics, including wires comprising the 502 carrier. Transmission media can also take the form of sound or light waves, such as those generated during data transmission. ultrasonic data communications

<p dir="rtl">10 Wireless radio-wave and infra-red data transmission. All of these media must be tangible and/or nontransistory so that the instructions carried by the media can be identified by a physical mechanism that reads the instructions into the machine.</p>

Common forms of machine-readable media include, for example, soft disk

<p dir="rtl">15th floppy disk, flexible disk, hard disk, magnetic tape, or other magnetic medium, CD-ROM, any optical media, punchcards, papertape, and any other format of the physical medium contains a pattern of holes, random access memory, programmable read-only memory</p>

Electrically ErasableProgrammable Read 20 PROM

EPROM (Only Memory), flash-only programmable read-only memory

FLASH-EPROM (Flash ErasableProgrammable Read-Only Memory), any other memory chip or cartridge, carrier wave as described here, or any other media from which a computer can read.

<p dir="rtl">25 Various formats of machine-readable media can be included in one or more loads</p>

Contexts for one or more instructions to the 504 processor to execute. For example, it can

The instructions are initially downloaded to a magnetic disk from a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over the telephone line using a modem. A local modem for a computer system 500 can receive data over a telephone line and use an infra-red transmitter to convert the data into an infrared signal.

<p dir="rtl">5 infra-red signal. An infrared detector can receive the data carried in the infrared signal and an appropriate circuit can put the data on the 502 bus. The 502 bus carries the data to the 506 main memory, from which the 504 processor retrieves and executes instructions. Optionally, the instructions received by the 506 main memory can be stored on the 510 storage device either before or after they are executed by the 504 processor.</p>

10 The 5000 computer system also includes a 518 communication interface

Coupled with bus 502. The 518 interface provides two-way data communication to the 520 LAN link. For example, the 518 interface can integrate with an integrated services ISDN digital network card. or a modem to provide a link to transmit information to a corresponding type of telephone line.

<p dir="rtl">15th As another example, the communication interface 518 can be a card LAN (local area network) to provide a data transmission link to the appropriate LAN. Wireless links can be used. In any such application, the communication interface 518 sends and receives electrical signals Electromagnetic, or optical, carries digital data streams representing different types of data.</p>

<p dir="rtl">20 A 520 connection typically provides the transmission of data through one or more networks to services</p>

Other data. For example, a connection link 520 provides links through a 522 LAN with a 524 host computer or data equipment operated by a 526 Internet Service Provider (ISP). The 526 ISP, in turn, provides data transmission services through a packet transport network. Data around the world that is now commonly referred to as the “Internet.”

<p dir="rtl">25 528 "Internet. The LAN 522 and the Internet 528 use electrical signal carriers,</p>

Electromagnetic or photovoltaic works to carry digital data streams. The signals are considered over the networks

The various signals and signals in the communication link 520 and through the communication interface 218, which carry data to and from the computer 500, are analogous forms of the carrier wave that transmits information.

A computer system can send 500 messages and receive data, including program code, through the network(s), link the 520 and the 518 interface.

<p dir="rtl">5 The example related to the Internet, the raw 530 server can send the required code for an application program through the Internet 528, ISP 526, LAN 522 and interface 518,</p>

Received code can be executed by the 204 processor as received, and/or stored in a 510 storage device, or other non-volatile storage medium for later execution. In this way, the PC 500 can obtain application code in the form of a carrier.

<p dir="rtl">10 In the foregoing description, embodiments of the invention are described with reference to several specific details</p>

It can vary from one application to another. Thus, the sole and exclusive indication of the nature of the invention, and the form of the invention intended by the applicant, is identified in the claims resulting from the current application, in the specific form in which the claims resulted, including a subsequent correction to them. Any definitions expressly stated herein of the terms in these Claims shall be deemed to be

<p dir="rtl">15th Govern the meaning of these terms as used in the Claims. Therefore, the scope of these claims is not limited by any limitations, elements, features, advantages or characteristics expressly stated in a claim in any way. Both the description and the graphics, accordingly, are illustrative and not considered prescriptive.</p>