Door lock and card cooperative processing method and system

Abstract

The invention discloses a door lock and card cooperative processing method and system, and the method comprises the steps: triggering a robot calling process according to preset times of doorbell button operation detected by a first door lock and read neighbor RFID card information, verifying a matching result of an RFID card and a resident registration form, and generating an authority verification passing signal; calculating a target multicast address based on the ID number of the RFID card, and converting the ID number of the RFID card into a false source IP address to obtain a communication parameter set; sending an IGMPv3 report message to the router according to the communication parameter set; according to the triggering operation of the same RFID card detected by the assisted second door lock, an assistance multicast request message is generated, the (S, G) forwarding table item is matched through the router and forwarded to the first door lock, the first door lock sends an assistance confirmation message to the second door lock, and robot calling authorization is completed. By utilizing the embodiment of the invention, efficient, safe and low-delay cross-door-lock cooperative operation can be realized.

Description

Technical Field

[0001] This invention belongs to the field of smart door lock technology, and in particular to a method and system for door lock and card collaborative processing. Background Technology

[0002] In modern smart home and community management systems, the collaborative application of door locks and smart cards is becoming increasingly widespread. However, existing technologies suffer from problems such as low cross-device communication efficiency, cumbersome authorization verification processes, and imperfect temporary authorization mechanisms. Traditional door lock systems typically use centralized servers for authorization verification and command forwarding, resulting in high response latency and susceptibility to service interruptions during network anomalies. For scenarios such as neighborly package pickup and temporary visitor assistance, existing solutions mostly rely on fixed IP addresses or Bluetooth pairing, making it difficult to achieve fast and secure cross-lock collaborative operations. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for collaborative processing of door locks and cards, so as to overcome the shortcomings of the prior art and realize efficient, safe and low-latency cross-door lock collaborative operation.

[0004] One embodiment of this application provides a method for coordinated processing of door locks and cards, the method comprising: Triggering process and authorization verification: Based on the preset number of doorbell button operations detected by the first door lock and the neighbor's RFID card information read, the robot summoning process is triggered, and the matching result of the RFID card and the resident registration form is verified to generate an authorization verification pass signal; Multicast address and fake source IP generation: Based on the ID number of the RFID card, the target multicast address is calculated by a hash algorithm, and the ID number of the RFID card is converted into a fake source IP address by a segmented mapping method, resulting in a set of communication parameters containing the multicast address and the fake source IP. Multicast message sending and routing table construction: Based on the set of communication parameters, an IGMPv3 report message carrying a fake source IP and multicast address is sent to the router, triggering the router to generate a (S, G) multicast forwarding table entry and bind it to the receiving interface, where S is the fake source IP and G is the target multicast address; Cross-lock request forwarding and confirmation: Based on the trigger operation of the same RFID card detected by the assisted second lock, a request for assistance multicast message containing a multicast address and a fake source IP is generated. The message is forwarded to the first lock through the router matching (S, G) forwarding table entry, and the first lock sends an assistance confirmation message to the second lock to complete the robot summoning authorization.

[0005] Optionally, the triggering process and permission verification include: Button operation detection: When the first door lock detects two consecutive doorbell button operations within a preset time, a 30-second countdown is started and the RFID card reader module is activated; RFID matching verification: Read the RFID card ID number and compare it with the resident registration form. If the match is successful, an authorization verification pass signal is generated; otherwise, the process is terminated. Cache recall events: Record recall event information, including RFID card ID number, multicast address, fake source IP and validity period, and start countdown monitoring. The validity period is updated synchronously with the validity period of the routing table entry.

[0006] Optionally, the generation of the multicast address and fake source IP includes: Multicast address calculation: Convert the base IP address 226.1.1.0 into a 32-bit binary constant U, concatenate it with the 32-bit binary representation V of the RFID card ID number to form a 64-bit data stream, calculate the hash value using the CRC32 hash algorithm and take the modulo 256 to obtain X in the multicast address 226.1.1.X; Fake source IP generation: Perform CRC32 hash calculation on the RFID card ID number, split the result into four 8-bit segments and convert them into decimal numbers to generate fake source IP addresses; Parameter binding: Associates the multicast address with the fake source IP address to form a set of communication parameters.

[0007] Optionally, the multicast message sending and routing table construction includes: IGMPv3 message encapsulation: Encapsulate the fake source IP address, multicast address, and 30-second validity period into an IGMPv3 report message; Routing table update: The router parses the IGMPv3 message, creates an (S, G) entry in the multicast forwarding table and binds it to the receiving interface, setting a validity period of 30 seconds; Exception handling: If the same (S, G) entry is detected to already exist, refresh the validity period of 30 seconds.

[0008] Optionally, the cross-lock request forwarding and confirmation includes: Cross-lock operation synchronization: After the assisted second lock detects two doorbell operations of the same RFID card, it generates a request for assistance message containing the same multicast address and fake source IP. Router precise forwarding: The router forwards the request message to the interface corresponding to the first lock according to the (S, G) forwarding table entry; Assistance confirmation and task triggering: After the first door lock verifies the validity of the RFID card, it sends a confirmation message to the second door lock, which then initiates a robot dispatch request to the platform.

[0009] Another embodiment of this application provides a system for door lock and card collaborative processing, the system comprising: The verification module is used to trigger process and permission verification: based on the preset number of doorbell button operations detected by the first door lock and the neighbor RFID card information read, the robot summoning process is triggered, and the matching result of the RFID card and the resident registration form is verified to generate a permission verification pass signal; The generation module is used to generate multicast addresses and fake source IPs: based on the ID number of the RFID card, the target multicast address is calculated by a hash algorithm, and the ID number of the RFID card is converted into a fake source IP address by a segmented mapping method, so as to obtain a set of communication parameters containing the multicast address and the fake source IP. The sending module is used for multicast message sending and routing table construction: based on the communication parameter set, it sends an IGMPv3 report message carrying a fake source IP and multicast address to the router, triggering the router to generate a (S, G) multicast forwarding table entry and bind it to the receiving interface, where S is the fake source IP and G is the target multicast address; The forwarding module is used for cross-lock request forwarding and confirmation: based on the trigger operation of the same RFID card detected by the second lock being assisted, a request for assistance multicast message containing a multicast address and a fake source IP is generated. The message is forwarded to the first lock through the router matching (S, G) forwarding table entries, and the first lock sends an assistance confirmation message to the second lock to complete the robot summoning authorization.

[0010] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0011] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0012] Compared with existing technologies, the present invention provides a method for door lock and card collaborative processing. Based on a preset number of doorbell button operations detected by the first door lock and the read neighbor's RFID card information, a robot summoning process is triggered, and the matching result between the RFID card and the resident registration form is verified to generate an authorization verification pass signal. Based on the RFID card's ID number, a target multicast address is calculated, and the RFID card's ID number is converted into a pseudo-source IP address to obtain a communication parameter set. Based on the communication parameter set, an IGMPv3 report message is sent to the router. Based on the trigger operation of the same RFID card detected by the assisted second door lock, a request for assistance multicast message is generated, which is forwarded to the first door lock through the router's (S, G) forwarding table entry. The first door lock then sends an assistance confirmation message to the second door lock, completing the robot summoning authorization. This enables efficient, secure, and low-latency cross-door lock collaborative operation. Attached Figure Description

[0013] Figure 1 Hardware structure block diagram of a computer terminal for a door lock and card collaborative processing method provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a method for coordinated processing of door locks and cards provided in an embodiment of the present invention. Figure 3 This is a schematic diagram of a system for coordinated processing of door locks and cards, provided as an embodiment of the present invention. Detailed Implementation

[0014] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0015] This invention first provides a method for the coordinated processing of door locks and cards, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0016] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for a door lock and card collaborative processing method provided in an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0017] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any method of door lock and card coordination.

[0018] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0019] Internal memory provides an environment for the execution of computer programs in non-volatile storage media. When the computer program is executed by the processor, it enables the processor to perform any method of door lock and card coordination.

[0020] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0021] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0022] See Figure 2 The present invention provides a method for door lock and card collaborative processing, which may include the following steps: S201, Triggering the process and verifying permissions: Based on the preset number of doorbell button operations detected by the first door lock and the neighbor's RFID card information read, the process of summoning the robot is triggered, and the matching result of the RFID card and the resident registration form is verified, generating a permission verification pass signal; specifically, the triggering process and permission verification include: Button operation detection: When the first door lock detects two consecutive doorbell button operations within a preset time, a 30-second countdown is started and the RFID card reader module is activated; RFID matching verification: Read the RFID card ID number and compare it with the resident registration form. If the match is successful, an authorization verification pass signal is generated; otherwise, the process is terminated. Cache recall events: Record recall event information, including RFID card ID number, multicast address, fake source IP and validity period, and start countdown monitoring. The validity period is updated synchronously with the validity period of the routing table entry.

[0023] S202, Multicast Address and Fake Source IP Generation: Based on the RFID card's ID number, a target multicast address is calculated using a hash algorithm, and a segmented mapping method is used to convert the RFID card's ID number into a fake source IP address, resulting in a set of communication parameters containing the multicast address and the fake source IP; specifically, the generation of the multicast address and fake source IP includes: Multicast address calculation: Convert the base IP address 226.1.1.0 into a 32-bit binary constant U, concatenate it with the 32-bit binary representation V of the RFID card ID number to form a 64-bit data stream, calculate the hash value using the CRC32 hash algorithm and take the modulo 256 to obtain X in the multicast address 226.1.1.X; Fake source IP generation: Perform CRC32 hash calculation on the RFID card ID number, split the result into four 8-bit segments and convert them into decimal numbers to generate fake source IP addresses; Parameter binding: Associates the multicast address with the fake source IP address to form a set of communication parameters.

[0024] S203, Multicast Message Sending and Routing Table Construction: Based on the communication parameter set, an IGMPv3 report message carrying a fake source IP and multicast address is sent to the router, triggering the router to generate a (S, G) multicast forwarding table entry and bind it to the receiving interface, where S is the fake source IP and G is the destination multicast address; specifically, the multicast message sending and routing table construction includes: IGMPv3 message encapsulation: Encapsulate the fake source IP address, multicast address, and 30-second validity period into an IGMPv3 report message; Routing table update: The router parses the IGMPv3 message, creates an (S, G) entry in the multicast forwarding table and binds it to the receiving interface, setting a validity period of 30 seconds; Exception handling: If the same (S, G) entry is detected to already exist, refresh the validity period of 30 seconds.

[0025] S204, Cross-lock Request Forwarding and Confirmation: Based on the trigger operation of the same RFID card detected by the assisted second lock, a request for assistance multicast message containing a multicast address and a fake source IP is generated. This message is forwarded to the first lock via the router's (S, G) forwarding table entry, and the first lock sends an assistance confirmation message to the second lock, completing the robot summoning authorization. Specifically, the cross-lock request forwarding and confirmation includes: Cross-lock operation synchronization: After the assisted second lock detects two doorbell operations of the same RFID card, it generates a request for assistance message containing the same multicast address and fake source IP. Router precise forwarding: The router forwards the request message to the interface corresponding to the first lock according to the (S, G) forwarding table entry; Assistance confirmation and task triggering: After the first door lock verifies the validity of the RFID card, it sends a confirmation message to the second door lock, which then initiates a robot dispatch request to the platform.

[0026] In practical applications, when the owner of a smart door lock forgets their access card or mobile phone and finds it inconvenient to travel to the management center for services, they may wish to summon a robot to unlock the door using facial recognition. After consultation, nearby neighbors may offer assistance. This invention proposes a method where a neighbor's RFID card swipe authorization summons the robot on their behalf. One specific technical solution includes: 1. Core Idea: I didn't have my RFID card or phone, so I couldn't swipe my card to enter or call the robot. Seeing my neighbor was there, I asked them for help in calling the robot. My neighbor pressed two buttons on their own door lock to trigger it, then swiped their RFID card, pressed two more buttons to confirm, and immediately came to my door lock, swiped their RFID card, and pressed two buttons to summon the robot for me. The robot then unlocked the door for me using facial recognition. Since my door lock and the neighbor's door lock don't know each other's IP addresses, a design was added: if B helps A while D helps C, multicast messages sent by A will be forwarded to both B and D simultaneously, causing confusion in router message forwarding. The key point is: the multicast group address of the IGMP message sent by lock B uses a hash result. The input to this hash function contains two data: a constant converted from 226.1.1.0 and the RFID ID number. The output is data between 0 and 255, and the final multicast group address is 226.1.1.X, where X is the hash result. The multicast message sent by A also uses the multicast address 226.1.1.X. Improvement: To avoid collisions, use the RFID tag as the source IP. When B assists A, B sends an igmpv3 message containing (the fake source IP converted from the RFID tag, and the hashed G). The router generates an (S, G) entry. When A sends a multicast message, the source IP is the fake source IP, and the destination address is the hashed G.

[0027] 2. The complete technical implementation process is as follows: Prerequisites: The homeowner's front door is equipped with a smart lock that supports RFID card reading for unlocking. The lock stores a "resident registration information form" which includes the homeowner's name, RFID-ID number, etc. The robot can autonomously walk to the door of a designated room; it is equipped with a display screen that supports facial recognition for comparison; it can connect to door locks and authorize unlocking of designated locks. The robot connects to the platform and receives tasks from it (such as delivering items to the homeowner or providing on-site facial recognition and door unlocking); the robot periodically synchronizes and stores the resident registration form from the platform (the information in this form is collected and recorded by the administrator, typically synchronized weekly), including room ID, door lock ID, door lock IP, homeowner's name, facial image / feature vector, RFID-ID number, etc.

[0028] Other auxiliary information: 1) Example scenario: The owner b of door lock B summons a robot for the owner a of door lock A using his own RFID-ID (b); during this period, the owner d of door lock D summons a robot for the owner c of door lock C using his own RFID-ID (d).

[0029] 2) A brief explanation of the manual operation process, taking B summoning the robot for A as an example: First, the owner of door lock B, b, presses the "doorbell" button twice on door lock B (triggering B to start the robot summoning process), swipes their RFID-ID (b) on door lock B, and then presses the "doorbell" button twice again (triggering B to confirm the robot summoning process).

[0030] Then, the owner of door lock B, b, presses the "doorbell" button twice on door lock A (triggering A to start the robot summoning process), swipes his RFID-ID (b) on door lock A, and then presses the "doorbell" button twice again (triggering A to confirm the robot summoning process).

[0031] Finally, the robot came to door lock A, and the owner of door lock A actively cooperated with the robot to perform facial recognition. The robot then unlocked door lock A.

[0032] Door lock B determines that the current process involves another door lock summoning the robot by reading the doorbell button press information and the RFID-ID(b) swiped by the card, and caches the robot summoning record. Then, it calculates the multicast address using a hash method of 226.1.1.0 and the RFID-ID(b), and sends an IGMP multicast message carrying the RFID-ID(b). The router records this message on the interface connected to door lock B in the (*,G) forwarding table entry. The reason for sending the IGMP multicast message is that B does not know which door lock is summoning the robot at this time; and using a hash method to calculate the multicast address is to reduce the inability of the router to distinguish the door lock connected to the specified outgoing interface when multiple door locks simultaneously send 226.1.1.0 IGMP multicast messages. Then, door lock A determines that the current process involves another door lock summoning the robot by reading the doorbell button press information and the RFID-ID(b) swiped by the card, and caches the robot summoning record. First, the multicast address is calculated using the hash method of RFID-ID(b) and the read RFID ID number (226.1.1.0). Then, a multicast message is sent. The router forwards A's multicast message to the interface of the door lock B connected to the multicast forwarding table entry by querying the (*,G) forwarding table entry. After receiving the message, B unicasts it to A, enabling A to summon the robot with B's confirmation. A uses the same RFID-ID(b) as B, and the same multicast address can be calculated using the above hash method. Therefore, when A sends a multicast message, it can be directly forwarded to B.

[0033] Detailed explanation of the implementation process: After door lock B detects two doorbell button notifications (at this time, b presses the "doorbell" button twice on door lock B), the robot summoning process is initiated and a 30-second countdown begins (waiting for RFID card reading; if no RFID card is read within 30 seconds, the robot summoning process ends; to continue summoning the robot, the "doorbell" button needs to be pressed twice again on door lock B). If no RFID card is read within 30 seconds (at this time, it may be that a stranger pressed the "doorbell" button twice on door lock B, and the stranger does not have an RFID card), the process ends. If B reads the RFID card, it matches the RFID card with the RFID-IDs in the "Resident Registration Owner Information Form" one by one, and a successful match is found to be RFID-ID (b) (at this time, b uses his / her RFID-ID (b) to swipe the card on door lock B). At this point, door lock B has completed the authorization confirmation for summoning robots for other door locks.

[0034] Door lock B calculates the multicast address 226.1.1.X using a hash method combining 226.1.1.0 and the RFID ID number RFID-ID(b) (for example, X = 160 after hashing). Each door lock calculates a unique multicast address based on its own RFID-ID number, allowing it to use different multicast addresses than other door locks.

[0035] Note: The hash method for calculating X in multicast address 226.1.1.X is as follows: 1) First, convert the IP address 226.1.1.0 into a constant U. The conversion method is as follows: assume each byte is in binary and concatenates them sequentially to form a 32-bit binary number U. The binary representation of 226 is 11100010, the binary representation of 1 is 00000001, and the binary representation of 0 is 00000000. Concatenating them gives 11100010 00000001 0000000100000000; 2) Extract the RFID(b) into a binary number V. For example, if the RFID(b) number is 98765432 (decimal), then the binary number is 101111000110000101001110000 (Note: the actual length may be less than 32 bits, so pad it with zeros to make it 32 bits). The zero-padded V is: 00000000 01011110 00110000 10100111 0000 (at this point, you need to ensure that it is 32 bits). 3) Concatenate U and V into a binary data stream to obtain a 64-bit binary data stream (e.g., direct connection): 11100010 00000001 00000001 00000000 00000000 01011110 00110000 10100111 0000; 4) Perform a hash calculation (such as CRC32, MD5, SHA-1, etc.) on the binary data stream concatenated with U and V, and take the modulo of the result with 256 to obtain an output between 0 and 255. For example, if CRC32 is used to calculate the CRC32 hash value, a 32-bit integer (e.g., 0x000000A0, which is 160) is obtained. Taking the modulo of 256 yields 160 (160 % 256 = 160 (because 160 < 256)).

[0036] 5) The result is X=160, and the multicast address after hash calculation is: 226.1.1.160.

[0037] Lock B sends an IGMP assistance message for "assistance call" to the target IP address 226.1.1.160, including the lock ID (B) and a validity period of 30 seconds. The router receives and parses the IGMP assistance message for "assistance call" sent by B, creates or updates a multicast forwarding entry (*, 226.1.1.160) in its routing table, and records a 30-second validity period on the interface that received the IGMP assistance message in this forwarding table entry (in this case, the interface connected to lock B). (Subsequently, when the router receives a multicast message with a destination address of 226.1.1.160, it will only forward it to this interface; the information about the above interface in the multicast forwarding table entry (*, 226.1.1.160) will be automatically deleted after the 30-second validity period). While sending the "Assistance Call" IGMP message, door lock B caches the dispatch robot event information, including the dispatch event ID number (the assisted door lock ID (B) + timestamp), RFID-ID (b), assisting door lock ID (B), validity period = 60 seconds, etc., and then starts a 60-second countdown (the 60-second countdown is set to accommodate the processing delay of door lock A, router, etc.). After 60 seconds, the dispatch robot event information is deleted.

[0038] In this scenario, if the owner of lock D (carrying RFID (d)) summons the robot on behalf of the owner of lock C, lock D sends an IGMP assistance message for "assistance call" to the target IP address 226.1.1.108 (assuming the calculation result X is 108 according to the hash calculation method described above). The router receives and parses the message sent by D, extracts information such as the multicast group address 226.1.1.108, creates or updates a multicast forwarding table entry (*, 226.1.1.108) in the routing table, and records a 30-second validity period on the interface that received the IGMP assistance message for "assistance call" in the forwarding table entry.

[0039] Note: Based on the above calculation method, the multicast addresses that B and D applied to join are 226.1.1.160 and 226.1.1.108 respectively. The two are clearly different and will not cause confusion.

[0040] After door lock A detects two doorbell button messages (at this time, b presses the "doorbell" button twice on door lock A to trigger the robot summoning process), it reads RFID-ID(b) (at this time, b swipes the RFID(b) card on door lock A). A extracts RFID-ID(b) and compares it with the RFID-ID numbers in A's resident registration information table one by one. However, it cannot be matched successfully (at this time, RFID-ID(b) is not the RFID-ID number in A's resident registration information table). Upon detecting two doorbell button notifications (at this point, b presses the "doorbell" button twice on door lock A to confirm the robot summoning), door lock A calculates X in the multicast address 226.1.1.X using the hash method described above, forming the multicast address 226.1.1.160 (since they have the same RFID-ID (b) at this time, the X in the calculated 226.1.1.X is the same as the X calculated by door lock B, i.e., X=160). Door lock A sends a "Request for Assistance" multicast message to the target IP address 226.1.1.160, containing door lock ID (A), door lock IP (A), RFID-ID (b), and a validity period of 30 seconds. Simultaneously, A caches the robot summoning event, containing the summoning event ID (encoded as: door lock ID (A) + timestamp), RFID-ID (b), assisting door lock ID / pending, and a validity period of 60 seconds, and then begins a 60-second countdown. Lock A sends a "Request for Assistance" multicast message to request the router to forward it.

[0041] The router receives a multicast message requesting assistance from A, extracts the target IP address 226.1.1.160, looks up the entry (*, 226.1.1.160) in the multicast forwarding table, and checks if the validity period has exceeded 30 seconds. The outgoing interface list of this entry contains the interface connected to door lock B (this entry indicates that door lock B previously sent an IGMP assistance message). The router forwards A's multicast message from this interface of the multicast forwarding entry (*, 226.1.1.160) (at this time, the receiver is door lock B).

[0042] At this point, if door lock C detects two doorbell button notifications, it generates and sends a "Request for Assistance" multicast message containing RFID-ID(d), a target address of 226.1.1.108 (door lock C first calculates the multicast address using the hash of 226.1.1.0 and RFID(d) according to the aforementioned method; since it is the same RFID(d), the calculated multicast address is the same as the multicast address calculated by D), and includes door lock ID(D), RFID-ID(d), etc. The router receives this multicast message, extracts the target IP address 226.1.1.108, and looks up the entry (*, 226.1.1.108) in the multicast forwarding table, checking if the validity period exceeds 30 seconds. The outgoing interface list of this entry contains the interface connected to door lock D (this entry indicates that door lock D previously sent an IGMP assistance message). The router forwards A's multicast message from this interface of the multicast forwarding entry (*, 226.1.1.108) (at this time, the receiver is door lock D).

[0043] Note: The multicast IP addresses 226.1.1.X obtained by calculating 226.1.1.0 and RFID(b) / RFID(d) hashes using the aforementioned method are different for locks B and D. They are 226.1.1.160 and 226.1.1.108 respectively. Therefore, the multicast forwarding table entries created or updated by the router after receiving IGMP messages from locks B and D will also be different: Lock B: (*, 226.1.1.160), with the outgoing interface connected to lock B; Lock D: (*, 226.1.1.108), with the outgoing interface connected to lock D. When lock A sends a multicast message using the multicast address 226.1.1.160 calculated from the detected RFID(b), the router will forward it to lock B. Similarly, when lock C sends a multicast message using the multicast address 226.1.1.108 calculated from the detected RFID(d), the router will forward it to lock D. This allows for a relatively clear distinction between the two.

[0044] When door lock B receives a "Request for Assistance" message from A forwarded by the router, it checks the cached call robot event information based on the RFID-ID(b) in the message. If it confirms that the RFID-ID(b) is the cached call RFID card, it replies to door lock A with an "Assistance Confirmation" message, which includes the RFID-ID(b), door lock ID(B), and whether the call is confirmed / yes.

[0045] When door lock A receives the "Assistance Confirmation" message from B, it checks if the "Confirm Recall?" result in the message is "Yes". If so, it sends a "Summon Robot" message to the platform, including the door lock ID (A). Simultaneously, door lock A stores the summon robot record for future reference, including the door lock ID (A), confirmation / yes status, summoning RFID / RFID (b), summoned door lock / door lock ID (B), and a timestamp (the clock at which B's reply message was received). The summon robot record is automatically deleted after one year.

[0046] Further improvement: When door lock B sends an IGMPv3 report message, it simultaneously uses the destination multicast IP address 226.1.1.160 calculated via the hash method described above, and the RFID number mapped to IP address calculation method in this scheme to obtain a fake source IP address 38.29.174.229. The router will generate a (S, G) multicast forwarding table entry (38.29.174.229, 226.1.1.160) in its routing table. When door lock A sends a multicast message, it similarly uses the destination multicast IP address 226.1.1.160 calculated via the hash method described above, and the RFID number mapped to IP address calculation method in this scheme to obtain a fake source IP address 38.29.174.229. Then, based on the (S, G) multicast forwarding table entry, the router can forward A's multicast message to B. Using this method, when the owner d of lock D summons the robot for the owner c of lock C using RFID(d), since RFID(d) and RFID(b) are different at this time, the destination multicast IP calculated by the hash method is different, and the fake source IP address is also different, which can eliminate the phenomenon of router forwarding chaos.

[0047] In the above steps, when the door lock calculates X in the multicast address 226.1.1.X using the RFID hash method with 226.1.1.0 and the RFID ID number, and uses 226.1.1.X as its multicast address, since the value range of X is 0~255 (a total of 256 values), while the number of RFIDs may be much greater than 256, according to the pigeonhole principle (if the possible values ​​of the hash output (at this time, there are 256 possible values ​​of X) are less than the possible values ​​of the input (at this time, the number of RFIDs may be much greater than 256)), there will inevitably be a hash collision, that is, the calculated result may be the same 226.1.1.X. In this scenario, if lock B's owner (b) is also lock A's owner (a) and summons the robot using 226.1.1.160 via hash calculation, and another group or multiple groups are simultaneously using this multicast group (226.1.1.160), for example, lock D's owner (d) is lock C's owner (c) and summons the robot using 226.1.1.160 via hash calculation, then the multicast message sent by A will be forwarded to both B and D simultaneously, causing message confusion. To solve this problem, the following optimization is proposed: After door lock B detects two doorbell button notifications (at this time, b presses the "doorbell" button twice on door lock B), the robot summoning process is initiated and a 30-second countdown begins (waiting for RFID card reading; if the RFID card is not read within 30 seconds, the robot summoning process ends; to continue summoning the robot, the "doorbell" button needs to be pressed twice again on door lock B). If the RFID card is not read within 30 seconds (at this time, it may be that a stranger pressed the "doorbell" button twice on door lock B, and the stranger does not have an RFID card), the process ends. If B reads the RFID card, it matches the RFID card with the RFID-IDs in the "Resident Registration Owner Information Form" one by one, and a successful match is RFID-ID(b) (at this time, b uses his / her own RFID-ID(b) to swipe the card on door lock B).

[0048] Door lock B calculates the multicast destination IP address 226.1.1.X using a hash method with the RFID tag ID number RFID-ID(b) (for example, after hash calculation, X=160; the hash calculation method is as described above and will not be repeated here), obtaining the multicast destination IP address 226.1.1.160. Door lock B then uses a hash algorithm combined with segmented mapping to convert the RFID tag ID number RFID-ID(b) into an IPv4 address, obtaining the fake source IP address 38.29.174.229.

[0049] The calculation method for mapping RFID numbers to IP addresses is as follows: 1) Select a hash algorithm (such as MD5, SHA-1, CRC32, etc.) to calculate the hash value: This solution uses the CRC32 algorithm (CRC32 is relatively simple to calculate; if a lower collision rate is required, MD5 or SHA-1 can be used), and RFID (b) number: 98765432 as an example: 2) Calculate the CRC32 hash value of the RFID-ID: Convert the RFID(b) number: 98765432 into 32-bit binary: 000000101 11100011 00001010 01110000 (pad zeros in front to make it 32 bits if necessary), and use the CRC32 algorithm to calculate the hash value: 0x261DAEE5.

[0050] 3) Map the hash value to the IPv4 address using the segmented mapping method: The hash value 0x261DAEE5 is split into four 8-bit parts and the decimal values ​​are calculated as 0x26 (38), 0x1D (29), 0xAE (174), and 0xE5 (229), and directly mapped to the four parts of the IPv4 address to form the IPv4 address: 38.29.174.229.

[0051] Door lock B sends an IGMPv3 report message to request joining the specified multicast group using the fake source IP address and multicast group address calculated in the above steps. The message includes a fake source IP address (38.29.174.229), a hashed multicast group address (226.1.1.160), and a validity period of 30 seconds. The router receives the IGMPv3 report message from B, resolves the fake source IP address and hashed multicast group address, generates a (S, G) multicast forwarding table entry (38.29.174.229, 226.1.1.160) in its routing table, and records the 30-second validity period on the interface receiving the IGMPv3 report message (the interface connected to B in this case).

[0052] At this point, if there exists a scenario where the owner d of lock D (carrying RFID (d)) summons the robot on behalf of the owner c of lock C, lock D, using the fake source IP address calculated in the above steps (assuming the IP address mapped to RFID (d) is 192.168.1.100) and the multicast group address (according to the hash calculation method in the above steps, if the calculation result X is 108, then the multicast IP address is 226.1.1.108), sends an IGMPv3 report message to request joining the specified multicast group. The message includes the source address as the fake source IP address (192.168.1.100), the multicast group address as the hashed multicast group address (226.1.1.08), and a validity period of 30 seconds. The router receives the IGMPv3 report message sent by D, resolves the fake source IP address and the hashed multicast group address, generates a (S, G) multicast forwarding table entry (192.168.1.100, 226.1.1.108) in the routing table, and records a 30-second validity period for the interface that receives the IGMPv3 report message (which is the interface connected to D at this time).

[0053] Note: Based on the improved method above, the multicast forwarding table entries in the router corresponding to the interfaces connecting B and D are (38.29.174.229, 226.1.1.160) and (192.168.1.100, 226.1.1.108), respectively. The two are clearly different in terms of source IP address and destination multicast IP address, and will not cause confusion.

[0054] When door lock A detects two doorbell button messages (at this time, b presses the "doorbell" button twice on door lock A to trigger the robot summoning process), it reads RFID-ID(b) (at this time, b swipes the RFID(b) card on door lock A). A extracts RFID-ID(b) and compares it with the RFID-ID numbers in A's resident registration information table one by one. If the match fails, it will not be successful (at this time, RFID-ID(b) is not the RFID-ID number in A's resident registration information table). Upon detecting two doorbell button notifications (at this time, b presses the "doorbell" button twice on door lock A to confirm summoning the robot), door lock A calculates X in the multicast address 226.1.1.X using the hash method described above, forming the multicast address 226.1.1.160 (since they have the same RFID-ID (b) at this time, the X in the calculated 226.1.1.X is the same as the X calculated by door lock B, i.e., X=160), and maps the RFID-ID (b) to the IP address 38.29.174.229 using the hash method described above (since A reads the same RFID-ID (b) as B at this time). Door lock A then sends a "Request for Assistance" multicast message to the target IP address 226.1.1.160 using a fake source IP address 38.29.174.229, containing the door lock ID (A), door lock IP (A), RFID-ID (b), and a validity period of 30 seconds. Meanwhile, lock A caches the summoning robot event, including the summoning event ID (encoded as: lock ID (A) + timestamp), RFID-ID (b), assisting lock ID / pending, validity period = 60 seconds, etc., and then starts a 60-second countdown. Lock A sends a "Request Assistance" multicast message to request the router to forward it.

[0055] The router receives a multicast message requesting assistance from A, extracts the destination IP address 226.1.1.160 and the source IP address 38.29.174.229, and looks up the entry (38.29.174.229, 226.1.1.160) in the multicast forwarding table. It then checks if the validity period has exceeded 30 seconds. The outgoing interface list of this entry contains the interface connected to door lock B (this entry indicates that door lock B previously sent an IGMPv3 report message). The router forwards A's multicast message from this interface of the multicast forwarding entry (38.29.174.229, 226.1.1.160) (at this time, the receiver is door lock B).

[0056] At this time, if door lock C detects the doorbell button information twice, it generates and sends a "Request for Assistance" multicast message containing RFID-ID(d), a target address of 226.1.1.108 (door lock C first calculates the multicast address using the aforementioned method with 226.1.1.0 and RFID(d) hash; since it is the same RFID(d), the calculated multicast address is the same as the multicast address calculated by D), and a source IP address of 192.168.1.100 (using the aforementioned RFID(d) hash mapping method), and includes door lock ID(D), RFID-ID(d), etc. The router receives the multicast message, extracts the destination IP address 226.1.1.108 and the source IP address 192.168.1.100, and looks up the entry (192.168.1.100, 226.1.1.108) in the multicast forwarding table. It then checks whether the validity period has exceeded 30 seconds. The outgoing interface list of this entry contains the interface connected to door lock D (this entry indicates that door lock D previously sent an IGMP assist message). The router forwards A's multicast message from this interface of the multicast forwarding entry (192.168.1.100, 226.1.1.108) (at this time, the receiver is door lock D).

[0057] Note: The multicast IP addresses 226.1.1.X obtained by calculating 226.1.1.0 and RFID(b) / RFID(d) hashes for locks B and D are different, specifically 226.1.1.160 and 226.1.1.108 respectively. Furthermore, the pseudo-source IP addresses obtained by mapping RFID(b) / RFID(d) hashes to IP addresses are 38.29.174.229 and 192.168.1.100 respectively. Therefore, the multicast forwarding table entries created or updated after the router receives multicast messages from locks B and D will also be different: Lock B: (38.29.174.229, 226.1.1.160), with the outgoing interface connected to lock B; Lock D: (192.168.1.100, 226.1.1.108), with the outgoing interface connected to lock D. When lock A sends a multicast message based on the multicast address 226.1.1.160 calculated from the detected RFID (b), the router forwards it to B. When lock C sends a multicast message based on the multicast address 226.1.1.108 calculated from the detected RFID (d), the router forwards it to D. This method can achieve a clearer distinction than the method described above.

[0058] Door lock B receives a "Request for Assistance" message from A forwarded by the router. Based on the RFID-ID(b) in the message, it checks the cached call-agent robot event information. If it confirms that RFID-ID(b) is the cached call-agent RFID card, it unicasts a "Confirm Assistance" message to door lock A. (The door lock IP(A) can be extracted from the message forwarded by the router from A; it cannot be extracted from the multicast message because the source IP is a fake source IP address.) This message includes the RFID-ID(b), door lock ID(B), and whether the call-agent is confirmed / yes.

[0059] When door lock A receives the "Assistance Confirmation" message from B, it checks if the "Confirm Recall?" result in the message is "Yes". If so, it sends a "Summon Robot" message to the platform, including the door lock ID (A). Simultaneously, door lock A stores the summon robot record for future reference, including the door lock ID (A), confirmation / yes status, summoning RFID / RFID (b), summoned door lock / door lock ID (B), and a timestamp (the clock at which B's reply message was received). The summon robot record is automatically deleted after one year.

[0060] The platform receives a message from door lock A to summon a robot, and dispatches the robot to A to perform facial recognition and unlock the door for the owner a.

[0061] Detailed explanation of the implementation process: The platform receives and caches the "Summon Robot" message sent by door lock A, dispatches the robot (robot dispatching is not the focus of this invention and will not be elaborated further), sends the door lock ID (A), door lock IP (A), etc. from the "Summon Robot" message to the robot, and at the same time, the platform sends a reply message to door lock A indicating that the robot has been dispatched. Door lock A receives the reply message from the platform and displays "Robot successfully summoned, please wait" on its display screen. The robot receives the dispatch instructions from the platform, autonomously navigates to door lock A according to the room ID (A) (autonomous navigation and walking of the robot are not the focus of this invention and will not be elaborated further), establishes a connection with door lock A, and then performs facial recognition comparison for door lock A. If the facial recognition is successful, the door is unlocked and opened for door lock A.

[0062] The system ultimately determines whether a neighbor can summon the robot on behalf of another by using RFID card swiping authorization from a neighbor, coordinating with the doorbell button on the door lock, and confirming the countdown timer for the same RFID-activated robot summoning function on the platform.

[0063] Another embodiment of the present invention provides a system for coordinated processing of door locks and cards, see [link to relevant documentation]. Figure 3 The system may include: The verification module 301 is used to trigger process and permission verification: based on the preset number of doorbell button operations detected by the first door lock and the neighbor RFID card information read, it triggers the robot summoning process, verifies the matching result of the RFID card and the resident registration form, and generates a permission verification pass signal; The generation module 302 is used for multicast address and fake source IP generation: based on the ID number of the RFID card, the target multicast address is calculated by a hash algorithm, and the ID number of the RFID card is converted into a fake source IP address by a segmented mapping method, so as to obtain a set of communication parameters containing the multicast address and the fake source IP. The sending module 303 is used for multicast message sending and routing table construction: according to the communication parameter set, it sends an IGMPv3 report message carrying a fake source IP and multicast address to the router, triggering the router to generate a (S, G) multicast forwarding table entry and bind it to the receiving interface, where S is the fake source IP and G is the target multicast address; Forwarding module 304 is used for cross-lock request forwarding and confirmation: based on the trigger operation of the same RFID card detected by the second lock being assisted, a request for assistance multicast message containing a multicast address and a fake source IP is generated, and forwarded to the first lock through the router matching (S, G) forwarding table entry, and the first lock sends an assistance confirmation message to the second lock to complete the robot summoning authorization.

[0064] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0065] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0066] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0067] As can be seen, based on the preset number of doorbell button operations detected by the first door lock and the information of the neighbor's RFID card, the robot summoning process is triggered, and the matching result of the RFID card and the resident registration form is verified to generate an authorization verification pass signal; based on the ID number of the RFID card, the target multicast address is calculated, and the ID number of the RFID card is converted into a fake source IP address to obtain a set of communication parameters; according to the set of communication parameters, an IGMPv3 report message is sent to the router; based on the trigger operation of the same RFID card detected by the assisted second door lock, a request for assistance multicast message is generated, which is forwarded to the first door lock through the router matching (S, G) forwarding table entry, and the first door lock sends an assistance confirmation message to the second door lock to complete the robot summoning authorization, thereby realizing efficient, safe, and low-latency cross-door lock collaborative operation.

[0068] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for coordinated processing of door locks and cards, characterized in that, The method includes: Triggering process and authorization verification: Based on the preset number of doorbell button operations detected by the first door lock and the neighbor's RFID card information read, the robot summoning process is triggered, and the matching result of the RFID card and the resident registration form is verified to generate an authorization verification pass signal; Multicast address and fake source IP generation: Based on the ID number of the RFID card, the target multicast address is calculated by a hash algorithm, and the ID number of the RFID card is converted into a fake source IP address by a segmented mapping method, resulting in a set of communication parameters containing the multicast address and the fake source IP. Multicast message sending and routing table construction: Based on the set of communication parameters, an IGMPv3 report message carrying a fake source IP and multicast address is sent to the router, triggering the router to generate a (S, G) multicast forwarding table entry and bind it to the receiving interface, where S is the fake source IP and G is the target multicast address; Cross-lock request forwarding and confirmation: Based on the trigger operation of the same RFID card detected by the assisted second lock, a request for assistance multicast message containing a multicast address and a fake source IP is generated. The message is forwarded to the first lock through the router matching (S, G) forwarding table entry, and the first lock sends an assistance confirmation message to the second lock to complete the robot summoning authorization.

2. The method according to claim 1, characterized in that, The triggering process and permission verification include: Button operation detection: When the first door lock detects two consecutive doorbell button operations within a preset time, a 30-second countdown is started and the RFID card reader module is activated; RFID matching verification: Read the RFID card ID number and compare it with the resident registration form. If the match is successful, an authorization verification pass signal is generated; otherwise, the process is terminated. Cache recall events: Record recall event information, including RFID card ID number, multicast address, fake source IP and validity period, and start countdown monitoring. The validity period is updated synchronously with the validity period of the routing table entry.

3. The method according to claim 2, characterized in that, The generation of the multicast address and fake source IP includes: Multicast address calculation: Convert the base IP address 226.1.1.0 into a 32-bit binary constant U, concatenate it with the 32-bit binary representation V of the RFID card ID number to form a 64-bit data stream, calculate the hash value using the CRC32 hash algorithm and take the modulo 256 to obtain X in the multicast address 226.1.1.X; Fake source IP generation: Perform CRC32 hash calculation on the RFID card ID number, split the result into four 8-bit segments and convert them into decimal numbers to generate fake source IP addresses; Parameter binding: Associates the multicast address with the fake source IP address to form a set of communication parameters.

4. The method according to claim 3, characterized in that, The multicast message sending and routing table construction includes: IGMPv3 message encapsulation: Encapsulate the fake source IP address, multicast address, and 30-second validity period into an IGMPv3 report message; Routing table update: The router parses the IGMPv3 message, creates an (S, G) entry in the multicast forwarding table and binds it to the receiving interface, setting a validity period of 30 seconds; Exception handling: If the same (S, G) entry is detected to already exist, refresh the validity period of 30 seconds.

5. The method according to claim 4, characterized in that, The cross-lock request forwarding and confirmation includes: Cross-lock operation synchronization: After the assisted second lock detects two doorbell operations of the same RFID card, it generates a request for assistance message containing the same multicast address and fake source IP. Router precise forwarding: The router forwards the request message to the interface corresponding to the first lock according to the (S, G) forwarding table entry; Assistance confirmation and task triggering: After the first door lock verifies the validity of the RFID card, it sends a confirmation message to the second door lock, which then initiates a robot dispatch request to the platform.

6. A system for coordinated processing of door locks and cards, characterized in that, The system includes: The verification module is used to trigger process and permission verification: based on the preset number of doorbell button operations detected by the first door lock and the neighbor RFID card information read, the robot summoning process is triggered, and the matching result of the RFID card and the resident registration form is verified to generate a permission verification pass signal; The generation module is used to generate multicast addresses and fake source IPs: based on the ID number of the RFID card, the target multicast address is calculated by a hash algorithm, and the ID number of the RFID card is converted into a fake source IP address by a segmented mapping method, so as to obtain a set of communication parameters containing the multicast address and the fake source IP. The sending module is used for multicast message sending and routing table construction: based on the communication parameter set, it sends an IGMPv3 report message carrying a fake source IP and multicast address to the router, triggering the router to generate a (S, G) multicast forwarding table entry and bind it to the receiving interface, where S is the fake source IP and G is the target multicast address; The forwarding module is used for cross-lock request forwarding and confirmation: based on the trigger operation of the same RFID card detected by the second lock being assisted, a request for assistance multicast message containing a multicast address and a fake source IP is generated. The message is forwarded to the first lock through the router matching (S, G) forwarding table entries, and the first lock sends an assistance confirmation message to the second lock to complete the robot summoning authorization.

7. The system according to claim 6, characterized in that, The verification module is specifically used for: Button operation detection: When the first door lock detects two consecutive doorbell button operations within a preset time, a 30-second countdown is started and the RFID card reader module is activated; RFID matching verification: Read the RFID card ID number and compare it with the resident registration form. If the match is successful, an authorization verification pass signal is generated; otherwise, the process is terminated. Cache recall events: Record recall event information, including RFID card ID number, multicast address, fake source IP and validity period, and start countdown monitoring. The validity period is updated synchronously with the validity period of the routing table entry.

8. The system according to claim 7, characterized in that, The generation module is specifically used for: Multicast address calculation: Convert the base IP address 226.1.1.0 into a 32-bit binary constant U, concatenate it with the 32-bit binary representation V of the RFID card ID number to form a 64-bit data stream, calculate the hash value using the CRC32 hash algorithm and take the modulo 256 to obtain X in the multicast address 226.1.1.X; Fake source IP generation: Perform CRC32 hash calculation on the RFID card ID number, split the result into four 8-bit segments and convert them into decimal numbers to generate fake source IP addresses; Parameter binding: Associates the multicast address with the fake source IP address to form a set of communication parameters.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-5 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-5.

Images