GB2540413A - System for processing parking transactions - Google Patents

Abstract

A system 100 and method for processing a vehicle parking transaction relating to a vehicle parked at a parking location is disclosed. The method is performed at a computer-implemented parking transaction system. Tracking information 105 indicative of a location of the vehicle is received. The system then accesses stored parking session information 103 associated with the vehicle, the parking session information indicating that a parking session is in progress, and determines based on the tracking information that the vehicle has departed the parking location. In response to the determination, a parking transaction is automatically processed to terminate the parking session, e.g. by initiating a payment transaction. Also disclosed is a method of processing a vehicle parking transaction characterised by transmitting information to a user device 132, specifying parking locations in a vicinity of the vehicle and initiating a parking session in response to a user selection.

Description

System for processing parking transactions

The present invention relates to a system for processing vehicle parking transactions.

Traditional solutions for implementing parking transactions and fee collection typically involve parking meters or pay-and-display car parks, where a ticket is acquired from a ticket vending machine for display in the user’s vehicle. In such approaches, users typically have to estimate the duration of their stay in advance. If the duration is underestimated the user has to return to the car park to top up the payment, which is very inconvenient, or risk a fine. If the duration is overestimated then the user will have overpaid for their stay.

More recently, some parking facilities provide for conducting parking transactions by telephone, e.g. by calling a number displayed at the facility and using an automated telephone system to make a card payment. Whilst convenient, such systems do not adequately address the above problems. On the other hand, some facilities issue tickets on arrival but allow payment on departure, but such facilities rely on secure gated access to ensure vehicles can only depart the facility after making payment, increasing the infrastructure required and hence the cost and management complexity to the parking facility operator.

The present invention seeks to alleviate certain problems associated with known approaches by providing novel technical solutions to the processing of parking transactions.

Accordingly, in a first aspect of the invention, there is provided a method of processing a vehicle parking transaction relating to a vehicle parked at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving tracking information relating to a location of the vehicle; accessing stored parking session information associated with the vehicle, the parking session information indicating that a parking session is in progress; determining based on the tracking information that the vehicle has departed the parking location; and in response to the determination, processing a parking transaction to terminate the parking session.

Processing a parking transaction may comprise one or more of: updating the stored session information to indicate completion of the session; determining a parking duration of the session, preferably based on one or both of: a session start time recorded in the parking session information, and a departure time associated with the received tracking information (e.g. the time may be specified in the tracking information or may be based on the time of receipt of the tracking information); and initiating a payment transaction to take payment for the parking session, preferably in dependence on the determined parking duration. The processing step may comprise accessing transaction rule information associated with the parking location in a database, calculating a payment amount based on the transaction rule information and optionally the determined parking duration, and initiating the payment transaction based on the payment amount. The processing step may comprise transmitting session information to an operator associated with the parking location. Updating session information may include storing the session end time, parking duration and/or payment information.

The determining and processing steps are preferably performed in response to receiving the tracking information indicating departure of the vehicle from the parking location, preferably without user interaction. Thus, the transaction may be processed and the parking session completed (e.g. including a payment transaction) automatically following departure of the vehicle from its parking location. By carrying out the transaction based on the tracking information, user intervention is not needed to complete the session, nor is any special equipment (such as ticket machines, automated gates etc.) needed at the parking site.

The method may comprise, prior to the receiving, accessing, determining and processing steps, initiating the parking session based on further received tracking information. Thus, both the start of the session and the end of the session may occur in response to tracking information.

The method may comprise identifying a parking location based on the further received tracking information. This may occur automatically (based on the tracking information, without user input) or semi-automatically (based on the tracking information and user input). For example, the method may include detecting, based on the further tracking information, that the vehicle is in the vicinity of one or more parking locations (e.g. at or near a particular parking site or car parking facility), and in response transmitting parking location information to a user device of a vehicle user. The parking location information may comprise information identifying one or more parking locations, preferably comprising a map, the method optionally further comprising receiving a user selection of one of the identified parking locations.

As used herein, “parking site” may refer to an area or facility providing for parking of multiple vehicles, whilst “parking location” refers more generally to any information specifying a location at which a vehicle is parked (or may park), for the purpose of completing transactions. In some embodiments, a “parking location” may correspond to a specific parking space or bay, which may be part of a parking site. However, a parking location may also correspond to a parking site or facility or other geographical area available for parking.

Thus a vehicle location obtained from the tracking information may be used to determine an approximate parking location (e.g. a parking site/facility or limited geographical area), with the user selecting or confirming a specific location (e.g. a site/zone or a particular space or bay).

Alternatively, the method may comprise identifying the parking location automatically based on the tracking information, without user interaction. For example a parking facility or site, or even a specific parking bay may be automatically determined without requiring user confirmation if the tracking information provides sufficient location accuracy. In some cases, it may be sufficient for transaction processing purposes to determine as the parking location the facility or site at which the vehicle is parked (e.g. via a coarse GPS fix) without needing to know the specific bay. In one embodiment, the tracking information may comprise primary location information having a first level of accuracy (e.g. a GPS location) and supplementary tracking information, the method comprising determining the vehicle location to a second, greater level of accuracy, based on the primary location information and the supplementary tracking information. The supplementary tracking information may comprise one or more of: movement distance information (e.g. based on wheel rotation information), and information from an accelerometer associated with the vehicle. Thus multiple types of tracking information may be combined to provide an improved location fix (e.g. to identify a particular bay). Supplementary information could also include roadside/kerbside sensor information or any other information useful for improving location accuracy.

The features relating to initiation of a parking session may also be provided independently. Thus, in a further aspect (which may be combined with any of the other aspects set out), the invention provides a method of processing a vehicle parking transaction relating to a vehicle parked at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving tracking information indicating a location of the vehicle; transmitting information to a user device associated with a user of the vehicle, the transmitted information specifying one or more parking locations in a vicinity of the vehicle, the parking locations determined based on the location of the vehicle (for example using a database of parking locations as set out elsewhere herein); receiving a selection of one of the parking locations from the user device; and initiating a parking session at the parking transaction system based on the selected parking location.

Note that wherever reference is made herein to a vehicle location the location may be determined from a tracking device installed at the vehicle, or may be inferred from the location of a user device (e.g. smartphone) associated with a user of the vehicle (it being assumed that a user and their user device are located in the vehicle when using the system). Similarly vehicle tracking information may refer to information relating specifically to the vehicle, or to information inferred from user device tracking information.

In this or any of the other defined aspects of the invention, the parking location information sent to a user device may further include availability information indicating availability of one or more of the parking locations. The method may comprise transmitting the parking location information to a parking system client application at a user device associated with the vehicle (such as a vehicle user’s smartphone), and receiving the selection from the parking system client application. The information may comprise a map indicating the one or more parking locations, the selection being received based on user interaction with the map.

In a further aspect (which may be combined with any of the other aspects set out), the invention provides a method of processing a vehicle parking transaction relating to a vehicle parked at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving tracking information indicating a location of the vehicle; determining based on the tracking information that the vehicle is located at a parking location based on a database of parking locations; and, in response to the determination, initiating a parking session at the parking transaction system.

Initiating a parking session may comprise storing session information specifying the identified parking location (and optionally other information) as set out elsewhere herein. The method may comprise identifying the parking location of the vehicle based on the database and the tracking information. For example, a vehicle location specified by the tracking information may be compared to parking locations defined in the database to identify the location at which the vehicle is parking. Identifying the parking location may comprise transmitting parking location information to a user device and receiving a selection, e.g. as set out above.

Alternatively, identifying the parking location may comprise selecting a parking location from parking locations specified in the database based on the tracking information, preferably without user interaction. Thus, the parking session may be initiated without the user having to select or confirm a parking location.

In either of the above aspects, the parking session may subsequently be completed based on receipt of further vehicle tracking information indicating departure of the vehicle from the parking location, preferably using a method as set previously.

The following optional features may be applied to any of the above aspects.

While in some embodiments, the user may provide a confirmation that parking is desired before a parking session is initiated, in other embodiments, the session may be initiated completely automatically without any user intervention. Thus, the method may include initiating the parking session without user intervention in response to detecting arrival at a parking location based on the tracking information. Preferably, the determining step comprises determining based on the vehicle tracking information that the vehicle has come to a stop at the parking location and initiating the parking session responsive to the determination (e.g. by determining that the vehicle has remained at the location for a predetermined length of time). This may prevent spurious transactions e.g. if a user drives past a parking location or stops only briefly.

Initiating a parking session may comprise storing parking session information, the parking session information preferably comprising at least one of: information identifying the parking location; a session start time; and user and/or vehicle identification information. The stored parking session information can then be used to complete the parking session later when the vehicle departs the parking location.

In a further aspect of the invention (which may be combined with any of the other aspects set out), there is provided a method of processing a parking transaction for a vehicle parking at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving, from a vehicle tracking device at the vehicle, vehicle tracking information indicating a location of the vehicle; determining a parking location based at least in part on the tracking information; storing session information for a parking session, comprising information specifying a session start time and the parking location; subsequently receiving further vehicle tracking information indicative of a departure of the vehicle from the identified parking location, and, in response to the further tracking information: determining a session end time; and processing a parking transaction in dependence on the parking location and the session start and end times. One or both of starting and ending the parking session may comprise starting and/or ending the session in response to received tracking information without user intervention.

The method may comprise performing the further steps of a method as set out in any of the previously defined aspects of the invention.

In any of the above aspects, the following features may additionally be provided. The method may comprise transmitting parking session information for a completed parking session to a user device associated with a user of the vehicle. For example, a summary may be sent including one or more of: location, parking duration, and fee charged.

The tracking information may comprise one or more of: a vehicle location; a location of a user device (e.g. smartphone) associated with a user of the vehicle (which may be used as the vehicle location in processing parking transactions); a vehicle start indication; a vehicle stop indication; and time information (where the preferably time indicates the time to which tracking information relates, e.g. the time of a GPS reading or of a vehicle start/stop event).

The tracking information may be based on tracking information transmitted by one or more of: a vehicle tracking device at the vehicle; a personal computing and/or communications device associated with a user of the vehicle; and a sensor installed at the parking location. Such a sensor may comprise an NFC, RFID or Bluetooth-enabled device and may be installed adjacent or near a parking location (for example associated with a particular parking bay or space), i.e. the sensor is separate from the vehicle. The sensor is preferably arranged to communicate with a corresponding device in the vehicle (e.g. the vehicle tracking device). Communication (or lack thereof) between vehicle and roadside sensor is preferably used to detect arrival (or departure) of a vehicle at the location. The sensor preferably provides identification information from which the parking location may be determined. Tracking information from any of the above sources may be combined.

The method may comprise receiving the tracking information from a vehicle tracking server, the vehicle tracking server transmitting the information responsive to vehicle tracking information received at the server from a vehicle tracking device installed at the vehicle.

Further aspects provide a transaction processing system, apparatus or device comprising means (e.g. in the form of a suitably programmed processing device) for performing any method as set out herein, and a computer-readable medium comprising software code adapted, when executed on a data processing apparatus, to perform any method as set out herein.

In a further aspect, the invention provides a transaction processing system comprising: a vehicle tracking device installed at a vehicle and configured to transmit vehicle tracking information including location information of the vehicle; a transaction processing module adapted to receive the vehicle tracking information, the transaction processing module comprising: a database for storing parking session information associated with the vehicle, the parking session information indicating an ongoing parking session and comprising a parking location of the vehicle; means for detecting based on the received vehicle tracking information a departure of the vehicle from the parking location; means for, in response to detecting the departure, determining a duration of the parking session; and means for, in response to detecting the departure, processing a parking transaction to complete the parking session in dependence on the parking location and the determined duration. The processing means is preferably configured to initiate a payment transaction. The system preferably further comprises means for performing any method as set herein.

In a further aspect, the invention provides a computer readable medium comprising software code for implementing a parking transaction client application for execution on a user device, the software code adapted to perform the steps of: receiving information from a parking transaction system indicating one or more parking locations in a vicinity of a determined location of the user device or a of vehicle associated with a user of the user device; displaying the information on a display of the user device; receiving a selection of one of the parking locations from a user; and transmitting the selection to the parking transaction system to initiate a parking session at the parking transaction system. The software code may further be adapted to: receive a notification from a parking transaction system (e.g. after the parking transaction system detects arrival of the vehicle in the vicinity of a parking location), and display the information responsive to the notification; or access and display the information responsive to activation of the application by a user. The software code may further be arranged to transmit location information of the user device to the parking transaction system, wherein the information is received in response to transmission of the location information. The location information may be obtained from a location service and/or geolocation sensor (e.g. GPS) at the user device.

The software code is preferably further adapted to participate in a parking transaction conducted according to a method as set previously. Method and apparatus/system aspects corresponding to this aspect of the invention may also be provided.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus and computer program aspects, and vice versa.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:-

Figure 1 illustrates components of a parking transaction processing system;

Figure 2 illustrates a process for initiating a parking session;

Figure 3 illustrates a process for completing a parking session;

Figure 4 illustrates a process for conducting a parking session without user interaction;

Figures 5-8 are illustrative screenshots of a mobile application; and Figure 9 illustrates a transaction processing server and user device.

Overview

Embodiments of the present invention provide a transaction processing system for processing vehicle parking transactions. The transaction processing system implements a one-click parking system that enables users to pay for parking through a smartphone application which ensures that they pay the correct amount for the duration for which they parked. The only action required is that the user is asked to confirm in the application that they are about to start parking at a particular location (this is the ‘one click’). The system detects when they have driven away, calculates the correct fee, and automatically makes a payment to the appropriate authority without further intervention by the user. A further described embodiment allows for a fully automated parking transaction in which both the start and end of a parking session are detected automatically based on vehicle tracking information.

There are several elements working together to provide the service, including: • A parking database and Content Management System (CMS) • Data ingress processes • A parking rules engine

• A parking search API • Integration with in-vehicle tracking devices • Availability monitoring • A client application

Each of these is described in the following sections, with reference to Figure 1.

Parking Database and Content Management System

Figure 1 illustrates a parking transaction processing system 100 in overview.

The system 100 maintains a database 102 of relevant parking information such as authorities, parking zones or sites, parking session information and other information used in the processing of parking transactions. This information is stored in and managed by a custom-built system referred to herein as the Content Management System (CMS) 104.

The CMS and database supply relevant information to the online transaction processing part of the system to allow processing of parking transactions. The database 102 may form part of the CMS or may be implemented as a separate component. The CMS and database may be implemented as a web service hosted by a cloud computing provider, with persistent storage also provided by a cloud computing provider (in a preferred example using ‘no SQL’ database storage and blob storage). Transient searchable indexes may further be provided, maintained by a cluster of virtual machines also hosted by a cloud computing provider.

The database 102 includes various information including: • Session information 103, comprising information relating to ongoing and completed parking sessions • Vehicle location/status information 105, indicating the location or movement status of vehicles based on received vehicle tracking information • Zone boundaries 106 which indicate geographical boundaries of parking zones or sites and bay shape/location information 108, specifying shapes/boundaries of individual parking bays within parking zones/sites where available, or bay centre locations otherwise. Together, the zone boundaries and bay information thus provide geographical information specifying areas where parking is possible and locations of specific parking bays within those areas. • Parking rules 110, including descriptions of the rules, regulations and charging criteria for different parking zones (or even individual bays). The rules determine when parking is allowed and under what conditions. • Searchable parking rules representation 112 which provides a processed, searchable representation of the parking rules 110 • Cached availability information 113 indicating (near) real-time parking bay availability

Note that while for illustrative purposes a single database is shown, the information may in practice be distributed across different databases. For example, relatively static information such as geographical information and rules information may be stored in one database, and dynamically modified information (e.g. session information) may be stored in another database. A parking zone, site or facility is generally an area having multiple parking spaces/bays, for example a car park or group of roadside bays associated with a particular parking authority and having a common set of parking restrictions and charging rules (though some sites could include just a single bay). Thus, embodiments of the invention generally seek to identify the zone/site/facility to enable accurate charging. However, embodiments of the system may also provide for identifying a specific bay or space at which a vehicle is parked, for example if restrictions/charging rules are defined per bay.

Data Ingress Process

The parking database 102 contains information obtained from numerous sources, some of which are available in digital form (e.g., many local government authorities such as councils supply parking zone and bay information in a digitized format.) An automated data import service 114 is provided for bringing this data into the system from external data sources 116, cleaning it (e.g. fixing errors, adding missing information), and translating it into the representation used in the CMS.

Data ingress runs are preferably implemented as a batch job hosted by a cloud computing provider, and is controlled through a web user interface. The web user interface directs the data ingress process by sending messages via a reliable queued message service (also provided by a cloud computing provider).

Parking Rules Engine

While the parking database 102 contains descriptions of the rules 110 that determine where users can park and under what conditions, the applicable parking regulations can often be very complex and varied in nature. As a result it may not be straightforward to answer questions such as “Can the user park here at this time?” or “What will it cost to park here?” based on the rules information 110 available to the system.

The system therefore provides a rules engine 118 that processes the rules store 110 in the parking database, and converts it into a searchable ‘timeline’ representation 112 of the rules that can provide simple answers to parking queries (such as the aforementioned ones) for any particular date and time in a way that requires significantly reduced processing at runtime, and which does not require complex logic in smartphone applications or websites to determine where the user can park, and what the associated cost will be.

The parking rules engine preferably runs as a batch job hosted by a cloud computing provider, and is controlled through a web user interface. The web user interface directs the engine by sending messages via a reliable queued message service (also provided by a cloud computing provider).

The rules engine takes time-based rules (e.g., parking not allowed between 8:30am and 6:30pm; tariff £4.40/h up to 1:30pm, £3.30/h after) and determines at what time a change occurs for any particular parking zone/bay/restriction/other on-road feature. Any rule changes due to special days such as bank holidays or other named days (e.g., special nonholiday days such as New Years Eve) are also taken into account, as are rule changes caused by sports matches, and other events at large venues that result in adjustments to parking rules. For each day in the time period for which the rules engine is building a timeline, the times are adjusted to UTC (taking into account the time offset due to time zone and/or daylight saving in effect for the date in question), and then the rules for each segment of time between each of the calculated change times are determined. Having calculated this for every day in the time period in question, any temporally adjacent segments that turn out to have identical rules are then coalesced into a single segment (e.g., this typically happens when parking is free overnight — a segment saying “Free from Monday 6:30pm to Monday midnight” and one saying “Free from Tuesday midnight to Tuesday 8:30am” will be combined into a single “Free from Monday 6:30pm to Tuesday 8:30am” segment). This may also involve longer periods, e.g. 24hr restrictions Mon-Sat would collapse from 6 separate segments down to one in any given week; 24x7 restrictions may become just one segment spanning the entire duration of the timeline.

The above rule translation process is performed for each parking location (zone, site or even individual bay) for which parking rules are defined in the database, and is performed for a predetermined time period (e.g. the next week or month) to generate rule timelines for each zone covering that time period. The rule generation is then repeated as necessary to ensure up-to-date rule timelines are available to the system.

The result of the rules processing is that for each restriction type for each road feature (parking zone/location) a sequence of segment definitions is produced which completely spans the entire timeline duration with no overlap, defining the rules and any charges in effect for that restriction type on that road feature at any time. This is stored in the database in a way that can be searched based on time, restriction type, and a geographic location or region.

Parking Search API

The searchable representation 112 produced by the parking rules engine is made available through a web API 124 that is used by an application running on a user device 132 (such as a smartphone) to enable the user to find out where one can legally park, and what it will cost, in any particular area. The same API can also used to discover nearby parking locations when a user’s vehicle stops.

The parking search API 124 may be implemented as a web service hosted by a cloud computing provider, and a searchable index (built by the parking rules engine 118) running on a cluster of virtual machines hosted by a cloud computing provider.

By using the timeline representation 112 of parking rules, the Search API is able to indicate for any identified parking locations the applicable rules (e.g. restrictions, costs) at a given time (typically at the time of search, though the user may also wish to search in advance e.g. when planning a trip).

For location based searches, based on the timeline representation 112 of the parking rules, the Search API is able to use criteria such as “find me rules for any paid parking bays in this rectangular region at the current time” where the rectangular region might be the area of map visible on a phone’s screen, or a search might look for “any paid bay within 30m of this particular point” if the system assumes that the location reported by vehicle tracking systems is only accurate to within 30m. As another example, a search might take the form “find me any controlled parking zone containing this exact location” for showing rules about zones at a location the user has pointed to on a map.

If a highly accurate vehicle location is available (e.g. to within a few centimetres), a search could be performed based on the vehicle’s shape in plan view to see which, if any, parking bays it was located in. Alternatively, search could be based on intersection with any arbitrary shape.

Integration with vehicle tracking service

The system uses an external vehicle tracking service 128 to receive information on vehicle locations and movements. The vehicle tracking service receives tracking information from vehicle tracking devices 130 installed in users’ vehicles (where the users typically subscribe to a vehicle tracking service associated with the specific tracking hardware used). In one example the vehicle tracking solution employed is Vodafone xone (TM), though other solutions may be used.

The parking transaction service 126 integrates with one or more such vehicle tracking services (e.g. provided by multiple different service providers). A given vehicle tracking service 128 sends notifications to the parking transaction service 126 each time a tracked vehicle starts or stops. The notifications may further specify GPS position information giving the location of the vehicle at the time, and the relevant time. Alternatively, the vehicle tracking information received could merely include GPS position information (and time information), with the transaction processing server itself detecting start and stop events based on comparing a current GPS position to previous GPS information. Whether done at the vehicle tracking system or the transaction processor, detection of a stop event may require the vehicle to remain stationary (possibly within some degree of tolerance) for a period of time before the lack of change in position is interpreted as a stop event.

The parking transaction service 126 keeps track of the vehicle state in vehicle location/status records 105, and reconciles apparent inconsistencies that can arise as a result of lost messages, out-of-order message delivery, and other problems that can arise when integrating with third party vehicle tracking systems.

The vehicle tracking devices may be provided by a third party provider and may be retrofitted or integrated into the vehicle at time of manufacture. The vehicle tracking devices include GPS (or other geolocation) sensors and cellular communications systems. These devices 130 send messages using conventional cellular network SMS mechanisms (the same system that powers ordinary text messages on phones). The vehicle tracking service that processes these SMS messages may also be operated by a third party. The parking transaction service 126 provides an integration layer comprising a web service hosted by a cloud computing provider, persistent ‘no SQL’ table storage hosted by a cloud computing provider, and reliable queued message delivery provided by a cloud computing provider to enable asynchronous processing of messages.

Alternatively, the transaction service 126 may communicate directly with vehicle tracking devices 130 without using an intermediate third party tracking service 128.

The tracking devices typically incorporate GPS receivers, but other geolocation technology could be used, e.g. based on GLONASS, Galileo or other satellite systems, mobile network cell detection/triangulation, WI-FI access point detection/triangulation etc. Multiple such information sources may be combined to produce vehicle tracking information. For example, some modern location sensors may utilise information from both GPS and GLONASS satellites depending on availability and the term “GPS” is intended to encompass such hybrid solutions. As mentioned elsewhere herein, instead of dedicated vehicle tracking solutions, user device location information obtained from location sensing technology provided in a user device (e.g. smartphone) may also be used.

Availability Monitoring

Where possible, the system provides information about how many parking bays are available at each on-street parking site.

Such information is not universally available — it requires the parking authority to fit street-side sensors that detect when parking bays are in use, so this feature is available only in certain areas, and even then it is typically only available for selected parking bays. The present system includes an import service 120 that regularly fetches real-time availability information from relevant external sources 122 via an interface 121 to the appropriate parking authorities’ systems, and places this in a cache 113 available to the parking transaction service and other back-end systems (e.g. this may be part of the database 102). When client applications make requests to the parking search API 124, availability information is added to the results where it is available from the cache 113.

The relevant parking authorities with which the system interfaces may include local government authorities (e.g. town or city councils) as well as commercial car park operators.

The availability monitoring system may be implemented as an in-memory data caching system hosted by a cloud computing provider, and a continuously-running processing job 120 to fetch availability data from sources 122 and load that information into the cache 113 (this job also being hosted by a cloud computing provider).

User device and client application

The user device 132 is typically a smartphone. However, other personal communications and/or computing devices could be used, such as tablet or laptop computers, smartwatches and the like. The user device may also be in the form of a vehicle on-board computer (e.g. a computing device permanently installed in the vehicle for providing vehicle information, navigation services, entertainment services and the like).

The user device runs a client application providing user interaction with the transaction service 126.

The user application provides a search interface for finding parking sites. The search interface can provide information on parking zones and bays at a given location specified by the user (e.g. when planning a journey) or at an automatically determined location (e.g. for an impromptu search). Search results are preferably augmented where possible by real-time availability information 113, e.g. to indicate availability of specific parking bays or number of available bays at particular sites/zones.

The application further provides an interface allowing the user to confirm their intention to start a parking session, in which case a parking session is initiated as described below.

The user application further provides functionality allowing a user to provide location confirmation when a parking session is initiated (manually or automatically), for example to allow a user to select a particular parking site or bay in the vicinity of the vehicle as described in more detail below.

The user application may additionally provide summary information for completed parking sessions (e.g. total duration, cost etc.). Alternatively, such information may be sent to a user by SMS or email.

While in the examples described herein, the system obtains location information from dedicated vehicle tracking devices 130 installed in vehicles, tracking information may alternatively (or additionally) be obtained from the user device 132. In that case, the system assumes that the user’s device is located in the vehicle, and the user device location is therefore assumed to correspond to the vehicle location.

Whether for search purposes, or for providing vehicle tracking information to initiate/terminate parking sessions (in place of or in addition to the dedicated tracking devices 130), such location information may, for example, be obtained from a location service of the user device or its operating system (such as Google/Android location services, which may be based on cell location, Wi-Fi access points, a GPS sensor etc.). Location information may also be obtained directly from a geolocation sensor of the device (e.g. a GPS sensor).

Figure 1 is intended to provide a logical, schematic view of functional components. Actual implementations may distribute functionality in any appropriate manner. Thus, while Figure 1 illustrates functionality distributed in a particular way between services, devices and other components, the functionality may be mapped to physical computing devices and processes in any suitable manner.

For example, import services 114 and 120 and rules engine 118 may be part of the CMS 104 or may be separate components. Furthermore, particular system components (or groups of system components) may be implemented on a single server, or on multiple servers (e.g. via distributed cloud platforms), as required. For example, the CMS 104 may run on a first server or group of servers and the transaction service 126 may run on a second server or group of servers; alternatively those components may run on the same server(s).

The various components may communicate using any appropriate wired or wireless networks, including mobile telephony networks, private local-area networks and the public Internet.

Transaction processing

The process of starting a parking session is illustrated in Figure 2 and is described below with references in parentheses to relevant components of Figure 1.

Before commencing a parking transaction, the user may optionally locate parking bays using the search facilities provided by the service and the mobile application on the user device (132), with the search guided by bay availability information (113) where available.

In step 202 of Figure 2, the user then drives to a parking location, parks, and stops the vehicle. In step 204, the in-vehicle tracking device (130) sends a ‘stop’ message (SMS via cellular phone network) with the vehicle’s GPS coordinates to the vehicle tracking service (128).

In step 206, the vehicle tracking service (128) notifies the parking transaction service (126) of the vehicle stop event, providing the vehicle GPS coordinates. The parking transaction service (180) updates its internal record (105) of vehicle location/status.

In step 208, the parking transaction service (126) sends a push notification to the user device (132).

In step 210, the user sees the notification and opens the parking application on the user device (132), which shows a map containing the area in the vicinity of the vehicle location, and the parking sites, spaces or bays nearest the reported vehicle stop location. Alternatively, the user may open the application before receiving the notification (because there can be a delay of several minutes before the vehicle tracking service 128 notifies the parking transaction service 126), which then shows a map identifying the location reported by the phone, and the nearest parking sites, facilities or spaces.

In either case, the user views the map and selects a parking site or zone (or in some embodiments even a particular parking bay or space) at which they have parked by tapping on the parking location on the map.

In step 212, the application shows details of the parking location (such as street name, cost per hour, maximum stay) for confirmation, and a button to start the parking session, and the user taps the button to confirm and start the parking session. The confirmation is sent to the transaction service (126).

In some embodiments, the system may pre-select a given parking site/zone/location in step 210 (e.g. if the vehicle location is within that site, or alternatively the nearest site to the reported location may be selected by the system - optionally if it is within a predetermined distance of the vehicle location). The pre-selected site is then indicated to the user in step 212, and the user can simply accept that selection if correct or select an alternative site if not, so that only a single action is required to initiate a session if the system has preselected the correct site.

In step 214, the transaction service (126) starts a new parking session, storing relevant session information (such as session start time, parking location identification e.g. zone/site or individual bay if known, and vehicle/user identification) in the session information database (103). The transaction service then reports to the relevant parking enforcement authorities (121) that the vehicle has initiated a parking session, to ensure that no penalty charge notice will be issued. The user then leaves the vehicle.

The location selection and user confirmation steps may optionally be omitted as described in more detail below.

The process of completing a parking session is illustrated in Figure 3.

In step 302, some time after parking and initiating the parking session (as per the Figure 2 process) the user returns to the vehicle and drives away.

In step 304, the in-vehicle tracking device (130) sends a ‘start’ message to the vehicle tracking service (128), which may include the vehicle GPS location. The message is sent via SMS, as with the ‘stop’ message described above.

In step 306, the vehicle tracking service (128) notifies the parking transaction service (126) of the vehicle start. The transaction service (126) determines based on the stored session information for the vehicle and the received notification that the vehicle has departed from the parking location, and that the parking session has therefore come to an end (instead of a vehicle start notification this could alternatively be determined directly from vehicle GPS location information, e.g. by comparing a current GPS location to a location stored for a parking session).

After detecting vehicle departure, a parking transaction is processed to complete the parking session in steps 308-310.

In step 308, the parking transaction service (126) determines the parking duration based on previously recorded arrival time (obtained from the session information) and the current departure time (received with the tracking information), and calculates the correct payment for the duration for which the user parked. This calculation is also performed based on the parking rules 112/113 stored in the CMS database 102. For example, the payment amount may be obtained by multiplying the parking duration (possibly in fixed increments, e.g. hours or half-hours) by a charging rate defined for the particular parking site or location at which the vehicle was parked.

In step 310, the parking transaction service initiates a payment transaction to take payment from the user, and updates the session information to record session time and/or duration, payment amount and any other relevant transaction details, and sends a user a message confirming payment (e.g. by SMS or email).

The payment transaction is typically processed via a pre-registered credit card or other payment instrument (e.g. PayPal account), for which the user provides the necessary details in advance of using the parking system. After payment has been taken from the user, payment is made to the relevant authority either immediately, or preferably according to whatever payment schedule has been agreed (e.g., daily, weekly, or monthly settlement of all parking fees) along with a report of all the parking activity corresponding to the payment. A payment transaction may also take the form of an accounting transaction without immediate payment, e.g. to apply a payment (or other parking credit) to a pre- or post-paid parking account.

Auto-Start Variation

If the in-vehicle device can supply location data with sufficient precision and accuracy (or if supplementary information regarding location is available), it is possible to eliminate the step where the user confirms the parking location (Figure 2 step 210).

In general, GPS equipment may not provide sufficiently accurate location information. There is normally a degree of uncertainty meaning that the vehicle’s location can often only be known to be somewhere within an area that is tens of metres wide, which may encompass several different parking locations. Even the best possible quality GPS receivers can typically only offer accuracy within around 3.5m, and only under optimal conditions, which can be large enough to span two parking bays which may be in different zones and have different rules. In practice, in-vehicle trackers tend to use relatively cheap GPS receivers, often with their antenna in less-than-ideal locations, meaning accuracy can be less than 3.5m in practice.

However, it is possible to augment GPS in various ways, such as by using accelerometers to perform dead reckoning, or using other distance tracking systems (e.g. monitoring car wheel rotation). In these cases it can be possible to determine the vehicle’s location with a precision of 1m or less, which is sufficient to narrow the location down to a specific parking bay. Furthermore, future geolocation systems may provide enhanced accuracy.

In this case it is possible to remove even the user confirmation step, providing a fully automated parking payment system (a ‘zero click parking’ system). The user would simply need to park, with the parking location being automatically detected (to a specific zone, or possibly to within a specific parking bay if required) and identified as a parking site. A parking transaction is then automatically initiated as described above, and subsequently automatically concluded when the user drives away, allowing the entire transaction to occur without any user intervention.

The process is essentially identical to the one outlined above, but without the steps in which the user uses the mobile application to confirm a parking location and start a session. The parking session would start automatically once the vehicle location notification was received from the vehicle tracking service. A notification may nevertheless be sent to the user so that the user is aware that a transaction has been started, and can take abortive action if necessary (e.g. if the transaction was started in error). A fully automated parking session is illustrated in Figure 4. In this approach, the transaction processor receives vehicle tracking information in step 402 and detects in step 404 that the vehicle has stopped at a parking location. This is determined by comparison of the vehicle location to geographical parking site/bay information in the database (106, 108). The specific parking location (e.g. a particular bay) is identified. In step 406 a parking session is initiated by storing session information and notifying the relevant parking authority. This is done automatically without user intervention. At a later time, in step 408, departure of the vehicle from its parking location is detected based on subsequently received vehicle tracking information, as described previously. The system then carries out a parking transaction to end the parking session as already described in step 410, e.g. by updating the session information and initiating a payment transaction.

Mobile application interface example

Figures 5-8 provide illustrative screenshots of the mobile application running at the user device during a parking transaction.

Figure 5 shows a search screen, in which available parking facilities (such as car parks, roadside parking sites etc.) in the vicinity of the user’s location are shown on a map. Cost and bay availability information is also shown for a selected site.

Figure 6 shows a parking confirmation screen. This is displayed when the user opens the application after arriving at a parking site (e.g. in response to a notification or proactively by the user) and identifies the parking site or facility (as identified from the vehicle location or user selection). As mentioned previously a parking facility may, for example, be a large car park or a small group of roadside bays. Furthermore, there may be multiple such facilities in close proximity (e.g. different groups of bays with different charging rules/authorities). Thus, if the location information does not sufficiently identify the exact parking site, then the user has the option at this stage to confirm their exact location, e.g. by tapping on the specific location on the displayed map. The user then selects the “start” button to start the parking session. If the location and other displayed details are correct the user simply selects “start” without making changes.

Figure 7 illustrates a confirmation screen after the user has started the session, confirming location, pricing etc. The parking session can then be ended simply by driving away as previously described. After the user has driven away, a confirmation email is sent indicating the final price charged and other relevant details, as shown in Figure 8.

Road-side sensors

The system may also make use of road-side sensors where available. Such sensors may be installed adjacent to individual parking bays/spaces.

The road-side sensors communicate with a device in the vehicle by a wireless connection such as Bluetooth, RFID (radio-frequency identification) or NFC (Near-Field Communication). The receiver in the vehicle may be integrated into the vehicle tracking device or may be a separate device (e.g. an RFID tag). Alternatively, the receiver may be provided by the user device (e.g. smartphone, satellite navigation device), and may make use of Bluetooth, NFC or other wireless communication functionality typically already present in such devices.

On arrival of the vehicle at a sensor-equipped parking site, the vehicle receiver establishes communication with the roadside sensor. A notification may then be sent to the parking transaction service, either by the roadside sensor, or by the device in the vehicle. The roadside sensor preferably provides identifying information from which the parking site (and possible the particular bay) can be uniquely determined.

Departure of the vehicle may be detected in a similar manner. For example, the roadside sensor may periodically poll the device in the vehicle (or vice versa); if no connection is established (or a connection cannot be established for a predetermined time duration or for a predetermined number of polling attempts), this is taken as an indication that the vehicle has departed, and a departure notification is sent to the parking transaction service. Again, this notification could be sent by the roadside sensor, if the sensor is network-connected. Alternatively, notifications can be sent by the device in the vehicle. In that case, the roadside sensors may simply transmit sensor/location and/or bay identification information to the device in the vehicle, which then communicates with the transaction service as described previously. The transaction service identifies the parking location (e.g. including the specific bay) from the received identifying information.

Thus roadside sensor information may be used as the vehicle tracking information instead of geolocation-type tracking information (e.g. GPS). Alternatively, the system may use both types of tracking information, for example, by using roadside sensor information when available to identify a parking location to greater accuracy, e.g. to identify a specific bay, and using geolocation information when sensor information is not available. Thus, in one embodiment the system may perform the “zero-click” parking method described above to automatically initiate a parking session if roadside sensor information is available to confirm the exact parking location, and may perform the previously described method of seeking user confirmation of the parking location where only GPS location information is received. In a further variation the system may combine both sources of information to provide a more accurate and reliable location determination.

Server and user device hardware

Figure 9 illustrates a transaction processing server 150 and user device 130.

The server 150 preferably comprises conventional server hardware including persistent storage media 502 (e.g. hard disk storage) and volatile/random access memory 506, both for storing computer-executable software code and data, one or more processors 504 for executing software and a network interface 508 for communication with external networks such as the Internet and mobile telephony networks.

The processor runs software modules for interfacing with the vehicle tracking system 128, CMS/DB backend 102/104 and user devices 132 (Figure 1), and processing parking transactions in the manner already described.

The user device 130 is in the form of a computing and/or communications device such as a smartphone. It includes persistent storage media 512 (e.g. FLASH memory), and volatile/random access memory 516, both for storing computer-executable software code and data, one or more processor(s) 514 for executing software, including the parking client application described above, and a network interface 510 for communication with the parking transaction server 150 via external networks such as the Internet, mobile telephony networks and the like. Display and user interface elements 518 (e.g. including a touchscreen, buttons and the like) are provided for user interaction. A location sensor 520 (e.g. GPS sensor) provides location information of the device.

As previously mentioned, while depicted here as a single server, the functions of the parking transaction service may be carried out by multiple servers (e.g. using a distributed cloud platform).

Figure 9 is intended to provide a simplified depiction of the server and user device architectures for illustrative purposes, and the server and user device typically include additional components that are not shown, as known to the person skilled in the art.

It will be understood that the present invention has been described above purely by way of example, and modification of detail can be made within the scope of the invention.

Claims (44)

1. A method of processing a vehicle parking transaction relating to a vehicle parked at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving tracking information relating to a location of the vehicle; accessing stored parking session information associated with the vehicle, the parking session information indicating that a parking session is in progress; determining based on the tracking information that the vehicle has departed the parking location; and in response to the determination, processing a parking transaction to terminate the parking session.

2. A method according to claim 1, wherein the processing step comprises updating the stored session information to indicate completion of the session.

3. A method according to claim 1 or 2, wherein the processing step comprises determining a parking duration of the session, preferably based on one or both of: a session start time recorded in the parking session information, and a departure time associated with the received tracking information.

4. A method according to any of the preceding claims, wherein the processing step comprises initiating a payment transaction to take payment for the parking session, preferably in dependence on the determined parking duration.

5. A method according to claim 4, wherein the processing step comprises accessing transaction rule information associated with the parking location in a database, calculating a payment amount based on the transaction rule information and optionally the determined parking duration, and initiating the payment transaction based on the payment amount.

6. A method according to any of the preceding claims, wherein the processing step comprises transmitting session information to an operator associated with the parking location.

7. A method according to any of the preceding claims, wherein the determining and processing steps are performed in response to receiving the tracking information indicating departure of the vehicle from the parking location, preferably without user interaction.

8. A method according to any of the preceding claims, comprising, prior to the receiving, accessing, determining and processing steps, initiating the parking session based on further received tracking information.

9. A method according to claim 8, comprising identifying a parking location based on the received tracking information.

10. A method according to claim 9, comprising detecting, based on the further tracking information, that the vehicle is in the vicinity of a parking location, and in response transmitting parking location information to a user device of a vehicle user.

11. A method according to claim 10, wherein the parking location information comprises information identifying one or more parking locations, preferably comprising a map, the method optionally further comprising receiving a user selection of one of the identified parking locations.

12. A method according to claim 9, comprising identifying the parking location automatically based on the tracking information without user interaction.

13. A method according to any of claims 9 to 12, wherein the tracking information comprises primary location information having a first level of accuracy and supplementary tracking information, the method comprising determining the vehicle location to a second, greater level of accuracy, based on the primary location information and the supplementary tracking information.

14. A method according claim 13, wherein the supplementary tracking information comprises one or more of: movement distance information and information from an accelerometer associated with the vehicle.

15. A method of processing a vehicle parking transaction relating to a vehicle parked at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving tracking information indicating a location of the vehicle; transmitting information to a user device associated with a user of the vehicle, the transmitted information specifying one or more parking locations in a vicinity of the vehicle, the parking locations determined based on the location of the vehicle; receiving a selection of one of the parking locations from the user device; and initiating a parking session at the parking transaction system based on the selected parking location.

16. A method according to claim 15, comprising transmitting the information to a parking system client application at a user device associated with the vehicle, and receiving the selection from the parking system client application.

17. A method according to claim 16, wherein the information comprises a map indicating the one or more parking locations, the selection being received based on user interaction with the map.

18. A method of processing a vehicle parking transaction relating to a vehicle parked at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving tracking information indicating a location of the vehicle; determining based on the tracking information that the vehicle is located at a parking location based on a database of parking locations; in response to the determination, initiating a parking session at the parking transaction system.

19. A method according to claim 18, further comprising identifying the parking location of the vehicle based on the database and the tracking information

20. A method according to claim 19, wherein identifying the parking location comprises transmitting parking location information to a user device and receiving a selection, preferably as set out in any of claims 15 to 17.

21. A method according to claim 19, wherein identifying the parking location comprises selecting a parking location from parking locations specified in the database based on the tracking information, preferably without user interaction.

22. A method according to any of claims 15 to 21, further comprising subsequently completing the parking session based on receipt of further vehicle tracking information indicating departure of the vehicle from the parking location, preferably using a method as set out in any of claims 1 to 7.

23. A method according to any of claims 8 to 22, the determining step further comprising determining based on the vehicle tracking information that the vehicle has come to a stop at the parking location and initiating the parking session responsive to the determination.

24. A method according to any of claims 8 to 23, wherein initiating a parking session comprises storing parking session information, the parking session information preferably comprising at least one of: information identifying the parking location; a session start time; and user and/or vehicle identification information.

25. A method according to any of the preceding claims, comprising initiating the parking session without user intervention in response to detecting arrival at a parking location based on the tracking information.

26. A method of processing a parking transaction for a vehicle parking at a parking location, the method performed at a computer-implemented parking transaction system and comprising: receiving, from a vehicle tracking device at the vehicle, vehicle tracking information indicating a location of the vehicle; determining a parking location based at least in part on the tracking information; storing session information for a parking session, comprising information specifying a session start time and the parking location; subsequently receiving further vehicle tracking information indicative of a departure of the vehicle from the identified parking location, and, in response to the further tracking information: determining a session end time; and processing a parking transaction in dependence on the parking location and the session start and end times.

27. A method according to claim 26, comprising starting and/or ending the parking session in response to received tracking information without user intervention.

28. A method according to claim 26 or 27 comprising performing the further steps of a method as set out in any of claims 1 to 25.

29. A method according to any of the preceding claims, comprising transmitting parking session information for a completed parking session to a user device associated with a user of the vehicle.

30. A method according to any of the preceding claims, wherein the tracking information comprises one or more of: a vehicle location; a location of a user device associated with a user of the vehicle; a vehicle start indication; a vehicle stop indication; and time information.

31. A method according to any of the preceding claims, wherein the tracking information is based on tracking information transmitted by one or more of: a vehicle tracking device at the vehicle; a personal computing and/or communications device associated with a user of the vehicle; and a sensor installed at the parking location.

32. A method according to clam 31, comprising receiving the tracking information from a vehicle tracking server, the vehicle tracking server transmitting the information responsive to vehicle tracking information received at the server from a vehicle tracking device installed at the vehicle.

33. A transaction processing system comprising means for performing a method as set out in any of the preceding claims.

34. A computer-readable medium comprising software code adapted, when executed on a data processing apparatus, to perform a method as set out in any of claims 1 to 32.

35. A transaction processing system comprising: a vehicle tracking device installed at a vehicle and configured to transmit vehicle tracking information including location information of the vehicle; a transaction processing module adapted to receive the vehicle tracking information, the transaction processing module comprising: a database for storing parking session information associated with the vehicle, the parking session information indicating an ongoing parking session and comprising a parking location of the vehicle; means for detecting based on the received vehicle tracking information a departure of the vehicle from the parking location; means for, in response to detecting the departure, determining a duration of the parking session; and means for, in response to detecting the departure, processing a parking transaction to complete the parking session in dependence on the parking location and the determined duration.

36. A system according to claim 35, wherein the processing means is configured to initiate a payment transaction.

37. A system according to claim 35 or 36, comprising means for performing a method as set out in any of claims 1 to 32.

38. A computer readable medium comprising software code for implementing a parking transaction client application for execution on a user device, the software code adapted to perform the steps of: receiving information from a parking transaction system indicating one or more parking locations in a vicinity of a determined location of the user device or of a vehicle associated with a device user; displaying the information on a display of the user device; receiving a selection of one of the parking locations from a user; and transmitting the selection to the parking transaction system to initiate a parking session at the parking transaction system.

39. A computer readable medium according to claim 38, the software code further adapted to: receive a notification from a parking transaction system, and display the information responsive to the notification; or access and display the information responsive to activation of the application by a user.

40. A computer-readable medium according to claim 38 or 39, the software code further arranged to transmit location information of the user device to the parking transaction system, wherein the information is received in response to transmission of the location information.

41. A computer-readable medium according to claim 40, comprising obtaining the location information from a location service and/or geolocation sensor at the user device.

42. A computer-readable medium according to any of claims 38 to 41, the software code further adapted to participate in a parking transaction conducted according to a method as set out in any of claims 1 to 32.

43. A transaction processing system substantially as described herein with reference to and/or as illustrated in the accompanying drawings.

44. A method of processing a parking transaction substantially as described herein with reference to and/or as illustrated in the accompanying drawings.