WO2013163372A1 - Système et procédé d'application de permis - Google Patents

Système et procédé d'application de permis Download PDF

Info

Publication number
WO2013163372A1
WO2013163372A1 PCT/US2013/038125 US2013038125W WO2013163372A1 WO 2013163372 A1 WO2013163372 A1 WO 2013163372A1 US 2013038125 W US2013038125 W US 2013038125W WO 2013163372 A1 WO2013163372 A1 WO 2013163372A1
Authority
WO
WIPO (PCT)
Prior art keywords
parking
permit
vehicle
database
computer
Prior art date
Application number
PCT/US2013/038125
Other languages
English (en)
Inventor
Josiah Johnson
Cory Marchasin
Chad Collins
Avinash Sridhar
Gad Moshe Berger
Original Assignee
Ipt Llc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US13/459,015 external-priority patent/US20120215596A1/en
Application filed by Ipt Llc filed Critical Ipt Llc
Priority to EP13781701.1A priority Critical patent/EP2845172A4/fr
Priority to AU2013251536A priority patent/AU2013251536B2/en
Publication of WO2013163372A1 publication Critical patent/WO2013163372A1/fr

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07BTICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07BTICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02Arrangements 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

Definitions

  • a municipality that institutes a permit-based parking program may face the task of issuing from 20,000 to 500,000 permits per year, which requires a complete overhaul of the municipality's existing parking regulation enforcement plan.
  • enforcement in areas designated for parking by permit-only is difficult since parking enforcement officers need to locate and validate every parking permit they encounter. This is especially difficult and sometimes even dangerous if the parking permits are for parking overnight.
  • the conventional verification process generally requires an applicant to prove, in person, the information needed for issuing the permit since scanned, faxed, or emailed documents can be easily forged. This wastes a considerable amount of time for both the permit holder and the issuing agency.
  • Anther problem is that while the issuance of permits assists in the institution of parking regulations, use of conventional permits includes many disadvantages.
  • a conventional parking system may designate a parking zone within the parking system with a unique parking permit design and color. These designs and colors may change from month to month, or year to year depending on the permit expiration dates. The reason these permits are different in each zone is to make it easier for the parking enforcement officers to determine the parking eligibility of the vehicle.
  • managing the inventory of physical permits for each different color and design scheme presents additional challenges and costs.
  • the disclosed technology relates to an enforcement method for enforcing parking permits rights in a parking zone.
  • One aspect of the disclosed technology relates to a computer-implemented method for enforcing parking rights within a parking zone, e.g., a parking lot, street, garage, parking structure or anywhere vehicles may reside.
  • the parking rights are rights that were previously designated by a permit holder and may define a specific parking spot, district, area, or zone in which a permit holder may park and/or a specific time of day, week, month or year in which the permit holder may park.
  • the method includes capturing parked vehicle images within the parking zone during a specified time period.
  • the images are then transmitted to a computing system with a time and date stamp and geographic location.
  • the images are processed to obtain vehicle identifiers.
  • the processing step may performed by an automatic license plate recognition system with the vehicle identifiers being license plate numbers.
  • a permit database containing permit holder data and parking rights data is queried to compile a list of vehicles permitted to park in the parking zone during the specified time period.
  • the vehicle identifiers are then compared to the compiled list to identify the vehicles identifiers which were not authorized to park within the parking zone during the specified time period. Once found, the unauthorized vehicle identifiers are associated with owner information using an outside entity database so that vehicle owners may be notified of violations, e.g., a summons or a warning of potential summons.
  • the outside entity database may receive data from a department of motor vehicles database, a school database, a business database or any outside agency database.
  • the parking rights are rights that were previously designated by a permit holder and may define a specific parking spot, district, area, or zone in which a permit holder may park and/or a specific time of day, week, month or year in which the permit holder may park.
  • the system may include one or more processors and one or more computer-readable storage mediums containing instructions configured to cause the one or more processors to perform operations.
  • the system includes capturing parked vehicle images within the parking zone during a specified time period. The images are then transmitted to a computing system with a time and date stamp and geographic location. The images are the processed to obtain vehicle identifiers. The processing step may performed by an automatic license plate recognition system with the vehicle identifiers being license plate numbers.
  • a permit database containing permit holder data and parking rights data is queried to compile a list of vehicles permitted to park in the parking zone during the specified time period.
  • the vehicle identifiers are then compared to the compiled list to identify the vehicles identifiers which were not authorized to park within the parking zone during the specified time period. Once found, the unauthorized vehicle identifiers are associated with owner information using an outside entity database so that vehicle owners may be notified of violations, e.g., a summons or a warning of potential summons.
  • the outside entity database may receive data from a department of motor vehicles database, a school database, a business database or any outside agency database.
  • Fig 1 is a block diagram showing the system of the disclosed technology
  • Fig 2 is a block diagram showing the mainframe for the disclosed
  • Fig 3 is a block diagram showing new permit module for the disclosed technology
  • Fig 4 is a flow chart for a new application process for the disclosed technology
  • Fig 5 is a block diagram showing an enforcement module for the disclosed technology
  • Fig 6 is a block diagram showing an enforcement computing system for the disclosed technology
  • Fig 7 is a flow chart for a enforcement process for the disclosed technology
  • Fig 8 is a block diagram showing a report generator module for the disclosed technology.
  • Fig 9 is a flow chart for a report generator process for the disclosed technology.
  • a parking permit environment may include one or more parking areas or zones that are controlled by a parking program, e.g., parking lots, streets, garages, parking structures or anywhere vehicles may reside.
  • the parking program may include a set of rules and regulations that govern parking in the zones of the disclosed technology.
  • Fig. 1 shows an example of a parking permit system.
  • the permit parking system 1 includes, but is not limited to, a parking permit mainframe 2, a permit holder computer system 4, an enforcement computing system 6, and an administrative computing system 8.
  • Each of these computing systems are communicatively connected to each other through the internet 12 via a web browser.
  • the web browser provides a portal to one or more computing systems using a network connection, for example, a Network/Internet 100.
  • any web browser is suitable for use in the present invention, including but not limited to FireFox, Microsoft Internet Explorer, Netscape, Opera, and Mozilla.
  • the parking permit mainframe 2 includes, but is not limited to, a new permit module 22, an enforcement module 24, a report generator module 26, an entity database 28, a permit database 30 and a user interface 32.
  • the user interface 32 allows potential and existing permit holders to access the parking permit mainframe 2 via the permit holder computing system 4 for a variety of reasons, e.g., applying for a new permit, editing an existing account, making payments for a permit.
  • the permit holder computing system 4 can be any web-capable device such as a home computer, laptop, tablet or smartphone.
  • the user interface 32 also allows system administrators to access the system 1 via the administrative computing system 8 for management purposes.
  • the administrative system 8 can be any type of corporate network environment allowing many employees to access the system as needed.
  • the user interface 32 may include an authentication or login screen which prompts existing permit holders and administrators to provide login information (e.g., a username and password).
  • login information e.g., a username and password.
  • a permit holder may access information related to his or her account, and perform a number of account-related tasks, including, but not limited to the following: 1 ) add/edit/delete/update vehicle data; 2) add/edit/delete/update permit data; 3) add/edit/delete/update permit holder data; 4) make bill, renewal, and/or citation payments; and 5) review account information including previously issued warnings/notices and/or citations; etc.
  • the administrative computing system 8 allows administrators to access the system for management purposes, including, but not limited to: 1 ) setting up and administering new parking programs; 2) providing online support; 3) managing user groups; 4) setting parking privilege data in accordance with the parameters of the parking program; 5) managing permit inventory; 6) processing new permit applications; 7) managing warning/notice and citation issuance; 8) defining and providing reports to the user groups; and 9) management of billing and invoicing processes.
  • the user interface 32 may also allow a potential or existing permit holder via the permit holder computing system 4 to access the new permits module 22 to submit a new permit application.
  • the new permits module 22 includes, but is not limited to, a verification module 34, a qualification module 36, an issue and notification module 38, a processor 40 and database 42.
  • the new permits module 22 provides an auto-verification method for processing parking permit applications. As will be discussed more fully below, the auto- verification works by using information provided in a parking permit application and electronically verifying a vehicle's motor registration information, residency of an individual or vehicle owner, enrollment status of a student, and/or other information provided by an applicant as required. The auto-verification system will determine if the vehicle(s) provided by the applicant have qualified for a parking permit, and/or the applicant has permission to park in a specific parking space, district, area, or zone for a period of time.
  • the vehicle's license plate will be used as the parking permit which will eliminate the need for a sticker, hang-tag, or decal to be distributed to the applicant by mail or in person.
  • Enforcement and verification of parked vehicles will be based on the vehicle's license plate number.
  • Enforcement tactics may include issuing a parking ticket, booting the vehicle, or towing the vehicle.
  • the new permit application may request data such as permit holder data, vehicle or vehicles to be associated with a permit, a license plate number of vehicle, a scope of privileges requested by the applicant, and a means for payment. It is worthy to note that the applicant need not submit proof required for issuance of the permit as will be discussed more fully below.
  • FIG. 4 shows a flow chart regarding the new permit process.
  • an applicant will access the new permit module 22 by logging onto the system mainframe 2 using a web portal (Step 1 ). Once on the system, the applicant will fill out a standardized form (Step 2) and once completed the applicant will inform the system that the form is completed. This may be accomplished by hitting an electronic button on the web screen informing the system that the form is ready for processing (Step 3). If the applicant is a new to the system, the system may create a new user profile and associate the applicant with an account number for administrative purposes. Once the form has been finalized by the applicant, the form will be stored in the new permit database 42 and the processing of the application will begin.
  • the processor 40 will ensure that the information contained in the applicant is true. This is accomplished by allowing the processor 40 to compare the applicant information contained on the application with data from the information database 28 (Step 4).
  • Information that may be verified is (1 ) the vehicle registration address, (2) vehicle registration validity, (3) the vehicle registration matches the vehicle owner's/permit applicant's primary address and (4) any other information that may be stored in the information database 28.
  • the information database 28 is a database that contains information about the applicant from outside sources such as the Department of Motor Vehicles records, school enrollment systems, business databases and other similar databases.
  • the outside source data 14 may be uploaded onto the information database 28 base on a regular schedule, e.g., daily, weekly. Or the outside source data 14 may be electronically linked to the information database 28 and the mainframe may send data requests to the outside sources 14 as needed.
  • Step 5 the module determines if the application information is true or false. If the applicant information is found to be false, the permit will not be issued and the system 1 will notify the applicant as to the reasons of why the application was denied, e.g., the vehicle was not registered to the applicant or the registration has expired. (Step 9).
  • the scope of privileges may include, but is not limited to: a) one or more locations, zones, streets, lots, spaces, garages, parking structures or areas the vehicle is requested to park; b) the term of the permit and/or the permit's expiration date; and/or c) the valid parking time or times (i.e., weekend-only rights; weekday-only rights, seasonal rights, etc.).
  • the qualification step is performed using a dynamic rules-based engine that identifies the parking rights which were applied for by the applicant and applies these rights a set of nested rules.
  • These nested rules are a set of requirements that must be met in order for an applicant is allowed to receive these privileges. Each requirement is considered to be part of a set and each set can have one or multiple items. For eligibility, depending on the set of rules, all or some of the requirements must be met in order to obtain a permit. These rules may be evaluated recursively with a parent set until a final valid or invalid result is returned.
  • the benefit to a rule engine as described above is that multiple levels of approvals and restrictions can be defined so that items of high importance have more weight than items of lower importance.
  • the rules may state that an applicant must reside within a certain number of miles or blocks of the requested zone, and/or the applicant must take classes at the university, or the applicant must be employed by institutions in which the permit is for, and/or the applicant must have no outstanding debts with the entity. If the applicant does not meet one or all of these rules the applicant may be denied the permit and a notification informing the applicant of the reasons why the application will be denied will be sent to the applicant. (Step 9). If the applicant meets required nested rules (Step 7), the system will approve the permit and notify the applicant of the approval. (Step 8). In one embodiment, the notification may be sent via e-mail, text message or any other electronic notification system. In another embodiment, the notification may be mailed to an address associated with the permit.
  • the system 1 will associate the vehicle license plate with the permit data and will store this data in the permit database 30. That is, the issued permits will be held in the permit database 30 that stores information pertaining to the permits.
  • Types of information that may be stored includes, but is not limited to, 1 ) vehicle data (includes, but is not limited to the make, model, color, year, and/or license plate number of the vehicle or vehicles authorized under a valid permit), 2) permit holder data (includes, but is not limited to, the permit holder's name, address, phone number, e-mail address, and/or facsimile number) and/or 3) permit data (defines the scope of privileges or parking rights held by the permit holder, including, but is not limited to: a) the one or more locations, zones, streets, lots, spaces, or areas the vehicle is permitted to park; b) the term of the permit and/or the permit's expiration date; and/or c) the valid parking time or times (i.e., weekend-
  • Figure 5 shows the enforcement module 24.
  • the enforcement module 24 is an integrated, automated process where the system 1 captures all vehicles that are parked within a zone during a defined period of time. Once a zone is patrolled, the system 1 , in an automated fashion, uses a rule system to segregate vehicles in violation from vehicles that are not and creates a citation based on violation type.
  • the enforcement module 24 includes, but is not limited to, a user interface 54, a full or partial Automatic Plate Number Recognition (ANPR system) 50, a noticing module 52, and processor 56.
  • the user interface 54 allows the system to receive and transmit data from and to the system mainframe 1.
  • the enforcement computing system 6 is part of an ALPR system that includes, is not limited to, a camera 60, a web-interface 68, GPS 64, display 62, database 66, a processor containing a full or particle ANPR system 70.
  • the camera 60 may be affixed to an outside of an enforcement vehicle or a handheld camera operated by an enforcement officer.
  • the camera 60 is configured to record vehicle identifiers while in motion, e.g., license plates and permit tags, and send the images to a processor for optical recognition.
  • an ANPR system may use a series of image manipulation techniques to detect, normalize and enhance images of licenses plates, and then use optical character recognition (OCR) to extract the alphanumerics of the license plate.
  • OCR optical character recognition
  • ANPR systems are generally deployed in one of two basic approaches: one allows for the entire process to be performed at the time an image is captured in real-time, and the other transmits the images to a remote computer location where the OCR process is done off-site at a later time.
  • the cameras will be installed in multiple positions on an enforcement vehicle so that the camera can get good quality images when (1 ) the enforcement vehicle is being driven at a moderate speed (e.g., 5-25 mph), (2) a variety of zones are being patrolled (e.g., streets, lots, angled parking) and (3) the license plates to be analyzed are from multiple states (e.g., New York, New Jersey, ect.).
  • a moderate speed e.g., 5-25 mph
  • a variety of zones e.g., streets, lots, angled parking
  • the license plates to be analyzed are from multiple states (e.g., New York, New Jersey, ect.).
  • FIG. 7 illustrates an exemplary process flow for monitoring a permit-based parking environment to determine if the vehicle(s) parked therein are permissibly parked.
  • an enforcement vehicle enters a parking zone during a defined period of time.
  • an ALPR camera 8 captures images of vehicles parked in a permit-based parking zone managed by the parking permit system 1.
  • the enforcement vehicle may have a GPS system that tracks the location of the enforcement vehicle to ensure that the enforcement vehicle is within the zone where enforcement is to be verified.
  • a map may be shown on the display that allows the operator to know the boundaries of zone in which the enforcement vehicle is operating.
  • step S3 the enforcement computing system transmits image data and operational data to the enforcement module 24.
  • the operational data may include the zone being patrolled, a time and a date and a geographic location of the vehicle, e.g., the geographic location may be a GPS coordinate or a point on a display map.
  • the image is processed using the ALPR module to obtain a vehicle identifier, e.g. a license plate.
  • the image may be processed in real-time by the enforcement computing system 6 and then transmits the vehicle identifier to the enforcement module 24.
  • step 5 the processor queries the permit database 30 to identify all cars that are authorized to park in the zone during a specified time period.
  • the vehicle identifiers parked in the lot are compared to the list containing all the cars that are authorized to park in the zone during the specified time period.
  • the module 24 identifies vehicles that are parked within the zone without permission.
  • the module 24 looks up vehicle owner information using the information database 28 to find the owner information and then issues an enforcement action to the vehicle owner, e.g., a citation may be sent to an individual whose car was parked in the lot on Saturday when the permit was only issued for weekdays between 9AM and 2PM.
  • the vehicle owner may be notified by mail or some other type of notification method such as e-mail. It is worthy to note that an enforcement officer does not have to place a citation on the windshield or any other area of the vehicle. During the enforcement stage, offenders may also be identified if vehicle has an expired registration or the offender has outstanding tickets.
  • the captured image may be sent to the
  • the parking permit system 1 also includes the report generator module 26 that includes, but is not limited to, a processor 80 and user interface 82.
  • This module 26 aggregates data and presents the data in a format that can be easily disseminated to public figures and the general public to show the progress of existing programs and the effectiveness of implementing programs in new places.
  • the information may be disseminated via e-mail, mail notifications and web-based visualizations such as a heat map. It can also be used to identify repeat offenders and send these offenders statistics on the parking program, the cost and how the repeat offender would be better suited to join the program.
  • the report generator 26 is a computer-executable module configured to generate reports relating to the parking program.
  • the reports may include any information related to the parking program which is maintained by the parking permit system.
  • reports which may be generated include, but are not limited to, reports relating to: 1 ) financial information (e.g., receivables of the parking program, 2) enforcement officer performance information (e.g., number of scans, number of warning/notices, number of citations, number of times the
  • enforcement officer failed to take action, etc.
  • 3) permit holder account information 4) permit inventory, 5) enforcement action information and any other reporting material that is relevant to the parking system.
  • Another aspect of the report generator 26 is generating a report showing how a zone not under a permit system will benefit if a system is applied. That is, the report generator 26 may be used to create suggestions for new zones or inform municipalities about permit options in zones that are not under a permit management system 1.
  • the report generator may also have an algorithm that analyzes the data so that suggestions for changes to rules for parking optimization.
  • the report generator is also capable of forming a list of permits set to expire within a timeframe so that the system may send out notifications to the permit holder so that there are no gaps in permit coverage.
  • Step 1 One example for a process of the report generator 26 is shown in Figure 9.
  • an administrator provides the report generator 26 with proposed boundary lines for a new zone. (Step 1). This may be performed by overlaying a map with a proposed zone or defining the zone using street and avenues.
  • the report generator 26 may then compare the proposed zone to existing zones so that a similar zone may be found. (Step 2). Once a similar zone is found, the system will analyze the proposed zone. (Step 3). Once analyzed, the module 26 may generate a report showing an approximation of (1 ) how many parking permits may be issued for the proposed zone, (2) how many spots may be created within the proposed zone, (3) the projected revenue for the proposed zone and (4) the amount of applicants that are qualified to have a permit.
  • Another aspect also allows the generator to form a list of repeat offenders within a zone and analyze the offender information to see if the offender is eligible to park with a zone or a nearby zone and what would the cost of such permit be.
  • the report generator may also allow particular users groups (e.g., permit holders, applicants, administrators, ect.) to submit a request for a report via the user interface. Based on the report request, the report generator can retrieve information from the database, generate the report, and provide the report to the requesting user group via the user interface.
  • users groups e.g., permit holders, applicants, administrators, ect.
  • the report generator may also be configured to automatically run reports at one or more specific intervals of time (e.g., hourly, daily, weekly, monthly, yearly, etc.) according to a pre-determined and customizable schedule. For example, the report generator may run a daily report detailing each violation that occurred in a particular zone during the previous 24 hour period, and automatically deliver the report to a managing computer and/or the enforcement computing system associated with that zone.
  • one or more specific intervals of time e.g., hourly, daily, weekly, monthly, yearly, etc.
  • the report generator may also automatically receive report requests from the enforcement computing system.
  • the enforcement computing system may send a daily request for a report providing permit data updates.
  • the report generator may also present the parking permit data in a usable format so that advantages and disadvantages of program can easily be seen.
  • the method may analyze the parking permit data for program advantages and disadvantages and notify permit holders and/or governing entities, such as,
  • Another embodiment of the system allows a valid permit holder to apply for guest permits. That is, a valid permit holder may log onto system and request a temporary guest permit that is to be associated with the permit holder's account and residency. This system can be updated live but an existing account needs to be already active. A rules system may be put in place that allows guest passes to be issued. For example, a permit holder may have a limit to how many guest passes may be issued per month and the times when guest passes may not be issued.
  • the parking permit system may include human-based components.
  • the user interface may be a call center or conventional office wherein persons (e.g., permit holders or applicants) may access the permit parking system via a telephone or in- person communication.
  • persons e.g., permit holders or applicants
  • the systems and methods disclosed herein may be implemented on various types of computer architectures, such as for example on a single general purpose computer or workstation, or on a network (e.g., local area network, wide area network, or internet), or in a client-server configuration, or in an application service provider configuration.
  • system's and method's data may be stored as one or more data structures in computer memory and/or storage depending upon the application at hand.
  • the systems and methods may be provided on many different types of computer readable media including instructions being executable by a computer to perform the system and method operations described herein.
  • the systems and methods may also have their information
  • carrier signals e.g., radio frequency carrier signals
  • other communication pathways e.g., fiber optics, infrared, etc.
  • a module includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code.
  • the computer components may be located on a single computer or distributed across multiple computers depending upon the situation at hand.

Landscapes

  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

L'invention concerne un système d'application de permis qui est un système mis en œuvre par ordinateur et qui applique des droits de stationnement dans une zone de stationnement. Le système peut comprendre un ou des processeurs qui permettent au système de capturer d'abord des images de véhicules stationnés dans la zone de stationnement pendant une période spécifiée. Les images sont ensuite transmises à un système informatique ayant un tampon temporel et à date et un emplacement géographique. Les images sont traitées pour obtenir des identifiants de véhicule. Le processeur demande ensuite à une base de données de permis de compiler une liste de véhicules autorisés à stationner dans la zone de stationnement pendant la période spécifiée. Cette liste est comparée aux identifiants de véhicule et les identifiants de véhicule qui ne sont pas autorisés à stationner dans la zone de stationnement pendant la période spécifiée sont identifiés. Ces véhicules sont ensuite associés à des informations de propriétaire à l'aide d'une base de données d'entité externe et les propriétaires de véhicule sont informés des violations.
PCT/US2013/038125 2012-04-27 2013-04-25 Système et procédé d'application de permis WO2013163372A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP13781701.1A EP2845172A4 (fr) 2012-04-27 2013-04-25 Système et procédé d'application de permis
AU2013251536A AU2013251536B2 (en) 2012-04-27 2013-04-25 System and method for permit enforcement

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/459,015 2012-04-27
US13/459,015 US20120215596A1 (en) 2005-11-16 2012-04-27 System And Method For Permit Enforcement

Publications (1)

Publication Number Publication Date
WO2013163372A1 true WO2013163372A1 (fr) 2013-10-31

Family

ID=49483876

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/038125 WO2013163372A1 (fr) 2012-04-27 2013-04-25 Système et procédé d'application de permis

Country Status (3)

Country Link
EP (1) EP2845172A4 (fr)
AU (1) AU2013251536B2 (fr)
WO (1) WO2013163372A1 (fr)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3287485A (en) 1963-03-21 1966-11-22 Us Rubber Co Method of providing a fluid tight seal between two rigid components
US3670688A (en) 1971-03-02 1972-06-20 Lewis A Seaberg Composite valve stem
US6005480A (en) 1998-05-20 1999-12-21 Schrader-Bridgeport International, Inc. Tire valve and associated tire pressure sending unit
US20060255119A1 (en) * 2004-06-16 2006-11-16 Marchasin Cory D Parking environment management system and method
US20070112620A1 (en) * 2005-11-16 2007-05-17 Josiah Johnson Permit-based parking environment management method and system
US7281421B2 (en) 2005-06-03 2007-10-16 Temic Automotive Of North America, Inc. Package for a tire pressure sensor assembly
US20080319837A1 (en) * 2005-08-29 2008-12-25 Mitschele Frederick L Pay Parking System and Method
US20090227240A1 (en) * 2008-03-07 2009-09-10 Velosum, Inc. Systems and methods for parking enforcement
US20120103432A1 (en) 2009-06-25 2012-05-03 Schrader Sas Asymmetric valve for vehicle wheel

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2199999A1 (fr) * 1997-03-14 1998-09-14 Peter Johann Kielland Systeme de patrouille d'aires de stationnement
US20040068433A1 (en) * 2002-09-23 2004-04-08 Eximsoft International Parking system with centralized reservation, payment and enforcement
AU2007356750A1 (en) * 2007-07-18 2009-01-22 The City Of Calgary System and method for managing parking rights

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3287485A (en) 1963-03-21 1966-11-22 Us Rubber Co Method of providing a fluid tight seal between two rigid components
US3670688A (en) 1971-03-02 1972-06-20 Lewis A Seaberg Composite valve stem
US6005480A (en) 1998-05-20 1999-12-21 Schrader-Bridgeport International, Inc. Tire valve and associated tire pressure sending unit
US20060255119A1 (en) * 2004-06-16 2006-11-16 Marchasin Cory D Parking environment management system and method
US7281421B2 (en) 2005-06-03 2007-10-16 Temic Automotive Of North America, Inc. Package for a tire pressure sensor assembly
US20080319837A1 (en) * 2005-08-29 2008-12-25 Mitschele Frederick L Pay Parking System and Method
US20070112620A1 (en) * 2005-11-16 2007-05-17 Josiah Johnson Permit-based parking environment management method and system
US20090227240A1 (en) * 2008-03-07 2009-09-10 Velosum, Inc. Systems and methods for parking enforcement
US20120103432A1 (en) 2009-06-25 2012-05-03 Schrader Sas Asymmetric valve for vehicle wheel

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2845172A4 *

Also Published As

Publication number Publication date
AU2013251536A1 (en) 2014-11-20
EP2845172A1 (fr) 2015-03-11
AU2013251536B2 (en) 2017-04-13
EP2845172A4 (fr) 2016-02-24

Similar Documents

Publication Publication Date Title
US20120215596A1 (en) System And Method For Permit Enforcement
US20120215595A1 (en) System and Method For Automatically Issuing Permits
US9262749B2 (en) System and method for generating permit reports
CA2516675C (fr) Gestion de peage electronique
US7950570B2 (en) Parking environment management system and method
US8504415B2 (en) Electronic toll management for fleet vehicles
EP2472476B1 (fr) Identification électronique de véhicule
US20140371950A1 (en) Systems and methods for monitoring and managing transportation infrastructure and locations of vehicles therein
US20080077417A1 (en) Systems and Methods for Citation Management
US20090083133A1 (en) Method and system for electronic payment of missed tolls
AU2013251536B2 (en) System and method for permit enforcement
EP2845175A1 (fr) Système et procédé pour distribuer automatiquement des permis
AU2013251635B2 (en) System and method for generating permit reports
USRE47678E1 (en) Parking environment management system and method
JP2015179531A (ja) 駐車権利を管理するシステムおよび方法
JP2013175223A (ja) 駐車権利を管理するシステムおよび方法
WO2013070093A2 (fr) Système de perception d'amendes basé sur le web

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13781701

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: P1167/2014

Country of ref document: AE

ENP Entry into the national phase

Ref document number: 2013251536

Country of ref document: AU

Date of ref document: 20130425

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2013781701

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2013781701

Country of ref document: EP