WO2017033172A1 - Système et procédé de création d'emplacement de stationnement modulaire - Google Patents

Système et procédé de création d'emplacement de stationnement modulaire Download PDF

Info

Publication number
WO2017033172A1
WO2017033172A1 PCT/IL2016/050239 IL2016050239W WO2017033172A1 WO 2017033172 A1 WO2017033172 A1 WO 2017033172A1 IL 2016050239 W IL2016050239 W IL 2016050239W WO 2017033172 A1 WO2017033172 A1 WO 2017033172A1
Authority
WO
WIPO (PCT)
Prior art keywords
parking
vehicle
spot
subunits
client device
Prior art date
Application number
PCT/IL2016/050239
Other languages
English (en)
Inventor
Itamar ROSEN
Elimelech Weissberg
Original Assignee
Sparkcity.Com.Ltd.
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 PCT/IB2015/056512 external-priority patent/WO2016046665A1/fr
Application filed by Sparkcity.Com.Ltd. filed Critical Sparkcity.Com.Ltd.
Publication of WO2017033172A1 publication Critical patent/WO2017033172A1/fr

Links

Classifications

    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/024—Guidance services
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • 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/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
    • 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/147—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 within an open public zone, e.g. city centre
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • 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
    • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • TITLE A SYSTEM AND METHOD OF CREATING
  • the invention is in the field of parking systems.
  • an individual driver may have difficulty finding parking, thereby wasting precious time and money.
  • Applicant has identified key components in providing a holistic solution to known parking problems faced both by drivers and by regional authorities such as municipalities and venue managers.
  • Methods and systems according to embodiments of the invention provide a solution to inefficient parking (e.g., a single vehicle parked so as to occupy more than a single parking spot), by increasing the efficiency of usage of existing parking resources. This effectively increases the parking capacity of the city as well as assists an individual driver to park.
  • a broad aspect of the invention relates to traffic control. More specifically various exemplary embodiments of the invention relate to parking reservation systems which assign parking spots to users based on availability. In some exemplary embodiments of the invention, users order parking spots using a user client device.
  • the user client devices are onboard computers (whether in a standard or driverless vehicle), smartphones, dedicated navigation devices (for example, a standalone GPS device) and/or tablet devices and/or laptop computers and/or wearable devices and/or desktop computers and/or 2G phones and/or specially equipped parking kiosks and/or and conventional phones (for example, operating through the Public Switched Telephone Network).
  • dedicated navigation devices for example, a standalone GPS device
  • parking docents carrying a user client device are deployed in order to assist drivers that do not have a user client device.
  • One aspect of some embodiments of the invention relates to assigning a correctly or appropriately sized individual parking spot for each incoming parking request.
  • Designated parking areas in a region may be divided into subunits ("parking subunits").
  • a subunit is a conventional parking spot.
  • the correctly sized individual parking spot is created by assembling two or more contiguous subunits.
  • a reservation server considers vehicle dimensions associated with a vehicle registration number and/or additional size requirements requested by a system user.
  • the additional size requirements are communicated as part of the parking request and/or provided as part of a user profile.
  • Another aspect of some embodiments of the invention relates to a GUI on a user client device which facilitates communication of additional size requirements from the system user to the reservation server.
  • a method including: transmitting a vehicle registration number from a parking reservation server to a vehicle registration database; receiving vehicle dimensions at the parking reservation server in response to the transmitting; calculating a parking spot size based on the vehicle dimensions; and reserving an appropriately sized parking spot based on results of the calculating.
  • the method includes receiving at the parking reservation server additional size requirements and employing the additional size requirements in the calculating.
  • the method includes accessing reservation history for the vehicle registration number; and transmitting a query concerning additional size requirements to a user client device if a recent reservation from the same vehicle registration number included additional size requirements.
  • the method includes assembling two or more contiguous spots to create the appropriately sized parking spot.
  • a method including storing a list of parking subunits at a parking reservation server, each parking subunit associated with a unique identifier (UID) and location coordinates; receiving a parking reservation request including a vehicle registration number at the server from a user client device; ascertaining a size of the vehicle from the vehicle registration number; assembling a parking spot sized for the vehicle from two or more contiguous parking subunits; and transmitting location coordinates of the parking spot sized for the vehicle to the user client device as part of a reservation confirmation.
  • the method includes associating the location coordinates of the parking spot sized for the vehicle with instructions to launch a navigation program on the user client device.
  • all of the parking subunits are same sized.
  • the parking subunits include at parking subunits that are differently sized.
  • a method including transmitting a parking request including a vehicle registration number and a destination to a reservation server from a user client device; receiving at the user client device a response including a map of an area in proximity to the destination with available parking subunits indicated; and a rectangle representing the vehicle defined by the registration number according to a scale of the map; and positioning the rectangle over two or more contiguous available subunits and entering a confirm command to reserve the two or more contiguous subunits.
  • the subunits are part of a parallel parking arrangement.
  • the subunits are part of a non-parallel parking arrangement.
  • the method includes increasing a length and/or width of the rectangle to cover additional subunits.
  • a system including: parcels of land each having a unique identifier; a database of said parcels of land; and a processor to calculate a parking spot using said parcels of land.
  • Region indicates any geographical area having any or all types of parking facilities. "City” is used interchangeably with “region” unless specified otherwise.
  • parking spot or “spot” includes, for example, on-street, off-street, parking lots, garages (for example, multi-story parking towers and/or underground garages).
  • venue indicates a destination which attracts a large number of vehicles carrying occupants that share a common purpose. Examples of venues include football stadia, amusement parks, transportation hubs such as, for example, airports and train stations, and shopping malls.
  • vehicle attribute indicates either one or both technical data of the vehicle and legal status.
  • “Technical data” includes, but is not limited to physical dimensions (length, width and height), and engine type (powered by gasoline, hydrogen; liquid propane or electricity).
  • Legal status includes, but is not limited to, private, resident (for example, of a specific region or a specific parking zone defined within that region) emergency (for example, fire truck or ambulance), law enforcement, government (for example, municipal maintenance trucks, postal delivery vehicles), security, prison, delivery, utility (for example, phone company or electric company).
  • vehicle indicates any wheeled conveyance used for on or off road transportation, provided that the specified vehicle is susceptible of being uniquely identified by listing in a database.
  • This definition includes, but is not limited to, automobiles, motorcycles, bicycles, tricycles, motorbikes/scooters, buses, trucks, emergency vehicles, security vehicles, industrial vehicles and public transportation vehicles.
  • driver and “user” are used interchangeably to mean a vehicle operator or vehicle passenger or other individual interacting with the system for the purpose of reserving a parking spot for a specified vehicle.
  • processing refers exclusively to the action and/or processes of a computer, computing system, client/server system, or similar electronic computing device that manipulates and/or transforms data.
  • these verbs are indicative of a transformation of abstract data into a concrete representation of information that has utility outside the machine on which it resides.
  • UI indicates user interface
  • GUI indicates graphical user interface
  • UID indicates unique identifier
  • method refers to manners, means, techniques and procedures for accomplishing a given task including, but not limited to, those manners, means, techniques and procedures either known to, or readily developed from known manners, means, techniques and procedures by practitioners of architecture and/or computer science.
  • Implementation of the method and system according to embodiments of the invention involves performing or completing selected tasks or steps manually, automatically, or a combination thereof.
  • several selected steps could be implemented by hardware or by software on any operating system of any firmware or a combination thereof, for example, as hardware, selected steps of the invention could be implemented as a chip or a circuit.
  • selected steps of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system.
  • selected steps of the method and system of the invention could be described as being performed by a data processor, such as a computing platform for executing a plurality of instructions.
  • Fig. 1 is a schematic representation of a parking system according to some embodiments of the invention.
  • Fig. 2a is a schematic representation of an exemplary graphic user interface for selecting a specific parking spot from a list offered by a reservation management server, displayed on a user client device;
  • Fig. 2b is a schematic representation of an exemplary graphic user interface for confirming arrival at specific parking spot interface assigned by a reservation management server displayed on a user client device;
  • Fig. 2c is a schematic representation of an exemplary graphic user interface for confirming departure from a specific parking spot assigned by a reservation management server displayed on a user client device;
  • Fig. 3. is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 4. is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 5. is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 6 is a table illustrating an exemplary rule application scheme according to some embodiments of the invention.
  • Fig. 7a is a schematic representation of differently sized parking spots resulting from practice of a method according to some exemplary embodiments of the invention.
  • Fig. 7b depicts a GUI according to some exemplary embodiments of the invention.
  • Fig. 7c depicts a GUI according to some exemplary embodiments of the invention.
  • Fig. 8a is a schematic representation of a system according to some exemplary embodiments of the invention
  • Fig. 8b is a schematic representation of a system according to some exemplary embodiments of the invention
  • Fig. 9 is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 10 is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Embodiments of the invention relate to parking systems, methods and devices.
  • some embodiments of the invention are used to assign a specific vehicle to a specific parking spot.
  • the assignment is for a predetermined amount of time.
  • some embodiments of the invention are used to join two or more adjacent parking subunits to create a spot for a single vehicle (for example, a standard car, oversized or requiring extra clearance for a lift).
  • some embodiments of the invention are used to manage what were previously considered as separate parking resources (e.g., on street spots and/or off street lots or garages and/or individual privately owned-spots) as an integrated parking facility.
  • separate parking resources e.g., on street spots and/or off street lots or garages and/or individual privately owned-spots
  • some embodiments of the invention are used to change parking rules from a central command and control center (CCC) easily and conveniently.
  • CCC central command and control center
  • some embodiments of the invention are used to provide usage statistics to the CCC according to selected areas. According to various exemplary embodiments of the invention the statistics are presented as a function of time and/or price.
  • Fig. 1 is a schematic representation of a computerized parking system illustrating the context in which various embodiments operate, indicated generally as system 100. Sub-systems and related methods discussed in greater detail below may be easier to understand when considered in the context of system 100 as described here.
  • exemplary system 100 operates a reservation server 120 which receives inputs from user client devices 122.
  • a single user client device 122 is depicted for clarity although a much larger number will be present in actuality.
  • One main function of the system is to receive parking requests from user client devices 122.
  • the request entered by a user includes a vehicle registration number and an indication of a destination.
  • Server 120 responds to each request by providing a reservation for a specific vehicle (e.g., identified by vehicle registration number) to a specific parking spot based upon a parking request from the user.
  • a specific vehicle e.g., identified by vehicle registration number
  • many embodiments of system 100 aid the operator of user client device 122 in locating and/or identifying the specific parking spot associated with their reservation.
  • system 100 Another main function of system 100 is to contribute to efficient enforcement of parking violations.
  • One way that system 100 makes this contribution is by permitting user client devices 122 to report parking violations to a violation system 130.
  • reservation server 120 communicates with one or more information resources to procure information needed to process an incoming parking reservation request from user client 122.
  • Exemplary databases (DBs) in system 100 are:
  • Vehicle DB 162 which stores vehicle attributes (as defined in Glossary hereinabove) in association with a vehicle registration number. In some embodiments at least a portion of the information in vehicle DB 162 is available from a governmental licensing authority (for example, department of motor vehicles, department of public safety or ministry of transportation).
  • system 100 communicates with an external governmental DB (not depicted) during processing of each incoming reservation request. In some embodiments system 100 mirrors the external governmental DB. In some embodiments, mirroring contributes to processing speed of each incoming reservation request.
  • system 100 provides supplemental information to DB 162 (for example, legal attributes associated with a vehicle) and/or an icon depicting the vehicle.
  • Parking spot DB 164 which stores information regarding the location (i.e. location coordinates), size and current status of parking subunits. Each parking spot (which may consist of several parking subunits) is administered by the system 100. Information regarding the location, size and current status of parking spots is also be stored in spot DB 164.
  • each parking subunit and/or specific spot has a unique identifier (UID).
  • UID is visible to a user of the system when they park their car (for example, painted on the pavement or on a wall or a sign adjacent to the subunit(s) or spot).
  • spot DB 164 also stores status for future time points (for example, if advance reservations are accepted and/or if the current use is subject to a time limitation).
  • spot DB 164 assigns a status of "available” or "not available” for each individual parking subunit as a function of time. The status "available" for a subunit indicates that it is not occupied and not reserved and not precluded from use by any rule.
  • the status "not available” indicates that the spot is either occupied or reserved or precluded from use by a rule or "uncertain”.
  • a temporary “uncertain” status is applied to spots and/or parking subunits which are the subject of complaints or reports.
  • the "uncertain” status will only be maintained until the actual status is investigated (e.g., by dispatching system personnel to inspect the parking spot).
  • sub statuses are applied, such as "reserved", "occupied”, "in violation”.
  • Rule DB 166 which stores parking rules for each individual spot administered by the system.
  • rule changes are applied to individual spots and/or groups of spots by one or more parties.
  • multiple rules apply to a given spot at any given moment in some embodiments.
  • rules often have multiple attributes as described hereinbelow in the section entitled "Exemplary rule attributes”.
  • Queue DB 172 which stores incoming parking reservation requests that have not yet been transformed into reservations for a specific spot and/or reservations for a specific spot which have not yet been taken up by an assigned car parking in the assigned spot.
  • Event history DB 168 which stores "parking events" for a particular spot defined in terms of at least a vehicle registration number and a parking duration. In many embodiments details such as, for example, date, reservation time, time in, time out, specific parking spot and hourly rate are also stored. Periodically, events from event history DB 168 are sent from system 100 to finance department 140 for payment processing. Violation history DB 132, which stores "violation events” defined in terms of at least a vehicle registration number and a specific spot. In many embodiments details such as, for example, date, time, infraction type (e.g., parked for 3 hours in a 2 hour spot or parked in a spot reserved for another vehicle) are stored. In some embodiments, evidence (e.g., a photograph of the infraction with a date/time stamp) is also stored in DB 132. Periodically, events from DB 132 are sent from system 100 to finance department 140 for payment processing.
  • events from event history DB 132 are sent from system 100 to finance department 140 for payment
  • reservation server 120 also communicates with suggestion list builder 110 to process at least some of the incoming parking reservation requests from user clients 122.
  • Suggestion list builder 110 communicates with DBs 162, 164 and 166 to assemble a list of available spots in proximity to a destination defined in the request received from user client device 122 and suitable for the car defined by the vehicle registration number in the request.
  • reservation server 120 also communicates with violation system 130 and relays violation information to spot DB 164.
  • violation information includes discovery of an unauthorized vehicle in a specific spot and/or a report of removal by a law enforcement agency of an unauthorized vehicle from a specific spot. Both the discovery and the removal report result in a status change for the specific spot in question in DB 164.
  • violation system 130 reports events which prevent the use of or access to a parking spot. Examples of such events include for example, a fallen tree or piles of snow resulting from plowing.
  • violation system 130 also issue reports 131 in the form of parking tickets.
  • system 100 includes a rule and spot manager 150 functioning to relay externally provided rules to spot DB 164.
  • externally supplied rules originate from a command and control center (CCC) 151 and/or from lot spot manager 153 and/or from private spot manager 152.
  • CCC 151, private spot manager 152 and lot spot manager 153 operate a rule input interface adapted to their specific needs.
  • the rule input interface for CCC 151 is typically the most robust of the three.
  • the rule input interface for CCC 151 handles the largest number of spots and deals with the largest number of possibilities.
  • the rule input interface for lot spot manager 153 is typically intermediate in capacity.
  • the rule input interface for lot spot manager 153 deals primarily with rules applicable to a whole parking facility, or a whole floor within a parking facility in some cases.
  • the rule input interface for private spot manager 152 typically has the least capacity. Private spot manager 152 deals with rules for a single spot.
  • system 100 As an example of how system 100 works, the processing of a single reservation request, which defined 52 Weizmann St. in Tel Aviv as a destination, is described with respect to both the functionalities of system 100 (Fig. 1) and of a specific user client device 122a (Figs. 2a- 2c) in the form of a smart phone running a software application (“app” or "parking app") that serves as a communication interface between system 100 and the display of device 122a.
  • the vehicle registration number is either included in the request or is available to the system from a user profile established previously (For example, during installation of the app).
  • Reservation server 120 of system 100 receives the request and relays it to suggestion list builder 110.
  • List builder 110 analyzes information in DBs 162, 164 and 166 and assembles a list of available parking spots that are relevant to the specific request. According to various exemplary embodiments of the invention relevance is analyzed either according to a user profile and/or according to rules programmed into list builder 110. The list of available parking spots is relayed to user client device 122a via reservation server 120.
  • Fig. 2a is a schematic representation, indicated generally as 200, of an exemplary user client device 122a displaying a user interface for selecting a specific parking spot from a list offered by reservation management server 120 after construction by list builder 110.
  • each of list items 123a, 123b and 123c includes a street address, a distance from the requested destination and an hourly rate.
  • An operator of device 122a makes a selection by touching one of the items in the list or by issuing a voice command.
  • selection of a list item issues an instruction to a navigation app running on user client device 122a and the navigation app guides the operator of 122a to a specific parking spot using location coordinates associated with the item selected from the list (but typically not displayed on the screen).
  • Fig. 2b is a schematic representation, indicated generally as 201,
  • the navigation app Since the navigation app is aware of current location and speed (for example, from a tracking component installed in device 122a), in some embodiments the navigation app displays a prompt 123d to confirm parking as the vehicle approaches the spot and/or slows down in proximity to the spot. The user confirms as described above for selection of a list item. In the depicted embodiment, a "do not confirm" icon 123e is also provided.
  • the server Upon receipt of confirmation of parking at server 120, the server updates the sub-status of the specific spot and/or of the parking subunits comprising the spot in DB 164 from "reserved" to "occupied".
  • Fig. 2c is a schematic representation, indicated generally as 202, of user client device 122a displaying an exemplary interface for confirming departure from a specific parking spot assigned by a reservation management server 120. Since the navigation app is aware of current location and speed (for example, from a tracking component installed in the device), the navigation app displays a prompt 124a to confirm exit from the parking spot as the vehicle departs from the spot and/or attains a velocity that indicates the operator of the device is not on foot (for example, 25km/hr). The user of the device confirms as described above for selection of a list item. In the depicted embodiment a "do not confirm" icon 124b is also provided.
  • the server 120 Upon receipt of confirmation of exit from the parking spot at server 120, the server 120 updates the sub-status of the specific spot and/or the parking subunits comprising the spot) in DB 164 from "occupied" to "unoccupied” or "reserved” as appropriate.
  • Fig. 3. is a simplified flow diagram of a method, indicated generally as 1300 for assigning appropriately sized parking spots to each vehicle in a computerized parking management system according to some exemplary embodiments of the invention.
  • Exemplary method 1300 includes transmitting 1310 a vehicle registration number from a parking reservation server 120 (Fig. 1) to a vehicle registration database 162 (for example, via list builder 110).
  • the method includes receiving 1320 vehicle dimensions at parking reservation server 120 from DB 162 in response to transmitting 1310 and calculating 1330 a parking spot size based on the vehicle dimensions.
  • calculating 1330 is based upon vehicle length. Alternatively or additionally, in some embodiments calculating 1330 is based upon vehicle width. Alternatively or additionally, in some embodiments calculating 1330 is based upon vehicle height. Alternatively or additionally, in some embodiments calculating 1330 is based upon required side clearance and/or rear clearance (for example, for a vehicle with a lift for a wheelchair or freight.) In the depicted embodiment once the correctly sized parking spot has been calculated, server 120 searches spot DB 164 to find an appropriately sized available spot and reserves 1340 the spot for the vehicle identification number.
  • vehicle registration database 162 is either an existing external resource or a mirror DB.
  • DB mirroring contributes to a reduction in request processing time.
  • DB mirroring permits association of additional information with a vehicle registration number.
  • additional information is incorporated by compiling user profiles which include vehicle registration numbers.
  • method 1300 includes receiving 1350 at parking reservation server 120 additional size requirements and employing 1355 the additional size requirements in calculating 1330.
  • Additional size requirements include, but are not limited to, requests relating to temporary physical changes in vehicle dimensions (for example, a trailer attached to a pick-up truck or a semi-truck cab that is parking without a trailer) and/or to user preferences (for example, I need one and a half car lengths to parallel park).
  • method 1300 includes accessing 1360 a reservation history for the vehicle registration number (for example, by reservation server 120 querying event history DB 168) and transmitting 1370 a query concerning additional size requirements if a recent reservation from the same vehicle registration number included additional size requirements, for example, in a family with several drivers, a driver that recently received their license requests extra space every time they park a car with a certain vehicle registration number because they lack confidence. Other drivers of the same vehicle request only what is required according to calculating 1330 based on actual dimensions. In such a case system 100 transmits 1370 queries concerning additional space requirements each time the vehicle is parked until a threshold number of consecutive parking reservations are made with a negative response to the query 1370.
  • the threshold number of events is 3, 5, 10, 15, 20 or 25 or intermediate or greater numbers.
  • the query includes a "do not ask again" option which overrides the threshold.
  • server 120 identifies a specific user client device 122 from which additional size requirement requests originate and transmits 1370 only to that user client device.
  • calculating 1330 results in assembling 1380 two or more contiguous spots and/or parking subunits to create the appropriately sized parking spot prior to reserving 1340. In such cases the reservation is for a spot created from the two or more contiguous spots and/or parking subunits.
  • spot DB 164 stores parking subunits with dimensions that are too small for most vehicles to facilitate future assembly.
  • each vehicle for which parking is requested by a user has predetermined dimensions, as well as possible additional size requirements as described above.
  • the step of calculating 1330 typically includes determining the dimensions of available spots based on one or more groups of contiguous available subunits stored in spot DB 164 and comparing the vehicle size requirements the determined dimensions of the available spots. Either a complete available spot or a portion thereof, depending on the number of subunits corresponding to the vehicle size requirements, is then be allocated to the vehicle, and will be associated with the vehicle registration number in spot DB 164.
  • defragmentation algorithms/functions are applied to obtain optimal division of the available on vehicle dimensions and other parameters.
  • calculating 1330 includes dividing available parking spots based on vehicle dimensions.
  • additional parameters are also taken into account, such as the enlargement of a proposed parking spot for ease of access.
  • a typical case in which ease of access is a factor is proximity to a crowded street, whereat the available area from parking is divided more precisely than a similar parking area at a less busy location, so as to provide more, smaller parking spots at the expense of fewer, larger spots.
  • defragmentation algorithms/functions are applied to obtain optimal division of the available on vehicle dimensions and other parameters.
  • Fig. 4 is a simplified flow diagram of a method, indicated generally as 1400, for assembling an appropriately sized parking spot for each vehicle in a computerized parking management system according to some exemplary embodiments of the invention.
  • Depicted exemplary method 1400 includes storing 1410 a list of parking subunits by a parking reservation server (for example, 120 in Fig. 1) on a spot DB (for example, 164 in Fig. 1), each parking subunit associated with a unique identifier (UID) and location coordinates.
  • Depicted exemplary method 1400 also includes receiving 1420 a parking reservation request including a vehicle registration number at the server from a user client device (for example, 122 in Fig. 1) and ascertaining 1430 a size or dimension of said vehicle from its vehicle registration number.
  • ascertaining 1430 includes transmitting a request for information to an external data resource (for example, Department of Motor Vehicles database) and/or transmitting a request for information to DB 162 (Fig. 1) and/or a machine implemented review of a user profile.
  • an external data resource for example, Department of Motor Vehicles database
  • DB 162 Fig. 1
  • user profiles are stored in DB 162.
  • Depicted exemplary method 1400 also includes assembling 1440 a parking spot sized for the vehicle from two or more contiguous parking subunits and transmitting 1450 location coordinates of the parking spot sized for the vehicle to the user client device 122 (Fig. 1) as part of a reservation confirmation.
  • method 1400 includes associating 1460 the location coordinates of the parking spot sized for the vehicle with instructions to launch a navigation program on the user client device.
  • all of the parking subunits are same sized. In other exemplary embodiments of the invention, not all of the parking subunits are same sized.
  • Fig. 7a is a schematic representation, indicated generally as 1700, of differently-sized parking spots assembled from a requisite number of subunits 1710 to accommodate cars 1712 and a truck 1714.
  • the pavement is marked to indicate subunits 1710 which are too small to accommodate most vehicles.
  • server 120 Fig. 1
  • car-sized spots 1720 using two contiguous subunits 1710 to create each spot.
  • a truck-sized spot 1722 using three contiguous subunits 1710.
  • Fig. 5 is a simplified flow diagram of a method, indicated generally as 1500, for a user client assembly of parking subunits.
  • method 1500 includes transmitting 1510 a parking request including a vehicle registration number and a destination to a reservation server (for example, 120 in Fig. 1) from a user client device (for example, 122) and receiving 1520 a response at the user client device.
  • the response of 1520 includes a map 1522 of an area in proximity to the destination with available parking subunits indicated and a rectangle 1524 representing the vehicle by its registration number.
  • the vehicle size is indicated by the rectangle size according to a scale of the provided map.
  • the response serves as a GUI for assembly of two or more contiguous available subunits to create a correctly sized parking spot.
  • the GUI facilitates positioning 1530 the rectangle over two or more contiguous available subunits and issuing 1532 a confirm command to reserve the newly created correctly sized parking spot. Issuing 1532 of the confirm command is performed, for example, by double clicking on the rectangle while it is correctly positioned and/or using a voice command.
  • subunits are part of a parallel parking arrangement and/or are part of a non-parallel parking arrangement (for example angled or perpendicular).
  • the phrase "rectangle representing the vehicle defined by registration number” includes any rectangle or other shape having a similar length and/or width as the vehicle (scaled to map). This definition includes a line segment with a length corresponding to vehicle length or width.
  • Fig. 7b depicts a GUI exemplifying method 1500 according to some embodiments of the invention as described in the preceding paragraphs.
  • 1702 is a map of an area with available parking subunits indicated. Subunits which are unavailable are depicted as being occupied by vehicles. The only subunits in a contiguous array of two or more are 1730, 1731 and 1732.
  • 1740 represents the vehicle and the hollow arrow indicates positioning over subunits 1730 and 1731 (as opposed to 1731 and 1732).
  • the GUI is adapted for increasing 1540 (Fig. 5) a length and/or width of the rectangle to cover one or more additional subunits.
  • Fig. 7c depicts a GUI implementation of this optional feature on map 1702 as in Fig. 7b.
  • rectangle 1740 is expanded by addition of area 1742.
  • the hollow arrow indicates positioning over subunits 1730 and 1731 and 1732. As a result of the expansion of the rectangle, that is the only choice in this example.
  • Fig. 8A schematically illustrates that current parking solutions for parking on street 6112 include the use of equipment such as signs 6111 depicting use rule (e.g., parking rules) for the street 6112 and parking meters 6113.
  • equipment such as signs 6111 depicting use rule (e.g., parking rules) for the street 6112 and parking meters 6113.
  • use rule e.g., parking rules
  • currently used equipment is eliminated.
  • a street such as street 6112 is divided into parcels of land such as subunits 6222, each parcel of land having a unique identifier 6225.
  • Depicted exemplary system 6000 includes a database (DB) such as spot DB 164 (Fig. 1) of parcels of land or subunits 6222.
  • spot DB 164 includes at least the unique identifiers 6225.
  • system 6000 includes a command and control center (CCC) 151 which applies at least one use rule to a subunit 6222 or to several subunits.
  • CCC 151 applies a payment parking rule to some or all of the subunits, or CCC 151 applies a handicap vehicle only rule to some of the subunits.
  • CCC 151 applies any other rule and/or rule type to one or more subunits 6222.
  • system 6000 includes a user interface.
  • the UI is a GUI, for example GUI 6335.
  • Depicted exemplary GUI 6335 displays a rule in relation to the parcel of land.
  • GUI 6335 is available to a CCC 151 computer workstation. According to these embodiments, a user of the workstation sees the rules applied to each subunit. Current and/or past and/or future rules are displayed per subunit.
  • GUI 6335 is available on a warden's user client device, in some embodiments the warden's user client device is in communication with the CCC 151. According to these embodiments, a warden sees the rules applied to any specific subunit.
  • GUI 6335 is available on a user client device 122 (e.g., a driver's device or a kiosk running an application according to exemplary embodiments of the invention).
  • street 6222 is marked, e.g., by marking 6226, to advise drivers that the parcels of land 6112 are managed by CCC 151. In some embodiments other markings that are not necessarily on the street are used.
  • CCC 151 communicates with spot DB 164 via rule and spot manager 150 to apply a rule on a subunit 6222.
  • the rule is displayed on GUI 6335 at the CCC 151 or on GUIs of user client devices 122.
  • one or more rules to a subunit causes different subunits to be available for parking to different vehicles.
  • a driver using a method according to an embodiment of the invention is directed to a parking space (which may include one or more subunits) efficiently with no need for signs, meters or other equipment.
  • system 6001 includes a processor 6227 for calculating a parking spot using the parcels of land.
  • processor 6227 communicates with DB 164 and/or CCC 151 and/or with GUI 6335 (for example a GUI on user end device 122a of Fig. 1).
  • processor 6227 calculates a parking spot 6224 using subunits 6222a, 6222b and 6222c as basic units.
  • subunits 6222a, 6222b and 6222c are of equal size and a parking spot 6224 includes one or more contiguous subunits.
  • subunits 6222a, 6222b and 6222c are differently shaped and/or sized.
  • a single parking spot 6224 includes several contiguous subunits and is associated with several unique identifiers (e.g., by all unique identifiers 6225a, 6225b and 6225c making up the parking spot 6224 or by the unique identifiers 6225a and 6225c marking the boarders of the parking spot 6224).
  • calculating a parking spot 6224 is done by using suitable algorithms as described herein. For example, calculating a parking spot 6224 is based at least on vehicle size.
  • a parking spot calculated for a large vehicle e.g., a truck
  • a parking spot calculated for a small vehicle e.g., motorcycle
  • a different parking spot is calculated and displayed on GUI 6335 than when a request for parking a small vehicle is accepted at reservation server 120.
  • a GUI 6335 displaying a parking spot for a truck shows a parking spot identified as 6225a-6225c
  • a GUI 6335 displaying a parking spot for a motorcycle shows a parking spot identified as 6225a.
  • a smartphone e.g. using APPLE IOS or ANDROID OS
  • a tablet device e.g. using APPLE IOS or ANDROID OS
  • a wearable device e.g. APPLE watch or ANDROID wear
  • a personal computer e.g. laptop or desktop
  • an onboard computer in a vehicle e.g. 2G mobile phone, a conventional phone (operating through the public switched telephone network) and a kiosk serve as a user client device.
  • the onboard computer in a vehicle is selected from the group consisting of a portable device, a built in device in a standard (driver operated) car and a built in computer on an automatic (driverless car).
  • a smartphone or onboard computer interfaces with the system using software installed on the client device.
  • the system transmits information (for example, cues and/or options) to the client device for display on the screen of the client device and/or as audio output though a speaker of the client device.
  • a user input responses to the device using a touchscreen and/or by voice activation.
  • the system proceeds according to a default selection (for example, the first item in a list).
  • a smartphone or 2G phone transmits an SMS to a designated telephone number which serves as a system interface. Successive exchanges of information are conducted via SMS according to these embodiments.
  • a tablet device or a personal computer serves as a user client device.
  • exchanges between the user client and the system of information are, for example, via an internet portal operated by the system.
  • a smartphone or 2G phone or a conventional telephone places a telephone call to a designated telephone number which serves as a system interface.
  • exchanges of information are via an IVR (integrated voice response) system and/or a call center.
  • a dedicated kiosk serves as a user client device for users of the system that do not have another device available to them and/or to supplement another user client device employed to complete a portion of the reservation process.
  • a user that used their home telephone to reserve a parking spot via an IVR interface uses a kiosk in proximity to their assigned spot to notify the system when they arrive and depart from their assigned parking spot.
  • a parking attendant operates a user client device for users that do not have a device of their own.
  • the system identifies a vehicle based upon a user client device. For example, in some embodiments a phone number is associated with vehicle registration number in a user profile (e.g. stored in vehicle DB 162; Fig. 1). In those embodiments where a smartphone serves as a user client device, the phone number of the user client is available even if an incoming reservation request is via data network, as opposed to in the form of a telephone call.
  • a phone number is associated with vehicle registration number in a user profile (e.g. stored in vehicle DB 162; Fig. 1).
  • the phone number of the user client is available even if an incoming reservation request is via data network, as opposed to in the form of a telephone call.
  • system 100 includes, or has access to, a database of vehicle icons.
  • Icons are designed to convey information pertaining to general vehicle type and/or appearance (for example, car/truck/SUV) and/or specific vehicle type (for example, sedan/station wagon/coupe/hatchback) and/or manufacturer (for example, FORD, CHEVY, HONDA, MAZDA, TOYOTA) and/or model (for example, COROLLA, CAMRY) and/or model year (or sets of model years with distinctive design features) and/or other characterizing features, such as color or shape.
  • the icons are two dimensional or three dimensional.
  • the icons are empty line drawings and are filled with an appropriate color prior to use.
  • each icon is stored as multiple copies in different colors.
  • icons are stored in vehicle DB 162 as a portion of individual vehicle records or as a separate collection of information within the DB.
  • system 100 uses a UID and/or position coordinates of a specific parking spot to generate a visual representation of the spatial context of the parking spot.
  • the visual representation in digital format, is transmitted to a user client device 122.
  • user client device 122 is destined to the specific spot (for example, a smartphone or onboard computer).
  • the transmission of the visual representation is made as the relevant user client device approaches the spot.
  • a single fixed angle picture serves as the visual representation.
  • the visual representation is a virtual reality file which changes as the user client device moves relative to the assigned parking spot.
  • building faces from external sources are added to the visual representation.
  • the view on a user client device switches to perspective or street view as the device approaches the destination and/or an assigned parking spot.
  • the switch occurs when a proximity threshold is crossed.
  • the proximity threshold is defined in terms of distance and/or estimated arrival time.
  • this view switching indicates presentation of one or more additional views (for example, using a split screen or pop-up window).
  • a single fixed angle picture is presented as the "switched view" (for example, in a pop-up window).
  • Each rule includes one or more rule attributes.
  • a single rule includes 2, 3, 4, or 5 or more attributes.
  • multiple rules are applied to a given parking spot.
  • Exemplary rule attributes include, but are not limited to spot ownership type, temporal limitations (for example, days and/or hours during which the rule applies); user type limitations (for example, residents only), duration limitations (for example, maximum stay of 0.5, 1, 2 or 3 hours), and legal status.
  • rules include an hourly payment rate for the spot.
  • there are group rules such as of the 100 spots in this area 5 spots must always be available for handicap vehicles.
  • Fig. 6 is a table, indicated generally as 1600 illustrating an exemplary rule application scheme according to some embodiments of the invention.
  • a single spot number (5) is depicted in the leftmost column for clarity although the system is capable of applying rules, or changes to rule, to large numbers of spots concurrently.
  • second column from the left indicates priority or layer.
  • the highest priority, or top layer governs lower priorities or layers for spot(s) indicated in the leftmost column.
  • the second column from the right indicates parking scheme in terms of parking/no parking for vehicles and potential parking events matching all the attributes of the rule in the highest priority applicable layer.
  • the rightmost parking indicates price scheme in terms of free or fixed price for vehicles and potential parking events matching all the attributes of the rule in highest priority applicable layer.
  • the base layer excludes all vehicles at all times.
  • each successive layer adds permissions.
  • permissions are described in terms of rule attributes as detailed hereinabove and/or in terms of additional attributes and/or in terms of combinations of 2, 3, 4 or 5 or more attributes. Elevation considerations
  • elevation coordinates are used in some embodiments.
  • a UI displays level row and spot number on the display when the vehicle approaches the garage. Use of such a UI is advantageous in situations where tracking devices used in many smartphones do not function well, such as underground facilities.
  • some lots/garages are permitted to rent out spots, or blocks of spots, independently of the system in some embodiments.
  • garages accustomed to leasing blocks of spots to companies in an adjacent office building are unlikely to surrender this revenue stream in order to participate in the system.
  • the garage operator uses lot spot manager 153 (Fig. 1) to enter rules in rule and spot manager 150 (Fig. 1 indicating that the leased spots are either unavailable to any car at any time or are reserved for a specific vehicle identification number for the entire term of the lease.
  • rule making for spots within a parking lot or garage remains in the hands of owners (for example, for price determination) and/or be relegated to city control (for example, for traffic control purposes or load balancing) .
  • city control for example, for traffic control purposes or load balancing
  • different levels of priority for spaces in a lot/garage are given to owner and city.
  • pavement markings correspond to the UID assigned to a specific spot in spot DB 164.
  • shorter alphanumeric indicators such as a 2 or a 3 digit numeral and/or a single letter or two letter combination serve as pavement markings.
  • a relevant pavement marking is associated with each UID in spot DB 164 together with the location coordinates of the spot.
  • pavement marking may be used many times within an area under administration of system 100 (Fig. 1) confusion is unlikely so long as sufficient location information (such as a printed map or navigation instructions) is provided to each user client device that reserves a parking spot.
  • a "pavement marking" is applied to a sidewalk, curb, adjacent wall or sign instead of to a road surface.
  • user profiles are stored within system 100 (for example as part of Vehicle DB 162) and/or on user client devices 122.
  • user profiles are compiled and maintained by a user and/or are assembled by system 100 (for example from event history DB 168).
  • a user interface is provide, for example via an application installed on a user client device or via an Internet portal.
  • the user interface employs a username and/or password
  • a user interface for user profiles compiled and maintained by a user includes fields such as, for example "my vehicles” and/or “my devices” and /or “my destinations” and/or settings.
  • my vehicles includes a field for entry of one or more vehicle registration numbers.
  • my devices includes a field for one or more telephone numbers (mobile and/or VOIP and/or PSTN based numbers)
  • settings includes input options for user preferences. For example, radio buttons for "auto-select lowest price”, “auto-select closest spot to destination” and “show me options”. As an additional example radio buttons for "auto-select indoor spot if available”, “auto-select indoor spot if closest to destination” and "ask me every time if an indoor spot is required”.
  • the settings portion of the user interface contains input options for auto-select first item in list after 0, 5, 10, 15, 30 or 60 seconds or intermediate or greater times.
  • the settings portion of the user interface contains input options for maximum hourly rate.
  • "my destinations" includes input fields for home and work locations and/or user selected locations.
  • system 100 populates the "my destinations settings" using recent parking events in event history DB 168 associated with the user via a user client device 122 and/or one or more vehicle registration numbers.
  • Systems and methods described hereinabove contributes to a reduction in maintenance of physical infrastructure (for example, parking meters and/or parking regulation signs and/or access gate), as drivers are directed to a parking spot based on a GUI as exemplified in Fig. 7b.
  • systems and methods described hereinabove contribute to a reduction in supervision requirements (personnel and/or vehicles), for example, by use of violation system 130 in Fig.l.
  • systems and methods described hereinabove contribute to a reduction in over-payments and under-payments relative to parking meters, for example, by using history DB 168 in Fig. 1.
  • systems and methods described hereinabove contribute to increased utilization of both public and private parking resources and/or to increased flexibility in managing parking resources as a whole and/or individual parking spots by use of a method for customizing parking spots to size of vehicle as exemplified in Fig. 4.
  • systems and methods described hereinabove enable advance reservation of a specific spot even in on-street parking situations.
  • systems and methods described hereinabove do not require sensors installed in spots, although they are amenable to use in the context of sensor based systems.
  • System 100 manages previously un-regulated no-cost parking spots and can enforce regulations (e.g. parking duration time limits). In some embodiments enforcement of regulations on no-cost spots contributes to greater availability of these spots. Mapping and reservation of no-cost spots is as described hereinabove. This is done as shown and described above by mapping the no-cost parking spots and adding them to spot database 1641ike any other spot. In some embodiments this additional regulation contributes to a public perception of increased parking availability. Exemplary network communications
  • the networks include the internet and/or local area networks (for example, at a command and control center) and/or cellular communications networks (voice and/or data) and/or the public switched telephone network (PSTN).
  • the networks include the internet and/or local area networks (for example, at a command and control center) and/or cellular communications networks (voice and/or data) and/or the public switched telephone network (PSTN).
  • PSTN public switched telephone network
  • the regional authority is aware of the date of a special event which will disrupt traffic, weeks or even months ahead of the event. More specific details of the event and of the specific areas to be affected may not be known until much closer to the event.
  • CCC 151 prevents all parking reservations of the date of the event in the affected region well in advance.
  • This "blackout” status is imposed by implementing a rule in rule and spot manager 150 with "all drivers” and the date of the event” as attributes, "no parking” as the scheme assigning it the maximum priority (for example, 100) and applying it to all the spots in the affected region, in DB 164.
  • the blackout rule for the whole region can be gradually replaced by a set of rules which are geographically more specific and less exclusive to users wishing to park on the day of the event.
  • notices are sent to users (for example, subscribers and/or residents) informing them that their parking rights will be suspended for the day of the event.
  • Delivery trucks typically require oversized spots for short periods of time, for example, to load or unload merchandise.
  • the oversized spots are typically required along known routes, at known locations and/or at a known schedule.
  • trucks stopping to load or unload typically extend into the street causing slowdown of cars and traffic congestion.
  • a truck registration number is entered through user client device 122 and the truck registration number is transmitted from the parking reservation server 120 to vehicle registration DB 162 as exemplified in flowchart 1300.
  • the location of the truck may is known (e.g., based on GPS tracking of the user client device used for entering the truck registration number).
  • a pre-set additional size requirement is automatically employed 1355 for the truck registration number, resulting in calculation of an appropriately sized parking spot 1330 and automatic reservation 1340 of the spot, typically for a limited predetermined time period.
  • Fig. 7c in some embodiments business places want to reserve large enough parking spots near the business place for delivery trucks.
  • the owner of the store or other business subscribes to several contiguous parking sub units at the front of the store, for example, sub units 1730, 1731 and 1732, for certain days and for certain time slots on those days.
  • Venues such as sport stadiums typically have large parking areas which are filled to capacity during a sports event at the stadium but which are relatively empty at other times.
  • CCC 151 in order to provide more efficient utilization of a venue parking area, applies a rule of low rates or even free parking to all parking spots (or parking subunits) in the stadium area when there is no event in the stadium.
  • the venue parking area is, when there is no sports event, as a park & ride area (transportation hub) with shuttles running from the parking area to a regional or city center.
  • a parking spot in the venue parking area is suggested to drivers on the UI of user client device 122 in response to a user entering a destination in the city center.
  • rule change is applied to all spots in the stadium parking area through rule DB 166.
  • the rule change includes an increase in price and/or a limit on allowed parking duration.
  • system 100 offers a discount for advance reservations for event parking, which reservations are stored at spot DB 164.
  • system 100 encourages, or even requires, them to do so if an unauthorized vehicle is parked in a spot reserved for them. Spot reservation gives a sense of entitlement which makes reporting a violation seem more acceptable. Alternatively or additionally, if an unauthorized vehicle is parked in a spot reserved for a user, the user needs to report the event to the system in order to receive an alternate spot.
  • a user client device 122 is operated by a warden, for example, an officer of the municipality.
  • the UI of a user client device 122 used by a warden may typically include a map or other representation of a region showing available and non-available parking spots or subunits.
  • a warden may be referred to specific parking spots through violation system 130 and/or the warden may identify violations by comparing the map on his user client device 122 to the actual situation on-site.
  • Fig. 1 for example when system 100 is applied to a region such as a municipality which is transitioning from a current or default status in which municipal parking rules are posted on signs or painted on pavements and/or curbs the computerized system of Fig. 1 overrides the previously installed visual instructions, so long as the system is functioning. In some embodiments as long as the various communications networks of system 100 are in working order, then the only way to legally park in the city is through system 100.
  • predetermined default parking rules are available to all.
  • signs and painted markings may apply when the system is down (This is analogous to a stop sign at an intersection with a traffic light; the stop sign is in position for times when the traffic light does not function).
  • system 100 includes a backup database storing the city's "default” settings for each parking spot in a downfall situation.
  • "default" settings are available for download to a user client device for future use.
  • printed maps of the city's "default” settings may be posted on billboards, or in the printed or electronic media, and the like.
  • system 100 includes a queue management module managing (DB 172 in Fig. 1) a queue of parking requests.
  • parking requests are prioritized based on different parameters as described herein.
  • parking requests are prioritized based on a user's (e.g., driver's) reputation.
  • a driver's reputation is saved as part of a user profile. For example, in some embodiments a driver (represented by their user client device, e.g., UCD 122a) that repeatedly violates is given negative points by the queue management module whereas drivers that abide by the rules are given positive points.
  • a driver's reputation is based on the amount of positive and negative points accumulated in the queue management module.
  • a user's reputation is used to change the priority of a parking request in a queue, e.g., to offer better conditions (e.g., less waiting time) to a driver having more positive points and/or offer worse conditions to a driver having more negative points.
  • a warden is given a suggested route to check for violations using a map provided to the warden from CCC 151 (Fig. 1).
  • system 100 adjusts itself to "add" notifications when additional violations occur along the route and/or generate new routes which incorporate newly registered violations. In some embodiments, this feature contributes to an increase in the number of citations/unit time from a single warden.
  • a method includes providing suggested routes to a warden, e.g., the most efficient route for the warden to walk (or otherwise travel) to a parking spot of interest.
  • Parking spots of interest include, for example, parking spots due to expire in 5; 10; 15 or 20 minutes or smaller or intermediate periods of time and/or parking spots where a violation has been reported and/or other parking spots where a warden's checkup is desired.
  • the suggested route is based on a known location of the warden (e.g., based on the GPS location of the warden's user client device and/or based on known locations of parking spots of interest.
  • a warden is assisted by camera based or other sensors located and positioned along streets and other parking areas to monitor parking spots (e.g., by detecting and recording vehicle license plate numbers using OCR technology).
  • a warden uses the information provided by the camera and/or sensors to report status changes of parking spots and/or violations.
  • a route is suggested to the warden (as described above) based on the information provided by the sensors.
  • the suggested route is based on a known location of the warden (e.g., based on the GPS location of the warden's user client device and/or based on known locations of parking spots of interest.
  • a status of specific parking spots is updated in DB 164 (e.g., from "occupied” to "available") based on reports from user client devices (such as devices 122a or a warden's device).
  • the status of specific parking spots is updated in DB 164 based on input from a sensor located and positioned along streets and other parking areas to allow monitoring of parking spots.
  • the sensors include cameras and/or RFID tags located at each parking spot or parking subunit.
  • RFID tags are integrated into pavements or roads at each parking subunit.
  • RF readers in vehicles allow system 100 (Fig. 1) to identify vehicles (specifically which vehicles) that have entered or exited specific parking spots. Alternately RFID tags are located in vehicles and RF readers are located at parking spots.
  • method 3700 includes receiving 3740 a confirmation of parking in a reserved spot and/or of exiting a reserved spot based on input from a sensor monitoring the spot, such as an RFID sensor capable of communication with the system.
  • a sensor monitoring the spot such as an RFID sensor capable of communication with the system.
  • parcels of land or parking subunits are marked by painted markings (such as lines demarcating each parking subunit) on pavements or roads.
  • markings such as lines demarcating each parking subunit
  • other markings are used (e.g., in geographical regions suffering from harsh weather such as snow and fog), such as sign posts or other appropriate techniques.
  • each marking has an adjacent color painted (or otherwise applied) on the pavement/street.
  • the colors appear in a fixed sequence (eg. RGB - Red, Green Blue).
  • each identifying character or group of characters
  • has a corresponding color thereby making it easier to identify a parking spot (e.g., trying to identify a spot composed of subunit 244 Green or 42 Blue).
  • different sided sidewalks are painted in a different color or numbered (e.g., odd/even), facilitating identification of parking spots.
  • privately owned spots, or other off-street parking subunits are marked with similar markings as on-street parking subunits to facilitate identification of all parking spots within system (e.g. system 100).
  • privately owned spots, or other off- street parking subunits or spots are included in system 100, thereby enabling enforcement (e.g., by wardens) and other advantages of the system in privately owned and other off-street parking spots for the benefit of the off-street parking spot owners.
  • system 100 is backed up by mirroring servers and/or DBs in different location. If one of the servers crashes, incoming communications from UCDs 122 are directed to the mirror.
  • a procedure is initiated in which user client devices 122 are notified and are requested to manually switch or are automatically switched to off-line mode.
  • off-line mode devices receive parking rules and/or a driver parks using default parking rules.
  • additional features are provided. Additional features in this context include, but are not limited to billboards advising drivers of parking rules during system failure.
  • drivers continue to report arrival at a reserved parking spot and/or exit from the parking spot in offline mode.
  • offline mode reports are stored on the user client devices 122. Once system 100 is back up, reports stored in user client devices 122 are uploaded to system 100 and server 120 updates event history DB 168 with offline mode parking events. In some cases, by statistically analyzing the events (based on history analytics), the system determines how many events should have occurred and also how many were reported, thereby deriving the percent of "unreported" events.
  • the unreported events are accommodated by increasing an occupancy buffer to handle larger margins of error (e.g., if it is determined that only 80% of the actual parking events were reported, 20% extra free spaces can be left open to allow reallocation for people requesting spots that were occupied).
  • users park using unaffected functions of their devices, such as by using SMS messaging and/or Interactive voice response (IVR) and/or unaffected devices such as a kiosk or devices at call centers.
  • IVR Interactive voice response
  • basic vehicle details such as size and color may are pre-stored on user client device 122 to be used in case of failure of a DB at an external licensing authority from which vehicle DB 162 receives information regarding vehicle attributes.
  • vehicles parking for the first time during failure of an external licensing authority DB are required to enter one or more details (e.g., by choosing a vehicle size from a list of several, e.g., 3 size categories and color from a list of colors) in order to reserve parking via system 100.
  • a driver uses maps available from a kiosk or another navigating systems or is directed by an operator at a call center.
  • payment is achieved by other methods such as by paying at a kiosk or by mail.
  • Fig. 9 is an exemplary flow chart illustrating operation of a parking spot management system, according to some embodiments of the invention.
  • system 100 stores a size attribute of the vehicle, which may list how many parking subunits (also referred to as slots) the specific vehicle requires, and a slot record may list the adjacent component parking slot(s) to the current component parking slot. In one embodiment, only one adjacent component slot, the one to the left, for example, of the current component slot, is stored.
  • Fig. 9 illustrates a BuildSizeAwareList function, given a suggestion list
  • SuggestionListl of possible component slots and vehicle information, to determine if a group of neighboring slots is available to a current component slot.
  • Suggestion list builder 110 may loop (step 7401) on each component slot in the SuggestionList and may, in step 7410, initially set a COMPONENT SLOT2 variable to the current component slot and a TOTALSIZE variable to the size of the current component slot.
  • step 7412 a check is made whether the current TOTALSIZE is larger than the vehicle size. If it is not, a loop is entered which will continue until the check is positive.
  • a LEFTCOMPONENT SLOT variable will be set (step 7414) to the adjacent component slot of the COMPONENT SLOT2 component slot, which, as described hereinabove, is to the left of the COMPONENT SLOT2 component slot.
  • step 7416 if the LEFTCOMPONENT SLOT is not in SuggestionListl (i.e. it was not available when SuggestionListl was made) or if it is Null, then the loop returns to step 7401 for the next component slot. Otherwise (i.e. the LEFTCOMPONENT SLOT is not Null and is in SuggestionListl), then, in step 7418, its size of LeftComponent slot is added to TOTALSIZE and LeftComponent slot becomes the new COMPONENT SLOT2. The loop returns to step 7412 to see if the current TOTALSIZE is larger than the vehicle size. The process may continue the loop until TOTALSIZE is larger than the vehicle size (i.e.
  • the sum of the sizes of the adjacent component slots in SuggestionList from the initial component slot is larger than the vehicle size). For example, if the vehicle size is slightly smaller than 2 small component slots, the loop will have repeated once before TOTALSIZE was larger than the vehicle size. If the vehicle size is slightly smaller than 3 small component slots, the loop will have repeated twice before TOTALSIZE was larger than the vehicle size.
  • the visited component slots may be added, as a single dynamic spot, to a new list, Suggestion List2.
  • the single dynamic spot may be defined in any suitable way, such as by the first spot in the list.
  • Fig. 9 may find groups of slots that are currently available. However, these slots may be allocated inefficiently and may leave many small component slots unused.
  • Fig. 10 is an exemplary flow chart of a method to increase the efficient use of the component slots, , according to an embodiment of the present invention.
  • Operation of the parking space management system may include implementing best-fit or other suitable allocation algorithms, and which may include fragmentation and defragmentation algorithms.
  • a user in a vehicle occupying a dynamic parking spot composed of several component parking subunits may notify the parking spot management system of his intended departure, and following the notification, may depart.
  • the parking spot management system looks for contiguous component parking slots. It determines the number of component parking slots vacated by the departed vehicle and calculates the number of available component slots adjacently located to the recently vacated component slots.
  • the parking spot management system selects a vehicle from its queue of vehicles seeking a parking spot in a region or in the vicinity of the region.
  • the selection rules for the vehicle may vary according to the automated parking spot allocation system being used but should include information regarding the size of the vehicle, such as the number of component parking slots the vehicle requires, in order to determine if the vehicle fit into the available and contiguous component parking slots. If not, the vehicle is rejected and a new vehicle is selected from the queue.
  • the parking spot management system may give priority to a specific vehicle requesting a parking spot in a region or in the area of the region. For example, if not all vehicles can be accommodated in the available component parking slots, dynamic parking spots will be evaluated and assigned in order of priority and/or vehicles which fit the available dynamic parking spots may be assigned the slots irrespective of the priority they have.
  • the rules for determining priority may vary according to the automated parking spot allocation system used.
  • the parking spot management system determines all combinations of available and contiguous component parking slots that can accommodate the size of the vehicle selected from the queue. The parking spot management system may then decide on an allocation method to use, a known allocation method at 7210, or a defragmentation method at 7212.
  • the parking spot management system may use the known allocation method which may include the execution of a best fit allocation algorithm or other known allocation method, including fragmentation methods, to allocate a spot to the selected vehicle.
  • the known allocation method may attempt to fit all vehicles into any parking spot within all available and contiguous component parking slots whose combined size is the same or larger than the vehicle size.
  • the known allocation method may also take into consideration conditions associated with the selection rules of the automated parking spot allocation system.
  • the parking spot management system may use the defragmentation method to allocate spot to the selected vehicle.
  • the user is notified that there is a parking spot in a region, and the identity of the component slots forming the dynamic spot allocated to the vehicle.
  • the method of notification may vary according to the automated parking spot allocation system being used.
  • these and other algorithms and methods of allocation may be used to further optimize utilization of the parking area.
  • features used to describe a method can be used to characterize an apparatus and features used to describe an apparatus can be used to characterize a method.
  • the invention has been described in the context of parking but might also be used as a traffic control system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Traffic Control Systems (AREA)
  • Navigation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé consistant à : (a) transmettre un numéro d'immatriculation de véhicule d'un serveur de réservation de stationnement à une base de données d'enregistrement de véhicules ; (b) recevoir les dimensions du véhicule au niveau du serveur de réservation de stationnement en réponse à la transmission ; (c) calculer une taille d'emplacement de stationnement d'après les dimensions du véhicule ; et (d) réserver un emplacement de stationnement de taille appropriée d'après les résultats du calcul.
PCT/IL2016/050239 2015-08-27 2016-03-02 Système et procédé de création d'emplacement de stationnement modulaire WO2017033172A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
PCT/IB2015/056512 WO2016046665A1 (fr) 2014-08-27 2015-08-27 Système et procédé de stationnement individuel et régional
IBPCT/IB2015/056512 2015-08-27
PCT/IB2015/056509 WO2016030854A1 (fr) 2014-08-27 2015-08-27 Système et procédé de gestion d'espace de stationnement
IBPCT/IB2015/056509 2015-08-27

Publications (1)

Publication Number Publication Date
WO2017033172A1 true WO2017033172A1 (fr) 2017-03-02

Family

ID=58107880

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/IL2016/050240 WO2017033173A1 (fr) 2015-08-27 2016-03-02 Système et procédé de création d'une place de stationnement dynamique
PCT/IL2016/050241 WO2017033174A1 (fr) 2015-08-27 2016-03-02 Système et procédé de réservation de stationnement à l'échelle de la ville
PCT/IL2016/050239 WO2017033172A1 (fr) 2015-08-27 2016-03-02 Système et procédé de création d'emplacement de stationnement modulaire

Family Applications Before (2)

Application Number Title Priority Date Filing Date
PCT/IL2016/050240 WO2017033173A1 (fr) 2015-08-27 2016-03-02 Système et procédé de création d'une place de stationnement dynamique
PCT/IL2016/050241 WO2017033174A1 (fr) 2015-08-27 2016-03-02 Système et procédé de réservation de stationnement à l'échelle de la ville

Country Status (1)

Country Link
WO (3) WO2017033173A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200197791A1 (en) 2017-06-16 2020-06-25 Honda Motor Co., Ltd. In-vehicle performance device, in-vehicle performance system, in-vehicle performance method, storage medium, and command measurement device
US11069239B2 (en) * 2017-06-16 2021-07-20 Honda Motor Co., Ltd. Event vehicle dispatch device, event vehicle dispatch method, program, and management system
US20210304081A1 (en) * 2020-03-30 2021-09-30 Honda Motor Co., Ltd. Accommodation area management device
US11586223B2 (en) 2017-06-16 2023-02-21 Honda Motor Co., Ltd. Vehicle and service management device
CN116153134A (zh) * 2023-03-02 2023-05-23 阿维塔科技(重庆)有限公司 一种车位推荐方法、装置及计算机可读存储介质
US11794816B2 (en) 2017-06-16 2023-10-24 Honda Motor Co., Ltd. Automated driving vehicle

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107481332A (zh) * 2017-06-19 2017-12-15 深圳市盛路物联通讯技术有限公司 一种基于移动网络的停车收费方法及系统
DE102018005761A1 (de) * 2018-07-20 2020-01-23 Daimler Ag Verfahren zum Parken eines Fahrzeugs
US11250363B2 (en) 2018-11-02 2022-02-15 Cornell University Resource allocation using scalable non-myopic atomic game for smart parking and other applications

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140372155A1 (en) * 2013-06-14 2014-12-18 Xerox Corporation System and method for parking reservation and finding parking space suitable for user's vehicle size
US20150066545A1 (en) * 2013-09-03 2015-03-05 Verizon Patent And Licensing Inc Mobile parking systems and methods for providing real-time parking guidance

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040068433A1 (en) * 2002-09-23 2004-04-08 Eximsoft International Parking system with centralized reservation, payment and enforcement
US8799037B2 (en) * 2010-10-14 2014-08-05 Palto Alto Research Center Incorporated Computer-implemented system and method for managing motor vehicle parking reservations
US8791838B2 (en) * 2012-04-10 2014-07-29 Inrix, Inc. Parking resource management

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140372155A1 (en) * 2013-06-14 2014-12-18 Xerox Corporation System and method for parking reservation and finding parking space suitable for user's vehicle size
US20150066545A1 (en) * 2013-09-03 2015-03-05 Verizon Patent And Licensing Inc Mobile parking systems and methods for providing real-time parking guidance

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200197791A1 (en) 2017-06-16 2020-06-25 Honda Motor Co., Ltd. In-vehicle performance device, in-vehicle performance system, in-vehicle performance method, storage medium, and command measurement device
US11069239B2 (en) * 2017-06-16 2021-07-20 Honda Motor Co., Ltd. Event vehicle dispatch device, event vehicle dispatch method, program, and management system
US11586223B2 (en) 2017-06-16 2023-02-21 Honda Motor Co., Ltd. Vehicle and service management device
US11691070B2 (en) 2017-06-16 2023-07-04 Honda Motor Co., Ltd. In-vehicle performance device, in-vehicle performance system, in-vehicle performance method, storage medium, and command measurement device
US11794816B2 (en) 2017-06-16 2023-10-24 Honda Motor Co., Ltd. Automated driving vehicle
US20210304081A1 (en) * 2020-03-30 2021-09-30 Honda Motor Co., Ltd. Accommodation area management device
CN116153134A (zh) * 2023-03-02 2023-05-23 阿维塔科技(重庆)有限公司 一种车位推荐方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
WO2017033173A1 (fr) 2017-03-02
WO2017033174A1 (fr) 2017-03-02

Similar Documents

Publication Publication Date Title
US20170018183A1 (en) System and method of creating a dynamic parking spot
US20160371607A1 (en) Citywide parking system and method
US20160180712A1 (en) Citywide parking reservation system and method
US20160180261A1 (en) System and method of creating a dynamic parking spot and a system and method of creating a dynamic parking zone\region
WO2017033172A1 (fr) Système et procédé de création d'emplacement de stationnement modulaire
US11011058B2 (en) Computer-implemented system and method for providing available parking spaces
US10692375B1 (en) Lotless storage of vehicle inventory
US11587193B2 (en) Smart vehicle parking apparatus and related methods
US9418553B2 (en) Easy parking finder
US20170140586A1 (en) Vehicle parking system and method
Giuffrè et al. A novel architecture of parking management for smart cities
JP6139504B2 (ja) 駐車管理システムと方法
EP2711875A1 (fr) Système et procédé informatique permettant de commander des espaces de stationnement interchangeables
WO2017033066A1 (fr) Système et procédé de stationnement dans toute la ville
Rye et al. Parking management
WO2016148560A1 (fr) Système et procédé permettant de trouver et de localiser un espace de stationnement disponible à l'intérieur d'une zone
Shoup Learning from parking reforms in other cities
Jioudi et al. e-parking: Multi-agent smart parking platform for dynamic pricing and reservation sharing service
KR20170136451A (ko) 개인 선호도에 기반한 복합 교통수단 정보를 제공하는 장치 및 방법
US20210082078A1 (en) The system and method of operating the self-steering electric taxi and smart underground parking lots
US20200236787A1 (en) Parking management system
Sharma et al. Problem of parking and their possible solutions with special reference to Kota City
CN108777073A (zh) 一种城市停车诱导系统、服务器及诱导方法
Ison et al. Parking
Mason E-Scooters in Eugene, Oregon: Recommendations for Regulations

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: 16838663

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 05/05/18 )

122 Ep: pct application non-entry in european phase

Ref document number: 16838663

Country of ref document: EP

Kind code of ref document: A1