A vehicle sharing transaction system

Abstract

The application relates to the technical field of vehicle source transaction, and aims to provide a vehicle source sharing transaction system, which comprises a data layer used for receiving and storing vehicle static attribute data and dynamic state data; a vehicle source value evaluation module used for executing a multi-dimensional weighted evaluation algorithm and outputting a dynamically updated vehicle source real-time value score; a user demand analysis engine used for extracting a demand feature vector from a vehicle use request; a bidirectional matching and game negotiation module used for carrying out a similarity clustering operation and calling a non-cooperative game negotiation model to generate a negotiated price; a sharing contract generation module used for generating a structured digital contract and triggering smart contract execution; a sharing permission management module used for distributing digital keys with different operation permission levels; a state synchronization and monitoring module used for monitoring operation behavior in real time and performing consistency checking; and an electronic settlement and evaluation module used for automatically deducting and receiving bidirectional anonymous evaluation.

Description

Technical Field

[0001] This invention relates to the field of vehicle source trading technology, and in particular to a vehicle source sharing and trading system. Background Technology

[0002] With the deepening development of the sharing economy and the continued acceleration of urbanization, the number of private cars has been increasing year by year. However, at the same time, a large number of private cars exhibit significant idle time characteristics in daily use. According to industry statistics, the average daily idle time of private cars usually exceeds 20 hours, and the utilization rate of vehicle resources has long been at a low level. In contrast, the demand for on-demand vehicle use services from people without cars and those who need temporary transportation continues to grow. This supply and demand contradiction has given rise to car sharing and trading platforms; however, existing technologies still have many shortcomings in achieving efficient, safe, and fair car sharing and trading.

[0003] Several technical solutions involving vehicle sharing or vehicle resource trading have been proposed in existing publicly available patent literature. For example, Chinese invention patent application CN1084279A (publication date: March 23, 1994) discloses a high-voltage megohmmeter with delayed short-circuit protection. This patent belongs to the field of electronic measuring instruments and has no technical relevance to vehicle sharing and trading, thus not constituting relevant prior art. More recent related technologies include Chinese invention patent application CN106228428A (publication date: December 14, 2016), which discloses a cloud management system and method for used car transactions. This solution integrates the scattered car brokerage market, connecting the information of buyers and sellers through a cloud server to achieve information-based management of used car transactions. However, this solution mainly targets one-time used car transactions, with the system's core focusing on information dissemination and matching. It cannot meet the transaction needs of dynamic sharing of vehicle usage rights over time and lacks effective perception of real-time vehicle status and a dynamic pricing mechanism.

[0004] The existing technologies have the following main technical defects: (1) The static characteristics of vehicle source information are obvious, and there is a lack of dynamic perception and integration of evaluation mechanism for real-time vehicle status (such as location, working condition, and occupancy status); (2) The evaluation method of vehicle source value is single and lagging, and cannot be dynamically corrected according to supply and demand changes, environmental conditions and time factors; (3) Demand analysis is limited to keyword matching, and lacks deep semantic understanding of user natural language input, resulting in insufficient matching accuracy; (4) The negotiation mechanism adopts fixed pricing or simple bidding mode, and lacks intelligent negotiation model based on game theory, making it difficult to achieve the optimal balance of interests between the two parties; (5) The permission management is mainly based on account password, which cannot achieve refined hierarchical authorization of permissions, and there are security risks in the permission transfer process; (6) Contract execution and status synchronization rely on centralized servers, and the data transparency and immutability are insufficient, making it difficult to trace transaction disputes; (7) The system architecture generally adopts a stacked design of functional modules, with loose coupling between modules and low data flow efficiency, making it difficult to achieve organic collaboration of the entire chain from vehicle source release, intelligent matching, dynamic negotiation to permission delivery.

[0005] Therefore, there is an urgent need to propose a vehicle resource sharing and trading system that can overcome the above-mentioned technical defects, realize dynamic perception of vehicle resource information, real-time assessment of vehicle resource value, deep semantic analysis of demand, intelligent negotiation based on game theory, hierarchical permission management, and secure performance based on smart contracts. Summary of the Invention

[0006] The purpose of this invention is to provide a vehicle resource sharing and trading system to address the aforementioned technical deficiencies in the prior art.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A vehicle resource sharing and trading system includes the following components.

[0008] The data layer is configured to receive and store vehicle static attribute data and dynamic status data from at least one vehicle owner's terminal, wherein the dynamic status data includes vehicle location information, time occupancy status information, and vehicle operating condition data collected in real time by on-board sensing devices.

[0009] The vehicle source value assessment module is configured to use the vehicle's static attribute data and dynamic status data as input parameters, execute a multi-dimensional weighted assessment algorithm, and output a real-time vehicle source value score that is dynamically updated over time.

[0010] The user demand parsing engine is configured to obtain car usage requests from at least one demand side, and extract demand feature vectors containing spatiotemporal constraints and car usage preferences from the car usage requests based on natural language processing technology.

[0011] The two-way matching and game-theoretic negotiation module is configured to map the real-time value score of the vehicle source and the demand feature vector to the same multi-dimensional feature space for similarity clustering operation, generate a candidate vehicle source list, and for each candidate vehicle source in the candidate vehicle source list, call a non-cooperative game-theoretic negotiation model to simulate the multi-round strategy interaction between the car owner and the demand side in the bidding space to generate negotiated pricing.

[0012] The shared contract generation module is configured to automatically generate a structured digital contract containing the vehicle usage period, price terms, and usage scope when the negotiated pricing is accepted by both parties, and trigger the execution of a blockchain-based smart contract.

[0013] The sharing permission management module is configured to distribute digital keys with different operation permission levels to the vehicle owner terminal and the sharing user terminal respectively during the execution of the smart contract. The digital keys are used to control access to the target vehicle's door opening, engine starting, and vehicle function groups.

[0014] The status synchronization and monitoring module is configured to monitor the operation behavior of the sharing terminal on the target vehicle in real time, and perform consistency verification with the execution status of the smart contract. If the verification is inconsistent, an alarm mechanism is triggered.

[0015] The electronic settlement and evaluation module is configured to trigger an automatic deduction operation based on the actual usage time and additional fees after the smart contract is fulfilled, and to receive two-way anonymous evaluations from the car owner's terminal and the sharing terminal.

[0016] Preferably, the vehicle source value assessment module further includes a condition-triggered score correction submodule, which is configured to monitor external environmental condition data and seasonal time factors. When the external environmental condition data or seasonal time factors meet preset correction conditions, the real-time value score of the vehicle source is subject to a one-time incremental correction and the corrected score is output. The weight coefficients of the multi-dimensional weighted assessment algorithm are periodically adjusted based on historical transaction data through regression analysis.

[0017] Preferably, the sharing permission management module is configured to generate at least two operation permission levels: the first permission level grants the operation permissions of unlocking the car door and starting the vehicle, but does not include access permissions for the in-vehicle entertainment system; the second permission level grants access permissions for all in-vehicle functions; the sharing permission management module also includes a timeliness constraint unit, which limits the validity period of the digital key to the end time of the vehicle usage right period, and the digital key automatically expires after the end time.

[0018] Preferably, the status synchronization and monitoring module is configured with a deviation detection unit, which calculates in real time the deviation distance between the actual driving trajectory of the target vehicle and the driving area agreed in the vehicle use request. When the deviation distance exceeds a preset threshold, a deviation alarm is generated and reported to the vehicle owner. The status synchronization and monitoring module is also configured to compare the vehicle operating condition data collected in real time by the vehicle-mounted sensing device with the standard operating condition parameters recorded in the vehicle static attribute data. When an abnormal operating condition event is detected, a temporary restriction command is triggered. The temporary restriction command is used to restrict further operations of the shared terminal on the target vehicle.

[0019] Preferably, the non-cooperative game negotiation model in the bidirectional matching and game negotiation module adopts the discrete-time version of the Rubinstein bargaining model, and sets a maximum upper limit for the number of negotiation rounds. In each round of negotiation, the non-cooperative game negotiation model dynamically outputs a suggested price based on the real-time value score of the vehicle source in the current round and the bidding history of the demand side. When the number of negotiation rounds reaches the maximum upper limit for negotiation rounds, the system automatically closes the current session and releases the corresponding vehicle source in the candidate vehicle source list.

[0020] Preferably, the system further includes a vehicle source status prediction module, which is configured to predict the availability probability of the target vehicle within a future time window based on the vehicle's static attribute data and historical dynamic status data, and push the prediction results to the two-way matching and game negotiation module to optimize the sorting of the candidate vehicle source list.

[0021] Preferably, the system also includes a shared contract transfer module, which is configured to receive a contract transfer request from the shared user terminal, find a third-party transferee terminal within the vehicle usage right period corresponding to the structured digital contract, and when the vehicle owner agrees and the third-party transferee terminal accepts the inheritance conditions of the negotiated pricing, transfer the rights and obligations of the structured digital contract to the third-party transferee terminal in their entirety, and simultaneously update the digital key allocation in the shared permission management module.

[0022] Preferably, the user demand parsing engine further includes a semantic disambiguation unit, which is configured to perform contextual relevance analysis on fuzzy words in the car use request based on a preset car terminology knowledge graph, and generate a disambiguated demand feature vector; the car terminology knowledge graph includes the classification hierarchy relationship of vehicle brand, model, body color, interior configuration, power type and vehicle age, as well as the synonym mapping relationship.

[0023] Preferably, the blockchain-based smart contract is deployed in a consortium blockchain or public blockchain environment, and the structured digital contract is anchored in the blockchain in the form of cryptographic hashes. Any modification to the execution state of the smart contract by any participating node must be confirmed by the consensus mechanism and then synchronized to all authorized nodes.

[0024] As an improvement, the beneficial effects of the present invention are as follows: (1) By integrating and storing the static attributes and dynamic states of vehicles through the data layer, the full-dimensional and real-time perception of vehicle source information is realized, overcoming the defects of static vehicle source information in the existing technology. (2) The vehicle value assessment module introduces a multi-dimensional weighted assessment algorithm and combines external environmental conditions and seasonal factors with condition-triggered correction to output a real-time value score that is dynamically updated over time, making the assessment of vehicle value more accurate and the response more sensitive. (3) The user demand parsing engine is based on natural language processing and semantic knowledge graph, which realizes deep semantic understanding of users' natural language car use requests, and improves the accuracy of demand extraction and matching precision. (4) The two-way matching and game negotiation module maps the value score and demand feature vector to a multi-dimensional feature space for similarity clustering, and then calls the non-cooperative game negotiation model to simulate multiple rounds of strategy interaction. It abandons the traditional fixed pricing or simple bidding mode and achieves the optimal balance of interests between the two parties. (5) The sharing permission management module distributes digital keys with different operation permission levels to realize fine-grained hierarchical authorization of vehicle doors, engine and vehicle function groups. The time-limited constraint unit ensures that the key automatically expires after the agreed time period ends, fundamentally eliminating the security risks in the permission transfer process. (6) The status synchronization and monitoring module realizes full monitoring of sharing and use and real-time response to anomalies through deviation detection and comparison of working conditions. The consistency verification mechanism with the execution status of smart contracts ensures the transparency and traceability of transactions. (7) The organic linkage between the shared contract generation module and the blockchain smart contract ensures that any modification to the contract execution status must be confirmed by consensus before it can take effect, which greatly improves the immutability of data and the traceability of transaction disputes. (8) The data flow and instruction flow between the above modules form a complete closed loop from vehicle source release, dynamic evaluation, semantic parsing, intelligent matching, game negotiation, contract generation, permission allocation to performance monitoring. The various technical features support each other and work together, rather than simply listing or superimposing functions, and together realize the organic collaboration of the entire link of vehicle source sharing transactions. Attached Figure Description

[0025] Figure 1 This is a block diagram of the overall structure of the present invention; Detailed Implementation

[0026] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings. Identical components are indicated by the same reference numerals. It should be noted that the terms "front," "rear," "left," "right," "up," and "down" used in the following description refer to directions in the accompanying drawings, while the terms "inner" and "outer" refer to directions toward or away from the geometric center of a specific component, respectively.

[0027] To make the content of this invention easier to understand, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Identical components are indicated by the same reference numerals.

[0028] This embodiment provides a complete implementation of a vehicle resource sharing and trading system.

[0029] Example 1 I. System Overall Architecture The vehicle resource sharing and trading system in this embodiment adopts a distributed microservice architecture and is deployed in a cloud server cluster. The system is divided into five logical layers: access layer, business logic layer, data storage layer, blockchain layer, and terminal layer. The access layer is responsible for load balancing and secure SSL / TLS termination of HTTPS requests from vehicle owners and sharing terminals. The business logic layer deploys the core functional modules of this invention, including a vehicle value assessment module, a user demand analysis engine, a two-way matching and game negotiation module, a sharing contract generation module, a sharing permission management module, a status synchronization and monitoring module, an electronic settlement and evaluation module, a vehicle status prediction module, and a sharing contract transfer module. The data storage layer includes a relational database (for storing user account information, transaction history, and vehicle static attribute data) and a time-series database (for storing dynamic status data such as vehicle location and operating condition data in time series). The blockchain layer runs a smart contract environment; in this embodiment, the Ethereum public chain is selected as the underlying execution environment for smart contracts. The terminal layer includes a vehicle owner mobile application and a sharing terminal mobile application. Both communicate with the cloud server via API and establish a near-field connection with the vehicle's in-vehicle communication unit via Bluetooth / BLE to obtain digital keys and perform door unlocking and engine start operations.

[0030] II. Specific Implementation of Each Module 2.1 Data Layer The data layer receives vehicle static attribute data and dynamic status data from the vehicle owner's client. Vehicle static attribute data includes, but is not limited to: Vehicle Identification Number (VIN), brand, model, body color, interior configuration, powertrain type (gasoline / pure electric / hybrid / hydrogen fuel cell), transmission type (manual / automatic / automatic / CVT / DCT), number of seats, manufacturing date, first registration date, mileage, maintenance records, repair history, vehicle registration certificate information (including ownership and mortgage status), vehicle insurance information (insurance type, coverage amount, and validity period), and emission standards. This static attribute data is entered through the vehicle owner's client application when the vehicle is first registered and, after system review, is stored in the vehicle information table of the relational database.

[0031] Dynamic status data includes: real-time vehicle location information (reported every 30 seconds via the onboard GPS module), time occupancy status information (divided into five states: "idle," "pending confirmation," "reserved," "in use," and "under maintenance"), and real-time vehicle operating condition data collected by onboard sensing devices. Vehicle operating condition data is collected through an intelligent onboard terminal connected via the onboard OBD (On-Board Diagnostics) interface. This terminal has a built-in 4G / 5G communication module and embedded processor, and collects and reports the following data to the cloud in real time: engine speed, vehicle speed, coolant temperature, fuel level / remaining battery charge (SoC), instantaneous fuel consumption / electricity consumption, tire pressure, fault codes (DTC), accelerator pedal opening, brake pedal opening, steering wheel angle, interior temperature, and air conditioning set temperature. The OBD data acquisition frequency can be dynamically adjusted according to the vehicle's motion status: when the vehicle speed is >0km / h, the acquisition frequency is increased to 1 second / time; when the vehicle speed is 0km / h and the engine is running, the acquisition frequency is 5 seconds / time; when the vehicle is completely turned off and stationary, the acquisition frequency is reduced to 60 seconds / time to save communication traffic and terminal power consumption.

[0032] 2.2 Vehicle Source Value Assessment Module The vehicle value assessment module takes vehicle static attribute data and dynamic status data as input parameters, executes a multi-dimensional weighted assessment algorithm, and outputs a real-time vehicle value score that is dynamically updated over time. In this embodiment, the assessment model is as follows: Let the real-time value score of vehicle resources be V(t) = Σ(w_i × f_i(t)) + Δ(t) + ε(t). Where w_i is the weight coefficient of the i-th dimension, f_i(t) is the feature score of the i-th dimension at time t, Δ(t) is the conditional trigger correction, and ε(t) is the random error term.

[0033] The feature dimension includes six sub-dimensions: (1) Vehicle brand premium index (calculated based on brand market awareness, residual value curve and brand complaint rate, with a value range of 0 to 100). (2) Vehicle condition index (based on the ratio of mileage to the standard value of annual mileage, the completeness and compliance of maintenance records, the number and severity of fault codes, the types of accidents in the repair history and the quality of repairs, with a value range of 0 to 100). (3) Dynamic performance index (calculated based on dynamic indicators such as the comparison of engine speed and vehicle speed in real time, the deviation of instantaneous fuel consumption / electricity consumption from the standard energy consumption of the same model, and tire pressure balance, with a value range of 0 to 100). (4) Location accessibility index (calculated based on the reciprocal of the distance between the vehicle's GPS coordinates and urban transportation hubs, subway stations, and large residential communities, and the normalized density of similar vehicles in the surrounding area, with a value range of 0 to 100). (5) Cleanliness and comfort index (calculated based on the readings of the in-vehicle air quality sensor collected by the vehicle sensing equipment, the foreign object residue detected by the seat sensor, the life of the air conditioning filter, etc., with a value range of 0 to 100). (6) Historical transaction rating index (calculated by weighting the vehicle’s historical transaction evaluation score, transaction completion rate and dispute rate in the system, with a value range of 0 to 100).

[0034] The initial values ​​for the six feature scores are calculated when the vehicle owner completes vehicle registration, and are subsequently updated dynamically. The vehicle brand premium index and vehicle condition index are updated incrementally on a weekly basis; the dynamic performance index is updated on a 15-minute basis; the location accessibility index is updated every 5 minutes; the cleanliness and comfort index is triggered by the shared user terminal rating the in-vehicle environment through the application interface after each vehicle use, and the onboard air quality sensor also continuously records during the use period, and the two are combined to generate the updated score after that use; the historical transaction rating index is updated immediately after each transaction is completed.

[0035] The weighting coefficients w_i are not fixed constants. The system is equipped with a weight self-learning engine, which extracts sample data of completed transactions (including feature scores for each dimension and the final transaction price) from the historical transaction database each month. Multiple linear regression analysis is used, with the logarithm of the transaction price as the dependent variable and the feature scores for each dimension as independent variables, to recalculate the weighting coefficients for each dimension. The regression analysis employs LASSO (Least Absolute Shrinkage and Selection Operator) regularization, which ensures the model's prediction accuracy while performing feature selection, automatically eliminating dimensions that do not significantly contribute to transaction price prediction and avoiding overfitting.

[0036] The condition-triggered scoring correction submodule monitors external environmental conditions and seasonal time factors.

[0037] External environmental condition data includes: Real-time weather data (obtained by calling a third-party weather API to retrieve temperature, humidity, precipitation probability, wind speed, air quality index (AQI), and PM2.5 concentration at the target vehicle's location); Traffic congestion index (obtained by calling the real-time traffic API of the map service provider to get the traffic index around the vehicle). Holiday information (marking of statutory holidays, adjusted workdays, and off-peak / peak periods before and after holidays).

[0038] Seasonal time factors include month (the impact of different months on travel demand), day of the week (significant differences in car usage patterns between weekday evenings and weekends), and time of day (morning peak 6:00-9:00, daytime off-peak 9:00-17:00, evening peak 17:00-20:00, and nighttime 20:00-6:00 the next day).

[0039] When any of the above conditions meet the preset correction threshold, the condition-triggered scoring correction submodule performs a one-time incremental correction on the real-time value score of the vehicle source.

[0040] For example: when the probability of precipitation is ≥70%, V(t) increases by 5% (the demand for shelter from enclosed vehicles increases during rainy weather, thus increasing its value); when AQI>150, V(t) increases by 3% (driving is relatively more attractive than public transportation when air pollution is high); during statutory holidays (3:00 PM the day before the holiday to 6:00 PM the last day of the holiday), V(t) increases by 15%; during weekday morning rush hour (7:00-9:00), V(t) increases by 8%. The above correction coefficients can be accumulated, but the maximum single correction is 30%, and the recalculated V(t) after conditional correction will be pushed to the two-way matching and game negotiation module in an event-triggered manner.

[0041] 2.3 User Requirement Analysis Engine The user demand analysis engine obtains car rental requests from the demand side. Users on the demand side input their car rental requests via a mobile application in natural language text or speech-to-text format, for example: "I want to rent a white SUV between 3 pm on Saturday and 11 am on Sunday, preferably with a panoramic sunroof, with a budget of 300 to 400 yuan per day, for taking my family on a trip to the suburbs. I hope the car is in good condition and preferably has a child safety seat interface." After the natural language request is sent to the user request parsing engine, the engine first performs word segmentation and part-of-speech tagging. Then, based on the BERT (Bidirectional Encoder Representations from Transformers) prediction language model, it performs semantic encoding on the segmented sentence and outputs a semantic vector. The semantic vector is then fed into three parallel sub-parsers: a spatiotemporal constraint parser, a preference parser, and a budget parser.

[0042] The spatiotemporal constraint parser extracts the constraints in the time and space dimensions: it parses the start timestamp T_start and end timestamp T_end from "between 3 pm on Saturday and 11 am on Sunday"; it infers the usage scenario and possible driving area from "going on a trip" combined with the user's usual address and historical car usage records, and then generates a list of recommended pick-up and drop-off locations.

[0043] The preference parser performs disambiguation and classification on the extracted preference terms based on a pre-defined knowledge graph of car-related terms. This knowledge graph is constructed as follows: Organized around a conceptual hierarchy, the top level is "Vehicle," and the next level is divided into major categories such as "Brand," "Model," "Body Type," "Powertrain Type," "Configuration," "Vehicle Condition," and "Scenario." Taking "Body Type" as an example, its lower level includes nodes such as "Sedan," "SUV," "MPV," "Sports Car," "Pickup Truck," and "Convertible." The "SUV" node is further divided into "Compact SUV," "Mid-size SUV," "Large SUV," "Large SUV," "Coupe SUV," and "Rugged Off-road SUV." The "Configuration" category includes nodes such as "Heated Seats," "Ventilated Seats," "Panoramic Sunroof," "Regular Sunroof," "Cruise Control," "Adaptive Cruise Control," "Reversing Camera," "360-degree Panoramic Camera," "Power Tailgate," and "Child Safety Seat Interface." Each node is connected by various types of semantic relationships: "is-a" relationship (e.g., "Panoramic Sunroof" is-a "sunroof"), "part-of" relationship (e.g., "Leather Seats" part-of "Interior"), and "synonym" relationship (e.g., "sunroof" and "sunroof" are synonym mappings).

[0044] The semantic disambiguation unit matches the words in the user request with the knowledge graph nodes using the shortest path and contextual attention weighting. It matches "SUV" to the mid-size SUV node, "panoramic sunroof" to the corresponding configuration node, and quantifies "better vehicle condition" as a hard constraint of a vehicle condition index ≥ 85.

[0045] The budget parser extracts the daily unit price range [300, 400] yuan from "300 to 400 yuan per day". Then, combined with the usage time extracted by the time and space constraint parser (a total of 20 hours from Saturday 15:00 to Sunday 11:00), it automatically calculates the total budget range: 300×(20 / 24)=250 yuan to 400×(20 / 24)≈333 yuan, which is rounded to get the range [250, 333] yuan.

[0046] The outputs of the three sub-parsers are merged into a 12-dimensional demand feature vector F_demand. The definition of each dimension corresponds to the dimension of the feature component in the vehicle source value assessment module, but the meanings are different: F_demand[1]~F_demand[6] represent the expected weight values ​​of brand premium index, vehicle condition index, dynamic performance index, location accessibility index, cleanliness and comfort index and historical transaction rating index respectively (normalized to 0~1, and the weighted sum is 1); F_demand[7]~F_demand[9] represent the start and end time windows T_start, T_end and elastic tolerance interval Δt (hours) respectively; F_demand

[10] ~F_demand

[12] represent the lower limit P_min, upper limit P_max of the price expectation interval and the user credit score (calculated based on the historical transaction behavior and payment records in the system, with a value range of 0~1000 points).

[0047] 2.4 Two-way matching and game-theoretic negotiation module The bidirectional matching and game-theoretic negotiation module maps the real-time value score of vehicle sources and the demand feature vector to the same multi-dimensional feature space for similarity clustering operations. This embodiment adopts a hybrid similarity measurement method combining cosine similarity and weighted Euclidean distance. Specifically, for each vehicle source i, its vehicle source feature vector F_vehicle[i] = [V_i(t), w_brand_i, w_condition_i, w_performance_i, w_location_i, w_clean_i, w_rating_i] is defined, where V_i(t) is the real-time value score of the vehicle source, and w_brand_i to w_rating_i are the actual scores of each dimension of the vehicle source, respectively. The demand feature vector F_demand is as described above. The system calculates the comprehensive matching score S_match[i] = α × cosine_similarity(F_vehicle[i]_norm, F_demand[1:6]) + (1-α) × (1-weighted_euclidean_distance(F_vehicle[i]_norm, F_demand[1:6])), where α is a configurable weight coefficient (0.5 in this embodiment), F_vehicle[i]_norm is the vector of the first 6 dimensions of F_vehicle[i] after L2 normalization, and F_demand[1:6] is the first 6 dimensions of the demand feature vector. Based on the comprehensive matching score, the top 10 vehicle sources are sorted from highest to lowest and selected as the candidate vehicle source list L_candidate. During the sorting process, spatiotemporal constraints are used as hard filtering conditions: if the time occupancy status of vehicle source i is not "idle" or "booked" in the interval [T_start, T_end], and there is a conflict in the time period where the vehicle owner has not yet confirmed the occupancy, then the vehicle source is directly removed from the candidate list.

[0048] After generating the candidate vehicle source list, the module initiates an independent game negotiation session for each candidate vehicle source i. The non-cooperative game negotiation model adopts a discrete-time version of the Rubinstein Bargaining Model, setting a maximum upper limit of N_max=5 negotiation rounds. Each round of negotiation proceeds in an alternating bidding manner: demand side bids → vehicle owner responds → system calculates the gap and provides a notification.

[0049] In the k-th round of negotiation (k=1,2,3,4,5), the model dynamically outputs a suggested price based on the real-time vehicle value score V_i(t) of the current round and the set of historical bids from the demand side H={b_1, b_2, …, b_{k-1}}. If k=1, the system automatically generates an initial suggested price of V_i(t)×1.02 (i.e., 102% of the real-time vehicle value score), which is displayed to the demand side as the recommended starting price. Simultaneously, a reference price range [V_i(t)×0.92, V_i(t)×1.05] is sent to the vehicle owner. The demand side can freely bid within ±15% of this suggested price. After receiving the bid, the vehicle owner can choose one of three responses: "accept," "reject and submit a counter-offer," or "abandon." If "Reject and Offer a Counter-Offer" is selected, the module automatically calculates the equilibrium counter-offer under the discount factor: p_counter = V_i(t) × (1 - δ_owner × δ_demand) + δ_demand ×b_demand, where δ_owner and δ_demand are the discount factors for the car owner and demand side, respectively (reflecting patience levels, ranging from 0 to 1, dynamically calculated by analyzing users' historical negotiation behavior data), and b_demand is the demand side's offer in this round. When the negotiation rounds reach N_max=5, if the two parties still have not reached an agreement, the system automatically closes the current session and releases the car from L_candidate.

[0050] 2.5 Shared Contract Generation Module Once the negotiated price is accepted by both parties, the sharing contract generation module automatically generates a structured digital contract containing the vehicle usage period (accurate to the minute, in ISO 8601 standard format), price terms (including basic rental fee, platform service fee (3-5% of basic rental fee, dynamically calculated), overtime fee (charged per minute after the agreed return time, at a rate of 1.5 times the basic hourly rate), cleaning fee (automatically deducted if the vehicle's interior cleanliness score is lower than the system-set threshold upon return, the threshold being determined by the 15th percentile of the historical cleanliness score distribution), and usage permission scope (first permission level or second permission level). The structured digital contract is organized in JSON Schema format, with key fields including: contract_id (a unique 32-bit UUID generated by the system), created_at (ISO 8601 standard), and other relevant fields. The contract includes 8601 timestamps, owner_id, demoander_id, vehicle_id, start_time, end_time, base_price, service_fee, overtime_rate_per_minute, clean_deposit (cleaning deposit), and permission_level. After contract generation, it is simultaneously sent to both parties' terminals for electronic signature confirmation. The signature uses the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm based on asymmetric encryption. The private key is stored in a secure area on the user's terminal, and the public key is anchored to the blockchain for verifying signature validity.

[0051] After both parties complete the electronic signature, the system triggers the execution of the smart contract deployed on the Ethereum public chain. The smart contract is deployed as follows: the system pre-compiles a standardized smart contract template (written in Solidity), which includes the following methods: `createContract()` (creates a contract instance based on the input contract parameters), `acceptContract()` (both parties confirm acceptance of the contract terms), `releaseCar()` (sends an event to the shared permission management module to release vehicle permissions), `recordUsage()` (records changes in vehicle status during use), `settlePayment()` (executes the settlement operation), and `transferContract()` (transfers the contract). After confirmation by both parties, the system calls the deployer account to execute the `createContract()` method, passing in the structured digital contract parameters of this transaction in the form of `calldata`. After the contract instance is successfully created, it returns the transaction hash value of the contract on the Ethereum mainnet. This hash value is synchronized to the system's relational database via API for subsequent querying and auditing.

[0052] The execution state of smart contracts is strictly recorded in the Ethereum Virtual Machine (EVM). Any modification to the execution state of a smart contract by any participating node must be confirmed by the Ethereum network's consensus mechanism based on Proof-of-Work or Proof-of-Stake before it can be synchronized and the state root updated on all full nodes. State fields include: contract state (0 - pending signing, 1 - signed and awaiting fulfillment, 2 - fulfilling, 3 - fulfilled and awaiting settlement, 4 - completed, 5 - cancelled, 6 - under dispute), current elapsed time (minutes), accumulated timeout fees (cents), cleanup fee deduction flag (true / false), and dispute flag (dispute_flag). All authorized nodes in this system (including cloud server nodes, some advanced user nodes, and regulatory nodes) obtain the latest version of the contract state by periodically synchronizing block headers.

[0053] 2.6 Sharing Permission Management Module At the start of smart contract execution (i.e., start time T_start), the sharing permission management module distributes digital keys with different operation permission levels to both the vehicle owner and the sharing terminal. The digital keys employ a passwordless authentication system based on WebAuthn, conforming to the FIDO2 standard protocol. The key generation process is as follows: The system generates a 256-bit random number as a session seed. This seed is concatenated with the contract ID and then hashed using SHA-256 to generate the master key MK. The master key is then extended using an HMAC-based Key Derivation Function (HKDF) to derive two subkeys: K_owner and K_demander. K_owner is stored in the TEE (Trusted Execution Environment) of the vehicle owner's mobile application; K_demander is sent to the sharing terminal via an end-to-end encrypted channel.

[0054] This digital key is used to control access to the target vehicle's doors, engine start, and in-vehicle functions. The implementation is as follows: The target vehicle is pre-installed with an intelligent in-vehicle control unit (IVT). This IVT connects to the door lock drive circuit, engine control unit (ECU), and in-vehicle infotainment system (IVI) via the vehicle's CAN (Controller Area Network) bus. The IVT has a built-in security chip storing a pre-authorized system public key. When the sharing terminal approaches the target vehicle and establishes a Bluetooth connection with the IVT, it sends an unlock command packet encrypted with K_demander to the IVT. The IVT decrypts the packet using the stored system public key, verifies the signature validity, and then sends an unlock signal to the door lock drive circuit via the CAN bus, simultaneously recording the unlock timestamp and uploading it to the cloud.

[0055] This embodiment configures two levels of operational permissions: The first permission level (standard level) grants access to unlocking the doors and starting the vehicle, but excludes access to the in-vehicle entertainment system (navigation, music playback, Bluetooth phone, app store, etc.). At the first permission level, after unlocking the doors and allowing engine start, the control unit simultaneously sends a "restricted mode" command to the IVI system via the CAN bus. Upon receiving the command, the IVI system activates a guest mode interface, displaying only basic vehicle information (speed, fuel / battery level, mileage) and the emergency call button; all modules involving personal privacy and paid content are disabled. The second permission level (full-function level) grants access to all in-vehicle functions. The control unit sends a "full mode" command to the IVI system, and the IVI system restores all functional modules.

[0056] The sharing permission management module also includes a time-limited constraint unit. This unit continuously runs in the system cloud and maintains a timer that starts counting from T_start. It combines this timer with the engine running time collected in real-time from the vehicle's CAN bus to determine whether the contracted usage period has been exceeded. Once the current clock time exceeds T_end, the time-limited constraint unit automatically pushes a key expiration notification to the sharing terminal and simultaneously sends a remote locking command to the vehicle control unit via the cloud. This command is preferentially sent via the 4G / 5G network; if the vehicle is in a 4G / 5G signal dead zone, the control unit will autonomously execute the locking based on the offline locking timestamp negotiated during the last Bluetooth connection (i.e., the windows were negotiated to be locked at T_end). After the termination time, the digital key automatically expires, and any unlocking command generated using K_demander will be rejected by the control unit. If the user is still driving after T_end, the vehicle's dashboard will continuously display an overtime warning message and emit a prompt sound every 30 seconds, but will not force the vehicle to stop to ensure driving safety. However, the overtime fee will continue to accumulate per minute until the vehicle is completely turned off and locked.

[0057] 2.7 Status Synchronization and Monitoring Module The state synchronization and monitoring module runs continuously during the execution of the smart contract, monitoring the shared terminal's operations on the target vehicle in real time and verifying consistency with the smart contract's execution status. Specifically, the module acquires information through two data channels: one is vehicle operating condition data (engine speed, vehicle speed, location, mileage, etc.) reported once per second by the vehicle's OBD terminal; the other is user operation behavior logs (including unlock / lock time, engine start / stop time, navigation destination input records, etc.) reported by the shared terminal's mobile application. The module's built-in consistency verification engine performs real-time cross-validation of the two data sources. When inconsistencies are detected (e.g., the reported vehicle speed is not 0 but the shared terminal has no operational behavior, or there is no engine start record for a long time after unlocking and the vehicle's location has not moved), an alarm is immediately triggered. The alarm message is sent to the vehicle owner's terminal in the form of a push notification, and a high-priority abnormal event record is generated in the system.

[0058] The state synchronization and monitoring module is equipped with a deviation detection unit, which calculates the deviation distance based on GPS trajectory data. During the contract generation phase, the smart contract includes an agreed-upon driving area field. This field automatically generates a polygonal area bounded by several geographical coordinates based on the scenario description in the user request (such as "intercity travel," "round trip to a designated scenic spot," etc.). If the user does not provide a specific scenario, the system defaults to a circular area with a radius of 80 kilometers centered on the vehicle pick-up location (for daily commuting) or a circular area with a radius of 200 kilometers (for weekend trips). Beyond this range, additional authorization from the vehicle owner is required. The deviation detection unit obtains the vehicle's latest GPS coordinates every 30 seconds and calculates the shortest distance D_deviation from the vehicle to the boundary of the agreed-upon driving area. When D_deviation exceeds a preset threshold (set to 2 kilometers in this embodiment), a deviation alarm is generated and reported to the vehicle owner. After the deviation alarm is sent, the vehicle owner can choose from three responses: "allow continuation," "prompt return but temporarily not restrict," or "immediately terminate the contract and notify the nearest partner to implement vehicle recovery." If the vehicle owner selects the third response option, the status synchronization and monitoring module automatically sends a dispute marker request to the smart contract.

[0059] The status synchronization and monitoring module also compares the vehicle operating condition data collected in real time by the onboard sensing equipment with the standard operating condition parameters recorded in the vehicle's static attribute data. Standard operating condition parameters are normal operating range parameters extracted from the vehicle manufacturer's publicly available maintenance manual. For example: the normal operating range for engine coolant temperature is 80-105℃; exceeding this range is considered abnormal; the engine speed redline is typically greater than 6000 rpm; exceeding this speed is marked as an aggressive driving event; if instantaneous fuel consumption exceeds the average of the same model by more than 40% and lasts for more than 30 minutes, it is marked as an abnormal driving style. When the above abnormal operating condition events are detected, the module triggers a temporary restriction command. This command is sent to the vehicle control unit via the CAN bus. Upon receiving the command, the control unit limits the vehicle's maximum permissible speed to 40 km / h, disables the vehicle's Dynamic mode (Sport mode) or Sport mode, and forces the use of Eco mode. The temporary restriction command is revoked after the owner confirms its removal or after the system verifies that the operating conditions have returned to normal.

[0060] 2.8 Electronic Settlement and Evaluation Module After the smart contract is fulfilled, the electronic settlement and evaluation module triggers automatic deduction based on the actual usage time and additional fees. The settlement logic is as follows: Let the base rental fee be P_base, the actual usage time be T_actual minutes, the contractually agreed duration be T_agreed minutes, the platform service fee coefficient be c_svc (3%~5%), the overtime unit price be o_rate=(P_base / T_agreed)×1.5 (yuan / minute), and the cleaning fee deduction flag be c_clean (true / false, if true, the prepaid cleaning deposit C_deposit will be deducted). If T_actual ≤ T_agreed, then the total cost = P_base × (1 + c_svc); if T_actual > T_agreed, then the total cost = P_base × (1 + c_svc) + (T_actual - T_agreed) × o_rate. If c_clean = true, an additional cleaning deposit will be deducted from the above calculation (i.e., C_deposit will be deducted from the pre-authorized credit card or digital wallet). The system automatically deducts the payment through a direct debit interface connected to third-party payment channels (Alipay, WeChat Pay, or bank card payment gateway). After the deduction is completed, the system distributes the revenue according to the configured revenue sharing rules: the platform receives a service fee of P_base × c_svc; the vehicle owner receives P_base + any overtime revenue and the cleaning fee deduction (if the cleaning fee is used to pay for professional cleaning services, it can be distributed according to the agreed ratio). After settlement, the electronic settlement and evaluation module receives two-way anonymous evaluations from the vehicle owner and the sharing terminal. The evaluation content is divided into three parts: (1) Star rating (1 to 5 stars, with 0.5 stars as the smallest unit), which evaluates four aspects: vehicle condition, owner / user's communication attitude, punctuality, and cleanliness of the vehicle interior; (2) Text evaluation (optional, with a maximum of 200 characters); (3) Preset tag selection (such as "punctual", "good vehicle condition", "smooth communication", "overdue return", "smoking in the vehicle", "aggressive driving", etc.). Before all evaluation data is written to the database, the system will perform text filtering and sensitive word detection on the evaluation content. Evaluations that meet the rules will be anonymized (the user ID of the evaluator will be replaced with a globally unique anonymous ID) and then publicly published on the homepage of the corresponding vehicle and user.

[0061] Example 2 This embodiment is a further optimization and expansion based on Embodiment 1.

[0062] First, the system added a vehicle availability prediction module. This module, based on vehicle static attribute data and historical dynamic status data (extracting status records for the vehicle at all points in time over the past 365 days from relational and time-series databases, including timestamps, status type (occupied / idle), geographic location information, season and weather tags, etc.), uses the Prophet time series prediction model to predict the availability probability of a target vehicle within a future time window. The Prophet model training process involves dividing historical status records into 1440-minute periods per day, labeling each period as "bookable" or "unbookable" (unbookable due to reasons such as owner use, vehicle maintenance, or sharing with other users). The model generates an availability probability value P_avail(h) (a floating-point number from 0 to 1) for each hour within the next 7 days by identifying multiple periodic patterns of the vehicle (weekday patterns, holiday patterns, seasonal patterns) and the impact of special events (such as unavailability during periods when the owner has a fixed commuting schedule). The prediction results are pushed to the two-way matching and game negotiation module as an additional weighting factor when sorting the candidate vehicle source list: the comprehensive matching score S_match[i] is modified to S_match[i]=α×cosine_similarity+(1-α)×(1-weighted_euclidean_distance)+β× P_avail_30, which is the 30-day moving average of the availability probability of the target vehicle source within the demand time window, and β is the weighting coefficient (0.15 in this embodiment).

[0063] Secondly, the system adds a shared contract transfer module. When a user of the shared vehicle is unable to continue using the vehicle due to a change in travel plans during the contract validity period (i.e., between T_start and T_end), the user can send a contract transfer request to the system. The contract transfer request includes the expected transfer price (which may differ from the original contract price) and the transfer period. After receiving the request, the shared contract transfer module searches for third-party candidate users in the system's demand-side users who match the following conditions: (1) their current geographical location is within 5 kilometers of the vehicle's current location; (2) there is an overlap between the time window of their usage demand and the remaining time window of the contract; (3) their credit score is not lower than 80% of the original demand-side user's credit score; and (4) they have a positive preference or neutral attitude towards the vehicle brand and configuration. The third-party candidate users found will receive a push notification, which includes vehicle information, the remaining duration of the original contract, the transfer price, and a transfer prompt. When a third-party candidate user accepts the transfer conditions, the system sends a transfer request approval notification to the original vehicle owner, who can choose to "agree" or "reject". If the vehicle owner does not respond within 30 minutes, the system defaults to agreeing (this default rule is publicized to the vehicle owner and stipulated in the user agreement). After the transfer is agreed upon, the sharing contract transfer module calls the transferContract() method in the smart contract to replace the demander_id field of the structured digital contract and the corresponding public key of the sharing terminal with the third-party user's information, and simultaneously updates the digital key allocation in the sharing permission management module—the original K_demander is actively cancelled by the system, and K_demander_new is regenerated for the third-party user according to the digital key generation process in Example 1 and securely distributed. After the contract transfer is completed, the original demand-side user no longer bears any responsibility for the vehicle and its usage behavior, and all rights and obligations are transferred to the third-party transferee terminal. The settlement of the transfer price difference between the transferor and the transferee is completed separately through the electronic settlement and evaluation module, which is processed separately from the settlement of the main contract.

[0064] Finally, in this embodiment, the user demand parsing engine is also configured with an advanced mode of semantic disambiguation. In addition to basic disambiguation based on a vehicle terminology knowledge graph, the advanced mode introduces a dialogue context memory mechanism. When a user continuously enters multiple vehicle requests in a single session, the system maintains a temporary context cache, recording conditions explicitly stated in the previous request (e.g., the user has already stated "needs an automatic transmission" but hasn't mentioned it again). These conditions are automatically inherited during the disambiguation process of subsequent requests. The advanced mode also supports cross-time period intent tracking: the system records the user's historical vehicle usage records over the past 30 days, identifies the user's preference patterns (e.g., the user tends to rent SUVs every Friday afternoon and always checks the "needs trunk space" tag). When parsing new requests, the system automatically incorporates these historical preferences as soft constraints (with lower weights) into the demand feature vector F_demand. When the user manually marks "do not use historical preferences" in the application, this tracking mechanism pauses and prompts the user via a pop-up at the start of the next session whether to re-enable it.

[0065] Example 3 This embodiment mainly describes how the system overcomes the technical defects of "simple superposition" or "functional combination" in the prior art. Compared with the prior art, the modules of the present invention are not isolated functional superpositions, but form a complete data flow closed loop. There are multi-channel bidirectional data exchange and instruction coupling between the modules, which is specifically reflected in the following aspects.

[0066] First, the dynamic status data output from the data layer (especially vehicle location information and time occupancy status information) is not only directly used as input to the vehicle source value assessment module, but is also synchronously pushed to the spatiotemporal constraint checker and vehicle source status prediction module in the bidirectional matching and game negotiation module via the system's message bus. The prediction results generated by the vehicle source status prediction module are then fed back to the data layer, guiding the dynamic optimization of the time-series database storage strategy in the data layer—for vehicles with a predicted availability probability higher than 0.7, the frequency of their dynamic status data collection is increased (from 30 seconds / time to 10 seconds / time) to provide more refined real-time data for the matching module. This data loop of "assessment layer → prediction layer → data layer collection frequency → data layer output → assessment layer input → prediction layer update" constitutes an organic collaboration, rather than separate functional modules.

[0067] Second, a state machine-based collaborative operation mechanism exists between the shared contract generation module and the shared permission management module. The execution state of the smart contract (0-pending signing → 1-signed and awaiting performance → 2-performance in progress → 3-performance awaiting settlement → 4-completed) drives the generation, distribution, activation, invalidation, and cancellation of digital keys in the shared permission management module. Simultaneously, the timeout event of the timeliness constraint unit in the shared permission management module triggers a change in the execution state of the smart contract in the shared contract generation module (transitioning from 2-performance in progress to 3-performance awaiting settlement, while simultaneously activating the electronic settlement and evaluation module). The state transitions between the three modules must strictly adhere to a predefined state transition matrix. If the state change of any module does not conform to the predecessor-successor relationship defined in the matrix, the system will immediately trigger a global exception handling process—resetting the relevant modules to a consistent state and sending an alert to the administrator.

[0068] Third, the output of the two-way matching and game-theoretic negotiation module—negotiated pricing—not only serves as the input parameter for the contract generation module but also influences the weighted self-learning engine of the vehicle source value assessment module. Specifically, for each successfully completed transaction, the difference δ = |P_transaction - V_i(t)| between the actual transaction price and the real-time vehicle source value score V_i(t) output by the vehicle source value assessment module at that moment is recorded as the regression error term for that transaction. When recalculating the weight coefficients w_i monthly during regression analysis, the system assigns higher weights to samples with larger differences between the transaction price and the real-time score (outlier samples where δ exceeds two standard deviations), causing the regression model to focus more on these samples with larger deviations, thereby gradually converging the gap between the assessment model and the actual market pricing.

[0069] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A vehicle resource sharing and trading system, characterized in that, include: The data layer is configured to receive and store vehicle static attribute data and dynamic status data from at least one vehicle owner's terminal, wherein the dynamic status data includes vehicle location information, time occupancy status information, and vehicle operating condition data collected in real time by the on-board sensing device. The vehicle source value assessment module is configured to use the vehicle's static attribute data and dynamic status data as input parameters, execute a multi-dimensional weighted assessment algorithm, and output a real-time vehicle source value score that is dynamically updated over time. The user demand parsing engine is configured to obtain car usage requests from at least one demand side, and extract demand feature vectors containing spatiotemporal constraints and car usage preferences from the car usage requests based on natural language processing technology. The two-way matching and game negotiation module is configured to map the real-time value score of the vehicle source and the demand feature vector to the same multi-dimensional feature space for similarity clustering operation, generate a candidate vehicle source list, and for each candidate vehicle source in the candidate vehicle source list, call the non-cooperative game negotiation model to simulate the multi-round strategy interaction between the car owner and the demand side in the bidding space to generate negotiated pricing. The shared contract generation module is configured to automatically generate a structured digital contract containing the vehicle usage period, price terms, and usage scope when the negotiated pricing is accepted by both parties, and trigger the execution of a blockchain-based smart contract. The sharing permission management module is configured to distribute digital keys with different operation permission levels to the vehicle owner terminal and the sharing terminal respectively during the execution of the smart contract. The digital keys are used to control access to the target vehicle's door opening, engine starting, and vehicle function groups. The status synchronization and monitoring module is configured to monitor the operation behavior of the sharing terminal on the target vehicle in real time, and perform consistency verification with the execution status of the smart contract. If the verification is inconsistent, an alarm mechanism is triggered. The electronic settlement and evaluation module is configured to trigger an automatic deduction operation based on the actual usage time and additional fees after the smart contract is fulfilled, and to receive two-way anonymous evaluations from the car owner's terminal and the sharing terminal.

2. The vehicle resource sharing and trading system according to claim 1, characterized in that, The vehicle source value assessment module also includes a condition-triggered score correction submodule. The condition-triggered score correction submodule is configured to monitor external environmental condition data and seasonal time factors. When the external environmental condition data or seasonal time factors meet the preset correction conditions, the real-time value score of the vehicle source is subject to a one-time incremental correction and the corrected score is output. The weight coefficients of the multi-dimensional weighted evaluation algorithm are periodically adjusted based on historical transaction data through regression analysis.

3. The vehicle resource sharing and trading system according to claim 1, characterized in that, The sharing permission management module is configured to generate at least two operation permission levels: the first permission level grants the operation permissions of unlocking the car door and starting the vehicle, but does not include the access permission of the in-vehicle entertainment system; the second permission level grants the access permission of all in-vehicle functions. The sharing permission management module also includes a time-limited constraint unit, which limits the validity period of the digital key to the end time of the vehicle usage right period, and the digital key automatically expires after the end time.

4. The vehicle resource sharing and trading system according to claim 1, characterized in that, The status synchronization and monitoring module is equipped with a deviation detection unit. The deviation detection unit calculates the deviation distance between the actual driving trajectory of the target vehicle and the driving area agreed in the vehicle use request in real time. When the deviation distance exceeds a preset threshold, a deviation alarm is generated and reported to the vehicle owner. The status synchronization and monitoring module is also configured to compare the vehicle operating condition data collected in real time by the vehicle-mounted sensing device with the standard operating condition parameters recorded in the vehicle static attribute data. When an abnormal operating condition event is detected, a temporary restriction command is triggered. The temporary restriction command is used to restrict the sharing terminal from further operations on the target vehicle.

5. A vehicle resource sharing and trading system according to claim 1, characterized in that, The non-cooperative game negotiation model in the bidirectional matching and game negotiation module adopts the discrete-time version of the Rubinstein bargaining model, and sets a maximum upper limit for the number of negotiation rounds. In each round of negotiation, the non-cooperative game negotiation model dynamically outputs a suggested price based on the real-time value score of the vehicle source in the current round and the bidding history of the demand side. When the number of negotiation rounds reaches the maximum limit, the system automatically closes the current session and releases the corresponding vehicle source in the candidate vehicle source list.

6. A vehicle resource sharing and trading system according to claim 1, characterized in that, It also includes a vehicle source status prediction module, which is configured to predict the availability probability of the target vehicle in a future time window based on the vehicle's static attribute data and historical dynamic status data, and push the prediction results to the two-way matching and game negotiation module to optimize the sorting of the candidate vehicle source list.

7. A vehicle resource sharing and trading system according to claim 1, characterized in that, It also includes a shared contract transfer module, which is configured to receive a contract transfer request from the shared user terminal, find a third-party transferee terminal within the vehicle usage right period corresponding to the structured digital contract, and when the vehicle owner agrees and the third-party transferee terminal accepts the inheritance conditions of the negotiated pricing, transfer the rights and obligations of the structured digital contract to the third-party transferee terminal in their entirety, and simultaneously update the digital key allocation in the shared permission management module.

8. A vehicle resource sharing and trading system according to claim 1, characterized in that, The user demand parsing engine also includes a semantic disambiguation unit, which is configured to perform contextual relevance analysis on fuzzy words in the car use request based on a preset car terminology knowledge graph, and generate a disambiguated demand feature vector; the car terminology knowledge graph includes the classification hierarchy relationship of vehicle brand, model, body color, interior configuration, power type and vehicle age, as well as the synonym mapping relationship.

9. A vehicle resource sharing and trading system according to any one of claims 1 to 8, characterized in that, The blockchain-based smart contract is deployed in a consortium blockchain or public blockchain environment. The structured digital contract is anchored to the blockchain in the form of cryptographic hashes. Any modification to the execution state of the smart contract by any participating node must be confirmed by the consensus mechanism and then synchronized to all authorized nodes.

Images