GB2515077A

GB2515077A - A locker access management system

Info

Publication number: GB2515077A
Application number: GB1310559.8A
Authority: GB
Inventors: Robert Luke Wollner
Original assignee: MOODFIELD Ltd
Current assignee: MOODFIELD Ltd
Priority date: 2013-06-13
Filing date: 2013-06-13
Publication date: 2014-12-17
Anticipated expiration: 2033-06-13
Also published as: GB2515077B; GB201310559D0

Abstract

A method of controlling access to a locker (16i, fig.2) comprises detecting user input of an access code at the locker, and comparing it with a local code generated at the locker. If the two codes match, the locker (16i, fig.2) is made available for use. The access code which is input by a user is based on a time of day for permitted access. The locally generated code may use an algorithm incorporating the time of day provided by a timer and a unique locker string associated with the locker. The unique locker string may comprise a locker identifier and a randomly generated string. The user may request an access code from a server 2, and the access code may be sent to a users mobile phone 10. The time of availability of the locker may be specified in the message.

Description

A LOCKER ACCESS MANAGEMENT SYSTEM

Field

The invention relates to a locker access management system.

The invenfion relates particulariy but not exclusively to security lockers for sports dubs, leisure centres, event venues and other applications.

Background

At present lockers for large venues such as the 02 Arena, which experience high volumes of customers before and after concert performances, require significant numbers of onsite locker staff to manage the lockers. *15

In these fields, there is a need for a system which will enable the sUocation, operaflon and payment for lockers based on customers using their mobile phones.

Statement of Invention

According to one aspect of the present invention there is provided a method of controlling access to a locker comprising: detecting user input of an access code at the locker, the access code based on a time of day for permitted access; at the locker generating a local code from the time of day provided by a timer, and a unique locker string associated with that locker; compañng the local code with the access code input by the user and releasing the locker for access by the user if there is a match.

The time may be located at the locker. The local code could be generated by an algorithm taking as input the unique locker string and the time of day provided by the tinier.

The unique locker string could comprise a locker identifier incorporating a randomly generated string.

S According to a second aspect of the present invention there is provided a locker comprising: a locking mechanism having a locked condition in which the locker is inaccessible and an unlock condition in which the locker is accessible; a controller connected to control the locking mechanism; a memory holding a unique locker string; and a user input means for receiving an access code, wherein the processor is configured to carry out the step of the method of any preceding claim, According to a third aspect of the present invention there is provded a locker management server having: a network interface for communicating with a user device to receive a user request for a locker access code, the user request defining a Ume of day for access; and a processor configured to generate an access code responsive to the user request, the access code based on the unique locker string and the time of day at which the locker is avaflable, and to formulate a response message to the user including a locker identifier, the access code and the time of day for permitted access, The present invention is particularly usefui in the context of lockers for large venues, of the type discussed in the background section, Such lockers generally have a capacity for holding bags and other personal items, and therefore have the size and capacity suitable for that function. It will be appreciated that the word locker" used herein is not restricted to that context, and it is intended to cover any kind of lockable container, for example security boxes, safes etc. Such containers may be much smaller and may not normally be referred to as lockers but nevertheless faU within the scope of the term as used herein.

The present invention will now be described by way of reference to the foowing drawings. In the drawings: a Figure 1 is a schematic block diagram of a locker access management system, Figure 2 is a schematic diagram of a single locker for use within the locker access management system.

Figure 3 is a flow chart iflustrating a method of operation of the locker access management system.

Figure 4 is a flow chart illustrating steps of an algorithm for generating an access code for a locker for use within the locker access management system.

The core of the system described herein is based on seeds and Uming information which are used to create a pseudorandom reproducible code in a code generation algorithm. The application of the same algorithm at two unconnected locations produces two identical codes which are matched up to operate a locker.

In one example, three inputs a Seed, a Salt and a Unicode Timestamp are subjected to a hashing algorithm to produce a nearandom reproducible code. This operation is carried out both by the specific locker and centrally by a locker management server. Because it is reproducible, the two independent calculations will yield the same code, importantly, these two calculations are carried out in complete separation, i.e. they are not connected via a data link. Instead (as seen in the examples below), the only "connection which is needed is the transfers via the customers' mobile phone of specific numbers. The other nk" in the system is a common reference point of time. The separation ensures that the system for locking and unlocking remains operative at aH times (provided there is mobile phone coverage). It does not rely on a data link between the locker location and the locker management server which (a) is at risk from disruption and (b) would provide a set-up which is more vulnerable to hacking.

Figure 1 iUustrates a schematic block diagram of a locker access management system. The system comprises a serier 2 which indudes a memory 4, a processor 6 and a network interface 8. The network interface 8 aflows communication with a user device 10 over a network (not shown). The user device 10 can take the form of any computer device, for example. a laptop. tablet, smartphone, etc. The user device 10 has a display 12 and a user input mechanism 14, The user input mechanism can be a keyboard, touchecreen (incorporated into the display 12) or any suitable user input device. The network can be wired or wireless, The locker access management system includes a bank of lockers 16. Each locker 16i in the bank is identified by a locker identifier referred to herein as LIN.

Asingle locker is shown in more detail in Figure 2. Each locker Wi has an accessible compartment concealed by a door 20. A locking mechanism 21 has a locked condition in which the locker compartment is inaccessible (because the door is shut) and an unlocked condition in which the locker compartment is accessible (because the door can swing open to reveal the compartment to a user). The locker includes a user input device 22 for example, in the form of a keypad into which a user can enter an access code for entering the locker. The locking mechanism 21 is controlled by a controller 24 responsive to the access code as described further herein. The controller 24 includes a memory 26 and a processor 28. It will be appreciated that Figure 2 is schematic only and that in fact the controller will be embedded somewhere within the locker housing whereas the user input means will be on an external surface of the housing to allow access by a user.

Figure 3 is a flow diagram illustrating how the locker access management system is operated. Step Si begins by a user sending a request to access a locker to the server 2. To do this, the user uses the user device 10 to generate a user request, for example, in the form of an SMS (short message service) message. The requests b request use of a locker at a certaRi specified location and can further indicate a required Ume of day for use of the locker. It will be recognised that although a single locker bank 16 is shown in Figure 1, in practice, there wifi be many other banks with multiple lockers at different geographical locaflons. The processor 4 at the server 2 receives a request and checks for locker availabflity. When it has determined that a locker is available at the requested time of day, it generates an access code for the locker based on the locker identifier and the time of availabity. For enhanced security, the locker identifier can be associated or otherwise scrambled with a random string generated at the time of generating the access code. The access code can be generated using any suitably secure algorithm, such as a hash or MAC algorithm.

Figure 4 shows an exemplary overview of such an algorithm for generating the access code. At step 41 a Seed, Unicode Timestamp and a SaR are input into a hash aigorithm such as, for example, SHA(256). The timestamp used on the lock side will be the current time, but on the server side can be suitable time not necessarily connected to the current time of day. The Seed and Unicode timestamps are concatenated. The Seed is generated from the locker identifier. For enhanced security, the Seed can be generated from the locker identifier associated or otherwise scrambled with a random string generated at the time of generating the access code. The Salt is a random string appended to the Seed and Unicode Timestamp which is input into the algorithm for enhanced security.

At step 42 the hash algorithm is performed in dependence on the inputs to generate a pseudo-random bit string (step 43). During steps 44 and 45 the algorithm converts the bit string into a code that can be interpreted by a user, for example into a 5-digit number.

The steps taken to convert the bit-string into a user-readable code are entirely implementation specific. in example illustrated in figure 4, the hash algorithm generates a 256-bit hexadecimal string (64 digits). This string is converted into a

B

number to be read by the user by first spUtting the string into 16 groups, with each group containing 4 digits. Each of these 16 groups is then summed and converted to decimal form (step 43). This value is then divided by some suitable value and the result rounded to the nearest whole number to produce a pseudorandom number (step 44).

Referring now back to figure 3, the server flags the locker as taken and generates a response message to be returned to the user, for example, aiso by SMS, The response specifies the access code, the locker number and the time of availability.

The time of availability can match the requested time from the user. Afternatively, if that time is not avaUsble a request can be formuiated offering a different time of avaUabity, The time of availabUity can be specified by specifying a start time and an end time, Alternativ&y, a specific opening period can be defined (for example, the access code can be utilised to open the locker at a certain time of day plus or minus ten minutes). A further alternative is to provide the locker avaUability with immediate effect and expiry at a certain time of day, It is possible to request a code at a time of day for opening a locker, and then to issue a subsequent request for a time of day to open the locker at a later occasion to access to items which have been placed in the locker at the first opening time of day.

The most appropriate time of day arrangement depends on the particular context of the locker usage.

Steps Si to 53 are carried out between the user device and the server. The subsequent method steps are carried out at the locker, ,At the appropriate time of day, a user approaches the locker identified by the locker number that he has received in the response and enters the access code (54). The processor 28 recognises the current time of day from the timer 30 and recaUs the locker identifier (and random string if utilised) from the memory 26. It utilises these parameters to generate a local code using the same algorithm that was generated at the server.

Thus, for the same locker and the same time of day the local code should match the access code, The processor carries out a comparison of the local code with the access code at step S6. If the codes match, the processor 28 controls the locking mechanism 21 to release it into the unlocked condition. If the codes do not match, the locking mechanism remains locked, and the user may be offered a subsequent attempt. After a certain number of attempts, the locker may remain permanently locked against that access code.

In Figure 1. the request is shown as being supplied directly from the user devIce 10 to the server 2 to diagrammatic purposes. In fact, it is possible for the user device 10 to send the text message to a text company with its own server. The text company can authenticate the text as being from a legitimate registered user device, and once authenticated pass the request to the server 2.

An alternative mechanism for receiving the access code would be to call a customer care centre who could activate a processor and cause an access code to be generated based on an available locker, Although the algorithm which generates the access code at the server and the local code at the locker is the same algorithm, at the server, the inputs to the algorithm include a time component as a data component which is not connected to a current time of day but to a time of availability. Thus, an earlier later time can be entered, or a period between an earlier and a later time can be utillsed, In contrast, the locker can only utlilse the current time of day as generated by the timer 30 for generating the local code for comparison purposes.

In figure 4, the algorithm shown is an exemplary overview of the basic steps for generating a user-readable access code and does not necessarily include all the steps that would be used in practice, for example extra steps to ensure cryptographic integrIty may also be included.

S

A specific applicatIon example will now be considered. A customer wishes to secure personal belongings at a venue before attending a performance, but has not pre-booked a locker. The sequence of steps Is given below for this example: 1. Customer goes to locker area. Using instructions displayed on signs In the locker area, the customer texts a code to a specified number at a text company.

2. The code Is received by the text company and Is passed on to a micropayment company 3. Once authenticated,it is then passed on to server 2 where it serves as a request to release for use one locker from the locker bank 16.

4. The server then marks a specific locker as used and generates a specific access code (UN), which will lock and unlock the specified locker, and Is sent to the text company.

5. The text company sends a premium text to the customer containing the locker number, together with the specific LIN and instructions for use.

6, Upon receipt of these numbers, the customer is charged by premium text to their phone bill.

7. The Customer enters the code into the correct locker which carries out the process explained above and, assuming a match of codes, then unlocks.

8. The Customer puts his belongings in the locker and re-enters the code to lock.

9. Customer re-enters the code to unlock any time until the end of the period which has been defined In the parameters. At the defined imeout, the customer loses his ability to operate the lock, which remains shut. That is.

the local code generated by the locker at the current time of day no longer creates a match with the time of day parameters in the access code generated by the server.

The system can be configured in multiple ways and the best configuration typically depends on optimizing between customer benefits on the one hand and operator benefits on the other. a,

The above example is tailored to an event of known duration (such as a concert) where customers' arrival and departure times are connected to the timing of the event, rather than occufflng randomly throughout the day. In this case, a uniform "time-out" approach is feasible and cost-effective for the operator, because staff need to be present only during the time-out period. Staff cost represent the largest operating cost for locker facilities and streamlining of the rental process is a key benefit to the operators.

The system can also be tailored to locker rental for fixed periods, with Individual down-times for each locker and can also be used to offer pre-booking and pre-payment functionality.

Claims

CLAIM& 1, A method of controfling access to a locker comprishig: detecflng user input of an access code at the locker, the access code based on a Ume of day for permitted access: at the locker generating a loca code from the time of day provided by a timer, and a unique locker string associated with that locker; comparing the local code with the access code input by the user and r&easing the locker for access by the user if there is a match.
2. A method according to claim, wherein the time is located at the locker.
3. A method according to claim 1 or 2, wherein the local code is generated by an algorithm taking as input the unique locker string and the time of day provided by the timer.
4. A method according to claim 3, wher&n the unique locker string comprises a locker identifier incorporating a randomly generated string.
5. A locker comprising: a locking mechanism having a locked condition in which the locker is inaccessible and an unlock condition in which the locker is accessible; a controller connected to control the locking mechanism; a memory holding a unique ocker string; and a user input means for receiving an access code? wherein the processor is configured to carry cut the step of the method of any preceding claim.
6. A Mocker management server having: a network interface for communicating wRh a user device to receive a user request for a locker access code, the user request defining a time of day for access; and a processor configured to generate an access code responshie to the user request, the access code based on the unique ocker string and the time of day at which the locker is available, and to formuate a response message to the user including a ocker identifier, the access code and the time of day for permitted access. 1 0