Systems, methods and computer program products for control of altering a locking state of a physical lock

Abstract

There is provided a technique for control of altering locking states of a physical lock. The technique comprises, by a server: receiving from a communication device authentication data of a user and, upon successful authenticating the user, using the authentication data to generate a first user-ID; generating an authorization token comprising the encrypted first user-ID; transmitting the authorization token to a physical lock using the communication device as untrusted relay that forwards the authorization token in the form of ciphertext with no capability of viewing or altering its content. The technique further comprises, by the physical lock: using a temporary wireless communication channel with the communication device to receive the authorization token and a second user-ID; verifying a matching between the decrypted first user-ID and the second user-ID; and in response to successful verifying the matching, providing one or more actions in accordance with one or more instructions comprised in the received authorization token.

Description

SYSTEMS, METHODS AND COMPUTER PROGRAM PRODUCTS FOR CONTROE OF AU TERING A EOCKING STATE OF A PHYSICAL LOCKCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] The present application claims benefit from Israeli Patent Application No.315935 filed on September 25, 2024 and incorporated hereby by reference in its entirety.TECHNICAL FIELD

[0002] The invention relates to techniques of controlling a physical lock, and more particularly, to systems, methods, and computer program products for remote control of altering the locking state of a physical lock.BACKGROUND

[0003] In recent years, the proliferation of internet-connected smartphones and other internet-connected communication devices has revolutionized various aspects of daily life, including access control for physical spaces. Traditionally, mechanical keys or specialized electronic fobs were used to unlock doors and secure compartments. However, the ubiquity of smartphones, coupled with their advanced computing capabilities and constant internet connectivity, has enabled a new paradigm in access management. Users can now leverage their smartphones to remotely unlock and secure various entry points, such as house doors, lockers, and vehicle compartments. This technology has also transformed urban mobility, allowing users to easily unlock and rent shared bicycles and scooters through smartphone applications. This technological shift offers enhanced convenience through digital authentication methods, and the ability to grant or revoke access permissions remotely, making it an attractive solution for both personal and commercial applications.

[0004] However, since smartphones and similar devices are exposed to various online threats, such as malware, hacking attempts, and data breaches, their use in access control systems introduces new security challenges. These vulnerabilities couldpotentially compromise the integrity of digital keys and access permissions, leading to unauthorized entry or theft. Therefore, the use of smartphones and similar devices poses real challenges in more secure scenarios, like controlling access to safes or to very secure location.GENERAL DESCRIPTION OF THE INVENTION

[0005] The inventors have recognized the need for a novel technique for remote control of altering the locking state of a physical safe lock and / or other locks with high security requirements. To meet the security requirements, the proposed technique uses end-to-end encryption whilst ensuring that no intermediate device has knowledge of the encryption keys.

[0006] In accordance with certain aspects of the presently disclosed subject matter, there is provided a system for control of altering a locking state of a physical lock. The system comprises a physical lock comprising: at least one processor; and at least one memory including computer program code. The at least one memory and the computer program code are configured, with the at least one processor, to cause the physical lock to at least: establish a temporary communication channel between a communication device and a communication module of the physical lock; receive from the communication device over the temporary communication channel: (a) an authorization token that comprises a first identification information of a user (user-ID) that is encrypted using a cryptographic encryption-key data associated with the physical lock, wherein the cryptographic encryption-key data is withheld from the communication device; and (b) a second user-ID associated with the user and readable by the physical lock; decrypt the first user-ID included in the authorization token using the cryptographic encryption-key data associated with the physical lock and available thereto; verify a matching between the decrypted first user-ID and the second user-ID; and in response to successful verifying the matching, provide the one or more actions in according with one or more instructions comprised in the received authorization token.

[0007] In accordance with further aspects of the presently disclosed subject matter, the system can further comprise a server comprising at least one second processor and atleast one second memory including second computer program code. The at least one second memory and the second computer program code are configured, with the at least one second processor, to cause the server to: receive from the communication device authentication data of the user and authenticate the user by the server; use the authentication data to generate the first user-ID; generate the authorization token, the generating comprises encrypting the first-user ID using the cryptographic encryptionkey data associated with the physical lock; and transmit the authorization token to the communication device.

[0008] In accordance with other aspects of the presently disclosed subject matter, there is provided a method of controlling a physical lock, the method comprising executing the following steps by the physical lock: establishing a temporary communication channel between a communication device and the physical lock; receiving from the communication device over the temporary communication channel: an authorization token that comprises a first user identification information of a user (user-ID) that is encrypted using a cryptographic encryption-key data associated with the physical lock, wherein the cryptographic encryption-key data is withheld from the communication device; and a second user-ID associated with the user. The method further comprising decrypting the first user-ID included in the authorization token using the cryptographic encryption-key data associated with the physical lock and available thereto; verifying a matching between the decrypted first user-ID and the second user-ID; and in response to successful verifying the matching, providing the one or more actions in accordance with one or more instructions comprised in the received authorization token.

[0009] In accordance with other aspects of the presently disclosed subj ect matter, there is provided a method for control of altering locking states of a plurality of physical locks.

[0010] The method comprises, by a server: receiving from a communication device authentication data of a user and a request to provide one or more actions regarding a given physical lock from the plurality of physical locks; upon successful authenticating the user, using the received authentication data to generate a first user-ID; generating an authorization token, the generating comprises encrypting the first-user ID using thecryptographic encryption-key data associated with the given physical lock; transmitting the authorization token to the given physical lock using the communication device as untrusted relay that forwards the authorization token in the form of ciphertext and has no capability of viewing or altering its content;[Oi l] The method further comprises, by the given physical lock: using a temporary communication channel with the communication device to receive the authorization token generated by the server and comprising encrypted first user-ID; using the temporary communication channel to receive a second user-ID associated with the user and readable by the physical lock; decrypting the first user-ID using the cryptographic encryption-key data associated with the given physical lock and available thereto; verifying a matching between the decrypted first user-ID and the second user-ID; and in response to successful verifying the matching, providing the one or more actions in accordance with one or more instructions comprised in the received authorization token.

[0012] In accordance with other aspects of the presently disclosed subject matter, there is provided a system for control of altering locking states of a plurality of physical locks, the system comprising a server operatively connected to the plurality of physical locks and configured to operate as detailed above.

[0013] In accordance with other aspects of the presently disclosed subject matter, there is provided a system for controlling access to a safe protected by a physical safe lock, the system comprising at least a communication device that comprises: at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured, with the at least one processor, to cause the communication device to at least: transmit to a remote server authentication data of a user for authenticating the user by the server; following the authentication of the user by the server, receive from the server an authorization token comprising first user identification information (user-ID) associated with the user in an encrypted form, encrypted using cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device; and transmit to the physical safe lock over a temporary wireless communication channel between the communication device and a wireless communication module of the physical safelock: (a) second user-ID associated with the user, stored by the communication device; and (b) the authorization token that comprises the first user-ID encrypted using the cryptographic encryption-key data associated with the physical safe lock, thereby providing to the physical safe lock over the temporary wireless communication channel information required by the physical safe lock for authenticated and authorized alteration of the locking state of the physical safe lock, thus triggering the alteration of the locking state of the physical safe lock.

[0014] The at least one memory and the computer program code can be configured, with the at least one processor, to cause the communication device to facilitate the alteration of the locking state of the physical safe lock by: transmitting first authentication information to the server for a first authentication process authenticating the user by the server, the first authentication information comprising the authentication data of a user; transmitting second authentication information to the physical safe lock for a second authentication process authenticating the user by the physical safe lock, the second authentication information comprising the second userID; and relaying to the physical safe lock authorization information generated by the server, the authorization information comprising information generated by the server in response to the transmitting of the first authentication information, and used by the physical safe lock in the second authentication process.

[0015] The at least one memory and the computer program code can be further configured, with the at least one processor, to cause the communication device to relay to the physical safe lock an at least partly encrypted authorization-token generated by the server without establishing a direct communication channel between the server and the physical safe lock, thereby establishing a communication conduit between the server and the physical safe lock, wherein a security level of the communication conduit is maintained by the server and is maintained above a predefined security level regardless of a security level of the communication device.

[0016] The system can further comprise the physical safe lock that is operable at least to: (a) decrypt the first user-ID included in the authorization token using the cryptographic encryption-key data of the physical safe lock; (b) verify a matching between the decrypted first user-ID and the second user-ID; and (c) in response toverifying the matching, and optionally subject to further criteria, physically unlocking the safe lock, thereby granting access to an interior of a safe secured by the safe lock.

[0017] The system can further comprise a server comprising at least one second processor; and at least one second memory including second computer program code. The at least one second memory and the second computer program code are configured, with the at least one second processor, to cause the server to: receive from the communication device authentication data of the user for authenticating the user by the server; authenticate an identity of the user based on the authentication data; in response to the authentication, generate the authorization token, the generating comprises encrypting the first-user ID using the cryptographic encryption-key data of the physical safe lock; and transmit the authorization token to the communication device.

[0018] In accordance with other aspects of the presently disclosed subj ect matter, there is provided a method for controlling a physical safe lock by a remote server, the method comprising executing the following steps by a communication device: transmitting to a remote server authentication data of a user for authenticating the user by the server; following the authentication of the user by the server, receiving from the server a authorization token comprising a first user identification information (userID) associated with the user in an encrypted form, encrypted using cryptographic encryption-key data of the physical safe lock that is withheld from the communication device; and transmitting to the physical safe lock over a temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock: a second user-ID associated with the user, stored by the communication device; and the authorization token that comprises the first user-ID encrypted using the cryptographic encryption-key data of the physical safe lock, thereby providing to the physical safe lock over the temporary wireless communication channel information required by the physical safe lock for authenticated and authorized alteration of the locking state of the physical safe lock, thus triggering the alteration of the locking state of the physical safe lock.

[0019] The method can further comprise performing the following steps by the safe lock: decrypting the first user-ID included in the authorization token using thecryptographic encryption-key data of the physical safe lock; verifying matching between the decrypted first user-ID and the second user-ID obtained from the communication device; and in response to verifying the matching, physically unlocking the safe lock, thereby granting access to an interior of a safe secured by the safe lock.

[0020] In accordance with other aspects of the presently disclosed subj ect matter, there is provided a method of controlling a physical lock, the method comprising executing the following steps by the physical lock: using a temporary communication channel with a communication device to receive from a user a request to provide one or more actions regarding physical lock and a reserved authorization token comprising a reserved permission object (RPO), wherein: the reserved authorization token has been, in advance, received by the communication device from a portable storage device (e.g. NFC device); the RPO comprises data usable for authentication of the user and data usable for identifying the portable storage device, wherein at least data usable for authentication of the user (authentication data) is encrypted; and neither the communication device nor the portable storage device has capability of viewing or altering the encrypted information in the reserved authorization token. The method further comprises matching between the RPO received in the reserved authorization token and cryptographic data possessed by the physical lock and informative of the RPO; and in response to successful matching, providing the one or more actions in accordance with one or more instructions comprised in the received reserved authorization token.

[0021] The physical lock can further delete the possessed cryptographic data informative of the RPO upon successful matching.

[0022] The cryptographic data possessed by the physical lock can be cryptographically derived by the physical lock from a respective RPO received during a setup process.

[0023] The RPO can be received by the physical lock from a server that, during the setup process, transmitted the RPO to the physical lock using the communication device as an untrusted relay.

[0024] The reserved authorization token can be generated by the portable storage device using encrypted authentication data, wherein, during the setup process, the encrypted authentication data can be received by the portable storage device from the server that transmitted the encrypted authentication data to the portable storage device using the communication device as an untrusted relay.

[0025] In accordance with further aspects and, optionally, in combination with above aspects of the presently disclosed subject matter, the one or more actions can be selected from: physically locking the lock, physically unlocking the lock, changing the level of security of locking, sending to the communication device a log of altering events during a certain period and generating and sending to the communication device a report informative of altering events during a certain period.

[0026] In accordance with further aspects and, optionally, in combination with above aspects of the presently disclosed subject matter, as a condition for providing the one or more actions, the one or more instructions can specify at least one of the following: validity of one or more timing parameters, matching one or more lock state parameters and matching one or more authorization parameters. Optionally, the one or more instructions comprised in the authorization token can be encrypted, wherein the physical lock can decrypt said one or more instructions prior to providing the one or more actions.BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to understand the invention and to see how it may be carried out in practice, embodiments will now be described, by way of non-limiting examples only, with reference to the accompanying drawings, in which:Figs. 1A, IB, and 1C are generalized block diagrams illustrating an environment comprising a system configured to provide control of altering the locking state of a physical lock in accordance with certain embodiments of the currently disclosed subject matter;Fig. 2 is a sequence diagram illustrating remote control of altering the locking state of a physical safe lock in accordance with certain embodiments of the currently disclosed subject matter,Figs. 3, 4A, 4B, 5A and 5B are sequence diagrams illustrating various examples of modification the method of remote control of altering the locking state of a physical safe lock in accordance with certain embodiments of the currently disclosed subject matter;Fig. 6 is a generalized flow chart illustrating operating the communication device to facilitate control of altering the locking state of a physical safe lock in accordance with certain embodiments of the currently disclosed subject matter;Fig. 7 is a generalized block diagram illustrating a communication device configured in accordance with certain embodiments of the currently disclosed subject matter;Fig. 8 is a generalized flow chart illustrating a method of operating a physical safe lock in accordance with certain embodiments of the currently disclosed subject matter; andFig. 9 is a generalized block diagram illustrating a safe lock configured in accordance with certain embodiments of the currently disclosed subject matter;

[0028] It will be appreciated that for simplicity and clarity of illustration and description, certain elements in the figures may not have been drawn to scale. This could include the exaggeration of certain element dimensions relative to others. Additionally, corresponding or analogous elements may be identified using repeated reference numerals in the figures.DETAILED DESCRIPTION OF EMBODIMENTS

[0029] In the following detailed description, numerous specific details are provided to ensure a comprehensive understanding of the invention. While these details aid in understanding, those skilled in the art will recognize that the invention can be implemented without these specific details. In addition, well-known methods, procedures, and components are not described in detail to avoid obscuring the invention. References to a method, system, or non-transitory computer readable medium should be interpreted inclusively, as including related aspects of the invention.

[0030] The terms “computer” and “processor”, should be expansively construed to cover any kind of hardware-based electronic device with data processing capabilities, including, by way of non-limiting example, the control system and processing and memory circuitries therein disclosed in the present application, Unless stated otherwise, the terms “computer”, “processor”, and “controller” may also include a combination of several modules (e.g., several central processing units, CPUs), which operate together toward a goal.

[0031] 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 non-transitory computer-readable storage medium.

[0032] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing", "establishing", "generating", “configuring”, “selecting”, “defining”, or the like, include actions and / or processes of a computer that manipulate and / or transform data into other data. That data is represented as physical quantities, e.g., such as electronic or electromagnetic quantities, and / or said data representing physical objects.

[0033] It is appreciated that certain features of the presently disclosed subject matter, which are, for the sake of clarity of description, described in the context of separate embodiments, may also be combined in a single embodiment. Conversely, various features of the presently disclosed subject matter, which are, for concision, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination. In embodiments of the presently disclosed subject matter one or more steps illustrated in the figures may be executed in a different order and / or one or more groups of steps may be executed simultaneously. The figures illustrate a general schematic of the system architecture in accordance with an embodiment of the presently disclosed subject matter. Each module in the figures can be made up of any combination of software, hardware and / or firmware that performs the functions as defined and explained herein. The modules in the figures may be centralized in one location or dispersed over more than one location.

[0034] Any reference in the specification to a method should be applied mutatis mutandis to a system capable of executing the method. Any reference in the specification to a method which can be executed by a computer should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that once executed by a computer result in the execution of the method. All the details, variations, optional features, optional steps which are discussed with respect to a system are also applicable, mutatis mutandis, to such a corresponding method (and non-transitory computer readable medium, where applicable), and vice versa.

[0035] Modem safe locks have evolved to incorporate sophisticated hybrid systems that combine physical security mechanisms with digital authentication technologies. These advanced locking solutions typically feature a robust physical component — such as a bolt, magnetic seal, or other mechanical barrier — working in tandem with a digital authorization circuitry. The digital circuitry may include keypads, biometric scanners, or wireless communication protocols that verify user credentials before engaging the physical unlocking mechanism. The synergy between mechanical engineering and digital security in these hybrid systems offers protection against both brute force attacks and electronic hacking attempts, making them increasingly prevalent in high-security applications across various industries.

[0036] The systems, methods, and computer program products disclosed below utilize communication devices (such as smartphones, laptop computers, tablets, smartwatches, personal digital assistants, etc.) to interact with and control safe locks. Even more so, the following disclosure demonstrates how novel systems, methods, and computer program product may be implemented to utilize communication devices which are put to everyday general use by unsupervised users (and therefore may be exposed to security risks, to malwares, to eavesdropping, etc.) to nevertheless enable a highly secure and robust wireless authentication and authorization process. It is noted that the same systems, methods, and computer program product may be used, mutatis mutandis, also to control altering of locking states of other types of physical locks (e.g., door locks, car locks, vehicle ignition switches).

[0037] It is also noted that in some cases, comparable systems, methods, and computer program products may be implemented using two or more communicationdevices collectively implementing the functionalities associated with communication device described therein. For example, while most of the functionalities described below as being associated with a single communication device may be implemented by a smartphone of the user, some parts of the authentication process (e.g., two factor authentication) may be implemented using another device of the user (e.g., a pager or another smartphone). Such variations are also considered part of the invention.

[0038] For the ease of description, the term “safe lock” will be used when referring to the physical lock whose locking state is altered (e.g., in order to lock or unlock it). It is nevertheless noted that whenever the term “safe lock” is used, equivalent systems, methods, and computer program product that are applicable to other types of physical locks are also considered part of the invention, mutatis mutandis

[0039] Figs. 1A, IB, and 1C are functional block diagrams illustrating environment 10 that includes a system capable of control of altering the locking state of a physical lock (referred to hereinafter as “control system”) and comprising at least one lock 300 operatively connectable to server 100 with the help of at least one communication device 200. Communication device 200 may communicate with server 100 via any suitable communication network 940 (e.g. via HTTPS communication channel 910). Each lock 300 secures a physical asset (e.g. like a corresponding safe 400), in accordance with embodiments of the presently disclosed invention. Communication device 200 may communicate with lock 300 via a temporal communication channel 920 (e.g. using BLE (Bluetooth Low Energy) protocol over ECDH encrypted channel).

[0040] It is noted that the term “server” used herein should be expansively construed to cover a single computer or a group of computers being in communication with one another and / or operating one or more coordinated databases (e.g., of authentication details, of authorization details, of audit logs).

[0041] Fig. 1A illustrates environment 10 in which locking state of a single lock 300 is controlled by server 100, and Fig. IB illustrates an environment 10 in which there are a plurality of locks 300 for which access by a plurality of users 90 is controlled by a single server 100. In Fig. IB some of the reference numerals include a letter that do not change the type of the referenced entity, used for referring to the different entities. For example, both safe lock 300A and safe lock 300B are safe locks 300. Each of the one or more users 90 operates their communication device 200 for altering a lockingstate of safe lock 300 (e.g., from locked to unlocked, from unlocked to locked, or between different locking settings). As aforementioned, in other implementations, other types of locks 300 may be implemented, in which case safe 400 may be replaced by another type of asset, such as a room or a building secured by a corresponding lock 300, a car or another vehicle secured by a corresponding lock, etc. While not necessarily so, optionally a single safe lock 300 may optionally be opened by more than one user 90. For example, in the illustrated example safe lock 300B may be opened either by user 90B or by user 90C. While not necessarily so, optionally a single user 90 may optionally be authorized to open more than one safe lock 300. For example, in the illustrated example user 90C may open lock 300B as well as lock 300C. The actual number of users 90, safe locks 300, and / or communication devices 200 supported by server 100 may be significantly larger, such as tens, hundreds, thousands, or more. For example, environment 10 may be a bank, and safes 400 may be safes of users 90 who are clients of the bank. In another example, locks 300 may be secured lockers of employees, each openable by the respective employee. In another example, access to locked storage chambers in a medical facility may be controlled by server 100 in order to prevent mixing up of medicine or other patient-specific materials between patients.

[0042] Fig. 2 is a sequence diagram illustrating an example of method 500 for remote controlling a physical safe lock in accordance with the presently disclosed subject matter. Referring to the examples set forth with respect to the previous drawings, implementing method 500 may involve user 90, communication device 200, server 100, and safe lock 300. An example scenario is a scenario in which the user 90 operates communication device 200 (e.g., by using a dedicated application or software on their smartphone or laptop) in order to alter a locking state of the safe lock 300 (e.g., in order to unlock that lock, to gain access to the interior of the safe secured by the safe lock, etc.). Any detail discussed with respect to environment 10 or any of the entities included in environment 10 may optionally be implemented for the corresponding entity (or entities) of method 500, and vice versa, even if not explicitly elaborated in the sake of concision of the disclosure.

[0043] In the proposed scenario, the lock may not store user-specific identification and / or authorization information in any memory module or database directlyaccessible by the lock. All such data may be stored by the server, in a remote and secure fashion. Therefore, the communication device must receive from the server an authorization token for the lock (at step 540), conditioned by initially successfully authentication by the server (at step 510).

[0044] Step 510 includes completing an authentication process of the user and / or of the communication device in front of the server. The authentication of the user (a human or an application) may be accomplished through any secure method known in the art, such as password verification, biometric identification (e.g., fingerprint, facial recognition, or retinal scan), multi-factor authentication (e.g., two-factor authentication), digital certificates, cryptographic challenge-response protocols, or token-based authentication systems. The authentication and secure information exchanges between the communication device and the server may be facilitated using any suitable key-exchange mechanisms (e.g. Elliptic Curve Ephemeral Diffie-Hellman (ECDHE), classical Diffie-Hellman (DH), RSA key exchange, post-quantum protocols like Supersingular Isogeny Diffie-Hellman (SIDH) or Kyber, Menezes-Qu- Vanstone (MQV), NIST P-256 Elliptic Curve Diffie -Hellman, Curve25519 (X25519), or Fully Hashed MQV (FHMQV), etc.) over HTTPS or other secure channel.

[0045] As part of step 510 the communication device may obtain authentication information (referred to hereinafter also as “user credentials”) from the user and transmit it to the server using any suitable communication network (e.g. Internet). Such credentials may include, for example, any one or more of the following: data informative of username, password, personal identification number (PIN), biometric data (such as fingerprints, facial recognition, voice patterns, or retinal scans), email address, physical tokens (like security keys or smart cards), responses to security questions, one-time codes generated by OTP or sent via SMS or email, digital certificates, or any combination thereof in a multi -factor authentication scheme. The user credentials provided by the user in step 510 may be used for authenticating an identity of the user by the server. Step 510 may be implemented using unidirectional (e.g., username and password) or bidirectional (e.g., two factor authentication, 2FA) authentication protocols.

[0046] Unless specifically stated otherwise, a password may exist in plaintext form or as a derivative of the input password (e.g., an encrypted value, a hash, a hash combined with a salt, etc.).

[0047] While not necessarily so, the communication device (e.g., an application running on the communication device) may carry out an independent authentication process between the user and the communication device, but this is not necessarily so. The authentication process of step 510 may optionally depend on - or be conditioned by - a successful authentication of the user by the communication device, but this is not necessarily so.

[0048] Authenticating the user by the server may include verification of the received user credentials using initial user identification information stored on the server or available thereto.

[0049] The term “user identification information (user-ID)” as used in the context of the present disclosure may pertain to a simple user identifier (e.g., a unique alphanumeric string assigned to each user within the system) or to any other type of user identification information (such as, but not limited to, full name, biometric data, or a combination of multiple identifying factors) and / or derivatives thereof that can be used to authenticate and / or distinguish individual users within the system.

[0050] It should be noted that in any case in which systems, methods, and computer program products are described in here as being initiated by the user and / or as involving authentication of the user (as a person who provides authentication information), such systems, methods, and computer program product may also be implemented, mutatis mutandis, as involving authentication of the communication device as an authenticatable and authorizable entity to trigger altering of the locking state of the safe lock. For example, if the communication device is a communication device which is passed between shift managers or active heads of department, it may be sufficient by the server to authenticate the communication device itself as a recognizable source of authority, regardless of the specific person who uses it (if at all). In such a case, the terms “user”, user credentials, “user-ID” and alike should be expansively construed to cover the communication device (mobile application) acting as a user for the purpose of authenticating and / or authorization thereof. Likewise, theseterms should be expansively construed to cover a group of users recognizable by a source of authority as a single account.

[0051] Optionally, the authentication of step 510 may conclude with (or otherwise be followed) step 512 in which the server provides to the communication device authentication confirmation data (also referred to as “authentication confirmation payload”). The authentication confirmation payload is a data structure that confirms a successful authentication event and may carry information such as the result of the authentication, session tokens, or other proof that a user or device has been authenticated. The authentication confirmation received from the server may be provided by the communication device to the safe lock (e.g., at step 560) in order to facilitate in the process of authorizing the alteration of the locking state of the lock. While not necessarily so, the authentication confirmation data may include a user identifier that may serve as the “second user identifier that is required by the lock in order to approve alteration of its locking state as further detailed with reference to steps 560 and 570.

[0052] It is noted that the steps of method 500 are illustrated using one -directional or two-directional arrow in a non-limiting fashion. For example, some processes that are illustrated using one directional arrow may optionally be implemented as a two directional process in which each entity communicates information to the other entity, possibly involving several different back-and-forth exchanges. On the other hand, processes that are illustrating using a bidirectional arrow may optionally be implemented as a simple communication of information from one entity to the other without the need of reply. For example, in authentication processes, the server may actively request additional information, provide additional information required for the authentication process, and / or issue a confirmation of success, in a bidirectional authentication process. In other implementations, authentication may be implemented using transmission of authentication information (e.g., username and password) in a unidirectional communication protocol, without confirmation being sent back if all is well.

[0053] In some implementations, the communication device (or any software running on that device for executing method 500) may follow the lead of the server in some or all of the different processes (e.g., respond to instructions for additionalinformation). In some implementations, the communication device (or any software running on that device for executing method 500) may be a trigger or a supervisor of some processes, even such that involve the server. Any combination of the two may also be implemented.

[0054] After the authentication of the user by the server at step 510 (and possibly subject to reception of an explicit request for alteration of the locking state of the lock from the user and / or from the communication device at step 520), method 500 continues with generating a first user identification information (first user-ID) associated with the user.

[0055] The first user-ID may optionally be the same as user credentials provided to the server by the user via the communication device (e.g., by entering username or any other type of authentication information), a user credentials provided to the server by the communication device, a initial user identification information stored by the server or a system accessible thereto, a user-ID generated by the server for the user for extended use, a user-ID generated by the server for the user for that session of authenticated access to the server by the user, a user-ID generated by the server for the user for the specific request (e.g. a request to alter the locking state of the lock, a request for receiving report of the altering actions during a certain period, etc.) made at step 520, and / or or any combination of the above.

[0056] It is noted that the first user-ID and second user ID may be different than user credentials provided to the server in step 510 and / or user ID stored by (or available to) the server in association with the user. For example, the user may access the server using username “Henry Dickens”, but be provided another username, “Henry222” to be used for the unlocking of the safe lock. Likewise, the server may communicate with the communication device using the username “Henry Dickens”, but generate a user one-off user ID such as “YF4gT5nUXprW2S” usable as a 1stuser-ID or a 2nduser-ID.

[0057] It is noted that the terms “first user-ID” and “second user-ID” pertain to two user-IDs that are related to the same user (“the user”), and “first” and “second” are intended to differentiate between these two pieces of data, not between any two users.

[0058] At step 530, the server further uses the 1stuser-ID to generate an authorization token by encrypting, at least, 1stuser-ID using an encryption key kept by the server and associated with the lock.

[0059] It is noted that the terms “encryption key” or “encryption key data” used in the context of the present disclosure should be expansively construed to cover any cryptographic data suitable for end-to-end protection between the server and the lock acting as end points. In case the server supports a plurality of safe locks, each lock may optionally be associated with a different encryption key.

[0060] The encryption key used in step 530 is not available either for the user or for the communication device. Optionally, the user and / or communication device can also be unaware of 1stuser-ID generated by the server and associated with the user.

[0061] The encryption key used in step 530 may be part of various types of encryption schemes, such as symmetric or asymmetric encryption schemes, depending on the security requirements of the system and on system security architecture. In symmetric encryption, a single shared key — often referred to as a Pre-Shared Key (PSK) — is used for both encryption and decryption, offering computational efficiency but presenting challenges in key distribution. Examples include Advanced Encryption Standard (AES) and Data Encryption Standard (DES). Asymmetric encryption, on the other hand, utilizes a public-private key pair, where the public key of the safe lock is kept by the server, but the private key remains secret kept by the safe lock and not by other entities of the environment. Rivest-Shamir-Adleman (RSA) and Elliptic Curve Cryptography (ECC) are common asymmetric algorithms. Additional approaches include hybrid encryption that combines both approaches, e.g., using symmetric encryption for bulk data and asymmetric encryption for key exchange. It is noted that any suitable encryption scheme may be implemented. For example, Pretty Good Privacy (PGP) combines both symmetric and asymmetric methods.

[0062] In addition to the encrypted first user-ID, the authorization token can comprise additional information such as, for example any combination of one or more of the following: a. Identification information of the safe lock, e.g., for enabling the lock to verify that the instruction is intended for the specific lock, and / or for enabling the communication device to establish a temporary wireless communication channel with the specific room (e.g., out of the plurality of the safes in a safes room). b. Time stamp.c. Validity timing parameters (e.g., the unlocking authorization is valid for 10 minutes, the unlocking authorization is valid during certain days of the week and / or during certain time of day, etc.). d. Other validity parameters (e.g., the locking authorization is valid only if certain other conditions are met). e. Authorization parameters (e.g., is this authorization single-use, limited uses authorization, or unlimited in the number of uses). f. Locking state parameters (e.g., how long can the safe lock remain in the altered state, to which locking state to switch when that time is up). g. Additional operational parameters (e.g., unlock parameters, lock parameters. h. Logging instructions (e.g., what information does the server require the safe lock to provide as a record of the action). i. Any other parameter or data relevant for controlling the state of the lock.

[0063] Any of the above additional information can be provided in encrypted form. The encryption of the above additional information can be provided separately from or together with encrypting the 1stuser-ID using the same or different encryption key(s) associated with the lock. At least part of the above additional information can be sent as one or more separate messages constitution a part of the authorization token.

[0064] It is noted that the term “authorization token” used in the context of the present disclosure should be expansively construed to cover a group of one or more messages comprising data informative of, at least, the encrypted 1stuser-ID and being sufficient to prove that the user, after further verification, is allowed to provide a certain action under one or more certain conditions. An authorization token can comprise instructions (encoded or implicitly represented) specifying certain actions and conditions under which they may be performed by the user upon successful verification.

[0065] Such actions may be altering the locking state of the safe lock (e.g. locking or unlocking the lock, switching to a more secure locking state, etc. Alternatively oradditionally, such actions can be requesting / receiving from the safe lock a report or a log informative of altering events during certain period.

[0066] Method 500 continues with step 540 in which the server provides to the communication device an authorization token, which includes data that when relayed to the safe lock can be used by the safe lock to verify that the request to alter a locking state of the safe lock is indeed authorized. While that data is being relayed by the communication device (e.g., of the user), at least part of that data is encrypted using a secure encryption key that is not available to the user or to the communication device. Such encryption is usable to verify that the encrypted data was generated by an authorized party (i.e., the server) and was not fabricated by any other entity. Furthermore, as demonstrated below, that encryption can also be used to verify other information that was provided by the user and / or by the communication device. As discussed with respect to step 530 above, the authorization token provided by the server includes at least the first user-ID in an encrypted form (encrypted using cryptographic encryption key associated with the physical safe lock, such encryption key is withheld from the communication device), but may also include additional information, e.g. such as these discussed above with respect to step 530. For example, the server may also provide an expiration timing information pertaining to any authorization or request for altering the locking state using the provided information. For example, the server may also provide information identifying the safe lock.

[0067] The server may transmit the authorization token to the communication device using various wireless communication methods. These methods may include, but are not limited to, cellular networks (e.g., 4G, 5G), Wi-Fi, Bluetooth, and satellite communication. The communication between the server and the communication device may be relayed through one or more intermediate systems, which may incorporate wireless and / or wired communication technologies, such as fiber optic networks, Ethernet, or coaxial cable systems. Furthermore, communication between the server and the communication device may optionally utilize multiple channels simultaneously or sequentially. For instance, certain information may be transmitted via SMS (Short Message Service) or cellular data communication, while other parts of the authorization token or other data provided by the server may be conducted over a Wi-Fi connection. This optional multi-channel approach may be used, for example,for optimizing data transfer based on factors such as available bandwidth, security requirements, or the nature of the information being transmitted. While not necessarily so, any communication channel between the server and the communication device may also be encrypted and / or otherwise secured.

[0068] After receiving the authorization token from the server, the communication device relays the authorization token to the safe lock (step 550).

[0069] Thus, the server transmits the authorization token to the safe lock using the communication device as an untrusted relay that is not trusted by the endpoints (the server and the safe lock), not capable of viewing or altering content and merely forwards the authorization token in the form of ciphertext.

[0070] The authorization token can be transmitted from the communication device to the safe lock via various bearers. Especially, the authorization token may be transmitted in any one or more forms of direct wireless communication, using various short-range technologies. These may include, but are not limited to, Wi-Fi Direct, Bluetooth (including Bluetooth Low Energy — BLE), Near Field Communication (NFC), infrared (IR), and ultrasonic communication. Communication between the devices may occur over a single channel or utilize multiple channels simultaneously or sequentially. While not necessarily so, a communication channel between the communication device and the safe lock may also be encrypted and / or otherwise secured.

[0071] It is noted that the communication device does not possess and has no access to the encryption key data associated with the safe lock. Accordingly, it is unable to read any information encrypted using the respective encryption key or amend the encrypted information without rendering it unusable. Therefore, such encrypted information may be used by the safe lock to ascertain that the request transmitted to it in the following steps of method 500 is valid and authorized by the server. Thus, the communication device can be used in steps 540 - 550 as the untrusted relay for delivering the authorization token from the server to the safe lock.

[0072] Steps 550 and 560 include transmitting by the communication device to the physical safe lock over a temporary wireless communication channel between the communication device and the wireless communication module of the physical safe lock:

[0073] The authorization token that includes at least the first user-ID encrypted using the cryptographic encryption-key data associated with the physical safe lock (at step 550).

[0074] Any additional information that may be required or useful by the lock, generated by the user or by the communication device. Optionally, such information may be initially sent to the server to be “signed” or encrypted by the server. For example, such additional data may include for example, reference information, status indication, communication parameters, and so on (not denoted in the diagram).

[0075] The second user-ID can be received by the communication device from the user, may be generated by the communication device in accordance with predefined rules and using the user credentials received at step 510 or may be received by the communication device from the server in authentication confirmation payload at step 512.

[0076] The second user-ID may be the same as the first user-ID (e.g., “HDickensl234” in both cases) or a different user-ID may be implemented (e.g. “HDickensl234” and “HDickensl234verification”, or “HDickensl234” and “YF4gT5nUXprW2S”), as long as the safe lock is being able to determined that the first user-ID and the second user-ID are both indicative of the same user (step 570).

[0077] While not necessarily so, some or all of the data provided by the communication device to the safe lock at step 560 may be obtained by the communication device from the user forthat specific cause, e.g., right before providing that data to the safe lock. Such data may include, for example, any one or more of the following: data informative of username, password, personal identification number (PIN), biometric data (such as fingerprints, facial recognition, voice patterns, or retinal scans), email address, physical tokens (like security keys or smart cards), responses to security questions, one-time codes sent via SMS or email, digital certificates, or any combination thereof in a multi -factor authentication scheme.

[0078] It is noted that the second user-ID may be stored by the communication device for different durations in different implementations. For example, in some embodiments the communication device may receive the credentials from the user and directly, or shortly thereafter, provide the second user-ID to the safe lock. In another example the communication device may store the second user-ID for a prolongedperiod of time such as since the registration of the user to the service. The duration during which the second user ID is stored on the communication device may optionally include shutting down of the phone, but this is not necessarily so. The second user-ID may be stored on a volatile memory module of the communication device and / or on a nonvolatile memory module of the communication device.

[0079] It is noted that the wireless communication channel between the communication device and the safe lock is temporary because it is established (and later terminated) for a specific interaction, usually involving a specific request to alter a locking state of the safe lock, and is not required after that. Furthermore, the temporary wireless communication channel may be implemented using a close-range wireless communication protocol (e.g., Bluetooth, BLE, NFC) which dictates a maximal distance between the communication device and the safe lock for communication (e.g., 50m, 10m, l-2m, <lm). Since the communication device may be used by the user also further away from the safe, that communication channel might also be terminated due to exceeding this distance.

[0080] Method 500 continues with step 570 in which the safe lock verifies the validity of the data it receives from the communication device, and upon success acts upon the content of the data.

[0081] Verification by the safe lock comprises using the received authorization token to extract 1stuser-ID using the respective key possessed by the safe lock and further matching between 2nduser-ID and 1stuser-ID. The verification is considered successful when the 1stand the 2nduser-IDs are identical or equivalent subject to predefined equivalence rules.

[0082] Upon successful verification, the safe lock may proceed according to instruction included in (or implied) into the authorization token (e.g. validity timing parameters, authorization parameters, locking state parameters, etc.). These instructions may be encrypted within the authorization token and thus withheld from the communication device.

[0083] For example, the safe lock may proceed with locking the lock, unlocking the lock, or otherwise changing an operational state of the lock (e.g., switching to a more secure locking state, either by involving a different physical level of protection and / or by involving a different level of instructions required for future unlocking of the lock).For example, the safe lock may proceed with unlocking of the safe lock, thereby granting the user access to the interior of the respective safe. In the example of Fig. 2 the verification of step 570 is depicted as depending on unilateral provision of data to the safe lock, which then use this data for the verification of the identity and permissions of the user to alter the locking state of the safe lock. It is nevertheless noted that in some implementations of the systems, methods, and computer program products disclosed in the present disclosure, the verification process may require bidirectional communication between the lock and the communication device and / or between the lock and the server. Any bidirectional security protocol may be implemented for that need.

[0084] Optionally, method 500 may continue with step 580, in which information such as reporting information, log information, etc. is sent (optionally in encrypted form) from the lock back to the server using the communication device.

[0085] It should be noted that while method 500 was discussed above with respect to a single user, a single communication device, and a single safe lock, the same process may be repeated many times, with different users, communication devices, and / or safe locks.

[0086] It is noted that the order of different steps illustrated in Fig. 2 may vary with respect to the diagram. For example, step 560 can be executed concurrently or before sequential steps 530 - 550; step 520 can be prior to step 510 and can initiate the entire process of authorization and authentication.

[0087] Altering the locking state of the physical lock in a manner detailed with reference to Fig. 2 requires communication between the server and the communication device, at least, for steps 510 - 540. There may be situations in which the communication device and the safe lock are both operational and able to establish a suitable wireless communication channel between them, but the server (which may be positioned in a remote location (possibly in another building, street, city, country, or even continent) is not non-functional, unresponsive, or otherwise unavailable (e.g., because a secure communication channel between the communication device and the server cannot be established, e.g., due to non-functional routers used for that communication). Fig. 3 illustrates certain modified embodiments of method 500 providing solutions for offline access to the lock when the user is facilitated to alterthe state of the lock with the help of mobile application in temporal absence of network communication between the server and the communication device.

[0088] For such a case, when the server is yet available, the user can request the server to generate a reserved authorization token (step 591). The reserved authorization token can be generated based on the same or on different user credentials and / or same or different key(s) associated with the safe lock. Accordingly, the reserved user-ID can be the same or different from 1stuser-ID.

[0089] Once the communication device receives from the server the reserved authorization token (comprising the reserved encrypted 1stuser-ID and possibly additional data, as discussed above), method 500 may continue with optional step 592 in which the communication device may acts as the untrusted relay and convey the reserved authorization token to a near-field wireless communication device or other portable storage device capable of storing digital data and of communicating with the communication device and / or with the safe lock.

[0090] For illustrative purposes, the following description refers to near-field devices. It should be noted that the teachings of the presently disclosed subject matter are likewise applicable to other portable storage devices capable of exchanging data with the communication device and / or with the safe lock over a physical data channel rather than a radio bearer (e.g. USB flash drives and memory cards, etc.).

[0091] Further, for illustrative purposes, the following description refers to a use case in which the reserved authentication token is utilized for emergency situations. It should be noted, however, that the teachings of the presently disclosed subject matter are likewise applicable to other scenarios requiring the capability to alter the locking state of the lock in the absence of communication with the server. Likewise, the teachings of the presently disclosed subject matter are applicable to other reserved passwords (e.g. single-use password, off-line password, etc.).

[0092] In the context of the present application, the term “near-field wireless communication device” pertains to a physical item that has a nonvolatile memory storage and a wireless communication module. For example, such devices may include Radio-Frequency Identification (RFID) tags, Near Field Communication (NFC) cards, and so on.

[0093] The near-field wireless communication device may then serve as an emergency authorization key to the safe lock, with the authorization granted to the user by the server being stored in that item, possibly being granted longer activation duration (e.g., 1 month, 1 year). In such cases, it may be expected that the near-field wireless communication device will be stored in a secure fashion. Additional security measures like further encryption may also be implemented. Such an emergency item does not need to be carried by users in their everyday life, for example, but rather stored at a secret or otherwise secure location.

[0094] Furthermore, such emergency authorization key may be protected by implementing additional requirements by the system itself (e.g., requiring entering of a separate emergency password, and not the usual user password used for the usual procedure of altering the locking state of the safe lock, requiring additional to-and- from with the safe lock, and so on; additional details are provided below, e.g., with respect to Figs. 4A and 4B).

[0095] Once the reserved authorization token was conveyed for storage in the near- field wireless communication device, the communication device may optionally delete this authorization token from any memory of the communication device (denoted step 594), e.g., as an additional security measure.

[0096] The following steps of method 500, in such case, include retrieving the reserved authorization token (e.g., the emergency authorization token) from the near- field wireless communication device to the communication device (step 596), and continuing with providing the reserved authorization token (step 550’) and additional authentication information, if necessary, (step 560’) in order to alter the locking state of the safe lock.

[0097] In some cases, it may be useful to implement some or all of the steps of steps 510 through 594 by a device other than the communication device which is used for the later steps (596 onwards). For example, the user may have switched device because of the possibly prolonged duration between the creating of the emergency near-field wireless communication device (i.e., the storing of the authorization token on that device) and the time in which altering the locking state of the safe lock without available communication with the server is enabled (e.g., several months). In another example, due to the potential sensitivity of the emergency near-field wirelesscommunication device, its creation may be implemented by a dedicated device (e.g., a dedicated computer, a dedicated smartphone) which is more secure than the communication device of the user. For example, such other device may be stored at the bank at all times, such a device may require additional authentication and approval of a supervisory authority, and so on.

[0098] In addition or as an alternative to the near-field wireless communication device discussed above with respect to optional steps 592, 594, and 596, the communication device may implement other means in order to verify the authorization token generated by the server. Such means do not necessarily require wireless communication. For example, the authorization token may be printed Quick Response (QR) codes or other visual code (e.g., High Capacity Color Barcode (HCCB) employing colored triangles, Just Another Barcode (JAB Code) utilizing multi-colored squares, Data Matrix codes offering compact data representation, Aztec codes, or MaxiCode featuring dots in a hexagonal grid arrangement), with the retrieval of step 596 executed by a camera of the communication device. Equivalent encoding of the authorization token using sound (retrievable using a microphone of the communication device) or in any other way detectable by a sensor of the communication device may also be implemented, mutatis mutandis.

[0099] Figs. 4A and 4B are a sequence diagram illustrating another example of modification of method 500 in accordance with the presently disclosed subject matter for controlling a physical safe lock in temporal absence of communication between the communication device and the server.

[0100] Optionally, the generation of the authorization token in step 530 may be preceded by provisioning to the server by the communication device additional information, which is specifically required for the use case in which a near-field wireless communication device would be used for the alteration of the locking state of the safe lock. For example, such use cases may include scenarios in which the server is not available, situations in which no communication may be established between the communication device and the server, and so on.

[0101] Optional step 5120 includes providing to the server by the user a reserved password (e.g., an emergency password, a single-use password, off-line password, etc.). While not necessarily so, the reserved password may be generated, determined,and / or selected by the user for which the near-field wireless communication device is made.

[0102] For illustrative purposes, the following description refers to an emergency password. It is noted that the teachings of the presently disclosed subject matter are applicable to other reserved passwords (e.g. single-use password, off-line password, etc.).

[0103] The emergency password may be provided after a request for generation of the near-field wireless communication device is made (e.g., using a user interface of a dedicated application running on the communication device). Additionally or alternatively, other types of authentication data may be provided by the user (e.g., a voice sample, a fingerprint of another finger, and so on) to be used in addition to - or in leu of - the emergency password, mutatis mutandis.

[0104] In optional step 5130, a unique identifier of the near-field wireless communication device is being obtained from the near-field wireless communication device and is later provided to the server (in step 140), in order to be provided to the lock later in the process. The unique identifier of the near-field wireless communication device may optionally be obtained from the near-field wireless communication device itself (in step 5130), using any near field wireless communication protocol used by the near-field wireless communication device. Inclusion of the unique identifier of the near-field wireless communication device in the information used by the lock in order to confirm alteration of its locking state may be used to make the specific near-field wireless communication device used a non- replicable recovery device (or another emergency device), whose identity can be confirmed by the safe lock even without real time communication with the server.

[0105] The information provided by the communication device to the server for use in case the locking state of the safe lock needs to be altered using the near-field wireless communication device (in step 5140) is collectively referred to as “Emergency Access data” or “EA data”. It is noted that while emergency is an important use case, the same methods, systems, and computer program products may be used also for other use cases, and not just for emergency use cases.

[0106] It should be noted that the order of different steps of method 500 may vary with respect to the diagram. For example, the communication device may obtain theunique identifier of the near-field wireless communication device (in step 5130) before, after, or at least partly concurrently with the providing of the emergency password to the server (step 5120). This is also true with respect to sub steps of each step. For example, some sub-steps of step 5120 may be executed before the execution of one or more sub-steps of step 5130, while other sub-steps of step 5120 may be executed concurrently with or after the execution of these one or more sub-steps of step 5130.

[0107] In step 5150 the server encrypts some or all of the emergency access data received from the communication device (e.g., in steps 5120 and / or 5130) in the token, together with a first user-ID of the user and provides the generated token to the communication device. It is noted that when discussing encrypting data by the server for the token, (in this step, or in any other step of the method), the server may encrypt the data itself, or data that was generated by processing of the relevant data. For example, the server may optionally include in the token hashed versions of the username, user password, reserved password, and so on. Processing data before encrypting it may be used for a wide variety of reasons, many of which are known in the art, and will therefore not be discussed in greater detail.

[0108] In step 5160, the server provides to the communication device the token, along with any additional data (either encrypted or not) that will be required by the safe lock to verify the validity of request for alteration of the locking state, even without further communication with the server. Such data may include, for example, information of the safe lock for which the token is intended. As can be seen in the example of diagrams 4A and 4B, possibly no further communication with the server is needed beyond this point.

[0109] Optionally, prior to saving the token to the near-field wireless communication device, the communication device may first provide the token to the safe lock (step 5170), which can then decrypt the token and save some or all of the emergency access data to a nonvolatile memory of the lock (step 5180). For example, the lock may store at least a hash of the reserved password and a user-ID of the user (e.g., any of the userIDs discussed above). If successful, the lock may indicate success (step 5190), indicating that the communication device may proceed with the configuration of the near-field wireless communication device. It is noted that, optionally, the server mayissue a first token to be used in steps 5170 and 5180, and a second token to be stored at the near-field wireless communication device (at step 592), e.g., if non-overlapping information is necessary in these different steps.

[0110] Method 500 may include optional step 5200, in which additional information is sent to be stored by the near-field wireless communication device. For example, in addition to the token, the communication device may further store in the near-field wireless communication device the lock info provided to the server, e.g., identifying the safe lock for which the token is intended, and possibly including additional instructions or operational parameters for the action of altering the locking state of the lock, which may be needed by the lock.

[0111] It should be noted that the optional storing of different parts of the access control information (which may include, for example, any one or more of: authentication credentials, authorization data such as permissions, roles, access levels, security protocols data, security parameters, etc.) at two different entities - the safe lock (e.g., in step 5170) and the near-field wireless communication device (e.g., at step 5200) may be implemented in order to increase the security of the process, and / or in order to maintain separation of access control information into multiple entities even in the absence of the server.

[0112] Continuing to Fig. 4B, the diagram illustrates steps which can be used to alter the locking state of the safe lock using the near-field wireless communication device, e.g., when reliable communication with the server is unavailable. As mentioned above, these steps may be implemented by a different communication device than the one used for the steps discussed with respect to Fig. 4A, for various reasons (several of which are discussed above).

[0113] The procedure of using the near-field wireless communication device to alter the locking state of the lock may start with retrieving of the EA data from the near- field wireless communication device to the communication device (step 5220). The retrieved data includes the token (which is at least partly — and possibly fully — encrypted) but may also include additional data that can be used by the communication device.

[0114] For example, in some cases a single near-field wireless communication device may authorize the user to alter the locking state of multiple safe locks, in whichcase the near-field wireless communication device may provide such list to the communication device, which in turn case present it to the user (optional step 5230). The user may than indicate to the communication device a selection of a lock whose locking state should be altered (denoted step 5240). This may be facilitated by previously executing optional step 5210 of retrieving from the near-field wireless communication device the information of the lock that was optionally provided by the server (at step 5160) and stored in the near-field wireless communication device (at step 5200).

[0115] The process continues with step 5250 in which the user enters the reserved password (e.g., emergency password, single-use password, etc.), which can be different than the usual password used for the authentication of the user. In some cases (e.g., if the near-field wireless communication device can be used to control a plurality of locks, but also in some single-lock control use cases), the communication device may provide the reserved password to the lock (step 5260). The safe lock in such case, upon verifying the authenticity of the reserved password, may respond (denoted step 5270) with a matching emergency access ID that was previously stored in the lock (in step 5180). The communication device may then use the information provided by the lock to retrieve data relevant for the specific lock (step 5280). It is noted that the emergency access ID may optionally be identical to the first user-ID that is stored in the unreachable server, or may optionally otherwise operate in leu of that first user-ID. Storing the first user-ID in the lock instead of in the near-field wireless communication device may be used, for example, in order to improve a security of the process, e.g., as discussed below in greater detail.

[0116] Involving the lock in the process of collecting the data that will be used in the request of step 5290 may be used, for example, in order to ascertain that the safe lock will execute the later steps of method 500 when it is aware of the fact that the altering of the locking state of the safe lock is done in emergency mode (or in any other suitable out of the ordinary mode, depending on the implementation). This may be used, for example, to alert the safe lock to switch to a more secure protocol.

[0117] In step 5290, the communication device issues a request to the lock for altering a locking state of the lock, including at least one user-ID of the lock encrypted by the server and at least one other user-ID of the user. It is noted that in such cases,the first user-ID may be the aforementioned emergency access ID, which is associated with the near-field wireless communication device which in turn is associated with the user. The information provided in step 5290 may be used by the safe lock to verify that all conditions for altering the locking state of the lock are met, and it can therefore proceed to unlock the safe lock, e.g., granting the user access to the interior of the respective safe. The request of step 5290 may be accompanied by the unique identifier of the near-field wireless communication device, which may be used by the safe lock for retrieving or identifying the necessary information (e.g., if recovery cards of multiple users were issued), for confirming the validity of the request, or for any other use.

[0118] After successful altering of the locking state of the safe lock (or, in some optional cases also if the altering of the locking state was unsuccessful), some or all of the different entities (e.g., the safe lock, the near-field wireless communication device, the communication device, and possibly eventually the server once communication is restored) may communicate with one another in order to indicate a result of the process, and possibly for removing authorizations and / or data used in the process. For example, if the near-field wireless communication device was configured to only be used in a single unlocking of the safe lock, any relevant tokens, keys, data, etc. may be removed from the near-field wireless communication device and / or from the lock (denoted step 5300).

[0119] In the embodiments illustrated with reference to Figs. 2, 3A, 3B, 4A, and 4B, the server and the lock may establish, at least temporarily, a direct and secure connection. This connection can be utilized by the server to configure security settings on the lock (e.g., encryption keys, validity parameters, locking state parameters, equivalence rules, etc.).

[0120] Referring to method 500 as a whole, it is noted that various ways for implementing method 500 for altering a locking state of one or more locks were discussed above. It should be noted that method 500 may be implemented multiple times to enable one or more users to alter a locking state of a specific locks (and / or of a plurality of locks) multiple times, using one or more communication device. It is noted that in different instances, method 500 may be implemented to alter locking states of such a safe lock a plurality of times, in different ways. For example, a lockwhich was unlocked and locked by the user using communication between the server and the communication device, may also be unlocked using the same communication device and a near-field wireless communication device at a different time (e.g., in time of emergency).

[0121] Figs. 5A and 5B are generalized sequence diagrams illustrating an example of method for remote control of altering the locking state of a physical safe lock when the direct connection between the server and the lock is impossible (e.g. the lock is located in an isolated bunker with no external communication).

[0122] As illustrated, the method comprises 4 steps: permission setup by an administrator (5400), setup of NFC device by the user (5500), setup of the lock (5600) by the user and the step of offline altering the locking state of the lock (5700).

[0123] It should be noted that although steps 5400, 5500, and 5600 are independent of one another and may be performed separately - both in terms of timing and by different users - they must be executed in the following sequence: 5400 55005600. Optionally, steps 5500 and 5600 can be provided by the user in the same or in different flows when the communication device has network communication with the server.

[0124] During permission setup 5400, the administrator may use a web frontend application to define parameters of a given Emergency Offline Access Event (EOA) characterized, at least, by user, lock, start and end day; and transfers (5401) the EOA definition to the server. The server receives EOA definition and generates (5402) Emergency Permit Object (EPO) informative, at least, of user-ID, log number, start and end dates, and saves the EPO in the database. At this stage the EPO object misses, at least, a user password and card ID and, thus, is currently inactive.

[0125] During the setup (5500) of NFC device (referred to hereinafter for ease of description also as RFID card) for a given lock, the user signs in the mobile application and provides (5501) the communication device with password for EOA setup. Once the password is entered, the communication device encrypts it, thus giving rise to the encrypted password.

[0126] The RFID card, when located in the range of the communication device, provides (5502) its ID (RFID-ID) to the communication device. Further, thecommunication device contacts (5503) the server via a communication network (e.g. HTTPS channel) to provide thereto user-ID, log number, RFID-ID and the encrypted password. The server completes EPO with the received encrypted password and RFID- ID, thereby transforming the inactive EPO object into the active EPO. Further, the server uses the active EPO to generate (5504) NFC payload for the given EOA and sends the generated NFC payload to the communication device to write therein. The NFC payload comprises encrypted user-ID and password and represents a single EOA.

[0127] It is noted that the password and, optionally, other data (e.g. user-ID, RFID- ID) are contained in the active EPO in the encrypted form.

[0128] When the RFID card is in the range of the communication device, the communication device transfers (5505) the received NFC payload to the RFID card to be saved therein.

[0129] During the setup (5600) of the lock, the user (or the administrator) signs in and requests the server to provide offline access payloads for emergency permission for a given lock. The communication device sends (5601) to the server (e.g. via HTTPS channel) the log number and user-ID used during the NFC setup; and, in response, the server fetches (5602) all active EPO objects associated with the given lock and sends the EOA payload(s) (i.e. the encrypted data to be received by a lock during setup for later performing EOA) to the communication device (e.g. via HTTPS channel). The communication device transmits (5603) EOA payload(s) to the lock (e.g. using BLE protocol over a secure channel).

[0130] For a given received EOA payload, the lock processes the received data and generates (5604) an EOA_DEF object being cryptographic representation of active EPO object for the given EOA. EOA DEF can be characterized by an identifier (e.g. hash identifier) representing encryption (e.g. hash) of user-ID, RFID-ID and the encrypted password.

[0131] It is noted that the teachings detailed with reference to Figs. 5a and 5b are applicable, in a similar manner, to reserved permit objects other than active EPOs (e.g. single use permission, off-line permission, etc.) comprising cryptographic data usable for user’s authentication (e.g. user-ID and password). Likewise, the cryptographic object possessed by the physical lock may represent, in a similar manner, other than EPO reserved permit objects.

[0132] It is noted that the setup process described above allows single offline permission per a user / lock combination.

[0133] Optionally, the setup process described above can be modified to enable multiple NFC payloads per card and / or bulk operation for setting up multiple NFC pay loads in one operation (e.g. multiple locks for a user on a single RFID card and / or multiple users’ permission on a single card). Likewise, the bulk operation can be provided to set up multiple users’ permissions and NFCs for a single lock.

[0134] Optionally, the parameters of EOA event can specify additional conditions for the validity of permission (e.g. the day of the week and / or time of day, etc.).

[0135] In absence of network access, upon authorization by the communication device, the user will be presented with login screen “Offline Access” and will be requested to scan (5701) the RFID card and to provide the emergency password. If the provided password matches the one stored by RFID card during the setup (RFID card will provide (5702) the communication device with NFC payload dictionary stored during RFID setup 5500, each NFC payload comprising the encrypted user-ID and password. The user selects (5703) from the provided list of locks, a lock to be open and sends (5704) to the selected lock a request for emergency unlock. The lock receives the request (e.g. using BLE protocol over a secure channel) comprising data informative of EPO object (e.g. card ID of the respected RFID card and encrypted NFC payload) and uses the saved EOA_DEF object to authenticate (5705) the request.

[0136] For the purposes of the present embodiment, one or more messages comprising data informative of reserved permission object (including the encrypted NFC payload and the identifier of the RFID card from which the payload is obtained) is referred to hereinafter as a “reserved authorization token”. Further to data informative of reserved permission object, the reserved authorization token can comprise instructions (encoded or implicitly represented) specifying certain actions (e.g. altering the locking state, requesting a report, etc.) and conditions (e.g. validity timing parameters, locking state parameters, authorization parameters, etc.) under which they may be performed by the user upon successful verification.

[0137] Upon successful authentication of the reserved authorization token, the lock can perform EA unlock and delete (5707) the used key-value pair. Likewise, the communication device may delete (5706) the used NFC payload. Authentication isconsidered successful when the cryptographic representation of the reserved permission object (e.g. EOA_DEF object) possessed by the lock and the reserved permission object comprised in the reserved authentication token are identical or equivalent subject to predefined equivalence rules.

[0138] The communication device further creates and persists an event report for this unlock and sends it to the server when it regains network access.

[0139] Alternatively or additionally, the setup steps 5400, 5500 and 5600 can be used to enable requesting / receiving by the communication device from the safe lock a report or a log informative of events of altering a state of the lock (referred to hereinafter as altering events) events during certain period and later sending the report to the server. Optionally, the log and / or the report can be encrypted by the safe lock prior to sending to the communication device.

[0140] Fig. 6 is a generalized flow chart illustrating a operating the communication device to facilitate control of altering a locking state of a physical safe lock , in accordance with the presently disclosed subject matter. Referring to the examples set forth with respect to the previous drawings, method 600 may optionally be executed by communication device 200.

[0141] It is noted that optionally, method 600 may include executing any combination of any one or more of the steps taken by the communication device of method 500. It is noted that any combination of one or more steps discussed with respect to method 500 may be applicable, mutatis mutandis, to method 600, and vice versa.

[0142] Step 610 of method 600 includes transmitting to a remote server authentication data of a user for authenticating the user by the server. Referring to the examples set forth with respect to the previous drawings, the server may be server 100. Referring to the examples set forth with respect to the previous drawings, step 610 may be executed as part of step 510 of method 500. Optionally, step 610 may be preceded by obtaining at least a part of the authentication data of the user from the user, using one or more user interfaces of the communication device (e.g., as discussed above with respect to step 510). Referring to the examples set forth with respect to the drawings, the transmitting of step 610 may include transmitting the authentication data using first communication module 230. Referring to the examples set forth withrespect to the drawings, the authentication data may be obtained from the user using user interface 210, e.g., by input user interface (UI) 212, such as using a keyboard (e.g., for username, password, PIN, etc.), microphone and / or camera (e.g., for biometric recognition using audio, video, or still images), using touchscreen (e.g., for typing data or drawing patterns), and so on. Referring to the examples set forth with respect to the previous drawings, the server may be server 100.

[0143] The authentication data is usable by the server to authenticate the user. Following such authentication of the user by the server method 600 may proceed with step 620 of receiving from the server an authorization token including in an encrypted form a first user-ID associated with the user, encrypted using cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device. Referring to the examples set forth with respect to the drawings, the receiving of step 620 may be executed by first communication module 230. Optionally, the method may include storing the received token at a memory module of the communication device, such as memory module 250. Referring to the examples set forth with respect to the previous drawings, step 620 may include step 540 of method 500, or be executed as part of step 540 of method 500.

[0144] Optionally, the authorization token may further include identification information of the physical safe lock, encrypted using the cryptographic encryptionkey data associated with the physical safe lock that is withheld from the communication device. In this way, the specific safe lock may determine using the token that the request to alter its locking state is indeed intended to it (especially if the user and / or the communication device may be authorized by the server to control more than one safe lock).

[0145] Optionally, the authorization token may further include timing information limiting a duration by which information of the authorization token may be used by the physical safe lock to authorize alteration of the locking-state of the physical safe lock. For example, that time limit may be set to one minute, 10 minutes, an hour, or any other suitable duration. The time limit may be set by the server, by the user, by the bank, or by any other authorized entity of the specific system.

[0146] Method 600 continues with step 630 of transmitting to the physical safe lock over a temporary wireless communication channel between the communication deviceand a wireless communication module of the physical safe lock: (a) a second user-ID associated with the user, stored by the communication device; and (b) the authorization token that includes the first user-ID encrypted using the cryptographic encryption-key data associated with the physical safe lock. Referring to the examples set forth with respect to the drawings, step 630 may include transmitting the data of step 630 to the physical lock by second communication module 240. Referring to the examples set forth with respect to the previous drawings, the safe lock may be safe lock 300. Method 600 may also include establishing the temporary wireless communication channel with the lock (e.g., establishing a Bluetooth Low Energy — BLE — communication channel, or implementing any other short-range communication protocol supported by the safe lock). Referring to the examples set forth with respect to the previous drawings, step 630 may include steps 550 and 560 of method 500 or be executed as part of steps 550 and 560 of method 500.

[0147] The transmitting of the aforementioned data in step 630 is providing to the physical safe lock over the temporary wireless communication channel information that is required by the physical safe lock for authenticated and authorized alteration of the locking state of the physical safe lock, thus triggering the alteration of the locking state of the physical safe lock (in optional step 640).

[0148] Optionally, method 600 may include facilitating the alteration of the locking state of the physical safe lock at least by:

[0149] Transmitting first authentication information to the server for a first authentication process authenticating the user by the server, the first authentication information including the authentication data of a user (in step 610).

[0150] Transmitting second authentication information to the physical safe lock for a second authentication process authenticating the user by the physical safe lock, the second authentication information including the second user-ID (in step 630).

[0151] Relaying to the physical safe lock authorization information generated by the server, the authorization information including information generated by the server in response to the transmitting of the first authentication information, and used by the physical safe lock in the second authentication process (in step 630).

[0152] Optionally, method 600 may include relaying to the physical safe lock by the communication device an at least partly encrypted authorization-token generated by the server (in step 630) without establishing a direct communication channel between the server and the physical safe lock. Thus, method 600 may include establishing a communication conduit between the server and the physical safe lock. The security level of that communication conduit is maintained by the server (who is in charge of encrypting important data for the safe lock) and is maintained above a predefined security level regardless of the security level of the communication device. That is, even if the communication device is jeopardized (e.g., hacked), the encryption of important data by the server means that malicious parties cannot trigger unlocking the safe lock by hacking into the phone. Method 600 is designed such - unless intentionally designed otherwise, which is permitted - the communication device does not act as an authorizing agent for the alteration of the locking state of the physical safe lock, but rather only as a conduit for authorization information by another entity (namely, the server).

[0153] Referring to step 630, it is noted that optionally the transmitting of data over the temporary wireless communication channel includes communicating with the wireless communication module of the physical safe lock via an encasing of a safe (or any other secured chamber, compartment, or enclosure, e.g., as discussed above). Access to an interior of the safe is being selectively enabled by unlocking of the physical safe lock, wherein communicating with the wireless communication module of the physical safe lock via the encasing of the safe attenuates signals of the communicating by a factor of at least at least x 10. Since the safe lock may be installed in the interior of the safe (e.g., on the inner side of the safe door, or adjacent to that), the wireless communication between the safe lock and the communication device may be attenuated significantly by the material of the safe itself (essentially operating as a faraday cage). Thus, a suitable communication protocol and suitable wireless communication unit for the lock and for the communication device must be selected. It is also noted that this attenuation may be utilized in at least some embodiments of the invention in order to increase the security level of the systems and / or methods, because that attenuation may be implemented to prevent communication of parties that are not in near proximity to the safe (e.g., further away than Im, than 3m, than 10m, etc.).

[0154] Optionally, method 600 may further include executing by the communication device — prior to the establishing of the temporary wireless communication channel with the wireless communication module of the physical safe lock: (a) connecting to the internet; (b) downloading data from at least one news website and from at least one social network; and (c) receiving a plurality of advertisements from a plurality of different ad networks. In other words, in such cases it is possible to implement method 600 in a secure manner to control alteration of the locking state of the physical lock of high security safes even while using a communication device that is exposed to the hazards of the internet. Method 600 may include performing any of the steps of method 600 (e.g., any combination of one or more steps out of steps 610, 620, 630, and 640) using a communication device that was previously infected by malware, that was previously been hacked to, and / or that was otherwise jeopardized or compromised, or any communication device whose data security could not be guaranteed.

[0155] Like method 500, method 600 may also be adapted for using a near-field wireless communication device, such as when reliable communication with the server is not obtainable, or for any other reason. Optionally in method 600 the transmitting of data to the physical safe lock over the temporary wireless communication channel may be preceded by retrieving from a near-field wireless communication device previously unavailable cryptographic data originating from the authorization token. This may be implemented, for example, by incorporating step 596 to method 600, and optionally also step 592 (and possibly also 594). The transmitting of the authorization token to the physical safe lock over the temporary wireless communication channel (in step 630) may include transmitting data retrieved from the near-field wireless communication device.

[0156] Pertaining to the retrieving of data from the near-field wireless communication device, it is noted that the retrieving may optionally be executed a significant time (e.g., at least a month) after the receiving of the authorization token for the server (in step 620). The retrieving may optionally be executed a significant time (e.g., at least a month) after the cryptographic data was written to the near-field wireless communication device (e.g., in step 592).

[0157] Optionally, when adapting method 600 for use with a near-field wireless communication device, the authorization token may include a hashed version of anemergency password of the user that is different than a password of the user used for the previous steps of authentication in the system.

[0158] Pertaining to use a near-field wireless communication device as part of method 600, it is noted that method 600 may optionally include executing the following steps before the transmitting of data to the physical safe lock over the temporary wireless communication channel:

[0159] Receiving from the server, as part of the first user-ID, password data of a password associated with the user (possibly including hashed password), the password data received in an encrypted form, encrypted using the cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device.

[0160] Establishing a preliminary temporary wireless communication channel with the wireless communication module of the physical safe lock, the preliminary temporary wireless communication channel nonoverlapping temporally with the temporary wireless communication channel. For example, the preliminary temporary wireless communication channel may be used for executing steps 5170 and 5190 as part of method 600. The preliminary temporary wireless communication channel may use the same communication protocol as the temporary wireless communication channel, but this is not necessarily so.

[0161] Transmitting to the physical safe lock over the preliminary temporary wireless communication channel the encrypted authorization token that includes the first user-ID encrypted using the cryptographic encryption-key data associated with the physical safe lock, for storing by the physical safe lock of the first user-ID (e.g., including the hashed password). This may be implemented, for example, by executing step 5170.

[0162] Writing to a near-field wireless communication device cryptographic data included in the authorization token, for storing of the cryptographic data away from the communication device. This may be implemented, for example, by executing step 592.

[0163] Following a separation of the communication device and the near-field wireless communication device for a period of at least one day and after thecommunication device and the locked exceeded the maximal communication range of the temporary wireless communication channel (e.g., distancing for at least 100 meters), retrieving by the communication device from the near-field wireless communication device the cryptographic data. This may be implemented, for example, by executing step 596 and / or step 5220.

[0164] The transmitting of the authorization token to the physical safe lock over the temporary wireless communication channel in such case may include transmitting the cryptographic data retrieved from the near-field wireless communication device.

[0165] It is noted that method 600 may be adapted to include any combination of any one or more other steps taken by the communication device in method 500, even if not explicitly elaborated for the sake of concision of the patent application.

[0166] Method 600 may optionally be extended to include any operation executed by the lock. For example, method 600 may further include performing the following steps by the safe lock:

[0167] Decrypting the first user-ID included in the authorization token using the cryptographic encryption-key data associated with the physical safe lock.

[0168] Verifying matching between the decrypted first user-ID and the second userID obtained from the communication device.

[0169] Physically unlocking the safe lock in response to verifying the matching, and optionally subject to further criteria, thereby granting access to an interior of a safe secured by the safe lock.

[0170] Fig. 7 is a functional block diagram illustrating communication device 200 in accordance with embodiments of the presently disclosed invention. It is noted that communication device 200 may include any combination of any one or more of the components illustrated in Fig. 7 and does not necessarily include all of them. Communication device 200 may also include additional components, either relating to its functionality as participant in facilitating of the alteration of the locking state of one or more safe locks or relating to any other functionality of that device.

[0171] Communication device 200 may optionally include user interface (UI) module 210, which includes UI for communicating with user (or users) of the communication device. Such UI may include input UI (denoted 212) and / or output UI(denoted 214). The input UI may include, for example, keyboard, microphone, touch screen, camera, tactile UI, or any other form of input UI. The output UI may include, for example, speaker, screen, touch screen, tactile UI, or any other form of output UI.

[0172] Communication device 200 may optionally include first communication module 230 for communicating with server 100. Such communication may include wireless communication (e.g., Wi-Fi, Bluetooth, cellular networks, satellite communication) and / or wired communication (e.g., Ethernet, USB, HDMI, fiber optic). First communication module 230 may include various components such as any one or more of: antenna, transceiver, modem, network interface card, encoder, decoder, modulator, demodulator, multiplexer, demultiplexer.

[0173] Communication device 200 may optionally include second communication module 240 for communicating with the safe lock over a temporary wireless communication channel. Such short-range wireless communication may include, but is not limited to, Bluetooth, Bluetooth Eow Energy (BLE), Near Field Communication (NFC), Wi-Fi Direct, ZigBee, Ultra-Wideband (UWB), and Infrared (IR). Second communication module 240 may include components such as a short-range radio frequency (RF) transceiver, antenna, signal processor, (encoder, decoder), and power management unit.

[0174] Communication device 200 may optionally include memory 250, either for storing computer code instructions for executing method steps for participating in the alteration of the locking state of one of more safe locks (e.g., method 500, method 600), and / or for storing data used in such methods (e.g., tokens, authentication data, and so on). Communication device 200 may optionally include — e.g., as a part of memory 250 — secure memory 252. Secure memory 252 may serve as (and have the characteristics and functionalities of) any one or more of the following types of memory: ephemeral memory module, encrypted memory module, and sandbox. An ephemeral memory is a type of computer memory that temporarily stores data for a short period of time and is automatically cleared or erased when certain conditions are met, such as when a program terminates or when a device is powered off. This type of memory is designed for short-term data storage and processing, offering fast access times but not retaining information persistently. For example, memory 252 may be erased when the user logs out, or after certain period of inactivity. In computing andcybersecurity, a “sandbox” is a controlled, isolated environment used to run or test software, code, or applications without affecting the host system or other applications. It provides a secure space where potentially untrusted programs can be executed and monitored, limiting their access to system resources and preventing them from making permanent changes to the underlying system. Secure memory 252 may be used, for example, to store the token, passwords, security and / or cryptographic information of the communication device (inaccessible by other entities such as the lock or the server), and so on.

[0175] Communication device 200 may optionally include processor 220, which may execute any computation required for facilitating the participation of communication device 200 in the alteration of the locking state of one of more safe locks (e.g., method 500, method 600). For example, processor 220 may include modules such as: (a) User interaction module 222, in charge of all communications and data exchanges with the user, if needed; (b) Safe lock interaction module 226 in charge of all communications and data exchanges with the safe lock(s); Server interaction module 228, in charge of all communications and data exchanges with the server; and (d) Safe lock control integration module 224, in charge of coordinating the operation of modules 222, 226, and 228, in accordance with predefined protocols and instructions, to support any functionality of the system of environment 10 to control operation of one or more safe locks 300 of one or more safes 400.

[0176] Pertaining to Figs. 1A, IB, 1C, and 7, a system for controlling access to a safe protected by a physical safe lock is disclosed, the system optionally including one or more units out of each of the units discussed with respect to environment 10, and at least one communication device 200 that includes at least one processor 220 and at least one memory 250 including computer program code. The at least one memory 250 and the computer program code are configured, with at least one processor 220, to cause communication device 200 to at least:

[0177] Transmit to a remote server authentication data of a user for authenticating the user by the server.

[0178] Following the authentication of the user by the server, receive from the server a authorization token including first user-ID associated with the user in an encryptedform, encrypted using cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device.

[0179] Transmit to the physical safe lock over a temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock: (a) second user-ID associated with the user, stored by the communication device; and (b) the authorization token that includes the first user-ID encrypted using the cryptographic encryption-key data associated with the physical safe lock; thereby providing to the physical safe lock over the temporary wireless communication channel information required by the physical safe lock for authenticated and authorized alteration of the locking state of the physical safe lock, thus triggering the alteration of the locking state of the physical safe lock.

[0180] That system, and especially the one or more communication devices of that system, may be adapted to execute any combination of any one or more steps, functionalities, capabilities, etc., discussed with respect to the any one or more of methods 500 and 600 (especially, those functionalities discussed with respect to the communication device). That system may also include any other component of environment 10, such as:

[0181] One or more safes that includes at least one door secured by one or more corresponding physical safe locks.

[0182] A server that includes at least one second processor; and at least one second memory including second computer program code, such the at least one second memory and the second computer program code are configured, with the at least one second processor, to cause the server to: (a) receive from the communication device authentication data of the user for authenticating the user by the server; (b) authenticate an identity of the user based on the authentication data; (c) in response to the authentication, generate the authorization token, the generating includes encrypting the first-user ID using the cryptographic encryption-key data associated with the physical safe lock; and (d) transmit the authorization token to the communication device.

[0183] A near-field wireless communication device operable to store the authorization token for a significate duration (e.g., at least a day, at least one month, between 1-12 months, between 1-5 years, etc.), such a duration of time may include,for example, several times in which the communication device is shut down, inactive, and / or malfunctioning.

[0184] Fig. 8 is a flow chart illustrating an example of method 700 for operating a physical safe lock in accordance with the presently disclosed subject matter. The steps of method 700 may be executed by a safe lock, in order to alter its locking state, in coordination with other systems such as a server and a communication device. Referring to the examples set forth with respect to the previous drawings, method 700 may optionally be executed by safe lock 300.

[0185] It is noted that optionally, method 700 may include executing any combination of any one or more of the steps taken by the safe lock of method 500. It is noted that any combination of one or more steps discussed with respect to method 500 may be applicable, mutatis mutandis, to method 7600, and vice versa.

[0186] Step 710 of method 700 includes establishing a new temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock. Referring to the examples set forth with respect to the drawings, step 710 may be executed by wireless communication module 340 and / or communication device interaction module 328. It is noted that while not necessarily so, step 710 may be executed in response to a trigger received from the communication device.

[0187] Method 700 continues with step 720 of receiving from the communication device over the temporary wireless communication channel: (a) a authorization token that includes a first user identification information (user-ID) of a user that is encrypted using a cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device; and (b) a second user-ID associated with the user. Optionally, the second user-ID may be provided to the communication device by the user in a format readable by the communication device for altering a locking state of the physical safe lock. The second user-ID may be provided by the user in different ways, such as entering it (e.g., typing it), selecting it out of a group of userIDs, taking a photo of it (e.g., if using facial recognition), and so on. Referring to the examples set forth with respect to the drawings, step 720 may be executed by wireless communication module 340 and / or communication device interaction module 328.

[0188] Step 730 of method 700 includes decrypting the first user-ID included in the authorization token using the cryptographic encryption-key data associated with the physical safe lock. Referring to the examples set forth with respect to the drawings, step 730 may be implemented using cryptography module 360 of processor 320.

[0189] Step 730 is followed by step 740 that includes verifying a matching between the decrypted first user-ID and the second user-ID. Referring to the examples set forth with respect to the drawings, step 740 may be carried out by processor 320 (e.g., by safe lock control integration module 324). It is noted that the safe lock may implement additional checks and / or other decision criteria before actually altering its locking state. For example, in addition to checking a match between the first user-ID and the second user-ID (e.g., usable to determine authenticity of the request), the safe lock may also check the validity of the request, for example by checking the validity of the timing of the request versus an expiration time set in the request and / or in the rules applied by the safe lock, by determining the validity of the location from which the request is made using geofencing data, or in any other suitable way

[0190] Step 740 is followed by step 750 that includes physically unlocking the safe lock — in response to verifying the matching, and optionally subject to further criteria — thereby granting the user access to an interior of a safe secured by the safe lock. Referring to the examples set forth with respect to the drawings, step 750 may be carried out by processor 320 (e.g., by safe lock control integration module 324).

[0191] Pertaining to steps 710 and 720, the receiving over the temporary wireless communication channel may include communicating with the communication device via an encasing of the safe, wherein communicating with the communication device via the encasing of the safe attenuates signals of the communicating by a factor of at least at least x 10.

[0192] Optionally, method 700 may include receiving the received data of step 720 from the communication device that is used by the user for: (a) connecting to the internet; (b) downloading data from at least one news website and from at least one social network; and (c) receiving a plurality of advertisements from a plurality of different ad networks. Method 700 may include (in such case and in others) maintaining a security level of the altering of the locking state by decrypting the firstuser-ID included in the authorization token using the cryptographic encryption-key data associated with the physical safe lock.

[0193] As discussed with respect to methods 500 and 600, a near-field wireless communication device may be used to facilitate the alteration of the locking state of the safe lock in various situations. Optionally, method 700 may further include: (a) receiving from the communication device an indication that the altering of the locking state is executed without a current communication between the communication device and the server; (b) obtaining from the communication device prior to the receiving of the first user-ID and the second user-ID a limited-use emergency password; (c) verifying an authenticity of the emergency password; and (d) in response to the verifying, transmitting to the communication device over the temporary wireless communication channel an emergency access ID that was provided to the lock prior to the obtaining. The receiving of the authorization token in such case may include receiving the authorization token that was retrieved by the communication device from data provided by a near-field wireless communication device using the emergency access ID.

[0194] Fig. 9 is a functional block diagram illustrating safe lock 300 in accordance with embodiments of the presently disclosed invention. It is noted that safe lock 300 may include any combination of any one or more of the components illustrated in Fig. 8, and does not necessarily include all of them. Safe lock 300 may also include additional components, either relating to its functionality as participant in facilitating of the alteration of the locking state of one or more safe locks, or relating to any other functionality of that device.

[0195] Safe lock 300 may include physical locking mechanism 310, which may include, for example, any one or more of: motorized bolt work (for extending and retracting one or more locking bolts), solenoid-operated spring bolt(s), electromagnetic lock(s) (e.g., for secondary locking), servo-controlled re-locker mechanism(s), and stepper motor-driven gear system(s).

[0196] Safe lock 300 may include memory 350 either for storing computer code instructions for executing method steps for participating in the alteration of the locking state of that safe lock 300 (method 600), and / or for storing data used in such methods (e.g., tokens, authentication data, and so on). Optionally, memory 350 may includecryptographic memory module 352, which is used for storing in a secured fashion cryptographic information used for the securing of stored data and / or communication. Optionally, cryptographic memory module 352 may be used for storing in a secured fashion information encrypted by such cryptographic data (such as, for example, the token, passwords, communication device unique identifier, emergency password, etc., if encrypted). Optionally, memory 350 may include operational memory module 354, used for storing data indicative of the locking state of the lock as well as other operational parameters of the safe lock (e.g., time since last being opened, security requirements, and so on.

[0197] Safe lock 300 may include wireless communication module 340 for wirelessly communicating with one or more communication devices over a temporary wireless communication channel. Such short-range wireless communication may include, but is not limited to, Bluetooth, Bluetooth Low Energy (BLE), Near Field Communication (NFC), Wi-Fi Direct, ZigBee, Ultra-Wideband (UWB), and Infrared (IR). Wireless communication module 340 may include components such as a short- range radio frequency (RF) transceiver, antenna, signal processor, (encoder, decoder), and power management unit.

[0198] Safe lock 300 may include Processor 320 which may execute any computation required for facilitating the participation of safe lock 300 in the alteration of its locking state (e.g., method 500, method 600). For example, processor 320 may include modules such as: (a) physical lock controller 322 for controlling operation of physical locking mechanism 310 in response to locking state alteration protocols, e.g., as discussed above; (b) communication device interaction module 328 in charge of all communications and data exchanges with the one or more communication devices that can be used to control that safe lock; (c) memory management module 326, in charge of reading and writing data to memory module 350, (d) cryptography module 360 operable to encrypt and / or decrypt message using one or more encryption keys of the safe lock, and (e) Safe lock control integration module 324, in charge of coordinating the operation of modules 322, 326, 328, and 360, in accordance with predefined protocols and instructions, to support any functionality of the system of environment 10 to control operation of that safe lock 300.

[0199] Pertaining to Figs. 1A, IB, 1C, and 9, a system for controlling access to a safe protected by a physical safe lock is disclosed, the system optionally including one or more units out of each of the units discussed with respect to environment 10, and at least one safe lock 300 that includes at least one processor 320 and at least one memory 350 including computer program code. The at least one memory 350 and the computer program code are configured, with at least one processor 320, to cause that safe lock 300 to at least:

[0200] Establish a new temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock.

[0201] Receiving from the communication device over the temporary wireless communication channel: (a) an authorization token that includes a first user identification information (user-ID) of a user that is encrypted using a cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device; and (b) a second user-ID associated with the user, the second user-ID being provided to the communication device by the user in a format readable by the communication device for altering a locking state of the physical safe lock.

[0202] Decrypt the first user-ID included in the authorization token using the cryptographic encryption-key data associated with the physical safe lock;

[0203] Verify a match between the decrypted first user-ID and the second user-ID.

[0204] In response to verifying the matching, and optionally subject to further criteria, physically unlock the safe lock, thereby granting at least one person access to an interior of a safe secured by the safe lock.

[0205] That system, and especially the one or more safe locks of that system, may be adapted to execute any combination of any one or more steps, functionalities, capabilities, etc., discussed with respect to any one or more of methods 500 and 700 (especially, those functionalities discussed with respect to the safe lock). That system may also include any other component of environment 10, such as:

[0206] One or more safes that include at least one door secured by one or more corresponding physical safe locks.

[0207] A server that includes at least one second processor; and at least one second memory including second computer program code, such the at least one secondmemory and the second computer program code are configured, with the at least one second processor, to cause the server to: (a) receive from the communication device authentication data of the user for authenticating the user by the server; (b) authenticate an identity of the user based on the authentication data; (c) in response to the authentication, generate the authorization token, the generating includes encrypting the first-user ID using the cryptographic encryption-key data associated with the physical safe lock; and (d) transmit the authorization token to the communication device.

[0208] A near-field wireless communication device operable to store the authorization token for at least one month.

[0209] Any of the methods and systems discussed above may be implemented using a corresponding computer program code product. Such a product typically comprises a non-transitory computer-readable medium containing instructions that, when executed by a processor, cause a computer system to perform specific operations. For example, a non-transitory computer-readable medium for implementing a method or system as described herein may comprise instructions stored thereon that, when executed on a processor, perform steps of the respective method and / or functionalities of the respective system. These instructions may be stored on any of various types of storage media (e.g., as discussed below) and executed on various types of processing units, including but not limited to general-purpose processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other suitable processing devices. It is noted that any step, detail, variation, module, functionality or capability discussed above with respect to any of the systems, components, modules, methods, and steps discussed above may be applicable, mutatis mutandis, to the corresponding computer program product.

[0210] For example, according to an aspect of the invention, there is disclosed a first non-transitory computer-readable medium for controlling a physical safe lock by a remote server, including instructions stored thereon, that when executed on a processor of a communication device perform the steps of: (a) transmitting to a remote server authentication data of a user for authenticating the user by the server; (b) following the authentication of the user by the server, receiving from the server an authorization token including a first user identification information (user-ID) associated with theuser in an encrypted form, encrypted using cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device; and (c) transmitting to the physical safe lock over a temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock: (i) a second user-ID associated with the user, stored by the communication device; and (ii) the authorization token that includes the first user-ID encrypted using the cryptographic encryption-key data associated with the physical safe lock; thereby providing to the physical safe lock over the temporary wireless communication channel information required by the physical safe lock for authenticated and authorized alteration of the locking state of the physical safe lock, thus triggering the alteration of the locking state of the physical safe lock.

[0211] It is noted that any step, detail, variation, functionality or capability discussed above with respect to communication device 200, to the interaction of communication device 200 with other devices of the system, to method 600, to the actions and interactions of the communication device in method 500 may be applicable, mutatis mutandis, to the first non-transitory computer-readable medium and any corresponding computer program product stored thereon. Such details are not explicitly repeated in full for the sake of brevity of the disclosure.

[0212] For example, according to an aspect of the invention, there is disclosed a second non-transitory computer-readable medium for controlling a physical safe lock by a remote server, including instructions stored thereon, that when executed on a processor of a safe lock perform the steps of: (a) establishing a new temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock; (b) receiving from the communication device over the temporary wireless communication channel: (i) an authorization token that includes a first user identification information (user-ID) of a user that is encrypted using a cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device; and (ii) a second user-ID associated with the user, the second user-ID being provided to the communication device by the user in a format readable by the communication device for altering a locking state of the physical safe lock; (c) decrypting the first user-ID included in the authorization token using the cryptographic encryption-key dataassociated with the physical safe lock; (d) verifying a matching between the decrypted first user-ID and the second user-ID; and (e) in response to verifying the matching, and optionally subject to further criteria, physically unlocking the safe lock, thereby granting the user access to an interior of a safe secured by the safe lock.

[0213] It is noted that any step, detail, variation, functionality or capability discussed above with respect to safe lock 300, to the interaction of safe lock 300 with other devices of the system, to method 700, to the actions and interactions of the safe lock in method 500 may be applicable, mutatis mutandis, to the second non-transitory computer-readable medium and any corresponding computer program product stored thereon. Such details are not explicitly repeated in full for the sake of brevity of the disclosure.

[0214] Any of the aforementioned one or more computer programs may be stored internally on a non-transitory computer readable medium. All or some of the computer program may be provided on computer readable media permanently, removably, or remotely coupled to an information processing system. The computer readable media may include, for example and without limitation, any number of the following: solid- state storage media including flash memory (e.g., NAND, NOR), solid-state drives (SSDs), and other non-volatile semiconductor-based memory units such as 3D XPoint, MRAM, FRAM, and ReRAM; magnetic storage media including hard disk drives (HDDs), tape storage media, and magnetic random access memory (MRAM); optical storage media such as Blu-ray disks, DVDs, and CDs; cloud-based storage accessible via network-attached storage (NAS) or storage area network (SAN) configurations; quantum storage devices; holographic storage media; DNA-based storage systems; volatile storage media including dynamic random-access memory (DRAM), static random-access memory (SRAM), and other forms of main memory; cache memory including CPU registers and various levels of cache (LI, L2, L3); and emerging storage technologies such as neuromorphic memory systems. The computer program may also be stored in distributed storage systems, edge computing nodes, or other decentralized architectures.

[0215] A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. An operatingsystem (OS) is software that manages the sharing of the resources of a computer or device and provides programmers with an interface used to access those resources. Operating systems can range from traditional desktop and server systems to mobile OS, real-time OS for embedded systems, and hypervisor-based systems for virtualization. An operating system processes system data and user input, and responds by allocating and managing tasks and internal system resources as a service to users and programs of the system. Modem operating systems often incorporate features such as containerization, microservices architecture support, advanced security measures, and APIs for cloud integration and edge computing.

[0216] Referring to all of the systems, methods, and computer program products discussed in the present application, it is noted that the disclosed systems, methods, and computer program products demonstrate, among other aspects, the ways in which wireless communication may be implemented to control and alter locking states of safe locks which are included inside safe, and even inside very high end safe (e.g., characterized by thick metal body and thick metal door). The disclosed systems, methods and computer program product demonstrate how a communication device of the user may be used in great proximity to the walls of the safe, thus enabling high frequency radio frequency signals (e.g., some or all of 900MHz, 1.5GHz, 1.8GHz, 2.4GHz) to infiltrate in the small spaces between the door of the safe and the frame, for example, in order to establish a temporary wireless communication channel between the safe lock and the communication device, which may be used for transmitting highly secured data.

[0217] While the embodiments described above are provided as examples, it should be understood that various modifications and substitutions may be made without departing from the scope of the invention as defined in the appended claims.

Claims

CLAIMSWhat is claimed is:

1. A system for control of altering a locking state of a physical lock, the system comprising a physical lock that comprises: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the physical lock to at least: establish a temporary communication channel between a communication device and a communication module of the physical lock; receive from the communication device over the temporary communication channel: (a) an authorization token that comprises a first identification information of a user (user-ID) that is encrypted using a cryptographic encryption-key data associated with the physical lock, wherein the cryptographic encryption-key data is withheld from the communication device; and (b) a second user-ID associated with the user and readable by the physical lock; decrypt the first user-ID included in the authorization token using the cryptographic encryption-key data associated with the physical lock and available thereto; verify a matching between the decrypted first user-ID and the second user-ID; and in response to successful verifying the matching, provide the one or more actions in according with one or more instructions comprised in the received authorization token.

2. The system according to claim 1, wherein the one or more actions are selected from: physically locking the lock, physically unlocking the lock, changing the level of security of locking, sending to the communication device a log of altering events during a certain period and generating and sending to the communication device a report informative of altering events during a certain period.

3. The system according to claims 1 or 2, wherein the one or more instructions specify at least one of the following as a condition for providing the one or more actions:validity of one or more timing parameters, matching one or more lock state parameters and matching one or more authorization parameters.

4. The system according to any one of claims 1 - 3, wherein the one or more instructions comprised in the authorization token are encrypted, and wherein the physical lock is caused to decrypt said one or more instructions prior to providing the one or more actions.

5. The system according to any one of claims 1 - 4, wherein the physical lock is a safe lock and wherein the system further comprises the safe that includes at least one door secured by the physical safe lock. .

6. The system according to claim 5, wherein the safe is located in a secured environment and wherein the safe lock is configured to store in its nonvolatile memory secured data related to reserved access with the help of a reserved authorization token.

7. The system according to any one of claims 1 - 6, further comprising a server, wherein the server comprises at least one second processor; and at least one second memory including second computer program code, wherein the at least one second memory and the second computer program code are configured, with the at least one second processor, to cause the server to: receive from the communication device authentication data of the user and authenticate the user by the server; use the authentication data to generate the first user-ID; generate the authorization token, the generating comprises encrypting the first- user ID using the cryptographic encryption-key data associated with the physical lock; and transmit the authorization token to the communication device.

8. A method of controlling a physical lock, the method comprising executing the following steps by the physical lock: establishing a temporary communication channel between a communication device and the physical lock;receiving from the communication device over the temporary communication channel: an authorization token that comprises a first user identification information of a user (user-ID) that is encrypted using a cryptographic encryption-key data associated with the physical lock, wherein the cryptographic encryption-key data is withheld from the communication device; and a second user-ID associated with the user; decrypting the first user-ID included in the authorization token using the cryptographic encryption-key data associated with the physical lock and available thereto; verifying a matching between the decrypted first user-ID and the second userID; and in response to successful verifying the matching, providing the one or more actions in accordance with one or more instructions comprised in the received authorization token.

9. The method according to claim 8, wherein the one or more actions are selected from: physically locking the lock, physically unlocking the lock, changing the level of security of locking, sending to the communication device a log of altering events during a certain period and generating and sending to the communication device a report informative of altering events during a certain period.

10. The method according to claims 8 or 9, wherein the one or more instructions specify at least one of the following as a condition for providing the one or more actions: validity timing parameters, lock state parameters and authorization parameters.

11. The method according to any one of claims 8 - 10, wherein the one or more instructions comprised in the authorization token are encrypted, and wherein the physical lock decrypts said one or more instructions prior to providing the one or more actions.

12. A non-transitory computer-readable medium comprising instructions stored thereon, that when executed on a processor of a physical lock performs the steps of any one of claims 8 -11.

13. A method for control of altering locking states of a plurality of physical locks, the method comprising: by a server, receiving from a communication device authentication data of a user and a request to provide one or more actions regarding a given physical lock from the plurality of physical locks; upon successful authenticating the user, using the received authentication data to generate a first user-ID; generating an authorization token, the generating comprises encrypting the first-user ID using the cryptographic encryption-key data associated with the given physical lock; transmitting the authorization token to the given physical lock using the communication device as untrusted relay that forwards the authorization token in the form of ciphertext and has no capability of viewing or altering its content; by the given physical lock: using a temporary communication channel with the communication device to receive the authorization token generated by the server and comprising encrypted first user-ID; using the temporary communication channel to receive a second user-ID associated with the user and readable by the physical lock; decrypting the first user-ID using the cryptographic encryption-key data associated with the given physical lock and available thereto; verifying a matching between the decrypted first user-ID and the second userID; and in response to successful verifying the matching, providing the one or more actions in accordance with one or more instructions comprised in the received authorization token.

14. The method according to claim 13, wherein the one or more actions are selected from: physically locking the lock, physically unlocking the lock, changing the levelof security of locking, sending to the server via the communication device a log of altering events during a certain period and generating and sending to the server via the communication device a report informative of altering events during a certain period.

15. The method according to claims 13 or 14, wherein the one or more instructions specify at least one of the following as a condition for providing the one or more actions: validity of one or more timing parameters, matching one or more lock state parameters and matching one or more authorization parameters.

16. The method according to any one of claims 13 - 15, wherein the one or more instructions comprised in the authorization token are encrypted by the server using the cryptographic encryption-key associated with the given physical lock, and wherein the physical lock decrypts said one or more instructions prior to providing the one or more actions.

17. A system for control of altering locking states of a plurality of physical locks, the system comprising a server operatively connected to the plurality of physical locks and configured to operate according to any one of claims 13 - 16.

18. A system for controlling access to a safe protected by a physical safe lock, the system comprising at least a communication device that comprises: at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the communication device to at least: transmit to a remote server authentication data of a user for authenticating the user by the server; following the authentication of the user by the server, receive from the server an authorization token comprising first user identification information (userID) associated with the user in an encrypted form, encrypted using cryptographic encryption-key data associated with the physical safe lock that is withheld from the communication device; and transmit to the physical safe lock over a temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock: (a) second user-ID associated with the user,stored by the communication device; and (b) the authorization token that comprises the first user-ID encrypted using the cryptographic encryption-key data associated with the physical safe lock; thereby providing to the physical safe lock over the temporary wireless communication channel information required by the physical safe lock for authenticated and authorized alteration of the locking state of the physical safe lock, thus triggering the alteration of the locking state of the physical safe lock.

19. The system according to claim 18, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the communication device to facilitate the alteration of the locking state of the physical safe lock by: transmitting first authentication information to the server for a first authentication process authenticating the user by the server, the first authentication information comprising the authentication data of a user; transmitting second authentication information to the physical safe lock for a second authentication process authenticating the user by the physical safe lock, the second authentication information comprising the second user-ID; and relaying to the physical safe lock authorization information generated by the server, the authorization information comprising information generated by the server in response to the transmitting of the first authentication information, and used by the physical safe lock in the second authentication process.

20. The system according to claims 18 or 19, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the communication device to relay to the physical safe lock an at least partly encrypted authorization-token generated by the server without establishing a direct communication channel between the server and the physical safe lock, thereby establishing a communication conduit between the server and the physical safe lock, wherein a security level of the communication conduit is maintained by the server and is maintained above a predefined security level regardless of a security level of the communication device.

21. The system according to any one of claims 18 - 20, further comprising the physical safe lock that is operable at least to: (a) decrypt the first user-ID included in the authorization token using the cryptographic encryption-key data of the physical safe lock; (b) verify a matching between the decrypted first user-ID and the second user-ID; and (c) in response to verifying the matching, and optionally subject to further criteria, physically unlocking the safe lock, thereby granting access to an interior of a safe secured by the safe lock.

22. The system according to any one of claims 18 -22, further comprising a server, wherein the server comprises at least one second processor; and at least one second memory including second computer program code, wherein the at least one second memory and the second computer program code are configured, with the at least one second processor, to cause the server to: receive from the communication device authentication data of the user for authenticating the user by the server; authenticate an identity of the user based on the authentication data; in response to the authentication, generate the authorization token, the generating comprises encrypting the first-user ID using the cryptographic encryption-key data of the physical safe lock; and transmit the authorization token to the communication device.

23. A method for controlling a physical safe lock by a remote server, the method comprising executing the following steps by a communication device: transmitting to a remote server authentication data of a user for authenticating the user by the server; following the authentication of the user by the server, receiving from the server a authorization token comprising a first user identification information (userID) associated with the user in an encrypted form, encrypted using cryptographic encryption-key data of the physical safe lock that is withheld from the communication device; andtransmitting to the physical safe lock over a temporary wireless communication channel between the communication device and a wireless communication module of the physical safe lock: a second user-ID associated with the user, stored by the communication device; and the authorization token that comprises the first user-ID encrypted using the cryptographic encryption-key data of the physical safe lock; thereby providing to the physical safe lock over the temporary wireless communication channel information required by the physical safe lock for authenticated and authorized alteration of the locking state of the physical safe lock, thus triggering the alteration of the locking state of the physical safe lock.

24. The method according to claim 23, comprising performing the following steps by the safe lock: decrypting the first user-ID included in the authorization token using the cryptographic encryption-key data of the physical safe lock; verifying matching between the decrypted first user-ID and the second user-ID obtained from the communication device; and in response to verifying the matching, physically unlocking the safe lock, thereby granting access to an interior of a safe secured by the safe lock.

25. A non-transitory computer-readable medium for controlling a physical safe lock by a remote server, comprising instructions stored thereon, that when executed on a processor of a communication device perform the steps of any one of claims 23 - 24.

26. A method of controlling a physical lock, the method comprising executing the following steps by the physical lock: using a temporary communication channel with a communication device to receive from a user a request to provide one or more actions regarding physical lock and a reserved authorization token comprising a reserved permission object (RPO), wherein: the reserved authorization token has been, in advance, received by the communication device from a portable storage device;the RPO comprises data usable for authentication of the user and data usable for identifying the portable storage device, wherein at least data usable for authentication of the user (authentication data) is encrypted; and neither the communication device nor the portable storage device has capability of viewing or altering the encrypted information in the reserved authorization token; matching between the RPO received in the reserved authorization token and cryptographic data possessed by the physical lock and informative of the RPO; and in response to successful matching, providing the one or more actions in accordance with one or more instructions comprised in the received reserved authorization token.

27. The method according to claim 26, wherein the physical lock deletes the possessed cryptographic data informative of the RPO upon successful matching.

28. The method according to claim 26 or 27, wherein the one or more actions are selected from: physically locking the lock, physically unlocking the lock, changing the level of security of locking, sending to the communication device a log of altering events during a certain period and generating and sending to the communication device a report informative of altering events during a certain period.

29. The method according to any one of claims 26 -28, wherein the one or more instructions specify at least one of the following as a condition for providing the one or more actions: validity of one or more timing parameters, matching one or more lock state parameters and matching one or more authorization parameters.

30. The method according to any one of claims 26 - 29, wherein the portable storage device is aNear-Field Communication (NFC) device.

31. The method according to any one of claims 26 - 30, wherein the cryptographic data possessed by the physical lock is cryptographically derived by the physical lock from a respective RPO received during a setup process.

32. The method according to claim 31, wherein the RPO is received by the physical lock from a server that, during the setup process, transmitted the RPO to the physical lock using the communication device as an untrusted relay.

33. The method according to claim 32, wherein the reserved authorization token is generated by the portable storage device using encrypted authentication data and wherein, during the setup process, the encrypted authentication data is received by the portable storage device from the server that transmitted the encrypted authentication data to the portable storage device using the communication device as an untrusted relay.

34. A system for control of altering locking states of a plurality of physical locks, the system comprising a server operatively connected to the plurality of physical locks and configured to operate according to any one of claims 26 - 34.

Images