GB2567618A - Parking system - Google Patents
Parking system Download PDFInfo
- Publication number
- GB2567618A GB2567618A GB1715175.4A GB201715175A GB2567618A GB 2567618 A GB2567618 A GB 2567618A GB 201715175 A GB201715175 A GB 201715175A GB 2567618 A GB2567618 A GB 2567618A
- Authority
- GB
- United Kingdom
- Prior art keywords
- parking
- parking location
- user
- vehicle
- sensor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
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
Abstract
A method of recording a parking session for a vehicle parking transaction for a vehicle parked at a parking location comprises: detecting, by a parking location sensor of the parking location, that the parking location is occupied by a vehicle; receiving at the parking location sensor an identifier associated with a user or vehicle profile of a parking transaction system; transmitting the identifier associated with the user or vehicle profile and an identifier associated with the parking location to a parking transaction system at a start time; and initiating a parking session for the user or vehicle profile and the parking location. The parking sensor detects that the location is no longer occupied, detects an end time, and terminates the parking session. A parking duration can be determined from the start and end times and a payment transaction made to take payment from a user or user profile based on the parking rules of the parking location or the parking duration. The parking sensor may contain an RF receiver or BLUETOOTH (RTM) beacon to detect an RFID tag or BLUETOOTH device associated with a user or vehicle profile and a magnetic sensor or a light sensor to detect the vehicle.
Description
The following terms are registered trade marks and should be read as such wherever they occur in this document:
BLUETOOTH, as found in pages 2, 9, 14 and 15
Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo
Parking system
Technical field
Embodiments of the present invention generally relate to vehicle parking transaction systems and in particular to automated vehicle parking transaction systems.
Background
Known parking systems traditionally involve parking meters or pay-and-display car parks, where a user is required to put money into the parking meter or to retrieve a ticket from the pay-anddisplay machine and display the ticket in the parked vehicle. Frequently, users must estimate the amount of time that the vehicle will be parked for. If underestimated the user has to return to top up the payment or may be fined. If overestimated, the user risks overpaying for their stay.
Other known parking facilities provide for paying for parking by phone, by phoning a number and paying using an automated phone system to make a card payment. Such systems do not resolve the above problems.
Furthermore, for the systems mentioned above, the systems require a number of steps of user interaction (e.g. retrieving a ticket, making a cash payment, displaying a ticket, topping up a ticket payment, typing in a phone number, entering card details) that make the system inconvenient for the user.
The present invention seeks to overcome these problems. Additionally, the present invention seeks to provide an improved parking transaction system.
Summary
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The invention provides a method according to CLAIM 1. Advantageously, a user associated with the user or vehicle profile only needs to connect to the parking location sensor to record the parking session. As the user has a user or vehicle profile associated with the parking transaction system, and the parking location sensor automatically detects that the parking location is occupied by a vehicle, the parking session can be initiated with minimal effort by the user (i.e.
UK-604931421.1 by only connecting to the parking location sensor in a one-step process). The user or vehicle profile may contain payment details of the user so that the whole process of initiating recordal of a parking session (including possible later payments) is reduced to a singular step interaction for the user.
It may be that the method comprises the steps of CLAIM 2. This allows the parking session to be terminated automatically without user interaction.
It may be that the method comprises the steps of CLAIM 3. The parking session can be accurately recorded and combined with parking rules associated with the parking location to calculate accurately the cost of the parking session.
It may be that the parking session is initiated without user interaction, for example by each step of the method being performed automatically. Thus a user can initiate a parking session by simply parking a vehicle in the parking location, and the parking session is automatically initiated.
It may be that the parking location sensor detects that the parking location is occupied by a vehicle upon connecting to an RFID tag having a unique identifier associated with the user or vehicle profile. Thus the steps of detecting that the parking location is occupied by a vehicle and receiving the identifier associated with the user or vehicle profile can be performed in a singular step.
The parking location sensor may comprise a Bluetooth beacon and detect that the parking location is occupied by a vehicle upon connecting to a Bluetooth device having a unique identifier associated with the user or vehicle profile, the Bluetooth beacon and Bluetooth device preferably being a BLE beacon and BLE device.
The user may manually initiate the RFID tag or Bluetooth device connecting to the parking location sensor, which allows the user a singular step interaction before the parking session is initiated. The RFID tag or Bluetooth device may automatically initiate connection to the parking location sensor so that the user does not need to initiate connection to the parking location sensor manually.
The parking location sensor may comprise a light sensor located at the parking location, and the parking location sensor may detect that the parking location is occupied by a vehicle responsive to detecting a change in an output of the light sensor. The parking location sensor may comprise a magnetic field sensor located at the parking location, and the parking location sensor may detect that the parking location is occupied by a vehicle responsive to detecting a change in an output of the magnetic sensor. The sensors provide an automated system for accurately determining the start time and the occupation of a parking location.
The parking location sensor may comprise a magnetic field sensor and an light sensor located at the parking location, and the parking location sensor may detect that the parking location is occupied by a vehicle responsive to detecting a change in both an output of the magnetic sensor and an output of the light sensor. The combination of sensors more accurately determined when a parking location is occupied by a vehicle.
It may be that upon detecting that the parking location is occupied, the parking location sensor automatically initiates searching for the identifier. This saves energy consumption of the parking location sensor (by avoiding searching for an identifier when the parking location is not occupied) and further decreases the probability that an identifier is received at an incorrect sensor (e.g. a neighbouring sensor).
According to a second aspect, there is provided a transaction processing system according to CLAIM 13.
According to a third aspect, there is provided a computer program product according to CLAIM 14.
Brief description of the drawings
Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.
Figure lisa schematic showing components of a parking transaction processing system;
Figure 2 is a flowchart showing a process for initiating a parking session; and
Figure 3 is a flowchart showing a process for terminating a parking session;
Detailed description
Those skilled in the art will recognise and appreciate that the specifics of the examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.
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.
More specifically, 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:
• Parking session information, comprising information relating to ongoing and completed parking sessions; parking location information which indicates geographical locations of parking zones or sites, including unique identifiers for each parking location. 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 for each parking zone or site, 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.
• A searchable parking rules representation which provides a processed, searchable representation of the parking rules.
• Cached availability information 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.
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.) Automated data import services 114 are provided for bringing this and other 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).
While the parking database 102 contains descriptions of the rules 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 available to the system.
The system therefore provides a rules engine 118 that processes the rules stored in the parking database 102, and converts it into a searchable 'timeline' representation 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 E4.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 non-holiday 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.
The searchable representation produced by the parking rules engine is made available through a web API 124 that can be accessed by an application running on a user mobile 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 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 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. 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.
Where possible, the system provides information about how many parking bays are available at each on-street parking site.
Such information may be provided in real-time by the parking location sensors 134n, described in more detail with respect to Figure 4. The present system includes an import service 120 that regularly fetches real-time availability information from relevant external sources 122, such as parking authorities' systems, and/or the parking location sensors, and places this in a cache (e.g. in the database 102) available to the parking transaction service and other back-end systems.
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.
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 114 to fetch availability data from sources 116 and load that information into the cache (this job also being hosted by a cloud computing provider).
The user mobile 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, e.g. to indicate availability of specific parking bays or number of available bays at particular sites/zones.
The application optionally provides an interface allowing the user to confirm their intention to start a parking session after a parking session has been initiated as described herein.
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 detected location of the vehicle.
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 or notification.
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 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.
The process of starting a parking session 200 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 mobile device (132), with the search guided by bay availability information (113) where available.
In step 202 of Figure 2, the user then arrives at a parking location (i.e. parks the vehicle in the parking location), the parking location having a parking location sensor (e.g. parking location sensor 134n) associated with it.
In step 204, the parking location sensor detects that the parking location is occupied. In some embodiments, the parking location sensor comprises a light sensor or a magnetic field sensor, for example located on the ground within the parking location, so that the parking location sensor detects that the parking location is occupied when the output of the light sensor or magnetic field sensor changes. The output may be representative of the light intensity, light frequency or magnetic field intensity, for example, whose values will change when a vehicle is placed near (i.e. above or beside) the sensor. In further embodiments, the parking location sensor comprises both a light sensor and a magnetic field sensor, and the parking location sensor detects that the parking location is occupied when the output of both the light sensor and magnetic field sensor changes. This reduces the chance that the parking location sensor incorrectly detects that the parking location is occupied. In some embodiments the system database 102 is updated to provide updated information information about the occupancy of the parking location.
In step 206, the parking location sensor receives an identifier (e.g a signal from a user tag device 136), the identifier being a unique ID associated with the user tag device. The identifier is also associated with a user or vehicle profile of the parking transaction system 126, such that the parking transaction system 126 is able to uniquely identify the user or vehicle profile. In the present embodiment the identifier associated with the user or vehicle profile is stored in the database 102. In some embodiments, the parking location comprises an RF receiver and the user tag device is an RFID tag. In those embodiments, the RFID tag connects to the RF receiver and transmits the identifier to the RF receiver. In other embodiments, the parking location sensor 134 comprises a Bluetooth beacon (preferably a BLE beacon) and the user tag device 136 is a Bluetooth device (preferably a BLE device), the Bluetooth device connecting to the Bluetooth beacon and transmitting the identifier to the beacon. The parking location sensor (comprising e.g. the RF receiver or Bluetooth beacon) may constantly search for a device to receive an identifier from, or the search for an identifier may only be activated by detecting that the parking location is occupied by a vehicle. The latter embodiment reduces the probability that the user tag device 136 connects to the wrong parking location detector. In some embodiments the user tag device is a simple device comprising a button for activating connection to the parking location sensor and transmitting the identifier. In other embodiments the user tag device 136 is a Bluetooth device such as a smartphone or any other Bluetooth device (e.g. a Bluetooth enabled vehicle), and in some embodiments is user mobile device 132. In some embodiments the user tag device is also constantly searching for a parking location sensor so that the process of connecting to the parking location sensor and transmitting the identifier is fully automated without any user interaction.
It will be appreciated that in some embodiments the steps 204 and 206 are combined so that the parking location sensor determines that the parking location is occupied once the parking location sensor has connected to the user tag device and received the user identifier.
In step 208, the parking location sensor transmits the user or vehicle profile identifier and an identifier associated with the parking location to the parking transaction system 126. In the present embodiment the identified associated with the parking location is stored in the database 102.
In step 210, a parking session for the user or vehicle profile and the parking location is initiated. 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 a session information database within the database 102. In some embodiments the user may set a preference on the user or vehicle profile of the transaction service 132 that a push notification is sent to mobile device 132, giving the user an opportunity to confirm or cancel the parking session. The transaction service then reports to the relevant parking enforcement authorities that the vehicle has initiated a parking session, to ensure that no penalty charge notice will be issued. In some embodiments the parking transaction system performs a pre-authorisation step with payment details associated with the user or vehicle profile in order to confirm that the parking session will be validly paid upon termination of the parking session. If the pre-authorisation step is successful, the parking session is initiated. If the pre-authorisation step is unsuccessful then the user is informed (e.g. via SMS, email or notification) and the parking session is not initiated.
The identifier of the tag device 136 can be associated with a parking permit, and this information can be retrieved from the relevant authority (i.e. from external sources 116) or may be saved in the database 102. Thus, upon receiving the identifier of the tag device and the identifier of the parking location, the parking transaction service is able to identify whether the owner of the tag device has a parking permit for the parking location. The tag device 136 is thus able to act as a virtual permit.
The process of completing a parking session 300 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 parking location detector detects that the parking location is no longer occupied. In embodiments where the parking location detector comprises a light sensor and/or a magnetic field sensor, it is determined that the parking location is no longer occupied when the output(s) of the sensor(s) return back to the original state (i.e. the output that is normally expected when the space is unoccupied). The parking location detector may be calibrated periodically to ensure that it correctly detects that the parking location is unoccupied based on the sensor outputs. In embodiments where the parking location sensor uses the connection to the user tag device 136 to determine that the parking location is occupied, it may be determined that the parking location is no longer occupied when the connection to the user tag device is lost.
In step 306, the parking session is terminated. The parking session end time is recorded in the session information database.
Finally in step 306, a payment transaction is initiated to ensure that the user pays for the parking session. 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 in step 306), and calculates the correct payment for the duration for which the user parked. This calculation is also performed based on the parking rules 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. The parking transaction service 126 also determines if the parking rules change over the length of the parking session, and takes payment accordingly. For example, the parking transaction service may determine if any part of the parking session occurred during hours that do not incur any cost, such that the payment transaction takes into account the parking rules over the whole parking session. 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 or notification).
The payment transaction is typically processed via a pre-registered credit card or other payment instrument (e.g. PayPal account) associated with the user or vehicle profile, 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.
In the embodiments described above, the user is merely required to register an identifier and payment details with a user or vehicle profile of the payment transaction system. Once the vehicle is parked in a parking location having a parking location sensor, the user then connects the user tag device to the sensor to transmit the identifier (this is a simple one-click process or even automated). The parking session is automatically terminated when the user drives away. Thus, the user has a minimal one-click or no-click interaction with the parking system and benefits from an accurate automated payment system.
It will be appreciated that the teachings of one embodiment described with reference to one Figure could be combined with the teachings of other embodiments.
The transaction processing server can also include a main memory, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by a processor. Such a main memory also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The transaction processing server may likewise include a read only memory (ROM) or other static storage device for storing static information and instructions for a processor.
The transaction processing server may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RW), or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.
In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the transaction processing server. Such components may include, for example, a removable storage unit and an interface , such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.
The transaction processing server and sensors can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium.
In this document, the terms ‘computer program product’, ‘computer-readable medium’ and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the computer system to cause the processor to perform specified operations. Such instructions, generally referred to as ‘computer program code’ (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system to perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.
In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code), when executed by the processor in the computer system, causes a processor to perform the functions of the invention as described herein.
Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as FPGA devices. Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units.
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps.
Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.
Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to ‘a’, ‘an’, ‘first’, ‘second’, etc. do not preclude a plurality.
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ or “including” does not exclude the presence of other elements.
Claims (14)
1. A method of recording a parking session for a vehicle parking transaction for a vehicle parked at a parking location, the method comprising:
detecting, at a parking location sensor of the parking location, that the parking location is occupied by a vehicle;
receiving at the parking location sensor an identifier associated with a user or vehicle profile of a parking transaction system;
transmitting the identifier associated with the user or vehicle profile, and an identifier associated with the parking location to a parking transaction system at a start time; and initiating a parking session for the user or vehicle profile and the parking location.
2. A method according to claim 1, further comprising the steps of:
detecting, at the parking location sensor, that the parking location is no longer occupied by a vehicle and an end time; and terminating the parking session.
3. A method according to claim 2, further comprising the steps of:
determining a parking duration of the parking session based on at least one of the start time and the end time; and initiating a payment transaction to take payment from the user or vehicle profile for the parking session, based on at least one of: a set of parking rules associated with the parking location, and the parking duration.
4. A method according to any preceding claim, wherein the parking session is initiated without user interaction.
5. A method according to any preceding claim, wherein the parking location sensor comprises an RF receiver and detects that the parking location is occupied by a vehicle upon connecting to an RFID tag having a unique identifier associated with the user or vehicle profile.
6 A method according to any of claims 1 to 4, wherein the parking location sensor comprises a Bluetooth beacon and detects that the parking location is occupied by a vehicle upon connecting to a Bluetooth device having a unique identifier associated with the user or vehicle profile, the Bluetooth beacon and Bluetooth device preferably being a BLE beacon and BLE device.
7. A method according to claim 5 or 6, wherein the RFID tag or Bluetooth device, respectively, automatically initiates connection to the parking location sensor.
8. A method according to claim 5 or 6, wherein the user manually initiates the RFID tag or Bluetooth device, respectively, connecting to the parking location sensor.
9. A method according to any preceding claim, wherein the parking location sensor comprises a light sensor located at the parking location, and the parking location sensor detects that the parking location is occupied by a vehicle responsive to detecting a change in an output of the light sensor.
10. A method according to any of claims 1 to 8, wherein the parking location sensor comprises a magnetic field sensor located at the parking location, and the parking location sensor detects that the parking location is occupied by a vehicle responsive to detecting a change in an output of the magnetic sensor.
11. A method according to any of claims 1 to 8, wherein the parking location sensor comprises magnetic field sensor and an light sensor located at the parking location, and the parking location sensor detects that the parking location is occupied by a vehicle responsive to detecting a change in both an output of the magnetic sensor and an output of the light sensor.
12. A method according to any of claims 9 to 11, wherein upon detecting that the parking location is occupied, the parking location sensor automatically initiates searching for the identifier.
13. A transaction processing system configured to perform the method according to any preceding claim.
14. A computer program product configured to perform the method according to any of claims 1 to 12.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1715175.4A GB2567618A (en) | 2017-09-20 | 2017-09-20 | Parking system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1715175.4A GB2567618A (en) | 2017-09-20 | 2017-09-20 | Parking system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB201715175D0 GB201715175D0 (en) | 2017-11-01 |
| GB2567618A true GB2567618A (en) | 2019-04-24 |
Family
ID=60159622
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB1715175.4A Withdrawn GB2567618A (en) | 2017-09-20 | 2017-09-20 | Parking system |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2567618A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021211144A1 (en) * | 2020-04-14 | 2021-10-21 | Saudi Arabian Oil Company | Parking control system, parking control method, and mobile robot device |
| US20220101468A1 (en) * | 2020-09-09 | 2022-03-31 | Auto Park Hawaii, Inc. | Method for automatically managing on-street parking |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020109611A1 (en) * | 2001-02-07 | 2002-08-15 | Howard Charles K. | Parking management systems |
| US20060136131A1 (en) * | 2004-12-06 | 2006-06-22 | Metertek, Llc | Vehicle detector and vehicle parking management system |
| EP2105904A1 (en) * | 2008-03-26 | 2009-09-30 | Software System Solutions FC-LLC | Automated parking guidance and mangement system |
| US20120188101A1 (en) * | 2009-08-31 | 2012-07-26 | Park Ltd | Fully automated parking system |
| US20140225763A1 (en) * | 2011-09-27 | 2014-08-14 | Sensys Networks, Inc. | Position and/or Distance Measurement, Parking and/or Vehicle Detection, Apparatus, Networks, Operations and/or Systems |
| US20140372185A1 (en) * | 2012-01-14 | 2014-12-18 | Zvi Ganot | Methods and systems for automated cellular parking with occupancy control |
| US20150181389A1 (en) * | 2013-12-19 | 2015-06-25 | International Business Machines Corporation | Tracking a mobile unit in a housing facility for mobile units |
| GB2540413A (en) * | 2015-07-16 | 2017-01-18 | Yellow Line Parking Ltd | System for processing parking transactions |
-
2017
- 2017-09-20 GB GB1715175.4A patent/GB2567618A/en not_active Withdrawn
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020109611A1 (en) * | 2001-02-07 | 2002-08-15 | Howard Charles K. | Parking management systems |
| US20060136131A1 (en) * | 2004-12-06 | 2006-06-22 | Metertek, Llc | Vehicle detector and vehicle parking management system |
| EP2105904A1 (en) * | 2008-03-26 | 2009-09-30 | Software System Solutions FC-LLC | Automated parking guidance and mangement system |
| US20120188101A1 (en) * | 2009-08-31 | 2012-07-26 | Park Ltd | Fully automated parking system |
| US20140225763A1 (en) * | 2011-09-27 | 2014-08-14 | Sensys Networks, Inc. | Position and/or Distance Measurement, Parking and/or Vehicle Detection, Apparatus, Networks, Operations and/or Systems |
| US20140372185A1 (en) * | 2012-01-14 | 2014-12-18 | Zvi Ganot | Methods and systems for automated cellular parking with occupancy control |
| US20150181389A1 (en) * | 2013-12-19 | 2015-06-25 | International Business Machines Corporation | Tracking a mobile unit in a housing facility for mobile units |
| GB2540413A (en) * | 2015-07-16 | 2017-01-18 | Yellow Line Parking Ltd | System for processing parking transactions |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021211144A1 (en) * | 2020-04-14 | 2021-10-21 | Saudi Arabian Oil Company | Parking control system, parking control method, and mobile robot device |
| US11335199B2 (en) | 2020-04-14 | 2022-05-17 | Saudi Arabian Oil Company | Parking control system, parking control method, and mobile robot device |
| US20220101468A1 (en) * | 2020-09-09 | 2022-03-31 | Auto Park Hawaii, Inc. | Method for automatically managing on-street parking |
Also Published As
| Publication number | Publication date |
|---|---|
| GB201715175D0 (en) | 2017-11-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10922708B2 (en) | Method and system for avoidance of parking violations | |
| US10657732B2 (en) | Method and system for legal parking | |
| US9997071B2 (en) | Method and system for avoidance of parking violations | |
| US10395535B2 (en) | Method and system for legal parking | |
| CN107735825B (en) | Method and system for legal parking | |
| US9558665B2 (en) | Method and system for avoidance of parking violations | |
| GB2540413A (en) | System for processing parking transactions | |
| US20160140774A1 (en) | Method and system for wireless payment for parking | |
| US11010988B2 (en) | Method, system and product for automatic parking payment and policy detection | |
| US20170046955A1 (en) | Method and System of Locating and Managing Parking Space | |
| US11514463B2 (en) | Instant personal electronic parking system and method | |
| US20160109577A1 (en) | Gps correction method and system | |
| US20130346317A1 (en) | Personal Communications Applications, Devices and Systems | |
| Noulas et al. | Developing and deploying a taxi price comparison mobile app in the wild: Insights and challenges | |
| Hössinger et al. | Development of a real-time model of the occupancy of short-term parking zones | |
| GB2567618A (en) | Parking system | |
| CN110599792A (en) | Intelligent parking method, parking system and parking terminal | |
| US20190340841A1 (en) | Computing system for defining and providing access to a parking area | |
| RU2683909C1 (en) | Method for automatic parking payment | |
| CN110837927B (en) | Method and device for counting refueling data, storage medium and thermodynamic diagram generation method | |
| KR20230152385A (en) | User-centered vehicle payment system and method | |
| CN116631214A (en) | Information processing apparatus, method, and recording medium | |
| CN115311059A (en) | Scientific instrument sharing system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40007480 Country of ref document: HK |
|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |