This invention relates to bicycle hire schemes, including associated systems, methods and apparatus. While predominantly directed to bicycle hire schemes the various inventions described may also have wider applicability, not only to the hire of other vehicles (eg. scooters, personal transporters, self-balancing motorised vehicles, unicycles, tandem bicycles, and others) but also for example to the hiring and time-management of limited resources more generally.

It is increasingly common for cities to have bicycle hire schemes, wherein bicycles ('bikes') are made available for use on a short-term basis. A typical bicycle-hire scheme comprises a plurality of docking stations provided at various locations around the city at which a user can hire and/or return a bicycle. Users may hire a bicycle from one docking station and return it to a different docking station. More recently, "dockless" schemes have been developed, wherein bicycles are not necessarily required to be collected from or returned to a docking station. In order to participate in a bicycle-hire scheme, users may be required to register with the scheme and set up a user account which is associated with their payment details. This may allow a user subsequently to hire and return a bicycle simply by providing, for example via a smartcard or smartphone, an account identifier at a docking station. In some embodiments non-registered users may also use the scheme providing they provide some payment details at the point of hire.

Charges are incurred according to the duration of bicycle hire. Various schemes and subscriptions may be available. For example, registered users may pay a subscription fee (eg. on a daily, weekly or annual basis), potentially with additional fees payable on an ad-hoc basis. Certain schemes may allow a registered user a limited period of free hire if they have paid the annual subscription fee.

Docking stations typically have a terminal for user interaction and docking points from which users can collect and return hired bicycles. The terminal may also have a display screen (for example a touch screen, or a screen connected to an input device, such as a keyboard and/or mouse) to allow a user to interact with the system. The docking station may also have payment facilities, such as a (eg. payment) card reader, and printing facilities to allow a user to print out their account details or hire information, for example.

Typically, users, docking stations and/or bicycles are managed from a central server. In order for the system to verify that an individual wishing to hire a bicycle at a docking station is a member of the scheme with an up-to-date (ie. paid for) subscription, the docking station communicates with the central server which in turn checks in a user subscription database whether the individual is a registered user of the scheme. Once the user is verified, the central server then identifies, based on the information in its central database, a suitable bicycle present at the docking station to release to the user.

There are many problems which may arise which lead to issues with hiring and/or returning bicycles at docking stations, for example:

• Docking stations need to be able to communicate with the central server at the very least when a user wishes to hire and/or return a bicycle to that docking station, and preferably at all times. This is not always possible since there may be problems with the central server and/or the communication channel to the central server.

• Demand for bicycles at certain docking stations may be greater than at other docking stations. This can lead to an accumulation of bicycles at certain docking stations or in certain geographical areas and a lack of bicycles in other areas, which is problematic.

• Bicycles and/or docking station are prone to developing faults over time and with use.

It is important to be able to identify problems with bicycles and/or docking stations easily, to determine which bicycles and/or docking stations are faulty and where they are situated in order to remedy faults as quickly as possible. There is therefore scope for improvement in the field of bicycle hire schemes and the associated systems, methods and apparatus.

The present invention provides improved systems, methods and apparatus for bicycle hire schemes, and in particular for bicycle hire schemes that employ a docking station.

According to an aspect of the invention, there is provided a system for administration of bicycle hires and/or returns at docking stations across one or more locations, comprising a server and a plurality of docking stations, wherein each of said plurality of docking stations is adapted to communicate with the server and also with at least another of said plurality of docking stations, ie. in a peer-to-peer mode. The docking stations may communicate either directly with each other or via the central server. The system may be configured to allow docking stations to operate in an Offline mode' whereby they can autonomously regulate hires and/or returns, for example when there is no connectivity to the server. The docking station may then upload data to the server once a connection is re-established.

The system may include a tool (eg. a 'mapping' tool), which may be configured to group docking stations into sub-clusters, based on their geographic location for example. Bicycle availability throughout a city can thereby be improved by allowing the regulation of bicycle hires and returns both at individual docking station level and also at sub-cluster level.

The system may be arranged to control (eg. remotely) the availability of bicycle hire at one or more docking stations. For example, bicycle hire from individual docking stations may be controlled based on local events. The docking stations may be controlled to have shortened or extended Opening' hours, on certain days or during certain events. A docking station may be controlled to be taken out of service for a period of time. The availability may be limited or completely restricted.

The system may be arranged to detect faulty bicycles automatically based on an elapsed time and/or distance travelled during a hire event. A bicycle may be provided with a GPS unit to help determine the distance it has travelled. The system may be arranged to enable and/or disable faulty bicycles remotely, preferably when docked at a docking station. The system may be arranged to enable or disable a bicycle based on said fault detection. The system may require a predetermined number of such faults to be detected before logging a bicycle as faulty. Additionally, or alternatively, the system may be arranged to allow for bicycles to be remotely enabled or disabled at a docking station according to one or more pieces of input information transmitted to the docking station, for example information relating to a bicycle being reported as faulty via an app and/or website. The system may be arranged to allow the content / information displayed by display screens and other audio and/or visual equipment provided at (eg. a terminal of) the docking stations (such as text, images, audio, etc.) to be controlled remotely.

A software application ('app') may be provided for end users/customers of the bicycle hire system, said app being downloadable on, and usable via, a smartphone(s), tablet(s), and/or any other personal computing device(s) belonging to the user. As used herein, the terms 'user', 'customer', and 'subscriber' may be used interchangeably.

The app and/or a website may make use of the mapping tool to allow users to view the list of docking stations along with their geographical locations. A search feature may be included to allow users to search the list of docking stations. Directions and/or timings to the nearest (or any) docking station may be provided. The availability of bicycles at a selected docking station may be provided.

The app may allow users to inform the system of faults and/or other problems with a bicycle. These faults may include mechanical faults and/or electronic faults such as the inability to properly register a bicycle, for example. The bicycles thus flagged as having faults can then, if desired, be disabled remotely and/or booked in for repair. Problems signalled by users via the app can be used to produce maintenance tickets assigned to individual users, individual bicycles, and/or individual docking stations, which can then be classified according to subject and straightforwardly prioritised for investigation and/or repair. There may be a predefined minimum waiting time between two distinct journeys for a single user. This may prevent a user from docking a bicycle and immediately trying to take it out again. The system may be arranged to enable the user to receive an audio and/or visual indication, preferably via appropriate equipment provided at the docking station (eg. a screen), of a 'countdown' of this minimum waiting time. The notification may be provided by the system in response to an input from the user, such as holding a (eg. smart) card against a card reader located at and associated with the docking station.

The app may be configured to use a user's email address as their username. The system may be configured to send real-time usage and billing information to users via emails to these addresses, for example to inform users of charges applied to their account. The system may be arranged to prevent or otherwise warn a customer of potential over-usage when a customer's journey time is close to a threshold duration (eg. one hour).

A user may be able to block access to his account or 'smartcard' temporarily via an app and/or website, if the card is misplaced or potentially considered to be lost. The user can unblock access in a similar manner. Users may be able to administer membership, subscription and/or communication preferences via the app. The app may have simplified log-on procedures, for example using a PIN-code or biometric identification. Users may be able to indicate within the app their preferred language (eg. Dutch, English, or French); further communication with the user, including emails, will then be sent in the preferred language. A website may be provided for users to perform substantially the same actions as with the app described above, a subset of those actions, and/or additional actions. The system may be arranged to provide an automated subscription and billing infrastructure that allows customers to electronically sign ("e-sign") documents including usage contracts, bills, or invoices, for example.

The subscription and billing infrastructure may be arranged to allow subscriptions for minors between 16 and 18 years of age to be electronically approved and/or paid for by their parents or guardians responsible for them. The subscription and billing infrastructure may be capable of administering payments via direct debit in a fully automatic manner.

The subscription and billing infrastructure may also be arranged to provide specific subscriptions for business, such as the hotel industry, for example, whereby hotels may be able to offer short subscriptions (eg. one day and/or one week) to their guests.

Additionally, the system described above may be arranged to be integrated as part of a "Mobility as a Service" (MaaS) infrastructure.

Sundry further features provided include:

• a system for managing and controlling a bicycle-hire scheme where the bicycle docking stations are managed and controlled depending on data in the local databases or in the central database.

• docking stations which have statuses relating to different criteria and the operation of the docking stations depend on their statuses. This may be advantageous in allowing the docking stations to adapt their behaviour dependent on certain criteria, which allows for the docking stations and the bicycles of the bicycle-hire scheme to be managed more effectively.

• an offline mode, which operates when a docking station is unable to communicate with the central server due to an issue with the central server or the communication channel to the central server. This may be advantageous in allowing users to hire and/or return bicycles to a docking station even when the docking station is unable to communicate with the central server. This prevents the possible abandonment of bicycles and/or the dissatisfaction of users of the bicycle hire scheme.

• a map tool, that allows the visualisation of the locations of the docking stations on a map, along with details of the docking stations such as whether each docking station is full, empty, or faulty, for example. This may be advantageous in allowing the docking stations and bicycles to be visualised and managed by geographical location. This allows the accumulation of bicycles in areas of low demand and lack of bicycles in areas of high demand (for example) to be prevented. It also allows users to be informed about the availability of bicycles and/or bicycle docking stations in their vicinity.

• a calendar functionality to configure the opening hours of docking stations on a local and/or global (system-wide) level in dependence on the day of the week and/or time of year, or during certain events such as public holidays, for example. This may allow for a greater degree of customisation of the opening hours of the docking stations, meaning the docking stations can be managed and controlled more effectively.

The system may be further arranged to provide one or more of the following features:

· Problem logging

• Cooperation with (eg. neighbouring) docking stations

• Control of docking stations

• Offline mode

• Mapping functionality

· Parental / guardian access control

• Increased user interaction

• Enhanced website and/or app functionality

• Digital signatures/payments

• Remote control of display screen content

· Integration with Mobility as a Service (MaaS)

• Facilitation of business subscriptions

• Upgrading of Bicycles

Generally, various systems may be implemented by a bicycle hire scheme, which allow it to be automated. These include systems for controlling bicycle usage, for example identifying users, accessing user accounts, processing payments, monitoring hire duration, and monitoring for the return of hired bicycles, including when a bicycle has been returned (ie. docked) at a different docking station to that from which it was hired.

Further features of the invention are set out in the accompanying claims.

The invention may also provide a computer program and a computer program product for carrying out any of the methods and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention may also provide a signal embodying a computer program for carrying out any of the methods and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out the methods described herein and/or for embodying any of the apparatus features described herein.

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

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination.

Equally, the invention may comprise any feature as described, whether singly or in any appropriate combination. Features expressed as means-plus-function may also be expressed in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

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

The invention will now be described in more detail by way of an example, with references to the accompanying drawings in which:

Figure 1 shows a bicycle hire system in overview; Figure 2 shows a bicycle hire system in more detail; Figure 3 shows a docking station behaviour table; Figure 4 shows a docking station failure / operations table; Figure 5 is a flowchart illustrating offline operation and synchronisation; Figure 6 shows a map interface for managing the bicycle hire system; Figure 7 shows a docking station management interface; and

Figure 8 shows examples of user interfaces for reporting faults. Overview

Figures 1 and 2 show a bicycle hire system, in which a server is in communication with a plurality of bicycle docking stations, which are also in communication with each other.

Bicycle hire system 10 comprises a plurality of docking stations 202 (a, b, c) each comprising respective docking bays 204 and bicycles for hire 206. The docking stations are provided at different geographical locations around a city.

Each docking station 202 is provided with a processor 208 which is operable to manage and control the docking station. For example, the processors control the release and/or return of bicycles to the docking station, and verify the identity of individuals wishing to hire bicycles at the docking station. The processor 208 is provided with a local database 210 which stores information pertaining to the bicycle hire system. Each processor 208 is operable to control the hire of bicycles at the docking station, for example, releasing a suitable bicycle 206 held in a bay 204 to a user based on the information in the local database 210.

The system further comprises a server 212. The server is provided with a central database 214 which stores information pertaining to the bicycle hire system. Server 212 is in communication with the docking stations 202, for example via the internet 216 or some other communications link. The docking stations 202 are operable to communicate with the central server 212 and to download the data in the central database 214 to their local databases 210. The docking stations 202 are also able to communicate between themselves, for example via the internet 216.

Each docking station 202 has a set of status values associated with it. The status values of each docking station 202 are stored in the local database 210; the status values of all the docking stations are stored in the central database 214. Docking status processors 208 control the behaviour of the docking stations 202 in dependence on the values of these statuses.

Examples of statuses and their possible values include the following:

Calendar status

The calendar status can be either Open' or 'closed'.

• 'Open' signifies that the station is open for use by the public by calendar hours. The hours during which a docking station 202 is open are given by the opening hours as defined in the calendar of the docking station.

• 'Closed' signifies that the station is closed to the public by calendar hours (as given by the non-opening hours defined in the calendar of the docking station). The calendar data of the docking station is stored in the local database 210.

For example, on a given date (eg. 1 August), the station can be configured by its calendar to have the calendar status 'open' during certain hours (eg. midnight until 1800hrs), and 'closed' outside these hours.

There is also provided a global calendar stored in the central database 214. A copy of the global calendar is also stored in the local databases 210 and is used in combination with the local calendar to determine the opening hours of a docking station. The global calendar allows the modification of the opening hours of all the docking stations in dependence on the time of year or during certain special events such as public holidays, for example.

Operational status

The operational status determines whether a given docking station 202 is functioning correctly. The value of the operational status can be any one of 'operational', 'non- operational', 'test', or 'removed'.

• 'operational' signifies that the docking station is functioning correctly.

'non-operational' signifies that the docking station is not functioning correctly. For example, a docking station can be ascribed the status 'non-operational' if all the locks securing the bicycles 206 to the docking bays 204 fail to work,

'test' signifies that the docking station is functioning correctly but can only be used for testing purposes.

'removed' signifies that a particular docking station is no longer present (ie. no longer a part of the bicycle-hire system), in which case the station record (ie. the contents of the local database 210 of the station) are archived in the central database 214. The 'test' and 'removed' statuses are only stored and/or used by the central server - for example, they are not displayed by the Map Tool (described below).

Connectivity status

The connectivity status determines whether a given docking station has connectivity to the server 212. The value of the connectivity status can be either 'connected' or 'disconnected'.

• 'connected' signifies that the docking station has connectivity to the server 212.

• 'disconnected' signifies that the docking station does not have connectivity to the server 212. A 'disconnected' status can be caused by technical issues with the internet 216 and/or server 212. Figure 3 shows a docking station behaviour table, which determines the behaviour of the docking stations 102 in dependence on the possible combinations of the abovementioned docking station statuses.

Each table row 302 represents a possible status combination, comprising a calendar 304, operational 306 and connectivity 308 statuses. The corresponding behaviours include: · "Bike check out?" 310 indicating whether, for the given combination of statuses in columns 304, 306, and 308, bicycles can be checked out from a docking station

• "Bike check in?" 312 indicating the corresponding behaviour for whether bicycles can be checked in at the docking station.

• "MapTool Station Status" 314 indicating what the status of the station is as displayed by the Map Tool (discussed below).

For example, referring to status combination 1 (row 1), if the calendar status of a docking station is 'open'; the operational status 'operational' and the connectivity status 'connected', then columns 310 and 312 indicate that it is possible to check bicycles into and out of the docking station. In such a case the status of the station as displayed by the Map Tool is 'online'.

If the docking station loses connectivity with the central server 212 such that the connectivity status becomes 'disconnected' (see status combination of row 2), then columns 310 and 312 indicate that bicycle check-in remains possible at the docking station, but that bicycle checkout is no longer possible. In this case, the docking station status as displayed by the Map Tool is 'offline'. If the calendar status is 'closed', and the operational status is 'operational' (see status combinations 5 and 6), then columns 310 and 312 indicate that bicycles can be checked into the docking station, but cannot be checked out - independent of whether the connectivity status 308 is 'connected' or 'disconnected'. This allows users to return bicycles to a docking station even when the docking station is closed, so long as the station is functioning.

However, if the station is not functioning, so the operational status of the docking station is 'non-operational' (see rows 7 and 8) then it is not possible to check in bicycles.

If the calendar status is 'closed' (rows 5, 6, 7 and 8), then the station status displayed by the Map Tool is 'closed'. Figure 4 shows a docking station failure / operations table, which determines the behaviour of the docking stations 102 in dependence on various failure scenarios.

For each failure scenario (indicated by row 402 and descriptor 404) the ability for a user of the bicycle hire scheme to check-out 406 and/or check-in 408 a bicycle at a docking station - and also for a supervisor to access the docking station 410 - is dependent also on the connectivity status 412 and the operational state 414 of the docking station. The final column 416 the message displayed at the management console for that failure scenario.

For example, in the scenario shown in row 1 , a station has an 'authentication failure' ie. a failure to authenticate with the central server, but is nevertheless online. In such a failure scenario, column 406 indicates that whether bicycles can be checked out from that station depends on the value of the 'Offline Checkout Flag'. The 'Offline Checkout Flag' is a city- level parameter that modifies the behaviour of bicycle check-in/check-out specific to offline station scenarios (ie. when there is no connectivity to the central server). If Offline Checkout Flag=1 , then bicycle check-out is permitted; otherwise it is not permitted. Column 408 indicates that bicycles can be checked in; column 410 indicates that supervisor access is possible; column 412 indicates that the connectivity status of the station is 'disconnected' (since it cannot authenticate with the central server); column 414 indicates that the operational state of the station is 'operational', and column 416 indicates that the message displayed at the management console is 'Station Offline Not Supported'.

As another example, for the failure scenario is row 3, where a station has a 'lock controller failure' ie. the locks securing the bicycles at the station cannot be locked and/or unlocked, and the station is online - column 404 indicates that bicycle check-out is not possible; column 408 bicycle check-in is not possible; column 410 indicates that supervisor access remains possible, and column 412 indicates that the connectivity status of the station is 'connected'. Column 414 indicates that the operational state of the station is 'non- operational' (since bicycles cannot be checked in or checked out from the station), and column 416 indicates that the message displayed at the management console is 'Non- operational - All Locks Failed'.

Offline operation and synchronisation

Figure 5 is a flowchart illustrating offline operation and synchronisation.

• At step 502, a user requests a bicycle at a docking station.

• At step 504, the docking station checks whether there is connectivity to the central server.

• At step 506, the docking station determines if there is connectivity to the central server. o If there is connectivity to the central server, then the docking station undertakes step 506-1 and downloads the data from the central database and reads that data. o If there is no connectivity to the central database, then the docking station undertakes step 506-2 and reads the data from its local database.

• At step 508-1 , the processor then controls the docking station (for example, release a bicycle to a user) based on either the data from the central database or the data from the local database.

If at step 504 the docking station determined that there was connectivity to the central server, the processor also performs a step 508-2, wherein it saves the data from the central database in the local database, thus ensuring that the data in the local database are kept up-to-date.

The steps 504, 506-1 , and 508-2 define a synchronisation process that allows the docking station to synchronise with the central server.

In some alternatives, the process illustrated in the flowchart is not initiated by a user requesting a bicycle at a docking station, but can be initiated by another action such as a user returning a bicycle to the docking station. In other alternatives, the docking stations is configured to periodically attempt to synchronise with the central server, checking for connectivity to the central server according to the step 504 and then synchronising according to steps 506-1 and 508-2 if connectivity exists.

The offline mode as described above allows the docking station to manage and control itself based on data in its local database if there is no connectivity to the central server. This allows the docking station, for example, to assign bicycles to users even when there is no connectivity to the central server.

The data synchronisation process described in steps 504, 506-1 and 508-2 occurs when the server goes from offline to online. The system is designed so that in the event of loss of mobile connectivity, a subscriber will (a) always be able to take a bicycle and (b) the station will still function. Messaging is queued and sent once the connection is back online. If the server has pending actions (station calendar, station restart) with the station (because of the communication cut to the server), the server will send all pending messages commanding such actions to the station and vice versa. Preferably, the docking stations work offline when the communication with the central server is down. Users can then perform bicycle docking and/or bicycle removal in such circumstances. A data synchronisation process (between the central server(s) and the docking stations occurs when the server return to online from being offline.

An emergency mode may also be provided for offline work in certain circumstances may also be provided.

In other words, the docking stations are arranged to perform in Offline' mode, whereby each docking station is operable to regulate the hire of bicycles from that docking station and/or to make decisions and/or take payments autonomously when no connectivity is available to the (central) server and/or neighbouring docking stations. The docking stations may be configured to download log and/or configuration files from the server and store them locally such that in case of outages in connectivity, individual docking stations have access to local and up-to-date copies of information relating to the position and/or rental status of bicycles from the same and/or other docking stations. This ensures that the system is robust against issues with and/or outages of connectivity. Map tool

Figure 6 shows a map interface - or 'Map Tool' - for interacting with the bicycle hire system, typically provided via a website or dedicated app. Docking stations are grouped into sub-clusters, typically based on their geographical location. Regulation or management of docking stations may also be done at a sub-cluster level, for example in order to improve the availability of bicycles in selected areas of the city. This may increase the number of hire events using the same resources. The app and/or website may be configured to display the geographical locations of each docking station, optionally with a search feature for the user, for example to identify the docking station they are closest to geographically. The map tool may allow a user to group docking stations into sub-clusters based on a geographical location, or their personal user profile, for example if they take a particular route regularly or are planning to take a particular route. This may allow for the hire bicycles to be regulated by geographical area, for example, and may also allow docking stations to cooperate with each other in an advantageous way using this geographic information. For example, if there are no bicycles left a given docking station, the docking station indicates (eg. via the app or on a screen at the docking station) to potential users the location of the nearest docking station that has bicycles available for hire.

Figure 6a shows the map tool displaying the locations of the docking stations 602 belonging to the bicycle hire system on a map 600 of the city. Each docking station 602 is associated with a geographical sub-region indicated by the lines round each docking station. These geographical sub-regions define 'sub-clusters'. Each sub-cluster contains at least one docking station.

Sub-clusters are coloured or shaded according to certain criteria, for example:

• full, ie. all docking bays at all docking stations are occupied (bright red, 602f); nearly full (pale red, 602nf); empty, ie. no docking bay at any docking station has bicycles available to hire (bright blue, 602e); nearly empty (pale blue, 602ne); other (unshaded)

The map tool is also operable to determine and display data relating to the sub-clusters 602 displayed on the map 600, eg. the number of full sub-clusters 604 and empty sub-clusters 606; the number of broken (faulty) bicycles 608; broken slots (docking bays) 610, and offline stations 612, in addition to the total number of outstanding issues (eg. maintenance actions) to be addressed 614.

Figure 6b shows an interface showing the details of the aforementioned sub-cluster data. The portion 604 of the interface shows the details of three of the six full sub-clusters - their names 604-1 (eg. 'SC Bel04'), the number of free slots remaining in these sub-clusters 604- 2 (eg. Ό slots', since they are full), and how full these sub-clusters are 604-3 (eg. '100%'), and how long the sub-clusters have been full 604-4 (eg. Ί 1814 min'). The portion 606 of the interface similarly shows the details of the empty sub-clusters; portion 608 the details of the faulty / broken bicycles; portion 610 the details of the broken slots; 612 the details of the off- line stations, and 614 the details of the needed actions.

Figure 7 shows a docking station management interface, as used for modifying the details of the docking stations including the local and global (system-wide) calendars. This interface can be accessed via a web interface or via an app.

In order to view the details of a docking station and/or edit the local calendar, it is necessary to enter the station code in the field 706 (eg. 'Bel01 ') and the station name in the field 704 (which maybe the same as the station code). The field 706 indicates the installation date of the docking station; the fields 708 indicate the details of the docking station selected, for example the total number of bicycle racks provided by that docking station, the number of bicycle slots per rack, the number of operational slots, and the number of non-operational slots.

Fields 710 and 712 indicate the local and global calendars. The local and global calendar data determines whether each station has a calendar status of Open' or 'closed' at a given time. The calendars local to each station are stored in the local databases, and the global calendar is stored on the central database. In an alternative, a copy of the global calendar is also stored in the local databases.

Field 710 indicates the local calendar of the selected docking station ie. its opening hours, which can be modified via this interface. The selected docking station is open 24hrs/day apart from Sunday when it is open from midnight to 8pm.

Field 712 indicates the global calendar for all the docking stations. This calendar allows custom opening hours to be defined for all the docking stations on particular days. For example, the global calendar can enforce that all the docking stations be closed on public holidays, or that the docking stations have extended opening hours during the school summer holidays. Problem logging

Figure 8 shows examples of user interfaces for logging problems, reporting faults.

Problems with hiring or returning a bicycle - whether with a registered user account or a faulty bicycle - may be reported via the user interface which can be accessed via a web interface, via an app, or via a POS (Point of Service) station at a docking station itself.

A faulty bicycle may then be taken out of service (ie. "blocked") automatically. Alternatively, if the report is made by telephone, a helpdesk may be provided to block the bicycle.

Figure 8a shows a first example page 800 of the problem-reporting pages of the user interface. Via this page 800 it is possible to report: i) a problem with a bicycle by clicking on the field 802; ii) a problem with a bicycle station by clicking on the field 804; iii) a lost or stolen identification card by clicking on the field 806; iv) an unrecognised bicycle by clicking on the field 808; and v) other problems by clicking on the field 809.

Figure 8b shows the user interface page 810 brought up by clicking on the 'report a bicycle' field 802. To report a problem with a bicycle, it is necessary to complete the field 812 with the number of the bicycle concerned (which may be displayed on the bicycle, for example). A cartoon of the bicycle 814 illustrates via circles the areas with which it is possible to register faults - for example, the saddle 814-1 , bell 814-2 and tires 814-3. Problems with these areas are reported by ticking (or otherwise selecting) boxes in the field 816 corresponding to the areas of the illustration 814. It is possible to add custom (free-form) comments in the 'comment' field 818. Once the report is completed, the problem(s) with the bicycle is/are logged by submitting the report by clicking on the 'send' button 819.

Figure 8c shows the user interface page 820 brought up by clicking on the 'report a bicycle station' in the field 804. A problem with a bicycle station is logged in a similar way to a problem with a bicycle in page 810 - it is necessary to enter the bicycle station number in the field 822, then tick (or otherwise select) the box corresponding to the problem being reported in the field 824 - for example, that the bicycle station is 'full', 'dirty', 'empty', 'disconnected' or 'vandalised'. It is possible to add custom (free-form) comments in the 'comment' field 828. The problem(s) with the bicycle station is/are logged by submitting the report by clicking on the 'send' button 826. The reports logged are used to generate CRM (Customer Relationship Management) tickets corresponding to the reports. Example reports and the possible information contained in them are given in the following table.

* An additional mandatory check-box is provided "[ ] Bicycle is securely locked at Station"; if unchecked, the Customer is prevented from submitting the report/CRM ticket, and is presented an error message prompting the user to lock the bicycle at the station before proceeding.

The system may also be configured to detect a faulty bicycle through its usage.

For example, the system may determine that a user has hired a bicycle but returned it within a limited time period (eg. three minutes), either to the original docking station or to a neighbouring docking station within a limited distance (eg. 100 metres) of the original docking station. In this case, the user may be allocated a different bicycle and the original bicycle may be flagged as possibly faulty. If the same bicycle is flagged as being possibly faulty in this way multiple (eg. three) times, then the bicycle may be flagged as faulty. Furthermore, the system may be arranged to disable that bicycle and/or to prevent its release from the docking station remotely.

If, instead, the user returns a bicycle within a limited time period (eg. three minutes), but more than a limited distance (eg. 100 metres) away from the original docking station, then it may be assumed that the user has completed their journey successfully, and may not be allocated a different bicycle. In such an instance, the returned bicycle may not be flagged as possibly faulty.

The bicycle may be equipped with a GPS unit that can determine the distance that a bicycle has travelled, such that if a bicycle is returned to the same docking station from which it was hired within a limited time period but the GPS unit determines that the bicycle has travelled further than a limited distance, then it may be assumed that the user has completed their journey and/or that the bicycle is not faulty.

The following are examples of the fault-thru-usage determination process: Example A: i. A user hires a bicycle from a docking station and checks it over.

ii. The user finds a fault

iii. The user replaces this bicycle within a limited time period (eg. 3 minutes) in a docking station within a specific distance (perimeter of 100 metres) of the original docking station.

iv. The system logs that bicycle as potentially faulty and sets a counter.

v. When the counter reaches a predetermined number (eg. three), the system marks the bicycle as Faulty.

Example B i. A user hires a bicycle from a docking station

ii. The user makes a short journey (eg. under 3 minutes)

iii. However, the user cycles further than the perimeter of 100 metres

iv. This is considered as a journey; the user can simply check in (eg. scan out) again and confirmation will be provided (eg. via a display screen) that the bicycle has registered properly on the system.

More specifically, a bicycle may be marked/flagged as 'broken' (or 'faulty') in three ways:

1. System triggered: If a bicycle is allocated to the user, the bicycle slot will open (ie. the lock will be released) and the user has a certain time window to take the bicycle out from the slot. If the user does not take the bicycle out within the time window, the bicycle slot will lock again automatically. The user's ride is then marked as 'cancelled' and the 'possibly faulty bicycle' counter for that bicycle is increased by 1. Similarly, if a user returns the bicycle to the original station or a sibling station (ie. a neighbouring/nearby station within a certain radius) in less than a limited time period (eg. three minutes), the ride is also considered as cancelled and the 'possibly faulty bicycle' counter is increased by 1. If the 'possibly faulty bicycle' counter of a bicycle exceeds a certain value N (eg. three), then the bicycle will be marked as faulty / broken and it will no longer be assignable to users. The time between bicycle removal and re-arrival at a station (or sibling station) is a configurable city-wide parameter. Similarly N (the number of consecutive cancelled rides by subscribers to mark a bicycle as broken) is a configurable parameter.

2. Manually by a back office user. An authorised back office/server user can manually mark the status of the bicycle as 'faulty' in case any issue is reported by a user.

3. From a CRM note/ticket: The customer can flag/report issues with the bicycle via the website interface or the app - if the customer has informed customer case about a problem with the bicycle, a CRM note is created. The note is assigned to someone (ie. a maintenance worker) who will check the bicycle and choose whether to mark the bicycle as 'faulty' or not (manual action).

Cooperation with (eg. neighbouring) docking stations

Upon returning a hire bicycle, for example to a different docking station from which it was hired, a user may have to wait for a predetermined time before he can hire another bicycle. The docking stations may communicate the recent hire / return information either directly or via a server. The duration that the user has to wait may be made visible at the docking station, for example on a display screen. When a customer replaces a bicycle, he will see on the screen that he will have to wait, say, "5 minutes" or before taking a new bicycle.

The screen may show a "count-down" of the time remaining during this cooling off period every time the user swipes his smartcard, for example with the screen returning to its default home screen in between. So, if the customer has replaced the hired bicycle and he then holds his card against an associated card reader, he will be notified of the 5 minutes waiting time. If he holds his card against the card reader again after two minutes, the time will have changed to 3 minutes. The amount of 'cooling off time is configurable at each subscription level, and may be different for mechanical and electric bicycles. There may be a 'VIP' subscription level that allows subscribers to make two consecutive rides without waiting for a 'cooling off time. The amount of 'cooling off time may be adapted in dependence on the duration of the previous hire event. The 'cooling off function may be disabled if a user returns a faulty bicycle. Control of clocking stations

The opening and/or closing hours of docking stations (eg. during which a bicycle may be hired) may be controlled and/or modified remotely, from the central server. This allows for docking stations to remain closed, or have extended opening hours, on specific days and/or during certain events, which may be local to a certain docking station. Opening hours may be extended during fair weather, due to the likelihood of increased demand for bicycles compared with variable or inclement weather. Different docking stations can be chosen to have different opening and/or closing hours based on their geographical location and/or local demand. Parental / guardian access control

Consent for usage / subscription by minors, such as those aged between 16 and 18 years, may be sought and/or obtained via the website or app. For example, parents/guardians may have the option of buying a yearly subscription via the website or app for their son or daughter, which option may be presented to them following their son or daughter registering for the bicycle hire scheme, via the app or website.

Customers under 16 years old (determined by the 'Date of Birth' field on the web form filled in to register for an account) are restricted from purchasing subscriptions and are informed "You must be 16 or older to buy a subscription" when attempting to do so.

However, customers between 16 and 18 years of age have the opportunity to declare they have consent (eg. from their parents or guardians) to proceed with purchasing/using the bicycle hire service (similarly to how customers are asked to accept the bicycle hire terms and conditions during the registration process). For example, they are provided with a mandatory checkbox that states Ί have consent from a parent or legal guardian to purchase/use this subscription'. In this way, the number of people wishing to apply for a subscription in person at the relevant office or outlet is reduced. If the customer between 16 and 18 years old does not declare that they have adult consent, they will be informed, for example, 'You have to confirm you have parental permission to subscribe'.

Increased user interaction

If a user uses a bicycle for more than X minutes (eg. 120 minutes), they may be sent an e- mail notification. The user may be able to define X for their user profile via the app or website. This feature may be useful for reducing "overtime-usage". Users can raise tickets (eg. to report problems and/or make comments) via the app and the website. The tickets may be classified and assigned a specific priority according to the problem / comment / subject. This helps to ensure that back office staff can prioritise handling of the tickets. Indeed, tickets may be created against users, bicycles or stations. The ticketing facility may also include developing workflows and assignment groups.

Users may be notified when they are charged for registering or renewing their subscriptions, and/or if they incur duplicate, multiple-use and/or extra time charges, for example. They may be sent an e-mail stating the amount that will be charged. Alert distribution lists may be created and distributed, whereby a business unit can set up notifications to be sent out to customers via email and/or SMS, for example, for any alert purpose.

The system may provide multi-tenant functionality, wherein all locations may share a common app. The bicycle-hire system has automatic email notifications set for users and for employees. Email notifications to customers are triggered based on few triggers eg. credit card expiry. Email notifications for employees are sent for system-triggered alerts (eg. broken bicycle slot). Whether an email needs to be sent for each alert can be configured at the level of the central server. Enhanced website and/or app functionality

A user can temporarily block their smartcard via the 'user zone' of the website or app. For example, if a user loses their smartcard they can block it immediately to prevent unauthorised usage. If the user later finds the smartcard, they can re-activate (ie. un-block) it by a similar process. Users may log in using their e-mail address as identification to log-in to the app and/or website. A user can specify on the website or app (for example within his user-profile or a "user zone") in which language he prefers to communicate, for example Dutch, French, English, etc. Further communication (eg. e-mails) with the user will be done in the requested language. Digital signatures/payments

Users can sign mandates (eg. purchase orders) digitally. For example, a payment provider service (such as provided by Atos Worldline) may be used to allow users to sign their mandate digitally using a code that Atos sends them (similar to online purchases using a credit card).

The system is Payment Card Industry (PCI) compliant, in particular the subscription and billing engine. Improved security in relation to payments may be provided by using 3D security on credit card payments.

Remote control of display screen content The display screens (provided as part of the terminal) at docking stations may be dynamically controlled, such that text, images, and other content can be changed remotely so as to update the screen content, for example for advertising / information purposes. The display screens may be controlled to display common content across screens at all, or some of the docking stations. Alternatively, content displayed on screens at docking stations may be individually controlled, for example depending on the location of the docking station and thus the local demographic.

The information / content may be controlled based on one or more pieces of input information. The input information may include, but is not limited to: log files from individual docking stations, which can be downloaded to and/or from the central server(s), for example remotely.

Integration with MaaS

The bicycle hire scheme may be integrated as part of Mobility as a Service (MaaS) Facilitation of business subscriptions

Business subscriptions can be provided, for example hotels can offer their guests daily and weekly passes. This may be part of the business subscriptions feature.

Business subscriptions are a type of group subscription; the system also provides the facility of setting up other group subscriptions. It is possible to define an employer account and an employee account and the percentage that the employer pays for the employee's subscription. Upgrading I Bicycles

Existing docking stations with mechanical bicycles may be upgraded to facilitate the hire of electric bicycles ("e-bicycles"), for example by providing the necessary infrastructure to charge the batteries, etc. Subscriptions can be purchased separately for each type of bicycle service (mechanical bicycles or eBicycles), and charging rates and charging time intervals can vary between the services.

The system is configurable so that it can work with electrical and mechanical bicycles independently or in a mixed mode with a minimum mandatory subscription (usually for mechanical bicycles). The system provides for the possibility to upgrade from the one type of subscription to another (from mechanical to electric, for example), and for multiple separate and/or mixed subscriptions. A maximum of one bicycle for one subscriber is maintained in systems with a mix of bicycle types.

The system may identify if a given bicycle is mechanical or electric, as well as whether a given alert or flagged problem is for an electric or mechanical bicycle. Electric bicycles may have a load-level indicator and the system is able to store the battery statuses and load levels.

There are two general types of electric bicycle models: one where the battery is charged automatically when the bicycle is docked at a station, and another where (depleted) batteries are exchanged for other (charged) batteries by maintenance operators. In the latter case, when the battery charge is below a minimum level (eg. a threshold percentage of remaining battery), the bicycle status is flagged, eg. as broken or faulty, or with a dedicated 'battery empty' parameter. The tariff can be varied in dependence on whether an electrical or a mechanical bicycle is hired. Time intervals and rate for each time interval can be different for each type. Subscriptions can be independent and purchased separately, for example a subscriber subscribes to mechanical bicycles and independently to electrical bicycles. A subscriber may have more than one subscription if the services are different (mechanical and/or electric bicycle).

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