Smart locks and keys

Abstract

A lock (100) includes a controller, a data storage device, a lock mechanism in a locked state or an unlocked state operable by the controller, and a data communication front end including a first data port (108) and a second data port; wherein the controller is configured to enter data communication via the second data port after data communication via the first data port is successfully completed. An electronic key (200) includes a key controller, a data storage device, a power source, and a data communication front end including a first data port (202) and a second data port; wherein the electronic key (200) is a physical key having a key body and is configured to work with the lock.

Description

Technical Field

[0001] The present disclosure relates to a smart lock and a smart key, and more particularly, to a lock having a lock mechanism operable by a smart electronic circuit system and an electronic key thereof. Background Art

[0002] A smart lock is an electronic lock with a locking mechanism that can be operated by an electronic circuit system. Electronic locks are becoming increasingly popular due to their flexibility and enhanced security. As the use of smart locks increases, improved smart locks and keys are advantageous. Summary of the invention

[0003] A lock is disclosed, comprising a controller, a data storage device, a lock mechanism in a locked state or an unlocked state operable by the controller, and a data communication front end comprising a first data port and a second data port. The controller is configured to enter data communication via the second data port after data communication via the first data port is successfully completed.

[0004] The controller may be configured to receive identification data via the first data port and to receive operational data messages via the second data port, and wherein the controller may be configured not to receive operational data messages via the second data port if the identification data received via the first data port does not meet admission criteria.

[0005] The controller may be configured to communicate unencrypted data via the first data port and to communicate encrypted data via the second data port.

[0006] An electronic key configured to work with the above lock is disclosed. The electronic key includes a key controller, a data storage device, a power supply, and a data communication front end including a first data port and a second data port. The electronic key is a physical key having a key body.

[0007] The key controller is configured to send identification data via the first data port and, upon receiving a positive response indicating admissibility via the first data port, transmit an operational data message via the second data port. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The present disclosure is described by way of example and with reference to the accompanying drawings, in which:

[0009] Figure 1 and Figure 1A is a block diagram of an example lock of the present disclosure,

[0010] Figure 2 and Figure 2A is a block diagram of an example hard key of the present disclosure,

[0011] Figure 3 is a schematic diagram showing an example encryption process of a command message,

[0012] Figure 4A is a front view of the sample lock.

[0013] Figure 4B It is shown Figure 4A A perspective view of an example lock's USB port,

[0014] Figure 4C yes Figure 4A A cross-sectional view of an example lock,

[0015] Figure 5A , Figure 5B and Figure 5C are front view, perspective view and cross-sectional view of an example hard key,

[0016] Figure 5D yes Figure 5A A display of an example key.

[0017] Figure 6 Shows Figure 4A An example of lock and Figure 5A An example of a key interface port,

[0018] Fig. 7A and Figure 7B The mechanical coupling is shown in the locked position and the released position respectively. Figure 4A An example of lock and Figure 5B A cross-sectional view of an example key,

[0019] Figure 8 Schematically shows the data communication equipment Figure 4A An example of remote operation of a lock,

[0020] Fig. 9 Schematically shows a hard key engaged with a lock Figure 4A An example of a lock contact operation,

[0021] Fig.10 Operation by a hard key in mating engagement with a lock is shown Figure 4A An example lock flowchart,

[0022] Fig.11 schematically illustrates contactless operation of an example lock,

[0023] Fig. 12A , Fig. 12B , Fig.13A and Fig. 13B An example safe and lock in the form of a locked box according to the present disclosure are shown, and

[0024] Fig.14A , Fig. 14B , Fig.15A and Fig. 15B Example locks in the form of cable locks and door locks according to the present disclosure are shown. DETAILED DESCRIPTION

[0025] The lock of the present disclosure comprises an electronic circuit system including a controller, a data storage device, a lock mechanism operable by the controller, a data communication front end including a first port as a first data communication port and a second port as a second data communication port, such as Figure 1 As shown. The controller is a lock controller, which may include a microprocessor-based solid-state controller (MCU) and peripheral circuit systems, the MCU being configured to control the lock, including its settings and operations, and the peripheral circuit systems being configured to support the operations of the MCU. The data storage device is used to store digital data, especially data related to the settings and operations of the lock, and may include volatile memory such as RAM and / or non-volatile components such as ROM or EPROM. The data storage device is connected in data communication with the controller so that data can be stored in the data storage device by the controller, and the data stored in the data storage device can be retrieved by the controller. The lock mechanism is capable of operating in a first state and a second state, in which the lock is in a locked state in the first state and in an unlocked state in the second state. The data communication front end, including its data port, is connected in data communication with the controller and is configured to cooperate with the controller to facilitate data communication between the lock and an external device such as a key. The electronic circuit system may include peripheral circuit systems, such as analog-to-digital converters, power management circuits, and other optional circuit systems. Data communication here refers to electronic data communication, and may be wired and / or wireless. In order to facilitate wireless data communication, the electronic circuit system may include a wireless data transceiver.

[0026] The first port is a data communication port configured for data communication of a first type of data, and the second data port is a data communication port configured for data communication of a second type of data different from the first type, and the difference between the first and second data types may be data nature, data format, data speed and / or data modulation.

[0027] In an example embodiment, the lock controller is configured to perform a first process through the first data port before entering the second process through the second data port. The first process can be a verification process, during which the controller operates to determine whether the data entering from the first data port meets the verification requirements. If the result of the verification process is positive, that is, successful, the controller determines that the incoming data is from a qualified object, and the lock controller will proceed to the second process. If the result of the first process is negative, that is, unsuccessful, the lock controller will not proceed to the second process.

[0028] The lock may include a third port, and the controller may be configured to perform a pre-process to determine whether to perform the first process with reference to the signal present at the third port. If the signal present at the third port corresponds to the signal of a qualified electronic key, the lock controller will operate to perform the first process. Otherwise, the lock controller will not perform the first process.

[0029] The lock is configured to work with a key. In an example embodiment, the key configured to work with the lock will have identification parameters and an encryption key pre-stored on the key.

[0030] The key can be a physical key or a software key that is configured to operate the lock through data communication. The software key is a non-dedicated electronic key generated by executing application software residing on a host such as a smart phone, tablet computer, notebook computer, personal computer, and other general or special computer-based machines, and operates the lock through wireless data communication. The physical key is a dedicated electronic key that is configured to operate the lock, and the data communication can be wired and / or wireless. The host, when executing the application software, will become an application machine ("APP") with an interface that works with the lock, including sending lock operation instructions and management instructions such as key reset.

[0031] The physical key includes an electronic circuit system including a controller, a data storage device, a data communication front end including a first data port and a second data port, and a key body, as shown in FIG2 . The first data port of the key is configured to perform data communication with the first data port of the lock, and the second data port of the key is configured to perform data communication with the second data port of the lock. Since the first data ports of the key and the lock must be compatible with each other, and the second data ports of the key and the lock must be compatible with each other, the descriptions of the controller, the first and second types of data, the data ports, the data storage device, the telecommunication front end, the controller, etc. are incorporated by reference and applied to the key with necessary changes, for example, the lock controller is renamed as the key controller. Similarly, the descriptions of the first process, the second process, the third process, and the third port are incorporated by reference and applied to the key with necessary changes.

[0032] The first process may be a verification process, which is designed to determine whether the key is configured for the target lock and whether the target lock has been paired with the key. If the determination result is positive, the key is a qualified key, and the lock and the key are a qualified pair.

[0033] The second process may be an instruction process during which one or more lock instructions are sent to the lock and the lock controller is configured to react to the one or more instructions upon receipt.

[0034] During the first process, the key may send an identification parameter to the lock, and the lock upon receiving the identification parameter will determine if the identification parameter is correct. If the lock controller determines that the identification parameter is correct, the first process is successful and the controller will send a confirmation response.

[0035] If the result of the first process is positive, that is, successful, the lock controller will perform the second process, that is, receive the lock instruction through the second data port. If the result of the verification process is negative, that is, unsuccessful, the key is an unqualified key, and the lock controller will not send a confirmation response, and will not perform the second process, that is, the controller will operate to ignore data from unqualified keys.

[0036] The identification parameter of the lock may be stored on the lock, for example, at the time of manufacture, i.e., at the factory, to facilitate the verification process. The identification parameter should be unique to the lock and may be assigned by the manufacturer, such as a serial number. The MAC address of the lock may be used as the identification parameter of the lock, since the MAC address is recognized as a unique identifier of the device.

[0037] The third port may be configured as a compatibility signal port for receiving a compatibility signal. If a compatibility signal is detected at the third port, the controller will proceed to the first process. For example, the third port of a compatibility key may be set at a specific voltage, and the lock controller will determine that the key has a valid compatibility signal qualified for the second process when it detects that a voltage at or within the specific voltage is present at the third port of the key. Similarly, the third port of a compatibility lock may be set at a specific voltage, and the key controller will determine that the lock has a valid compatibility signal qualified for the second process when it detects that a voltage at or within the specific voltage is present at the third port of the lock.

[0038] To determine whether the key is a qualified key with a valid compatibility signal, the third port of the qualified key and the third port of the qualified key lock can be configured to make physical and electrical contact so that the voltage of the third port of the key can be measured by the lock controller, and vice versa.

[0039] When determining whether the key has a valid compatibility signal, the third port of the lock may have an isolation switch, which can be operated by the controller to connect the third port to the power circuit of the lock or isolate the third port from the power circuit, and when the signal measurement is performed at the third port, the lock controller can operate the isolation switch to isolate the third port of the lock from the power circuit to avoid conflicts. Similarly, the third port of the key may have an isolation switch, which can be operated by the controller to connect the third port to the power circuit of the key or isolate the third port from the power circuit, and the key controller can operate the isolation switch to isolate the third port of the key from the power circuit of the key when the signal measurement is performed at the third port to avoid conflicts.

[0040] The data communication between the lock and the key is carried out by means of data packets. An example data packet has 16 bytes of data, and each byte has 8 bits of binary data. The data packets include two types of data packets, namely, a first type called a command packet ("Command Packet") and a second type called a response packet ("Response Packet") configured to respond to a received command packet.

[0041] The example command packet includes a format portion (overhead portion) and a substantial content portion (payload portion). The example command packet has an 11-byte substantial content portion (such as bytes 3 to byte 13) and a 5-byte format portion (such as bytes 0 to 2 and bytes 14 to 15). The substantial content portion includes an "array" type data portion containing command parameters, and the format portion includes a command packet sequence number (SEQ, 2 bytes), type information ("CMD", command) and a 2-byte checksum ("CSM").

[0042] The example response packet includes a format portion and a substantial content portion. The example command packet has a 10-byte substantial content portion (e.g., byte 4 to byte 13) and a 6-byte format portion (e.g., bytes 0 to 3 and bytes 14 to 15). The substantial content portion includes a data portion of type "array", which includes response parameters, and the format portion includes a response packet sequence number (RSEQ, 2 bytes), type information ("RCM", response), an error field indicating whether the received command has been successfully executed ("ERR", 1 byte) and a 2-byte checksum ("CSM").

[0043] A command is an instruction that can be classified as a lock operation command, an administration command (administration or admin), or a query command. A lock operation instruction is configured to instruct the lock controller to perform lock operations such as locking and unlocking. An administration command is configured to instruct the lock controller to set parameters such as clock time, motor forward time, motor reverse time, timers such as advertising intervals, advertising disable time, etc. A query command is configured to instruct the lock controller to return the status information of the lock, and may include commands to obtain the lock status (locked, unlocked, damaged), lock operation records, etc.

[0044] The lock command may be encrypted to facilitate secure data communication between the key and the corresponding lock paired with the key. To facilitate secure data communication, the controller may include an encryption and decryption machine. The encryption and decryption machine may be an electronic circuit dedicated to performing data encryption and data decryption, for example, according to a data encryption algorithm such as that compliant with the AES (Advanced Encryption Standard). In an exemplary embodiment, the AES 128 standard using 128-bit data (i.e., 6 bytes of data) is adopted. To facilitate data encryption and decryption, a data encryption and decryption key is stored in the lock. The data encryption and decryption key ("encryption key" or "decryption key") may be stored at the time of manufacture, or may be installed and stored on the lock by activation after purchase by the user.

[0045] During operation, the user can operate the key to send instructions to the lock via the second data port only. The lock controller will operate according to the data content of the instruction when the instruction is detected. In the case where the lock is configured to operate using secure data communication and encrypted instructions, the lock controller will operate to decrypt the received encrypted instructions and operate according to the decrypted instructions. In the case where the lock controller is configured to send a response to the key in response to the received instruction, the lock controller will respond by sending a response command or an encrypted response command via the second data port. When an encrypted response command is received, the key controller will operate to decrypt the received encrypted response command and update the lock state as appropriate.

[0046] The second data port may be configured for wireless data communications, and day-to-day operation of the lock may be by wireless data communications only via the second data port, for example when an encryption key has been stored on the lock.

[0047] The software key is configured to operate the lock only by data communication via the second data port, such as by wired or wireless data communication.

[0048] The lock and paired key can be configured for Bluetooth (RTM) operation, for example, via a second port. As a convenient example, a Bluetooth (RTM) enabled controller such as Toshiba's TC35680FSG / TC35681FSG can be used as a lock controller and a key controller. The example controller is configured for BTLE (Bluetooth (RTM) low energy operation protocol) version 5.0 and operates at 2.4GHz. To comply with the BTLE protocol, each lock command is followed by a UUID (universally unique identifier). Alternatively, if a different wireless data communication standard is used, the command data format will be different. In an example embodiment, the second data port of the lock can be configured to be used only for wireless data communication.

[0049] In order to operate the lock through the software key resident on the host, the host will look for the lock to be paired when executing the application software, and since the identification information of the lock is unknown, the pairing can be performed through the connection protocol of the communication standard. After the connection is established, the host will send a lock instruction to the lock, and the lock controller will respond by broadcasting a response command via the second data port and perform the lock operation where appropriate. When the lock instruction and response command are encrypted, the corresponding controller will perform decryption to retrieve the embedded data.

[0050] In order to facilitate the contact operation of the lock by a physical key, the lock is provided with a key interface, and the key is provided with a lock interface, and the lock interface is configured to physically engage with the key interface. The key interface includes a plurality of terminals, including a first terminal configured as a first data port and a second terminal configured as a third port, and the third port is a compatibility signal port.

[0051] In an example embodiment, both the lock interface and the key interface are configured to be physically compatible with the USB Micro-B connector standard, one being configured as a female connector and the other being configured as a male connector.

[0052] The USB connector has five terminals, namely, terminals 1 to 5. Terminal 1 is configured as a positive voltage terminal, which is set to a positive voltage V CC , terminal 2 is a negative voltage terminal, terminal 3 is a positive data terminal, terminal 4 is an identification (ID) terminal, and terminal 5 is a reference terminal, which is set to a ground potential. Positive voltage V CC The positive data terminal is configured as the first data port or data port 1, and the ID terminal is configured as the third port or compatibility signal port. The ID terminal is configured to be biased at the compatibility signal level, and the compatibility signal level can be different from V CC , for example, is 3.675V.

[0053] In an example embodiment, after the physical key has been physically and electrically engaged with the lock, the lock controller will perform a pre-process via the ID terminal and then perform a first process via the first data port. The first process may be performed using a USB data communication protocol.

[0054] During the execution of the first process, the key may send the lock's identification parameter to find the lock's presence. When the lock receives an incoming data message corresponding to the incoming query for finding the lock's presence, the lock will send a confirmation response upon detecting its own identification parameter, which may include its identification parameter to show presence. In an example embodiment, the MAC address is used as the identification parameter because it is unique enough, and the sent identification parameter is not encrypted.

[0055] The physical key or host may include a plurality of soft keys for operating the corresponding plurality of locks, and the user may select one of the stored soft keys to pair with the target lock so as to communicate lock instruction data with the target lock.

[0056] After completing the first process, the lock controller will announce using the BLTE protocol and the physical key will establish a data communication connection with the lock, whereby lock instructions are sent by the key controller and response commands are sent by the lock controller, all via the second data port and with the help of wireless data communication.

[0057] In the secure version of the lock, the lock instructions and response commands are encrypted using an encryption key.

[0058] In an example embodiment, the encryption key (and decryption key) used by the physical key has a higher authorization level and is different from the encryption key (and decryption key) used by the host machine. The encryption key with the higher authorization level is referred to herein as the Admin key, while the encryption key used by the host has a lower authorization level and is referred to as the User key. Admin commands may be used for the Admin key and may be used for the User key to avoid conflicts or to enhance lock security.

[0059] In an example embodiment, the lock will require management key encrypted lock instructions when detecting a physical key in data communication with the lock via the first data port and ignore user key encrypted lock instructions when detecting a physical key in data communication with the lock via the first data port.

[0060] In an example embodiment, data communication via the first data port and data communication via the second data port use different communication standards or protocols. For example, data communication via the first data port can follow USB protocol or NFC protocol, while data communication at the second data port can be based on Bluetooth (RTM) protocol.

[0061] In an example embodiment, the physical key is configured to provide operating power to the lock when the physical key is in physical and electrical contact with a key interface of the lock. For example, when the lock detects that the physical key is physically engaged with its key interface, the lock controller can be operated to switch the power management circuit system so that the lock mechanism operating power is supplied by the physical key rather than by the lock's internal stored power.

[0062] In the case where the lock is configured for more secure operation, the physical key is provided with a management key and the lock instructions transmitted via the second data port are encrypted using the management key. If the physical key with the management key is removed from the physical connection with the key interface after completing the first process and before completing the second process, the lock controller is configured to operate to abort the second process. The lock controller can be configured to continuously monitor the compatibility signal port to determine the continued presence or absence of the physical key.

[0063] In an example embodiment, the physical key carries a management key, which may be easily known by the lock, for example, identification parameters of the physical key may already be stored on a database of the lock.

[0064] User keys or management keys (collectively referred to as "keys") can be pre-stored in the lock, and keys can be set for the lock later. Keys set later are beneficial, for example, when the ownership of the lock changes, the key can be changed.

[0065] The key can be set or reset through the collaboration between the master key, the host running the APP, and the server. The master key can be a physical key that is pre-stored with the default key and identification parameters of the lock. The default key and identification parameters of the lock are also stored in the lock and on the server that hosts the default keys of many locks. The default key ("DefaultKey") is an encryption key, or more specifically, a reserved encryption key that is reserved for setting management keys and user keys.

[0066] In order to obtain the key retroactively, the host will need to communicate with the server in order to obtain the key. The information provided by the host to the server will include the identification parameters of the lock, such as its MAC address. The MAC address is used as a convenient example of an identification parameter in this example, and where appropriate, references to MAC here can be interpreted as references to identification parameters. Upon receiving the request, the server will return the key encrypted with the default key to the host. After the host receives the key encrypted with the default key, the host forwards the encrypted key to the lock and key, and the lock and key will retrieve the key by decrypting using the default key.

[0067] The encryption key can be sent by the command Set_Key_Req, and based on the UUID of the command, the lock controller or key controller will recognize that this is a key establishment command and will use the default key to retrieve the key, which is the second encryption key, and the default key is the first encryption key.

[0068] The example lock 100 includes a lock mechanism, a drive mechanism, an electronic circuit system including a controller and peripheral circuits including an encryption / decryption engine, a wireless data communication front end, a key interface, a power management circuit, and a main housing, such as Figure 1A shown.

[0069] The wireless data communication front end is configured for wireless transmission and wireless reception of data and includes a radio frequency transceiver (TX) and an antenna. The radio frequency transceiver is electrically connected between the controller and the antenna so that the controller can receive and send data via the antenna.

[0070] The lock mechanism includes a locking mechanism that can be operated between a first state as a locked state and a second state as an unlocked or open state. When the lock mechanism is in the locked state, the locking mechanism is physically engaged with the locking port. When the lock mechanism is in the unlocked state, the locking mechanism is disengaged or released from the locking port.

[0071] The drive mechanism is configured to drive the lock mechanism to move between a locked state and an unlocked state, and its operation is controlled by the controller.

[0072] The lock controller (or lock controller) is configured to send and receive instructions to the drive mechanism to operate the lock mechanism, receive data, process received data, retrieve data, transmit data, send control signals to operate the drive mechanism, and perform other control, communication and data processing functions without loss of generality.

[0073] The key interface is optional and is configured to interact with a physical key (eg, a hard key of the present disclosure that is a physical key and includes a key entry that is a key interface port).

[0074] The controller includes a solid-state microprocessor with built-in memory and peripheral circuitry. The memory includes volatile memory and non-volatile memory, and the controller can be implemented as a control circuit including the microprocessor and the peripheral circuitry and memory.

[0075] The power management circuit is configured to manage power for operation of the lock. In the case where the lock is a portable lock, the power management circuit includes a portable power source (e.g. a battery, in particular a rechargeable battery, such as a lithium-ion battery), a charging circuit for charging the power source, and optionally a battery charging port for connection to the charging power source. In the case where the lock is a fixed lock, the power source may include a rectifier circuit for converting AC mains power into DC operating power. A fixed lock in this context refers to a lock that is installed as a fixed device and forms part of the fixed device, such as part of a door or gate.

[0076] The power management circuit may include a power selector for selecting a power source from a plurality of available power sources. For example, the power selector may be configured to select an external power source, such as power from a hard key when the hard key is in keyed connection with the lock. The power selector may include a power switch operable by the controller to switch power to the lock mechanism between the power sources.

[0077] The main housing may be constructed of a rugged and tamper resistant material and define an interior compartment within which components such as electronic circuitry and a power supply are housed.

[0078] The locking port is formed on or mounted inside the main housing and may have a rigid recessed portion wherein the key interface is configured as a female connector.

[0079] The movable portion of the locking mechanism is hidden within the main housing, and the movable portion of the locking mechanism can be exposed from the main housing. For example, when in a locked state, the locking port is inside the main housing, and the movable portion of the locking mechanism is exposed outside the main housing. When changing from a locked state to an unlocked state, the movable portion can retreat or advance toward the main housing to release the physical engagement with the main housing. In an example embodiment of a portable lock, the movable portion can include a pivoting hook, and in an example embodiment of a fixed lock, the movable portion can include a latch.

[0080] The lock controller is configured to receive instructions, process the received instructions and perform operations according to the received instructions. The instructions are exchanged between the lock and the corresponding device through a data communication channel in a data communication scheme. The instructions are in the form of data messages, and each data message is a command message (or simply a message). Each message is a data string, and the message is preferably an encrypted message to enhance security. Upon receiving one or more encrypted command messages, the controller operates to decrypt one or more messages and retrieve the embedded instructions. The AES 128-ECB encryption and decryption algorithm can be used as an example encryption and decryption algorithm.

[0081] Command messages may have different attributes or characteristics and are categorized according to the function or purpose of the message.

[0082] In an example embodiment, the controller is configured to receive and process example multiple three categories of operating instructions, namely, a first category of user-oriented messages (or simply referred to as "user messages"), a second category of management-oriented messages (or simply referred to as "management messages"), and a third category, which is a reset message for resetting the lock to factory settings.

[0083] For example, a user message has a user message characteristic and is configured to convey an operational instruction such as "open lock", "close lock", etc. An administrative message is configured to deliver administrative instructions, such as setting an operational parameter, an operational setting, obtaining a log record or other data, such as date and time information and battery status.

[0084] User messages can be encrypted with a user key (symbol: "USR_KEY") or an administration key (symbol: "ADM_KEY" or simply "administration key"), and administration messages are encrypted with the administration key).

[0085] Each lock has a unique identification, and no two locks are configured to have the same identification. The unique identification is intended to be used as a means of identifying the lock, and may be built in at the time of manufacture. The unique identification may be in the form of an identification code used by a machine to identify the lock. The lock's MAC (Media Access Control), such as the controller's MAC address, may conveniently be used as the lock's identification code.

[0086] The identification code of the lock may be printed on the outer surface of the lock or may be separate from the lock. The identification code may be presented in the form of a machine-readable code, such as a QR code, a barcode, or other forms of digital code. For example, the identification code may be encrypted by encrypting a hashed MAC address using a soft key.

[0087] The lock can be operated by a hard key or a soft key. The soft key here is an invisible key that is configured as a data string for the operation of the lock, for example, changing the lock from a locked state to an unlocked state or from an unlocked state to a locked state. The example soft key here is a data string with an example data sequence of an example plurality of 128 binary data bits. The soft key can be sent as a string of electrical data signals by a hard key or by a device ("APP") that pre-stores the soft key and has a wireless data transmitter.

[0088] The hard key here is a physical key. The hard key includes a lock interface for physically contacting or engaging with a corresponding key interface on a lock, and includes a lock interface port.

[0089] An example hard key 200 for operating with a lock includes a controller, a wireless data communication front end, a lock interface, a power source, a power management circuit, and a main housing, such as Figure 2A shown.

[0090] The lock interface includes a lock inlet configured to physically interact with a key inlet of the lock. The lock inlet is configured to be physically compatible with the key inlet of the lock. In an example embodiment, the key inlet and the lock inlet are complementary in shape. For example, the lock inlet may have a first profile and the key may have a second profile that is physically complementary to the first profile. In an example embodiment, the lock inlet includes a protrusion having a first physical profile, and the key inlet has a socket that defines a compartment and has a second physical profile that is physically complementary to the first physical profile.

[0091] The wireless data communication front end includes a radio frequency transceiver (TX / RX) and an antenna, and is configured for wireless transmission and wireless reception of data.

[0092] The radio frequency transceiver is electrically connected between the controller and the antenna, so that the controller can receive data from the antenna and can send data from the antenna to the surrounding environment.

[0093] Without loss of generality, the controller of the hard key (or key controller) is configured to send instructions to the lock, receive data from the lock, process received data, retrieve data, and perform other control, communication, and data processing functions.

[0094] The controller includes a solid-state microprocessor with built-in memory and peripheral circuitry. The memory may include volatile memory and non-volatile memory, and the controller may be implemented as a control circuit including the microprocessor and peripheral circuitry and the memory.

[0095] The power management circuit is configured to manage the operating power of the hard key and includes a charging circuit for charging the power source. The charging circuit is connected to a battery charging port having a connection interface on the main housing for physically connecting to a battery charging power source. In an exemplary embodiment such as the present invention, the battery charging port is adjacent to the lock interface and is an optional form of a USB Micro-B female connector. The key's power source is also configured to power the operation of the lock in certain circumstances, for example, when the key and the lock are in a keyed physical connection. When the lock and the key are in a keyed connection state, it means here when they are in a complementary physical connection state. The key's power source can be a rechargeable battery, for example, a lithium battery including one or more battery cells, such as a CR2032 button battery.

[0096] Each lock has a built-in soft key that is fixed or embedded in the lock when it is manufactured. In an exemplary embodiment, the soft key is flashed into the lock's non-volatile memory or ROM. The built-in soft key is the only key for the lock and is conveniently referred to as the default key here.

[0097] Each lock has a hard key that is paired with the lock. The lock and the paired hard key (conveniently referred to as a master key in this article) can be delivered to the purchaser at the time of delivery or when leaving the factory.

[0098] A copy of the default key is saved on the master key. The default key may be attached to the master key at the time of manufacture. For example, the default key may be flashed into the non-volatile memory or ROM of the key.

[0099] A copy of the default key is also stored on a secure host. The host may be a host server that operates a host website to provide customer support or user support and has a database of locks, their characteristics, and their default keys. Upon successful registration or satisfactory fulfillment of authentication requirements, a copy of the default key may be downloaded from the host.

[0100] In example embodiments such as the present invention, the lock and master key do not have a valid or usable user key in the manufacturing or factory state. In such embodiments, the user key and master key of the lock can be pre-set to a factory default value, such as invalid or INVALID, at the factory. Similarly, the default key can be pre-set to the administrative key in the factory state. When the lock is initialized, the default user key and the default administrative key can be replaced by a new user key and a new administrative key, respectively.

[0101] For example, when a user uses the lock for the first time, the user will perform an initialization process. In order to initialize the lock for operation, the user will send an initialization request to the host server to request activation of the lock. Upon receiving the initialization request, in response, the host server will send a set of soft keys to the owner. The set of soft keys may include a user key and an administrative key. Each of the user key and the administrative key is a soft key. The example soft key here is an encoded data string formed by directly or indirectly encrypting a default key. Upon receiving the soft key, the owner will be able to use the soft key to operate the lock.

[0102] After the initialization process has been completed, the lock is ready for use by the user in possession of the soft key.

[0103] To operate the lock, the user will send a command to the lock. When receiving the command, the lock will respond to the command and execute it accordingly.

[0104] The instruction can be a user instruction or a management instruction. The user instruction is included in the user message, and the management instruction is included in the management message.

[0105] User messages can be encrypted with either the user key or the administration key, while administration messages are encrypted with the administration key.

[0106] When receiving the command, the lock will check and determine whether the command carries a valid key. If the command carries a valid key, the command will be regarded as a true command, and the lock will perform the predetermined operation according to the command.

[0107] The example message has four example message parts, namely, the first part is "serial number", the second part is "command", the third part is "data", and the fourth part is "CRC" (cyclic redundancy check). The example message has a 16-byte format and contains 128 binary data bits, and is encrypted by a key to form an encrypted message, such as Figure 3 Schematically shown in .

[0108] In an example setup, a user will use a data communication device such as a smart phone to download application software ("APP") from a host website. The data communication device includes a controller, a memory, a user interface, and a telecommunications front end. The telecommunications front end includes a data communication front end, which includes a wireless data transceiver. The data communication device may include a display such as a touch panel screen. The example data communication device may run on an operating system such as AndroidTM or iOSTM.

[0109] After downloading the App, the App resides on the memory of the data communication device as stored instructions and is ready to execute. The user can operate the data communication device to execute the stored instructions to run the App and send the lock's identification code to the host website to request activation.

[0110] In an example embodiment, the data communication device includes an image capture device such as a digital camera, and the App includes image capture and processing routines. To initiate an activation request, a user activates the App on the data communication device. Upon activating the App, the data communication device operates to execute stored instructions to capture an image of the identification code, process the image, and retrieve the identification code from the processed image.

[0111] In some embodiments, the identification code is in a human-readable form, and the data communication device includes a user interface for a user to input the identification code. Upon receiving the human-readable identification code, the data communication device running the App will determine the authenticity of the identification code.

[0112] The host server, upon checking the request and the identification code accompanying the request, will determine whether the received code is the true identification code of the lock when executing the stored instructions. If it is determined that the received code is the true or authentic identification code of the lock, the host server sends the soft key to the requesting device or the electronic account designed by the request. In some embodiments, alternatively or in addition, the host server sends a copy of the soft key to a specified or registered account. In the event that the lock has been activated before, indicating that a new user has replaced the old user, the host server will deactivate the previous or old soft key and notify the lock of the change in the state of the soft key by sending a copy of the new soft key to the lock. For example, when a new soft key is received, the lock is notified of the change of user or owner, and the lock will update its record, including the deactivation or abandonment of the old soft key.

[0113] A copy of the soft key may be stored on a hard key, on a smart phone, or on a data communications device configured to operate as an electronic key to the lock according to the user's selection or preference.

[0114] Data communications between the data communications device and the lock may be in two example forms of data packets.

[0115] The first example form is a command packet having the example format shown in Table 1:

[0116] Table 1

[0117] Command Grouping:

[0118]

[0119] The second example form is a response packet having the example format of Table 2:

[0120] Table 2

[0121] Response Grouping:

[0122]

[0123]

[0124] This lock is used to send out a response packet when a command packet is received.

[0125] The lock supports multiple services, including, for example, device information, device services, and other services. Each type of service has a universal unique identifier (UUID) plus a number of supported features.

[0126] The device information is configured to provide fixed information of the lock. Fixed information refers to data that is fixed or embedded in the lock when it is manufactured. The example device information service uses a 16-bit UUID and includes a number of read-only ("R") information of the lock. Example readable information can include the identity of the manufacturer, the model of the lock, the lock serial number, and other useful information such as hardware version, firmware version, and software version.

[0127] The lock (DEV) supports a variety of services, and example services and some properties are shown in Table 3 below.

[0128] Table 3

[0129] name Data direction property encryption Number of bytes Device Status DEV→APP R / N none 2 Reset message APP→DEV WO / N DEFAULT_KEY 16 User Message APP→DEV WO / N USER_KEY 16 Management Messages APP→DEV WO / N ADMIN_DEY 16 Device Configuration APP→DEV WO none 16

[0130] The lock status is read-only and is configured to inform the host (or "APP") of the state of the lock, that is, whether the lock is in a locked state or in an unlocked or open state. The lock status has an example data length of one byte and has a binary value, such as 1 or 0.

[0131] The reset message is an example command packet and is configured to reset the lock to its factory mode. When the lock is in factory mode, the lock is reset to factory settings. The reset message is the highest level control command requiring the highest level of security and is encrypted by the default key.

[0132] A user message is an example command packet and is configured to operate a lock, for example, to change the lock from a locked state to an unlocked state and / or from an unlocked state to a locked state. A user message is a user-level or operation-level control command encrypted by a user key or an administrative key. The user key (USR_KEY) is set to an invalid example value in a factory state or factory mode and may have an example 16-byte hexadecimal value.

[0133] An example of a command message having management message characteristics is set forth in Table 4 below.

[0134] Table 4

[0135]

[0136] The Open_Lock command is configured to be sent by the APP. This command has an example command and response data format as shown in Table 9 below.

[0137] Table 5

[0138] OPEN_LOCK Command

[0139]

[0140]

[0141] response

[0142]

[0143] In response to the command, the lock controller will open the lock and send a response to notify that the lock has been opened.

[0144] The Open_Lock_Master_Key command is configured to be sent by the master key and has an example format as shown in Table 6.

[0145] Table 6

[0146] OPEN_LOCK_MASTER_KEY command

[0147]

[0148] response

[0149]

[0150] After the lock is opened by issuing the Open_Lock_Master_Key command via the master key, the time the lock was opened and the identity of the master key will be recorded by the lock, and the recorded date will be saved on the lock and retrievable.

[0151] The Set_timing command is a management command to set the motor forward (FWD) time, set the motor reverse (REV) time, or disable the advertising timeout value. This command has the example command and response data format shown in Table 7 below.

[0152] Table 7

[0153] SET_TIMING Command

[0154]

[0155] response

[0156]

[0157] The Get_timing command is a management command used to get the motor forward (FWD) timing, set the motor reverse (REV) timing, or disable the advertising timeout value.

[0158] The Reset_Seq_Num command is both a management command and a user command to reinitialize the sequence number, and has an example format as shown in Table 8 below.

[0159] Table 8

[0160] RESET_SEQ-NUM command

[0161]

[0162] response

[0163]

[0164] The Set_Admin_Key command is an administrative command that will be used by the APP to set the admin key. The admin key is an important encryption key used to encrypt management messages and has an example data length of 16 bytes. The example process of setting a new admin key is divided into three example stages. In the first stage, the APP will send the first part of the new admin key to the lock. Upon receiving a response message from the lock indicating that the first part of the admin key has been received, the APP will send the second part of the new admin key to the lock. Upon receiving a response message from the lock indicating that the second part of the new admin key has been received, the APP will then send Set_Key_Finish to the lock to indicate that the new admin key setup is complete. During the new admin key setup, the old or existing admin key will be used for data encryption and decryption.

[0165] In the first stage, the lower 8 bytes of the new management key will be sent to the lock, after the lock has responded with a confirmation message, in the second stage, the upper 8 bytes of the new management key will be sent to the lock, and in the third stage, the SETADMOK message is sent by the APP. After the new management key has been set, the new management key will be used subsequently until another new management key is set.

[0166] The Set_User_Key command is an administrative command to be used by the APP to set the user key. The user key is an important encryption key used for user message encryption and has an example data length of 16 bytes. The example process of setting a new user key is divided into multiple three stages of the example. In the first stage, the APP sends the first part of the new user key to the lock. When the APP receives a response message from the lock indicating that the first part of the user key has been received, the APP sends the second part of the new user key to the lock. When the response message is received from the lock indicating that the second part of the new user key has been received, the APP will then send Set_Key_Finnish to the lock to indicate that the new user key setup is complete. During the new user key setup, the old or existing administrative key will be used for data encryption and decryption. The command has an example command and response data format as shown in Table 10 below.

[0167] Table 9

[0168] SET_USER_KEY command

[0169]

[0170] response

[0171]

[0172] In the example shown in Table 9, in the first stage, the lower 8 bytes of the new user key will be sent to the lock, after the lock has responded with a confirmation message, in the second stage, the upper 8 bytes of the new user key will be sent to the lock, and in the third stage, the APP sends a SETUSROK message. After the new management key is set, the new management key will then be used until another new management key is set.

[0173] The Get_User_Key command is a management command that the APP will use to obtain the user key from the lock.

[0174] Figure 4A An example physical lock 100 implemented in the form of a padlock is shown. Figure 5A An example hard key that is paired with a lock during manufacture is shown in FIG. The hard key that is paired with a lock during manufacture is a master key (“Master Key”) here.

[0175] The lock 100 comprises a main housing, which is a hard and strong metal housing, in which a drive mechanism, a part of a lock mechanism, a controller, a wireless data communication front end, a key interface and a power management circuit are housed. The lock mechanism comprises a lock arm movable between a locked position and an unlocked position. The lock arm comprises a first portion, which is permanently housed in the metal housing and is pivotally movable relative to the main housing and about its axis. The first portion of the lock arm is an axial portion movable between a locked position and an unlocked position in the axial direction of its axis. The first portion has a first recess and moves in its axial direction and away from the locked position towards the unlocked position under the urging of a spring.

[0176] The second part is an axial part offset from the first part and is pivotally movable relative to the main housing and is pivotally movable about the axis of the first part as a pivot axis. The second part is also movable between a locked position and an unlocked position in a direction parallel to its pivot axis and has a second recess. When in the locked position, the second recess is inside the main housing, and when in the unlocked position, the second recess is outside the main housing.

[0177] The lock mechanism includes a lock member movable between a locked position and a release portion.

[0178] When the locking arm is in the locking position and the locking member is in the locking position, the lock is in the locked state and the locking arm is locked in its locking position.

[0179] When the locking member is in the release position, the lock is moved to the unlocked state and the locking arm is moved to its unlocked position by the spring urging force acting on the first portion of the locking arm.

[0180] Reference FIG. 4A to FIG. 4C , the locking member comprises a pair of round heads 102. When the lock is in its locked state, the round heads 102 complementarily engage with recesses on the locking arm 104. The round heads are opposite ends of the locking means and are on the opposite diametrical end of the motor shaft 106. The round heads protrude from the opposite diametrical side of the motor shaft and the locking means extend in a transverse direction orthogonal to the motor axis. The transverse extent of the round heads measured from free end to free end is equivalent to the gap between the recesses of the locking arm.

[0181] The locking device is driven by a drive mechanism to move between a locking position and a release position, such as Fig. 7A and Figure 7B The drive mechanism includes a motor having a motor shaft 106 rotatable about a motor axis and a motor drive circuit. The motor may be a brushless DC motor, and the motor drive circuit may include a drive bridge for driving the motor.

[0182] The motor is electrically connected to a motor driving circuit controlled by a controller. The controller is configured to operate a driving mechanism to drive the motor so as to rotate the locking member between a locking position and a releasing position.

[0183] The Toshiba TC35680 is a Bluetooth low energy (5) single chip controller with built-in flash ROM and is used as an example controller. The wireless transceiver that facilitates Bluetooth (BT) data communications is on the controller so that there is no separate wireless data communications front end if enhanced compactness and cost efficiency are desired. The locking arm is configured as an antenna for wireless signal reception and transmission. The controller and motor drive circuitry are mounted on a printed circuit board ("PCB"). For compactness, the example PCB is mounted on one side of the motor.

[0184] The example lock requires user activation in order to start operating service for the first time after factory delivery. In an example embodiment, the example lock sets its user key to invalid in its factory state and sets its default key to the management key. In order to activate the lock, the first owner of the lock needs to initialize the lock by participating in data communication with the host server and register ownership with the host server. In an example embodiment, the owner can operate a mobile data communication device such as a smart phone to capture an image of the encrypted identification code and send the captured image of the scanned encrypted identification code to the main server. The host server sends the soft key to the user after verifying the authenticity of the identification code, and then the lock is ready for use. The encrypted identification code can be formed by encrypting the hashed MAC address of the lock with the default key of the lock. After the user has the soft key, the user can save the soft key and the identification code of the lock on a master key, a smart phone or other data communication device ("APP") for subsequent use. Multiple user keys for multiple locks can be stored on a single data communication device, and the user can execute the stored instructions to operate the lock. The lock can be assigned a nickname by the user for easy identification and use. The nickname can be, for example, a garage door, a bicycle 1, etc., without loss of generality. The APP may have lock information arranged in the form of a lock table, including identification codes and / or nicknames of the locks, their respective soft keys, and their respective statuses.

[0185] The soft keys saved on the APP may include user keys and / or administrative keys. For example, a user may be granted the right to open and / or close a lock, in which case the user is only given a copy of the user key and not a copy of the administrative key. In the case where the APP is a master key paired with, say, Lock 1 (garage), the APP will have both the user key and the administrative key. Similarly, the APP may be an administrator who is only given administrative rights, in which case only a copy of the administrative key (not the user key) may be given to the administrator's APP. The status "Registered" indicates that the hardware identifier of the hard key has been registered with a specific lock, while "Unregistered" indicates that the hardware identifier of the hard key has not been registered with a specific lock.

[0186] In an example operation, a user activates a dedicated application software (App) on the data communication device 300 to operate the lock. The data communication device, when executing the App, will become an App (or hard key) operable to send a soft key to operate the lock. Initially, the App will begin a wireless scan to query and locate the lock. In response, the lock will send its identification code, which in this example is its MAC address, via wireless data communication in the Bluetooth LE ("BTLE") protocol. The APP will look up its storage when it receives the identification code via BTLE transmission and determine whether the lock can be operated by the stored soft key and paired with the lock. The APP can then use the App and the App's commands to operate the lock.

[0187] In an example operation, a user may operate the lock with a master key that is in physical contact with the lock.

[0188] refer to Figure 4B , the example lock has a USB port 108 on its main housing, and the master key has a compatible and complementary USB portion on its main housing, so that the USB port on the lock and the mating USB port on the master key can be brought into mating engagement. In this example, the key interface port of the lock has the form and configuration of a USB Micro-B female connector, and the lock interface port of the key has the form and configuration of a USB Micro-B male connector, which can physically engage with the key interface of the lock.

[0189] The example lock interface port 202 of the key 200 includes an example plurality of five key interface terminals (or pins), and the pins have the same description as the terminals of the USB connector herein.

[0190] The example lock is configured to monitor the state of the identification terminal of the key interface. When the state of the identification terminal indicates that a hard key compatible with the lock is present, the lock will start data communication and will communicate data through the data communication terminals, namely terminals 2 and 3.

[0191] In an example embodiment, a signature identification voltage present at the identification terminal will wake up the lock. When the lock is woken up by the signature identification voltage, the lock will proceed to initiate data communication through the key interface terminals.

[0192] In an embodiment of the present invention, the data communication performed through the key interface is wired data transmission, for example, performed in serial form through a serial port protocol.

[0193] In an example embodiment, data exchange over the key interface is limited to non-secure data, such as device identification data, for example, MAC addresses or serial numbers of the lock and hard key.

[0194] When the lock's identification data is received by the hard key, the hard key will look up its lock table and determine if the lock is an eligible lock for the hard key. An eligible lock is a lock on the hard key's lock table.

[0195] If the lock is on the lock list of the hard key, which means that the lock is ready to be operated by the hard key, the hard key will switch to wireless data communication with the lock. In example embodiments such as the present invention, since both the lock and the hard key are Bluetooth enabled, the BTLE protocol is used to facilitate wireless data communication. In some embodiments, the lock and the hard key can be configured to facilitate data communication using other wireless data communication protocols without loss of generality. If the lock is not on the lock list, the hard key will shut down its power output to conserve power.

[0196] After the lock has sent out its device identification data, the lock will switch to discoverable mode in order to be discovered, and the hard key will perform a scan and search for a matching Bluetooth device with device identification data for Bluetooth pairing. Once the lock is found by the hard key, the hard key will initiate a connection request to establish a Bluetooth data connection, for example via a standard Bluetooth "Just-Works" model.

[0197] When the lock establishes a wireless data connection with the hard key, the hard key queries its lock table to check whether the hard key has previously operated the lock. If the hard key has previously operated the lock, the lock will have a "registered" status assigned on the lock table. Otherwise, the lock will not have a "registered" status and may have, for example, a "not yet registered" status. If the lock does not have a "registered" status, indicating that the hard key has not been previously operated, such as to open or close the lock, the hard key will send an instruction to request the lock to add or include the hard key as a qualified hard key, and the instruction may include the device identification data of the hard key. The instruction may have a command name "Add_Master-Key".

[0198] After the lock has received and accepted the "Add_Master-Key" command, hard key #6 with the example MAC address is approved as a qualified hard key for operation of the lock, and the lock will update its key table.

[0199] After acceptance and table updates have been completed, the newly authorized hard key will be entered into the lock's key table and assigned a "valid" status, and the lock will send a confirmation to the hard key. The "valid" status means that the hard key has passed the authorization process and is therefore operational. When the hard key is on the key table and assigned a "valid" status, the authorized hard key can create an operational command (e.g., a Lock_Open command to open the lock) and send it to the lock.

[0200] On the other hand, if the lock is on the lock table and has a "registered" status, which means that the hard key has been previously registered with the lock and the lock has a record of the hard key's identification code on its key table, the lock will communicate with the hard key and obtain operating commands from the hard key, subject to an authenticity check of the operating commands.

[0201] In some embodiments, the hard key may be configured to verify its status to the lock even if it is on the lock table and has a "registered" status, since the "registered" status may become outdated due to an intervening event, such as an intervening registration of a new owner or an intervening disabling of the hard key.

[0202] In an example embodiment, the hard key may be configured to send a command requesting verification of its status relative to the lock. The command may have a code named "Key_valid_Check_Request".

[0203] In response, the lock will send a Key_valid_Check_Response.

[0204] If the return value of Key_valid_Check_Response indicates that the hard key is valid, the hard key can send an operation command such as Lock_Open_Request to open the lock.

[0205] Upon receiving a command such as an encrypted Lock_Open_Request message, the lock will decrypt the message using the user key that sent the command to extract the hard key embedded in the command. If the decryption is successful, the lock will proceed to perform the operation specified by the command.

[0206] In an example embodiment, the controller of the lock is configured to switch the operating power of the lock from the built-in power supply to the hard key. In such an embodiment, the controller includes a power switching circuit. The power switching circuit can be controlled by the controller or the built-in power control circuit.

[0207] For example, when a characteristic voltage indicating that a hard key has been inserted is detected at the key interface of the lock, the controller or power switching circuit will recognize the characteristic voltage as an identification signal of the hard key, and operate to change the power supply so that the operating power of the lock is provided by the hard key rather than by the internal power supply of the lock, in order to save the power of the lock, thereby extending the time before charging. The example hard key may have a button preset on the main housing for operating the lock. Without loss of generality, the preset buttons may include a "lock" button, an "unlock" button, and / or other functional buttons. The buttons here may be mechanical buttons or electronic buttons, such as sensing tags on a panel.

[0208] The hard key can remotely operate the lock, for example, using the BTLE protocol, i.e., there is no physical contact between the lock and the hard key. For example, the master key can remotely operate its default lock without having the lock interface and the key interface in mating engagement. In an example embodiment, the master key may have one or more default buttons assigned for remote operation of the default lock. The default lock ("Default Lock") herein is a lock paired with the master key at the time of manufacture or delivery. For example, if only one lock is stored or registered on the hard key and / or is in an activated or valid state, the key controller will start wireless data communication with the controller of the lock when detecting an operation signal at a preset button, and perform operations according to command instructions. For example, when the default lock is the only lock stored or registered on the master key, pressing the preset button on the master key will result in the operation of the default lock. In an example embodiment, the controller will determine whether there is only one operable lock stored on the hard key when detecting the operation signal of the preset button, and if it is determined that there is only one operable lock, the operable lock continues to be operated.

[0209] Valid soft and hard keys can be updated remotely from time to time.

[0210] For example, if a hard key is reported lost, the APP may execute stored instructions, such as a remove key or disable key command, and the lock will remove or disable the key upon receiving the instruction.

[0211] Alternatively, or in addition, the APP can execute stored instructions to change the user key and the management key, and notify the lock to update the change. As a result, outdated keys with outdated user keys and management keys will no longer pass the decryption process.

[0212] In an example embodiment, authentication of the device identification data is accomplished via a contactless method, such as near field communication (NFC). Fig.11 , an example electronic lock is an NFC tag, and an example electronic key is an NFC reader. The NFC tag is a passive device, which means that it operates without its own power source during the authentication phase. If no activity is detected for a predetermined period of time, it enters a sleep mode, thereby conserving power. When the key approaches the lock, connectivity and authentication are initiated.

[0213] While the present disclosure has been made with reference to examples and embodiments, the examples and embodiments are non-limiting and are not intended to limit the scope of the present disclosure.

[0214] For example, the lock can be implemented as a lock of a smart safe, a door lock, or a FIG. 12A to FIG. 15BOther forms shown. The terms user key (UserKey and User Key) can be used interchangeably, and the terms administration key (AdminKey and Admin Key) can be used interchangeably.

Claims

1. A lock comprising a controller, a data storage device, a lock mechanism operable by the controller in a locked state or an unlocked state, and a data communication front end comprising a first data port and a second data port; in, The controller is configured to enter data communication via the second data port after data communication via the first data port is successfully completed; wherein the controller is configured to execute a first process through the first data port before entering a second process through the second data port, wherein the first process is a verification process, during which the controller operates to determine whether data entering from the first data port meets verification requirements, If the result of the verification process is positive, that is, successful, the controller determines that the data entering from the first data port is from a qualified object, and the controller proceeds to the second process, which is an instruction process. And wherein, if the result of the first process is negative, ie, unsuccessful, the controller will not perform the second process.

2. The lock according to claim 1, wherein: The controller is configured to receive identification data via the first data port and to receive operational data messages via the second data port, and wherein the controller is configured not to receive operational data messages via the second data port if the identification data received via the first data port does not meet admission criteria.

3. The lock according to claim 1 or 2, wherein: The controller is configured to communicate unencrypted data via the first data port and to communicate encrypted data via the second data port.

4. The lock according to claim 1, wherein: The first data port is a data port configured for wired data communication or wireless data communication, and the second data port is a data port configured for wireless data communication.

5. The lock according to claim 1, wherein: The first data port is configured for wireless data communication or baseband binary data communication at a first modulation frequency, and the second data port is configured for wireless data communication at a second modulation frequency.

6. The lock according to claim 1, wherein: The first data port is configured for near field data communication and the second data port is configured for non-near field data communication.

7. The lock according to claim 1, wherein: A code is pre-stored in the lock, and the controller is configured to respond by transmitting the code upon detecting the code entering from the first data port.

8. The lock according to claim 7, wherein: The code includes a unique identification code for the lock, and the controller is configured to respond by transmitting the code via the first data port.

9. The lock according to claim 1, wherein: A first encryption key as a built-in encryption key is permanently stored on the lock, and the controller is configured to use a second encryption key to retrieve lock operation instructions including locking and unlocking instructions, and wherein the controller is configured to use the built-in encryption key to retrieve the second encryption key.

10. The lock according to claim 9, wherein: The second encryption key is embedded in a data message received via the second data port, and the data message is encrypted using the built-in encryption key as a default encryption key.

11. The lock according to claim 1, wherein: The lock includes a third port, and the controller is configured to detect and measure a compatibility signal at the third port, and wherein the controller is configured to start data communication via the first data port if the compatibility signal satisfies an access criterion as a first access criterion, and not to participate in data communication via the first data port if the compatibility signal at the third port does not satisfy the first access criterion.

12. The lock according to claim 11, wherein: the compatibility signal is a DC signal having a DC voltage, and the controller is configured to continue data communication via the first data port if the DC voltage at the third port is at a specific voltage level or within a specific voltage range; And / or wherein the controller is configured to continue data communication via the first data port if the DC voltage at the third port is higher than the specific voltage level or is not within the specific voltage range.

13. A lock according to claim 11 or 12, wherein: The controller is configured to stop data communication via the first data port and / or the second data port when the compatibility signal stops satisfying the first admission criterion.

14. The lock according to claim 11, wherein: The lock includes a key interface for receiving a pair of physical keys, and wherein the key interface includes the first data port and the third port.

15. The lock according to claim 14, wherein: The lock includes a power management device, and the controller is configured to operate the power management device to switch to receiving lock mechanism operating power from the physical key when the physical key is physically and electrically connected to the key interface.

16. The lock of claim 1, wherein: The controller is configured to perform wired data communication via the first data port to determine admissibility and to switch to wireless data communication via the second data port if positive admissibility is determined during the wired data communication.

17. An electronic key comprising a key controller, a data storage device, a power supply, and a data communication front end comprising a first data port and a second data port; wherein: The electronic key is a physical key having a key body and is configured to work with the lock of any preceding claim.

18. The electronic key according to claim 17, wherein: The key controller is configured to send identification data via the first data port and, upon receiving a positive response indicating admissibility via the first data port, transmit an operational data message via the second data port.

19. The electronic key according to claim 17, wherein: The key controller is configured to conduct unencrypted data communications via the first data port and to conduct encrypted data communications via the second data port.

20. The electronic key according to claim 17, wherein: A first encryption key as a built-in encryption key is permanently stored on the key, and the key controller is configured to encrypt the lock operation instructions using a second encryption key before sending the lock operation instructions to the lock.

21. The electronic key according to claim 20, wherein: The second encryption key is received via the second data port in the form of an encrypted message, and the key controller is configured to retrieve the second encryption key using the built-in encryption key.

22. The electronic key according to claim 17, wherein: The key comprises a lock interface configured for pairing connection with a key interface of the lock, wherein the key interface comprises the first data port and a third port, and wherein the third port is set at a DC voltage as a compatibility signal.

Images