Sensor data attestation and trustworthiness management

Abstract

Disclosed herein are systems, devices, and apparatuses for a trust platform for managing sensor data from automated vehicles. The trust platform includes a key manager configured to provision a trust platform asset (e.g., an autonomous agent content key) to a participating node for encoding sensor data of the participating node. The trust platform also includes a content manager configured to determine an attestation score for an external sensor data of a second participating node and to record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

Description

SENSOR DATA ATTESTATION AND TRUSTWORTHINESS MANAGEMENTTechnical Field

[0001] The disclosure relates generally to data management and, in particular, to multimodality sensor data management that ensures the integrity, usability, and reliability of sensor data exchanges among participating nodes, such as that which may be shared among vehicles, robots, and other environmental-, roadway-, network-, and infrastructure-related systems. The sensor data methods and techniques may serve as the basis for artificial intelligence (Al) model learning and generative Al training.Background

[0002] As robots, autonomous vehicles, mobile devices, etc. become increasingly prevalent, the amount of data collected by these types of devices becomes dauntingly vast. Autonomous vehicles, for example, generate vast amounts of sensory data from various sources, including cameras, Light Detection and Ranging (LiDAR) sensors, inertial sensors, ultrasonic sensors, radar, and other sensors. Such devices benefit from access to large amounts of data in order to improve navigation, perception, safety, localization, etc., especially with respect to moving vehicles that must navigate (sometimes autonomously) by taking into account their surroundings, other people, other vehicles, etc. Sensor data is also often collected from external sources to augment, compliment, and / or verify the local sensor data collected, and ensuring the security, privacy, and trustworthiness of sensor data that is sensed locally or obtained from remote sources may be paramount for sensor-based determinations that impact the safety, comfort, and reliability of the operation of vehicles such as autonomous or assistive vehicles. Conventional approaches often lack robust mechanisms for securely handling sensor data and / or establishing trust among participating nodes.Brief Description of the Drawings

[0003] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the exemplary principles of the disclosure. In the following description, various exemplary aspects of the disclosure are described with reference to the following drawings, in which:FIG. 1 shows an example a portion of the multi-modal trust platform that may be implemented at a node in order to interface sources of and consumers of sensor data content;FIG. 2 illustrates an example of a trust platform for ensuring trustworthiness of multi-modal sensor data from multiple nodes;FIG. 3 outlines an example of a trust platform, where each provisioned node may register sensor information to the blockchain network;FIG. 4 shows an example of a trust platform with a collection of sensor data that may include both AI-Generated content and real sensor data content;FIG. 5 illustrates an example timing flow diagram for a trust platform;FIG. 6 shows an exemplary schematic drawing of a trust platform; andFIG. 7 depicts an exemplary schematic flow diagram of a trust platform.Description

[0004] The following detailed description refers to the accompanying drawings that show, by way of illustration, exemplary details and features.

[0005] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration”. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0006] Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures, unless otherwise noted.

[0007] The phrase “at least one” and “one or more” may be understood to include a numerical quantity greater than or equal to one (e.g., one, two, three, four, [...], etc., where “[...]” means that such a series may continue to any higher number). The phrase “at least one of’ with regard to a group of elements may be used herein to mean at least one element from the group consisting of the elements. For example, the phrase “at least one of’ with regard to a group of elements may be used herein to mean a selection of: one of the listed elements, a plurality of one of the listed elements, a plurality of individual listed elements, or a plurality of a multiple of individual listed elements.

[0008] The words “plural” and “multiple” in the description and in the claims expressly refer to a quantity greater than one. Accordingly, any phrases explicitly invoking the aforementioned words (e.g, “plural [elements]”, “multiple [elements]”) referring to a quantity of elements expressly refers to more than one of the said elements. For instance, the phrase “a plurality” may be understood to include a numerical quantity greater than or equal to two (e.g., two, three, four, five, [...], etc.,means that such a series may continue to any higher number).

[0009] The phrases “group (of)”, “set (of)”, “collection (of)”, “series (of)”, “sequence (of)”, “grouping (of)”, etc., in the description and in the claims, if any, refer to a quantity equal to or greater than one, i.e., one or more. The terms “proper subset”, “reduced subset”, and “lesser subset” refer to a subset of a set that is not equal to the set, illustratively, referring to a subset of a set that contains less elements than the set.

[0010] The term “data” as used herein may be understood to include information in any suitable analog or digital form, e.g., provided as a file, a portion of a file, a set of files, a signal or stream, a portion of a signal or stream, a set of signals or streams, and the like. Further, the term “data” may also be used to mean a reference to information, e.g, in form of a pointer. Theterm “data”, however, is not limited to the aforementioned examples and may take various forms and represent any information as understood in the art.

[0011] The terms “processor” or “controller” as, for example, used herein may be understood as any kind of technological entity that allows handling of data. The data may be handled according to one or more specific functions executed by the processor or controller. Further, a processor or controller as used herein may be understood as any kind of circuit, e.g., any kind of analog or digital circuit. A processor or a controller may thus be or include an analog circuit, digital circuit, mixed-signal circuit, logic circuit, processor, microprocessor, Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), integrated circuit, Application Specific Integrated Circuit (ASIC), etc., or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as a processor, controller, or logic circuit. It is understood that any two (or more) of the processors, controllers, or logic circuits detailed herein may be realized as a single entity with equivalent functionality or the like, and conversely that any single processor, controller, or logic circuit detailed herein may be realized as two (or more) separate entities with equivalent functionality or the like.

[0012] As used herein, “memory” is understood as a computer-readable medium (e.g., a non-transitory computer-readable medium) in which data or information can be stored for retrieval. References to “memory” included herein may thus be understood as referring to volatile or non-volatile memory, including random access memory (RAM), read-only memory (ROM), flash memory, solid-state storage, magnetic tape, hard disk drive, optical drive, 3D XPoint™, among others, or any combination thereof. Registers, shift registers, processor registers, data buffers, among others, are also embraced herein by the term memory. The term “software” refers to any type of executable instruction, including firmware.

[0013] Unless explicitly specified, the term “transmit” encompasses both direct (point-to- point) and indirect transmission (via one or more intermediary points). Similarly, the term “receive” encompasses both direct and indirect reception. Furthermore, the terms “transmit,” “receive,” “communicate,” and other similar terms encompass both physical transmission (e.g., the transmission of radio signals) and logical transmission (e.g., the transmission of digital data over a logical software-level connection). For example, a processor or controller may transmit or receive data over a software-level connection with another processor or controller in the form of radio signals, where the physical transmission and reception is handled by radio-layer components such as RF transceivers and antennas, and the logical transmission and reception over the software-level connection is performed by the processors or controllers. The term “communicate” encompasses one or both of transmitting and receiving, i.e., unidirectional or bidirectional communication in one or both of the incoming and outgoing directions. The term “calculate” encompasses both ‘direct’ calculations via a mathematical expression / formula / relationship and ‘indirect’ calculations via lookup or hash tables and other array indexing or searching operations.

[0014] A “vehicle” may be understood to include any type of machinery that may be operated by software, including autonomous, partially autonomous, stationary, moving, or other objects or entities that utilize software as part of their operation. By way of example, a vehicle may be a driven object with a combustion engine, a reaction engine, an electrically driven object, a hybrid driven object, or a combination thereof. A vehicle may be or may include an automobile, a bus, a mini bus, a van, a truck, a mobile home, a vehicle trailer, a motorcycle, a bicycle, a tricycle, a train locomotive, a train wagon, a robot, a personal transporter, a boat, a ship, a submersible, a submarine, a drone, an aircraft, industrial machinery, autonomous or partially autonomous machinery, or a rocket, among others.

[0015] A “robot” may be understood to include any type of digitally controllable machine that is designed to perform a task or tasks. By way of example, a robot may be an autonomousmobile robot (AMR) that may move within an area (e.g., a manufacturing floor, an office building, a warehouse, etc.) to perform a task or tasks; or a robot may be understood as an automated machine with arms, tools, and / or sensors that may perform a task or tasks at a fixed location; or a combination thereof. More generally, “vehicle” and “robot” may be used herein to refer to devices that utilize sensor information about the environment to inform operation of the vehicle / robot with respect to the environment. Such vehicles and robots may be referred to as an “autonomous agent.”

[0016] Given that vehicles may rely on sensor information for critical operations such as collision avoidance, navigation, safety, route planning, autonomous driving, task implementation, and other activities, the general understanding is that as much data as possible should be collected so that such decisions may be based on a rich set of diverse data in order to arrive at the best decision. While vehicles may have access to a vast amount of sensor data, be it from their own sensing systems or crowd-sourced from external data sources such as road side units, other vehicles, infrastructure equipment, etc., it may be difficult to verify the trustworthiness of the shared data. Is the data from a reliable source? Is the data itself reliable? Was the data collected under favorable conditions? Was the data collected at the same, similar, or reliable location? Current systems offer no way of answering these types of questions and in particular how to securely perform content generation, curation, and management from a multi-modality perspective, where the data may include generative artificial intelligence (Gen Al) and blockchain, in order to meet geographically-specific privacy and data security data requirements.

[0017] The disclosed multi-modal trustworthiness platform (or trust platform) may include a trusted execution environment (TEE) that may securely capture and encrypt multi-modal sensor data based on an autonomous agent content key (AACK). The AACK may be derived using provisioned platform assets that utilize an agreed-upon key derivation algorithm (e.g. using a provisioned keybox asset and using an Advanced Encryption Standard (AES) keyderivation logic.). Additionally, the key derivation algorithm may also use the secure TEE context as well. The AACK may include a manifest of the keys, for example that include keys for real / native sensory data (AACKReai) and keys for Gen Al-based augmented data (AACKcenAi) so that the keys may distinguish between types of data or the context in which it was collected. As should be understood, Gen Al-based augmented data may be understood as data that is generated by an Al learning-model in order to fill in for, supplement, or compliment the real / native data that has been collected by actual sensor systems. For example, there may be corrupted, erroneous, or missing data in an actual sensor’s native data stream, and the Al learning-model may generate new “sensor” data to take the place of the corrupted, erroneous, or missing data. This data may be understood as “Gen Al-based augmented data,” and it may be important for a downstream consumer of such data to understand whether the data was real sensor data or Gen Al-based augmented data.

[0018] The disclosed multi-modal trustworthiness platform may include a number of nodes (e.g., each “node” representing a different vehicle, a roadside unit, a data repository / source, etc.) that participate in the trustworthiness platform, where each participating node may attest the data with / for each other (e.g., using swarm or crowd-sourced attestation) and provide an attestation score that is captured in blockchain, where the AACK may be registered to blockchain (e.g., recorded or logged onto a blockchain ledger). Each participating node may also encrypt its sensory data using the context-specific keys (e.g., AACKReai or AACKoenAi) to create a unique platform fingerprint whose encryption is specific to the context in which the data was generated (e.g., as real / native sensor data, Al-generated data, or other categories that indicate the context of data). Each participating node may also follow additive homomorphic encryption for collaborative scenarios on their content edits that may then be tracked via their content fingerprint by the public ledger (e.g., is recorded / logged in a blockchain ledger). Each participating node may also, without the need for a centralized blockchain management system,decide for itself how its data content is distributed, consumed, and modified by consumers of its data.

[0019] Such a multi-modal trustworthiness platform may advantageously enforce, throughout the data lifecycle, a distributed consensus algorithm that is based on a secure time stamp synchronization and enforced across all participating nodes. The recorded ledger data (e.g., what is logged in the blockchain ledger) may serve as a helpful, tamper-resistant audit trail that regulatory bodies may use for certification, authentication, etc. In addition, the disclosed multi-modal trustworthiness platform may provide for efficient license management and content-distribution management that conforms to configured policies (e.g., policies for geo-fencing, privacy, confidentiality, security, etc. set forth by, for example, regulatory bodies, corporate targets, local municipalities, etc.). Data that has been augmented by Al may be distinguished from actual sensor data for auditing purposes, especially in the case Gen Al augmented data is based on maturing models. For example, any Gen Al augmented data may be removed for audit purposes or to comply with regulatory requirements on the use of Gen Al augmented data. This means that results may include Gen Al augmented data that may also include traceability into the model version and annotations included as part of the blockchain ledger.

[0020] FIG. 1 shows a portion of the multi-modal trust platform that may be implemented at a node (e.g., in an automated vehicle platform) in order to interface sources of and consumers of sensor data in a trusted manner. Node 100 may include an AACK key manager 110 that may manage the AACK keys that it may derive using provisioned platform assets and an agreed- upon key derivation algorithm (e.g. by using a provisioned keybox asset and by using an AES key derivation logic, as noted above). Additionally, the key derivation algorithm may also use the secure TEE context. The AACK key manager 110 may include a manifest of keys that, in an example embodiment, include keys for real sensory data (e.g., AACKReai) and keys for Gen Al-based augmented data (e.g., AACKoenAi). The manifest of keys may include details such asunique identifiers or labels for each key, information about the cryptographic algorithms and parameters associated with each key, metadata describing the purpose or usage context of each key (e.g., whether it is used for encrypting real sensory data or Al-generated augmented data), provisioning information (such as the method of key derivation or generation), security attributes or access control policies associated with each key, timestamps or versioning information indicating when the keys were created or last updated, etc. The AACK key manager 110 may be executed in the real-time operating system (RTOS) and may be part of the secure context (e.g., executed in a trusted execution environment (TEE)).

[0021] Node 100 may also include an AACK content manager 120 that may also be executed in the RTOS. The AACK content manager 120 may be responsible for leveraging the AACK content fusion manager 130 that may utilize generative Al (e.g., an Al learning model) within the node’s trusted execution environment (e.g., a software component in the TEE) in order to author augmented content (e.g., Gen Al-based augmented data) to replace, supplement, and / or complement the real sensor data stream to enable multi-modality sensory fusion, and the Gen Al-based augmented data may be fused from multi-modal sources (e.g., visual / image sensor data, audio sensor data, infrared sensor data, LiDAR sensor data, etc.) according to the mode (e.g., selected by the AACK mode manager 131 based on the environment / regulatory policy selected by the AACK policy manager 132). For example, the mode manager 131 may determine a mode of synchronization based on a predetermined synchronization policy for the node 100, where the mode of synchronization may include a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode. The policy manager 132 may select from policies that define enforcement in a geographic region of node 100 and / or at a timeframe. Node 100 may also include other software, firmware, and hardware to support the platform, and the functional features in FIG. 1 are merely exemplary to show how the AACK content manager 120, the AACK key manager 110, and the AACK content fusionmanager 130 may logically fit into the ecosystem. As should be appreciated, these features may be implemented in other ways and / or be distributed among other locations.

[0022] FIG. 2 shows an example of a trust platform 200 for ensuring trustworthiness of multi-modal sensor data from multiple participating nodes (e.g. from multiple autonomous vehicles / agents such as drones, cars, trucks, road-side units, etc.). To capture target data for a given geofence (e.g., a geographic area, a set of coordinates, a environmental category, etc.), a central licensing and revocation manager 201 may provision keys and define a key derivation algorithm that are provided, via provisioning, to the participating nodes 210 (in the example of FIG. 2, to node 210-1, node 210-2, node 210-3, node 210-4). Once the participating nodes 210 are provisioned, they may then communicate via logged exchanges (e.g., via blockchain ledger entries) to share, attest to, generate, provide, and request encrypted sensor data using the registered AACKs (e.g., recording and / logging onto a blockchain ledger). The central licensing and revocation manager 201 may provision a trusted execution environment (TEE) of the participating nodes 210 for securely capturing, encrypting, and processing sensory data at the participating nodes 210. The TEE may be, for example, provided by the Software Guard Extensions (SGX) in Intel® processors. The TEE may ensure that sensitive operations, such as key management and cryptographic operations, are performed in a secure and isolated environment, protecting the confidentiality and integrity of the data (e.g., from unauthorized access or tampering). The TEE may help mitigate various security threats and risks associated with the management of sensitive data in distributed systems.

[0023] The participating nodes 210, after a successful provisioning into the trust platform 200, may participate in various activities within the trust platform 200, such as capturing and encrypting sensory data using AACKs within a Trusted Execution Environment (TEE), exchanging data with others of the participating nodes 210 provisioned in the trust platform 200, including attesting to each other’s data and trustworthiness using mechanisms like crowdsourced “swarm” attestation, collaborating on content editing through additive homomorphicencryption, and participating in the distributed trust mechanism by registering attestation scores and AACKs to the public ledger (e.g., an entry in the blockchain ledger). The license and revocation manager 201 may also be responsible for revoking a provisioning of participating node 210 based on predefined criteria, such as license expiration, violation of policies, data consumption / processing limits, poor scoring / reputation, etc. As should be appreciated, the license and revocation manager 201 may be centralized or be a distributed architecture.

[0024] Each participating node in the trust platform 200 may register AACKs to the blockchain to make sure the recorded sensor data is immutable and resistant to tampering. Once registered to the blockchain, the information cannot be altered or deleted without consensus from the network, ensuring the integrity of the AACKs. The registered AACKs on the blockchain may provide a means for verifying the authenticity and validity of the keys provisioned by the license and revocation manager 201. Participating nodes 210 within the trust platform 200 may refer to the blockchain to verify the ownership and attributes of AACKs using the public ledger as a transparent and auditable record of AACK registrations. Any changes or transactions involving AACKs are recorded on the blockchain, providing a complete history of key-related activities. In addition, the AACK registrations may provide for a decentralized trust mechanism where participants in the trust platform 200 may rely on blockchain’s consensus mechanism to ensure the accuracy and reliability of AACK registrations without the need for querying the license and revocation manager 201. Instead, each individual node of the participating nodes 210 may use the blockchain ledger to ensure the accuracy and reliability of AACK registrations.

[0025] Each node of participating nodes 210 may have a distributed app that may be implemented using blockchain technology such as that provided by Linux Foundation Hyperledger Project or other distributed computing infrastructure such as loTivity, OPC-UA, DCE, etc. The distributed app may consist of a few nodes of the participating nodes 210 thathave been clustered together for efficient processing optimized for maximal transaction processing throughput.

[0026] FIG. 3 shows an example of a trust platform 300 (e.g., similar to trust platform 200), where each provisioned, participating node (e.g., node 310-1, node 310-2, and up to any number of nodes 310-n) may record sensor information to the blockchain network. The trust platform 300 may also include a license and revocation manager 301 (e.g., similar to license and revocation manager 201 of FIG. 2), that is responsible for providing provision keys and a key derivation algorithm to participating nodes (e.g., node 310-1, node 310-2, node 310-n, etc.). Each of the participating nodes may include a local copy of the blockchain ledger that may include the AACKs that have been registered to the blockchain. This means that each of the participating nodes may encrypt data from its various senor stages (Ml, M2, M3, ... Mn, etc.) in a platform configuration register (PCR) with the provisioned key, for example, node 310-1 may encrypt the first stage of sensor data (Ml) with its provisioned key (kl) (e.g., representing a context of real / native sensor data) and, thus, [PCRMI]I<I, its second stage of sensor data (M2) as [PCRM2]ki, etc. Node 310-2 may encrypt the first stage of sensor data (Ml) with its provisioned key (k2) (e.g., representing a different context of Gen-AI augmented data) and, thus, [PCRM2]k2, its second stage of sensor data (M2) as [PCRM2]k2, etc.

[0027] Each block (Bl, B2, B3 ... BN) may be represented by:or[PCRMx]Ki

[0028] As should be appreciated the PCR may be for a subset of all the stored records / files, depending on whether the data may be individually recorded or grouped (e.g., a continuous series or grouped into discrete subsets), where the data or metadata may indicate how the data is recorded and / or grouped.

[0029] FIG. 4 shows an example of a collection of sensor data 400 that may include both AI-Generated content and real / native sensor data content. In the example of FIG. 4, the collection of sensor data 400 may be a sequence of image frames (e.g., frames 1, 2, 3, 4, etc.), where some of the image frames (e.g., image frame 440) may be an Al-generated image and some of the frames (e.g., image from 410) may be an image captured from a camera (e.g., “real” sensor data). So that the content may be distinguished, the license manager 401 may provision different licenses for encrypting the content according to the source / context of the data. For example, if the content is AI-Generated, the license manager 401 may provision one key for encrypting such data (e.g., KEY_ID_4 or AACKoenAi) and if the content is real / native camera data, the license manager 401 may provision a different key for encrypting such data (e.g., KEY ID l or AACKReai).

[0030] FIG. 5 shows a timing flow diagram for a trust platform (e.g., trust platform 200 and / or 300). First, the license server may, in 510, offer to a node a license for some or all of the Al-generated content to be used by the participating node. The node’s AACK content and fusion engine may, in 520, select some or all of the licensed content to be used for Al-content generation. Next, the license server may, in 530, then initiate a remote attestation request to the node’ s AACK content manager which may, in 540, make an APP call to the platform’ s TEE (e.g., via SGX). The platform’s TEE may then, in 550, retrieve the keybox and perform a challenge / response with the server. If successful, the TEE may inform, in 560, the license server that the authentication was successful. Next, the license server may, in 570, provision a license to the TEE (e.g., a time-bound license with content generation constraints). The node’s TEE may then, in 580, utilize the provisioned license, enforcing the time synchronization (e.g., either through a central server or through a decentralized blockchain ledger) based on the constraints associated with the license). Next, the TEE may also, in 590, via a payment processing module, interact with a data clearing house to quantify micro / meta payments / credits associated with the data.

[0031] FIG. 6 is a schematic drawing illustrating a device 600 for providing a trust platform. The device 600 may include any of the features discussed with respect to the trust platforms discussed above and any of FIGs. 1-5. FIG. 6 may be implemented as a device, a system, a method, and / or a computer readable medium that, when executed, performs the features of the trust platforms described above. It should be understood that device 600 is only an example, and other configurations may be possible that include, for example, different components or additional components.

[0032] Device 600 includes a key manager 610 and a content manager 620. Key manager 610 may be configured to provision a trust platform asset to a participating node for encoding sensor data of the participating node. Content manager 620 may be configured to determine an attestation score for an external sensor data of a second participating node. Content manager 620 may be further configured to record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

[0033] Furthermore, in addition to or in combination with any of the features described in this or the preceding paragraph with respect to device 600, the trust platform asset may include a content key for the participating node. Furthermore, in addition to or in combination with any of the features described in this or the preceding paragraph, the participating node may include an autonomous agent, wherein the trust platform asset may include an autonomous agent content key (AACK). Furthermore, in addition to or in combination with any of the features described in this or the preceding paragraph, the content key may be based on a predefined key derivation logic. Furthermore, in addition to or in combination with any of the features described in this or the preceding paragraph, the predefined key derivation logic may include an Advanced Encryption Standard (AES) logic. Furthermore, in addition to or in combination with any of the features described in this or the preceding paragraph, device 600 may further include a content fusion manager configured to generate an augmented content using an artificial intelligence generation model according to a predefined data usage policy.Furthermore, in addition to or in combination with any of the features described in this or the preceding paragraph, device 600 may further include a policy manager configured to select the predefined data usage policy based on a predefined performance metric.

[0034] Furthermore, in addition to or in combination with any of the features described in this or the preceding two paragraphs, device 600 may further include a mode manager configured to switch a mode of synchronization based on a predetermined synchronization policy for the participating node. Furthermore, in addition to or in combination with any of the features described in this or the preceding two paragraphs, the mode of synchronization may include a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode. Furthermore, in addition to or in combination with any of the features described in this or the preceding two paragraphs, the predetermined synchronization policy may define policies to be enforced in a geographic region of the participating node and / or at a timeframe. Furthermore, in addition to or in combination with any of the features described in this or the preceding two paragraphs, content manager 620 may be configured to determine a time synchronization between the sensor data and external sensor data based on the blockchain network.

[0035] Furthermore, in addition to or in combination with any of the features described in this or the preceding three paragraphs, wherein key manager 610 may be configured to statically configure the trust platform asset. Furthermore, in addition to or in combination with any of the features described in this or the preceding three paragraphs, key manager 610 may be configured to dynamically configure the trust platform asset based on a context in which the sensor data was collected (e.g., geographic location, time, weather conditions, road type, light conditions, etc.). Furthermore, in addition to or in combination with any of the features described in this or the preceding three paragraphs, the content key may be provisioned in a trusted execution environment. Furthermore, in addition to or in combination with any of the features described in this or the preceding three paragraphs, content manager 620 may be furtherconfigured to encode a local sensor data of the participating node with the trust platform asset. Furthermore, in addition to or in combination with any of the features described in this or the preceding three paragraphs, content manager 620 may be configured to determine whether to fuse the external sensor data with the local sensor data based on the attestation score.

[0036] Furthermore, in addition to or in combination with any of the features described in this or the preceding four paragraphs, the trust platform asset may include one of a plurality of unique content keys, wherein content manager 620 may be configured to select the one of the plurality of unique content keys based on whether the sensor data is a native sensor data or an augmented sensor data. Furthermore, in addition to or in combination with any of the features described in this or the preceding four paragraphs, the augmented sensor data may include generated sensor data that is generated using an artificial intelligence generation model, wherein the native sensor data may include raw sensor data that is received from a sensor and not generated using the artificial intelligence generation model. Furthermore, in addition to or in combination with any of the features described in this or the preceding four paragraphs, the attestation score may indicate a degree of correlation between the external sensor data and a second sensor data. Furthermore, in addition to or in combination with any of the features described in this or the preceding four paragraphs, wherein the degree of correlation may be based on a difference in a geographic location at which the external sensor data and the second sensor data was captured.

[0037] Furthermore, in addition to or in combination with any of the features described in this or the preceding five paragraphs, the degree of correlation may be based on a difference in a multi-modal category in which the external sensor data and the second sensor data was captured (e.g., via a geofence such as a geographic location, a type of weather, a type of terrain, a type of road, a type of environment) with respect to a time period. Furthermore, in addition to or in combination with any of the features described in this or the preceding five paragraphs, the participating node may include one of a plurality of participating nodes, each with a uniquetrust platform asset. Furthermore, in addition to or in combination with any of the features described in this or the preceding five paragraphs, content manager 620 may be configured to use an additive homomorphic encryption to revise the external sensor data and record a revision of the external sensor data to the blockchain network. Furthermore, in addition to or in combination with any of the features described in this or the preceding five paragraphs, content manager 620 may be configured to specify in the blockchain network a consumption restriction that is applicable to a consumer of the external sensor data encoded with the trust platform asset.

[0038] Furthermore, in addition to or in combination with any of the features described in this or the preceding six paragraphs, the consumption restriction may be a location-based restriction that depends on a physical location of the consumer. Furthermore, in addition to or in combination with any of the features described in this or the preceding six paragraphs, the blockchain network may be implemented using a distributed computing infrastructure, preferably Linux Foundation Hyperledger Project, loTivity, OPC-UA, or DCE. Furthermore, in addition to or in combination with any of the features described in this or the preceding six paragraphs, key manager 610 may be further configured to perform continuous integrity monitoring of the external sensor data and to trigger re-encoding of the external sensor data with an updated trust platform asset in case of a detected anomaly or a security breach. Furthermore, in addition to or in combination with any of the features described in this or the preceding six paragraphs, the attestation score may be determined based on an authenticity of the second participating node, an accuracy of the external sensor data, or an historical trustworthiness of the second participating node.

[0039] Furthermore, in addition to or in combination with any of the features described in this or the preceding seven paragraphs with respect to device 600, external sensor data may include a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / Al-generated data), wherein content manager 620 may be configured to determine the attestation score based only on the non-sensor-generated data. Furthermore, in addition toor in combination with any of the features described in this or the preceding seven paragraphs, the external sensor data may include a sensor-generated data (e.g., raw sensor data) and a non- sensor-generated data (e.g., augmented / Al-generated data), wherein the attestation score may indicate a degree of similarity between the sensor-generated data and the non-sensor-generated data. Furthermore, in addition to or in combination with any of the features described in this or the preceding seven paragraphs, the external sensor data may include a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / Al-generated data), wherein the attestation score may be based only on the sensor-generated data

[0040] FIG. 7 depicts a schematic flow diagram of a method 700 for providing a trust platform for sensor data. Method 700 may implement any of the features discussed above with respect to the trust platforms discussed above and / or FIGs. 1-6. Method 700 includes, in 710, provisioning a trust platform asset to a participating node for encoding sensor data of the participating node. Method 700 includes, in 720, determining an attestation score for an external sensor data of a second participating node. Method 700 includes, in 730, recording the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

[0041] In the following, various examples are provided that may include one or more aspects described with reference to the trust platforms discussed above and / or any of FIGs. 1-7. The examples provided in relation to the devices may apply also to the described method(s), and vice versa.

[0042] Example 1 is a system including a key manager configured to provision a trust platform asset to a participating node for encoding sensor data of the participating node. The system includes a content manager configured to determine an attestation score for an external sensor data of a second participating node. The content manager is also configured to record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

[0043] Example 2 is the system of claim 1, wherein the trust platform asset includes a content key for the participating node.

[0044] Example 3 is the system of claim 2, wherein the participating node includes an autonomous agent, wherein the trust platform asset includes an autonomous agent content key (AACK).

[0045] Example 4 is the system of any one of claims 1 to 3, wherein the content key is based on a predefined key derivation logic.

[0046] Example 5 is the system of claim 4, wherein the predefined key derivation logic includes an Advanced Encryption Standard (AES) logic.

[0047] Example 6 is the system of any one of claims 1 to 5, wherein the system further includes a content fusion manager configured to generate an augmented content using an artificial intelligence generation model according to a predefined data usage policy.

[0048] Example 7 is the system of claim 6, wherein the system further includes a policy manager configured to select the predefined data usage policy based on a predefined performance metric.

[0049] Example 8 is the system of any one of claims 1 to 7, wherein the system further includes a mode manager configured to switch a mode of synchronization based on a predetermined synchronization policy for the participating node.

[0050] Example 9 is the system of any one of claims 7 to 8, wherein the mode of synchronization includes a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode.

[0051] Example 10 is the system of any one of claims 7 to 9, wherein the predetermined synchronization policy defines policies to be enforced in a geographic region of the participating node and / or at a timeframe.

[0052] Example 11 is the system of any one of claims 1 to 10, wherein the content manager is configured to determine a time synchronization between the sensor data and external sensor data based on the blockchain network.

[0053] Example 12 is the system of any one of claims 1 to 11, wherein the key manager is configured to statically configure the trust platform asset.

[0054] Example 13 is the system of any one of claims 1 to 12, wherein the key manager is configured to dynamically configure the trust platform asset based on a context in which the sensor data was collected (e.g., geographic location, time, weather conditions, road type, light conditions, etc.).

[0055] Example 14 is the system of any one of claims 1 to 13, wherein the content key is provisioned in a trusted execution environment.

[0056] Example 15 is the system of any one of claims 1 to 14, wherein the content manager is further configured to encode a local sensor data of the participating node with the trust platform asset.

[0057] Example 16 is the system of claim 15, wherein the content manager is configured to determine whether to fuse the external sensor data with the local sensor data based on the attestation score.

[0058] Example 17 is the system of any one of claims 1 to 16, wherein the trust platform asset includes one of a plurality of unique content keys, wherein the content manager is configured to select the one of the plurality of unique content keys based on whether the sensor data is a native sensor data or an augmented sensor data.

[0059] Example 18 is the system of claim 17, wherein the augmented sensor data includes generated sensor data that is generated using an artificial intelligence generation model, wherein the native sensor data includes raw sensor data that is received from a sensor and not generated using the artificial intelligence generation model.

[0060] Example 19 is the system of any one of claims 1 to 18, wherein the attestation score indicates a degree of correlation between the external sensor data and a second sensor data.

[0061] Example 20 is the system of claim 19, wherein the degree of correlation is based on a difference in a geographic location at which the external sensor data and the second sensor data was captured.

[0062] Example 21 is the system of claim 19, wherein the degree of correlation is based on a difference in a multi-modal category in which the external sensor data and the second sensor data was captured (e.g., via a geofence such as a geographic location, a type of weather, a type of terrain, a type of road, a type of environment) with respect to a time period.

[0063] Example 22 is the system of any one of claims 1 to 21, wherein the participating node includes one of a plurality of participating nodes, each with a unique trust platform asset.

[0064] Example 23 is the system of any one of claims 1 to 22, wherein the content manager is configured to use an additive homomorphic encryption to revise the external sensor data and record a revision of the external sensor data to the blockchain network.

[0065] Example 24 is the system of any one of claims 1 to 23, wherein the content manager is configured to specify in the blockchain network a consumption restriction that is applicable to a consumer of the external sensor data encoded with the trust platform asset.

[0066] Example 25 is the system of claim 24, wherein the consumption restriction includes a location-based restriction that depends on a physical location of the consumer.

[0067] Example 26 is the system of any one of claims 1 to 25, wherein the blockchain network is implemented using a distributed computing infrastructure, preferably Linux Foundation Hyperledger Project, loTivity, OPC-UA, or DCE.

[0068] Example 27 is the system of any one of claims 1 to 26, wherein the key manager is further configured to perform continuous integrity monitoring of the external sensor data and to trigger re-encoding of the external sensor data with an updated trust platform asset in case of a detected anomaly or a security breach.

[0069] Example 28 is the system of any one of claims 1 to 27, wherein the attestation score is determined based on an authenticity of the second participating node, an accuracy of the external sensor data, or an historical trustworthiness of the second participating node.

[0070] Example 29 is the system of any one of claims 1 to 28, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non- sensor-generated data (e.g., augmented / Al-generated data), wherein the content manager is configured to determine the attestation score based only on the non-sensor-generated data.

[0071] Example 30 is the system of any one of claims 1 to 29, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the attestation score indicates a degree of similarity between the sensor-generated data and the non-sensor-generated data.

[0072] Example 31 is the system of any one of claims 1 to 30, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the attestation score is based only on the sensorgenerated data.

[0073] Example 32 is a non-transitory, computer-readable medium, including instructions that, when executed by one or more processors, cause the one or more processors to provision a trust platform asset to a participating node for encoding sensor data of the participating node. The instructions also cause the one or more processors configured to determine an attestation score for an external sensor data of a second participating node. The instructions also cause the one or more processors to record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

[0074] Example 33 is the non-transitory, computer-readable medium of claim 32, wherein the trust platform asset includes a content key for the participating node.

[0075] Example 34 is the non-transitory, computer-readable medium of claim 33, wherein the participating node includes an autonomous agent, wherein the trust platform asset includes an autonomous agent content key (AACK).

[0076] Example 35 is the non-transitory, computer-readable medium of any one of claims 32 to 34, wherein the content key is based on a predefined key derivation logic.

[0077] Example 36 is the non-transitory, computer-readable medium of claim 35, wherein the predefined key derivation logic includes an Advanced Encryption Standard (AES) logic.

[0078] Example 37 is the non-transitory, computer-readable medium of any one of claims 32 to 36, wherein the instructions also cause the one or more processors to generate an augmented content using an artificial intelligence generation model according to a predefined data usage policy.

[0079] Example 38 is the non-transitory, computer-readable medium of claim 37, wherein the instructions also cause the one or more processors to select the predefined data usage policy based on a predefined performance metric.

[0080] Example 39 is the non-transitory, computer-readable medium of any one of claims 32 to 38, wherein the instructions also cause the one or more processors to switch a mode of synchronization based on a predetermined synchronization policy for the participating node.

[0081] Example 40 is the non-transitory, computer-readable medium of any one of claims 38 to 39, wherein the mode of synchronization includes a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode.

[0082] Example 41 is the non-transitory, computer-readable medium of any one of claims 38 to 40, wherein the predetermined synchronization policy defines policies to be enforced in a geographic region of the participating node and / or at a timeframe.

[0083] Example 42 is the non-transitory, computer-readable medium of any one of claims 32 to 41, wherein the instructions also cause the one or more processors to determine a timesynchronization between the sensor data and external sensor data based on the blockchain network.

[0084] Example 43 is the non-transitory, computer-readable medium of any one of claims 32 to 42, wherein the instructions also cause the one or more processors to statically configure the trust platform asset.

[0085] Example 44 is the non-transitory, computer-readable medium of any one of claims 32 to 43, wherein the instructions also cause the one or more processors to dynamically configure the trust platform asset based on a context in which the sensor data was collected (e.g., geographic location, time, weather conditions, road type, light conditions, etc.).

[0086] Example 45 is the non-transitory, computer-readable medium of any one of claims 32 to 44, wherein the content key is provisioned in a trusted execution environment.

[0087] Example 46 is the non-transitory, computer-readable medium of any one of claims 32 to 45, wherein the instructions also cause the one or more processors to encode a local sensor data of the participating node with the trust platform asset.

[0088] Example 47 is the non-transitory, computer-readable medium of claim 46, wherein the instructions also cause the one or more processors to determine whether to fuse the external sensor data with the local sensor data based on the attestation score.

[0089] Example 48 is the non-transitory, computer-readable medium of any one of claims 32 to 47, wherein the trust platform asset includes one of a plurality of unique content keys, wherein the instructions also cause the one or more processors to select the one of the plurality of unique content keys based on whether the sensor data is a native sensor data or an augmented sensor data.

[0090] Example 49 is the non-transitory, computer-readable medium of claim 48, wherein the augmented sensor data includes generated sensor data that is generated using an artificial intelligence generation model, wherein the native sensor data includes raw sensor data that is received from a sensor and not generated using the artificial intelligence generation model.

[0091] Example 50 is the non-transitory, computer-readable medium of any one of claims 32 to 49, wherein the attestation score indicates a degree of correlation between the external sensor data and a second sensor data.

[0092] Example 51 is the non-transitory, computer-readable medium of claim 50, wherein the degree of correlation is based on a difference in a geographic location at which the external sensor data and the second sensor data was captured.

[0093] Example 52 is the non-transitory, computer-readable medium of claim 50, wherein the degree of correlation is based on a difference in a multi-modal category in which the external sensor data and the second sensor data was captured (e.g., via a geofence such as a geographic location, a type of weather, a type of terrain, a type of road, a type of environment) with respect to a time period.

[0094] Example 53 is the non-transitory, computer-readable medium of any one of claims 32 to 52, wherein the participating node includes one of a plurality of participating nodes, each with a unique trust platform asset.

[0095] Example 54 is the non-transitory, computer-readable medium of any one of claims 32 to 53, wherein the instructions also cause the one or more processors to use an additive homomorphic encryption to revise the external sensor data and record a revision of the external sensor data to the blockchain network.

[0096] Example 55 is the non-transitory, computer-readable medium of any one of claims 32 to 54, wherein the instructions also cause the one or more processors to specify in the blockchain network a consumption restriction that is applicable to a consumer of the external sensor data encoded with the trust platform asset.

[0097] Example 56 is the non-transitory, computer-readable medium of claim 55, wherein the consumption restriction includes a location-based restriction that depends on a physical location of the consumer.

[0098] Example 57 is the non-transitory, computer-readable medium of any one of claims 32 to 56, wherein the blockchain network is implemented using a distributed computing infrastructure, preferably Linux Foundation Hyperledger Project, loTivity, OPC-UA, or DCE.

[0099] Example 58 is the non-transitory, computer-readable medium of any one of claims 32 to 57, wherein the instructions also cause the one or more processors to perform continuous integrity monitoring of the external sensor data and to trigger re-encoding of the external sensor data with an updated trust platform asset in case of a detected anomaly or a security breach.

[0100] Example 59 is the non-transitory, computer-readable medium of any one of claims 32 to 58, wherein the attestation score is determined based on an authenticity of the second participating node, an accuracy of the external sensor data, or an historical trustworthiness of the second participating node.

[0101] Example 60 is the non-transitory, computer-readable medium of any one of claims 32 to 59, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the instructions further cause the one or more processors to determine the attestation score based only on the non-sensor-generated data.

[0102] Example 61 is the non-transitory, computer-readable medium of any one of claims 32 to 60, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the attestation score indicates a degree of similarity between the sensor-generated data and the non- sensor-generated data.

[0103] Example 62 is the non-transitory, computer-readable medium of any one of claims32 to 61, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the attestation score is based only on the sensor-generated data.

[0104] Example 63 is a method including provisioning a trust platform asset to a participating node for encoding sensor data of the participating node. The method also includes determining an attestation score for an external sensor data of a second participating node. The method also includes recording the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

[0105] Example 64 is the method of claim 63, wherein the trust platform asset includes a content key for the participating node.

[0106] Example 65 is the method of claim 64, wherein the participating node includes an autonomous agent, wherein the trust platform asset includes an autonomous agent content key (AACK).

[0107] Example 66 is the method of any one of claims 63 to 65, wherein the content key is based on a predefined key derivation logic.

[0108] Example 67 is the method of claim 66, wherein the predefined key derivation logic includes an Advanced Encryption Standard (AES) logic.

[0109] Example 68 is the method of any one of claims 63 to 67, wherein the method further includes generating an augmented content using an artificial intelligence generation model according to a predefined data usage policy.

[0110] Example 69 is the method of claim 68, wherein the method further includes selecting the predefined data usage policy based on a predefined performance metric.

[0111] Example 70 is the method of any one of claims 63 to 69, wherein the method further includes switching a mode of synchronization based on a predetermined synchronization policy for the participating node.

[0112] Example 71 is the method of any one of claims 69 to 70, wherein the mode of synchronization includes a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode.

[0113] Example 72 is the method of any one of claims 69 to 71, wherein the predetermined synchronization policy defines policies to be enforced in a geographic region of the participating node and / or at a timeframe.

[0114] Example 73 is the method of any one of claims 63 to 72, wherein method includes determining a time synchronization between the sensor data and external sensor data based on the blockchain network.

[0115] Example 74 is the method of any one of claims 63 to 73, wherein the method further includes statically configuring the trust platform asset.

[0116] Example 75 is the method of any one of claims 63 to 74, wherein the method further includes dynamically configuring the trust platform asset based on a context in which the sensor data was collected (e.g., geographic location, time, weather conditions, road type, light conditions, etc.).

[0117] Example 76 is the method of any one of claims 63 to 75, wherein the method includes provisioning the content key in a trusted execution environment.

[0118] Example 77 is the method of any one of claims 63 to 76, wherein the method includes encoding a local sensor data of the participating node with the trust platform asset.

[0119] Example 78 is the method of claim 77, wherein the method includes determining whether to fuse the external sensor data with the local sensor data based on the attestation score.

[0120] Example 79 is the method of any one of claims 63 to 78, wherein the trust platform asset includes one of a plurality of unique content keys, wherein the method includes selecting the one of the plurality of unique content keys based on whether the sensor data is a native sensor data or an augmented sensor data.

[0121] Example 80 is the method of claim 79, wherein the augmented sensor data includes generated sensor data that is generated using an artificial intelligence generation model, wherein the native sensor data includes raw sensor data that is received from a sensor and not generated using the artificial intelligence generation model.

[0122] Example 81 is the method of any one of claims 63 to 80, wherein the attestation score indicates a degree of correlation between the external sensor data and a second sensor data.

[0123] Example 82 is the method of claim 81, wherein the degree of correlation is based on a difference in a geographic location at which the external sensor data and the second sensor data was captured.

[0124] Example 83 is the method of claim 81, wherein the degree of correlation is based on a difference in a multi-modal category in which the external sensor data and the second sensor data was captured (e.g., via a geofence such as a geographic location, a type of weather, a type of terrain, a type of road, a type of environment) with respect to a time period.

[0125] Example 84 is the method of any one of claims 63 to 83, wherein the participating node includes one of a plurality of participating nodes, each with a unique trust platform asset.

[0126] Example 85 is the method of any one of claims 63 to 84, wherein the method includes using an additive homomorphic encryption to revise the external sensor data and recording a revision of the external sensor data to the blockchain network.

[0127] Example 86 is the method of any one of claims 63 to 85, wherein the method includes specifying in the blockchain network a consumption restriction that is applicable to a consumer of the external sensor data encoded with the trust platform asset.

[0128] Example 87 is the method of claim 86, wherein the consumption restriction includes a location-based restriction that depends on a physical location of the consumer.

[0129] Example 88 is the method of any one of claims 63 to 87, wherein the blockchain network includes implementing a distributed computing infrastructure, preferably Linux Foundation Hyperledger Project, loTivity, OPC-UA, or DCE.

[0130] Example 89 is the method of any one of claims 63 to 88, wherein the method further includes performing continuous integrity monitoring of the external sensor data and triggeringre-encoding of the external sensor data with an updated trust platform asset in case of a detected anomaly or a security breach.

[0131] Example 90 is the method of any one of claims 63 to 89, wherein the attestation score is determined based on an authenticity of the second participating node, an accuracy of the external sensor data, or a historical trustworthiness of the second participating node.

[0132] Example 91 is the method of any one of claims 63 to 90, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non- sensor-generated data (e.g., augmented / AI-generated data), wherein the method further includes determining the attestation score based only on the non-sensor-generated data.

[0133] Example 92 is the method of any one of claims 63 to 91, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the attestation score indicates a degree of similarity between the sensor-generated data and the non-sensor-generated data.

[0134] Example 93 is the method of any one of claims 63 to 92, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the attestation score is based only on the sensorgenerated data.

[0135] Example 94 is an apparatus including a means for provisioning a trust platform asset to a participating node for encoding sensor data of the participating node. The apparatus also includes a means for determining an attestation score for an external sensor data of a second participating node. The apparatus also includes a means for recording the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

[0136] Example 95 is the apparatus of claim 94, wherein the trust platform asset includes a content key for the participating node.

[0137] Example 96 is the apparatus of claim 95, wherein the participating node includes an autonomous agent, wherein the trust platform asset includes an autonomous agent content key (AACK).

[0138] Example 97 is the apparatus of any one of claims 94 to 96, wherein the content key is based on a predefined key derivation logic.

[0139] Example 98 is the apparatus of claim 97, wherein the predefined key derivation logic includes an Advanced Encryption Standard (AES) logic.

[0140] Example 99 is the apparatus of any one of claims 94 to 98, wherein the apparatus further includes a means for generating an augmented content using an artificial intelligence generation model according to a predefined data usage policy.

[0141] Example 100 is the apparatus of claim 99, wherein the apparatus further includes a means for selecting the predefined data usage policy based on a predefined performance metric.

[0142] Example 101 is the apparatus of any one of claims 94 to 100, wherein the apparatus further includes a means for switching a mode of synchronization based on a predetermined synchronization policy for the participating node.

[0143] Example 102 is the apparatus of any one of claims 100 to 101, wherein the mode of synchronization includes a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode.

[0144] Example 103 is the apparatus of any one of claims 100 to 102, wherein the predetermined synchronization policy defines policies to be enforced in a geographic region of the participating node and / or at a timeframe.

[0145] Example 104 is the apparatus of any one of claims 94 to 103, wherein apparatus includes a means for determining a time synchronization between the sensor data and external sensor data based on the blockchain network.

[0146] Example 105 is the apparatus of any one of claims 94 to 104, wherein the apparatus further includes a means for statically configuring the trust platform asset.

[0147] Example 106 is the apparatus of any one of claims 94 to 105, wherein the apparatus further includes a means for dynamically configuring the trust platform asset based on a context in which the sensor data was collected (e.g., geographic location, time, weather conditions, road type, light conditions, etc.).

[0148] Example 107 is the apparatus of any one of claims 94 to 106, wherein the apparatus includes a means for provisioning the content key in a trusted execution environment.

[0149] Example 108 is the apparatus of any one of claims 94 to 107, wherein the apparatus includes a means for encoding a local sensor data of the participating node with the trust platform asset.

[0150] Example 109 is the apparatus of claim 108, wherein the apparatus includes a means for determining whether to fuse the external sensor data with the local sensor data based on the attestation score.

[0151] Example 110 is the apparatus of any one of claims 94 to 109, wherein the trust platform asset includes one of a plurality of unique content keys, wherein the apparatus includes a means for selecting the one of the plurality of unique content keys based on whether the sensor data is a native sensor data or an augmented sensor data.

[0152] Example 111 is the apparatus of claim 110, wherein the augmented sensor data includes generated sensor data that is generated using an artificial intelligence generation model, wherein the native sensor data includes raw sensor data that is received from a sensor and not generated using the artificial intelligence generation model.

[0153] Example 112 is the apparatus of any one of claims 94 to 111, wherein the attestation score indicates a degree of correlation between the external sensor data and a second sensor data.

[0154] Example 113 is the apparatus of claim 112, wherein the degree of correlation is based on a difference in a geographic location at which the external sensor data and the second sensor data was captured.

[0155] Example 114 is the apparatus of claim 112, wherein the degree of correlation is based on a difference in a multi-modal category in which the external sensor data and the second sensor data was captured (e.g., via a geofence such as a geographic location, a type of weather, a type of terrain, a type of road, a type of environment) with respect to a time period.

[0156] Example 115 is the apparatus of any one of claims 94 to 114, wherein the participating node includes one of a plurality of participating nodes, each with a unique trust platform asset.

[0157] Example 116 is the apparatus of any one of claims 94 to 115, wherein the apparatus includes a means for using an additive homomorphic encryption to revise the external sensor data and recording a revision of the external sensor data to the blockchain network.

[0158] Example 117 is the apparatus of any one of claims 94 to 116, wherein the apparatus includes a means for specifying in the blockchain network a consumption restriction that is applicable to a consumer of the external sensor data encoded with the trust platform asset.

[0159] Example 118 is the apparatus of claim 117, wherein the consumption restriction includes a location-based restriction that depends on a physical location of the consumer.

[0160] Example 119 is the apparatus of any one of claims 94 to 118, wherein the blockchain network includes a means for implementing a distributed computing infrastructure, preferably Linux Foundation Hyperledger Project, loTivity, OPC-UA, or DCE.

[0161] Example 120 is the apparatus of any one of claims 94 to 119, wherein the apparatus further includes a means for performing continuous integrity monitoring of the external sensor data and triggering re-encoding of the external sensor data with an updated trust platform asset in case of a detected anomaly or a security breach.

[0162] Example 121 is the apparatus of any one of claims 94 to 120, wherein the attestation score is determined based on an authenticity of the second participating node, an accuracy of the external sensor data, or a historical trustworthiness of the second participating node.

[0163] Example 122 is the apparatus of any one of claims 94 to 121, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / Al-generated data), wherein the apparatus further includes a means for determining the attestation score based only on the non-sensor-generated data.

[0164] Example 123 is the apparatus of any one of claims 94 to 122, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / Al-generated data), wherein the attestation score indicates a degree of similarity between the sensor-generated data and the non-sensor-generated data.

[0165] Example 124 is the apparatus of any one of claims 94 to 123, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / Al-generated data), wherein the attestation score is based only on the sensor-generated data.

[0166] Example 125 is a device including a processor configured to provision a trust platform asset to a participating node for encoding sensor data of the participating node. The processor is also configured to determine an attestation score for an external sensor data of a second participating node. The processor is also configured to record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

[0167] Example 126 is the device of claim 125, wherein the trust platform asset includes a content key for the participating node.

[0168] Example 127 is the device of claim 126, wherein the participating node includes an autonomous agent, wherein the trust platform asset includes an autonomous agent content key (AACK).

[0169] Example 128 is the device of any one of claims 125 to 127, wherein the content key is based on a predefined key derivation logic.

[0170] Example 129 is the device of claim 128, wherein the predefined key derivation logic includes an Advanced Encryption Standard (AES) logic.

[0171] Example 130 is the device of any one of claims 125 to 129, wherein the processor is further configured to generate an augmented content using an artificial intelligence generation model according to a predefined data usage policy.

[0172] Example 131 is the device of claim 130, wherein the processor is further configured to select the predefined data usage policy based on a predefined performance metric.

[0173] Example 132 is the device of any one of claims 125 to 131, wherein the processor is further configured to switch a mode of synchronization based on a predetermined synchronization policy for the participating node.

[0174] Example 133 is the device of any one of claims 131 to 132, wherein the mode of synchronization includes a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode.

[0175] Example 134 is the device of any one of claims 131 to 133, wherein the predetermined synchronization policy defines policies to be enforced in a geographic region of the participating node and / or at a timeframe.

[0176] Example 135 is the device of any one of claims 125 to 134, wherein the processor is further configured to determine a time synchronization between the sensor data and external sensor data based on the blockchain network.

[0177] Example 136 is the device of any one of claims 125 to 135, wherein the processor is further configured to statically configure the trust platform asset.

[0178] Example 137 is the device of any one of claims 125 to 136, wherein the processor is further configured to dynamically configure the trust platform asset based on a context in which the sensor data was collected (e.g., geographic location, time, weather conditions, road type, light conditions, etc.).

[0179] Example 138 is the device of any one of claims 125 to 137, wherein the content key is provisioned in a trusted execution environment.

[0180] Example 139 is the device of any one of claims 125 to 138, wherein the processor is further configured to encode a local sensor data of the participating node with the trust platform asset.

[0181] Example 140 is the device of claim 139, wherein the processor is further configured to determine whether to fuse the external sensor data with the local sensor data based on the attestation score.

[0182] Example 141 is the device of any one of claims 125 to 140, wherein the trust platform asset includes one of a plurality of unique content keys, wherein the processor is further configured to select the one of the plurality of unique content keys based on whether the sensor data is a native sensor data or an augmented sensor data.

[0183] Example 142 is the device of claim 141, wherein the augmented sensor data includes generated sensor data that is generated using an artificial intelligence generation model, wherein the native sensor data includes raw sensor data that is received from a sensor and not generated using the artificial intelligence generation model.

[0184] Example 143 is the device of any one of claims 125 to 142, wherein the attestation score indicates a degree of correlation between the external sensor data and a second sensor data.

[0185] Example 144 is the device of claim 143, wherein the degree of correlation is based on a difference in a geographic location at which the external sensor data and the second sensor data was captured.

[0186] Example 145 is the device of claim 143, wherein the degree of correlation is based on a difference in a multi-modal category in which the external sensor data and the second sensor data was captured (e.g., via a geofence such as a geographic location, a type of weather, a type of terrain, a type of road, a type of environment) with respect to a time period.

[0187] Example 146 is the device of any one of claims 125 to 145, wherein the participating node includes one of a plurality of participating nodes, each with a unique trust platform asset.

[0188] Example 147 is the device of any one of claims 125 to 146, wherein the processor is further configured to use an additive homomorphic encryption to revise the external sensor data and record a revision of the external sensor data to the blockchain network.

[0189] Example 148 is the device of any one of claims 125 to 147, wherein the processor is further configured to specify in the blockchain network a consumption restriction that is applicable to a consumer of the external sensor data encoded with the trust platform asset.

[0190] Example 149 is the device of claim 148, wherein the consumption restriction includes a location-based restriction that depends on a physical location of the consumer.

[0191] Example 150 is the device of any one of claims 125 to 149, wherein the blockchain network is implemented using a distributed computing infrastructure, preferably Linux Foundation Hyperledger Project, loTivity, OPC-UA, or DCE.

[0192] Example 151 is the device of any one of claims 125 to 150, wherein the processor is further configured to perform continuous integrity monitoring of the external sensor data and to trigger re-encoding of the external sensor data with an updated trust platform asset in case of a detected anomaly or a security breach.

[0193] Example 152 is the device of any one of claims 125 to 151, wherein the processor is further configured to determine the attestation score based on an authenticity of the second participating node, an accuracy of the external sensor data, or an historical trustworthiness of the second participating node.

[0194] Example 153 is the device of any one of claims 125 to 152, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / AI-generated data), wherein the processor is further configured to determine the attestation score based only on the non-sensor-generated data.

[0195] Example 154 is the device of any one of claims 125 to 153, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generateddata (e.g., augmented / Al-generated data), wherein the attestation score indicates a degree of similarity between the sensor-generated data and the non-sensor-generated data.

[0196] Example 155 is the device of any one of claims 125 to 154, wherein the external sensor data includes a sensor-generated data (e.g., raw sensor data) and a non-sensor-generated data (e.g., augmented / Al-generated data), wherein the attestation score is based only on the sensor-generated data.

[0197] While the disclosure has been particularly shown and described with reference to specific aspects, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims. The scope of the disclosure is thus indicated by the appended claims and all changes, which come within the meaning and range of equivalency of the claims, are therefore intended to be embraced.

Claims

CLAIMSClaimed is:

1. A system comprising: a key manager configured to provision a trust platform asset to a participating node for encoding sensor data of the participating node; and a content manager configured to: determine an attestation score for an external sensor data of a second participating node; and record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

2. The system of claim 1, wherein the trust platform asset comprises a content key for the participating node.

3. The system of claim 2, wherein the participating node comprises an autonomous agent, wherein the trust platform asset comprises an autonomous agent content key (AACK).

4. The system of any one of claims 1 to 3, wherein the content key is based on a predefined key derivation logic.

5. The system of claim 4, wherein the predefined key derivation logic comprises an Advanced Encryption Standard (AES) logic.

6. The system of any one of claims 1 to 5, wherein the system further comprises a content fusion manager configured to generate an augmented content using an artificial intelligence generation model according to a predefined data usage policy.

7. The system of claim 6, wherein the system further comprises a policy manager configured to select the predefined data usage policy based on a predefined performance metric.

8. The system of any one of claims 1 to 7, wherein the system further comprises a mode manager configured to switch a mode of synchronization based on a predetermined synchronization policy for the participating node.

9. The system of any one of claims 7 to 8, wherein the mode of synchronization comprises a centralized synchronization server mode, a distributed ledger synchronization mode, or a hybrid mode.

10. The system of any one of claims 7 to 9, wherein the predetermined synchronization policy defines policies to be enforced in a geographic region of the participating node and / or at a timeframe.

11. The system of any one of claims 1 to 10, wherein the content manager is configured to determine a time synchronization between the sensor data and external sensor data based on the blockchain network.

12. The system of any one of claims 1 to 11, wherein the key manager is configured to: statically configure the trust platform asset; or to dynamically configure the trust platform asset based on a context in which the sensor data was collected, wherein the context is a geographic location, a time, a weather condition, a road type, or a light condition.

13. The system of any one of claims 1 to 12, wherein the content key is provisioned in a trusted execution environment.

14. The system of any one of claims 1 to 13, wherein the content manager is further configured to encode a local sensor data of the participating node with the trust platform asset.

15. The system of any one of claims 1 to 14, wherein the content manager is configured to determine whether to fuse the external sensor data with the local sensor data based on the attestation score.

16. The system of any one of claims 1 to 15, wherein the trust platform asset comprises one of a plurality of unique content keys, wherein the content manager is configured to select the one of the plurality of unique content keys based on whether the sensor data is a native sensor data or an augmented sensor data.

17. The system of claim 16, wherein the augmented sensor data comprises generated sensor data that is generated using an artificial intelligence generation model, wherein the native sensor data comprises raw sensor data that is received from a sensor and not generated using the artificial intelligence generation model.

18. A device comprising a processor configured to: provision a trust platform asset to a participating node for encoding sensor data of the participating node; determine an attestation score for an external sensor data of a second participating node; and record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

19. The device of claim 18, wherein the attestation score indicates a degree of correlation between the external sensor data and a second sensor data.

20. The device of claim 19, wherein the degree of correlation is based on a difference in a geographic location at which the external sensor data and the second sensor data was captured.

21. The device of claim 19, wherein the degree of correlation is based on a difference in a multi-modal category in which the external sensor data and the second sensor data was captured, wherein , the multi-modal category comprises a geofence, a geographic location, a type of weather, a type of terrain, a type of road, a type of environment, or a time period.

22. A non-transitory, computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to: provision a trust platform asset to a participating node for encoding sensor data of the participating node; determine an attestation score for an external sensor data of a second participating node; and record the attestation score and the external sensor data encoded with the trust platform asset in a blockchain network.

23. The non-transitory, computer-readable medium of claim 22, wherein the participating node comprises one of a plurality of participating nodes, each with a unique trust platform asset.

24. The non-transitory, computer-readable medium of any one of claims 22 to 23, wherein the instructions also cause the one or more processors to revise the external sensor data with an additive homomorphic encryption and to record a revision of the external sensor data to the blockchain network.

25. The non-transitory, computer-readable medium of any one of claims 22 to 24, wherein the instructions also cause the one or more processors to specify in the blockchain network a consumption restriction that is applicable to a consumer of the external sensor data encoded with the trust platform asset, wherein the consumption restriction comprises a location-based restriction that depends on a physical location of the consumer.

Images