Track sharing method and vehicle background server

Abstract

The invention provides a track sharing method and a vehicle background server, and belongs to the technical field of data communication.The method comprises the steps that a first track code uplink request sent by an original creator client is received, and the first track code uplink request comprises a first complete uplink track code and a second complete uplink track code; the first complete uplink track code is formed by associating a digital identity label of an original person, a track generation timestamp and a hash value of the track code, and the hash value of the track code is generated by performing hash calculation on track core metadata; and encoding the first complete uplink track code into transaction data which can be identified by the block chain smart contract, and sending the transaction data to a block chain network node. The track code uplink is generated based on the Hash algorithm, the uniqueness of the track code is ensured, and the digital identity label of the original person is added in the complete uplink track code so as to prove that the ownership of the track code always belongs to the original person, and the problem of unclear ownership of the original track is solved.

Description

Technical Field

[0001] This application relates to the field of data communication technology, and in particular to a trajectory sharing method and a vehicle back-end server. Background Technology

[0002] In some long-distance sports scenarios, such as off-road driving and long-distance running, enthusiasts often share their recorded tracks of complex terrain on social media platforms via mobile apps. However, currently, this shared track data is easily copied and modified, and the original creators find it difficult to prove ownership of the track data. Existing track sharing solutions fail to resolve the issues of traceability and ownership of shared tracks, severely dampening the enthusiasm of off-road enthusiasts to share and hindering the protection and promotion of valuable routes. Summary of the Invention

[0003] In view of the above problems, this application provides a trajectory sharing method and a vehicle backend server to overcome or at least partially solve the above problems. The technical solution is as follows: A trajectory sharing method, the method comprising: receiving a first trajectory code on-chain request sent by an creator client, wherein the first trajectory code on-chain request comprises: a first complete on-chain trajectory code, the first complete on-chain trajectory code being formed by associating the creator's digital identity identifier, the trajectory generation timestamp, and the hash value of the trajectory code, wherein the hash value of the trajectory code is a hash value generated by hashing the core metadata of the trajectory; The first complete on-chain trajectory code is encoded into transaction data that can be recognized by the blockchain smart contract and sent to the blockchain network node.

[0004] Optionally, before receiving the first track code on-chain request sent by the creator's client, the method further includes: Receive the original trajectory data sent by the creator's client. The original trajectory data includes: the location coordinate sequence of the driving trajectory, the trajectory timestamp, and the road condition description information. The original trajectory data is subjected to anomaly removal and data compression preprocessing to obtain the trajectory core metadata, which is then sent to the originator client.

[0005] Optionally, the method further includes: In response to a hash collision on the blockchain, a random salt value is generated and sent to the originator's client. The originator client performs hash calculations on the core metadata of the trajectory and the random salt value to generate the hash value of the trajectory code.

[0006] Optionally, the method further includes: The system receives a publishing request sent by the original creator's client. The publishing request includes: public metadata information, publishing scope, and publishing permissions. The public metadata information includes at least the core metadata of the trajectory, and the publishing permissions include only disclosing the core metadata of the trajectory. A public link is generated based on the release request, and the public metadata information and the public link are synchronized to the cooperative community platform; The release request is encoded into transaction data recognizable by the blockchain smart contract and sent to the blockchain network node, and a shared flag is set for the complete on-chain trajectory code.

[0007] Optionally, the trajectory code on-chain request further includes: an access control permission policy, which includes: the identifier of the subject allowed to access, the type of operation allowed to be performed, and additional conditions; The method further includes: The access control policy is encoded into a storage variable of the blockchain smart contract and sent to the blockchain network node.

[0008] Optionally, the method further includes: Receive an access authorization request sent by the access client, the access authorization request including: authorization application information, the authorization application information including the visitor's identity identifier and access operation type; The authorization application information is sent to the creator's client, and the authorization result returned by the creator's client is received; If the authorization result is successful, a temporary access token is generated, and an access authorization response is sent to the access client. The access authorization response includes the authorization result and the temporary access token. The access control policy is updated based on the visitor's identity and access operation type. Transaction data is generated that calls the smart contract function to update the access control policy, and then sent to the blockchain network node to complete the permission update.

[0009] Optionally, the method further includes: Receive a sharing verification request sent by the access client, the sharing verification request including: a temporary access token and the hash value of the trajectory code; The validity of the temporary access token is verified. If the verification is successful, a smart contract function is called through the blockchain application programming interface to verify whether the visitor's digital identity and access operation meet the access control permission policy. If the verification is successful, the visitor is allowed to view and download the original trajectory data based on the hash value of the trajectory code. Transaction data that calls smart contract reference functions is generated based on the transmitted information and sent to the blockchain network node. The transmitted information is used to record the visitor's reference relationship to the original trajectory data and usage log.

[0010] Optionally, the method further includes: Receive a new trajectory code generation request sent by the post-creator client, wherein the new trajectory code generation request includes: new trajectory core metadata and the hash value of the trajectory code; The blockchain application programming interface is used to query whether the hash value of the trajectory code exists on the chain. If it exists, the verification is successful. A reference identifier is generated based on the hash value of the trajectory code and sent to the post-creator client. The system receives a second trajectory code on-chain request sent by the post-creator client. The second trajectory code on-chain request includes a second complete on-chain trajectory code. The second complete on-chain trajectory code is formed by associating the reference identifier, the digital identity identifier of the post-creator, the trajectory generation timestamp, and the hash value of the second trajectory code. The hash value of the second trajectory code is a hash value generated by hashing the core metadata of the new trajectory. The second complete on-chain trajectory code is encoded into transaction data that can be recognized by the blockchain smart contract and sent to the blockchain network node.

[0011] Optionally, the method further includes: Receive a traceability query request sent by the access client, wherein the traceability query request includes: the hash value of the target trajectory code; By querying the on-chain reference tree through the blockchain application programming interface, the trace code information that has a reference relationship and / or is referenced relationship with the target trace code is obtained. The trace code information includes: the hash value of the trace code of the referrer and the referenced party, digital identity identifier, and reference timestamp.

[0012] A vehicle backend server, the vehicle backend server including at least one processor, the at least one processor executing the steps of the trajectory sharing method as described above.

[0013] By employing the aforementioned technical solutions, this application provides a trajectory sharing method and a vehicle backend server. Based on a hash algorithm, it generates trajectory codes from the trajectory data of the original creator and uploads them to the blockchain, ensuring the uniqueness of the originality. A digital identity identifier of the original creator is added to the complete on-chain trajectory code, thus proving that the ownership of the trajectory code always belongs to the original creator, solving the ownership problem of original trajectories. When the trajectory code is uploaded to the blockchain, an access permission policy is configured to ensure that the original creator can only allow specific people to view or use it when sharing the original trajectory, preventing arbitrary copying and abuse, thus solving the permission management problem of original trajectories. Furthermore, it requires that when subsequent creators use the original creator's trajectory code to generate new trajectories, they must embed a reference identifier to protect the originality, prevent plagiarism, and achieve the traceability of original trajectories.

[0014] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0015] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A schematic diagram of the trajectory sharing system provided in an embodiment of this application is shown; Figure 2 A schematic flowchart of the trajectory sharing method provided in an embodiment of this application is shown; Figure 3 A schematic diagram of the trajectory publishing process in the trajectory sharing method provided in this application embodiment is shown; Figure 4 A schematic diagram of the trajectory publishing process in the trajectory sharing method provided in an application example of this application is shown; Figure 5 A schematic diagram of the trajectory publishing process is shown in another application example of this application's trajectory sharing method; Figure 6 A schematic diagram of the access authorization process in the trajectory sharing method provided in this application embodiment is shown; Figure 7 A schematic diagram illustrating the process of updating access control permission policies provided in an embodiment of this application is shown; Figure 8 A schematic diagram of the sharing verification process in the trajectory sharing method provided in this application embodiment is shown; Figure 9This illustration shows a flowchart of the process of generating new trajectory codes by referencing original trajectory codes and uploading them to the blockchain in the trajectory sharing method provided in this application embodiment; Figure 10 This paper shows a schematic diagram of the structure of a trajectory sharing server provided in an embodiment of this application; Figure 11 A schematic diagram of the structure of a vehicle back-end server provided in an embodiment of this application is shown. Detailed Implementation

[0016] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0017] In off-road driving scenarios, many enthusiasts enjoy exploring and sharing their driving routes, such as unique lines they've created in complex terrains like mountains, deserts, or forests. These routes are typically shared through navigation software or social media platforms, such as recording them with GPS and posting them on social media or forums. However, current methods of sharing routes have significant flaws. Route data is easily copied and modified, and the original creators struggle to prove ownership. This lack of clarity and traceability in route ownership severely dampens the enthusiasm of off-road enthusiasts and hinders the protection and promotion of valuable routes.

[0018] To address the aforementioned problems in the prior art, this application provides a trajectory sharing method, which is applied to a trajectory sharing server and a trajectory sharing system.

[0019] To facilitate understanding of the trajectory sharing method provided in the embodiments of this application, a brief introduction to the trajectory sharing system provided in the embodiments of this application will be given first. Figure 1 A structural block diagram of a trajectory sharing system 10 illustrated in an exemplary embodiment of this application is shown. Figure 1 As shown, the trajectory sharing system 10 provided in this application embodiment includes: a client 100, a trajectory sharing server 200, and a blockchain network 300. The functions of each component of the trajectory sharing system 10 are described below: Client 100: For example, it can be a mobile app, which is the interface directly operated by the user and is responsible for front-end functions such as trajectory data collection, trajectory code generation, permission settings, and sharing interaction. It does not directly store core data, but only transmits key information (such as the hash value of the trajectory code, permission rules, etc.) to the trajectory sharing server 200 and the blockchain network 300.

[0020] Track sharing server 200: Responsible for connecting client 100 and blockchain network 300. It handles various requests from client 100, such as track data preprocessing, track code on-chain requests, access permission settings, track sharing, publishing, and access requests. It authenticates clients, formats key data to be on-chain into blockchain-recognizable transaction data for on-chain storage, records reference relationships, updates on-chain, and stores data such as raw track data.

[0021] Blockchain Network 300 is an immutable trust ledger responsible for storing core data such as the unique identifier (i.e., track code) of the track shared by the original creator, ownership, referencing relationships, and permission rules, ensuring that all operations are traceable and tamper-proof. It does not handle complex calculations; it only receives transaction data sent by the track sharing server 200, such as track code on-chaining and referencing records, and completes consensus verification.

[0022] The following will combine Figures 2 to 9 The trajectory sharing method provided in the embodiments of this application will be explained and described in detail. These embodiments are only used to explain this application and do not constitute a limitation thereof.

[0023] As shown in Figure 2, which is a schematic flowchart of a trajectory sharing method provided in an embodiment of this application, the method can be applied to the trajectory sharing server 200 described above. The method includes the following steps (S101-S102): S101. Receive the first trajectory code on-chain request sent by the original creator's client, wherein the first trajectory code on-chain request includes: the first complete on-chain trajectory code, which is formed by associating the original creator's digital identity, the trajectory generation timestamp, and the hash value of the trajectory code. The hash value of the trajectory code is the hash value generated by hashing the core metadata of the trajectory. In this embodiment, the track code on-chain request refers to a transaction application initiated by the creator's client to the track sharing server, requesting the submission of the complete track code to the blockchain network for consensus verification and permanent storage. Its core components include the complete track code data to be on-chain, user identity verification information, and related operation statements, making it the core request type triggering the blockchain storage process. Initiating the on-chain request signifies the user's agreement to include core track-related information (ownership, track identifier, etc.) into the blockchain's immutable system. Once the request is forwarded to the blockchain network by the track sharing server, its corresponding on-chain operation record will be permanently traceable. In this embodiment, the first track code on-chain request must carry the creator's client's digital signature (generated based on the user's wallet private key) for the track sharing server to verify the legitimacy of the request initiator, ensuring that the on-chain operation is the creator's own intention and preventing others from impersonating them to initiate on-chain operations.

[0024] In this embodiment, during off-road driving, users can use a mobile app or dedicated device (such as a GPS navigator) to record their driving trajectory in complex terrains such as mountains, deserts, or forests. This includes the location coordinates of the starting point, waypoints, and destination, timestamps, road condition data (such as slope, altitude, and obstacles), and personal experience notes. After completing an off-road driving session, the original user's original trajectory data can be sent to the server via the original user's client. This original trajectory data includes: the sequence of location coordinates of the driving trajectory, trajectory timestamps, and road condition descriptions. The server receives the original trajectory data sent by the original user's client and stores it locally so that it can be provided to visitors who request to download the data later. The server performs anomaly removal and data compression preprocessing on the original trajectory data to obtain the core trajectory metadata, and then sends the core trajectory metadata to the original user's client. For example, the core trajectory metadata only contains brief information such as the starting point, destination, and a simplified trajectory path map, thereby reducing the amount of data required for hash calculations based on the core trajectory metadata.

[0025] In this embodiment, after receiving the core metadata of the trajectory returned by the server, the creator client uses a local hash algorithm (such as SHA-256) to hash the core metadata of the trajectory, generating a hash value, i.e., a fixed-length string, which forms the main body of the trajectory code. Then, the creator client associates the creator's digital identity (such as a wallet address), the trajectory generation timestamp, and the hash value of the trajectory code to form the first complete on-chain trajectory code. The trajectory code is the core element of this application. It is a unique digital identifier generated by the trajectory data uploaded by the creator. It is a globally unique identifier generated by a hash function and contains the core metadata of the trajectory and a cryptographic signature. The uniqueness of the trajectory code ensures that each creator's trajectory is unique and will not be duplicated or conflicted with others. Adding the creator's digital identity to the complete on-chain trajectory code proves that the ownership of the trajectory code always belongs to the original creator, and any subsequent operations (such as sharing, referencing, or commercial use) require the creator's signed authorization.

[0026] S102. Encode the first complete on-chain trajectory code into transaction data that can be recognized by the blockchain smart contract, and send it to the blockchain network node.

[0027] In some embodiments, the trajectory sharing server formats the first complete on-chain trajectory code into transaction data recognizable by the blockchain smart contract and sends it to the blockchain network nodes. The blockchain network verifies the uniqueness of the trajectory code's hash value through a distributed consensus mechanism (Proof-of-Work or Proof-of-Stake). For example, when uploading to the blockchain, the smart contract's `mint` function is called. The smart contract checks if a trajectory code with the same hash value exists on the chain. If no trajectory code with the same hash value exists, a new entry is created, the trajectory code is stored on the chain, and the transaction hash is returned as confirmation and synchronized to the original client.

[0028] In some embodiments, the trajectory sharing method provided in this application further includes: in response to a hash collision in the hash value of the trajectory code on the blockchain, generating a random salt value and sending the random salt value to the originator client; the originator client performs hash calculation on the trajectory core metadata and the random salt value to generate the hash value of the trajectory code. In this embodiment, if a hash collision exists on the chain, the hash value of the trajectory code is recalculated, and the first complete on-chain trajectory code is updated to complete the on-chain process. This ensures that the hash values ​​of the trajectory codes on the blockchain are unique and without duplication. Once on-chain, the hash value of the trajectory code, as part of the blockchain, cannot be changed, ensuring global uniqueness. This further prevents counterfeit trajectories from also attempting to be on-chain, protecting the original creator.

[0029] The track code in this embodiment is not easily copied or modified after being uploaded to the blockchain. By binding the digital identity with the track code, the ownership of the original track by the creator is ensured, overcoming the problems of unclear ownership and difficulty in tracing track sharing. This can increase the enthusiasm of off-road enthusiasts to share, and is also conducive to the protection and promotion of valuable routes.

[0030] In some embodiments, the trajectory code can be publicly published on a platform or forum for public viewing or use, rather than being shared privately. The trajectory sharing method provided in this application also includes a process for publishing the trajectory. Figure 3 A schematic diagram of the trajectory sharing method illustrating an exemplary embodiment of this application is shown.

[0031] like Figure 3 As shown, the trajectory sharing method provided in this application includes the following steps (S201-S203) for publishing a trajectory: S201. Receive a publishing request sent by the original creator's client. The publishing request includes: public metadata information, publishing scope, and publishing permissions. The public metadata information includes at least the trajectory core metadata, and the publishing permissions include only publicizing the trajectory core metadata. In this embodiment, the original creator can select the "Publish" option in the mobile app and choose the content of the public metadata information. For example, the public metadata information includes: core trajectory metadata, simplified route map, route description, publication time, user anonymity identifier, and public links. It should be noted that the public metadata information is only an illustrative example, and this application does not limit the public metadata information. The publishing scope can also be selected, such as choosing the desired platform, making it visible only to friends and contacts, blocking certain people, etc. Publishing permissions can also be selected, including restrictions on the content to be published, the uses that can be authorized for free, and the requirement to pay for commercial use, etc. To protect the original creator's original trajectory data, in this embodiment, the published content only includes the core trajectory metadata; the complete original trajectory data requires authorization from the original creator to prevent the original trajectory from being counterfeited or plagiarized. The public metadata information includes: core trajectory metadata, public links, route description, and publication time. S202. Generate a public link based on the release request, and synchronize the public metadata information and the public link to the partner community platform; In this embodiment, the cooperative community platform refers to an online service platform that has reached a data synchronization cooperation agreement with this trajectory sharing system and focuses on sharing and exchanging content related to off-road sports. Its core functions include trajectory route display, user interaction and communication, and off-road activity organization, and it has the technical capability to connect to the blockchain API interface and synchronize publicly available trajectory information in real time. As an important carrier for the public dissemination of trajectories, the cooperative community platform must promise to abide by the permission management rules of this trajectory sharing system and not disclose unauthorized complete trajectory data. For example, cooperative community platforms include, but are not limited to: professional off-road sports forums (such as "Off-road E-Clan Forum" and "China Off-road Alliance Community"), outdoor travel vertical platforms (such as "Mafengwo Outdoor Section" and "8264 Off-road Zone"), vehicle brand-specific communities (such as "Great Wall Motors Off-road Vehicle Owners Club Platform"), and navigation service-related communities (such as "Gaode Map Off-road Route Sharing Platform").

[0032] S203. The release request is encoded into transaction data recognizable by the blockchain smart contract and sent to the blockchain network node, and a shared flag is set for the complete on-chain trace code.

[0033] In some embodiments, the publish request is formatted as transaction data calling the `setPublic` function of the smart contract and sent to blockchain network nodes. The `setPublic` function of the smart contract sets the "public" flag of the track code to true; once set, any node can query basic information, but sensitive data is stored encrypted. Upon publication, the smart contract broadcasts an event to notify subscribers.

[0034] The following is a specific application example and... Figure 4 The process of publishing a trajectory in the trajectory sharing method provided in the embodiments of this application will be described in detail. For example... Figure 4 As shown, this specific application example includes the following steps: S301. After Xiao Li finished the off-road race, the mobile app generated a track code hash value of 0x789...abc. The ownership was bound to Xiao Li's wallet address, and the time of track code generation formed a complete track code and was uploaded to the blockchain. S302. Xiao Li opens the app, finds the track code, clicks the publish button, and makes the following settings: (1) Scope of publication: Select “***Off-road Community” or “Off-road *** Forum” (APP supports one-click synchronization to cooperative platforms); (2) Public metadata information: Fill in the route description ("A lesser-known branch of the Duku Highway, avoiding the congestion of the main road, with 3 viewpoints along the way, suitable for SUVs, and no water crossings"), and a simplified route map automatically generated based on the core metadata of the trajectory, for example, only showing the general route from the starting point Urumqi to the end point Qiaerma and then to the end point Nalati, without exposing the precise coordinates of the 5 hidden viewpoints in between). (3) Publishing permissions: Free authorization is available for personal use, but you need to leave a message explaining the purpose. For commercial use, such as inclusion in a navigation APP, you need to pay 50 yuan per time. When Xiao Li clicks to confirm the release, the APP sends the release request to the trajectory sharing server. The server calls the setPublic function of the blockchain smart contract to add the "public=true" flag to the trajectory code on the chain and broadcasts the "TrajectoryPublished" event to notify all users and platforms that have subscribed to this type of trajectory. S303 The track sharing server generates a public link based on the publishing request and publishes the public link and the publishing request information to the cooperation platform, such as route introduction, simplified route map and lighting, to "***Off-road Community" and "Off-road *** Forum". The post is automatically titled "[Original] Duku Highway Niche Branch Route (No Congestion Viewpoints)" and includes a simplified route map, publishing instructions and public link.

[0035] In some embodiments, the collaborative community platform integrates a blockchain API to publish lists in real time. The trajectory sharing method provided in this application also includes: the trajectory sharing server sending the hash value of the trajectory code, the status of the "public" flag, public metadata information, and public links to the collaborative community platform through a preset blockchain API interface; receiving synchronization confirmation feedback from the collaborative community platform; if no feedback is received or synchronization fails, resending after a preset interval until synchronization is successful; and simultaneously storing the synchronization record in a local database to form a traceable synchronization log.

[0036] This ensures that the posting is permanent; even if the platform goes offline, the on-chain data remains accessible, solving the problem of easily deleted posts in traditional forums. Below, we'll combine this with a specific application example and... Figure 5 This application provides a detailed description of the trajectory sharing method's trajectory publishing process in its embodiments. Assume that one year later, the "Off-Road Tribe Forum" shuts down due to operational issues, and Xiao Li's post disappears; Xiao Wang wants to share this route with his friend Xiao Zhang but cannot find the original post. Figure 5 As shown, this specific application example includes the following steps: S401. Xiao Wang uses the blockchain query function of his mobile APP to input the hash value of the trajectory code 0x789...abc and initiates a query request to the trajectory sharing server. In this embodiment, the hash value of the trajectory code can be exported in the form of a QR code or a link. By scanning or importing it through the APP, Xiao Wang can obtain the hash value of the trajectory code 0x789...abc through the previously saved QR code. S402. After receiving the query request, the trajectory sharing server queries the "public" flag on the blockchain node based on the hash value of the trajectory code. Then, it retrieves the public metadata information corresponding to the hash value of the trajectory code from the locally stored synchronization log, regenerates the public link, and returns the public link to Xiao Wang's mobile APP.

[0037] Through the above process, Xiao Wang can share the new public link with Xiao Zhang, thus realizing that even if the platform is gone, the link will remain forever.

[0038] In some embodiments, the trajectory code supports custom access permissions, allowing the creator to control who can view, use, or modify the trajectory. In some embodiments, the trajectory code on-chain request in step S101 further includes an access control policy, which includes: the identifiers of allowed access subjects, the types of operations allowed, and additional conditions. The trajectory sharing method provided in this application embodiment further includes: encoding the access control policy into a storage variable of a blockchain smart contract and sending it to a blockchain network node. For example, the access control policy can be implemented through an Access Control List (ACL). When the creator generates the trajectory code on the client, they can set the allowed access subjects in the ACL, such as visible only to friends or publicly available, whitelisted user IDs or roles; they can also set the types of operations allowed, such as authorization required for citation, prohibition of modification, payment required for commercial use, and free for personal use; and they can also set additional conditions, such as the amount paid and the validity period. In this embodiment, unified permission management facilitates authorization and authentication for subsequent visitors when using or citing the creator's trajectory code.

[0039] In some embodiments, the trajectory code supports transmission and sharing. The creator can export the trajectory code generated by the client as a QR code or link, send it to friends, or publish it on social media platforms for others to use or modify. However, all of this requires the other party to obtain authorization from the creator. The trajectory sharing method provided in this application also includes an access authorization process. Figure 6 A schematic diagram of the access authorization process in a trajectory sharing method illustrated in an exemplary embodiment of this application is shown.

[0040] like Figure 6 As shown, the access authorization process in the trajectory sharing method provided in this application embodiment includes the following steps: S501, The trajectory sharing server receives an access authorization request sent by the access client. The access authorization request includes: authorization application information, which includes the visitor's identity identifier and access operation type; In this application, visitors who wish to use the original trajectory data of the creator, such as quoting the original trajectory data or using it for commercial purposes, must obtain authorization from the original creator before they can use it.

[0041] S502, the track sharing server sends the authorization application information to the creator's client and receives the authorization result returned by the creator's client; The original creator can identify whether the visitor is an individual or a commercial applicant based on the visitor's identity identifier in the authorization application information. Depending on the type of access operation, such as for personal use, learning, or citation only, the authorization will be approved if the user agrees to use the content; otherwise, the authorization will be denied.

[0042] S503. If the authorization result is successful, generate a temporary access token and send an access authorization response to the accessing client. The access authorization response includes the authorization result and the temporary access token. Once the client receives a temporary access token from the server, it can view, download, or reference the original creator's track code.

[0043] S504. Update the access control policy based on the visitor's identity and access operation type, generate transaction data to call the smart contract function to update the access control policy, and send it to the blockchain network node to complete the permission update.

[0044] In this embodiment of the application, after the original author's authorization is approved, the trajectory sharing server also needs to add the visitor's identity to the list of allowed access subject identifiers, and add the visitor's access operation to the allowed access operation type. If it is a commercial applicant or commercial operation, information such as the payment amount also needs to be added to the appendix conditions to complete the update of the access control permission policy, and the updated access control permission policy, for example, the updated ACL is put on the chain to replace the original ACL.

[0045] In this embodiment of the application, by authorizing visitors by the creator, it is ensured that when the creator shares the original work, only specific people can view or use it, so as to solve the problem of arbitrary copying and abuse.

[0046] In some embodiments, access control policies can be dynamically updated, and the originator can initiate a permission update request to modify the access control policies on the chain. In some embodiments, such as... Figure 7 As shown in the embodiments of this application, the method also includes a process for updating access control permission policies, specifically comprising the following steps: S601, The track sharing server receives a permission update request sent by the original creator's client. The permission update request includes: the first complete on-chain track code and the updated access control permission policy; In this embodiment, the original user can select the "Modify Permissions" option in the mobile APP and modify the allowed subject identifier, the allowed operation type, and additional conditions.

[0047] S602. The trajectory sharing server verifies the consistency between the digital identity of the originator client and the identity of the first complete on-chain trajectory code. After the consistency verification is passed, it generates transaction data to call the smart contract function to update the access control permission policy and sends it to the blockchain network node to complete the permission update.

[0048] In this embodiment, the trajectory sharing server also synchronizes the permission update results to the original creator's client and the access clients of the relevant authorized visitors.

[0049] In this embodiment, the access control policy is stored on the blockchain as a smart contract variable. The access control policy can be dynamically updated, which is useful in off-road scenarios, such as sharing it only with club members to prevent commercial abuse or security risks.

[0050] In some embodiments, by setting access permissions, visitors need to be verified upon access to ensure that only authorized visitors can obtain the original creator's trajectory code. The trajectory sharing method provided in this application also includes a sharing verification process. Figure 8 A schematic diagram of the sharing verification process in a trajectory sharing method illustrated in an exemplary embodiment of this application is shown.

[0051] like Figure 8 As shown, the sharing verification process in the trajectory sharing method provided in this application embodiment includes the following steps: S701, The track sharing server receives a sharing verification request sent by the access client. The sharing verification request includes: a temporary access token and the hash value of the track code. S702. The trajectory sharing server verifies the validity of the temporary access token. After successful verification, it calls the smart contract function through the blockchain application programming interface to verify the visitor's digital identity and whether the access operation meets the access control policy. If the verification is successful, the visitor is allowed to view and download the original trajectory data based on the hash value of the trajectory code. In some embodiments, the ACL is stored on the blockchain as a variable of the smart contract. The trajectory sharing server verifies the visitor's identity by calling the smart contract's accessControl function; if there is a mismatch, the operation is rejected. In this embodiment, zero-knowledge proof (ZK-SNARKs) technology is used to ensure that the verification does not leak privacy. The zero-knowledge proof credential is generated from the visitor's digital identity and is used to prove that they belong to the ACL access control list without exposing other information in the list. The smart contract's accessControl function verifies the validity of the visitor's zero-knowledge proof credential. If the verification passes, it confirms that the visitor has access rights and returns the decryption key to the visitor's client. If the verification fails, it returns a permission-unauthorized message to the visitor's client.

[0052] Once verified, visitors can view and download the raw trajectory data from the server, including the complete driving trajectory's location coordinate sequence, trajectory timestamps, and road condition descriptions. Visitors can load the creator's trajectory into their own devices for navigation, reproducing the creator's off-road trajectory, enabling the trajectory code to be transmitted and shared.

[0053] S703. Generate transaction data for calling smart contract reference functions based on the transmitted information and send it to the blockchain network node. The transmitted information is used to record the reference relationship of the visitor to the original trajectory data and the usage log.

[0054] In some embodiments, the trajectory sharing server generates transaction data that calls the smart contract's cite function and sends it to the blockchain network node, updates the on-chain records, and records reference relationships and usage logs, making the trajectory code traceable. Whenever a visitor uses the original creator's original trajectory, the on-chain records are updated.

[0055] In some embodiments, whenever someone uses or generates a new trajectory based on the original trajectory, the original code must be referenced. That is, a reference link to the original trajectory code, such as the hash value of the original trajectory code, is embedded in the new trajectory code to prevent plagiarism and protect originality. The trajectory sharing method provided in this application also includes a process of generating new trajectory codes and uploading them to the blockchain by referencing the original trajectory code. Figure 9 The illustration shows a schematic diagram of the process of generating new trajectory codes and uploading them to the blockchain by referencing original trajectory codes in a trajectory sharing method according to an exemplary embodiment of this application.

[0056] like Figure 9 As shown in the embodiment of this application, the process of generating new trajectory codes by referencing original trajectory codes and uploading them to the blockchain in the trajectory sharing method includes the following steps: S801, The track sharing server receives a new track code generation request sent by the post-creator client, wherein the new track code generation request includes: new track core metadata and the hash value of the track code; In this embodiment, a post-creator refers to a user who obtains an original trajectory code (authorized or publicly citationable) that has been uploaded to the blockchain through this trajectory sharing system, and then uses, optimizes, or recreates the original trajectory to generate a new trajectory and apply for its upload. The core characteristic of a post-creator is that their new trajectory has a clear citation relationship with the original trajectory, and they must embed the citation identifier of the original trajectory code in the new trajectory code, fulfilling their obligation to declare the source. Specifically, the creative behavior of a post-creator includes, but is not limited to: 1) generating a new trajectory by supplementing local road condition updates (such as adding obstacle prompts or optimizing detour routes) based on the core route of the original trajectory; 2) merging effective road segments from multiple original trajectories to form a completely new off-road route and generating a new trajectory; 3) generating a subdivided scene trajectory by adjusting route parameters (such as slope adaptation and traffic condition marking) for specific vehicle types (such as hardcore off-road vehicles or urban SUVs) based on the original trajectory. Regardless of the creative form, post-creators must clearly indicate the source of the original trajectory through the system's citation mechanism and must not conceal the citation relationship to impersonate independent original creators.

[0057] In this embodiment, for a subsequent creator to generate a new trajectory code by referencing the original creator's trajectory code, authorization from the original creator and verification by the trajectory sharing server are required. After authorization and verification, the subsequent creator can send the original trajectory data to the server via the subsequent creator client. This original trajectory data includes the location coordinate sequence of the subsequent creator's driving trajectory, trajectory timestamps, and road condition descriptions. The server receives the original trajectory data sent by the subsequent creator client and stores it locally for use by subsequent visitors requesting downloads. The server performs anomaly removal and data compression preprocessing on the original trajectory data sent by the subsequent creator client to obtain the new trajectory core metadata for the subsequent creator, and then sends this new metadata to the subsequent creator client. For example, the new trajectory core metadata only includes brief information such as the start point, end point, and a simplified trajectory path diagram, thereby reducing the amount of data required for hash calculations based on the new trajectory core metadata.

[0058] S802. The trajectory sharing server queries the blockchain application programming interface to see if the hash value of the trajectory code exists on the chain. If it exists, the verification is successful. Based on the hash value of the original creator's trajectory code, a reference identifier is generated and sent to the subsequent creator's client. In this embodiment, the trajectory sharing server verifies the validity of the original creator's trajectory code by querying whether the hash value of the original creator's trajectory code exists on the chain. After verification, subsequent on-chain operations can be performed to ensure the legitimacy of referencing the original creator.

[0059] S803. Receive the second trajectory code on-chain request sent by the subsequent creator client, wherein the second trajectory code on-chain request includes: a second complete on-chain trajectory code, which is formed by associating the reference identifier, the digital identity identifier of the subsequent creator, the trajectory generation timestamp, and the hash value of the second trajectory code, and the hash value of the second trajectory code is the hash value generated by hash calculation of the new trajectory core metadata; In this embodiment, after receiving the reference identifier returned by the server upon successful verification, the post-creator client uses a local hash algorithm (such as SHA-256) to perform hash calculation on the core metadata of the post-creator's new trajectory, generating a hash value to form the main body of the post-creator's new trajectory code. Then, the post-creator client associates the reference identifier, the post-creator's digital identity identifier (such as a wallet address), the new trajectory generation timestamp, and the hash value of the new trajectory code to form a second complete on-chain trajectory code. For example, if user A shares a trajectory code with B, and B generates a new trajectory code after running it, the new trajectory code adds "parent: A's hash value" as a reference identifier. In this embodiment, the uniqueness of the new trajectory code ensures that the post-creator's trajectory is also unique and will not duplicate or conflict with others. Adding a reference identifier to the complete on-chain trajectory code makes it clear, like a paper citation, who used whose trajectory, protecting originality and preventing plagiarism. Adding the digital identity of the post-creator to the complete on-chain trajectory code proves that the ownership of the new trajectory code always belongs to the post-creator, and any subsequent operations (such as sharing, referencing, or commercial use) will require the post-creator's signature authorization.

[0060] S804. Encode the second complete on-chain trajectory code into transaction data that can be recognized by the blockchain smart contract and send it to the blockchain network node.

[0061] In this embodiment, a reference tree is maintained by the smart contract through an on-chain linked list structure, with each track code as a node and reference relationships as edges. When a new reference occurs, the track sharing server generates transaction data that calls the smart contract's `cite` function and sends it to the blockchain network nodes, updating the on-chain records and forming an irreversible reference chain. It also records reference relationships and usage logs, making the track codes traceable. Whenever someone uses the original creator's original track, the on-chain records are updated.

[0062] In some embodiments, the trajectory sharing method provided in this application further includes: receiving a tracing query request sent by an access client, wherein the tracing query request includes: the hash value of the target trajectory code; querying the on-chain reference tree through a blockchain application programming interface to obtain trajectory code information that has a reference relationship and / or is referenced relationship with the target trajectory code, wherein the trajectory code information includes: the hash values ​​of the trajectory codes of the referrer and the referenced, digital identity identifiers, and reference timestamps. In this embodiment, when a user queries the tracing, the mobile APP can call the query interface of the smart contract (such as getHistory) to pull the complete path from the blockchain explorer, including all users and usage timestamps. This is particularly useful in off-road communities, such as tracking the evolution history of a popular route, preventing plagiarism, and encouraging original sharing.

[0063] The trajectory sharing method provided in this embodiment generates trajectory codes based on hash algorithms and puts them on the blockchain, ensuring the uniqueness of the originality. A digital identity identifier of the original creator is added to the complete on-chain trajectory code, proving that the ownership of the trajectory code always belongs to the original creator, thus solving the ownership problem of original trajectories. When the trajectory code is put on the blockchain, an access permission policy is configured to ensure that the original creator can only allow specific people to view or use it when sharing the original trajectory, preventing arbitrary copying and abuse, thus solving the permission management problem of original trajectories. Furthermore, it requires that when subsequent creators use the original creator's trajectory code to generate new trajectories, they must embed a reference identifier to protect the originality, prevent plagiarism, and achieve the traceability of original trajectories.

[0064] An exemplary embodiment of this application provides a trajectory sharing server 200. Figure 10 A structural block diagram of a trajectory sharing server provided in an exemplary embodiment of this application is shown. The aforementioned trajectory sharing server is applied to a vehicle backend server and can achieve the following: Figures 1 to 9 All or part of the contents of any of the illustrated embodiments. The following is only a brief description of the structure and function of the trajectory sharing server; for other matters not covered, please refer to the relevant descriptions in the trajectory sharing method described above. The embodiment of this trajectory sharing server corresponds to the embodiment of the trajectory sharing method described above. All implementation processes and methods of the above method embodiments can be applied to the embodiment of this trajectory sharing server and can achieve the same technical effect.

[0065] like Figure 10 As shown, the trajectory sharing server 200 includes an interaction module 201 and a control module 202. In this embodiment, the interaction module 201 is used to receive a first trajectory code on-chain request sent by the creator's client. The first trajectory code on-chain request includes a first complete on-chain trajectory code, which is formed by associating the creator's digital identity, the trajectory generation timestamp, and the hash value of the trajectory code. The hash value of the trajectory code is a hash value generated by hashing the core metadata of the trajectory. The control module 202 is used to encode the first complete on-chain trajectory code into transaction data that can be recognized by the blockchain smart contract and send it to the blockchain network node.

[0066] In some embodiments, such as Figure 10As shown, the trajectory sharing server 200 also includes a data processing module 203. In this embodiment, the interaction module 201 is further used to receive the original trajectory data sent by the originator client and store it locally. The original trajectory data includes: the position coordinate sequence of the driving trajectory, the trajectory timestamp, and road condition description information. The data processing module 203 is used to perform anomaly removal and data compression preprocessing on the original trajectory data to obtain the trajectory core metadata, and send the trajectory core metadata to the originator client through the interaction module 201. For example, the trajectory core metadata only contains brief information such as the start point, the end point, and a brief trajectory path map, thereby reducing the amount of computational data required for hash calculations based on the trajectory core metadata.

[0067] In this embodiment, after receiving the core metadata of the trajectory returned by the server, the creator's client uses a local hash algorithm (such as SHA-256) to hash the core metadata, generating a hash value, i.e., a fixed-length string, which forms the main body of the trajectory code. Then, the creator's client associates the creator's digital identity (such as a wallet address), the trajectory generation timestamp, and the hash value of the trajectory code to form the first complete on-chain trajectory code. In this embodiment, the uniqueness of the trajectory code ensures that each creator's trajectory is unique and will not duplicate or conflict with others. Adding the creator's digital identity to the complete on-chain trajectory code proves that the ownership of the trajectory code always belongs to the original creator, and any subsequent operations (such as sharing, referencing, or commercial use) require the creator's signed authorization.

[0068] In some embodiments, the control module 202 formats the first complete on-chain trajectory code into transaction data recognizable by the blockchain smart contract and sends it to the blockchain network node. The blockchain network verifies the uniqueness of the trajectory code's hash value through a distributed consensus mechanism (Proof-of-Work or Proof-of-Stake). For example, when uploading to the blockchain, the smart contract's mint function is called. The smart contract checks if a trajectory code with the same hash value exists on the chain. If no trajectory code with the same hash value exists on the chain, a new entry is created, the trajectory code is stored on the chain, and the transaction hash is returned as confirmation and synchronized to the original client.

[0069] In some embodiments, the control module 202 is further configured to generate a random salt value in response to a hash collision of the hash value of the track code on the blockchain, and send the random salt value to the originator client through the interaction module 201; the originator client performs hash calculation on the core metadata of the track and the random salt value to generate the hash value of the track code and sends it to the interaction module 201, and the control module 202 then completes the first complete track code on the blockchain, thereby ensuring that the hash value of the track code on the blockchain is unique and there is no duplication. Once on the blockchain, the hash value of the track code is part of the blockchain and cannot be changed, ensuring global uniqueness. This further prevents counterfeit tracks from also trying to be on the blockchain and protects the originality.

[0070] In some embodiments, the interaction module 201 is further configured to receive a publishing request sent by the original creator client. The publishing request includes: public metadata information, publishing scope, and publishing permissions, wherein the public metadata information includes at least: trajectory core metadata, and the publishing permissions include only publishing the trajectory core metadata. The control module 202 is further configured to generate a public link according to the publishing request, synchronize the public metadata information and the public link to the cooperative community platform, encode the publishing request into transaction data recognizable by the blockchain smart contract, send it to the blockchain network node, and set a shared flag for the complete on-chain trajectory code.

[0071] In some embodiments, the track code on-chain request further includes: an access control policy, which includes: the identifiers of allowed subjects, the types of operations allowed, and additional conditions; the control module 202 is further configured to encode the access control policy into a storage variable of the blockchain smart contract and send it to the blockchain network node. For example, the access control policy can be implemented through an Access Control List (ACL). When the creator generates the track code on the client, the creator can set the allowed subjects in the ACL, such as visible only to friends or publicly available, whitelisted user IDs or roles; the allowed types of operations can also be set, such as authorization required for citation, prohibition of modification, payment required for commercial use, and free for personal use; additional conditions can also be set, such as the amount of payment, validity period, etc. In this embodiment, unified permission management facilitates authorization and authentication for subsequent visitors when using or citing the creator's track code.

[0072] In some embodiments, the interaction module 201 is further configured to receive an access authorization request sent by the access client, the access authorization request including: authorization application information, the authorization application information including the visitor's identity identifier and access operation type; send the authorization application information to the creator client, and receive the authorization result returned by the creator client; the control module 202 is further configured to generate a temporary access token if the authorization result is successful, and send an access authorization response to the access client through the interaction module 201, the access authorization response including: authorization result and temporary access token; the control module 202 is further configured to update the access control permission policy based on the visitor's identity identifier and access operation type, generate transaction data for calling smart contract functions to update the access control permission policy, and send it to the blockchain network node to complete the permission update. In this embodiment of the application, after the original author's authorization is approved, the trajectory sharing server also needs to add the visitor's identity to the list of allowed access subject identifiers, and add the visitor's access operation to the allowed access operation type. If it is a commercial applicant or commercial operation, information such as the payment amount also needs to be added to the appendix conditions to complete the update of the access control permission policy, and the updated access control permission policy, for example, the updated ACL is put on the chain to replace the original ACL.

[0073] In this embodiment of the application, by authorizing visitors by the creator, it is ensured that when the creator shares the original work, only specific people can view or use it, so as to solve the problem of arbitrary copying and abuse.

[0074] In some embodiments, the interaction module 201 is further configured to receive a sharing verification request sent by the access client, the sharing verification request including: a temporary access token and the hash value of the trajectory code; the control module 202 is further configured to verify the validity of the temporary access token, and after successful verification, call a smart contract function through the blockchain application programming interface to verify whether the visitor's digital identity and access operation meet the access control permission policy; if the verification is successful, the visitor is allowed to view and download the original trajectory data based on the hash value of the trajectory code; transaction data for calling the smart contract reference function is generated based on the transmission information and sent to the blockchain network node, wherein the transmission information is used to record the visitor's reference relationship to the original trajectory data and usage log. In this embodiment, by setting access permissions, visitors need to be verified when accessing, to ensure that only authorized visitors can obtain the original creator's trajectory code, thus protecting the originality and enabling the original trajectory code to be transmitted and shared.

[0075] In some embodiments, the interaction module 201 is further configured to receive a new trajectory code generation request sent by the post-creator client, wherein the new trajectory code generation request includes: new trajectory core metadata and the hash value of the trajectory code; the control module 202 is further configured to query whether the hash value of the trajectory code exists on the chain through the blockchain application programming interface, and if it exists, the verification is successful, a reference identifier is generated based on the hash value of the trajectory code, and sent to the post-creator client through the interaction module 201; the interaction module 201 is further configured to receive a second trajectory code on-chain request sent by the post-creator client, wherein the second trajectory code on-chain request includes: a second complete on-chain trajectory code, which is formed by associating the reference identifier, the digital identity identifier of the post-creator, the trajectory generation timestamp, and the hash value of the second trajectory code, and the hash value of the second trajectory code is generated by hashing the new trajectory core metadata; the control module 202 is further configured to encode the second complete on-chain trajectory code into transaction data recognizable by the blockchain smart contract, and send it to the blockchain network node. In this embodiment, through the chain list structure, the smart contract maintains a reference tree, with each trajectory code as a node and the reference relationship as an edge. When a new reference occurs, the trajectory sharing server generates transaction data that calls the smart contract's `cite` function and sends it to the blockchain network nodes, updating the on-chain records and forming an irreversible reference chain. It also records the reference relationships and usage logs, making the trajectory code traceable. Whenever someone uses the original creator's original trajectory, the on-chain records are updated.

[0076] In this embodiment, the uniqueness of the new trajectory code ensures that the trajectory of subsequent creators is also unique and will not duplicate or conflict with others. Adding a citation identifier to the complete on-chain trajectory code, similar to citations in academic papers, makes it clear who used whose trajectory, protecting originality and preventing plagiarism. Adding a digital identity identifier to the complete on-chain trajectory code proves that the ownership of the new trajectory code always belongs to the subsequent creator, and any subsequent operations (such as sharing, citation, or commercial use) require the subsequent creator's signed authorization.

[0077] In some embodiments, the interaction module 201 is further configured to receive a traceability query request sent by the access client, wherein the traceability query request includes: the hash value of the target trajectory code; the control module 202 is further configured to query the on-chain reference tree through the blockchain application programming interface to obtain trajectory code information that has a reference relationship and / or is referenced relationship with the target trajectory code, wherein the trajectory code information includes: the hash value of the trajectory code of the referrer and the referenced, digital identity identifier, and reference timestamp.

[0078] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0079] The trajectory sharing server provided in this embodiment generates trajectory codes based on a hash algorithm and uploads them to the blockchain, ensuring the uniqueness of the originality. A digital identity identifier of the original creator is added to the complete on-chain trajectory code, proving that the ownership of the trajectory code always belongs to the original creator, thus solving the ownership problem of original trajectories. When the trajectory code is uploaded to the blockchain, an access permission policy is configured to ensure that the original creator can only allow specific people to view or use it, preventing arbitrary copying and abuse, thus solving the permission management problem of original trajectories. Furthermore, when subsequent creators use the original creator's trajectory code to generate new trajectories, they must embed a reference identifier to protect the originality, prevent plagiarism, and achieve the traceability of original trajectories.

[0080] Figure 11 is a schematic diagram of the structure of a vehicle back-end server provided in an embodiment of this application.

[0081] For example, as shown in Figure 11, the vehicle backend server includes a memory 501 and a processor 502, wherein the memory 501 stores executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to execute the trajectory sharing method.

[0082] This embodiment can divide the backend server into functional modules according to the above method example. For example, each module can correspond to a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0083] When each functional module is divided according to its corresponding function, the backend server may include: an interaction module and a control module, etc. It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0084] The vehicle backend server provided in this embodiment is used to execute the above-described trajectory sharing method, and thus can achieve the same effect as the above-described implementation method.

[0085] When using integrated units, the backend server may include a processing module and a storage module.

[0086] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as disclosed in this application. The processor may also be a combination of components that implement computational functions. For example, it may include one or more microprocessor combinations, digital signal processing (DSP) and microprocessor combinations, etc., and the storage module may be a memory.

[0087] This embodiment also provides a computer-readable storage medium (including but not limited to disk storage, CD-ROM, optical storage, etc.) storing computer program code. When the computer program code is run on a computer, the computer executes the above-mentioned related method steps to implement a trajectory sharing method provided in the above embodiment.

[0088] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a trajectory sharing method provided in the above embodiment.

[0089] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0090] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0091] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0092] In the description of this application, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0093] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0094] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A trajectory sharing method, characterized in that, The method includes: The system receives a first trajectory code on-chain request sent by the creator's client. The first trajectory code on-chain request includes a first complete on-chain trajectory code, which is formed by associating the creator's digital identity, the trajectory generation timestamp, and the hash value of the trajectory code. The hash value of the trajectory code is a hash value generated by hashing the core metadata of the trajectory. The first complete on-chain trajectory code is encoded into transaction data that can be recognized by the blockchain smart contract and sent to the blockchain network node.

2. The method according to claim 1, characterized in that, Before receiving the first track code on-chain request sent by the creator's client, the method further includes: Receive the original trajectory data sent by the creator's client. The original trajectory data includes: the location coordinate sequence of the driving trajectory, the trajectory timestamp, and the road condition description information. The original trajectory data is subjected to anomaly removal and data compression preprocessing to obtain the trajectory core metadata, which is then sent to the originator client.

3. The method according to claim 2, characterized in that, The method further includes: In response to a hash collision on the blockchain, a random salt value is generated and sent to the originator's client. The originator client performs hash calculations on the core metadata of the trajectory and the random salt value to generate the hash value of the trajectory code.

4. The method according to claim 1, characterized in that, The method further includes: The system receives a publishing request sent by the original creator's client. The publishing request includes: public metadata information, publishing scope, and publishing permissions. The public metadata information includes at least the core metadata of the trajectory, and the publishing permissions include only disclosing the core metadata of the trajectory. A public link is generated based on the release request, and the public metadata information and the public link are synchronized to the cooperative community platform; The release request is encoded into transaction data recognizable by the blockchain smart contract and sent to the blockchain network node, and a shared flag is set for the complete on-chain trajectory code.

5. The method according to claim 1, characterized in that, The trajectory code on-chain request also includes: an access control permission policy, which includes: the subject identifier allowed to access, the type of operation allowed to be performed, and additional conditions; The method further includes: The access control policy is encoded into a storage variable of the blockchain smart contract and sent to the blockchain network node.

6. The method according to claim 5, characterized in that, The method further includes: Receive an access authorization request sent by the access client, the access authorization request including: authorization application information, the authorization application information including the visitor's identity identifier and access operation type; The authorization application information is sent to the creator's client, and the authorization result returned by the creator's client is received; If the authorization result is successful, a temporary access token is generated, and an access authorization response is sent to the access client. The access authorization response includes the authorization result and the temporary access token. The access control policy is updated based on the visitor's identity and access operation type. Transaction data is generated that calls the smart contract function to update the access control policy, and then sent to the blockchain network node to complete the permission update.

7. The method according to claim 5 or 6, characterized in that, The method further includes: Receive a sharing verification request sent by the access client, the sharing verification request including: a temporary access token and the hash value of the trajectory code; The validity of the temporary access token is verified. If the verification is successful, a smart contract function is called through the blockchain application programming interface to verify whether the visitor's digital identity and access operation meet the access control permission policy. If the verification is successful, the visitor is allowed to view and download the original trajectory data based on the hash value of the trajectory code. Transaction data that calls smart contract reference functions is generated based on the transmitted information and sent to the blockchain network node. The transmitted information is used to record the visitor's reference relationship to the original trajectory data and usage log.

8. The method according to claim 1, characterized in that, The method further includes: Receive a new trajectory code generation request sent by the post-creator client, wherein the new trajectory code generation request includes: new trajectory core metadata and the hash value of the trajectory code; The blockchain application programming interface is used to query whether the hash value of the trajectory code exists on the chain. If it exists, the verification is successful. A reference identifier is generated based on the hash value of the trajectory code and sent to the subsequent creator client. The system receives a second trajectory code on-chain request sent by the post-creator client, wherein the second trajectory code on-chain request includes: a second complete on-chain trajectory code, which is formed by associating the reference identifier, the post-creator's digital identity identifier, the trajectory generation timestamp, and the hash value of the second trajectory code, and the hash value of the second trajectory code is generated by hash calculation of the new trajectory core metadata; The second complete on-chain trajectory code is encoded into transaction data that can be recognized by the blockchain smart contract and sent to the blockchain network node.

9. The method according to claim 1, characterized in that, The method further includes: Receive a traceability query request sent by the access client, wherein the traceability query request includes: the hash value of the target trajectory code; By querying the on-chain reference tree through the blockchain application programming interface, the trace code information that has a reference relationship and / or is referenced relationship with the target trace code is obtained. The trace code information includes: the hash value of the trace code of the referrer and the referenced party, digital identity identifier, and reference timestamp.

10. A vehicle backend server, characterized in that, The vehicle backend server includes at least one processor, which, when executed, implements the steps of the trajectory sharing method as described in any one of claims 1 to 9.

Images