A method and system for parking space sharing based on door lock

Abstract

This invention discloses a method and system for parking space sharing based on door locks. The method includes: based on parking space sharing information set on a first door lock by the parking space provider, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a service agent; based on the parking space demand and bidding strategy input on a second door lock by the parking space demander, its gateway router is triggered to record the information, become a service agent, establish a precise forwarding path, and the agent multicasts and sends a parking space sharing application message; based on multiple application or bidding messages received by the provider's gateway router, the bidding leader, the bidding loser, and the latest bid status are synchronized in real time; based on a preset bidding stabilization period, the provider's gateway router confirms the final winner, completing the distributed locking of parking space resources. Using this invention, the processing efficiency, system reliability, and overall security of the parking space sharing service can be improved.

Description

Technical Field

[0001] This invention belongs to the field of smart door lock technology, and in particular to a method and system for parking space sharing based on door locks. Background Technology

[0002] With the increasing imbalance between urban parking supply and demand, parking space sharing based on the sharing economy has become an effective way to alleviate the "parking difficulty." Existing parking space sharing solutions mostly rely on centralized cloud platforms for information dissemination, transaction matching, and resource allocation. This architecture has significant shortcomings: First, the central server acts as a single point of failure and performance bottleneck; any failure or network congestion will lead to system service interruption or response delays, making reliability and real-time performance difficult to guarantee. Second, the centralized storage and processing of all transaction data and user privacy information makes it vulnerable to large-scale data leaks and cyberattacks, posing significant security risks. Third, the centralized bidding and locking process involves many steps and is time-consuming, failing to meet users' urgent need for immediate and efficient parking space locking, especially during peak hours. Therefore, how to achieve a decentralized, fast-response, and highly reliable parking space sharing method while ensuring security and efficiency has become a pressing technical problem to be solved in this field. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for parking space sharing based on door locks, so as to overcome the shortcomings of the prior art and improve the processing efficiency, system reliability and overall security of parking space sharing services.

[0004] One embodiment of this application provides a method for parking space sharing based on door locks, the method comprising: Shared information publishing and path establishment: Based on the parking space sharing information set by the parking space provider owner on the first door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a service agent, and establishes a precise multicast forwarding path for the door lock in the network through the extended multicast routing protocol; Shared application submission and path establishment: Based on the parking space demand and bidding strategy entered by the parking space owner on the second door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a business proxy, establish a precise forwarding path, and then the proxy multicasts and sends the parking space sharing application message. Distributed bidding processing and status synchronization: Based on multiple application or bidding messages received by the provider's gateway router, the gateway router performs demand matching, price comparison and status determination, and synchronizes the bidding leader, bidding loser and the latest bid status in real time by forwarding the messages via targeted multicast. Confirmation of bidding results and locking of resources: Based on the preset bidding stabilization period, the provider gateway router confirms the final winner and multicasts the successful bidding result to relevant parties. At the same time, it triggers other publisher gateways in the network to clean up invalid bidding information, thus completing the distributed locking of parking space resources.

[0005] Optionally, the shared information publishing and path establishment includes: Shared information settings: Based on the owner's operation on the first door lock, set the identifier of the parking space to be shared, the sharing time period, and the minimum sharing price information; Agent Joining and Local Binding: Based on the shared information, the first door lock sends an extended IGMP join message to its directly connected gateway router. The message includes the message type, door lock identifier, and the shared information. After receiving the message, the gateway router binds the parking space provider identifier, the first door lock identifier, and the shared information to the outgoing interface corresponding to its multicast forwarding table entry, thus becoming the service agent of the door lock. Precise forwarding path establishment: Based on the extended PIM join message carrying the first door lock identifier sent upstream by the gateway router, each router in the community network adds the receiving interface to the outgoing interface list in its multicast routing table entry and binds the first door lock identifier as a forwarding filtering condition, thereby establishing a precise multicast forwarding path for messages sent to the door lock identifier.

[0006] Optionally, the sharing request submission and path establishment include: Demand and Strategy Input: Based on the actions of the parking space owner on the second door lock, input the demand period, initial price, bidding range, and maximum bid strategy; Agent Joining and Local Binding: According to the requirements and policies, the second door lock sends an extended IGMP join message to its directly connected gateway router. The message includes the message type, door lock identifier, and the requirements and policies information. After receiving the message, the gateway router binds the parking space demander tag, the second door lock identifier, and the requirements and policies information to the outgoing interface corresponding to its multicast forwarding table entry, thus becoming the service agent of the door lock. Precise forwarding path establishment: Based on the extended PIM join message carrying the second door lock identifier sent upstream by the gateway router, a precise multicast forwarding path for the door lock identifier is established in the network; Application message multicast: Based on the gateway router acting as a proxy, a parking space sharing application data message is sent via multicast. The message includes the lock identifier of the requesting party, the time period of the request, and the initial price. The target lock identifier field is empty, so as to trigger the flooding and forwarding of the message within the multicast group in the network.

[0007] Optionally, the distributed bidding process and state synchronization include: Initial application ruling: Based on the first parking space sharing application message sent by the demander's agent received by the provider's gateway router, the demand time period and the sharing time period are matched locally, and the application price is compared with the lowest sharing price; If the requested bid is not lower than the lowest price, the local interface will add the lock identifier and its bid as the current successful bid information and cache the application message. Then, a bid acceptance message will be sent to the lock's multicast channel, which will be delivered to the lock's proxy gateway. If the requested bid is lower than the lowest price, a bid rejection message will be sent to the lock's multicast channel. The rejection message includes the current lowest price as a reference, and the message will also be delivered to the lock's proxy gateway. Competitive bid adjudication: Based on the application or bidding messages received by the provider's gateway router from other demanders' agents, and provided that the lowest price is met, the provider's bid is compared with the currently registered successful bids. If the new bid is higher, the local successful bid information is updated to reflect the new bidder. Previously cached old messages are deleted, and the message corresponding to the new bidder is cached. Simultaneously, the message is modified to specify the original leading lock as the target and set the publishing lock identifier before multicasting. This modified message is sent to the original leading lock's proxy gateway to notify it of the higher bid and a temporary bid acceptance message is sent to the new bidding lock's proxy gateway. Similarly, this message is also sent to the new bidding lock's proxy gateway. If the new bid is not higher than the current successful bid, a bid rejection message is sent to the new bidding lock, containing the current successful bid. Automatic bidding decision for the losing party: Based on the rejection notification or higher price notification received by the gateway router of the party that temporarily loses the bid, a decision is made in combination with the locally recorded bid range for the door lock and the highest bid strategy; If the decision is made to continue bidding and the bid does not exceed the maximum price limit, a multicast message will be sent targeting the provider's door lock, carrying the new offer. If the decision is to abandon the bidding, the process can proceed to other shared parking space application processes.

[0008] Optionally, the confirmation of bidding results and resource locking includes: Final winner confirmation: Based on the timer started by the provider's gateway router when the successful bidding information is first generated or updated, if the information is not updated again within the preset time period, the demand party in the information is confirmed as the final winner; Notification to resource providers and winners: Based on the final confirmation result, the provider's gateway router will supplement the cached winning bid or application message with specific shared parking space identification information and forward it to the provider's door lock for notification; at the same time, it will multicast a parking space sharing bidding formal acceptance message with an empty target door lock identifier to trigger the message flooding forwarding within the multicast group in the network; after receiving the message, the winning gateway will further forward it to the winning door lock for notification; Distributed resource locking and cleanup: Upon receiving the formal acceptance message of the bidding from the gateway router of other parking space publishers, the winning gate lock identifier is extracted and the local bidding information is checked to see if the identifier is included. If it is included, it is deleted, thereby automatically releasing the winning party's bidding lock on other shared parking space resources.

[0009] Optionally, the method also includes a business completion process after the bidding ends: Transaction details transmission: The cached message forwarded by the provider's gateway router to the provider's door lock contains the complete application information of the winning party, so that the provider's owners can know the transaction details; Application layer notification: The provider lock and the successful lock will notify their respective owners of the successful parking space sharing through their associated lock management applications to complete the subsequent offline handover.

[0010] Another embodiment of this application provides a parking space sharing system based on door locks, the system comprising: The publishing module is used for sharing information publishing and path establishment: Based on the parking space sharing information set by the parking space provider owner on the first door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a service agent, and establishes a precise multicast forwarding path for the door lock in the network through the extended multicast routing protocol; The submission module is used for submitting sharing applications and establishing paths: based on the parking space demand and bidding strategy entered by the parking space demander on the second door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a business proxy, establish a precise forwarding path, and then the proxy multicasts and sends the parking space sharing application message. The processing module is used for distributed bidding processing and status synchronization: based on multiple application or bidding messages received by the provider gateway router, it performs demand matching, price comparison and status determination by proxy, and synchronizes the bidding leader, bidding loser and latest bid status in real time by forwarding the messages via targeted multicast. The confirmation module is used for confirming the bidding results and locking resources: based on the preset bidding stabilization period, the provider gateway router confirms the final winner and multicasts the successful bidding result to relevant parties. At the same time, it triggers other publisher gateways in the network to clean up invalid bidding information, thus completing the distributed locking of parking space resources.

[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 present invention provides a parking space sharing method based on door locks, which can improve the processing efficiency, system reliability and overall security of parking space sharing services. Attached Figure Description

[0014] Figure 1 Hardware structure block diagram of a computer terminal for a parking space sharing method based on door locks provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a method for sharing parking spaces based on door locks, provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a parking space sharing system based on door locks, provided as 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. If other residents have visitors who need parking, and demand exceeds supply (i.e., shared parking spaces are scarce), they can bid in advance to secure temporary parking rights for those spaces.

[0017] This invention first provides a method for parking space sharing based on door locks. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0018] The following detailed explanation uses a computer terminal as an example. Figure 1This is a hardware structure block diagram of a computer terminal for a parking space sharing method based on door locks, 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.

[0019] See Figure 2 The present invention provides a method for parking space sharing based on door locks, which may include the following steps: S201, Shared Information Publication and Path Establishment: Based on the parking space sharing information set by the parking space provider owner on the first door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a service proxy, and establishes a precise multicast forwarding path for the door lock in the network through the extended multicast routing protocol; specifically, the shared information publication and path establishment includes: Shared information settings: Based on the owner's operation on the first door lock, set the identifier of the parking space to be shared, the sharing time period, and the minimum sharing price information; Agent Joining and Local Binding: Based on the shared information, the first door lock sends an extended IGMP join message to its directly connected gateway router. The message includes the message type, door lock identifier, and the shared information. After receiving the message, the gateway router binds the parking space provider identifier, the first door lock identifier, and the shared information to the outgoing interface corresponding to its multicast forwarding table entry, thus becoming the service agent of the door lock. Precise forwarding path establishment: Based on the extended PIM join message carrying the first door lock identifier sent upstream by the gateway router, each router in the community network adds the receiving interface to the outgoing interface list in its multicast routing table entry and binds the first door lock identifier as a forwarding filtering condition, thereby establishing a precise multicast forwarding path for messages sent to the door lock identifier.

[0020] S202, Shared Request Submission and Path Establishment: Based on the parking space demand and bidding strategy entered by the parking space owner on the second door lock, the door lock sends an extended multicast join message, triggering its gateway router to record this information and become a service proxy, establishing a precise forwarding path, and the proxy multicasts and sends a parking space sharing request message; specifically, the shared request submission and path establishment includes: Demand and Strategy Input: Based on the actions of the parking space owner on the second door lock, input the demand period, initial price, bidding range, and maximum bid strategy; Agent Joining and Local Binding: According to the requirements and policies, the second door lock sends an extended IGMP join message to its directly connected gateway router. The message includes the message type, door lock identifier, and the requirements and policies information. After receiving the message, the gateway router binds the parking space demander tag, the second door lock identifier, and the requirements and policies information to the outgoing interface corresponding to its multicast forwarding table entry, thus becoming the service agent of the door lock. Precise forwarding path establishment: Based on the extended PIM join message carrying the second door lock identifier sent upstream by the gateway router, a precise multicast forwarding path for the door lock identifier is established in the network; Application message multicast: Based on the gateway router acting as a proxy, a parking space sharing application data message is sent via multicast. The message includes the lock identifier of the requesting party, the time period of the request, and the initial price. The target lock identifier field is empty, so as to trigger the flooding and forwarding of the message within the multicast group in the network.

[0021] S203, Distributed Bidding Processing and State Synchronization: Based on multiple application or bidding messages received by the provider's gateway router, its proxy performs demand matching, price comparison, and state determination, and synchronizes the bidding leader, bidding losers, and latest bid status in real time through targeted multicast forwarding of the messages; specifically, the distributed bidding processing and state synchronization includes: Initial application ruling: Based on the first parking space sharing application message sent by the demander's agent received by the provider's gateway router, the demand time period and the sharing time period are matched locally, and the application price is compared with the lowest sharing price; If the requested bid is not lower than the lowest price, the local interface will add the lock identifier and its bid as the current successful bid information and cache the application message. Then, a bid acceptance message will be sent to the lock's multicast channel, which will be delivered to the lock's proxy gateway. If the requested bid is lower than the lowest price, a bid rejection message will be sent to the lock's multicast channel. The rejection message includes the current lowest price as a reference, and the message will also be delivered to the lock's proxy gateway. Competitive bid adjudication: Based on the application or bidding messages received by the provider's gateway router from other demanders' agents, and provided that the lowest price is met, the provider's bid is compared with the currently registered successful bids. If the new bid is higher, the local successful bid information is updated to reflect the new bidder. Previously cached old messages are deleted, and the message corresponding to the new bidder is cached. Simultaneously, the message is modified to specify the original leading lock as the target and set the publishing lock identifier before multicasting. This modified message is sent to the original leading lock's proxy gateway to notify it of the higher bid and a temporary bid acceptance message is sent to the new bidding lock's proxy gateway. Similarly, this message is also sent to the new bidding lock's proxy gateway. If the new bid is not higher than the current successful bid, a bid rejection message is sent to the new bidding lock, containing the current successful bid. Automatic bidding decision for the losing party: Based on the rejection notification or higher price notification received by the gateway router of the party that temporarily loses the bid, a decision is made in combination with the locally recorded bid range for the door lock and the highest bid strategy; If the decision is made to continue bidding and the bid does not exceed the maximum price limit, a multicast message will be sent targeting the provider's door lock, carrying the new offer. If the decision is to abandon the bidding, the process can proceed to other shared parking space application processes.

[0022] S204, Bidding Result Confirmation and Resource Locking: Based on a preset bidding stabilization period, the provider's gateway router confirms the final winner and multicasts the successful bidding result to relevant parties. Simultaneously, it triggers other publisher gateways in the network to clear invalid bidding information, completing the distributed locking of parking space resources. Specifically, the bidding result confirmation and resource locking includes: Final winner confirmation: Based on the timer started by the provider's gateway router when the successful bidding information is first generated or updated, if the information is not updated again within the preset time period, the demand party in the information is confirmed as the final winner; Notification to resource providers and winners: Based on the final confirmation result, the provider's gateway router will supplement the cached winning bid or application message with specific shared parking space identification information and forward it to the provider's door lock for notification; at the same time, it will multicast a parking space sharing bidding formal acceptance message with an empty target door lock identifier to trigger the message flooding forwarding within the multicast group in the network; after receiving the message, the winning gateway will further forward it to the winning door lock for notification; Distributed resource locking and cleanup: Upon receiving the formal acceptance message of the bidding from the gateway router of other parking space publishers, the winning gate lock identifier is extracted and the local bidding information is checked to see if the identifier is included. If it is included, it is deleted, thereby automatically releasing the winning party's bidding lock on other shared parking space resources.

[0023] Furthermore, the method also includes a business completion process after the bidding ends: Transaction details transmission: The cached message forwarded by the provider's gateway router to the provider's door lock contains the complete application information of the winning party, so that the provider's owners can know the transaction details; Application layer notification: The provider lock and the successful lock will notify their respective owners of the successful parking space sharing through their associated lock management applications to complete the subsequent offline handover.

[0024] This invention enables a bidding function for single parking space sharing requests when the demand for shared parking spaces in a residential community exceeds the supply (i.e., there are few shared parking spaces), by utilizing the community's existing property management system, community network routers, and homeowner door locks in coordination, without relying on a central server.

[0025] (I) Core Idea: Prerequisites: 1. Each resident's door lock is connected to the community network through their respective floor gateway router.

[0026] 2. The community property management system pre-configures residents' parking space information (parking space ID). Residents then associate their parking space information (parking space ID) with their door locks.

[0027] Core process: 1. Parking space sharing announcement (Door lock C): After a parking space provider sets a sharing time period and minimum price on their own door lock (e.g., door lock C), the owner publishes the information. Door lock C sends an enhanced IGMP join message to its gateway router (gateway RC) to join multicast group G. This message extension includes the message type (parking space sharing announcement), door lock ID, parking space ID, sharing time period, and minimum sharing price. Gateway RC records this information and becomes a service agent for door lock C. Subsequently, it sends an extended PIM Join message (carrying door lock C ID) to the upstream router. Upon receiving this message, each router in the community adds the interface receiving this message to its outgoing interface list in its multicast routing table entry (*, G) and binds door lock C as a forwarding filter condition, thereby establishing a routing path that accurately forwards only messages destined for door lock C to gateway RC.

[0028] 2. Parking space sharing application (door lock A): Parking space requesters enter their desired time period, initial bid, bid increment, and maximum bid on their door lock (e.g., door lock A). Door lock A sends an enhanced IGMP join message to its gateway router (gateway RA) to join multicast group G. The message extension includes the message type (parking space sharing application), door lock ID, expected time period, initial bid, bid increment, and maximum bid. Gateway RA records this information and becomes a proxy, establishing a precise forwarding path for door lock A in the network through an extended PIM Join message (carrying door lock A's ID). Subsequently, gateway RA, acting as a proxy, multicasts the parking space sharing application data packet, which does not yet specify the target door lock ID.

[0029] 3. Initial application processing for parking space sharing (Gateway RC): After receiving the request message from step 2, the provider gateway (RC) searches for the interface marked with "parking space provider tag" in its local (*, G) table and matches it with the required time period. Next, it compares the bid price in the request message with the lowest shared price registered for that interface. (1) If the bid is greater than or equal to the lowest price: The gateway RC adds the bidding information to the interface, including the bidding door lock ID (door lock A) and its bid, and temporarily caches the application message. Subsequently, the gateway RC multicasts a "parking space sharing bidding temporarily accepted" message, which is accurately forwarded to the demand door lock RA by means of the filtering path established in the network.

[0030] (2) If the bid is less than the lowest price: the gateway RC multicasts a “parking space sharing bidding rejection” message, which includes the reason for rejection and the current successful bid (i.e. the lowest price), and forwards it accurately to the demander door lock RA.

[0031] 4. Parking space sharing application (door lock B): Another homeowner with the same needs initiates an application through door lock B, following the same process as step 2. Door lock B joins multicast group G through its gateway RB, sends extended IGMP messages, establishes a precise forwarding path, and the gateway RB proxies the multicast transmission of the parking space sharing application message.

[0032] 5. Parking space sharing bidding processing (gateway RC): After receiving the application message from lock B, the provider gateway (RC) performs a matching process. If a bidding record for lock A is found, and provided lock B's bid is not less than the minimum shared price, the RC then compares lock B's bid with the currently successful bid (lock A's bid): (1) If B's ​​bid is higher: The gateway RC updates the local bidding information to lock B and its higher bid, and deletes the previously cached old messages, only caching lock B's application message. Subsequently, the gateway RC directly modifies lock B's application message, adding the fields "Target Lock ID (Lock A)" and "Publisher Lock ID (Lock C)" to it, and then multicasts this modified message to notify lock A that there is a higher bid. At the same time, a "Bidding temporarily accepted" message is sent to lock B.

[0033] (2) If B’s bid is less than or equal to the current successful bid: the gateway RC sends a “bid rejection” message to lock B, which includes the current successful bid (lock A’s bid).

[0034] 6. Handling of temporary bidding failure for door lock proxy gateway: For door lock buyers (such as RA or RB) who receive a rejection notice or a higher price notice, the agent makes a decision based on the local record of door lock bidding ranges and the highest bid: (1) If you choose to continue bidding: add a bidding increment based on the known highest bid. If the bid does not exceed the maximum price limit of this lock, send a multicast message “Parking space sharing bidding”. This message specifies the target lock ID as the provider lock C and carries the new bid.

[0035] (2) If you choose to give up bidding: you can apply for other shared parking spaces.

[0036] 7. Continuous processing of parking space sharing bidding (gateway RC): After receiving a new bidding message, the provider gateway RC repeats the logic of step 5, compares the new bid with the currently registered successful bids locally, updates the bidding information accordingly, replaces the cached message, and notifies relevant parties (by modifying the message to notify the failed party and sending a "temporarily accept" message to notify the new leading party).

[0037] 8. Continuous bidding: Subsequently, the handling of temporarily failed bidding for door lock agent gateways should refer to step 6, and the handling of continuous bidding for gateway RC parking space sharing should refer to step 7.

[0038] 9. Successful processing of parking space sharing bidding (gateway RC): Once the local bidding information has been stable for more than the preset timer duration (e.g., 15 minutes), the provider gateway RC confirms the final winner of the door lock and performs the following operations: (1) Notify the provider, Lock C: For the previously cached original application or bidding message of the winner, add the specific shared parking space ID information and then formally forward it to Lock C.

[0039] (2) Multicast notification of successful bidding: The multicast sends a "Parking space sharing bid officially accepted" message. The target lock ID of this message is empty (sent to all multicast group members). The message contains the ID of the successfully bid lock, the successful bid, the ID of the parking space provider lock, and the ID of the shared parking space. The winning gateway receives the message and notifies its lock.

[0040] (3) Clear other publishers' caches: After receiving this broadcast message, the gateways of other parking space providers in the network will clear the bidding information about the door lock in their local records based on the successful bidding door lock ID in the message.

[0041] (II) Complete technical implementation process: Prerequisites: Same as before. The complete process includes: 1. Parking space sharing announcement (Door lock C): Owners who are parking space sharing providers can publish their parking spaces for sharing on their own door locks (e.g., door lock C). For example, after pressing a specific button on the door lock, the owner can activate the parking space sharing publishing mode and set the sharing time period (e.g., 09:00-17:00) and the minimum sharing price (e.g., 5 yuan / hour).

[0042] Door lock C first sends an enhanced IGMP join message to its gateway router (such as gateway RC) to join multicast group G. The extension is that the message contains an extended message type (parking space sharing announcement), door lock ID (door lock C), parking space ID (such as parking space c1), sharing time period, and minimum sharing price.

[0043] Upon receiving the message, the gateway RC records the correspondence between the interface and multicast group G in its IGMP interface group table and generates a (*, G) multicast routing table entry. The entry binds the following information to the interface that received the message: parking space provider identifier, door lock ID (door lock C), parking space ID (e.g., parking space c1, multiple entries can be published, each a separate record), sharing time period, and minimum sharing price information. The gateway RC becomes the publisher agent for the parking space sharing service of door lock C, listening for and proxying subsequent multicast messages related to the service, thereby reducing operational requirements on door lock C and saving its power.

[0044] The gateway RC then sends an extended PIM Join message to the upstream router, carrying the lock ID (lock C). Upon receiving the message, the upstream router adds the interface receiving the message to its multicast routing table entry (*, G) and binds lock C as a forwarding filter condition. This mechanism propagates hop-by-hop among the routers in the cell. That is, after each router receives the extended PIM Join message from the downstream router, it adds the interface receiving the message to its multicast routing table entry (*, G) and binds lock C as a forwarding filter condition; simultaneously, it sends an extended PIM Join message to its upstream router, carrying the lock ID (lock C). The purpose of this design is that subsequent routers receiving multicast messages destined for multicast group G, with the target lock ID specified as lock C, will accurately forward them to the directly connected gateway RC of lock C (the actual target is lock C, but the gateway RC, acting as its proxy, will perform proxy operations upon receiving the message, and the same applies below).

[0045] 2. Parking space sharing application (door lock A): Owners who need parking space sharing can apply for it through their own door locks (e.g., door lock A). For example, after pressing a specific button on the door lock, the owner can activate the parking space sharing application mode and enter the expected time period (e.g., 10:00-12:00), initial bid (e.g., 4 yuan / hour, 5 yuan / hour, etc.), bid increment (e.g., 0.5 yuan / hour), and maximum bid (e.g., 10 yuan / hour).

[0046] Similar to step 1, door lock A sends an enhanced IGMP join message to its gateway router (such as gateway RA) to join multicast group G. The extension is that the message includes an extended message type (parking space sharing application), door lock ID (door lock A), expected demand time period, initial bid price, bid increment, and maximum bid price.

[0047] Upon receiving the message, gateway RA records the correspondence between the interface and multicast group G in its IGMP interface group table and generates a (*, G) multicast routing table entry. The entry binds the following information to the interface that received the message: parking space demander identifier, door lock ID (door lock A), initial bid price, bid increment, and maximum bid price. Gateway RA becomes the demander agent for door lock A's parking space sharing service, listening for and proxying subsequent multicast messages related to the service, thereby reducing operational requirements on door lock A and saving its power.

[0048] Gateway RA then sends an extended PIM Join message to the upstream router, carrying the lock ID (lock A). Upon receiving the message, the upstream router adds the interface receiving this message to its multicast routing table entry (*, G) in its outgoing interface list and binds lock A as a forwarding filter condition. This mechanism propagates hop-by-hop among the routers in the cell. Subsequent routers receiving multicast messages destined for multicast group G, with the target lock ID specified as lock A, will precisely forward them to the directly connected gateway RA of lock A.

[0049] As the demand agent for door lock A, gateway RA then multicasts a parking space sharing application multicast data packet. The packet contains the multicast group address G, message type (parking space sharing application), target door lock ID (set to empty in this case because it is unknown which door lock has published the parking space sharing application), demand door lock ID (door lock A), expected demand time period, and bid price (this is the initial bid price).

[0050] 3. Initial application processing for parking space sharing (Gateway RC): After the multicast data packet representing the parking space sharing request from lock A is forwarded by each router according to the multicast routing table entries (since the target lock ID is not specified this time, each router forwards it to all outgoing interfaces in (*, G) without filtering), the gateway RC directly connected to lock C receives the multicast data, identifies it as a parking space sharing request, and then searches for entries with a parking space provider tag on the outgoing interface in its local (*, G) multicast routing table. It then matches this data with the expected demand time period information in the multicast data and finds that the sharing time period for parking space c1 of lock C meets the requirements. Next, the gateway RC compares the bidding price in the multicast message with the lowest sharing price registered on that interface. There are two possibilities: (1) Case 1: The bid price for door lock A is higher than or equal to the lowest shared bid: The gateway RC further queries the (*, G) multicast routing table entries for the interface that has lock C registered. Finding no bidding information (indicating that lock A's bidding price is its first bid), it adds new bidding information to that interface, including the bidding lock ID (lock A) and lock A's bidding price. The gateway RC temporarily caches the parking space sharing application multicast data packet sent by gateway RA (the purpose of caching is so that if lock A's application is successful, the gateway RC can subsequently forward the multicast data packet to lock C to notify it).

[0051] The gateway RC recasts a parking space sharing bidding temporary acceptance multicast data packet, containing the multicast group address G, message type (parking space sharing bidding temporary acceptance), and target door lock ID (door lock A). This multicast packet will be accurately forwarded by each router according to the outgoing interface information of door lock A bound in its (*, G) table, and finally delivered to the direct-connected gateway RA of door lock A.

[0052] (2) Scenario 2: The bid price for door lock A is lower than the lowest shared bid: The gateway RC sends a multicast data packet to reject the parking space sharing bid. The packet includes the multicast group address G, message type (parking space sharing bid rejection), target lock ID (lock A), rejecting lock ID (lock C), rejection reason (below the minimum sharing bid), and the current successful bid (set to the minimum sharing bid for lock C in this case). This multicast data will also be accurately forwarded to the direct gateway RA of lock A.

[0053] The following steps 4 and 5 are described, assuming it is case 1 (i.e., temporarily accepting the bid for door lock A).

[0054] 4. Parking space sharing application (door lock B): Afterwards, other owners who needed to share parking spaces also activated the parking space sharing application mode through their own door locks (such as door lock B), and entered the expected time period, initial bid, and highest bid increment.

[0055] Similar to door lock A (step 2), door lock B sends an enhanced IGMP join message to its gateway router (such as gateway RB) to join multicast group G. The message includes an extended message type (parking space sharing application), door lock ID (door lock B), expected demand period, initial bid, bid increment, and maximum bid.

[0056] After receiving the message, the gateway RB records the correspondence between the interface and multicast group G in its IGMP interface group table, and generates a (*, G) multicast routing table entry. The entry binds the following information to the interface that received the message: parking space demander identifier, door lock ID (door lock B), initial bid price, bid increment, and maximum bid price. The gateway RB then becomes the demander agent for door lock B's parking space sharing service.

[0057] The gateway RB then sends an extended PIM Join message to the upstream router, carrying the lock ID (lock B). Upon receiving the message, the upstream router adds the interface receiving this message to its multicast routing table entry (*, G) in its outgoing interface list and binds lock B as a forwarding filter condition. This mechanism propagates hop-by-hop among the routers in the cell. Subsequent routers receiving multicast messages destined for multicast group G, with the target lock ID specified as lock B, will precisely forward them to the directly connected gateway RB of lock B.

[0058] As the demand agent for door lock B, gateway RB also multicasts a parking space sharing application multicast data message, which includes the multicast group address G, message type (parking space sharing application), demander door lock ID (door lock B), expected demand time period, and bidding price.

[0059] 5. Parking space sharing bidding processing (gateway RC): After the multicast data packet of parking space sharing request from door lock B, which is proxies gateway RB, is forwarded by each router, gateway RC, which is directly connected to door lock C, receives the multicast data, identifies it as a parking space sharing request, and then searches its local (*, G) multicast routing table for an entry marked with a parking space provider. It then matches this entry with the expected demand time period information of door lock B in the multicast data and finds that the sharing time period for parking space c1 of door lock C meets the requirements. Similarly, gateway RC, acting as a proxy for door lock C's parking space sharing service, does not forward the multicast data to door lock C and performs subsequent proxy operations. Next, gateway RC compares the bidding price of door lock B in the multicast message with the lowest sharing price of door lock C registered on that interface. There are two possibilities: (1) Case 1: The bidding price of door lock B is higher than or equal to the lowest shared price.

[0060] The gateway RC further queries the (*, G) multicast routing table entries, finding entries in the table where the interface is registered as lock C. It discovers bidding information (bid lock A, lock A's bid price). Comparing the bid price of lock B with that of lock A, the following sub-cases emerge: 1) Sub-case 1: The bid price for door lock B is higher than the bid price for door lock A.

[0061] In its local (*, G) multicast routing table, the gateway RC updates its local bidding information with a higher bid for the entry registered with lock C (updated as: bidding lock B, lock B's bidding bid). Next, the gateway RC temporarily caches the parking space sharing application multicast data packets sent by the gateway RB (again, caching is for the purpose of forwarding the multicast data packets to lock C if lock B's application is successful). Previously cached parking space sharing application multicast data packets from the gateway RA can be deleted. Then, the gateway RC modifies the parking space sharing application multicast data packets previously received from the gateway RB (not regenerating the packets for higher efficiency), adding the target lock ID (lock A) field (this information is for forwarding the packet to the gateway where lock A resides, informing lock B of its higher bid and its bidding bid) and the publisher lock ID (lock C; this information indicates which parking space sharing application the lock is applying for), and then multicasts it. After the modification, the message will be accurately forwarded to the gateway RA where lock A is located through each router. The latter can continue to act as a proxy for lock A to bid, see step 6.

[0062] The gateway RC also multicasts a parking space sharing bidding temporary acceptance multicast data packet, which includes the multicast group address G, message type (parking space sharing bidding temporary acceptance), and target door lock ID (door lock B). This multicast packet will be accurately forwarded by each router according to the outgoing interface information of door lock B bound in its respective (*, G) table, and finally delivered to the direct-connected gateway RB of door lock B.

[0063] 2) Sub-case 2: The bidding price of door lock B is equal to or lower than the bidding price of door lock A.

[0064] The gateway RC does not update the bidding information. In cases of identical bids, since lock A submitted its bid first, lock B is also deemed to have failed to win the bid.

[0065] Next, the gateway RC multicasts a parking space sharing bid rejection multicast data packet. The packet includes the multicast group address G, message type (parking space sharing bid rejection), target lock ID (lock B), rejecting lock ID (lock C), rejection reason (lower than the current successful bid), and the current successful bid price (lock A's bid price). This multicast message will be precisely forwarded by each router according to the outgoing interface information of lock B bound in its respective (*, G) table entry, and finally delivered to the direct-connected gateway RB of lock B.

[0066] (2) Situation 2: The bidding price of door lock B is lower than the lowest shared price.

[0067] The gateway RC sends a multicast data packet to reject the parking space sharing bid. The packet includes the multicast group address G, message type (parking space sharing bid rejection), target lock ID (lock B), rejecting lock ID (lock C), rejection reason (below the lowest sharing bid), and the current successful bid (here, the lowest sharing bid for lock C). This multicast data will also be accurately forwarded to the direct gateway RB of lock B.

[0068] 6. Handling of temporary bidding failure for door lock proxy gateway: For step 3(2) case 2 (i.e., lock A is rejected), or step 5(1)1) sub-case 1 (i.e., lock A receives a higher bid message from lock B), or step 5(1)2) sub-case 2 (i.e., lock B is rejected), or step 5(2) case 2 (i.e., lock B is rejected), the corresponding locks are all temporarily rejected in the bid. The relevant multicast messages will be accurately forwarded to the direct gateway (gateway RA or gateway RB) of the temporarily rejected lock through each router according to the destination lock ID information.

[0069] There are two ways to handle a door lock if the bid is temporarily unsuccessful: (1) For the shared parking space C with door locks, continue bidding: The direct gateway of a lock whose bidding has temporarily failed will, based on the lock ID, bidding increment, and highest bidding price recorded in its local (*, G) multicast routing table entry, increase the bidding increment by 1 (e.g., 0.5 yuan / hour) on top of the current successful bidding price (or the higher bid from competitor lock B) received in the multicast message. Then, it will determine whether it exceeds the lock's own highest bidding price. If so, it will abandon the bidding and send a bidding failure message unicast to its own proxy locks. If not, it will send a parking space sharing bidding multicast data packet, which includes the multicast group address G, message type (parking space sharing bidding), target lock ID (lock C), demand lock ID (i.e., the ID of the lock whose bidding has temporarily failed: lock A or B), expected demand time period, and bidding price (current successful bidding price + bidding increment).

[0070] (2) For the shared parking space with lock C, we will abandon the bidding and continue to bid for the shared parking spaces with other locks. The direct gateway of the door lock that has temporarily failed the bid (for door lock C parking space sharing) may also receive parking space sharing bid acceptance multicast data packets from other parking space sharing door lock proxy gateways. Therefore, it can also choose to abandon the door lock C parking space sharing application (i.e., not respond) and continue to complete other door lock parking space sharing applications and bidding operations.

[0071] 7. Continuous processing of parking space sharing bidding (gateway RC): In step 6(1), the parking space sharing bidding multicast data packet is accurately forwarded to the proxy gateway RC of door lock C through each router. The gateway RC identifies it as parking space sharing bidding and, referring to the logic in step 5, makes a new bidding offer. Compared with the current successful bidding offer in the bidding information registered with door lock C in the (*, G) multicast routing table entry, there are two cases: (1) Case 1: The bid price in the multicast data packet is higher than the currently registered successful bid price locally.

[0072] The gateway RC locally updates the bidding information; caches the latest received multicast data packets for parking space sharing applications and deletes the old packets; then modifies the received multicast data packets for parking space sharing bidding (in the original packet, the target lock ID field is modified to the lock ID that failed in this bid comparison to notify it that it can continue bidding; the publisher lock ID (i.e., lock C) is added to indicate which parking space sharing application was issued for), and performs multicast forwarding; then multicasts a parking space sharing bidding temporary acceptance message (the target lock ID is the lock ID that succeeded in this bid comparison).

[0073] (2) Case 2: The bid price in the multicast data packet is equal to or lower than the currently registered successful bid price locally.

[0074] The gateway RC multicasts a parking space sharing bidding rejection message (the target lock ID is the lock ID that failed in this bidding).

[0075] 8. Continuous bidding: Subsequently, the handling of temporarily failed bidding for door lock agent gateways should refer to step 6, and the handling of continuous bidding for gateway RC parking space sharing should refer to step 7.

[0076] 9. Successful processing of parking space sharing bidding (gateway RC): When the gateway RC generates bidding information for the first time (such as step 3(1) case 1) or updates bidding information subsequently (such as step 5(1)1) sub-case 1, or step 7(1) case 1), it sets a timer (such as 15 minutes). If the gateway RC does not update the local bidding information after the timer expires, it confirms that the bidding for the door lock in the bidding information was successful.

[0077] At this time, the gateway RC performs the following operations simultaneously: (1) Notify door lock C: For a successfully bid lock, the gateway RC temporarily caches the latest parking space sharing application multicast data message or parking space sharing bidding multicast data message sent by the corresponding directly connected gateway (the content of which includes the requesting lock ID, the expected demand period, and the bidding price). At this time, the local (*, G) table entry information can be used to add the parking space information c1 shared by lock C (lock C may share 2 or more parking spaces, so it is necessary to specify which parking space was successfully shared) to the local (*, G) table entry. Then, the message is officially forwarded to lock C to notify it.

[0078] (2) Notification of successful bid for door lock: The gateway (RC) sends a multicast message to formally accept parking space sharing bids. The message includes the multicast group address G, message type (formal acceptance of parking space sharing bids), target lock ID (set to empty to ensure it's sent to all locks in multicast group G, which all corresponding gateways can receive), successful bid lock ID (the bid lock ID recorded locally), successful bid price, parking space sharing lock ID (lock C), and shared parking space ID. This multicast message will be forwarded by each router to all outgoing interfaces in (*, G). The gateway directly connected to the successful bid lock forwards this message to the successful bid lock.

[0079] (3) Notify other parking spaces to share the direct connection gateway for door locks: For the multicast data packets mentioned in (2) above, other parking space sharing locks (except for lock C) can also receive the packets directly connected to the gateway. These gateways will find that the packets are officially accepted for parking space sharing bidding. Based on the lock ID that was successfully bid in the packet, they will check whether it is also registered in the local bidding information. If it is, it will be deleted locally (because the lock has successfully bid for the shared parking space of lock C, so other locks do not need to retain its bidding information).

[0080] Afterwards, both door lock C and the successfully bid door lock can notify the owner of the successful sharing of the parking space through the door lock management APP, thus completing the subsequent business.

[0081] Beneficial effects: 1. Low cost: Reuse existing property management systems, networks and door lock equipment, without the need to deploy dedicated servers.

[0082] 2. Power saving and reliability: Complex bidding logic is handled by the gateway, reducing the power consumption and interaction burden of the door lock.

[0083] 3. High efficiency and accuracy: It utilizes extended multicast protocol to achieve direct communication and accurate routing between agents, resulting in fast response and balanced network load.

[0084] 4. Decentralized and robust: No single point of failure, high system reliability.

[0085] Innovation points: 1. Extend the multicast protocol to bind parking space IDs and bidding information to routing table entries, enabling network devices to have service awareness capabilities and achieve accurate multicast forwarding based on application layer parameters.

[0086] 2. When a higher bid is received, the gateway reuses the original message from the subsequent competitor and modifies the target ID before forwarding it, efficiently combining status notifications with complete competition information and optimizing the interaction process.

[0087] 3. By making the gateway a "business agent" for the door lock, which maintains the status, makes decisions and communicates on behalf of the door lock, the contradiction between the computing and power supply capabilities of IoT terminals such as door locks and the complex real-time business requirements is resolved.

[0088] 4. The gateway automatically calculates, decides, and executes bid increases based on preset strategies (amplitude, maximum price), realizing full automation of the bidding process and improving the system's intelligence and response efficiency.

[0089] 5. Based on the multicast broadcast of the final successful bid message, the gateway of the non-successful parking space publisher is triggered to automatically clean up invalid bid information, realizing distributed parking space resource mutual exclusion locking under the decentralized architecture.

[0090] 6. By using cached messages to transmit complete transaction details to resource providers, the reliability and integrity of the business loop are ensured, avoiding the overhead and errors caused by reassembling data.

[0091] Another embodiment of the present invention provides a parking space sharing system based on door locks, see [link to relevant documentation]. Figure 3 The system may include: The publishing module 301 is used for publishing shared information and establishing paths: based on the parking space sharing information set by the parking space provider owner on the first door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a service agent, and establishes a precise multicast forwarding path for the door lock in the network through the extended multicast routing protocol; Submission module 302 is used for sharing application submission and path establishment: Based on the parking space demand and bidding strategy entered by the parking space demander on the second door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a business proxy, establish a precise forwarding path, and the proxy multicasts and sends the parking space sharing application message. Processing module 303 is used for distributed bidding processing and status synchronization: Based on multiple application or bidding messages received by the provider gateway router, it performs demand matching, price comparison and status determination by proxy, and synchronizes the bidding leader, bidding loser and latest bid status in real time by forwarding the messages via targeted multicast. The confirmation module 304 is used for confirming the bidding results and locking resources: based on the preset bidding stabilization time, the provider gateway router confirms the final winner and multicasts the successful bidding result to the relevant parties. At the same time, it triggers other publisher gateways in the network to clean up invalid bidding information, thus completing the distributed locking of parking space resources.

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

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

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

[0095] 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 sharing parking spaces based on door locks, characterized in that, The method includes: Shared information publishing and path establishment: Based on the parking space sharing information set by the parking space provider owner on the first door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a service agent, and establishes a precise multicast forwarding path for the door lock in the network through the extended multicast routing protocol; Shared application submission and path establishment: Based on the parking space demand and bidding strategy entered by the parking space owner on the second door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a business proxy, establish a precise forwarding path, and then the proxy multicasts and sends the parking space sharing application message. Distributed bidding processing and status synchronization: Based on multiple application or bidding messages received by the provider's gateway router, the gateway router performs demand matching, price comparison and status determination, and synchronizes the bidding leader, bidding loser and the latest bid status in real time by forwarding the messages via targeted multicast. Confirmation of bidding results and locking of resources: Based on the preset bidding stabilization period, the provider gateway router confirms the final winner and multicasts the successful bidding result to relevant parties. At the same time, it triggers other publisher gateways in the network to clean up invalid bidding information, thus completing the distributed locking of parking space resources.

2. The method according to claim 1, characterized in that, The shared information publishing and path establishment include: Shared information settings: Based on the owner's operation on the first door lock, set the identifier of the parking space to be shared, the sharing time period, and the minimum sharing price information; Agent Joining and Local Binding: Based on the shared information, the first door lock sends an extended IGMP join message to its directly connected gateway router. The message includes the message type, door lock identifier, and the shared information. After receiving the message, the gateway router binds the parking space provider identifier, the first door lock identifier, and the shared information to the outgoing interface corresponding to its multicast forwarding table entry, thus becoming the service agent of the door lock. Precise forwarding path establishment: Based on the extended PIM join message carrying the first door lock identifier sent upstream by the gateway router, each router in the community network adds the receiving interface to the outgoing interface list in its multicast routing table entry and binds the first door lock identifier as a forwarding filtering condition, thereby establishing a precise multicast forwarding path for messages sent to the door lock identifier.

3. The method according to claim 2, characterized in that, The shared request submission and path establishment include: Demand and Strategy Input: Based on the actions of the parking space owner on the second door lock, input the demand period, initial price, bidding range, and maximum bid strategy; Agent Joining and Local Binding: According to the requirements and policies, the second door lock sends an extended IGMP join message to its directly connected gateway router. The message includes the message type, door lock identifier, and the requirements and policies information. After receiving the message, the gateway router binds the parking space demander tag, the second door lock identifier, and the requirements and policies information to the outgoing interface corresponding to its multicast forwarding table entry, thus becoming the service agent of the door lock. Precise forwarding path establishment: Based on the extended PIM join message carrying the second door lock identifier sent upstream by the gateway router, a precise multicast forwarding path for the door lock identifier is established in the network; Application message multicast: Based on the gateway router acting as a proxy, a parking space sharing application data message is sent via multicast. The message includes the lock identifier of the requesting party, the time period of the request, and the initial price. The target lock identifier field is empty, so as to trigger the flooding and forwarding of the message within the multicast group in the network.

4. The method according to claim 3, characterized in that, The distributed bidding process and state synchronization include: Initial application ruling: Based on the first parking space sharing application message sent by the demander's agent received by the provider's gateway router, the demand time period and the sharing time period are matched locally, and the application price is compared with the lowest sharing price; If the requested bid is not lower than the lowest price, the local interface will add the lock identifier and its bid as the current successful bid information and cache the application message. Then, a bid acceptance message will be sent to the lock's multicast channel, which will be delivered to the lock's proxy gateway. If the requested bid is lower than the lowest price, a bid rejection message will be sent to the lock's multicast channel. The rejection message includes the current lowest price as a reference, and the message will also be delivered to the lock's proxy gateway. Competitive bid adjudication: Based on the application or bidding messages received by the provider's gateway router from other demanders' agents, and provided that the lowest price is met, the provider's bid is compared with the currently registered successful bids. If the new bid is higher, the local successful bid information is updated to reflect the new bidder. Previously cached old messages are deleted, and the message corresponding to the new bidder is cached. Simultaneously, the message is modified to specify the original leading lock as the target and set the publishing lock identifier before multicasting. This modified message is sent to the original leading lock's proxy gateway to notify it of the higher bid and a temporary bid acceptance message is sent to the new bidding lock's proxy gateway. Similarly, this message is also sent to the new bidding lock's proxy gateway. If the new bid is not higher than the current successful bid, a bid rejection message is sent to the new bidding lock, containing the current successful bid. Automatic bidding decision for the losing party: Based on the rejection notification or higher price notification received by the gateway router of the party that temporarily loses the bid, a decision is made in combination with the locally recorded bid range for the door lock and the highest bid strategy; If the decision is made to continue bidding and the bid does not exceed the maximum price limit, a multicast message will be sent targeting the provider's door lock, carrying the new offer. If the decision is to abandon the bidding, the process can proceed to other shared parking space application processes.

5. The method according to claim 4, characterized in that, The confirmation of bidding results and resource locking include: Final winner confirmation: Based on the timer started by the provider's gateway router when the successful bidding information is first generated or updated, if the information is not updated again within the preset time period, the demand party in the information is confirmed as the final winner; Notification to resource providers and winners: Based on the final confirmation result, the provider's gateway router will supplement the cached winning bid or application message with specific shared parking space identification information and forward it to the provider's door lock for notification; at the same time, it will multicast a parking space sharing bidding formal acceptance message with an empty target door lock identifier to trigger the message flooding forwarding within the multicast group in the network; after receiving the message, the winning gateway will further forward it to the winning door lock for notification; Distributed resource locking and cleanup: Upon receiving the formal acceptance message of the bidding from the gateway router of other parking space publishers, the winning gate lock identifier is extracted and the local bidding information is checked to see if the identifier is included. If it is included, it is deleted, thereby automatically releasing the winning party's bidding lock on other shared parking space resources.

6. The method according to claim 5, characterized in that, The method also includes a business completion process after the bidding ends: Transaction details transmission: The cached message forwarded by the provider's gateway router to the provider's door lock contains the complete application information of the winning party, so that the provider's owners can know the transaction details; Application layer notification: The provider lock and the successful lock will notify their respective owners of the successful parking space sharing through their associated lock management applications to complete the subsequent offline handover.

7. A parking space sharing system based on door locks, characterized in that, The system includes: The publishing module is used for sharing information publishing and path establishment: Based on the parking space sharing information set by the parking space provider owner on the first door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a service agent, and establishes a precise multicast forwarding path for the door lock in the network through the extended multicast routing protocol; The submission module is used for submitting sharing applications and establishing paths: based on the parking space demand and bidding strategy entered by the parking space demander on the second door lock, the door lock sends an extended multicast join message, triggering its gateway router to record the information and become a business proxy, establish a precise forwarding path, and then the proxy multicasts and sends the parking space sharing application message. The processing module is used for distributed bidding processing and status synchronization: based on multiple application or bidding messages received by the provider gateway router, it performs demand matching, price comparison and status determination by proxy, and synchronizes the bidding leader, bidding loser and latest bid status in real time by forwarding the messages via targeted multicast. The confirmation module is used for confirming the bidding results and locking resources: based on the preset bidding stabilization period, the provider gateway router confirms the final winner and multicasts the successful bidding result to relevant parties. At the same time, it triggers other publisher gateways in the network to clean up invalid bidding information, thus completing the distributed locking of parking space resources.

8. The system according to claim 7, characterized in that, The publishing module is specifically used for: Shared information settings: Based on the owner's operation on the first door lock, set the identifier of the parking space to be shared, the sharing time period, and the minimum sharing price information; Agent Joining and Local Binding: Based on the shared information, the first door lock sends an extended IGMP join message to its directly connected gateway router. The message includes the message type, door lock identifier, and the shared information. After receiving the message, the gateway router binds the parking space provider identifier, the first door lock identifier, and the shared information to the outgoing interface corresponding to its multicast forwarding table entry, thus becoming the service agent of the door lock. Precise forwarding path establishment: Based on the extended PIM join message carrying the first door lock identifier sent upstream by the gateway router, each router in the community network adds the receiving interface to the outgoing interface list in its multicast routing table entry and binds the first door lock identifier as a forwarding filtering condition, thereby establishing a precise multicast forwarding path for messages sent to the door lock identifier.

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