WO2016127215A1

WO2016127215A1 - Integrated booking system for vehicle parking

Info

Publication number: WO2016127215A1
Application number: PCT/AU2016/050084
Authority: WO
Inventors: Nicholas Gordon AUSTIN; James Gilmour SIMPSON; Peter Joshua Thomas GAMMELL
Original assignee: Divvy Parking Pty Ltd
Priority date: 2015-02-11
Filing date: 2016-02-11
Publication date: 2016-08-18

Abstract

The present invention relates to a computer-implemented system and method for managing vehicle parking bookings. The system and method comprises (a) a database storing: a plurality of membership codes of members of the vehicle parking booking system; an active record of parking spaces at least one secured parking facility; an active record of bookings for the parking spaces, wherein each booking is associated with a membership code; (b) a human interface arranged to provide access to the database, configured to enable a member to search available parking spaces and to make a booking that is stored in the database associated with the member's membership code; (c) a smart controller located at the secured parking facility, comprising: a local memory storing bookings for parking spaces at the secured parking facility, the bookings being associated with a corresponding membership code; a communication interface for wireless data communication with the database to synchronise the bookings in the local memory with the bookings in the database; and a user interface arranged to receive an input membership code, wherein the smart controller is configured to search the local memory for a valid booking matching the input membership code and to enable vehicle access to the secured parking facility if a valid booking is identified.

Description

Integrated Booking System for Vehicle Parking

Field of the invention

The present invention relates to a system for managing vehicle parking bookings and access to parking facilities, and in particular to an integrated web-based vehicle parking booking system.

Background of the invention

Current systems for managing secure access to car parking rely on physical tokens in the possession of an individual. These are presented at a reader device that operates a mechanism to control access, such as a boom-gate, lock or roller door. People who are allowed access to the facility are given physical tokens (such as keys, swipe cards) and must have these tokens available whenever they wish to enter or exit the secure car park.

When the group of people who are allowed to use the facility changes, or if a person loses a physical token, there is a need to exchange, invalidate and replace these physical tokens. These operations also require an update be made manually to the software that controls the access mechanism. This is typically performed by a building manager or similar role. For large facilities, this workload can take up a large proportion of a building manager's working day.

Additionally, the reliance on physical tokens acts as an impediment to using the secured car parking facility for temporary or short term users. The overhead in cost and time to allocate and deliver a new physical token, and update the controlling mechanism, outweighs the benefit delivered to the temporary user of the facility.

Reference to any prior art in the specification is not an acknowledgment or suggestion that this prior art forms part of the common general knowledge in any jurisdiction or that this prior art could reasonably be expected to be understood, regarded as relevant, and/or combined with other pieces of prior art by a skilled person in the art. Summary of the invention

According to one aspect of the invention there is provided a computer-implemented system for managing vehicle parking bookings, comprising: a) a database storing:

• a plurality of membership codes of members of the vehicle parking booking system;

• an active record of parking spaces at at least one secured parking

facility;

• an active record of bookings for the parking spaces, wherein each

booking is associated with a membership code; b) a human interface arranged to provide access to the database, configured to enable a member to search available parking spaces and to make a booking that is stored in the database associated with the member's membership code; c) a smart controller located at the secured parking facility, comprising:

• a local memory storing bookings for parking spaces at the secured parking facility, the bookings being associated with a corresponding membership code;

• a communication interface for wireless data communication with the database to synchronise the bookings in the local memory with the bookings in the database; and

• a user interface arranged to receive an input membership code, wherein the smart controller is configured to search the local memory for a valid booking matching the input membership code and to enable vehicle access to the secured parking facility if a valid booking is identified.

According to a second aspect of the invention there is provided a computer- implemented method for managing vehicle parking bookings, comprising: a) storing, at a database,: • a plurality of membership codes of members of the vehicle parking booking system;

• an active record of parking spaces at at least one secured parking facility; · an active record of bookings for the parking spaces, wherein each booking is associated with a membership code; b) searching and booking, via a human interface, available parking spaces stored in the database and associated with the member's membership code; c) at a smart controller located at the secured parking facility: · storing, in a local memory, bookings for parking spaces at the secured parking facility, the bookings being associated with a corresponding membership code;

• synchronising the bookings in the local memory with the bookings in the database; and · receiving, at a user interface, an input membership code, wherein the smart controller searches the local memory for a valid booking matching the input membership code and if a valid booking is identified, enabling vehicle access to the secured parking facility.

According to a third aspect of the invention there is provided a computer-implemented system for managing vehicle parking bookings, comprising: a) a database storing:

• an active record of parking spaces at at least one secured parking facility; • an active record of bookings for the parking spaces, wherein each booking is associated with a membership code; b) a human interface arranged to provide access to the database, configured to enable a member to search available parking spaces and to make a booking that is stored in the database associated with the member's membership code; c) a smart controller located at the secured parking facility, comprising:

• a local memory storing bookings for parking spaces at the secured parking facility, the bookings being associated with a corresponding membership code; · a communication interface for wireless data communication with the database to synchronise the bookings in the local memory with the bookings in the database; and

• a user interface arranged to receive an input membership code, wherein the smart controller is configured to search the local memory for a valid booking matching the input membership code and to indicate to a member that a valid booking has been identified.

According to a fourth aspect of the invention there is provided a computer-implemented method for searching for resource availability in a database comprising booking information for multiple resources, the method comprising: · generating, for each of the resources, an availability mask defining resource

availability for a specified time period, wherein the time period is subdivided into time increments and the availability mask for the resource comprises a sequence of bits wherein each bit defines the availability of the resource for a respective time increment; · generating a requesting mask for a user to search for resource availability

between a start time and an end time during the time period, wherein the requesting mask comprises a sequence of bits corresponding respectively to the time increments of the time period, wherein each bit of the requesting mask defines whether or not the corresponding time increment lies between the start time and the end time;

• performing a bit-wise logical operation between the requesting mask and the

availability masks of the plurality of resources; · identifying to a user, based on an output of the bit-wise logical operation, whether one or more of the resources is available for booking between the start time and the end time; and

• booking the resource based on a selection by the user.

As used herein, except where the context requires otherwise, the term "comprise" and variations of the term, such as "comprising", "comprises" and "comprised", are not intended to exclude further additives, components, integers or steps.

Further aspects of the present invention and further embodiments of the aspects described in the preceding paragraphs will become apparent from the following description, given by way of example and with reference to the accompanying drawings.

Brief description of the drawings

Figure 1 is a schematic drawing of an integrated web-based car parking booking system.

Figure 1A is a schematic drawing of the web-based car parking booking system of Figure 1 integrated with a third party interface in accordance with an embodiment.

Figure 2 is a flow chart of a method for issuing a membership code for use in the system of Figure 1 .

Figure 2A is a flow chart of a method for searching for available resources using the system of Figure 1 in accordance with an embodiment. Figure 2B is a diagram of an availability mask for use in the method of Figure 2A in accordance with an embodiment; Figure 2C is a diagram of an availability mask, a requesting mask and a product string used in the method of Figure 2A in accordance with an embodiment.

Figure 2D is a schematic drawing illustrating a system for automatically readjusting prices of parking spaces within the system of Figure 1 in accordance with an embodiment.

Figure 3 is a flow chart of a method of making a booking using the system of Figure 1 .

Figure 4A is a schematic diagram illustrating the interactions within the system when a member makes a booking on demand upon arrival at a parking location. Figure 4B is a flow chart of a method for effecting a booking on demand.

Figure 5 is a schematic diagram illustrating a messaging algorithm used by a smart controller in the system of Figure 1 .

Figure 6 is a schematic diagram of a computing device that may be used in the system of Figure 1 . Figure 7 is a schematic illustration of a hand-held computing device.

Detailed description of the embodiments

The system described herein is used to control entry and exit to parking facilities (and the various facilities associated with the property including lockers, 'end-of-trip' facilities', and other secure areas associated with the property) based on the presentation of a unique membership code held by the individual. This membership code is allocated to an individual when joining the service, and is presented at facilities in order to authorize access.

It will be appreciated that the parking facility can be a building, such as a hotel, office shopping centre or cinema, or a car parking facility and that a parking space can be a space associated with any parking facility. It will also be appreciated that the system described herein can be used for booking other services, such as lockers, conference rooms, loading docks, storage units and boating berths. This system works by the coordinated interaction of the components illustrated in Figure 1 .

A membership inventory and bookings ( MIB ) database 124 is used to record the parking locations, inventory, bookings and memberships in the system. A human interface ( HI ) 122 to the MIB database 124 is used by members 120 to search for available parking spaces at specified locations for specified time windows and to make bookings for these spaces.

A Machine Interface ( Ml ) 126 to the MIB database 124 is a software interface that allows a plurality of smart controller (SC) devices 130 to send and receive information for a specific physical location.

A plurality of smart controller ( SC ) devices 130 connects to the MIB database 124 using the Machine Interface 126. The connection may take place using the Internet 1 18. The SC device 130 controls the physical access mechanism 128 (such as a lock, boom gate or roller door) at a car park. The SC 130 also has the intelligence to support On demand' bookings, manage anti-passback and multiple entries into the secured facilities and display messages including usage instructions and promotional information.

When people join the service, they are issued with a unique code that identifies their membership within the service. This code is used to identify the member's account details, history, and preferences. In one arrangement this membership code is a string of numbers that can be encoded in multiple ways, for example as a string of digits, or as a QR code. In both of these formats the value of the unique code identifies the member.

When a member 120 wishes to book a car parking space in advance, they use the human interface 122 (typically implemented as a web site or mobile phone application) to search for available spaces in desired locations, and then make a booking for a nominated date and time. At the specified date and time, the member 120 presents their membership code to the Smart Controller device 130 at the physical location of the car-parking facility. In normal circumstances, the Smart Controller device 130 verifies the membership code and verifies that there is a valid booking. If the booking is in order, the smart controller 130 issues a signal to open the appropriate door or gate 128 permitting entry. In another embodiment, the smart controller indicates, visually and/or aurally, to the member that a valid booking has been made.

The Membership, Inventory and Bookings Database

The MIB database 124 records information about: A. Which car parking spaces, and supporting resources, the system is managing;

B. An inventory of these spaces, their status and supporting resources such as when they are busy (booked for use), how many spaces are available and their dates and times of availability, descriptions and any special conditions or notes attached to the specific car parking spaces and resources;

C. Members of the service, including their unique membership code, name, address and payment details such as credit card, debit card or mobile wallet details;

D. Bookings for car parking spaces by members;

E. The history of member activity; F. The booking history for all managed car parking spaces and any attached resources;

G. Real-time or forecast utilisation rates of a car parking space or spaces within a parking facility;

H. Prices of a space within a parking facility, based on the owner's discretion or utilisation rates; and

I. Smart-Controller devices 130 deployed by the service, including their unique identifiers and the physical address and location details of each device.

The MIB database 124 is implemented using relational database technology. The MIB database 124 also includes computational resources enabling the system to operate on the data stored in the MIB database 124. Smart Controller

Each smart controller device 130 has an identifier that is used to uniquely identify an instance of a Smart Controller device, and to correlate each device instance with a physical address. The SC 130 wirelessly connects to the MIB database 124 via the internet 1 18 in order to communicate with the machine-interface component 126. This communication is performed using HTTP and HTTPS over TCP/IP technologies.

The SC 130 accepts the presentation of a membership code from a person 120 for example in the form of a sequence of alphanumeric characters entered on a keypad or the same information presented as a QR code that is scanned by a camera embedded in the device. As described below with reference to Figure 5, the SC evaluates if the supplied membership code appears in a list of valid bookings for the location that were retrieved from the MIB database and stored within the device memory. If the supplied membership code does have a valid booking record, then a control signal is sent to the mechanism that controls physical access to the site (such as a boom-gate, lock or roller-door) 128. In another embodiment, the smart controller contains a means for a member or a third party to open the physical control access mechanism remotely. In another embodiment, if the supplied membership code is associated with a valid booking record, the SC 130 may indicate, through a display and/or a speaker, to the person 120 that they have a valid booking record.

If the membership code does not have a booking record AND there are free spaces available in the car parking facility, then the Smart Controller 130 asks if the person presenting the code would like to make an on-demand booking. This process is described below with reference to Figures 4A and 4B. The smart controller 130 at a secured parking facility may have an anti-passback capability. Once a membership code has been used to enter the parking facility, the smart controller will not enable a second entry using the membership code unless the code has been used to exit the parking facility.

Human Interface The Human Interface 122 to the MIB database 124 supports human interaction with the service. Its role within the service is to present information and to ask questions in a way that allows a member of the public to search for available car parking spaces (and supporting or attached resources) within a geographic location. This searching operation may be constrained by distance from a known point on a map, a price range, or attributes associated with a specific car parking space such as whether it is undercover and/or secured. In one example, the human interface displays all search results within a walking radius calculated from an address entered by the member. In one example, the walking radius calculation assumes an average constant walking speed of 20 minutes per kilometer. In another example, the member can adjust the walking distance through the human interface.

The HI 122 enables members to make bookings for specific physical locations for a defined window of time, for a recurring time period (e.g. every Monday) or may offer a defined package of goods and services associated with parking (e.g. a movie-ticket and a parking space bundled together as one offering).

In one arrangement the system creates alerts that signal the availability of car parking spaces that can be communicated via SMS and emailed to the member based on user supplied preferences (i.e. location, price range, or specific attributes attached to the space such as whether it is under cover or not). The human interface 122 may be used to create and send messages via specified channels such as SMS and Email to members advising them of promotions and sales for car parking spaces and/or package-deals associated with car parking spaces (e.g. parking + a movie ticket in a location near a cinema).

The Human Interface is implemented as a website for use with browsers, and as a mobile phone application.

Machine Interface

The Machine Interface 126 to the MIB database 124 supports "machine to machine" communication with the service. The Machine Interface 126 contains the logic that is applied to the data that is stored in the MIB database 124, and the Machine Interface 126 applies logic to data that is to be stored in the MIB database 124. It is designed to provide access to multiple types of devices, exposing its services using a Representational State Transfer (REST) programming interface.

Specifically this part of the service allows a Smart Controller 130 to connect and identify itself with its unique identifier. The Machine Interface 126 uses data from the MIB database 124 to correlate the present unique identifier to a specific physical address. The Machine Interface 126 allows a Smart Controller 130 to download a set of booking records that are applicable to the physical address location of the Smart Controller 130. These booking records contain information that associate specific membership codes with specific car parking spaces (or associated resources) with the secured facility.

The Machine Interface 126 accepts information from the Smart Controller 130 about which membership codes have been presented for entry and exit, and at what date/times these were presented.

The Machine Interface 126 may also accept connections from business partners and authorized agents to query available car parking spaces at specified locations of interest for marketing and promotional purposes. The Machine Interface 126 may also accept connections from authorized agents to query utilisation rates of one or more car parking spaces or of one or more parking garages. In addition, the Machine Interface 126 may accept connections from authorized agents to query pricing of one or more car parking spaces, where these prices are calculated from utilisation rates of the one or more car parking spaces.

In another embodiment shown in Figure 1A, the Machine Interface 126 is integrated with one or more third party interfaces 132, for example, a tenant portal or facilities management platform. Integration of the third party interface 132 with the machine interface 126 allows for search results of available car parking spaces to be integrated to services by a third party service provider, such as a theatre or restaurant. In one embodiment, a member 120 can access the third party interface 132 and services provided thereon. For example, if the machine interface 126 is integrated with a third party interface 132 associated with a shopping centre, the member 120 can use their membership code or membership details to validate shopping centre purchases in order to receive discounted parking, attract frequent user points to claim discounted parking, redeem promotional offers or claim other benefits.

In another embodiment, a building operator 134 can access the third party interface 132 to perform or edit a booking for a non-member in order to provide them with an access code for entry into a secured parking facility or confirmation of a car parking space without the non-member submitting a membership request. In another embodiment, the building operator 134 may operate a parent account, which is linked to a number of access identifiers that can be used when making a booking for a non- member. It will be appreciated that the building operator 134 can be an owner, manager or operator of the building or parking facility.

In another embodiment, an alert is generated by the machine interface 126 and communicated to the member 120 or building operator 134 when a membership code or access code is used to enter or exit a parking facility.

The integration of the machine interface 126 with the third party interface 132 allows for a seamless experience for non-members and members of the system described in Figure 1 to access the third party platform and the services provided.

The Machine Interface 126 supports connections via a REST programming interface over HTTP and HTTPS using JSON as the syntax for data exchange. For example, the system may support 3 specific types of REST messages from Smart Controllers 130: a. FullSynchronisation: Used to give an SC device an initial full set of booking records for its specific location that are expected to be presented to the device in the next 24 hours. This message is called by Smart Controller devices 130 when they are first booted up/started. b. PeriodicUpdate: Used to provide the Smart Controller 130 with updates to the list of bookings expected in the next 24 hours (new bookings and cancellations). This message is sent by the Smart Controller 130 every 5 minutes and is also used as a "heartbeat" signal to track whether a given SC is online and active or not, c. OnDemandBooking: Used to make a booking in real-time in response to a member presenting their unique membership code at a SmartController where there is no current booking active.

The Machine Interface 126 supports multiple concurrent connections to occur simultaneously, and supports a network of thousands of Smart Controller devices 130 that each connect into the Machine Interface around every 5 minutes.

The Machine Interface 126 tracks the most recent time each SC 130 managed by the system has sent the "PeriodicUpdate" message and alerts administrators to SC devices that appear to be offline or no longer in communication for more than 10 minutes.

Processing a membership request

Figure 2 shows a flow chart of a method that may be followed in processing a membership request. A potential member accesses a human interface, which could, for example, be the human interface 122 of Figure 1 . The human interface is typically implemented as a website or as an application for mobile phones and other portable computing devices.

In a first step 220, the potential member indicates that he or she wishes to apply for membership of the parking system. In the next process 222, the human interface 122 captures appropriate information about the member. The information may include the name and address of the member, and payment details such as credit card information or bank details. The information typically includes contact information such as telephone numbers or email addresses to enable communication with the member. In some cases, the membership may be linked to an account that includes a plurality of members. Thus, for example, several members of a family may sign up as members and set up a common account for the family. In another example, employees of a company may sign up as individual members, with their payment details being linked to a common fleet account for the employer. In another embodiment, the information provided by a member 122 is used to determine a membership type, such as silver, gold or platinum. In process 224, the registering software generates a membership code for the applying member. In one arrangement the membership code is a six digit alphanumeric sequence of characters. The membership code is saved in the MIB database 124, where it is saved in memory associated with the member information captured in process 222. Each member has an individual membership code. For a family account, each individual family member is issued with an individual membership code, and for a fleet account, each member is issued with a separate membership code.

In process 226, the membership code is made available to the member. The code may be presented to the member in many ways including ASCII format (human readable), in QR code format (machine readable) or an identified extracted from another device such as a credit card or mobile phone. The member may hold the membership code in one or more desired formats. The membership code may be committed to memory, written down on paper, or printed from the human interface. A common feature is that the membership code is available as information rather than being limited to a physical token. In one embodiment, a membership code can be a single use membership code or a multiuse membership code that allows a member to use the same membership code to access various parking locations at different points in time.

The membership code can potentially be displayed on a number of devices. To do so, a user logs in to an account via the human interface 122 using the desired device, for example a mobile phone or tablet. The logged-in user may download a QR code, for example, onto the mobile phone or tablet. In one example, a member of the parking system may be travelling with a colleague, and may find it convenient to access a secured parking location using a device carried by the colleague.

In addition to the version of the membership code that may be displayed on a portable electronic device, the membership registration procedure may include the issue of a vehicle-based indicium such as a printed QR code. This is indicated in process 228 of Figure 2. The vehicle-based QR code may be displayed in the member's vehicle. Thus, for example when the vehicle is parked in a parking garage, security personnel inspecting the parking facility may use a portable reader to register the QR code displayed in the vehicle. In another example, when the vehicle is parked in a parking space, a parking officer may also use a portable device to read the QR code or other identifier (e.g. radio frequency identification chip) displayed in the vehicle to determine, for example, how long the vehicle has parked in a space. The scanner may connect wirelessly to other elements of the system, such as the smart controller 130 or the MIB database 124 to check that the vehicle that is physically present matches with the booking records.

There is an option in some arrangements (step 230) for the membership code to be refreshed or changed. This may prevent or limit the risk of unauthorised use or unauthorised replication of the membership code. There are several ways in which the code may be refreshed. For example, the member applying for membership may be presented during registration with an option for refreshing. If this option is chosen then the membership code is automatically refreshed from time to time. The code may be changed after the expiry of a specified period of time. Alternatively, the membership code may be refreshed after the code has been used for a specified number of times.

Searching for available bookings Figure 2A is a flowchart of a method that may be followed in searching the MIB database for one or more available resources, such as one or more car parking spaces. At step 240, the MIB database stores booking information and availability data associated with a plurality of resources, including the date and timeframe that the resources are available. At step 242, for each of the resources, an availability mask is created to define the availability data for a specified time period (i.e. a day) and is stored in the MIB database. An example of an availability mask 260 is shown in Figures 2B-2C and is made up of a string of 288 bits (equivalent to a 36 byte string). This string represents the availability of the resource for a 24 hour period, where each bit 262 within the string represents a five minute increment of time within this 24 hour period and the first bit of the string starts at midnight. Each bit 262 is assigned a value of 0 or 1 depending on whether the resource is available for the respective time increment. In the example shown in Figure 2B, a bit value of 0 indicates that the resource is not available 264, while a bit value of 1 indicates that the resource is available 266 for the respective time increment. At step 244 in Figure 2A, a member uses the machine interface to search for available resources based on a specified date and timeframe (i.e. between a start time and an end time). The machine interface, at step 246, then generates a requesting mask containing a 288 bit string (equivalent to a 36 byte string). This string represents a 24 hour period in which the member can place a request, where each bit within the string represents a five minute increment of time within this 24 hour period and the first bit of the string starts at midnight. Each bit within this string is also assigned a value of 0 or 1 depending on the timeframe specified by the member. In one embodiment, a bit value of 1 indicates that the member is requesting a booking for that time, while a bit value of 0 indicates that the member is not requesting a booking for that time. In the example shown in Figure 2C, if the member is requesting a resource between 10 am and 1 1 am then a requesting mask 270 will be generated where bits located at positions 120 to 132 (inclusive and corresponding to the timeframe between 10 am and 1 1 am) along the string will have a value of 1 , while all remaining bits will have a value of 0.

At step 248 in Figure 2A, the machine interface requests the availability mask for the date nominated by the member from the MIB database 248 before performing a bitwise logical operation between the requesting mask and the availability mask 250 for each resource. In one embodiment, the bitwise logical operation is a bitwise AND operation. As a result of this operation, one or more 288 bit product strings are produced, as shown by example in Figure 2C and indicated by reference numeral 272. If these product strings yield the same value for the bits encoded in the requesting mask 272 for the member's nominated timeframe 274, then the one or more resources are available. At step 252, the machine interface displays, to the member, the availability of the one or more resources for the member's specified timeframe. The member can then use the machine interface to complete a booking 254 for the one or more resources and once these bookings have been completed, the resource availability is updated in the MIB database 256.

The foregoing states that the machine interface conducts the search, however, it will be understood that the machine interface may be a distributed system. It will be also appreciated that the foregoing can be performed through a human interface.

The method described in Figure 2A allows for rapid searching that uses few computational resources or memory as large quantities of data can be searched within short computational timeframes resulting in improved computational efficiency. In particular, the creation of an availability mask prior to a member performing the search and the use of the bitwise AND operation allows for the searching of available resources with respect to a member's chosen timeframe without the need to reference resource availability data or process start and end times of bookings. Furthermore, the use of an availability mask allows for an increase in computational speed as the machine interface does not have to process all of the potential bookings for all of the potential resources for the date nominated by the member. In one trial performed by the inventors, the method described above processed 1000 records in less than 14 milliseconds on standard PC hardware. In contrast, conventional computational processes for performing searches are thought to incur execution times of 10 seconds or longer, which is considered to exceed the maximum time that a member is willing to wait for a search to be performed. For example, if a search was performed of 1000 potential resources and each of these resources has on average 4 bookings, in order to calculate the availability of these 1000 resources, existing systems would firstly have to retrieve 4000 booking definitions and then conventional systems would need to process each of these bookings to determine whether the associated resource is free for the requested time period.

Search result aggregation

Referring to Figure 1 , a member 120 uses the human interface to search for available resources (e.g. one or more car parking spaces) based on a set of criteria defined by the member. In one example, the member can search for the availability of a car parking space from a chosen address. The human interface communicates to the MIB database to return all available car parking spaces, based on the criteria set by the member, to the human interface. If multiple car parking spaces are returned for a location, the human interface will aggregate the multiple car parking spaces and display a primary search result for this location. In one embodiment, the human interface dynamically detects when multiple resources (e.g. car parking spaces) are located at the same address and instead of displaying these as separate search results, displays them as a single search result with a visual indicator to signal that there are multiple resources at this address. For example, the member may search for all car parking spaces available at 1 Margaret Street, Sydney, which returns 50 results from the MIB database. The human interface will then aggregate these results into a primary search result. This primary search result may also be provided with a summary that outlines details of all the available car parking spaces at the member's chosen location, for example, "50 bays, ranging from small to large, monthly and hourly periods". The member may then use the human interface to refine these search results by various filters, such as the distance radius from the chosen location and size of the vehicle. The human interface will then communicate to the MIB database to return all the available car parking spaces and re- perform the aggregation based on the member's refined search criteria.

This method of aggregating search results allows for faster computational processes and allows for a member to select from an aggregated and streamlined list of search results from a single location.

Automatic repricing based on utilisation Figure 2D is a flowchart of a method in which a system operator initially specifies a pricing rule for a parking facility and as people enter and exit the parking facility, prices of the parking spaces automatically readjust. It will be appreciated that the parking facility can be a building, such as a hotel or office building, or a car parking facility. The system operator specifies three rule types 274 through a webpage and on behalf of a building operator 134:

1 . Rule 1 involves calculating utilisation rates from pricing adjustments 276:

The system operator 134 specifies a price increase or decrease in percentage terms for different levels of utilisation within a building. For example, the system operator specifies that when a building is below 25% utilised a pricing adjustment of -30% is applied, as indicated by reference numeral 277. The effect of this rule will result in prices being reduced by 30% when the building is only 25% full or less. In another example, the system operator can specify that when a building is above 75% utilised a pricing adjustment of +30% is applied, as indicated by reference number 278. The effect of this rule will result in increases per space pricing by 30% once the overall utilisation of the building reaches 75%.

2. Rule 2 involves date and time sensitive pricing adjustments 279: The system operator specifies a time window and pairs this with a resource ID, for example a car parking space ID. This creates a "key" that is associated with pricing adjustments, which are expressed in percentage terms. For example, a positive percentage indicates an increase in price (calculated from a base price), while a negative percentage indicates a reduction in the price (calculated from the base price). The pricing adjustment then stored with each key. For each space within the building, an automatic repricing algorithm 286 determines from current date and time data whether a pricing adjustment is applicable. In one example, if a given date and key is absent then no pricing adjustments will apply.

In another embodiment, the "key" is associated with a time window and a product type combination (e.g. daily parking, hourly parking). It will be appreciated that the time window can be used to define an entire day, multiple days or hours within a day.

3. Rule 3 involves dynamic inventory reallocation 280. The system operator can specify a primary price for any given resource and time period, and this is treated as a normal price and time period for which the resource is rented. For example, a given parking space can be listed as primarily being rented on a daily basis for $50, as indicated by reference numeral 281 . The system operator can then additionally (and optionally) specify a secondary price for the resource using a different time period than was used for the primary price. For example the same parking space can have a secondary pricing rule associated with it that indicates it can be rented on an hourly basis for $20, as indicated by reference numeral 282. This is useful if the system runs out of hourly spaces as the presence of a secondary 'hourly' price for a parking space allows it to be reallocated and sold as an hourly parking space (rather than a primary 'daily' parking space).

These rules specified by the system operator are then stored in the MIB database 283 and used by the automatic pricing algorithm 286. The MIB database also maintains two sub-databases, a Building Entry and Exit (BEE) database 284 and a Building Utilisation (BU) database 285, which are associated with a building and used by the automatic pricing algorithm 286.

The BEE database 284: stores entry and exit data recorded from a Smart Controller 130 located at a building. This data is communicated to the MIB database in real-time to allow the MIB database to maintain a real-time view of traffic into and out of the building;

The BU database 285: stores bookings data containing expected entry and exit times of users to the building.

It will be appreciated that the bookings data from the BU database and the entry and exit data stored in the BEE database may not correlate exactly. In real world situations, some bookings are missed (e.g. a "no-show"), some are extended (e.g. "an overstay"), and some car parking spaces can be sold without a booking in advance (e.g. a "booking-on-demand"). This means that the entry and exit data, and the bookings data from each respective database, when combined, presents a clearer overall picture of real-time building utilisation and building utilisation as it is expected to be in the near future than if the entry and exit data or building data from each respective database were considered alone. The time horizon defining the "near future" may be specific to a building, as different facilities may have differing volatility in their patterns of occupancy. In one example, the "near future" represents a time horizon of 2-3 hours or 2-3 days at a specific building and is used to determine a dynamic utilisation of the building.

In one embodiment, the data from the BEE database 284 and the BU database 285 is used for the calculation of a real-time, dynamic utilisation percentage for the building. The calculated utilization may be a function of:

• entry and exit data obtained from the BEE database;

• bookings data obtained from the BU database;

• historical and location specific parameters derived from historical records, such as the number of "no-shows", "overstays" and "bookings-on-demand" that occurred at a specific location, on specific day and at specific times; • forecast demand, calculated from historical and location specific parameters, expected to occur at a specific location, on a specific day and at a specific time. For example, the bookings data may indicate that the number of "no-shows" to a parking space is higher for a building close to a cinema on the weekend compared to the number of "no-shows" for a building close to a court during business hours.

• the time horizon for use in determining the dynamic utilization for specific buildings.

When changes occur to the BEE database 284 or the BU database 285, the MIB database 283 is triggered to initiate the automatic repricing algorithm 286, as indicated by reference numerals 287. The automatic repricing algorithm 286 uses the data from the BEE database and the BU database to calculate the dynamic building utilisation, as well as the utilisation for each product category (e.g. daily parking, hourly parking) supported by the building, and then for each space in the building, the MIB database: a. looks up a base price for a space identifier;

b. using rule 1 , determines if there is a pricing adjustment in percentage terms that needs to be applied given the calculated utilisation trigger. This pricing adjustment (if any) is stored temporarily for the next step in the algorithm. In an embodiment, the dynamic building utilisation percentage is used in determining the pricing adjustment.

c. using rule 2, determines if the space falls within a currently defined time period that has a pricing adjustment defined for it. This pricing adjustment (if any) is added to the stored pricing adjustment value from step (b) described above;

d. using rule 3, determines if a product category is no longer available in the building due to having reached the maximum utilisation for this category of product (e.g. daily, hourly parking), and if the utilisation for another product category within this building is below the maximum value allowed for the building (e.g. below 95% to 100% utilisation), a search is conducted to determine if any of the resources in these "underutilised" categories has secondary prices for the fully utilised category. If such resources are found, new availability records are created for these resources using the secondary prices as the base price; and

e. applies an accumulated pricing adjustment, calculated from rules 1 -3, to the base price in an availability record for the space.

f. the adjusted price of the space is then stored in a Building Price database

288, which is sub-database of the MIB database.

The automatic pricing algorithm 286 occurs without human intervention and unless a system operator updates Rules 1 -3 described above, then once the accumulated pricing adjustment is applied, all future bookings will have the readjusted price applied to them.

In one embodiment, it is expected that as more members are using the car building, increasing the utilization of the building, a positive price adjustment will apply (e.g. +30%), causing prices of the car parking spaces to increase. In another embodiment, as cars exit the building or fewer bookings are forecasted for the near future, the calculated utilization of the building decreases and a negative price adjustment or discount (e.g. -30%) will apply. As a result, it is expected that these discounted prices will encourage members to use the building at times of low utilization. Making a booking in advance

Figure 3 is a flowchart of a method in which a member 120 makes an advance booking using the system of Figure 1 . In step 302 the member 120 uses the human interface 122 to make a booking for access to a given location for a desired date and time, based on availability. The member 120 may, for example, use a portable device such as that shown in Figure 7 in order to access the human interface 122. Once the member 120 has made a booking, in step 304 the human interface 122 updates the MIB database 124 with the booking and membership code details. In another embodiment, a member 120 used the human interface 122 to modify their booking. The human interface 122 then communicates the updated booking details to the MIB database 124. Every five minutes, in process 306, the smart controller 130 identifies itself (and thereby its address), to the system via the internet 1 18, and downloads booking details of members for resources at the address of the smart controller 130. The smart controller 130 also uploads any exit information from resources at the address (if any).

In step 308, the member 120 arrives at the address of the car park and presents the membership code to the smart controller 130. The member may present the membership code in several ways, for example keying in the code at a keypad of the smart controller 130, or presenting a QR code on a device such as a smartphone or tablet to a scanner at the smart controller 130. Other techniques for presentation may also be used, for example radio frequency identification (RFID), Bluetooth low energy (BLE) and/or near field communication (NFC). In process 310, software running on the smart controller 130 checks whether the presented membership code is on an approved list of bookings for the resources at the smart controller's physical address. If the check is positive, the smart controller 130 sends an "open" signal to the boom gate or door infrastructure 128 that controls access to the parking. The arrangement of Figure 1 shows a configuration in which the parking facility has existing access control such as boom gates or doors. The smart controller 130 may be retrofitted to an existing system. In alternative arrangements, where a new system is being set up for a parking facility, an integrated access control system may be provided that incorporates both the smart controller 130 and a physical boom gate or door, together with the means for operating the boom gate or door. When the member 120 exits the secured parking facility (step 312) the member presents their membership code to the smart controller at the exit. This causes the exit door or gate to open, and the associated smart controller 130 records the exit date and time and the membership code. As at the entrance, the member 120 may present the membership code in several ways including typing in the code at a keypad or presenting a QR code to a scanner associated with the smart controller 130 at the exit.

In one embodiment, if the presented membership code is associated with a booking for the resources at the smart controller's physical address, the smart controller will indicate, visually and/or aurally, to the member that a valid booking has been made. In an optional step 314, the system may notify the member 120 that the member's membership code has been used to enter or exit the secured parking facility or other parking area. For example, the system may send an SMS to a mobile phone number that is stored in the MIB database 124 as part of the membership details associated with the membership code. Various methods may be used to alert the member to use of the member code, for example SMS, email or app pop-up. This optional step provides a level of security against unauthorised use of the membership code. Booking on demand

Instead of making an advance booking, member 120 may wish to make a booking on demand upon arrival at a parking facility. This is illustrated in Figures 4A and 4B. Figure 4A schematically illustrates the interactions between the system components, and Figure 4B is a flowchart describing the interactions. Upon arrival at a parking facility, the member 120 presents a membership code

402 or other accepted identifier (e.g. an electronic wallet, credit card, debit card or RFID chip) to the smart controller 130 located at the entrance to the parking facility. There is a sequence of interactions 404, 406, 408, 410 between the smart controller 130 and the machine interface 126 to the MIB database 124. The machine interface 126 exchanges information 412 with the MIB database 124. If the outcome of the sequence of communications is successful, then the smart controller issues an "open" signal 414 to the boom gate or door 128, thereby permitting entry to the facility. In another embodiment, if the outcome of the sequence of communications is successful, then the smart controller will indicate, visually or aurally, to the member that a valid booking has been made.

This is further described in the flowchart of Figure 4B. In process 430, the member 120 arrives at a secured car parking facility without a booking, and presents a membership code to the smart controller device 130.

Next, in process 432, the smart controller device 130 identifies that there is no booking in its memory for the member 120. The smart controller 130 initiates a call 404 to the machine interface 126 to look for a booking made since the last synchronisation between the machine interface and the smart controller 130.

In process 434, the machine interface 126 returns a message 406 indicating that there is no booking for the member 120, and returning a list of available spaces (if any) at the location associated with the smart controller 130. In process 436, a user interface, for example a display screen, at the smart controller 130 informs the member 120 that there is no booking recorded but it is possible to make an immediate booking if desired. The member responds with a yes/no answer. If the member selects "no", that is the end of the interaction. If the member 120 selects "yes", the smart controller 130 outputs a signal 408 to the machine interface 126 requesting an immediate booking.

The system may check whether the member's payment options are in good standing before authorising an on-demand booking. For instance the system may check whether a valid credit card, debit card or mobile wallet is linked to the member's membership information in the MIB database 124. Alternatively, the system can check whether the member has a credit balance available.

In one arrangement the system makes an on-demand booking for a default booking period. The member may adjust this default period if necessary. For example, the member 120 may log in to their account via the human interface 122 and adjust the booking details. The human interface 122 then communicates the updated booking details to the MIB database 124.

In process 438, once the on-demand booking is made, the details are recorded in the MIB database 124 for billing and historical purposes. The machine interface 126 returns a confirmation message 410 to the smart controller 130 for the booking. The smart controller 130 then sends an open signal 414 to the boom gate or roller door infrastructure to enable access. In another embodiment, then the smart controller will indicate, visually or aurally, to the member that a valid on-demand booking has been made.

When a membership code is used to create an on-demand booking, the member may be alerted of this use, for example via an SMS, email or app pop-up.

Display of booking information

In another embodiment, the smart controller is located at a car parking facility that lacks a physical access mechanism. In one example, the smart controller is located at a parking area designated for an event, such as a sporting event, concert or street parking bay, and is mounted to an access stick or parking meter device. A member arriving at the event parking area will present their membership code to the smart controller that will check whether the presented membership code is on an approved list of bookings and if this check is positive, will display a message indicating that a valid booking has been found. In another embodiment, if no valid booking is identified by the smart controller, the member will be provided with an option to make a booking on demand.

Messaging used by the smart controller

Figure 5 illustrates schematically the messaging algorithms used by the smart controller 130 to identify itself and to retrieve and send information to the machine interface 126, typically via the internet 1 18. In Figure 5, the ellipses 530, 540 and 550 represent software execution threads running on the smart controller 130. The arrows 532, 542, 552 indicate calls to the machine interface 126, typically over the internet 1 18.

The functional structure of the smart controller 130 may be as described with reference to Figure 6 below. The smart controller 130 has local device memory 502. Data stored in the local device memory 502 includes a unique identifier 504 for the smart controller 130.

The memory also includes a list 506 of approved bookings by members. This list is updated periodically by synchronisation between the smart controller 130 and the MIB database 124. The smart controller's memory also includes a list 508 of entry and exit records showing a history of access and departure at the parking facility.

The smart controller may use the entry and exit list 508 to implement an anti- passback feature. Once a membership code has been used to enter the parking facility, the smart controller will not enable a second entry using the membership code unless the membership code has been used to exit the parking facility.

The smart controller 130 may also include a keypad 520 that enables the member to enter information such as a membership code or to make selections where appropriate. The smart controller 130 may also include a QR code scanner 522. A member 120 may present a QR code either in a printed form or on a mobile device such as a smartphone or tablet.

The smart controller 130 also includes a signal output 524 that sends a signal to the boom gate or door, causing the boom gate or door to open and enable access to the parking facility. The smart controller 130 has a device boot thread 530 that runs at start up time and provides a full synchronisation. In the synchronisation thread 530, the smart controller 130 sends a call 532 to the machine interface 126 to present the unique identifier 504 of the smart controller 130 and to request a full synchronisation. This full synchronisation occurs on boot up of the smart controller and may be repeated once every 24 hours or other specified interval. In response to the call 532, the web service returns a full set of membership codes for the device.

In addition, there is a periodic thread 540 that runs at specified intervals. In one arrangement the periodic thread 540 runs every five minutes while the smart controller 130 is active. In this periodic update, the smart controller 130 calls the machine interface 126 in a call 542A, 542B and supplies its unique identifier 504 and the list 508 of membership codes that have been presented for entry and/or presented for exit, along with time stamps. The periodic update may be called with a membership code that has been presented and for which no booking was found. The smart controller may make such a call to check it if a member has made a new booking since the last partial update. In response to the periodic update 542, the web service returns a set of membership codes that are to be added and removed from the smart controller memory 502, as well as any additional control instructions for the smart controller 130.

When a membership code is presented to the smart controller 130 and no booking is found in memory by a check function 560 running on the smart controller 130, then an on-demand booking execution thread is run on the smart controller 130. The smart controller sends a call 552 to the machine interface 126 supplying its unique identifier 504 and the membership code. Following the interaction outlined in Figure 4A and 4B, the machine interface 126 returns confirmation of a new booking, potentially along with a parking space number, for the supplied membership code. The check function 560 searches the list of bookings 506 indexed by membership codes. If a booking is found for the supplied membership code then the signal generator 524 is pulsed to open the door for secured access. In another embodiment, the smart controller also includes a display and/or a speaker to visually and/or aurally indicate to a member that a booking has been found for the supplied membership code.

Computer processing system

The present invention is necessarily implemented using an electronic device. The electronic device is, or will include, a computer processing system. For example, the Human Interface 122, Database 124, Machine Interface 126 and Smart Controller 130 may be implemented using a computer processing system.

Figure 6 provides a block diagram of one example of a computer processing system 100. System 100 as illustrated in Figure 6 is a general-purpose computer processing system. It will be appreciated that Figure 6 does not illustrate all functional or physical components of a computer processing system. For example, no power supply or power supply interface has been depicted, however system 100 will either carry a power supply or be configured for connection to a power supply (or both). It will also be appreciated that the particular type of computer processing system will determine the appropriate hardware and architecture, and alternative computer processing systems suitable for implementing aspects of the invention may have additional, alternative, or fewer components than those depicted, combine two or more components, and/or have a different configuration or arrangement of components.

The computer processing system 100 includes at least one processing unit 102. The processing unit 102 may be a single computer-processing device (e.g. a central processing unit, graphics processing unit, or other computational device), or may include a plurality of computer processing devices. In some instances all processing will be performed by processing unit 102, however in other instances processing may also, or alternatively, be performed by remote processing devices accessible and useable (either in a shared or dedicated manner) by the system 100. Through a communications bus 104 the processing unit 102 is in data communication with one or more machine-readable storage (memory) devices that store instructions and/or data for controlling operation of the processing system 100. In this instance system 100 includes a system memory 106 (e.g. a BIOS), volatile memory 108 (e.g. random access memory such as one or more DRAM modules), and nonvolatile memory 1 10 (e.g. one or more hard disk or solid state drives).

System 100 also includes one or more interfaces, indicated generally by 1 12, via which system 100 interfaces with various devices and/or networks. Generally speaking, other devices may be physically integrated with system 100, or may be physically separate. Where a device is physically separate from system 100, connection between the device and system 100 may be via wired or wireless hardware and communication protocols, and may be a direct or an indirect (e.g. networked) connection.

Wired connection with other devices/networks may be by any appropriate standard or proprietary hardware and connectivity protocols. For example, system 100 may be configured for wired connection with other devices/communications networks by one or more of: USB; FireWire; eSATA; Thunderbolt; Ethernet; OS/2; Parallel; Serial; HDMI; DVI; VGA; SCSI; AudioPort. Other wired connections are, of course, possible.

Wireless connection with other devices/networks may similarly be by any appropriate standard or proprietary hardware and communications protocols. For example, system 100 may be configured for wireless connection with other devices/communications networks using one or more of: infrared; Bluetooth; Wi-Fi; near field communications (NFC); Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), long term evolution (LTE), wideband code division multiple access (W-CDMA), code division multiple access (CDMA). Other wireless connections are, of course, possible.

Generally speaking, the devices to which system 100 connects - whether by wired or wireless means - allow data to be input into/received by system 100 for processing by the processing unit 102, and data to be output by system 100. Example devices are described below, however it will be appreciated that not all computer- processing systems will include all mentioned devices, and that additional and alternative devices to those mentioned may well be used. For example, system 100 may include or connect to one or more input devices by which information/data is input into (received by) system 100. Such input devices may include physical buttons, alphanumeric input devices (e.g. keyboards), pointing devices (e.g. mice, track pads and the like), touchscreens, touchscreen displays, microphones, accelerometers, proximity sensors, GPS devices and the like. System 100 may also include or connect to one or more output devices controlled by system 100 to output information. Such output devices may include devices such as indicators (e.g. LED, LCD or other lights), displays (e.g. CRT displays, LCD displays, LED displays, plasma displays, touch screen displays), audio output devices such as speakers, vibration modules, and other output devices. System 100 may also include or connect to devices which may act as both input and output devices, for example memory devices (hard drives, solid state drives, disk drives, compact flash cards, SD cards and the like) which system 100 can read data from and/or write data to, and touch-screen displays which can both display (output) data and receive touch signals (input). System 100 may also connect to communications networks (e.g. the Internet, a local area network, a wide area network, a personal hotspot etc.) to communicate data to and receive data from networked devices, which may themselves be other computer processing systems.

It will be appreciated that system 100 may be any suitable computer processing system such as, by way of non-limiting example, a desktop computer, a laptop computer, a netbook computer, tablet computer, a smart phone, a Personal Digital Assistant (PDA), a cellular telephone, a web appliance. Typically, system 100 will include at least user input and output devices 1 14 and (if the system is to be networked) a communications interface 1 16 for communication with a network 1 18. The number and specific types of devices which system 100 includes or connects to will depend on the particular type of system 100. For example, if system 100 is a desktop computer it will typically connect to physically separate devices such as (at least) a keyboard, a pointing device (e.g. mouse), a display device (e.g. a LCD display). Alternatively, if system 100 is a laptop computer it will typically include (in a physically integrated manner) a keyboard, pointing device, a display device, and an audio output device. Further alternatively, if system 100 is a tablet device or smartphone, it will typically include (in a physically integrated manner) a touchscreen display (providing both input means and display output means), an audio output device, and one or more physical buttons.

System 100 stores or has access to instructions and data which, when processed by the processing unit 102, configure system 100 to receive, process, and output data. Such instructions and data will typically include an operating system such as Microsoft Windows®, Apple OSX, Apple IOS, Android, Unix, or Linux.

System 100 also stores or has access to instructions and data (i.e. software) which, when processed by the processing unit 102, configure system 100 to perform various computer-implemented processes/methods in accordance with embodiments of the invention (as described above). It will be appreciated that in some cases part or all of a given computer-implemented method will be performed by system 100 itself, while in other cases processing may be performed by other devices in data communication with system 100.

Instructions and data are stored on a non-transient machine-readable medium accessible to system 100. For example, instructions and data may be stored on non- transient memory 1 10. Instructions may be transmitted to/received by system 100 via a data signal in a transmission channel enabled (for example) by a wired or wireless network connection.

Electronic device In one embodiment, the present invention is implemented using an electronic device with a touchscreen display, for example a smart phone or tablet computer. For example, the Human Interface 122 may be implemented using such an electronic device. The member 120 may also use a device such as a smartphone to present the membership code to the Smart Controller 130. Figure 7 provides a depiction of such an electronic device 200. Device 200 is a type of computer processing system 100 (as described above), and as such includes computer processing system components such as processing unit 102, bus 104, and memory 106, 108, and/or 1 10. Device 200 also includes (in this instance) communications interfaces allowing device 200 to wirelessly connect to a mobile telecommunications network (e.g. 3G or 4G network) and a data network (e.g. via Wi-Fi).

Device 200 also includes (in a physically integrated manner) a touchscreen display 202, physical buttons 204a, 204b, and 204c, a microphone 206, and a speaker 208.

Embodiments of the system will be described with reference to their implementation on or by an electronic device such as device 200. It will be appreciated, though, that elements of the system could well be implemented by other computer processing systems.

It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

Claims

1 . A computer-implemented system for managing vehicle parking bookings, comprising: a) a database storing:

• an active record of parking spaces at at least one secured parking facility;

• an active record of bookings for the parking spaces, wherein each booking is associated with a membership code; b) a human interface arranged to provide access to the database, configured to enable a member to search available parking spaces and to make a booking that is stored in the database associated with the member's membership code; c) a smart controller located at the secured parking facility, comprising:

2. The system according to claim 1 wherein, if no valid booking is identified in the local memory for the input membership code, the smart controller is configured to communicate with the database via the communication interface to search for available parking in the active record of parking spaces and to present available parking from the active record for member selection via the user interface.

3. The system according to claim 1 or claim 2 wherein the user interface of the smart controller comprises at least one of:

• a keypad;

• a touchscreen;

• a QR code reader;

• an RFID reader;

• a BLE sensor; and

· an NFC reader.

4. The system according to any one of the preceding claims wherein the local memory of the smart controller comprises a list of entry and exit records for the secured parking facility, and wherein the smart controller is configured to refuse vehicle access if the input membership code has been previously used to enable vehicle access at the secured parking facility and there is not a subsequent exit record in the list.

5. The system according to any one of the preceding claims wherein the database stores details of at least one fleet account, wherein a group of membership codes are linked to the fleet account.

6. The system according to claim 1 wherein the human interface is arranged to display the available parking spaces based on preferences supplied by the member.

7. The system according to claim 6 wherein the human interface is arranged to display booking details associated with the available parking spaces.

8. The system according to claim 1 wherein the wireless data

communication between the smart controller and the database involves complete or periodic synchronisation of the bookings in the local memory of the smart controller with the bookings in the database.

9. The system according to claim 1 wherein the human interface is configured to alert the member to an available parking space, wherein this alert is based on preferences supplied by the member.

10. The system according to claim 1 wherein the human interface is configured to issue a vehicle based indicium.

1 1 . A computer-implemented method for managing vehicle parking bookings, comprising: a) storing, at a database,:

• an active record of bookings for the parking spaces, wherein each booking is associated with a membership code; b) searching and booking, via a human interface, available parking spaces stored in the database and associated with the member's membership code; c) at a smart controller located at the secured parking facility:

• storing, in a local memory, bookings for parking spaces at the secured parking facility, the bookings being associated with a corresponding membership code;

• synchronising the bookings in the local memory with the bookings in the database; and

• receiving, at a user interface, an input membership code, wherein the smart controller searches the local memory for a valid booking matching the input membership code and if a valid booking is identified, enabling vehicle access to the secured parking facility.

12. The method of claim 1 1 wherein searching available parking spaces in the database further comprises:

• generating, for each of the parking spaces, an availability mask defining parking space availability for a specified time period, wherein the time period is subdivided into time increments and the availability mask for the parking space comprises a sequence of bits wherein each bit defines the availability of the parking space for a respective time increment;

• generating a request mask for a user to search for available parking

spaces between a start time and an end time during the time period, wherein the request mask comprises a sequence of bits corresponding respectively to the time increments of the time period, wherein each bit of the request mask defines whether or not the corresponding time increment lies between the start time and the end time;

• performing a bit-wise logical operation between the request mask and the availability masks of the plurality of parking spaces;

• identifying to a user, based on an output of the bit-wise logical operation, whether one or more of the parking spaces are available for booking between the start time and the end time; and

• booking the parking space based on a selection by the user.

13. The method of claim 12 wherein the availability mask and requesting mask each comprise a string of 288 bits.

14. The method of claim 13 wherein each bit of the availability mask is assigned a value of 0 or 1 depending on the availability data of the resource for the respective time increment.

15. The method of claim 13 wherein each bit of the requesting mask is assigned a value of 0 or 1 depending on whether or not the corresponding time increment lies between the start time and end time.

16. A computer-implemented system for managing vehicle parking bookings, comprising: a) a database storing:

17. The system of claim 16, wherein the smart controller indicates that a valid booking has been identified via a display or speaker.

18. A computer-implemented system for managing vehicle parking bookings, comprising: a) a database storing: • a plurality of membership codes of members of the vehicle parking booking system;

· an active record of bookings for the parking spaces, wherein each booking is associated with a membership code; b) a machine interface arranged to provide access to the database, configured to enable a member to search available parking spaces and to make a booking that is stored in the database associated with the member's membership code; c) a smart controller located at the secured parking facility, comprising:

19. A computer-implemented method for searching for resource availability in a database comprising booking information for multiple resources, the method

comprising:

• generating, for each of the resources, an availability mask defining

resource availability for a specified time period, wherein the time period is subdivided into time increments and the availability mask for the resource comprises a sequence of bits wherein each bit defines the availability of the resource for a respective time increment; generating a requesting mask for a user to search for resource availability between a start time and an end time during the time period, wherein the requesting mask comprises a sequence of bits corresponding respectively to the time increments of the time period, wherein each bit of the requesting mask defines whether or not the corresponding time increment lies between the start time and the end time; performing a bit-wise logical operation between the requesting mask and the availability masks of the plurality of resources; identifying to a user, based on an output of the bit-wise logical operation, whether one or more of the resources is available for booking between the start time and the end time; and booking the resource based on a selection by the user.

20. The method of claim 19 wherein the availability mask and requesting mask each comprise a string of 288 bits.

21 . The method of claim 20 wherein each bit of the availability mask is assigned a value of 0 or 1 depending on the availability data of the resource for the respective time increment.

22. The method of claim 20 wherein each bit of the requesting mask is assigned a value of 0 or 1 depending on whether or not the corresponding time increment lies between the start time and end time.