A method and system for door lock vehicle coordination

Abstract

The application discloses a kind of door lock vehicle cooperation method and system, method includes: according to the IGMP member report message sent by owner family door lock, all parking stall sharing provider and demand side door lock join the multicast group G of pre-set;According to multicast release message sent by provider door lock, which carries parking stall sharing message mark, continue to forward after adding shared release gateway ID field by provider direct connection gateway, other demand side door lock receives and locally stores shared provider information;According to multicast application message sent by demand side door lock, which carries parking stall sharing message mark, provider direct connection gateway carries out auction processing to multiple applications according to two-stage timing auction algorithm;According to the auction processing result of provider direct connection gateway, generate confirmation or rejection message, forward by multicast and reach demand side door lock after being handled by demand side direct connection gateway.Utilize the embodiment of the application, the security of user privacy data and the fairness of parking stall resource allocation can be guaranteed.

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 vehicle coordination. Background Technology

[0002] With the continuous growth of urban car ownership, the shortage of parking spaces is becoming increasingly prominent. Smart lock and vehicle collaboration technology offers a new solution for parking space sharing. Existing parking space sharing solutions mainly rely on cloud servers for centralized information forwarding and matching. Users need to publish or apply for parking spaces through a mobile app, and the system notifies both parties after matching supply and demand in the cloud. This centralized architecture has two shortcomings: First, all interactive data must be relayed through the cloud, increasing communication latency, which can easily cause response congestion, especially during peak parking space application periods; second, sensitive data such as user location information and parking space usage patterns are uploaded to the cloud, posing a risk of privacy leaks. In addition, traditional solutions lack an effective real-time bidding mechanism, making it difficult to allocate resources fairly and efficiently when multiple users apply for the same parking space simultaneously. Therefore, there is an urgent need for a decentralized, low-latency lock and vehicle collaboration method with dynamic competition processing capabilities to improve the real-time performance and security of parking space sharing. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for door lock vehicle coordination to overcome the shortcomings of the prior art and ensure the security of user privacy data and the fairness of parking space resource allocation.

[0004] One embodiment of this application provides a method for door lock vehicle coordination, the method comprising: Parking space sharing multicast group establishment: Based on the IGMP member report message sent by the owner's home door lock, all parking space sharing provider and demander door locks join the preset multicast group G, completing system initialization; Parking space sharing information publishing and recording: Based on the multicast publishing message carrying the parking space sharing message tag sent by the provider's door lock, the provider's direct connection gateway identifies the parking space sharing message tag, adds the sharing publishing gateway ID field, and then continues to forward it. Other requesting door locks receive and store the sharing provider information locally. Parking space sharing application and bidding processing: Based on the multicast application message carrying the parking space sharing message tag sent by the demand side's door lock, the demand side's direct connection gateway identifies the parking space sharing message tag, adds the sharing application gateway ID field, and forwards it to the provider's direct connection gateway. The provider's direct connection gateway processes multiple applications for bidding according to a two-stage timed bidding algorithm. Application Confirmation and Result Feedback: Based on the bidding results of the provider's direct-connect gateway, a confirmation or rejection message carrying the source IP masquerading as the provider's door lock address is generated. After being forwarded via multicast and processed by the requester's direct-connect gateway, the message is delivered to the requester's door lock, completing the parking space sharing application process.

[0005] Optionally, the publication and recording of parking space sharing information includes: Message generation and transmission: Based on the sharing parameters configured on the door lock by the provider owner, the door lock generates and sends a multicast message containing the destination multicast IP, the source IP of the door lock address, the parking space sharing message tag, the message type of the parking space sharing, the provider door lock ID, and the lowest sharing unit price. Gateway listening and field addition: Based on the multicast message carrying the parking space sharing message tag sent by the directly connected door lock, which is detected by the provider's direct-connected gateway, add the sharing publishing gateway ID field to the message, without changing the source IP and destination IP, and continue to forward the multicast message; Local publishing record storage: Based on the provider's direct connection gateway, the parking space sharing publishing confirmation record is stored locally, including the provider's door lock ID, provider's door lock IP, minimum sharing unit price, and confirmed demander's door lock information. The confirmed demander's door lock information is initially empty. Demand-side information recording: Based on the publication message received by other door locks that have joined multicast group G, the sharing provider information is stored locally, including the provider door lock ID, the lowest sharing unit price, and the sharing publishing gateway ID.

[0006] Optionally, the parking space sharing application and bidding process includes: Application message generation and transmission: Based on the parking space sharing application parameters set by the owner on the door lock, the door lock queries the parking space sharing provider information, and then generates and sends a multicast application message containing the destination multicast IP, the source IP of the owner's door lock address, the parking space sharing message tag, the message type of the parking space sharing application, the owner's door lock ID, the provider's door lock ID, the sharing publishing gateway ID, the sharing application price, the bidding range and the maximum price limit; Add the following to the demand-side gateway field: Based on the multicast message carrying the parking space sharing message tag sent by the directly connected door lock detected by the demand-side direct-connected gateway, add the sharing request gateway ID field to the message, without changing the source IP and destination IP, and continue to forward the multicast message. Provider Gateway Reception and Caching: Upon receiving the application message from the provider's directly connected gateway, the provider's lock ID and shared publishing gateway ID are parsed out. It is confirmed that the application is for a lock directly connected to this gateway. The local publishing confirmation record is queried. If there is no confirmed request from the corresponding provider lock, the application information is cached and the initial confirmation timer for this application from the provider lock is started. If there is a confirmed request, a rejection message is sent. Two-phase bidding process: Based on whether the provider gateway receives other request messages for the same provider lock during the initial confirmation timer period, the following processing is performed: If the initial confirmation timer expires and there are no new requests, an initial confirmation multicast message with the provider lock's IP address as the source IP is sent to impersonate the provider lock, declaring the initial confirmation request lock as the original requester and announcing its initial confirmation request price. Then, the final confirmation timer associated with that requester lock for this request to the provider lock is started. If a new request is received during the initial confirmation timer period, and if the new request price is higher than the current winning price, the new requester wins. If the prices are the same, the winner is determined by the order in which the messages arrive at the provider's directly connected gateway; the first message arrives wins. After determining the winner, the current initial confirmation timer is canceled, and a new multicast is performed. An initial acknowledgment message with the source IP of the provider's lock is sent to impersonate the provider's lock and declare the initial acknowledgment request lock as the winning lock, announcing its initial acknowledgment request price. Then, the initial acknowledgment timer associated with the winning lock is started. If the final acknowledgment timer expires and there are no new requests, the request is confirmed as successful. Then, a final acknowledgment multicast message with the source IP of the provider's lock is sent, and the information of the confirmed request lock is recorded. If a new request is received during the final acknowledgment timer, the winner is determined according to the price and the order of message arrival. The current final acknowledgment timer is then canceled, and an initial acknowledgment message with the source IP of the provider's lock is re-multicasted to declare the initial acknowledgment request lock as the winning lock, announcing its initial acknowledgment request price. Then, the initial acknowledgment timer associated with the winning lock is started. Blacklist filtering mechanism: During the two-stage bidding process, a temporary blacklist is maintained by the provider's gateway. If the number of consecutive bids from the same demander for a door lock that are not higher than the current winner's bid exceeds a preset threshold, the door lock from that demander will be added to the temporary blacklist, and its subsequent application messages in the current bidding round will be ignored. If the subsequent bids from that demander for a door lock are higher than the current winner's bid and it is not included in the temporary blacklist, its consecutive low price count will be cleared. The bidding round ends when the provider's direct-connected gateway sends the final confirmation message for the sharing application, and the temporary blacklist will be automatically cleared after the bidding ends.

[0007] Optionally, the application confirmation and result feedback include: Confirmation / Rejection Message Generation and Disguised Transmission: Based on the two-stage bidding process of the provider's direct-connect gateway, an initial / final confirmation or rejection message carrying a parking space sharing message tag is generated. The message content includes the destination multicast IP, the source IP disguised as the provider's door lock address, the message type, the provider's door lock ID, the demander's door lock ID for initial / final confirmation or rejection, the initial / final confirmation application price, the shared publishing gateway ID, and the shared requesting gateway ID, and is sent via multicast. Demand-side gateway reception and intelligent processing: Based on the confirmation or rejection message received by the demand-side direct-connected gateway, the following processing is performed: If an initial confirmation message is received and the initial confirmation demand-side is another door lock, the local application record is queried. If the door lock directly connected to this gateway is also applying to the same provider, a bidding increment is added to the initial confirmation price. It is then determined whether the new price exceeds the maximum price limit of the demand-side door lock recorded locally. If it does not exceed the limit, a new application message is regenerated for bidding, and the source IP address of the regenerated application message is set to the IP address of the demand-side door lock. Then, filtering strategies are used to prevent packets from being sent back to the directly connected door locks of this gateway. If a final confirmation packet is received and the final confirmation requester is a directly connected door lock of this gateway, the shared publishing gateway ID and shared requesting gateway ID fields in the packet are removed, the source IP address remains unchanged, and the packet is forwarded to the directly connected door lock. If a final confirmation packet is received and the final confirmation requester is another door lock, or if a rejection packet is received and the rejection requester is a directly connected door lock of this gateway, the shared publishing gateway ID and shared requesting gateway ID fields in the packet are also removed, the source IP address remains unchanged, and the packet is forwarded to the directly connected door lock. Final processing by the requester's door lock: Based on the final confirmation or rejection message received by the requester's door lock, if it is a final confirmation, the owner will be notified of the successful application through the door lock APP; if it is a rejection, the corresponding local sharing provider record will be deleted, and it will be checked whether there are other sharing providers. If so, the application will be resubmitted.

[0008] Optionally, the application confirmation and result feedback also include: Source IP masquerading configuration: When the provider's direct-connected gateway generates an acknowledgment or rejection message, the source IP address of the message is set to the IP address of the provider's lock, rather than the gateway's own IP address; when the demand-side gateway regenerates an application message to increase the bid increment, the source IP address of the message is set to the IP address of the demand-side lock, rather than the gateway's own IP address. Transparent forwarding processing: When the requesting direct-connected gateway forwards the confirmation or rejection message to the direct-connected door lock, it only removes the shared publishing gateway ID and shared requesting gateway ID fields, keeping the source IP address unchanged; Door lock seamless reception: Based on the message received by the requesting door lock, the source IP is parsed to be the address of the providing door lock. It is considered to be a direct reply from the providing door lock, so that the receiving door lock thinks that it is communicating directly with the other door lock, without needing to be aware of the intermediate processing logic of the gateway.

[0009] Optionally, the method further includes dynamic assisted forwarding processing when the gateway is under high load: Assistance request trigger: When the provider's direct-connect gateway detects that the CPU utilization rate continues to exceed the set threshold, an assistance request flag will be added to the next final confirmation message for the sharing request. Idle Gateway Response: If other idle gateways detect a message carrying an assistance request flag and its own CPU utilization is below a set threshold, it multicasts and forwards the assistance request message, which includes the target gateway ID. Assistance confirmation and data synchronization: Based on the assistance request message received from the original provider's direct connection gateway, select one of the idle gateways, multicast an assistance request confirmation message, which includes the locally saved parking space sharing publication confirmation record information, and locally record the IP address of the assisting gateway; Assisting gateway takeover processing: After receiving the confirmation message, the assisting gateway stores the original gateway's publishing record information, records the effective time of the assistance, and starts to respond to the application message for the provider's door lock as the main processing gateway. In all relevant response messages sent by the provider, the shared publishing gateway ID is set as the identifier of this gateway, so that the receiving door lock updates its locally recorded shared publishing gateway information. Transitional message caching and forwarding: After the original provider's direct-connect gateway sends an assistance confirmation message and before the assistance takes effect, it locally caches new application messages for the provider's door lock; when it detects a response message from the assisting gateway with the provider's door lock ID as its own direct-connect door lock, it unicasts and forwards the cached message to the assisting gateway. Assisting gateway supplementary processing: Based on the cached message forwarded by the original gateway received by the assisting gateway, check the message timestamp and the demander lock ID in the message. If the demander lock ID in the message has been marked as a confirmed demander in the parking space sharing release confirmation record, or if the message timestamp is later than the assistance effective time recorded locally by the assisting gateway, then discard the forwarded message; otherwise, perform supplementary processing. Recovery from assistance failure: If the original provider's direct-connect gateway does not detect a response message from the assisting gateway within the set timeout threshold, the assistance is deemed to have failed. The forwarding of the lock message for that provider is resumed, and the provider handles the queue of request messages for that provider's lock that were cached during the transition period. At the same time, the assisting gateway is notified by unicast.

[0010] Another embodiment of this application provides a door lock vehicle coordination system, the system comprising: The module is used to establish a parking space sharing multicast group: based on the IGMP member report message sent by the owner's home door lock, all parking space sharing provider and demander door locks join the preset multicast group G, completing the system initialization; The publishing module is used for publishing and recording parking space sharing information: based on the multicast publishing message carrying the parking space sharing message tag sent by the provider's door lock, the provider's direct connection gateway identifies the parking space sharing message tag, adds the sharing publishing gateway ID field, and then continues to forward it. Other requesting door locks receive and store the sharing provider information locally. The application module is used for parking space sharing application and bidding processing: Based on the multicast application message carrying the parking space sharing message tag sent by the demand side door lock, the demand side direct connection gateway identifies the parking space sharing message tag, adds the sharing application gateway ID field, and forwards it to the provider direct connection gateway. The provider direct connection gateway processes multiple applications for bidding according to the two-stage timed bidding algorithm. The confirmation module is used for application confirmation and result feedback: Based on the bidding results of the provider's direct connection gateway, it generates a confirmation or rejection message carrying the source IP disguised as the provider's door lock address. After being forwarded via multicast and processed by the demander's direct connection gateway, the message is delivered to the demander's door lock to complete the parking space sharing application process.

[0011] 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.

[0012] 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.

[0013] Compared with existing technologies, the door lock and vehicle coordination method provided by this invention can ensure the security of user privacy data and the fairness of parking space resource allocation. Attached Figure Description

[0014] Figure 1 Hardware structure block diagram of a computer terminal for a door lock vehicle coordination method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a method for door lock and vehicle coordination provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a door lock and vehicle coordination system provided in an embodiment of the present invention. Detailed Implementation

[0015] 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.

[0016] Due to limited surface parking spaces in the community, residents often struggle to find parking when guests arrive by car. The community property management has designed a parking space sharing system for residents. When a resident leaves their underground garage, their space becomes available and can be shared with other residents. Other residents can apply for shared parking if they have visitors who need it.

[0017] In small to medium-sized residential communities, a distributed mechanism for publishing, applying for, and confirming shared parking spaces is implemented by utilizing existing network routers and residents' door locks. The core function of the door lock gateway is to handle the bidding logic and protocol conversion on behalf of the residents, while remaining transparent to the door locks.

[0018] This invention first provides a method for door lock and vehicle coordination, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0019] 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 vehicle coordination 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.

[0020] See Figure 2 The present invention provides a method for door lock vehicle coordination, which may include the following steps: S201, Parking space sharing multicast group establishment: Based on the IGMP member report message sent by the owner's home door lock, all parking space sharing provider and demander door locks join the preset multicast group G, completing system initialization; S202, Parking space sharing information publishing and recording: Based on the multicast publishing message carrying the parking space sharing message tag sent by the provider's door lock, the provider's direct-connected gateway identifies the parking space sharing message tag, adds the sharing publishing gateway ID field, and then continues to forward it. Other requesting door locks receive and locally store the sharing provider information; specifically, the parking space sharing information publishing and recording includes: Message generation and transmission: Based on the sharing parameters configured on the door lock by the provider owner, the door lock generates and sends a multicast message containing the destination multicast IP, the source IP of the door lock address, the parking space sharing message tag, the message type of the parking space sharing, the provider door lock ID, and the lowest sharing unit price. Gateway listening and field addition: Based on the multicast message carrying the parking space sharing message tag sent by the directly connected door lock, which is detected by the provider's direct-connected gateway, add the sharing publishing gateway ID field to the message, without changing the source IP and destination IP, and continue to forward the multicast message; Local publishing record storage: Based on the provider's direct connection gateway, the parking space sharing publishing confirmation record is stored locally, including the provider's door lock ID, provider's door lock IP, minimum sharing unit price, and confirmed demander's door lock information. The confirmed demander's door lock information is initially empty. Demand-side information recording: Based on the publication message received by other door locks that have joined multicast group G, the sharing provider information is stored locally, including the provider door lock ID, the lowest sharing unit price, and the sharing publishing gateway ID.

[0021] S203, Parking space sharing application and bidding processing: Based on the multicast application message carrying a parking space sharing message tag sent by the demander's door lock, the demander's direct connection gateway identifies the parking space sharing message tag, adds a sharing application gateway ID field, and forwards it to the provider's direct connection gateway. The provider's direct connection gateway processes multiple applications through bidding according to a two-stage timed bidding algorithm; specifically, the parking space sharing application and bidding processing includes: Application message generation and transmission: Based on the parking space sharing application parameters set by the owner on the door lock, the door lock queries the parking space sharing provider information, and then generates and sends a multicast application message containing the destination multicast IP, the source IP of the owner's door lock address, the parking space sharing message tag, the message type of the parking space sharing application, the owner's door lock ID, the provider's door lock ID, the sharing publishing gateway ID, the sharing application price, the bidding range and the maximum price limit; Add the following to the demand-side gateway field: Based on the multicast message carrying the parking space sharing message tag sent by the directly connected door lock detected by the demand-side direct-connected gateway, add the sharing request gateway ID field to the message, without changing the source IP and destination IP, and continue to forward the multicast message. Provider Gateway Reception and Caching: Upon receiving the application message from the provider's directly connected gateway, the provider's lock ID and shared publishing gateway ID are parsed out. It is confirmed that the application is for a lock directly connected to this gateway. The local publishing confirmation record is queried. If there is no confirmed request from the corresponding provider lock, the application information is cached and the initial confirmation timer for this application from the provider lock is started. If there is a confirmed request, a rejection message is sent. Two-phase bidding process: Based on whether the provider gateway receives other request messages for the same provider lock during the initial confirmation timer period, the following processing is performed: If the initial confirmation timer expires and there are no new requests, an initial confirmation multicast message with the provider lock's IP address as the source IP is sent to impersonate the provider lock, declaring the initial confirmation request lock as the original requester and announcing its initial confirmation request price. Then, the final confirmation timer associated with that requester lock for this request to the provider lock is started. If a new request is received during the initial confirmation timer period, and if the new request price is higher than the current winning price, the new requester wins. If the prices are the same, the winner is determined by the order in which the messages arrive at the provider's directly connected gateway; the first message arrives wins. After determining the winner, the current initial confirmation timer is canceled, and a new multicast is performed. An initial acknowledgment message with the source IP of the provider's lock is sent to impersonate the provider's lock and declare the initial acknowledgment request lock as the winning lock, announcing its initial acknowledgment request price. Then, the initial acknowledgment timer associated with the winning lock is started. If the final acknowledgment timer expires and there are no new requests, the request is confirmed as successful. Then, a final acknowledgment multicast message with the source IP of the provider's lock is sent, and the information of the confirmed request lock is recorded. If a new request is received during the final acknowledgment timer, the winner is determined according to the price and the order of message arrival. The current final acknowledgment timer is then canceled, and an initial acknowledgment message with the source IP of the provider's lock is re-multicasted to declare the initial acknowledgment request lock as the winning lock, announcing its initial acknowledgment request price. Then, the initial acknowledgment timer associated with the winning lock is started. Blacklist filtering mechanism: During the two-stage bidding process, a temporary blacklist is maintained by the provider's gateway. If the number of consecutive bids from the same demander for a door lock that are not higher than the current winner's bid exceeds a preset threshold, the door lock from that demander will be added to the temporary blacklist, and its subsequent application messages in the current bidding round will be ignored. If the subsequent bids from that demander for a door lock are higher than the current winner's bid and it is not included in the temporary blacklist, its consecutive low price count will be cleared. The bidding round ends when the provider's direct-connected gateway sends the final confirmation message for the sharing application, and the temporary blacklist will be automatically cleared after the bidding ends.

[0022] S204, Application Confirmation and Result Feedback: Based on the bidding results of the provider's direct-connect gateway, a confirmation or rejection message carrying a source IP masquerading as the provider's door lock address is generated. This message is forwarded via multicast and processed by the requester's direct-connect gateway before being delivered to the requester's door lock, completing the parking space sharing application process. Specifically, the application confirmation and result feedback includes: Confirmation / Rejection Message Generation and Disguised Transmission: Based on the two-stage bidding process of the provider's direct-connect gateway, an initial / final confirmation or rejection message carrying a parking space sharing message tag is generated. The message content includes the destination multicast IP, the source IP disguised as the provider's door lock address, the message type, the provider's door lock ID, the demander's door lock ID for initial / final confirmation or rejection, the initial / final confirmation application price, the shared publishing gateway ID, and the shared requesting gateway ID, and is sent via multicast. Demand-side gateway reception and intelligent processing: Based on the confirmation or rejection message received by the demand-side direct-connected gateway, the following processing is performed: If an initial confirmation message is received and the initial confirmation demand-side is another door lock, the local application record is queried. If the door lock directly connected to this gateway is also applying to the same provider, a bidding increment is added to the initial confirmation price. It is then determined whether the new price exceeds the maximum price limit of the demand-side door lock recorded locally. If it does not exceed the limit, a new application message is regenerated for bidding, and the source IP address of the regenerated application message is set to the IP address of the demand-side door lock. Then, filtering strategies are used to prevent packets from being sent back to the directly connected door locks of this gateway. If a final confirmation packet is received and the final confirmation requester is a directly connected door lock of this gateway, the shared publishing gateway ID and shared requesting gateway ID fields in the packet are removed, the source IP address remains unchanged, and the packet is forwarded to the directly connected door lock. If a final confirmation packet is received and the final confirmation requester is another door lock, or if a rejection packet is received and the rejection requester is a directly connected door lock of this gateway, the shared publishing gateway ID and shared requesting gateway ID fields in the packet are also removed, the source IP address remains unchanged, and the packet is forwarded to the directly connected door lock. Final processing by the requester's door lock: Based on the final confirmation or rejection message received by the requester's door lock, if it is a final confirmation, the owner will be notified of the successful application through the door lock APP; if it is a rejection, the corresponding local sharing provider record will be deleted, and it will be checked whether there are other sharing providers. If so, the application will be resubmitted.

[0023] Specifically, the application confirmation and result feedback also include: Source IP masquerading configuration: When the provider's direct-connected gateway generates an acknowledgment or rejection message, the source IP address of the message is set to the IP address of the provider's lock, rather than the gateway's own IP address; when the demand-side gateway regenerates an application message to increase the bid increment, the source IP address of the message is set to the IP address of the demand-side lock, rather than the gateway's own IP address. Transparent forwarding processing: When the requesting direct-connected gateway forwards the confirmation or rejection message to the direct-connected door lock, it only removes the shared publishing gateway ID and shared requesting gateway ID fields, keeping the source IP address unchanged; Door lock seamless reception: Based on the message received by the requesting door lock, the source IP is parsed to be the address of the providing door lock. It is considered to be a direct reply from the providing door lock, so that the receiving door lock thinks that it is communicating directly with the other door lock, without needing to be aware of the intermediate processing logic of the gateway.

[0024] Furthermore, the method also includes dynamic assisted forwarding processing when the gateway is under high load: Assistance request trigger: When the provider's direct-connect gateway detects that the CPU utilization rate continues to exceed the set threshold, an assistance request flag will be added to the next final confirmation message for the sharing request. Idle Gateway Response: If other idle gateways detect a message carrying an assistance request flag and its own CPU utilization is below a set threshold, it multicasts and forwards the assistance request message, which includes the target gateway ID. Assistance confirmation and data synchronization: Based on the assistance request message received from the original provider's direct connection gateway, select one of the idle gateways, multicast an assistance request confirmation message, which includes the locally saved parking space sharing publication confirmation record information, and locally record the IP address of the assisting gateway; Assisting gateway takeover processing: After receiving the confirmation message, the assisting gateway stores the original gateway's publishing record information, records the effective time of the assistance, and starts to respond to the application message for the provider's door lock as the main processing gateway. In all relevant response messages sent by the provider, the shared publishing gateway ID is set as the identifier of this gateway, so that the receiving door lock updates its locally recorded shared publishing gateway information. Transitional message caching and forwarding: After the original provider's direct-connect gateway sends an assistance confirmation message and before the assistance takes effect, it locally caches new application messages for the provider's door lock; when it detects a response message from the assisting gateway with the provider's door lock ID as its own direct-connect door lock, it unicasts and forwards the cached message to the assisting gateway. Assisting gateway supplementary processing: Based on the cached message forwarded by the original gateway received by the assisting gateway, check the message timestamp and the demander lock ID in the message. If the demander lock ID in the message has been marked as a confirmed demander in the parking space sharing release confirmation record, or if the message timestamp is later than the assistance effective time recorded locally by the assisting gateway, then discard the forwarded message; otherwise, perform supplementary processing. Recovery from assistance failure: If the original provider's direct-connected gateway fails to detect a response message from the assisting gateway within a set timeout threshold, assistance is deemed to have failed. Forwarding of messages for the provider's lock resumes, and the provider handles the queue of cached request messages for that provider's lock during the transition period. Simultaneously, a unicast notification is sent to the assisting gateway. One technical solution includes: (I) Core Idea: Prerequisites: 1. Each resident's door lock is connected to the community network through their respective floor gateway router. The direct-connect gateways for the door locks all support the listening and processing of parking space sharing multicast messages (multicast messages marked with the parking space sharing message tag), as detailed in the process description.

[0025] 2. All routers in the community network support multicast functionality.

[0026] 3. Homeowners can set up or apply for parking space sharing by pressing a button on their door lock and complete parameter configuration (such as minimum sharing price).

[0027] 4. Door locks and routers achieve time synchronization based on NTP service.

[0028] Core process: 1. System initialization: All parking space sharing providers and homeowners' door locks are added to multicast group G.

[0029] 2. Parking space sharing announcement (Door lock C): The parking space sharing provider's door lock (such as door lock C) multicasts a parking space sharing announcement message, which includes the destination IP (G), source IP (the IP address of door lock C), parking space sharing message tag, message type (parking space sharing announcement), sharing provider's door lock ID (door lock C), minimum sharing unit price, and other information.

[0030] 3. Parking space sharing publishing and forwarding processing (gateway RC): The gateway router (RC) of door lock C listens for and receives the multicast message, adds the shared publishing gateway ID (RC) field, and continues to forward it (without changing the destination IP and source IP address of the message), while storing the parking space sharing publishing confirmation record locally.

[0031] 4. Parking space sharing information record: Other door locks that join multicast group G receive the published messages and store the parking space sharing provider information locally (including door lock C, minimum sharing unit price, and sharing publishing gateway RC).

[0032] 5. Parking space sharing application (lock A and lock B): The parking space requesting party's door locks (such as door locks A and B) multicast a parking space sharing application message, which includes the destination IP (G), source IP (the IP address of door lock A or B), parking space sharing message tag, message type (parking space sharing application), requesting party ID, provider ID, sharing publishing gateway ID, sharing application price, bidding range and maximum price limit.

[0033] 6. Parking space sharing application forwarding processing (gateway RA and RB): The demand-side gateway router (RA, RB) listens for and receives the multicast message, adds the sharing request gateway ID field, and then forwards it (without changing the destination IP and source IP address of the message), while simultaneously recording the parking space sharing request information locally.

[0034] 7. Parking space sharing application confirmation and rejection processing (Gateway RC): After receiving the application message, the publishing gateway (RC) processes it according to the current status of the parking space: If the parking space is available: cache the first request and start an initial confirmation timer. If no higher offer is received when the timer expires, send an initial confirmation message to the requester and start a final confirmation timer. If the final confirmation timer expires, the transaction is completed. If a new offer is received during any timer period, cancel the current timer, send an initial confirmation to the winner, and start a new timer for them. In case of identical offers, the one whose message arrives first prevails.

[0035] To prevent malicious low-price bids from interfering with the bidding process, a temporary blacklist mechanism is introduced: During any given timer period, if the number of consecutive bids from the same bidder for a door lock that are not higher than the current winning bidder's bid exceeds a preset threshold, that door lock will be added to the temporary blacklist. Subsequent bids from that bidder in this round of bidding will be ignored, and the timer will not be reset. If a bid from that bidder for a door lock is higher than the current winning bidder's bid and is not on the temporary blacklist, its consecutive low-price count will be cleared, and it will be considered a normal bidder, making it the new winner. The temporary blacklist is automatically cleared after the end of this round of bidding.

[0036] If the parking space is already occupied: send a rejection message via multicast.

[0037] The source IP of all acknowledgment / rejection messages is spoofed as the address of the provider, door lock C.

[0038] 8. Continuing forwarding processing of request confirmation / rejection messages (Gateway RB): The Request Gateway (RB) processes the RC's (Regulator) messages. If it receives an initial acknowledgment message for another lock, the RB increases the bid increment based on the current quote and multicasts a new request message (the source IP of the message is the IP address of lock B) instead of lock B, and uses filtering policies to prevent the message from being sent back to lock B. If it receives a final acknowledgment or rejection message for lock B, the RB removes the shared publishing gateway ID and shared requesting gateway ID fields (the destination IP and source IP address remain unchanged) and forwards it to lock B.

[0039] 9. Final processing of parking space sharing application (door lock B): The requesting party, door lock B, receives the final confirmation or rejection message. If confirmed, it notifies the owner through the door lock APP; if rejected, it deletes the record and checks if there are other sharing parties. If so, it re-initiates the application.

[0040] 10. Further improvements: Assisted forwarding handling when the gateway is busy; When the provider gateway (RC) is under high load, it initiates an assistance request. The idle assisting gateway (RD) responds and records the effective time. In its response, the RD sets the shared publishing gateway ID field to its own ID in the acknowledgment or rejection multicast message (indicating that it is assisting in handling parking space sharing-related multicast messages for door lock C, replacing the original gateway RC). During the transition period before takeover, the RC caches new request messages for door lock C. When the RC detects a response message from the RD carrying the RD's ID, it determines that the assistance has taken effect, unicasts the cached message to the RD, and stops processing new requests for door lock C. Upon receiving the cached message, the RD checks the timestamp; if it is later than the effective time or the requester ID has been confirmed, it discards the message; otherwise, it performs supplementary processing to ensure state synchronization and business continuity.

[0041] (II) Complete technical implementation process: Prerequisites: Same as above.

[0042] Complete process: 1. System initialization: All parking space sharing providers and demanders' home door locks send IGMP member report messages and join multicast group G.

[0043] 2. Parking space sharing announcement (Door lock C): The parking space sharing provider owner sends a parking space sharing announcement message via multicast through their own door lock (such as door lock C). The message includes the destination IP (G), source IP (the IP address of door lock C), parking space sharing message tag, message type (parking space sharing announcement), sharing provider door lock ID (door lock C), and minimum sharing unit price (such as 4 yuan / hour).

[0044] 3. Parking space sharing publishing and forwarding processing (gateway RC): After the gateway router (such as RC) of door lock C listens for and receives a multicast message containing a parking space sharing message tag sent by its directly connected door lock, it adds the sharing publishing gateway ID (RC) field to the multicast message. The destination IP and source IP address of the message are not changed, and then the multicast message is forwarded. (The purpose of adding the sharing publishing gateway ID field is that other door locks or gateways will retain this field when processing and replying to the message. Later, when RC receives the corresponding multicast message with this field, it can determine that it needs to be processed.) At the same time, a parking space sharing publishing confirmation record is added locally, including the sharing provider door lock ID (door lock C), the sharing provider door lock IP address (the IP address of door lock C), the minimum sharing unit price, and the confirmed sharing requesting door lock (initially empty).

[0045] 4. Parking space sharing information record: The multicast message will be sent to all other door locks that have joined the multicast group G. After receiving the message, the other door locks will store the parking space sharing provider information locally (door lock C, minimum sharing unit price, sharing publishing gateway RC).

[0046] 5. Parking space sharing application (lock A and lock B): Owners requesting parking spaces enter their information via buttons on their door locks (e.g., lock A and lock B). Locks A and B then query information about parking space sharing providers and select a specific lock (e.g., lock C) to request a parking space. A multicast parking space sharing request message is then sent, containing the destination IP (G), source IP (the IP address of lock A or B), parking space sharing message flag, message type (parking space sharing request), requester lock ID (lock A or B), provider lock ID (lock C), sharing gateway ID (RC), sharing request price (the initial value must be equal to or higher than the provider's minimum unit price; otherwise, it will be rejected by the RC), bidding increment (e.g., 1 yuan / hour), and maximum price limit.

[0047] 6. Parking space sharing application forwarding processing (gateway RA and RB): After the gateway router (such as RA) of door lock A listens for and receives a multicast message containing a parking space sharing message tag sent by its directly connected door lock, it adds the sharing request gateway ID (RA) field information to the multicast message (the purpose of adding this field is similar to adding the sharing request gateway ID field to the RC mentioned above). It does not change the destination IP and source IP address of the message, and then continues to forward the multicast message. At the same time, it records the parking space sharing request information locally, including the requesting door lock ID (door lock A or B), the providing door lock ID (door lock C), the sharing publishing gateway ID (RC), the sharing request price, the bidding range, and the maximum price limit.

[0048] The gateway router (such as RB) of door lock B is handled similarly to the gateway router RA.

[0049] 7. Parking space sharing application confirmation and rejection processing (Gateway RC): The parking space sharing request multicast messages from locks A and B are sent to the gateway RC via each router. The gateway RC detects the parking space sharing message marker in the message and, based on the sharing publishing gateway ID (RC) and the provider lock ID (lock C) in the message, confirms that the parking space sharing request is being made to lock C. It then queries the local parking space sharing publishing confirmation record, with two possible scenarios (described below using the example of receiving a message from lock A; the processing of a message from lock B is similar): (1) Case 1: If the confirmed shared lock requester for lock C is empty (meaning lock C has not yet been requested and confirmed), the gateway RC needs to confirm whether there will be other lock bidding. Therefore, it temporarily caches the application information for lock A and starts the initial confirmation timer for the associated lock A (e.g., 30 seconds). Subsequent processing includes the following two stages: Phase 1: Initial Confirmation Timing Phase; 1) Scenario 1-1 (No new applications during the initial confirmation timer): When the initial confirmation timer for the associated lock A expires, if the gateway RC has not received any application messages from other locks for lock C during this period, it confirms that lock A's initial confirmation application was successful. Then, it multicasts a shared application initial confirmation message, which includes the destination IP (G), source IP (lock C's IP address), parking space sharing message flag, message type (shared application initial confirmation), provider lock ID (lock C), initial confirmation requester lock ID (lock A), initial confirmation application quote (lock A's current quote), shared publishing gateway ID (RC), and shared application gateway ID (RA), making this message appear as if lock C is making an initial confirmation to lock A. Then, the final confirmation timer for the associated lock A's application is started (e.g., 30 seconds), entering the second stage.

[0050] Phase Two: Final Confirmation Timing Phase; ① Scenario 1-1-1 (No new applications during the final confirmation timeout): When the final confirmation timer for the application of associated lock A expires, if the gateway RC has not received any application messages from other locks for lock C during this period, it confirms that lock A has applied for final confirmation. Then, it multicasts and sends a shared application final confirmation message, which includes the destination IP (G), source IP (lock C's IP address), parking space sharing message flag, message type (shared application final confirmation), provider lock ID (lock C), final confirmation requester lock ID (lock A), final confirmation application quote (lock A's current quote), shared publishing gateway ID (RC), and shared application gateway ID (RA). This makes the message appear as if lock C is making a final confirmation to lock A. The gateway RC also locally records that the confirmed shared requester lock corresponding to lock C is lock A. At the same time, it unicasts and informs lock C of the application confirmation result. Lock C then sends an application success message to the provider owner's lock APP via the mobile Internet to notify the provider owner.

[0051] ② Scenario 1-1-2 (New application during final confirmation timeout): Before the final confirmation timer for the application of associated lock A expires, if the gateway RC receives an application message from another lock (such as lock B) for lock C, and if lock B's application price is equal to or less than lock A's application price, then lock A is considered to have won (in the case of the same price, the lock that arrives at the gateway RC earlier wins); if lock B's application price is higher than lock A's application price, then lock B is considered to have won. At this point, the gateway RC immediately cancels the final confirmation timer for the application of the associated lock A. If lock B wins, it still caches the application information of the winning lock B. Then, it multicasts and sends a shared application initial confirmation message (the destination IP is the multicast group address G, the source IP is the IP address of lock C, the initial confirmation requester lock ID is the winning lock, the initial confirmation application price is the application price of the winning lock, and the shared application gateway ID is the direct gateway of the winning lock). Then, it starts the application initial confirmation timer for the winning lock (it needs to confirm whether there will be other locks bidding). The subsequent process is as described in step 7 (1). Further improvement: In the final confirmation stage, in order to avoid the winning lock from being unable to end the final confirmation timer due to malicious continuous low-price applications, the gateway RC maintains a temporary blacklist for the shared publication of locks from designated providers. Before the bidding comparison, if the applying lock is in the blacklist, the message is ignored and the timer is not reset. The blacklist maintenance mechanism is as follows: If the number of times the same bidder's bid for a door lock is not higher than the current winning door lock exceeds a threshold (e.g., 3 times), the door lock will be added to the blacklist, and any subsequent applications from that bidder in this round of bidding will be ignored without resetting the timer; if the door lock is not on the blacklist and its bid is higher than the current winning door lock, its consecutive low-price count will be cleared, it will be considered a normal bid, and it will become the new winner according to the original process; after the end of this round of bidding (final confirmation sent), the blacklist will be automatically cleared.

[0052] 2) Scenario 1-2 (New Request During Initial Confirmation Timeout): Before the initial confirmation timer for the request from lock A expires, if the gateway RC receives a request message from another lock (such as lock B) for lock C, the operation is similar to Scenario 1-1-2. The gateway RC also uses a temporary blacklist mechanism to filter malicious low-price requests.

[0053] (2) Case 2: If the confirmed sharing requesting door lock corresponding to door lock C is not empty (meaning that other door locks have successfully applied before), then the gateway RC rejects the application, that is, it sends a multicast sharing application rejection message, the content of which includes the destination IP (G), source IP (the IP address of door lock C), parking space sharing message flag, message type (sharing application rejection), provider door lock ID (door lock C), rejecting requesting door lock ID (door lock A), sharing publishing gateway ID (RC), and sharing requesting gateway ID (RA), making this message look like door lock C is rejecting the application from door lock A.

[0054] 8. Continuing forwarding processing of request confirmation / rejection messages (Gateway RB): Taking gateway RB as an example, when gateway RB receives a multicast message from gateway RC, it processes it as follows, depending on the message type: (1) If the gateway RB receives an initial confirmation message for a shared parking space application (where the provider lock ID is lock C and the initial confirmation request lock ID is another lock), it means that the other lock's bid exceeds that of lock B, but the application has not been finally confirmed. The gateway RB queries the local parking space sharing application information and finds that its directly connected lock B is also applying for lock C. Therefore, it adds a bidding increment to the initial confirmation application bid (i.e., the current bid of other locks) in the message, and then multicasts and sends a parking space sharing application message containing the destination IP (G), source IP (lock B's IP address), parking space sharing message marker, message type (parking space sharing application), request lock ID (lock B), provider lock ID (lock C), shared application gateway ID (RB), shared publishing gateway ID (RC), and shared application bid (new bidding bid), making this message appear as if lock B is applying for lock C. The gateway RB uses a filtering strategy to ensure that this message is not sent back to the requesting lock B. The subsequent process is described in step 7. It should be noted that if the new price exceeds the maximum price limit of door lock B recorded locally after increasing the bidding increment, the gateway RB will stop bidding.

[0055] (2) If the gateway RB receives a final confirmation message for the sharing application (where the provider lock ID is lock C, the final confirmation requester lock ID is lock B, and the sharing application gateway ID is itself), it means that the application of lock B has been finally confirmed. Then the gateway RB removes the information of the sharing publishing gateway ID (RC) and sharing application gateway ID (RB) fields from the message, without changing the destination IP and source IP address, and forwards it to lock B (so that lock B thinks it is a confirmation of the application of lock C), notifying lock B of the application result so that it can proceed to the next step.

[0056] (3) If the gateway RB receives a final confirmation message for the sharing application (where the provider lock ID is lock C and the final confirmation requester lock ID is another lock) or a rejection message for the sharing application (where the provider lock ID is lock C, the rejection requester lock ID is lock B, and the sharing publishing gateway ID is itself), it means that lock B's application for a parking space from lock C was implicitly or explicitly rejected. In this case, the gateway RB will also remove the sharing publishing gateway ID (RC) and sharing application gateway ID (RB) fields from the message, without changing the destination IP and source IP address, and then forward it to lock B (so that lock B thinks it is an implicit or explicit rejection reply from lock C), and notify lock B of the application result so that it can proceed with the next step.

[0057] 9. Final processing of parking space sharing application (door lock B): Lock B receives and parses the final confirmation message or rejection message for the sharing application. If the sharing application is finally confirmed, it sends a success message to the owner's lock APP via the mobile internet to notify the owner. If the sharing application is implicitly or explicitly rejected, it deletes the lock C record in the local parking space sharing provider record table and checks if there are other sharing providers. If so, it re-multicasts and sends a new parking space sharing application message to trigger the subsequent steps 6-9.

[0058] 10. Further improvements to the assist forwarding process when the gateway is busy: Currently, shared publishing gateways are all directly connected to shared publishing locks, and shared request gateways are all directly connected to shared request locks. If the shared publishing gateway / shared request gateway needs to forward a large number of locks and the CPU utilization is high, it can request other idle gateways to assist in forwarding the processing. The specific process (taking the shared publishing gateway RC as an example, the shared request gateway is similar) is as follows: (1) When the gateway RC is processing parking space sharing, it will monitor its own CPU utilization in real time. When the gateway RC detects that its own CPU utilization has exceeded the set threshold (e.g., 80%) for a certain period of time (e.g., 30 seconds), it will add an "assistance request flag" to the message when it needs to send the final confirmation message of the sharing application via multicast the next time (ensuring that the current complete confirmation transaction has been completed).

[0059] (2) Other idle gateways (such as RD) listen for multicast messages containing the parking space sharing message flag. If they find a "help request flag" in the sharing request confirmation multicast message and determine that their CPU utilization is low (e.g., less than 40%), they can multicast and send a forwarding processing help request message. The message includes the destination IP (G), source IP (IP address of gateway RD), parking space sharing message flag, message type (forwarding processing help request), sharing publishing gateway ID (RC), and the target gateway ID (RD) of the help forwarding processing request. If other idle gateways hear this forwarding processing help request message, they will stop sending new help request messages for the same gateway RC to avoid duplicate requests.

[0060] (3) When the gateway RC receives the forwarding processing assistance request message, it can accept the request (if multiple idle gateways send requests, the gateway RC can select one according to the preset strategy (such as the earliest receiving time), that is, it multicasts the forwarding processing assistance request confirmation message, the content of which includes the destination IP (G), the source IP (IP address of the gateway RC), the parking space sharing message flag, the message type (forwarding processing assistance request confirmation), the sharing publishing gateway ID (RC), the assistance forwarding processing request confirmation gateway ID (RD), and the parking space sharing publishing confirmation record information stored locally; and synchronizes the IP address of the local record RD.

[0061] (4) After receiving the confirmation message of the forwarding processing assistance request, the gateway RD stores the parking space sharing publication confirmation record information of the gateway RC locally, realizes the assistance forwarding processing, and records the effective time of the assistance forwarding processing. The gateway RD enters the "formal assistance forwarding processing" state and becomes the main processing gateway for door lock C parking space sharing.

[0062] RD immediately begins responding to and processing the following two types of parking space sharing request multicast messages: Scenario 1: The user has not yet received the multicast message with the shared publishing gateway ID RD when applying for the door lock, and is unaware that the shared publishing gateway has changed to RD. Therefore, the shared publishing gateway ID in the application message sent is still RC. Scenario 2: The user has received a multicast message with the shared publishing gateway ID RD and knows that the shared publishing gateway has changed to RD. Therefore, the shared publishing gateway ID in the application message has been updated to RD.

[0063] For both types of request messages mentioned above, the RD sets the Shared Publishing Gateway ID field to its own ID (RD) in the response confirmation or rejection multicast message. The sharing provider, Lock C, is unaware of this assisted forwarding process.

[0064] (5) When the application door lock receives any multicast message related to parking space sharing (including publish, confirm, refuse, etc.), it will check the sharing publish gateway ID field in the message and update the record of the corresponding sharing provider on the local machine.

[0065] (6) After the gateway RC sends the forwarding processing assistance request confirmation message in step (3), and during the transition period before the gateway RD officially assists in forwarding processing in step (4), the gateway RC needs to locally cache the received parking space sharing application multicast messages for door lock C (because the RD has not yet taken over and will not process these application messages); after that, if the RC receives a sharing application confirmation or rejection multicast message, and detects that the provider door lock ID in the message is its own directly connected door lock ID and the sharing publishing gateway ID is RD (indicating that the gateway RD has started to assist in forwarding processing), it means that the assistance processing has taken effect, and then unicasts the cached multicast message content to the RD. After the assistance processing takes effect, the original gateway RC stops processing new application messages for door lock C and is only responsible for forwarding messages during the transition period. (Note: If the RC does not detect the above sharing application confirmation or rejection multicast message within the migration timeout threshold (e.g., 1 minute) (indicating that the assistance in forwarding processing has failed), then the RC resumes forwarding processing of multicast messages for door lock C, processes the cache queue itself, continues to work normally, and unicasts a notification to the RD).

[0066] (7) When the gateway RD receives the unicast message from the RC, it checks the timestamp in the message. If the timestamp of the message is later than the effective time of the assistance forwarding processing recorded locally, or if the requester's door lock ID in the message is already in the parking space sharing release confirmation record (hitting the confirmed sharing requester's door lock field), then the RD discards the forwarding message (because the application has been confirmed and does not need to be processed); otherwise, supplementary processing is required.

[0067] Beneficial effects: By utilizing the community's existing network equipment and smart door locks to build a fully distributed system, the entire process of parking space sharing is realized through multicast communication and intelligent gateway processing, eliminating the need to deploy dedicated servers and significantly reducing deployment and maintenance costs.

[0068] Innovation points: 1. Transparent forwarding processing and source IP masquerading mechanism. During the forwarding process, the gateway masquerades as a door lock to communicate. All response packets have the source IP address of the provider or requester door lock, so that the terminal door lock does not need to be aware of the complex gateway processing logic, simplifying the design complexity of the terminal device.

[0069] 2. Two-stage timed distributed bidding algorithm. A dual timer mechanism with initial and final confirmation is designed to achieve orderly bidding without a central coordinator. When a higher bid is received, the algorithm rolls back and resets, effectively extending the bidding window and ensuring the fairness and dynamism of the bidding process.

[0070] 3. Distributed gateway intelligent collaborative bidding mechanism. After detecting the initial confirmation messages of other door locks, the demand-side gateway automatically bids and increases the price on behalf of the door lock directly connected to its own gateway, without the need for the door lock terminal to participate. This achieves an intelligent experience of one-time configuration and automatic bidding; at the same time, filtering strategies prevent message loops, ensuring the automation and efficiency of the bidding process.

[0071] 4. Malicious Bidding Defense Mechanism. To address potential malicious low-price interference during distributed bidding, a temporary blacklist and counting / cleaning strategy are introduced. The gateway monitors continuous low-price bidding behavior from the same party in real time, automatically blocking subsequent applications from malicious bidders exceeding a threshold, preventing timers from being maliciously reset, and ensuring the fairness and termination of the normal bidding process.

[0072] 5. Dynamic Assisted Forwarding Processing. The gateway automatically triggers assistance requests based on CPU utilization, and achieves seamless migration of processing tasks through mechanisms such as multicast negotiation, data synchronization, and cache forwarding, ensuring system stability and response speed under high load.

[0073] Another embodiment of the present invention provides a door lock vehicle coordination system, see [link to relevant documentation]. Figure 3 The system may include: Establish module 301 for parking space sharing multicast group establishment: Based on the IGMP member report message sent by the owner's home door lock, all parking space sharing provider and demander door locks join the preset multicast group G, completing system initialization; The publishing module 302 is used for publishing and recording parking space sharing information: based on the multicast publishing message carrying the parking space sharing message tag sent by the provider's door lock, the provider's direct connection gateway identifies the parking space sharing message tag, adds the sharing publishing gateway ID field, and then continues to forward it. Other requesting door locks receive and store the sharing provider information locally. Application module 303 is used for parking space sharing application and bidding processing: Based on the multicast application message carrying the parking space sharing message tag sent by the demand side door lock, the demand side direct connection gateway identifies the parking space sharing message tag, adds the sharing application gateway ID field, and forwards it to the provider direct connection gateway. The provider direct connection gateway processes multiple applications for bidding according to the two-stage timed bidding algorithm. The confirmation module 304 is used for application confirmation and result feedback: Based on the bidding processing result of the provider's direct connection gateway, it generates a confirmation or rejection message carrying the source IP disguised as the provider's door lock address, forwards it via multicast, processes it through the demander's direct connection gateway, and then delivers it to the demander's door lock to complete the parking space sharing application process.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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 door lock and vehicle operation, characterized in that, The method includes: Parking space sharing multicast group establishment: Based on the IGMP member report message sent by the owner's home door lock, all parking space sharing provider and demander door locks join the preset multicast group G, completing system initialization; Parking space sharing information publishing and recording: Based on the multicast publishing message carrying the parking space sharing message tag sent by the provider's door lock, the provider's direct connection gateway identifies the parking space sharing message tag, adds the sharing publishing gateway ID field, and then continues to forward it. Other requesting door locks receive and store the sharing provider information locally. Parking space sharing application and bidding processing: Based on the multicast application message carrying the parking space sharing message tag sent by the demand side's door lock, the demand side's direct connection gateway identifies the parking space sharing message tag, adds the sharing application gateway ID field, and forwards it to the provider's direct connection gateway. The provider's direct connection gateway processes multiple applications for bidding according to a two-stage timed bidding algorithm. Application Confirmation and Result Feedback: Based on the bidding results of the provider's direct-connect gateway, a confirmation or rejection message carrying the source IP masquerading as the provider's door lock address is generated. After being forwarded via multicast and processed by the requester's direct-connect gateway, the message is delivered to the requester's door lock, completing the parking space sharing application process.

2. The method according to claim 1, characterized in that, The publication and recording of parking space sharing information includes: Message generation and transmission: Based on the sharing parameters configured on the door lock by the provider owner, the door lock generates and sends a multicast message containing the destination multicast IP, the source IP of the door lock address, the parking space sharing message tag, the message type of the parking space sharing, the provider door lock ID, and the lowest sharing unit price. Gateway listening and field addition: Based on the multicast message carrying the parking space sharing message tag sent by the directly connected door lock, which is detected by the provider's direct-connected gateway, add the sharing publishing gateway ID field to the message, without changing the source IP and destination IP, and continue to forward the multicast message; Local publishing record storage: Based on the provider's direct connection gateway, the parking space sharing publishing confirmation record is stored locally, including the provider's door lock ID, provider's door lock IP, minimum sharing unit price, and confirmed demander's door lock information. The confirmed demander's door lock information is initially empty. Demand-side information recording: Based on the publication message received by other door locks that have joined multicast group G, the sharing provider information is stored locally, including the provider door lock ID, the lowest sharing unit price, and the sharing publishing gateway ID.

3. The method according to claim 2, characterized in that, The processing of parking space sharing applications and bidding includes: Application message generation and transmission: Based on the parking space sharing application parameters set by the owner on the door lock, the door lock queries the parking space sharing provider information, and then generates and sends a multicast application message containing the destination multicast IP, the source IP of the owner's door lock address, the parking space sharing message tag, the message type of the parking space sharing application, the owner's door lock ID, the provider's door lock ID, the sharing publishing gateway ID, the sharing application price, the bidding range and the maximum price limit; Add the following to the demand-side gateway field: Based on the multicast message carrying the parking space sharing message tag sent by the directly connected door lock detected by the demand-side direct-connected gateway, add the sharing request gateway ID field to the message, without changing the source IP and destination IP, and continue to forward the multicast message. Provider Gateway Reception and Caching: Upon receiving the application message from the provider's directly connected gateway, the provider's lock ID and shared publishing gateway ID are parsed out. It is confirmed that the application is for a lock directly connected to this gateway. The local publishing confirmation record is queried. If there is no confirmed request from the corresponding provider lock, the application information is cached and the initial confirmation timer for this application from the provider lock is started. If there is a confirmed request, a rejection message is sent. Two-phase bidding process: Based on whether the provider gateway receives other request messages for the same provider lock during the initial confirmation timer period, the following processing is performed: If the initial confirmation timer expires and there are no new requests, an initial confirmation multicast message with the provider lock's IP address as the source IP is sent to impersonate the provider lock, declaring the initial confirmation request lock as the original requester and announcing its initial confirmation request price. Then, the final confirmation timer associated with that requester lock for this request to the provider lock is started. If a new request is received during the initial confirmation timer period, and if the new request price is higher than the current winning price, the new requester wins. If the prices are the same, the winner is determined by the order in which the messages arrive at the provider's directly connected gateway; the first message arrives wins. After determining the winner, the current initial confirmation timer is canceled, and a new multicast is performed. An initial acknowledgment message with the source IP of the provider's lock is sent to impersonate the provider's lock and declare the initial acknowledgment request lock as the winning lock, announcing its initial acknowledgment request price. Then, the initial acknowledgment timer associated with the winning lock is started. If the final acknowledgment timer expires and there are no new requests, the request is confirmed as successful. Then, a final acknowledgment multicast message with the source IP of the provider's lock is sent, and the information of the confirmed request lock is recorded. If a new request is received during the final acknowledgment timer, the winner is determined according to the price and the order of message arrival. The current final acknowledgment timer is then canceled, and an initial acknowledgment message with the source IP of the provider's lock is re-multicasted to declare the initial acknowledgment request lock as the winning lock, announcing its initial acknowledgment request price. Then, the initial acknowledgment timer associated with the winning lock is started. Blacklist filtering mechanism: During the two-stage bidding process, a temporary blacklist is maintained by the provider's gateway. If the number of consecutive bids from the same demander for a door lock that are not higher than the current winner's bid exceeds a preset threshold, the door lock from that demander will be added to the temporary blacklist, and its subsequent application messages in the current bidding round will be ignored. If the subsequent bids from that demander for a door lock are higher than the current winner's bid and it is not included in the temporary blacklist, its consecutive low price count will be cleared. The bidding round ends when the provider's direct-connected gateway sends the final confirmation message for the sharing application, and the temporary blacklist will be automatically cleared after the bidding ends.

4. The method according to claim 3, characterized in that, The application confirmation and result feedback include: Confirmation / Rejection Message Generation and Disguised Transmission: Based on the two-stage bidding process of the provider's direct-connect gateway, an initial / final confirmation or rejection message carrying a parking space sharing message tag is generated. The message content includes the destination multicast IP, the source IP disguised as the provider's door lock address, the message type, the provider's door lock ID, the demander's door lock ID for initial / final confirmation or rejection, the initial / final confirmation application price, the shared publishing gateway ID, and the shared requesting gateway ID, and is sent via multicast. Demand-side gateway reception and intelligent processing: Based on the confirmation or rejection message received by the demand-side direct-connected gateway, the following processing is performed: If an initial confirmation message is received and the initial confirmation demand-side is another door lock, the local application record is queried. If the door lock directly connected to this gateway is also applying to the same provider, a bidding increment is added to the initial confirmation price. It is then determined whether the new price exceeds the maximum price limit of the demand-side door lock recorded locally. If it does not exceed the limit, a new application message is regenerated for bidding, and the source IP address of the regenerated application message is set to the IP address of the demand-side door lock. Then, filtering strategies are used to prevent packets from being sent back to the directly connected door locks of this gateway. If a final confirmation packet is received and the final confirmation requester is a directly connected door lock of this gateway, the shared publishing gateway ID and shared requesting gateway ID fields in the packet are removed, the source IP address remains unchanged, and the packet is forwarded to the directly connected door lock. If a final confirmation packet is received and the final confirmation requester is another door lock, or if a rejection packet is received and the rejection requester is a directly connected door lock of this gateway, the shared publishing gateway ID and shared requesting gateway ID fields in the packet are also removed, the source IP address remains unchanged, and the packet is forwarded to the directly connected door lock. Final processing by the requester's door lock: Based on the final confirmation or rejection message received by the requester's door lock, if it is a final confirmation, the owner will be notified of the successful application through the door lock APP; if it is a rejection, the corresponding local sharing provider record will be deleted, and it will be checked whether there are other sharing providers. If so, the application will be resubmitted.

5. The method according to claim 4, characterized in that, The application confirmation and result feedback also include: Source IP masquerading configuration: When the provider's direct-connected gateway generates an acknowledgment or rejection message, the source IP address of the message is set to the IP address of the provider's lock, rather than the gateway's own IP address; when the demand-side gateway regenerates an application message to increase the bid increment, the source IP address of the message is set to the IP address of the demand-side lock, rather than the gateway's own IP address. Transparent forwarding processing: When the requesting direct-connected gateway forwards the confirmation or rejection message to the direct-connected door lock, it only removes the shared publishing gateway ID and shared requesting gateway ID fields, keeping the source IP address unchanged; Door lock seamless reception: Based on the message received by the requesting door lock, the source IP is parsed to be the address of the providing door lock. It is considered to be a direct reply from the providing door lock, so that the receiving door lock thinks that it is communicating directly with the other door lock, without needing to be aware of the intermediate processing logic of the gateway.

6. The method according to claim 5, characterized in that, The method also includes dynamic assisted forwarding processing when the gateway is under high load: Assistance request trigger: When the provider's direct-connect gateway detects that the CPU utilization rate continues to exceed the set threshold, an assistance request flag will be added to the next final confirmation message for the sharing request. Idle Gateway Response: If other idle gateways detect a message carrying an assistance request flag and its own CPU utilization is below a set threshold, it multicasts and forwards the assistance request message, which includes the target gateway ID. Assistance confirmation and data synchronization: Based on the assistance request message received from the original provider's direct connection gateway, select one of the idle gateways, multicast an assistance request confirmation message, which includes the locally saved parking space sharing publication confirmation record information, and locally record the IP address of the assisting gateway; Assisting gateway takeover processing: After receiving the confirmation message, the assisting gateway stores the original gateway's publishing record information, records the effective time of the assistance, and starts to respond to the application message for the provider's door lock as the main processing gateway. In all relevant response messages sent by the provider, the shared publishing gateway ID is set as the identifier of this gateway, so that the receiving door lock updates its locally recorded shared publishing gateway information. Transitional message caching and forwarding: After the original provider's direct-connect gateway sends an assistance confirmation message and before the assistance takes effect, it locally caches new application messages for the provider's door lock; when it detects a response message from the assisting gateway with the provider's door lock ID as its own direct-connect door lock, it unicasts and forwards the cached message to the assisting gateway. Assisting gateway supplementary processing: Based on the cached message forwarded by the original gateway received by the assisting gateway, check the message timestamp and the demander lock ID in the message. If the demander lock ID in the message has been marked as a confirmed demander in the parking space sharing release confirmation record, or if the message timestamp is later than the assistance effective time recorded locally by the assisting gateway, then discard the forwarded message; otherwise, perform supplementary processing. Recovery from assistance failure: If the original provider's direct-connect gateway does not detect a response message from the assisting gateway within the set timeout threshold, the assistance is deemed to have failed. The forwarding of the lock message for that provider is resumed, and the provider handles the queue of request messages for that provider's lock that were cached during the transition period. At the same time, the assisting gateway is notified by unicast.

7. A system for coordinated door lock and vehicle operation, characterized in that, The system includes: The module is used to establish a parking space sharing multicast group: based on the IGMP member report message sent by the owner's home door lock, all parking space sharing provider and demander door locks join the preset multicast group G, completing the system initialization; The publishing module is used for publishing and recording parking space sharing information: based on the multicast publishing message carrying the parking space sharing message tag sent by the provider's door lock, the provider's direct connection gateway identifies the parking space sharing message tag, adds the sharing publishing gateway ID field, and then continues to forward it. Other requesting door locks receive and store the sharing provider information locally. The application module is used for parking space sharing application and bidding processing: Based on the multicast application message carrying the parking space sharing message tag sent by the demand side door lock, the demand side direct connection gateway identifies the parking space sharing message tag, adds the sharing application gateway ID field, and forwards it to the provider direct connection gateway. The provider direct connection gateway processes multiple applications for bidding according to the two-stage timed bidding algorithm. The confirmation module is used for application confirmation and result feedback: Based on the bidding results of the provider's direct connection gateway, it generates a confirmation or rejection message carrying the source IP disguised as the provider's door lock address. After being forwarded via multicast and processed by the demander's direct connection gateway, the message is delivered to the demander's door lock to complete the parking space sharing application process.

8. The system according to claim 7, characterized in that, The publishing module is specifically used for: Message generation and transmission: Based on the sharing parameters configured on the door lock by the provider owner, the door lock generates and sends a multicast message containing the destination multicast IP, the source IP of the door lock address, the parking space sharing message tag, the message type of the parking space sharing, the provider door lock ID, and the lowest sharing unit price. Gateway listening and field addition: Based on the multicast message carrying the parking space sharing message tag sent by the directly connected door lock, which is detected by the provider's direct-connected gateway, add the sharing publishing gateway ID field to the message, without changing the source IP and destination IP, and continue to forward the multicast message; Local publishing record storage: Based on the provider's direct connection gateway, the parking space sharing publishing confirmation record is stored locally, including the provider's door lock ID, provider's door lock IP, minimum sharing unit price, and confirmed demander's door lock information. The confirmed demander's door lock information is initially empty. Demand-side information recording: Based on the publication message received by other door locks that have joined multicast group G, the sharing provider information is stored locally, including the provider door lock ID, the lowest sharing unit price, and the sharing publishing gateway ID.

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-6 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-6.

Images