WO2017033066A1 - Système et procédé de stationnement dans toute la ville - Google Patents

Système et procédé de stationnement dans toute la ville Download PDF

Info

Publication number
WO2017033066A1
WO2017033066A1 PCT/IB2016/051193 IB2016051193W WO2017033066A1 WO 2017033066 A1 WO2017033066 A1 WO 2017033066A1 IB 2016051193 W IB2016051193 W IB 2016051193W WO 2017033066 A1 WO2017033066 A1 WO 2017033066A1
Authority
WO
WIPO (PCT)
Prior art keywords
parking
spot
spots
client device
reservation
Prior art date
Application number
PCT/IB2016/051193
Other languages
English (en)
Inventor
Itamar ROSEN
Haim Yosef GOTLIEB
Orri BEN-NATHAN
Elimelech Weissberg
Shai Yagur
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.
Priority claimed from US15/058,766 external-priority patent/US20160180712A1/en
Priority claimed from US15/058,245 external-priority patent/US20160180261A1/en
Publication of WO2017033066A1 publication Critical patent/WO2017033066A1/fr
Priority to IL257752A priority Critical patent/IL257752A/en

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems
    • G—PHYSICS
    • 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/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • 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/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • 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/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • the invention is in the field of parking systems.
  • a shortage of available parking spots is caused by a finite total area of often valuable real estate in city centers set aside for parking, as well as an inefficient use of this resource.
  • many drivers park so as to occupy more than a single spot, and drivers of large vehicles are often unable to find parking of suitable size.
  • an individual driver may have difficulty finding parking, thereby wasting precious time and money.
  • Embodiments of the invention provide a tool for drivers which increases parking efficiency while decreasing parking effort. This reduces wasted time and money for the driver, as well as pollution, infrastructure costs and other damage for the city.
  • systems and methods according to embodiments of the invention provide efficient utilization of space, increasing the space available for parking in the city and providing better control of parking facilities for the city and parking owners.
  • Embodiments of the invention provide tools for municipalities to respond efficiently to changes affecting the urban space, thereby enabling solutions where there are none and reducing the often significant resources required in dealing with these changes (e.g., policing and directing traffic).
  • embodiments of the invention facilitate valid parking, namely, parking that does not violate parking regulations.
  • embodiments of the invention save an individual driver time and money.
  • congestion which is caused by uninformed (and thus hesitant) drivers typically slowing down while trying to determine the rules of a parking spot, may be significantly reduced.
  • 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.
  • 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 stand-alone 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).
  • 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 incorporation of off street parking spots into a reservation system for on street parking spots.
  • the off street spots include privately owned individual spots and/or parking lots and/or parking garages.
  • Another aspect of some embodiments of the invention relates to flexible queue management for reservations of individual parking spots.
  • the system or a user thereof operating a user client device, makes an initial selection of an individual parking spot and is offered a spot which is closer to destination or has a lower hourly rate after the initial selection is made.
  • Another aspect of some embodiments of the invention relates to proximity based queue management of reservations for individual parking spots.
  • the system provides information pertaining to one or more individual parking spots to a user client device when a threshold proximity to destination is crossed.
  • the system processes a bulk order for a future date.
  • the bulk order defines a future time and/or a number of spots required and/or a desired parking duration and/or a start time and/or destination and/or a maximum distance from therefrom.
  • a map indicating current status of parking spot is employed by parking wardens to detect violations and/or by users to locate a spot assigned to them.
  • the map provides context information for one or more spots.
  • the context information pertains to off street landmarks and/or cars currently parked in one or more adjacent spot.
  • the context information is provided as text and/or audio cues and/or pictorially.
  • a tracking component of a user client device indicates to the system what portion of the map is relevant to that user client device.
  • Another aspect of some embodiments of the invention relates to use of a publicly available kiosk to provide a map indicating an available spot reserved in response to an order placed from the kiosk.
  • the map includes navigation cues from the kiosk to the reserved spot.
  • the map is provided as a printout or as a digital file available for transfer to a device in proximity to the kiosk.
  • vehicle attributes include physical characteristics (e.g. engine type or required rear or side clearance) and status characteristics (e.g. handicap or resident).
  • status characteristics e.g. handicap or resident.
  • spot feature is a fixed physical item like an electric charger, rear or side lift clearance underground/open air (Many jurisdictions do not allow liquid propane powered vehicles to park in enclosed structures).
  • Another aspect of some embodiments of the invention relates to disregarding spots which are close to vehicle, but would be difficult to for that vehicle to reach when reserving a spot for the vehicle.
  • Another aspect of some embodiments of the invention relates to suggestion of an alternate desti8nation in response to a request for a parking spot which includes an input destination.
  • the alternate destination is in the same category as the input destination (e.g. substitution of one shopping mall for another; substitution of one supermarket for another supermarket in the same chain or substitution of one supermarket for another supermarket in a different chain but located in proximity to the input destination).
  • the alternate destination is a transportation hub providing public transportation service to a stop in proximity to the input destination.
  • Another aspect of some embodiments of the invention relates to identifying parking preferences for a vehicle from a history of parking events associated with the vehicle and employing those preferences in processing a reservation.
  • Another aspect of some embodiments of the invention relates to provision of an alternate specific parking spot when there is a problem with an initially assigned parking spot.
  • the problem is that the initially assigned spot is occupied by another car.
  • the problem is a physical impediment to use other than a parked car (e.g. fallen tree, garbage dumpster, standing water or snow).
  • 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.
  • One aspect of some embodiments of the invention relates to user interfaces for centralized management of parking regulations.
  • the user interfaces are graphical.
  • Another aspect of some embodiments of the invention relates to user interfaces for analysis of usage statistics for subsets of parking spots managed by a computerized system.
  • the subsets are defined by delimiting an area on a map (for example, using a finger or stylus on a touch screen or using a mouse or trackpad on a non-touch screen).
  • each zone contains parking spots managed by a common computerized system.
  • occupancy rate (occupied spots plus reserved spots)/total spots).
  • parking rules for a zone are changed as a maximum occupancy rate is approached.
  • Another aspect of some embodiments of the invention relates to maintaining a database of individual parking spots with at least three designations for each spot: Occupied, Reserved and Available.
  • a fourth designation, Violation is used to indicate a spot occupied by an unauthorized vehicle
  • a system including a database of individual on-street parking spots, and individual off-street parking spots, each of the individual parking spots associated with a unique identifier (UID) and location coordinates; and an off street spot management module in communication one or more external client devices, adapted to receive parking rules from an external client device operated by an owner of each of the individual off-street parking spots.
  • the system includes a location definition module adapted to receive location coordinates defining a specific individual off-street parking spot from one of the one or more external client devices, assign a UID to the location coordinates to create an individual spot definition and add the spot definition to a spot database.
  • the system includes a cue management module adapted to receive cue information to be used in guiding a vehicle to a specific individual off-street parking spot and associate the cue information with the specific spot in a spot database.
  • the off street spot management module resides on a reservation server.
  • the off street spot management module resides on an external client device adapted to communicate with a reservation server.
  • at least some of the individual off-street parking spots are privately owned.
  • a system including a database of individual parking spots, each of the individual parking spots associated with a unique identifier (UID) and location coordinates and a current availability status; a reservation management server adapted to receive user parking requests from user client devices, each request including a destination; a suggestion engine adapted to transmit prompts including hourly parking rate and distance from destination for parking spots to the user client devices at least until an order is received at the server from the user client device or the request is cancelled by the user client device; and a reservation engine that transforms the order into a reservation by changing an availability status of an ordered spot to not available.
  • UID unique identifier
  • a suggestion engine adapted to transmit prompts including hourly parking rate and distance from destination for parking spots to the user client devices at least until an order is received at the server from the user client device or the request is cancelled by the user client device
  • a reservation engine that transforms the order into a reservation by changing an availability status of an ordered spot to not available.
  • the suggestion engine continues to transmit additional prompts after the order is received; each additional prompt having a shorter distance to destination and/or a lower hourly parking rate than the order; and wherein the reservation engine transforms a new order into a reservation and cancels a previous order received from a same user client device upon selection of one of the additional prompts from the user client device.
  • the system includes a cancellation management module adapted to receive cancellation requests from a user client device, and cancel a previous request or order made by the user client device.
  • the prompts include additional information.
  • the additional prompts indicate individual spots which were not available when the parking request was received.
  • a system including a database of individual parking spots, each of the individual parking spots associated with a unique identifier (UID) and location coordinates and a current availability status; a reservation management server adapted to receive user parking requests from user client devices coupled to a position tracker via a network, each request including a destination; a tracking engine monitoring progress of each position tracker towards the destination defined in the request from the client device coupled thereto and issuing a push signal when a threshold proximity to destination is crossed; and a suggestion engine responding to the push signal by transmitting a location of at least one individual parking spot to the user client device as a spot suggestion.
  • UID unique identifier
  • a reservation management server adapted to receive user parking requests from user client devices coupled to a position tracker via a network, each request including a destination; a tracking engine monitoring progress of each position tracker towards the destination defined in the request from the client device coupled thereto and issuing a push signal when a threshold proximity to destination is crossed; and a suggestion engine responding to the push signal by transmitting a
  • the suggestion engine transmits only one spot suggestion and reservation management server transforms the suggestion to a reservation.
  • the system includes a user profile, wherein the suggestion engine chooses the one spot based on the user profile.
  • the suggestion engine transmits several spot suggestions to the user client device and a choice is received at the reservation management server from the user client device.
  • the threshold is defined in in terms of distance from destination.
  • the threshold is defined in in terms of estimated arrival time.
  • the threshold includes maximum speed as second variable.
  • a method including receiving at a reservation management server from a user client device a bulk parking order for a future time, the bulk parking order defining a number of spots required, a desired parking duration, a start time, destination and a maximum distance therefrom; responding to the bulk parking order by transmitting a map of available parking spots at the future time for the desired parking duration from the start time and within the maximum distance from the destination to the user client device; receiving at the reservation management server an order indicating specific spots on the map and transforming the bulk parking order to a bulk parking reservation for the indicated spots.
  • the method includes returning to the user client device a redemption token.
  • a maximum amount of time in the future the bulk parking order can be made varies as a function of the number of spots defined by the order.
  • the method includes providing an invitation redemption portal adapted to assign specific vehicle registration numbers to the specific spots defined in the bulk parking reservation.
  • a method including receiving, at a reservation management server, a query including location coordinates from a tracking component in a user client device equipped with a display; responding to the query by transmitting a portion of a map including the location coordinates, the map depicting parking spots and indicating for each spot whether its current status in the system is occupied, empty or reserved; the map displayable on the display.
  • the method includes displaying a vehicle registration number of car that ordered a spot for each spot indicated as reserved on the map.
  • the method includes populating the spots on the map indicated as occupied with virtual reality depictions of relevant cars.
  • the method includes populating the spots on the map indicated as reserved with virtual reality depictions of relevant cars. Alternatively or additionally in some embodiments the method includes displaying text describing relevant cars in association with the spots on the map indicated as occupied. Alternatively or additionally in some embodiments the method includes presenting the map on the user client device in perspective view. Alternatively or additionally in some embodiments the method includes updating the map as the location coordinates of the user client device change. Alternatively or additionally in some embodiments the method includes updating the map as the current status of one or more spots changes. Alternatively or additionally in some embodiments the method includes receiving at the reservation management server a status change input from the user client device and updating a status of the spot in accord with the input.
  • the input switches a status of an individual spot to occupied.
  • the input switches a status of an individual spot from occupied to vacant.
  • a method including transmitting location information for a specific parking spot from a parking reservation management server to a user client device; and transmitting supplementary context information about the specific parking spot from the server to the user client device.
  • the supplementary context information includes location information.
  • the method includes monitoring proximity of the user client device to the specific spot and transmitting the supplementary context information when a proximity threshold is crossed.
  • the supplementary context information describes a car in at least one flanking spot.
  • the supplementary context information describes an off street landmark.
  • the supplementary context information is provided as text.
  • the supplementary context information is provided as audio.
  • the supplementary context information is provided as a virtual reality representation of car currently parked in at least one flanking spot.
  • the method includes providing navigation instructions to the location defined by the location information.
  • a parking kiosk including a user interface component accepting a vehicle registration number as an input; a request generator that that transmits the vehicle registration number to a parking reservation management server which assigns a specific parking spot to the vehicle registration number and generates a digital file encoding a map including navigation cues from the kiosk to the assigned spot and transmits the digital file back to the kiosk; and a map delivery apparatus.
  • the map delivery apparatus includes a printer that prints out the map encoded by the digital file.
  • the map delivery apparatus includes a data port for transmission of the map to an external device.
  • the kiosk includes a camera positioned to capture an image of a user of the user interface component.
  • the user interface component of kiosk accepts confirmation of parking and/or exit.
  • the kiosk includes a payment mechanism.
  • the kiosk is connected to a server via a wired network connection.
  • the request includes a vehicle identification number and the determining includes retrieval of data from a vehicle DB.
  • the request includes a user identification and the determining includes retrieval of a user profile including attributes of the vehicle.
  • the vehicle attributes include physical characteristics.
  • the vehicle attributes include status characteristics.
  • the request includes a destination.
  • the request includes a user preference.
  • a method including receiving at a reservation management server a request to park including a destination from a user client device; compiling a list of available spots ahead of the user client device based on a current position and available travel direction of the user client device; and transmitting at least position coordinates of least one spot on the list to the user client device.
  • a method including receiving at a reservation management server a request to park from a user client device, the request including a destination; determining a category for the destination; and transmitting to the user client device a set of suggested parking spots including at least one parking spot at an alternate destination in the destination category.
  • the determining includes a keyword analysis of the destination.
  • the destination includes a street address and the determining includes a query to a directory to determine what is at the address.
  • each parking spot in the set of suggested parking spots is characterized in terms of estimated wait time for availability.
  • the method includes analyzing the request to determine whether a stop for any public transportation route proving service from the hub is in proximity to the destination.
  • the method includes including in the prompt information on how much closer to the destination the stop is than the available parking spot closest to the destination.
  • the method includes including in the prompt information on how much money is potentially saved by using public transportation from the hub.
  • the method includes including in the prompt information on how much time is potentially saved by using public transportation from the hub.
  • a method including receiving a parking request including a vehicle registration number at a parking reservation server; accessing parking history for the vehicle registration number; identifying at least one parking preference in the history; and transmitting one or more suggested parking spots to a user client device, accompanied by data pertaining to each identified preference for each spot.
  • the request includes a destination.
  • the transmitting is of a single parking spot reserved for the vehicle registration number.
  • the parking history incudes duration of previous parking events for the destination.
  • the history includes destinations defined for previous parking events.
  • the method includes constructing a user profile based on the at least one preference.
  • a method including transmitting a reservation for an initial parking spot to a user client device from a reservation management server in response to a parking request; receiving a problem notification related to the initial parking spot from the user client device at the server; and responding to the problem notification by transmitting a reservation for an alternate parking spot to the user client device.
  • the method includes dispatching a service resource to the initial parking spot to evaluate the problem notification.
  • the method includes suspending further reservations for the initial parking spot until a problem of the problem notification is resolved.
  • a method including receiving a parking request from a first user client device at a reservation management server; storing a reservation of a parking spot in response to the request; receiving a request for details of the reservation from a second user client device.
  • the method includes receiving a confirmation of parking in a spot reserved by the reservation.
  • the method includes receiving an exit notification for the parking spot.
  • a user client apparatus including a calendar reader that reviews entries in a digital calendar and prompts the user for confirmation that one or more future events presented in a list is a current destination and; a destination modification module that prompts the user for a parking reservation request and, upon confirmation issues the parking reservation request to a reservation management server via a network.
  • the apparatus includes a mapping module displaying current position on a map based upon output from a tracking device in communication with an external navigation resource.
  • the external navigation resource includes a GNSS system (Global Navigation Satellite System).
  • the external navigation resource includes at least one network communication station.
  • 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.
  • 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.
  • a system including a reservation server receiving reservation input, parking confirmation input and parking exit input from at least one user client device; and a parking spot status database in communication with the server and configured to assign to each spot in the database a status selected from a group including at least available, reserved and occupied in accord with the inputs received by the server.
  • the system includes a mapping engine adapted to produce map output data for each spot.
  • the system includes a reservation nesting module adapted to identify incoming reservation inputs with a defined parking duration and match them with spots that have a current status of available and a reserved status at a time that is further in the future than a present time plus the defined parking duration.
  • a system including a database of individual spots, each of the individual parking spots associated with a unique identifier (UID) and location coordinates; at least one computer workstation adapted to display a map; and a graphical user interface (GUI) operable on the workstation, the GUI adapted to receive a map area selection as a first input and at least one parking rule as a second input and apply the at least one parking rule to all of the parking spots with location coordinates in the map area.
  • the workstation displays the individual on-street parking spots on the map.
  • the workstation displays a current status of each of the individual on-street parking spots on the map.
  • the second input includes a temporal limitation. Alternatively or additionally in some embodiments of the system, the second input includes a duration limitation. Alternatively or additionally in some embodiments of the system, the duration limitation is dependent on at least one additional factor. Alternatively or additionally in some embodiments of the system, the second input includes a user limitation. Alternatively or additionally in some embodiments of the system, the second input includes a vehicle type limitation. Alternatively or additionally in some embodiments of the system, the second input relates to a group of the individual on-street parking spots.
  • the second input relates to at least two members of the group consisting of a temporal limitation, a duration limitation, a user limitation, a vehicle type limitation and a limitation which relates to a group of the individual parking spots.
  • the system includes a second input UI adapted to accept layers of rules.
  • a system including a database of individual parking spots, each of the individual parking spot associated with a unique identifier (UID) and location coordinates; at least one computer workstation adapted to display a map; and a user interface (UI) operable on the workstation, the UI adapted to receive a display of data of spots located in a geographical area as a first input and at least one parking rule as a second input and apply the at least one parking rule to all of the parking spots with location coordinates in the geographical area.
  • the database includes on street and off street spots.
  • the database includes indoor spots.
  • the data display includes a table and/or a list.
  • a system including a database of individual parking spots, each of the individual parking spots associated with a unique identifier (UID) and location coordinates; at least one computer workstation adapted to display a map; a graphical user interface (GUI) operable on the workstation, the GUI adapted to receive a map area selection as a first input and at least one usage statistic as a second input; and an analytic module adapted to produce an output status report including at least one usage statistic for the parking spots with location coordinates in the map area.
  • the at least one usage statistic indicates percentage of spaces currently occupied.
  • the at least one usage statistic indicates percentage of spaces currently reserved and current average reservation time.
  • the at least one usage statistic indicates percentage of spaces currently reserved for a future time and average reservation time for the future time. Alternatively or additionally in some embodiments of the system, the at least one usage statistic indicates percentage of spaces currently in violation of parking rules.
  • an output status report depicts one or more usage statistics as a function of time. Alternatively or additionally in some embodiments of the system, at least some of the individual spots are on street spots. Alternatively or additionally in some embodiments of the system, an output status report depicts one or more usage statistics based on different rules applied to the map area.
  • a system including a database of individual on-street parking spots, and individual off-street parking spots, each of the individual parking spots associated with a unique identifier (UID) and location coordinates; and an off-street spot management module in communication one or more external client devices, the off -street spot management module adapted to receive parking rules for an individual parking spot from an external client device operated by an administrator of an individual parking spot.
  • the system includes a location definition module adapted to receive location coordinates defining a specific individual off-street parking spot from one of the one or more external client device, assign a UID to the location coordinates to create an individual spot definition and add the spot definition to the spot database.
  • the system includes a cue management module adapted to receive cue information related to a specific individual off-street parking spot and associate the cue information with the specific spot in a spot database.
  • the off street spot management module resides on a reservation server.
  • the off-street spot management module resides on an external client device adapted to communicate with a reservation server.
  • at least some of the individual off-street parking spots are privately owned.
  • the off-street spot management module has a user interface selected from a web based interface and a smartphone based interface.
  • a system including a database of individual parking spots, each of the individual parking spots associated with a unique identifier (UID) and location coordinates; at least one computer workstation adapted to display a map; a graphical user interface (GUI) operable on the workstation, the GUI adapted to divide the map into zones and to assign a desired occupancy rate to each zone; and a reservation server adapted to receive user parking requests including a destination from user client devices via a network, and to respond to each request by assigning an available spot closest to the destination, that does not cause any of the zones to exceed its assigned desired occupancy rate.
  • UID unique identifier
  • location coordinates at least one computer workstation adapted to display a map
  • GUI graphical user interface
  • the GUI operable on the workstation, the GUI adapted to divide the map into zones and to assign a desired occupancy rate to each zone
  • a reservation server adapted to receive user parking requests including a destination from user client devices via a network, and to respond to each request by assigning an available spot closest to the destination,
  • a system including: parcels of land each having a unique identifier; a database of the parcels of land; a command and control center for applying at least one use rule to said parcel of land; and a graphical user interface for displaying the at least one rule in relation to the parcels of land.
  • the command and control center is configured to apply at least two different rules the parcel of land.
  • Regular 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.
  • 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 schematic representation of a parking system according to some embodiments of the invention.
  • Fig. 4 is a schematic representation of a parking system according to additional embodiments of the invention.
  • Fig. 5 is a schematic representation of a parking system according to further additional embodiments of the invention.
  • Fig. 6 is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 7a is a simplified flow diagram of a method according to additional exemplary embodiments of the invention.
  • Fig. 7b is a schematic representation an exemplary user client device interface according to some exemplary embodiments of the invention.
  • Fig. 8a is a simplified flow diagram of a method according to further additional exemplary embodiments of the invention.
  • Fig. 8b is a schematic representation of an exemplary user client device interface for presenting context information for a specific spot
  • Fig. 8c is a schematic representation of another exemplary user client device interface for presenting context information for a specific spot
  • Fig. 9 is a schematic representation of a parking kiosk according to some embodiments of the invention.
  • Fig. 10 is a simplified flow diagram of a method according to still further additional exemplary embodiments of the invention.
  • Fig. 11 is a simplified flow diagram of a method according to still further additional exemplary embodiments of the invention.
  • Fig. 12 is a simplified flow diagram of a method according to still further additional exemplary embodiments of the invention.
  • Fig. 13a is a simplified flow diagram of a method according to still further additional exemplary embodiments of the invention.
  • Fig. 13b is a schematic representation of information flow according to some exemplary embodiments of the invention
  • Fig. 14 is a simplified flow diagram of a method according to still further additional exemplary embodiments of the invention.
  • Fig. 15 is a simplified flow diagram of a method according to still further additional exemplary embodiments of the invention.
  • Fig. 16 is a table (spreadsheet) illustrating an exemplary rule application scheme according to some embodiments of the invention.
  • Fig. 17 is a simplified flow diagram of a method according to still further additional exemplary embodiments of the invention.
  • Fig. 18 is a schematic representation of a user client device according to some exemplary embodiments of the invention.
  • Fig. 19 is a schematic representation of a parking system according to some embodiments of the invention.
  • Fig. 20a is a schematic representation of a parking system according to some embodiments of the invention.
  • Fig. 20b is a schematic representation of a parking system according to some embodiments of the invention.
  • Fig. 21 is a schematic representation of a system according to some exemplary embodiments of the invention.
  • Fig. 22a is a schematic representation of a system according to some exemplary embodiments of the invention.
  • Fig. 22b depicts an exemplary Graphical User Interface (GUI) according to some exemplary embodiments of the invention.
  • GUI Graphical User Interface
  • Fig. 23 is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 24 is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 25 is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 26a is a schematic representation of differently sized parking spots resulting from practice of a method according to some exemplary embodiments of the invention
  • Fig. 26b depicts a GUI according to some exemplary embodiments of the invention.
  • Fig. 26c depicts a GUI according to some exemplary embodiments of the invention.
  • Fig. 27 is a simplified flow diagram of a method according to some exemplary embodiments of the invention.
  • Fig. 28 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). In some embodiments system 100 communicates with an external governmental DB 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. Alternatively or additionally, 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.
  • system 100 automatically (e.g., based on a predetermined system law) changes rules based on current status of parking subunits and/or analytics.
  • information from DB 164 is used, for example, by rule and spot manager 150 to automatically and dynamically change rules in rule DB 166. For example, if the current status of a spot or spots and/or analytics of a spot or spots fulfils a predetermined system law then a rule change may be applied automatically.
  • 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 may apply to a given spot at any given moment.
  • 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. In the depicted embodiment, 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 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 may deal primarily with rules applicable to a whole parking facility, or a whole floor within a parking facility.
  • 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.
  • Exemplary single parking reservation request As an example of how system 100 works, the processing of a single reservation request, which defined 52 Weizman 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 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 201 of user client device 122a displaying an exemplary interface for confirming arrival at a specific parking spot assigned by reservation management server 120 (Fig. 1) overlaid on the map of 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 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 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 schematic representation of a computerized parking management system, indicated generally as 2300, according to some embodiments of the invention.
  • Depicted exemplary system 2300 includes a database 2310 of individual on-street parking spots 2330 and individual off-street parking spots 2320, each of the individual parking spots associated with a unique identifier (UID) and location coordinates.
  • the depicted system also includes an off street spot management module 2340 in communication one or more external client devices 2342 and adapted to receive parking rules from an external client device 2342 operated by an owner of each of the individual off-street parking spots.
  • the term "external client” indicates spot management function but the client devices can be any of the device types listed in the section entitled "Exemplary user client devices”.
  • system 2300 includes a location definition module 2341 (depicted here as part of spot management module 2340) adapted to receive location coordinates defining a specific individual off-street parking spot from one external client devices 2342 and assign a UID to the location coordinates to create an individual spot definition and add the spot definition to spot database 2310.
  • a location definition module 2341 (depicted here as part of spot management module 2340) adapted to receive location coordinates defining a specific individual off-street parking spot from one external client devices 2342 and assign a UID to the location coordinates to create an individual spot definition and add the spot definition to spot database 2310.
  • an owner of an individual off street spot uses a location function of a smartphone to acquire and transmit location coordinates of a specific parking spot to module 2341.
  • system 2300 includes a cue management module 2360 adapted to receive cue information from the external client device 2342.
  • the cue information is used in guiding a vehicle to a specific individual off-street parking spot.
  • the cue information transmitted from client device 2342 to module 2360 is stored in DB 2310 in association with a specific off street spot 2320 in the DB 2310.
  • cue information includes audio and/or text and/or images.
  • off street spot management module 2340 resides on reservation server 120 (Fig. 1). According to these embodiments, owners of off street spots log in and have access privileges only for spots they own.
  • off street spot management module 2340 resides on an external client device 2342 adapted to communicate with reservation server 120.
  • spot owners manage their spots on the external client (using any device 2342) and submit rules to reservation server 120.
  • Parking lot owners can manage their spots on an individual basis (for example a single spot subscription sold by lot equals a "reservation blackout" for the system), in groups (for example lease of a whole floor of a parking garage to a company) or on a whole lot basis (for example a global rate change).
  • At least some of individual off street parking spots 2320 are privately owned. Different on-street and/or different off-street parking spots may be owned by different owners. Systems and methods according to embodiments of the invention enables centralized control of different types of parking spots regardless of ownership.
  • the private spot management module 152 has a user interface selected from a web based interface and a smartphone based interface.
  • the interface is similar to that depicted in Fig. 5C except that the leftmost column is either absent or always populated with the single spot belonging to the user.
  • Fig. 4 is a schematic representation of a computerized parking management system, indicated generally as 2400 according to some embodiments of the invention.
  • Depicted exemplary system 2400 includes a database 2410 of individual parking spots 2411 with each of the individual parking spots associated with a unique identifier (UID) and location coordinates and a current availability status.
  • a reservation management server 2420 receives user parking requests 2418 from user client devices 122 with each request including a destination.
  • suggestion engine 2430 transmits prompts 2432 including hourly parking rate and distance from destination for parking spots to user client devices 122 at least until an order 2434 is received at engine 2440 of server 2420 from said user client device 122 or until request 2418 is cancelled 2452 by user client device 122.
  • Depicted reservation engine 2440 transforms order 2434 into a reservation by changing an availability status of an ordered spot to not available in DB 2410.
  • suggestion engine 2430 continues to transmit additional prompts 2432 after order 2434 is received.
  • each additional prompt 2432 offers a spot that has better conditions (for example a shorter distance to destination and/or a lower hourly parking rate) than the spot requested in order 2434.
  • reservation engine 2440 transforms new order 2434 into a reservation and cancels a previous order received from a same user client device 122 upon selection of one of additional prompts 2432 from the suggestion engine 2430.
  • system 2400 includes a cancellation management module 2450 adapted to receive cancellation requests 2452 from a user client device 122, and cancel a previous request 2418 or order 2434 made by the user client device.
  • cancellation management module 2450 cancels a previous request 2418 (or order 2434) sent from the same user client device 122 from which the previous request 2418 (or order 2434) was sent.
  • a cancellation request 2452 is made from a different user client device 122 and is accompanied by information connecting the cancellation request 2452 with the previous request 2418 (or order 2434). Examples of connecting information include, but are not limited to, a vehicle identification number, a user ID and/or password and identifying information for user client device 122 that made the reservation or order (for example a mobile phone number).
  • prompts 2432 include additional information.
  • additional information for inclusion in a prompt include, but are not limited to, on street/off street and/or parallel vs diagonal spot and/or indoor vs outdoor parking.
  • a level within a parking facility is specified in the prompt.
  • additional prompts 2432 indicate individual spots which were not available when parking request 2418 was received at server 2420.
  • these newly available spots are offered to the earliest request first (first in first out).
  • these newly available spots are offered to the request with a destination closest to the newly available spot.
  • Fig. 5 is a schematic representation of a computerized parking management system, indicated generally as 2500 according to further additional embodiments of the invention.
  • Depicted exemplary system 2500 includes a database 2510 of individual parking spots 2511 each of the individual parking spots associated with a unique identifier (UID) and location coordinates and a current availability status.
  • a reservation management server 2520 receives user parking requests 2515 from user client devices 122 that are coupled to position trackers 2514.
  • requests 2515 are compared to a user profile in a user profile DB 2512.
  • requests 2515 are received via a network and each request includes a destination.
  • a tracking engine 2522 monitors progress of each position tracker 2514 towards the destination defined in request 2515 from client device 122 coupled thereto and issue a push signal 2524 when a threshold proximity to destination is crossed.
  • push signal 2524 is received by a suggestion engine 2530, which responds to the push signal 2524 by transmitting a location 2532 of at least one individual parking spot to user client device 122.
  • suggestion engine 2530 transmits only one spot suggestion
  • reservation management server 2520 transforms suggestion 2532 to a reservation.
  • system 2500 includes a user profile and suggestion engine 2530 chooses the one spot based on a user profile.
  • the user profile is associated with user client device 122 and/or with a vehicle registration number contained in request 2515.
  • suggestion engine 2530 transmits several spot suggestions 2532 to user client device 122 and a choice 2533 is received at reservation management server 2520 from user client device 122. In some embodiments if no choice is received, the first suggestion in the list becomes a default selection.
  • the threshold proximity is defined in in terms of distance from destination and/or in terms of estimated arrival time.
  • the threshold includes maximum speed as a second variable.
  • tracking engine monitors speed of user client device 122 using tracking device 2515.
  • push signal 2524 is sent by tracking engine 2522 only if the measured speed is below a predefined maximum speed (for example 20, 15, 10 or 5 K.P.H. or lower or intermediate speeds).
  • use of maximum speed as a second variable contributes to a reduction in dangerous driver interaction with user client device 122 while their vehicle is at high speed. Virtual parking lot on demand
  • Fig. 6 is a simplified flow diagram of a method for providing a virtual parking lot on demand, indicated generally as 2600, according to some exemplary embodiments of the invention.
  • Depicted exemplary method 2600 includes receiving 2610 at a reservation management server from a user client device a bulk parking order for a future time.
  • the bulk parking order defines a number of spots required, a desired parking duration, a start time, a destination and a maximum distance therefrom.
  • the depicted method includes the server responding 2620 to the bulk parking order by transmitting a map of available parking spots to the user client device. Each spot on the map is available at the future time for the desired parking duration from the indicated start time and is within the maximum distance from the destination
  • the depicted embodiment of method 2600 also includes receiving 2630 at the reservation management server an order indicating specific spots on the map and transforming 2640 the bulk parking order to a bulk parking reservation for the indicated spots at the future time.
  • the method includes returning 2650 a redemption token to the user client device.
  • Exemplary redemption token formats include, but are not limited to hypertext links and/or QR codes and/or barcodes and/or an alphanumeric event codes.
  • the party placing the order distributes the redemption token to invitees in various ways.
  • QR codes are distributed on printed paper invitations for subsequent machine reading (for example using a camera of a smartphone as a reader).
  • tokens are distributed to invitees as part of an e- invitation sent out by e-mail or using an instant messaging application.
  • recipients of tokens use the redemption tokens to allocate a portion of the bulk parking order to a specific vehicle identification number and/or to obtain directions to a specific assigned spot.
  • a maximum amount of time in the future the bulk parking order can be made varies as a function of the number of spots defined by the order. For example, a system 100 accepts reservations further in advance as the number of spots involved goes up.
  • the method includes providing 2660 an invitation redemption portal adapted to assign specific vehicle registration numbers to specific spots defined in the bulk parking reservation.
  • the portal is Internet based and/or provided as an IVR (Interactive voice response) menu at a call center and/or operates though a smartphone application.
  • Method 2600 is described from the client side as follows
  • responding 2620 includes provision of a non graphical UI (such as a list or table) by the server to the user in addition to or instead of the map and transmits it to the user.
  • a non graphical UI such as a list or table
  • the user client device accepts user selections from a non graphical UI (such as a list or table) and/or displays user selections from a non graphical UI (such as a list or table).
  • a non graphical UI such as a list or table
  • user selections made on a map appear in a list or table as part of a hybrid user interface.
  • selection made using a non graphical UI such as a list or table
  • Fig. 7a is a simplified flow diagram of a method for parking enforcement, indicated generally as 2700, according to some exemplary embodiments of the invention.
  • Depicted exemplary method 2700 includes receiving 2710 at a reservation management server, a query including location coordinates from a tracking component in a user client device equipped with a display.
  • the user client device is issued to a parking warden.
  • the depicted method includes responding 2720 to the query by transmitting a portion of a map including the location coordinates from the query.
  • the map depicts parking spots and indicates 2725 for each spot whether its current status in the system is occupied, empty or reserved.
  • the map is transmitted in a format suitable for display on the relevant user client device. In some embodiments map transmission is by allowing the user client device access to the system map online. In some embodiments a non-graphical UI (such as a list or table) is substituted for a map as described above in the context of Fig. 6a.
  • the method includes displaying 2730 a vehicle registration number of a vehicle specified in a reservation of a specific spot for each spot indicated as reserved on the map.
  • the display of the vehicle registration number is constant or appears in response to rollover and/or touch.
  • the method includes one or more display options 2731 for the map.
  • the method includes populating 2732 spots on the map indicated as occupied with virtual reality depictions, or icons, of relevant cars.
  • the method includes populating 2734 the spots on the map indicated as reserved with virtual reality depictions, or icons, of relevant cars.
  • the method includes displaying 2736 text describing relevant cars in association with the spots on the map indicated as occupied and/or reserved.
  • the text includes make and/or model and/or color and/or vehicle registration number.
  • the method includes presenting 2740 the map on the user client device in perspective view. In some embodiments the perspective is that of a pedestrian at the location.
  • the method includes populating the spots on the map indicated as available with predetermined icons indicating this status.
  • the method includes one or more update options 2749 for the map.
  • the method includes updating 2770 map as the location coordinates 2750 of the user client device change and/or updating spot status 2780.
  • this option is coupled with the presentation of perspective view 2740 and/or one or more other display options 2731.
  • the method includes updating
  • method 2700 includes receiving at the reservation management server a status change input for a specific spot from the user client device and updating a status of the spot in a spot database in accord with the input.
  • a warden updates the system with respect to violations and/or cars that reserved but forgot to indicate arrival.
  • the input includes location coordinates and/or UID of spot and/or vehicle registration number.
  • the input switches a status of an individual spot to occupied. For example, the status would be occupied if an authorized car is in a spot indicated as reserved or if the spot is illegally occupied.
  • the system accepts a designation of "violation,” which indicates that the spot is occupied, and the system sends a report including a vehicle registration number to violation system 130 (Fig. 1).
  • the input changes a status of an individual spot from occupied to vacant. For example, if a spot indicated as occupied on the map is empty.
  • Fig. 7b is a schematic representation of an exemplary user client device interface, indicated generally as 2721, for presenting status information for specific spots in proximity to a location.
  • key 2723 contributes to simplification of identification of reserved 2725 and/or available 2727 spots which are improperly occupied by a car. In this depiction no violations are shown.
  • Interface 2721 is suitable for use in the practice of method 2700.
  • Fig. 8a is a simplified flow diagram of a computerized parking management method, indicated generally as 2800 according to some exemplary embodiments of the invention.
  • Depicted exemplary method 2800 includes transmitting 2810 location information for a specific parking spot from a parking reservation management server to a user client device and transmitting 2820 supplementary context information (discussed below) about the specific parking spot from the server to the user client device.
  • the location information transmitted at 2810 is in machine readable format (for example digitally encoded location coordinates).
  • method 2800 includes providing navigation instructions 2830 to the location defined by the location information of 2810.
  • accuracy of a tracking or guidance component in the user client device is limited. For example, GPS tracking and navigation can have an error of +10 meters.
  • the supplementary context information helps user easily and correctly identify a specific spot reserved for them if they are within sight range of the spot.
  • the supplementary context information includes location information.
  • this location information is transmitted digitally in some embodiments, presentation on the user client device is in a non-machine readable format.
  • this additional location information is, in various embodiments, formatted as a street address and/or a row and spot number in a parking lot or garage.
  • garage spots are further identified by level number and/or zone information (for example color and/or icon).
  • Some embodiments of depicted exemplary method 2800 include monitoring 2812 proximity of the user client device to the specific spot and transmitting 2820 said supplementary context information when a proximity threshold to the spot is crossed 2814.
  • Fig. 8b is a schematic representation of an exemplary user client device interface, indicated generally as 2801, for presenting context information for a specific spot assigned by the system.
  • interface 2801 is presented in a conventional vehicle navigation system.
  • the vehicle navigation system uses machine readable location information provided from 2810 (Fig. 8a) to guide the vehicle to the specific spot.
  • machine readable information includes location coordinates transmitted directly to a user client device for use by an application already running on that device and/or an instruction which, when read by a user client device, launches an application on the user client device and provides access to relevant position coordinates to the newly launched application.
  • suitable machine readable information formats include QR codes and/or barcodes and/or hypertext links.
  • the supplementary context information transmitted at 2820 describes a vehicle in at least one spot flanking the spot for which location information was provided at 2810.
  • Exemplary user interface 2801 includes a portion of a map with an assigned parking spot 2813, which is the destination indicated.
  • a pop up window 2815 displays the supplementary context information of 2820.
  • text boxes 2807a and 2807b In the depicted embodiment some of the supplementary context information is provided in text boxes 2807a and 2807b.
  • Each of text boxes 2807a and 2807b contains information describing cars 2805a and 2805b parked in spots 2803a and 2803b on either side of assigned spot 2809a indicated by marker 2809b.
  • the text in the text boxes 2807a and 2807b includes car make and/or car model and/or model year and/or color and/or at least a portion of the vehicle registration number (for example last 4 letters and/or numbers). As described hereinabove, this information is available from vehicle DB 162.
  • textual information is provided via a 2 G phone (for example via SMS message) and/or printed at a kiosk.
  • supplementary context information depicted here as text is provided as audio (for example via a 2 G phone or on smart device).
  • audio presentation employs text to speech technology in the relevant user client device.
  • supplementary context information 2813 describes an off street landmark in the form of "City Hall" 2817.
  • the depiction is textual, but other embodiments employ graphics, an image or icon to represent off street landmarks.
  • an icon of a fire hydrant or a graphic of a sign for example showing a name of a shop or restaurant and/or a symbol associated with a business
  • a representation of a whole building for example a photograph or icon.
  • Depicted exemplary interface 2801 includes a parking confirmation icon 2811.
  • Selection of the icon (for example by touching on a touch screen user client device) transmits a signal to system 100 that spot 2813 indicated on the map is now occupied.
  • provision of supplementary context information about spot 2813 which is current contributes to an ability of a user of the system to find a specific spot assigned to them (e.g., information about currently parked vehicles received from vehicle DB 162).
  • the supplementary context information is provided as a graphical and/or iconic and/or virtual reality representation of a car currently parked in at least one flanking spot.
  • Fig. 8c is a schematic representation of an exemplary user client device interface, indicated generally as 2802, for presenting context information for a specific spot assigned by the system.
  • Fig. 8c is similar to Fig. 8b in content and purpose, but the perspective view of Fig. 8c imparts a feeling of virtual reality.
  • 2802 is presented as a pop-p window, optionally layer over a portion of a map, as depicted in Fig. 8b.
  • interface 2802 is presented in a conventional vehicle navigation system.
  • the vehicle navigation system uses machine readable location information provided from 2810 (Fig. 8a) to guide the vehicle to the specific spot.
  • the supplementary context information transmitted at 2820 describes a vehicle (2805a and/or 2805b) in at least one spot flanking the spot (2803a and/or 2803b) for which location information was provided at 2810.
  • the supplementary context information is presented graphically in a perspective view simulating the viewpoint of a driver approaching the assigned spot 2809a.
  • a pavement marking 2819a is clearly visible in assigned parking spot 2809a in a perspective view simulating the viewpoint of a driver approaching the assigned spot 2809a.
  • a vehicle registration number 2819b is clearly visible on the license plate of car 2805a in flanking spot 2803a in a perspective view simulating the viewpoint of a driver approaching assigned spot 2809a.
  • interface 2802 is provided to a user on a screen of a user client device or in printed form (e.g. at a kiosk 2900 as described hereinbelow).
  • interface 2802 is presented her as a still image, in some exemplary embodiments of the invention it is provided as a virtual reality animation so that the perspective changes as user client device 122 approaches assigned spot 2809a.
  • use of graphical context information presentation contributes to ease of user assimilation of presented information.
  • Fig. 9 is a schematic representation of a parking kiosk, indicated generally as 2900, for use in a computerized parking management system as described hereinabove according to some embodiments of the invention.
  • deployment of kiosks 2900 in public places provides a system interface for users that do not have a user client device with them when they want to reserve a parking spot and/or park in an assigned spot and/or vacate an assigned spot.
  • a request for a parking spot from kiosk 2900 automatically defines a location as "in proximity to this kiosk” and/or a desired parking time as "now + estimated driving time to the spot".
  • Users that do not have a user client device with them include, but are not limited to, users that reserve a spot using a non-portable user client device (for example conventional telephone or desktop computer) and users that are roaming outside a service area of their personal user client device.
  • a non-portable user client device for example conventional telephone or desktop computer
  • Depicted exemplary kiosk 2900 includes a user interface component 2910 accepting a vehicle registration number as an input.
  • component 2910 is depicted as including a display screen 2912 and keypad 2914.
  • display screen 2912 is a touch screen and no keypad is provided.
  • keypad 2914 is a 10 key numeric keypad or a more robust alphanumeric input device (for example QWERTY keyboard).
  • keypad 2914 includes "dedicated function" buttons such as new reservation, receive map for existing reservation, confirm parking, and exit notification.
  • "dedicated function" instructions appear on display screen 2912. For example:
  • user interface component 2910 of kiosk 2900 accepts confirmation of parking and/or exit as described above or in other ways.
  • interface 2910 includes a microphone and speaker (not depicted).
  • a microphone and speaker are provided as an intercom box or as a telephone receiver.
  • a kiosk user is presented with an IVR menu via the speaker and makes selections via keypad 2914 and/or by using voice commands delivered into the microphone.
  • Depicted exemplary kiosk 2900 includes a request generator 2916 in communication with interface 2910.
  • Request generator 2916 transmits the vehicle registration number as a reservation request 2920 to a parking reservation management server (for example 120 in Fig. 1) which assigns a specific parking spot to the vehicle registration number and generates a digital file encoding a map including navigation cues from the kiosk to the assigned spot.
  • the server transmits the digital file 2930 to the kiosk.
  • data transmission is via any available network type.
  • Depicted exemplary kiosk 2900 also includes a map delivery apparatus 2940.
  • map delivery apparatus 2940 includes a printer that prints out the map encoded by digital file 2930.
  • map delivery apparatus 2940 includes a data port for transmission of the map (encoded by digital file 2930) to an external device.
  • data ports include, but are not limited to USB port, Bluetooth, infrared, microwave and NFC.
  • Corresponding external devices include, but are not limited to USB drives, devices with USB ports (for example computer, tablet or smartphone), Bluetooth enabled devices (for example computer, car computer, tablet or smartphone) infrared enabled devices (for example computer, car computer, tablet or smartphone) and NFC enabled devices (for example tablet or smartphone).
  • kiosk 2900 includes a camera 2950 positioned to capture an image of a user of user interface component 2910.
  • the camera is a still camera and/or a video camera.
  • kiosk 2900 includes a payment mechanism 2960.
  • payment mechanism 2960 includes credit card transaction processing capability and/or coin handling capability and/or banknote handling capability.
  • payment is made in advance or at parking checkout.
  • the kiosk is stationary or portable (for example for use at special events).
  • the kiosk sends request 1920 and/or receives digital file 2930 via a wireless and/or a wired network.
  • kiosks 2900 with wired network connections continue to function when user client devices relying on wireless connections (for example cell phones) are not in services due to failure of a network (for example a cellular communications network) which is used by system 100 but is not part of system 100.
  • Exemplary special feature spot assignment method Fig. 10 is a simplified flow diagram of a computerized parking management method, indicated generally as 3000, according to some exemplary embodiments of the invention.
  • Depicted exemplary method 3000 includes receiving 3010 a request to reserve a 5 parking spot for a vehicle at a reservation management server from a user client device and determining 3020 (for example across a network or via a query to an internal DB) attributes of the vehicle and searching 3030 a spot DB to identify spots with features corresponding to the vehicle attributes.
  • Spot features include fixed physical characteristics (for example a charger for an electric cars and indoor/outdoor status,
  • the request includes a vehicle identification number and said determining 3020 includes retrieval of data from a vehicle DB.
  • the request includes a user name and/or password and
  • the determining includes retrieval of a user profile including attributes of the vehicle.
  • vehicle attributes include physical characteristics (for example electric powered; propane powered, handicap lift, freight lift).
  • vehicle attributes include 20 status characteristics (for example handicap and/or resident and/or emergency and/or law enforcement and/or delivery and/or municipal service vehicle and/or utility vehicle (for example telephone company or electric company)).
  • status characteristics for example handicap and/or resident and/or emergency and/or law enforcement and/or delivery and/or municipal service vehicle and/or utility vehicle (for example telephone company or electric company)).
  • the request includes a destination.
  • method 3000 includes assigning 3040 a spot identified at 25 3030 to vehicle.
  • location coordinates in machine readable format are provided to the user client device that made the request for use on that user client device or a different user client device.
  • location coordinates in machine readable format are provided to a different user client device than the one that made the request (e.g. a kiosk 30 2900).
  • the location coordinates in machine readable format are used by a device incapable of communication with system 100.
  • a map printed at kiosk 2900 includes a QR code. The user requested a printed map from the kiosk because they are roaming in an area where they have no data coverage.
  • a smartphone belonging to the user uses a camera incorporated therein to scan the QR code. Scanning launches a map application stored locally on the smartphone and indicates the position of the assigned spot.
  • Fig. 11 is a simplified flow diagram of a computerized parking management method, indicated generally as 3100 according to some exemplary embodiments of the invention.
  • a spot becomes available after a user has passed it on a one-way road.
  • the spot may be the closest available spot, its position behind the user makes it difficult to reach.
  • Other spots located farther away but ahead of the user are easier and/or faster to reach.
  • These embodiments contribute to an ability of the user to arrive at an assigned spot without violation traffic regulations and/or in less time than it would take to return to the spot they had already passed via a legal route.
  • Depicted exemplary method 3100 includes receiving 3110 at a reservation management server a request to park including a destination from a user client device and compiling 3120 a list of available spots ahead of the user client device based on a current position and available travel direction of the user client device and transmitting 3130 at least position coordinates of least one spot on the list to the user client device.
  • Available travel direction is a flexible parameter that considers distance and/or time of the shortest route to a spot which can be legally travelled to a specific available spot from a current location. In some embodiments as the percentage of occupied spots in an area increases, the available travel direction parameter is relaxed so that spots which are further away on the shortest legal route and/or require more time to reach on the shortest legal route are eligible for inclusion in the compiled list.
  • Fig. 12 is a simplified flow diagram of a computerized parking management method, indicated generally as 3200 according to some exemplary embodiments of the invention.
  • Depicted exemplary method 3200 includes receiving 3210 at a reservation management server a request to park including a destination from a user client device, determining 3220 a category for the destination and transmitting 3230 to the user client device a set of suggested parking spots including at least one parking spot at an alternate destination in the destination category.
  • determining 3220 5 includes a keyword analysis of the destination. For example, mall, beach, park and cinema are examples of keywords. Retail chain names also serve as keywords in some embodiments.
  • alternate destinations within a category are included in a list of suggested parking spots when the destination indicated in the request has little or no parking available and/or when parking at the destination 10 indicated in the request would require a significant wait.
  • inclusion of alternate destinations within a category in a list of suggested parking spots warns an operator of the user client device that the originally selected destination is crowded.
  • the destination (received at 15 3210) includes a street address and determining 3220 includes a query to a directory to determine what is at the address.
  • a parking spot in the set of suggested parking spots is characterized in terms of estimated wait time for availability.
  • information pertaining to distance from destination and/or hourly 20 parking rate are also provided.
  • information pertaining to distance from destination and/or hourly 20 parking rate are also provided.
  • 100 sets maximum permitted parking time well above the time the average shopper takes based on analysis of historic data in event DB 168. In some embodiments this contributes to an increase in estimated wait times. Alternatively or additionally, longer reservations are filled with spots further from the entrance.
  • Fig. 13a is a simplified flow diagram of a computerized parking management method, indicated generally as 3300 according to some exemplary embodiments of the invention.
  • Depicted exemplary method 3300 includes receiving 3310 a parking request including a destination at a reservation management server and transmitting 3320 a prompt to accept assignment to a spot in proximity to public transportation hub in response to the request.
  • the prompt is received at a user client device from which the request originated.
  • method 3300 includes analyzing 3330 the request to determine whether a stop for any public transportation route proving service from the hub is in proximity to the destination.
  • proximity is defined in terms of distance (for example 100, 200, 300, 400 or 500 meters or intermediate or lesser distances.) and/or in terms of estimated walking time (for example 1 minute, 2 minutes, 5 minutes, or 10 minutes or intermediate or greater times).
  • method 3300 includes including in the prompt information on how much closer to the destination the stop (in closest proximity to the destination) is than the available parking spot closest to the destination.
  • method 3300 includes including in the prompt information on how much money is potentially saved by using public transportation from the hub. In some embodiments parking at hub and public transportation shuttle are both free, so savings equals the hourly rate times the number of parking hours.
  • method 3300 includes including in the prompt information on how much time is potentially saved by using public transportation from the hub.
  • Fig. 13b is a schematic representation of information flow, indicated generally as 3301, according to some exemplary embodiments of the invention.
  • information flow 3301 contributes to an ability of system 100 to provide prompt information on how much time is potentially saved by using public transportation from the hub.
  • a server 3303 operated by a Public Transportation Authority (PTA) periodically updates a public transportation DB 3309 with Current Travel Time (CTT) data 3305.
  • CTT data 3305 includes information pertaining to public transportation hubs with parking spots and transportation lines operating from those stops, and the stops on each line. Each hub and each stop is defined in terms of location coordinates.
  • CTT data 33305 indicates a current travel time from each hub to every stop serviced by that hub and a relevant line which services each stop.
  • the updates occur every 30, 10, 5, 3, 2 or 1 minutes or with intermediate or shorter intervals.
  • PT DB 3309 is part of system 100 (Fig. 1).
  • Suggestion list builder 110 of system 100 receives parking requests 3307 from user client devices 122d equipped with navigation devices that sense current position and provide an estimated time of arrival at a current destination.
  • each parking request 3307 indicates a current location, a current destination and the current ETA.
  • List builder 110 compares the information in each request 3307 to information PT DB 3309 using a predefined logic flow.
  • One example of a predefined logic flow is:
  • (a) is an estimate of travel time for user client device 122D from its current location to a transportation hub;
  • (b) is current data from PT DB 3309 on travel time from the hub to the identified
  • suggestion list builder 110 upon completion of this comparison, provides a prompt 3311 to user client device 122D asking the if the current destination should be changed to a transportation hub and providing an estimate of how much time will be saved by travelling to the hub and using public transportation to travel from the hub to a stop in proximity to the destination. If the user of user client device confirms prompt
  • method 3300 is only applied to requests from users that have opted in. In other exemplary embodiments of the invention, the method actively recruits public transportation users.
  • Fig. 14 is a simplified flow diagram of a computerized parking management method, indicated generally as 3400 according to some exemplary embodiments of the invention.
  • Depicted exemplary method 3400 includes receiving 3410 a parking request including a vehicle registration number at a parking reservation server.
  • the request includes a destination.
  • method 3440 includes accessing 3420 parking history for the vehicle registration number (for example from DB 168; Fig. 1).
  • the history incudes duration of previous parking events for the destination.
  • the history includes destinations defined for previous parking events.
  • method 3440 includes identifying 3430 at least one parking preference in said history.
  • identifying 3430 includes pattern analysis. For example, if a user routinely drives to a specific destination on Tuesday evenings, the system prompts the user by sending a query (for example pop up window and or voice prompt) "Are you looking for a spot near the corner of Main St. and fourth Ave.?
  • a query for example pop up window and or voice prompt
  • identification of a user preference from a history contributes to an obviation of a need for destination data entry.
  • a user provides recurring events including locations and schedule information as part of a user profile.
  • method 3400 includes transmitting 3440 one or more suggested parking spots to said user client device, accompanied by data pertaining to each identified preference for each spot.
  • transmitting 3440 is of a single parking spot reserved for the vehicle registration number.
  • a list of available spots is transmitted.
  • method 3400 includes constructing 3450 a user profile based on said at least one preference. According to these embodiments the construct profile is used to identify parking preferences in the future (arrow from 3450 to 3410).
  • Fig. 15 is a simplified flow diagram of a computerized parking management method, indicated generally as 3500, according to some exemplary embodiments of the invention.
  • Depicted exemplary method 3500 includes transmitting 3510 a reservation for an initial parking spot to a user client device from a reservation management server in response to a parking request; receiving 3520 a problem notification related to the first parking spot from the user client device at the server; and responding 3530 to the problem notification by transmitting a reservation for an alternate parking spot to the user client device.
  • the problem notification is transmitted by touching or pushing an appropriate button (not shown) on the user client device.
  • the reservation for an alternate parking is processed by the system with a higher or preferred priority in accordance with preset criteria.
  • Preferred priority indicates processing first, ahead of reservations previously received and/or changing an existing reservation for a different vehicle on order to provide the alternate parking spot.
  • exemplary method 3500 includes dispatching 3540 a service resource to said initial parking spot to evaluate said problem notification.
  • exemplary method 3500 includes suspending 3550 further reservations for said first parking spot until a problem of the problem notification is resolved.
  • suspending 3550 is accompanied by changing the status of the initial spot in spot DB 164, According to various exemplary embodiments of the invention the status is change to occupied and/or violation (indicates a need for violation report and/or towing) or unavailable (for example if access to the spot is blocked, but not by a vehicle).
  • a notification may be sent directly to the user device 122 of the relevant driver from the violation system 130.
  • the notification is, for example, in the form of a text message, a voice message, a push notification through a smart phone application, a phone call among others.
  • a problem notification indicates an unauthorized car parked in the initial parking spot.
  • Resolution of the problem is towing of the car (for example by a dispatched 3540 service vehicle in the form of a tow truck), which makes the initial spot available again.
  • the status of the spot in spot DB either remains "reserved” or is switched to "occupied” or is switched to "violation".
  • a problem notification indicates a spot is covered by a large pile of snow resulting from clearing of a parking lot by snowplows. Resolution of the problem may occur only when the snow melts, which makes the spot available again. In this scenario repeated periodic (for example daily) dispatch 3540 of a service vehicle to monitor the situation is indicated.
  • dispatch 3540 is of an automatic (driverless) service vehicle via transmission of a service request as one or more packets of digital data from the server (for example 120 in Fig. 1) to the vehicle across an available network.
  • Fig. 17 is a simplified flow diagram of a computerized parking management method, indicated generally as 3700, according to some exemplary embodiments of the invention.
  • Depicted exemplary method 3700 includes receiving 3710 a parking request from a first user client device at a reservation management server (for example 120 in Fig. 1) and storing 3720 a reservation of a parking spot in response to the request.
  • the request includes a destination and/or a vehicle registration number and/or a reference to a user profile.
  • the first user client device is a device of any type.
  • the first user client device is nonportable (for example a conventional PSTN telephone or a home computer operating a web browser) and/or has limited graphics capabilities (for example a 2G phone).
  • the server then receives 3730 a request for details of the reservation from a second user client device.
  • the request for details includes sufficient information for identification of the request (for example vehicle registration number and/or a reference to a user profile).
  • Reference to a user profile may be, for example, a username and/or password.
  • a user makes a parking request from a nonportable first user client device in their home and subsequently makes a request for details from a public kiosk (for example 2900; Fig. 9) filling the role of second user client device.
  • a public kiosk for example 2900; Fig. 9
  • a user makes a parking request from a non-portable first user client device in their home and subsequently picks up a neighbor carrying a smartphone and travelling to a shared destination.
  • the neighbor's smartphone serves the role of second user client device.
  • This scenario offers navigation instructions en-route.
  • method 3700 includes receiving 3740 a confirmation of parking in a spot reserved by said reservation.
  • confirmation originates from any user client device capable of communication with the system so long as the confirmation includes sufficient information for identification of the relevant reservation (e.g. vehicle registration number and/or a reference to a user profile and/or a UID of a parking spot and/or identifying information pertaining to the first user client device (for example a home phone number)).
  • method 3700 includes receiving 3750 an exit notification for the parking spot.
  • confirmation originates from any user client device capable of communication with the system so long as the confirmation includes sufficient information for identification of the relevant reservation (for example vehicle registration number and/or a reference to a user profile and/or a UID of a parking spot and/or identifying information pertaining to the first user client device (for example a home phone number).
  • Fig. 18 is a schematic representation of a user client device, indicated generally as apparatus 3800.
  • the user client device integrates calendar, parking reservation and navigation functions in a seamless user experience.
  • user client device 3800 includes a display screen 3840.
  • screen 3840 is a touchscreen.
  • user client device 3800 includes a calendar reader 3810 that reviews entries in a digital calendar and prompts the user for confirmation that one or more future events presented in a list is a current destination.
  • the calendar is maintained locally on user client device 3800 and/or synchronized with a calendar maintained on a different user client device.
  • list presentation by calendar reader 3810 is via display 3840 (for example using a format similar to that of Fig.2a with calendar entries replacing parking spots).
  • list presentation by calendar reader 3810 includes audio presentation via one or more speakers included in, or available to, user client device 3800 (speakers not depicted).
  • selection of a list item from the presented list is via voice command (using a microphone, not depicted) or via touching an item in a list displayed on display 3840.
  • user client device 3800 includes a destination modification module 3820 that prompts the user for a parking reservation request in response to selection of an item from the list.
  • destination modification module 3820 issues the parking reservation request to a reservation management server 120 via a network.
  • confirmation is active (by voice command or via touching display 3840) and in other embodiments confirmation is passive.
  • passive confirmation occurs when there is no user response to a prompt after 5, 10, 15, 30 or 60 seconds or intermediate or longer amounts of time.
  • destination modification module 3820 prompts the user to request parking at the beginning of a journey or as the vehicle approaches the selected destination. This is achieved, for example, as explained in the context of Fig. 5 and system 2500 hereinabove.
  • user client device includes a mapping module 3830 displaying current position on a map 3842 based upon output from a tracking device 3848 in communication with an external navigation resource 3850.
  • external navigation resource 3850 includes a GNSS system (Global Navigation Satellite System). Examples of GNSS include, but are not limited to, American (GPS), Russian (GLONASS), European (GALILEO) and Chinese (BeiDou- 2) systems.
  • GNSS Global Navigation Satellite System
  • GLONASS Russian
  • GALILEO European
  • BeiDou- 2 Chinese
  • the external navigation resource 3850 includes at least one network communication station, for example one or more cellular communication towers and triangulation.
  • a calendar entry selected as a current destination includes location information (as opposed to coordinates) and calendar reader 3810 transmits the location information from the current destination to destination modification module 3820 for inclusion in in the parking reservation request.
  • a calendar entry selected as a current destination does not include location information.
  • destination modification module 3820 provides a prompt for location information for inclusion in the parking reservation request.
  • the server Upon receipt of the parking reservation request, the server locates one or more specific parking spots defined by location coordinates and transmits coordinates for one or more specific spots back to user client device 3800 for use by map module 3830.
  • coordinates for a single spot are transmitted and map module 3830 begins navigation to the specific parking spot using map 3842 on display 3840 and/or audio cues.
  • map module 3830 provides a list for user selection.
  • List display in this case is similar to Fig. 2a.
  • map module 3830 begins navigation to the selected specific parking spot using map 3842 on display 3840 and/or audio cues.
  • Integration of the user experience contributes to an increase in safety and/or a decrease in user distraction while driving a vehicle.
  • Fig. 19 is a schematic representation of a parking system, indicated generally as 5000, according to some embodiments of the invention.
  • System 5000 is similar to system 100 (Fig. 1) in many respects.
  • Depicted exemplary system 5000 includes a base sub-system 5010, a regulation sub-system 5020, a management sub-system 5030, and multiple interfaces.
  • the three sub-systems 5010, 5020, and 5030 interact as layers to effectively serve a large and diversified population of drivers seeking convenient parking.
  • the first layer, the base sub-system 5010 has a ground level 5040 and a virtual level 5050.
  • the ground level 5040 references the management of the physical marking of all the parking spaces in the system 5000.
  • Non-limiting examples of the physical marking are painting parking spot numbers on or adjacent the pavement of the spot and posting signs adjacent the spot to display the spot numbers.
  • the virtual level 5050 of the base sub-system 5010 maintains digital representations of the parking spaces spots and their supporting infrastructures.
  • the virtual level 5050 has, for each stored parking spot, location coordinates (see spot DB 164 in Fig. 1) and relevant dimensions.
  • the second layer, the regulation sub-system 5020 stores for each parking spot digitally represented in the base sub-system 5010 rules that govern when and how the spot is used. Rules dictate whether the spot is available to the general public or reserved for handicapped use and/or which times of day, if any, the spot is unavailable and/or how much it costs for the user to park there, as non-limiting examples.
  • the third layer (compare to server 120 in Fig. 1), allocates parking spots registered in the base sub-system 5010 according to the rules in the regulation sub-system 5020.
  • Duties of the regulation sub-system 5020 include recording for retrieval the occupancy status for each spot and the enforcement of the parking rules, which will be discussed in more detail below.
  • the system 5000 includes a driver interface 5050 that enables registrants to reserve spaces, to later notify the system 5000 that the spaces have been vacated, and additional communications discussed in more detail below.
  • Human users interface with system 5000 via user client devices, for example via a smartphone (application) and/or 5 a 2G phone (voice/SMS) and/or a public kiosk (for example 900) and/or a website and/or an onboard vehicle computer for either a human-driven or an automatic vehicle,
  • user client devices for example via a smartphone (application) and/or 5 a 2G phone (voice/SMS) and/or a public kiosk (for example 900) and/or a website and/or an onboard vehicle computer for either a human-driven or an automatic vehicle,
  • Depicted exemplary system 5000 includes a parking owner interface 5060, which enables owners of parking facilities, such as a city municipality with respect to public parking, a private parking lot or garage owner, or a private individual, to set rules 10 for the use of their parking spaces.
  • Example rules are a city restricting parking in some space during peak traffic times and a home owner offering his/her space for use during specified times only.
  • management interface 5070 Another interface of the system 5000 is management interface 5070.
  • Such interface enables a command and control center (CCC 151; Fig. 1) to access the system 15 5000.
  • CCC 151 command and control center
  • the usher accesses the system 5000 via management interface 5070.
  • system 5000 include a planning and marking module 5080 for use by engineers and/or field contractors.
  • the engineers and/or field contractors map city parking facilities and upload the parking 20 map(s) through the planning and marking module 5080 to the virtual level 5050 of the base sub-system 5010.
  • Embodiments of the system 5000 further include a support system module 5090 for use by some or all of the following: a branch of the government's division of motor vehicles (DMV)/motor vehicle administration (MVA), a downfall system, a closed 25 space system, a blind spot system, a payment system, a data logging, analytics, and a backup system.
  • DMV motor vehicles
  • MVA motor vehicle administration
  • the downfall system is an alternate parking administration system to be implemented if the primary functionalities of system 5000 fail.
  • One non-limiting example of a downfall system includes the parking space markings, signs, and 30 regulations that were in place before system 5000 was implemented.
  • a closed space system manages vehicle tracking and space identification in locations where GPS reception is unreliable or non-existent, an example of the latter is within a parking garage.
  • Other forms of tracking implement Wi-Fi, ultrasound, and infrared technologies.
  • the related system for blind spots provides tracking during temporary GPS lapses, such as during inclement weather.
  • payment systems are also implemented to manage financial transactions between users and parking spot owners, and the payment system provides data to the system 5000 through the support system module 5090.
  • Data logging stores every parking event (see event history DB 168; Fig. 1), such as when a user reserves a space, occupies a space, and later vacates a space.
  • the data that are logged become available for analytics.
  • the analytics provide real-time and/or historic and/or predicted statuses of parking spot use. Also, the data become available for determining trends to facilitate better parking allocation in the future. For example, in some embodiments system 5000 observes congestion in some areas on weekends and responds by directing some users to park in less congested areas.
  • the backup system which also interfaces with the rest of system 5000 through system module 5090, enables the system 5000 to continue functioning even if some of the components malfunction.
  • the backup system implements redundant data storage, servers, and/or communication paths to be used primarily if one or more of the storage, servers, and/or communication paths malfunction.
  • Fig. 20a 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. 100) 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 900 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 6222 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). Alternatively or additionally, in some embodiments 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.
  • Fig. 21 is a schematic representation of a centrally managed parking system, indicated generally as 4100, according to some exemplary embodiments of the invention.
  • Depicted exemplary system 4100 receives inputs from user client devices 122.
  • a single device 122 is depicted for clarity, although in actuality a large number are typically present.
  • a single user client device 122 interacts with the system by providing, in sequence, a reservation 4112, a parking confirmation 4114 and an exit notification 4116. These three inputs together define a parking event.
  • Depicted exemplary system 4100 includes a reservation server 4110 receiving parking event inputs (as described above) from user client devices 122 and a parking spot status database 4120 in communication with server 4110 and configured to assign to each individual spot in the database a status 4122 selected from at least three possibilities selected from the group consisting of available, reserved and occupied in accord with the parking event inputs received by server 4110.
  • a "violation" status is assigned to the spot.
  • not available is a conglomeration of reserved, occupied, prohibited and violation; and "available” normally indicates an absence of any other designation, although there may be a situation in which a spot is currently available, even though it may have a future reservation.
  • system 4100 includes a mapping engine 4130 adapted to produce map output data for each spot.
  • a mapping engine 4130 adapted to produce map output data for each spot.
  • a map 4132 with each displayed spot and its status are visible to a user of the workstation.
  • the depicted exemplary embodiment also includes a reservation nesting module 4140 adapted to identify incoming reservation inputs 4112 with a defined parking duration and match them with spots that have a current status of available and a reserved status at a time that is further in the future than a present time plus the defined parking duration for a vehicle currently occupying the spot.
  • a reservation nesting module 4140 adapted to identify incoming reservation inputs 4112 with a defined parking duration and match them with spots that have a current status of available and a reserved status at a time that is further in the future than a present time plus the defined parking duration for a vehicle currently occupying the spot.
  • system 100 creates temporary spaces which blocks the egress of a vehicle parked in a permanent space.
  • the temporary spaces are assigned a temporary UID and location coordinates in spot DB 164 and are handle as other spots, with the caveat that a reservation filled with a temporary spot must be for a time that ends before the vehicle parked in the permanent space is scheduled to leave.
  • double parking creates additional parking spots on a demand responsive basis.
  • system 100 permits a vehicle to park in an empty spot which is reserved for another vehicle.
  • a user client device 122 is used to report what spot has been taken (for example using the UID and/or pavement markings and/or location coordinates). The system responds by transferring the "snatched" reservation to another spot.
  • Fig. 22a is a schematic representation of a centrally managed parking system, indicated generally as 4200, according to some exemplary embodiments of the invention.
  • Depicted exemplary system 4200 includes a database 4210 of individual parking spots. Each of the individual spots is associated with a unique identifier (UID) and map coordinates.
  • UID unique identifier
  • Depicted exemplary system 4200 also includes a command control center (CCC) 4220 with at least one computer workstation 4222 adapted to display a map and a graphical user interface (GUI) 4230 operable on the workstation.
  • CCC command control center
  • GUI graphical user interface
  • Fig. 22b is a schematic representation of an exemplary GUI 4230 of Fig. 22a indicated generally as GUI 4201.
  • Depicted exemplary GUI 4201 is adapted to receive a map area selection 4211 as a first input and at least one parking rule as a second input.
  • a map area may include one or more parking spots.
  • a map area may include contiguous spots or separated spots.
  • the selection of a map area 4211 may be performed by a user input device such as a mouse. Specifically one point or a set of points may be selected by positioning the mouse cursor thereover and pressing the mouse button, thereby to define the edges of the area 4211.
  • the set of points defining the edges of the area is used to define an array of points within the area using well known algorithms which check whether a point is inside a polygon.
  • rule editor 4203 which opens a rule editing interface.
  • An exemplary rule editing interface is depicted in Fig 16 as table 4203 which serves as a user interface for data entry (for example as a spreadsheet). This is described in detail in section entitled "Exemplary rule attributes” and “Exemplary rule application schemes” hereinbelow.
  • Operation of the rule editing interface in conjunction with map area selection 4211 populates the leftmost column of table 4203 with all spots in map area selection 4211. Rules entered in other columns of the table 4203 are then applied to all spots with location coordinates within the selected map area.
  • the map displayed on workstation 4222 displays individual on-street parking spots on the map (for example 4215). In depicted embodiment 4201 the map displayed on workstation 4222 also displays individual off- street parking spots on the map (for example 4213) and spots in off-street parking lots or garages map (for example 4217). Alternatively or additionally, in depicted embodiment 4201 the map displayed on workstation 4222 displays a current status of each of individual on-street parking spots on the map. In the depicted embodiment current status of available is indicated by an empty circle, current status of reserved is indicated by a triangle and current status of occupied is indicated by a filled circle. Each "X" indicates a spot where parking is currently prohibited.
  • spot editor 4205 provides an interface for entering dimensions (length, width, and height clearance of spots) and/or for entering other spot features (for example, indoor, electric charger, rear clearance or side clearance). Information entered via spot editor 4205 is stored in spot DB 164 (Fig. 1) and/or 4210.
  • vehicle editor 4207 provides an interface for entering status definitions (for example resident of a particular zone or handicap) to vehicles based on vehicle registration number. Information entered via vehicle editor 4207 is stored in vehicle DB 162 (Fig. 1).
  • "Admin" interface 4209 is used to set permissions of access by private spot manager 152 and/or lot spot manager 153 (Fig. 1).
  • the above-mentioned second input includes a temporal limitation.
  • temporal limitations indicate specific hours and/or specific days of week and/or specific types of days (for example holidays).
  • the second input includes a duration limitation.
  • Exemplary duration limitations include, but are not limited to, 30 minutes, one hour two hour and three hour parking and unlimited from eleven pm to six am.
  • system 100 adjusts the duration limitation in response to events. For example, if occupancy percentage of spots in a predefined zone increases, the system responds by decreasing the permitted parking duration from 30 minutes to 20 minutes.
  • the second input includes a price limitation.
  • the price is expressed as an hourly rate or a fixed price per parking event.
  • raising and lowering prices contributes to a change in percentage of occupied spaces in a zone.
  • the second input includes a user limitation.
  • a car with handicapped status has greater access and/or exempt from payment.
  • car registered to an address on a certain street gets payment exemption on that street.
  • the second input a vehicle type limitation. For example, no truck parking during rush hour and/or trucks exempt from payment before 7AM or after 7PM.
  • the second input relates to a group of individual on-street parking spots. For example, on a residential street with 50 on- street spots, 40 are reserved for residents of the street during specified times and all
  • the system reserves additional spaces in the lot for handicap vehicles.
  • the second input relates to at least two, at least three or at least four members of the group consisting of a temporal limitation, a duration limitation, a price limitation, a user limitation, a vehicle type limitation and a limitation which relates to a group of the individual on-street parking spots.
  • Fig. 22b (4203) and Fig. 16 4203 depict a second input UI adapted to accept layers of rules.
  • system 4200 include a database of individual parking spots 4210, each of the individual parking spots associated with a unique identifier (UID) and location coordinates and a command control center (CCC) 4220 with at least one computerized workstation 4222 adapted to display a map.
  • UID unique identifier
  • CCC command control center
  • system 4200 includes a user interface (UI) 4203 operable on workstation 4222.
  • UI 4203 is adapted to receive display of data of spots located in a geographical area as a first input and at least one parking rule as a second input and apply the at least one parking rule to all parking spots with location coordinates in the geographical area.
  • database 4210 includes individual on street and individual off street spots. Alternatively or additionally, database 4210 includes indoor spots.
  • the data display of the first input includes a table and/or a list. For example, a highlighted portion of a spreadsheet serves as the data display of the first input.
  • system 4200 include a database of individual parking spots 4210, each of the individual parking spots associated with a unique identifier (UID) and location coordinates and a command control center (CCC) 4220 with at least one computerized workstation 4222 adapted to display a map.
  • UID unique identifier
  • CCC command control center
  • system 4200 includes a graphical user interface (GUI) 4240 operable on workstation 4220.
  • GUI 4240 is adapted to receive a map area selection as a first input and at least one usage statistic as a second input.
  • usage statistics are input via Admin, interface 4209 (Fig. 22b).
  • system 4200 includes an analytic engine 4242 adapted to produce an output 4250 status report including at least one usage statistic for the parking spots with location coordinates in map area.
  • the usage statistics for the spots in the output are for individual spots or for all spots defined by the first input as a group.
  • the at least one usage statistic indicates percentage of spaces currently occupied.
  • the at least one usage statistic indicates percentage of spaces currently reserved and current average reservation time.
  • “reservation time” indicates an elapsed time from when an order was placed until parking was confirmed.
  • the at least one usage statistic indicates percentage of spaces currently reserved for a future time and average reservation time for the future time.
  • the at least one usage statistic indicates percentage of spaces currently in violation of applicable parking regulations.
  • the output status report 4250 depicts one or more usage statistics as a function of time.
  • At least some of the individual spots are on street spots.
  • the output status report depicts 4250 one or more usage statistics relative to different rules applied to the map area.
  • Fig. 23 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.)
  • 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. 24 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. 26a is a schematic representation, indicated generally as 1700, of differently- sized parking spots assembled from a requisite number of subunits 1710to 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. 25 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. 26b 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.
  • 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 a length and/or width of the rectangle to cover additional subunits.
  • Fig. 26c depicts a GUI implementation of this optional feature on map 1702 as in Fig. 26b.
  • rectangle 1740 is expanded by addition of area 1742.
  • the hollow arrow indicates positioning over subunits 1730 and 1731 and 732. As a result of the expansion of the rectangle, that is the only choice in this example.
  • Fig. 27 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. 27 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.
  • SuggestionListl i.e. it was not available when SuggestionList 1 was made
  • 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 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. 27 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. 28 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.
  • 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, for example, 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). 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.
  • system 100 identifies drivers in addition to or instead of vehicles.
  • a driver is associated with a driver UID and/or a reputation of the driver.
  • driver UIDs include, but are not limited to EV1EI (international mobile station equipment identity code) of the driver's cellphone, an ANDROID_ID for ANDROID devices, or a MAC Address for a MACINTOSH device.
  • one or more driver Ids are associated with, or are part of, a user profile. Vehicle icons
  • 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 attributer.
  • 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.
  • the "rule scheme" may be a price rule scheme as exemplified in the table 4203, a duration rule scheme, etc.
  • the rule scheme includes a function of the attribute (e.g., price function or duration function) such that changes to the attribute may be dynamic and dependent on a changing status and/or on predetermined laws.
  • rules have start date and/or end date and/or times as attributes. According to these embodiments future reservations for spots are handled in accord with the rules which will be applicable on the relevant date/time and not in accord with the rules in effect at the time the reservation is received.
  • minimum availability for a category is a rule attribute.
  • This attribute indicates that no matter how many vehicles in a category (e.g. handicap) are already present in a defined area (e.g. a parking lot or a city block), at least X additional spots must remain available for that category.
  • a category e.g. handicap
  • a defined area e.g. a parking lot or a city block
  • X is an integer between 1 and a hundred.
  • Fig. 16 is a table, indicated generally as 3600 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.
  • table 3600 is a spreadsheet which receives data inputs and/or functions as a user interface.
  • 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.
  • 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) .
  • 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.
  • system 100 is configured to handle irregular parking events of various types.
  • irregular parking events include, but are not limited to, unreported entrance, and/or false reporting of entrance and/or false reporting of exit.
  • unreported entrance is perceived by system 100 (Fig. 1) as a reservation cancellation after a predetermined amount of time.
  • the vehicle that parked without reporting their entrance is in violation.
  • the violation is likely to be discovered by another user assigned to the same spot and/or by a warden.
  • false reporting of entrance is discovered by system 100 as duplicate parking events for the same vehicle at two different locations at the same time. In these cases the system responds by dispatching a warden and/or service vehicle to investigate.
  • false reporting of exit creates a violation situation for a vehicle that remains in a spot that was legitimately reserved for it.
  • machine readable format for example digitally encoded latitude and longitude coordinates to monitor and/or maintain status information pertaining to individual parking spots and/or to communicate a location of a reserved spot to a user client device and/or as in input for a mapping and/or navigation program.
  • machine readable format includes digital data and/or analog representations of that digital information (such as a QR code or bar code).
  • analog representations are printed.
  • the machine readable data includes an instruction which, when read by a user client device, launches an application on the user client device and provides access to relevant position coordinates to the newly launched application.
  • suitable machine readable information formats include QR codes and/or barcodes and/or hypertext links.
  • Exemplary instruction formats include QR codes, bar codes and hypertext links.
  • a vehicle navigation system receives machine readable location information in the form of digital location coordinates which are loaded directly into an already running application.
  • 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 a driver may be directed to a parking spot based on a GUI as exemplified in Fig. 7b.
  • physical infrastructure for example, parking meters and/or parking regulation signs and/or access gate
  • 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 provides control over previously un-monitored parking spots, such as no-cost parking.
  • 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.
  • 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.
  • This feature enabled by methods and systems according to embodiments of the invention allows for suitable parking spots for trucks thereby contributing to a reduction in eliminating traffic congestion.
  • 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.
  • a UI of a user client device 122 used by a warden includes a map or other representation of a region showing available and non-available parking spots or subunits.
  • a warden is referred to specific parking spots through violation system 130 and/or the warden identifies violations by comparing the map on user client device 122 to the actual situation on-site.
  • the wardens photographs a license plate of an offending vehicle.
  • the license plate number is scanned by OCR to facilitate issue of a report 131 by violation system 130. According to various exemplary embodiments of the invention the OCR is done at user client device 122 and/or at server 120.
  • 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 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 are 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.
  • method 2700 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 2800 (Fig. 7b)) 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 2800 (Fig. 7b)) 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 device 2800).
  • 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.
  • 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 kiosk 2900 (Fig. 9) or devices at call centers.
  • IVR Interactive voice response
  • vehicle details such as size and color may be 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 kiosk 2900 (Fig. 9) 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 2900 (Fig. 9) or by mail.
  • 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

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Accounting & Taxation (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Traffic Control Systems (AREA)
  • Navigation (AREA)

Abstract

L'invention porte sur un système comprenant : (a) une base de données de places de stationnement individuelles sur et hors voirie, chacune des places de stationnement individuelles étant associée à un identifiant unique (UID) et à des coordonnées d'emplacement ; (b) un module de gestion de places hors voirie en communication avec un ou plusieurs dispositifs clients externes, conçu pour recevoir des règles de stationnement d'un dispositif client externe actionné par un propriétaire de chacune des places de stationnement individuelles hors voirie.
PCT/IB2016/051193 2015-08-27 2016-03-02 Système et procédé de stationnement dans toute la ville WO2017033066A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
IL257752A IL257752A (en) 2015-08-27 2018-02-27 A system and method for parking throughout the city

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
IBPCT/IB2015/056509 2015-08-27
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
US15/058,766 2016-03-02
US15/058,540 US20170018183A1 (en) 2014-08-27 2016-03-02 System and method of creating a dynamic parking spot
US15/058,245 2016-03-02
US15/058,766 US20160180712A1 (en) 2015-08-27 2016-03-02 Citywide parking reservation system and method
US15/058,540 2016-03-02
US15/058,245 US20160180261A1 (en) 2015-08-27 2016-03-02 System and method of creating a dynamic parking spot and a system and method of creating a dynamic parking zone\region

Publications (1)

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

Family

ID=58099899

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2016/051193 WO2017033066A1 (fr) 2015-08-27 2016-03-02 Système et procédé de stationnement dans toute la ville

Country Status (2)

Country Link
IL (1) IL257752A (fr)
WO (1) WO2017033066A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111815091A (zh) * 2019-04-11 2020-10-23 深圳市家家分类科技有限公司 垃圾协同处理方法及相关设备
WO2020241988A1 (fr) * 2019-05-28 2020-12-03 엘지전자 주식회사 Procédé pour véhicule pour communiquer avec un réseau dans un système de communication sans fil, et véhicule associé
US20220222589A1 (en) * 2019-05-27 2022-07-14 Sharp Nec Display Solutions, Ltd. Display management device, display management method, and program
CN115147944A (zh) * 2022-09-01 2022-10-04 浙江省邮电工程建设有限公司 一种智慧小镇停车智能管理方法和系统
US20220326711A1 (en) * 2021-04-13 2022-10-13 Waymo Llc Evaluating pullovers for autonomous vehicles

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130073350A1 (en) * 2010-06-01 2013-03-21 Pink Park Ltd. Parking space management system and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130073350A1 (en) * 2010-06-01 2013-03-21 Pink Park Ltd. Parking space management system and method

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111815091A (zh) * 2019-04-11 2020-10-23 深圳市家家分类科技有限公司 垃圾协同处理方法及相关设备
CN111815091B (zh) * 2019-04-11 2024-03-26 深圳市家家分类科技有限公司 垃圾协同处理方法及相关设备
US20220222589A1 (en) * 2019-05-27 2022-07-14 Sharp Nec Display Solutions, Ltd. Display management device, display management method, and program
WO2020241988A1 (fr) * 2019-05-28 2020-12-03 엘지전자 주식회사 Procédé pour véhicule pour communiquer avec un réseau dans un système de communication sans fil, et véhicule associé
US11853928B2 (en) 2019-05-28 2023-12-26 Lg Electronics Inc. Method for vehicle to communicate with network in wireless communication system, and vehicle therefor
US20220326711A1 (en) * 2021-04-13 2022-10-13 Waymo Llc Evaluating pullovers for autonomous vehicles
US11947356B2 (en) * 2021-04-13 2024-04-02 Waymo Llc Evaluating pullovers for autonomous vehicles
CN115147944A (zh) * 2022-09-01 2022-10-04 浙江省邮电工程建设有限公司 一种智慧小镇停车智能管理方法和系统

Also Published As

Publication number Publication date
IL257752A (en) 2018-04-30

Similar Documents

Publication Publication Date Title
US20160371607A1 (en) Citywide parking system and method
US20160180712A1 (en) Citywide parking reservation system and method
US20170018183A1 (en) System and method of creating a dynamic parking spot
US20160180261A1 (en) System and method of creating a dynamic parking spot and a system and method of creating a dynamic parking zone\region
US11545031B2 (en) System and method for providing distributed on-street valet parking with the aid of a digital computer
US11011058B2 (en) Computer-implemented system and method for providing available parking spaces
WO2017033174A1 (fr) Système et procédé de réservation de stationnement à l'échelle de la ville
US20170140586A1 (en) Vehicle parking system and method
US10395535B2 (en) Method and system for legal parking
JP6139504B2 (ja) 駐車管理システムと方法
US8816879B2 (en) Computer-implemented system and method for managing interchangeable parking spaces
US20170206471A1 (en) Public parking space remote reservation system
WO2018156112A1 (fr) Appareil de stationnement de véhicule intelligent et procédés associés
WO2017033066A1 (fr) Système et procédé de stationnement dans toute la ville
US20200242583A1 (en) Curbside management system for connected and autonomous vehicles
Jioudi et al. e-parking: Multi-agent smart parking platform for dynamic pricing and reservation sharing service
WO2020210796A1 (fr) Système et procédé de ramassage et de débarquement de covoiturage
US20210082078A1 (en) The system and method of operating the self-steering electric taxi and smart underground parking lots
Kharde et al. Smart parking system
Mason E-Scooters in Eugene, Oregon: Recommendations for Regulations
Ison et al. Parking
Percival et al. Information architectures for next generation car park services

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 257752

Country of ref document: IL

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 1205 DATED 21/08/2018)

122 Ep: pct application non-entry in european phase

Ref document number: 16838623

Country of ref document: EP

Kind code of ref document: A1