Parking lot package matching method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of intelligent parking, in particular to a parking lot package matching method and device, electronic equipment and a storage medium, and the method comprises the steps: receiving parking renting demand information inputted by a user in a user interface, and carrying out the structural processing of the parking renting demand information, and obtaining a user demand feature vector; and extracting a feature vector from at least one package in the parking lot package resource library to obtain a package feature vector corresponding to the package. According to the method, the renting demand of the user and the parking lot package resources are vectorized respectively, and intelligent matching and integrating degree calculation are performed based on the feature vectors, so that conversion from a fixed package to demand driving is realized. According to the method, the single package and the combined package with high integrating degree can be automatically recommended to the user, the matching accuracy of the package and the user demand is improved, the time for the user to select the package is shortened, the selection cost and parking expenditure of the user are reduced, meanwhile, the parking lot is assisted to digest idle resources, and the operation strategy is optimized.

Description

Technical Field

[0001] This invention relates to the field of smart parking technology, and in particular to a parking lot package matching method, device, electronic device, and storage medium. Background Technology

[0002] With the acceleration of urbanization, the problem of "parking difficulties" has become increasingly prominent. In order to improve the utilization rate of parking spaces and user experience, many parking lot managers have launched a variety of rental packages, such as monthly, quarterly, annual, daytime packages, nighttime packages, and off-peak packages.

[0003] Currently, parking lot packages offer fixed, pre-set options. However, user needs are diverse and dynamic (for example, a user may only need parking during weekdays or only on Tuesdays and Thursdays). With the increasing variety of parking packages, it becomes increasingly difficult for users to find a package that perfectly suits their needs from among numerous parking lots and packages. The selection process is time-consuming, often resulting in users choosing more expensive or less utilized packages, leading to economic waste and a poor user experience. For parking lot managers, the lack of access to user demand information prevents them from accurately understanding potential market needs, resulting in unsold packages or idle parking spaces and low resource utilization. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a parking lot package matching method, device, electronic device and storage medium, which obtains the user's parking rental demand information and recommends customized package information that meets the user's rental demand information, thereby improving the user experience and making it easier for parking lot managers to grasp the user's demand information in a timely manner.

[0005] In a first aspect, embodiments of the present invention provide a parking lot package matching method, the method comprising: Receive parking rental request information input by the user in the user interface, and perform structured processing on the parking rental request information to obtain the user demand feature vector; Extract feature vectors from at least one package in the parking package resource library to obtain the package feature vectors corresponding to the package; Based on user demand feature vectors and package feature vectors, at least one package is matched from the parking lot package resource library, and the degree of fit between the package and the user demand feature vector is greater than a preset value. Normalize at least one package and generate recommendation results; The final recommendation results will be returned to the user interface.

[0006] Combining the first aspect, the parking rental demand information is structured to obtain a user demand feature vector, including: Extract the core parameters, preference parameters, and flexibility parameters from parking rental demand information; Core parameters, preference parameters, and flexibility parameters are quantified into feature values ​​and combined to form a user demand feature vector. The core parameters include at least one of the following: target parking lot or area, expected rental period, and daily parking hours. Preference parameters include at least one of the following: budget limit, parking space type preference, and parking lot brand preference; The flexibility parameters include at least one of the following: rental period adjustment range, parking time period fluctuation range, and acceptable alternative parking lot range.

[0007] In conjunction with the first aspect, the step of extracting feature vectors from at least one package in the parking package resource library to obtain the package feature vectors corresponding to the package includes: Extract basic attribute parameters, usage rule parameters, and dynamic attribute parameters from the package; The basic attribute parameters, usage rule parameters, and dynamic attribute parameters are quantified into feature values ​​and combined to form a package feature vector. The basic attribute parameters include at least one of the following: package identifier, package type, price, and validity period; The rule parameters include at least one of the following: applicable time period, applicable date, parking space type, and shared attribute; Dynamic attribute parameters include at least one of the following: inventory balance, historical sales volume, and package flexibility score. The package flexibility score is used to characterize the parking lot's willingness to adjust package prices or rules.

[0008] In conjunction with the first aspect, at least one package is normalized to generate recommendation results, including: Standardize at least one package to obtain a recommended package; For each recommended package, a comprehensive score is calculated based on a pre-set unified scoring model to obtain the comprehensive score of the recommended package; All recommended packages are ranked according to the order of merit of the comprehensive scores. Select the top-ranked recommendation schemes to generate the final recommendation result list; Each recommended option in the results list includes the total price, the amount saved relative to the original price, and information on how well it matches the user's needs.

[0009] Combining the first aspect, based on user demand feature vectors and package feature vectors, at least one package is matched from the parking package resource library, including: Based on the user demand feature vector, at least one target package is matched from the parking package resource library using the first matching rule; Based on the user demand feature vector, at least one target combination package is matched from the parking package resource library using the second matching rule; If neither the first matching rule nor the second matching rule matches a corresponding package, the target package and / or target combination package with the closest fit to the preset value will be sent to the administrator terminal, and the customized package information returned by the administrator terminal will be received.

[0010] In conjunction with the first aspect, the first matching rule includes: matching the user demand feature vector with the package feature vector of a single package one by one to determine at least one target package with a fit greater than a preset value. The second matching rule includes: decomposing the user demand feature vector into several sub-feature vectors, matching the sub-feature vectors with the package feature vectors of multiple packages, and determining at least one target combination package with a fit greater than a preset value.

[0011] In conjunction with the first aspect, the steps of sending the target package and / or target combination package with the closest matching degree to the preset value to the administrator terminal include: Obtain the administrator information configured in the target package and / or target combination package, and send the target package and / or target combination package and parking rental demand information to at least one administrator terminal corresponding to the administrator information.

[0012] Secondly, embodiments of this application also provide a parking lot package matching device, the device comprising: The demand extraction module is used to receive parking rental demand information input by users in the user interface, and to perform structured processing on the parking rental demand information to obtain user demand feature vectors. The package extraction module is used to extract feature vectors from at least one package in the parking package resource library to obtain the package feature vectors corresponding to the package. The resource matching module is used to match at least one package from the parking lot package resource library based on the user demand feature vector and the package feature vector. The degree of fit between the package and the user demand feature vector is greater than a preset value. The recommendation generation module is used to normalize at least one package and generate recommendation results; The information feedback module is used to return the final recommendation results to the user interface.

[0013] Thirdly, embodiments of this application also provide an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor runs the computer program to cause the electronic device to perform the method described above.

[0014] Fourthly, embodiments of this application also provide a readable storage medium storing computer program instructions, which are read and executed by a processor to perform the method described above.

[0015] The embodiments of the present invention bring the following beneficial effects: The present application provides a parking package matching method, device, electronic device and storage medium. The method includes: receiving parking rental demand information input by a user on a user interface; performing structured processing on the parking rental demand information to obtain a user demand feature vector; extracting feature vectors from at least one package in a parking package resource library to obtain a package feature vector corresponding to the package; matching at least one package from the parking package resource library based on the user demand feature vector and the package feature vector, wherein the fit between the package and the user demand feature vector is greater than a preset value; performing normalization processing on the at least one package to generate a recommendation result; and returning the final recommendation result to the user interface.

[0016] This application vectorizes user rental demands and parking package resources separately, and performs intelligent matching and fit calculation based on feature vectors, realizing a shift from fixed packages to demand-driven approaches. This method can automatically recommend highly compatible single and combined packages to users, improving the accuracy of matching packages with user needs, reducing the time users spend selecting packages, lowering user selection costs and parking expenses, while also helping parking lots utilize idle resources and optimize operational strategies, achieving two-way optimization of supply and demand and efficient resource allocation.

[0017] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the parking package matching method provided in an embodiment of the present invention. Figure 2The execution logic diagram of the parking package matching method provided in the embodiments of the present invention is shown below; Figure 3 A schematic diagram of a parking package matching device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the electronic device structure provided in an embodiment of the present invention.

[0021] Figure label: 10 - Demand Extraction Module, 20 - Package Extraction Module, 30 - Resource Matching Module, 40 - Recommendation Generation Module, 50 - Information Feedback Module; 130 - Processor, 131 - Memory, 132 - Bus, 133 - Communication interface. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] To facilitate understanding of this embodiment, the application scenarios and design concepts of this application embodiment will be briefly introduced below.

[0024] The main shortcomings of existing technologies are: fixed packages cannot match users' personalized and fragmented parking needs; matching relies on manual selection by users, which is inefficient and cannot handle cross-package combinations; information asymmetry leads to excessive user costs and idle parking resources, and there is a lack of an effective intelligent supply and demand matching and negotiation mechanism.

[0025] Based on this, embodiments of this application provide a parking lot package matching method, device, electronic device, and storage medium.

[0026] Example 1 This application provides a parking lot package matching method, combined with Figure 1 As shown, the method includes: S110 receives parking rental request information input by the user in the user interface, and performs structured processing on the parking rental request information to obtain the user request feature vector.

[0027] S120: Extract feature vectors from at least one package in the parking lot package resource library to obtain the package feature vectors corresponding to the package.

[0028] S130, based on the user demand feature vector and the package feature vector, matches at least one package from the parking lot package resource library, and the degree of fit between the package and the user demand feature vector is greater than the preset value.

[0029] S140, normalize at least one package and generate recommendation results.

[0030] S150, return the recommendation results to the user interface.

[0031] Step S110 aims to guide users to clearly and completely express their personalized parking rental needs through a dedicated "Rental Center" interface. This interface, which allows users to actively initiate parking requests, differs from the traditional passive browsing of package lists. It provides guided input components such as forms, calendars, and sliders, enabling users to define their parking needs in detail. The system then collects parking rental requests based on the user's input.

[0032] In conjunction with the first aspect, step S110 involves structuring the parking rental demand information to obtain a user demand feature vector, specifically including: S111, extract the core parameters, preference parameters, and flexibility parameters from the parking rental demand information.

[0033] S112 quantifies the core parameters, preference parameters, and flexibility parameters into feature values, and combines them to form a user demand feature vector.

[0034] The core parameters include at least one of the following: target parking lot or area, expected rental period, and daily parking hours. Preference parameters include at least one of the following: budget limit, parking space type preference, and parking lot brand preference; The flexibility parameters include at least one of the following: rental period adjustment range, parking time period fluctuation range, and acceptable alternative parking lot range.

[0035] In this embodiment, the structured processing of parking rental demand information to obtain user demand feature vectors refers to converting the diverse demand information input by users through the interface into a unified, quantifiable, and calculable data representation format within the system. Specifically, this includes the following steps: First, the requirement parameters are extracted and categorized. The system parses and separates three key parameters from the raw input: Core parameters are used to define the spatiotemporal basis of parking demand, including at least one of the following: target parking lot or area, expected rental period (accurate to start and end dates), and daily parking hours, such as "near Building A, rental for 3 months, parking from 9:00 to 18:00 every day".

[0036] Preference parameters are used to reflect users' subjective choices and economic constraints, including at least one of the following: budget limit, parking brand preference, and preference for parking space type (such as fixed / non-fixed, indoor / outdoor). For example, a budget of no more than 500 yuan / month, a preference for a fixed indoor parking space, and a preference for a certain brand of parking lot.

[0037] Flexibility parameters are used to characterize the flexibility and compromise range of demand, the adjustability of demand, including at least one of the following: rental period adjustment range, parking time period fluctuation range, and acceptable alternative parking lot range. For example, the rental period can be adjusted by ±7 days, the time period can fluctuate by 1 hour, and other parking lots within 500 meters are acceptable.

[0038] Next, vectorization is performed. The parsed parameter values ​​are analyzed and normalized, for example, converting dates to timestamps, budgets to numerical values, and preference types to enumeration codes. Then, these processed values ​​are filled into a pre-defined multi-dimensional vector template according to a predetermined dimension order, thereby generating a standardized user demand feature vector U that can be directly processed by the machine. This provides accurate input for subsequent algorithm matching, and the normalized recommendation results pushed to the user are more in line with the user's actual rental needs, making it easier for the user to understand the recommended package.

[0039] In conjunction with the first aspect, step S120 includes: S121 extracts basic attribute parameters, usage rule parameters, and dynamic attribute parameters from the package.

[0040] S122 quantifies the basic attribute parameters, usage rule parameters, and dynamic attribute parameters into feature values, and combines them to form a package feature vector.

[0041] The basic attribute parameters include at least one of the following: package identifier, package type, price, and validity period; The rule parameters include at least one of the following: applicable time period, applicable date, parking space type, and shared attribute; Dynamic attribute parameters include at least one of the following: inventory balance, historical sales volume, and package flexibility score. The package flexibility score is used to characterize the parking lot's willingness to adjust package prices or rules.

[0042] Step S120 is used to transform the original package information with different formats released by the parking lot management party (B-end) into a standardized feature vector P that is in the same semantic and computational space as the user demand vector U, thereby establishing a digital model of the supply side for intelligent matching.

[0043] Specifically, step S121 involves parsing and structuring the original package data.

[0044] The basic attribute parameters define the package's identity and business terms. These include a unique package identifier (ID), a package type that distinguishes its business model (such as monthly, quarterly, daytime, and nighttime packages), a price (original price and discounted price), and a validity period. These are the most core and static characteristics of the package that cannot be easily changed.

[0045] Rule parameters are used to define the applicable conditions and service content of the package, precisely describing when, where, and how the package takes effect, including applicable time periods (e.g., 8:00-20:00), applicable dates (e.g., Monday to Friday only), parking space type (fixed, non-fixed, indoor, outdoor), and sharing attributes (whether multiple people can share the space at the same time). This part directly determines whether the package can meet the core parameters of the user's needs.

[0046] Dynamic attribute parameters are used to reflect the market status and negotiability of the package. This includes real-time or near real-time updated inventory levels, historical sales reflecting popularity, and a package flexibility score. This score, based on historical data and parking lot operation strategies, quantitatively assesses the parking lot management's willingness to adjust the package price or rules (such as temporarily relaxing usage periods).

[0047] Step S122 converts the above three types of parameters into a package feature vector P that the algorithm can compute: First, quantification is performed using feature values: text or non-standard format parameters are mapped to numerical values. For example, package types are mapped to discrete codes (e.g., 0-monthly, 1-quarterly, 2-daytime package); prices are directly expressed as numerical values; applicable time periods are broken down into hourly and minute codes for start and end times; applicable dates can be represented by a 7-dimensional binary vector (Monday to Sunday) such as [1, 1, 1, 1, 1, 0, 0]; and the package flexibility score is calculated as a continuous value between 0 and 1 based on the model.

[0048] Subsequently, the dispersed and heterogeneous feature values ​​are combined to form a vector P: all quantized feature values ​​are combined according to a preset structure that is aligned with or can be mapped to the user requirement vector U in terms of dimensional definition. For example, a simplified vector P might be represented as: [Parking lot ID, Package ID, Type code, Price, Valid start date, Valid end date, Time period start, Time period end, Date vector, Parking space type code, Shared sign, Inventory, Historical sales, Elasticity rating].

[0049] Subsequently, step S130 performs a three-layer progressive intelligent matching process based on the user demand feature vector U obtained in step S110 and the package feature vector P obtained in step S120, so as to output one or more highly compatible packages that meet budget constraints in complex demand scenarios.

[0050] In conjunction with the first aspect, step S140 includes: S141, standardize and convert at least one package to obtain a recommended package.

[0051] S142, For each recommended package, a comprehensive score is calculated based on a preset unified scoring model to obtain the comprehensive score of the recommended package.

[0052] S143. Sort all recommended packages according to the order of merit of the schemes represented by the comprehensive score.

[0053] S144: Select the first number of recommended schemes with the best ranking and generate the final recommendation result list.

[0054] Each recommended option in the results list includes the total price, the amount saved relative to the original price, and information on how well it matches the user's needs.

[0055] Step S140 is used to standardize, integrate, quantitatively evaluate, and present the best of the various packages generated in step S130.

[0056] First, step S141 unifies all input packages into a comparable data object (i.e., a recommended package or recommended plan). For example, a combination plan containing multiple sub-packages is aggregated and its key attributes such as total cost and total coverage period are calculated to form a standardized plan record.

[0057] Subsequently, to ensure the objectivity and consistency of the evaluation, step S142 employs a pre-defined unified scoring model to quantitatively evaluate each standardized recommended package. This model comprehensively considers multiple attributes of each option (such as total cost, demand coverage, and package-specific attributes) as well as the preferences and constraints in the user's original needs, outputting a comprehensive score through a defined calculation function. This score quantitatively characterizes the overall merits of the option in meeting the user's core needs and controlling overall costs across multiple dimensions.

[0058] Next, based on the comprehensive score calculated in S142, the order of merit of all candidate solutions is determined. This order refers to the ranking sequence of solutions based on the magnitude of the score values. If the scoring model is designed so that higher scores represent better solutions, then they are arranged in descending order of score; if the score represents cost deviation (lower values ​​are better), then they are arranged in ascending order. Thus, in step S143, the full order of the solutions is completed according to the good and bad criteria defined by the scoring model.

[0059] Finally, after the total order sort is completed, step S144 starts from the optimal end of the sorted sequence and selects a pre-set first number (i.e., Top-N) of recommended solutions to generate the final recommendation result list. This process ensures that the final selection presented to the user is a limited number of options that have been filtered through global comparison by the algorithm and have the best overall performance, which conforms to the principle of simplicity and efficiency. Each recommended solution explicitly includes the following key information: Total Price: The total cost that the user needs to pay to adopt this plan; Savings: The amount saved by this plan compared to the original price or a benchmark plan (such as per-use billing), used to visually demonstrate its economic efficiency; Fit information: This shows the extent to which the solution meets the user's core needs, either quantitatively or in a tiered manner.

[0060] The client refers to the front-end application that the user interacts with directly, such as a mobile app, WeChat mini-program, or web page. Finally, in step S150, the "final recommendation result" generated in step S140 (usually structured data in JSON or Protocol Buffers format) is encapsulated and prepared to be sent back to the client via a network protocol (usually HTTP / HTTPS or WebSocket) according to a predefined API interface specification.

[0061] On the user interface, the results list is dynamically rendered and presented in a structured visual format, such as lists, cards, or comparison tables. Each recommended option is displayed according to its ranking position (usually with the best option at the top), ensuring that key decision-making factors such as total price, savings, and suitability information are clearly identifiable. This step achieves the visual delivery of algorithm results, allowing users to intuitively compare the advantages and disadvantages of different options and make a final choice based on this, thus completing the entire intelligent service process from inputting needs to receiving personalized recommendations.

[0062] In conjunction with the first aspect, step S130 includes: S131, based on the user demand feature vector, at least one target package is matched from the parking package resource library through the first matching rule.

[0063] S132, based on the user demand feature vector, at least one target combination package is matched from the parking package resource library through the second matching rule.

[0064] S133, if neither the first matching rule nor the second matching rule matches the corresponding package, then the target package and / or target combination package with the closest fit to the preset value is sent to the administrator terminal, and the customized package information returned by the administrator terminal is received.

[0065] In conjunction with the first aspect, the first matching rule in step S131 includes: matching the user demand feature vector with the package feature vector of a single package one by one to determine at least one target package with a fit greater than a preset value.

[0066] The second matching rule in step S132 includes: decomposing the user demand feature vector into several sub-feature vectors, matching the sub-feature vectors with the package feature vectors of multiple packages, and determining at least one target combination package with a fit greater than a preset value.

[0067] Step S130 employs a multi-level, progressively deepening intelligent matching strategy, designed to address various user parking needs ranging from simple to complex, ensuring that a feasible recommended solution is ultimately generated.

[0068] In conjunction with the first aspect, step S133, which involves sending the target package and / or target combination package with the closest fit to the preset value to the administrator terminal, includes: Obtain the administrator information configured in the target package and / or target combination package, and send the target package and / or target combination package and parking rental demand information to at least one administrator terminal corresponding to the administrator information.

[0069] In step S131, precise matching is performed, which involves comparing and quantifying the user demand feature vector U with each package feature vector P in the parking package resource library using the first matching rule. The core of this process is calculating a comprehensive fit score. This score uses a weighted function to integrate the degree of matching between user needs and the package across multiple dimensions, such as time-of-day matching. Date matching degree And budget fit, etc. The weight coefficients of each dimension (such as w1, w2, w3, etc.) can be dynamically adjusted according to the user's preferences and flexibility parameters to achieve personalized priority settings. Understandably, a threshold T1 is preset in the matching strategy. If one or more packages have a fit score exceeding T1, these packages are output as target packages that directly meet the user's needs. This step aims to efficiently handle standardized or simple needs that can be well covered by existing single packages. For example, for a user's need for "parking from 9:00 to 17:00 on weekdays for one month, with a budget of 300 yuan," the fit score of all "monthly packages" (usually available 24 hours a day, priced at 350 yuan) is calculated. Because the price far exceeds the budget, its budget fit score is extremely low, resulting in an overall score that cannot reach T1, therefore no exact match is found.

[0070] In step S132, if a perfect match fails to find a single package that meets the required fit, it indicates that the user's needs may be more complex or specific. The algorithm then automatically enters the combination matching stage, exploring based on the second matching rule. In this stage, the algorithm is no longer limited to finding a perfect match for a single package, but intelligently decomposes the user's overall needs U into multiple logical sub-units (e.g., decomposing periodic parking needs by day or by time period). Subsequently, the algorithm performs combination search and optimization in the package resource library, aiming to find a package set S = {P1, P2…Pn} such that the combined usage rules of this set can cover all of the user's sub-needs. This process is driven by a clear optimization objective: maximizing the overall fit while ensuring that the total cost does not exceed the user's budget. and minimize total cost This approach allows for flexible combinations of multiple packages to meet non-standard, personalized needs that cannot be satisfied by any single package (e.g., parking only on specific days of the week), significantly improving the coverage and success rate of matching. Using the example above, after breaking down the requirements, we found a "daytime package" (8:00-18:00, 15 yuan per day) and a "weekday package coupon pack" (20 coupons for 250 yuan). Through optimized calculations, we determined that purchasing one "coupon pack" plus two "daytime packages" could cover 22 days of needs, with a total cost of 280 yuan, which is below the 300 yuan budget. Therefore, this combination solution was successfully implemented.

[0071] In step S133, if neither the aforementioned precise matching nor combined matching produces an ideal solution that meets the preset cost and fit constraints, for example, if the total cost of the combined solution still exceeds the user's budget, or the overall fit is lower than the quality threshold, then the system initiates the final negotiation recommendation mechanism as the final guarantee path to ensure successful matching.

[0072] At this stage, instead of declaring a matching failure, a structured collaborative process is executed: First, the administrator information associated with the current best approximation result (i.e., the target package or combination scheme with the closest fit to the preset threshold) is obtained. This information originates from the parking lot management identifier defined in the package feature vector. Understandably, by mapping stored administrator information to administrator terminals, the target administrator terminal can be quickly located after obtaining the aforementioned administrator information. Subsequently, the user demand feature vector is intelligently fused with the current best approximation scheme to generate a structured customized demand proposal. This proposal clearly articulates the user's core needs, the gap in algorithm matching, and a clear customization suggestion (e.g., "Daytime parking space demand for 22 consecutive working days, current optimal combination cost 320 yuan, user budget 300 yuan, is a customized quote of 300 yuan acceptable?"). Then, this proposal is automatically and accurately pushed to the administrator terminals of one or more relevant parking lots via an asynchronous communication interface (such as a message queue). After receiving the proposal at the terminal, the parking lot management party (B-end) can directly provide a customized discount quote or a new package scheme based on its real-time resource status and operational strategy through the terminal. Ultimately, the system receives this feedback and treats it as a formal, direct-response candidate customized package, incorporating it into the subsequent normalization and ranking process. This mechanism constructs an intelligent collaborative channel from personalized long-tail demand from the user end (C-end) directly to the supply end (B-end) decision-making. It not only avoids ineffective resource broadcasting but also incentivizes B-end to provide flexible supply through structured information presentation, thereby achieving efficient and precise interaction between supply and demand. Using the above example, if the cost of the combined solution output in step S132 is 320 yuan (exceeding the 300 yuan budget), this negotiation recommendation mechanism will be triggered. It will generate a structured proposal such as "22 working days of daytime parking spaces, budget 300 yuan," and push it to the parking lot manager's terminal that provides "daytime packages" and "working day coupon packages." If the parking lot management agrees, it will provide a customized quote of 300 yuan through the terminal. This customized quote will be considered a new feasible solution and will participate in the generation of the final recommendation list along with the previous algorithmic solutions.

[0073] Finally, after processing in step S140, in step S150 the combination of "coupon package + 2-day pass" and possible customized quotes are returned to the client and recommended to the user.

[0074] Step S130 constructs a complete decision chain from automatic screening and intelligent combination to human-machine collaboration through a three-layer progressive matching strategy, ensuring that no matter how complex the user's needs are, a feasible solution can always be generated through at least one path, which greatly improves the matching flexibility, success rate and overall efficiency between parking resources and personalized needs.

[0075] Furthermore, in this embodiment, the customized packages generated through negotiation are highly time-sensitive and specific. They are typically generated based on the parking lot management's available resources and temporary pricing strategies at the time. If the user does not confirm the offer for an extended period, the offer may become invalid, and the parking space resources need to be released for other uses. Therefore, this embodiment introduces a time-based state machine. A valid window ("specified duration") is set for each customized package, and the user's purchase confirmation behavior is monitored. If the transaction is not completed within the time limit, its status is automatically set to invalid, meaning the product is removed from the platform. Understandably, when a customized package is returned to the client as a candidate, a generation timestamp is recorded for the package, and a countdown timer is started for that package. The system continuously listens for "purchase request" commands from clients for this specific customized package. If a purchase request is received before the countdown ends (a specified time), the process enters the order processing stage, and the package status can be marked as "sold out" or "locked." If no purchase request is received before the countdown ends (the default trigger condition), the system automatically performs a status update operation, marking the customized package's status field in the database as "discontinued," "expired," or "invalid," etc. It's worth noting that after being marked as discontinued, the package will be removed from the recommendation list of any activity and will no longer be visible to any user. The parking lot management can also see in their backend that the proposal has expired, and the corresponding parking space resources have been released back to the resource pool.

[0076] Combination Figure 2 As shown, the entire process begins in S1, where guided interaction is used to collect users' original needs, which are then parsed and quantified into a structured user need feature vector U. This transforms vague, personalized intentions into precise input that the machine can process. Simultaneously, in S2, features are extracted from all parking packages to form a standardized package feature vector P. This step lays a unified data foundation for all subsequent intelligent matching, fundamentally solving the initial problem of heterogeneous supply and demand information formats and the difficulty in direct computation.

[0077] This process employs a funnel-shaped filtering strategy in a three-layer progressive intelligent matching engine (S3a, S3b, S3c), attempting matching patterns of varying complexity layer by layer: The precise matching layer (S3a) acts as the first filter, performing efficient one-to-one screening. It calculates the instantaneous fit between vector U and each vector P using a quantization model and makes a judgment based on a preset quality threshold T1. This layer aims to quickly intercept and resolve routine needs that can be directly met by existing standardized packages, reflecting the optimization of algorithm efficiency.

[0078] The combined matching layer (S3b) is automatically activated after exact matching fails, and is used to handle discretized, non-standard, and complex requirements. The algorithm intelligently decomposes the overall requirement U into multiple sub-requirements, and then searches for the optimal set of packages S in the package pool using combinatorial optimization algorithms (such as cost minimization and fit maximization under constraints). The corresponding decision nodes in the diagram evaluate whether the combined solution is valid under the dual constraints of total cost not exceeding the budget and overall fit meeting the target. This layer breaks through the inherent limitations of a single package, enabling flexible resource splicing.

[0079] The negotiation and recommendation layer (S3c) is an extension and supplement to the automatic matching algorithm, and also the ultimate guarantee for ensuring the robustness of the system output. When the automated algorithm cannot find a solution within the preset constraints, the system does not terminate, but instead initiates a human-machine collaboration mechanism. It encapsulates the demand U and the current best approximate solution into a structured proposal and actively pushes it to the relevant parking lot management party (B-end). The final decision node in the flowchart is the confirmation of whether the B-end will provide a customized quote. This mechanism creatively opens up a channel for long-tail demand from the C-end to directly reach the B-end decision-making, activating the elastic response capability of the supply side.

[0080] Ultimately, all feasible solutions generated through different paths (whether it's a single item in S3a, a combination in S3b, or a customized quote in S3c) are converged into a unified output processing stage (S4). Here, all candidate solutions are normalized and globally ranked, ultimately generating a concise, comparable, and comprehensively optimal Top-N recommendation list, which is then fed back to the client in S5 for presentation to the user. This ensures that regardless of the path through which the need is met, the user receives a clear and consistent decision-making experience.

[0081] In summary, this process Figure 2 This application not only describes the sequence of parking package matching steps but also reveals the underlying paradigm: by establishing a standardized data representation (U / P vector), it constructs a flexible matching pipeline with automatic degradation capabilities, consisting of precise filtering, intelligent combination, and collaborative negotiation. This ensures the system can seamlessly cover the full spectrum of parking needs, from standardized to highly personalized solutions, consistently striving to output feasible solutions. At the technical implementation level, this perfectly supports the shift in business model from people searching for packages to packages searching for people, achieving a systematic improvement in resource utilization and user satisfaction.

[0082] Secondly, embodiments of this application provide a parking lot package matching device, combined with Figure 3 As shown, the device includes: a demand extraction module 10, a package extraction module 20, a resource matching module 30, a recommendation generation module 40, and an information feedback module 50.

[0083] The demand extraction module 10 is used to receive parking rental demand information input by the user in the user interface, and to perform structured processing on the parking rental demand information to obtain the user demand feature vector.

[0084] The package extraction module 20 is used to extract feature vectors from at least one package in the parking lot package resource library to obtain the package feature vectors corresponding to the package.

[0085] The resource matching module 30 is used to match at least one package from the parking lot package resource library based on the user demand feature vector and the package feature vector. The degree of fit between the package and the user demand feature vector is greater than a preset value.

[0086] The recommendation generation module 40 is used to normalize at least one package and generate recommendation results.

[0087] The information feedback module 50 is used to return the final recommendation results to the user interface.

[0088] Thirdly, embodiments of this application provide an electronic device, combined with Figure 4 As shown, the electronic device includes a memory 131 and a processor 130. The memory 131 stores a computer program, and the processor 130 runs the computer program to make the electronic device perform the above-described method.

[0089] Furthermore, combined Figure 4 The electronic device shown also includes a bus 132 and a communication interface 133, with the processor 130, the communication interface 133 and the memory 131 connected via the bus 132.

[0090] The memory 131 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 133 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 132 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0091] Processor 130 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 130 or by instructions in software form. Processor 130 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 131. The processor 130 reads the information from memory 131 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0092] Fourthly, embodiments of this application provide a readable storage medium storing computer program instructions, which are read and executed by a processor to perform the above-described method.

[0093] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0094] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0095] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0096] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0097] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for matching parking lot packages, characterized in that, The method includes: Receive parking rental request information input by the user in the user interface, and perform structured processing on the parking rental request information to obtain the user request feature vector; Extract feature vectors from at least one package in the parking package resource library to obtain the package feature vectors corresponding to the package; Based on the user demand feature vector and the package feature vector, at least one package is matched from the parking lot package resource library, and the degree of fit between the package and the user demand feature vector is greater than a preset value. Normalize the at least one of the packages to generate a recommendation result; The recommendation results are returned to the user interface.

2. The method according to claim 1, characterized in that, The parking rental demand information is structured to obtain a user demand feature vector, including: Extract the core parameters, preference parameters, and flexibility parameters from the parking rental demand information; The core parameters, the preference parameters, and the flexibility parameters are quantified into feature values ​​and combined to form the user demand feature vector. The core parameters include at least one of the following: target parking lot or area, expected rental period, and daily parking time. The preference parameters include at least one of the following: budget limit, parking space type preference, and parking lot brand preference; The flexibility parameters include at least one of the following: rental period adjustment range, parking time period fluctuation range, and acceptable alternative parking lot range.

3. The method according to claim 1, characterized in that, The steps of extracting feature vectors from at least one package in the parking package resource library to obtain the package feature vectors corresponding to the package include: Extract basic attribute parameters, usage rule parameters, and dynamic attribute parameters from the package; The basic attribute parameters, the usage rule parameters, and the dynamic attribute parameters are quantified into feature values ​​and combined to form the package feature vector; The basic attribute parameters include at least one of the following: package identifier, package type, price, and validity period; The usage rule parameters include at least one of the following: applicable time period, applicable date, parking space type, and sharing attribute; The dynamic attribute parameters include at least one of inventory balance, historical sales volume, and package flexibility score. The package flexibility score is used to characterize the parking lot's willingness to adjust the price or rules of the package.

4. The method according to claim 1, characterized in that, Normalize at least one of the aforementioned packages to generate recommendation results, including: The at least one of the aforementioned packages is standardized and converted to obtain a recommended package; For each of the recommended packages, a comprehensive score is calculated based on a preset unified scoring model to obtain the comprehensive score of the recommended package; Based on the order of merit of the solutions represented by the comprehensive score, all the recommended packages are sorted. Select the top-ranked recommendation schemes to generate the final recommendation result list; Each recommended solution in the recommendation result list includes the total price, the amount saved relative to the original price, and information on its suitability for the user's needs.

5. The method according to any one of claims 1-4, characterized in that, Based on the user demand feature vector and the package feature vector, at least one package is matched from the parking package resource library, including: Based on the user demand feature vector, at least one target package is matched from the parking package resource library using the first matching rule; Based on the user demand feature vector, at least one target combination package is matched from the parking lot package resource library using the second matching rule; If neither the first matching rule nor the second matching rule matches a corresponding package, the target package and / or target combination package with the closest fit to the preset value is sent to the administrator terminal, and the customized package information returned by the administrator terminal is received.

6. The method according to claim 5, characterized in that, The first matching rule includes: matching the user demand feature vector with the package feature vector of a single package one by one to determine at least one target package with a fit greater than a preset value; The second matching rule includes: decomposing the user demand feature vector into several sub-feature vectors, matching the sub-feature vectors with the package feature vectors of multiple packages, and determining at least one target combination package with a fit greater than a preset value.

7. The method according to claim 6, characterized in that, The step of sending the target package and / or target combination package with the closest fit to the preset value to the administrator terminal includes: Obtain the administrator information configured in the target package and / or target combination package, and send the target package and / or target combination package and the parking rental demand information to at least one administrator terminal corresponding to the administrator information.

8. A parking lot package matching device, characterized in that, The device includes: The demand extraction module is used to receive parking rental demand information input by the user in the user interface, and to perform structured processing on the parking rental demand information to obtain the user demand feature vector. The package extraction module is used to extract feature vectors from at least one package in the parking package resource library to obtain the package feature vectors corresponding to the package. The resource matching module is used to match at least one package from the parking lot package resource library based on the user demand feature vector and the package feature vector, wherein the degree of fit between the package and the user demand feature vector is greater than a preset value. The recommendation generation module is used to normalize the at least one of the packages and generate recommendation results; The information feedback module is used to return the recommendation results to the user interface.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program and the processor running the computer program to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-7.

Images