Unlocking management system, receiver, management server and program

Abstract

In a configuration where unlocking is managed using a management server, a door equipped with a receiver capable of short-range communication, and a mobile terminal capable of short-range communication with the receiver, the present invention provides a technology that reduces the possibility of unauthorized unlocking due to retransmission while maintaining the regular updating of the unlock password. [Solution] This is an unlocking management system comprising a management server, a door equipped with a receiver, and a mobile terminal capable of short-range communication with the receiver. When the authentication process is successful, the receiver sends a challenge value to the terminal and requests the input of an unlock password. The terminal generates verification information, including a challenge value and a message authentication code, based on the entered unlock password and the challenge value, and sends it to the management server. The management server recalculates the message authentication code, and when it determines that the recalculation result matches the message authentication code included in the received verification information, it sends an unlock permission signal to the receiver, and the receiver unlocks the door accordingly.

Description

Technical Field

[0001] The present invention relates to an unlocking management system for managing door unlocking, a receiver, a management server, and a program used therefor.

Background Art

[0002] Techniques for managing door unlocking using electronic locks and access control devices have become widespread. For example, in hotel guest rooms and the like, systems that permit entry based on authentication elements associated with possessions such as electronic access keys are widely used. On the other hand, such conventional door access control often allows unlocking with only a single authentication element (such as an electronic access key), and there is a problem that unauthorized entry can occur if the authentication element is obtained by a third party.

[0003] For this reason, proposals have been made to apply multi-factor authentication, which determines access permission based on two or more authentication elements, to door access control. For example, Patent Document 1 discloses a door access control system that permits access based on two or more authentication elements, and aims to alleviate problems with conventional access control that depends on a single element. Further, Patent Document 2 discloses a configuration for an electronic lock with multi-factor authentication, in which a mechanism for detecting the presence of a user, performing preliminary authentication after detection, and then starting another authentication system such as biometric authentication to perform additional authentication is disclosed, and an approach of sequentially requesting authentication elements near the door is shown.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] As described above, applying multi-factor authentication or the requirement of multiple authentication factors to door unlocking is expected to reduce unauthorized unlocking caused by the theft of a single factor. However, in door unlocking operations, short-range communication between mobile terminals and door-side devices, as well as network communication with a management server, are often combined, resulting in an operational model where authentication-related information is exchanged between multiple devices. Therefore, simply increasing the "types" or "number" of authentication factors does not guarantee that each unlocking request is a "legitimate request made on the spot," and there remains the problem that attacks may occur due to the retransmission of information obtained on the communication path.

[0006] Patent Document 1 presents a framework for granting access based on two or more authentication factors and addresses the problems of conventional single-factor authentication. However, in field operations that assume communication between multiple devices, how to ensure resilience on a per-unlock request basis, from the perspective that authentication-related information may be retransmitted if it is acquired at a certain point in time, requires separate consideration.

[0007] Furthermore, while Patent Document 2 describes a step-by-step authentication process that activates another element after detecting the user's presence or performing preliminary authentication, the step-by-step requirement itself does not directly mathematically constrain "situationality," and if the information exchanged between stages can be reused as identical content, there is still room for fraud due to retransmission.

[0008] Furthermore, in actual operation, a management server is used to centrally manage access and unlocking information, and it is desirable to periodically update unlocking information (e.g., unlocking passwords) to reduce the risk of theft. However, while the practice of "periodically updating" unlocking information may be effective from the perspective of long-term resistance to theft, it may not be sufficient deterrent against short-term attacks that occur at the moment an individual unlocking request is made, i.e., attacks that attempt to unlock by resending the previous or past exchange, unless the information changes with each unlocking request and is used for verification. In other words, if the information necessary for unlocking appears on the communication path once and can be resent as the same content, even if the unlocking password is periodically updated, there is a risk that retransmission attacks that occur during the update cycle cannot be eliminated.

[0009] Therefore, the present invention aims to maintain the advantages of centralized management, such as periodically updating the unlock password on the management server side, while ensuring that each unlock request is a "one-time, legitimate request made on the spot" on a per-unlock request basis, thereby reducing the possibility of unauthorized unlocking due to the retransmission of authentication-related information obtained on the communication path. [Means for solving the problem]

[0010] To solve the above problems, the unlocking management system of the present invention comprises a management server, an auto-locking door equipped with a receiver capable of short-range communication, and a mobile terminal capable of short-range communication with the receiver. The management server stores authentication information associated with users who can unlock the door and an unlock password that is updated periodically. The receiver transmits authentication information sent from the mobile terminal to the management server, and the management server performs user authentication processing based on the authentication information. The mobile terminal is equipped with an unlocking application, and when the mobile terminal approaches the receiver, it performs short-range communication with the receiver, activates the unlocking application, and transmits authentication information based on the authentication information to the receiver.

[0011] The receiver generates a challenge value and sends it to the mobile terminal if the authentication process is successful, and also sends a notification to the mobile terminal requesting the input of an unlock password. The mobile terminal accepts the input of the unlock password, generates verification information including the challenge value and a message authentication code based on the entered unlock password and the challenge value, and sends the verification information to the management server. The management server recalculates the message authentication code based on the unlock password and the challenge value, determines the validity of the verification information by checking whether the recalculated message authentication code matches the message authentication code included in the received verification information, and if it is valid, sends an unlock permission signal to the receiver, and the receiver unlocks the door in response to the unlock permission signal. The embodiment is consistent in that the verification information is sent to the management server.

[0012] The challenge value includes a receiver identifier that identifies the receiver. The challenge value may also include expiration information, and the management server may configure itself to only consider verification information received within the expiration period as valid. The verification information may include a message authentication code calculated using the entered unlock password and the challenge value as input.

[0013] The receiver may generate a challenge value only if the authentication process is successful. The receiver may also invalidate the challenge value if it does not receive an unlock permission signal from the management server within a predetermined time after sending the challenge value. Here, the invalidation of the challenge value by the receiver is mainly for locally expiring the challenge value after a predetermined time has elapsed or for other reasons.

[0014] The unlock password may have a limit on the number of times it can be used, and its validity period may be set according to the day of the week and time of day.

[0015] The management server may be capable of performing a batch lock process that prohibits unlocking multiple doors at once based on the authorization identifier corresponding to a user, and may also be capable of releasing the batch lock performed by the batch lock process based on the master authorization identifier. Furthermore, the management server may be capable of performing a user lock process that prohibits unlocking by a user based on the user identifier that identifies the user.

[0016] The door may be equipped with a camera and a motion sensor, and the management server may be configured to acquire images captured by the camera from the receiver when the door is unlocked after the motion sensor detects the presence of a person. In this case, the images may be those taken during a predetermined period from the time the authentication process is successful until the door is unlocked.

[0017] The management server may perform matching using feature quantities calculated from the image and matching information associated with the user. Furthermore, the management server may send an alarm notification if the matching result does not meet predetermined conditions, may record a flag in the unlock history if the matching result does not meet predetermined conditions, or may execute user lock processing if the matching result does not meet predetermined conditions.

[0018] Furthermore, the management server may invalidate the challenge value used in the verification after it has determined that the verification information is valid. Here, the invalidation of the challenge value by the management server is primarily intended to prevent the reuse of the challenge value after the validity determination, and its role differs from local invalidation on the receiver side after a predetermined time has elapsed. The verification information may be generated based on the challenge value, which includes the entered deactivation password and receiver identifier.

[0019] Furthermore, if communication between the management server and the receiver is impossible, the receiver may switch to a preliminary authentication mode, in which case unlocking the door may be permitted only a predetermined number of times. After communication is restored, the management server may acquire the unlocking history from the preliminary authentication mode and invalidate the unlock password if it determines that the unlocking history violates a predetermined policy. This makes it possible to achieve both limited operation when communication is impossible and control after it is restored.

[0020] The present invention may be understood as a receiver constituting the above unlocking management system. This receiver is installed on an auto-locking door, is capable of short-range communication with a mobile terminal, and is capable of network communication with a management server. The receiver receives authentication information from the mobile terminal, transmits the authentication information to the management server, generates a challenge value and transmits it to the mobile terminal if the authentication process based on the authentication information is successful by the management server, and also sends a notification requesting the input of an unlock password, and unlocks the door when it receives an unlock permission signal from the management server. If the receiver does not receive an unlock permission signal from the management server within a predetermined time after transmitting the challenge value, it invalidates the challenge value, and if communication with the management server is further impossible, it may switch to a preliminary authentication mode, in which case the unlocking of the door may be permitted only a predetermined number of times.

[0021] The present invention may be understood as a management server constituting the above-mentioned unlocking management system. This management server manages the unlocking of an auto-locking door equipped with a receiver, stores authentication information associated with users who can unlock the door and a periodically updated unlock password, receives authentication information from the receiver and performs authentication processing based on the authentication information, receives verification information based on a challenge value sent by the receiver to a mobile terminal if the authentication processing is successful, and sends an unlock permission signal to the receiver if the verification information is valid based on the unlock password and challenge value comparison. Furthermore, the management server may acquire the unlocking history of unlocks performed by the receiver in a preliminary authentication mode and invalidate the unlock password if it determines that the unlocking history violates a predetermined policy.

[0022] The present invention may be understood as a program for causing a computer to function as the management server. This program causes the computer to store authentication information and a release password, receive authentication information from a receiver, execute authentication processing based on the authentication information, receive verification information when the authentication processing is successful, and transmit an unlocking permission signal to the receiver when the verification information is valid through collation based on the release password and a challenge value.

Advantages of the Invention

[0023] According to the invention of claim 1, after the primary authentication is successful, the receiver generates a challenge value and transmits it to the mobile terminal. The mobile terminal receives an input of the release password, generates verification information based on the input release password and the challenge value, and transmits the verification information to the management server. The management server recalculates a message authentication code based on the release password and the challenge value, determines the validity of the verification information by comparing the recalculation result with the message authentication code included in the received verification information, and permits unlocking. Therefore, while regularly updating and operating the release password on the management server side, by involving different challenge values in the collation for each unlocking request, it is possible to manage door unlocking using short-range communication while reducing the possibility of unauthorized unlocking due to retransmission of information acquired on the communication path.

[0024] According to the invention of claim 2, by including a receiver identifier in the challenge value, the challenge value and the verification information based thereon can be associated with and handled for the receiver (door), and it is possible to manage unlocking while suppressing diversion to other receivers.

[0025] According to the invention of claim 3, by including expiration date information in the challenge value and determining that only the verification information received within the range of the expiration date information is valid, it is possible to suppress acceptance of verification information that has passed the time limit and further reduce the possibility of unauthorized unlocking due to retransmission.

[0026] According to the invention of claim 4, by configuring the verification information as a message authentication code, it is possible to enhance the ability to detect tampering based on the unlock password and challenge value, and to more reliably determine the legitimacy of the verification information.

[0027] According to the invention of claim 5, if the authentication process is unsuccessful, a notification requesting the input of a deactivation password is not sent. This suppresses prompting the user to input a deactivation password while authentication is incomplete, thereby reliably enabling an operation that requests additional input only after successful authentication, while suppressing unnecessary inputs and fraudulent attempts.

[0028] According to the invention of claim 6, if an unlock permission signal is not received from the management server within a predetermined time after the transmission of the challenge value, the challenge value is invalidated. This prevents the challenge value from remaining in place while the unlocking process is not completed, and allows for operation while suppressing long-term misuse or misinterpretation of the challenge value.

[0029] According to the invention of claim 7, by setting an upper limit on the number of times the unlock password can be used, the number of times the unlock password can be used can be controlled, making it possible to manage unlocking while limiting the impact of excessive or unauthorized use.

[0030] According to the invention of claim 8, by setting an effective period for the unlock password according to the day of the week and time of day, the time range in which unlocking is permitted can be controlled according to operational requirements, and access control with time management of authority can be realized.

[0031] According to the invention of claim 9, since it is possible to perform a simultaneous locking process for multiple doors based on an authorization identifier, it is possible to quickly prevent unlocking across multiple doors in the event of loss, accident, emergency, etc.

[0032] According to the invention of claim 10, since the bulk lock can be released based on the master authority identifier, the bulk lock state can be quickly restored when necessary through emergency release or administrator operation.

[0033] According to the invention of claim 11, since user lock processing based on a user identifier can be executed, it is possible to immediately suspend the privileges of a specific user and to respond flexibly to individual misuse or operational suspension measures.

[0034] According to the invention of claim 12, when the presence of a person is detected by the motion sensor and the door is unlocked, a camera image is acquired from the receiver. This allows the image to be acquired in association with the unlocking event, making it possible to efficiently collect information useful for auditing and security purposes.

[0035] According to the invention of claim 13, by limiting the images to those taken during a predetermined period from the successful authentication process to unlocking, it is possible to acquire images focused on scenes related to unlocking, thereby improving the auditability of unlocking while reducing unnecessary shooting and data volume.

[0036] According to the invention of claim 14, since the matching is performed using feature quantities calculated from the image and matching information, it is possible to perform matching processing related to unlocking events, and audits and verifications that go beyond mere photography are possible.

[0037] According to the invention of claim 15, if communication between the management server and the receiver is impossible, the receiver switches to a preliminary authentication mode and permits unlocking to a predetermined number of times. Therefore, even in the event of a communication failure, it is possible to continue unlocking to the extent necessary for operation while suppressing unlimited unlocking.

[0038] According to the invention of claim 16, after communication is restored, the unlock history is obtained using the preliminary authentication mode, and if a policy violation is determined, the unlock password is invalidated. This makes it possible to retrospectively control exceptional operations in the event of a failure and deter use that violates the operational policy.

[0039] According to the invention of claim 17, the challenge value used in the determination is invalidated after the verification information is determined to be valid, thereby preventing the reuse of the challenge value after the validity determination and further reducing the possibility of unauthorized unlocking through retransmission.

[0040] According to the invention of claim 18, since the verification information is generated based on a challenge value that includes the entered unlock password and receiver identifier, the verification information can be more strongly linked to the receiver (door), and verification can be performed while suppressing its use to other receivers.

[0041] According to the invention of claim 19, an alarm notification is sent when the matching result does not meet predetermined conditions, making it possible to detect suspicious unlocking events early and prompt notification and response.

[0042] According to the invention of claim 20, if the matching result does not meet predetermined conditions, a flag is added to the unlocking history and recorded, making it possible to easily extract suspicious events during subsequent audits and tracking, thereby improving audit efficiency.

[0043] According to the invention of claim 21, a user lock process is executed when the matching result does not satisfy predetermined conditions, so it is possible to prevent the user from unlocking the device if a suspicious unlock is detected.

[0044] According to the invention of claim 22, the receiver alone can generate and transmit a challenge value after successful authentication, invalidate the challenge value if an unlock permission signal is not received within a predetermined time, perform a preliminary authentication mode (limited number of times) in case of communication failure, and perform unlock control. Therefore, the functionality as a door-side device can improve the safety and availability of unlock management.

[0045] According to the invention of claim 23, the management server alone can store authentication information and unlock passwords, perform authentication processing based on the reception of authentication information, receive verification information and perform matching based on the unlock password and challenge value, and transmit an unlock permission signal, so that the unlocking of multiple doors can be managed uniformly through centralized management.

[0046] According to the invention of claim 24, the unlocking history can be obtained using the preliminary authentication mode and the unlock password can be invalidated in the event of a policy violation, thereby enabling retrospective control of limited operation during communication failures and strengthening management based on operational policies.

[0047] According to the invention of claim 25, a program is provided that causes a computer to execute various processes as a management server, making it possible to implement, distribute, and update the management server function as software.

[0048] Furthermore, the aforementioned Patent Documents 1 and 2 do not describe any specific configuration for ensuring that each unlocking request is a "one-time, legitimate request on the spot" while maintaining the advantages of centralized management, such as the unlocking management system, receiver, management server, and program according to the present invention, which involves periodically updating the unlocking password on the management server side, and for reducing the possibility of unauthorized unlocking due to the retransmission of authentication-related information obtained on the communication path. [Brief explanation of the drawing]

[0049] [Figure 1] This is a block diagram showing the overall configuration of an unlocking management system according to one embodiment of the present invention. [Figure 2] Figure 1 is a block diagram showing an example of the functional configuration of a receiver. [Figure 3] Figure 1 is a block diagram showing an example of the functional configuration of the management server. [Figure 4] Figure 1 is a block diagram showing an example of the functional configuration of a mobile device (unlocking application). [Figure 5] This is a sequence diagram showing an example of the unlocking process in an unlocking management system. [Figure 6] This is a schematic diagram illustrating an example of the generation and verification of verification information. [Figure 7] This flowchart shows an example of the process by which the management server determines whether or not unlocking is possible. [Figure 8] This sequence diagram shows an example of image acquisition and matching processing using a human presence sensor and a camera. [Figure 9] This is an explanatory diagram illustrating an example of limited unlocking in the preliminary authentication mode when communication is impossible, and the processing after communication is restored. [Modes for carrying out the invention]

[0050] Embodiments of the present invention will be described below with reference to the drawings. Note that the following description is an example of the present invention, and the present invention is not limited to these examples.

[0051] <1. Definitions of Terms> In this specification, "management server" means a computer (server device or virtual computer on the cloud) that has the function of storing authentication information and unlock passwords associated with a user, performing authentication processing based on authentication information received from a receiver, and verifying the received verification information after the authentication processing is successful and sending an unlock permission signal.

[0052] In this specification, "receiver" refers to a device installed in an automatic locking door, capable of short-range communication with a mobile terminal, capable of network communication with a management server, and having the function of generating a challenge value after successful authentication and sending it to the mobile terminal, and unlocking the door when it receives an unlock permission signal from the management server. The receiver may be built into the door or installed near the door.

[0053] In this specification, "mobile device" refers to a portable computer such as a smartphone, mobile device, or tablet device that is capable of short-range communication with a receiver and can run an unlocking application.

[0054] In this specification, "short-range communication" refers to communication performed between a mobile terminal and a receiver over a short distance (e.g., a few centimeters to a few meters), and is implemented using methods such as Bluetooth Low Energy (BLE) or NFC. The method is not limited to these.

[0055] In this specification, "network communication" refers to communication performed between a receiver and / or a mobile terminal and a management server, and is implemented by, for example, the Internet, a mobile network, a wireless LAN, a LAN, etc. The method is not limited to these.

[0056] In this specification, "authentication information" refers to information associated with a user who can unlock a door, and may include, for example, a user ID, terminal ID, certificate, shared key, public key, token, etc. The specific form is arbitrary.

[0057] In this specification, "authentication information" refers to information generated by a mobile device based on authentication information, transmitted to a receiver, and used by the management server for authentication processing. Authentication information may include the authentication information itself, or it may include tokens, signatures, etc., derived from the authentication information. Authentication information includes at least information that allows the management server to identify the user.

[0058] In this specification, "authentication process" means the process by which the management server determines, based on the authentication information received from the receiver, whether or not the unlocking request is associated with a legitimate user.

[0059] In this specification, “unlock password” means confidential information used to authorize unlocking, which is stored by the management server and may be updated periodically. The unlock password may be a sequence of numbers, a string of characters, or a confidential value held by the application. While the claims of this application assume an unlock password entered by user input (a pre-entered unlock password), the specific form of the unlock password is not limited thereto. In the main aspects of this embodiment, the unlock password is obtained as a pre-entered unlock password by user input.

[0060] In this specification, "validity period" refers to the period during which the unlock password can be used to unlock the device, and may be determined by the day of the week and time of day.

[0061] In this specification, “challenge value” is a value generated by the receiver after successful authentication and transmitted to the mobile terminal, and is generated to be different for each unlock request. The challenge value may function as a one-time value (nonce). The challenge value may include a receiver identifier and / or expiration information. In this specification, “invalidating the challenge value” includes making the challenge value unusable for subsequent verification, which can be achieved, for example, by prohibiting reuse by assigning a used flag or registering it in a used list.

[0062] In this specification, "receiver identifier" refers to identification information that identifies a receiver. The receiver identifier can be implemented as a fixed ID, serial number, public key identifier, etc.

[0063] In this specification, "expiration date information" refers to information that defines the time range in which the challenge value is valid, and can be implemented, for example, by the generation time and allowable time range, or by the expiration time.

[0064] In this specification, "predetermined time" refers to the allowable time from the transmission of the challenge value to the reception of the unlock permission signal, which can be set to a range of, for example, a few seconds to a few minutes.

[0065] In this specification, "verification information" refers to information generated by a mobile device based on the entered unlock password and challenge value, and transmitted to the management server. Verification information may include a message authentication code (MAC) calculated using the entered unlock password and challenge value as input. Here, the MAC can be implemented as, for example, an HMAC, but is not limited to this. Verification information includes the challenge value and the message authentication code calculated based on the entered unlock password for that challenge value.

[0066] In this specification, "unlock permission signal" refers to a signal (data) that the management server sends to the receiver when it determines that the verification information is valid, and which serves as the trigger for the receiver to perform an unlocking operation. The unlock permission signal can be implemented using an permission flag, a signed token, or the like.

[0067] In this specification, "unlocking history" refers to log information that records events related to unlocking (permission / denial, date and time, receiver identifier, user identifier, etc.). The unlocking history may be flagged according to the matching result.

[0068] In this specification, "matching information" refers to reference information associated with a user, and is registration information used for comparison with feature quantities calculated from captured images. Matching information can be stored, for example, as a face feature quantity template associated with a user.

[0069] In this specification, "policy" refers to the rules that the management server uses to determine operational permission or denial, and may include, for example, the maximum number of unlocking attempts during preliminary authentication mode, restrictions on the items to be unlocked, and how to handle mismatches in verification.

[0070] In this specification, "preliminary authentication mode" refers to an operating mode to which the receiver switches when communication with the management server is impossible, and which may permit unlocking to a predetermined number of times.

[0071] <2. Overall Structure (Figure 1)> Figure 1 shows an example of the overall configuration of the unlocking management system. The unlocking management system includes a management server 100, an auto-locking door 200, and a mobile terminal 300. The door 200 is equipped with a receiver 210 and, if necessary, a locking mechanism 230, a motion sensor 240, and a camera 250.

[0072] The management server 100 includes a storage unit 110. The storage unit 110 records at least authentication information, unlock password (periodically updated), verification information, authorization identifier, user identifier, policy, and unlock history.

[0073] The mobile terminal 300 is capable of short-range communication with the receiver 210 and runs the unlocking application 310. The receiver 210 is capable of network communication with the management server 100. Furthermore, the mobile terminal 300 can transmit verification information to the management server 100 via network communication. For example, the mobile terminal 300 can transmit verification information to the management server 100 via a mobile network or Wi-Fi.

[0074] The receiver 210 controls the lock mechanism 230 and unlocks the door 200 in response to an unlock permission signal. The motion sensor 240 and camera 250 may be used for image acquisition and matching associated with the unlocking event.

[0075] The management server 100 may manage multiple doors 200 (multiple receivers 210). In Figure 1, for the sake of explanation, one door 200 is shown as an example, but multiple doors 200 may be installed within the same building, or they may be installed across multiple buildings. The management server 100 can identify and manage each door 200 based on a receiver identifier or the like.

[0076] <3. Receiver Functional Configuration (Figure 2)> Figure 2 shows an example of the functional configuration of the receiver 210. The receiver 210 may include a short-range communication unit 211, a network communication unit 212, an authentication control unit 213, a challenge generation unit 214, a timer unit 215, and an unlocking control unit 216.

[0077] The short-range communication unit 211 communicates with the mobile terminal 300 via short-range communication. The network communication unit 212 communicates with the management server 100 via the network. The authentication control unit 213 transmits the authentication information received from the mobile terminal 300 to the management server 100 and receives and processes the authentication result (success / failure) from the management server 100. The challenge generation unit 214 generates a challenge value (a one-time value generated for each unlock request) if the authentication process is successful. The authentication control unit 213 may transmit the challenge value to the mobile terminal 300 and send a notification to the mobile terminal 300 requesting the input of an unlock password if the authentication process is successful, but may not send a notification requesting the input of an unlock password if the authentication process is unsuccessful.

[0078] The timer unit 215 manages a predetermined time after the transmission of the challenge value and is used to control the system by invalidating the challenge value if it does not receive an unlock permission signal from the management server 100 within the predetermined time. The unlock control unit 216 drives the lock mechanism 230 to unlock the door 200 when it receives an unlock permission signal.

[0079] Furthermore, if communication with the management server 100 is impossible, the receiver 210 may switch to a preliminary authentication mode, and in the preliminary authentication mode, it may perform control to allow unlocking only a predetermined number of times. The number of unlocks during the preliminary authentication mode can be managed by a counter in the receiver 210.

[0080] <4. Functional configuration of the management server (Figure 3)> Figure 3 shows an example of the functional configuration of the management server 100. The management server 100 may include an authentication unit 101, a password management unit 102, a verification unit 103, an access control unit 104, an audit / history management unit 105, and an image processing / verification unit 106.

[0081] The authentication unit 101 performs authentication processing based on authentication information received from the receiver 210 and determines success or failure. The unlock password management unit 102 periodically updates the unlock password and manages operational conditions such as the maximum number of uses and the validity period according to the day of the week and time of day, as needed. The matching unit 103 recalculates the message authentication code using the unlock password and challenge value based on the challenge value and message authentication code contained in the verification information received from the mobile terminal 300, and can determine the validity of the verification information by matching. The authority management unit 104 can perform batch lock processing based on the authority identifier, batch unlocking based on the master authority identifier, and user lock processing based on the user identifier. The audit and history management unit 105 records the unlock history and can record it with a flag according to the matching result as needed. The image processing and matching unit 106 calculates feature quantities from the captured image acquired from the receiver 210 and can compare them with the matching information.

[0082] Here, the management server 100 may, after determining that the verification information is valid, invalidate the challenge value used in the determination (including making the challenge value unusable for subsequent verifications) to make it unusable. Possible implementations of this unusable status include, for example, flag management that records the challenge value (or challenge value identifier) ​​as "used" in the storage unit 110, or registration in a used list.

[0083] <5. Functional configuration of mobile devices (Figure 4)> Figure 4 shows an example of the functional configuration of a mobile terminal 300 (unlocking application 310). The mobile terminal 300 may include a short-range communication unit 331, an application control unit 311, an input reception unit 313, a verification information generation unit 314, and a server communication unit 315.

[0084] The short-range communication unit 331 communicates with the receiver 210. The application control unit 311 activates the unlocking application 310 and controls screen display, etc., upon approaching the receiver 210. The input reception unit 313 accepts the input of the unlock password. The verification information generation unit 314 generates verification information based on the entered unlock password and the challenge value (which may include the receiver identifier). The server communication unit 315 transmits the verification information to the management server 100. As a specific example of the verification information, the verification information generation unit 314 may calculate a MAC for the challenge value using the entered unlock password as a key, and include this MAC in the verification information before transmitting it.

[0085] <6. Overview of the unlocking process (Figure 5)> Figure 5 is a sequence diagram showing an example of the unlocking process in the unlocking management system. Below, the processing procedure performed between the management server 100, receiver 210, mobile terminal 300 (unlocking application 310), and lock mechanism 230 will be described as a representative example.

[0086] When the mobile terminal 300 approaches the receiver 210, the mobile terminal 300 establishes short-range communication with the receiver 210 and activates the unlocking application 310 (step S1). The unlocking application 310 generates authentication information based on the authentication information and transmits the authentication information to the receiver 210 (step S2). The receiver 210 transmits the received authentication information to the management server 100 (step S3). The management server 100 performs authentication processing based on the received authentication information and notifies the receiver 210 of the authentication result (success / failure) (step S4).

[0087] If the authentication process is successful, the receiver 210 generates a challenge value (a one-time value generated for each unlock request), sends this challenge value to the mobile terminal 300, and also sends a notification to the mobile terminal 300 requesting the entry of an unlock password (step S5). On the other hand, if the authentication process is unsuccessful, the receiver 210 does not send a notification requesting the entry of an unlock password. This can prevent prompting the user to enter an unlock password before primary authentication is successful.

[0088] The mobile terminal 300 accepts the input of an unlock password (step S6) and generates verification information based on the entered unlock password and the challenge value received from the receiver 210. The mobile terminal 300 transmits the generated verification information to the management server 100 via network communication (step S7). At this time, the mobile terminal 300 includes the challenge value in the verification information and transmits it to the management server 100. The management server 100 recalculates the message authentication code based on the unlock password and the challenge value, determines the validity of the verification information by checking whether the recalculated message authentication code matches the message authentication code included in the received verification information, and transmits an unlock permission signal to the receiver 210 if it is valid (step S8). When the receiver 210 receives the unlock permission signal, it drives the lock mechanism 230 to unlock the door 200 (step S9).

[0089] Here, the receiver 210 manages a predetermined time using the timer unit 215 after transmitting the challenge value, and if it does not receive an unlock permission signal from the management server 100 within the predetermined time, it invalidates the challenge value. This invalidation can be achieved, for example, by the receiver 210 discarding the temporary area (session information) where the challenge value is held and not performing any further processing based on that challenge value.

[0090] Furthermore, after the verification information is determined to be valid, the management server 100 invalidates the challenge value used in the determination, making it unusable for reuse. For example, the management server 100 may record the challenge value (or challenge value identifier) ​​with a used flag in the storage unit 110, and then refuse to accept any further verifications based on that challenge value. This can suppress the reuse of the challenge value after it has been determined to be valid.

[0091] As described above, by generating a challenge value for each unlock request and involving it in the verification process, the possibility of unauthorized unlocking due to resending past transmissions can be reduced.

[0092] <7. Generation and verification of challenge values ​​and verification information (Figure 6)> Figure 6 is a schematic diagram illustrating an example of the generation and matching of verification information. The following sections will explain specific examples of the challenge value, verification information, and matching by the management server 100.

[0093] The receiver 210 generates a challenge value after successful authentication. The challenge value is generated to be different for each unlock request and may include, for example, a random number (nonce). The challenge value may also include a receiver identifier. That is, the challenge value may be composed of data that combines, for example, a random number and a receiver identifier. The challenge value may also include expiration information. For example, the expiration information can be represented by including the generation time and the allowable time range within the challenge value, or by including the expiration time.

[0094] After receiving the input of an unlock password, the mobile terminal 300 generates verification information based on the entered unlock password and the challenge value. As a specific example of verification information, the verification information may include a message authentication code (MAC). For example, the mobile terminal 300 may calculate an HMAC using the entered unlock password as the key and the challenge value as the message, and send this HMAC value to the management server 100 as verification information. This makes it difficult for someone who does not know the unlock password to generate a valid MAC for the challenge value. For example, the verification information may be calculated as an HMAC (key = entered unlock password, message = challenge value).

[0095] Furthermore, verification information may be generated based on the entered unlock password and challenge value (including receiver identifier). For example, by adopting a configuration that includes the receiver identifier within the challenge value, verification information will be generated in a way that is linked to the receiver (door), which can help prevent its misuse to other receivers.

[0096] The management server 100 receives verification information from the mobile terminal 300, including a challenge value and a message authentication code. Based on the challenge value included in the verification information, it recalculates the HMAC using the unlock password stored in the storage unit 110 as a key, and compares the recalculation result with the message authentication code included in the received verification information. If they match, the management server 100 can determine that the verification information is valid.

[0097] In a configuration that includes expiration date information, the management server 100 may, prior to verification, refer to the expiration date information of the challenge value corresponding to the received verification information and determine only the verification information received within the range of said expiration date information as valid. For example, the management server 100 may compare the reception time with the expiration time and treat it as invalid without performing verification if the expiration date has been exceeded.

[0098] Furthermore, after the management server 100 determines that the verification information is valid, it invalidates the challenge value used in that determination, making it unusable for reuse. For example, the management server 100 may record a "used flag" in the storage unit 110, and even if a verification request based on the same challenge value arrives thereafter, it may refer to this flag and not accept it. This can prevent the reuse of the same challenge value after the validity of the verification information has been determined.

[0099] <8. Determination process by the management server to determine whether unlocking is possible (Figure 7)> Figure 7 is a flowchart showing an example of the unlocking permission / denial process by the management server 100. The following section explains the unlocking permission / denial process, including management functions (maximum number of attempts, validity period, bulk lock, master unlock, user lock).

[0100] The management server 100 receives verification information from the mobile terminal 300 (step F1). The management server 100 recalculates the message authentication code and checks for a match based on the unlock password and challenge value, and proceeds to the next determination process if the match is successful (step F2). If the match is unsuccessful, the management server 100 does not grant permission to unlock and records it as a denial in the unlock history as necessary.

[0101] In a configuration where the number of uses for the unlock password is limited, the management server 100 checks the remaining uses for the unlock password (or the usage management information associated with the unlock password) and does not grant unlocking permission if there are no remaining uses. If there are remaining uses, the management server 100 may deduct the remaining uses before granting unlocking permission. The timing of the deduction is arbitrary depending on the implementation, but it is desirable to deduct the uses after successful verification to avoid duplicate use and to update the deduction in the same transaction as sending the unlocking permission signal.

[0102] In a configuration where an expiration period is set for the unlock password, the management server 100 determines whether the current time is within the expiration period of the unlock password, and if it is outside the expiration period, it does not grant permission to unlock. The expiration period may be determined, for example, by the day of the week and time of day.

[0103] In a configuration where batch locking is possible, the management server 100 refers to the batch lock status based on the authorization identifier corresponding to the user and does not grant permission to unlock if the system is currently locked. In a configuration where batch unlocking is possible, the management server 100 may perform batch unlocking based on the master authorization identifier. For example, if the master authorization identifier is entered or selected by an administrator, the batch lock status may be released, allowing subsequent unlocking requests.

[0104] In a configuration where user lock processing is possible, the management server 100 refers to the user lock status based on the user identifier and does not grant permission to unlock if the user is locked. User lock can be used, for example, to prohibit the target user from unlocking their account if there is suspicion of misuse or as an operational suspension measure.

[0105] If unlocking is permitted based on the above determinations, the management server 100 sends an unlocking permission signal to the receiver 210 (step F3). The management server 100 may record the unlocking history as needed, for example, permission / denial, date and time, receiver identifier, user identifier, etc.

[0106] Furthermore, if the results of the image verification described later do not meet the predetermined conditions, the management server 100 can be configured to send an alarm notification, record a flag in the unlock history, or perform a user lock process. This will be explained in detail in conjunction with the explanation in Figure 8.

[0107] <9. Acquisition and matching of captured images (Figure 8)> Figure 8 is a sequence diagram showing an example of image acquisition and matching processing using a motion sensor 240 and a camera 250. In this embodiment, assuming that the unlocking management system is used for auditing and security purposes, an example is described in which images are acquired in association with unlocking events and matching is performed based on those images.

[0108] The door 200 is equipped with a motion sensor 240 and a camera 250. The motion sensor 240 can detect the presence of a person in the vicinity of the door 200. The detection method of the motion sensor 240 is arbitrary and can be implemented by means of infrared, distance sensor, image analysis, etc. The camera 250 can capture images of the vicinity of the door 200. The placement and field of view of the camera 250 are arbitrary and can be installed on the outside of the door, for example.

[0109] When the door 200 is unlocked while the presence of a person is detected by the motion sensor 240, the management server 100 acquires the image captured by the camera 250 from the receiver 210. In this embodiment, the receiver 210 is connected to the camera 250, and the receiver 210 acquires the captured image and transmits it to the management server 100, so that the management server 100 acquires the captured image "from the receiver 210". Specifically, the receiver 210 may refer to the detection state of the motion sensor 240 (the state in which the presence of a person is detected) and instruct the camera 250 to take a picture in association with the unlocking operation, or the receiver 210 may be configured to take the image captured by the camera 250. In any case, the management server 100 acquires the image by receiving the captured image from the receiver 210.

[0110] In this case, the captured image may be an image taken during a predetermined period from the time the authentication process is successful until the door 200 is unlocked. The predetermined period can be set arbitrarily; for example, it may be set to include the period from the time the receiver 210 detects the success of the authentication process until the unlocking operation, or a certain time range (e.g., several seconds) immediately before the unlocking operation. For example, the receiver 210 may send a request to the camera 250 to start taking pictures from the time it receives the authentication process success (S4 in Figure 5) until it receives the unlock permission signal and performs the unlocking operation (S8-S9 in Figure 5), and send the images taken during that period to the management server 100. This makes it easier to obtain images that are highly relevant to the unlocking event.

[0111] The management server 100 may perform matching based on the captured image acquired from the receiver 210. In this embodiment, an example is described in which the management server 100 calculates feature quantities from the captured image and performs matching using these feature quantities and matching information associated with the user. Feature quantities are matching feature information extracted from the captured image and can be implemented as, for example, a feature vector of the face region, a template, etc. Matching information is reference information registered in the storage unit 110 and associated with the user and can be stored as, for example, a face feature quantity template associated with the user. The management server 100 calculates feature quantities from the captured image using the image processing and matching unit 106 and obtains a matching result by comparing these feature quantities with the matching information. The matching method is arbitrary; for example, if the similarity is above a threshold, it may be determined to be a match, and if it is below the threshold, it may be determined to be a mismatch.

[0112] Identifying the target of the matching (the user associated with the matching information) is optional, but for example, the management server 100 may select the matching information based on the user identifier identified through the unlocking history or authentication process. This allows verification through matching whether the unlocking event corresponds to the expected user.

[0113] <10. Processing based on the matching result> If the verification result does not meet predetermined conditions, the management server 100 may perform at least one of the following actions: sending an alarm notification, adding a flag to the unlock history, or executing a user lock process. In this embodiment, each of these will be described as a configuration in which they can be executed independently.

[0114] The predetermined conditions are the conditions under which the management server 100 determines operational approval or rejection of the matching results, and can be expressed, for example, as "match determination" or "similarity is above a predetermined threshold." Therefore, cases where the matching results do not satisfy the predetermined conditions include, for example, cases where a mismatch determination is made or where the similarity is below a predetermined threshold. Specific values ​​(thresholds, etc.) of the predetermined conditions may be stored as policies in the storage unit 110.

[0115] The management server 100 may send an alarm notification if the matching result does not meet predetermined conditions. The destination of the alarm notification is arbitrary and may be, for example, an administrator terminal, a monitoring center, or a mobile terminal 300. The alarm notification may include information such as a receiver identifier, date and time, user identifier, and matching result (mismatch). This allows for early detection of suspicious unlocking events and prompts appropriate action.

[0116] The management server 100 may add a flag to the unlocking history and record it if the matching result does not meet predetermined conditions. For example, the management server 100 may add a flag such as a "matching mismatch flag" to the unlocking history record, and use this flag to extract suspicious events in a later audit. This can improve the efficiency of audits.

[0117] The management server 100 may perform a user lock process if the matching result does not meet predetermined conditions. For example, the management server 100 may activate the user lock state corresponding to the user identifier and refuse subsequent unlock requests when conditions based on the policy are met, such as when matching mismatches occur a predetermined number of times or when a mismatch occurs for a specific receiver identifier. This can deter unlocking by users suspected of unauthorized use.

[0118] In this embodiment, the processing based on the verification result is not incorporated into the unlock permission condition itself, but is treated as an additional process for auditing and security purposes. That is, unlock permission is granted by verifying the unlock password and the challenge value, and the verification and processing based on the verification result can be implemented as auxiliary processes that are executed in association with the unlock event.

[0119] <11. Preliminary authentication mode in case of communication failure (Figure 9)> Figure 9 is an explanatory diagram illustrating an example of the process in which, when communication between the management server 100 and the receiver 210 becomes impossible, the receiver 210 switches to a preliminary authentication mode and allows limited unlocking, and the process in which the management server 100 controls this limited operation after communication is restored. The following explanation will be divided into the processes on the receiver 210 side and the processes on the management server 100 side.

[0120] Under normal circumstances, the receiver 210 communicates with the management server 100 via the network to send authentication information, receive authentication results, and receive unlock permission signals. However, communication between the management server 100 and the receiver 210 may become impossible due to communication failures, line outages, server failures, etc. When the receiver 210 detects such a communication failure, it switches to a preliminary authentication mode.

[0121] The method for detecting communication failure is arbitrary, but for example, the receiver 210 may determine that communication is impossible if the response to the transmission request to the management server 100 is not received, if the retransmission fails a predetermined number of times, or if the response is waited for a predetermined time. Alternatively, the receiver 210 may periodically check for connectivity with the management server 100 (e.g., heartbeat) and determine that communication is impossible if the connectivity check fails consecutively for a predetermined number of times or more. The "predetermined number of times" and "predetermined time" here may be stored as configuration information of the receiver 210.

[0122] In pre-authentication mode, the receiver 210 permits unlocking the door 200 for a predetermined number of times. Specifically, the receiver 210 maintains an unlock count counter for pre-authentication mode and refers to the remaining count each time an unlock request arrives. If there are remaining counts, the receiver 210 permits unlocking and deducts the remaining count after the unlocking operation is completed. If there are no remaining counts, the receiver 210 refuses to unlock. The initial value (determined number of times) of the unlock count counter may be, for example, stored as a setting value in the receiver 210's non-volatile memory, or it may be a setting value that has been distributed to the receiver 210 in advance based on operational policies.

[0123] The method for receiving "unlock requests" in preliminary authentication mode is arbitrary, but for example, if an unlock request arrives from a mobile terminal 300 via short-range communication, the receiver 210 may allow or deny unlocking based on the preliminary authentication mode determination (remaining attempts) without querying the management server 100. In preliminary authentication mode, the security level may be lower than in normal mode, so it is desirable to set the remaining attempts to a small amount and to record the history in detail each time an unlock occurs during preliminary authentication mode.

[0124] The receiver 210 may record the unlocking history (preliminary authentication history) in preliminary authentication mode. The items to be recorded in the preliminary authentication history are arbitrary, but may include, for example, the date and time, receiver identifier, unlocking result (permitted / denied), remaining attempts, and, if necessary, identification information (terminal ID, etc.) presented by the mobile terminal 300. The receiver 210 stores the preliminary authentication history in non-volatile memory and makes it available for transmission to the management server 100 after communication is restored.

[0125] The receiver 210 may return from the preliminary authentication mode to the normal mode when it detects that communication has been restored. The method for detecting communication restoration is arbitrary, but for example, communication restoration may be determined when the connectivity check is successful or when a response is received from the management server 100 to the transmission request. After returning to the normal mode, the receiver 210 performs authentication cooperation and unlocking control with the management server 100 according to the normal procedure.

[0126] <12. Acquisition and control of history after communication restoration (Figure 9)> After communication is restored, the management server 100 can ascertain the operational status of unlocking performed during the preliminary authentication mode and take action if there is any use that violates the operational policy. Specifically, the management server 100 obtains the preliminary authentication history from the receiver 210 and determines whether the history violates the predetermined policy.

[0127] The method for obtaining the preliminary authentication history is arbitrary, but for example, the receiver 210 may send the preliminary authentication history to the management server 100 after detecting that communication has been restored. Alternatively, the management server 100 may send a history upload request to the receiver 210 after communication has been restored, and the receiver 210 may send the preliminary authentication history in response. The history may also be sent in batches of a certain number of entries.

[0128] The management server 100 performs policy determination based on the received preliminary authentication history. The content of the policy is arbitrary, but for example, the determination items may include whether the number of unlocks during preliminary authentication mode has exceeded a predetermined number, whether unlocking was performed during a time when unlocking is not permitted, whether there have been many rejections, or whether there is a bias towards a particular terminal ID, etc. The policy is stored in the storage unit 110 and may be modified by the administrator.

[0129] If the management server 100 determines that the preliminary authentication history violates the policy, the management server 100 may invalidate the unlock password. Invalidating the unlock password can be achieved, for example, by setting a flag to "invalid" in the storage unit 110, updating the unlock password to a new unlock password and invalidating the old password, or setting the number of times the unlock password can be used to zero. This makes it possible to deter further unlocking using the unlock password if there is suspicion of use that violates the operational policy after limited operation during a communication failure.

[0130] If the management server 100 invalidates the unlock password, it may record the fact of such invalidation in the unlock history or audit log. The management server 100 may also provide operational communications, such as sending a notification to the administrator terminal.

[0131] As described above, the receiver 210 can continue limited unlocking even when communication is impossible, and the management server 100 can control exceptional operations by acquiring history and making policy decisions after communication is restored.

[0132] <13. Supplementary information regarding preliminary authentication mode> In the preliminary authentication mode, the conditions for granting permission to unlock are generally limited to a predetermined number of times. However, in practice, the receiver 210 can be configured to, for example, display a warning (buzzer, LED, notification to a mobile device, etc.) each time unlocking is permitted, or record the receiver identifier and date and time with higher accuracy each time unlocking occurs during the preliminary authentication mode.

[0133] Furthermore, since the state of the preliminary authentication mode may be lost due to a power outage of the receiver 210, it is desirable to store the remaining number of attempts and history in the preliminary authentication mode in non-volatile memory. In addition, if the receiver 210 is configured not to store time information, the elapsed time information measured by the receiver 210 may be recorded and interpreted by the management server 100 in combination with the reception time, etc., after communication is restored.

[0134] <14. Specific examples of updating and managing unlock passwords> The management server 100 may periodically update the unlock password. The update cycle is arbitrary and can be set to, for example, daily, weekly, or monthly. The method for generating the unlock password is arbitrary, but for example, a cryptographic pseudorandom number generator may be used to generate a random number sequence of a predetermined number of digits, and this random number sequence may be registered in the storage unit 110 as the unlock password. The unlock password may be a different value for each user, or a common value for each authorization identifier. When the unlock password is updated, the old unlock password may be invalidated, and only the new unlock password may be valid after the update.

[0135] If a limit is placed on the number of times the unlock password can be used, the management server 100 may store the remaining uses in the storage unit 110 in association with the unlock password and deduct the remaining uses when unlock permission is granted. To avoid double deduction or conflicts, the management server 100 may perform the deduction after successful verification and the transmission of the unlock permission signal in the same exclusive control (e.g., a database transaction).

[0136] If an expiration period is set for the unlock password, the management server 100 may determine the expiration period based on the day of the week and time of day, and determine whether the current time is within that expiration period. The management of the expiration period may be recorded in the storage unit 110 as schedule information that holds multiple pairs of "day of the week → start time → end time". If multiple expiration periods are set, the management server 100 may treat the password as valid when it is included in any of the expiration periods, and as invalid when it is not included in any of them.

[0137] <15. Specific examples of authentication information and authentication data> As a specific example of authentication information, the management server 100 may store a user identifier, a terminal identifier associated with the user's mobile terminal 300, and a public key associated with the terminal in the storage unit 110. The mobile terminal 300 may generate authentication information via an unlocking application 310 when it approaches the receiver 210 and transmit it to the receiver 210.

[0138] For example, the mobile terminal 300 may generate a signature for data including a user identifier, a terminal identifier, and the current time, and transmit the signature and identifier set as authentication information. The management server 100 may perform signature verification using a public key or the like stored in the storage unit 110, and determine that the authentication process is successful if the authentication information is valid. The signature method is arbitrary, and authentication information may be generated using MAC with symmetric key cryptography.

[0139] <16. Specific examples of challenge value generation, expiration date information, and receiver identifier> The receiver 210 generates a challenge value after the authentication process is successful. The method for generating the challenge value is arbitrary, but for example, the receiver 210 may generate a random number of a predetermined bit length using a cryptographic pseudorandom number generator and use this random number as the main part (nonce) of the challenge value.

[0140] If the receiver identifier is included in the challenge value, the challenge value can be represented as a data structure such as the following:

[0141] • Field 1: Receiver identifier Field 2: Random number (nonce) • Field 3: Expiration date information (optional)

[0142] As a concrete example of expiration information, the receiver 210 may include the generation time and validity period (e.g., 30 seconds), or it may include the expiration time (e.g., generation time + 30 seconds). If the receiver 210 does not maintain an accurate time, the receiver 210 may treat the elapsed time measured by its internal timer as expiration information, and the management server 100 may evaluate it in combination with the reception time, etc.

[0143] The receiver 210 may invalidate the challenge value if it does not receive an unlock permission signal from the management server 100 within a predetermined time after transmitting the challenge value to the mobile terminal 300. Invalidation can be achieved, for example, by discarding the session information for the challenge value held by the receiver 210. The receiver 210 may also choose not to accept any further unlock requests corresponding to invalidated challenge values.

[0144] <17. Specific Examples of Generating and Matching Verification Information (MAC)> The mobile terminal 300 generates verification information based on the entered unlock password and challenge value. As a concrete example of verification information, HMAC can be used as follows. Here, an example is shown where the MAC is calculated using the unlock password as the key and the challenge value as the message.

[0145] • Key: Entered unlock password • Message: Challenge value (may include receiver identifier and expiration date information) • Output: MAC value (to be included in verification information)

[0146] The mobile terminal 300 may send the challenge value and the above MAC value as verification information to the management server 100.

[0147] The management server 100 may recalculate the MAC using the same input (unlock password and challenge value) and determine if it matches the MAC value received from the mobile terminal 300. If they do not match, the management server 100 does not send an unlock permission signal.

[0148] If expiration information is included, the management server 100 may verify that the challenge value is valid based on the expiration information before MAC verification. For example, if the expiration date has passed, it may be treated as invalid without performing MAC verification.

[0149] After the management server 100 determines that the verification information is valid, it makes the challenge value used in that determination unusable. As an example of implementing unusable challenge values, the management server 100 may record a "used" flag in the storage unit 110 and refer to this flag to reject any subsequent verification requests based on the same challenge value. To conserve storage space, the management server 100 may record the hash value of the challenge value as the key for "used" management.

[0150] <18. Specific examples of bulk locking, master unlocking, and user locking> The management server 100 may be able to perform a batch lock process based on the authorization identifier. For example, the management server 100 may maintain a "batch lock status" flag in the storage unit 110 associated with the authorization identifier, and if the flag is valid, it may not grant unlocking permission to multiple receiver identifiers belonging to that authorization identifier. The association between authorization identifiers and receiver identifiers may be maintained as a table in the storage unit 110.

[0151] As a concrete example of batch unlocking based on a master authority identifier, the management server 100 may accept unlocking requests from administrator terminals and, if the unlocking request includes a master authority identifier, remove the batch lock status flag. After unlocking, a normal unlocking check may be performed.

[0152] As a concrete example of user lock processing, the management server 100 may maintain a "lock status" flag associated with a user identifier, and if the flag is valid, it may not grant unlocking permission to the user. User locks may be set by administrator operations, or by automatic processing such as when the matching result does not meet predetermined conditions.

[0153] <19. Specific examples of unlocking history and flags> The management server 100 may record the unlocking history in the storage unit 110. The following items may be included as a minimum configuration example of the unlocking history.

[0154] · Date and time • Receiver identifier • User identifier (if identifiable) • Unlock result (permitted / denied) • Reason for rejection (e.g., mismatch, expired, no remaining attempts, bulk lock, user lock, etc.) • Matching flag (set when the matching result does not meet the specified conditions)

[0155] In an example where a flag is assigned when the matching result does not meet predetermined conditions, the management server 100 may assign a flag such as "matching mismatch" to the unlocking history record, allowing it to be searched using that flag at a later date. This allows for the efficient extraction of events to be audited.

[0156] <20. Specific Examples of Alarm Notifications> In an example where an alarm notification is sent when the matching result does not meet predetermined conditions, the management server 100 may send a notification to the administrator terminal or monitoring center. The notification method is arbitrary and can be implemented by email, push notification, messaging, etc. The notification content may include the receiver identifier, date and time, type of matching result, and, if necessary, reference information for the captured image.

[0157] <21. Specific Examples of Image Feature Calculation and Matching> The management server 100 calculates feature quantities from the captured image acquired from the receiver 210 and performs matching by comparing them with matching information. As a specific example of feature quantity calculation, the management server 100 may detect face regions through image processing and extract feature vectors from those face regions. Matching information may be stored in the storage unit 110 by similarly extracting feature vectors from images acquired during user registration. Matching can be achieved by calculating the distance or similarity between feature vectors and comparing them with a threshold.

[0158] <22. Variation> The above example illustrates how the mobile terminal 300 accepts input of an unlock password, but the method of inputting the unlock password is not limited to this. For example, the unlock password is not limited to numerical input; it may also be a predetermined string of characters or a code selected by the user. Furthermore, since the unlock password is updated periodically, the unlocking application 310 may not present the latest unlock password to the user, and the user may be required to input an unlock password obtained through another means.

[0159] Furthermore, the format of the challenge value, the representation of the expiration date information, the format of the verification information, and the format of the unlock permission signal are not limited to the specific examples shown here, and any format that can achieve equivalent functionality may be adopted. [Explanation of Symbols]

[0160] 100... Management Server 101…Authentication Department 102... Password Management Department 103...Verification section 104…Authority Management Department 105…Audit and History Management Department 106…Image Processing and Matching Unit 110...Storage section 200... doors 210... Receiver 211…Near field communication department 212…Network Communications Department 213…Authentication Control Unit 214...Challenge Generation Unit 215... Timer section 216... Unlocking control unit 230...Lock mechanism 240…Human motion sensor 250... Camera 300… Mobile devices 310… Unlocking application 311... App Control Unit 313... Input reception section 314...Verification Information Generation Unit 315... Server Communications Department 331…Near field communication department

Claims

1. An unlocking management system comprising a management server, an auto-locking door equipped with a receiver capable of short-range communication, and a mobile terminal capable of short-range communication with the receiver, The management server stores authentication information associated with users who can unlock the door, and a periodically updated unlock password. The aforementioned mobile device is equipped with an unlocking application, When the mobile terminal approaches the receiver, it performs the short-range communication with the receiver, activates the unlocking application, and transmits authentication information based on the authentication information to the receiver. The receiver transmits the authentication information to the management server, the management server performs the user authentication process, and if the authentication process is successful, it generates a challenge value and sends it to the mobile terminal, and also sends a notification to the mobile terminal requesting the input of the unlock password. The mobile terminal receives the input of the unlock password, generates verification information including the challenge value and a message authentication code based on the entered unlock password and the challenge value, and transmits the verification information to the management server. The management server recalculates the message authentication code based on the unlock password and the challenge value, determines the validity of the verification information by checking whether the recalculated message authentication code matches the message authentication code contained in the received verification information, and if it is valid, sends an unlock permission signal to the receiver, and the receiver unlocks the door in response to the unlock permission signal. A lock-unlocking management system characterized by the following features.

2. In the unlocking management system according to claim 1, The challenge value includes a receiver identifier that identifies the receiver, A lock-unlocking management system characterized by the following features.

3. In the unlocking management system according to claim 1 or 2, The challenge value includes expiration date information, and the management server determines only the verification information received within the range of the expiration date information to be valid. A lock-unlocking management system characterized by the following features.

4. In the unlocking management system according to claim 1, The verification information includes the challenge value and a message authentication code calculated using the entered unlock password and the challenge value as inputs. A lock-unlocking management system characterized by the following features.

5. In the unlocking management system according to claim 1, The receiver generates the challenge value only if the authentication process is successful, and sends a notification to the mobile terminal requesting the input of the unlock password. The receiver does not send a notification requesting the input of the unlock password if the authentication process is unsuccessful. A lock-unlocking management system characterized by the following features.

6. In the unlocking management system according to claim 1, If the receiver does not receive the unlock permission signal from the management server within a predetermined time after transmitting the challenge value, it invalidates the challenge value. A lock-unlocking management system characterized by the following features.

7. In the unlocking management system according to claim 1, The aforementioned unlock password has a limit on the number of times it can be used. A lock-unlocking management system characterized by the following features.

8. In the unlocking management system according to claim 1, The aforementioned unlock password has an expiration period set according to the day of the week and time of day. A lock-unlocking management system characterized by the following features.

9. In the unlocking management system according to claim 1, The management server can perform a batch lock process to prohibit unlocking multiple doors at once, based on the authorization identifier corresponding to the user. A lock-unlocking management system characterized by the following features.

10. In the unlocking management system according to claim 9, The management server can release the bulk locks created by the bulk lock process based on the master authority identifier. A lock-unlocking management system characterized by the following features.

11. In the unlocking management system according to claim 1, The management server is capable of performing a user lock process that prohibits the user from unlocking based on a user identifier that identifies the user. A lock-unlocking management system characterized by the following features.

12. In the unlocking management system according to claim 1, The door is equipped with a camera and a motion sensor, and when the door is unlocked while the presence of a person is detected by the motion sensor, the management server acquires the image captured by the camera from the receiver. A lock-unlocking management system characterized by the following features.

13. In the unlocking management system according to claim 12, The aforementioned image is an image taken during a predetermined period from the time the authentication process is successful until the door is unlocked. A lock-unlocking management system characterized by the following features.

14. In the unlocking management system according to claim 13, The management server performs matching using the feature quantities calculated from the image and the matching information associated with the user. A lock-unlocking management system characterized by the following features.

15. In the unlocking management system according to claim 1, If communication between the management server and the receiver is impossible, the receiver switches to a preliminary authentication mode, in which case it permits unlocking the door for a predetermined number of times. A lock-unlocking management system characterized by the following features.

16. In the unlocking management system according to claim 15, The management server acquires the unlock history using the preliminary authentication mode after communication is restored, and if it determines that the unlock history violates a predetermined policy, it invalidates the unlock password. A lock-unlocking management system characterized by the following features.

17. In the unlocking management system according to claim 1, After the management server determines that the verification information is valid, it invalidates the challenge value used in the determination. A lock-unlocking management system characterized by the following features.

18. In the unlocking management system according to claim 2, The verification information is generated based on the challenge value, which includes the entered unlock password and the receiver identifier. A lock-unlocking management system characterized by the following features.

19. In the unlocking management system according to claim 14, The management server sends an alarm notification if the result of the verification does not meet the predetermined conditions. A lock-unlocking management system characterized by the following features.

20. In the unlocking management system according to claim 14, The management server, if the result of the verification does not meet the predetermined conditions, records a flag in the unlocking history related to the unlocking of the door. A lock-unlocking management system characterized by the following features.

21. In the unlocking management system according to claim 14, The management server, if the result of the verification does not meet predetermined conditions, executes a user lock process that prohibits unlocking the user based on the user identifier that identifies the user. A lock-unlocking management system characterized by the following features.

22. A receiver installed in an automatic locking door, capable of short-range communication with a mobile device, and capable of network communication with a management server, The receiver receives authentication information from the mobile terminal and transmits the authentication information to the management server. The receiver, upon successful authentication by the management server based on the authentication information, generates a challenge value and sends it to the mobile terminal, and sends a notification to the mobile terminal requesting the input of a deactivation password. When the receiver receives an unlock permission signal from the management server, it unlocks the automatic locking door. If the receiver does not receive the unlock permission signal from the management server within a predetermined time after transmitting the challenge value, it invalidates the challenge value. The receiver switches to a preliminary authentication mode if it is unable to communicate with the management server, and in the preliminary authentication mode, it permits unlocking the auto-locking door for a predetermined number of times. A receiver characterized by the following features.

23. A management server for managing the unlocking of an automatic locking door equipped with a receiver, The management server stores authentication information associated with users who can unlock the automatic locking door, and a periodically updated unlock password. The management server receives authentication information from the receiver and performs authentication processing based on the authentication information. If the authentication process is successful, the management server receives verification information, including a challenge value and a message authentication code, from a mobile terminal capable of short-range communication with the receiver, recalculates the message authentication code based on the unlock password and the challenge value, and, upon determining that the verification information is valid based on a match between the recalculated message authentication code and the message authentication code included in the received verification information, transmits an unlock permission signal to the receiver. A management server characterized by the following features.

24. In the management server described in claim 23, The management server, when the receiver is unable to communicate with the management server, acquires a history of unlocking performed in a preliminary authentication mode that limits the number of times the automatic locking door can be unlocked, and if it determines that the history violates a predetermined policy, it invalidates the unlock password. A management server characterized by the following features.

25. To cause a computer to function as the management server described in claim 23, The authentication information and the unlock password are stored, The receiver receives authentication information, and performs authentication processing based on the authentication information. If the authentication process is successful, the system receives the verification information, recalculates the message authentication code based on the challenge value and unlock password contained in the verification information, and if the verification information is deemed valid based on a match between the recalculated message authentication code and the message authentication code contained in the received verification information, the system transmits an unlock permission signal to the receiver. A program characterized by the following features.

Images