US20140249896A1 - Controlling Use of Parking Spaces Using a Camera - Google Patents
Controlling Use of Parking Spaces Using a Camera Download PDFInfo
- Publication number
- US20140249896A1 US20140249896A1 US14/279,272 US201414279272A US2014249896A1 US 20140249896 A1 US20140249896 A1 US 20140249896A1 US 201414279272 A US201414279272 A US 201414279272A US 2014249896 A1 US2014249896 A1 US 2014249896A1
- Authority
- US
- United States
- Prior art keywords
- vehicle
- parking
- destination location
- characteristic
- images
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000003068 static effect Effects 0.000 claims abstract description 67
- 230000004044 response Effects 0.000 claims abstract description 25
- 238000000034 method Methods 0.000 claims description 71
- 238000003860 storage Methods 0.000 claims description 12
- 230000000007 visual effect Effects 0.000 claims description 9
- 230000008859 change Effects 0.000 claims description 5
- 230000003993 interaction Effects 0.000 claims description 3
- 230000014759 maintenance of location Effects 0.000 claims description 3
- 238000004590 computer program Methods 0.000 claims 2
- 230000010354 integration Effects 0.000 description 73
- 238000012545 processing Methods 0.000 description 52
- 238000004891 communication Methods 0.000 description 42
- 238000001514 detection method Methods 0.000 description 25
- 230000007246 mechanism Effects 0.000 description 21
- 230000000875 corresponding effect Effects 0.000 description 20
- 238000007781 pre-processing Methods 0.000 description 15
- 230000008569 process Effects 0.000 description 14
- 238000012552 review Methods 0.000 description 14
- 238000013459 approach Methods 0.000 description 13
- 238000013519 translation Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 12
- 230000008901 benefit Effects 0.000 description 11
- 238000012790 confirmation Methods 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 10
- 230000001413 cellular effect Effects 0.000 description 9
- 230000033001 locomotion Effects 0.000 description 8
- 230000000737 periodic effect Effects 0.000 description 8
- 239000003086 colorant Substances 0.000 description 7
- 238000012015 optical character recognition Methods 0.000 description 7
- 230000006855 networking Effects 0.000 description 6
- 230000009471 action Effects 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 5
- 230000001360 synchronised effect Effects 0.000 description 5
- 238000010200 validation analysis Methods 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 230000002829 reductive effect Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000001276 controlling effect Effects 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 238000005286 illumination Methods 0.000 description 3
- 238000009434 installation Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000000717 retained effect Effects 0.000 description 3
- 238000010561 standard procedure Methods 0.000 description 3
- 244000025254 Cannabis sativa Species 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 230000003466 anti-cipated effect Effects 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000001815 facial effect Effects 0.000 description 2
- 238000003384 imaging method Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 239000003973 paint Substances 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000001931 thermography Methods 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 241000282813 Aepyceros melampus Species 0.000 description 1
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 235000004522 Pentaglottis sempervirens Nutrition 0.000 description 1
- 239000010426 asphalt Substances 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000007727 cost benefit analysis Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000003708 edge detection Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000003760 hair shine Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000011900 installation process Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000010408 sweeping Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
- G08G1/017—Detecting movement of traffic to be counted or controlled identifying vehicles
- G08G1/0175—Detecting movement of traffic to be counted or controlled identifying vehicles by photographing vehicles, e.g. when violating traffic rules
-
- G06T7/0042—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F18/00—Pattern recognition
- G06F18/20—Analysing
- G06F18/22—Matching criteria, e.g. proximity measures
-
- G06K9/00771—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
- G06Q20/145—Payments according to the detected use or quantity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0283—Price estimation or determination
- G06Q30/0284—Time or distance, e.g. usage of parking meters or taximeters
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/26—Government or public services
- G06Q50/265—Personal security, identity or safety
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/40—Business processes related to the transportation industry
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T7/00—Image analysis
- G06T7/20—Analysis of motion
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T7/00—Image analysis
- G06T7/20—Analysis of motion
- G06T7/292—Multi-camera tracking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T7/00—Image analysis
- G06T7/70—Determining position or orientation of objects or cameras
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T7/00—Image analysis
- G06T7/70—Determining position or orientation of objects or cameras
- G06T7/73—Determining position or orientation of objects or cameras using feature-based methods
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T7/00—Image analysis
- G06T7/90—Determination of colour characteristics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V20/00—Scenes; Scene-specific elements
- G06V20/50—Context or environment of the image
- G06V20/52—Surveillance or monitoring of activities, e.g. for recognising suspicious objects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V20/00—Scenes; Scene-specific elements
- G06V20/50—Context or environment of the image
- G06V20/52—Surveillance or monitoring of activities, e.g. for recognising suspicious objects
- G06V20/54—Surveillance or monitoring of activities, e.g. for recognising suspicious objects of traffic, e.g. cars on the road, trains or boats
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V20/00—Scenes; Scene-specific elements
- G06V20/50—Context or environment of the image
- G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V20/00—Scenes; Scene-specific elements
- G06V20/50—Context or environment of the image
- G06V20/59—Context or environment of the image inside of a vehicle, e.g. relating to seat occupancy, driver state or inner lighting conditions
- G06V20/593—Recognising seat occupancy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V20/00—Scenes; Scene-specific elements
- G06V20/60—Type of objects
- G06V20/62—Text, e.g. of license plates, overlay texts or captions on TV images
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V30/00—Character recognition; Recognising digital ink; Document-oriented image-based pattern recognition
- G06V30/10—Character recognition
- G06V30/22—Character recognition characterised by the type of writing
- G06V30/224—Character recognition characterised by the type of writing of printed characters having additional code marks or containing code marks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V40/00—Recognition of biometric, human-related or animal-related patterns in image or video data
- G06V40/20—Movements or behaviour, e.g. gesture recognition
- G06V40/23—Recognition of whole body movements, e.g. for sport training
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
- G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
- G08G1/017—Detecting movement of traffic to be counted or controlled identifying vehicles
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
- G08G1/052—Detecting movement of traffic to be counted or controlled with provision for determining speed or overspeed
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
- G08G1/056—Detecting movement of traffic to be counted or controlled with provision for distinguishing direction of travel
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
- G08G1/133—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams within the vehicle ; Indicators inside the vehicles or at stops
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
- G08G1/141—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces
- G08G1/142—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces external to the vehicles
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
- G08G1/141—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces
- G08G1/143—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces inside the vehicles
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
- G08G1/141—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces
- G08G1/144—Traffic control systems for road vehicles indicating individual free spaces in parking areas with means giving the indication of available parking spaces on portable or mobile units, e.g. personal digital assistant [PDA]
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
- G08G1/145—Traffic control systems for road vehicles indicating individual free spaces in parking areas where the indication depends on the parking areas
- G08G1/148—Management of a network of parking areas
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
- H04N23/60—Control of cameras or camera modules
- H04N23/62—Control of parameters via user interfaces
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
- H04N23/60—Control of cameras or camera modules
- H04N23/66—Remote control of cameras or camera parts, e.g. by remote control devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
- H04N23/90—Arrangement of cameras or camera modules, e.g. multiple cameras in TV studios or sports stadiums
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast
- H04N7/181—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast for receiving images from a plurality of remote sources
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60Q—ARRANGEMENT OF SIGNALLING OR LIGHTING DEVICES, THE MOUNTING OR SUPPORTING THEREOF OR CIRCUITS THEREFOR, FOR VEHICLES IN GENERAL
- B60Q1/00—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor
- B60Q1/02—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments
- B60Q1/04—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments the devices being headlights
- B60Q1/0483—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments the devices being headlights mounted on a bracket, e.g. details concerning the mouting of the lamps on the vehicle body
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T2207/00—Indexing scheme for image analysis or image enhancement
- G06T2207/10—Image acquisition modality
- G06T2207/10004—Still image; Photographic image
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T2207/00—Indexing scheme for image analysis or image enhancement
- G06T2207/30—Subject of image; Context of image processing
- G06T2207/30236—Traffic on road, railway or crossing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T2207/00—Indexing scheme for image analysis or image enhancement
- G06T2207/30—Subject of image; Context of image processing
- G06T2207/30248—Vehicle exterior or interior
- G06T2207/30252—Vehicle exterior; Vicinity of vehicle
- G06T2207/30264—Parking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
- G06V20/00—Scenes; Scene-specific elements
- G06V20/60—Type of objects
- G06V20/62—Text, e.g. of license plates, overlay texts or captions on TV images
- G06V20/625—License plates
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/24—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for parking meters
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/01—Detecting movement of traffic to be counted or controlled
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/14—Traffic control systems for road vehicles indicating individual free spaces in parking areas
- G08G1/145—Traffic control systems for road vehicles indicating individual free spaces in parking areas where the indication depends on the parking areas
- G08G1/146—Traffic control systems for road vehicles indicating individual free spaces in parking areas where the indication depends on the parking areas where the parking area is a limited parking space, e.g. parking garage, restricted space
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
- H04N23/60—Control of cameras or camera modules
- H04N23/69—Control of means for changing angle of the field of view, e.g. optical zoom objectives or electronic zooming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
- H04N23/80—Camera processing pipelines; Components thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast
Definitions
- This invention relates to the use of cameras to identify vehicles and track and control the use of parking spaces by the vehicles.
- a method of tracking the use of at least one destination location comprising: receiving a plurality of vehicle images captured by a plurality of cameras, wherein each vehicle image includes an image of a first vehicle, the plurality of cameras includes a first identification camera, the plurality of cameras includes a destination camera, the vehicle images include one or more first identification images captured by the first identification camera, a plurality 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 the second time; determining a first unique identifier for the first vehicle based on the first identification images; determining a first plurality of characteristics for the first vehicle based on the first identification images; determining a second plurality of characteristics for a vehicle based on one or more of the destination images; determining that the second plurality of characteristics correspond to the first plurality of characteristics; determining that an image of the first vehicle is included in the plurality of destination
- Various benefits obtained by the disclosed subject matter include, but are not limited to: (1) offering hands-off self-enforcement for parking citations; (2) offering hands-off self-enforcement for parking citations that integrates with existing “in-place” parking payment infrastructure; (3) a smaller number of sensors, and associated reduction in installation costs, in comparison to techniques relying on proximity sensors that identify the presence of only one or very few vehicles—a factor which can prove significant for the management of parking spaces in large open areas, such as parking lots; (4) leveraging commercial off-the-shelf (COTS) technologies, and associated reduction in equipment costs, for vehicle detection and parking enforcement; (5) improvements in software-based vehicle detection techniques can be quickly updated throughout the system, particularly in an embodiment where image processing is performed remote from the cameras, and realizing improvements in vehicle detection without hardware changes throughout a parking management system; (6) the ability to rapidly make changes in system behavior system-wide, or in connection with a more narrowly defined subset of parking spaces.
- COTS commercial off-the-shelf
- FIG. 1 illustrates an example of an overall system 100 according to the disclosed subject matter.
- FIGS. 2A and 2B illustrate examples of images captured by identification cameras.
- FIGS. 3A and 3B illustrate examples of images captured by destination cameras.
- FIG. 4 illustrates how images captured by cameras with overlapping fields of view may be used to identify a vehicle, track the movement of the vehicle to a destination location, and identify use of the destination location by the vehicle.
- FIG. 5 is a block diagram that illustrates a computer system 500 upon which aspects of the invention may be implemented
- FIGS. 6A and 6B illustrate aspects of a graphical user interface (GUI) for specifying characteristics of a camera's field of view.
- GUI graphical user interface
- FIG. 6A illustrates a portion of the GUI in which an image from a first camera is displayed.
- FIG. 6B illustrates a portion of the GUI in which an image from a second camera is displayed.
- FIG. 1 illustrates an example of an overall system 100 according to the disclosed subject matter.
- Network 110 provides data communication services among the elements illustrated in FIG. 1 .
- networking technologies including, but not limited to, Ethernet, 802.11 wireless, and cellular data networking technologies, which those skilled in the art can reliably and predictably integrate for the exchange of data among the illustrated elements.
- separate networks may be used.
- cameras 120 and 125 and server 140 may communicate via a first network, whereas the other elements communicate via the public Internet.
- an independent first network those skilled in the art may realize desired goals for reliability and security.
- Identification camera 120 illustrates one of a plurality of such cameras included in system 100 . For the convenience of discussion, only a single Identification camera 120 is illustrated in FIG. 1 .
- Identification camera 120 is positioned such that it may capture images of vehicle identifiers, such as, but not limited to, an automobile license plate or a label affixed to a vehicle that provides a vehicle identifier in a format such as, but not limited to, a QR code or a bar code.
- Images captured by Identification camera 120 such as image 121 , are used in conjunction with images captured by one or more destination cameras 125 in order to identify individual vehicles, such as vehicle 130 , and record their usage of various destination locations.
- Examples of destination locations for wheeled motor vehicles include areas designated as appropriate for parking, although possibly subject to various restrictions, such as, but not limited to, parking spots, and areas designated as inappropriate for parking, such as, but not limited to, bus stops, fire lanes, areas around fire hydrants, sidewalks, areas within X feet of an intersection, driveways, islands, medians, bicycle lanes, pedestrian crossings.
- server system 140 may be configured to determine when a vehicle is parked at a bus stop, and request or take action upon that determination, such as requesting the vehicle be towed or issue a citation by mail.
- an Identification camera may also include a mobile or handheld camera, including, for example, a camera included in a smartphone.
- Destination camera 125 illustrates one of a plurality of such cameras included in system 100 . For the convenience of discussion, only a single destination camera 125 is illustrated in FIG. 1 . Destination camera 125 is positioned such that it may capture images of one or more destination locations, such as, but not limited to, automobile parking spots. Typically, destination camera 125 will be mounted at an elevation, such as, but not limited to, on a lighting or telephone pole, or on the façade or top of a building. By mounting destination camera 125 at an elevation, the field of view of images, such as image 126 , captured by destination camera 125 can include, and therefore be used to monitor, multiple destination locations.
- a destination camera may also include a mobile or handheld camera, including, for example, a camera included in a smartphone.
- a destination camera may be included in a parking meter body.
- a destination camera may be provided by a space satellite imaging camera, potentially obviating a need for destination cameras installed throughout a municipality.
- a destination camera may be included in an air vehicle, such as, but not limited to, a blimp or other airship, or an unmanned air vehicle, and may be autonomously operated for extended periods of flight.
- Identification camera 120 and destination camera 125 may be configured to each directly communicate with network 110 via respective communication links 127 and 128 .
- Identification camera 120 may be configured to communicate directly with, and relay data through, destination camera 125 , such that rather than Identification camera 120 being configured to communicate directly with network 110 via communication link 127 , it communicates with destination camera 125 via communication link 129 , and destination camera 125 communicates with network 110 via communication link 128 , such that destination camera 125 serves to relay data to and from identification camera 120 .
- Communication link 129 may be a wireless networking link.
- FIG. 1 illustrates an example with a communication link 129 between the two cameras 120 and 125 , this may be extended to data being sent from or to a given camera by relaying the data through multiple cameras.
- a wireless mesh network may be established among a plurality of cameras, providing a fault-tolerant and self-configuring wireless communication medium among the cameras.
- wireless communications instead of hardwired links, the number of hardwired communications links in the system as a whole, and expense and labor associated with installing and maintaining such hardwired links, can be reduced.
- this may serve as a useful alternative to using, for example, cellular data communications for conveying data to network 110 , as typically the cost of cellular data communications is significantly greater than via a hardwired link.
- wireless communication is not required, and some or all cameras may communicate via a hardwired link.
- Server system 140 comprises one or more computer systems which provide central data storage, data retrieval, and processing services.
- the computer systems included in server system 140 will generally each include a random access memory 142 and a processor 143 .
- Server system 140 includes database 141 , which is used to record information such as usage of destination locations, such as parking spaces, by vehicles; vehicle account information; identifications of vehicles obtained via identification camera images; observations of vehicles obtained via destination camera images; destination reservation information; billing information; and payment information.
- Database 141 may be implemented, for example, using software programs such as MySQL, Oracle, or DBASE. Database 141 may comprise multiple database instances executing across multiple computer systems.
- server system 140 is configured to perform vehicle and vehicle identification recognition from images captured by identification cameras, such as identification camera 120 , and destination cameras, such as destination camera 125 . Further server 140 is configured to perform decision making based on the recognized information, such as determining the usage of destination locations, and when the usage of a destination location is in violation of use restrictions for the destination location.
- This embodiment in which image processing and decision making are centralized in server system 140 , exploits Moore's Law, in which the number of transistors in a microprocessor, and a corresponding amount of data processing capability, doubles every 18 months, and Nielsen's Law, which hypothesizes that bandwidth speeds grow by 50% per year. Significant benefits can be realized by this centralized approach.
- identification camera 120 may be configured to identify the presence of vehicle identification information, such as license plate numbers, in captured images.
- vehicle identification information such as license plate numbers
- the amount of data communication bandwidth between identification camera 120 and server system 140 , and the amount of processing which must be performed by server system 140 may be significantly reduced, with a tradeoff in that identification camera 120 needs to be a more sophisticated device capable of performing image processing functions capable of, for example, identifying the presence of vehicles in images, identifying the presence of vehicle identification information in images, and/or extracting vehicle identification information from images.
- the identification and destination cameras can be programmed to determine characteristics of vehicle images, as detailed below in connection with FIG. 4 , rather than perform such determinations using server system 140 .
- Mobile device 150 comprises a programmable computer, an identification camera, and wireless data communication capability for communicating with server system 140 .
- mobile device 150 could be dispatched to the destination location, and an image 151 of vehicle 130 captured, from which a unique identification for vehicle 130 could be obtained.
- mobile device 150 can also be configured to capture a vehicle VIN identifier tag, which may be helpful for vehicles lacking license plates.
- mobile device 150 may also be configured to provide features useful for parking enforcement. For example, mobile device 150 may be configured to print out a paper citation for parking violations identified by server system 140 .
- Onsite payment system 160 is one of a plurality of devices which offers a direct physical interface, generally located near one or more destination locations, for an end user to submit a payment or an agreement to pay for the use of a destination location.
- Examples of payment system 160 include, but are not limited to, a parking meter dedicated to an individual destination location, a payment station associated with several street parking spaces, and a payment station for destination locations provided in a parking lot or garage.
- onsite payment system 160 may include a destination camera which captures images for one or more destination locations.
- End user system 170 is a programmable computer system by which an end user, such as a driver of vehicle 130 , may interact with server system 140 .
- Examples of such systems include, but are not limited to, a desktop computer system with a web browser application, a smartphone with a web browser application or dedicated parking application, and an in-vehicle system included in vehicle 130 .
- End user system 170 may be used, for example, to create an end user account for repeated interactions with server system 140 , reserve use of destination locations, request identification of an available destination location, and submit payment information for the use of a destination location.
- end user system 170 may be configured to request and obtain information from server system 140 describing available destination locations for a given area.
- end user system 170 may further be configured to obtain and/or request particular criteria for acceptable destination locations, such as destination locations which are in a parking garage or not on-street parking (such as a parking lot).
- location information such as, but not limited to, cost of use for a given destination location may be obtained by end user system 170 .
- End user system 170 may be further configured to request and obtain information for currently available destination locations and/or destination locations available at a specified point or range of time in the future.
- End user system may be further configured to provide a graphical user interface to the end user showing specific locations, such as on a map, of one or more of the available destination locations obtained from server system 140 .
- end user system 170 may be configured to broadly indicate the availability, possibly indicating a number of available destination locations) of a destination location at the parking facility, rather than individually identifying each destination location.
- End user system 170 may be configured to receive an indication of a selected destination location from the end user.
- End user system 170 may be further configured to provide guidance, such as turn-by-turn directions, to the selected destination location.
- End user system 170 may be further configured to instruct server system 140 to reserve use of an available destination location.
- Manual review system 180 is a programmed computer system by which a human operator 181 provides assistance to server system 140 for identifying vehicles, such as vehicle 130 .
- server system 140 may determine that an error has occurred in performing an automated machine-based determination of a unique identifier for vehicle 130 from images, such as image 121 , captured by identification camera 120 .
- server system 140 may request assistance from human operator 181 to determine a unique identifier, such as a license plate number, for vehicle 130 .
- Manual review system 180 provides a user interface by which human operator 181 may review image 121 , and perhaps other images captured by identification camera 120 or other cameras.
- human operator 181 can rewind the video footage manually and freeze-frame forward in order to manually determine the vehicle license plate number and state/province information. Via this interface, human operator 181 may provide an identification of vehicle 130 or indicate that human operator 181 was unable to determine an identification for vehicle 130 , which may result in mobile device 150 being dispatched to a destination location in order to make a positive identification of vehicle 130 . More than one manual review system 180 may be made available for use by server system 140 , depending on the volume of information processed by server system 140 . Additionally, human operator 181 may be a member of a Live Operator team, discussed in more detail below.
- one or more of the identification and destination cameras capture images at a higher frame rate and/or resolution than the images transmitted from the cameras to server system 140 .
- the image data captured by such cameras is transmitted to server system 140 , in the interest in conserving possibly expensive network communication bandwidth (for example, a cellular data network) and limited image processing resources available at server system 410 , such cameras can buffer a limited amount of the full image data that they capture, such as in a circular buffer.
- such cameras are configured to respond to requests for such additional image data, including, for example, portions of higher resolution images which may be useful for license plate recognition.
- server system 140 may automatically determine that additional images may be useful for identifying and tracking vehicles, or manual review system 180 may request various images in order to resolve an error raised by server system 140 .
- Parking operation system 190 is a programmed computer system by which a parking facility operator may interact with and control server system 140 .
- Server system 140 is expected to operate autonomously with little input required by a parking operator the majority of the time. However, occasionally there are instances when the parking facility operator personnel take an active part in its operation.
- parking operation system 190 may provide a live indication as to how many and which destination locations are being used and/or are available. As another example, parking operation system 190 may provide a live indication as to destination locations in which vehicles are violating usage restrictions, allowing parking facility operator personnel to take action for such violations as deemed necessary.
- FIG. 2A illustrates an example of an image 121 captured by identification camera 120 , where identification camera 120 is located so as to effectively capture identification information for vehicles passing by identification camera 120 .
- identification camera 120 streams video containing images of identification information, such as license plate information, to server system 140 .
- identification information such as license plate information
- typical streetlights are approximately 18 feet in height, they provide an excellent mounting location for identification cameras which benefit from a clear line of sight away from trees and other obstacles, including closely traveling vehicles.
- the identification camera may be installed so as to draw power from the streetlight.
- streetlight-mounted identification cameras can provide sufficient coverage for any vehicles traversing the street.
- Identification images captured by identification camera 120 are used for two primary purposes: (1) obtaining a unique identification of a vehicle, such as by reading an identifier from a license plate mounted on the front or rear of the vehicle; and (2) determining various characteristics of the vehicle, so that it may be determined that an image of a vehicle obtained by another camera corresponds to an identified vehicle, as discussed below in connection with FIG. 4 .
- a view of a vehicle and its license are available for processing by server system 140 .
- Multiple identification images may be used for determining vehicle characteristics such as speed and direction of travel.
- machine vision techniques for obtaining vehicle identifiers may be performed by identification camera 120 .
- the amount of data sent from identification camera 120 to server system 140 may be significantly reduced, as a vehicle identifier can be sent in place of identification images.
- one or more identification images may still be transmitted to server system 140 for storage and/or determination of vehicle characteristics by server system 140 (although in an embodiment, this may also be performed by identification camera 120 ).
- server system 140 may recognize it is only able to obtain a portion of a vehicle identifier, perhaps as a result of certain particular conditions, such as the angle of the vehicle or a closely following vehicle. In such a case, server system may further rely on a second identification image captured by a second identification camera to obtain the remaining portion of the identifier.
- FIG. 2B illustrates an example of an image 121 captured by identification camera 120 , where identification camera 120 is located so as to effectively capture identification information for vehicles entering and exiting an urban intersection via the roadway extending along the axis of view of identification camera 120 .
- this identification image views of three vehicles are effective for processing by server system 140 , such that unique identifiers may be obtained for all three vehicles from the single image.
- identification camera 120 may have pan, tilt, and/or zoom capability, which may be used for server system 140 to obtain a more detailed view of a vehicle, or may be used by parking facility operator personnel via a user interface on parking operation system 190 to monitor particular areas of interest viewable by identification camera 120 .
- server system 140 may be configured to perform a coordinate transformation in order to accurately determine vehicle characteristics while varying the field of view of identification camera 120 .
- server system 140 when a vehicle appears in the field of view of identification camera 120 , server system 140 performs one or more of six tasks. In the first task, server system 140 detects the presence of one or more vehicles based on one or more images captured by identification camera 120 . In an embodiment, server system 140 may be configured to detect the presence of a vehicle based on differences in color between the vehicle and the background, and a determination that a size of a total shape for a potential vehicle is larger than a specified minimal vehicle size adjusted for any applicable zoom level. Specifically, such an algorithm may compare colors of all the pixels in an image against each other. Pixels are divided into rows and columns (for example, an absolute location 21 , 34 may represent a pixel located on Row 21 and Column 34 ).
- the algorithm may be configured to detect groups of pixels with similar colors (a range of colors that be considered to be similar may be specified in a system configuration, such as that similar colors may be a maximum of 2 shades difference, with reference to shades indicated by a color chart). The locations of these pixels are then mathematically computed to determine whether they form a shape larger than the minimal vehicle size (for example, a relative size of 10 ⁇ 30 may represent a shape measuring 10 rows by 30 columns). Vehicles appearing in images captured by identification camera 120 tend to appear to be parallelograms rather than rectangular in shape due to the viewing angle. Therefore, the determination may take this factor into account.
- a further refinement could be made to accommodate “holes” or imperfections in a detected shape due to, for example, a reflection of the sun, a windshield area, or a roof rack.
- the algorithm may specify a number of shapes of a particular minimum size up to certain distance (or pixels) away from each other, which may correspond to portions of a vehicle such as a hood, roof, and trunk, which are typically of the same color.
- an entry is recorded in a portion of database 141 corresponding to identification camera 120 , along with information including, for example, a date, time, color of vehicle, size of vehicle, locations of pixels, and zoom level. This information may be used in conjunction with other detections of the vehicle to identity of the vehicle. Alternatively, such information may be temporarily recorded in volatile memory, such as RAM.
- server system 140 detects the presence of license plates and/or additional identification, such as, but not limited to, decals, on vehicles in images captured by identification camera 120 .
- license plate and/or additional identification Once a license plate and/or additional identification has been detected, an entry is recorded in a portion of database 141 corresponding to identification camera 120 , along with information including, for example, a date, time, license plate #, state/province, decal details (for example, a type, an identifier, and expiration), locations of pixels, and zoom level. This information may be used in conjunction with other detections of the vehicle to identify the vehicle in other images, such as images captured by a destination camera.
- server system 140 identifies vehicles that are moving versus vehicles which are stationary, based on multiple images captured by identification camera 120 .
- server system 140 identifies license plates and/or additional identifications that are moving versus license plates and/or additional identifications which are stationary, based on multiple images captured by identification camera 120 .
- server system 140 may be configured to: (1) based on license plates and/or additional identification information obtained, such as via OCR, from the current image, find corresponding matches in previous images (for example, by reviewing data stored in database 141 or memory); and (2) once such matches are found, compare the locations of pixels between the current image and previous images, taking into account any change in zoom level. Based on such processing, one or more of the following scenarios may be detected. (A) if locations of pixels are unchanged or have unchanged below a predetermined threshold, all license plates and/or additional identifications are deemed to have remained stationary.
- a simple update of the date and time is performed for existing entries in database 141 or memory for the vehicles.
- (B) if pixels associated with one or more license plates and/or additional identifications are at new locations, the one or more license plates and/or additional identifications are determined to have moved.
- Server system 140 may calculate speed and direction of travel for these vehicles and update database 141 or memory with this information, along with updated locations.
- (C) if one or more license plates and/or additional identifications have disappeared from the current image, server system 140 may be configured to remove data recorded in database 141 or memory for such vehicles.
- (D) if one or more license plates and/or additional identifications have newly appeared in the current image, data associated with the new license plates and/or additional identifications may be recorded in database 141 or memory.
- server system 140 may determine that one of the new vehicles corresponds to a vehicle recently determined to have disappeared, and may treat the view of the vehicle as having been temporarily obstructed. (E) if all license plates and/or additional identifications have disappeared from the current image, data from database 141 or memory from the preceding interval may be removed in connection with the license plates and/or additional identifications therein. However, some data may be retained in order to perform vehicle tracking to or from an identification camera, as discussed previously.
- server system 140 mates identified license plates and/or additional identifications to vehicles detected in the first task.
- server system 140 may be configured to compare attributes of license plates and/or additional identifications (such as, for example, absolute pixel location, direction of travel, and speed) to such attributes determined for possible vehicles and attempt to mate each license plate and/or additional identification to a vehicle.
- attributes of license plates and/or additional identifications such as, for example, absolute pixel location, direction of travel, and speed
- server system 140 may apply machine vision techniques to identify additional identification on vehicles for the purpose of confirming that either the particular vehicle is eligibility of parking in a particular parking space, or the vehicle license registration is current and valid.
- machine vision techniques include, but are not limited to: a handicap parking decal or mirror-hanger, a resident-only parking decal, and a registration decal typically adhered to license plates.
- OCR optical character recognition
- any license plate image(s) in order to obtain an alphanumeric license plate number along with state/province of issue.
- the license plate observed can be either the front or the rear license plate (typically, identification cameras are provided which point both ways up and down a street).
- the obtained license plate information is used to obtain a unique vehicle identifier used for recording information about the vehicle in database 141 .
- the first task may be performed locally on the identification camera where the license plate number and state/province data are transmitted to the server system 140 in a concise data format.
- server system 140 can track up to 10 sets of vehicle license number plate information simultaneously from a single identification camera at any given time.
- a vehicle is “tracked” as it moves across the field of view of identification camera 120 .
- neighboring or nearby camera positions are determined to ensure this overlap occurs.
- obtaining overlapped images of any given vehicle from both of these cameras is treated as a positive identification of the vehicle (via license plate number obtained from the identification image 121 ) along with an exact destination location the vehicle has occupied (in the event the vehicle parks).
- preliminary motion detection may be used to reduce the number of identification images which are captured and/or analyzed, as there may be significant periods of time during which no vehicles pass through the field of view of identification camera 120 .
- OCR rate is only one of the useful measurements in assessing identification performance.
- server system 140 failed to OCR only 1 of the license plates (in other words, was not able to produce an alpha-numeric plate number), if such a configuration (including factors such as server system programming, identification camera placement, and identification camera image quality) failed to capture/register 100 other license plates (in other words, additional license plate images were not identified as such by server system 140 ), the overall effectiveness is only 49.5%.
- license plate recognition systems are typically tuned to read license plates from a particular state/province along with ones from a number of the surrounding states/provinces. License plates from various states/provinces have different colors and contrast for letters and background.
- the capture rate is at least 95% and the OCR accuracy is at least 95%, yielding a minimum overall effectiveness of at least 90.25%.
- FIG. 3A illustrates an example of an image 126 captured by destination camera 125 , where destination camera 125 is located on a façade or top of a building looking down onto a portion of an urban street, such that a top view of vehicles is seen in image 126 .
- nine appropriate destination locations 310 a to 310 i (such as parking spots with a hourly rate for use) have been specified to server system 140 .
- all but destination location 310 d appear to be in use by vehicles 310 a to 310 i .
- inappropriate destination location 340 (such as a commercial entrance).
- a vehicle remaining stationary in any area not identified as a destination location may be considered a violation.
- vehicle 330 in a traffic lane for vehicles traveling from right to left in the image. Taken alone, the single image does not indicate whether vehicle 330 is moving or stationary. For example, in a preceding image, vehicle 330 might have been making use of destination location 310 d , and this image may cause server system 140 to determine that vehicle 330 has just completed its use of destination location 310 d.
- Destination images captured by destination camera 125 are used for two primary purposes: (1) identifying when destination locations are being or not being used by vehicles; and (2) determining various characteristics of vehicles, so that vehicles may be tracked as they traverse from camera to camera, by determining whether the characteristics determined from images captured by neighboring cameras correspond to one another, as discussed below in connection with FIG. 4 .
- FIG. 3B illustrates an example of an image 126 captured by destination camera 125 , where destination camera 125 is positioned such that a side view of vehicles is seen in image 126 .
- a view may be obtained where destination camera 125 is located in onsite parking system 160 , such as a parking meter, or on a building or structure opposite from one or more destination locations of interest.
- onsite parking system 160 such as a parking meter
- destination locations 350 a to 350 d such as parking spots with a hourly rate for use
- server system 140 four appropriate destination locations 350 a to 350 d (such as parking spots with a hourly rate for use) have been specified to server system 140 .
- all but destination location 350 c appear to be in use by vehicles 360 a to 360 d.
- destination camera 125 may be positioned such that image 126 provides a perspective view of one or more destination locations.
- FIGS. 3A and 3B illustrate the specification of rectangular areas 310 and 350 for destination locations, other shapes may be used, such as polygons (which is useful where destination camera 125 is positioned such that a destination location is seen in perspective).
- the GUI described below in connection with FIGS. 6A and 6B may also be configured to provide user interface elements which may be used to specify, with an overlay on an image feed, the position and extent of destination locations within the field of view of a camera. Additionally, the GUI may provide tools for assigning identifiers for destination locations, and possibly various characteristics about destination locations, such as, but not limited to, whether they are parking spaces, “no parking” locations, and time- and/or date-based restrictions on use.
- server system 140 when a vehicle appears in the field of view of destination camera 125 , server system 140 performs two tasks. For the first task, server system 140 may be configured to: (1) be aware of any and all vehicles present in the field of view of destination camera 125 ; (2) distinguish moving from stationary vehicles; (3) identify a time at which a moving vehicle becomes stationary in an area of the field of view corresponding to a destination location; (4) identify which destination location(s) each stationary vehicle is occupying; (5) keep track of how long each vehicle has occupied its respective destination location(s); (6) identify a time at which a stationary vehicle vacates an area of the field of view corresponding to a destination location; (7) determine when use of a destination location conflicts with restrictions established for the destination location; (8) identify which street or block a vehicle is improperly parked; (9) track an amount of time each vehicle has been improperly parked; and (10) track a time at which a vehicle ceases to be illegally parked.
- Various types of destination locations each having respective restrictions, for wheeled motor vehicles include, but are not limited to: no parking areas (anytime, fire lane, fire hydrant), no parking during specified times and/or days (for example, during rush hour or street cleaning), no parking/stopping/standing, limited-time parking (for example, 2 hour time limit), parking restricted to classes of vehicles (taxi stand, bus stop, loading zone/commercial vehicles only), permitted parking (handicapped or resident-only parking), pick-up and drop-off only locations, and street intersections (for anti-gridlock “block the box” moving violations in which a vehicle remains within an intersection during a red light for the vehicle's direction of travel).
- Server system 140 may be configured to detect other parking violations, such as, but not limited to, parking within a specified distance of an intersection, parking in a bike lane or crosswalk or other pedestrian zone, not within a space for a single destination location, more than a specified distance from a curb, parking in or in front of a driveway, use of an island or center strip, vehicle parked facing the wrong direction, abandoned vehicle (stationary for more than a specified number of days), oversize vehicles, incorrect class of vehicle (such as a camper, trailer, or boat for more than a specified number of hours in a given number of days).
- a destination location may also be subject to a reservation, where an end user reserves exclusive use of a destination location for a specified period of time.
- Server system 140 may also be configured to detect double parked vehicles, while distinguishing vehicles stopping in traffic lanes due to driving conditions from improperly double parked vehicles. Server system 140 may also be configured to recognize, and in some cases distinguish, smaller wheeled vehicles such as motorcycles, scooters, and “smart cars.”
- the vehicle is “tracked” as it moves across the field of view of destination camera 125 .
- neighboring camera positions are determined to ensure this overlap occurs.
- obtaining overlapped images of any given vehicle from both of these cameras is treated as a positive identification of the vehicle (via license plate number obtained from the identification image 121 ) along with the exact parking space the vehicle has occupied (in the event the vehicle parks).
- a destination camera may be positioned to monitor vehicle movement in a particular area, where the area does not include any destination locations of interest to server system 140 .
- Such an area may be located, for example, between two areas each containing destination locations of interest.
- images captured by the destination camera may overlap images captured by cameras corresponding to these two areas, and can be used for a “handoff” procedure as illustrated in FIG. 4 , discussed below.
- destination camera 125 may have pan, tilt, and/or zoom capability, which may be used for server system 140 to obtain a more detailed view of a destination location, or may be used by parking facility operator personnel via a user interface on parking operation system 190 to monitor particular areas of interest viewable by destination camera 125 .
- server system 140 may be configured to perform a coordinate transformation in order to monitor usage of destination locations and accurately determine vehicle characteristics while varying the field of view of destination camera 125 .
- preliminary motion detection may be used to reduce the number of destination images which are captured and/or analyzed, as there may be significant periods of time during which no vehicles pass through the field of view of destination camera 125 .
- accurate date and time stamps are included in all images captured by identification cameras and destination cameras to facilitate later manual review of stored images, should such a need arise.
- some amount of “grace period” is given to vehicles after they are determined to have become stationary within an appropriate destination location (in contrast to an inappropriate destination location, such as a no parking zone).
- an appropriate destination location in contrast to an inappropriate destination location, such as a no parking zone.
- FIG. 4 illustrates how images captured by cameras with overlapping fields of view may be used to identify a vehicle, track the movement of the vehicle to a destination location, and identify use of the destination location by the vehicle.
- FIG. 4 is not presented to scale; for example, overlapping area 430 a nominally would extend 44 feet or more in the vertical direction, but it is illustrated as approximately the same size as vehicle 410 .
- an identification camera (not illustrated) captures identification image 420 covering the field of view illustrated in FIG. 4 . Included in identification image 420 is vehicle 410 at the location designated 410 ′.
- server system 140 determines a unique identifier for vehicle 410 .
- Server system 140 records in database 141 , in connection with the unique identifier that vehicle 410 was observed by the identification camera at time t1.
- server system 140 instead stores in volatile memory that vehicle 410 was observed by the identification camera at time t1, and such information is recorded in database 141 after a determination that vehicle 410 has made use of a destination location prior to vehicle 410 being identified by server system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420 .
- the identification camera captures another identification image 420 a ′ of vehicle 410 at the location designated 410 a .
- a first destination camera captures destination image 420 b of vehicle 410 within overlap area 430 a (for example, at approximately the location 410 a ).
- the identification camera and the first destination camera are synchronized, such that images 420 a ′ and 420 b are both captured at essentially the same time t2.
- Overlap area 430 a corresponds to the field of view of identification image 420 a ′ which overlaps the field of view of destination image 420 b . In both images 420 a ′ and 420 b , images of vehicle 410 have been captured while vehicle 410 is within overlap area 430 a.
- server system 140 determines a plurality of characteristics Ca for vehicle 410 .
- fixed characteristics for vehicle 410 and recorded in database 141 may be included in Ca.
- the characteristics include, but are not limited to: a speed of travel for vehicle 410 , a direction of travel for vehicle 410 , a position of a vehicle in a vehicle image (including, for example, a lane of traffic vehicle 410 is traveling in), a color of vehicle 410 , and a size or dimension of vehicle 410 .
- Some characteristics may be considered static characteristics of vehicle 410 , and are not expected to change over time (for example, vehicle color or size).
- Other characteristics may be considered dynamic characteristics of vehicle 410 , and may change significantly over time (for example, vehicle speed or lane of travel).
- static characteristics may be recorded in database 141 as fixed characteristics of vehicle 410 in connection with the unique identifier determined based on identification image 420 a . These fixed characteristics may be determined based on vehicle information provided by an end user (such as make, model, year, and color), or they may be based on vehicle images captured during a previous encounter between vehicle 410 and server system 140 . The fixed characteristics may be used in connection with determining a unique identifier for vehicle 410 , by ensuring that static characteristics determined from identification images correspond to the fixed characteristics. The fixed characteristics may also be included in Ca or other pluralities of characteristics where a vehicle identification has been confirmed.
- server system 140 determines a plurality of characteristics Ca′ for vehicle 410 . Due to factors such as the different angles of view of vehicle 410 for the identification camera and the first destination camera, and obstructing vehicles, Ca and Ca′ may consist of different, but typically overlapping, sets of vehicle characteristics. For example, a vehicle width may be determined for Ca but not Ca′ due to a partial obstruction of vehicle 410 from the point of view of the first destination camera around time t2. Additionally, image distortion, which is typically more significant at the borders or images, or other factors may result in some vehicle characteristics, such as speed or size, only being approximate values. Normalization of characteristics such as size, speed, and direction of travel may be performed to compensate for camera positioning and zoom level.
- Server system 140 determines whether Ca′ corresponds to Ca by comparing the values of the vehicle characteristics included in both Ca and Ca′. As vehicle characteristics determined by server system 140 may be approximations of the actual characteristics of vehicle 410 , an approximate equivalence between values, where such equivalence is demonstrated for all of the compared characteristics, is sufficient to support a determination that Ca′ corresponds to Ca. If Ca′ is determined to correspond to Ca, then server system 140 records in database 141 , in connection with the unique identifier, that vehicle 410 was observed by the first destination camera at time t2.
- server system 140 instead stores in volatile memory that vehicle 410 was observed by the first destination camera at time t2, and such information is recorded in database 141 after a determination that vehicle 410 has made use of a destination location prior to vehicle 410 being identified by server system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420 . This avoids writing vehicle location information to database 141 that is not required to demonstrate that a use of a particular destination location by vehicle 410 .
- the first destination camera captures another destination image 420 b ′ of vehicle 410 at the location designated 410 b .
- a second destination camera captures destination image 420 c of vehicle 410 within overlap area 430 b (for example, at approximately the location 410 b ).
- the first destination camera and the second destination camera are synchronized, such that images 420 b ′ and 420 c are both captured at essentially the same time t3.
- Overlap area 430 b corresponds to the field of view of destination image 420 b ′ which overlaps the field of view of destination image 420 c .
- images of vehicles 410 and 440 have been captured while vehicles 410 and 440 are within overlap area 430 b.
- server system 140 determines a plurality of characteristics Cb for vehicle 410 . As noted above, fixed characteristics for vehicle 410 and recorded in database 141 may be included in Cb. Based on destination image 420 c , and possibly other destination images captured by the second destination camera, server system 140 determines a plurality of characteristics Cb′ for vehicle 410 . Additionally, due to the inclusion of vehicle 440 in destination image 420 c , a plurality of vehicle characteristics Cx are determined for vehicle 440 . Differences in dynamic vehicle characteristics between Cb′ and Cx would result due to vehicle 440 traveling in the opposite direction in a different lane of travel.
- Server system 140 determines whether Cx corresponds to Cb, which should not occur. Server system 140 then determines whether Cb′ corresponds to Cb. If Cb′ is determined to correspond to Cb, then server system 140 records in database 141 , in connection with the unique identifier, that vehicle 410 was observed by the second destination camera at time t3. In an alternative embodiment, server system 140 instead stores in volatile memory that vehicle 410 was observed by the second destination camera at time t3, and such information is recorded in database 141 after a determination that vehicle 410 has made use of a destination location prior to vehicle 410 being identified by server system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420 .
- the second destination camera captures another destination image 420 c ′ of vehicle 410 at the location designated 410 c .
- a third destination camera captures destination image 420 d of vehicle 410 within overlap area 430 c (for example, at approximately the location 410 c ).
- the second destination camera and the third destination camera are synchronized, such that images 420 c ′ and 420 d are both captured at essentially the same time t4.
- Overlap area 430 c corresponds to the field of view of destination image 420 c ′ which overlaps the field of view of destination image 420 d . In both images 420 c ′ and 420 d , images of vehicle 410 have been captured while vehicle 410 is within overlap area 430 c.
- server system 140 determines a plurality of characteristics Cc for vehicle 410 . As noted above, fixed characteristics for vehicle 410 and recorded in database 141 may be included in Cc. Based on destination image 420 d , and possibly other destination images captured by the third destination camera, server system 140 determines a plurality of characteristics Cc′ for vehicle 410 . Server system 140 then determines whether Cc′ corresponds to Cc. If Cc′ is determined to correspond to Cc, then server system 140 records in database 141 , in connection with the unique identifier, that vehicle 410 was observed by the third destination camera at time t4.
- server system 140 instead stores in volatile memory that vehicle 410 was observed by the third destination camera at time t4, and such information is recorded in database 141 after a determination that vehicle 410 has made use of a destination location prior to vehicle 410 being identified by server system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420 .
- a second identification camera may be responsible for capturing image 420 d , but is unable to obtain an image of a license plate for vehicle 410 , in which case characteristics of vehicle observed via the second identification camera are used to confirm that the vehicle observed in overlap area 430 c around area 410 c is vehicle 410 . This illustrates that it is not significant whether it is a destination camera or an identification camera which is used for tracking vehicle 410 as it moves away from the initial identification camera. When used in connection with such tracking, these cameras may be broadly referred to as “tracking cameras.”
- the third destination camera captures another destination image 420 d ′ of vehicle 410 at the location designated 410 d .
- a fourth destination camera captures destination image 420 e of vehicle 410 within overlap area 430 d (for example, at approximately the location 410 d ).
- the third destination camera and the fourth destination camera are synchronized, such that images 420 d ′ and 420 e are both captured at essentially the same time t5.
- Overlap area 430 d corresponds to the field of view of destination image 420 d ′ which overlaps the field of view of destination image 420 e . In both images 420 d ′ and 420 e , images of vehicle 410 have been captured while vehicle 410 is within overlap area 430 d.
- server system 140 determines a plurality of characteristics Cd for vehicle 410 . As noted above, fixed characteristics for vehicle 410 and recorded in database 141 may be included in Cd. Based on destination image 420 e , and possibly other destination images captured by the fourth destination camera, server system 140 determines a plurality of characteristics Cd′ for vehicle 410 . Server system 140 then determines whether Cd′ corresponds to Cd. If Cd′ is determined to correspond to Cd, then server system 140 records in database 141 , in connection with the unique identifier, that vehicle 410 was observed by the fourth destination camera at time t5.
- server system 140 instead stores in volatile memory that vehicle 410 was observed by the fourth destination camera at time t5, and such information is recorded in database 141 after a determination that vehicle 410 has made use of a destination location prior to vehicle 410 being identified by server system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420 .
- destination image 420 e ′ is captured by the fourth destination camera, at a time when vehicle 410 is at location 410 e .
- server system 140 determines that vehicle 410 is within the rectangular region specified for destination location 450 b .
- destination image 420 e ′′ is captured by the fourth destination camera, with vehicle 410 remaining at location 410 e .
- server system 140 Based on destination image 420 e ′′, server system 140 again determines that vehicle 410 is within the rectangular region specified for destination location 450 b , accordingly determines that vehicle 410 began use of destination location 450 b beginning at time t6, and records this information in database 141 . At time t8, destination image 420 e ′′′ is captured by the fourth destination camera, at a time when vehicle 410 has exited destination location 450 b . Based on destination image 420 e ′′′, server system 140 determines that vehicle 410 is no longer within the rectangular region specified for destination location 450 b , accordingly determines that vehicle 410 completed its use of destination location 450 b at time t8.
- server system 140 can initiate actions such as billing an end user account for this use of destination location 450 b , or such as levying a fine for improper use of destination location 450 b.
- Server system 140 is also configured to correctly identify a vehicle which has made use of a destination location where server system 140 first determines that a vehicle has made use of a destination location, and then later is able to capture a vehicle identification via an identification camera. This situation may occur where, for example, a view of a vehicle is obstructed as it passes by an identification camera, or a restart of server system 140 results an identification of the vehicle not being made previously. As an example, if at time t0, before time t1, the fourth destination camera were to first determine that vehicle 440 was making use of destination location 450 c , but not have an identification for vehicle 440 , a temporary unique identifier would be assigned to vehicle 440 , and entries recorded in database 141 in connection with the temporary identifier.
- Sets of vehicle characteristics would be determined for vehicle 440 while it made use of destination location 450 c , as well as when it passed through overlap areas 430 d , 430 c , 430 b , and 430 a , and the correspondence of these sets of characteristics would be performed much in the same manner described above, to determine and record that the same vehicle 440 associated with the temporary identifier, was still being observed.
- server system 140 Once observed by the first identification camera while located in overlap area 430 a , server system 140 would be able to determine a correct unique identifier for vehicle 440 .
- An alternative mechanism for obtaining an identification of vehicle 440 after time t0 is to dispatch mobile device 150 to capture one or more identification images of vehicle 440 while it is making use of destination location 450 c .
- Dispatch of mobile device 150 may be designated a higher priority where the use of destination location 450 c by vehicle 440 is determined to conflict with restrictions associated with use of destination location 450 c.
- Server system 140 receives images from the identification and destination cameras and interpolates the identities of parked vehicles. Server system 140 may then retrieve parking payment information (such as, but not limited to, duration of paid parking and time of expiration) from a third-party parking payment system via an API (application programming interface). If a vehicle parking status is determined to be either unpaid or expired, the server system 140 transmits this information to the third-party parking payment system via an API.
- the parking facility operator which runs the third-party payment system can then follows its Standard Operating Procedures (SOP) in dealing with parking violations (such as, but not limited to, mailing a parking violation ticket, installing a wheel clamp on the vehicle, or towing the vehicle upon repeated or severe parking violations).
- SOP Standard Operating Procedures
- Vehicle detection by server system 140 may be configured to perform several functions: (1) detecting the presence and location of vehicles in video frames; (2) distinguishing moving vehicles from stationary vehicles; (3) identifying whether particular detected vehicles are occupying destination locations, such as parking spaces or no-parking areas; (4) determine a time at which a vehicle begins to occupy or vacates a destination location; (5) track vehicles as they travel from the field of view of one tracking camera to another, and raise an exception if an error in this tracking is determined to have occurred.
- server system 140 may also be configured to identify whether particular vehicles are displaying an appropriate indicator for access or use of a destination location.
- Such indicators include, but are not limited to, a handicapped parking hanger or decal, or a parking hanger or decal indicating authorized use of a “resident only” parking location.
- a camera may be zoomed in to more clearly capture images of such indicators.
- a vehicle identifier such as a license plate, may be used to determine appropriate access or use of a destination location, and obviate the need for a separate indicator.
- server system 140 may be programmed to use threads to carry out its tasks for identification and destination cameras.
- a “video_receiver” thread may handle the reception of a video and/or image stream from an identifier or destination camera and store raw video and/or image information. This may be with one thread per video and/or image stream or multiple video and/or image streams. Configurable options for this thread may include (1) store to file, (2) store to memory, (3) store to memory and file, (4) a retention time for video data (for example, 4 hours)).
- Another example is a thread to detect vehicle color, shape, location, lane position, speed/direction of travel, whether a vehicle location is in a handoff zone (and which one), camera identification, and storing such information in database 141 .
- This thread would examine each multiple video frames to determine updated locations and speed/direction of travel of vehicles and storing such information in database 141 .
- Another example is a thread which confirms a particular vehicle detected as exiting via a handoff zone is detected by a nearby camera. This may be done, for example, by reviewing the database 141 for a particular camera based on in which handoff zone the vehicle was detected and/or a detected direction of travel for the vehicle.
- Another example is a thread to determine whether a vehicle is occupying a destination location by remaining stationary at that destination location, along with a time when vehicle begins to occupy or vacates the destination location.
- an algorithm may detect the presence of a vehicle based on differences in color between the vehicle and the background, and whether a size of a total shape is larger than a minimum vehicle size expected in consideration of zoom level and/or location in a field of vision. For example, the algorithm may compare colors of pixels in a video stream snapshot against each other. Since an image likely includes various non-vehicle objects such as a fire hydrant, pedestrian, grass, road markings, and paint, the algorithm may detect groups of pixels with similar colors (with a configurable range of variation in color considered to be a match).
- the number and location of pixels in the total shape are used to determine whether the shape is larger than the minimum vehicle size.
- the algorithm may further accommodate “holes” or imperfections in the shape, which may occur due to specular reflections or highlights, for example. Additionally, the algorithm may determine whether a number of shapes of respective minimum sizes are within certain distances of each other. These shapes may correspond to, for example, hood, roof, and trunk portions of a vehicle, which are typically of the same color.
- a boundary condition may occur where there is insufficient contrast or difference in color between a vehicle and the background, in which detection may fail.
- a black vehicle against black asphalt For example, a black vehicle against black asphalt.
- camera hardware and/or the algorithm may be introduced to address this boundary condition.
- a camera that performs both visible light and thermal imaging may be used, which obtains a heat signature of a vehicle that has begun occupying a destination location.
- the engine compartment would have a different thermal profile than its surrounding even though both the vehicle and the backdrop are black in color.
- Further cost-benefit analysis would determine whether the benefits gained from such an approach justifies the incremental cost, as well as taking in account any boundary conditions caused by the thermal imaging process can be sufficiently addressed (such as by the visible light captured by the camera).
- server system 140 may be configured to: (1) based on determinations of color and size of vehicles in the current image, find corresponding matches in previous images (for example, by reviewing data stored in database 141 or memory); and (2) once such matches are found, compare the locations of pixels between the current image and previous images, taking into account any change in zoom level. Based on such processing, one or more of the following scenarios may be detected. (A) if locations of pixels are unchanged or have unchanged below a predetermined threshold, all vehicles are deemed to have remained stationary.
- a simple update of the date and time is performed for existing entries in database 141 or memory for the vehicles.
- (B) if pixels associated with one or more vehicles are at new locations, then the one or more vehicles are determined to have moved.
- Server system 140 may calculate speed and direction of travel for these vehicles and update database 141 or memory with this information, along with updated locations.
- (C) if one or more vehicles have disappeared from the current image, server system 140 may be configured to remove data recorded in database 141 or memory for such vehicles.
- D if one or more vehicles have newly appeared in the current image, data associated with the new vehicles may be recorded in database 141 or memory.
- server system 140 may determine that one of the new vehicles corresponds to a vehicle recently determined to have disappeared, and may treat the view of the vehicle as having been temporarily obstructed. (E) if all vehicles have disappeared from the current image, data from database 141 or memory from the preceding interval may be removed in connection with the vehicles therein. However, some data may be retained in order to perform vehicle tracking to or from an identification camera, as discussed previously.
- an algorithm for identifying which vehicles are occupying destination areas is similar to the basic vehicle detection algorithm.
- server system 140 evaluates whether pixel locations corresponding to a vehicle occupy any of the pre-mapped visual regions.
- a degree of overlap may be configurable.
- a vertical offset may be applied to compensate for vehicle height and compensate for a visual obstruction, such as a parked vehicle, between a destination camera and the vehicle. Such obstructions may frequently occur in dense parking lots, for example.
- server system 140 determines whether the vehicle has remained stationary for at least a certain amount of time.
- server system 140 may be configured to detect when a vehicle takes up multiple destination locations, such as by occupying two parking spaces. This may result in, for example, issuance of one or more parking citations or increased usage fees. Server system 140 may also determine when the vehicle vacates the destination location, and record corresponding information in database 141 .
- server system 140 may be configured to determine when user of the destination location by the vehicle will soon exceed, or has exceeded, a period of time for use of the destination location, such as may occur in connection with a parking spot with a two-hour maximum parking duration, a destination location not available for vehicle use after a specified time for street sweeping, or the exhaustion of funds provided for the vehicle.
- server system 140 may be configured to recognize one or more multi-vehicle destination locations, which may be used by more than one vehicle at a time.
- server system 140 may be configured to support tracking for “long block” parking of vehicles, in which a parking area controlled by, for example, a single Pay-by-Space, Pay-and-Display, or Pay-by-Plate unit is provided along the length of a curb for a city block, but the parking area is not divided into marked parking spaces; instead, vehicles can make use of any available space along the curb (excluding certain “no parking” regions, such as, but not limited to, loading zones and driveways).
- server system 140 may be configured to track use of a parking lot, but not a plurality of individually marked spaces therein, controlled by, for example, a single Pay-and-Display unit. Although server system 140 may not be configured to track use of a multi-vehicle destination location on a space by space basis, server system 140 may determine and record the position of a vehicle within the multi-vehicle destination location for tracking the vehicle's use over time and for parking enforcement activities, such as attaching a citation to a vehicle which has exceeded its permitted use of the multi-vehicle destination location.
- server system 140 may be configured to determine a length of a vehicle making use of a multi-vehicle destination location, as a greater parking fee and/or fine may imposed for the use of space that otherwise could be occupied by more than one vehicle.
- server system 140 described in this application is that whereas conventional controlled parking lots might rely on a single point of ingress and egress for controlling use of the lot, tracking by use of cameras allows for a parking lot with multiple entrances and exits and a more “open” design, as vehicles do not need to be confined by wall of fencing.
- multiple noncontiguous destination locations or multi-vehicle destination locations may be aggregated into a single multi-vehicle destination location. This may include where two constituent destination locations are covered by different destination cameras. This may be useful where, for example, a multi-vehicle destination location is broken up by various “no parking” destination locations along the length of a city block.
- a restricted destination location such as a “no parking” overlaying a multi-vehicle destination location, so as to “carve out” restricted areas of the multi-vehicle location.
- a single multi-vehicle destination location may be defined along the entire length of a city block, with “no parking” destination locations overlaying various portions along the city block, such as, but no limited to, loading zones and driveways along the length of the block.
- a vehicle detected by server system 140 as making use of one of the “no parking” destination locations will be determined by server system 140 as having committed a parking violation, despite the vehicle also have been within the larger multi-vehicle destination location.
- a computer-based configuration utility may be provided.
- mobile device 150 or manual review system 180 may be configured with a configuration utility, allowing for on-site or remote configuration.
- mobile device 150 may be used by a person performing camera installation, in order to provide feedback as to the effectiveness of a camera configuration for vehicle identification, tracking, and/or detection.
- certain system or camera configuration changes may be made via manual review system 180 as a result of configuration shortcoming identified during use of manual review system 180 .
- a user interface may be made available via a web browser.
- the configuration utility may provide one or more features such as, but not limited to:
- a GUI presents two image feeds and allows an administrator to superimpose rulers on each image feed.
- a zoom level if any, may be displayed as part of the GUI, as may be a control for modifying the zoom level.
- the two image feeds originate from the given camera and another camera with an overlapping field of vision (such cameras are often adjacent to each other).
- the capture of images for the two cameras is synchronized such that images are captured at the same time, allowing for review of a vehicle's position in each video feed, such as when it passes through the overlapping area of the two cameras' fields of vision.
- the configuration utility may also provide, by way of the GUI, temporal image control functions such as pause, play, rewind, fast forward, freeze frame advance, freeze frame reverse, and goto frame functions.
- the configuration utility may be used to find one or more vehicles of known make and model in one or both image feeds (this might include, for example, a vehicle used by a technician operating the configuration utility), and position one or more rulers in the GUI such that the rulers indicate the correct length, width, and/or height of the vehicles by reference to known values for these dimensions for the vehicles being measured.
- the ruler function provided by the GUI is configured to compensate for nonlinearities due to factors such as visual distortion introduced by the camera (which may have known characteristics based on a camera model, for example) or the perspective of the captured image.
- ruler markings indicating units of distance may be spaced closer on a right-hand side of an image where vehicles captured in that area are further away from the camera than those captured in the left-hand side of the image.
- the configuration utility may be configured to allow for on-site calibration of such nonlinearities for a given camera by identifying markers in an image, and specifying positions and/or distances (relative to other markers and/or the camera). Such markers may be temporarily, or in some cases permanently for the purpose of later recalibration, placed by a technician.
- the configuration utility may be used to specify relationships between directions of travel in the two image feeds, as well as identify pixels or image locations corresponding to common points in the two image feeds.
- locations and directions of travel may be specified for lanes/paths of traffic in each of the image feeds, and correlated between the two images feeds (allowing, for example, later determination of when a vehicle passes from the field of one camera to another within the same lane/path of traffic). Specification of these features may be done via the GUI, for example by allowing for the overlay of lines or other indicators on the image feeds indicating lane/path boundaries.
- FIGS. 6A and 6B illustrate aspects of an example GUI.
- FIG. 6A illustrates a portion of the GUI in which an image 600 a from a first camera is displayed.
- FIG. 6B illustrates a portion of the GUI in which an image 600 b from a second camera is displayed.
- the field of views of the images 600 a and 600 b overlap, with the area of overlap including areas 640 a and 640 b .
- Also captured in images 600 a and 600 b are two lanes/paths of traffic, labeled as lanes/paths 611 a and 612 a in FIG. 6A , and lanes/paths 611 b and 612 b in FIG. 6B .
- lanes/paths 611 a and 612 a labeled as lanes/paths 611 a and 612 a in FIG. 6A
- lanes/paths 611 b and 612 b in FIG. 6B .
- traffic proceeds in the same direction (generally corresponding to angle 8 ) in lanes/paths 611 a and 611 b , although in a similar example traffic might proceed in opposing directions in lanes/paths 611 a and 611 b
- images 600 a and 600 b are images of three vehicles, respectively labeled A, B, and C.
- lane/path boundaries have been specified with the dashed lane/path boundary indicators 621 a , 622 a , and 623 a , which may be added, placed, moved, labeled, and otherwise identified by use of the GUI.
- dashed lane/path boundary indicators 621 a , 622 a , and 623 a which may be added, placed, moved, labeled, and otherwise identified by use of the GUI.
- two traffic lanes/paths have been specified using the GUI: the lane/path 611 a between lane/path boundary indicators 621 a and 623 a , and the lane/path 612 a between lane/path boundary indicators 622 a and 623 a .
- the lane/path 611 a between lane/path boundary indicators 621 a and 623 a
- the lane/path 612 a between lane/path boundary indicators 622 a and 623 a .
- traffic proceeds in lanes/paths 611 a and 612 a in the same direction 8
- lane/path boundary indicators 621 a and 622 a are of a first type (illustrated by the similar dashed lines)
- lane/path boundary indicator 623 a is of a second type indicating the division of the area of unidirectional traffic flow between lane/path boundary indicators 621 a and 622 a into the two lanes/paths 611 a and 612 a .
- the configuration utility may be configured to automatically provide or suggest identifiers for the specified lanes for cross referencing with, for example, lanes identified in connection with other cameras, such as lanes/paths 611 b and 612 b illustrated in FIG. 6B .
- FIG. 6B illustrates the lanes/paths 611 b and 612 b illustrated in FIG. 6B .
- the configuration utility provides similar facilities for lane/path identification, with lanes/paths 611 b and 612 b , and lane/path boundary indicator lines 621 b , 622 b , and 623 b corresponding to their counterparts in FIG. 6A described above.
- each lane/path of traffic may be divided into a number of smaller segments. These segments may be specified via the GUI, for example by allowing for the overlay of lines or other indicators on the image feeds indicating the segments. In an embodiment, the overlaid lines may be used to aid in automatically characterizing nonlinearities in image feeds.
- FIG. 6A illustrates an example, with lane/path segment indicator 631 a and other similar unlabeled lane/path segment indicators.
- the configuration utility may be configured to automatically generate suggested lane/path segment indicators based on previously specified lane/path boundary indicators, and provide via the GUI tools for adjusting the lane/path boundary indicators as desired. Also, the inclusion of vehicle images, such as vehicles A, B, and C shown in FIG.
- FIG. 6A may aid a technician in accurately placing or adjusting lane/path segment indicators.
- FIG. 6B illustrates lane/path segment indicator 631 b and other similar unlabeled lane/path segment indicators corresponding to their counterpart in FIG. 6A described above.
- the configuration utility may also provide similar features via the GUI for specifying an area of an image stream with an overlapping field of view with a respective area of a second image stream.
- these areas are used for “handing off” the detection of a vehicle from one tracking camera to another, these areas may be referred to as “handoff zones.”
- FIGS. 6A and 6B illustrate images captured by cameras with overlapping fields of view, in which the field of view for handoff zone 640 a overlaps the field of view for handoff zone 640 b .
- the GUI may be configured to allow for specification of handoff border indicators 651 a and 652 a in FIG. 6A , and respective handoff border indicators 651 b and 652 b in FIG. 6B .
- a specified handoff zone may be divided into a number of smaller segments, using handoff segment indicators 611 a and 611 b (and other unlabeled handoff segment indicators) illustrated in FIGS. 6A and 6B .
- the configuration utility may be configured to automatically generate suggested handoff segment indicators based on previously specified handoff boundary indicators, and provide via the GUI tools for adjusting the handoff boundary indicators as desired. Also, the inclusion of vehicle images, such as vehicles A, B, and C shown in FIG. 6A , may aid a technician in accurately placing or adjusting handoff segment indicators.
- the configuration utility may be configured to determine a distance between handoff border indicators 651 a and 652 a , an alert a user of the GUI if this distance is below a minimum desired distance.
- GUI illustrated in FIGS. 6A and 6B shows and describes indicators provided by the GUI as simple lines
- the configuration utility and the GUI may also provide for specifying features with more complex shapes, such as, but not limited to, curves and freehand lines.
- an indicator specified in connection with a first camera such as lane/path boundary indicator 623 a
- a counterpart indicator in connection with another camera such as lane/path boundary indicator 623 b
- these counterpart indicators may be linked using the GUI.
- such links may be automatically determined or suggested based on information such as previously specified indicators, a known position of a camera, a known orientation of the camera, and known aspects of traffic flow proximate to a camera, such as numbers of lanes/paths and directions of traffic flow within those lanes/paths.
- the configuration utility may be configured to allow for the specification of various indicator features in images captured with the camera at various zoom levels or orientations. This additional information may be used to more fully specify the overall field of view of the camera. Once a technician is satisfied with how indicators and/or rulers have been used to specify the field of view of a camera, this information and/or other information derived therefrom may be stored in database 141 for use in, for example, vehicle tracking by server system 140 .
- the configuration utility may be configured to provide a GUI to perform contiguous video camera alignment. This functionality may be provided via additional user interface elements included in the above-described GUI for specifying lane/path boundaries.
- Contiguous video camera alignment refers to the fact that during an initial camera hardware installation process, or if existing camera hardware is later updated, if the camera is equipped with pan, tilt, and/or zoom (PTZ) function, the pan, tilt, and/or zoom settings of the camera need to be adjusted and/or calibrated to ensure there is sufficient overlap in the field of vision between cameras, such as the overlap illustrated in FIGS. 4 , 6 A, and 6 B.
- a technician can review the GUI to determine whether a handoff zone of sufficient size and/or duration is provided by a pair of cameras. If not, pan, tilt, and/or zoom settings may require changes, or the physical installation location of a camera may need to be changed altogether.
- the configuration utility may be configured to provide a GUI to perform pre-mapping of destination locations, such as parking spaces and “no parking” zones.
- the GUI presents an image feed and allows a technician to superimpose grayed out polygons, for example, on an image feed.
- a parking spot #123 might be mapped to a collection of 20 pixels as captured by a particular destination camera at a given zoom level and/or PTZ orientation.
- the GUI may be configured to provide operations for including, but not limited to, moving, resizing, and rotating such polygons to indicate the position and extent of destination locations within a field of view of a camera. Where a camera has PTZ capabilities, PTZ controls may be provided.
- the GUI may also provide an interface of assigning an identifier to a destination location which may be used, for example, to provide a common identifier for the destination location for use by various aspects of server system 140 .
- the GUI may also provide interface elements allowing for various characteristics of a destination location to be specified, although it may be preferable to employ other aspects of the configuration utility or server system 140 to manage, assign, and/or modify such characteristics with minimal direct human operation.
- the configuration utility may be configured to provide a GUI to perform pre-mapping of multi-vehicle destination locations, discussed above, in much the same manner as the above description for pre-mapping single-vehicle destination locations.
- the configuration utility may be configured to allow multiple destination locations or multi-vehicle destination locations to be aggregated into a single destination location. For example, each of the constituent destination locations might be assigned a common identifier to indicate they form a multi-vehicle destination location.
- the configuration utility may be configured to allow restricted destination locations to be overlaid a multi-vehicle destination location, to “carve” out portions of a broad area subject to parking restrictions, such as, but not limited to, loading zones and driveways.
- the configuration utility may be configured to provide a GUI for specifying what constitutes a parking violation.
- a grace period duration may be specified with the GUI, which defines an amount of time a vehicle may occupy a destination location before the vehicle may be considered to be in violation of restrictions on use of the destination location. For example, when a vehicle stops at a parking meter, it is reasonable to provide a grace period sufficient for the driver of the vehicle to leave the vehicle and pay for parking. Differing periods of time may be specified for different types or groups of destination locations (for example, a “no parking” zone may have a small or zero grace period.
- an amount of vehicle overlap may be specified with the GUI, as to how much in terms of square footage or percent area coverage a vehicle overlaps a destination location before the vehicle may be considered to be in violation.
- permit parking rules may be specified with the GUI, including rules in connection with, for example, the use of handicap parking spaces, resident-only parking, or other parking requiring the display of a permit or decal.
- the GUI may also provide an interface for identifying characteristics and features of a required permit or decal, such as, but not limited to, color, an image featured on the permit or decal, and a location of an identifier (such as a serial number) for the permit or decal.
- a GUI may be configured to define rules for determining what constitutes an expired license plate tag, such as whether a tag indicating the current month is considered to have expired.
- the configuration utility may be configured to provide a GUI for specifying consequences for vehicle misuse of a destination location. Examples include, but are not limited to, on-screen display of license plate information, license plate lookup to obtain the name and address of a registered owner, dispatching an enforcement officer, provide a laser-based illumination of a vehicle misusing a destination location, applying a parking fine to a credit card or account on file, and deducting a parking fine from a checking or other monetary account.
- the configuration utility may be configured to receive and record parameters specifying certain vehicles for which outcomes of detected parking violations would be modified (for example, a police vehicle may be identified as exempt from specified violations). For example, such vehicles may be identified by license plate number, or bear a specified identifier such as a decal.
- server system 140 may be configured to obtain preexisting street and/or parking information, which may be obtained through a commercial or municipal database and/or provided by a parking operator, and automatically determining destination and traffic lane/path information In an embodiment, based on information indicating the location and orientation of the various identification and destination cameras, server system 140 may be configured to automatically pre-map destination locations and/or traffic lanes/paths. In an embodiment, server system 140 may be configured to record and/or update characteristics for destination locations and or traffic lanes/paths recorded in database 141 , such as, but not limited to, identifiers, locations (for example, latitude/longitude or street address), rates for use of destination locations, and time-based, date-based, and other restrictions for destination locations described in this application. In an embodiment, server system 140 may provide an API to more easily allow a parking provider to upload destination location information and/or updates in bulk.
- server system 140 and other elements illustrated in FIG. 1 are in the form of a turnkey platform where no integration with third-party parking payment systems via an API is required.
- part of the turnkey platform consists of payment stations/equipment, and equipment that generates parking violation tickets for mailing.
- onsite payment system 160 may include a turnkey platform Pay-by-Phone feature.
- IVR interactive voice response
- onsite payment system 160 may include a turnkey platform Pay-by-Phone feature.
- end users can pay for parking by calling a particular IVR (interactive voice response) system-driven phone line and input a destination location identifier or vehicle license plate number and a duration of parking, regardless of whether a destination location is associated with a curbside parking meter, a Pay-by-Space parking space, or a parking lot.
- IVR interactive voice response
- the turnkey Pay-by-Phone module enables end users to pay for parking by use of a telephone—typically cellular phone.
- the turnkey Pay-by-Phone machine enables database-level integration with server system 140 .
- Database-level integration is superior to API-level integration since database-level integration offers more flexibility and speed.
- the turnkey Pay-by-Phone module receives data from one or more DTMF transceivers where users enter information over the telephone. There is no requirement for the turnkey Pay-by-Phone module to receive data from server system 140 in order for the turnkey Pay-by-Phone module to operate correctly.
- the turnkey Pay-by-Phone module may be configured to output data to mobile device 150 for manual paid parking validation, as well as to server system 140 for self-enforcement. All self-enforcement data processing takes place on server system 140 .
- onsite payment system 160 may include Pay-Online on a turnkey platform.
- end users can pay for parking or view prior history by visiting a website and enter a destination location identifier or vehicle license plate number and the duration of parking regardless of whether a destination location is associated with a curbside parking meter, a Pay-by-Space parking space, or a parking lot. This extends to other online conduits such as smart phones and, in the future, Internet-enabled media centers in cars.
- the turnkey Pay-Online module receives data online where end users enter information over the Internet. There is no requirement for the turnkey Pay-Online module to receive data from server system 140 in order for the turnkey Pay-Online module to operate correctly.
- the turnkey Pay-Online module outputs data to the mobile device 150 for manual paid parking validation, as well as to the server system 140 for self-enforcement. All self-enforcement data processing takes place on server system 140 .
- onsite payment system 160 may include a Pay-and-Display machine with QR codes.
- QR codes have become popular, and accordingly have significant smartphone support. Further, QR codes can easily hold all of the relevant information typically contained on a Pay-and-Display ticket (such as, but not limited to, parking duration, parking expiration time, amount paid, date, and time).
- the turnkey Pay-and-Display machine allows end users to pay for parking and leave a display ticket with a QR code on the dash of the vehicle.
- the turnkey Pay-and-Display machine enables database-level integration with server system 140 . Database-level integration is superior to API-level integration since database-level integration offers more flexibility and speed.
- the turnkey Pay-and-Display machine receives payment from end users via a built-in keypad, coin acceptor, credit card reader, and printer. There is also a text/graphics LCD display. There is no requirement for the turnkey Pay-and-Display machine to receive data from server system 140 in order for the turnkey Pay-and-Display machine to operate correctly.
- the turnkey Pay-and-Display machine outputs data to mobile device 150 for manual paid parking validation, as well as to server system 140 for self-enforcement. All self-enforcement data processing takes place on server system 140 .
- onsite payment system 160 may include a Pay-by-Space turnkey machine.
- Pay-by-Space is increasingly becoming popular compared to Pay-and-Display which has a longer history of operation. Parking operations using Pay-by-Space are generally more efficient since parking enforcement personnel no longer have to walk to each vehicle and lean into the windshield in order to manually check the printed expiration time. Instead, they can drive in a patrol vehicle and perform visual checks from a distance to see whether an occupied parking space has been paid for.
- Pay-by-Space offers enhanced user experience since drivers no longer have to walk back to their vehicles to display the ticket after paying at the machine—instead, they can continue on to their destination.
- the turnkey Pay-by-Space machine receives payment from end users via a built-in keypad, coin acceptor, credit card reader, and printer. There is also a text/graphics LCD display. There is no requirement for the turnkey Pay-by-Space machine to receive data from server system 140 in order for the turnkey Pay-by-Space machine to operate correctly.
- the turnkey Pay-by-Space machine may output data to the mobile device 150 for manual paid parking validation, as well as to server system 140 for self-enforcement. All self-enforcement data processing takes place on server system 140 .
- onsite payment system 160 may include a Pay-by-Plate turnkey machine.
- the turnkey Pay-by-Plate machine receives payment from end users via a built-in keypad, coin acceptor, credit card reader, and printer. There is also a text/graphics LCD display. There is no requirement for the turnkey Pay-by-Plate machine to receive data from server system 140 in order for the turnkey Pay-by-Plate machine to operate correctly.
- the turnkey Pay-by-Plate machine may output data to the mobile device 150 for manual paid parking validation, as well as to server system 140 for self-enforcement. All self-enforcement data processing takes place on server system 140 .
- Integration with third-party parking systems is an option rather than a requirement for server system 140 .
- no integration with third party parking systems is required.
- An API provides a standard software programming interface designed to allow an external program to gain access to information in a host system without exposing any trade secrets of the host system. This is achieved by creating clearly defined functions, objects, and variables at the boundary of the two systems, such that the external system is allowed to obtain pre-defined set of information without any knowledge of how the information is gathered, stored, or calculated within the host system itself.
- companies generally have no reservations with publishing API for other systems to interface to its products or servers.
- Data may be exchanged via an API via network-based mechanisms, often protected by encryption mechanisms such as SSL, relying on XML, JSON, HTML, MIME, or other encodings or languages supported by the API.
- server system 140 can integrate with an API.
- vehicle payment information such as, but not limited to, duration paid, and space number.
- server system 140 has or can readily obtain the complete information necessary to produce a list of vehicle license plates with detailed parking violation information to a parking facility operator. The parking facility operator can then follow its SOP, and mail parking violation tickets, install wheel clamps, or tow repeat or severe offenders.
- the second integration method is for server system 140 to publish its own API so third-party parking systems can obtain information on vehicle detection and vehicle identity. Combined with the vehicle payment information already possessed by the third-party parking system, the third-party parking system can then provide a seamless presentation to the parking operator including a list of vehicle license plates with detailed parking violation information.
- the third-party parking system provider may prefer this approach in order to retain control over how the parking violation information flows back to the parking operator.
- server system 140 can integrate with the following types of parking payment systems: Pay-by-Phone, Pay-by-Space, Pay-and-Display, Curbside Parking Meters (single or double space), and Live-Operator Option.
- Pay-by-Phone The basic premise of Pay-by-Phone is an end user (such as a driver of a vehicle) calls a phone number displayed in the vicinity of a destination location. Typically the phone number offers IVR (interactive voice response) which guides callers through an automated menu. The end user is prompted to input a unique destination location number, followed by parking duration desired, vehicle license plate number, and credit card information.
- IVR interactive voice response
- Pay-by-Phone is starting to gain traction as a popular “overlay” payment approach, where parking facility operators add Pay-by-Phone capability to curbside parking meters, Pay-by-Space, and Pay-and-Display machines.
- the typical motivation is to provide end users an alternate way of paying for parking in an effort to increase parking revenue.
- Pay-by-Phone may be added to traditional curbside parking meters (single or double space) in order to allow end users to pay with credit cards over the phone.
- server system 140 may include a Pay-by-Phone integration module, which may be a software component that extracts parking payment information from a third party parking payment system which server system 140 uses for parking self-enforcement.
- the integration module for pay-by-phone performs steps including: (1) establishing a connection with a third-party Pay-by-Phone API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the third-party Pay-by-Phone API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection.
- an API typically specifies the mechanism through which a connection to it can be established.
- the Pay-by-Phone API typically specifie
- server system 140 determines that a particular vehicle has vacated a destination location
- server system 140 signals this event to the Pay-by-Phone integration module, such as via a database or Inter-Process Communication (IPC) call, in response to which the Pay-by-Phone integration module issues a request to the third-party Pay-by-Phone API for parking payment information for the particular vehicle.
- IPC Inter-Process Communication
- Data sent to the third-party Pay-by-Phone API may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the Pay-by-Phone API (which may require translation from an identifier used internally by server system 140 ), and a date/time the particular vehicle vacated the destination location.
- vehicle license plate information including plate number and state/province information
- identifier for the destination location recognized by the Pay-by-Phone API which may require translation from an identifier used internally by server system 140
- a date/time the particular vehicle vacated the destination location may be included in the destination location.
- the Pay-by-Phone integration module may be configured to receive information from the third-party Pay-by-Phone API including, for example, a paid parking start date/time and a paid parking end date/time.
- the Pay-by-Phone integration module may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- the Pay-by-Phone system will obtain only the vehicle detection information (actual vehicle parking start and end times) from server system 140 since typically vehicle license plate information is already possessed by the Pay-by-Phone system. The end result is the Pay-by-Phone system will have the precise information required to generate a list of vehicle license plates with parking violation details.
- the Pay-by-Phone system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data from server system 140 .
- the useful data is actual vehicle parking duration, indicating an actual amount of time a particular vehicle has occupied a specific destination location, for a particular vehicle license plate number or destination location number.
- Pay-by-Phone systems already have the vehicle license plate number or destination location number, as they are generally obtained as part of the end user payment process.
- Integration via a Pay-by-Phone API provided by server system 140 may be according to one of two options.
- First is a data inflow model, in which the third party parking payment system pushes information into server system 140 .
- Second is a data outflow model, in which server system 140 pushes all relevant information to the Pay-by-Phone system.
- server system 140 may include an inflow-based Pay-by-Phone API for use by a third-party parking payment system via, for example, network 110 , in which the third party parking payment system pushes information into server system 140 via the inflow-based Pay-by-Phone API.
- the inflow-based Pay-by-Phone API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Pay-by-Phone API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the inflow-based Pay-by-Phone API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the inflow-based Pay-by-Phone API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking.
- the received information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for a destination location for which payment was received in connection with the particular vehicle (which may require translation to an identifier used internally by server system 140 ), a paid parking start date/time, and paid parking end date/time.
- a Pay-by-Phone integration module included in server system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- server system 140 may include an outflow-based Pay-by-Phone API for use by a third-party parking payment system via, for example, network 110 , in which server system 140 pushes all relevant information to the third-party Pay-by-Phone system.
- the outflow-based Pay-by-Phone API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the outflow-based Pay-by-Phone API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the outflow-based Pay-by-Phone API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system.
- the uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140 ), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location.
- vehicle license plate information including plate number and state/province information
- an identifier for the destination location recognized by the third party parking payment system which may require translation from an identifier used internally by server system 140
- an actual date/time the particular vehicle began use of the destination location and an actual date/time the particular vehicle vacated the destination location.
- server system 140 obtains vehicle payment information from the Pay-by-Phone system (such as paid parking start and end times, parking space number, vehicle license plate number) by using the Pay-by-Phone system-provided API.
- the server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details.
- an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Pay-by-Phone system by using the API provided by server system 140 .
- the Pay-by-Phone system will then have total control over how the list of “offending” vehicles is presented to the parking operator (for example, by way of a custom software application developed by the Pay-by-Phone system vendor).
- This integration method requires minimal development effort on the part of the Pay-by-Phone system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided by server system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development.
- This integration approach represents a “pull” followed by a “push” model.
- Pay-by-Space works equally well for both on-street curbside parking and off-street parking lots/parking garages.
- Pay-by-Space is increasingly becoming popular compared to Pay-and-Display, which has a longer history of operation. Parking operations using Pay-by-Space are generally more efficient since parking enforcement personnel no longer have to walk to each vehicle and lean into the windshield in order to manually check a printed expiration time. Instead, they can drive in a patrol vehicle and perform visual checks from a distance to see whether an occupied parking space has been paid for. In addition, Pay-by-Space offers enhanced an user experience since end users no longer have to walk back to their vehicles to display the ticket after paying at the machine—instead, they can continue on to their destination.
- integration can be accomplished by using either a Pay-by-Space system-provided API or an API provided by server system 140 .
- the objective is for either system to gain access to all the information required to generate a list of vehicle license plates with parking violation information.
- server system 140 obtains vehicle payment information from the Pay-by-Space system (such as paid parking start and end times, destination location number, and vehicle license plate number). The end result is server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details.
- vehicle payment information such as paid parking start and end times, destination location number, and vehicle license plate number.
- server system 140 may include a Pay-by-Space integration module, which may be a software component that extracts parking payment information from a third party parking payment system which server system 140 uses for parking self-enforcement.
- the integration module for pay-by-space performs steps including: (1) establishing a connection with a third-party Pay-by-Space API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the third-party Pay-by-Space API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection.
- an API typically specifies the mechanism through which a connection to it can be established.
- the Pay-by-Space integration module is configured to observe the protocol
- server system 140 determines that a particular vehicle has vacated a destination location
- server system 140 signals this event to the Pay-by-Space integration module, such as via a database or Inter-Process Communication (IPC) call, in response to which the Pay-by-Space integration module issues a request to the third-party Pay-by-Space API for parking payment information for the particular vehicle.
- Data sent to the third-party Pay-by-Space API may include, for example, an identifier for the destination location recognized by the Pay-by-Space API (which may require translation from an identifier used internally by server system 140 ), and a date/time the particular vehicle vacated the destination location.
- the Pay-by-Space integration module may be configured to receive information from the third-party Pay-by-Space API including, for example, a paid parking start date/time and a paid parking end date/time.
- the Pay-by-Space integration module may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- server system 140 transmits vehicle information to the Pay-by-Space system (such as vehicle license plate number, destination location, and actual parking start and end times).
- vehicle information such as vehicle license plate number, destination location, and actual parking start and end times.
- the end result is the Pay-by-Space system will have the precise information required to generate a list of vehicle license plates with parking violation details.
- the Pay-by-Space system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data from server system 140 .
- the useful data is actual vehicle parking duration, an actual amount of time a particular vehicle has occupied a specific destination location, for a particular vehicle license plate number or space number.
- Pay-by-Space systems already have the vehicle license plate number or space number, as this may be obtained as part of the end user payment process.
- Integration via a Pay-by-Space API provided by server system 140 may be according to one of two options.
- First is a data inflow model, in which the third party parking payment system pushes information into server system 140 .
- Second is a data outflow model, in which server system 140 pushes all relevant information to the third-party Pay-by-Space system.
- server system 140 may include an inflow-based Pay-by-Space API for use by a third-party parking payment system via, for example, network 110 , in which the third party parking payment system pushes information into server system 140 via the inflow-based Pay-by-Space API.
- the inflow-based Pay-by-Space API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Pay-by-Space API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the inflow-based Pay-by-Space API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the inflow-based Pay-by-Space API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking.
- the received information for a particular vehicle may include, for example, an identifier for a destination location for which payment was received in connection with the particular vehicle (which may require translation to an identifier used internally by server system 140 ), a paid parking start date/time, and paid parking end date/time.
- a Pay-by-Space integration module included in server system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- server system 140 may include an outflow-based Pay-by-Space API for use by a third-party parking payment system via, for example, network 110 , in which server system 140 pushes all relevant information to the third-party Pay-by-Space system.
- the outflow-based Pay-by-Space API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the outflow-based Pay-by-Space API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the outflow-based Pay-by-Space API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system.
- the uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140 ), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location.
- vehicle license plate information including plate number and state/province information
- an identifier for the destination location recognized by the third party parking payment system which may require translation from an identifier used internally by server system 140
- an actual date/time the particular vehicle began use of the destination location and an actual date/time the particular vehicle vacated the destination location.
- server system 140 is configured to integrate with a Pay-by-Space system in two steps. First, server system 140 obtains vehicle payment information from the Pay-by-Space system (for example, paid parking start and end times, parking space number, vehicle license plate number) by using a Pay-by-Space system-provided API. At this stage, server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. However, instead of server system 140 presenting this list to the parking operator, there may be instances where an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Pay-by-Space system by using the API provided by server system 140 . The Pay-by-Space system will then have total control over how the list of “offending” vehicles is presented to the parking operator (such as by way of a custom software application developed by the Pay-by-Space system vendor).
- vehicle payment information for example, paid parking start and end times, parking space number, vehicle license plate number
- server system 140 will have the
- This integration method requires minimal development effort on the part of the Pay-by-Space system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided by server system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development.
- This integration approach represents a “pull” followed by a “push” model.
- Pay-and-Display The premise of a Pay-and-Display is that once an end user pays for parking, the end user needs to leave a ticket inside the vehicle on the dashboard in order for parking enforcement personnel to perform visual checks of the ticket to ensure that the period of time paid for by the end user has not expired.
- Pay-and-Display dominated off-street parking lots and parking garages. Despite the recent popularity of Pay-by-Space machines, Pay-and-Display still has a vast installed base. There are also Pay-and-Display systems deployed for curbside parking.
- server system 140 requires the following information: vehicle license plate information (including state/province), actual parking start and end times, paid parking duration.
- vehicle license plate information including state/province
- actual parking start and end times paid parking duration.
- server system 140 gathers vehicle license plate information via the identification cameras, while the destination cameras provide actual parking start and end times by allowing server system 140 to determine when a vehicle pulls into a destination location and when the vehicle leaves. Paid parking duration may be determined by utilizing destination cameras with pan, tilt, and zoom capability, and zooming in to extract a bar code or printed characters from the display ticket itself which an end user places on a vehicle dashboard.
- a Pay-and-Display machine may be configured to use a larger font for the printed characters or print larger versions of other identifying features.
- a Pay-and-Display machine may be configured to ask for a license plate number as part of a payment process, whereas a conventional system would only ask for an amount of time a driver wishes to park a vehicle.
- a Pay-and-Display machine may utilize rolls of display ticket paper with an RFID chip embedded within each display ticket.
- server system 140 may be configured to perform pedestrian tracking based on multiple images captured via one or more cameras, such as a camera including a Pay-and-Display machine within its field of view.
- server system 140 may be configured to track a driver and/or passenger of a vehicle as they walk to and/or from a vehicle for which payment is obtained via the Pay-and-Display machine, much as server system 140 performs vehicle tracking.
- the payment may be linked to a particular location for a vehicle, and a corresponding vehicle identifier, such as a license plate number, determined by server system 140 .
- a license plate number such as a license plate number
- server system 140 may receive a plurality of pedestrian images captured by one or more cameras, including one or more images demonstrating an individual was a passenger of the vehicle, and one or more images demonstrating the passenger made a payment at a Pay-and-Display payment station for use of a destination location.
- Server system 140 may be configured to perform tracking by determining whether characteristics determined for pedestrians captured in the pedestrian images correspond over time, demonstrating that the passenger traveled between the vehicle and the payment station, and made the payment. Based on this, server system 140 may associate the payment with use of a particular destination location by the vehicle.
- server system 140 is able to produce a list of vehicle license plates with detailed violation information. This holds true regardless of whether the Pay-and-Display system supports real-time wireless networking since the Pay-and-Display system itself does not possess any of the said information.
- server system 140 In an embodiment integrating server system 140 with a Pay-and-Display system via an API provided by server system 140 , to provide self-enforcement capability, server system 140 requires vehicle license plate information (including state/province information), actual parking start and end times, and paid parking duration.
- vehicle license plate information including state/province information
- Server system 140 gathers vehicle license plate information via the identification cameras, while the destination cameras allow server system 140 to determine actual parking start and end times by detecting when a vehicle pulls into a parking space and when it leaves. Paid parking duration is determined by using destination cameras with pan, tilt, and zoom functionality, enabling zooming in to extracting the bar code or printed characters from the display ticket itself which end users place on the vehicle dash.
- the Pay-and-Display API provided by server system 140 may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout.
- this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the Pay-and-Display API before data exchange is permitted.
- server system 140 may be configured to, via the Pay-and-Display API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system.
- the uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140 ), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location.
- server system 140 When server system 140 is configured to operate in this mode, server system 140 transmits vehicle parking violation information to the Pay-and-Display system (such as vehicle license plate number, paid parking start and end times, actual parking start and end times).
- vehicle parking violation information such as vehicle license plate number, paid parking start and end times, actual parking start and end times.
- the third-party Pay-and-Display system will have the precise information required to generate a list of vehicle license plates with parking violation details.
- the Pay-and-Display system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data from server system 140 .
- the useful data is the paid parking start and end times, and actual vehicle parking start and end times for a particular vehicle license plate number.
- Pay-and-Display systems are paper-based (as they rely on a printed display ticket) and do not possess any information with respect to vehicle identity or destination location number. While Pay-and-Display systems do possess paid parking start time and paid parking duration, these systems have no knowledge of which vehicle the paid parking correlates to.
- the Pay-and-Display system has the option of presenting a list of vehicles with parking violation information to the parking operator by using an API provided by server system 140 .
- the Pay-and-Display system can obtain the pertinent information from server system 140 and present it in any desired format.
- integration via the API provided by server system 140 is a “push” model where server system 140 “pushes” all relevant information to the Pay-and-Display system. Subsequently, the Pay-and-Display system displays a list of vehicle license plates with unpaid or expired parking. In other words, Pay-and-Display integration via the API provided by server system 140 is generally not accomplished in a “pull” model.
- a Pay-and-Display machine with QR codes may be provided. QR codes have become popular, and can easily hold all of the relevant information typically contained on a Pay-and-Display ticket (such as parking duration, parking expiration time, amount paid, date, and time).
- a Pay-by-Phone system may overlay a Pay-and-Display parking system, and server system 140 may be integrated with the Pay-by-Phone payment system via API.
- server system 140 will transmit vehicle detection information to the Pay-by-Phone system since typically the vehicle license plate information is already possessed by the Pay-by-Phone system. The end result is the Pay-by-Phone system will have the information required to generate a list of vehicle license plates with parking violation details.
- curbside parking meters single or double space
- Pay-by-Phone has become a popular “overlay” payment approach which works well with traditional curbside parking meters.
- curbside parking meters which accept both coins and credit cards, and have networking capability built-in.
- Traditional parking meters generally have either a mechanical or an LCD display “expired flag” to indicate that a paid parking period has expired or parking is simply not paid.
- the mechanical expired flag typically red
- the LCD display shows a clear display on the side of the meter facing the roadway.
- the red mechanical expired flag is prominently displayed in the “up” position, while the LCD display facing the roadway flashes alternately between a clear display and a dark display (sometimes also with a flashing red LED). Both of these are generally referred to as an expired flag.
- server system 140 can interface with traditional curbside parking meters using a combination of information gathered from both identification and destination cameras.
- images captured by the identification and destination cameras can pinpoint paid parking status (such as, but not limited to, whether a prepaid time has expired) on the parking meters.
- Server system 140 gathers vehicle license plate information via the images captured by identification cameras, while images captured by destination cameras enable server system 140 to determine actual parking start and end times by detecting when a vehicle pulls into a parking space and when it leaves. Time of expiration of paid parking is determined by zooming in with both location and destination cameras and monitoring the visible status of the expiration flag on each parking meter. Based on this information, server system 140 may determine parking violation status, and mark use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic. In situations where an expiration flag is not readable by server system 140 , server system 140 may be configured to indicate an exception to a parking operator or staff and/or make use of a Live Operator (discussed below) to manually determine parking violation status and/or exception flag status.
- Live Operator discussed below
- server system 140 is able to produce a list of vehicle license plates with detailed violation information.
- server system 140 In an embodiment integrating server system 140 with a Traditional Curbside Parking Meter system via an API provided by server system 140 , to provide self-enforcement capability, server system 140 requires vehicle license plate information (including state/province information), actual parking start and end times, and paid parking duration.
- vehicle license plate information including state/province information
- actual parking start and end times including paid parking duration.
- Server system 140 gathers vehicle license plate information via the images captured by identification cameras, while images captured by destination cameras enable server system 140 to determine actual parking start and end times by detecting when a vehicle pulls into a parking space and when it leaves. Time of expiration of paid parking is determined by zooming in with both location and destination cameras and monitoring the visible status of the expiration flag on each parking meter. Based on this information, server system 140 may determine parking violation status, and mark use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic. In situations where an expiration flag is not readable by server system 140 , server system 140 may be configured to indicate an exception to a parking operator or staff and/or make use of a Live Operator (discussed below) to manually determine parking violation status and/or exception flag status.
- Live Operator discussed below
- the Traditional Curbside Parking Meter API provided by server system 140 may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout.
- this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the Traditional Curbside Parking Meter API before data exchange is permitted.
- server system 140 may be configured to, via the Traditional Curbside Parking Meter API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system.
- the uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140 ), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location.
- server system 140 When server system 140 is configured to operate in this mode, server system 140 transmits vehicle parking violation information to the Traditional Curbside Parking Meter system, which is typically a payment collection/tallying system with no connectivity to the actual curbside meters.
- the Traditional Curbside Parking Meter system will have the precise information required to generate a list of vehicle license plates with parking violation details.
- the Traditional Curbside Parking Meter system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data from server system 140 .
- the useful data is the expired or unpaid parking status, and actual vehicle parking start and end times for a particular vehicle license plate number.
- Traditional Curbside Parking Meter systems do not possess any information with respect to vehicle identity or space number.
- server system 140 “pushes” all relevant information to the Traditional Curbside Parking Meter system. Subsequently, the Traditional Curbside Parking Meter system displays a list of vehicle license plates with unpaid or expired parking.
- a Pay-by-Phone system may overlay a traditional curbside parking system, and server system 140 may be integrated with the Pay-by-Phone payment system via API.
- server system 140 will transmit vehicle detection information to the Pay-by-Phone system since typically the vehicle license plate information is already possessed by the Pay-by-Phone system. The end result is the Pay-by-Phone system will have the information required to generate a list of vehicle license plates with parking violation details.
- curbside parking meters single or double space
- server system 140 can be configured to interface with this type of parking meters through a Curbside Parking Meter API.
- these curbside parking meters already have built-in wireless network connectivity and an associated backend server, it is not difficult for server system 140 to integrate with this third-party backend server.
- an integration module for the Curbside Parking Meter API performs steps including: (1) establishing a connection with a third-party Curbside Parking Meter API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the Curbside Parking Meter API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection.
- an API typically specifies the mechanism through which a connection to it can be established.
- the integration module for the Curbside Parking Meter API is configured to observe the protocol required by the Curbside Parking Meter API and establishes a connection.
- server system 140 determines that a particular vehicle has vacated a destination location
- server system 140 signals this event to the integration module for the Curbside Parking Meter API, such as via a database or Inter-Process Communication (IPC) call, in response to which the integration module for the Curbside Parking Meter API issues a request to the third-party Curbside Parking Meter API for parking payment information for the particular vehicle.
- Data sent to the third-party Curbside Parking Meter API may include, for example, an identifier for the destination location recognized by the Curbside Parking Meter API (which may require translation from an identifier used internally by server system 140 ), and a date/time the particular vehicle vacated the destination location.
- the integration module for the Curbside Parking Meter API may be configured to receive information from the third-party Curbside Parking Meter API including, for example, an identifier for the destination location recognized by the Curbside Parking Meter API (which may require translation to an identifier used internally by server system 140 ), a paid parking start date/time, and a paid parking end date/time.
- the integration module for the Curbside Parking Meter API may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- integration via Curbside Parking Meter API is a “pull” model where server system 140 “pulls” all relevant information the third-party Curbside Parking Meter system is capable of outputting, and adds automated vehicle violation information determined by server system 140 to produce a list of vehicle license plates with unpaid or expired parking.
- integration via Curbside Parking Meter API is generally not accomplished in a “push” model.
- server system 140 In an embodiment in which server system 140 is configured to integrate with a Curbside Parking Meter system via an API provided by server system 140 , server system 140 transmits vehicle information to the Curbside Parking Meter system (such as vehicle license plate number, destination location, and actual parking start and end times). The end result is the Curbside Parking Meter system will have the precise information required to generate a list of vehicle license plates with parking violation details.
- vehicle information such as vehicle license plate number, destination location, and actual parking start and end times.
- the Curbside Parking Meter system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data from server system 140 .
- the useful data is actual vehicle parking duration, the actual amount of time a particular vehicle has occupied a specific destination location, for a particular vehicle license plate number or destination location number.
- Curbside Parking Meter systems already have the vehicle license plate number or space number, as this information may be obtained as part of the end user payment process.
- Integration via a Curbside Parking Meter API provided by server system 140 may be according to one of two options.
- First is a data inflow model, in which the third party parking payment system pushes information into server system 140 .
- Second is a data outflow model, in which server system 140 pushes all relevant information to the Curbside Parking Meter system.
- server system 140 may include an inflow-based Curbside Parking Meter API for use by a third-party parking payment system via, for example, network 110 , in which the third party parking payment system pushes information into server system 140 via the inflow-based Curbside Parking Meter API.
- the inflow-based Curbside Parking Meter API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Curbside Parking Meter API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the inflow-based Curbside Parking Meter API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the inflow-based Curbside Parking Meter API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking.
- the received information for a particular vehicle may include, for example, an identifier for a destination location for which payment was received in connection with the particular vehicle (which may require translation to an identifier used internally by server system 140 ), a paid parking start date/time, and a paid parking end date/time.
- a Curbside Parking Meter integration module included in server system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- server system 140 may include an outflow-based Curbside Parking Meter API for use by a third-party parking payment system via, for example, network 110 , in which server system 140 pushes all relevant information to the third-party Curbside Parking Meter system.
- the outflow-based Curbside Parking Meter API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the outflow-based Curbside Parking Meter API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the outflow-based Curbside Parking Meter API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system.
- the uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140 ), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location.
- vehicle license plate information including plate number and state/province information
- an identifier for the destination location recognized by the third party parking payment system which may require translation from an identifier used internally by server system 140
- an actual date/time the particular vehicle began use of the destination location and an actual date/time the particular vehicle vacated the destination location.
- server system 140 may be configured to integrate with a Curbside Parking Meter system in two steps. First, server system 140 obtains vehicle payment information from the Curbside Parking Meter system (such as paid parking start and end times, parking space number, vehicle license plate number) by using the Curbside Parking Meter system-provided API. At this stage, server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. However, instead of server system 140 presenting this list to a parking operator, there may be instances where an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Curbside Parking Meter system by using an API provided by server system 140 . The Curbside Parking Meter system will then have total control over how the list of “offending” vehicles is presented to the parking operator (such as by use of a custom software application developed by the Curbside Parking Meter system vendor).
- vehicle payment information such as paid parking start and end times, parking space number, vehicle license plate number
- server system 140 will have the precise
- This integration method requires minimal development effort on the part of the Curbside Parking Meter system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided by server system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development.
- This integration approach represents a “pull” followed by a “push” model.
- Pay-by-Plate Similar to Pay-by-Space where a parking payment is associated with a particular numbered parking space (in which a vehicle parks), Pay-by-Plate associates a parking payment to a vehicle with a particular license plate parked in a parking space.
- Manual enforcement of Pay-by-Plate parking typically involves the enforcement officer driving past the physical parking space to ensure license plates of all parked vehicles are on a list of license plates with paid status. Conversely, any parked vehicles with license plates not on the “paid” list would receive a parking citation.
- integration can be accomplished by using either a Pay-by-Plate system-provided API or an API provided by server system 140 .
- the objective is for either system to gain access to all the information required to generate a list of vehicle license plates with parking violation information.
- server system 140 obtains vehicle payment information from the Pay-by-Plate system (such as paid parking start and end times and vehicle license plate numbers). The end result is server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details.
- server system 140 may include a Pay-by-Plate integration module, which may be a software component that extracts parking payment information from a third party parking payment system which server system 140 uses for parking self-enforcement.
- the integration module for pay-by-plate performs steps including: (1) establishing a connection with a third-party Pay-by-Plate API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the third-party Pay-by-Plate API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection.
- an API typically specifies the mechanism through which a connection to it can be established.
- the Pay-by-Plate integration module is configured
- server system 140 determines that a particular vehicle has vacated a destination location
- server system 140 signals this event to the Pay-by-Plate integration module, such as via a database or Inter-Process Communication (IPC) call, in response to which the Pay-by-Plate integration module issues a request to the third-party Pay-by-Plate API for parking payment information for the particular vehicle.
- Data sent to the third-party Pay-by-Plate API may include, for example, vehicle license plate information (including plate number and state/province information), and a date/time the particular vehicle vacated the destination location.
- the Pay-by-Plate integration module may be configured to receive information from the third-party Pay-by-Plate API including, for example, a paid parking start date/time and a paid parking end date/time.
- the Pay-by-Plate integration module may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- server system 140 transmits vehicle information to the Pay-by-Plate system (such as vehicle license plate number, destination location, and actual parking start and end times).
- vehicle information such as vehicle license plate number, destination location, and actual parking start and end times.
- the end result is the Pay-by-Plate system will have the precise information required to generate a list of vehicle license plates with parking violation details.
- the Pay-by-Plate system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data from server system 140 .
- the useful data is actual vehicle parking duration, an actual amount of time a particular vehicle has occupied a destination location, for a particular vehicle license plate number.
- Pay-by-Plate systems already have the vehicle license plate number, as this is obtained as part of the end user payment process.
- Integration via a Pay-by-Plate API provided by server system 140 may be according to one of two options.
- First is a data inflow model, in which the third party parking payment system pushes information into server system 140 .
- Second is a data outflow model, in which server system 140 pushes all relevant information to the third-party Pay-by-Plate system.
- server system 140 may include an inflow-based Pay-by-Plate API for use by a third-party parking payment system via, for example, network 110 , in which the third party parking payment system pushes information into server system 140 via the inflow-based Pay-by-Plate API.
- the inflow-based Pay-by-Plate API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data to database 141 ; (5) determining parking violation status; (6) marking use of a destination location as a parking violation in database 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Pay-by-Plate API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the inflow-based Pay-by-Plate API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the inflow-based Pay-by-Plate API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking.
- the received information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), a paid parking start date/time, and paid parking end date/time.
- a Pay-by-Plate integration module included in server system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by server system 140 . If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed.
- server system 140 may include an outflow-based Pay-by-Plate API for use by a third-party parking payment system via, for example, network 110 , in which server system 140 pushes all relevant information to the third-party Pay-by-Plate system.
- the outflow-based Pay-by-Plate API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout.
- step (1) this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection.
- the third party parking payment system is required to authenticate itself through the outflow-based Pay-by-Plate API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped.
- server system 140 may be configured to, via the outflow-based Pay-by-Plate API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system.
- the uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140 ), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location.
- vehicle license plate information including plate number and state/province information
- an identifier for the destination location recognized by the third party parking payment system which may require translation from an identifier used internally by server system 140
- an actual date/time the particular vehicle began use of the destination location and an actual date/time the particular vehicle vacated the destination location.
- server system 140 is configured to integrate with a Pay-by-Plate system in two steps. First, server system 140 obtains vehicle payment information from the Pay-by-Plate system (for example, paid parking start and end times, and vehicle license plate number) by using a Pay-by-Plate system-provided API. At this stage, server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. However, instead of server system 140 presenting this list to the parking operator, there may be instances where an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Pay-by-Plate system by using the API provided by server system 140 . The Pay-by-Plate system will then have total control over how the list of “offending” vehicles is presented to the parking operator (such as by way of a custom software application developed by the Pay-by-Plate system vendor).
- vehicle payment information for example, paid parking start and end times, and vehicle license plate number
- server system 140 will have the
- This integration method requires minimal development effort on the part of the Pay-by-Plate system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided by server system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development.
- This integration approach represents a “pull” followed by a “push” model.
- Live Operator team as part of the system illustrated in FIG. 1 warrants consideration and may offer a practical option to offer to prospective parking operators as a value added feature.
- server system 140 autonomously receives and processes images obtained from the identification and destination cameras, there are typically live operators who monitor obtained images and software executing on server system 140 . These live operators can review operation of server system 140 and take appropriate actions on an exception basis if required. For example, when unexpected problems occur, Live Operators can review images related to the problems and deduce information that server system 140 may not be configured to handle.
- An advantage with the networked architecture supported by server system 140 is that a single Live Operator team can oversee or augment operations at multiple sites regardless of their respective geographic locations or the fact that the facility operations may be owned by different parking operations or even competitors.
- the Live Operator option can be a scalable and cost-effective approach for parking operators.
- IP multicast or similar standard TCP/IP protocol a video stream can effectively be sent simultaneously to multiple destinations, thereby allowing the Live Operator option to be added at a future date in addition to local on-site monitoring staffed by the parking operators.
- Pay-and-Display and curbside meter configurations discussed above may present significant real life challenges. Not only are cameras with a high level of zoom are required, there are also potential problems such as that an angle of view from a particular video camera may not be sufficient to properly detect an expiration flag of a traditional curbside parking meter, or a bar code on a Pay-and-Display ticket on a vehicle dashboard may be facing away from any of the video cameras due to the physical three dimensional shape of the dashboard and the placement of the ticket itself.
- server system 140 can generate exception events to the Live Operator when server system 140 fails to automatically detect a key piece of information such as license plate number, status of an expiration flag on a traditional parking meter, or bar code/printed information on a Pay-and-Display ticket.
- a key piece of information such as license plate number, status of an expiration flag on a traditional parking meter, or bar code/printed information on a Pay-and-Display ticket.
- Such an exception event may trigger a Live Operator to take a number of specific actions, including but not limited to Rewind/Fast Forward/Pause/Freeze-Frame FWD & RWD specific footages captured by identification and/or destination cameras, zoom in/out on particular areas of interest in the captured footages, Pan/Tilt/Zoom video cameras in real-time in order to obtain enhanced images, and dispatch on-site personnel to perform inspection of a vehicle or parking meter, either visually of by use of mobile device 150 to obtain enhanced images for use by server system 140 .
- specific actions including but not limited to Rewind/Fast Forward/Pause/Freeze-Frame FWD & RWD specific footages captured by identification and/or destination cameras, zoom in/out on particular areas of interest in the captured footages, Pan/Tilt/Zoom video cameras in real-time in order to obtain enhanced images, and dispatch on-site personnel to perform inspection of a vehicle or parking meter, either visually of by use of mobile device 150 to obtain enhanced images for use by server system
- server system 140 is configured to correlate a mailing address of a registered owner of a vehicle with its license plate number, allowing a parking operator to collect parking citation revenue.
- Red-light camera systems utilize such a mechanism to have citation tickets mailed to registered owners of the vehicles.
- parking operators are in three different categories.
- server system 140 only needs to supply a list of Vehicle License Plate Numbers with state/province information along with parking violation details (such as date, time, and location) in order for citations to be mailed to registered owners.
- DPPA Driver's Privacy Protection Act
- name and address information of a third-party vehicle owner may not be released online, but instead must be obtained either by mail or in person.
- private parking operators may wish to obtain name and address information on a batched basis (such as daily, every 2 or 3 days, or weekly).
- end user systems 170 can include in-vehicle systems.
- new vehicle dashboards straight from car manufacturers can include an indicator icon, similar to other dashboard lights such as “check engine,” parking-brake warnings, or cruise-control indicator lights.
- This indicator icon is normally not illuminated when vehicle 130 is driving on the highway or not inside a perimeter serviced by server system 140 . As vehicle 130 approaches parking lots or curbside parking areas, the indicator icon may light up in amber advising an end user of the availability of automated parking services provided by server system 140 . When vehicle 130 pulls into a destination location, such as a parking space, the indicator icon turns red to notify the end user that parking has not been paid.
- the indicator icon turns green to signify parking has been paid.
- these visual indications may be accompanied by audio notifications, which may be simple chimes or voice announcements. Audio output may be performed by providing audio information or data to a vehicle entertainment unit.
- this invention enables many aspects of parking payment and enforcement processes to be automated, it is important to provide feedback to end users as to what the server system 140 is doing or a particular state server system 140 has associated with vehicle 130 (for example, whether vehicle 130 has committed a parking violation). End users can then react accordingly to the feedback provided. While operating within a highly automated payment and enforcement system, it is a reasonable expectation that end users or registered owners do not get penalized for minor or administrative errors. Feedback provided via a simple interface such as the dashboard indicator icon can greatly alleviate this concern.
- server system 140 is not able to apply a parking charge. This feedback provides the end user the opportunity to, for example, visit a website provided by or in connection with server system 140 to query his/her account status and correct the error.
- dashboard indicator icon can get its information from, including built-in cellular data or WiFi vehicle connectivity, or smart sensors (discussed below).
- smart sensors discussed below.
- end users may be provided with a retrofit kit in the form of a visual module which receives information by way of Bluetooth, cellular data, or WiFi connectivity.
- the indicator icon feature receives GPS location data from third-party in-vehicle subsystems via a vehicle wiring harness.
- the GPS data allows the indicator icon feature to determine whether vehicle 130 is currently in a paid parking zone.
- smart sensors can be designed into new vehicles straight from the factory. Using technology similar to the ZigBee IEEE 802.15.4 standard, low cost, low power, short range wireless mesh networks can be created among vehicles as well as between vehicles and parking equipment. Each vehicle becomes a node, and a node can communicate with a distant end-point by relaying data through intermediate nodes by forming a mesh network. Each smart sensor contains a unique identifier, such that license plate information is no longer critical.
- smart sensors may be configured to communicate with server system 140 via a cellular data connection and/or provide Pay-by-Phone functionality, whereby payment for use of a destination location may be made via the smart sensor.
- the smart sensors can include a GPS receiver or communicate with an in-vehicle GPS to determine a present location of vehicle 130 and report the present location to server system 140 .
- GPS techniques such as assisted GPS
- a location determined via GPS may have enough accuracy and precision to determine the vehicle is making use of a particular destination location.
- These sensors can also communicate with parking meters and in essence report the presence of the vehicle and how long it has been parked for. This parking information can be relayed to a distant device/network through the mesh network so the parking equipment does not need to be located within the vicinity of the vehicle.
- use of the identification and destination cameras is not necessary, as the embedded smart sensor already provide a unique identity of the vehicle to server system 140 .
- vehicles may be equipped with a near-field communication (NFC) device, such as an RFID chip.
- NFC near-field communication
- a communication device may be included in a mirror hanger.
- an RFID chip may be embedded in a ticket provided by a Pay-and-Display device.
- the smart sensors can sense the status of other vehicles nearby (such as, but not limited to, whether they are moving, parked, and for what duration they have been parked) and report the status to server system 140 .
- server system 140 is aware as to where almost any smart sensor-equipped vehicle is parked and for how long. By combining this information with parking payment information from either third-party systems or turnkey platforms, it is possible to determine the identity of vehicles that did not pay for parking or with expired parking, and have parking violation tickets mailed to the registered owners or even charging a parking fine on the spot (for example, by charging a credit card on file).
- a destination camera can be provided with laser status notification. Similar to laser logo devices seen at shopping malls and retail outlets, the laser status notification feature shines a nonharmful flashing red light enveloping a parked vehicle to notify an end user upon return that parking was not paid or has expired. This is akin to returning to a vehicle and seeing a parking ticket clipped under the windshield wiper under the traditional manual parking enforcement model. As a destination camera is typically located at elevation with respect to vehicles, an included laser status notification module has a bird's eye view to below destination locations to facilitate shining laser notification onto vehicles and destination locations.
- laser status notification feature replaces the need to mail out paper parking violation tickets. Once an end user receives a laser notification for a parking violation, the end user can then be expected to pay the parking fine through a number of media including, but not limited to, an online website or Pay-by-Phone. Furthermore, laser status notifications can be captured by the destination camera to provide later evidence of the parking violation and notification.
- dynamic real-time Individual Parking Space Reservation is a feature made possible by an online/phone/smart phone parking space reservation system, and may be further enhanced with the laser status notification feature. While currently some vendors offer parking space reservation feature, the feature is limited to space reservation in the general vicinity of parking spaces (for example, somewhere on a parking lot) as there is no practical method of physically reserving a single, particular parking space in an automated fashion. In addition, the reserved spaces are typically held open for a long period of time because there is also no practical way of knowing when a reserved parking spot becomes available again after the driver who reserved the space has parked and subsequently driven off.
- the dynamic real-time Individual Parking Space Reservation feature allows end users to pinpoint the exact parking space they desire (for example, a space closest to a shopping mall during Christmas shopping period), for a specified period of time (for example, a destination location may be reserved for use during some day in the future).
- a laser notification may be shined on the parking spot to indicate that the destination location is reserved (providing, for example, a red color as a warning to other drivers).
- the use of a destination location during a reserved period by another vehicle will result in a parking violation. This enables a parking operator to increase revenue by offering both tiered/premium parking spots, and advance reservation of parking spaces.
- a parking operator may designate particular destination locations as restricted only for use by vehicles for which a reservation has been made.
- server system 140 may determine a number of available reserved destination locations for a given time, and price reservations according to how many unreserved destination locations remain available.
- server system 140 may be configured to allow buyers to submit competing bids for the use of reserved destination locations.
- a Pay-by-Phone feature can be offered either directly on a turnkey platform or through a partnership with a third-party vendor.
- the end result is that end users can pay for parking by calling a particular IVR phone line, input a destination location number or vehicle license plate number, and a duration of parking.
- Pay-Online is a variation along the same theme to support online payment for parking, typically via a website accessible via a web-enabled smartphone.
- a “push” technology feature can be incorporated where as soon as an end user parks vehicle 130 , the end user receives a text message or other notification prompting for an affirmative reply to charge a specific parking rate until vehicle 130 leaves a destination location.
- Server system 140 identifies vehicle 130 via an identification camera, and further determines that vehicle 130 is associated with a pre-registered end user with credit card or other billing information and a cellular phone number or other contact information on record. Once server system 140 determines via a destination camera that vehicle 130 has parked in a destination location, server system 140 initiates a “push” sequence to actively notify and engage the driver for payment or confirmation of payment. By simplifying the payment process, improved parking revenue is realized.
- any “leftover” paid parking time can be reset to zero.
- curbside meters as these typically do not have any communication capability or the intelligence to activate the expiration flag prior to time expiration.
- Server system 140 may be configured to provide a push technology software component that enhances the user experience when it comes to paying for parking.
- Push technology supports functions such as: (1) initiating a payment sequence via text message; (2) allowing a pre-registered user to take a photo of their license plate, then provide the photo to server system 140 by way of, for example, email or text-message; (3) allowing a non-registered user to take a photo of their license plate, then provide the photo to server system 140 by way of, for example, email or text-message; and (4) allowing drivers to sign up once to not get parking fees under a subscription-based model.
- the push technology component interacts with vehicle identifier detection logic, vehicle detection logic, database 141 , and a payment gateway.
- the push technology component pushes a text message indicating that use of the destination location has begun, to a mobile phone number registered with server system 140 .
- a credit card associated with the registered account may then get charged an appropriate usage fee, such as, but not limited to, a flat-rate parking fee for use of the destination location.
- a driver who has pre-registered with server system 140 may take photos of their license plate, then email or text-message the photo to server system 140 .
- a credit card associated with a registered account for the pre-registered user then gets charged a usage fee.
- a driver may take a photo of the license plate, then email/text-message the photo to server system 140 .
- usage charges may be added to a user's monthly mobile device bill.
- a driver may sign up once to automatically pay for all usage fees (or at least all parking fees) with a registered credit card.
- the push technology software component may also be configured to automatically send a text message to a user In the event that server system 140 determines inappropriate use of a destination location, such as parking a vehicle in a “no parking” area.
- Server system 140 may be configured to provide a parking violation pre-processing logic software component that examines all occurrences of destination location usages newly identified as violations and assigns them to a corresponding destination as specified in a system configuration, such as the license plate lookup module or the license plate forward module, discussed below.
- the parking violation pre-processing logic software component interacts with database 141 , the system configuration utility, and third-party APIs.
- the parking violation pre-processing logic software component may be configured to: (1) enqueue violations identified by other software processes included in server system 140 ; (2) examine the next violation in the queue; (3) validate the destination location usage is a violation by verifying rules established via the system configuration utility in connection with the destination location and detected use of the destination location by a vehicle; (4) assign the violation to license plate processing logic; and (5) examine any other enqueued violations or await an identification of a later violation.
- Server system 140 may be configured to determine whether a vehicle has an expired tag from an identification image.
- the identification image may be captured using a fixed Identification camera 120 , although at typical distances and vehicle speeds, and the small size of the typical expiration date indicator on a license plate, determining whether a vehicle bears an expired tag from the identification image alone is generally not possible.
- a PTZ-capable camera zoomed into a license plate of a stationary vehicle, either with an Identification camera or destination camera, it may be possible to zoom into a license plate to obtain enough detail to determine whether a vehicle bears an expired tag from the obtained image alone.
- the identification image instead can be captured via a mobile or handheld camera, including, for example, a camera included in a smartphone or mobile device 150 .
- server system 140 may be configured to query, via an API to a municipal database, determine whether a vehicle registration for a particular license plate number is expired. Server system 140 may be configured to, in the event it determines a vehicle is bearing an expired tag, report the vehicle to a municipality.
- Server system 140 may be configured to provide a license plate processing logic software component that takes an identified destination location usage violation, such as a violation assigned by the parking violation pre-processing logic component, and converts it into an actionable item for either a Registered Owner (RO)/user of a vehicle involved in the destination location usage violation, or for a parking operator responsible for the destination location.
- the actionable item can be in the form of a parking citation automatically mailed to the registered owner, or a license plate number displayed on a screen at a parking operations office.
- the license plate processing logic software component interacts with the parking violation pre-processing logic software component, system configuration utility, and database 141 .
- the license plate processing logic component may be configured to check one or more business rules specified via the system configuration utility in connection with the destination location to determine the appropriate actionable item. For example, if a business rule specifies license plate lookup, a specific type of license plate lookup may also be specified, such as via an API provided by a municipality, or an API provided by a private business. Then license plate lookup is performed as specified. Also, business rules may identify sub-options such as mailing out parking tickets to a registered owner via API, or just providing a mailing address for a registered owner and any other associated information for the violation to the parking operator. In another example, if a business rule specifies license plate information forwarding, the license plate processing logic component checks to see the specific type of license plate information forwarding specified, and forwards the license plate information accordingly.
- a license plate database such as one provided by a private business, must exist and be available for searches for license plates belonging to a particular state/province for the license plate. Also, use of such a database must be reasonable in terms of any fees involved to such lookup is commercially viable.
- an alternative option may include providing the license plate in question to a municipal body, which typically has access to license plate records via the local police branch or otherwise.
- the license plate processing logic software component may include a license plate lookup and followup submodule.
- the license plate lookup and followup submodule may be configured to make an API call to a license plate database to retrieve the mailing address for a registered owner of a vehicle.
- databases include an HTTP-based Dial-in Search Account API provided by the New York State Department of Motor Vehicles, database services provided by the American Association of Motor Vehicle Administrators (AAMVA) or other insurance companies, and online collections of public records, such as PublicData.com (although many such collections are less reliable than government or commercially managed databases, thus possibly requiring additional efforts to ensure information is valid and accurate).
- the license plate lookup and followup submodule may be configured to automatically mail a parking citation to a registered owner associated with a vehicle that has misused a destination location.
- the process of mailing may be automated via an API call to a printing/mailing service such as, but not limited to, L-Mail.com.
- the license plate lookup and followup submodule may be configured to create, maintain, and review records in database 141 to see if a given vehicle identifier (such as a license plate) is associated with prior misuse of a destination location within a specified period of time (which is configurable via, for example, the system configuration utility), If so, the license plate lookup and followup submodule may presume that the previously obtained address remains valid and accurate, skip the API call, and mail a citation using the previously obtained mailing address in the system in order to lower operating expenses associated with API calls. In the event that the parking citation has not been paid after a specified number of days (actual duration also configurable via, for example, the system configuration utility) or the citation is returned as undeliverable, a subsequent API call may be made to obtain a current address.
- a given vehicle identifier such as a license plate
- a parking violation such as, but not limited to, when paid parking expires or a vehicle is parked without payment
- server system 140 may be configured to notify one or more enforcement officers with a location of a destination location, such as a longitude and latitude or an approximate street address. An enforcement officer then may go to the offending vehicle and issue a citation on the spot.
- server system 140 may be configured to identify and/or locate an individual enforcement officer who is best suited to deal with a particular offending vehicle. Factors for making this identification may include, for example, the distance from the offending vehicle or workload of an enforcement officer, or whether an offending vehicle is to be towed (for example, where an offending vehicle must be promptly removed).
- offending vehicles may have to be enqueued where, for example, there are too few enforcement officers or a particular enforcement officer has multiple offending vehicles to handle. In an embodiment, multiple enforcement officers may be notified of nearby offending vehicles, and individual enforcement officers may accept to handle particular offending vehicles.
- Server system 140 may also be configured to track enforcement officer performance, which may be used in connection with a reward or quota system for the enforcement officers.
- an enforcement officer may be equipped with a mobile device 150 , and mobile device 150 may be configured to preprint a citation for an offending vehicle to reduce an amount of time taken to deliver the citation to the vehicle.
- Server system 140 may be configured to provide dynamic variable-rate parking fees.
- server system 140 may record different parking rates for a destination location which vary according to time of day and/or day of the week, for example.
- server system 140 may be configured to determine a total fee for use of the destination location based the first rate being applied from the beginning of the use of the destination location until the second rate applies, and the second rate being applied for the remaining time the vehicle occupies the destination location.
- server system 140 may be configured to determine a number of vehicles which may be accommodated by the destination locations available in a given area, and base a fee or rate for parking on the determined number of vehicles. For example, as server system 140 determines this number decreases (for example, because there are fewer remaining destination locations), it may apply a higher rate for vehicles which begin to make use of the few remaining locations.
- Server system 140 may be configured to allow a parking provider, via an API or the configuration utility, specify particular events for which a specified parking rate or flat fee is to be applied for specified destination locations. For example, if a concert occurs from 7-11 PM at a venue associated with or near a parking facility, the parking facility may levy a flat $10 fee for vehicles parked after 4 PM that same evening.
- Server system 140 may be configured to provide a no-fine feature, where a driver may leave a vehicle parked in a destination location for as long as they wish, and have a credit card or other account billed for according to rules established for the destination location (such as, but not limited to, per-hour or flat rate per-day fees).
- a text message or email may be pushed or otherwise sent to the driver indicating that the no-fine feature is available for the destination location, and allowing the driver to elect use of the no-fine feature, such as by replying with a message such as “yes” or “no fine”.
- server system 140 may be configured to generally make the no-fine feature available for all unrestricted destination locations in specified areas or throughout the destination locations tracked by server system 140 . However, server system 140 may be configured not to offer the no-fine feature for a restricted destination location, such as, for example, a destination location subject to a 3-6 PM “no parking” rush hour restriction.
- server system 140 may be able to perform profiling based on 3D outline of the vehicle. For example, such profiling may be able to roughly profile a vehicle as belong to a category such as, but not limited to, sport utility vehicle (SUV), van, sedan, coupe, or motorcycle. In addition, a vehicle may be categorized as having a light or dark color.
- the vehicle profiling can serve non-parking applications, such as, but not limited to, assisting police tracking of stolen vehicles within a certain vicinity, Amber alert, Homeland Security needs. In an embodiment, the vehicle profiling can be used to provide additional vehicle characteristics for comparisons performed in tracking a vehicle from one tracking camera to another.
- the vehicle profiling may provide an additional layer of confirmation of an identity of a vehicle for an automated parking citation mailing process.
- manual 3D vehicle profiles are provided to server system 140 .
- one manual 3D vehicle profile for a Chevrolet Impala may describe a ratio of 1:2:1 for height of hood to height of passenger compartment to height of trunk.
- a laser transmitter which may be integrated with an actuated beam-deflecting mirror, may be configured to shine a laser beam onto one or more destination locations.
- the laser beam may shine on a retroreflector mounted on or around a destination location to provide a return signal to a receiver associated with the laser transceiver.
- server system 140 may be configured to obtain a destination image and/or an identifier image with a nearby camera.
- server system 140 may be configured to, in addition to the aforementioned uses involving vehicle identification, also use an identification camera as a “red light camera” for the detection of events in which a vehicle incorrectly proceeds through an intersection controlled by a traffic light. For example, as a traffic light changes from amber to red, vehicles incorrectly proceeding through a late amber or red light may be identified, along with a captured vehicle license plate, such that server system 140 is configured to simultaneously utilize an imaging camera for both purposes. Alternatively or in addition, server system 140 may be configured to use an identification camera to detect “block the box” moving violations, where a vehicle remains within an intersection during a red light for the vehicle's direction of travel, which may lead to gridlock high-traffic situations.
- server system 140 may be configured to provide real-time vehicle tracking services for third parties such as, but not limited to, repossession companies (for locating vehicles with outstanding loan payments), law enforcement, homeland security.
- Server system 140 may provide an API by which such third-party entities may register vehicles of interest by, for example, a vehicle identifier such as a license plate.
- a vehicle identifier such as a license plate.
- the registering party may be notified. Notifications may be provided in connection with an initial detection of the vehicle and/or when the vehicle is determined to have stopped.
- records of the movements of a registered vehicle may be retained by server system 140 , and made accessible, for example, via a map-based web interface, which may be configured to present updated information in real-time.
- the API may also allow a third party to designate an area of interest, for which server system 140 is configured to perform identification and tracking of any vehicles determined to have entered the area of interest.
- Server system 140 may also be configured to provide images of registered vehicles obtained by the tracking cameras.
- any archived tracking information such as the past use of destination locations, may also be made available to reconstruct a person's whereabouts over time (assuming the person is connected with the vehicle).
- server system 140 may be configured to obtain vehicle images including an image of a driver's face, and may further be configured to perform facial recognition techniques to confirm facial characteristics of the driver correspond to a person of interest.
- server system 140 may be configured to determine and provide traffic count information, such as the number of vehicles determined to have traversed a given portion of roadway. Such information may be employed for purposes including, but not limited to, dynamic control of traffic systems such as traffic lights in response to currently observed traffic counts, and for determining construction requirements based on traffic counts observed over time.
- the traffic count information may include and/or be filtered on the basis of time and/or date, and/or determined vehicle characteristics, including, but not limited to, direction of travel and vehicle size or type (such as SUV, truck, car, or motorcycle).
- server system 140 may determine vehicle counts in connection with a direction of entry and/or exit for a portion of roadway, such as, for example, how many vehicles were northbound or southbound upon exiting an eastbound portion of roadway, based on a direction each vehicle exits an intersection.
- server system 140 may be configured for use in controlling access to and/or levy a toll upon vehicles by type, such as assessing a fee for the use of specified roadways by large trucks.
- FIG. 5 is a block diagram that illustrates a computer system 500 upon which aspects of the invention may be implemented.
- Computer system 500 includes a bus 502 or other communication mechanism for communicating information, and a processor 504 coupled with bus 502 for processing information.
- Computer system 500 also includes a main memory 506 , such as a random access memory (RAM) or other dynamic storage device, coupled to bus 502 for storing information and instructions to be executed by processor 504 .
- Main memory 506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504 .
- Computer system 500 further includes a read only memory (ROM) 508 or other static storage device coupled to bus 502 for storing static information and instructions for processor 504 .
- ROM read only memory
- a storage device 510 such as a magnetic disk or optical disk, is provided and coupled to bus 502 for storing information and instructions.
- Computer system 500 may be coupled via bus 502 to a display 512 , such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user.
- a display 512 such as a cathode ray tube (CRT) or liquid crystal display (LCD)
- An input device 514 is coupled to bus 502 for communicating information and command selections to processor 504 .
- cursor control 516 is Another type of user input device, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512 .
- This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
- a first axis e.g., x
- a second axis e.g., y
- Another type of user input device is a touchscreen, which generally combines display 512 with hardware that registers touches upon display 512 .
- the invention is related to the use of one or more computer systems, such as computer system 500 , collectively configured and/or programmed to perform implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506 . Such instructions may be read into main memory 506 from another machine-readable medium, such as storage device 510 . Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
- machine-readable medium refers to any medium that participates in providing data that causes a machine to operation in a specific fashion.
- various machine-readable media are involved, for example, in providing instructions to processor 504 for execution.
- Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media.
- Non-volatile media includes, for example, optical or magnetic disks, such as storage device 510 .
- Volatile media includes dynamic memory, such as main memory 506 .
- Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 502 .
- Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. All such media must be tangible and/or nontransitory to enable the instructions carried by the media to be detected by a physical mechanism that reads the instructions into a machine.
- Machine-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
- Various forms of machine-readable media may be involved in carrying one or more sequences of one or more instructions to processor 504 for execution.
- the instructions may initially be carried on a magnetic disk of a remote computer.
- the remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem.
- a modem local to computer system 500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal.
- An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 502 .
- Bus 502 carries the data to main memory 506 , from which processor 504 retrieves and executes the instructions.
- the instructions received by main memory 506 may optionally be stored on storage device 510 either before or after execution by processor 504 .
- Computer system 500 also includes a communication interface 518 coupled to bus 502 .
- Communication interface 518 provides a two-way data communication coupling to a network link 520 that is connected to a local network 522 .
- communication interface 518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line.
- ISDN integrated services digital network
- communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN.
- LAN local area network
- Wireless links may also be implemented.
- communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
- Network link 520 typically provides data communication through one or more networks to other data devices.
- network link 520 may provide a connection through local network 522 to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526 .
- ISP 526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 528 .
- Internet 528 uses electrical, electromagnetic or optical signals that carry digital data streams.
- the signals through the various networks and the signals on network link 520 and through communication interface 218 which carry the digital data to and from computer system 500 , are exemplary forms of carrier waves transporting the information.
- Computer system 500 can send messages and receive data, including program code, through the network(s), network link 520 and communication interface 518 .
- a server 530 might transmit a requested code for an application program through Internet 528 , ISP 526 , local network 522 and communication interface 518 .
- the received code may be executed by processor 204 as it is received, and/or stored in storage device 510 , or other non-volatile storage for later execution. In this manner, computer system 500 may obtain application code in the form of a carrier wave.
Landscapes
- Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Development Economics (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Economics (AREA)
- Marketing (AREA)
- Signal Processing (AREA)
- Tourism & Hospitality (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Computer Security & Cryptography (AREA)
- Primary Health Care (AREA)
- Human Resources & Organizations (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Educational Administration (AREA)
- Human Computer Interaction (AREA)
- Data Mining & Analysis (AREA)
- Remote Sensing (AREA)
- Radar, Positioning & Navigation (AREA)
- Bioinformatics & Computational Biology (AREA)
- Life Sciences & Earth Sciences (AREA)
- Artificial Intelligence (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Evolutionary Biology (AREA)
- Evolutionary Computation (AREA)
- General Engineering & Computer Science (AREA)
- Psychiatry (AREA)
- Social Psychology (AREA)
- Traffic Control Systems (AREA)
- Operations Research (AREA)
- Closed-Circuit Television Systems (AREA)
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 14/187,300, filed Feb. 23, 2014, which is a continuation of U.S. patent application Ser. No. 13/686,802, filed Nov. 27, 2012, and now U.S. Pat. No. 8,698,895, which claims the benefit of U.S. Provisional Patent Application No. 61/680,268, filed on Aug. 6, 2012, the disclosures of which are incorporated by reference in their entirety.
- This invention relates to the use of cameras to identify vehicles and track and control the use of parking spaces by the vehicles.
- Various municipal and private parking operators have extensive legacy parking management systems for managing the use of, and obtaining revenue for the user of, destination locations for vehicles, such as parking spaces for wheeled motor vehicles. The substantial rework and expense that traditionally has been required to upgrade such legacy systems to full automation poses a substantial up-front capital investment that prevents many parking operators from performing such upgrades.
- What is needed is a fully automated and autonomous parking management system which easily integrates with existing parking payment systems, including systems that have already been installed and operational for some time. Doing so unlocks new revenue opportunities and efficiencies for the parking facility operators that are previously untapped.
- In an embodiment, there is a method of tracking the use of at least one destination location, the method comprising: receiving a plurality of vehicle images captured by a plurality of cameras, wherein each vehicle image includes an image of a first vehicle, the plurality of cameras includes a first identification camera, the plurality of cameras includes a destination camera, the vehicle images include one or more first identification images captured by the first identification camera, a plurality 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 the second time; determining a first unique identifier for the first vehicle based on the first identification images; determining a first plurality of characteristics for the first vehicle based on the first identification images; determining a second plurality of characteristics for a vehicle based on one or more of the destination images; determining that the second plurality of characteristics correspond to the first plurality of characteristics; determining that an image of the first vehicle is included in the plurality of destination images based on the determining that the second plurality of characteristics correspond to the first plurality of characteristics; determining the first vehicle is stopped at a first destination location based on the first destination image and the second destination image; determining the first vehicle has left the first destination location based on the third destination image; indicating that the first vehicle began use of the first destination location at the first time; and indicating that the first vehicle completed use of the first destination location at the third time, wherein the preceding steps of receiving, determining, and indicating are performed by one or more computers collectively programmed to perform the preceding steps.
- Various benefits obtained by the disclosed subject matter include, but are not limited to: (1) offering hands-off self-enforcement for parking citations; (2) offering hands-off self-enforcement for parking citations that integrates with existing “in-place” parking payment infrastructure; (3) a smaller number of sensors, and associated reduction in installation costs, in comparison to techniques relying on proximity sensors that identify the presence of only one or very few vehicles—a factor which can prove significant for the management of parking spaces in large open areas, such as parking lots; (4) leveraging commercial off-the-shelf (COTS) technologies, and associated reduction in equipment costs, for vehicle detection and parking enforcement; (5) improvements in software-based vehicle detection techniques can be quickly updated throughout the system, particularly in an embodiment where image processing is performed remote from the cameras, and realizing improvements in vehicle detection without hardware changes throughout a parking management system; (6) the ability to rapidly make changes in system behavior system-wide, or in connection with a more narrowly defined subset of parking spaces.
-
FIG. 1 illustrates an example of an overall system 100 according to the disclosed subject matter. -
FIGS. 2A and 2B illustrate examples of images captured by identification cameras. -
FIGS. 3A and 3B illustrate examples of images captured by destination cameras. -
FIG. 4 illustrates how images captured by cameras with overlapping fields of view may be used to identify a vehicle, track the movement of the vehicle to a destination location, and identify use of the destination location by the vehicle. -
FIG. 5 is a block diagram that illustrates acomputer system 500 upon which aspects of the invention may be implemented, -
FIGS. 6A and 6B illustrate aspects of a graphical user interface (GUI) for specifying characteristics of a camera's field of view.FIG. 6A illustrates a portion of the GUI in which an image from a first camera is displayed.FIG. 6B illustrates a portion of the GUI in which an image from a second camera is displayed. -
FIG. 1 illustrates an example of an overall system 100 according to the disclosed subject matter. Network 110 provides data communication services among the elements illustrated inFIG. 1 . There are many networking technologies, including, but not limited to, Ethernet, 802.11 wireless, and cellular data networking technologies, which those skilled in the art can reliably and predictably integrate for the exchange of data among the illustrated elements. In an embodiment, separate networks may be used. For example,cameras server 140 may communicate via a first network, whereas the other elements communicate via the public Internet. By use of an independent first network, those skilled in the art may realize desired goals for reliability and security. -
Identification camera 120 illustrates one of a plurality of such cameras included in system 100. For the convenience of discussion, only asingle Identification camera 120 is illustrated inFIG. 1 .Identification camera 120 is positioned such that it may capture images of vehicle identifiers, such as, but not limited to, an automobile license plate or a label affixed to a vehicle that provides a vehicle identifier in a format such as, but not limited to, a QR code or a bar code. Images captured byIdentification camera 120, such asimage 121, are used in conjunction with images captured by one ormore destination cameras 125 in order to identify individual vehicles, such asvehicle 130, and record their usage of various destination locations. Examples of destination locations for wheeled motor vehicles include areas designated as appropriate for parking, although possibly subject to various restrictions, such as, but not limited to, parking spots, and areas designated as inappropriate for parking, such as, but not limited to, bus stops, fire lanes, areas around fire hydrants, sidewalks, areas within X feet of an intersection, driveways, islands, medians, bicycle lanes, pedestrian crossings. For example,server system 140 may be configured to determine when a vehicle is parked at a bus stop, and request or take action upon that determination, such as requesting the vehicle be towed or issue a citation by mail. In an embodiment, other parking violations may be identified, such as a vehicle not being properly parked within a designated parking space, parking more than 1 foot from a curb, parking with the left wheels toward the curb (parked facing wrong direction), back-in angle parking, and abandoned vehicles (left in a particular location for X or more consecutive days). In an embodiment, an Identification camera may also include a mobile or handheld camera, including, for example, a camera included in a smartphone. -
Destination camera 125 illustrates one of a plurality of such cameras included in system 100. For the convenience of discussion, only asingle destination camera 125 is illustrated inFIG. 1 .Destination camera 125 is positioned such that it may capture images of one or more destination locations, such as, but not limited to, automobile parking spots. Typically,destination camera 125 will be mounted at an elevation, such as, but not limited to, on a lighting or telephone pole, or on the façade or top of a building. By mountingdestination camera 125 at an elevation, the field of view of images, such asimage 126, captured bydestination camera 125 can include, and therefore be used to monitor, multiple destination locations. In an embodiment, a destination camera may also include a mobile or handheld camera, including, for example, a camera included in a smartphone. In an embodiment, a destination camera may be included in a parking meter body. In an embodiment, a destination camera may be provided by a space satellite imaging camera, potentially obviating a need for destination cameras installed throughout a municipality. In an embodiment, a destination camera may be included in an air vehicle, such as, but not limited to, a blimp or other airship, or an unmanned air vehicle, and may be autonomously operated for extended periods of flight. - Although
Identification camera 120 anddestination camera 125 may be configured to each directly communicate withnetwork 110 viarespective communication links Identification camera 120 may be configured to communicate directly with, and relay data through,destination camera 125, such that rather thanIdentification camera 120 being configured to communicate directly withnetwork 110 viacommunication link 127, it communicates withdestination camera 125 viacommunication link 129, anddestination camera 125 communicates withnetwork 110 viacommunication link 128, such thatdestination camera 125 serves to relay data to and fromidentification camera 120.Communication link 129 may be a wireless networking link. AlthoughFIG. 1 illustrates an example with acommunication link 129 between the twocameras -
Server system 140 comprises one or more computer systems which provide central data storage, data retrieval, and processing services. The computer systems included inserver system 140 will generally each include arandom access memory 142 and aprocessor 143.Server system 140 includesdatabase 141, which is used to record information such as usage of destination locations, such as parking spaces, by vehicles; vehicle account information; identifications of vehicles obtained via identification camera images; observations of vehicles obtained via destination camera images; destination reservation information; billing information; and payment information.Database 141 may be implemented, for example, using software programs such as MySQL, Oracle, or DBASE.Database 141 may comprise multiple database instances executing across multiple computer systems. - In an embodiment,
server system 140 is configured to perform vehicle and vehicle identification recognition from images captured by identification cameras, such asidentification camera 120, and destination cameras, such asdestination camera 125.Further server 140 is configured to perform decision making based on the recognized information, such as determining the usage of destination locations, and when the usage of a destination location is in violation of use restrictions for the destination location. This embodiment, in which image processing and decision making are centralized inserver system 140, exploits Moore's Law, in which the number of transistors in a microprocessor, and a corresponding amount of data processing capability, doubles every 18 months, and Nielsen's Law, which hypothesizes that bandwidth speeds grow by 50% per year. Significant benefits can be realized by this centralized approach. Not only can the intelligence/feature-richness of server applications be quickly scaled up with ever cheaper and faster CPU power, new features and applications can also be quickly rolled out to onsite “thin-client” devices. Manufacturing costs are generally reduced by use of COTS (commercial off the shelf) components throughout the system. In addition, a highly networked system will be well positioned to take advantage of updates in technology services available via network. Finally, as microprocessor and bandwidth costs continue to decrease, the costs of expansion in size or capability can be realized at ever reducing costs. - In another embodiment, some functions may be distributed to other components of the system. For example,
identification camera 120 may be configured to identify the presence of vehicle identification information, such as license plate numbers, in captured images. In such an embodiment, the amount of data communication bandwidth betweenidentification camera 120 andserver system 140, and the amount of processing which must be performed byserver system 140 may be significantly reduced, with a tradeoff in thatidentification camera 120 needs to be a more sophisticated device capable of performing image processing functions capable of, for example, identifying the presence of vehicles in images, identifying the presence of vehicle identification information in images, and/or extracting vehicle identification information from images. By way of another example, the identification and destination cameras can be programmed to determine characteristics of vehicle images, as detailed below in connection withFIG. 4 , rather than perform such determinations usingserver system 140. How functions may be distributed throughout the system as a whole would depend on the anticipated costs of providing distributed functionality (such as providing the necessary processing hardware and programming to identification and/or destination cameras), weighed against the anticipated costs to convey images captured by the cameras to a central location for processing. Moving programmed functions from one computer system to another to accommodate communication bottlenecks, such as fromserver system 140 toidentification camera 120, and ensuring that adequate processing resources are provided for various computer systems to perform these functions is a routine exercise which is well within the skill in the art. -
Mobile device 150 comprises a programmable computer, an identification camera, and wireless data communication capability for communicating withserver system 140. In an example, ifvehicle 130 were determined to be using a destination location, but a unique identification forvehicle 130 had not been determined,mobile device 150 could be dispatched to the destination location, and animage 151 ofvehicle 130 captured, from which a unique identification forvehicle 130 could be obtained. In additional to capturing an image of a license plate, as done byidentification camera 120,mobile device 150 can also be configured to capture a vehicle VIN identifier tag, which may be helpful for vehicles lacking license plates. This helps overcome occasional situations, such as occlusion ofvehicle 130 by another vehicle as it passes through the field of view foridentification camera 120, in whichidentification camera 120 is unable to capture images effective for uniquely identifyingvehicle 130. Multiple mobile devices may be included in the system in order to better ensure timely capture of images across all of the destination locations managed byserver system 140. In an embodiment,mobile device 150 may also be configured to provide features useful for parking enforcement. For example,mobile device 150 may be configured to print out a paper citation for parking violations identified byserver system 140. -
Onsite payment system 160 is one of a plurality of devices which offers a direct physical interface, generally located near one or more destination locations, for an end user to submit a payment or an agreement to pay for the use of a destination location. Examples ofpayment system 160 include, but are not limited to, a parking meter dedicated to an individual destination location, a payment station associated with several street parking spaces, and a payment station for destination locations provided in a parking lot or garage. In an embodiment,onsite payment system 160 may include a destination camera which captures images for one or more destination locations. -
End user system 170 is a programmable computer system by which an end user, such as a driver ofvehicle 130, may interact withserver system 140. Examples of such systems include, but are not limited to, a desktop computer system with a web browser application, a smartphone with a web browser application or dedicated parking application, and an in-vehicle system included invehicle 130.End user system 170 may be used, for example, to create an end user account for repeated interactions withserver system 140, reserve use of destination locations, request identification of an available destination location, and submit payment information for the use of a destination location. - In an embodiment,
end user system 170 may be configured to request and obtain information fromserver system 140 describing available destination locations for a given area. In an example,end user system 170 may further be configured to obtain and/or request particular criteria for acceptable destination locations, such as destination locations which are in a parking garage or not on-street parking (such as a parking lot). In addition to location information, other information such as, but not limited to, cost of use for a given destination location may be obtained byend user system 170.End user system 170 may be further configured to request and obtain information for currently available destination locations and/or destination locations available at a specified point or range of time in the future. End user system may be further configured to provide a graphical user interface to the end user showing specific locations, such as on a map, of one or more of the available destination locations obtained fromserver system 140. In an embodiment, where multiple destination locations are available at a parking facility (such as a parking garage or parking lot),end user system 170 may be configured to broadly indicate the availability, possibly indicating a number of available destination locations) of a destination location at the parking facility, rather than individually identifying each destination location.End user system 170 may be configured to receive an indication of a selected destination location from the end user.End user system 170 may be further configured to provide guidance, such as turn-by-turn directions, to the selected destination location.End user system 170 may be further configured to instructserver system 140 to reserve use of an available destination location. -
Manual review system 180 is a programmed computer system by which ahuman operator 181 provides assistance toserver system 140 for identifying vehicles, such asvehicle 130. For example,server system 140 may determine that an error has occurred in performing an automated machine-based determination of a unique identifier forvehicle 130 from images, such asimage 121, captured byidentification camera 120. In response to this error,server system 140 may request assistance fromhuman operator 181 to determine a unique identifier, such as a license plate number, forvehicle 130.Manual review system 180 provides a user interface by whichhuman operator 181 may reviewimage 121, and perhaps other images captured byidentification camera 120 or other cameras. For example,human operator 181 can rewind the video footage manually and freeze-frame forward in order to manually determine the vehicle license plate number and state/province information. Via this interface,human operator 181 may provide an identification ofvehicle 130 or indicate thathuman operator 181 was unable to determine an identification forvehicle 130, which may result inmobile device 150 being dispatched to a destination location in order to make a positive identification ofvehicle 130. More than onemanual review system 180 may be made available for use byserver system 140, depending on the volume of information processed byserver system 140. Additionally,human operator 181 may be a member of a Live Operator team, discussed in more detail below. - In an embodiment, one or more of the identification and destination cameras capture images at a higher frame rate and/or resolution than the images transmitted from the cameras to
server system 140. Although not all of the image data captured by such cameras is transmitted toserver system 140, in the interest in conserving possibly expensive network communication bandwidth (for example, a cellular data network) and limited image processing resources available atserver system 410, such cameras can buffer a limited amount of the full image data that they capture, such as in a circular buffer. Additionally, such cameras are configured to respond to requests for such additional image data, including, for example, portions of higher resolution images which may be useful for license plate recognition. By this mechanism,server system 140 may automatically determine that additional images may be useful for identifying and tracking vehicles, ormanual review system 180 may request various images in order to resolve an error raised byserver system 140. -
Parking operation system 190 is a programmed computer system by which a parking facility operator may interact with andcontrol server system 140.Server system 140 is expected to operate autonomously with little input required by a parking operator the majority of the time. However, occasionally there are instances when the parking facility operator personnel take an active part in its operation. For example,parking operation system 190 may provide a live indication as to how many and which destination locations are being used and/or are available. As another example,parking operation system 190 may provide a live indication as to destination locations in which vehicles are violating usage restrictions, allowing parking facility operator personnel to take action for such violations as deemed necessary. -
FIG. 2A illustrates an example of animage 121 captured byidentification camera 120, whereidentification camera 120 is located so as to effectively capture identification information for vehicles passing byidentification camera 120. In an embodiment,identification camera 120 streams video containing images of identification information, such as license plate information, toserver system 140. Since typical streetlights are approximately 18 feet in height, they provide an excellent mounting location for identification cameras which benefit from a clear line of sight away from trees and other obstacles, including closely traveling vehicles. Also, as a streetlight is already supplied with power, the identification camera may be installed so as to draw power from the streetlight. In addition, as most city regulations require at least one streetlight per block on each site of the street, streetlight-mounted identification cameras can provide sufficient coverage for any vehicles traversing the street. - Identification images captured by
identification camera 120 are used for two primary purposes: (1) obtaining a unique identification of a vehicle, such as by reading an identifier from a license plate mounted on the front or rear of the vehicle; and (2) determining various characteristics of the vehicle, so that it may be determined that an image of a vehicle obtained by another camera corresponds to an identified vehicle, as discussed below in connection withFIG. 4 . In the example identification image shown inFIG. 2A , a view of a vehicle and its license are available for processing byserver system 140. Multiple identification images may be used for determining vehicle characteristics such as speed and direction of travel. - In the field of license plate readers, various techniques are known in the art for reliably capturing images effective for reliable reading of vehicle identifiers under a variety of illumination and vehicle conditions. One nonlimiting example is described in U.S. Pat. No. 7,016,518, which is incorporated by reference in its entirety. In an embodiment, issues arising from the lack of natural illumination during night may be avoided where restrictions for the use of destination locations are only in effect during daylight hours.
- In an embodiment, machine vision techniques for obtaining vehicle identifiers may be performed by
identification camera 120. In such an embodiment, the amount of data sent fromidentification camera 120 toserver system 140 may be significantly reduced, as a vehicle identifier can be sent in place of identification images. However, one or more identification images may still be transmitted toserver system 140 for storage and/or determination of vehicle characteristics by server system 140 (although in an embodiment, this may also be performed by identification camera 120). - In an embodiment,
server system 140 may recognize it is only able to obtain a portion of a vehicle identifier, perhaps as a result of certain particular conditions, such as the angle of the vehicle or a closely following vehicle. In such a case, server system may further rely on a second identification image captured by a second identification camera to obtain the remaining portion of the identifier. -
FIG. 2B illustrates an example of animage 121 captured byidentification camera 120, whereidentification camera 120 is located so as to effectively capture identification information for vehicles entering and exiting an urban intersection via the roadway extending along the axis of view ofidentification camera 120. In this identification image, views of three vehicles are effective for processing byserver system 140, such that unique identifiers may be obtained for all three vehicles from the single image. - In an embodiment,
identification camera 120 may have pan, tilt, and/or zoom capability, which may be used forserver system 140 to obtain a more detailed view of a vehicle, or may be used by parking facility operator personnel via a user interface onparking operation system 190 to monitor particular areas of interest viewable byidentification camera 120. In such an embodiment,server system 140 may be configured to perform a coordinate transformation in order to accurately determine vehicle characteristics while varying the field of view ofidentification camera 120. - In an embodiment, when a vehicle appears in the field of view of
identification camera 120,server system 140 performs one or more of six tasks. In the first task,server system 140 detects the presence of one or more vehicles based on one or more images captured byidentification camera 120. In an embodiment,server system 140 may be configured to detect the presence of a vehicle based on differences in color between the vehicle and the background, and a determination that a size of a total shape for a potential vehicle is larger than a specified minimal vehicle size adjusted for any applicable zoom level. Specifically, such an algorithm may compare colors of all the pixels in an image against each other. Pixels are divided into rows and columns (for example, an absolute location 21, 34 may represent a pixel located on Row 21 and Column 34). Since the image likely includes other non-vehicle objects such as, but not limited to, a fire hydrant, pedestrian, cars, grass, or road marking/paint, the algorithm may be configured to detect groups of pixels with similar colors (a range of colors that be considered to be similar may be specified in a system configuration, such as that similar colors may be a maximum of 2 shades difference, with reference to shades indicated by a color chart). The locations of these pixels are then mathematically computed to determine whether they form a shape larger than the minimal vehicle size (for example, a relative size of 10×30 may represent a shape measuring 10 rows by 30 columns). Vehicles appearing in images captured byidentification camera 120 tend to appear to be parallelograms rather than rectangular in shape due to the viewing angle. Therefore, the determination may take this factor into account. - A further refinement could be made to accommodate “holes” or imperfections in a detected shape due to, for example, a reflection of the sun, a windshield area, or a roof rack. For example, the algorithm may specify a number of shapes of a particular minimum size up to certain distance (or pixels) away from each other, which may correspond to portions of a vehicle such as a hood, roof, and trunk, which are typically of the same color.
- Once a vehicle has been detected, an entry is recorded in a portion of
database 141 corresponding toidentification camera 120, along with information including, for example, a date, time, color of vehicle, size of vehicle, locations of pixels, and zoom level. This information may be used in conjunction with other detections of the vehicle to identity of the vehicle. Alternatively, such information may be temporarily recorded in volatile memory, such as RAM. - In the second task,
server system 140 detects the presence of license plates and/or additional identification, such as, but not limited to, decals, on vehicles in images captured byidentification camera 120. Once a license plate and/or additional identification has been detected, an entry is recorded in a portion ofdatabase 141 corresponding toidentification camera 120, along with information including, for example, a date, time, license plate #, state/province, decal details (for example, a type, an identifier, and expiration), locations of pixels, and zoom level. This information may be used in conjunction with other detections of the vehicle to identify the vehicle in other images, such as images captured by a destination camera. - In the third task,
server system 140 identifies vehicles that are moving versus vehicles which are stationary, based on multiple images captured byidentification camera 120. - In the fourth task,
server system 140 identifies license plates and/or additional identifications that are moving versus license plates and/or additional identifications which are stationary, based on multiple images captured byidentification camera 120. In an example,server system 140 may be configured to: (1) based on license plates and/or additional identification information obtained, such as via OCR, from the current image, find corresponding matches in previous images (for example, by reviewing data stored indatabase 141 or memory); and (2) once such matches are found, compare the locations of pixels between the current image and previous images, taking into account any change in zoom level. Based on such processing, one or more of the following scenarios may be detected. (A) if locations of pixels are unchanged or have unchanged below a predetermined threshold, all license plates and/or additional identifications are deemed to have remained stationary. In this scenario, a simple update of the date and time is performed for existing entries indatabase 141 or memory for the vehicles. (B) if pixels associated with one or more license plates and/or additional identifications are at new locations, the one or more license plates and/or additional identifications are determined to have moved.Server system 140 may calculate speed and direction of travel for these vehicles andupdate database 141 or memory with this information, along with updated locations. (C) if one or more license plates and/or additional identifications have disappeared from the current image,server system 140 may be configured to remove data recorded indatabase 141 or memory for such vehicles. (D) if one or more license plates and/or additional identifications have newly appeared in the current image, data associated with the new license plates and/or additional identifications may be recorded indatabase 141 or memory. In an embodiment,server system 140 may determine that one of the new vehicles corresponds to a vehicle recently determined to have disappeared, and may treat the view of the vehicle as having been temporarily obstructed. (E) if all license plates and/or additional identifications have disappeared from the current image, data fromdatabase 141 or memory from the preceding interval may be removed in connection with the license plates and/or additional identifications therein. However, some data may be retained in order to perform vehicle tracking to or from an identification camera, as discussed previously. - In the fifth task,
server system 140 mates identified license plates and/or additional identifications to vehicles detected in the first task. For example,server system 140 may be configured to compare attributes of license plates and/or additional identifications (such as, for example, absolute pixel location, direction of travel, and speed) to such attributes determined for possible vehicles and attempt to mate each license plate and/or additional identification to a vehicle. - In the first through fifth tasks,
server system 140 may apply machine vision techniques to identify additional identification on vehicles for the purpose of confirming that either the particular vehicle is eligibility of parking in a particular parking space, or the vehicle license registration is current and valid. These other types of unique identification include, but are not limited to: a handicap parking decal or mirror-hanger, a resident-only parking decal, and a registration decal typically adhered to license plates. - In the first through fifth tasks, OCR (optical character recognition) may be performed on any license plate image(s) in order to obtain an alphanumeric license plate number along with state/province of issue. Note the license plate observed can be either the front or the rear license plate (typically, identification cameras are provided which point both ways up and down a street). The obtained license plate information is used to obtain a unique vehicle identifier used for recording information about the vehicle in
database 141. In certain configurations, the first task may be performed locally on the identification camera where the license plate number and state/province data are transmitted to theserver system 140 in a concise data format. This is especially true when the underlying communications network between theidentification camera 120 andserver system 140 does not provide sufficient bandwidth (for example, 1 Mb/sec may be deemed a minimum threshold for streaming images) or is deemed to be too costly (for example, more than $10/MB). Multiple vehicles may be present simultaneously inidentification image 121. In an embodiment,server system 140 can track up to 10 sets of vehicle license number plate information simultaneously from a single identification camera at any given time. - In the sixth task a vehicle is “tracked” as it moves across the field of view of
identification camera 120. There is overlap between an image captured byidentification camera 120 and a neighboringdestination camera 125 such that a vehicle is within the field of vision of both cameras for a minimum of 2 seconds at a speed of 15 MPH (approximately 44 feet). In general, neighboring or nearby camera positions are determined to ensure this overlap occurs. As the two cameras have uniquely different angles of view, obtaining overlapped images of any given vehicle from both of these cameras is treated as a positive identification of the vehicle (via license plate number obtained from the identification image 121) along with an exact destination location the vehicle has occupied (in the event the vehicle parks). - In an embodiment, preliminary motion detection may be used to reduce the number of identification images which are captured and/or analyzed, as there may be significant periods of time during which no vehicles pass through the field of view of
identification camera 120. - An OCR rate is only one of the useful measurements in assessing identification performance. For example, while it is impressive that of 100 license plates recorded/captured,
server system 140 failed to OCR only 1 of the license plates (in other words, was not able to produce an alpha-numeric plate number), if such a configuration (including factors such as server system programming, identification camera placement, and identification camera image quality) failed to capture/register 100 other license plates (in other words, additional license plate images were not identified as such by server system 140), the overall effectiveness is only 49.5%. Furthermore, license plate recognition systems are typically tuned to read license plates from a particular state/province along with ones from a number of the surrounding states/provinces. License plates from various states/provinces have different colors and contrast for letters and background. In an embodiment, the capture rate is at least 95% and the OCR accuracy is at least 95%, yielding a minimum overall effectiveness of at least 90.25%. -
FIG. 3A illustrates an example of animage 126 captured bydestination camera 125, wheredestination camera 125 is located on a façade or top of a building looking down onto a portion of an urban street, such that a top view of vehicles is seen inimage 126. In association with the field of view corresponding to image 126 shown inFIG. 3A , nineappropriate destination locations 310 a to 310 i (such as parking spots with a hourly rate for use) have been specified toserver system 140. Of these, all butdestination location 310 d appear to be in use byvehicles 310 a to 310 i. Also specified toserver system 140 is inappropriate destination location 340 (such as a commercial entrance). If a vehicle is determined to have made use ofdestination location 340 by remaining stationary for a period of time, the vehicle will be considered in violation, resulting inserver system 140 initiating actions such as, but not limited to, assessing a fine for the violation, or alerting a parking facility operator of the violation. In some embodiments, a vehicle remaining stationary in any area not identified as a destination location may be considered a violation. Also seen inimage 126 isvehicle 330, in a traffic lane for vehicles traveling from right to left in the image. Taken alone, the single image does not indicate whethervehicle 330 is moving or stationary. For example, in a preceding image,vehicle 330 might have been making use ofdestination location 310 d, and this image may causeserver system 140 to determine thatvehicle 330 has just completed its use ofdestination location 310 d. - Destination images captured by
destination camera 125 are used for two primary purposes: (1) identifying when destination locations are being or not being used by vehicles; and (2) determining various characteristics of vehicles, so that vehicles may be tracked as they traverse from camera to camera, by determining whether the characteristics determined from images captured by neighboring cameras correspond to one another, as discussed below in connection withFIG. 4 . -
FIG. 3B illustrates an example of animage 126 captured bydestination camera 125, wheredestination camera 125 is positioned such that a side view of vehicles is seen inimage 126. Such a view may be obtained wheredestination camera 125 is located inonsite parking system 160, such as a parking meter, or on a building or structure opposite from one or more destination locations of interest. In association with the field of view corresponding to image 126 shown inFIG. 3B , fourappropriate destination locations 350 a to 350 d (such as parking spots with a hourly rate for use) have been specified toserver system 140. Of these, all butdestination location 350 c appear to be in use byvehicles 360 a to 360 d. - In another example, not illustrated in the drawings,
destination camera 125 may be positioned such thatimage 126 provides a perspective view of one or more destination locations. AlthoughFIGS. 3A and 3B illustrate the specification of rectangular areas 310 and 350 for destination locations, other shapes may be used, such as polygons (which is useful wheredestination camera 125 is positioned such that a destination location is seen in perspective). The GUI described below in connection withFIGS. 6A and 6B may also be configured to provide user interface elements which may be used to specify, with an overlay on an image feed, the position and extent of destination locations within the field of view of a camera. Additionally, the GUI may provide tools for assigning identifiers for destination locations, and possibly various characteristics about destination locations, such as, but not limited to, whether they are parking spaces, “no parking” locations, and time- and/or date-based restrictions on use. - In an embodiment, when a vehicle appears in the field of view of
destination camera 125,server system 140 performs two tasks. For the first task,server system 140 may be configured to: (1) be aware of any and all vehicles present in the field of view ofdestination camera 125; (2) distinguish moving from stationary vehicles; (3) identify a time at which a moving vehicle becomes stationary in an area of the field of view corresponding to a destination location; (4) identify which destination location(s) each stationary vehicle is occupying; (5) keep track of how long each vehicle has occupied its respective destination location(s); (6) identify a time at which a stationary vehicle vacates an area of the field of view corresponding to a destination location; (7) determine when use of a destination location conflicts with restrictions established for the destination location; (8) identify which street or block a vehicle is improperly parked; (9) track an amount of time each vehicle has been improperly parked; and (10) track a time at which a vehicle ceases to be illegally parked. Various types of destination locations, each having respective restrictions, for wheeled motor vehicles include, but are not limited to: no parking areas (anytime, fire lane, fire hydrant), no parking during specified times and/or days (for example, during rush hour or street cleaning), no parking/stopping/standing, limited-time parking (for example, 2 hour time limit), parking restricted to classes of vehicles (taxi stand, bus stop, loading zone/commercial vehicles only), permitted parking (handicapped or resident-only parking), pick-up and drop-off only locations, and street intersections (for anti-gridlock “block the box” moving violations in which a vehicle remains within an intersection during a red light for the vehicle's direction of travel).Server system 140 may be configured to detect other parking violations, such as, but not limited to, parking within a specified distance of an intersection, parking in a bike lane or crosswalk or other pedestrian zone, not within a space for a single destination location, more than a specified distance from a curb, parking in or in front of a driveway, use of an island or center strip, vehicle parked facing the wrong direction, abandoned vehicle (stationary for more than a specified number of days), oversize vehicles, incorrect class of vehicle (such as a camper, trailer, or boat for more than a specified number of hours in a given number of days). A destination location may also be subject to a reservation, where an end user reserves exclusive use of a destination location for a specified period of time.Server system 140 may also be configured to detect double parked vehicles, while distinguishing vehicles stopping in traffic lanes due to driving conditions from improperly double parked vehicles.Server system 140 may also be configured to recognize, and in some cases distinguish, smaller wheeled vehicles such as motorcycles, scooters, and “smart cars.” - In the second task the vehicle is “tracked” as it moves across the field of view of
destination camera 125. There is overlap between an image captured bydestination camera 125 and a neighboring identification or destination camera such that a vehicle is within the field of vision of both cameras for a minimum of 2 seconds at a speed of 15 MPH (approximately 44 feet). In general, neighboring camera positions are determined to ensure this overlap occurs. As the two cameras have uniquely different angles of view, obtaining overlapped images of any given vehicle from both of these cameras is treated as a positive identification of the vehicle (via license plate number obtained from the identification image 121) along with the exact parking space the vehicle has occupied (in the event the vehicle parks). - In some configurations, a destination camera may be positioned to monitor vehicle movement in a particular area, where the area does not include any destination locations of interest to
server system 140. Such an area may be located, for example, between two areas each containing destination locations of interest. In this example, images captured by the destination camera may overlap images captured by cameras corresponding to these two areas, and can be used for a “handoff” procedure as illustrated inFIG. 4 , discussed below. - In an embodiment,
destination camera 125 may have pan, tilt, and/or zoom capability, which may be used forserver system 140 to obtain a more detailed view of a destination location, or may be used by parking facility operator personnel via a user interface onparking operation system 190 to monitor particular areas of interest viewable bydestination camera 125. In such an embodiment,server system 140 may be configured to perform a coordinate transformation in order to monitor usage of destination locations and accurately determine vehicle characteristics while varying the field of view ofdestination camera 125. - In an embodiment, preliminary motion detection may be used to reduce the number of destination images which are captured and/or analyzed, as there may be significant periods of time during which no vehicles pass through the field of view of
destination camera 125. - In an embodiment, accurate date and time stamps are included in all images captured by identification cameras and destination cameras to facilitate later manual review of stored images, should such a need arise.
- In an embodiment, some amount of “grace period” is given to vehicles after they are determined to have become stationary within an appropriate destination location (in contrast to an inappropriate destination location, such as a no parking zone). When a driver leaves the vehicle to pay for parking, even though it has been determined that the vehicle has begun use of a destination location with no payment made, some grace period is needed to delay the determination that the vehicle is in violation of a paid use requirement since some amount of time is required to complete the payment process.
-
FIG. 4 illustrates how images captured by cameras with overlapping fields of view may be used to identify a vehicle, track the movement of the vehicle to a destination location, and identify use of the destination location by the vehicle.FIG. 4 is not presented to scale; for example, overlappingarea 430 a nominally would extend 44 feet or more in the vertical direction, but it is illustrated as approximately the same size asvehicle 410. First, at time t1 an identification camera (not illustrated) captures identification image 420 covering the field of view illustrated inFIG. 4 . Included in identification image 420 isvehicle 410 at the location designated 410′. Based onimage 420 a (and perhaps additional images captured by the identification camera prior to time t1),server system 140 determines a unique identifier forvehicle 410. For example, by performing OCR on one or more detected images of a license plate to obtain a license plate number from which the unique identifier can be obtained.Server system 140 records indatabase 141, in connection with the unique identifier thatvehicle 410 was observed by the identification camera at time t1. In an alternative embodiment,server system 140 instead stores in volatile memory thatvehicle 410 was observed by the identification camera at time t1, and such information is recorded indatabase 141 after a determination thatvehicle 410 has made use of a destination location prior tovehicle 410 being identified byserver system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420. - At time t2, the identification camera captures another
identification image 420 a′ ofvehicle 410 at the location designated 410 a. At approximately time t2, a first destination camera capturesdestination image 420 b ofvehicle 410 withinoverlap area 430 a (for example, at approximately thelocation 410 a). In some embodiments, the identification camera and the first destination camera are synchronized, such thatimages 420 a′ and 420 b are both captured at essentially the same time t2.Overlap area 430 a corresponds to the field of view ofidentification image 420 a′ which overlaps the field of view ofdestination image 420 b. In bothimages 420 a′ and 420 b, images ofvehicle 410 have been captured whilevehicle 410 is withinoverlap area 430 a. - Based on one or more identification images captured by the identification camera (such as
identification image 420 a′),server system 140 determines a plurality of characteristics Ca forvehicle 410. As noted above, fixed characteristics forvehicle 410 and recorded indatabase 141 may be included in Ca. Examples of the characteristics include, but are not limited to: a speed of travel forvehicle 410, a direction of travel forvehicle 410, a position of a vehicle in a vehicle image (including, for example, a lane oftraffic vehicle 410 is traveling in), a color ofvehicle 410, and a size or dimension ofvehicle 410. Some characteristics may be considered static characteristics ofvehicle 410, and are not expected to change over time (for example, vehicle color or size). Other characteristics may be considered dynamic characteristics ofvehicle 410, and may change significantly over time (for example, vehicle speed or lane of travel). In an embodiment, static characteristics may be recorded indatabase 141 as fixed characteristics ofvehicle 410 in connection with the unique identifier determined based onidentification image 420 a. These fixed characteristics may be determined based on vehicle information provided by an end user (such as make, model, year, and color), or they may be based on vehicle images captured during a previous encounter betweenvehicle 410 andserver system 140. The fixed characteristics may be used in connection with determining a unique identifier forvehicle 410, by ensuring that static characteristics determined from identification images correspond to the fixed characteristics. The fixed characteristics may also be included in Ca or other pluralities of characteristics where a vehicle identification has been confirmed. Based ondestination image 420 b, and possibly other destination images captured by the first destination camera,server system 140 determines a plurality of characteristics Ca′ forvehicle 410. Due to factors such as the different angles of view ofvehicle 410 for the identification camera and the first destination camera, and obstructing vehicles, Ca and Ca′ may consist of different, but typically overlapping, sets of vehicle characteristics. For example, a vehicle width may be determined for Ca but not Ca′ due to a partial obstruction ofvehicle 410 from the point of view of the first destination camera around time t2. Additionally, image distortion, which is typically more significant at the borders or images, or other factors may result in some vehicle characteristics, such as speed or size, only being approximate values. Normalization of characteristics such as size, speed, and direction of travel may be performed to compensate for camera positioning and zoom level. -
Server system 140 then determines whether Ca′ corresponds to Ca by comparing the values of the vehicle characteristics included in both Ca and Ca′. As vehicle characteristics determined byserver system 140 may be approximations of the actual characteristics ofvehicle 410, an approximate equivalence between values, where such equivalence is demonstrated for all of the compared characteristics, is sufficient to support a determination that Ca′ corresponds to Ca. If Ca′ is determined to correspond to Ca, thenserver system 140 records indatabase 141, in connection with the unique identifier, thatvehicle 410 was observed by the first destination camera at time t2. In an alternative embodiment,server system 140 instead stores in volatile memory thatvehicle 410 was observed by the first destination camera at time t2, and such information is recorded indatabase 141 after a determination thatvehicle 410 has made use of a destination location prior tovehicle 410 being identified byserver system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420. This avoids writing vehicle location information todatabase 141 that is not required to demonstrate that a use of a particular destination location byvehicle 410. - At time t3, the first destination camera captures another
destination image 420 b′ ofvehicle 410 at the location designated 410 b. At approximately time t3, a second destination camera capturesdestination image 420 c ofvehicle 410 withinoverlap area 430 b (for example, at approximately thelocation 410 b). In some embodiments, the first destination camera and the second destination camera are synchronized, such thatimages 420 b′ and 420 c are both captured at essentially the same time t3.Overlap area 430 b corresponds to the field of view ofdestination image 420 b′ which overlaps the field of view ofdestination image 420 c. In bothimages 420 b′ and 420 c, images ofvehicles vehicles overlap area 430 b. - Based on one or more destination images captured by the first destination camera (such as
identification image 420 b′),server system 140 determines a plurality of characteristics Cb forvehicle 410. As noted above, fixed characteristics forvehicle 410 and recorded indatabase 141 may be included in Cb. Based ondestination image 420 c, and possibly other destination images captured by the second destination camera,server system 140 determines a plurality of characteristics Cb′ forvehicle 410. Additionally, due to the inclusion ofvehicle 440 indestination image 420 c, a plurality of vehicle characteristics Cx are determined forvehicle 440. Differences in dynamic vehicle characteristics between Cb′ and Cx would result due tovehicle 440 traveling in the opposite direction in a different lane of travel.Server system 140 then determines whether Cx corresponds to Cb, which should not occur.Server system 140 then determines whether Cb′ corresponds to Cb. If Cb′ is determined to correspond to Cb, thenserver system 140 records indatabase 141, in connection with the unique identifier, thatvehicle 410 was observed by the second destination camera at time t3. In an alternative embodiment,server system 140 instead stores in volatile memory thatvehicle 410 was observed by the second destination camera at time t3, and such information is recorded indatabase 141 after a determination thatvehicle 410 has made use of a destination location prior tovehicle 410 being identified byserver system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420. - At time t4, the second destination camera captures another
destination image 420 c′ ofvehicle 410 at the location designated 410 c. At approximately time t4, a third destination camera capturesdestination image 420 d ofvehicle 410 withinoverlap area 430 c (for example, at approximately thelocation 410 c). In some embodiments, the second destination camera and the third destination camera are synchronized, such thatimages 420 c′ and 420 d are both captured at essentially the same time t4.Overlap area 430 c corresponds to the field of view ofdestination image 420 c′ which overlaps the field of view ofdestination image 420 d. In bothimages 420 c′ and 420 d, images ofvehicle 410 have been captured whilevehicle 410 is withinoverlap area 430 c. - Based on one or more destination images captured by the second destination camera (such as
identification image 420 c′),server system 140 determines a plurality of characteristics Cc forvehicle 410. As noted above, fixed characteristics forvehicle 410 and recorded indatabase 141 may be included in Cc. Based ondestination image 420 d, and possibly other destination images captured by the third destination camera,server system 140 determines a plurality of characteristics Cc′ forvehicle 410.Server system 140 then determines whether Cc′ corresponds to Cc. If Cc′ is determined to correspond to Cc, thenserver system 140 records indatabase 141, in connection with the unique identifier, thatvehicle 410 was observed by the third destination camera at time t4. In an alternative embodiment,server system 140 instead stores in volatile memory thatvehicle 410 was observed by the third destination camera at time t4, and such information is recorded indatabase 141 after a determination thatvehicle 410 has made use of a destination location prior tovehicle 410 being identified byserver system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420. In an embodiment, a second identification camera may be responsible for capturingimage 420 d, but is unable to obtain an image of a license plate forvehicle 410, in which case characteristics of vehicle observed via the second identification camera are used to confirm that the vehicle observed inoverlap area 430 c aroundarea 410 c isvehicle 410. This illustrates that it is not significant whether it is a destination camera or an identification camera which is used for trackingvehicle 410 as it moves away from the initial identification camera. When used in connection with such tracking, these cameras may be broadly referred to as “tracking cameras.” - At time t5, the third destination camera captures another
destination image 420 d′ ofvehicle 410 at the location designated 410 d. At approximately time t5, a fourth destination camera capturesdestination image 420 e ofvehicle 410 withinoverlap area 430 d (for example, at approximately thelocation 410 d). In some embodiments, the third destination camera and the fourth destination camera are synchronized, such thatimages 420 d′ and 420 e are both captured at essentially the same time t5.Overlap area 430 d corresponds to the field of view ofdestination image 420 d′ which overlaps the field of view ofdestination image 420 e. In bothimages 420 d′ and 420 e, images ofvehicle 410 have been captured whilevehicle 410 is withinoverlap area 430 d. - Based on one or more destination images captured by the third destination camera (such as
identification image 420 d′),server system 140 determines a plurality of characteristics Cd forvehicle 410. As noted above, fixed characteristics forvehicle 410 and recorded indatabase 141 may be included in Cd. Based ondestination image 420 e, and possibly other destination images captured by the fourth destination camera,server system 140 determines a plurality of characteristics Cd′ forvehicle 410.Server system 140 then determines whether Cd′ corresponds to Cd. If Cd′ is determined to correspond to Cd, thenserver system 140 records indatabase 141, in connection with the unique identifier, thatvehicle 410 was observed by the fourth destination camera at time t5. In an alternative embodiment,server system 140 instead stores in volatile memory thatvehicle 410 was observed by the fourth destination camera at time t5, and such information is recorded indatabase 141 after a determination thatvehicle 410 has made use of a destination location prior tovehicle 410 being identified byserver system 140 via identification images obtained from an identification camera other than the identification camera which captured identification image 420. - In association with the field of view for
image 420 e illustrated inFIG. 4 , fourappropriate destination locations 450 a to 450 d (such as parking spots with a hourly rate for use) have been specified toserver system 140. At time t6,destination image 420 e′ is captured by the fourth destination camera, at a time whenvehicle 410 is atlocation 410 e. Based ondestination image 420 e′,server system 140 determines thatvehicle 410 is within the rectangular region specified fordestination location 450 b. At time t7,destination image 420 e″ is captured by the fourth destination camera, withvehicle 410 remaining atlocation 410 e. Based ondestination image 420 e″,server system 140 again determines thatvehicle 410 is within the rectangular region specified fordestination location 450 b, accordingly determines thatvehicle 410 began use ofdestination location 450 b beginning at time t6, and records this information indatabase 141. At time t8,destination image 420 e′″ is captured by the fourth destination camera, at a time whenvehicle 410 has exiteddestination location 450 b. Based ondestination image 420 e′″,server system 140 determines thatvehicle 410 is no longer within the rectangular region specified fordestination location 450 b, accordingly determines thatvehicle 410 completed its use ofdestination location 450 b at time t8. Based on information as to restrictions applicable to use ofdestination location 450 b from the time period t6 to t8, such as, for example, an hourly rate for use of thedestination location 450 b,server system 140 can initiate actions such as billing an end user account for this use ofdestination location 450 b, or such as levying a fine for improper use ofdestination location 450 b. -
Server system 140 is also configured to correctly identify a vehicle which has made use of a destination location whereserver system 140 first determines that a vehicle has made use of a destination location, and then later is able to capture a vehicle identification via an identification camera. This situation may occur where, for example, a view of a vehicle is obstructed as it passes by an identification camera, or a restart ofserver system 140 results an identification of the vehicle not being made previously. As an example, if at time t0, before time t1, the fourth destination camera were to first determine thatvehicle 440 was making use ofdestination location 450 c, but not have an identification forvehicle 440, a temporary unique identifier would be assigned tovehicle 440, and entries recorded indatabase 141 in connection with the temporary identifier. Sets of vehicle characteristics would be determined forvehicle 440 while it made use ofdestination location 450 c, as well as when it passed throughoverlap areas same vehicle 440 associated with the temporary identifier, was still being observed. Once observed by the first identification camera while located inoverlap area 430 a,server system 140 would be able to determine a correct unique identifier forvehicle 440. At that point, records previously recorded indatabase 141 under the temporary identifier can be modified or stored again under the correct unique identifier forvehicle 440, which the use ofdestination location 450 c properly associated with that identifier. An alternative mechanism for obtaining an identification ofvehicle 440 after time t0 is to dispatchmobile device 150 to capture one or more identification images ofvehicle 440 while it is making use ofdestination location 450 c. Dispatch ofmobile device 150 may be designated a higher priority where the use ofdestination location 450 c byvehicle 440 is determined to conflict with restrictions associated with use ofdestination location 450 c. -
Server system 140 receives images from the identification and destination cameras and interpolates the identities of parked vehicles.Server system 140 may then retrieve parking payment information (such as, but not limited to, duration of paid parking and time of expiration) from a third-party parking payment system via an API (application programming interface). If a vehicle parking status is determined to be either unpaid or expired, theserver system 140 transmits this information to the third-party parking payment system via an API. The parking facility operator which runs the third-party payment system can then follows its Standard Operating Procedures (SOP) in dealing with parking violations (such as, but not limited to, mailing a parking violation ticket, installing a wheel clamp on the vehicle, or towing the vehicle upon repeated or severe parking violations). - Vehicle detection by
server system 140 may be configured to perform several functions: (1) detecting the presence and location of vehicles in video frames; (2) distinguishing moving vehicles from stationary vehicles; (3) identifying whether particular detected vehicles are occupying destination locations, such as parking spaces or no-parking areas; (4) determine a time at which a vehicle begins to occupy or vacates a destination location; (5) track vehicles as they travel from the field of view of one tracking camera to another, and raise an exception if an error in this tracking is determined to have occurred. In an embodiment,server system 140 may also be configured to identify whether particular vehicles are displaying an appropriate indicator for access or use of a destination location. Examples of such indicators include, but are not limited to, a handicapped parking hanger or decal, or a parking hanger or decal indicating authorized use of a “resident only” parking location. A camera may be zoomed in to more clearly capture images of such indicators. In an embodiment, a vehicle identifier, such as a license plate, may be used to determine appropriate access or use of a destination location, and obviate the need for a separate indicator. - In an example implementation,
server system 140 may be programmed to use threads to carry out its tasks for identification and destination cameras. For example, a “video_receiver” thread may handle the reception of a video and/or image stream from an identifier or destination camera and store raw video and/or image information. This may be with one thread per video and/or image stream or multiple video and/or image streams. Configurable options for this thread may include (1) store to file, (2) store to memory, (3) store to memory and file, (4) a retention time for video data (for example, 4 hours)). Another example is a thread to detect vehicle color, shape, location, lane position, speed/direction of travel, whether a vehicle location is in a handoff zone (and which one), camera identification, and storing such information indatabase 141. This thread would examine each multiple video frames to determine updated locations and speed/direction of travel of vehicles and storing such information indatabase 141. There may be one thread per video and/or image stream or multiple video and/or image streams. Another example is a thread which confirms a particular vehicle detected as exiting via a handoff zone is detected by a nearby camera. This may be done, for example, by reviewing thedatabase 141 for a particular camera based on in which handoff zone the vehicle was detected and/or a detected direction of travel for the vehicle. There may be one thread per video and/or image stream or multiple video and/or image streams. Another example is a thread to determine whether a vehicle is occupying a destination location by remaining stationary at that destination location, along with a time when vehicle begins to occupy or vacates the destination location. There may be one thread per video and/or image stream or multiple video and/or image streams. - Many machine vision techniques are known in the art which may be used for detecting the presence of vehicles in video frames. For example, there are various known edge detection algorithms which may be used for detecting the presence of vehicles. As an example, an algorithm may detect the presence of a vehicle based on differences in color between the vehicle and the background, and whether a size of a total shape is larger than a minimum vehicle size expected in consideration of zoom level and/or location in a field of vision. For example, the algorithm may compare colors of pixels in a video stream snapshot against each other. Since an image likely includes various non-vehicle objects such as a fire hydrant, pedestrian, grass, road markings, and paint, the algorithm may detect groups of pixels with similar colors (with a configurable range of variation in color considered to be a match). The number and location of pixels in the total shape are used to determine whether the shape is larger than the minimum vehicle size. The algorithm may further accommodate “holes” or imperfections in the shape, which may occur due to specular reflections or highlights, for example. Additionally, the algorithm may determine whether a number of shapes of respective minimum sizes are within certain distances of each other. These shapes may correspond to, for example, hood, roof, and trunk portions of a vehicle, which are typically of the same color.
- A boundary condition may occur where there is insufficient contrast or difference in color between a vehicle and the background, in which detection may fail. For example, a black vehicle against black asphalt. Further refinements, to camera hardware and/or the algorithm, may be introduced to address this boundary condition. For example, a camera that performs both visible light and thermal imaging may be used, which obtains a heat signature of a vehicle that has begun occupying a destination location. In this example, the engine compartment would have a different thermal profile than its surrounding even though both the vehicle and the backdrop are black in color. Further cost-benefit analysis would determine whether the benefits gained from such an approach justifies the incremental cost, as well as taking in account any boundary conditions caused by the thermal imaging process can be sufficiently addressed (such as by the visible light captured by the camera).
- Although the presence and many characteristics of a vehicle can be recognized from a single image, multiple images are needed and used to determine, for example, if the vehicle is stationary or moving. In an example,
server system 140 may be configured to: (1) based on determinations of color and size of vehicles in the current image, find corresponding matches in previous images (for example, by reviewing data stored indatabase 141 or memory); and (2) once such matches are found, compare the locations of pixels between the current image and previous images, taking into account any change in zoom level. Based on such processing, one or more of the following scenarios may be detected. (A) if locations of pixels are unchanged or have unchanged below a predetermined threshold, all vehicles are deemed to have remained stationary. In this scenario, a simple update of the date and time is performed for existing entries indatabase 141 or memory for the vehicles. (B) if pixels associated with one or more vehicles are at new locations, then the one or more vehicles are determined to have moved.Server system 140 may calculate speed and direction of travel for these vehicles andupdate database 141 or memory with this information, along with updated locations. (C) if one or more vehicles have disappeared from the current image,server system 140 may be configured to remove data recorded indatabase 141 or memory for such vehicles. (D) if one or more vehicles have newly appeared in the current image, data associated with the new vehicles may be recorded indatabase 141 or memory. In an embodiment,server system 140 may determine that one of the new vehicles corresponds to a vehicle recently determined to have disappeared, and may treat the view of the vehicle as having been temporarily obstructed. (E) if all vehicles have disappeared from the current image, data fromdatabase 141 or memory from the preceding interval may be removed in connection with the vehicles therein. However, some data may be retained in order to perform vehicle tracking to or from an identification camera, as discussed previously. - In an example, an algorithm for identifying which vehicles are occupying destination areas is similar to the basic vehicle detection algorithm. Once vehicle detection is completed,
server system 140 evaluates whether pixel locations corresponding to a vehicle occupy any of the pre-mapped visual regions. A degree of overlap may be configurable. In an embodiment, a vertical offset may be applied to compensate for vehicle height and compensate for a visual obstruction, such as a parked vehicle, between a destination camera and the vehicle. Such obstructions may frequently occur in dense parking lots, for example. Also,server system 140 determines whether the vehicle has remained stationary for at least a certain amount of time. Once it is determined that a vehicle has dwelled in a given destination location for at least the certain amount of time, identification information for the vehicle, the destination location, and a time and date at which the vehicle began to make use of the destination are recorded indatabase 141, preferably in non-volatile storage. In an embodiment,server system 140 may be configured to detect when a vehicle takes up multiple destination locations, such as by occupying two parking spaces. This may result in, for example, issuance of one or more parking citations or increased usage fees.Server system 140 may also determine when the vehicle vacates the destination location, and record corresponding information indatabase 141. Also,server system 140 may be configured to determine when user of the destination location by the vehicle will soon exceed, or has exceeded, a period of time for use of the destination location, such as may occur in connection with a parking spot with a two-hour maximum parking duration, a destination location not available for vehicle use after a specified time for street sweeping, or the exhaustion of funds provided for the vehicle. - In an embodiment,
server system 140 may be configured to recognize one or more multi-vehicle destination locations, which may be used by more than one vehicle at a time. For example,server system 140 may be configured to support tracking for “long block” parking of vehicles, in which a parking area controlled by, for example, a single Pay-by-Space, Pay-and-Display, or Pay-by-Plate unit is provided along the length of a curb for a city block, but the parking area is not divided into marked parking spaces; instead, vehicles can make use of any available space along the curb (excluding certain “no parking” regions, such as, but not limited to, loading zones and driveways). In another example,server system 140 may be configured to track use of a parking lot, but not a plurality of individually marked spaces therein, controlled by, for example, a single Pay-and-Display unit. Althoughserver system 140 may not be configured to track use of a multi-vehicle destination location on a space by space basis,server system 140 may determine and record the position of a vehicle within the multi-vehicle destination location for tracking the vehicle's use over time and for parking enforcement activities, such as attaching a citation to a vehicle which has exceeded its permitted use of the multi-vehicle destination location. In an embodiment,server system 140 may be configured to determine a length of a vehicle making use of a multi-vehicle destination location, as a greater parking fee and/or fine may imposed for the use of space that otherwise could be occupied by more than one vehicle. One benefit of using theserver system 140 described in this application is that whereas conventional controlled parking lots might rely on a single point of ingress and egress for controlling use of the lot, tracking by use of cameras allows for a parking lot with multiple entrances and exits and a more “open” design, as vehicles do not need to be confined by wall of fencing. - In an embodiment, multiple noncontiguous destination locations or multi-vehicle destination locations may be aggregated into a single multi-vehicle destination location. This may include where two constituent destination locations are covered by different destination cameras. This may be useful where, for example, a multi-vehicle destination location is broken up by various “no parking” destination locations along the length of a city block.
- In an embodiment, there may be a restricted destination location (such as a “no parking” overlaying a multi-vehicle destination location, so as to “carve out” restricted areas of the multi-vehicle location. For example, in the “long block” scenario discussed above, a single multi-vehicle destination location may be defined along the entire length of a city block, with “no parking” destination locations overlaying various portions along the city block, such as, but no limited to, loading zones and driveways along the length of the block. A vehicle detected by
server system 140 as making use of one of the “no parking” destination locations will be determined byserver system 140 as having committed a parking violation, despite the vehicle also have been within the larger multi-vehicle destination location. - In an embodiment, a computer-based configuration utility may be provided. For example,
mobile device 150 ormanual review system 180 may be configured with a configuration utility, allowing for on-site or remote configuration. For example,mobile device 150 may be used by a person performing camera installation, in order to provide feedback as to the effectiveness of a camera configuration for vehicle identification, tracking, and/or detection. Alternatively or in addition, certain system or camera configuration changes may be made viamanual review system 180 as a result of configuration shortcoming identified during use ofmanual review system 180. In an embodiment, a user interface may be made available via a web browser. The configuration utility may provide one or more features such as, but not limited to: -
- Providing a graphical user interface (GUI) to perform calibration of vehicle detection for a given camera.
- Providing a GUI for ensuring contiguous camera alignment.
- Providing a GUI for specifying minimal vehicle dimensions. This may be in terms of pixels and adjusted for zoom level.
- Providing a GUI for identifying a portion of a camera's field of view which overlaps with the field of view of another camera.
- Providing a GUI for aligning a camera and/or specifying camera orientation and/or alignment.
- Providing a GUI for pre-mapping destination locations.
- Defining circumstances which are considered vehicle parking violations. Such circumstances may be particular to a given region or location.
- Configure outcomes for various parking violations. For example, information about a violation may be simply displayed on a screen, registered owner information may be obtained for issuing a citation or bill, or a warning may be printed and placed on a vehicle.
- Configuring an expiration period after which a new request for vehicle owner registration information must be made, such to a state-run motor vehicle agency, before issuing a parking citation by way of mail or otherwise.
- Provide a GUI for other system configuration parameters to be reviewed and modified.
- To perform calibration of vehicle detection for a given camera, a GUI presents two image feeds and allows an administrator to superimpose rulers on each image feed. A zoom level, if any, may be displayed as part of the GUI, as may be a control for modifying the zoom level. The two image feeds originate from the given camera and another camera with an overlapping field of vision (such cameras are often adjacent to each other). Preferably, for calibration the capture of images for the two cameras is synchronized such that images are captured at the same time, allowing for review of a vehicle's position in each video feed, such as when it passes through the overlapping area of the two cameras' fields of vision. The configuration utility may also provide, by way of the GUI, temporal image control functions such as pause, play, rewind, fast forward, freeze frame advance, freeze frame reverse, and goto frame functions.
- For calibration, the configuration utility may be used to find one or more vehicles of known make and model in one or both image feeds (this might include, for example, a vehicle used by a technician operating the configuration utility), and position one or more rulers in the GUI such that the rulers indicate the correct length, width, and/or height of the vehicles by reference to known values for these dimensions for the vehicles being measured. In an embodiment, the ruler function provided by the GUI is configured to compensate for nonlinearities due to factors such as visual distortion introduced by the camera (which may have known characteristics based on a camera model, for example) or the perspective of the captured image. For example, ruler markings indicating units of distance may be spaced closer on a right-hand side of an image where vehicles captured in that area are further away from the camera than those captured in the left-hand side of the image. The configuration utility may be configured to allow for on-site calibration of such nonlinearities for a given camera by identifying markers in an image, and specifying positions and/or distances (relative to other markers and/or the camera). Such markers may be temporarily, or in some cases permanently for the purpose of later recalibration, placed by a technician.
- Also, the configuration utility may be used to specify relationships between directions of travel in the two image feeds, as well as identify pixels or image locations corresponding to common points in the two image feeds. In an embodiment, locations and directions of travel may be specified for lanes/paths of traffic in each of the image feeds, and correlated between the two images feeds (allowing, for example, later determination of when a vehicle passes from the field of one camera to another within the same lane/path of traffic). Specification of these features may be done via the GUI, for example by allowing for the overlay of lines or other indicators on the image feeds indicating lane/path boundaries.
FIGS. 6A and 6B illustrate aspects of an example GUI.FIG. 6A illustrates a portion of the GUI in which animage 600 a from a first camera is displayed.FIG. 6B illustrates a portion of the GUI in which animage 600 b from a second camera is displayed. The field of views of theimages overlap including areas images paths FIG. 6A , and lanes/paths FIG. 6B . In this particular example illustrated inFIGS. 6A and 6B , traffic proceeds in the same direction (generally corresponding to angle 8) in lanes/paths paths images FIG. 6A , lane/path boundaries have been specified with the dashed lane/path boundary indicators FIG. 6A , two traffic lanes/paths have been specified using the GUI: the lane/path 611 a between lane/path boundary indicators path 612 a between lane/path boundary indicators FIG. 6A , traffic proceeds in lanes/paths path boundary indicators path boundary indicator 623 a is of a second type indicating the division of the area of unidirectional traffic flow between lane/path boundary indicators paths paths FIG. 6B . InFIG. 6B , the configuration utility provides similar facilities for lane/path identification, with lanes/paths boundary indicator lines FIG. 6A described above. - In an embodiment, each lane/path of traffic may be divided into a number of smaller segments. These segments may be specified via the GUI, for example by allowing for the overlay of lines or other indicators on the image feeds indicating the segments. In an embodiment, the overlaid lines may be used to aid in automatically characterizing nonlinearities in image feeds.
FIG. 6A illustrates an example, with lane/path segment indicator 631 a and other similar unlabeled lane/path segment indicators. The configuration utility may be configured to automatically generate suggested lane/path segment indicators based on previously specified lane/path boundary indicators, and provide via the GUI tools for adjusting the lane/path boundary indicators as desired. Also, the inclusion of vehicle images, such as vehicles A, B, and C shown inFIG. 6A , may aid a technician in accurately placing or adjusting lane/path segment indicators.FIG. 6B illustrates lane/path segment indicator 631 b and other similar unlabeled lane/path segment indicators corresponding to their counterpart inFIG. 6A described above. - The configuration utility may also provide similar features via the GUI for specifying an area of an image stream with an overlapping field of view with a respective area of a second image stream. As these areas are used for “handing off” the detection of a vehicle from one tracking camera to another, these areas may be referred to as “handoff zones.” For example,
FIGS. 6A and 6B illustrate images captured by cameras with overlapping fields of view, in which the field of view forhandoff zone 640 a overlaps the field of view forhandoff zone 640 b. The GUI may be configured to allow for specification ofhandoff border indicators FIG. 6A , and respectivehandoff border indicators FIG. 6B . Also, a specified handoff zone may be divided into a number of smaller segments, usinghandoff segment indicators FIGS. 6A and 6B . The configuration utility may be configured to automatically generate suggested handoff segment indicators based on previously specified handoff boundary indicators, and provide via the GUI tools for adjusting the handoff boundary indicators as desired. Also, the inclusion of vehicle images, such as vehicles A, B, and C shown inFIG. 6A , may aid a technician in accurately placing or adjusting handoff segment indicators. In an embodiment, the configuration utility may be configured to determine a distance betweenhandoff border indicators - Although the GUI illustrated in
FIGS. 6A and 6B shows and describes indicators provided by the GUI as simple lines, the configuration utility and the GUI may also provide for specifying features with more complex shapes, such as, but not limited to, curves and freehand lines. Also, where an indicator specified in connection with a first camera, such as lane/path boundary indicator 623 a, has a counterpart indicator in connection with another camera, such as lane/path boundary indicator 623 b, these counterpart indicators may be linked using the GUI. In an embodiment, such links may be automatically determined or suggested based on information such as previously specified indicators, a known position of a camera, a known orientation of the camera, and known aspects of traffic flow proximate to a camera, such as numbers of lanes/paths and directions of traffic flow within those lanes/paths. - In an embodiment, where a camera provides for zoom and/or pan/tilt capabilities, the configuration utility may be configured to allow for the specification of various indicator features in images captured with the camera at various zoom levels or orientations. This additional information may be used to more fully specify the overall field of view of the camera. Once a technician is satisfied with how indicators and/or rulers have been used to specify the field of view of a camera, this information and/or other information derived therefrom may be stored in
database 141 for use in, for example, vehicle tracking byserver system 140. - The configuration utility may be configured to provide a GUI to perform contiguous video camera alignment. This functionality may be provided via additional user interface elements included in the above-described GUI for specifying lane/path boundaries. Contiguous video camera alignment refers to the fact that during an initial camera hardware installation process, or if existing camera hardware is later updated, if the camera is equipped with pan, tilt, and/or zoom (PTZ) function, the pan, tilt, and/or zoom settings of the camera need to be adjusted and/or calibrated to ensure there is sufficient overlap in the field of vision between cameras, such as the overlap illustrated in
FIGS. 4 , 6A, and 6B. A technician can review the GUI to determine whether a handoff zone of sufficient size and/or duration is provided by a pair of cameras. If not, pan, tilt, and/or zoom settings may require changes, or the physical installation location of a camera may need to be changed altogether. - The configuration utility may be configured to provide a GUI to perform pre-mapping of destination locations, such as parking spaces and “no parking” zones. The GUI presents an image feed and allows a technician to superimpose grayed out polygons, for example, on an image feed. In another nonlimiting example, a parking spot #123 might be mapped to a collection of 20 pixels as captured by a particular destination camera at a given zoom level and/or PTZ orientation. The GUI may be configured to provide operations for including, but not limited to, moving, resizing, and rotating such polygons to indicate the position and extent of destination locations within a field of view of a camera. Where a camera has PTZ capabilities, PTZ controls may be provided. This functionality may be provided via additional user interface elements included in the above-described GUI for specifying lane/path boundaries. The GUI may also provide an interface of assigning an identifier to a destination location which may be used, for example, to provide a common identifier for the destination location for use by various aspects of
server system 140. The GUI may also provide interface elements allowing for various characteristics of a destination location to be specified, although it may be preferable to employ other aspects of the configuration utility orserver system 140 to manage, assign, and/or modify such characteristics with minimal direct human operation. - In an embodiment, the configuration utility may be configured to provide a GUI to perform pre-mapping of multi-vehicle destination locations, discussed above, in much the same manner as the above description for pre-mapping single-vehicle destination locations. The configuration utility may be configured to allow multiple destination locations or multi-vehicle destination locations to be aggregated into a single destination location. For example, each of the constituent destination locations might be assigned a common identifier to indicate they form a multi-vehicle destination location. The configuration utility may be configured to allow restricted destination locations to be overlaid a multi-vehicle destination location, to “carve” out portions of a broad area subject to parking restrictions, such as, but not limited to, loading zones and driveways.
- The configuration utility may be configured to provide a GUI for specifying what constitutes a parking violation. In a first example, a grace period duration may be specified with the GUI, which defines an amount of time a vehicle may occupy a destination location before the vehicle may be considered to be in violation of restrictions on use of the destination location. For example, when a vehicle stops at a parking meter, it is reasonable to provide a grace period sufficient for the driver of the vehicle to leave the vehicle and pay for parking. Differing periods of time may be specified for different types or groups of destination locations (for example, a “no parking” zone may have a small or zero grace period. In a second example, an amount of vehicle overlap may be specified with the GUI, as to how much in terms of square footage or percent area coverage a vehicle overlaps a destination location before the vehicle may be considered to be in violation. In a third example, permit parking rules may be specified with the GUI, including rules in connection with, for example, the use of handicap parking spaces, resident-only parking, or other parking requiring the display of a permit or decal. The GUI may also provide an interface for identifying characteristics and features of a required permit or decal, such as, but not limited to, color, an image featured on the permit or decal, and a location of an identifier (such as a serial number) for the permit or decal. In a fourth example, a GUI may be configured to define rules for determining what constitutes an expired license plate tag, such as whether a tag indicating the current month is considered to have expired.
- The configuration utility may be configured to provide a GUI for specifying consequences for vehicle misuse of a destination location. Examples include, but are not limited to, on-screen display of license plate information, license plate lookup to obtain the name and address of a registered owner, dispatching an enforcement officer, provide a laser-based illumination of a vehicle misusing a destination location, applying a parking fine to a credit card or account on file, and deducting a parking fine from a checking or other monetary account.
- The configuration utility may be configured to receive and record parameters specifying certain vehicles for which outcomes of detected parking violations would be modified (for example, a police vehicle may be identified as exempt from specified violations). For example, such vehicles may be identified by license plate number, or bear a specified identifier such as a decal.
- In an embodiment,
server system 140 may be configured to obtain preexisting street and/or parking information, which may be obtained through a commercial or municipal database and/or provided by a parking operator, and automatically determining destination and traffic lane/path information In an embodiment, based on information indicating the location and orientation of the various identification and destination cameras,server system 140 may be configured to automatically pre-map destination locations and/or traffic lanes/paths. In an embodiment,server system 140 may be configured to record and/or update characteristics for destination locations and or traffic lanes/paths recorded indatabase 141, such as, but not limited to, identifiers, locations (for example, latitude/longitude or street address), rates for use of destination locations, and time-based, date-based, and other restrictions for destination locations described in this application. In an embodiment,server system 140 may provide an API to more easily allow a parking provider to upload destination location information and/or updates in bulk. - In an alternative embodiment,
server system 140 and other elements illustrated inFIG. 1 are in the form of a turnkey platform where no integration with third-party parking payment systems via an API is required. In such an embodiment, part of the turnkey platform consists of payment stations/equipment, and equipment that generates parking violation tickets for mailing. - In an embodiment,
onsite payment system 160 may include a turnkey platform Pay-by-Phone feature. The end result is that end users can pay for parking by calling a particular IVR (interactive voice response) system-driven phone line and input a destination location identifier or vehicle license plate number and a duration of parking, regardless of whether a destination location is associated with a curbside parking meter, a Pay-by-Space parking space, or a parking lot. - The turnkey Pay-by-Phone module enables end users to pay for parking by use of a telephone—typically cellular phone. The turnkey Pay-by-Phone machine enables database-level integration with
server system 140. Database-level integration is superior to API-level integration since database-level integration offers more flexibility and speed. - The turnkey Pay-by-Phone module receives data from one or more DTMF transceivers where users enter information over the telephone. There is no requirement for the turnkey Pay-by-Phone module to receive data from
server system 140 in order for the turnkey Pay-by-Phone module to operate correctly. The turnkey Pay-by-Phone module may be configured to output data tomobile device 150 for manual paid parking validation, as well as toserver system 140 for self-enforcement. All self-enforcement data processing takes place onserver system 140. - In an embodiment,
onsite payment system 160 may include Pay-Online on a turnkey platform. The end result is that end users can pay for parking or view prior history by visiting a website and enter a destination location identifier or vehicle license plate number and the duration of parking regardless of whether a destination location is associated with a curbside parking meter, a Pay-by-Space parking space, or a parking lot. This extends to other online conduits such as smart phones and, in the future, Internet-enabled media centers in cars. - The turnkey Pay-Online module receives data online where end users enter information over the Internet. There is no requirement for the turnkey Pay-Online module to receive data from
server system 140 in order for the turnkey Pay-Online module to operate correctly. The turnkey Pay-Online module outputs data to themobile device 150 for manual paid parking validation, as well as to theserver system 140 for self-enforcement. All self-enforcement data processing takes place onserver system 140. - In an embodiment,
onsite payment system 160 may include a Pay-and-Display machine with QR codes. QR codes have become popular, and accordingly have significant smartphone support. Further, QR codes can easily hold all of the relevant information typically contained on a Pay-and-Display ticket (such as, but not limited to, parking duration, parking expiration time, amount paid, date, and time). The turnkey Pay-and-Display machine allows end users to pay for parking and leave a display ticket with a QR code on the dash of the vehicle. The turnkey Pay-and-Display machine enables database-level integration withserver system 140. Database-level integration is superior to API-level integration since database-level integration offers more flexibility and speed. - The turnkey Pay-and-Display machine receives payment from end users via a built-in keypad, coin acceptor, credit card reader, and printer. There is also a text/graphics LCD display. There is no requirement for the turnkey Pay-and-Display machine to receive data from
server system 140 in order for the turnkey Pay-and-Display machine to operate correctly. The turnkey Pay-and-Display machine outputs data tomobile device 150 for manual paid parking validation, as well as toserver system 140 for self-enforcement. All self-enforcement data processing takes place onserver system 140. - In an embodiment,
onsite payment system 160 may include a Pay-by-Space turnkey machine. Pay-by-Space is increasingly becoming popular compared to Pay-and-Display which has a longer history of operation. Parking operations using Pay-by-Space are generally more efficient since parking enforcement personnel no longer have to walk to each vehicle and lean into the windshield in order to manually check the printed expiration time. Instead, they can drive in a patrol vehicle and perform visual checks from a distance to see whether an occupied parking space has been paid for. In addition, Pay-by-Space offers enhanced user experience since drivers no longer have to walk back to their vehicles to display the ticket after paying at the machine—instead, they can continue on to their destination. - The turnkey Pay-by-Space machine receives payment from end users via a built-in keypad, coin acceptor, credit card reader, and printer. There is also a text/graphics LCD display. There is no requirement for the turnkey Pay-by-Space machine to receive data from
server system 140 in order for the turnkey Pay-by-Space machine to operate correctly. The turnkey Pay-by-Space machine may output data to themobile device 150 for manual paid parking validation, as well as toserver system 140 for self-enforcement. All self-enforcement data processing takes place onserver system 140. - In an embodiment,
onsite payment system 160 may include a Pay-by-Plate turnkey machine. The turnkey Pay-by-Plate machine receives payment from end users via a built-in keypad, coin acceptor, credit card reader, and printer. There is also a text/graphics LCD display. There is no requirement for the turnkey Pay-by-Plate machine to receive data fromserver system 140 in order for the turnkey Pay-by-Plate machine to operate correctly. The turnkey Pay-by-Plate machine may output data to themobile device 150 for manual paid parking validation, as well as toserver system 140 for self-enforcement. All self-enforcement data processing takes place onserver system 140. - Integration with third-party parking systems is an option rather than a requirement for
server system 140. In a turnkey configuration where the entire parking equipment platform is provided, for example, through a single supplier, no integration with third party parking systems is required. However, there are many advantages to the integration approach using API. An API provides a standard software programming interface designed to allow an external program to gain access to information in a host system without exposing any trade secrets of the host system. This is achieved by creating clearly defined functions, objects, and variables at the boundary of the two systems, such that the external system is allowed to obtain pre-defined set of information without any knowledge of how the information is gathered, stored, or calculated within the host system itself. As such, companies generally have no reservations with publishing API for other systems to interface to its products or servers. Data may be exchanged via an API via network-based mechanisms, often protected by encryption mechanisms such as SSL, relying on XML, JSON, HTML, MIME, or other encodings or languages supported by the API. - There are two ways for
server system 140 to integrate with an API. First, by using an API published by the third-party parking system,server system 140 can gain access to vehicle payment information (such as, but not limited to, duration paid, and space number). Combined with the vehicle detection and vehicle identityinformation server system 140 already possesses,server system 140 has or can readily obtain the complete information necessary to produce a list of vehicle license plates with detailed parking violation information to a parking facility operator. The parking facility operator can then follow its SOP, and mail parking violation tickets, install wheel clamps, or tow repeat or severe offenders. - The second integration method is for
server system 140 to publish its own API so third-party parking systems can obtain information on vehicle detection and vehicle identity. Combined with the vehicle payment information already possessed by the third-party parking system, the third-party parking system can then provide a seamless presentation to the parking operator including a list of vehicle license plates with detailed parking violation information. The third-party parking system provider may prefer this approach in order to retain control over how the parking violation information flows back to the parking operator. - By use of APIs,
server system 140 can integrate with the following types of parking payment systems: Pay-by-Phone, Pay-by-Space, Pay-and-Display, Curbside Parking Meters (single or double space), and Live-Operator Option. - The basic premise of Pay-by-Phone is an end user (such as a driver of a vehicle) calls a phone number displayed in the vicinity of a destination location. Typically the phone number offers IVR (interactive voice response) which guides callers through an automated menu. The end user is prompted to input a unique destination location number, followed by parking duration desired, vehicle license plate number, and credit card information.
- Pay-by-Phone is starting to gain traction as a popular “overlay” payment approach, where parking facility operators add Pay-by-Phone capability to curbside parking meters, Pay-by-Space, and Pay-and-Display machines. The typical motivation is to provide end users an alternate way of paying for parking in an effort to increase parking revenue. For example, Pay-by-Phone may be added to traditional curbside parking meters (single or double space) in order to allow end users to pay with credit cards over the phone.
- In an embodiment,
server system 140 may include a Pay-by-Phone integration module, which may be a software component that extracts parking payment information from a third party parking payment system whichserver system 140 uses for parking self-enforcement. The integration module for pay-by-phone performs steps including: (1) establishing a connection with a third-party Pay-by-Phone API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the third-party Pay-by-Phone API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection. In connection with step (1), an API typically specifies the mechanism through which a connection to it can be established. The Pay-by-Phone integration module is configured to observe the protocol required by the third-party Pay-by-Phone API and establishes a connection. - In connection with step (2), when
server system 140 determines that a particular vehicle has vacated a destination location,server system 140 signals this event to the Pay-by-Phone integration module, such as via a database or Inter-Process Communication (IPC) call, in response to which the Pay-by-Phone integration module issues a request to the third-party Pay-by-Phone API for parking payment information for the particular vehicle. Data sent to the third-party Pay-by-Phone API may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the Pay-by-Phone API (which may require translation from an identifier used internally by server system 140), and a date/time the particular vehicle vacated the destination location. - In connection with step (3), the Pay-by-Phone integration module may be configured to receive information from the third-party Pay-by-Phone API including, for example, a paid parking start date/time and a paid parking end date/time. In connection with step (5), the Pay-by-Phone integration module may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by
server system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - In an embodiment in which an API provided by
server system 140 is used for integration, the Pay-by-Phone system will obtain only the vehicle detection information (actual vehicle parking start and end times) fromserver system 140 since typically vehicle license plate information is already possessed by the Pay-by-Phone system. The end result is the Pay-by-Phone system will have the precise information required to generate a list of vehicle license plates with parking violation details. - Typically when a Pay-by-Phone system or its staff is agreeable to using the API provided by
server system 140, the Pay-by-Phone system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data fromserver system 140. In this particular case, the useful data is actual vehicle parking duration, indicating an actual amount of time a particular vehicle has occupied a specific destination location, for a particular vehicle license plate number or destination location number. In general, Pay-by-Phone systems already have the vehicle license plate number or destination location number, as they are generally obtained as part of the end user payment process. - Integration via a Pay-by-Phone API provided by
server system 140 may be according to one of two options. First is a data inflow model, in which the third party parking payment system pushes information intoserver system 140. Second is a data outflow model, in whichserver system 140 pushes all relevant information to the Pay-by-Phone system. - In an embodiment,
server system 140 may include an inflow-based Pay-by-Phone API for use by a third-party parking payment system via, for example,network 110, in which the third party parking payment system pushes information intoserver system 140 via the inflow-based Pay-by-Phone API. The inflow-based Pay-by-Phone API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Pay-by-Phone API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the inflow-based Pay-by-Phone API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the inflow-based Pay-by-Phone API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking. The received information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for a destination location for which payment was received in connection with the particular vehicle (which may require translation to an identifier used internally by server system 140), a paid parking start date/time, and paid parking end date/time. In connection with step (5), a Pay-by-Phone integration module included inserver system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined byserver system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - In an embodiment,
server system 140 may include an outflow-based Pay-by-Phone API for use by a third-party parking payment system via, for example,network 110, in whichserver system 140 pushes all relevant information to the third-party Pay-by-Phone system. The outflow-based Pay-by-Phone API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the outflow-based Pay-by-Phone API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the outflow-based Pay-by-Phone API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system. The uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location. - In another embodiment, integration between a Pay-by-Phone system and
server system 140 takes place in two steps. First,server system 140 obtains vehicle payment information from the Pay-by-Phone system (such as paid parking start and end times, parking space number, vehicle license plate number) by using the Pay-by-Phone system-provided API. At this stage, theserver system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. However, instead ofserver system 140 presenting this list to a parking operator, there may be instances where an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Pay-by-Phone system by using the API provided byserver system 140. The Pay-by-Phone system will then have total control over how the list of “offending” vehicles is presented to the parking operator (for example, by way of a custom software application developed by the Pay-by-Phone system vendor). - A significant difference between this integration method and only relying on integration via the API provided by
server system 140 is that this integration method requires minimal development effort on the part of the Pay-by-Phone system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided byserver system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development. This integration approach represents a “pull” followed by a “push” model. - The premise of Pay-by-Space is that once an end user parks a vehicle, the end user notes the space number of the parking spot. When the end user pays for parking at a Pay-by-Space machine, the end user enters a stall number followed by parking duration desired. Once the payment is complete, the end user does not need to leave a ticket in the vehicle, instead the end user can simply continue on to wherever they are going. Pay-by-Space works equally well for both on-street curbside parking and off-street parking lots/parking garages.
- Pay-by-Space is increasingly becoming popular compared to Pay-and-Display, which has a longer history of operation. Parking operations using Pay-by-Space are generally more efficient since parking enforcement personnel no longer have to walk to each vehicle and lean into the windshield in order to manually check a printed expiration time. Instead, they can drive in a patrol vehicle and perform visual checks from a distance to see whether an occupied parking space has been paid for. In addition, Pay-by-Space offers enhanced an user experience since end users no longer have to walk back to their vehicles to display the ticket after paying at the machine—instead, they can continue on to their destination.
- Similar to the above-described Pay-by-Phone, integration can be accomplished by using either a Pay-by-Space system-provided API or an API provided by
server system 140. The objective is for either system to gain access to all the information required to generate a list of vehicle license plates with parking violation information. - In an embodiment in which
server system 140 is integrated via a Pay-by-Space system-provided API,server system 140 obtains vehicle payment information from the Pay-by-Space system (such as paid parking start and end times, destination location number, and vehicle license plate number). The end result isserver system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. - In an embodiment,
server system 140 may include a Pay-by-Space integration module, which may be a software component that extracts parking payment information from a third party parking payment system whichserver system 140 uses for parking self-enforcement. The integration module for pay-by-space performs steps including: (1) establishing a connection with a third-party Pay-by-Space API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the third-party Pay-by-Space API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection. In connection with step (1), an API typically specifies the mechanism through which a connection to it can be established. The Pay-by-Space integration module is configured to observe the protocol required by the third-party Pay-by-Space API and establishes a connection. - In connection with step (2), when
server system 140 determines that a particular vehicle has vacated a destination location,server system 140 signals this event to the Pay-by-Space integration module, such as via a database or Inter-Process Communication (IPC) call, in response to which the Pay-by-Space integration module issues a request to the third-party Pay-by-Space API for parking payment information for the particular vehicle. Data sent to the third-party Pay-by-Space API may include, for example, an identifier for the destination location recognized by the Pay-by-Space API (which may require translation from an identifier used internally by server system 140), and a date/time the particular vehicle vacated the destination location. - In connection with step (3), the Pay-by-Space integration module may be configured to receive information from the third-party Pay-by-Space API including, for example, a paid parking start date/time and a paid parking end date/time. In connection with step (5), the Pay-by-Space integration module may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by
server system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - In an embodiment in which
server system 140 is integrated with a Pay-by-Space system via an API provided byserver system 140,server system 140 transmits vehicle information to the Pay-by-Space system (such as vehicle license plate number, destination location, and actual parking start and end times). The end result is the Pay-by-Space system will have the precise information required to generate a list of vehicle license plates with parking violation details. - Typically when a Pay-by-Space system or its staff is agreeable to using the API provided by
server system 140, the Pay-by-Space system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data fromserver system 140. In this particular case, the useful data is actual vehicle parking duration, an actual amount of time a particular vehicle has occupied a specific destination location, for a particular vehicle license plate number or space number. In general, Pay-by-Space systems already have the vehicle license plate number or space number, as this may be obtained as part of the end user payment process. - Integration via a Pay-by-Space API provided by
server system 140 may be according to one of two options. First is a data inflow model, in which the third party parking payment system pushes information intoserver system 140. Second is a data outflow model, in whichserver system 140 pushes all relevant information to the third-party Pay-by-Space system. - In an embodiment,
server system 140 may include an inflow-based Pay-by-Space API for use by a third-party parking payment system via, for example,network 110, in which the third party parking payment system pushes information intoserver system 140 via the inflow-based Pay-by-Space API. The inflow-based Pay-by-Space API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Pay-by-Space API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the inflow-based Pay-by-Space API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the inflow-based Pay-by-Space API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking. The received information for a particular vehicle may include, for example, an identifier for a destination location for which payment was received in connection with the particular vehicle (which may require translation to an identifier used internally by server system 140), a paid parking start date/time, and paid parking end date/time. In connection with step (5), a Pay-by-Space integration module included inserver system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined byserver system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - In an embodiment,
server system 140 may include an outflow-based Pay-by-Space API for use by a third-party parking payment system via, for example,network 110, in whichserver system 140 pushes all relevant information to the third-party Pay-by-Space system. The outflow-based Pay-by-Space API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the outflow-based Pay-by-Space API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the outflow-based Pay-by-Space API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system. The uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location. - In another embodiment,
server system 140 is configured to integrate with a Pay-by-Space system in two steps. First,server system 140 obtains vehicle payment information from the Pay-by-Space system (for example, paid parking start and end times, parking space number, vehicle license plate number) by using a Pay-by-Space system-provided API. At this stage,server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. However, instead ofserver system 140 presenting this list to the parking operator, there may be instances where an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Pay-by-Space system by using the API provided byserver system 140. The Pay-by-Space system will then have total control over how the list of “offending” vehicles is presented to the parking operator (such as by way of a custom software application developed by the Pay-by-Space system vendor). - A significant difference between this integration method and integration with the Pay-by-Space system via the API provided by
server system 140 is that this integration method requires minimal development effort on the part of the Pay-by-Space system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided byserver system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development. This integration approach represents a “pull” followed by a “push” model. - The premise of a Pay-and-Display is that once an end user pays for parking, the end user needs to leave a ticket inside the vehicle on the dashboard in order for parking enforcement personnel to perform visual checks of the ticket to ensure that the period of time paid for by the end user has not expired.
- Historically Pay-and-Display dominated off-street parking lots and parking garages. Despite the recent popularity of Pay-by-Space machines, Pay-and-Display still has a vast installed base. There are also Pay-and-Display systems deployed for curbside parking.
- In order to provide self-enforcement capability,
server system 140 requires the following information: vehicle license plate information (including state/province), actual parking start and end times, paid parking duration. - In an embodiment integrating
server system 140 with a Pay-and-Display system,server system 140 gathers vehicle license plate information via the identification cameras, while the destination cameras provide actual parking start and end times by allowingserver system 140 to determine when a vehicle pulls into a destination location and when the vehicle leaves. Paid parking duration may be determined by utilizing destination cameras with pan, tilt, and zoom capability, and zooming in to extract a bar code or printed characters from the display ticket itself which an end user places on a vehicle dashboard. - In an embodiment, to facilitate the reading of such information, a Pay-and-Display machine may be configured to use a larger font for the printed characters or print larger versions of other identifying features. In another embodiment, a Pay-and-Display machine may be configured to ask for a license plate number as part of a payment process, whereas a conventional system would only ask for an amount of time a driver wishes to park a vehicle. In an embodiment, a Pay-and-Display machine may utilize rolls of display ticket paper with an RFID chip embedded within each display ticket.
- In an embodiment,
server system 140 may be configured to perform pedestrian tracking based on multiple images captured via one or more cameras, such as a camera including a Pay-and-Display machine within its field of view. With pedestrian tracking,server system 140 may be configured to track a driver and/or passenger of a vehicle as they walk to and/or from a vehicle for which payment is obtained via the Pay-and-Display machine, much asserver system 140 performs vehicle tracking. Based on the tracked pedestrian movement, the payment may be linked to a particular location for a vehicle, and a corresponding vehicle identifier, such as a license plate number, determined byserver system 140. Such an embodiment eliminates a need to capture information directly from a printed ticket. In an example,server system 140 may receive a plurality of pedestrian images captured by one or more cameras, including one or more images demonstrating an individual was a passenger of the vehicle, and one or more images demonstrating the passenger made a payment at a Pay-and-Display payment station for use of a destination location.Server system 140 may be configured to perform tracking by determining whether characteristics determined for pedestrians captured in the pedestrian images correspond over time, demonstrating that the passenger traveled between the vehicle and the payment station, and made the payment. Based on this,server system 140 may associate the payment with use of a particular destination location by the vehicle. - With the above information available,
server system 140 is able to produce a list of vehicle license plates with detailed violation information. This holds true regardless of whether the Pay-and-Display system supports real-time wireless networking since the Pay-and-Display system itself does not possess any of the said information. - In an embodiment integrating
server system 140 with a Pay-and-Display system via an API provided byserver system 140, to provide self-enforcement capability,server system 140 requires vehicle license plate information (including state/province information), actual parking start and end times, and paid parking duration. -
Server system 140 gathers vehicle license plate information via the identification cameras, while the destination cameras allowserver system 140 to determine actual parking start and end times by detecting when a vehicle pulls into a parking space and when it leaves. Paid parking duration is determined by using destination cameras with pan, tilt, and zoom functionality, enabling zooming in to extracting the bar code or printed characters from the display ticket itself which end users place on the vehicle dash. - The Pay-and-Display API provided by
server system 140 may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the Pay-and-Display API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the Pay-and-Display API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system. The uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location. - When
server system 140 is configured to operate in this mode,server system 140 transmits vehicle parking violation information to the Pay-and-Display system (such as vehicle license plate number, paid parking start and end times, actual parking start and end times). The end result is the third-party Pay-and-Display system will have the precise information required to generate a list of vehicle license plates with parking violation details. - Typically when a Pay-and-Display system or its staff is agreeable to using the API provided by
server system 140, the Pay-and-Display system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data fromserver system 140. In this particular case, the useful data is the paid parking start and end times, and actual vehicle parking start and end times for a particular vehicle license plate number. In general, Pay-and-Display systems are paper-based (as they rely on a printed display ticket) and do not possess any information with respect to vehicle identity or destination location number. While Pay-and-Display systems do possess paid parking start time and paid parking duration, these systems have no knowledge of which vehicle the paid parking correlates to. The Pay-and-Display system has the option of presenting a list of vehicles with parking violation information to the parking operator by using an API provided byserver system 140. Through the API, the Pay-and-Display system can obtain the pertinent information fromserver system 140 and present it in any desired format. - As such, integration via the API provided by
server system 140 is a “push” model whereserver system 140 “pushes” all relevant information to the Pay-and-Display system. Subsequently, the Pay-and-Display system displays a list of vehicle license plates with unpaid or expired parking. In other words, Pay-and-Display integration via the API provided byserver system 140 is generally not accomplished in a “pull” model. - In an embodiment, a Pay-and-Display machine with QR codes may be provided. QR codes have become popular, and can easily hold all of the relevant information typically contained on a Pay-and-Display ticket (such as parking duration, parking expiration time, amount paid, date, and time).
- In an embodiment, a Pay-by-Phone system may overlay a Pay-and-Display parking system, and
server system 140 may be integrated with the Pay-by-Phone payment system via API. In such a case, where a Pay-by-Phone system-provided API is used,server system 140 will transmit vehicle detection information to the Pay-by-Phone system since typically the vehicle license plate information is already possessed by the Pay-by-Phone system. The end result is the Pay-by-Phone system will have the information required to generate a list of vehicle license plates with parking violation details. - While traditional curbside parking meters (single or double space) would only accept coins with no built-in intelligence or networking capability, Pay-by-Phone has become a popular “overlay” payment approach which works well with traditional curbside parking meters. Recently there has also been an emergence of curbside parking meters which accept both coins and credit cards, and have networking capability built-in.
- Traditional parking meters generally have either a mechanical or an LCD display “expired flag” to indicate that a paid parking period has expired or parking is simply not paid. When parking has been paid and there is time remaining, the mechanical expired flag (typically red) is hidden from view, whereas the LCD display shows a clear display on the side of the meter facing the roadway. In contrast, when paid parking has expired or when no payment has been made, the red mechanical expired flag is prominently displayed in the “up” position, while the LCD display facing the roadway flashes alternately between a clear display and a dark display (sometimes also with a flashing red LED). Both of these are generally referred to as an expired flag.
- In an embodiment,
server system 140 can interface with traditional curbside parking meters using a combination of information gathered from both identification and destination cameras. In addition to identifying vehicle parking status (such as, but not limited to, parking start and end times), images captured by the identification and destination cameras can pinpoint paid parking status (such as, but not limited to, whether a prepaid time has expired) on the parking meters. -
Server system 140 gathers vehicle license plate information via the images captured by identification cameras, while images captured by destination cameras enableserver system 140 to determine actual parking start and end times by detecting when a vehicle pulls into a parking space and when it leaves. Time of expiration of paid parking is determined by zooming in with both location and destination cameras and monitoring the visible status of the expiration flag on each parking meter. Based on this information,server system 140 may determine parking violation status, and mark use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic. In situations where an expiration flag is not readable byserver system 140,server system 140 may be configured to indicate an exception to a parking operator or staff and/or make use of a Live Operator (discussed below) to manually determine parking violation status and/or exception flag status. - A destination image captured by a destination camera from across the street will have sufficient angle of view to monitor the status of the expiration flag on each parking meter. Additionally, an identification camera with pan, tilt, and zoom capability can be provided with sufficient zoom power and angle of view to also monitor the expiration flag status on each parking meter. With the above information available,
server system 140 is able to produce a list of vehicle license plates with detailed violation information. - In an embodiment integrating
server system 140 with a Traditional Curbside Parking Meter system via an API provided byserver system 140, to provide self-enforcement capability,server system 140 requires vehicle license plate information (including state/province information), actual parking start and end times, and paid parking duration. -
Server system 140 gathers vehicle license plate information via the images captured by identification cameras, while images captured by destination cameras enableserver system 140 to determine actual parking start and end times by detecting when a vehicle pulls into a parking space and when it leaves. Time of expiration of paid parking is determined by zooming in with both location and destination cameras and monitoring the visible status of the expiration flag on each parking meter. Based on this information,server system 140 may determine parking violation status, and mark use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic. In situations where an expiration flag is not readable byserver system 140,server system 140 may be configured to indicate an exception to a parking operator or staff and/or make use of a Live Operator (discussed below) to manually determine parking violation status and/or exception flag status. - The Traditional Curbside Parking Meter API provided by
server system 140 may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the Traditional Curbside Parking Meter API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the Traditional Curbside Parking Meter API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system. The uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location. - When
server system 140 is configured to operate in this mode,server system 140 transmits vehicle parking violation information to the Traditional Curbside Parking Meter system, which is typically a payment collection/tallying system with no connectivity to the actual curbside meters. The end result is that the Traditional Curbside Parking Meter system will have the precise information required to generate a list of vehicle license plates with parking violation details. - Typically when a Traditional Curbside Parking Meter system or its staff is agreeable to using the API provided by
server system 140, the Traditional Curbside Parking Meter system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data fromserver system 140. In this particular case, the useful data is the expired or unpaid parking status, and actual vehicle parking start and end times for a particular vehicle license plate number. In general, Traditional Curbside Parking Meter systems do not possess any information with respect to vehicle identity or space number. - As such, integration via the API provided by
server system 140 is a “push” model whereserver system 140 “pushes” all relevant information to the Traditional Curbside Parking Meter system. Subsequently, the Traditional Curbside Parking Meter system displays a list of vehicle license plates with unpaid or expired parking. - In an embodiment, a Pay-by-Phone system may overlay a traditional curbside parking system, and
server system 140 may be integrated with the Pay-by-Phone payment system via API. In such a case, where a Pay-by-Phone system-provided API is used,server system 140 will transmit vehicle detection information to the Pay-by-Phone system since typically the vehicle license plate information is already possessed by the Pay-by-Phone system. The end result is the Pay-by-Phone system will have the information required to generate a list of vehicle license plates with parking violation details. - More recently, curbside parking meters (single or double space) have been introduced which perform credit card authorization using a built-in 3G or WiFi modem. In an embodiment,
server system 140 can be configured to interface with this type of parking meters through a Curbside Parking Meter API. Specifically, since these curbside parking meters already have built-in wireless network connectivity and an associated backend server, it is not difficult forserver system 140 to integrate with this third-party backend server. - When
server system 140 is configured to operate in this mode, an integration module for the Curbside Parking Meter API performs steps including: (1) establishing a connection with a third-party Curbside Parking Meter API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the Curbside Parking Meter API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection. In connection with step (1), an API typically specifies the mechanism through which a connection to it can be established. The integration module for the Curbside Parking Meter API is configured to observe the protocol required by the Curbside Parking Meter API and establishes a connection. - In connection with step (2), when
server system 140 determines that a particular vehicle has vacated a destination location,server system 140 signals this event to the integration module for the Curbside Parking Meter API, such as via a database or Inter-Process Communication (IPC) call, in response to which the integration module for the Curbside Parking Meter API issues a request to the third-party Curbside Parking Meter API for parking payment information for the particular vehicle. Data sent to the third-party Curbside Parking Meter API may include, for example, an identifier for the destination location recognized by the Curbside Parking Meter API (which may require translation from an identifier used internally by server system 140), and a date/time the particular vehicle vacated the destination location. - In connection with step (3), the integration module for the Curbside Parking Meter API may be configured to receive information from the third-party Curbside Parking Meter API including, for example, an identifier for the destination location recognized by the Curbside Parking Meter API (which may require translation to an identifier used internally by server system 140), a paid parking start date/time, and a paid parking end date/time. In connection with step (5), the integration module for the Curbside Parking Meter API may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by
server system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - As such, integration via Curbside Parking Meter API is a “pull” model where
server system 140 “pulls” all relevant information the third-party Curbside Parking Meter system is capable of outputting, and adds automated vehicle violation information determined byserver system 140 to produce a list of vehicle license plates with unpaid or expired parking. In other words, integration via Curbside Parking Meter API is generally not accomplished in a “push” model. - In an embodiment in which
server system 140 is configured to integrate with a Curbside Parking Meter system via an API provided byserver system 140,server system 140 transmits vehicle information to the Curbside Parking Meter system (such as vehicle license plate number, destination location, and actual parking start and end times). The end result is the Curbside Parking Meter system will have the precise information required to generate a list of vehicle license plates with parking violation details. - Typically when a Curbside Parking Meter system or its staff is agreeable to using the API provided by
server system 140, the Curbside Parking Meter system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data fromserver system 140. In this particular case, the useful data is actual vehicle parking duration, the actual amount of time a particular vehicle has occupied a specific destination location, for a particular vehicle license plate number or destination location number. In general, Curbside Parking Meter systems already have the vehicle license plate number or space number, as this information may be obtained as part of the end user payment process. - Integration via a Curbside Parking Meter API provided by
server system 140 may be according to one of two options. First is a data inflow model, in which the third party parking payment system pushes information intoserver system 140. Second is a data outflow model, in whichserver system 140 pushes all relevant information to the Curbside Parking Meter system. - In an embodiment,
server system 140 may include an inflow-based Curbside Parking Meter API for use by a third-party parking payment system via, for example,network 110, in which the third party parking payment system pushes information intoserver system 140 via the inflow-based Curbside Parking Meter API. The inflow-based Curbside Parking Meter API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Curbside Parking Meter API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the inflow-based Curbside Parking Meter API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the inflow-based Curbside Parking Meter API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking. The received information for a particular vehicle may include, for example, an identifier for a destination location for which payment was received in connection with the particular vehicle (which may require translation to an identifier used internally by server system 140), a paid parking start date/time, and a paid parking end date/time. In connection with step (5), a Curbside Parking Meter integration module included inserver system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined byserver system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - In an embodiment,
server system 140 may include an outflow-based Curbside Parking Meter API for use by a third-party parking payment system via, for example,network 110, in whichserver system 140 pushes all relevant information to the third-party Curbside Parking Meter system. The outflow-based Curbside Parking Meter API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the outflow-based Curbside Parking Meter API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the outflow-based Curbside Parking Meter API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system. The uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location. - In an embodiment,
server system 140 may be configured to integrate with a Curbside Parking Meter system in two steps. First,server system 140 obtains vehicle payment information from the Curbside Parking Meter system (such as paid parking start and end times, parking space number, vehicle license plate number) by using the Curbside Parking Meter system-provided API. At this stage,server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. However, instead ofserver system 140 presenting this list to a parking operator, there may be instances where an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Curbside Parking Meter system by using an API provided byserver system 140. The Curbside Parking Meter system will then have total control over how the list of “offending” vehicles is presented to the parking operator (such as by use of a custom software application developed by the Curbside Parking Meter system vendor). - A significant difference between this integration method and integration via the API provided by
server system 140 is that this integration method requires minimal development effort on the part of the Curbside Parking Meter system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided byserver system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development. This integration approach represents a “pull” followed by a “push” model. - Similar to Pay-by-Space where a parking payment is associated with a particular numbered parking space (in which a vehicle parks), Pay-by-Plate associates a parking payment to a vehicle with a particular license plate parked in a parking space. Manual enforcement of Pay-by-Plate parking typically involves the enforcement officer driving past the physical parking space to ensure license plates of all parked vehicles are on a list of license plates with paid status. Conversely, any parked vehicles with license plates not on the “paid” list would receive a parking citation.
- Similar to the above-described Pay-by-Phone and Pay-by-Space, integration can be accomplished by using either a Pay-by-Plate system-provided API or an API provided by
server system 140. The objective is for either system to gain access to all the information required to generate a list of vehicle license plates with parking violation information. - In an embodiment in which
server system 140 is integrated via a Pay-by-Plate system-provided API,server system 140 obtains vehicle payment information from the Pay-by-Plate system (such as paid parking start and end times and vehicle license plate numbers). The end result isserver system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. - In an embodiment,
server system 140 may include a Pay-by-Plate integration module, which may be a software component that extracts parking payment information from a third party parking payment system whichserver system 140 uses for parking self-enforcement. The integration module for pay-by-plate performs steps including: (1) establishing a connection with a third-party Pay-by-Plate API; (2) issuing a request for data; (3) receiving data; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the third-party Pay-by-Plate API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) repeating steps 2-7 or closing the connection. In connection with step (1), an API typically specifies the mechanism through which a connection to it can be established. The Pay-by-Plate integration module is configured to observe the protocol required by the third-party Pay-by-Plate API and establishes a connection. - In connection with step (2), when
server system 140 determines that a particular vehicle has vacated a destination location,server system 140 signals this event to the Pay-by-Plate integration module, such as via a database or Inter-Process Communication (IPC) call, in response to which the Pay-by-Plate integration module issues a request to the third-party Pay-by-Plate API for parking payment information for the particular vehicle. Data sent to the third-party Pay-by-Plate API may include, for example, vehicle license plate information (including plate number and state/province information), and a date/time the particular vehicle vacated the destination location. - In connection with step (3), the Pay-by-Plate integration module may be configured to receive information from the third-party Pay-by-Plate API including, for example, a paid parking start date/time and a paid parking end date/time. In connection with step (5), the Pay-by-Plate integration module may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined by
server system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - In an embodiment in which
server system 140 is integrated with a Pay-by-Plate system via an API provided byserver system 140,server system 140 transmits vehicle information to the Pay-by-Plate system (such as vehicle license plate number, destination location, and actual parking start and end times). The end result is the Pay-by-Plate system will have the precise information required to generate a list of vehicle license plates with parking violation details. - Typically when a Pay-by-Plate system or its staff is agreeable to using the API provided by
server system 140, the Pay-by-Plate system or its staff is prepared to undertake some degree of custom software development generally for the purpose of receiving some useful data fromserver system 140. In this particular case, the useful data is actual vehicle parking duration, an actual amount of time a particular vehicle has occupied a destination location, for a particular vehicle license plate number. By definition, Pay-by-Plate systems already have the vehicle license plate number, as this is obtained as part of the end user payment process. - Integration via a Pay-by-Plate API provided by
server system 140 may be according to one of two options. First is a data inflow model, in which the third party parking payment system pushes information intoserver system 140. Second is a data outflow model, in whichserver system 140 pushes all relevant information to the third-party Pay-by-Plate system. - In an embodiment,
server system 140 may include an inflow-based Pay-by-Plate API for use by a third-party parking payment system via, for example,network 110, in which the third party parking payment system pushes information intoserver system 140 via the inflow-based Pay-by-Plate API. The inflow-based Pay-by-Plate API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) receiving data from the third party parking payment system; (4) processing and storing data todatabase 141; (5) determining parking violation status; (6) marking use of a destination location as a parking violation indatabase 141 for further processing, for example, by the below-described parking violation pre-processing logic; (7) periodic confirmation that the inflow-based Pay-by-Plate API is active and valid, such as, but not limited to, by use of “keep-alive”/“ping” messages or commands; and (8) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the inflow-based Pay-by-Plate API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the inflow-based Pay-by-Plate API, receive vehicle parking information from the third party parking payment system every time a vehicle/driver pays for parking. The received information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), a paid parking start date/time, and paid parking end date/time. In connection with step (5), a Pay-by-Plate integration module included inserver system 140 may be configured to compare a duration of paid parking indicated by the data received from step (3) with the actual parking duration determined byserver system 140. If the actual parking duration exceeds the paid parking duration, processing of step (6) is performed, otherwise step (6) is not performed. - In an embodiment,
server system 140 may include an outflow-based Pay-by-Plate API for use by a third-party parking payment system via, for example,network 110, in whichserver system 140 pushes all relevant information to the third-party Pay-by-Plate system. The outflow-based Pay-by-Plate API may be configured to perform steps including, for example: (1) waiting for the third party parking payment system to establish a connection; (2) authenticating the identity of the third party parking payment system; (3) uploading data to the third party parking payment system; (4) receiving an acknowledgement for the uploaded data; (5) responding to “keep-alive”/“ping” requests from the third party parking payment system; and (6) closing the connection when requested or upon timeout. In connection with step (1), this may involve listening on a TCP or UDP port for the third party parking payment system to establish the connection. In connection with step (2), the third party parking payment system is required to authenticate itself through the outflow-based Pay-by-Plate API before data exchange is permitted. If authentication fails, a retry mechanism may be provided, and after several unsuccessful attempts the connection may be dropped. In connection with step (3),server system 140 may be configured to, via the outflow-based Pay-by-Plate API, upload vehicle parking information to the third party parking payment system every time a vehicle vacates a destination location associated with the third party parking payment system. The uploaded information for a particular vehicle may include, for example, vehicle license plate information (including plate number and state/province information), an identifier for the destination location recognized by the third party parking payment system (which may require translation from an identifier used internally by server system 140), an actual date/time the particular vehicle began use of the destination location, and an actual date/time the particular vehicle vacated the destination location. - In another embodiment,
server system 140 is configured to integrate with a Pay-by-Plate system in two steps. First,server system 140 obtains vehicle payment information from the Pay-by-Plate system (for example, paid parking start and end times, and vehicle license plate number) by using a Pay-by-Plate system-provided API. At this stage,server system 140 will have the precise information required to generate a list of vehicle license plates with parking violation details. However, instead ofserver system 140 presenting this list to the parking operator, there may be instances where an incumbent parking payment vendor wishes to retain control over how the parking violation information flows back to the parking operator. This can be accomplished by sending the vehicle violation data back to the Pay-by-Plate system by using the API provided byserver system 140. The Pay-by-Plate system will then have total control over how the list of “offending” vehicles is presented to the parking operator (such as by way of a custom software application developed by the Pay-by-Plate system vendor). - A significant difference between this integration method and integration with the Pay-by-Plate system via the API provided by
server system 140 is that this integration method requires minimal development effort on the part of the Pay-by-Plate system vendor. Since all the key information to be presented to the parking operator is already supplied by the API provided byserver system 140 without any further analysis required, this information can simply be displayed or forwarded to the parking operator with minimal software development. This integration approach represents a “pull” followed by a “push” model. - There are two main reasons why use of a Live Operator team as part of the system illustrated in
FIG. 1 warrants consideration and may offer a practical option to offer to prospective parking operators as a value added feature. - First, although
server system 140 autonomously receives and processes images obtained from the identification and destination cameras, there are typically live operators who monitor obtained images and software executing onserver system 140. These live operators can review operation ofserver system 140 and take appropriate actions on an exception basis if required. For example, when unexpected problems occur, Live Operators can review images related to the problems and deduce information thatserver system 140 may not be configured to handle. - An advantage with the networked architecture supported by
server system 140 is that a single Live Operator team can oversee or augment operations at multiple sites regardless of their respective geographic locations or the fact that the facility operations may be owned by different parking operations or even competitors. As a result, the Live Operator option can be a scalable and cost-effective approach for parking operators. Furthermore, by using IP multicast or similar standard TCP/IP protocol, a video stream can effectively be sent simultaneously to multiple destinations, thereby allowing the Live Operator option to be added at a future date in addition to local on-site monitoring staffed by the parking operators. - Second, depending on the available technology, Pay-and-Display and curbside meter configurations discussed above may present significant real life challenges. Not only are cameras with a high level of zoom are required, there are also potential problems such as that an angle of view from a particular video camera may not be sufficient to properly detect an expiration flag of a traditional curbside parking meter, or a bar code on a Pay-and-Display ticket on a vehicle dashboard may be facing away from any of the video cameras due to the physical three dimensional shape of the dashboard and the placement of the ticket itself.
- With the Live Operator option,
server system 140 can generate exception events to the Live Operator whenserver system 140 fails to automatically detect a key piece of information such as license plate number, status of an expiration flag on a traditional parking meter, or bar code/printed information on a Pay-and-Display ticket. Such an exception event may trigger a Live Operator to take a number of specific actions, including but not limited to Rewind/Fast Forward/Pause/Freeze-Frame FWD & RWD specific footages captured by identification and/or destination cameras, zoom in/out on particular areas of interest in the captured footages, Pan/Tilt/Zoom video cameras in real-time in order to obtain enhanced images, and dispatch on-site personnel to perform inspection of a vehicle or parking meter, either visually of by use ofmobile device 150 to obtain enhanced images for use byserver system 140. - In an embodiment,
server system 140 is configured to correlate a mailing address of a registered owner of a vehicle with its license plate number, allowing a parking operator to collect parking citation revenue. Red-light camera systems utilize such a mechanism to have citation tickets mailed to registered owners of the vehicles. In connection with such functionality, parking operators are in three different categories. - First, in the event that the parking operator is part of the city/municipality who may already have access to DMV records,
server system 140 only needs to supply a list of Vehicle License Plate Numbers with state/province information along with parking violation details (such as date, time, and location) in order for citations to be mailed to registered owners. - Second, for private parking operators with no pre-established access to DMV records, there are a number of legislated ways to obtain personal information, including name and address, tied to a Vehicle License Plate Number. These methods vary from state to state (and provinces). As an example, in the State of New York, private parking operators are allowed to gain access to such information by use of Driver's Privacy Protection Act (DPPA) form MV-15DPPA “for use in connection with the operation of private toll transportation facilities”, “including companies that operate parking facilities for the purpose of providing notice to the owners of vehicles who have used the facility.” For some jurisdictions, name and address information may be released online, and
server system 140 may be configured to obtain and process such information. In some jurisdictions, name and address information of a third-party vehicle owner may not be released online, but instead must be obtained either by mail or in person. In such jurisdictions, private parking operators may wish to obtain name and address information on a batched basis (such as daily, every 2 or 3 days, or weekly). - Third, for private parking operators who prefer real time access to registered owner information, a number of private Vehicle License Number Plate databases are available via the Internet. The main advantage of this approach is that name and address information can be immediately and automatically retrieved with no manual operation required.
- As noted in connection with
FIG. 1 ,end user systems 170 can include in-vehicle systems. In an embodiment, new vehicle dashboards straight from car manufacturers can include an indicator icon, similar to other dashboard lights such as “check engine,” parking-brake warnings, or cruise-control indicator lights. This indicator icon is normally not illuminated whenvehicle 130 is driving on the highway or not inside a perimeter serviced byserver system 140. Asvehicle 130 approaches parking lots or curbside parking areas, the indicator icon may light up in amber advising an end user of the availability of automated parking services provided byserver system 140. Whenvehicle 130 pulls into a destination location, such as a parking space, the indicator icon turns red to notify the end user that parking has not been paid. Once parking has been paid (whether by the afore-mentioned Pay-by-Phone, curbside meter, Pay-by-Space, or other techniques), the indicator icon turns green to signify parking has been paid. In an embodiment, these visual indications may be accompanied by audio notifications, which may be simple chimes or voice announcements. Audio output may be performed by providing audio information or data to a vehicle entertainment unit. - As this invention enables many aspects of parking payment and enforcement processes to be automated, it is important to provide feedback to end users as to what the
server system 140 is doing or a particularstate server system 140 has associated with vehicle 130 (for example, whethervehicle 130 has committed a parking violation). End users can then react accordingly to the feedback provided. While operating within a highly automated payment and enforcement system, it is a reasonable expectation that end users or registered owners do not get penalized for minor or administrative errors. Feedback provided via a simple interface such as the dashboard indicator icon can greatly alleviate this concern. - For example, as
vehicle 130 parks, if the indicator icon remains red after some time, the end user realizes an exception event has taken place. It may be that a credit card number on file has expired and thereforeserver system 140 is not able to apply a parking charge. This feedback provides the end user the opportunity to, for example, visit a website provided by or in connection withserver system 140 to query his/her account status and correct the error. - There are a number of potential sources of information by which the dashboard indicator icon can get its information from, including built-in cellular data or WiFi vehicle connectivity, or smart sensors (discussed below). For older vehicles without factory-installed indicator icons, end users may be provided with a retrofit kit in the form of a visual module which receives information by way of Bluetooth, cellular data, or WiFi connectivity.
- In an embodiment, the indicator icon feature receives GPS location data from third-party in-vehicle subsystems via a vehicle wiring harness. The GPS data allows the indicator icon feature to determine whether
vehicle 130 is currently in a paid parking zone. - Similar to the vehicle dashboard icon, smart sensors can be designed into new vehicles straight from the factory. Using technology similar to the ZigBee IEEE 802.15.4 standard, low cost, low power, short range wireless mesh networks can be created among vehicles as well as between vehicles and parking equipment. Each vehicle becomes a node, and a node can communicate with a distant end-point by relaying data through intermediate nodes by forming a mesh network. Each smart sensor contains a unique identifier, such that license plate information is no longer critical. In an embodiment, smart sensors may be configured to communicate with
server system 140 via a cellular data connection and/or provide Pay-by-Phone functionality, whereby payment for use of a destination location may be made via the smart sensor. - Many applications are possible with the introduction of such smart sensors. For example, the smart sensors can include a GPS receiver or communicate with an in-vehicle GPS to determine a present location of
vehicle 130 and report the present location toserver system 140. With some GPS techniques, such as assisted GPS, a location determined via GPS may have enough accuracy and precision to determine the vehicle is making use of a particular destination location. These sensors can also communicate with parking meters and in essence report the presence of the vehicle and how long it has been parked for. This parking information can be relayed to a distant device/network through the mesh network so the parking equipment does not need to be located within the vicinity of the vehicle. For vehicles equipped with smart sensors, use of the identification and destination cameras is not necessary, as the embedded smart sensor already provide a unique identity of the vehicle toserver system 140. - In an embodiment, vehicles may be equipped with a near-field communication (NFC) device, such as an RFID chip. For example, such a communication device may be included in a mirror hanger. In another example, an RFID chip may be embedded in a ticket provided by a Pay-and-Display device. By obtaining a vehicle identification from a near-field communication device, use of images captured by identification cameras, such as images including license plate information, may not be required by
server system 140 and/or may be used to verify information received from an NFC device corresponding to an observed vehicle. - In an embodiment, the smart sensors can sense the status of other vehicles nearby (such as, but not limited to, whether they are moving, parked, and for what duration they have been parked) and report the status to
server system 140. The end result is thatserver system 140 is aware as to where almost any smart sensor-equipped vehicle is parked and for how long. By combining this information with parking payment information from either third-party systems or turnkey platforms, it is possible to determine the identity of vehicles that did not pay for parking or with expired parking, and have parking violation tickets mailed to the registered owners or even charging a parking fine on the spot (for example, by charging a credit card on file). - In an embodiment, a destination camera can be provided with laser status notification. Similar to laser logo devices seen at shopping malls and retail outlets, the laser status notification feature shines a nonharmful flashing red light enveloping a parked vehicle to notify an end user upon return that parking was not paid or has expired. This is akin to returning to a vehicle and seeing a parking ticket clipped under the windshield wiper under the traditional manual parking enforcement model. As a destination camera is typically located at elevation with respect to vehicles, an included laser status notification module has a bird's eye view to below destination locations to facilitate shining laser notification onto vehicles and destination locations.
- In an embodiment, laser status notification feature replaces the need to mail out paper parking violation tickets. Once an end user receives a laser notification for a parking violation, the end user can then be expected to pay the parking fine through a number of media including, but not limited to, an online website or Pay-by-Phone. Furthermore, laser status notifications can be captured by the destination camera to provide later evidence of the parking violation and notification.
- In an embodiment, dynamic real-time Individual Parking Space Reservation is a feature made possible by an online/phone/smart phone parking space reservation system, and may be further enhanced with the laser status notification feature. While currently some vendors offer parking space reservation feature, the feature is limited to space reservation in the general vicinity of parking spaces (for example, somewhere on a parking lot) as there is no practical method of physically reserving a single, particular parking space in an automated fashion. In addition, the reserved spaces are typically held open for a long period of time because there is also no practical way of knowing when a reserved parking spot becomes available again after the driver who reserved the space has parked and subsequently driven off.
- In contrast, the dynamic real-time Individual Parking Space Reservation feature allows end users to pinpoint the exact parking space they desire (for example, a space closest to a shopping mall during Christmas shopping period), for a specified period of time (for example, a destination location may be reserved for use during some day in the future). Once a parking space has been reserved, a laser notification may be shined on the parking spot to indicate that the destination location is reserved (providing, for example, a red color as a warning to other drivers). The use of a destination location during a reserved period by another vehicle will result in a parking violation. This enables a parking operator to increase revenue by offering both tiered/premium parking spots, and advance reservation of parking spaces.
- In an embodiment, a parking operator may designate particular destination locations as restricted only for use by vehicles for which a reservation has been made. In this embodiment,
server system 140 may determine a number of available reserved destination locations for a given time, and price reservations according to how many unreserved destination locations remain available. In an embodiment,server system 140 may be configured to allow buyers to submit competing bids for the use of reserved destination locations. - In an embodiment, a Pay-by-Phone feature can be offered either directly on a turnkey platform or through a partnership with a third-party vendor. The end result is that end users can pay for parking by calling a particular IVR phone line, input a destination location number or vehicle license plate number, and a duration of parking. In another embodiment, Pay-Online is a variation along the same theme to support online payment for parking, typically via a website accessible via a web-enabled smartphone.
- In an embodiment, a “push” technology feature can be incorporated where as soon as an end
user parks vehicle 130, the end user receives a text message or other notification prompting for an affirmative reply to charge a specific parking rate untilvehicle 130 leaves a destination location.Server system 140 identifiesvehicle 130 via an identification camera, and further determines thatvehicle 130 is associated with a pre-registered end user with credit card or other billing information and a cellular phone number or other contact information on record. Onceserver system 140 determines via a destination camera thatvehicle 130 has parked in a destination location,server system 140 initiates a “push” sequence to actively notify and engage the driver for payment or confirmation of payment. By simplifying the payment process, improved parking revenue is realized. - In many traditional parking meter systems, if an end user pays for more time than actually used by the end user, excess time remains on the meter for use by a following end user. In an embodiment of the disclosed subject matter, as
destination camera 125 allowsserver system 140 to accurately determine when a vehicle leaves a destination location, any “leftover” paid parking time can be reset to zero. One exception is traditional curbside meters, as these typically do not have any communication capability or the intelligence to activate the expiration flag prior to time expiration. -
Server system 140 may be configured to provide a push technology software component that enhances the user experience when it comes to paying for parking. Push technology supports functions such as: (1) initiating a payment sequence via text message; (2) allowing a pre-registered user to take a photo of their license plate, then provide the photo toserver system 140 by way of, for example, email or text-message; (3) allowing a non-registered user to take a photo of their license plate, then provide the photo toserver system 140 by way of, for example, email or text-message; and (4) allowing drivers to sign up once to not get parking fees under a subscription-based model. The push technology component interacts with vehicle identifier detection logic, vehicle detection logic,database 141, and a payment gateway. In connection with item (1), based on a vehicle identifier of the vehicle that has just begun use of a destination location such as a parking space, the push technology component pushes a text message indicating that use of the destination location has begun, to a mobile phone number registered withserver system 140. When the driver assents to the text message by replying with “yes”, a credit card associated with the registered account may then get charged an appropriate usage fee, such as, but not limited to, a flat-rate parking fee for use of the destination location. In connection with item (2), a driver who has pre-registered withserver system 140 may take photos of their license plate, then email or text-message the photo toserver system 140. A credit card associated with a registered account for the pre-registered user then gets charged a usage fee. In connection with item (3), for vehicles bearing license plates not registered withserver system 140, a driver may take a photo of the license plate, then email/text-message the photo toserver system 140. Where a mobile phone service provider supports and provides access to such a billing feature, usage charges may be added to a user's monthly mobile device bill. In connection with item (4), a driver may sign up once to automatically pay for all usage fees (or at least all parking fees) with a registered credit card. The push technology software component may also be configured to automatically send a text message to a user In the event thatserver system 140 determines inappropriate use of a destination location, such as parking a vehicle in a “no parking” area. -
Server system 140 may be configured to provide a parking violation pre-processing logic software component that examines all occurrences of destination location usages newly identified as violations and assigns them to a corresponding destination as specified in a system configuration, such as the license plate lookup module or the license plate forward module, discussed below. The parking violation pre-processing logic software component interacts withdatabase 141, the system configuration utility, and third-party APIs. The parking violation pre-processing logic software component may be configured to: (1) enqueue violations identified by other software processes included inserver system 140; (2) examine the next violation in the queue; (3) validate the destination location usage is a violation by verifying rules established via the system configuration utility in connection with the destination location and detected use of the destination location by a vehicle; (4) assign the violation to license plate processing logic; and (5) examine any other enqueued violations or await an identification of a later violation. -
Server system 140 may be configured to determine whether a vehicle has an expired tag from an identification image. The identification image may be captured using a fixedIdentification camera 120, although at typical distances and vehicle speeds, and the small size of the typical expiration date indicator on a license plate, determining whether a vehicle bears an expired tag from the identification image alone is generally not possible. With a PTZ-capable camera zoomed into a license plate of a stationary vehicle, either with an Identification camera or destination camera, it may be possible to zoom into a license plate to obtain enough detail to determine whether a vehicle bears an expired tag from the obtained image alone. In an embodiment, the identification image instead can be captured via a mobile or handheld camera, including, for example, a camera included in a smartphone ormobile device 150. An identification image obtained from such sources often has enough detail to determine whether a vehicle bears an expired tag from the identification image alone. In an embodiment, rather than use an image alone to determine if a tag is expired,server system 140 may be configured to query, via an API to a municipal database, determine whether a vehicle registration for a particular license plate number is expired.Server system 140 may be configured to, in the event it determines a vehicle is bearing an expired tag, report the vehicle to a municipality. -
Server system 140 may be configured to provide a license plate processing logic software component that takes an identified destination location usage violation, such as a violation assigned by the parking violation pre-processing logic component, and converts it into an actionable item for either a Registered Owner (RO)/user of a vehicle involved in the destination location usage violation, or for a parking operator responsible for the destination location. For example, the actionable item can be in the form of a parking citation automatically mailed to the registered owner, or a license plate number displayed on a screen at a parking operations office. The license plate processing logic software component interacts with the parking violation pre-processing logic software component, system configuration utility, anddatabase 141. The license plate processing logic component may be configured to check one or more business rules specified via the system configuration utility in connection with the destination location to determine the appropriate actionable item. For example, if a business rule specifies license plate lookup, a specific type of license plate lookup may also be specified, such as via an API provided by a municipality, or an API provided by a private business. Then license plate lookup is performed as specified. Also, business rules may identify sub-options such as mailing out parking tickets to a registered owner via API, or just providing a mailing address for a registered owner and any other associated information for the violation to the parking operator. In another example, if a business rule specifies license plate information forwarding, the license plate processing logic component checks to see the specific type of license plate information forwarding specified, and forwards the license plate information accordingly. - In order to utilize a license plate lookup API option for the purpose of identifying a mailing address for a registered owner from a license plate vehicle identifier, a license plate database, such as one provided by a private business, must exist and be available for searches for license plates belonging to a particular state/province for the license plate. Also, use of such a database must be reasonable in terms of any fees involved to such lookup is commercially viable. In the event that either condition above does not materialize, an alternative option may include providing the license plate in question to a municipal body, which typically has access to license plate records via the local police branch or otherwise.
- The license plate processing logic software component may include a license plate lookup and followup submodule. The license plate lookup and followup submodule may be configured to make an API call to a license plate database to retrieve the mailing address for a registered owner of a vehicle. Examples of such databases include an HTTP-based Dial-in Search Account API provided by the New York State Department of Motor Vehicles, database services provided by the American Association of Motor Vehicle Administrators (AAMVA) or other insurance companies, and online collections of public records, such as PublicData.com (although many such collections are less reliable than government or commercially managed databases, thus possibly requiring additional efforts to ensure information is valid and accurate).
- Also, the license plate lookup and followup submodule may be configured to automatically mail a parking citation to a registered owner associated with a vehicle that has misused a destination location. For example, the process of mailing may be automated via an API call to a printing/mailing service such as, but not limited to, L-Mail.com.
- In an embodiment, the license plate lookup and followup submodule may be configured to create, maintain, and review records in
database 141 to see if a given vehicle identifier (such as a license plate) is associated with prior misuse of a destination location within a specified period of time (which is configurable via, for example, the system configuration utility), If so, the license plate lookup and followup submodule may presume that the previously obtained address remains valid and accurate, skip the API call, and mail a citation using the previously obtained mailing address in the system in order to lower operating expenses associated with API calls. In the event that the parking citation has not been paid after a specified number of days (actual duration also configurable via, for example, the system configuration utility) or the citation is returned as undeliverable, a subsequent API call may be made to obtain a current address. - In an embodiment, a parking violation, such as, but not limited to, when paid parking expires or a vehicle is parked without payment,
server system 140 may be configured to notify one or more enforcement officers with a location of a destination location, such as a longitude and latitude or an approximate street address. An enforcement officer then may go to the offending vehicle and issue a citation on the spot. In an embodiment,server system 140 may be configured to identify and/or locate an individual enforcement officer who is best suited to deal with a particular offending vehicle. Factors for making this identification may include, for example, the distance from the offending vehicle or workload of an enforcement officer, or whether an offending vehicle is to be towed (for example, where an offending vehicle must be promptly removed). In an embodiment, offending vehicles may have to be enqueued where, for example, there are too few enforcement officers or a particular enforcement officer has multiple offending vehicles to handle. In an embodiment, multiple enforcement officers may be notified of nearby offending vehicles, and individual enforcement officers may accept to handle particular offending vehicles.Server system 140 may also be configured to track enforcement officer performance, which may be used in connection with a reward or quota system for the enforcement officers. In an embodiment, an enforcement officer may be equipped with amobile device 150, andmobile device 150 may be configured to preprint a citation for an offending vehicle to reduce an amount of time taken to deliver the citation to the vehicle. -
Server system 140 may be configured to provide dynamic variable-rate parking fees. In an embodiment,server system 140 may record different parking rates for a destination location which vary according to time of day and/or day of the week, for example. In the event that a vehicle occupies a destination location over a period of time in which first and second rates apply,server system 140 may be configured to determine a total fee for use of the destination location based the first rate being applied from the beginning of the use of the destination location until the second rate applies, and the second rate being applied for the remaining time the vehicle occupies the destination location. In an embodiment,server system 140 may be configured to determine a number of vehicles which may be accommodated by the destination locations available in a given area, and base a fee or rate for parking on the determined number of vehicles. For example, asserver system 140 determines this number decreases (for example, because there are fewer remaining destination locations), it may apply a higher rate for vehicles which begin to make use of the few remaining locations. -
Server system 140 may be configured to allow a parking provider, via an API or the configuration utility, specify particular events for which a specified parking rate or flat fee is to be applied for specified destination locations. For example, if a concert occurs from 7-11 PM at a venue associated with or near a parking facility, the parking facility may levy a flat $10 fee for vehicles parked after 4 PM that same evening. -
Server system 140 may be configured to provide a no-fine feature, where a driver may leave a vehicle parked in a destination location for as long as they wish, and have a credit card or other account billed for according to rules established for the destination location (such as, but not limited to, per-hour or flat rate per-day fees). In an embodiment, a text message or email may be pushed or otherwise sent to the driver indicating that the no-fine feature is available for the destination location, and allowing the driver to elect use of the no-fine feature, such as by replying with a message such as “yes” or “no fine”. In an embodiment,server system 140 may be configured to generally make the no-fine feature available for all unrestricted destination locations in specified areas or throughout the destination locations tracked byserver system 140. However,server system 140 may be configured not to offer the no-fine feature for a restricted destination location, such as, for example, a destination location subject to a 3-6 PM “no parking” rush hour restriction. - In an embodiment,
server system 140 may be able to perform profiling based on 3D outline of the vehicle. For example, such profiling may be able to roughly profile a vehicle as belong to a category such as, but not limited to, sport utility vehicle (SUV), van, sedan, coupe, or motorcycle. In addition, a vehicle may be categorized as having a light or dark color. The vehicle profiling can serve non-parking applications, such as, but not limited to, assisting police tracking of stolen vehicles within a certain vicinity, Amber alert, Homeland Security needs. In an embodiment, the vehicle profiling can be used to provide additional vehicle characteristics for comparisons performed in tracking a vehicle from one tracking camera to another. In an embodiment, the vehicle profiling may provide an additional layer of confirmation of an identity of a vehicle for an automated parking citation mailing process. In an embodiment, manual 3D vehicle profiles are provided toserver system 140. For example, one manual 3D vehicle profile for a Chevrolet Impala may describe a ratio of 1:2:1 for height of hood to height of passenger compartment to height of trunk. - In an embodiment, a laser transmitter, which may be integrated with an actuated beam-deflecting mirror, may be configured to shine a laser beam onto one or more destination locations. In an embodiment, the laser beam may shine on a retroreflector mounted on or around a destination location to provide a return signal to a receiver associated with the laser transceiver. When a vehicle occupies a destination location illuminated by the laser beam, the presence of the vehicle is detected by interruption of the laser beam or a return signal. In response to this detection,
server system 140 may be configured to obtain a destination image and/or an identifier image with a nearby camera. - In an embodiment,
server system 140 may be configured to, in addition to the aforementioned uses involving vehicle identification, also use an identification camera as a “red light camera” for the detection of events in which a vehicle incorrectly proceeds through an intersection controlled by a traffic light. For example, as a traffic light changes from amber to red, vehicles incorrectly proceeding through a late amber or red light may be identified, along with a captured vehicle license plate, such thatserver system 140 is configured to simultaneously utilize an imaging camera for both purposes. Alternatively or in addition,server system 140 may be configured to use an identification camera to detect “block the box” moving violations, where a vehicle remains within an intersection during a red light for the vehicle's direction of travel, which may lead to gridlock high-traffic situations. - In an embodiment,
server system 140 may be configured to provide real-time vehicle tracking services for third parties such as, but not limited to, repossession companies (for locating vehicles with outstanding loan payments), law enforcement, homeland security.Server system 140 may provide an API by which such third-party entities may register vehicles of interest by, for example, a vehicle identifier such as a license plate. In the event thatserver system 140 determines the presence of a vehicle with the vehicle identifier, the registering party may be notified. Notifications may be provided in connection with an initial detection of the vehicle and/or when the vehicle is determined to have stopped. In an embodiment, records of the movements of a registered vehicle may be retained byserver system 140, and made accessible, for example, via a map-based web interface, which may be configured to present updated information in real-time. The API may also allow a third party to designate an area of interest, for whichserver system 140 is configured to perform identification and tracking of any vehicles determined to have entered the area of interest.Server system 140 may also be configured to provide images of registered vehicles obtained by the tracking cameras. In an embodiment, any archived tracking information, such as the past use of destination locations, may also be made available to reconstruct a person's whereabouts over time (assuming the person is connected with the vehicle). In an embodiment,server system 140 may be configured to obtain vehicle images including an image of a driver's face, and may further be configured to perform facial recognition techniques to confirm facial characteristics of the driver correspond to a person of interest. - In an embodiment,
server system 140 may be configured to determine and provide traffic count information, such as the number of vehicles determined to have traversed a given portion of roadway. Such information may be employed for purposes including, but not limited to, dynamic control of traffic systems such as traffic lights in response to currently observed traffic counts, and for determining construction requirements based on traffic counts observed over time. The traffic count information may include and/or be filtered on the basis of time and/or date, and/or determined vehicle characteristics, including, but not limited to, direction of travel and vehicle size or type (such as SUV, truck, car, or motorcycle). Additionally,server system 140 may determine vehicle counts in connection with a direction of entry and/or exit for a portion of roadway, such as, for example, how many vehicles were northbound or southbound upon exiting an eastbound portion of roadway, based on a direction each vehicle exits an intersection. In an embodiment,server system 140 may be configured for use in controlling access to and/or levy a toll upon vehicles by type, such as assessing a fee for the use of specified roadways by large trucks. -
FIG. 5 is a block diagram that illustrates acomputer system 500 upon which aspects of the invention may be implemented.Computer system 500 includes abus 502 or other communication mechanism for communicating information, and a processor 504 coupled withbus 502 for processing information.Computer system 500 also includes amain memory 506, such as a random access memory (RAM) or other dynamic storage device, coupled tobus 502 for storing information and instructions to be executed by processor 504.Main memory 506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504.Computer system 500 further includes a read only memory (ROM) 508 or other static storage device coupled tobus 502 for storing static information and instructions for processor 504. Astorage device 510, such as a magnetic disk or optical disk, is provided and coupled tobus 502 for storing information and instructions. -
Computer system 500 may be coupled viabus 502 to adisplay 512, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. Aninput device 514, including alphanumeric and other keys, is coupled tobus 502 for communicating information and command selections to processor 504. Another type of user input device iscursor control 516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement ondisplay 512. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. Another type of user input device is a touchscreen, which generally combinesdisplay 512 with hardware that registers touches upondisplay 512. - The invention is related to the use of one or more computer systems, such as
computer system 500, collectively configured and/or programmed to perform implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed bycomputer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained inmain memory 506. Such instructions may be read intomain memory 506 from another machine-readable medium, such asstorage device 510. Execution of the sequences of instructions contained inmain memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software. - The term “machine-readable medium” as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. In an embodiment implemented using
computer system 500, various machine-readable media are involved, for example, in providing instructions to processor 504 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such asstorage device 510. Volatile media includes dynamic memory, such asmain memory 506. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprisebus 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. All such media must be tangible and/or nontransitory to enable the instructions carried by the media to be detected by a physical mechanism that reads the instructions into a machine. - Common forms of machine-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
- Various forms of machine-readable media may be involved in carrying one or more sequences of one or more instructions to processor 504 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to
computer system 500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data onbus 502.Bus 502 carries the data tomain memory 506, from which processor 504 retrieves and executes the instructions. The instructions received bymain memory 506 may optionally be stored onstorage device 510 either before or after execution by processor 504. -
Computer system 500 also includes acommunication interface 518 coupled tobus 502.Communication interface 518 provides a two-way data communication coupling to anetwork link 520 that is connected to alocal network 522. For example,communication interface 518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example,communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation,communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. - Network link 520 typically provides data communication through one or more networks to other data devices. For example,
network link 520 may provide a connection throughlocal network 522 to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526.ISP 526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 528.Local network 522 andInternet 528 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals onnetwork link 520 and through communication interface 218, which carry the digital data to and fromcomputer system 500, are exemplary forms of carrier waves transporting the information. -
Computer system 500 can send messages and receive data, including program code, through the network(s),network link 520 andcommunication interface 518. In the Internet example, a server 530 might transmit a requested code for an application program throughInternet 528,ISP 526,local network 522 andcommunication interface 518. - The received code may be executed by processor 204 as it is received, and/or stored in
storage device 510, or other non-volatile storage for later execution. In this manner,computer system 500 may obtain application code in the form of a carrier wave. - In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Claims (30)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/279,272 US8830323B1 (en) | 2012-08-06 | 2014-05-15 | Controlling use of parking spaces using a camera |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261680268P | 2012-08-06 | 2012-08-06 | |
US13/686,802 US8698895B2 (en) | 2012-08-06 | 2012-11-27 | Controlling use of parking spaces using multiple cameras |
US14/187,300 US8982213B2 (en) | 2012-08-06 | 2014-02-23 | Controlling use of parking spaces using cameras and smart sensors |
US14/279,272 US8830323B1 (en) | 2012-08-06 | 2014-05-15 | Controlling use of parking spaces using a camera |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/187,300 Continuation US8982213B2 (en) | 2012-08-06 | 2014-02-23 | Controlling use of parking spaces using cameras and smart sensors |
Publications (2)
Publication Number | Publication Date |
---|---|
US20140249896A1 true US20140249896A1 (en) | 2014-09-04 |
US8830323B1 US8830323B1 (en) | 2014-09-09 |
Family
ID=50025108
Family Applications (22)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/686,820 Active US8830322B2 (en) | 2012-08-06 | 2012-11-27 | Controlling use of a single multi-vehicle parking space and a restricted location within the single multi-vehicle parking space using multiple cameras |
US13/686,839 Active US8698896B2 (en) | 2012-08-06 | 2012-11-27 | Controlling vehicle use of parking spaces and parking violations within the parking spaces using multiple cameras |
US13/686,802 Active US8698895B2 (en) | 2012-08-06 | 2012-11-27 | Controlling use of parking spaces using multiple cameras |
US13/686,831 Active US8836788B2 (en) | 2012-08-06 | 2012-11-27 | Controlling use of parking spaces and restricted locations using multiple cameras |
US14/187,300 Active US8982213B2 (en) | 2012-08-06 | 2014-02-23 | Controlling use of parking spaces using cameras and smart sensors |
US14/187,964 Active US9064414B2 (en) | 2012-08-06 | 2014-02-24 | Indicator for automated parking systems |
US14/196,201 Active US8982214B2 (en) | 2012-08-06 | 2014-03-04 | Controlling use of parking spaces using cameras and smart sensors |
US14/209,375 Active US8982215B2 (en) | 2012-08-06 | 2014-03-13 | Controlling use of parking spaces using cameras and smart sensors |
US14/214,973 Active US9330303B2 (en) | 2012-08-06 | 2014-03-16 | Controlling use of parking spaces using a smart sensor network |
US14/226,193 Active US8817100B2 (en) | 2012-08-06 | 2014-03-26 | Controlling use of parking spaces using cameras |
US14/229,688 Active US9064415B2 (en) | 2012-08-06 | 2014-03-28 | Tracking traffic violations within an intersection and controlling use of parking spaces using cameras |
US14/244,027 Active US8937660B2 (en) | 2012-08-06 | 2014-04-03 | Profiling and tracking vehicles using cameras |
US14/250,597 Active US9165467B2 (en) | 2012-08-06 | 2014-04-11 | Defining a handoff zone for tracking a vehicle between cameras |
US14/251,399 Active US9390319B2 (en) | 2012-08-06 | 2014-04-11 | Defining destination locations and restricted locations within an image stream |
US14/263,916 Active US9652666B2 (en) | 2012-08-06 | 2014-04-28 | Human review of an image stream for a parking camera system |
US14/267,981 Active US8878936B2 (en) | 2012-08-06 | 2014-05-02 | Tracking and counting wheeled transportation apparatuses |
US14/279,272 Active US8830323B1 (en) | 2012-08-06 | 2014-05-15 | Controlling use of parking spaces using a camera |
US14/280,958 Active US9036027B2 (en) | 2012-08-06 | 2014-05-19 | Tracking the use of at least one destination location |
US14/848,335 Active US9208619B1 (en) | 2012-08-06 | 2015-09-09 | Tracking the use of at least one destination location |
US14/856,484 Active US9607214B2 (en) | 2012-08-06 | 2015-09-16 | Tracking at least one object |
US14/943,025 Abandoned US20160078299A1 (en) | 2012-08-06 | 2015-11-17 | Imaging a Parking Display Ticket |
US17/147,016 Pending US20210279451A1 (en) | 2012-08-06 | 2021-01-12 | Tracking the Use of at Least One Destination Location |
Family Applications Before (16)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/686,820 Active US8830322B2 (en) | 2012-08-06 | 2012-11-27 | Controlling use of a single multi-vehicle parking space and a restricted location within the single multi-vehicle parking space using multiple cameras |
US13/686,839 Active US8698896B2 (en) | 2012-08-06 | 2012-11-27 | Controlling vehicle use of parking spaces and parking violations within the parking spaces using multiple cameras |
US13/686,802 Active US8698895B2 (en) | 2012-08-06 | 2012-11-27 | Controlling use of parking spaces using multiple cameras |
US13/686,831 Active US8836788B2 (en) | 2012-08-06 | 2012-11-27 | Controlling use of parking spaces and restricted locations using multiple cameras |
US14/187,300 Active US8982213B2 (en) | 2012-08-06 | 2014-02-23 | Controlling use of parking spaces using cameras and smart sensors |
US14/187,964 Active US9064414B2 (en) | 2012-08-06 | 2014-02-24 | Indicator for automated parking systems |
US14/196,201 Active US8982214B2 (en) | 2012-08-06 | 2014-03-04 | Controlling use of parking spaces using cameras and smart sensors |
US14/209,375 Active US8982215B2 (en) | 2012-08-06 | 2014-03-13 | Controlling use of parking spaces using cameras and smart sensors |
US14/214,973 Active US9330303B2 (en) | 2012-08-06 | 2014-03-16 | Controlling use of parking spaces using a smart sensor network |
US14/226,193 Active US8817100B2 (en) | 2012-08-06 | 2014-03-26 | Controlling use of parking spaces using cameras |
US14/229,688 Active US9064415B2 (en) | 2012-08-06 | 2014-03-28 | Tracking traffic violations within an intersection and controlling use of parking spaces using cameras |
US14/244,027 Active US8937660B2 (en) | 2012-08-06 | 2014-04-03 | Profiling and tracking vehicles using cameras |
US14/250,597 Active US9165467B2 (en) | 2012-08-06 | 2014-04-11 | Defining a handoff zone for tracking a vehicle between cameras |
US14/251,399 Active US9390319B2 (en) | 2012-08-06 | 2014-04-11 | Defining destination locations and restricted locations within an image stream |
US14/263,916 Active US9652666B2 (en) | 2012-08-06 | 2014-04-28 | Human review of an image stream for a parking camera system |
US14/267,981 Active US8878936B2 (en) | 2012-08-06 | 2014-05-02 | Tracking and counting wheeled transportation apparatuses |
Family Applications After (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/280,958 Active US9036027B2 (en) | 2012-08-06 | 2014-05-19 | Tracking the use of at least one destination location |
US14/848,335 Active US9208619B1 (en) | 2012-08-06 | 2015-09-09 | Tracking the use of at least one destination location |
US14/856,484 Active US9607214B2 (en) | 2012-08-06 | 2015-09-16 | Tracking at least one object |
US14/943,025 Abandoned US20160078299A1 (en) | 2012-08-06 | 2015-11-17 | Imaging a Parking Display Ticket |
US17/147,016 Pending US20210279451A1 (en) | 2012-08-06 | 2021-01-12 | Tracking the Use of at Least One Destination Location |
Country Status (5)
Country | Link |
---|---|
US (22) | US8830322B2 (en) |
BR (1) | BR112015011749A8 (en) |
IL (1) | IL238803A (en) |
RU (1) | RU2607043C1 (en) |
SA (1) | SA515360480B1 (en) |
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150127222A1 (en) * | 2013-11-06 | 2015-05-07 | Frazier Cunningham, III | Parking signaling system |
US20150356469A1 (en) * | 2013-01-23 | 2015-12-10 | Ying-Tsun Su | System and method for management parking spaces |
CN105701865A (en) * | 2016-01-05 | 2016-06-22 | 常州加美科技有限公司 | Unmanned vehicle automatic payment system and method thereof |
US9558419B1 (en) | 2014-06-27 | 2017-01-31 | Blinker, Inc. | Method and apparatus for receiving a location of a vehicle service center from an image |
US9563814B1 (en) | 2014-06-27 | 2017-02-07 | Blinker, Inc. | Method and apparatus for recovering a vehicle identification number from an image |
US9589202B1 (en) | 2014-06-27 | 2017-03-07 | Blinker, Inc. | Method and apparatus for receiving an insurance quote from an image |
US9589201B1 (en) | 2014-06-27 | 2017-03-07 | Blinker, Inc. | Method and apparatus for recovering a vehicle value from an image |
US9594971B1 (en) | 2014-06-27 | 2017-03-14 | Blinker, Inc. | Method and apparatus for receiving listings of similar vehicles from an image |
US9600733B1 (en) | 2014-06-27 | 2017-03-21 | Blinker, Inc. | Method and apparatus for receiving car parts data from an image |
US9607236B1 (en) | 2014-06-27 | 2017-03-28 | Blinker, Inc. | Method and apparatus for providing loan verification from an image |
US9754171B1 (en) | 2014-06-27 | 2017-09-05 | Blinker, Inc. | Method and apparatus for receiving vehicle information from an image and posting the vehicle information to a website |
US9760776B1 (en) | 2014-06-27 | 2017-09-12 | Blinker, Inc. | Method and apparatus for obtaining a vehicle history report from an image |
US9773184B1 (en) | 2014-06-27 | 2017-09-26 | Blinker, Inc. | Method and apparatus for receiving a broadcast radio service offer from an image |
US9779318B1 (en) | 2014-06-27 | 2017-10-03 | Blinker, Inc. | Method and apparatus for verifying vehicle ownership from an image |
US9818154B1 (en) | 2014-06-27 | 2017-11-14 | Blinker, Inc. | System and method for electronic processing of vehicle transactions based on image detection of vehicle license plate |
US9892337B1 (en) | 2014-06-27 | 2018-02-13 | Blinker, Inc. | Method and apparatus for receiving a refinancing offer from an image |
US10242284B2 (en) | 2014-06-27 | 2019-03-26 | Blinker, Inc. | Method and apparatus for providing loan verification from an image |
US10429852B2 (en) * | 2016-03-29 | 2019-10-01 | Beijing Xiaomi Mobile Software Co., Ltd. | Methods and devices for controlling self-balancing vehicle to park |
US10515285B2 (en) | 2014-06-27 | 2019-12-24 | Blinker, Inc. | Method and apparatus for blocking information from an image |
US10540564B2 (en) | 2014-06-27 | 2020-01-21 | Blinker, Inc. | Method and apparatus for identifying vehicle information from an image |
US10572758B1 (en) | 2014-06-27 | 2020-02-25 | Blinker, Inc. | Method and apparatus for receiving a financing offer from an image |
CN111225182A (en) * | 2018-11-26 | 2020-06-02 | 杭州海康威视数字技术股份有限公司 | Image acquisition equipment, method and device |
CN111311923A (en) * | 2020-03-05 | 2020-06-19 | 浙江长元科技有限公司 | Fire fighting access supervision method and system |
US10733471B1 (en) | 2014-06-27 | 2020-08-04 | Blinker, Inc. | Method and apparatus for receiving recall information from an image |
US10867327B1 (en) | 2014-06-27 | 2020-12-15 | Blinker, Inc. | System and method for electronic processing of vehicle transactions based on image detection of vehicle license plate |
US10930151B2 (en) * | 2017-11-16 | 2021-02-23 | Intelligent Inter Connection Technology Co., Ltd. | Roadside parking management method, device, and system based on multiple cameras |
WO2021179035A1 (en) * | 2020-03-10 | 2021-09-16 | Sensen Networks Group Pty Ltd | Systems and methods for image-based location determination and parking monitoring |
US11199848B2 (en) * | 2017-07-21 | 2021-12-14 | Beijing Tusen Zhitu Technology Co., Ltd.. | Method, system and related device of implementing vehicle automatic payment |
Families Citing this family (506)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150235094A1 (en) | 2014-02-17 | 2015-08-20 | General Electric Company | Vehicle imaging system and method |
US10110795B2 (en) | 2002-06-04 | 2018-10-23 | General Electric Company | Video system and method for data communication |
US9875414B2 (en) | 2014-04-15 | 2018-01-23 | General Electric Company | Route damage prediction system and method |
US11124207B2 (en) * | 2014-03-18 | 2021-09-21 | Transportation Ip Holdings, Llc | Optical route examination system and method |
US7783406B2 (en) | 2005-09-22 | 2010-08-24 | Reagan Inventions, Llc | System for controlling speed of a vehicle |
US8930331B2 (en) | 2007-02-21 | 2015-01-06 | Palantir Technologies | Providing unique views of data based on changes or rules |
US8984390B2 (en) | 2008-09-15 | 2015-03-17 | Palantir Technologies, Inc. | One-click sharing for screenshots and related documents |
US9104695B1 (en) | 2009-07-27 | 2015-08-11 | Palantir Technologies, Inc. | Geotagging structured data |
US8315617B2 (en) | 2009-10-31 | 2012-11-20 | Btpatent Llc | Controlling mobile device functions |
US8145199B2 (en) | 2009-10-31 | 2012-03-27 | BT Patent LLC | Controlling mobile device functions |
US9230292B2 (en) * | 2012-11-08 | 2016-01-05 | Uber Technologies, Inc. | Providing on-demand services through use of portable computing devices |
TW201221391A (en) * | 2010-11-26 | 2012-06-01 | Hon Hai Prec Ind Co Ltd | Vehicle and backing up method thereof |
US9317860B2 (en) | 2011-03-08 | 2016-04-19 | Bank Of America Corporation | Collective network of augmented reality users |
US9773285B2 (en) | 2011-03-08 | 2017-09-26 | Bank Of America Corporation | Providing data associated with relationships between individuals and images |
US8873807B2 (en) * | 2011-03-08 | 2014-10-28 | Bank Of America Corporation | Vehicle recognition |
US9224166B2 (en) | 2011-03-08 | 2015-12-29 | Bank Of America Corporation | Retrieving product information from embedded sensors via mobile device video analysis |
US9317835B2 (en) | 2011-03-08 | 2016-04-19 | Bank Of America Corporation | Populating budgets and/or wish lists using real-time video image analysis |
US8451344B1 (en) * | 2011-03-24 | 2013-05-28 | Amazon Technologies, Inc. | Electronic devices with side viewing capability |
US9547693B1 (en) | 2011-06-23 | 2017-01-17 | Palantir Technologies Inc. | Periodic database search manager for multiple data sources |
US9092482B2 (en) | 2013-03-14 | 2015-07-28 | Palantir Technologies, Inc. | Fair scheduling for mixed-query loads |
US8799240B2 (en) | 2011-06-23 | 2014-08-05 | Palantir Technologies, Inc. | System and method for investigating large amounts of data |
US8612137B2 (en) * | 2011-07-18 | 2013-12-17 | Ituran Usa | System, method and apparatus for tracking parking behavior of a vehicle |
US8732574B2 (en) | 2011-08-25 | 2014-05-20 | Palantir Technologies, Inc. | System and method for parameterizing documents for automatic workflow generation |
US8504542B2 (en) | 2011-09-02 | 2013-08-06 | Palantir Technologies, Inc. | Multi-row transactions |
WO2013074604A2 (en) * | 2011-11-15 | 2013-05-23 | Magna Electronics, Inc. | Calibration system and method for vehicular surround vision system |
SE536199C2 (en) * | 2012-01-09 | 2013-06-25 | Movelo Ab | Reading and central storage of meter stand |
NZ605569A (en) * | 2012-02-02 | 2013-04-26 | Kapsch Trafficcom Ag | Factor VIII Formulations |
US20140337153A1 (en) * | 2012-03-02 | 2014-11-13 | Constantinos Antonios Terzidis | Exchange of information about geographical locations |
US8830322B2 (en) | 2012-08-06 | 2014-09-09 | Cloudparc, Inc. | Controlling use of a single multi-vehicle parking space and a restricted location within the single multi-vehicle parking space using multiple cameras |
US9489839B2 (en) * | 2012-08-06 | 2016-11-08 | Cloudparc, Inc. | Tracking a vehicle using an unmanned aerial vehicle |
DE102012216038A1 (en) * | 2012-09-11 | 2014-03-13 | Robert Bosch Gmbh | Method and device for operating a driver assistance system of a vehicle |
CA2790316C (en) * | 2012-09-19 | 2017-12-12 | Trapeze Software Inc. | Systems and methods for secure electronic ticketing |
WO2014052329A1 (en) | 2012-09-25 | 2014-04-03 | Scoot Networks, Inc. | Systems and methods for regulating vehicle access |
US9348677B2 (en) | 2012-10-22 | 2016-05-24 | Palantir Technologies Inc. | System and method for batch evaluation programs |
US9501507B1 (en) | 2012-12-27 | 2016-11-22 | Palantir Technologies Inc. | Geo-temporal indexing and searching |
US20140184428A1 (en) * | 2012-12-27 | 2014-07-03 | Jennifer A. Healey | Interactive management of a parked vehicle |
KR102194533B1 (en) | 2013-01-25 | 2020-12-23 | 뮤니시팔 파킹 서비시즈 인크. | Parking meter system |
US9380431B1 (en) | 2013-01-31 | 2016-06-28 | Palantir Technologies, Inc. | Use of teams in a mobile application |
WO2014123224A1 (en) * | 2013-02-08 | 2014-08-14 | 株式会社ニコン | Electronic controller, control method, and control program |
JP6205757B2 (en) * | 2013-03-07 | 2017-10-04 | オムロン株式会社 | Control system, control apparatus, image processing apparatus, and control method |
US10037314B2 (en) | 2013-03-14 | 2018-07-31 | Palantir Technologies, Inc. | Mobile reports |
US20140266801A1 (en) * | 2013-03-14 | 2014-09-18 | Infinite Computing Systems, Inc. | Digital Parking Management, Enforcement, and Notification |
US8917274B2 (en) | 2013-03-15 | 2014-12-23 | Palantir Technologies Inc. | Event matrix based on integrated data |
US8909656B2 (en) | 2013-03-15 | 2014-12-09 | Palantir Technologies Inc. | Filter chains with associated multipath views for exploring large data sets |
US8788405B1 (en) | 2013-03-15 | 2014-07-22 | Palantir Technologies, Inc. | Generating data clusters with customizable analysis strategies |
US8937619B2 (en) | 2013-03-15 | 2015-01-20 | Palantir Technologies Inc. | Generating an object time series from data objects |
US8868486B2 (en) | 2013-03-15 | 2014-10-21 | Palantir Technologies Inc. | Time-sensitive cube |
US9965937B2 (en) | 2013-03-15 | 2018-05-08 | Palantir Technologies Inc. | External malware data item clustering and analysis |
US10275778B1 (en) | 2013-03-15 | 2019-04-30 | Palantir Technologies Inc. | Systems and user interfaces for dynamic and interactive investigation based on automatic malfeasance clustering of related data in various data structures |
US20150170031A1 (en) * | 2013-05-01 | 2015-06-18 | Google Inc. | Determining parking of a vehicle |
US8799799B1 (en) | 2013-05-07 | 2014-08-05 | Palantir Technologies Inc. | Interactive geospatial map |
US9268741B1 (en) * | 2013-06-07 | 2016-02-23 | Lytx, Inc. | Deleting unnecessary map data |
US20140368652A1 (en) * | 2013-06-18 | 2014-12-18 | Xerox Corporation | Methods and systems for efficiently monitoring parking occupancy |
US9363483B2 (en) * | 2013-06-19 | 2016-06-07 | Xerox Corporation | Method for available parking distance estimation via vehicle side detection |
US9317752B2 (en) * | 2013-06-20 | 2016-04-19 | Xerox Corporation | Method for detecting large size and passenger vehicles from fixed cameras |
JP2015022658A (en) * | 2013-07-22 | 2015-02-02 | 株式会社東芝 | Vehicle monitoring apparatus and vehicle monitoring method |
KR101519209B1 (en) * | 2013-08-06 | 2015-05-11 | 현대자동차주식회사 | Apparatus and method for providing image |
US9335897B2 (en) | 2013-08-08 | 2016-05-10 | Palantir Technologies Inc. | Long click display of a context menu |
US9223773B2 (en) | 2013-08-08 | 2015-12-29 | Palatir Technologies Inc. | Template system for custom document generation |
US8713467B1 (en) | 2013-08-09 | 2014-04-29 | Palantir Technologies, Inc. | Context-sensitive views |
US9224062B2 (en) * | 2013-08-09 | 2015-12-29 | Xerox Corporation | Hybrid method and system of video and vision based access control for parking stall occupancy determination |
US9330316B2 (en) * | 2013-08-27 | 2016-05-03 | Simmonds Precision Products, Inc. | Sensor location and logical mapping system |
US20150062334A1 (en) * | 2013-08-29 | 2015-03-05 | FanPix, LLC | Systems and Methods for Image Capture and Distribution in Venues |
US9996827B2 (en) | 2013-09-10 | 2018-06-12 | Boku, Inc. | System and method for metered parking at a parking server |
US20150073880A1 (en) * | 2013-09-10 | 2015-03-12 | Boku, Inc. | System and method for metered parking at a billing server |
US9785317B2 (en) | 2013-09-24 | 2017-10-10 | Palantir Technologies Inc. | Presentation and analysis of user interaction data |
US8923565B1 (en) * | 2013-09-26 | 2014-12-30 | Chengdu Haicun Ip Technology Llc | Parked vehicle detection based on edge detection |
US8938686B1 (en) | 2013-10-03 | 2015-01-20 | Palantir Technologies Inc. | Systems and methods for analyzing performance of an entity |
JP6167824B2 (en) * | 2013-10-04 | 2017-07-26 | アイシン精機株式会社 | Parking assistance device |
US8812960B1 (en) | 2013-10-07 | 2014-08-19 | Palantir Technologies Inc. | Cohort-based presentation of user interaction data |
US9412031B2 (en) * | 2013-10-16 | 2016-08-09 | Xerox Corporation | Delayed vehicle identification for privacy enforcement |
US9792631B2 (en) | 2013-10-16 | 2017-10-17 | Boku, Inc. | Merchant managed method and system for text-to-pay subscriptions at a billing server |
US8924872B1 (en) | 2013-10-18 | 2014-12-30 | Palantir Technologies Inc. | Overview user interface of emergency call data of a law enforcement agency |
US9116975B2 (en) | 2013-10-18 | 2015-08-25 | Palantir Technologies Inc. | Systems and user interfaces for dynamic and interactive simultaneous querying of multiple data stores |
US9021384B1 (en) | 2013-11-04 | 2015-04-28 | Palantir Technologies Inc. | Interactive vehicle information map |
US8868537B1 (en) | 2013-11-11 | 2014-10-21 | Palantir Technologies, Inc. | Simple web search |
US9105000B1 (en) | 2013-12-10 | 2015-08-11 | Palantir Technologies Inc. | Aggregating data from a plurality of data sources |
US9727622B2 (en) | 2013-12-16 | 2017-08-08 | Palantir Technologies, Inc. | Methods and systems for analyzing entity performance |
US9402018B2 (en) * | 2013-12-17 | 2016-07-26 | Amazon Technologies, Inc. | Distributing processing for imaging processing |
US9552615B2 (en) | 2013-12-20 | 2017-01-24 | Palantir Technologies Inc. | Automated database analysis to detect malfeasance |
US10356032B2 (en) | 2013-12-26 | 2019-07-16 | Palantir Technologies Inc. | System and method for detecting confidential information emails |
US9043696B1 (en) | 2014-01-03 | 2015-05-26 | Palantir Technologies Inc. | Systems and methods for visual definition of data associations |
US8832832B1 (en) | 2014-01-03 | 2014-09-09 | Palantir Technologies Inc. | IP reputation |
US11244171B2 (en) | 2014-01-22 | 2022-02-08 | Conduent Business Services Llc | Video-based system for automated detection of double parking violations |
US9514366B2 (en) * | 2014-02-03 | 2016-12-06 | Xerox Corporation | Vehicle detection method and system including irrelevant window elimination and/or window score degradation |
US11443331B2 (en) * | 2014-02-13 | 2022-09-13 | Conduent Business Solutions, Llc | Multi-target tracking for demand management |
US9483162B2 (en) | 2014-02-20 | 2016-11-01 | Palantir Technologies Inc. | Relationship visualizations |
US9009827B1 (en) | 2014-02-20 | 2015-04-14 | Palantir Technologies Inc. | Security sharing system |
US9727376B1 (en) | 2014-03-04 | 2017-08-08 | Palantir Technologies, Inc. | Mobile tasks |
US8935201B1 (en) | 2014-03-18 | 2015-01-13 | Palantir Technologies Inc. | Determining and extracting changed data from a data source |
US20150278969A1 (en) * | 2014-03-26 | 2015-10-01 | Xerox Corporation | Integrated automated solution for the management of services for the disabled and others |
JP6708368B2 (en) * | 2014-04-25 | 2020-06-10 | コンデュエント ビジネス サービシーズ エルエルシー | Method and system for partial concealment processing in vehicle tracking using deformable partial model |
US9857958B2 (en) | 2014-04-28 | 2018-01-02 | Palantir Technologies Inc. | Systems and user interfaces for dynamic and interactive access of, investigation of, and analysis of data objects stored in one or more databases |
US9009171B1 (en) | 2014-05-02 | 2015-04-14 | Palantir Technologies Inc. | Systems and methods for active column filtering |
US9550498B2 (en) * | 2014-05-13 | 2017-01-24 | Ford Global Technologies, Llc | Traffic light anticipation |
US11308462B2 (en) | 2014-05-13 | 2022-04-19 | Clear Token Inc | Secure electronic payment |
US10207193B2 (en) | 2014-05-21 | 2019-02-19 | Universal City Studios Llc | Optical tracking system for automation of amusement park elements |
US9616350B2 (en) | 2014-05-21 | 2017-04-11 | Universal City Studios Llc | Enhanced interactivity in an amusement park environment using passive tracking elements |
US10061058B2 (en) | 2014-05-21 | 2018-08-28 | Universal City Studios Llc | Tracking system and method for use in surveying amusement park equipment |
US10025990B2 (en) * | 2014-05-21 | 2018-07-17 | Universal City Studios Llc | System and method for tracking vehicles in parking structures and intersections |
US9858816B2 (en) * | 2014-05-21 | 2018-01-02 | Regents Of The University Of Minnesota | Determining parking space occupancy using a 3D representation |
US9429398B2 (en) | 2014-05-21 | 2016-08-30 | Universal City Studios Llc | Optical tracking for controlling pyrotechnic show elements |
US9600999B2 (en) * | 2014-05-21 | 2017-03-21 | Universal City Studios Llc | Amusement park element tracking system |
US9433870B2 (en) | 2014-05-21 | 2016-09-06 | Universal City Studios Llc | Ride vehicle tracking and control system using passive tracking elements |
WO2015195976A2 (en) * | 2014-06-18 | 2015-12-23 | Chris Barnard | Application framework for interactive light sensor networks |
US9535974B1 (en) | 2014-06-30 | 2017-01-03 | Palantir Technologies Inc. | Systems and methods for identifying key phrase clusters within documents |
US9619557B2 (en) | 2014-06-30 | 2017-04-11 | Palantir Technologies, Inc. | Systems and methods for key phrase characterization of documents |
US9129219B1 (en) | 2014-06-30 | 2015-09-08 | Palantir Technologies, Inc. | Crime risk forecasting |
US9202249B1 (en) | 2014-07-03 | 2015-12-01 | Palantir Technologies Inc. | Data item clustering and analysis |
US10572496B1 (en) | 2014-07-03 | 2020-02-25 | Palantir Technologies Inc. | Distributed workflow system and database with access controls for city resiliency |
US9256664B2 (en) | 2014-07-03 | 2016-02-09 | Palantir Technologies Inc. | System and method for news events detection and visualization |
US9785773B2 (en) | 2014-07-03 | 2017-10-10 | Palantir Technologies Inc. | Malware data item analysis |
JP6248836B2 (en) * | 2014-07-10 | 2017-12-20 | 株式会社デンソー | Driving assistance device |
US9928594B2 (en) * | 2014-07-11 | 2018-03-27 | Agt International Gmbh | Automatic spatial calibration of camera network |
US9805602B2 (en) * | 2014-07-21 | 2017-10-31 | Ford Global Technologies, Llc | Parking service |
CN104183153A (en) * | 2014-07-23 | 2014-12-03 | 陈嘉延 | Intelligent parking guiding system based on guidance of quadrotor unmanned plane |
US9454281B2 (en) | 2014-09-03 | 2016-09-27 | Palantir Technologies Inc. | System for providing dynamic linked panels in user interface |
JP6316161B2 (en) * | 2014-09-29 | 2018-04-25 | クラリオン株式会社 | In-vehicle image processing device |
WO2016053073A1 (en) * | 2014-09-30 | 2016-04-07 | PALAZUELOS VALDES, Alvaro | Parking management assisted by artificial vision |
US9418553B2 (en) * | 2014-10-02 | 2016-08-16 | Omid B. Nakhjavani | Easy parking finder |
US9767172B2 (en) | 2014-10-03 | 2017-09-19 | Palantir Technologies Inc. | Data aggregation and analysis system |
US9501851B2 (en) | 2014-10-03 | 2016-11-22 | Palantir Technologies Inc. | Time-series analysis system |
US20160110999A1 (en) * | 2014-10-15 | 2016-04-21 | Xerox Corporation | Methods and systems for parking monitoring with vehicle identification |
KR101657962B1 (en) * | 2014-10-16 | 2016-09-21 | 렉스젠(주) | Apparatus for inputting vehicle number and method thereof |
US9984133B2 (en) | 2014-10-16 | 2018-05-29 | Palantir Technologies Inc. | Schematic and database linking system |
US20160110925A1 (en) * | 2014-10-21 | 2016-04-21 | Salem Ali BEN KENAID | Vehicle parking management device |
US20160119585A1 (en) * | 2014-10-28 | 2016-04-28 | Motorola Solutions, Inc | Method and apparatus for forwarding a camera feed |
US20160116564A1 (en) * | 2014-10-28 | 2016-04-28 | Motorola Solutions, Inc | Method and apparatus for forwarding a camera feed |
WO2016070121A1 (en) * | 2014-10-30 | 2016-05-06 | Ryhorchuk Kent W | Parking and traffic analysis |
US9229952B1 (en) | 2014-11-05 | 2016-01-05 | Palantir Technologies, Inc. | History preserving data pipeline system and method |
US9043894B1 (en) | 2014-11-06 | 2015-05-26 | Palantir Technologies Inc. | Malicious software detection in a computing system |
DE102015118598A1 (en) * | 2015-10-30 | 2017-05-04 | Cleverciti Systems Gmbh | METHOD FOR RECORDING PARKED VEHICLES AND BILLING PARKING FEES |
KR20160058519A (en) * | 2014-11-17 | 2016-05-25 | 삼성전자주식회사 | Image processing for multiple images |
WO2016093553A1 (en) * | 2014-12-12 | 2016-06-16 | 서울대학교 산학협력단 | System for collecting event data, method for collecting event data, service server for collecting event data, and camera |
US9541409B2 (en) | 2014-12-18 | 2017-01-10 | Nissan North America, Inc. | Marker aided autonomous vehicle localization |
US9348920B1 (en) | 2014-12-22 | 2016-05-24 | Palantir Technologies Inc. | Concept indexing among database of documents using machine learning techniques |
US9367872B1 (en) | 2014-12-22 | 2016-06-14 | Palantir Technologies Inc. | Systems and user interfaces for dynamic and interactive investigation of bad actor behavior based on automatic clustering of related data in various data structures |
US10552994B2 (en) | 2014-12-22 | 2020-02-04 | Palantir Technologies Inc. | Systems and interactive user interfaces for dynamic retrieval, analysis, and triage of data items |
US10362133B1 (en) | 2014-12-22 | 2019-07-23 | Palantir Technologies Inc. | Communication data processing architecture |
US9817563B1 (en) | 2014-12-29 | 2017-11-14 | Palantir Technologies Inc. | System and method of generating data points from one or more data stores of data items for chart creation and manipulation |
US9335911B1 (en) | 2014-12-29 | 2016-05-10 | Palantir Technologies Inc. | Interactive user interface for dynamic data analysis exploration and query processing |
US9870205B1 (en) | 2014-12-29 | 2018-01-16 | Palantir Technologies Inc. | Storing logical units of program code generated using a dynamic programming notebook user interface |
CN104616361A (en) * | 2014-12-30 | 2015-05-13 | 腾讯科技(深圳)有限公司 | Parking management method, server, user terminal and system |
US10372879B2 (en) | 2014-12-31 | 2019-08-06 | Palantir Technologies Inc. | Medical claims lead summary report generation |
JP6409882B2 (en) * | 2015-01-14 | 2018-10-24 | オムロン株式会社 | Report reception system and report reception method |
US9448559B2 (en) | 2015-01-15 | 2016-09-20 | Nissan North America, Inc. | Autonomous vehicle routing and navigation using passenger docking locations |
US9625906B2 (en) * | 2015-01-15 | 2017-04-18 | Nissan North America, Inc. | Passenger docking location selection |
US10387834B2 (en) | 2015-01-21 | 2019-08-20 | Palantir Technologies Inc. | Systems and methods for accessing and storing snapshots of a remote application in a document |
CN105894817B (en) * | 2015-01-26 | 2019-04-30 | 杭州海康威视数字技术股份有限公司 | The evidence collecting method and its device of vehicle violation parking |
US9568335B2 (en) | 2015-01-30 | 2017-02-14 | Nissan North America, Inc. | Associating parking areas with destinations based on automatically identified associations between vehicle operating information and non-vehicle operating information |
US9697730B2 (en) | 2015-01-30 | 2017-07-04 | Nissan North America, Inc. | Spatial clustering of vehicle probe data |
CN104680211B (en) * | 2015-02-09 | 2018-01-02 | 天津创思佳网务科技发展有限公司 | A kind of secret protection intelligent sliding car system and its shifting car method |
US9727560B2 (en) | 2015-02-25 | 2017-08-08 | Palantir Technologies Inc. | Systems and methods for organizing and identifying documents via hierarchies and dimensions of tags |
CN104637304B (en) * | 2015-03-08 | 2016-08-24 | 江苏巴吉装备科技有限公司 | A kind of vehicle peccancy behavioral value method robbing row left-hand lane |
DE102015204169A1 (en) * | 2015-03-09 | 2016-09-15 | Bayerische Motoren Werke Aktiengesellschaft | Method for updating parking information in a navigation system and navigation system |
DE102015204363A1 (en) * | 2015-03-11 | 2016-09-15 | Robert Bosch Gmbh | Method for operating a server |
US9778658B2 (en) | 2015-03-13 | 2017-10-03 | Nissan North America, Inc. | Pattern detection using probe data |
US9891808B2 (en) | 2015-03-16 | 2018-02-13 | Palantir Technologies Inc. | Interactive user interfaces for location-based data analysis |
WO2016145626A1 (en) * | 2015-03-18 | 2016-09-22 | 富士通株式会社 | Traffic abnormity detection method and device, and image monitoring system |
GB2536470A (en) * | 2015-03-18 | 2016-09-21 | Mendel Sudak Menachem | Car parks |
US9886467B2 (en) | 2015-03-19 | 2018-02-06 | Plantir Technologies Inc. | System and method for comparing and visualizing data entities and data entity series |
CN107787508A (en) * | 2015-03-23 | 2018-03-09 | 飞利浦照明控股有限公司 | Light fixture stopping guide |
DE102015205634A1 (en) * | 2015-03-27 | 2016-09-29 | Robert Bosch Gmbh | Method for detecting movements of objects on a parking space for vehicles |
KR101556950B1 (en) * | 2015-03-31 | 2015-10-06 | 파킹클라우드 주식회사 | Parking lot managing method, handheld device and parking lot managing system |
JP6523018B2 (en) * | 2015-03-31 | 2019-05-29 | 株式会社デンソーテン | Parking support device and parking support system |
US9607509B2 (en) * | 2015-04-08 | 2017-03-28 | Sap Se | Identification of vehicle parking using data from vehicle sensor network |
US10380430B2 (en) | 2015-04-17 | 2019-08-13 | Current Lighting Solutions, Llc | User interfaces for parking zone creation |
US20160307048A1 (en) * | 2015-04-17 | 2016-10-20 | General Electric Company | Simulating camera node output for parking policy management system |
US10043307B2 (en) | 2015-04-17 | 2018-08-07 | General Electric Company | Monitoring parking rule violations |
US9549100B2 (en) * | 2015-04-23 | 2017-01-17 | Microsoft Technology Licensing, Llc | Low-latency timing control |
DE102015208058B4 (en) * | 2015-04-30 | 2017-06-29 | Robert Bosch Gmbh | Automated parking system |
CA2985539C (en) * | 2015-05-13 | 2023-04-04 | Uber Technologies, Inc. | Autonomous vehicle operated with guide assistance |
CN104809913A (en) * | 2015-05-21 | 2015-07-29 | 重庆云途交通科技有限公司 | Parking management system based on cloud platform and management method thereof |
US9460175B1 (en) | 2015-06-03 | 2016-10-04 | Palantir Technologies Inc. | Server implemented geographic information system with graphical interface |
US20160364984A1 (en) * | 2015-06-11 | 2016-12-15 | National Chung Shan Institute Of Science And Technology | Infrared logical matrix-style traffic violation detection method and apparatus |
DE102016206493A1 (en) * | 2015-06-23 | 2016-12-29 | Robert Bosch Gmbh | Method and camera system for determining the distance of objects to a vehicle |
CN107134165B (en) * | 2015-06-29 | 2021-06-15 | 杨秀莲 | Parking space license plate movable type recognition device and recognition method |
US20170004710A1 (en) * | 2015-06-30 | 2017-01-05 | Kristen Dozono | Intelligent Parking Management |
US9449258B1 (en) * | 2015-07-02 | 2016-09-20 | Agt International Gmbh | Multi-camera vehicle identification system |
CN105049721B (en) * | 2015-07-10 | 2018-07-31 | 深圳市灵动飞扬科技有限公司 | Vehicle-mounted camera bearing calibration and system |
US9454785B1 (en) | 2015-07-30 | 2016-09-27 | Palantir Technologies Inc. | Systems and user interfaces for holistic, data-driven investigation of bad actor behavior based on clustering and scoring of related data |
CA2993808C (en) * | 2015-07-30 | 2023-10-10 | Mark J. Moran | Virtual parking lots |
KR102531014B1 (en) | 2015-07-30 | 2023-05-11 | 뮤니시팔 파킹 서비시즈 인크. | Integrated mobile parking application and smart parking meter system |
US9996595B2 (en) | 2015-08-03 | 2018-06-12 | Palantir Technologies, Inc. | Providing full data provenance visualization for versioned datasets |
US9456000B1 (en) | 2015-08-06 | 2016-09-27 | Palantir Technologies Inc. | Systems, methods, user interfaces, and computer-readable media for investigating potential malicious communications |
CN105185111A (en) * | 2015-08-12 | 2015-12-23 | 国网山东省电力公司济南供电公司 | Voice warning and networked alarm system for social vehicle jam at substation gate |
US10467905B2 (en) | 2015-08-14 | 2019-11-05 | Ford Global Technologies, Llc | User configurable vehicle parking alert system |
US9600146B2 (en) | 2015-08-17 | 2017-03-21 | Palantir Technologies Inc. | Interactive geospatial map |
US10489391B1 (en) | 2015-08-17 | 2019-11-26 | Palantir Technologies Inc. | Systems and methods for grouping and enriching data items accessed from one or more databases for presentation in a user interface |
US10102369B2 (en) | 2015-08-19 | 2018-10-16 | Palantir Technologies Inc. | Checkout system executable code monitoring, and user account compromise determination system |
EP3133545A1 (en) * | 2015-08-20 | 2017-02-22 | Samsung Electronics Co., Ltd. | Apparatus and operating method for mobile payments in a vehicle |
US10853378B1 (en) | 2015-08-25 | 2020-12-01 | Palantir Technologies Inc. | Electronic note management via a connected entity graph |
US11150917B2 (en) | 2015-08-26 | 2021-10-19 | Palantir Technologies Inc. | System for data aggregation and analysis of data from a plurality of data sources |
US9485265B1 (en) | 2015-08-28 | 2016-11-01 | Palantir Technologies Inc. | Malicious activity detection system capable of efficiently processing data accessed from databases and generating alerts for display in interactive user interfaces |
JP6556563B2 (en) * | 2015-08-31 | 2019-08-07 | 株式会社東芝 | Detection apparatus, detection method, detection program, and information processing system |
US10706434B1 (en) | 2015-09-01 | 2020-07-07 | Palantir Technologies Inc. | Methods and systems for determining location information |
US9639580B1 (en) | 2015-09-04 | 2017-05-02 | Palantir Technologies, Inc. | Computer-implemented systems and methods for data management and visualization |
US9576015B1 (en) | 2015-09-09 | 2017-02-21 | Palantir Technologies, Inc. | Domain-specific language for dataset transformations |
US9679485B2 (en) | 2015-09-11 | 2017-06-13 | International Business Machines Corporation | Determining a parking position based on visual and non-visual factors |
US9947107B2 (en) | 2015-09-16 | 2018-04-17 | Agt International Gmbh | Method and system for tracking objects between cameras |
US10088736B2 (en) * | 2015-09-24 | 2018-10-02 | Amazon Technologies, Inc. | Unmanned aerial vehicle descent |
WO2017053612A1 (en) * | 2015-09-25 | 2017-03-30 | Nyqamin Dynamics Llc | Automated capture of image data for points of interest |
CN112184928A (en) * | 2015-09-28 | 2021-01-05 | 西安艾润物联网技术服务有限责任公司 | Parking lot vehicle access control method and device |
US20170089711A1 (en) * | 2015-09-30 | 2017-03-30 | Faraday&Future Inc | Methods and apparatus for generating digital boundaries based on overhead images |
US10296617B1 (en) | 2015-10-05 | 2019-05-21 | Palantir Technologies Inc. | Searches of highly structured data |
US9773178B2 (en) | 2015-10-08 | 2017-09-26 | International Business Machines Corporation | Vehicle tracking |
CA2908762C (en) * | 2015-10-16 | 2024-01-02 | Imperial Parking Canada Corporation | Method and system for managing parking by dual location verification |
DE102015221356B4 (en) * | 2015-10-30 | 2020-12-24 | Conti Temic Microelectronic Gmbh | Device and method for providing a vehicle panoramic view |
US9842263B2 (en) * | 2015-11-10 | 2017-12-12 | Ford Global Technologies, Llc | Inter-vehicle authentication using visual contextual information |
CN105516616A (en) * | 2015-11-28 | 2016-04-20 | 绵阳少军信息科技有限公司 | Integrated vehicle-mounted camera module applied to law enforcement vehicle and video recording system thereof |
EP3792880B1 (en) | 2015-12-01 | 2023-07-12 | Genetec Inc. | Peer-to-peer virtual chalking |
JP6909802B2 (en) * | 2015-12-02 | 2021-07-28 | シティファイド インコーポレイテッドCitifyd, Inc. | Vehicle parking and public transport beacon system |
US9824289B2 (en) | 2015-12-07 | 2017-11-21 | Conduent Business Services, Llc | Exploiting color for license plate recognition |
US20170161961A1 (en) * | 2015-12-07 | 2017-06-08 | Paul Salsberg | Parking space control method and system with unmanned paired aerial vehicle (uav) |
US10049286B2 (en) * | 2015-12-15 | 2018-08-14 | International Business Machines Corporation | Image-based risk estimation |
KR101843538B1 (en) * | 2015-12-16 | 2018-03-30 | 엘지전자 주식회사 | Driver assistance appratus and method thereof |
US9542446B1 (en) | 2015-12-17 | 2017-01-10 | Palantir Technologies, Inc. | Automatic generation of composite datasets based on hierarchical fields |
SG10201510469RA (en) * | 2015-12-18 | 2017-07-28 | Mastercard International Inc | Method For Managing Payment Vehicle Data Based On Location Information |
US10109094B2 (en) | 2015-12-21 | 2018-10-23 | Palantir Technologies Inc. | Interface to index and display geospatial data |
US10074272B2 (en) * | 2015-12-28 | 2018-09-11 | Here Global B.V. | Method, apparatus and computer program product for traffic lane and signal control identification and traffic flow management |
US9823818B1 (en) | 2015-12-29 | 2017-11-21 | Palantir Technologies Inc. | Systems and interactive user interfaces for automatic generation of temporal representation of data objects |
US10089289B2 (en) | 2015-12-29 | 2018-10-02 | Palantir Technologies Inc. | Real-time document annotation |
US9612723B1 (en) | 2015-12-30 | 2017-04-04 | Palantir Technologies Inc. | Composite graphical interface with shareable data-objects |
CN108431879B (en) * | 2015-12-31 | 2023-03-14 | 罗伯特·博世有限公司 | Intelligent distributed visual traffic marker and method thereof |
US11455838B2 (en) * | 2016-01-13 | 2022-09-27 | Parkhub, Inc. | System for monitoring arrival of a vehicle at a given location and associated methods |
CN105469529B (en) * | 2016-01-13 | 2018-08-21 | 上海腾盛智能安全科技股份有限公司 | A kind of image-type fire communication alarming device |
US11386780B2 (en) | 2016-01-13 | 2022-07-12 | Parkhub, Inc. | System for monitoring arrival of a vehicle at a given location and associated methods |
US10019898B2 (en) * | 2016-01-14 | 2018-07-10 | Siemens Industry, Inc. | Systems and methods to detect vehicle queue lengths of vehicles stopped at a traffic light signal |
JP2017151944A (en) * | 2016-02-23 | 2017-08-31 | キヤノン株式会社 | Image forming apparatus, system, method, and program |
CN106156767A (en) * | 2016-03-02 | 2016-11-23 | 平安科技(深圳)有限公司 | Driving license effect duration extraction method, server and terminal |
US10698938B2 (en) | 2016-03-18 | 2020-06-30 | Palantir Technologies Inc. | Systems and methods for organizing and identifying documents via hierarchies and dimensions of tags |
CN107220579B (en) * | 2016-03-21 | 2020-02-04 | 杭州海康威视数字技术股份有限公司 | License plate detection method and device |
CN106384393A (en) * | 2016-03-29 | 2017-02-08 | 上海瀚泰智能科技有限公司 | Intelligent parking lot management terminal and system |
US10778600B2 (en) * | 2016-03-30 | 2020-09-15 | Intel Corporation | Adaptive workload distribution for network of video processors |
GB2564314B (en) * | 2016-03-31 | 2022-02-23 | Mitsubishi Heavy Ind Mach Systems Ltd | Toll collection system and soundness determination method |
DE102016106513B4 (en) * | 2016-04-08 | 2019-06-27 | Cleverciti Systems Gmbh | Method for detecting parked vehicles |
US10846668B1 (en) * | 2016-04-12 | 2020-11-24 | Wells Fargo Bank, N.A. | Systems and methods for completing transactions via curbside service |
US9946936B2 (en) | 2016-04-12 | 2018-04-17 | Conduent Business Services, Llc | Automated video based ingress/egress sensor reset for truck stop occupancy detection |
US10360458B2 (en) * | 2016-04-13 | 2019-07-23 | GM Global Technology Operations LLC | Method of calculating dimensions of a towed vehicle |
JP6692209B2 (en) * | 2016-05-11 | 2020-05-13 | 株式会社日立製作所 | Parking management system and control method thereof |
US10068199B1 (en) | 2016-05-13 | 2018-09-04 | Palantir Technologies Inc. | System to catalogue tracking data |
CN106055745B (en) * | 2016-05-20 | 2019-02-19 | 浙江大学 | A method of linear CCD carriage simulation model is established based on MATLAB |
DE102016208846B4 (en) * | 2016-05-23 | 2020-03-12 | Continental Teves Ag & Co. Ohg | Communication system for a vehicle |
CN109313035A (en) * | 2016-06-02 | 2019-02-05 | 索尼公司 | Information processing unit and information processing method |
CN107492260A (en) * | 2016-06-12 | 2017-12-19 | 上海仪景信息技术有限公司 | A kind of comprehensive control system in parking lot and its charging method |
CN109311511B (en) * | 2016-06-28 | 2021-11-23 | 福特全球技术公司 | Method and apparatus for repositioning a vehicle based on vehicle and environmental characteristics |
US10311723B2 (en) * | 2016-07-15 | 2019-06-04 | Intel Corporation | Parking management system and method |
US10324609B2 (en) | 2016-07-21 | 2019-06-18 | Palantir Technologies Inc. | System for providing dynamic linked panels in user interface |
US10719188B2 (en) | 2016-07-21 | 2020-07-21 | Palantir Technologies Inc. | Cached database and synchronization system for providing dynamic linked panels in user interface |
CN107666590B (en) * | 2016-07-29 | 2020-01-17 | 华为终端有限公司 | Target monitoring method, camera, controller and target monitoring system |
US9686357B1 (en) | 2016-08-02 | 2017-06-20 | Palantir Technologies Inc. | Mapping content delivery |
US10217002B2 (en) * | 2016-08-04 | 2019-02-26 | International Business Machines Corporation | Systems and methods for monitoring unmanned vehicles |
US10437840B1 (en) | 2016-08-19 | 2019-10-08 | Palantir Technologies Inc. | Focused probabilistic entity resolution from multiple data sources |
US9547883B1 (en) * | 2016-08-19 | 2017-01-17 | Intelligent Security Systems Corporation | Systems and methods for dewarping images |
CN106355886B (en) * | 2016-08-31 | 2019-11-15 | 智慧互通科技有限公司 | A kind of open type parking ground parking management system and its management method |
CN106469469A (en) * | 2016-08-31 | 2017-03-01 | 北京悦畅科技有限公司 | A kind of method and system realizing the lease control of Parking position |
US10803423B2 (en) | 2016-09-29 | 2020-10-13 | The Parking Genius, Inc. | System for managing parking of autonomous driving vehicles |
US10786327B2 (en) * | 2016-10-03 | 2020-09-29 | Verb Surgical Inc. | Immersive three-dimensional display for robotic surgery |
US10255791B2 (en) * | 2016-10-14 | 2019-04-09 | Walmart Apollo, Llc | Apparatus and method for providing reminders |
CN108022311A (en) * | 2016-10-27 | 2018-05-11 | 英业达科技有限公司 | Place management method and site management system |
US10368036B2 (en) * | 2016-11-17 | 2019-07-30 | Vivotek Inc. | Pair of parking area sensing cameras, a parking area sensing method and a parking area sensing system |
US10318630B1 (en) | 2016-11-21 | 2019-06-11 | Palantir Technologies Inc. | Analysis of large bodies of textual data |
DE102016223106A1 (en) * | 2016-11-23 | 2018-05-24 | Robert Bosch Gmbh | Method and system for detecting a raised object located within a parking lot |
DE102016223180A1 (en) * | 2016-11-23 | 2018-05-24 | Robert Bosch Gmbh | Method and system for detecting a raised object located within a parking lot |
DE102016223171A1 (en) * | 2016-11-23 | 2018-05-24 | Robert Bosch Gmbh | Method and system for detecting a raised object located within a parking lot |
US10299122B2 (en) | 2016-11-23 | 2019-05-21 | The Parking Genius, Inc. | User validation system utilizing symbolic or pictographic representations of validation codes |
CN106504578B (en) * | 2016-11-24 | 2018-12-21 | 江苏旭云物联信息科技有限公司 | A kind of wisdom shutdown system based on Internet of Things |
CN108109132B (en) | 2016-11-25 | 2021-02-05 | 杭州海康威视数字技术股份有限公司 | Image analysis method and device |
US10515433B1 (en) | 2016-12-13 | 2019-12-24 | Palantir Technologies Inc. | Zoom-adaptive data granularity to achieve a flexible high-performance interface for a geospatial mapping system |
US11037024B1 (en) * | 2016-12-20 | 2021-06-15 | Jayant Ratti | Crowdsourced on-demand AI data annotation, collection and processing |
US10270727B2 (en) | 2016-12-20 | 2019-04-23 | Palantir Technologies, Inc. | Short message communication within a mobile graphical map |
US10460602B1 (en) | 2016-12-28 | 2019-10-29 | Palantir Technologies Inc. | Interactive vehicle information mapping system |
DE102017200069A1 (en) * | 2017-01-04 | 2018-07-05 | Robert Bosch Gmbh | Method for determining a parking position, and arrangement for carrying out the method |
PH12017000044B1 (en) * | 2017-02-13 | 2018-08-20 | Samsung Electronics Co Ltd | Vehicle parking area access management system and method |
IT201700021559A1 (en) * | 2017-02-27 | 2018-08-27 | St Microelectronics Srl | CORRESPONDENT PROCEDURE FOR THE CONTROL OF LASER RAYS, DEVICE, EQUIPMENT AND COMPUTER PRODUCT |
CN110419069B (en) * | 2017-03-03 | 2023-08-18 | 福特全球技术公司 | Vehicle parking control |
US10381296B2 (en) * | 2017-03-06 | 2019-08-13 | Advanced Semiconductor Engineering, Inc. | Semiconductor device package and a method of manufacturing the same |
CN106875730B (en) * | 2017-03-13 | 2019-09-17 | 江苏大学 | A kind of more vehicles collaboration Input System based on ultrasonic wave positioning and radio communication |
US10499001B2 (en) * | 2017-03-16 | 2019-12-03 | Gvbb Holdings S.A.R.L. | System and method for augmented video production workflow |
CN107545776A (en) * | 2017-03-21 | 2018-01-05 | 昆山市苞蕾众创投资管理有限公司 | A kind of wechat of sweeping can preengage the parking stall of parking |
US10579239B1 (en) | 2017-03-23 | 2020-03-03 | Palantir Technologies Inc. | Systems and methods for production and display of dynamically linked slide presentations |
EP3388972B1 (en) * | 2017-04-13 | 2020-08-26 | Aptiv Technologies Limited | A method and a device for generating an occupancy map of an environment of a vehicle |
CN107730956A (en) * | 2017-05-04 | 2018-02-23 | 西安艾润物联网技术服务有限责任公司 | Vehicle parking method, apparatus and computer-readable recording medium |
CN107274495A (en) * | 2017-05-16 | 2017-10-20 | 南京信息工程大学 | A kind of unattended curb parking fee collecting system |
US10895946B2 (en) | 2017-05-30 | 2021-01-19 | Palantir Technologies Inc. | Systems and methods for using tiled data |
US11334216B2 (en) | 2017-05-30 | 2022-05-17 | Palantir Technologies Inc. | Systems and methods for visually presenting geospatial information |
US10956406B2 (en) | 2017-06-12 | 2021-03-23 | Palantir Technologies Inc. | Propagated deletion of database records and derived data |
US10157476B1 (en) * | 2017-06-15 | 2018-12-18 | Satori Worldwide, Llc | Self-learning spatial recognition system |
CN107195119A (en) * | 2017-06-28 | 2017-09-22 | 邓宏伟 | Shared bicycle parking system and its parking method |
CN109238293A (en) * | 2017-07-10 | 2019-01-18 | 李公健 | A kind of system and method for long-range management bicycle parking posture |
US10403011B1 (en) | 2017-07-18 | 2019-09-03 | Palantir Technologies Inc. | Passing system with an interactive user interface |
JP6819500B2 (en) * | 2017-07-26 | 2021-01-27 | 株式会社デンソー | Parking support system and parking support method |
CN107545416A (en) * | 2017-07-28 | 2018-01-05 | 阿里巴巴集团控股有限公司 | Refuel, refuel clearing, oiling method of payment, device and electronic equipment |
EP3664742A1 (en) * | 2017-08-11 | 2020-06-17 | Brainlab AG | Video based microscope adjustment |
JP2019036872A (en) | 2017-08-17 | 2019-03-07 | パナソニックIpマネジメント株式会社 | Search support device, search support method and search support system |
CN107563419B (en) * | 2017-08-22 | 2020-09-04 | 交控科技股份有限公司 | Train positioning method combining image matching and two-dimensional code |
US10726723B1 (en) * | 2017-08-25 | 2020-07-28 | Objectvideo Labs, Llc | Parking lot use monitoring for small businesses |
US10585439B2 (en) * | 2017-08-29 | 2020-03-10 | Ford Global Technologies, Llc | Vehicle inspection |
US10867518B2 (en) * | 2017-08-31 | 2020-12-15 | Ubicquia Iq Llc | Method and system for identifying location of a parked vehicle |
KR101784764B1 (en) | 2017-09-05 | 2017-10-12 | 주식회사한맥아이피에스 | The highway toll payment method for electric vehicle |
CN107393311B (en) * | 2017-09-13 | 2019-11-26 | 京东方科技集团股份有限公司 | A kind of license plate tamper Detection device and method |
US10706297B2 (en) * | 2017-09-20 | 2020-07-07 | International Business Machines Corporation | Management of parking spaces |
US10325497B2 (en) | 2017-09-21 | 2019-06-18 | The Parking Genius, Inc. | Parking sensors capable of determining direction and speed of vehicle entering or leaving a parking lot using magnetic signature recognition |
US10446024B2 (en) | 2017-09-21 | 2019-10-15 | The Parking Genius, Inc. | Parking sensors capable of determining direction and speed of vehicle entering or leaving a parking lot |
US10474904B1 (en) * | 2017-09-30 | 2019-11-12 | Alarm.Com Incorporated | System and method for parking a vehicle in a camera's field of view |
US11482006B2 (en) * | 2017-10-02 | 2022-10-25 | Wisesight Technologies Ltd. | System of monitoring vehicles in a parking arena |
CN113269901B (en) * | 2017-10-19 | 2023-07-04 | 西安艾润物联网技术服务有限责任公司 | Parking lot control method, system and computer readable storage medium |
US10885367B2 (en) | 2017-10-26 | 2021-01-05 | Municipal Parking Services, Inc. | Device, method and system for detecting parking in a no parking area |
CN107833464B (en) * | 2017-10-30 | 2020-09-18 | 清华大学 | Driving behavior safety assessment method and storage medium |
US10830597B2 (en) | 2017-11-02 | 2020-11-10 | International Business Machines Corporation | Smart city crosswalk and traffic navigation system |
US10522030B2 (en) * | 2017-11-03 | 2019-12-31 | Lorren Travis Taylor | System and method for automatically transmitting floorplan |
CN110769773A (en) * | 2017-11-16 | 2020-02-07 | 直观外科手术操作公司 | Master/slave registration and control for remote operation |
CN107945566A (en) * | 2017-11-17 | 2018-04-20 | 张慧 | Curb parking management system and method based on multiple target tracking and deep learning |
JP7056098B2 (en) * | 2017-11-28 | 2022-04-19 | トヨタ自動車株式会社 | Guidance system |
US10371537B1 (en) | 2017-11-29 | 2019-08-06 | Palantir Technologies Inc. | Systems and methods for flexible route planning |
CN109859260B (en) * | 2017-11-30 | 2021-02-12 | 华为技术有限公司 | Method and device for determining parking position and computer readable storage medium |
CN107945292A (en) * | 2017-12-05 | 2018-04-20 | 赛拓信息技术有限公司 | Automobile management system |
US11599706B1 (en) | 2017-12-06 | 2023-03-07 | Palantir Technologies Inc. | Systems and methods for providing a view of geospatial information |
US11538257B2 (en) | 2017-12-08 | 2022-12-27 | Gatekeeper Inc. | Detection, counting and identification of occupants in vehicles |
US10698756B1 (en) | 2017-12-15 | 2020-06-30 | Palantir Technologies Inc. | Linking related events for various devices and services in computer log files on a centralized server |
CN108038923B (en) * | 2017-12-27 | 2020-08-07 | 深圳市小猫信息技术有限公司 | Vehicle exit control method and device |
CN108242084A (en) * | 2017-12-28 | 2018-07-03 | 深圳市金溢科技股份有限公司 | A kind of parking fee payment method, server and mobile terminal |
WO2019132852A1 (en) * | 2017-12-29 | 2019-07-04 | Олэг Лэонидовыч ДЫВИНЭЦЬ | Smart camera, information system and method of identifying free parking places in parking facilities having such a camera |
CN108205928A (en) * | 2018-01-01 | 2018-06-26 | 智慧互通科技有限公司 | Apparatus system and method based on the parking of image, electronic license plate and sensor management |
US11073838B2 (en) | 2018-01-06 | 2021-07-27 | Drivent Llc | Self-driving vehicle systems and methods |
CN108335481B (en) * | 2018-01-10 | 2020-10-16 | 佛山科学技术学院 | Shared bicycle designated area parking system and control method |
US10539957B2 (en) | 2018-01-11 | 2020-01-21 | Honda Motor Co., Ltd. | Methods and systems for enabling a vehicle to park remotely |
US10713518B2 (en) * | 2018-01-29 | 2020-07-14 | Toyota Motor Engineering & Manufacturing North America, Inc. | System and method for recording and reporting license number violation |
CN108331397A (en) * | 2018-02-02 | 2018-07-27 | 浙江德清华杨科技有限公司 | A kind of stereo-parking system and method with fire alarm function |
JP7150447B2 (en) * | 2018-02-28 | 2022-10-11 | 株式会社小松製作所 | Information presentation device and information presentation method |
US11599369B1 (en) | 2018-03-08 | 2023-03-07 | Palantir Technologies Inc. | Graphical user interface configuration system |
CN108305466B (en) * | 2018-03-13 | 2020-05-08 | 北京智芯原动科技有限公司 | Roadside parking detection method and device based on vehicle characteristic analysis |
US11206375B2 (en) | 2018-03-28 | 2021-12-21 | Gal Zuckerman | Analyzing past events by utilizing imagery data captured by a plurality of on-road vehicles |
US10896234B2 (en) | 2018-03-29 | 2021-01-19 | Palantir Technologies Inc. | Interactive geographical map |
US10830599B2 (en) | 2018-04-03 | 2020-11-10 | Palantir Technologies Inc. | Systems and methods for alternative projections of geographical information |
US11585672B1 (en) | 2018-04-11 | 2023-02-21 | Palantir Technologies Inc. | Three-dimensional representations of routes |
US11468503B2 (en) | 2018-04-16 | 2022-10-11 | Bird Rides, Inc. | On-demand rental of electric vehicles |
US10754822B1 (en) | 2018-04-18 | 2020-08-25 | Palantir Technologies Inc. | Systems and methods for ontology migration |
US11215981B2 (en) | 2018-04-20 | 2022-01-04 | Bird Rides, Inc. | Remotely controlling use of an on-demand electric vehicle |
US10909826B1 (en) * | 2018-05-01 | 2021-02-02 | Amazon Technologies, Inc. | Suppression of video streaming based on trajectory data |
US10885021B1 (en) | 2018-05-02 | 2021-01-05 | Palantir Technologies Inc. | Interactive interpreter and graphical user interface |
TWI779029B (en) * | 2018-05-04 | 2022-10-01 | 大猩猩科技股份有限公司 | A distributed object tracking system |
US20190340841A1 (en) * | 2018-05-07 | 2019-11-07 | Simplypark Ltd. | Computing system for defining and providing access to a parking area |
US11887479B2 (en) * | 2018-05-23 | 2024-01-30 | Hitachi Astemo, Ltd. | Parking management system, vehicle control device, and control center |
CN110533950A (en) * | 2018-05-25 | 2019-12-03 | 杭州海康威视数字技术股份有限公司 | Detection method, device, electronic equipment and the storage medium of parking stall behaviour in service |
US10429197B1 (en) | 2018-05-29 | 2019-10-01 | Palantir Technologies Inc. | Terrain analysis for automatic route determination |
JP2019207618A (en) * | 2018-05-30 | 2019-12-05 | 日本電気株式会社 | Information processing system |
CN109345861A (en) * | 2018-05-31 | 2019-02-15 | 亿航智能设备(广州)有限公司 | Unmanned plane dispatching method, unmanned plane and unmanned plane cluster |
US20190385449A1 (en) | 2018-06-13 | 2019-12-19 | Christos Pateropoulos | System and method for providing automatic on-street parking control and unoccupied parking spot availability detection |
US11119630B1 (en) | 2018-06-19 | 2021-09-14 | Palantir Technologies Inc. | Artificial intelligence assisted evaluations and user interface for same |
US10824146B2 (en) * | 2018-06-29 | 2020-11-03 | Ford Global Technologies, Llc | Handling rider service at autonomous vehicles |
CN108922178B (en) * | 2018-07-01 | 2020-05-01 | 北京工业大学 | Public transport vehicle real-time full load rate calculation method based on public transport multi-source data |
JP7006527B2 (en) * | 2018-07-09 | 2022-01-24 | トヨタ自動車株式会社 | In-vehicle equipment and vehicle search system |
US10909866B2 (en) * | 2018-07-20 | 2021-02-02 | Cybernet Systems Corp. | Autonomous transportation system and methods |
US11044588B2 (en) | 2018-07-23 | 2021-06-22 | International Business Machines Corporation | System and method for collaborative caching |
CN109226967B (en) * | 2018-07-25 | 2021-03-09 | 同高先进制造科技(太仓)有限公司 | Active laser vision steady weld joint tracking system for laser-arc hybrid welding |
CN109086708A (en) * | 2018-07-25 | 2018-12-25 | 深圳大学 | A kind of parking space detection method and system based on deep learning |
US11138418B2 (en) | 2018-08-06 | 2021-10-05 | Gal Zuckerman | Systems and methods for tracking persons by utilizing imagery data captured by on-road vehicles |
JP2020027418A (en) * | 2018-08-10 | 2020-02-20 | トヨタ自動車株式会社 | Mobile body, control method, and program |
US11263690B2 (en) | 2018-08-20 | 2022-03-01 | Bird Rides, Inc. | On-demand rental of electric vehicles |
KR102511260B1 (en) * | 2018-08-21 | 2023-03-21 | 엘지전자 주식회사 | Vehicle user interface device and service information provision system |
US11294949B2 (en) | 2018-09-04 | 2022-04-05 | Toyota Connected North America, Inc. | Systems and methods for querying a distributed inventory of visual data |
EP3624067B1 (en) * | 2018-09-14 | 2020-12-30 | Kapsch TrafficCom AG | Tolling station for tolling vehicles of different classes |
US10493952B1 (en) | 2019-03-21 | 2019-12-03 | Drivent Llc | Self-driving vehicle systems and methods |
US10479319B1 (en) | 2019-03-21 | 2019-11-19 | Drivent Llc | Self-driving vehicle systems and methods |
TWI667631B (en) * | 2018-09-26 | 2019-08-01 | 閤美企業股份有限公司 | Parking lot management system and implementing method thereof for curb parking |
JP7169832B2 (en) * | 2018-09-27 | 2022-11-11 | 株式会社Subaru | MOBILE OBJECT MONITORING DEVICE FOR VEHICLE AND VEHICLE CONTROL SYSTEM USING THE SAME |
US11221622B2 (en) | 2019-03-21 | 2022-01-11 | Drivent Llc | Self-driving vehicle systems and methods |
US10832569B2 (en) | 2019-04-02 | 2020-11-10 | Drivent Llc | Vehicle detection systems |
US11644833B2 (en) | 2018-10-01 | 2023-05-09 | Drivent Llc | Self-driving vehicle systems and methods |
US10794714B2 (en) | 2018-10-01 | 2020-10-06 | Drivent Llc | Self-driving vehicle systems and methods |
CN112136309B (en) * | 2018-10-09 | 2022-10-11 | 谷歌有限责任公司 | System and method for performing rewind operations with a mobile image capture device |
JP7218535B2 (en) * | 2018-10-12 | 2023-02-07 | トヨタ自動車株式会社 | Traffic violation vehicle identification system and server |
US10467435B1 (en) | 2018-10-24 | 2019-11-05 | Palantir Technologies Inc. | Approaches for managing restrictions for middleware applications |
CN109377768B (en) * | 2018-10-24 | 2021-10-12 | 成都臻识科技发展有限公司 | Parking detection method and system for roadside parking |
US11025672B2 (en) | 2018-10-25 | 2021-06-01 | Palantir Technologies Inc. | Approaches for securing middleware data access |
US10474154B1 (en) * | 2018-11-01 | 2019-11-12 | Drivent Llc | Self-driving vehicle systems and methods |
CN111161542B (en) * | 2018-11-08 | 2021-09-28 | 杭州海康威视数字技术股份有限公司 | Vehicle identification method and device |
US11062601B2 (en) * | 2018-11-23 | 2021-07-13 | Blackberry Limited | Systems and methods of vehicle detection within a vehicle parking facility |
CN109327684A (en) * | 2018-11-23 | 2019-02-12 | 智慧互通科技有限公司 | A kind of management system of the Roadside Parking based on camera matrix |
CN109525810A (en) * | 2018-11-23 | 2019-03-26 | 广州路派电子科技有限公司 | A kind of high definition dynamic 3D interactive mode panoramic looking-around system |
CN109711264B (en) * | 2018-11-30 | 2020-12-18 | 武汉烽火众智智慧之星科技有限公司 | Method and device for detecting occupation of bus lane |
CN109345154A (en) * | 2018-12-04 | 2019-02-15 | 山东科技大学 | A kind of intersection time and space utilization efficiency rating method |
CN109584607A (en) * | 2018-12-07 | 2019-04-05 | 东软睿驰汽车技术(沈阳)有限公司 | A kind of method and system of parking lot automatic parking |
CN109767626B (en) * | 2018-12-20 | 2021-03-16 | 北京筑梦园科技有限公司 | Roadside parking inspection method and system, patrol car and server |
CN109509368A (en) * | 2018-12-21 | 2019-03-22 | 深圳信路通智能技术有限公司 | A kind of parking behavior algorithm based on roof model |
CN109493635A (en) * | 2018-12-26 | 2019-03-19 | 北京筑梦园科技有限公司 | A kind of parking lot management method, storage medium, server and system |
US10990815B2 (en) | 2018-12-27 | 2021-04-27 | Beijing Didi Infinity Technology And Development Co., Ltd. | Image pre-processing in a lane marking determination system |
US11087173B2 (en) | 2018-12-27 | 2021-08-10 | Beijing Didi Infinity Technology And Development Co., Ltd. | Using image pre-processing to generate a machine learning model |
WO2020139357A1 (en) * | 2018-12-27 | 2020-07-02 | Didi Research America, Llc | Using image pre-processing to generate a machine learning model |
US11023745B2 (en) * | 2018-12-27 | 2021-06-01 | Beijing Didi Infinity Technology And Development Co., Ltd. | System for automated lane marking |
US11816709B2 (en) * | 2018-12-28 | 2023-11-14 | Pied Parker, Inc. | Image-based parking recognition and navigation |
CN109727458B (en) * | 2018-12-28 | 2021-05-18 | 武汉无线飞翔科技有限公司 | Method for realizing interval parking charging through dynamic and static traffic linkage |
US10726718B1 (en) * | 2019-01-04 | 2020-07-28 | Auto Park Hawaii, Inc. | Method for managing vehicle parking within a parking structure |
CN111462502B (en) * | 2019-01-22 | 2021-06-08 | 杭州海康威视数字技术股份有限公司 | Method, device and computer readable storage medium for vehicle management |
US10991251B2 (en) | 2019-01-29 | 2021-04-27 | Toyota Motor Engineering & Manufacturing North America, Inc. | Parking meter monitoring and payment system |
US11355011B1 (en) | 2019-01-31 | 2022-06-07 | United Services Automobile Association (Usaa) | Autonomous vehicle convergence avoidance systems and methods |
JP7192541B2 (en) * | 2019-02-01 | 2022-12-20 | トヨタ自動車株式会社 | Information processing device, information processing method and program |
CN109949231B (en) * | 2019-02-02 | 2021-05-14 | 浙江工业大学 | Method and device for collecting and processing city management information |
US10744976B1 (en) | 2019-02-04 | 2020-08-18 | Drivent Llc | Self-driving vehicle systems and methods |
US10723281B1 (en) * | 2019-03-21 | 2020-07-28 | Lyft, Inc. | Calibration of vehicle sensor array alignment |
FR3094298B1 (en) * | 2019-03-25 | 2021-09-03 | Renault Sas | Method of assisting the parking of a motor vehicle in a parking lot |
CN110008298B (en) * | 2019-03-28 | 2022-03-15 | 武汉星视源科技有限公司 | Parking multidimensional information perception application system and method |
KR20210149722A (en) | 2019-04-08 | 2021-12-09 | 가부시키가이샤 유야마 세이사쿠쇼 | Drug dispensing system, drug dispensing program |
US10796567B1 (en) * | 2019-04-17 | 2020-10-06 | Capital One Services, Llc | Vehicle identification based on machine-readable optical marker |
WO2020223577A1 (en) | 2019-04-30 | 2020-11-05 | Pied Parker, Inc. | Image-based parking recognition and navigation |
CN110021172A (en) * | 2019-05-06 | 2019-07-16 | 北京英泰智科技股份有限公司 | A kind of vehicle total factor method for collecting characteristics and system |
CN110189113A (en) * | 2019-05-27 | 2019-08-30 | 深圳六滴科技有限公司 | Self-service panoramic picture camera system based on user terminal and third-party application |
CN110348883A (en) * | 2019-06-19 | 2019-10-18 | 深圳市顺易通信息科技有限公司 | A kind of recommended method and equipment of noninductive payment scheme of stopping |
CN110211420B (en) * | 2019-06-25 | 2021-11-30 | 重庆长安汽车股份有限公司 | Method and system for judging whether current scene is parking lot or not and computer readable storage medium |
US10867193B1 (en) | 2019-07-10 | 2020-12-15 | Gatekeeper Security, Inc. | Imaging systems for facial detection, license plate reading, vehicle overview and vehicle make, model, and color detection |
CN110503730B (en) * | 2019-07-10 | 2022-09-30 | 西安艾润物联网技术服务有限责任公司 | Parking charging method and device |
CN110556018A (en) * | 2019-07-12 | 2019-12-10 | 天津易华录信息技术有限公司 | Parking management system and parking management method based on video monitoring |
CN110491157B (en) * | 2019-07-23 | 2022-01-25 | 中山大学 | Vehicle association method based on parking lot data and checkpoint data |
US11853863B2 (en) | 2019-08-12 | 2023-12-26 | Micron Technology, Inc. | Predictive maintenance of automotive tires |
US11586943B2 (en) | 2019-08-12 | 2023-02-21 | Micron Technology, Inc. | Storage and access of neural network inputs in automotive predictive maintenance |
US11586194B2 (en) | 2019-08-12 | 2023-02-21 | Micron Technology, Inc. | Storage and access of neural network models of automotive predictive maintenance |
US11775816B2 (en) | 2019-08-12 | 2023-10-03 | Micron Technology, Inc. | Storage and access of neural network outputs in automotive predictive maintenance |
US11635893B2 (en) | 2019-08-12 | 2023-04-25 | Micron Technology, Inc. | Communications between processors and storage devices in automotive predictive maintenance implemented via artificial neural networks |
US11748626B2 (en) | 2019-08-12 | 2023-09-05 | Micron Technology, Inc. | Storage devices with neural network accelerators for automotive predictive maintenance |
CN110418114B (en) | 2019-08-20 | 2021-11-16 | 京东方科技集团股份有限公司 | Object tracking method and device, electronic equipment and storage medium |
US11361552B2 (en) * | 2019-08-21 | 2022-06-14 | Micron Technology, Inc. | Security operations of parked vehicles |
US11042350B2 (en) | 2019-08-21 | 2021-06-22 | Micron Technology, Inc. | Intelligent audio control in vehicles |
CN110444007A (en) * | 2019-08-21 | 2019-11-12 | 深圳市合隆智慧城市服务有限公司 | Smart city cloud service garbage truck integrated control platform |
US11702086B2 (en) | 2019-08-21 | 2023-07-18 | Micron Technology, Inc. | Intelligent recording of errant vehicle behaviors |
US11498388B2 (en) | 2019-08-21 | 2022-11-15 | Micron Technology, Inc. | Intelligent climate control in vehicles |
US10993647B2 (en) | 2019-08-21 | 2021-05-04 | Micron Technology, Inc. | Drowsiness detection for vehicle control |
US11693562B2 (en) | 2019-09-05 | 2023-07-04 | Micron Technology, Inc. | Bandwidth optimization for different types of operations scheduled in a data storage device |
US11650746B2 (en) | 2019-09-05 | 2023-05-16 | Micron Technology, Inc. | Intelligent write-amplification reduction for data storage devices configured on autonomous vehicles |
US11409654B2 (en) | 2019-09-05 | 2022-08-09 | Micron Technology, Inc. | Intelligent optimization of caching operations in a data storage device |
US11436076B2 (en) | 2019-09-05 | 2022-09-06 | Micron Technology, Inc. | Predictive management of failing portions in a data storage device |
US11435946B2 (en) | 2019-09-05 | 2022-09-06 | Micron Technology, Inc. | Intelligent wear leveling with reduced write-amplification for data storage devices configured on autonomous vehicles |
CN112468681B (en) | 2019-09-06 | 2022-02-15 | 杭州海康威视数字技术股份有限公司 | Camera device for collecting vehicle information |
JP7176496B2 (en) * | 2019-09-17 | 2022-11-22 | トヨタ自動車株式会社 | vehicle photography system |
US11295148B2 (en) * | 2019-09-24 | 2022-04-05 | Ford Global Technologies, Llc | Systems and methods of preventing removal of items from vehicles by improper parties |
US11276307B2 (en) | 2019-09-24 | 2022-03-15 | International Business Machines Corporation | Optimized vehicle parking |
CN112579658B (en) * | 2019-09-27 | 2023-04-18 | 深圳市赛格车圣智联科技有限公司 | Method for analyzing daytime and nighttime of vehicle in multi-process manner |
JP7238722B2 (en) * | 2019-10-11 | 2023-03-14 | トヨタ自動車株式会社 | vehicle parking assist device |
WO2021079636A1 (en) * | 2019-10-21 | 2021-04-29 | ソニー株式会社 | Display control device, display control method and recording medium |
US11196965B2 (en) | 2019-10-25 | 2021-12-07 | Gatekeeper Security, Inc. | Image artifact mitigation in scanners for entry control systems |
WO2021086884A1 (en) * | 2019-10-29 | 2021-05-06 | Flownetworx, Inc. | System, apparatus and method of provisioning allotments utilizing machine visioning |
CN110766812B (en) * | 2019-10-31 | 2020-11-10 | 广东科学技术职业学院 | Riding payment method and device for unmanned automobile and electronic equipment |
RU2749941C2 (en) * | 2019-11-01 | 2021-06-21 | Юрий Владимирович Горюнов | Universal way to photograph traffic violations |
CN110930750A (en) * | 2019-11-15 | 2020-03-27 | 苏州浪潮智能科技有限公司 | Intelligent park personnel management method and system based on cloud platform |
DE102019130957A1 (en) * | 2019-11-15 | 2021-05-20 | Parkhere Gmbh | Parking management system |
CN111081047A (en) * | 2019-12-10 | 2020-04-28 | 重庆邮电大学 | Accurate intelligent parking management method and management system based on photoelectric image processing |
US11250648B2 (en) | 2019-12-18 | 2022-02-15 | Micron Technology, Inc. | Predictive maintenance of automotive transmission |
CN111275978B (en) * | 2019-12-23 | 2021-08-20 | 江西山水光电科技股份有限公司 | Roadside parking vehicle real-time acquisition management system and management method |
TWI760678B (en) * | 2020-01-16 | 2022-04-11 | 國立虎尾科技大學 | Smart curb parking meter, management system and payment method |
US11285967B2 (en) * | 2020-02-13 | 2022-03-29 | Toyota Motor Engineering & Manufacturing North America, Inc. | System and method for modifying actions taken by an autonomous vehicle |
US11531339B2 (en) | 2020-02-14 | 2022-12-20 | Micron Technology, Inc. | Monitoring of drive by wire sensors in vehicles |
US11709625B2 (en) | 2020-02-14 | 2023-07-25 | Micron Technology, Inc. | Optimization of power usage of data storage devices |
US11713047B2 (en) * | 2020-02-21 | 2023-08-01 | Calamp Corp. | Technologies for driver behavior assessment |
US11593951B2 (en) * | 2020-02-25 | 2023-02-28 | Qualcomm Incorporated | Multi-device object tracking and localization |
CN111414806A (en) * | 2020-02-27 | 2020-07-14 | 贵州智诚科技有限公司 | Real-time supervision and searching method for case-involved vehicles of public security traffic control department |
IL295639A (en) | 2020-03-02 | 2022-10-01 | Neutron Holdings Inc Dba Lime | Artificial intelligence based real time vehicle parking verification |
WO2021183993A1 (en) * | 2020-03-13 | 2021-09-16 | Arizona Board Of Regents On Behalf Of Arizona State University | Vision-aided wireless communication systems |
CN111383462A (en) * | 2020-03-19 | 2020-07-07 | 天津职业技术师范大学(中国职业培训指导教师进修中心) | New traffic accident scene video speed measurement method based on four-point plane homography |
CN111405203B (en) * | 2020-03-30 | 2022-11-04 | 杭州海康威视数字技术股份有限公司 | Method and device for determining picture switching, electronic equipment and storage medium |
CN111488835B (en) * | 2020-04-13 | 2023-10-10 | 北京爱笔科技有限公司 | Identification method and device for staff |
CN111427359A (en) * | 2020-04-17 | 2020-07-17 | 筑石科技(湖州)有限公司 | Travel control method and travel control device for construction equipment |
CN111767938B (en) * | 2020-05-09 | 2023-12-19 | 北京奇艺世纪科技有限公司 | Abnormal data detection method and device and electronic equipment |
TWM610111U (en) * | 2020-05-13 | 2021-04-11 | 奇異平台股份有限公司 | Roadside parking management system |
US11210949B1 (en) | 2020-06-08 | 2021-12-28 | Toyota Motor Engineering & Manufacturing North America, Inc. | Meter time notification of other vehicles to driver |
EP4172960A4 (en) * | 2020-06-25 | 2024-07-17 | Innovative Signal Analysis Inc | Multi-source 3-dimensional detection and tracking |
US11423704B2 (en) * | 2020-07-01 | 2022-08-23 | Sony Corporation | Apparatus for controlling multiple gates through which vehicles travel |
CN112558511A (en) * | 2020-07-20 | 2021-03-26 | 浙江明德微电子股份有限公司 | Intelligent monitoring system for fire fighting access |
TWI762996B (en) * | 2020-08-07 | 2022-05-01 | 國立臺北科技大學 | Working timing system and method thereof |
CN111935281B (en) * | 2020-08-10 | 2023-04-07 | 京东科技信息技术有限公司 | Method and device for monitoring illegal parking |
CN112017475A (en) * | 2020-09-07 | 2020-12-01 | 深圳天海宸光科技有限公司 | Intelligent vehicle searching system and method for parking lot |
EP4195150A4 (en) * | 2020-09-21 | 2024-06-26 | Siemens Ltd., China | Target positioning method and device, and computer-readable medium |
CN112133125A (en) * | 2020-09-23 | 2020-12-25 | 上海软杰智能设备有限公司 | Parking security protection management system |
CN112201064A (en) * | 2020-09-30 | 2021-01-08 | 康京博 | Method and system for monitoring riding behaviors of motorcycle |
CN112201047B (en) * | 2020-10-10 | 2022-02-18 | 武汉中科通达高新技术股份有限公司 | Suspected vehicle foothold analysis method and device based on Flink framework |
US11003919B1 (en) * | 2020-10-16 | 2021-05-11 | Hayden Al Technologies, Inc. | Systems and methods for detecting traffic violations using mobile detection devices |
US20220122452A1 (en) * | 2020-10-16 | 2022-04-21 | Direct Technology Holdings Inc | Venue entry payment system for vehicles |
CN112380933B (en) * | 2020-11-02 | 2023-11-07 | 中国兵器工业计算机应用技术研究所 | Unmanned aerial vehicle target recognition method and device and unmanned aerial vehicle |
US20220138883A1 (en) * | 2020-11-05 | 2022-05-05 | William Pamphile | Automated motor vehicle services and parking tickets |
US11164014B1 (en) * | 2020-11-09 | 2021-11-02 | Hayden Ai Technologies, Inc. | Lane violation detection using convolutional neural networks |
CN112380953B (en) * | 2020-11-10 | 2023-05-09 | 支付宝(杭州)信息技术有限公司 | Communication address calibration method and device for sales counter camera equipment and calibration plate |
JP2022088190A (en) * | 2020-12-02 | 2022-06-14 | トヨタ自動車株式会社 | Information processor, program and information processing method |
US20220180740A1 (en) * | 2020-12-03 | 2022-06-09 | Clancy Systems, Inc. | Camera parking enforcement |
MX2023001144A (en) | 2020-12-15 | 2023-04-14 | Selex Es Inc | Systems and methods for electronic signature tracking. |
CN112767707B (en) * | 2021-01-11 | 2023-10-31 | 深圳智优停科技有限公司 | Parking stall inductor and parking stall response shooting system |
US11807188B2 (en) * | 2021-01-14 | 2023-11-07 | Toyota Motor Engineering & Manufacturing North America, Inc. | Methods and systems for controlling image capture sessions with external devices |
WO2022203757A1 (en) * | 2021-03-26 | 2022-09-29 | Gatekeeper Security, Inc. | System and methods for monitoring and determining operational efficiency of a surveillance system |
US11804121B2 (en) * | 2021-04-01 | 2023-10-31 | Lenovo (Singapore) Pte. Ltd. | Human presence detector device |
CN113284261B (en) * | 2021-04-02 | 2023-07-14 | 北京通通易联科技有限公司 | Vehicle pre-release method based on edge storage |
CN113763700B (en) * | 2021-04-26 | 2022-09-20 | 腾讯云计算(北京)有限责任公司 | Information processing method, information processing device, computer equipment and storage medium |
CA3162192A1 (en) * | 2021-06-11 | 2022-12-11 | Citifyd, Inc. | Eliminating use of a mobile printing device in issuing a record of transaction activity information |
DE102021117613A1 (en) * | 2021-07-08 | 2023-01-12 | Valeo Schalter Und Sensoren Gmbh | METHOD OF OPERATING A PARKING ASSISTANCE SYSTEM, COMPUTER PROGRAM PRODUCT AND PARKING ASSISTANCE SYSTEM |
CN113657378B (en) * | 2021-07-28 | 2024-04-26 | 讯飞智元信息科技有限公司 | Vehicle tracking method, vehicle tracking system and computing device |
AU2021106912A4 (en) * | 2021-08-10 | 2021-11-25 | Sensen Networks Group Pty Ltd | Systems and methods for monitoring urban areas |
CN113936497B (en) * | 2021-09-15 | 2024-02-20 | 上海康裕企业管理咨询有限公司 | Park industry communication system based on block chain service |
CN113920775B (en) * | 2021-10-13 | 2023-11-14 | 天津新泰基业电子股份有限公司 | Intelligent parking management operation method and system |
US11928963B2 (en) * | 2021-11-08 | 2024-03-12 | Honeywell International Inc. | System and method for tracking egress times from a parking facility and providing action recommendations |
CN114267180B (en) * | 2022-03-03 | 2022-05-31 | 科大天工智能装备技术(天津)有限公司 | Parking management method and system based on computer vision |
CN114627565B (en) * | 2022-03-31 | 2022-12-27 | 山东晟昌智能科技有限公司 | Intelligent parking charging management system based on artificial intelligence |
CN115050193B (en) * | 2022-05-07 | 2023-12-15 | 北京卓视智通科技有限责任公司 | Vehicle speed measurement method and system based on road monitoring video image |
WO2024022863A1 (en) * | 2022-07-28 | 2024-02-01 | L'air Liquide, Societe Anonyme Pour L'etude Et L'exploitation Des Procedes Georges Claude | Method and installation for counting objects in a moving vehicle |
WO2024039300A1 (en) * | 2022-08-19 | 2024-02-22 | Grabtaxi Holdings Pte. Ltd. | Location-specific image collection |
US11715305B1 (en) | 2022-11-30 | 2023-08-01 | Amitha Nandini Mandava | Traffic detection system using machine vision |
US11735042B1 (en) * | 2023-03-14 | 2023-08-22 | Pathfins C. Okezie | Traffic watch, monitor, and accident prevention device |
US11869357B1 (en) | 2023-06-14 | 2024-01-09 | Pathfins C. Okezie | Method and apparatus for expanded traffic watch |
CN116561602B (en) * | 2023-07-10 | 2023-09-19 | 三峡高科信息技术有限责任公司 | Automatic sales material matching method for sales cost transfer |
CN116958908B (en) * | 2023-09-19 | 2023-12-15 | 坤前计算机有限公司 | Monitoring data processing method and system |
Family Cites Families (119)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5173692A (en) | 1990-08-13 | 1992-12-22 | Ai Computer Services, Inc. | System and method of vehicle detection |
US5351187A (en) | 1992-12-30 | 1994-09-27 | At/Comm Incorporated | Automatic debiting parking meter system |
SE502679C2 (en) * | 1993-05-28 | 1995-12-04 | Saab Scania Combitech Ab | Method and apparatus for recording the movement of a vehicle on a ground |
US5948038A (en) | 1996-07-31 | 1999-09-07 | American Traffic Systems, Inc. | Traffic violation processing system |
US7014355B2 (en) * | 1996-10-02 | 2006-03-21 | Innovapark Company Llc | Electronic parking meter system |
GB2330471A (en) | 1997-10-15 | 1999-04-21 | Secr Defence | Production of moving images for holography |
WO2000031707A1 (en) | 1998-11-23 | 2000-06-02 | Nestor, Inc. | Non-violation event filtering for a traffic light violation detection system |
US6437819B1 (en) * | 1999-06-25 | 2002-08-20 | Rohan Christopher Loveland | Automated video person tracking system |
CN100533482C (en) | 1999-11-03 | 2009-08-26 | 特许科技有限公司 | Image processing techniques for a video based traffic monitoring system and methods therefor |
US6747687B1 (en) * | 2000-01-11 | 2004-06-08 | Pulnix America, Inc. | System for recognizing the same vehicle at different times and places |
US7123166B1 (en) | 2000-11-17 | 2006-10-17 | Haynes Michael N | Method for managing a parking lot |
AU2395302A (en) | 2000-05-09 | 2002-02-05 | Metervision.Com Inc | Parking payment system |
NL1016553C2 (en) * | 2000-11-07 | 2002-05-14 | Loyalty Unltd Bvba | Parking management system for managing covered or uncovered parking. |
DE60218982T2 (en) * | 2001-01-26 | 2007-12-06 | Raytheon Company, Waltham | SYSTEM AND METHOD FOR READING A NUMBER PLATE |
WO2003029046A1 (en) | 2001-10-03 | 2003-04-10 | Maryann Winter | Apparatus and method for sensing the occupancy status of parking spaces in a parking lot |
US20030128136A1 (en) * | 2002-01-07 | 2003-07-10 | Macropark, Inc. | Electronic parking meter having audio-video communications with a central station |
EP1472869A4 (en) | 2002-02-06 | 2008-07-30 | Nice Systems Ltd | System and method for video content analysis-based detection, surveillance and alarm management |
US7436887B2 (en) | 2002-02-06 | 2008-10-14 | Playtex Products, Inc. | Method and apparatus for video frame sequence-based object tracking |
US7016518B2 (en) | 2002-03-15 | 2006-03-21 | Extreme Cctv Inc. | Vehicle license plate imaging and reading system for day and night |
AU2003280516A1 (en) | 2002-07-01 | 2004-01-19 | The Regents Of The University Of California | Digital processing of video images |
US7382277B2 (en) | 2003-02-12 | 2008-06-03 | Edward D. Ioli Trust | System for tracking suspicious vehicular activity |
US20040167861A1 (en) | 2003-02-21 | 2004-08-26 | Hedley Jay E. | Electronic toll management |
KR20060007048A (en) | 2003-05-07 | 2006-01-23 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | Traffic information system for conveying information to drivers |
CA2526551C (en) | 2003-05-22 | 2010-04-13 | Alan Sefton | Automated site security, monitoring and access control system |
JP2007504551A (en) * | 2003-09-03 | 2007-03-01 | ストラテック システムズ リミテッド | Apparatus and method for locating, recognizing and tracking a vehicle in a parking lot |
US7248149B2 (en) | 2003-10-06 | 2007-07-24 | California Institute Of Technology | Detection and enforcement of failure-to-yield in an emergency vehicle preemption system |
JP4738778B2 (en) * | 2003-10-15 | 2011-08-03 | 富士通テン株式会社 | Image processing device, driving support device, and driving support system |
US20050111699A1 (en) | 2003-11-24 | 2005-05-26 | Emil Gran | Suite of parking regulation control systems |
US7104447B1 (en) | 2003-12-15 | 2006-09-12 | Anthony Lopez | Parking meters, systems and methods of parking enforcement |
RU2268175C1 (en) * | 2004-04-19 | 2006-01-20 | Общество с ограниченной ответственностью "ДжиПиЭс-Питер" | Inspection, navigation and monitoring system for mobile objects |
US7466223B2 (en) * | 2004-05-21 | 2008-12-16 | Pips Technology, Inc. | Automated site security, monitoring and access control system |
US7950570B2 (en) * | 2004-06-16 | 2011-05-31 | Ipt, Llc | Parking environment management system and method |
EP1779331A4 (en) * | 2004-06-23 | 2009-07-29 | Frederick L Mitschele | Hand-held device for parking meter enforcement |
US7253398B2 (en) | 2004-07-22 | 2007-08-07 | Flir Systems Inc. | Sensor system with improved operator input devices |
WO2006137829A2 (en) | 2004-08-10 | 2006-12-28 | Sarnoff Corporation | Method and system for performing adaptive image acquisition |
US20060098729A1 (en) * | 2004-11-09 | 2006-05-11 | Lien-Chieh Shen | Smart image processing CCTV camera device and method for operating same |
US7845560B2 (en) | 2004-12-14 | 2010-12-07 | Sky-Trax Incorporated | Method and apparatus for determining position and rotational orientation of an object |
US20060152349A1 (en) * | 2005-01-05 | 2006-07-13 | Nitesh Ratnakar | Smart Parking Meter |
US7355527B2 (en) * | 2005-01-10 | 2008-04-08 | William Franklin | System and method for parking infraction detection |
JPWO2006098469A1 (en) | 2005-03-18 | 2008-08-28 | ヤマハ発動機株式会社 | Flight control system |
US10019877B2 (en) | 2005-04-03 | 2018-07-10 | Qognify Ltd. | Apparatus and methods for the semi-automatic tracking and examining of an object or an event in a monitored site |
US7899583B2 (en) | 2005-04-12 | 2011-03-01 | Ehud Mendelson | System and method of detecting and navigating to empty parking spaces |
GB2425385B (en) | 2005-04-18 | 2007-08-01 | Pips Technology Ltd | Vehicle speed monitoring system |
KR20070013719A (en) * | 2005-07-27 | 2007-01-31 | 주식회사 현대오토넷 | Apparatus and method for informing the distance of forward and backward vehicle |
WO2007027945A1 (en) | 2005-08-30 | 2007-03-08 | Sensact Applications, Incorporated | Wireless parking guidance system |
US20120215596A1 (en) | 2005-11-16 | 2012-08-23 | Ipt Llc | System And Method For Permit Enforcement |
KR100796266B1 (en) | 2005-12-02 | 2008-01-21 | 주식회사 비전라이드 | System and method of parking control |
US8626418B2 (en) | 2005-12-15 | 2014-01-07 | International Business Machines Corporation | Method and system for monitoring speed of a vehicle |
US7765062B2 (en) | 2006-04-25 | 2010-07-27 | Honeywell International Inc. | Method and system for autonomous tracking of a mobile target by an unmanned aerial vehicle |
US20090294573A1 (en) | 2006-05-23 | 2009-12-03 | Wilson Samuel B | Dual-Use Modular Propulsion surveillance Vehicle with Detachable Unmanned Airborne Vehicles |
US7973641B1 (en) * | 2006-06-07 | 2011-07-05 | Yuanlin Huang | RFID based parking management system |
US20070294692A1 (en) | 2006-06-16 | 2007-12-20 | Microsoft Corporation | Task Assignment Among Multiple Devices |
GB0613465D0 (en) * | 2006-07-06 | 2006-08-16 | Metric Group Ltd | A method and apparatus for operating a system for monitoring the status of vehicle parking spaces |
GB2441382B (en) | 2006-08-29 | 2009-10-14 | Ranger Services Ltd | Automated parking system |
US7720260B2 (en) | 2006-09-13 | 2010-05-18 | Ford Motor Company | Object detection system and method |
US8139115B2 (en) | 2006-10-30 | 2012-03-20 | International Business Machines Corporation | Method and apparatus for managing parking lots |
US20080114675A1 (en) | 2006-11-10 | 2008-05-15 | Pom Incorporated | Parking Payment System Using a Cell Phone or Other Mobile Device |
KR100699414B1 (en) | 2006-12-21 | 2007-03-23 | 에이치케이이카 주식회사 | System and method for managing record of vehicles |
US7701363B1 (en) | 2007-01-17 | 2010-04-20 | Milan Zlojutro | Vehicle tracking and monitoring system |
US8712105B2 (en) | 2007-04-16 | 2014-04-29 | Redflex Traffic Systems Pty, Ltd. | Vehicle speed verification system and method |
EP2183718A4 (en) | 2007-07-18 | 2010-08-11 | City Of Calgary | System and method for managing parking rights |
US9177210B2 (en) | 2007-10-30 | 2015-11-03 | Hki Systems And Service Llc | Processing container images and identifiers using optical character recognition and geolocation |
US8108055B2 (en) * | 2007-12-28 | 2012-01-31 | Larry Wong | Method, system and apparatus for controlling an electrical device |
US7970507B2 (en) * | 2008-01-23 | 2011-06-28 | Honeywell International Inc. | Method and system for autonomous tracking of a mobile target by an unmanned aerial vehicle |
KR101074279B1 (en) | 2008-03-10 | 2011-10-19 | 주식회사 제이캐스트 | Monitering system using unmanned air vehicle with WiMAX communication |
WO2009121053A2 (en) | 2008-03-28 | 2009-10-01 | On-Net Surveillance Systems, Inc. | Method and systems for video collection and analysis thereof |
US20090280838A1 (en) * | 2008-05-09 | 2009-11-12 | Ajay Malik | Device and Method for Adding Location Data to Images |
GB0813101D0 (en) | 2008-07-17 | 2008-08-27 | Anpr Internat Ltd | Monitoring vehicle use |
US20100057338A1 (en) | 2008-09-04 | 2010-03-04 | International Business Machines Corporation | Method and system for route tracking |
KR20100029985A (en) | 2008-09-09 | 2010-03-18 | 엘지전자 주식회사 | A method of providing information for parking and an apparatus therefor |
US20100117863A1 (en) * | 2008-11-10 | 2010-05-13 | Kane Dutt | Parking system and methods of use and doing business |
TWI405457B (en) | 2008-12-18 | 2013-08-11 | Ind Tech Res Inst | Multi-target tracking system, method and smart node using active camera handoff |
AU2009329831A1 (en) | 2008-12-24 | 2011-07-21 | Vehicle Monitoring Systems Pty Ltd | Method and system for detecting vehicle offences |
US20100201815A1 (en) | 2009-02-09 | 2010-08-12 | Vitamin D, Inc. | Systems and methods for video monitoring |
US20100245125A1 (en) | 2009-03-30 | 2010-09-30 | Lasercraft, Inc. | Systems and Methods For Surveillance and Traffic Monitoring (Claim Set I) |
US8254633B1 (en) | 2009-04-21 | 2012-08-28 | Videomining Corporation | Method and system for finding correspondence between face camera views and behavior camera views |
AU2010201693A1 (en) | 2009-04-28 | 2010-11-11 | Monsive Jr., Michael G | Portable traffic monitoring system and methods for use |
US20100302359A1 (en) * | 2009-06-01 | 2010-12-02 | Honeywell International Inc. | Unmanned Aerial Vehicle Communication |
US20110218940A1 (en) * | 2009-07-28 | 2011-09-08 | Recharge Power Llc | Parking Meter System |
AU2010288152A1 (en) | 2009-08-31 | 2012-02-16 | Parx Ltd | Fully automated parking system |
CA2773132C (en) | 2009-09-04 | 2015-11-03 | Ips Group Inc. | Location-aware advertising to parking location users |
US8749403B2 (en) | 2009-09-04 | 2014-06-10 | Ips Group Inc. | Parking meter communications for remote payment with updated display |
JP5289256B2 (en) | 2009-09-24 | 2013-09-11 | 三菱電機株式会社 | Vehicle position detection system |
JP5634046B2 (en) | 2009-09-25 | 2014-12-03 | クラリオン株式会社 | Sensor controller, navigation device, and sensor control method |
US8511539B2 (en) * | 2009-10-19 | 2013-08-20 | Liberty Plugins, Inc. | Method and apparatus for parking lot metering |
US20120056758A1 (en) | 2009-12-03 | 2012-03-08 | Delphi Technologies, Inc. | Vehicle parking spot locator system and method using connected vehicles |
US20110148662A1 (en) | 2009-12-18 | 2011-06-23 | Daniel Lowenthal | System and method for notification of parking-related information |
US20110267469A1 (en) | 2010-01-28 | 2011-11-03 | American Traffic Solutions, Inc. of Kansas | System and method for overlaying data onto images of a traffic enforcement camera |
US9398231B2 (en) | 2010-03-15 | 2016-07-19 | Omron Corporation | Surveillance camera terminal |
US8356746B2 (en) | 2010-03-24 | 2013-01-22 | Flanagan Frank M | Electronic parking validation |
DE102010019888B4 (en) * | 2010-04-23 | 2017-02-23 | Helmut Jakob | Device for the automatic parking of motor vehicles |
CN102243813B (en) | 2010-05-11 | 2014-09-17 | 岳洋有限公司 | Parking lot guidance system, picking up vehicle guidance method and parking guidance method applying same |
US8063797B1 (en) * | 2010-07-31 | 2011-11-22 | ParkMe LLC | Parking information collection system and method |
US8799037B2 (en) | 2010-10-14 | 2014-08-05 | Palto Alto Research Center Incorporated | Computer-implemented system and method for managing motor vehicle parking reservations |
US9836975B2 (en) | 2010-11-05 | 2017-12-05 | Grid Smarter Cities Limited | System and method for implementing an exception to a parking restriction |
US9460623B2 (en) * | 2010-11-22 | 2016-10-04 | International Business Machines Corporation | Parking management |
US20120143657A1 (en) | 2010-12-03 | 2012-06-07 | Cds Worldwide Pty Ltd | Parking system and method |
US9154747B2 (en) | 2010-12-22 | 2015-10-06 | Pelco, Inc. | Stopped object detection |
US20120162431A1 (en) | 2010-12-23 | 2012-06-28 | Scott Riesebosch | Methods and systems for monitoring traffic flow |
US9058578B2 (en) * | 2010-12-24 | 2015-06-16 | Martin Kelly Jones | Systems and methods for battery remediation in connection with an electric powered mobiel thing (EPMT) |
TWI413025B (en) | 2011-04-26 | 2013-10-21 | Nat Univ Chin Yi Technology | Parking lot management system |
US20120280836A1 (en) * | 2011-05-04 | 2012-11-08 | Federal Signal Corporation | Vehicle Detection System with RFID-Based Location Determination |
US20120287278A1 (en) | 2011-05-15 | 2012-11-15 | Robert Danis | Traffic Violation Photo Enforcement System |
WO2013052863A1 (en) | 2011-10-05 | 2013-04-11 | Radio Systems Corporation | Image-based animal control systems and methods |
US8970701B2 (en) | 2011-10-21 | 2015-03-03 | Mesa Engineering, Inc. | System and method for predicting vehicle location |
US8742948B2 (en) * | 2011-11-14 | 2014-06-03 | Verizon Patent And Licensing Inc. | User-managed parking system |
US8666117B2 (en) | 2012-04-06 | 2014-03-04 | Xerox Corporation | Video-based system and method for detecting exclusion zone infractions |
US8682036B2 (en) * | 2012-04-06 | 2014-03-25 | Xerox Corporation | System and method for street-parking-vehicle identification through license plate capturing |
US20130265419A1 (en) | 2012-04-06 | 2013-10-10 | Xerox Corporation | System and method for available parking space estimation for multispace on-street parking |
US9367966B2 (en) | 2012-04-06 | 2016-06-14 | Xerox Corporation | Smartphone augmented video-based on-street parking management system |
US8737690B2 (en) | 2012-04-06 | 2014-05-27 | Xerox Corporation | Video-based method for parking angle violation detection |
US20130265423A1 (en) | 2012-04-06 | 2013-10-10 | Xerox Corporation | Video-based detector and notifier for short-term parking violation enforcement |
US8744132B2 (en) | 2012-04-06 | 2014-06-03 | Orhan BULAN | Video-based method for detecting parking boundary violations |
US9336238B2 (en) | 2012-06-16 | 2016-05-10 | Evrio, Inc. | Mobile wireless object recognition and control |
US9087415B1 (en) | 2012-07-18 | 2015-07-21 | Kevin W. McLain | System and method for control of a parking facility |
US8830322B2 (en) | 2012-08-06 | 2014-09-09 | Cloudparc, Inc. | Controlling use of a single multi-vehicle parking space and a restricted location within the single multi-vehicle parking space using multiple cameras |
US9858816B2 (en) | 2014-05-21 | 2018-01-02 | Regents Of The University Of Minnesota | Determining parking space occupancy using a 3D representation |
JP6062079B2 (en) * | 2014-05-30 | 2017-01-18 | エスゼット ディージェイアイ テクノロジー カンパニー リミテッドSz Dji Technology Co.,Ltd | Controller and method and vehicle for controlling the operation of an unmanned air transport (UAV) |
CA2993808C (en) * | 2015-07-30 | 2023-10-10 | Mark J. Moran | Virtual parking lots |
-
2012
- 2012-11-27 US US13/686,820 patent/US8830322B2/en active Active
- 2012-11-27 US US13/686,839 patent/US8698896B2/en active Active
- 2012-11-27 US US13/686,802 patent/US8698895B2/en active Active
- 2012-11-27 US US13/686,831 patent/US8836788B2/en active Active
-
2013
- 2013-11-25 BR BR112015011749A patent/BR112015011749A8/en not_active Application Discontinuation
- 2013-11-25 RU RU2015125482A patent/RU2607043C1/en active
-
2014
- 2014-02-23 US US14/187,300 patent/US8982213B2/en active Active
- 2014-02-24 US US14/187,964 patent/US9064414B2/en active Active
- 2014-03-04 US US14/196,201 patent/US8982214B2/en active Active
- 2014-03-13 US US14/209,375 patent/US8982215B2/en active Active
- 2014-03-16 US US14/214,973 patent/US9330303B2/en active Active
- 2014-03-26 US US14/226,193 patent/US8817100B2/en active Active
- 2014-03-28 US US14/229,688 patent/US9064415B2/en active Active
- 2014-04-03 US US14/244,027 patent/US8937660B2/en active Active
- 2014-04-11 US US14/250,597 patent/US9165467B2/en active Active
- 2014-04-11 US US14/251,399 patent/US9390319B2/en active Active
- 2014-04-28 US US14/263,916 patent/US9652666B2/en active Active
- 2014-05-02 US US14/267,981 patent/US8878936B2/en active Active
- 2014-05-15 US US14/279,272 patent/US8830323B1/en active Active
- 2014-05-19 US US14/280,958 patent/US9036027B2/en active Active
-
2015
- 2015-05-13 IL IL238803A patent/IL238803A/en active IP Right Grant
- 2015-05-27 SA SA515360480A patent/SA515360480B1/en unknown
- 2015-09-09 US US14/848,335 patent/US9208619B1/en active Active
- 2015-09-16 US US14/856,484 patent/US9607214B2/en active Active
- 2015-11-17 US US14/943,025 patent/US20160078299A1/en not_active Abandoned
-
2021
- 2021-01-12 US US17/147,016 patent/US20210279451A1/en active Pending
Cited By (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150356469A1 (en) * | 2013-01-23 | 2015-12-10 | Ying-Tsun Su | System and method for management parking spaces |
US20150127222A1 (en) * | 2013-11-06 | 2015-05-07 | Frazier Cunningham, III | Parking signaling system |
US9333908B2 (en) * | 2013-11-06 | 2016-05-10 | Frazier Cunningham, III | Parking signaling system |
US10192114B2 (en) | 2014-06-27 | 2019-01-29 | Blinker, Inc. | Method and apparatus for obtaining a vehicle history report from an image |
US9607236B1 (en) | 2014-06-27 | 2017-03-28 | Blinker, Inc. | Method and apparatus for providing loan verification from an image |
US10210416B2 (en) | 2014-06-27 | 2019-02-19 | Blinker, Inc. | Method and apparatus for receiving a broadcast radio service offer from an image |
US9589202B1 (en) | 2014-06-27 | 2017-03-07 | Blinker, Inc. | Method and apparatus for receiving an insurance quote from an image |
US9589201B1 (en) | 2014-06-27 | 2017-03-07 | Blinker, Inc. | Method and apparatus for recovering a vehicle value from an image |
US9594971B1 (en) | 2014-06-27 | 2017-03-14 | Blinker, Inc. | Method and apparatus for receiving listings of similar vehicles from an image |
US9600733B1 (en) | 2014-06-27 | 2017-03-21 | Blinker, Inc. | Method and apparatus for receiving car parts data from an image |
US10210417B2 (en) | 2014-06-27 | 2019-02-19 | Blinker, Inc. | Method and apparatus for receiving a refinancing offer from an image |
US9754171B1 (en) | 2014-06-27 | 2017-09-05 | Blinker, Inc. | Method and apparatus for receiving vehicle information from an image and posting the vehicle information to a website |
US9760776B1 (en) | 2014-06-27 | 2017-09-12 | Blinker, Inc. | Method and apparatus for obtaining a vehicle history report from an image |
US9773184B1 (en) | 2014-06-27 | 2017-09-26 | Blinker, Inc. | Method and apparatus for receiving a broadcast radio service offer from an image |
US9779318B1 (en) | 2014-06-27 | 2017-10-03 | Blinker, Inc. | Method and apparatus for verifying vehicle ownership from an image |
US10204282B2 (en) | 2014-06-27 | 2019-02-12 | Blinker, Inc. | Method and apparatus for verifying vehicle ownership from an image |
US9892337B1 (en) | 2014-06-27 | 2018-02-13 | Blinker, Inc. | Method and apparatus for receiving a refinancing offer from an image |
US10163025B2 (en) | 2014-06-27 | 2018-12-25 | Blinker, Inc. | Method and apparatus for receiving a location of a vehicle service center from an image |
US10163026B2 (en) | 2014-06-27 | 2018-12-25 | Blinker, Inc. | Method and apparatus for recovering a vehicle identification number from an image |
US10169675B2 (en) | 2014-06-27 | 2019-01-01 | Blinker, Inc. | Method and apparatus for receiving listings of similar vehicles from an image |
US10176531B2 (en) | 2014-06-27 | 2019-01-08 | Blinker, Inc. | Method and apparatus for receiving an insurance quote from an image |
US10192130B2 (en) | 2014-06-27 | 2019-01-29 | Blinker, Inc. | Method and apparatus for recovering a vehicle value from an image |
US11436652B1 (en) | 2014-06-27 | 2022-09-06 | Blinker Inc. | System and method for electronic processing of vehicle transactions based on image detection of vehicle license plate |
US9818154B1 (en) | 2014-06-27 | 2017-11-14 | Blinker, Inc. | System and method for electronic processing of vehicle transactions based on image detection of vehicle license plate |
US9558419B1 (en) | 2014-06-27 | 2017-01-31 | Blinker, Inc. | Method and apparatus for receiving a location of a vehicle service center from an image |
US9563814B1 (en) | 2014-06-27 | 2017-02-07 | Blinker, Inc. | Method and apparatus for recovering a vehicle identification number from an image |
US10210396B2 (en) | 2014-06-27 | 2019-02-19 | Blinker Inc. | Method and apparatus for receiving vehicle information from an image and posting the vehicle information to a website |
US10242284B2 (en) | 2014-06-27 | 2019-03-26 | Blinker, Inc. | Method and apparatus for providing loan verification from an image |
US10885371B2 (en) | 2014-06-27 | 2021-01-05 | Blinker Inc. | Method and apparatus for verifying an object image in a captured optical image |
US10515285B2 (en) | 2014-06-27 | 2019-12-24 | Blinker, Inc. | Method and apparatus for blocking information from an image |
US10540564B2 (en) | 2014-06-27 | 2020-01-21 | Blinker, Inc. | Method and apparatus for identifying vehicle information from an image |
US10572758B1 (en) | 2014-06-27 | 2020-02-25 | Blinker, Inc. | Method and apparatus for receiving a financing offer from an image |
US10579892B1 (en) | 2014-06-27 | 2020-03-03 | Blinker, Inc. | Method and apparatus for recovering license plate information from an image |
US10867327B1 (en) | 2014-06-27 | 2020-12-15 | Blinker, Inc. | System and method for electronic processing of vehicle transactions based on image detection of vehicle license plate |
US10733471B1 (en) | 2014-06-27 | 2020-08-04 | Blinker, Inc. | Method and apparatus for receiving recall information from an image |
CN105701865A (en) * | 2016-01-05 | 2016-06-22 | 常州加美科技有限公司 | Unmanned vehicle automatic payment system and method thereof |
US10429852B2 (en) * | 2016-03-29 | 2019-10-01 | Beijing Xiaomi Mobile Software Co., Ltd. | Methods and devices for controlling self-balancing vehicle to park |
US11199848B2 (en) * | 2017-07-21 | 2021-12-14 | Beijing Tusen Zhitu Technology Co., Ltd.. | Method, system and related device of implementing vehicle automatic payment |
US20220100199A1 (en) * | 2017-07-21 | 2022-03-31 | Beijing Tusen Zhitu Technology Co., Ltd. | Method, system and related device of implementing vehicle automatic payment |
US11768502B2 (en) * | 2017-07-21 | 2023-09-26 | Beijing Tusen Zhitu Technology Co., Ltd. | Method, system and related device of implementing vehicle automatic payment |
US10930151B2 (en) * | 2017-11-16 | 2021-02-23 | Intelligent Inter Connection Technology Co., Ltd. | Roadside parking management method, device, and system based on multiple cameras |
CN111225182A (en) * | 2018-11-26 | 2020-06-02 | 杭州海康威视数字技术股份有限公司 | Image acquisition equipment, method and device |
CN111311923A (en) * | 2020-03-05 | 2020-06-19 | 浙江长元科技有限公司 | Fire fighting access supervision method and system |
WO2021179035A1 (en) * | 2020-03-10 | 2021-09-16 | Sensen Networks Group Pty Ltd | Systems and methods for image-based location determination and parking monitoring |
EP4118634A4 (en) * | 2020-03-10 | 2024-03-13 | Sensen Networks Group Pty Ltd | Systems and methods for image-based location determination and parking monitoring |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210279451A1 (en) | Tracking the Use of at Least One Destination Location | |
US20190050634A1 (en) | Tolling with vehicle tracking | |
US9171382B2 (en) | Tracking speeding violations and controlling use of parking spaces using cameras | |
EP2925564B1 (en) | Controlling use of a single multi-vehicle parking space using multiple cameras |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CLOUDPARC, INC., NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NERAYOFF, STEVEN DAVID;WONG, THOMPSON S.;SIGNING DATES FROM 20131013 TO 20131015;REEL/FRAME:033297/0558 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2551) Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Year of fee payment: 8 |