WO2015159281A1

WO2015159281A1 - Code-activated lock system and methods operative in conjunction therewith

Info

Publication number: WO2015159281A1
Application number: PCT/IL2015/050384
Authority: WO
Inventors: Ilan Goldman; Boaz Harel
Original assignee: Knock N'lock Ltd.
Priority date: 2014-04-13
Filing date: 2015-04-12
Publication date: 2015-10-22
Also published as: IL232091A0; EP3132425A1; EP3132425A4

Abstract

The present disclosure provides an access-code-activated locking system for at least one asset/s comprising, for each asset, a pre-programmed apparatus which uses at least one processor to trigger imposed advancement at predefined intervals, to predetermined imposed positions in a sequence of expected access codes and a lock which unlocks and provides access to at least one asset responsive to recognition of an access code presented by an access seeker. The disclosure further provides a locking method and a computer program product.

Description

CODE-ACTIVATED LOCK SYSTEM AND METHODS OPERATIVE IN CONJUNCTION THEREWITH

TECHNOLOGICAL FIELD

The field includes locks and more specifically code-activated locks having an electronic access control system.

PRIOR ART

References considered to be relevant as background to the presently disclosed subject matter are listed below:

[1] WO14/006615

[2] help.ablecommerce.com/mergedProiects/ablecommerce7/configure/security/ encryption key.htm

[3] www. east ec.coiiL'kb/what"iS"the-difference-between-passwords -access-keys- _.ggd-actiyation-kgys

Acknowledgement of the above references herein is not to be inferred as meaning that these are in any way relevant to the patentability of the presently disclosed subject matter.

BACKGROUND

Security solutions for offices and commercial facilities, operative for locking, and for managing access and keys, rely on wired or wireless communications infrastructure e.g. computer networks and of course electricity, installed on site. But outdoor and in-transit situations are more difficult to secure against theft, damage and vandalism, e.g. due to remote locations (even if an alarm system is triggered, it can take time for help to arrive and/or cost of replacement and maintenance), harsh weather conditions, and/or limited or even zero access to an electric power grid and wired or wireless communications.

Security units used as solutions for this type of situation may transfer encrypted data by mechanical pulses to open a lock. Locks may lack conventional keys, keyholes or external parts. To open the lock, the user may enter a code using a suitable device, against a corresponding locking unit or adjacent hard surface. Alternatively Bluetooth, RF or any other suitable implementation may be employed. A fully-customizable access control system may be programmed into the lock to support offline user validation, onetime access codes, and other options.

PCT publication WO14006615 describes off-line encoding in an access control system comprising one or more locks, each comprising a receiver for receiving a first signal and a processor module for decoding same signal and for controlling operation of the lock accordingly. Portable access control unit/s are operative for delivering the first signal to one of the receiving modules when in proximity to a respective lock. A central system controller delivers at least one second signal to the control unit and the first signal is generated by the portable access control unit based on the second signal.

Generally speaking, use of keyed encryption (e.g. Advanced Encryption Standard (AES) cryptography or RSa public -key cryptography) to limit access to sensitive data or sensitive locations is well known. For example, a typical admonishment, at:

help.ablecommerce.com/mergedProjects/ablecommerce7/configure/security/encryption key.htm,

recommends: "Change your key regularly. Every 90 days is recommended. You should also change the key any time an employee with access to the key leaves your company. Always replace the key if you know or suspect it has been compromised by any means."

It is known (e.g. at http www link east-tec.com kb/what-is-the-difference- between-passwords-access-keys-and-activation-keys/) that a plurality of passwords used by a single person or entity can all be stored in a list which is then opened with a single "master password", also sometimes called an "Access Key" to the list of passwords.

The disclosures of all publications and patent documents mentioned in the specification, and of the publications and patent documents cited therein directly or indirectly.

SUMMARY OF THE INVENTION

In conventional offline locking units there is a synced counter (synchronized between centrally located SW and lock/s) that is computed and incremented e.g. as part of lock operation algorithm logic. The counter may be incremented based on the previous counter and may be a part of the code structure e.g. may be an input to code generation. Each service code may be generated based on inputs e.g. a serial number of the lock and/or a previous - e.g. the most recently computed— counter that in turn may be computed based on a previous - e.g. the most recently computed— previous counter. Each service code may be limited for use in a specific time window and/or may be used only once within a (e.g. the) time window, and/or may be randomly generated for each time window. All service codes' time windows may be uniform i.e. all service codes generated within a particular time window such as midnight till 4 AM, expire together at the end of that time window i.e. at 4 AM.

Because of performance and power consumption considerations the lock may receive a code e.g. service code or access code from the key and then compute a certain number of codes ahead (or some other parameter determining the number of codes e.g. length of the segment within a sequence of expected codes). The lock may then check if the received code matches one of a predetermined segment of expected codes including, say, 10 (or any other parameter value) computed codes. 10 (say) codes may be computed because a code might have been generated by the software but not used on the lock so the lock may look for each of an entire segment of codes within a sequence of codes which the lock may compute based on an incremented counter e.g. as described herein.

In a cluster mode several locking units may share the same counter. A code generated by the software may be very far advanced along the sequence, in comparison to the counter of a lock that was used infrequently or even not at all, to date. Therefore the infrequently used lock may not open at all due to being entirely out of sync relative to the segment of codes which the little -used lock expects in view of the more frequent usage of counterpart locking units.

Certain embodiments of the present invention seek to provide a method and system for generating a time limited access code (e.g. service code) for several offline locking units that may all be clustered at one site and/or may all be clustered functionally or administratively as the responsibility of a single administrative or maintenance person, crew or group.

References to opening or unlocking are merely exemplary in this disclosure and alternatively any "controlling operation of the lock" may be substituted including but not limited to include locking or unlocking or imparting any other functionality to a lock such as but not limited to programming the processor module of the lock in such a manner so as to affect future operation of the lock (e.g. automatically unlocking at a specific time and under specific circumstances, programming the lock or the processor module in a lock to be primed for unlocking by a defined emergency code, etc.); for example, defining a subsequent first coded signal for opening the lock, (e.g. the first coded signal to which the lock may be responsive to in a subsequent operation).

Certain embodiments seek to provide an access-code-activated locking system for at least one asset/s, the system comprising for each asset, a pre-programmed apparatus which uses at least one processor to trigger imposed advancement at predefined intervals, to predetermined imposed positions in a sequence of expected access codes wherein each of said codes, when recognized, unlocks access to the asset; and a lock which provides access to the asset responsive to recognition of an access code, which is presented by an access seeker and which falls within a currently expected segment of access codes lying along said sequence.

The present invention typically includes at least the following embodiments:

Embodiment 1 : An access-code-activated locking system for at least one asset/s, the system comprising:

for each asset, a pre-programmed apparatus which uses at least one processor to trigger imposed advancement at predefined intervals, to predetermined imposed positions in a sequence of expected access codes; and

a lock which unlocks and provides access to at least one asset responsive to recognition of an access code presented by an access seeker if said code falls within a currently expected segment of access codes lying along said sequence wherein each currently expected segment is defined relative to a current imposed position from among said predetermined imposed positions.

The at least one processor may be co-located with the lock e.g. wired thereto or may, in certain applications, be remotely located relative to the lock.

A currently expected segment may be defined in any suitable manner relative to the current imposed position in the code sequence. For example, the currently expected segment may begin at the current imposed position.

Embodiment 2. A system according to any of the preceding Embodiments wherein multiple assets are provided each having said pre-programmed apparatus thereby to define multiple pre-programmed apparatus units and wherein all of said multiple pre-programmed apparatus units are pre-programmed to simultaneously trigger periodic advancement to identical imposed positions.

Embodiment 3. A system according to any of the preceding Embodiments wherein said imposed positions are selected enough positions ahead, along said sequence, such that each imposed position is always further along than each asset's preprogrammed apparatus's currently expected position absent said imposed advancement in said expected access code sequence, notwithstanding variance between number of times assets are accessed during said intervals.

Embodiment 4. A system according to any of the preceding Embodiments wherein said imposed advancement is periodic and said predefined intervals are equal.

Embodiment 5. A system according to any of the preceding Embodiments wherein length of said predefined intervals is a system configurable parameter defined according to a system user profile.

Embodiment 6. A system according to any of the preceding Embodiments wherein identity of said imposed positions is a system configurable parameter defined according to a system user profile.

Embodiment 7. A locking method comprising:

providing a set of at least one code-operated locks; and

using a processor for advancing to respective predetermined new positions in a sequence of codes known to all locks in said set of code-operated locks, at respective predetermined times known to each lock in said set.

Embodiment 8. A method according to any of the preceding Embodiments wherein said sequence of codes known to all locks is generated by each of said locks.

Embodiment 9. A method according to any of the preceding Embodiments wherein at least one code in said sequence of codes is generated by each of said locks by applying a predetermined cryptographic procedure known to all locks, to a previous code in said sequence of codes.

Embodiment 10. A method according to any of the preceding Embodiments wherein counter generation requires less power than code generation.

Embodiment 11. A method according to any of the preceding Embodiments wherein functionality in at least one lock generates codes as a cryptographic function of at least a counter which is a cryptographic function of a previous counter defined for said sequence.

Embodiment 12. A method according to any of the preceding Embodiments wherein functionality in at least one lock generates at least one code using SHA-1 functionality.

Embodiment 13. A method according to any of the preceding Embodiments wherein functionality in at least one lock generates at least one counter using LCG functionality.

Embodiment 14. A method according to any of the preceding Embodiments wherein functionality in at least one lock generates at least one counter as a cryptographic function of at least a current index of a position defined with reference to said sequence.

Embodiment 15. A method according to any of the preceding Embodiments wherein functionality in at least one individual lock generates at least one counter as a cryptographic function of a pre-synced parameter uniquely identifying said individual lock.

Embodiment 16. A method according to any of the preceding Embodiments wherein said set of at least one code-operated lock comprises a plurality of code- operated locks.

Embodiment 17. A method according to any of the preceding Embodiments or any of the preceding Embodiments 10 and wherein the lock is operative at least once to generate a next counter from a previous counter without generating a code from the previous counter.

Embodiment 18. A system according to any of the preceding Embodiments wherein the lock comprises an off-line lock which, during normal operation, does not communicate with any remote apparatus.

Embodiment 19. A method according to any of the preceding Embodiments wherein each of said locks is pre-programmed to unlock responsive to presentation of any code within a segment of at least one codes within said sequence wherein said segment is pre-defined relative to a current one of said predetermined new positions.

Embodiment 20. A computer program product, comprising a non-transitory tangible computer readable medium having computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a locking method comprising advancing to a predetermined new position in a sequence of codes known to all locks in a set of code-operated locks, at predetermined times known to each lock in said set.

Also provided, excluding signals, is a computer program comprising computer program code means for performing any of the methods shown and described herein when said program is run on a computer; and a computer program product, comprising a typically non-transitory computer-usable or -readable medium e.g. non-transitory computer -usable or -readable storage medium, typically tangible, having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement any or all of the methods shown and described herein. It is appreciated that any or all of the computational steps shown and described herein may be computer-implemented. The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general purpose computer specially configured for the desired purpose by a computer program stored in a typically non-transitory computer readable storage medium. The term "non-transitory" is used herein to exclude transitory, propagating signals or waves, but to otherwise include any volatile or non-volatile computer memory technology suitable to the application.

Any suitable processor, display and input means may be used to process, display e.g. on a computer screen or other computer output device, store, and accept information such as information used by or generated by any of the methods and apparatus shown and described herein; the above processor, display and input means including computer programs, in accordance with some or all of the embodiments of the present invention. Any or all functionalities of the invention shown and described herein, such as but not limited to steps of flowcharts, may be performed by a conventional personal computer processor, workstation or other programmable device or computer or electronic computing device or processor, either general-purpose or specifically constructed, used for processing; a computer display screen and/or printer and/or speaker for displaying; machine-readable memory such as optical disks, CDROMs, DVDs, BluRays, magnetic-optical discs or other discs; RAMs, ROMs, EPROMs, EEPROMs, magnetic or optical or other cards, for storing, and keyboard or mouse for accepting. The term "process" as used above is intended to include any type of computation or manipulation or transformation of data represented as physical, e.g. electronic, phenomena which may occur or reside e.g. within registers and /or memories of a computer or processor. The term processor includes a single processing unit or a plurality of distributed or remote such units.

The above devices may communicate via any conventional wired or wireless digital communication means, e.g. via a wired or cellular telephone network or a computer network such as the Internet.

The apparatus of the present invention may include, according to certain embodiments of the invention, machine readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements some or all of the apparatus, methods, features and functionalities of the invention shown and described herein. Alternatively or in addition, the apparatus of the present invention may include, according to certain embodiments of the invention, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any of the teachings incorporated herein may wherever suitable operate on signals representative of physical objects or substances.

The embodiments referred to above, and other embodiments, are described in detail in the next section.

Any trademark occurring in the text or drawings is the property of its owner and occurs herein merely to explain or illustrate one example of how an embodiment of the invention may be implemented.

Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions, utilizing terms such as, "processing", "computing", "estimating", "selecting", "ranking", "grading", "calculating", "determining", "generating", "reassessing", "classifying", "generating", "producing", "stereo-matching", "registering", "detecting", "associating", "superimposing", "obtaining" or the like, refer to the action and/or processes of a computer or computing system, or processor or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories, into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices. The term "computer" should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, computing system, communication devices, processors (e.g. digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) and other electronic computing devices.

The present invention may be described, merely for clarity, in terms of terminology specific to particular programming languages, operating systems, browsers, system versions, individual products, and the like. It will be appreciated that this terminology is intended to convey general principles of operation clearly and briefly, by way of example, and is not intended to limit the scope of the invention to any particular programming language, operating system, browser, system version, or individual product.

Elements separately listed herein need not be distinct components and alternatively may be the same structure.

Any suitable input device, such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein. Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein. Any suitable processor may be employed to compute or generate information as described herein e.g. by providing one or more modules in the processor to perform functionalities described herein. Any suitable computerized data storage e.g. computer memory may be used to store information received by or generated by the systems shown and described herein. Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any other computerized components shown and described herein may communicate between themselves via a suitable computer network.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand the subject matter that is disclosed herein and to exemplify how it may be carried out in practice, embodiments will now be described, by way of non-limiting example only, with reference to the figures, in which: Fig. 1 is a simplified flowchart illustration of a method for operating an access- code-activated locking system according to certain embodiments.

Fig. 2 is a simplified flowchart illustration of a first time synchronization method according to certain embodiments.

Fig. 3 is a simplified flowchart illustration of a service code generation method according to certain embodiments.

Figs. 4-8 are simplified flowchart illustrations of locking unit cluster functionality provided according to certain embodiments; in particular Fig. 4 is a method for new cluster generation; Fig. 5 for generation of a new locking unit in a cluster; Fig. 6 for generation of a new Access Definition in a cluster; and Fig. 7 for generating a code for a cluster.

In each flowchart, the method may include some or all of the illustrated steps, suitably ordered e.g. as illustrated.

In the drawings:

LNLi - Log n' Lock Intranet

LU - Locking Unit

SC - Service Code

DB - Database

AD - Access Definition parameter

TS - Time Slice

TSP - Time Slice Point

TSI - Time Slice Index

SCI - Service Code Counter

SCG - Service Counter Group.

Computational components described and illustrated herein can be implemented in various forms, for example, as hardware circuits such as but not limited to custom VLSI circuits or gate arrays or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one tangible or intangible computer readable medium and executable by at least one processor, or any suitable combination thereof. A specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question. For example, the component may be distributed over several code sequences such as but not limited to objects, procedures, functions, routines and programs and may originate from several computer files which typically operate synergistically.

Data can be stored on one or more tangible or intangible computer readable media stored at one or more different locations, different network nodes or different storage devices at a single node or location.

It is appreciated that any computer data storage technology, including any type of storage or memory and any type of computer components and recording media that retain digital data used for computing for an interval of time, and any type of information retention technology, may be used to store the various data provided and employed herein. Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or off-line; which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use; and which is based on any suitable technologies such as semiconductor, magnetic, optical, paper and others.

DETAILED DESCRIPTION OF EMBODIMENTS

According to certain embodiments, a counter is divided or partitioned into groups (e.g. subsequences) of steps, e.g. access code positions, which may be identified by suitable indices, within a sequence of such codes may be divided or partitioned into, say, groups with e.g. 50 steps per group. Every predefined time interval (e.g. once a day) the lock is pre-programmed to increment its counter to an imposed position at the beginning of the next counter group; this is also known as "advancing" or "pushing forward" of the counter to its new imposed position.

As a result, if one lock in the cluster is used, say, 20 times a day and another lock used not at all, a 20-counter gap (say) may develop, but the next day the gap may be eliminated and initially, on that day, both locks are again synchronized to the same counter. Each day the locks may become unsynchronized again by day's end, but they start each day synchronized. Each service code may be computed using a suitable cryptographic hash function such as but not limited to SHA-1 function. One of the input parameters to SHA-1 (say) may be an AC counter. This process consumes time hence power, The AC counter may be generated using a suitable pseudorandom number generator e.g. linear congruential generator (LCG) function. One of the LCG input parameters is the previous AC counter. It is appreciated that incrementation of the AC counter using LCG (say) requires little time, hence consumes little energy. Therefore, pushing forward the AC counter from time to time (e.g. once a day) is power and time efficient. SHA-1 is one of several cryptographic hash functions ("secure hash algorithms") designed by the United States National Security Agency and is a U.S. Federal Information Processing Standard published by the United States National Institute of Standards and Technology.

Where the counter is incremented, but actual codes are not computed for some or all incrementations, time and battery consumption may be saved particularly since code computation (as opposed to counter computation) may be relatively time- consuming hence may require more power.

Codes for presentation to a lock can be distributed to access seekers by any suitable method e.g. orally by telephone, by text messages, smart phone app and so forth.

According to certain embodiments, an access-code-activated locking system is provided for securing at least one asset/s, the system comprising, for each asset, preprogrammed apparatus which triggers imposed advancement at predefined intervals, to predetermined imposed positions in a sequence of expected access codes which, when recognized, unlock access to the asset. Also, a lock provides access to the asset responsive to recognition of an access code, which is presented by an access seeker and which falls within a currently expected segment of access codes lying along said sequence.

A method according to a certain embodiment of the invention, which is a suitable method of operation for the access-code-activated locking system described above, is presented in Fig. 1. According to certain embodiments, the lock is operative at least once to generate a previous counter and then generate a next counter therefrom without generating a code from the previous counter. This is advantageous when, as is often the case, counter generation is more rapid and requires less computation resources (hence less power) than code generation.

The method of Fig. 1 may include some or all of the following steps, suitably ordered e.g. as shown: Step 10: imposed advancement each 2400 o'clock (say), to next of predetermined imposed positions in sequence of access codes to be generated at lock; typically lock (e.g. software functionality thereof) generates codes as cryptographic function (e.g. SHA-1) of counter which is a cryptographic function (e.g. LCG) of previous counter

Step 20: access seeker presents code to lock

Step 30: lock (e.g. software functionality thereof) generates a next code, typically depending on e.g. starting. From the current imposed position. Typically step 30 is performed more than once, e.g. as described below with reference to step 40, typically yielding a segment of the computer code sequence, starting from or otherwise defined relative to predetermined imposed position. Generating each next code may comprise: (a) using LCG or other cryptographic function to generate a next counter based e.g. on previous counter and/or on current index/position in code sequence and/or on serial number of lock, then (b) using SHA-1 or other cryptographic function to generate next code based inter alia on the next (i.e. current) counter.

Step 40: after computing each code in step 30, the lock checks whether the presented code equals the code just computed in step 30; if so the lock unlocks; if not revert to step 30 to compute the next code (typically unless N (parameter) codes have already been computed and none have been found equal to the presented code).

An example embodiment of the invention, using service code auto-sync methodology and based on commercially available Knock n' Lock products, is now described with reference to Figs. 2, 3; the methods shown and described may or may not employ any or all of the particular steps shown in Fig. 1. Any or all of the methods shown and described are a suitable method of operation for the access-code-activated locking system described above. Some or all of the steps illustrated may be provided for any of the methods, in any suitable order such as but not limited to the order actually shown.

A Service Code Auto-Sync function according to certain embodiments of the invention may be used in conjunction with Log n' Lock Intranet (LNLi) and Locking Unit logic and keys, as distributed by Knock n' Lock, however these devices are referred to merely by way of example. Any suitable service-code activated lock ('locking unit") and service-code providing key/s may be employed. The lock's software may comprise any suitable "service code generator" functionality which generates, typically in a predetermined fashion, a suitable sequence of service codes, each code typically being based inter alia on the previous code e.g. by hashing or applying any other suitable cryptographic function to, a previous code inter alia e.g. as described herein. The Log n' Lock Intranet may be replaced by any suitable apparatus for initializing, e.g. via cable, parameters defining the methods of operation of the lock's software which may include any or all of the methods illustrated and described herein.

The Service Code Auto-Sync function may prevent Service Codes in the Log n' Lock Intranet (e.g.) from getting out of sync from Service Codes in the Locking Unit so as to avoid situations in which a generated Service Code fails to unlock the Locking Unit and/or in which the Locking Unit needs to be re-synced before the Service Code can be used again in the Locking Unit. This functionality may for example be employed in conjunction with any suitable code-based key such as but not limited to Knock n' Lock's Personal KnocKeys (PK174) and Shared KnocKeys (MK204 and KK254).

A Service Code may be generated by providing some or all of the following several parameters to the Service Code generator: A Service Code_Counter which is unique to the specific KnocKey and Locking Unit. The Service Code_Counter typically advances in Log n' Lock Intranet (e.g.) whenever a new code is generated. In the Locking Unit on the other hand, the Service Code_Counter typically advances only when a valid code is detected. According to certain embodiments, the Locking Unit is typically offline e.g. is typically not wired to or connected wirelessly to Log n' Lock Intranet, and the Service Code_Counter on both sides is made to match, thereby to prevent out-of-sync Service Code situations in which the generated Service Code in Log n' Lock Intranet (e.g.) might be rejected by, and fail to unlock, the Locking Unit.

It is appreciated that in some security systems (e.g. in Log n' Lock Intranet), up to a limit of 10 (say) codes may be generated and not applied in the Locking Unit, but after a limited number of codes is exceeded, the Service Code becomes out of sync. An advantage of certain embodiments, is to remove the limit on the number of unused Service Codes and/or to prevent out of sync service code scenarios. According to certain embodiments, the Service Code_Counter in the Locking Unit "Auto-Rotates" or auto-advances, whenever a pre-defined time interval has elapsed. It is appreciated that in Log n' Lock Intranet (e.g.) the Service Code_Counter "Rotates-On-Demand" or advances, dependent on need for access to the locked facility or asset, e.g. whenever a Service Code is required.

According to certain embodiments, continuous time axes are "sliced" into predetermined, equal time periods or "intervals" whose starting point/s may coincide with the starting point/s of at least one predefined service code window ("Service Shift"). The above definitions and/or initial values for parameters controlling methods of operation of locks, as illustrated and described herein, are typically pre-programmed into each lock at an initial lock synchronization session. For example, if each service code is applicable only for a given time period from among predetermined time periods into which a 12 hour period (say) is divided or partitioned, such as one of the following: 8-12 o'clock, 12-4 o'clock, 4-8 o'clock; then codes may if desired for simplicity, be advanced at precisely 8 or 12 or 4 o'clock. The Time Slice is typically measured in days, or alternatively in hours, weeks, minutes, months, etc.

A Time Slice Point (TSP) is a point in a day (say) where one Time Slice ends and another begins. Time Slice Point is typically the beginning of a first "Service Shift" in a day. A suitable formula for computing the Time Slice Point (TSP) is:

TSP=n_Mmimum[(ABS(n-" First Window Start Time")) MOD "Time Window Length" == 0] where ABS is absolute value; n = 0 to 23; MOD is modulus operator; == is a logical equal operator.

A Service Counter Group (SCG) is the number of Service Code_Counters that are pre-allocated for each Time Slice, e.g. a rate of Service Code_Counters per Time Slice.

Each Time Slice typically receives a zero based index called a TSI or Time Slice Index which may be used, e.g. by Log n' Lock Intranet and a Locking Unit, to determine the Time Slice difference between the last used Service Code Group (SCG) and the current Service Code Group (SCG).

A Service Code Counter (SCI) counts the number of Service Code_Counter increments in each Time Slice. Whenever the Service Code_Counter advances to the next value, the Service Code Counter (SCI) increments. Service Counter Auto-Rotation: In the physical Locking Unit, there may be either or both of two types of Time Slice Index (TSI). One is the Locking Unit Time Slice Index (TSI) which is tied to the real-time-clock. Another is per Access Definition Time Slice Index (TSI). Whenever a Time Slice ends (e.g. at the Time Slice Point (TSP) time of the day), the Locking Unit enters an Auto-Rotation mode in which all Service Access Definitions are fetched from the internal memory and each Time Slice Index (TSI) is tested against the Locking Unit Time Slice Index (TSI). When a Time Slice Index (TSI) difference is found, the Access Definition Service Code_Counter is advanced to the current Service Code Group (SCG).

A suitable formula for computing a Time Slice Index (TSI) difference is:

Asc ^ATsi^■ SCG - SCI _{^ where} A_re/ = TSI _LU -TSI _AD

Service Counter Rotation-On-Demand: In Log n' Lock Intranet, for example, the Service Codes are requested based on user demand and therefore the Service Code_Counter rotation is done on demand, whenever a code is requested. The logic for rotating the Service Code_Counter may be the same as in "Auto-Rotation". In addition, the system level Time Slice Index (TSI) may be updated before "rotating" the Access Definition Service Code_Counter. A suitable formula for computing the Time Slice Index (TSI) difference is:

TSI_LNLi = FLOOR[(CurrentDateTime - Re / _ TSP)_days I TS ]

where FLOOR is the floor operator; CurrentDateTime is the date and time of the Service Code request, the result of the subtraction is given in days; and Ref_TSP is reference Time Slice Point (TSP) computed in Log n' Lock Intranet (e.g.) upon first Locking Unit sync, described below.

Reference is now made to Fig. 3 which illustrates a suitable Service Code Generation process. When a service code is requested, Log n' Lock Intranet (e.g.) typically performs some or all of the following operations, suitably ordered e.g. as follows or as shown in Fig. 3:

1.1.1. Compute the current Time Slice Index (TSI) e.g. as described above

1.1.2. Fetch relevant Access Definition 1.1.3. Check if there is an above-threshold Time Slice Index (TSI) difference. If so, rotate the Access Definition Service Code_Counter till current Service Code Group (SCG) is reached

1.1.4. Check if there are used Service Code Counter (SCI) in this Service Code Group (SCG). If so, increment the Service Code_Counter accordingly and save Access Definition in Database.

1.1.5. Check if code requested is for current shift or future

1.1.6. If current shift do a - e below:

a. Generate the Service Code based on current Access Definition Service Code_Counter

b. Increment Service Code_Counter and Service Code Counter (SCI) c. If SCI > SCG increment Access Definition Time Slice Index (TSI) d. Check if there are used Service Code Counter (SCI) in current Service Code Group (SCG). If so, increment Service Code_Counter accordingly

e. Save Access Definition in Database

1.1.7. If future shift do aa - cc below:

aa. Compute the next available Access Definition Service Code_Counter in the Service Code Group (SCG) that matches the requested date/time

bb. Use that Service Code_Counter to generate Service Code cc. Save Service Code generated in step bb and all Service Code parameters in "Future service Codes" table in Database

Reference is now made to Fig. 2 which illustrates a suitable First time Locking Unit sync process. When a Locking Unit is synced for the first time, Log n' Lock Intranet (e.g.) typically computes a Ref_TSP to be used from that point on both in Log n' Lock Intranet (e.g.) and in the Locking Unit, for computing the next Time Slice Point (TSP). Ref_TSP includes date and time of the last Time Slice Point (TSP). A suitable formula for computing Ref_TSP is:

[ for TSP > current hour, Re / _TSP = Yesterday' s date and time = TSP : 00 : 00

\ forTSP< curre t ho r. Re / _TSP = Current date and time = TSP : 00 : 00 According to certain embodiments, some users with a relatively high level of authorization are entitled access to a large number of protected assets, each protected, say, by single-use access code-activated locks. It may be desired to use a single key, storing a single code, to access all of these assets. However, there may be no communication between a lock in the field and a central server which might synchronize between the codes currently anticipated by various assets particularly if one asset is more frequently accessed than another.

A Locking Units Cluster function useful in conjunction with certain embodiments is now described in detail. The cluster function may be incorporated into the Log n' Lock Intranet (LNLi), or in conjunction with alternative functionality e.g. service code generation functionality. The clustering may allow grouping several Locking Units together such that they share common properties. Alternatively or in addition, the cluster function may make it possible to generate a Service Code for a key (e.g. Knock N' Lock Personal KnocKey) for all of, or a plurality of, Locking Units in a cluster, by a single request. The resulting Service Code may be used to unlock all Locking Units in the cluster.

A "cluster" may include a group of Locking Units linked together (e.g. in LNLi). A cluster may for example be similar in some ways to the LNLi Groups function. But the Locking Units in the cluster may be partially autonomous since they may share some of their properties with other Locking Units in the same cluster. The Locking Units' properties in the cluster may be either shared and personal, where shared properties are identical in all Locking Units, and personal properties include an individual Locking Unit's unique behavior and definition properties such as but not limited to Locking Unit type and Auto-Relock-Delay. Typically, shared properties include properties related to Service Code generation and handling, such as but not limited to Time Zone and Time Window Length.

As shown in Fig. 4, when creating a new cluster, LNLi may automatically generate, typically, "behind the scenes" or in background, Service Code specific properties to be shared among Locking Units in the cluster. Additionally, user- presentable properties may be shown on a screen to enable a human user to change these properties. Once a first Locking Unit's sync has been effected, all these properties are typically locked for changes. As shown in Fig. 5, when a new Locking Unit in a cluster is created, the Locking Unit inherits all the shared properties and a user may be left the option of changing personal Locking Unit properties on the screen. In addition, typically, all "Cluster Service Access Definitions" are copied to the new Locking Unit.

Any suitable method for Syncing a Cluster may be employed. A cluster may be considered "synced" when all Locking Units in the cluster are synced e.g. using a Knock n'Lock CC170 providing PC (personal computer) to Locking Unit communication for Log N'Lock programming, or other suitable communication cable. Typically, when syncing a Locking Unit in a Cluster, Cluster Service Access Definitions are updated before the actual sync is effected. To update Cluster Service Access Definitions, the synced "Cluster Service Access Definitions" may be fetched from all Locking Units and the most progressed (most advanced) Cluster Service Access Definition in terms of Time Slice Index (TSI) may be employed. The Time Slice Index (TSI) and Service Code Counter (SCI) may then be updated in all Locking Unit's "Cluster Service Access Definitions" to ensure that all the Cluster Locking Unit's "Cluster Service Access Definitions" are synced between LNLi and the physical Locking Units and between the Locking Units themselves.

Referring now to Fig. 6:

Regular and Fixed Access Definitions may be added to a single Locking Unit in a cluster or all Locking Units. When added to all Locking Units, the user can choose whether to have the same unlock code for all Locking Units in the cluster.

Service Access Definitions in a Cluster: An Access Definition can be created for a Shared KnocKey (MK204, KK204) or a Personal KnocKey (PK174). A Service Access Definition for a Shared KnocKey may for example be created as is conventional in commercially available Knock n' Lock technology.

There are two options for creating a Service Access Definition for a Knock n' Lock Personal KnocKey: Same Service Code for all (Cluster Service Access Definition); and Unique Service Code for each.

Same Service Code for all (Cluster Service Access Definition): When it is desired that the same generated Service Code be used to unlock all Locking Units in the Cluster using a single KnocKey, the user selects this option and responsively, the Access Definition may be generated for all Locking Units in the cluster and marked as a "Cluster Access Definition".

Unique Service Code for each: When it is not required to have the same generated Service Code unlock all the Locking Units in the Cluster or when the user wants to generate a Service Access Definition for only some of the Locking Units in the Cluster, a Knock n' Lock Service Access Definition may be created e.g. conventionally, and the user refrains from requesting the "Same Service Code for all" option.

An example method for generating a Service Code is now described with reference to Fig. 7. In the embodiment of Fig. 7, a service code may be generated and then "shared" with all locks (and typically keys) associated with a particular cluster.

The "generate service code" block may use any of the code generation method variations shown and described herein.

The "cluster AD" block typically asks: "is the current access definition a cluster access definition e.g. does the current AD point to a cluster?"

Any suitable scheme may be employed to define access definitions which link locks with keys. For example, Knock n'Lock products support generation of suitable access definitions.

If a Service Code is desired for a non-Cluster Service Access Definition, a suitable code may be generated. However, if a Service Code is desired for a Cluster Service Access Definition, then after generating the Service Code, the SC_Counter, Time Slice Index (TSI) and Service Code Counter (SCI) may be updated in all Locking Units in the Cluster and Service Code so generated may be shown in all Locking Units.

The embodiments shown and described herein may serve security systems in which an encrypted sequence of mechanical pulses may be used to communicate between the lock and the key. The user may enter a code, which passes straight through a solid material to the lock. The system may perform access verification offline - within the locking unit - eliminating the need for network communications. Timing intervals between pulses may contain the lock's encrypted opening code. If the lock identifies the correct code, the lock may open. The technology embedded in the lock may validate the user and/or the code. Access requirements that may be supported include but are not limited to one -time access codes (impossible to imitate the key— even by recording the code; single -use codes may be uniquely identified with the user, key and locking unit), two-code opening (locks open only after two different valid codes have been entered), time-limited access, delayed access (Configurable delays between initial transmission of code and opening of lock), and scheduling (authorization for specific users to open locking units only during scheduled intervals).

An advantage of certain embodiments is that off-line management of programmed locks, which is facilitated by certain embodiments described herein, is not merely a necessity in certain applications, it also provides better security since online communications can fail or be hacked. Also, facilities which are used to provide on-line communication may fail and terminate the on-line communication. The facilities may now need repair but paradoxically, access thereto may become impossible if access thereto is dependent upon functioning of a system which depends on the very on-line communication whose failure caused the repairperson's visit in the first place. To date, synchronization of expected codes (e.g. as per a counter) could only be provided by using on-line management.

Some or all of the embodiments shown and described herein may be advantageous in (a) providing a single time limited access code (e.g. service code) for several offline locking units; and/or (b) preventing out-of-sync problems which might otherwise occur if an administrative or maintenance person, crew or group request many codes and then, for whatever reason, fail to use same.

The embodiments shown and described herein may operate in conjunction with any suitable access control system e.g. having code-activated locks, and/or configurable user and key management software based on the code, such as but not limited to the following variations:

Variation 1 : An access control system, comprising:

one or more locks, each comprises a receiver for receiving a first signal and a processor module for decoding the first signal and for controlling operation of the lock;

one or more portable access control units for delivering said first signal to one of said receiving modules when in proximity to a respective lock; and

a central system controller for delivering to said control unit at least one second signal; said first signal being generated by said portable access control unit based on said second signal. Variation 2: A system according to Variation 1, wherein the processor module of the lock is pre-programmed for recognition of a first signal with defined attributes and operating the lock based thereon.

Variation 3: A system according to Variation 1 or 2, wherein each first signal is a one-time code and after its use the lock's processor is rendered receptive to a different first signal.

Variation 4: A system according to Variation 3, wherein the central system controller keeps track of first signals used for controlling operation of a lock and issuing a subsequent second signal for inducing the portable access control unit to output a defined first signal to which a lock is receptive.

Variation 5: A system according to any one of Variations 1 to 4, wherein each lock or a group of locks is operated by a unique first signal.

Variation 6: A system according to any one of Variations 1 to 5, wherein said portable access control unit is adapted to output a unique, lock-specific first signal, corresponding to its geographical location.

Variation 7: A system according to any one of Variations 1 to 6, wherein one or both of the first or second signals are encrypted.

Variation 8: A system according to any one of Variations 1 to 7, wherein said central system controller transmits the second signal to said portable access control unit via wired or wireless communication.

Variation 9: A system according to any one of Variations 1 to 8, wherein said portable access control unit comprises a user interface for inputting the second signal.

Variation 10: A system according to any one of Variations 1 to 9, wherein the first signal is decoded into instructions that define operational parameters of the lock processor module.

Variation 11: A system according to Variation 10, wherein the operational parameter is at least one of subsequent opening of the lock, change of operational parameters of the lock, change of functions of the lock, or a new series of access control permissions.

Variation 12: A system according to any one of Variations 1 to 11, wherein the portable access control unit is an application or a functionality of a mobile communication device. Variation 13: A system according to any one of Variations 1 to 12, wherein the portable access control unit is a mobile communication device.

Variation 14: A system according to Variation 13, wherein the communication between the mobile communication device and the central system controller is through encrypted SMS messages.

Variation 15: A system according to any one of Variations 1 to 14, wherein the first coded signal is transmitted from the portable access control unit to the electronic control module of the lock via RF communication, Bluetooth communication protocol, cellular communication, near field communication (NFC), an acoustic or mechanical signal.

Variation 16: A system according to Variation 15, wherein said signal is a series of knocks.

Variation 17: A system according to any one of Variations 1 to 16, wherein the processor module of the lock comprises an emergency code, activated by receipt of an activation code from the portable access control unit.

Variation 18: A system according to any one of Variations 1 to 17, wherein said one or more locks are on-line locks.

Variation 19: A system according to Variation 18, wherein the processor module of the lock comprises an emergency code operative once on-line communication fails to be established between the controller and the one or more locks, said emergency code being activated by receipt of an activation code from the portable access control unit.

Variation 20: A lock comprising a receiver for receiving a signal and a processor module for decoding the signal and controlling operation of the lock based thereon, the processor module storing one or more sets of lock-operating instructions functionalized by a system controller through a portable access control unit.

Variation 21: A lock according to Variation 20, wherein said lock processor module stores an emergency code, activated by receipt of an activation code from the portable access control unit.

Variation 22: A lock according to Variation 20 or 21, wherein said lock receiving module is adapted to receive a first signal from the portable access control unit via RF communication, Bluetooth communication protocol, cellular communication, near field communication (NFC), or an acoustic or mechanical signal. Variation 23: A lock according to Variation 22, wherein said signal is a series of knocks.

Variation 24: A lock according to any one of Variations 20 to 23, wherein the processor module is pre-programmed for recognition of a first signal with defined attributes and operating the lock based thereon.

Variation 25: A lock according to any one of Variations 20 to 24, wherein said processor is adapted to decode the first signal into instructions that define operational parameters of the lock processor module.

Variation 26: A lock according to any one of Variations 20 to 25, wherein said processor module and said receiver are positioned at the inner side of a door onto which the lock is installed.

Variation 27: A lock according to any one of Variations 20 to 25, being an online lock.

Variation 28: A system according to Variation 27, wherein the processor module of the lock comprises an emergency code operative once on-line communication fails to be established between the controller and the one or more locks, said emergency code being activated by receipt of an activation code from the portable access control unit.

Variation 29: A portable access control unit for use in the system of Variation 1.

Variation 30: A portable access control unit operating in an access control system comprising one or more locks and a central system control, said unit being adapted for receiving a second signal from said central system controller and outputting a first signal based on said second signal for controlling operation of the one or more locks.

Variation 31 : A portable access control unit according to Variation 30, adapted for encrypting the second signal into the first signal.

Variation 32: A portable access control unit according to Variation 30 or 31, adapted for communicating with the central system controller via wired or wireless communication.

Variation 33: A portable access control unit according to any one of Variations 30 to 32, adapted for communicating with said one or more locks via wired or wireless communication.

Variation 34: A portable access control unit according to any one of Variations 30 to 33, comprising a user interface for inputting the second signal. Variation 35: A portable access control unit according to any one of Variations 30 to 34, being an application or a functionality of a mobile communication device.

Variation 36: A portable access control unit according to Variation 35, wherein the communication between the mobile communication device and the central system controller is through encrypted SMS messages.

Variation 37: A portable access control unit according to any one of Variations 30 to 36, being adapted for transmitting said first signal as a series of knocks.

Assets which may be protected include but are not limited to containers and delivery vans, wired and wireless/cellular communications (towers or communication cabinets, and connection boxes e.g.), cable (cable TV cabinets e.g.), industrial sites, shelters, utility equipment e.g. Electricity cabinets, gas and oil reservoirs and gauges, underground control boxes, water reservoirs and gauges, and self-service stations such as automatic Teller Machines (ATMs).

Certain embodiments enjoy at least some of the following advantages: ease and low cost of installation, use and maintenance; no risk or cost of lost or stolen keys (intelligence is in the lock, rather than the key; stolen or lost key is useless without correct access codes but these can be reset at any time); no risk of identity theft; adaptable to future business needs; Resistance to vandalism (invisibility from the outside) and weather (no keyhole), locking units to reduce vandalism, fraud-proof access control which works offline without computer networks or electricity, retrofitting to existing assets e.g. doors, containers, safes, cams, vending machines; one user may access multiple sites with the same key (single key having different access codes opens different locks, greatly simplifying key management due to configurable codes and access definitions), and conversely, multiple users may access the same site without risky key duplication, Integrative with Physical Security Information Management (PSIM) systems, and separation of electronic control and mechanical device to facilitate flexible installation for many applications.

It is appreciated that terminology such as "mandatory", "required", "need" and "must" refer to implementation choices made within the context of a particular implementation or application described herewithin for clarity and are not intended to be limiting since in an alternative implantation, the same elements might be defined as not mandatory and not required or might even be eliminated altogether. It is appreciated that software components of the present invention including programs and data may, if desired, be implemented in ROM (read only memory) form including CD-ROMs, EPROMs and EEPROMs, or may be stored in any other suitable typically non-transitory computer-readable medium such as but not limited to disks of various kinds, cards of various kinds and RAMs. Components described herein as software may, alternatively, be implemented wholly or partly in hardware and/or firmware, if desired, using conventional techniques, and vice-versa. Each module or component may be centralized in a single location or distributed over several locations.

Included in the scope of the present invention, inter alia, are electromagnetic signals carrying computer-readable instructions for performing any or all of the steps or operations of any of the methods shown and described herein, in any suitable order including simultaneous performance of suitable groups of steps as appropriate; machine-readable instructions for performing any or all of the steps of any of the methods shown and described herein, in any suitable order; program storage devices readable by machine, tangibly embodying a program of instructions executable by the machine to perform any or all of the steps of any of the methods shown and described herein, in any suitable order; a computer program product comprising a computer useable medium having computer readable program code, such as executable code, having embodied therein, and/or including computer readable program code for performing, any or all of the steps of any of the methods shown and described herein, in any suitable order; any technical effects brought about by any or all of the steps of any of the methods shown and described herein, when performed in any suitable order; any suitable apparatus or device or combination of such, programmed to perform, alone or in combination, any or all of the steps of any of the methods shown and described herein, in any suitable order; electronic devices each including a processor and a cooperating input device and/or output device and operative to perform in software any steps shown and described herein; information storage devices or physical records, such as disks or hard drives, causing a computer or other device to be configured so as to carry out any or all of the steps of any of the methods shown and described herein, in any suitable order; a program pre-stored e.g. in memory or on an information network such as the Internet, before or after being downloaded, which embodies any or all of the steps of any of the methods shown and described herein, in any suitable order, and the method of uploading or downloading such, and a system including server/s and/or client/s for using such; a processor configured to perform any combination of the described steps or to execute any combination of the described modules; and hardware which performs any or all of the steps of any of the methods shown and described herein, in any suitable order, either alone or in conjunction with software. Any computer-readable or machine -readable media described herein is intended to include non-transitory computer- or machine-readable media.

Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any step described herein may be computer- implemented. The invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally include at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.

The system may if desired be implemented as a web-based system employing software, computers, routers and telecommunications equipment as appropriate.

Any suitable deployment may be employed to provide functionalities e.g. software functionalities shown and described herein. For example, a server may store certain applications, for download to clients, which are executed at the client side, the server side serving only as a storehouse. Some or all functionalities e.g. software functionalities shown and described herein may be deployed in a cloud environment. Clients e.g. mobile communication devices such as smartphones may be operatively associated with but external to the cloud.

The scope of the present invention is not limited to structures and functions specifically described herein and is also intended to include devices which have the capacity to yield a structure, or perform a function, described herein, such that even though users of the device may not use the capacity, they are if they so desire able to modify the device to obtain the structure or function.

Features of the present invention which are described in the context of separate embodiments may also be provided in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding process embodiment. Also, each system embodiment is intended to include a server-centered "view" or client centered "view", or "view" from any other node of the system, of the entire functionality of the system, computer-readable medium, apparatus, including only those functionalities performed at that server or client or node. Features may also be combined with features known in the art and particularly although not limited to those described in the Background section or in publications mentioned therein.

Conversely, features of the invention, including method steps, which are described for brevity in the context of a single embodiment or in a certain order may be provided separately or in any suitable subcombination, including with features known in the art (particularly although not limited to those described in the Background section or in publications mentioned therein) or in a different order, "e.g." is used herein in the sense of a specific example which is not intended to be limiting. Devices, apparatus or systems shown coupled in any of the drawings may in fact be integrated into a single platform in certain embodiments or may be coupled via any appropriate wired or wireless coupling such as but not limited to optical fiber, Ethernet, Wireless LAN, HomePNA, power line communication, cell phone, PDA, Blackberry GPRS, Satellite including GPS, or other mobile delivery. It is appreciated that in the description and drawings shown and described herein, functionalities described or illustrated as systems and sub-units thereof can also be provided as methods and steps therewithin, and functionalities described or illustrated as methods and steps therewithin can also be provided as systems and sub-units thereof. The scale used to illustrate various elements in the drawings is merely exemplary and/or appropriate for clarity of presentation and is not intended to be limiting.

Claims

1. An access-code-activated locking system for at least one asset, the system comprising:

2. A system according to claim 1 wherein multiple assets are provided each having said pre-programmed apparatus thereby to define multiple pre-programmed apparatus units and wherein all of said multiple pre-programmed apparatus units are preprogrammed to simultaneously trigger periodic advancement to identical imposed positions.

3. A system according to claim 1 wherein said imposed positions are selected enough positions ahead, along said sequence, such that each imposed position is always further along than each asset's pre-programmed apparatus's currently expected position absent said imposed advancement in said expected access code sequence, notwithstanding variance between number of times assets are accessed during said intervals.

4. A system according to claim 1 wherein said imposed advancement is periodic and said predefined intervals are equal.

5. A system according to claim 1 wherein length of said predefined intervals is a system configurable parameter defined according to a system user profile.

6. A system according to claim 1 wherein identity of said imposed positions is a system configurable parameter defined according to a system user profile.

7. A locking method comprising:

providing a set of at least one code-operated locks; and

8. A method according to claim 7 wherein said sequence of codes known to all locks is generated by each of said locks.

9. A method according to claim 8 wherein at least one code in said sequence of codes is generated by each of said locks by applying a predetermined cryptographic procedure known to all locks, to a previous code in said sequence of codes.

10. A method according to claim 7 wherein counter generation requires less power than code generation.

11. A method according to claim 7 wherein functionality in at least one lock generates codes as a cryptographic function of at least a counter which is a cryptographic function of a previous counter defined for said sequence.

12. A method according to claim 7 wherein functionality in at least one lock generates at least one code using SHA-1 functionality.

13. A method according to claim 7 wherein functionality in at least one lock generates at least one counter using LCG functionality.

14. A method according to claim 7 wherein functionality in at least one lock generates at least one counter as a cryptographic function of at least a current index of a position defined with reference to said sequence.

15. A method according to claim 7 wherein functionality in at least one individual lock generates at least one counter as a cryptographic function of a pre-synced parameter uniquely identifying said individual lock.

16. A method according to claim 7 wherein said set of at least one code-operated lock comprises a plurality of code-operated locks.

17. A method according to claim 7 or claim 10 and wherein the lock is operative at least once to generate a next counter from a previous counter without generating a code from the previous counter.

18. A system according to claim 1 wherein the lock comprises an off-line lock which, during normal operation, does not communicate with any remote apparatus.

19. A method according to claim 7 wherein each of said locks is pre-programmed to unlock responsive to presentation of any code within a segment of at least one codes within said sequence wherein said segment is pre-defined relative to a current one of said predetermined new positions.

20. A computer program product, comprising a non-transitory tangible computer readable medium having computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a locking method comprising advancing to a predetermined new position in a sequence of codes known to all locks in a set of code-operated locks, at predetermined times known to each lock in said set.