GB2372126A - Secure access system for goods delivery - Google Patents

Abstract

An access system has a central server which generates an access code for a lock restricting access to a target site, and communicates the access code to a recipient to enable remote access to the site, e.g. for the purpose of goods delivery and collection. In response to a request for an access code, the request including a lock identifier, the server validates the request based on authentication information provided in the request (which can be a requester identifier, or a postal address of the lock), and, if the request is valid, generates an access code based on seed information for the identified lock. The lock validates the entered access code based on a defined algorithm in dependence on stored seed information in the lock, and unlocks in response to successful validation. Single use codes, multiple use codes, or codes that are valid for a limited period, can be used. The systems allows a flexible goods distribution system to be provided.

Description

ACCESS SYSTEM This invention relates to an access system for affording access to a building or container or for the secure receipt of delivery goods or documents without necessarily requiring the presence of a person at a delivery site.

In recent times there has been a marked increase in the direct delivery of goods to either residential or commercial premises following ordering of the goods by telephone, mail or over the Internet. Such delivery is extremely convenient for the end customer, but it is often difficult to time the delivery of the ordered goods with the required presence of the recipient and customers are naturally wary of delivery occurring during their absence given the possibility of theft, etc.

It is also often required to afford access to a building to a person for a limited time or for a specific purpose, for example to deliver goods, collect an item, read a meter or service an appliance.

Historically, the most basic conventional system is to entrust a key to the person who requires access. This may be undesirable for various reasons, for example the key may be copied before it is returned and is neither practical nor desirable when ordering goods remotely.

The problem of the key being copied may be alleviated by providing a changeable combination lock, electronic or mechanical, but this requires a combination and requires the user to remember and communicate the combination and subsequently change it. This is not convenient when ordering remotely and when the user is not present at the target site to change the combination after use.

Systems have been proposed using electronic locks whose codes can be changed remotely, either by means of a wired or wireless link. These can solve most of the above problems. However, they suffer from the drawback of requiring a communication link adding to operating and installation cost and complexity.

The invention aims to provide a system by which access to a target site, whether an entire building or simply a delivery receptacle, can be afforded remotely.

According to a first aspect of the present invention there is provided an access system comprising: at at least one target site: a lock for restricting access to a target site, the lock comprising: input means for receiving an access code; means for validating a received access code based on a defined algorithm in dependence on stored seed information; a locking mechanism arranged to unlock in response to successful validation; and an identifier of the lock; at a server site; means for storing identifiers of a plurality of locks; means for storing location and/or validation information for each lock; means for storing seed information for each lock; means for receiving a request from a remote site for an access code for a lock, the request including lock information for use in identifying the lock and authentication information for use in validating the request; means for identifying the lock based on the received lock information; means for validating the request based on the received authentication information; means for looking up the seed information for the identified lock; means for generating an access code for the lock based on the seed information and the defined algorithm for the lock; means for communicating the access code to a recipient.

The invention extends, independently, in other aspects to a lock for use in such a system, a server for use in such a system, software or a computer program or computer program product containing code executable on a server for use in the method, a method of affording access, a server-side method of generating an access code, an access code carrier, a database storing lock identifiers and seeds. Further aspects and preferred features are set out in the claims. Preferred features of any aspect may be applied to any other aspect, unless otherwise expressly stated.

This system allows an access code to be communicated to a recipient without requiring direct communication between the lock and server. The provision of an identifier for each lock and a server storing identifiers of a plurality of locks simplifies access to a large number of locks, which may be at disparate physical or geographical locations.

The defined algorithm is preferably substantially the same for each lock but the seed information varies between the locks; this simplifies the server-side apparatus.

However, the algorithms may also vary between locks, in which case the server may store details of the algorithm as well as the seed information for each lock. It will be appreciated that variations in the algorithm between locks, for example, certain coefficients used will normally be relatively minor and may be accommodated by simply storing the variable coefficients or one or more identifiers of a number of possible alternative algorithm features rather than storing the full details of the algorithm. Such details may be considered to be part of the seed information.

The means for validating a received access code may comprise means for generating a sequence of valid access codes and means for comparing a received access code to a generated access code. This has the advantage that substantially the same algorithm may be employed in the server and lock. However, the possibility that the lock may run a"reverse"algorithm which validates codes without first generating a list of valid codes is not excluded.

In certain embodiments, the recipient of the access code may be the requester of the access code but this is not necessarily the case. For example the user associated with the lock may request that an access code be delivered to another person or organisation. An organisation who is authorised may request that an access code be delivered to a specific service operative. Such a step of validating the request may allow flexibility without compromising security. In some cases, the step of validating the request may comprise validating the identity of the requester. The authentication information may be at least partially embedded in the method of requesting the code; for example if a request is received by telephone or by an SMS message, the number of the caller may be checked with a database of registered authorised requesters.

Alternatively or in addition, an identification number or password may be requested optionally together with a specific user identifier.

Preferably the server stores a list of authorised requesters for each lock. This may include requesters who are authorised to obtain multiple access codes, optionally at specified intervals, for example regular service, utility or delivery companies and requesters who are authorised to obtain a single access code, for example for a onetime delivery. It may be desirable to store a list of requestors who are authorised to obtain multiple single access codes, that is to say a number of separate codes, each of which is only valid for a single use. This may enable, for example, a delivery company to obtain unimpeded access over a period of time, but that access can readily be revoked by halting the supply of new single use codes and, in addition, the issuance of the codes can be traced. In addition, one or more users, typically limited to the owner and a few particularly trusted users may be able to obtain a code which is valid for multiple accesses. This enables repeated access without requiring new codes to be issued each time, which is more convenient, but does not have the possibility of easily preventing access. The multiple use codes may be set to expire after a number of uses or after a length of time, typically a relatively long time period. In addition to or as an alternative to identifying the requester, validation information, for example a password or PIN number for a user may be requested. This may be requested in a case where a user requests an access code either directly to be sent to the user or to be sent to a third party.

The identifier of the lock is preferably human-readable, for example a number or alphabetic or alphanumeric sequence but may additionally, or alternatively, be encoded in machine readable form. Having a human-readable identifier may increase flexibility in obtaining access codes. A most preferred format is a numeric only identifier; this can be readily communicated by a variety of means, including by dialling on a conventional telephone keypad. In certain cases, the identifier of the lock may be another identifier of the location of the lock, for example a postal address of the premises at which the lock is located or a telephone number of the premises.

A most preferred arrangement, however, is for each lock to be assigned a unique (preferably globally unique) serial number. Preferably each lock has a globally unique seed and preferably the identifier or serial number does not reversibly encode the seed within the lock; this enhances security as it means that the seed cannot be determined from the identifier without access to the database stored on the server relating identifiers to seeds.

In a most preferred arrangement, the server is arranged to store the name and address of the user associated with the lock and preferably stores the postal or zip code. This enables a request for delivery including the address of an intended recipient to be communicated to the server, for example by a delivery agent, and used by the server as lock information to identify the lock without requiring additional information. Optionally, additional information such as the lock identifier may be communicated and a check for mutual consistency may be made to validate a request.

It is noted that, whilst an address and other information may desirably be stored, in many preferred implementations, only an identifier (such as a numerical identifier associated with the lock, for example printed on the fascia) may be communicated.

The access code may be communicated in human-readable or machine-readable form. A preferred form is human readable (such as alphanumeric, alphabetic or numeric), preferably numeric as this can simply be entered by means of a numeric keypad. Thus, preferably, the lock has a numeric keypad, optionally with a few additional function keys (but not a complete alphabetic keypad) for entry of an access code. Additionally or alternatively, the lock may include other means for non-manual entry of a code, for example a magnetic stripe reader, bar code reader or smart card reader, an infra-red port, for example for communication with an IrDa port of a mobile or hand held device, an electronic serial or parallel interface, a wireless radio frequency, for example Bluetooth interface, or other suitable interface for communication with a nearby or physically connected device.

Preferably, both the lock and the server include a clock (which term is intended to encompass a low frequency clock such as a calendar). This enables access codes to be used which have time-limited validity. The server may, however, simply request a date of validity from the requester. In a most preferred arrangement, the lock has at least two timebases, one relatively short and one relatively long, for example one operating in minutes and another operating in days or even weeks or years. The two (or more) timebases need not be independent and one will normally be obtained by dividing the clock used for the other. This facilitates provision of both short validity access codes, for example by using a minute timebase, and long validity access codes without requiring large numbers to be used to encode long periods of validity.

Preferably the lock is arranged so that a plurality of access codes may be valid at any one time. Preferably at least some access codes have limited validity, for example where a clock is included the codes expire after a certain time. If a clock is not included, a maximum number of codes may be valid at any one time, for example, the lock may be designed to have a maximum number of valid codes and for"old" codes to be deleted when a new code is added to the list. The maximum number of valid codes at any one time may be varied depending on the application but is limited so that the probability of a random code, or an attempt to guess a code, being successful, is relatively small. This probability can be reduced by increasing the length or"base"of the code. If non numeric symbols are included the number of possibile codes increases rapidly as the number of symbols increases-a 6 digit code has 106 possible codes and if 500 codes may be valid at any one time then the possibility of a code at random being correct is 0. 05% whereas if 26 letters and 10 digits are provided and 500 codes may be valid at any time, the probability of a

random code being correct is approximately 0. 00002%. The number of digits/symbols and the length of the code can thus be selected to give any desired degree of security against random or brute-force guessing of the code.

In a most preferred arrangement, at least certain codes are designated one time only access codes (single access codes) and expire after they have been used to open the lock, or a short time afterwards. Preferably the lock includes a memory for storing a list of codes which are valid and/or codes which have been used and/or expired. In conjunction with the means for generating codes, the provision of a memory enables limited access codes to be used. In a preferred implementation the lock is implemented using a microprocessor running software.

The server preferably includes means for storing access codes issued for each lock. This enables new single-access codes to be generated for each requester. Most preferably issued codes are stored together with an identifier of the requester of the code and/or the recipient of the code and preferably also information identifying at least one of the time at which the code was issued and/or valid and the nature of the request. This may enhance security by enabling issuance of codes to be traced.

Although the lock may in principle be used to secure any area, for example a porch, garage or outbuilding or a main door to a building, one implementation provides the lock on a discrete delivery box. In a further aspect, the invention provides a box having a lock for restricting access to the box, the lock comprising: input means for receiving an access code; means for validating a received access code based on a defined algorithm in dependence on stored seed information; a locking mechanism arranged to unlock in response to successful validation; the box further comprising an identifier of the lock for communication to a remote server arranged to supply access codes for the lock.

The box may be portable and may be provided with means for securing the box in place. Preferably the box may be arranged so that access to remove the box is only possible when the box is open, although a separate padlock or chain may be used to secure the box. The box is preferably self-contained, having a battery or other source of power and requiring no external wired (or wireless) communication link with a remote server.

The box may be a key safe. Thus the device may be used to control access to a building indirectly. An advantage of a key safe is that a code may be required for a user to access the keysafe initially to retrieve the key and a new code after use, to replace the key. The time of request for each code, preferably having a relatively short validity, may be recorded to record the time the user both leaves and enters the building (whereas with direct access, the user may not be required to obtain a code to leave, so exit time cannot easily be ascertained).

In a preferred implementation, codes having a relatively short validity are issued, preferably less than one hour, preferably less than half an hour, more preferably less than 15 minutes and in some cases 5 minutes or even less. Such a code must be requested by a user at (or very close to) the site of the lock and this provides a convenient way to track the user. For example, if the user is a delivery agent or a servicing agent, visiting several properties in sequence, the time at which codes are requested can be correlated to the position of a lock, to give a measure of position of the requestor. Estimated arrival at subsequent locks can be calculated based on this and knowledge of the requestor's timetable.

In a further aspect, the invention provides a method of tracking the position of a user, the method comprising: receiving a request from a user for an access code for a lock having an identifier, the request communicating the identifier; validating the identity of the user; looking up information containing the location of the lock and seed information for the lock; storing a measure of the time of the request; generating an access code for the lock based on the seed information; storing information identifying the user based on the validated identity of the user, the location of the lock based on the lock identifier, and the measure of time; communicating an access code to the user based on the seed information for the lock.

The method may further comprise notifying another user of the position of the user, or of an access request. The method may inlcude tracking the positions of several users and may include storing or graphically displaying indicators of position or progress in accordance with a schedule for the users, for example on a map. The request will normally be received by means of a mobile communications device, for example a mobile telephone or the like.

This aspect may be used in conjunction with other features but is preferably provided in conjunction with a readable coded identifier of a lock and receipt of a request for an access code over a wireless network such as a mobile telecommunications network.

Whilst preferably the access code is only valid for a short time, as mentioned above, allowing the time at which the user can be assumed to be at the lock to be pinpointed more accurately, this need not necessarily be so.

Having a time dependent access code, particularly a short time dependent access code requires a clock in the lock and some form of time synchronisation between the lock and the server generating the access codes. A quartz crystal clock can normally provide sufficient accuracy so that it should remain accurately synchronised for many months or even years. To tolerate drifts in synchronisation, the access code may have a validity window which is larger than the actual validity period desired and may extend either side of the desired validity period. For example, if the desired validity period is 5 minutes from the time of issue of a code, the actual validity period may run from 5 minutes before the time of issue (as measured by the server issuing the code) to 10 minutes after the time of issue, thus giving a 5 minute tolerance. If the clocks are initially synchronised and the clock in the lock drifts by 1 second a month (which is achievable with quartz clocks (0. 4ppm accuracy) then they will remain synchronised within this 5 minute window for 25 years. Alternatively, both clocks may receive synchronisation from an external source, such as the VLF time signal broadcast from Rugby in the UK or from a GPS clock. As a further alternative, the lock may provide an output of its internal time, either in plain form as a clock or in coded form, for example encoded in an identification number and this may be included in the request to the server for an access code which will generate a code based on the time indicated by the lock.

The lock may further comprise means for updating access data in the memory following the receipt of keyed data. The access data that is stored may include information related to keyed data which is acceptable or unacceptable, acceptable keyed data that has been received previously by the lock, a history of received keyed data, as well as information related to identifiers present on individual keyed data which represent products that have been delivered, keyed data generator details, delivery person details and information relating to the time of receipt of keyed data and the times at which the access data comparing means has allowed the lock to unlock to allow access to the delivery box.

The lock may be arranged to be powered by a stand-alone battery.

The lock may be on a box and may be arranged such that it is removably attached, in a lockable manner, on or near to the building to which the ordered goods are to be delivered. The box may also be arranged so that it is thermally insulated to safely receive frozen or heated goods.

The lock may further be arranged such that it carries a further identifying code on its interior for reading by a delivery person once access has been authorised. For example, an identifying bar code that is readily scanned may be provided.

The present invention has advantages over the prior art in that it provides a stand-alone lock arrangement which does not require on-line communication equipment to communicate with a base station in order to enable access by a delivery person. Also, no wiring is required to supply power to the lock. Furthermore, the system can provide for explicit or implicit confirmation of delivery of goods, as well as enabling the provision of a history of goods delivered and a history of access times and failed access times to assist in security investigations and the provision of marketing and customer purchase information.

One example of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1 to 3 are schematic block diagrams showing the operation of systems embodying the invention; and Figure 4 is a schematic block diagram showing the main components of a lock employed in an embodiment of the invention.

Figure 1 is a schematic block diagram of a system employing the lock of figure 1. In this system a retailer 20 receives an order from a customer 19 who provides information sufficient to provide identity information for the relevant lock. The retailer 20 can then either of their own accord generate an access code and produce appropriate keyed data in a manner as described below, or can refer to a third party.

In either case a database 21 then generates the appropriate data. The appropriate ordered goods and keyed data can then be provided to the delivery operator 22 for the retailer 20 and goods provided to the site by the delivery operator 22, access being gained by keyed data containing the appropriate components. Once the goods have been delivered the box may contain an identifier which can be read by the deliverer for their own records and/or to provide later proof of delivery. The processing unit 15 in the lock 4 of the site can then store data relating to the keyed data input (and optionally the goods and retailer and deliverer), so that either future access to the box by that keyed data can be denied, or future records relating to the delivery can be accessed or both.

There are a number of approaches that can be employed generating the keyed data for use to gain access to the lock. In general, the keyed data should only enable access during a given time frame or range of dates. Furthermore, it should be sufficiently complex that it is unlikely to enable access to more than one lock of a similar type. In addition to this, it may be of benefit to provide it with additional encoded information that is specific to the manner in which it is generated or the delivery company or retailer to which it has been provided.

The precise algorithm used is not critical but the considerations behind selection of an algorithm will be discussed.

Generation of an access code by the server and validation of that access code by the lock without requiring communication between server and lock: This can be achieved if the two parts to the system: the server software that is able to generate access codes and the lock that accepts or rejects them are running the same algorithm.

The basic concept requires that the lock must have a microprocessor with an updateable memory and preferably a means for measuring time elapsed. The microprocessor runs the algorithm (see below), Two key data i) a cipher key and ii) a standard unit of time are defined and entered into the memory when the lock is set up. The means for measuring time elapsed is also synchronised with the means for measuring time elapsed running on the server when the lock is set up.

Generation of an access code by the server: An access code for a particular lock can be generated using the software running on the server by entering the following data: 1. Lock identifier-this allows i) the cipher key and ii) the standard unit of time for the lock to be ascertained 2. Start date and time of the code-this is translated into a number corresponding to the number of standard units of time (see above) elapsed since since time zero the "time parameter" 3. Duration of the code (can be 1-30 (or any predetermined maximum) standard units of time).

Thus the following key parameters can be deduced and input into the algorithm to give an access code that will be valid on the specified lock starting from the start date/time selected for the duration selected.

1. Cipher key 2. Time parameter 3. Duration parameter Validation of that access code by the lock To ascertain whether an access code is valid the lock must compare the code entered with a list of access codes, the"Valid Code List", that are valid at the point in time that the access code is keyed in. The Valid Code List is generated and updated by the lock by running the algorithm.

Lock Code Generation The lock is running the same algorithm as the server. As described above the three key parameters are: 1. Cipher key- (Constant for the lock in question) 2. Time parameter 3. Duration parameter Let us assume that the standard unit of time is set to be exactly one day. Every new day the time parameter corresponding to the current time increases by one. By running the algorithm with the cipher key (stored in its memory) and the time parameter corresponding to today as constants and varying the duration parameter from 1-30, the lock will generate 30 new codes. The first code must be valid for 1 day from today, the second for two days, the third for three days, etc until the thirtieth code which is valid for thirty days from that day. These 30 new codes must be added to the Valid Code List in memory. The Valid Code List will also contain all the codes that were generated yesterday except the code that was valid for only one day.

As this is defined as being valid for only one day it is discarded from the list today.

All the codes generated the day before yesterday except the codes which were defined as being valid for only one day and two days will be in the valid code list and so on back to the one code generated 30 days ago that is valid for 30 days.

Lock Code Validation In order to validate the code that has been entered, all the lock must do is now simply check it against the 1 + 2 +... + 29 + 30 = 0.5 x 30 x (1 + 30) = 465 codes in the Valid Code List which are potentially valid for the current day. (This sum arises from the fact that there is one code still in date from the codes generated 30 days ago, two codes still in date from the codes generated 29 days ago etc. ). In this basic case, if the code entered matches one of the codes stored in the Valid Code List then the lock will open. Example algorithm To generate 30 seemingly random codes as each unit of time passes, the processor will use the parameters-the cipher key, time parameter and duration and blend them in a way such that the result seems random, but in fact is entirely reproducible given these parameters.

One example recipe for blending the parameters to produce a seemingly random 6 digit number. Write each of the parameters as a 6 digit number (by padding with zeros if necessary). Arrange the parameters in the order above, and then take the 1st digit from the first, 2nd digit from the 2nd, 3rd digit from the 3rd, 4th from the 1st, 5th from the 2nd, 6th from the third. Add the nth digit of time parameter to the nth digit of the constructed number, and then multiply the resulting 6 digit number by 4,527, 532 and take the 1st 6 digits of the result in the order 3,5, 2,1, 6,4. Both the lock and server software can be pre-programmed with this recipe. (Note that it is the hidden cipher key that makes this process produce different numbers on different locks. ) Note that the time elapsed may eventually cycle round back to zero due to hardware limitations. This should be a sufficiently large enough cycle period that it has no effect on a human time scale.

The above example algorithm is chosen for ease of understanding but it has limitations in that it may not provide an optimum spread of codes. Any suitable algorithm may be used and it will be appreciated that an algorithm which is not exactly the same as a known algorithm offers greater security. As an example of a slightly more sophisticated algorithm, data may be encoded using the information to be encoded as the seed to a pseudo-random number generator. Many such algorithms are known but a further example using the Oxford University NAG library functions. (Ref www. nag. co. uk) will now be explained.

The following web page gives details of their random number generating algorithms. http ://www. nag. co. uk/numeric/cl/manual/html/g05 % 5FcIO6. html These are attached as Appendix 1 to the specification.

In the present application, one possibility is to combine all relevant parameters such

as validity date/time, numerical flag indicating type of validity (e. g. 1= single use, 9=multiple use), lock number or lock number seeds to form one number, most easily done simply by concatenating the numbers from left to right so they form one number.

The resulting number is used as a"seed"in the nag-random-init-repeatable () function. Then, calling the nagrandomcontinuousuniform () function produces a random number between 0 and 1 drawn from the uniform distribution. Taking the first 6 decimal places of the output produces a 6 digit seemingly random lock code which cannot easily be reverse decoded. In such a case, the lock must operate a similar "forward"algorithm to generate candidate codes and compare them to received codes.

This offers greater security. However, a reversible algorithm may be used if desired.

Additional features Single use codes: The lock has a memory for codes which have been tapped into it and that have opened the lock before. This allows the lock to perform an additional check on a code that matches one of the codes stored in the Valid Code List to see if it has already been used to open the lock, and reject it if that is the case.

Multiple Valid Code Lists: For greater versatility, the lock is capable of running multiple (preferably at least 2, preferably at least 3, sometimes 5 or more, preferably no more than 10, preferably no more than 9 so that one code prefix may be used for control codes, with 8 being a particularly convenient number) independent Valid Code Lists, each generated using a different cipher key. The lock has multiple independent cipher keys stored in its memory and the server also stores the multiple cipher keys associated with each lock.

These cipher keys are numbered 1-n. When an access code is generated by the server using one of the cipher keys, an additional number (1-n) is added to the code which identifies which cipher key the access code was generated using. This allows the lock to know which of the multiple Valid Code Lists to compare the access code to.

Other key features can be altered for each of the Valid Code Lists to give greater versatility. For example the standard unit of time can be different for each and whether a code will work only once or many times.

This means that for any lock one can generate some codes that last for many days or weeks and that are multiple use (suitable for use as a PIN by the lock owner), some codes that are valid once only, and are valid for a couple of days (suitable for printing below the address on a parcel) and some that are valid once only and only for a matter of minutes after they have been generated (suitable for communicating to a delivery man via IVR, WAP or SMS who has used a mobile phone to request an access code when he has arrived at the lock).

The server may record for each lock which codes have been issued on which channel.

The lock may be configured so that entry of a new code on a channel (code list) invalidates previously issued codes on that list, for example if access in a particular order is desirable.

Figures 2 and 3 show alternative approaches to the delivery system, in which components corresponding to those described above are numbered identically. In the system of figure 3 a consumer 19 places an order with a retailer 20 and at the time of placing the order gives the retailer 20 an appropriate access code. The consumer knows the access code by either having generated the access code on a dedicated system or by accessing a remote code generating server 21. The access may be via the Internet or a dedicated link, and could even be a telephone-based system. Once the details have been provided to the retailer 20 a delivery person 22 can deliver to the delivery site and gain access to the lock 4 by entering the appropriate access code.

Figure 3 shows an alternative system in which a consumer 19 places an order with a retailer 20. The retailer 20 instructs a delivery person 22, who, upon arrival at the lock 4 requests an access code from a remote server 21. It will be noted that this is independently of the consumer and whilst the example given here is in response to a consumer request, anyone wishing to gain access could in principle request a code. Normally a handheld or (otherwise portable) mobile communications device (for example a mobile phone) may be used to request an access code from the remote server 21. The request for an access code will include a number obtained from the face of the lock 4 so that the server 21 can generate the appropriate access code for the lock by which the delivery person 22 is standing. The request for the access code could be made by any form of mobile communication device, such as a mobile phone, using for example interactive voice response, WAP, SMS or a delivery data transmitting device. For additional security, the access code requesting device may have a unique number that is provided to the server 21, for example the mobile phone number, using caller ID technology to identify the requestor, and the delivery person 22 may also be required to insert an additional pin code to ensure that they are authorised to use the communication device or voiceprint recognition may be used.

The access code transmitted to the person by thelock is preferably valid for only a short period, for example 5 minutes and preferably is single use. In addition, the location of the lock, assumed to be close to that of the person, may be recorded together with the timing of the request to provide a track of the person. It may normally be assumed that once an access code has been requested the delivery item has been delivered or at least that access has been granted within a short time thereafter, particularly if the access code is time-limited to a few minutes, so the server 21 may optionally send a confirmation transmission to the consumer, via an E-mail or an SMS text message, for example, so that the consumer can be aware that a delivery has been (or is just being) made or access has been granted.

Referring now to Figure 4, a suitable lock will now be described. An unassembled lock 4 suitable for use in the invention has a facia plate 10 which has a relatively standard manually operated handle 11 and standard manual lock 12 attached thereto. The facia 10 is connected, when attached to a door to which access is to be given, to a core locking assembly 13, so that the handle 11 can open the lock in conjunction with appropriate operation of the manual lock 12 and a standard key or upon appropriate activation of the locking assembly 13 by the components described below.

The door to which the lock is connected may be the door of a dedicated delivery box, a garage, a house, a shed, etc.

The facia plate 10 also has a keypad 14 into which data can be input in use.

Data is received by the keypad and then transmitted to a processing unit 15 which is powered by an independent battery unit 16 contained within the lock 4 and which consists of readily replaceable batteries. The processing unit 15 is, in turn, connected to the locking assembly 13 and can instruct it to unlock as and when it is appropriate.

In use, the lock 4 receives data from a deliverer via the keypad. The data is transmitted to the processing unit 15 which compares the received data with data stored in its memory and a reference clock and determines whether or not the locking mechanism 13 is to be actuated either allowing or denying access to the deliverer. The processing mechanism can store additional information other than that involved in straight forward identification. As discussed above, it can store data from the keyed data relating to the type of items delivered, the time and date of the delivery, the person making the delivery, the identity of the keyed data creator, etc. The processing unit 15 then has the ability to enable access of this stored data from either the day-today user of the box or an appropriately authorised third party, so that such information can be used for security purposes, for marketing information, etc.

It will be appreciated that the system of the present invention could also be used to enable a user to allow access to a property by a repair man, or other service provider, so that it may be services rather than goods that are delivered.

The embodiment therefore provides an arrangement in which secure access to delivery site can be provided without the delivery site requiring complex communication systems and/or an external power supply.

g05 - Random Number Generators nag-random-initjrepeatable (g05cbc) 1. Purpose

nag-random-initjrepeatable (g05cbc) sets the seed used by the basic generator in the gO5 Chapter to a repeatable initial value.

2. Specification #include < nag. h > #include < naggO5. h > void nag~random~init~repeatable (Integer seed) 3. Description

This function sets the internal seed used by the basic generator nag-random-continuous-uniform (gO5cac) to a value no calculated from the parameter seed: no = 2 seed + 1.

It then generates the value nl and discards it, i. e., the first available value is .

This function will yield different subsequent sequences of random numbers if called with different values of seed, but the sequences will be repeatable in different runs of the calling program. It should be noted that there is no guarantee of statistical properties between sequences, only within sequences.

4. Parameters seed Input: a number from which the new seed is to be calculated.

5. Error Indications and Warnings None.

6. Further Comments None.

7. See Also

nag-random-continuous-uniform (g05cac) nag-random-init-nonrepeatable (g05ccc) 8. Example The example program prints the first five pseudo-random real numbers from a uniform distribution between 0 and 1, generated by nag-random-continuous-uniform (g05cac) after initialisation by nag-random-init-repeatable.

8.1. Program Text /* nag~random~init~repeatable (g05cbc) Example Program * * Copyright 1990 Numerical Algorithms Group.

*

* Mark 1, 1990.

*1 #include < nag. h > #include < stdio. h > #include < nag~stdlib. h > #include < naggO5. h > main () { Integer i; Integer seed = 0 ; Vprintf ("gO5cbc Example Program Results\n") ; gOScbc (seed); for (i=1 ; i < =5; i++)

Vprintf ("% 10. 4f\n", gO5caco) ; exit (EXIT~SUCCESS) ; } 8. 2. Program Data None.

8.3. Program Results gO5cbc Example Program Results 0. 7951 0.2257 0. 3713 0.2250 0.8787

gO5-Random Number Generators g05cac nag-xandom-continuous-uniform (g05cac) 1. Purpose nag-random-continuous-uniform (g05cac) returns a pseudo-random number taken from a uniform distribution between 0 and 1.

2. Specification #include < nag. h > #include < naggO5. h > double nag-random-continuous-uniform (void) 3. Description This function returns the next pseudo-random number from the basic uniform (0, 1) generator.

The basic generator uses a multiplicative congruential algorithm

bi+l = 1313 x b, mod 259.

The integer bHJ is divided by 259 to yield a real value y, which is guaranteed to satisfy 0 < y < 1.

The value of bi is saved internally in the code. The initial value bo is set by default to 123456789 x (2 + 1), but the sequence may be re-initialized by a call to nag~random~init~repeatable (g05cbc) for a repeatable sequence, or nag~random~init~nonrepeatable (g05ccc) for a non-repeatable sequence.

4. Parameters None.

5. Error Indications and Warnings None.

6. Further Comments The period of the basic generator is 257.

Its performance has been analysed by the Spectral Test (see Knuth 1981, Section 3.3. 4), yielding the following results in the notation of Knuth. n vn Upper bound for I/n 2 3. 44 x 108 4.08 x 108 3 4.29 x 105 5.88 x 105 4 1.72 x 104 2. 32 x 104 5 1.92 x 103 3.33 x 103 6 593 939 7 198 380 8 108 197 9 67 120 The right-hand column gives an upper bound for the values of vn attainable by any multiplicative congruential generator working modulo 259.

An informal interpretation of the quantities vn is that consecutive n-tuples are statistically uncorrelated to an accuracy of 1/1/n'This is a theoretical result; in practice the degree of randomness is usually much greater than the above figures might support. More details are given in Knuth (1981), and in the references cited therein.

Note that the achievable statistical independence drops rapidly as the number of dimensions increases. This is a property of all multiplicative congruential generators and is the reason why very long periods are needed even for samples of only a few random numbers.

6.1. Accuracy Not applicable.

6.2. References Knuth D E (1981) The Art of Computer Programming (Vol 2) (2nd Edn) Addison-Wesley.

7. See Also

nag-random-init-repeatable (g05cbc) nag-randomJnit-nonrepeatable (g05ccc) 8. Example The example program prints the first five pseudo-random numbers from a uniform distribution between 0 and 1, generated by nag~random~continuous~uniform after initialisation by nag~random~init~repeatable (g05cbc).

8. 1. Program Text /* nag-random-continuous-uniform (g05cac) Example Program * * Copyright 1990 Numerical Algorithms Group.

* * Mark 1, 1990.

*1 #include < nag. h > #include < stdio. h > #include < nag~stdlib. h > #include < nagg05.h > main () { Integer i; Integer seed = 0 ; Vprintf ("g05cac Example Program Results\n") ; g05cbc (seed); for (i=1 ; i < =5; i++) Vprintf ("% 10.4f\n", g05cac ()) ; exit (EXIT~SUCCESS) ; } 8.2. Program Data None.

8.3. Program Results g05cac Example Program Results 0.7951 0. 2257 0.3713 0.2250 0.8787

Claims (25)

1. An access system comprising: at at least one target site: a lock for restricting access to a target site, the lock comprising: input means for receiving an access code; means for validating a received access code based on a defined algorithm in dependence on stored seed information; a locking mechanism arranged to unlock in response to successful validation; and an identifier of the lock; at a server site; means for storing identifiers of a plurality of locks; means for storing location and/or validation information for each lock; means for storing seed information for each lock; means for receiving a request from a remote site for an access code for a lock, the request including lock information for use in identifying the lock and authentication information for use in validating the request; means for identifying the lock based on the received lock information; means for validating the request based on the received authentication information; means for looking up the seed information for the identified lock; means for generating an access code for the lock based on the seed information and the defined algorithm; means for communicating the access code to a recipient.

2. A server for use in the system of Claim 1.

3. A server comprising: means for storing identifiers of a plurality of locks; means for storing validation and/or location information for each lock; means for storing seed information for each lock; means for receiving a request from a remote site for an access code for a lock, the request including lock information for use in identifying the lock and authentication information for use in validating the request; means for identifying the lock based on the received lock information; means for validating the request based on the received authentication information; means for looking up the seed information for the identified lock; means for generating an access code for the lock based on the seed information and the defined algorithm; means for communicating the access code to a recipient.

4. A server according to Claim 2 or 3, arranged to receive a request over at least one network, preferably the Internet and/or a telecommunications network.

5. A server according to any of Claims 2 to 4 arranged to communicate the access code to the recipient over at least one network, preferably the Internet and/or a telecommunications network.

6. A server according to any of Claims 2 to 5 including means storing a postal address for each lock.

7. A server according to any of Claims 2 to 6 including means storing the name of a user associated with the lock.

8. A server according to Claim 6 or 7 arranged to receive an indication of at least one of the name of a user associated with the lock and a postal address of the lock as said lock or authentication information and to compare the received indication with stored information.

9. A server according to any of Claims 2 to 8 including arranged to generate an access code which expires at or after a defined time.

10. A server according to any of Claims 2 to 9 arranged to generate a single use access code.

11. A server according to any of Claims 2 to 10 including means for storing a list of previously issued access codes.

12. A server according to Claim 11 including means for storing an identifier of the recipient of each issued access code.

13. A server according to any of Claims 2 to 12 having means for communicating an access code to a recipient other than the requestor of the access code.

14. A server according to any of Claims 2 to 13 having means for authenticating a requestor based at least partially on a feature of the request communicated from the requestor, preferably based on an originating telephone number, E-mail address or other unique identifier of the requestor.

15. A server according to any of Claims 2 to 14 having means for maintaining a list of authorised requestors and/or recipients of access codes.

16. A lock for use in the system of Claim 1 in combination with an identifier of the lock.

17. A lock according to Claim 16 wherein the identifier is globally unique.

18. A lock according to Claim 17 wherein the identifier corresponds to an identifier stored on a server in association with seed information for the lock but does not itself reversibly encode the seed information.

19. A lock according to any of Claims 16 to 18 wherein the identifier comprises a visible identifier printed on a portion of the lock.

20. A lock according to any of Claims 16 to 19 wherein the identifier is a machine readable identifier.

21. A box having a lock for restricting access to the box, the lock comprising: input means for receiving an access code; means for validating a received access code based on a defined algorithm in dependence on stored seed information; a locking mechanism arranged to unlock in response to successful validation; the box further comprising an identifier of the lock for communication to a remote server arranged to supply access codes for the lock.

22. A key safe comprising a container for securely retaining a key and a lock for restricting access to the key safe, the lock comprising: input means for receiving an access code; means for validating a received access code based on a defined algorithm in dependence on stored seed information; a locking mechanism arranged to unlock in response to successful validation.

23. A method of tracking the position of a user, the method comprising: receiving a request from a user for an access code for a lock having an identifier, the request communicating the identifier; validating the identity of the user; looking up information containing the location of the lock and seed information for the lock; storing a measure of the time of the request; generating an access code for the lock based on the seed information; storing information identifying the user based on the validated identity of the user, the location of the lock based on the lock identifier, and the measure of time ; communicating an access code to the user based on the seed information for the lock.

24. A method of operating a server in accordance with any of Claims 2 to 15 or 23.

25. A computer program or computer program product for a server in accordance with any of Claims 2 to 15 or 23.