WO2024243358A2 - Content verification - Google Patents

Abstract

Technology is provided for object validation. A device for object validation may include data processing hardware, and memory hardware in communication with the data processing hardware. The memory hardware may storing instructions that when executed on the data processing hardware may cause the data processing hardware to perform operations including: computing, at the device, a hash of a digital file based on metadata and a proof; storing, using the device, the digital file on a data repository; signing, using the device, content of the digital file and one or more transactions stamping the content on a chain; and verifying, at the device, the digital file using the hash.

Description

CONTENT VERIFICATION

RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No.

63/503,584, filed May 22, 2023, U.S. Provisional Application No. 63/517,066, filed August 1, 2023, and U.S. Provisional Application No. 63/607,099, filed December 7, 2023, the disclosures of which are each incorporated herein by reference in their entirety.

[0002] This disclosure relates to decentralized networking and computing including aspects relating to proof of connectivity, location, and origin.

BACKGROUND

[0003] Unless otherwise indicated herein, the materials described herein are not prior art to the claims in the present application and are not admitted to be prior art by inclusion in this section.

[0004] Digital content may be faked in various ways, including by using artificial intelligence (Al). Determining whether the digital content is an original or has been artificially generated by Al may be difficult. Digital content may also be faked in other ways including: data poisoning, byzantine attacks, evasion attacks, model extraction, or the like. Therefore, devices, systems, and methods for verifying digital content may be useful.

[0005] The subject matter claimed herein is not limited to implementations that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some implementations described herein may be practiced. SUMMARY

[0006] With the widespread adoption of artificial intelligence (Al), mission critical data may be verified. An enterprise data verification stack may be built on the blockchain to allow data (like photos, videos and sensor data) to be protected and audited by third parties in a zero trust environment. This may prevent fake data from being uploaded and data from being manipulated after capture.

[0007] In some cases, an offender may try to claim that evidence is not acceptable. The offender may claim it was produced by the system or by generative Al. With more and more deep-fakes, this argument might be received by a court if not backed with strong technical evidence of the authenticity of the content.

[0008] In some cases, people may want to spam a system with fake data with the intent to take it down (Denial of Service) or in order to try to make it very difficult for the system to cope. Malicious data may be injected that can alter key business functions and economic success.

[0009] In some cases, content verification may be “backed up” in multiple places. If content is maliciously uploaded or modified within a content repository, there may be a way to ensure this can be flagged, removed, and original content be verified as authentic.

[0010] Mission critical data may have substantial financial value and may be auditable by an independent third party. The disclosure allows for independent third parties to verify data integrity.

[0011] The disclosure allows for smartphone data capture and 3rd party data sources like sensor streams (e.g. internet protocol (IP) video cameras) and edge compute devices. Sensor- signed data streams (e.g. a phone camera signing the image) may be supported pushing the root of trust to the edge. [0012] Centralized (e.g. S3 Cloud storage) and decentralized data storage (e.g. IPFS) may be used. Data storage nodes may be hosted privately to create redundancy and protect data from unauthorized access. Content may be stored within a closed enterprise environment and may not be public. Only the hash or "reference" of the content may be written on-chain and may be further obfuscated based on security standards. The system may use further obfuscation (for example off-chain Merkle trees) to further obfuscate data written on-chain. [0013] This disclosure provides blockchains that may be energy-efficient and secure. Public blockchains have the benefit of strong immutability, where in contrast private blockchains are no more secure than a distributed database. However, this disclosure may support both public and private chain deployments. Public blockchains may increase the cost of an attack when compared with private chain deployments. This disclosure may provide verification APIs and Source code to match the signature of content locally, with its on-chain reference.

[0014] In one example, a device for digital file verification, may include data processing hardware; and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware cause the data processing hardware to perform operations comprising: computing, at the device, a hash of a digital file based on metadata and a proof; storing, using the device, the digital file on a data repository; signing, using the device, content of the digital file and one or more transactions stamping the content on a chain; and verifying, at the device, the digital file using the hash.

[0015] In another example, a computer-implemented method may include: identifying a digital file; verifying the digital file using metadata associated with the digital file; and minting a non-fungible token (NFT) using the digital file and the metadata associated with the digital file. [0016] In another example, a device may include data processing hardware; and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware cause the data processing hardware to perform operations comprising: identifying, at the device, a block chain header and a public key; capturing, at the device, content using the block chain header and the public key; generating, at the device, attested content based on the content; signing, at the device, the attested content using a unique device certificate to generate signed attested content; and pushing, at the device, a hash of the signed attested content onto a chain by signing with a user wallet.

[0017] The objects and advantages of the disclosure will be realized and achieved at least by the elements, features, and combinations particularly pointed out in the claims. Both the foregoing general description and the following detailed description are given as examples and are explanatory and are not restrictive of the invention, as claimed.

DESCRIPTION OF DRAWINGS

[0018] Examples will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0019] FIG. l is a schematic view of a network architecture including one or more endpoint devices, one or more intermediate devices, one or more relay servers, and one or more endpoint manager servers in accordance with some implementations of the present disclosure.

[0020] FIGS. 2A-2D are schematic views illustrating functionality using a network architecture in accordance with some implementations of the present disclosure.

[0021] FIGS. 3 A illustrates an example process flow for object validation.

[0022] FIG. 3B illustrates an example process flow for object validation using a non- fungible token (NFT). [0023] FIG. 3C illustrates an example process flow for digital image validation using a non-fungible token (NFT).

[0024] FIG. 4 A illustrates an example process flow for capturing a digital image.

[0025] FIG. 4B illustrates an example process flow for validating an object using a blockchain.

[0026] FIG. 4C illustrates an example for minting a non-fungible token (NFT).

[0027] FIG. 4D illustrates an example for validating a video.

[0028] FIG. 4E illustrates an example for validating a video.

[0029] FIG. 4F illustrates an example process flow for validating a video using a blockchain.

[0030] FIG. 5 illustrates an example block diagram for verifying a digital file using digital certificates.

[0031] FIG. 6 A illustrates an example process flow for validating a digital file.

[0032] FIG. 6B illustrates an example process flow for validating a digital file.

[0033] FIG. 6C illustrates an example process flow for validating a digital file.

[0034] FIG. 7 is a schematic view illustrating a machine in the example form of a computing device.

[0035] FIG. 8 illustrates an exemplary device configured to run a host application.

[0036] FIG. 9 illustrates an example block diagram for providing for content verification.

[0037] FIGS. 10A - 10G illustrates a number of user interfaces for an exemplary host application.

DETAILED DESCRIPTION

[0038] Conventional systems may lack techniques for validating different objects such as digital information and/or media. Digital information may be difficult to validate with the proliferation of artificial intelligence (Al) tools for modifying digital content. For example, digital photos may be generated using Al tools without capturing the corresponding image in a native format. Even when the corresponding image is captured in a native format, the digital image may be modified using Al tools or other digital image editing tools.

Furthermore, for creators of digital artwork, correct attribution may be not be simple without an explicit origin. Moreover, distributing a digital image without losing data relating to attestation, authenticity, provenance, or the like may be difficult without a distributed way of verifying a digital image.

[0039] For example, people may want to report fake infractions by creating images via generative Al of a real vehicle with a real license plate depicted in a wrong situation, therefore punishing innocent people for the aim of financial reward.

[0040] Real reports accused of being faked: In court, a nuisance parking offender may claim that the evidence presented is not acceptable because it was produced by generative Al. With more and more deep fakes, this argument might be received by the court if not backed with strong technical evidence of the authenticity of the content.

[0041] Spam reports: People might want to spam the system with fake reports with the intent to take it down (Denial of Service) or in order to try to make it very difficult for the system to cope. Generative Al would make this process particularly difficult to address. Malicious third parties may attempt to attack the system, in a similar fashion to hackers conducting Distributed Denial of Service attacks (DDoS Attacks) on city infrastructure.

[0042] Replay attacks: People might want to replay an authentic infraction that was valid and that helped them get a reward. Real reports could be modified (for example changing the license plate) to attempt to claim a reward.

[0043] Cyberattack: City infrastructure may be targeted by hackers. Content verification may be “backed up” in multiple places (leveraging a blockchain with many nodes for example). If content is maliciously uploaded or modified within a content repository, there may be a way to ensure this can be flagged and removed.

[0044] Therefore, videos may be used as part of an Evidence Package that may be proven to have been taken at the right location, at the right time; without alterations.

[0045] For the video recorded by the camera installed on a vehicle (e.g., a bus), cameras and compute modules located on busses may have more security in the system. But defects may still occur.

[0046] The certification and verification of video records may be provided. As generative Al continues to be deployed, the validity and resistance to tampering of data may be used for enterprise operations and public safety. The immutability of recorded infractions may be provided to prevent tampering which may provide videos of infractions that may not be "faked" (e.g., generated by Al).

[0047] The combination of a public blockchain with a private content repository may enhance privacy and data immutability.

[0048] Private blockchains may rely on centralized control. Content may be illicitly modified, and the blockchain may be forked to reflect these changes. From a data security perspective, a private blockchain may be no more immutable than a traditional centralized database. Deploying more nodes on a private blockchain may increase security but increase the cost of operation.

[0049] An app may allow people (e.g., bicyclists) to report vehicles illegally parked in a bike lane. A similar self-reporting system may be used to report idling trucks that may be releasing toxic carbon monoxide. Reporting may free up bike lanes from obstruction which may enhance safety for bicyclists and enable bike lanes to be used for last mile delivery. The system may be configured to prevent the generation of fake reports and the alteration of images after the fact. [0050] A layer of authenticity may be facilitated for video records ensuring they are robust.

An app may use a software development kit (SDK) configured to provide secure video recording. Some features may include: (i) e.g., Android® and iOS® SDK, (2) smart contracts (’’pallets”) on-chain that may allow the app to perform a transaction, (3) a data storage architecture, (4) a funding of the transactions in the native tokens, and (5) technical support.

[0051] Some features may be used with a camera on a vehicle (e.g., a bus) including an SDK for e.g., Linux which may include functionality that include e.g.., (i) a command line interface to verify the authenticity of a video record, or (ii) technical support.

[0052] Proving connectivity, authenticity, and/or origin may be achieved in various ways. The proof may be used to prove the origin and authenticity of a piece of content (e.g., a digital image). In some instances, the proof may be tokenized. For a digital image, proof of authenticity and/or origin may enhance the value of a digital image - which may be viewed as an original negative.

[0053] A device for object validation may comprise data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware may cause the data processing hardware to perform operations. The operations may comprise: identifying an object identifier for an object; generating a non-fungible token (NFT) based on the object; generating an NFT proof using NFT metadata and the object identifier; and pushing the NFT proof to a blockchain.

[0054] The proposed architecture may be composed of the following sub -components.

[0055] A secure app: the host app embedding an SDK. The SDK may ensure that content is taken by a non-compromised device (not rooted, or in developer mode) and that all metadata is correct (e.g. time and location). The host app may generate a wallet public private key pair that is only known by the app itself - no parties will have access to it.

[0056] A secure and public blockchain: The blockchain may use proof-of-stake blockchain which may be energy-efficient and upgradeable. The chain may be decentralized through the hundreds of validators all over the world that constitute the decentralized infrastructure.

[0057] A private data repository: The content storage may hold video content and may serve media content when provided with the media hash. The files may be kept secure for a time period based on a per use-case period, e.g., for a period of 3 months, 1 year, 3 years, 5 years, or the like e.g., using cloud based storage (such as Amazon Web Services (AWS)® or Google® cloud).

[0058] Verification tools: A user with access may independently verify content via e.g., a Command Line Interface (CLI) to allow independent parties to get the content hash from the content and provide all the meta data. Other components may be used such as an authenticated indexer and an application protocol interface (API). The API may allow other parties to query the blockchain from the hash of a content. A web interface may retrieve the content and compare the hash.

[0059] Referring to FIG. 1, in some implementations, an example network architecture 100 may include one or more endpoint devices 105a-d, one or more intermediate devices 115a-d, one or more relay servers 125a-b, and one or more endpoint manager servers 135a. In some implementations, the network architecture 100 is capable of moving or transferring data (e.g., message, desired information, desired measurement data) between one or more endpoint devices 105a-d and various endpoint manager servers 135a by way of crowdsourced intermediate devices 115a-d, which can be implemented as network clients, and one or more relay servers 125a-b. In at least one implementation, the one or more endpoint devices 105a-d may be referred to as edge devices (“ED”). In at least one implementation, the one or more endpoint devices 105a-d and the one or more intermediate devices 115a-d may collectively be referred to as edge devices (“EDs”). In some implementations, the network architecture 100 is capable of providing “hotspot” service to one or more of the edge devices ED directly or in-directly. In some implementations, the network architecture 100 is capable of providing “hotspot” service to one or more of the endpoint devices 105a-d using a short-range wireless network.

[0060] In some implementations, an endpoint device 105a-d includes one or more Internet of Things (loT) devices 11 la-d. To support the operation of the loT device 11 la-d, the endpoint device 105a-d may include a power supply 112a-d, a data collection device 113a-d (e.g., sensor, meter, device capable of sensing environment or person), and a network device 114a-d. The power supply 112a-d may include a battery and/or a connection to a power grid. Additionally or alternatively, the power supply 112a-d may include an energy harvesting apparatus, such as a solar panel, solar cell, solar photovoltaic, electromagnetic, etc. In at least some implementations, the endpoint device 105a-d does not include a power supply and use ambient backscatter or other suitable techniques instead to operate the endpoint device 105a-d. The data collection device 113a-d in the endpoint device 105a-d may include one or more sensors. The one or more sensors may be configured to detect any type of condition (e.g., environmental condition, human condition), and generate electronic data based on a detected condition. For example, the endpoint device 105a-d may include a smart watch with a heart rate monitor (configured with the heart rate sensor) that is configured to generate heart rate data based on heart rate conditions collected by the heart rate sensor. In at least one implementation, the endpoint device 105a-d does not have capability to communicate over the Internet and includes hardware and/or software capable of communicating with nearby devices, such as a nearby intermediate device 115a-d, using one short-range wireless protocol or a combination of short-range wireless protocols. In some implementations, the endpoint device 105a-d includes a data storage which is used to store the condition measurement data. In some implementations, the endpoint device 105a-d is configured to transmit the stored data to a device (e.g., intermediate device 115a-d) when the endpoint device 105a-d is in data communication with the device.

[0061] The network device 114a-d of the endpoint device 105a-d may include any suitable hardware, software, or combination thereof that is capable to communicate with another device (e.g., intermediate device 115a-d) via a network. In at least one implementation, the network device 114a-d includes a network controller 116a-d configured to communicate via a short-range network, such as a network implemented with Bluetooth® protocols or any other suitable type of short-range network. In at least one implementation, the network device 114a-d may include a network controller 116a-d configured to communicate via a low-power network (e.g., a suitable network that supports transmit powers from 0.01 mW to lOOmW). In some implementations, the network controller 116a-d may be configured to communicate via a low-power and short-range network (e.g., Bluetooth® network). Example endpoint devices 105a-d may include, but are not limited to, industrial devices, residential appliances, commercial equipment, inventory trackers, smart watches, wearables, heart rate monitors, logistics trackers, environmental sensors, cash registers, credit card readers, point-of-sale (POS), bikes, electric scooters, electric skate boards, cars, electric cars, satellites, or any device (mobile and not mobile that includes a wireless radio interface). In accordance with some implementations of the present disclosure, the network architecture 100 may include any number of endpoint devices 105a-d, and the endpoint devices 105a-d in the network architecture 100 may be any type of endpoint device 105a-d, including any type of network-capable device. The endpoint devices 105a-d may be fixed or relatively stationary in the network architecture 100, such as a POS or a pollution sensing device. Additionally or alternatively, the endpoint devices 105a-d may be mobile, such as a smart watch, or any vehicle categories (e.g., car, truck, bike, kickboard).

[0062] As illustrated in FIG. 1, in some implementations, the one or more endpoint devices 105a-d may be configured to communicate with other devices (e.g., intermediate devices 115a-d) in the network via at least one first wireless network 1 lOa-d. For example, an endpoint device 105a in FIG. 1 may be in electronic communication (e.g., data communication) with an intermediate device 115a via a first wireless network 110a. The one or more intermediate devices 115a-d may include any kind of device capable of communicating with the endpoint device 105a-d via the first wireless network 1 lOa-d and with the relay server 125a-b via a second network 120a-b. In at least one implementation, the intermediate device 115a-d includes two network controllers: a first network controller 117a- d to communicate via the first wireless network 1 lOa-d and a second network controller 118a-d to communicate via the second network 120a-b. Example intermediate devices 115a- d include personal computers (PC), laptops, smart phones, netbooks, e-readers, personal digital assistants (PDA), cellular phones, mobile phones, tablets, vehicles, drones, cars, trucks, wearable devices, routers, televisions, or set top boxes, etc.

[0063] As illustrated in FIG. 1, in some implementations, the first endpoint device 105a may be in electronic communication with the first intermediate device 115a via the first wireless network 110a (e.g., a short-range network with a range between 10 meters and 100 meters). Further, an endpoint device 105b may be in electronic communication with an intermediate device 115b via a first wireless network 110b. An endpoint device 105c may be in electronic communication with an intermediate device 115c via a first wireless network 110c. An endpoint device 105d may be in electronic communication with an intermediate device 115d via a first wireless network 1 lOd. [0064] In some implementations, the first wireless network 1 lOa-d may be any network that consumes or uses a relatively low amount of power (e.g., power between 0.01 mW and lOOmW). At least some example of the first wireless networks 110 include Bluetooth® network (e.g., Bluetooth Low Energy (BLE), Bluetooth 4.0, Bluetooth 5.0, Bluetooth Long Range), NarrowBand-IoT (NB-IoT) network, Long-Term Evolution (LTE) Direct network, LTE for Machines (LTE-M) network, LTE Machine-to-Machine (LTE M2M) network, 5G network, Wireless Fidelity (Wi-Fi) network, Wi-Fi Aware network, or any low-power network and/or short-range network.

[0065] As illustrated in FIG. 1, in some implementations, the one or more endpoint devices 105a-d may connect to various intermediate devices 115a-d using different kind of first wireless networks 1 lOa-d. For example, the first endpoint device 105a may be in electronic communication (e.g., data communication) with the first intermediate device 115a via a first wireless network 110a implemented with the BLE, and the second endpoint device 105b may be in electronic communication with the second intermediate device 115b via a first wireless network 110b implemented with other type of the short-range wireless network. [0066] In some implementations, the first wireless network 1 lOa-d and the second network 120a-b are different types of networks. For example, the first wireless network 110 may be a Bluetooth® network and the second network 120a-b may be a cellular network, WiFi, or the Internet. For example, the second network 120a-b may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), a wired network (e.g., Ethernet network), a wireless network (e.g., an 8O2.xx network or a Wi-Fi network), a cellular network (e.g., a Long Term Evolution (LTE) or LTE- Advanced network, 1G network, 2G network, 3G network, 4G network, 5G network, etc.), routers, hubs, switches, server computers, and/or a combination thereof. [0067] In some implementations, a third network 130, that connects the relay servers

125a-b to the endpoint manager server 135a, may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN), a wired network (e.g., Ethernet network), a wireless network (e.g., an 802. xx network or a WiFi network), a cellular network (e.g., a Long Term Evolution (LTE) or LTE-Advanced network, 1G network, 2G network, 3G network, 4G network, 5G network, etc.), routers, hubs, switches, server computers, and/or a combination thereof. In at least one implementation, the second network 120a-b and the third network 130 may be the same network or include at least some overlapping components. In some implementations, at least some portion of the relay servers 125a-b, third network 130, and endpoint manager server 135a may be a network architecture 200 (e.g., cloud server) (as illustrated in FIG. 2A and 2D) (e.g., distributed computing network). For example, relay servers 125a-b, third network 130, and endpoint manager server 135a may form a distributed computing network that may interact with the intermediate devices 115a-d and endpoint devices 105a-d. The edge devices ED (e.g., intermediate device 115a-d) may be included in the cloud server 200 for edge devices ED configured to collect and/or process desired data.

[0068] Endpoint devices 105a-d, intermediate devices 115a-d, or both, may be fixed, relatively stationary, or moveable. When an endpoint device 105a-d and an intermediate device 115a-d come into wireless range of each other (e.g., 10 meters), the endpoint device 105a-d and the intermediate device 115a-d may perform a handshake and/or authentication to initiate data exchange between the endpoint device 105a-d and the intermediate device 115a- d in accordance with some implementations. For example, an intermediate device 115a-d may be configured to provide “hotspot” service to an endpoint device 105a-d after the authentication. In some implementations, the “hotspot” service may be provided to the endpoint device 105a-d by executing code (e.g., program 204 shown in FIG 2a) on a virtual environment 202 (shown in FIG. 2a) of the intermediate device 115a-d.

[0069] The endpoint device 105a-d may be configured to periodically or randomly send or transmit a beacon signal 140a-d or a beacon signal 140a-d that includes data (e.g., data that identify the transmitting endpoint device 105a-d, data measured or received by the transmitting endpoint device 105a-d) via the first wireless network 1 lOa-d. The endpoint devices 105a-d may include various services that may run on the endpoint devices 105a-d. For example, a smart watch may include a clock service, a heart rate monitor service, a motion detection service, a music service, etc. Separate beacon signals 140a-d may be generated for each of these services or a single beacon signal may be generated to include data for some or all of the services.

[0070] In some implementations, a service can execute on-demand Bluetooth Low Energy (BLE) conversations in order to read/write information from/to the endpoint device 105a-d (e.g., loT device 11 la-d in the endpoint device 105a-d). This works by running custom-made code (e.g., instructions or code capable of running on a virtualization environment and/or containerization environment such as bytecode and containerized program) on virtual environment 202 (e.g., virtual machine, container) operating on the edge device ED (endpoint device 105a-d and/or the intermediate device 115a-d). This code (e.g., bytecode, containerized program) is also referred to as a "Smart exchange" or “SX” in the present disclosure. In some implementations, the virtual environment 202 exposes certain opcode allowing basic networking operations such as BLE read/write, http get/post, or dtn send. Because the virtual environment 202 is Turing complete, it is possible to run any kind (or version) of BLE protocol.

[0071] The edge devices ED (e.g., the endpoint devices 105a-d and/or the intermediate devices 115a-d) may include circuitry (e.g., hardware, software, or a combination thereof) that may be configured to execute the code (also referred to as “program 204” in this disclosure) locally. In at least one implementation, the circuitry includes the virtual environment 202 where the code is run on. The virtual environment 202 may include an interpreter that can execute a program 204 (e.g., bytecode, containerized program) written in any programming language, such as in Nodle Assembly (NASM). A benefit to the virtual environment 202 residing inside an edge device ED (e.g., the endpoint devices 105a-d and/or the intermediate devices 115a-d) may include an ability to selectively execute the program 204 responsive to one or more predetermined conditions (e.g., trigger event). Additional benefits of the virtual environment 202 residing inside the edge device ED may include that the program 204 can be selectively pushed from the network architecture 200 (e.g., cloud server) to edge devices ED - bypassing the application stores (e.g., Play Store by Google, App Store by Apple). Further, the same program 204 can be pushed and installed onto different edge devices ED regardless of version and/or type of the operating system installed on the edge devices ED (e.g., version of Android, or iPhone® operating system (iOS)). However, the present disclosure does not limit that the form of the program 204. The program 204 may be included in an application that is available at the application stores. The program 204 may be included to an operating system of the edge device ED. By executing the program 204, the owner of the edge device ED may receive reward (e.g., cryptocurrency) from the distributor or operator of the program (e.g., author of the program 204).

[0072] A program 204 may be configured to cause one edge device ED (endpoint device 105a-d and/or intermediate device 115a-d) to communicate (e.g., sharing, relaying, routing data or message) with another edge device ED (endpoint device 105a-d and/or intermediate device 115a-d) nearby using a short-range wireless network (e.g., first wireless network 1 lOa-d). In a specific example, a group of edge devices ED are selected to have the program 204 installed (relay service program in this example). Based on the program 204, the edge devices ED are configured to provide data and/or message relay service. For instance, an endpoint manager server 135a may send or transmit a message 150 (e.g., advertisement, announcement, information, data, firmware, program 204) to one of the edge devices ED (intermediate device 115a in this example) configured with the program 204. In some implementations, the edge device ED (intermediate device 115a), which received the message 150 from the endpoint manager server 135a, may relay or transmit the message 150 to other edge devices ED nearby (intermediate device 115b in this example) configured with the program 204 via the short-range wireless network (e.g., first wireless network 1 lOa-d). Similarly, the message 150 \may be relayed or propagated from the intermediate device 115b to the intermediate device 115c via the short-range wireless network (e.g., first wireless network 1 lOa-d) and then from the intermediate device 115c to the intermediate device 115d via the short range wireless network (e.g., first wireless network 1 lOa-d). In some implementations, similarly, the message 150 may be transmitted or propagated to nearby endpoint devices 105a-d (endpoint devices 105a-d in this example) installed with the program 204. For example, the message 150 may be relayed or transmitted between the endpoint devices 105a-d nearby. In other words, the message 150 from the endpoint manger server 135a may be delivered to edge devices ED configured with the program 204 in a particular area using the short-range wireless network (e.g., first wireless network 1 lOa-d). In some implementations, each of the intermediate devices 115a-d may receive the message 150 and may relay or transmit the message 150 to endpoint devices 105a-d nearby via the short-range wireless network (e.g., first wireless network 1 lOa-d). In this manner, local, ad-hoc networks of devices may be created.

[0073] A server, for example, may push an instruction that may be received by at least one device. That device, may establish a network and may forward the instruction to any other device within range. Those devices may join the network, and can forward the instructions again to other devices within their respective range. In this manner, instructions for creating networks can be propagated. In some examples, the instruction may include a network limiter, which may be geography-based, size-based, number of joined devices-based, time-based, etc. In a geography-based limitation on a network, for example, the instruction may include an identification of a central point for the network, such a global positioning system (GPS) location, latitude/longitude coordinates, etc. and a distance from that central point where the network is permitted. For example, a stadium can be selected as the central point, a distance from that central point, such as a boundary to substantially encompass the stadium, as well as a time in which the network may expire, such as after a sports event. For devices that receive the instruction to join the network, those devices can perform a check first to see if the criteria is met, and if so, those devices can join the network. If at least one of the criteria is not met (e.g., out of range, beyond the time limit, etc.) then the device may not join the network. The potentially joining device, for example, can check its own location (e.g., actual location, distance from the central point, etc.) to see if it is within the range. Devices that join the network, for example, can append data to instructions that are forwarded. For example, a number of devices that are joined can be data included in the instructions and a potentially joining device can check that number versus a total allowable number of devices on the network. That potentially joining device can join the network if there are still available spots for devices and may not join if there are no more available spots. As devices leave the network, other devices may join, and may even receive a notification that the network is now available to join.

[0074] The intermediate devices 115a-d and endpoint devices 105a-d (that are configured with the program 204) may form one mesh network using the short-range wireless network

(e.g., first wireless network HOa-d) so information (e.g., data 140, message 150) may be transmitted between devices (e.g., endpoint devices 105a-d, intermediate devices 115a-d) within the mesh network using the short-range wireless network (e.g., first wireless network).

[0075] In another example, the edge device ED (intermediate device 115a in this example), which receives data 208 (e.g., data collected from loT device/endpoint device) from an endpoint device 105a may relay or transmit the data 208 to other intermediate devices 115b-d/endpoint devices 105b-d nearby similar to the message 150 above (e.g., using mesh network, using intermediate device-to-intermediate device network, using endpoint device-to-endpoint device network, using intermediate device-to-endpoint device network). This method may be helpful when the intermediate device 115a does not have an access to a second network 120a. Using this method, the data 208 may be relayed to the intermediate device 115d via various routes and transmitted to the endpoint server 135a via the second network 120b. Thus, a “hotspot” service may be provided to the edge device ED (endpoint device 105a and intermediate device 115a in this example) using the program 204 based on the short-range wireless network (e.g., first wireless network 1 lOa-d). Any type of data may be sent to and via the network, including targeted advertisements that are time-based and could also be interest-based. For example, continuing the sports event example from above, an advertisement that could be more applicable to the audience in the stands at the time could be sent, such as for merchandise, or could be for a coupon to the concessions stand at the stadium.

[0076] Each of the intermediate devices 115a-s may be configured to listen or detect the beacon signals 140a-d transmitted from surrounding endpoint devices 105a-d. In response to receiving the beacon signals 140a-d, the intermediate devices 115a-d, which detected the beacon signal 140a-d, may send or forward the beacon signals 140a-d to a (corresponding and/or nearby) relay server 125a-b via a second network 120a-b. The first wireless network 1 lOa-d and the second wireless network 120a-b may be different networks (e.g., different network types, different coverage ranges). For example, the first wireless network 1 lOa-d may be a Bluetooth® network or a short-range network and the second wireless network 120a-b may be a cellular network, Wi-Fi®, or the Internet (which may provide a wider coverage than the short-range network).

[0077] Each of the relay servers 125a-b may be configured to receive the beacon signals 140a-d from the edge device ED (intermediate device 115a-d in this example) connected via the second network 120a-b. Each of the relay servers 125a-b may be configured to send or forward the beacon signals 140a-d (e.g., beacon signal 140a-d received from the intermediate device 115a-d and/or the endpoint device 105a-d), and/or information (e.g., desired data) related to the beacon signals 140a-d (e.g., unique identification in the beacon signal 140a-d received from the intermediate device 115a-d and/or the endpoint device 105a-d), to an endpoint manager server 135a via a third network 130. In at least one implementation, the second network 120a-b and the third network 130 may be the same network or include at least some overlapping components.

[0078] Each of the relay servers 125a-b may include one or more computing devices (such as a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, smartphone, cars, drones, a robot, any mobility device that has an operating system, etc.), data storage (e.g., hard disks, memories, databases), networks, software components, and/or hardware components.

[0079] Each of the relay servers 125a-b may be configured to receive a message 150 from the endpoint manager server 135a. Each of the relay servers 125a-b may be configured to send or forward the message 150 from the endpoint manager server 135a to the intermediate devices 115a-d. Each of the intermediate devices 115a-d may be configured to receive the message 150 and forward the message 150 to the endpoint devices 105a-d. [0080] In some implementations, the endpoint manager server 135a may include one or more computing devices (such as a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, a smartphone, a car, a drone, a robot, any mobility device that has an operating system etc.), data storage (e.g., hard disks, memories, databases), networks, software components, and/or hardware components. The endpoint manager server 135a may be associated with one or more endpoint devices 105a-d. For example, a particular corporation, person, or manufacturer may sell an endpoint device 105a-d and may use an endpoint manager server 135a to communicate with and/or control the endpoint devices 105a-d.

[0081] The endpoint manager server 135a may be configured to send or transmit messages 150 associated with a particular endpoint device 105a-d. For example, the endpoint manager server 135a may be configured to send or transmit updates (e.g., firmware, software, program 204 as discussed above) to the particular endpoint device 105a-d. The endpoint manager server 135a may send other communications to an endpoint device 105a-d, such as a response to a request from a beacon signal 140a-d generated by the particular endpoint device 105a-d.

[0082] In some implementations, each of the relay servers 125a-b may include a message manager 142a-b. The message manager 142a-b may be implemented using hardware including a processor, a microprocessor (e.g., to perform or control performance of one or more operations), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC). In some other instances, the message manager 142a-b may be implemented using a combination of hardware and software. Implementation in software may include rapid activation and deactivation of one or more transistors or transistor elements such as may be included in hardware of a computing system (e.g., the relay server 125a-b). Additionally, software defined instructions may operate on information within transistor elements. Implementation of software instructions may at least temporarily reconfigure electronic pathways and transform computing hardware.

[0083] Each of the relay servers 125a-b may include a data storage 145a-b. The data storage 145a-b may include any memory or data storage. In some implementations, the data storage 145a-b may include computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. The computer-readable storage media may include any available media that may be accessed by a general -purpose or special-purpose computer, such as a processor. For example, the data storage 145a-b may include computer- readable storage media that may be tangible or non-transitory computer- readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and that may be accessed by a general- purpose or special-purpose computer. Combinations of the above may be included in the data storage 145a-b.

[0084] The data storage 145a-b is part of the relay server 125a-b. The data storage 145a- b may be separate from the relay server 125a-b and may access the data storage 145a-b via a suitable network. In at least one implementations, the data storage 145a-b may include multiple data storages.

[0085] The data storage 145a-b may include data pertaining to the endpoint devices 105a- d, intermediate devices 115a-d, and endpoint manager servers 135a and relationships between the endpoint devices 105a-d, intermediate devices 115a-d, and endpoint manager servers 135a. For example, the data storage 145a-b may include a table or list of endpoint devices 105a-d that are associated with a particular endpoint manager server 135a. The data storage 145a-b may include data pertaining to beacon signals 140a-d received from endpoint devices 105a-d, such as a timestamp of the receipt of the beacon signal 140a-d, a timestamp associated with the creation of the beacon signal 140a-d, a geo-location associated with the beacon signal 140a-d and/or the endpoint device 105a-d that created or transmitted the beacon signal 140a-d, sensor data associated with the endpoint device 105a-d, routing information for how and/or where to send data between endpoint manager servers 135a and endpoint devices 105a-d, connection strengths between intermediate devices 115a-d and endpoint devices 105a-d, proximity of an endpoint device 105a-d to an intermediate device 115a-d, type of first wireless network 1 lOa-d that connects an intermediate device 115a-d and an endpoint device 105a-d, a cost of a connection between an intermediate device 115a-d and an endpoint device 105a-d, a current battery level of the intermediate device, a type of intermediate device 115a-d, etc.

[0086] In some implementations, the message manager 142a-b may process communications between the endpoint devices 105a-d, the intermediate devices 115a-d, and the endpoint manager server(s) 135a. In an example, the message manager 142a-b may receive a beacon signal 140a-d from the intermediate device 115a-d via the second network 120a-b. The beacon signal 140a-d may have been sent to the intermediate device 115a-d via the first wireless network 1 lOa-d by endpoint device 105a-d. In some implementations, the beacon signal 140a-d may contain characteristics about the endpoint device 105a-d, including an identifier of the endpoint device 105a-d (e.g., MAC address, unique identification), a geographical location of the endpoint device 105a-d, and advertisements of the UUIDs of the services it supports, etc. The message manager 142a-b may identify the characteristic of the beacon signal 140a-d, such as by analyzing the beacon signal 140a-d to identify information pertaining to the beacon signal 140a-d. The message manager 142a-b may access the data storage 145a-b to identify, based on the characteristic of the beacon signal 140a-d, an endpoint manager server 135a that is associated with the beacon signal 140a-d. For example, the identifier of the endpoint device 105a-d may be associated with a particular manufacturer that operations a particular endpoint manager server 135a. The message manager 142a-b may identify this particular endpoint manager server 135a in the data storage 145a-b and an address and/or path to send the beacon signal 140a-d in order to reach the endpoint manager server 135a. In at least some implementations, the message manager 142a-b may send the beacon signal 140a-d, or a beacon message to the endpoint manager server 135a via the third network 130. The beacon message may include the beacon signal 140a-d, may not include the beacon signal 140a-d, or may include information pertaining to the beacon signal 140a-d. [0087] A beacon signal 140a-d may include data from multiple services associated with the endpoint device 105a-d. Additionally or alternatively, multiple beacon signals 140a-d from a single endpoint device 105a-d may be generated and broadcast via the first wireless network 1 lOa-d. Each of these multiple beacon signals 140a-d, for example, may be associated with a different service associated with the endpoint device 105a-d. The message manager 142a-b may identify the services, and based on information for the service, identify an appropriate endpoint manager server 135a that may receive a beacon signal 140a-d.

[0088] The endpoint manager server 135a may be configured to receive the beacon signal 140a-d (e.g., message) from the relay server 125a-b. The endpoint manager server 135a may store the beacon signal 140a-d, process the beacon signal 140a-d, generate a report based on the beacon signal 140a-d, may generate a notification or response based on the beacon signal 140a-d, or any other action. For example, the endpoint manager server 135a may generate a message 150 (e.g., response message) pertaining to the beacon signal 140a-d. The message 150 (e.g., response message) may include a message 150 intended for one or more of the relay server 125a-b, an intermediate device 115a-d, the endpoint device 105a-d that generated the beacon signal 140a-d, or another endpoint device 105a-d that did not generate the beacon signal 140a-d. The endpoint manager server 135a may send the response message to the same relay server 125a-b that sent the beacon signals 140a-d to the endpoint manager server 135a, or to a different relay server 125a-b that did not send the beacon message to the endpoint manager server 135a.

[0089] The relay server 125a-b may receive, from the endpoint manager server 135a, the message 150 (e.g., response message) pertaining to the beacon signal 140a-d. The relay server 125a-b may process the message 150 (e.g., response message), such as by performing operations at the relay server 125a-b, sending data to another device (e.g., a user device), sending data to an endpoint device 105a-d, etc.

[0090] The network architecture 100 may be used to exchange data between any devices capable of network-based communication in a manner that is different than conventional communication over the Internet.

[0091] As illustrated in Fig. 2a, the example network architecture 200a may include an intermediate device 115e that is configured with the virtual environment 202e (e.g., virtualization environment, containerization environment). Once the program 204 is received by the intermediate device 115e, the program 204 may be ready to execute or run on the virtual environment 202e to fulfill a specific mission. In some implementations, the program 204 includes at least one unique identification of the desired endpoint device 105e (e.g., media access control (MAC) address associated with the desired endpoint device 105e, universally unique identifier (UUTD) associated with the desired endpoint device 105e) to determine the event that triggers the execution of the program 204 (e.g., determining that the intermediate device 115e is within the communication range of the desired endpoint 105e, detecting a beacon signal from the endpoint device 115e). The network architecture 100 in FIG. 2a may comprise a network architecture 200 (e.g., cloud server) comprising relay servers, 125c-d and an endpoint manager server 135b.

[0092] Referring to the network architecture 200b in Fig. 2b, in some circumstances, the intermediate device 115e is movable. When the intermediate device 115e is moving, the intermediate device 115e may listen or detect the beacon signals (e.g., listening mode) from nearby endpoint devices 105e periodically or randomly. Based on the received beacon signals (e.g., a beacon signal with a unique identifier of the desired endpoint device 105e), the intermediate device 115e may determine when the intermediate device 115e is within the communication range of the desired endpoint device 105e via a first network 1 lOe. The intermediate device 115e may forward the beacon signals to the relay servers 125c-d and/or the endpoint manager server 135b and wait for a (confirm) message from the relay servers 125c-d and/or the endpoint manager server 135b (as illustrated in FIG 2A). The intermediate device 115e may determine when the intermediate device 115e is within the communication range of the desired endpoint device 105e. More than one intermediate device 115e may be provided with the program 204. More than one unique identifier of the desired endpoint 105e may be included in the program 204 when there is more than one target endpoint device 105e. The endpoint device 105e may be configured to transmit the beacon signals upon receiving a particular signal (e.g., a beacon signal, a query signal, or the like) from an intermediate device 115e.

[0093] Referring to the network architecture 200c in FIG. 2c, in some circumstances, when the intermediate device 115e determines that the intermediate device 115e is within the communication range of the desired endpoint 105e (e.g., matching between the unique identifier in the beacon signal and the unique identification in the program 204), the program 204 on the intermediate device 115e may be executed to transmit a request to obtain the desired data (e.g., a rotating code) from the desired endpoint device 105e. In response to the request from the intermediate device 115e, the desired endpoint 105e may transmit the desired data (e.g., a rotating code 306, as provided in FIG. 3A) to the intermediate device 115e. The intermediate device 115e may be configured to store the data in its storage. The intermediate device may be configured to transmit the desired data to a second network 120c. [0094] Referring to the network architecture 200d in FIG. 2D, the intermediate device 115e (which may comprise the program 204) may be configured to transmit the data to the network architecture 200 (e.g., cloud server) when the second network 120c (e.g., Wi-Fi®, cellular network) is available to the intermediate device 115e.

[0095] The network architecture 100, 200a-d as provided in FIG. 1 and FIGS. 2A-2D may be used for object validation. Validation may be facilitated by computing a proof (e.g., a proof of connectivity, proof of participation, location, time, object origin/authenticity, environmental conditions, or the like). A device for object validation may comprise data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware may cause the data processing hardware to perform operations. As illustrated in the functionality 300a in FIG. 3A, the operations may comprise one or more of: generating a rotating code 306 by combining a private key 302 with metadata 304. The operations may comprise computing a proof 312 using the rotating code 306 and an object identifier 308 for an object 310. The operations may comprise: generating a hash 320 of the proof 312 and the metadata 304; or storing the hash 320 in a network-accessible storage device.

[0096] A private key 302, or a symmetric key, may be combined with metadata 304 to generate a rotating code 306. The private key 302, or a symmetric key, may be any suitable private key 302, or a suitable symmetric key, that may be combined with metadata 304 to generate a rotating code 306. The private key 302, or a symmetric key, may comprise one or more of: a private signature key, a symmetric authentication key, a private authentication key, a symmetric data encryption key, a symmetric key wrapping key, a symmetric master key, a private key transport key, a symmetric key agreement key, a private static key agreement key, a private ephemeral key agreement key, a symmetric authorization key, a private authorization key, or the like.

[0097] The private key 302, or a symmetric key, may be combined with the metadata 304. The metadata 304 may include one or more of: a timestamp, a location, a date, a file size, an author, event (e.g., a calendar event), directional orientation (e.g., north, west, east, south, or the like), annotation (e.g., text, tags, or the like), or the like. In one example, the timestamp may be a current time and the private key 302, or a symmetric key, may be combined with the current time to generate the rotating code 306.

[0098] The private key 302, or a symmetric key, may be combined with the metadata 304 to generate the rotating code 306 using any suitable technique. In one example, a hash function may be used to generate a rotating code 306 using the private key 302 (or the symmetric key) and metadata 304. The hash function may be any suitable hash function for generating a rotating code 306 such as, e.g., secure hash algorithm 1 (SHA-1), messagedigest algorithm (MD5), Research and Development in Advanced Communications Technologies in Europe (RACE) integrity primitives evaluation message digest (RIPEMD)- 128/60, or the like. The rotating code 306 may be generated by truncating the output when the hash function is used to combine the private key 302 (or the symmetric key) and the metadata 304. When the metadata 304 is a current time, the rotating code 306 may be generating by applying the hash function to the private key 302 and the current time (e.g., a timestamp).

[0099] The rotating code 306 may be any suitable variable code that may be generated using a private key 302 (or a symmetric key) and metadata 304. For example, the rotating code 306 may be a 6 digit code that may be generated using the timestamp and the private key 302 (or a symmetric key). For example, when an object 310 is set up (e.g., by a client), a private key 302 may be loaded on the object 310. This private key 302 may be shared with the client and the object 310 and may not be known to other entities. The rotating code 306 may be generated by combining the private key 302 and metadata (e.g., a current time). This code may be valid for a selected time window.

[00100] The rotating code 306 may be used with an object identifier 308 for an object to compute a proof 312 (e.g., a proof of connectivity, location, time, object origin/authenticity, environmental conditions, or the like). The object 310 may be any suitable object 310 that may be used for proof of connectivity, proof of participation, proof of location, proof of time, proof of object origin, proof of object authenticity, proof of environmental condition, or the like. That is, for an example of proof-of-connectivity, the proof 312 may be the combination of the object identifier 308 (e.g., a unique object identifier (UOID)) and the rotating code 306 (e.g., a 6-digit code). The proof 312 may be valid for a selected period of time associated with the rotating code 306. Different proofs may be associated with different keys.

[00101] The object identifier 308 may be used to identify the object 310 using any suitable data type (e.g., floating-point, integer, or the like). For example, the object identifier 308 may comprise one or more of: a UOID or a content identifier (CID) (e.g., for a digital image). In an example of proof of connectivity, the client may own an object 310 (e.g., a smart object) which may be configured to compute cryptographic primitives. The object 310 may have a UOID that may be broadcast using one or more of: (i) a short-range wireless protocol (e.g., Bluetooth® or Bluetooth® Low Energy (BLE)), or (ii) a displayed quick response (QR) code that may be scanned.

[00102] One or more hashes 320 of the proof 312 and the metadata 304 may be generated. For example, one or more hashes 320 associated with an object 310 may be computed for the object 310 for the time period of e.g., a smart contract. One or more hashes 320 of the plurality of hashes 320 may be computed by generating one or more hashes using the proof 312 and a current time to facilitate the generation of a plurality of hashes over a selected time period. The one or more hashes 320 may be stored in a network-accessible storage device. For example, the one or more hashes may be published to a distributed file system (e.g., on an Interplanetary File System (IPFS)) that may be accessible by a contract (e.g., a smart contract).

[00103] The object 310 may be configured to transmit one or more of the rotating code 306 or the object identifier 308 within a selected communication range of the object 310. One or more of the rotating code 306 or the object identifier 308 may be received by an intermediate device 115a-e (as illustrated in FIGS. 1 and 2A-2D) via one or more of a wired network, a wireless network, a QR code, or the like.

[00104] The intermediate device 115a-e may comprise data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware may cause the data processing hardware to perform operations comprising receiving a rotating code 306 and an object identifier 308 for an object 310. When the intermediate device 115a- e is within a selected communication range of the object 310, the intermediate device 115a-e may be configured to listen to the broadcast from the object 310 which includes one or more of the rotating code 306 or the object identifier 308. The intermediate device 115a-e may be configured to receive the rotating code 306 (e.g., a 6 digit code) and the object identifier 308 (e.g., a UOID). The intermediate device 115a-e may be configured to compute a proof 312 using the object identifier 308 and the rotating code 306. The intermediate device 115a-e may be configured to compute a hash 320 of the proof 312 and metadata 304 (e.g., a current time). The intermediate device 115a-e may be configured to send the hash 320 to a server for verification of the proof 312.

[00105] Object validation may be used with various kinds of connections between nodes (e.g., items, services, devices, accounts, events, or people). A network architecture 100, 200a-d (as illustrated in FIGS. 1 and 2A-2D) may be configured to connect two or more nodes (e.g., items, services, devices, accounts, events, or people). The connection may be a link between two or more devices (e.g., between an intermediate device 115a-e and an endpoint device 105a-e). The connection may be between an account (e.g., associated with a user) and a device (e.g., an end point device 105a-e). The connection may be between two or more of the devices in the network architecture 100, 200a-d (e.g., 105a-e, 11 la-e, 115a-e, 125a-b, 135a, etc.), which may be configured to identify a lost or severed connection and restore the connection between the nodes (e.g., an item and another item, an owner of an item, a user account, or the like). Two or more of the nodes in the network architecture 100, 200a-d may create a temporary connection between, e.g., a device or user account with a particular event or with other people.

[00106] To assist with connectively and/or with rewarding various activities on the network architecture 100, 200a-d, proof-of-connectivity may be used. When a network architecture 100, 200a-d is a decentralized network, smart contracts holding a reward may be unlocked upon receiving a proof 312 (e.g., a proof of connectivity). A proof 312 may be used for implementing a trustless process for providing funds to an intermediate device 115a- e. An object 310 (e.g., associated with an endpoint device 105a-e) may be associated with a smart contract. In one example, a pre-payment may be sent to a smart contract which may include details for a bounty associated with the smart contract. In one example, an intermediate device 115a-e may determine when a bounty is associated with the hash 320 and send the proof 312 (e.g., a proof of connectivity) to a smart contract. The proof 312 may be encrypted using a public key for the smart contract. The smart contract may be configured to verify that the proof 312 is valid and, in response to the verification, release the bounty associated with the smart contract to the intermediate device 115a-e.

[00107] Alternatively or in addition, one or more tokens (e.g., cryptographic tokens) may be used to facilitate object validation. A device (e.g., associated with a client) may be configured to generate one or more tokens 314 (e.g., a non-fungible token (NFT)) based on an object 310. The device may be configured to generate a token proof 318 (e.g., an NFT proof) using token metadata (e.g., NFT metadata) and the object identifier 308 for the object 310. The device may be configured to push the token proof to a suitable data storage device. When the token is an NFT, the device may be configured to push the NFT proof to a blockchain. The object 310 may be any suitable object that may be linked to a token such as digital art, videogame assets, music, film, or the like. In one example, the object 310 may be a digital image.

[00108] An intermediate device 115a-e (as illustrated in FIGS. 1 and 2A to 2D) may be configured to send, on the blockchain, an NFT proof for an object 310 to receive a bounty. The intermediate device 115a-e may receive cryptocurrency and/or a different digital asset (e.g., a different NFT) based on submitting a proof-of-connectivity (which may be validated using the NFT proof or may be validating using a different cryptographic proof). When the network architecture 100, 200a-d (as illustrated in FIGS. 1 and 2A-D) is a decentralized network, the smart contract may be trustless. That is, a device (e.g., associated with a client) may not: (i) receive the proof-of-connectivity from the intermediate device 115a-e without providing the bounty to the intermediate device 115a-e, and (ii) the intermediate device 115a- e may not use inaccurate data to receive the bounty from the device (e.g., associated with a client). [00109] Proof of connectivity may be used in various use cases such as object tracking, increasing location foot traffic, event participation, performance participation, micromessaging, or the like. An intermediate device 115a-e may be configured to communicate with a network architecture 100, 200a-d to facilitate proof of connectivity. In some cases, the intermediate device 115a-e may not communicate directly with a chain and may not reserve the bounty. The intermediate device 115a-e may be configured to communicate directly to an endpoint manager server 135a (e.g., a Nodle Service Provider (“NSP”)) that may manage access to the network architecture 100, 200a-d. The endpoint manager server 135a may receive payment in fiat currency (e.g., USD, EUR) which may carry the risk of cryptocurrency price volatility. The endpoint manager server 135a may be configured to provide application protocol interfaces and/or user interfaces to facilitate access to the network. A device (e.g., associated with a client) may be configured to connect to the network architecture 100, 200a-d using the endpoint manager server 135a.

[00110] Proof of connectivity may be used for object tracking, e.g., for a physical object.

When an intermediate device 115a-e connects to the object, the intermediate device 115a-e may receive a reward (e.g., cryptographic tokens) by sending the proof-of-connectivity (e.g., as hash or as a token proof) to a network architecture 100, 200a-d (as illustrated in FIGS. 1 and 2A-D).

[00111] For example, a company who manages a fleet of vehicles may track those vehicles using Bluetooth® beacons that may be installed in the tracked vehicles by registering the tracked vehicles on the network architecture 100, 200a-d. The company may provide a reward (e.g., cryptocurrency) for the vehicle location over a selected period of time. When an intermediate device 115a-e receives one or more of the rotating code 306 or an object identifier 308 from the Bluetooth® beacon on the tracked vehicle, the intermediate device

115a-e may be configured to send the encrypted location of the tracked vehicles to the network architecture 100, 200a-d to receive the reward. The intermediate device 115a-e may be configured to compute a proof 312 using the object identifier 308 and the rotating code 306 to generate a hash of the proof 312 and metadata 304. The intermediate device 115a-e may be configured to send the hash of the proof 312 (e.g., the proof of connectivity) and the metadata 304 for verification of the proof 312. The intermediate device 115a-e may send an address for receiving the reward.

[00112] Proof of connectivity may be used for increasing foot traffic to a particular location. An intermediate device 115a-e (as illustrated in FIGS. 1 and 2A-2D), when located within a communication distance of an endpoint device 105a-e (e.g., a Bluetooth beacon), may receive one or more of the rotating code 306 or the object identifier 308 from the endpoint device 105a-e, which may be located at a particular location such as a retail location. The intermediate device 115a-e may be configured to compute a proof 312 using the rotating code and an object identifier (e.g., a universal unique identifier (UUTD) for a Bluetooth® beacon or a UOID for an object). A hash 320 of the proof 312 and metadata 304 (e.g., a current time) may be generated. The hash 320 may be sent for verification to a network architecture 100, 200a-d. The intermediate device 115a-e may be configured to receive a reward (e.g., in cryptocurrency) for providing proof of connectivity at the particular location.

[00113] For example, a restaurant may want to attract customers for lunch. An endpoint device 105a-e (as illustrated in FIGS. 1 and 2A-2D) may be located at the restaurant location. An application (e.g., the Nodle Cash app) may be used to create a “Place Mission” to assign cryptocurrency as an associated bounty (e.g., with a reward in cryptocurrency) in the Mission escrow for the first 20 participants. There may be a cryptocurrency fee to create a mission in the application. When the Mission is active and, in some instances, when the restaurant’s Nodle Cash app is opened, people with the Nodle Cash app in the same city may be notified that there is an ongoing mission to go to the restaurant for lunch.

[00114] The restaurant may have a device at the restaurant (e.g., an endpoint device 105a-e as illustrated in FIGS. 1 and 2A-2D) that may broadcast a rotating code 306 using Bluetooth®. The rotating code may be combined with an object identifier 308 for the endpoint device 105a-e to compute a proof 312, which may be combined with metadata 304 (e.g., a current time) to generate a hash 320. The hash 320 may be used by the Nodle Cash app to prove that the intermediate device 115a-e (and an associated user) were in the vicinity (e.g., a communication distance of the endpoint device 105a-e) of the restaurant.

Alternatively, or in addition, the proof 312 may be provided using a QR code which may be scanned by an intermediate device 115a-e. The QR code may be combined with an object identifier 308 to compute a proof 312. The proof 312 may be combined with metadata 304 to compute a hash 320, which may be sent to a network architecture 100, 200a-d for verification of the proof 312. Alternatively or in addition, the QR code may be the proof 312 and the QR code may be combined with metadata 304 to generate a hash 320 which may be sent to the network architecture 100, 200a-d for verification of the proof 312. When the maximum number of participants has been reached (which is 20 participants in this scenario), the bounty may be depleted and the mission may be ended.

[00115] Proof of connectivity may be used to increase foot traffic and to provide rewards based on additional proof-of-connectivity. For example, a retail coffee company may want to increase traffic at their coffee shops. The coffee company may provide an endpoint device 105a-e (as illustrated in FIGS. 2A-2D) to broadcast, e.g., a Bluetooth® signal. People with a specific application (e.g., a Nodle Cash app) in the vicinity of the coffee shops (e.g., a communication distance of the Bluetooth® signal) may collect the digital badge and use the digital badge to buy coffee. The retail coffee company may use the specific application (e.g., a Nodle Web app) to create a mission for the retail coffee locations. The missions may be created for a fee.

[00116] For the retail coffee company example, an intermediate device 115a-e may be used to establish proof of connectivity. The intermediate device 115a-e may be configured to identify an object identifier 308 (e.g., an identifier broadcast by the Bluetooth® signal) for an object 310 (e.g., the coffee shop). The intermediate device 115a-e may be configured to generate a token (e.g., an NFT) 314 based on the object 310. Token metadata 316 (e.g., NFT metadata) may be combined with the object identifier 308 to generate a token proof 318 (e.g., an NFT proof). The token proof 318 (e.g., NFT proof) may be pushed to a blockchain to verify proof of connectivity for the intermediate device 115a-e. Alternatively or in addition, a token (e.g., an NFT) may be provided to the intermediate device 115a-e which may be used to buy coffee at the coffee shops. The tokens (e.g., NFTs) may be tracked to provide further rewards after a selected number of tokens (NFTs) have been used.

[00117] Proof-of-connectivity may be used with tokens to facilitate increased functionality. For example, a conference organizer or sponsor may want to provide a conference experience in which attendees may use a token to: (i) receive admission to the conference, (ii) receive rewards at the conference, and (iii) receive access to media pertaining to the conference. When the attendees purchase a ticket, the attendees may receive a token 314 (e.g., an NFT) from the conference organizer/ sponsor on an application (e.g., a Nodle app wallet). The token 314 (e.g., an NFT) may include a cryptocurrency allowance. The token 314 (e.g., NFT) may have an associated rotating code 306. Alternatively or in addition, the token 314 (e.g., NFT) may have one or more of a QR code representation or Beacon ID representation. The rotating code 306 may allow the token 314 (e.g., NFT): (i) to facilitate admission to the conference, (ii) to receive a reward (e.g., cryptocurrency) to purchase food during the conference, and (iii) to provide access to digital media (e.g., a private off-chain board that may include chat or other social media) about the conference. The token 314 (e.g., NFT) may be used for proof-of-connectivity when the token 314 (e.g., NFT) is scanned at the conference. Scanning the token 314 (e.g., NFT) may facilitate the transfer of a reward (e.g., cryptocurrency) to a digital wallet for the attendee.

[00118] Proof of connectivity may be used for a social network. The network architecture

100, 200a-d (as illustrated in FIGS. 1 and 2A-D) may be used to create a social network, which may be based on a proximal social graph of the devices (e.g., endpoint devices 105a-e and intermediate devices 115a-e in the network architecture 100, 200a-d) as well as based on users of those devices. Such a proximal social network that may be leveraged by any code (e.g., 204) executed on devices.

[00119] With a sports event example, a proximal and temporal social network may be created for fans in the stadium. Multiple proximal social networks may also be created within a geographical range, such as one for each team that is playing at the sport event, and for any number of other interest groups. In some examples, the social networks may be predefined. Additionally or alternatively, a social network may be created based on input received via one or more of the devices (e.g., endpoint devices 105a-e and intermediate devices 115a-e in the network architecture 100, 200a-d). In some examples, social networks may be created based on user input or may be subject to one or more filters that may prevent certain types of social networks from being created.

[00120] A social network may be accessed by any device (e.g., endpoint devices 105a-e and intermediate devices 115a-e in the network architecture 100, 200a-d) that has either a proof 312 or an NFT 322 associated with the social network. Additionally or alternatively, a location may be used so that the device may be at or near a particular location. Within the social network, users may chat with each other without one or more of: (i) sharing any personal information, (ii) sending or accepting any friend requests, or (iii) having to search for a link. Users of the social network may remain anonymous while also getting the benefit of interacting with like-minded people who may be looking to interact with others.

[00121] Proof-of-connectivity may be used to provide payment. That is, to receive proof- of-connectivity, an intermediate device 115a-e (as illustrated in FIGS. 1 and 2A-2D) may send payment to an endpoint device 105a-e. For example, a street performer may want to be paid for playing guitar when people like her music. The street performer may use an application (e.g., the Nodle Cash app) to create an activity (e.g., an “Activity labeled “Guitar Street performance) at a specific location. People listening to the music may receive a token (e.g., an NFT) when in a communication distance of an endpoint device 105a-e associated with the street performer. When the activity is active, and when the performers’ application (e.g., Nodle Cash app) is active, people with the application (e.g., Nodle Cash app) in a communication distance of the endpoint device 105a-e may be notified that there is an ongoing activity with the price in cryptocurrency for receiving the a proof of connectivity. The street performer’s endpoint device 105a-e may broadcast a Bluetooth® signal comprising a rotating code. People with the application (e.g., Nodle Cash app) who are listening to the performance may receive a notification about a minimum donation amount - (e.g., request for payment) and, when the people pay the minimum amount or more, then they may receive the proof-of-participation token 314 (e.g., NFT). In response, the endpoint device (e.g., associated with the street performer) may receive the donation amounts (e.g., in cryptocurrency) from people who have donated when the performance has finished.

[00122] Proof-of-connectivity may be used for various smart contracts. For example, proof-of-connectivity may be used in micro-messaging. For example, a person may challenge a participant to do an activity (such as a “dare”) in the presence of a witness to receive cryptocurrency. For example, a Student may challenge a Friend to eat the spiciest food of his life, and she is willing to pay a particular amount of cryptocurrency. The Student may create the challenge using an application (e.g., the Nodle app) and provide the reward in cryptocurrency. The challenge may have a specified time limit and allow for the selection of a participant (e.g., the Friend) and a Witness. The Friend may receive a notification on the application and agree to participate and the Witness (which may comprise one or more people) may receive a notification on the application and agree to be a Witness. The bounty may be sent to the smart contract. The Friend may submit the result of the challenge to the Student and the Witness. The Witness may approve the result to unlock the fund. In this example, the Witness may issue the proof 312. The proof 312 may be computed using an object identifier 308 and a rotating code 306. Alternatively or in addition, the proof 312 may be a token (e.g., an NFT). The intermediate device 115e may be configured to generate a token (e.g., an NFT) 314. Token metadata 316 (e.g., NFT metadata) may be combined with the object identifier 308 to generate a token proof 318 (e.g., an NFT proof). The token proof 318 (e.g., NFT proof) may be pushed to a blockchain to verify proof of connectivity for the intermediate device 115a-e.

[00123] Proof of connectivity may be used to verify that a product or service is the correct product or service. For example, a user may hail a vehicle using a ride sharing application. The driver of the vehicle may issue a proof 312 or token proof 318 (e.g., an NFT) that may be broadcast. When the user approaches the vehicle, the intermediate device 115e may receive one or more of the proof 312 or the token proof 318. One or more of the proof 312 or the token proof 318 may be used to confirm that the vehicle is the correct vehicle. On the intermediate device 115a-e, information (e.g., data) about the vehicle may be displayed based on one or more of the proof 312 or the token proof 318 (e.g., the NFT) such as one or more of a make, model, or confirmation that the vehicle is the correct vehicle.

[00124] An NFT 322 may be used for object validation as illustrated in the functionality

300b in FIG. 3B. A device for object validation may comprise data processing hardware; and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware may cause the data processing hardware to perform operations. The operations may comprise one or more of identifying an object identifier 308 for an object 310; generating an NFT 322 based on the object 310; generating an NFT proof 326 using NFT metadata 324 and the object identifier 308; or pushing the NFT proof 326 to a blockchain 328.

[00125] Alternatively or in addition, a proof 312 may be computed using one or more of an object identifier 308 or a rotating code 306, as illustrated in FIG. 3A. A hash 320 may be generated using the proof 312 and metadata 304 and the hash 320 may be stored in a network-accessible storage device. The proof 312 may be used in combination with the NFT 322 to increase the level of the proof when compared to the proof 312 or the NFT 322, individually.

[00126] As illustrated in FIG. 3B, the object 310 may comprise an object identifier 308.

When the object 310 is a digital image, the object identifier may be a content identifier (CID) for the digital image. The object 310 may be associated with metadata which may include one or more of a proof of location at a selected time and a selected place, a proof of time, a proof of connectivity, or a proof of origin. When the object 310 is a digital image, the proof of location at a selected time and a selected place may include when the digital image was captured and where the digital image was captured. When the object 310 is a digital image, the proof of connectivity may include proof that a particular person captured the digital image. When the object 310 is a digital image, the proof of origin may include proof that the digital image was captured by a particular camera. When the object is a digital file (e.g., a video file): (i) the proof of location at a selected time and a selected place may include when the digital file (e.g., the video file) was generated (e.g., captured by a video camera); (ii) the proof of time may include proof that the digital file (e.g., the video file) was captured at a particular time, (iii) the proof of connectivity may include proof that a particular person captured the digital file (e.g., the video file), and/or (iv) the proof of origin may include proof that the digital file (e.g., the video file) was captured by a particular camera.

[00127] Alternatively or in addition, one or more of a digital witness (e.g., nearby nodes), cellular, Bluetooth®, WiFi®, or the like may be used as the proof. For example, nearby nodes may use beacon signals to confirm the time and/or location for the proof. The beacon may be used in a general location to confirm the time and/or location to provide the proof. Alternatively or in addition, a cellular signal may be used to confirm the time and/or location to provide the proof. For example, a cellular signal may be transmitted at a particular time and place to provide the proof. Alternatively or in addition, Bluetooth®, WiFi®, or any other signal may be used as the proof (e.g., of a time or a location).

[00128] Proof of device genuineness may use one or more of software and/or hardware protection mechanisms such as secure elements or code anti tampering. For example, a secure element (e.g., a secure operating system in a tamper-resistant chip) may be used to establish proof of device genuineness. The secure element may be one or more of a smart card, a universal integrated circuit card (UICC), a smart microSD card, or may be embedded within a larger device. Code anti-tampering may be used to establish proof of device genuineness. For example, monitoring software may be used. Alternatively or in addition, runtime integrity checks (e.g., using cyclic redundancy checksums, anti-debugging measures, encryption, or the like) may be used to provide code anti -tampering.

[00129] Before an NFT 322 is generated based on an object 310 (e.g., a digital file such as a digital image or a video file), attestation data may be inserted into the object. The attestation data may include one or more of nearby device data, sensor data, network data, biometric data, additional imaging data, or the like. An NFT 322 may be generated based on the object 310 (e.g., a digital file such as a digital image or a video file). NFT metadata 324 for the NFT 322 may be combined with the object identifier 308 to generate an NFT proof 326. The NFT proof 326 may be pushed to a blockchain 328. The NFT proof 326 may be used to verify one or more of an object time, an object location, an object origin, or the like. The NFT proof 326 may be an NFT CID.

[00130] As illustrated in FIG. 3C, functionality 300c for facilitating NFT proof 376 for a digital image 360 (or more generally a digital file such as a video file) is provided. A device (e.g., an endpoint device 105a-e or an intermediate device 115a-e as illustrated in FIGS. 1 and 2A-D) for digital image proof (or more generally a digital file proof such as a video file proof) may comprise data processing hardware, and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware may cause the data processing hardware to perform operations. The operations may comprise identifying a digital image 360 (e.g., using a CID 358 for the digital image 360) (or more generally a digital file such as a video file). The digital image 360 (or more generally a digital file such as a video file) may include attestation data as a root of trust for generating a digital image NFT (e.g., NFT 372), as shown in block 355. In one example, the attestation data may be generated using an image attestation standard (e.g., a Content Authenticity Initiative (CAI) standard, a Coalition for Content Provenance and Authenticity (C2PA) standard, or the like).

[00131] The digital image 360 (or more generally a digital file such as a video file) may be captured using any suitable device (e.g., a digital camera), which may be included on or in communication with a user equipment (e.g., a mobile phone, a laptop, a tablet, or the like) which may have wired or wireless connectivity. When the digital image 360 is captured (or more generally a digital file such as a video file is captured), one or more of a signature or an attestation data (as shown in block 355) may be added to the digital image 360 (or more generally a digital file such as a video file). One or more of the signature, the attestation data, or metadata (e.g., EXIF metadata), as shown in block 355, may be added to the raw image file (or more generally a raw digital file such as a raw video file). The digital image data (or more generally a digital file data such as a video file data) may be signed using one or more of a public key or a wallet address. The metadata may include verified location using a proof of interaction or a third party application on a network architecture 100. In one example, the verified location may be obtained using Bluetooth® low energy (BLE). In one example, different kinds of metadata may be included such as date of digital image capture (or more generally a digital file generation such as a video file capture), time of digital image capture (or more generally time of digital file generation such as time of video file capture), an identifier associated with a customer or client for the digital image (or more generally an identifier for a digital file such as an identifier for a video file), a location name (or more generally a location name for a digital file such as a location name for a video file), a calendar event (or more generally a calendar event for a digital file), an orientation of the digital image (e.g., north, south, east, west) (or more generally one or more orientations for a digital file such as one or more orientations at one or more times for a video file), specific measurements of the area (or more generally one or more specific measurements associated with a digital file such as one or more specific measurements at one or more times for a video file), or other annotations (e.g., text, tags, drawing, voice memo, translated voice memos, or the like) (which may be associated with a digital file such as a video file).

[00132] Attestation data may be provided to the digital image 360 (or more generally a digital file such as a video file) before generating an NFT 372. The attestation data may include any data suitable for attestation including one or more of nearby device data (e.g., data from different devices within a selected distance (e.g., 10m, 20m, 50m, 1000 m, 1 mile, or the like) of the device that may be used to determine a reality metric, sensor data (e.g., motion data, temperature data, humidity data, or environmental data), network data (e.g., cloud data), biometric data (e.g., fingerprints, facial, voice, iris, palm, or the like), or additional imaging data (e.g., digital image data from outside of the range of the digital image 360, e.g., capturing a three dimensional field scan of an image and attaching it to the digital image 360).

[00133] During the capture and upload process, attestation data may be added to verification of the digital image 360 (or more generally a digital file such as a video file) that may previously comprise attestation data. For example, a digital image 360 (or more generally a digital file such as a video file) may previously comprise attestation data using a standard (e.g., CAI or C2PA). Additional attestation data may be added to the previous attestation data to increase an attestation level (CAI standard attestation with sensor attestation data) relative to a baseline situation in which attestation is provided without the additional attestation data (e.g., CAI standard without sensor attestation data). In some examples, additional data may be added to the digital image (e.g., that the digital image was edited using a digital image editing program, such as Photoshop® or Lightroom®) (or more generally a digital file such as a video file).

[00134] The digital image (or more generally the digital file) may be pushed on chain using a user’s signature. For e.g., C2PA supported media, the device’s signature may be used to push the digital image (or more generally the digital file) on chain.

[00135] An NFT 372 may be generated based on the digital image 360 (or more generally a digital file such as a video file). The operations may comprise receiving a CID 358 for the digital image 360 (or more generally a digital file such as a video file). The CID 358 may be received by pushing one or more of the digital image 360 (or more generally a digital file such as a video file), the metadata, the attestation data, or the signature to a distributed file system (e.g., Interplanetary File System (IPFS)). An NFT Proof 376 (e.g., an NFT CID) may be received based on NFT metadata 374 and the CID 358 for the digital image 360. An image attestation status may be requested from a network and the network may check when image attestation has been uploaded before or has a different provenance.

[00136] The NFT proof 376 may be pushed to the blockchain 378. The NFT proof 376 may include the NFT CID (e.g., CID of NFT metadata). After the NFT proof 376 has been pushed to the blockchain, attestation for the NFT may be added. For example, CAI attestation may be added showing that the NFT has been minted. Consequently, the image NFT may be verified using a standard (e.g., a CAI standard) and/or open source code as authentic. A source of the NFT content (e.g., brands, camera makers, content creators) may be provided to a party using a bidirectional communication channel.

[00137] The NFT may be distributed using various methods. In one example, a distribution and/or licensing for the NFT may be selected. That is, the NFT may be sent, traded, or sold on a decentralized marketplace. A distribution option may be selected upon uploading the NFT. In one example, the distribution options may include one or more of: (i) a public domain distribution option may be selected in which, e.g., a select number of prints in which the creator retains ownership may be selected, (ii) a select number of NFT owners, (iii) a select number of uses for NFT owners, (iv) an unlimited number of licenses, or the like. [00138] Attestation for the digital image may be added or verified (or more generally for a digital file such as a video file). An attestation may be added (e.g., using a CAI standard or a different attestation standard) to a non-attested digital image (or more generally for a digital file such as a video file). The attestation standard (e.g., CAI standard or non-CAI standard) may be used to verify that a digital image is authentic, to verify provenance for the digital image, or to verify a creator for the digital image (or more generally for a digital file such as a video file). When a CAI standard has not been used, a digital image may be uploaded that has been attested using a non-CAI standard. [00139] Verification data may be generated using a combination of first verification and second verification data (e.g., first and second proofs). The first verification data may include attestation data based on a first standard and the second verification data may include data captured when the digital image is captured. The operations may comprise combining a plurality of proofs to create a combined proof that is stronger than each individual proof. [00140] A server may be configured to generate NFT 372 to facilitate proof of a digital image 360 (or more generally for a digital file such as a video file). The server (e.g., an endpoint manager server 135a as illustrated in FIG. 1) may comprise data processing hardware; and memory hardware in communication with the data processing hardware. The memory hardware may store instructions that when executed on the data processing hardware may cause the data processing hardware to perform operations. The operations may comprise identifying, at the server, a digital image 360 (or more generally for a digital file such as a video file). The operations may comprise identifying, at the server, a CID 358 for the digital image 360 (or more generally for a digital file such as a video file). The operations may comprise generating, at the server, an NFT 372 based on the digital image 360. The operations may comprise identifying, at the server, an NFT proof 376 (e.g., an NFT CID) based on NFT metadata 374 and the CID 358 for the digital image 360 (or more generally for a digital file such as a video file). The operations may comprise pushing the NFT proof 376 (e.g., NFT CID) to a blockchain 378.

[00141] The signature for the original digital file (e.g., a video file or a digital image) may be used to authenticate a digital file (e.g., the video file or the digital image) as an original. For example, for a digital image, the signature for the original photo may be used to authenticate a digital image as an original. As illustrated in FIG. 4 A, a block diagram 400a for digital image verification shows a camera 410 (e.g., a digital camera, or more generally a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital video camera, a digital audio recorder, or the like) that may be configured to capture a digital image, sign the digital image, and include metadata with the digital image. The camera 410 (e.g., a digital camera, or more generally a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital video camera, a digital audio recorder, or the like) may be configured to include the signature 425 for the original photo 420. The signature 425 may indicate that the original photo 420 is authentic. When the original photo 420 has been modified to generate a modified photo 430, then the modified photo 430 may comprise an unmatched signature 435. The preceding operations may be used for a digital file more generally (e.g., a video file). [00142] An NFT may be used to verify the authenticity of a digital file (e.g., a digital image or a video file). For example, for a digital image, an NFT may be used to verify the authenticity of a digital image. As shown in the process flow 400b in FIG. 4B, a device (e.g., a wireless device such as a wireless digital camera, a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital video camera, a digital audio recorder, or the like) may be configured to capture a digital image (e.g., a photo) that includes an attestation record (e.g., an attestation record based on a CAI standard or a non-CAI standard) and generate an NFT based on the digital image, as shown in block 440. The device may capture the digital image as a raw image file that may be signed. The signature may be included in the exchangeable image file (EXIF) metadata associated with the digital image.

[00143] The signature of the raw file, additional metadata (e.g., for a time or place of capture or the like), attestation data, or the like may be pushed to a blockchain. That is, the device (e.g., a digital camera, or a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital video camera, a digital audio recorder, or the like) may be configured to push the digital image including the attestation record to a distributed file system (e.g., IPFS) and receive a media CID for the digital image, as shown in 450. The raw image file may be stored offline, on the distributed file system (e.g., IPFS) or on decentralized storage. The device may be configured to push NFT metadata and the media CID (e.g., the digital image CID) to the distributed file system (e.g., IPFS) and receive an NFT CID, as shown in 460. The device may be configured to push the NFT CID to a blockchain, as shown in 470.

[00144] When a device (e.g., a digital camera, or a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital video camera, a digital audio recorder, or the like) is connected to a network, a number of digital images (or more generally digital files such as video files) may be selected to be minted as NFTs or digital images may be minted as NFTs to be claimed by a user. Upon NFT minting, payment may be provided to one or more of a device manufacturer (e.g., a camera manufacturer, or a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital video camera, a digital audio recorder, or the like), a blockchain owner, or the like.

[00145] The digital image (or more generally the digital file which may be a video file) may be attested (e.g., as a C2PA marked digital image) and pushed on-chain to generate an NFT, as illustrated in FIG. 4C. The digital image (or more generally the digital file which may be a video file) may be captured using a wireless device (e.g., an iPhone®, or a another user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital video camera, a digital audio recorder, or the like) or a device in communication with a wireless device that may be configured to attach attestation data (e.g., C2PA metadata) to the digital image (or more generally the digital file which may be a video file). In another example, the digital image (or more generally the digital file which may be a video file) may be processed to have NFT metadata included in the digital image format (or more generally the digital file format which may be a video file format).

[00146] A user interface 400c (e.g., for a web browser, a smart phone, a tablet, or the like) may include various operations. A digital image file (or more generally the digital file which may be a video file) may be dragged and dropped onto the display area 480 and the digital image file (or more generally the digital file which may be a video file) may be used to generate an NFT (e.g., minting an NFT as shown in the display area 490) based on the digital image (or more generally the digital file which may be a video file). For example, a digital image (or more generally the digital file which may be a video file) that has been attested using an attestation standard (e.g., C2PA) may be minted into an NFT using the user interface 400c. The drag-and-drop functionality and the NFT generation functionality may be supported natively as a background function (e.g., for iOS® or for Android®). When the digital image file (or more generally the digital file which may be a video file) does not include an attestation record (e.g., a C2PA record), then an attestation record (e.g., a C2PA record) may be added to the digital image file (or more generally the digital file which may be a video file). An attestation record software development kit (SDK) or application protocol interface (API) may be used to attach an attestation record to the digital image file (or more generally the digital file which may be a video file).

[00147] A digital image viewer may be configured to add support for attestation data (e.g., C2PA metadata) when viewing the digital image (or more generally the digital file which may be a video file). The digital image viewer may be configured to support numerous aspect ratios (e.g., square aspect ratios, rectangular aspect ratios, or the like. Branding or a source of the specific digital camera used to capture the digital image may be included in the digital image that may be displayed using the digital image viewer. Additional metadata (e.g., as stored using exchangeable image file format (EXIF) such as, “Shot on Leica ® Ml 1 fl.8 1/100^th s. ISO 32”) may be displayed using the digital image viewer. The digital image viewer may be configured to allow the attestation record (e.g., the C2PA attestation record) to be viewed. The NFT associated with the digital image may be used to verify the digital image. The digital image viewer may be configured to display whether the digital image was captured natively using the same device or whether the digital image was copied from another source (e.g., uploaded). The digital image may be uploaded to a digital image viewer that may natively support verification.

[00148] The example of the digital image may be, more generally, any suitable digital file. The digital file may include meta-data to describe the content (e.g., the content of the photo when the digital file is a digital photo, the content of the video when the digital file is a digital video, the content of the energy usage when the digital file includes energy usage, the clean energy produced when the digital file includes clean energy production) being taken. The digital file may include one or more of: the geo-location (as GPS coordinates); the date and time of capture; the signer’s public key (i.e. the SDK public key).

[00149] For example, when the digital file is a video file, the digital file may be any suitable video file in one or more of a: (i) container format (e.g., Matroska, flash video, Video Object (VOB), Ogg, HyperText Markup Language (HTML), Audio Video Interleave (AVI), Advanced Video Coding High Definition (AVCHD), Quicktime, Advanced Systems Format (ASF), VivoActive (VIV), Moving Picture Expert Group (MPEG)-4 Part 12, MPEG-1 part 1, Material Exchange Format (MXF), nullsoft streaming video (NSV), or the like); (ii) a video coding format (e.g., VP8, VP9, AVI, VP6, Dirac, AVCHD, Windows Media Video, RealVideo, Motion Joint Photographic Experts Group (JPEG), MPEG-1 part 2, H.262, H.263, H.264, Adobe Flash Platform, or the like), (iii) an audio coding format (Vorbis, MPEG Audio Layer 3 (MP3), Dolby AC-3, Windows Media Audio, RealAudio, Advanced Audio Coding (AAC), MPEG-1 Audio Layer 1, MPEG-1 Audio Layer III, Dolby Digital, Adaptive Multi-Rate Narrow Band (AMR-NB), Adaptive Multi-Rate Wide Band AMR- WB+, Shock Wave Flash (SWF), or the like), (iv) a suitable file extension, or the like. [00150] The digital file may be e.g., a selected amount of production data over a period of time (e.g., 15 seconds, 1 minute, 30 minutes, 12 hours, 1 day, 1 week, 1 month, or the like), usage data, or the like. The production or usage data may comprise one or more of water data, electricity data, gas data, alternative energy data (e.g., solar), clean energy data, or the like. The clean energy produced may be measured in one or more of milliwatts, kilograms, tons, or any other suitable metric. The amount of clean energy produced when manufacturing a material (e.g., steel, iron, aluminum, zinc, bronze, glass, sand, cement, lead, wood pellets, natural gas, oil or any other material with the potential to cause environmental harm) may be measured.

[00151] One or more additional sensors may be used to sign the data in the digital file. The one or more additional sensors may comprise any suitable sensors including e.g., cryptographically signed sensors. The sensors may be external sensors that may interface with the device (e.g., a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital camera, a digital video camera, a digital audio recorder, or the like) or may be sensors that may be located in the device (e.g., a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital camera, a digital video camera, a digital audio recorder, or the like). When cryptographically signed sensors are used, the data may be processed and/or stored in one or more of a decentralized network, a decentralized storage, or a centralized storage (e.g., a cloud storage). When stored in one or more of a decentralized network or a decentralized storage, using cryptographically signed sensors may prevent the uploading of manipulated data and/or the poisoning of data after capture. [00152] A digital twin (e.g., a digital representation of an object) may be verified using cryptographically signed sensors and to prevent malicious digital twins from providing fake data. For example, a malicious digital twin may be generated to provide fake digital images and/or videos that may be intended to mimic a real event (e.g., such as a car crash). Cryptographically signed sensors may prevent the fake digital images and/or videos from being verified.

[00153] As illustrated in FIGS. 4D, 4E, and 4F, a video file may be recorded and cryptographically signed. The data may be pushed to a secure content repository (e.g., an IPFS or Amazon S3) and a content ID may be generated. The content ID may be pushed on- chain.

[00154] As illustrated in FIG. 4D, a device 400d may be operable to capture a video file 492a. The video file 492a may be associated with various fields 494a including an incident number, an author, a location, a date, and a verification status (e.g., verified on Nodle Chain). [00155] As illustrated in FIG. 4E, a device 400e may include a digital image or video file 492 that may be associated with various fields 494b including a sensor identifier, an author, a location, a date, and a verification status (e.g., verified on Nodle Chain).

[00156] As illustrated in the flowchart 400f in FIG. 4F, a user equipment 495 may be operable to record content which may be cryptographically signed. The data from the UE 495 may be pushed to a secure content repository 497 such as an IPFS or S3). The secure content repository may be operable to generate a CID. The CID may be pushed as an NFT on a chain 499 (e.g., a Nodle chain).

[00157] For example, a 15 second video file may be directly captured by the SDK and the meta-data may be configured for the host app. The hash may be computed from the file and may use one of the hashing algorithms supported by IPFS for forward compatibility with a future IPFS-based storage. The hash computed from the content may be used as part of the transaction that is included on the blockchain. The hash may be used to retrieve the video file from the private repository. The hash on the chain may not be deleted. The content itself on the private repository may be deleted at some point in time.

[00158] To prevent tampering of the app code, some operations may include: preventing the user from capturing content and crashing the app if it detects that the location has been spoofed; when the device is in developer mode, or when the device is rooted. The SDK along and sample source code of a camera app using the SDK may be used in combination with a video capture feature.

[00159] The SDK may contain a blockchain wallet responsible to create, secure, and manage an SR25519 key pair. The key pair may be randomly generated on the device. The private key may remain on the SDK and the public key may be made available through an API to the host app so that the correspondence between the host app user account and the public key may be made.

[00160] The state of the app may be verified to ensure the system has not been tampered with. If the app is running on an unsafe device, the SDK may crash the app to prevent further inspection and manipulation. The SDK may handle the camera and capture the video itself to make sure that the content has not been modified by the host app. At the end of the capture, metadata may be added and the hash may be created.

[00161] The APIs may be provided to initiate the private storage of the video and sign the transaction including the hash. When the user feels that the record is correct, they can initiate the minting of the content on-chain. An API is provided to the host app to abstract the process. Two transactions may be made: one to the private data storage, and the other to the public blockchain. Each record may have its own content ID (CID). [00162] The APIs may be provided to list the records associated to this public key: The SDK may expose APIs allowing the host app to query the blockchain and list the records that may be associated with the public key linked to the user account.

[00163] A public blockchain may provide multiple benefits such as an immutable timestamp (e.g., when the hash of the content is written on the blockchain, it is a strong proof that this exact content was not created after the timestamp). The hash of the content may be the proof that the content has not been modified. A single bit that changes in the file may result in a derived hash that may be different.

[00164] The chain transaction, such as a minted NFT of the content, may be the proof that the record has not been modified. A transaction on a blockchain may not be statistically reversible. For example, on the Bitcoin blockchain, a block is created every 10 minutes and it is estimated that a transaction is final after 6 blocks, i.e. after an hour. On a blockchain as disclosed herein, the blocks may be created every 12 seconds and the transaction may not be reversed after a block is finalized - a process which usually takes less than a minute.

[00165] The transaction cost may increase the cost to spam and attack the network. Every transaction made on chain has a cost, through transaction fees. This cost may create a strong incentive to not spam the network with thousands of fake transactions. If a “node” is taken over and submits false transactions, it may be kicked off the blockchain.

[00166] The chain may manage access control to the ability to mint Evidence Packages transparently. Because minting the evidence packages may occur on-chain, it is possible to establish that select devices may mint Evidence Packages, which may greatly reduce the potential for abuses.

[00167] The transaction cost on chain may not diminish with volume: In Web2, a drop in price may occur along with the volume of transactions. In blockchain, space on the chain is a scarce resource. A fixed price model may be used to account for this. [00168] A replay attack may be possible but may be prevented by the indexer. An attacker could replay a previously correct video recording. For instance, you can imagine a video of an infraction being taken and pushed on chain. Then a day later, the same video is pushed again. There are several ways to mitigate this including referencing hashes and reverse image searches.

[00169] Because it would be impractical to have every phone and vehicle-embedded computer to maintain a dedicated wallet with tokens for minting, a relay system may be used in which transactions may be signed by an edge device with their own private key (a phone or bus), then submitted and paid for by a single account.

[00170] Devices may sign minting transactions using an SDK. These transactions may be sent to a backend service that may co-sign these transactions and submit them on-chain. Fees may be paid for by the relay account while retaining the relationship with the device that first signed the transaction. Doing may ensure a fully auditable track of the Evidence Package’s production from creation (a phone is capturing a video), up until its record on-chain (NFT minting) and eventual submission to, e.g., a court. The system may function offline by uploading valid transactions for submission on-chain when internet connectivity may be reestablished (valuable for vehicle use cases). The system may use various off-chain data structures (e.g., a hash tree such as an off-chain Merkle trees) to prevent data written on-chain from being manipulated after capture or from being manipulated prior to capture.

[00171] The private data repository may be able to retrieve the content from its own reference on-chain or from its own hash. The content may remain private while the unique identifier of the record may be computed from the content itself, i.e. its hash, may be disclosed publicly.

[00172] A dedicated cloud service may be used for the private data storage (for example Amazon S3 or the like). This may be upgraded to a more complex IPFS deployment in a later stage. The private data storage may need to provide a level of redundancy to ensure that the content is kept safe and secure for up to 5 years. Access to the content may be limited to user accounts with permissions. Content may be verified independently by a third party with access to the media file. Verification may be made by matching the cryptographic hash of the media file with the hash stored on-chain. An API or CLI tool may be used for verifying content on-chain.

[00173] Production data and/or usage data may be measured using various sensors. The sensors may comprise any suitable sensors including e.g., cryptographically signed sensors. The sensors may be external sensors that may interface with the device (e.g., a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital camera, a digital video camera, a digital audio recorder, or the like) or may be sensors that may be located in the device (e.g., a user equipment such as a mobile phone, a laptop, a tablet, or the like, or another suitable device such as a digital camera, a digital video camera, a digital audio recorder, or the like). When cryptographically signed sensors are used, the production data and/or usage data may be processed and/or stored in one or more of a decentralized network, a decentralized storage, or a centralized storage (e.g., a cloud storage). The sensors may be configured to include a root of trust that may be signed and pushed to a blockchain.

[00174] A certificate linked to e.g., green steel may be used to go up the blockchain to identify the certificates for derivative materials. The certificates may be linked to each other to establish that the amount of clean energy produced may be verified at each point of production. For example, derivative data certificates may be linked, e.g. certificates and/or NFTs for 100MW of clean energy produced, for 1000 kg of hydrogen produced, and for one ton of green steel produced. [00175] As illustrated in FIG. 5, a block diagram 500 for various certificates and/or NFTs may include a certificate (e.g., digital certificate C 508) and/or NFT that may be linked to production (e.g., a production status such as a green status) of one or more materials (e.g., 1 ton of steel) that may be produced using one or more properties (e.g., produced using green energy/sources). The certificate 508 and/or NFT may linked to one or more upstream and/or downstream certificates (e.g., other digital certificates) and/or NFTs used in producing the one or more upstream or downstream materials (e.g., iron ore and/or H2, as shown by digital certificate AB 506) using one or more properties (e.g., a production status such as produced using green energy/sources). The one or more upstream and/or downstream materials (e.g., iron ore and/or H2) may be linked to additional upstream and/or downstream materials (e.g., iron ore mined in the USA, as shown by digital certificate A 502 and/or hydrogen produced using solar power, as shown by digital certificate B 504).

[00176] Modifications, additions, or omissions may be made to the network architecture 100 without departing from the scope of the present disclosure. The present disclosure more generally applies to the network architecture 100, 200a-d including one or more endpoint devices 105a-e, one or more wireless networks 1 lOa-d, one or more intermediate devices 115a-e, one or more second networks 120a-b, one or more relay servers 125a-b, one or more third networks 130, and one or more endpoint manager servers 135a or any combination thereof.

[00177] Moreover, the separation of various components in the implementations described herein is not meant to indicate that the separation occurs in all implementations. In addition, it may be understood with the benefit of this disclosure that the described components may be integrated together in a single component or separated into multiple components.

[00178] FIG. 6Ais a flowchart of an example arrangement of operations for a method 600 of object validation. The method 600 may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both, which processing logic may be included in any computer system or device. The software may be instructions or code capable of running on a virtualization environment and/or containerization environment such as bytecode and containerized program.

[00179] The method 600, at operation 605, comprises computing a hash of a digital file. At operation 610, the method 600 may comprise storing the digital file on a public or private data repository. At operation 615, the method 600 may comprise signing the content and the transactions stamping the content on the chain. At operation 620, the method 600 may comprise verifying the digital file using the hash.

[00180] For example, data may be captured at the edge. A short video may be taken and signed locally at the edge, i.e. by the phone itself via an SDK. The private key of the wallet may be stored on the phone. The SDK may compute the hash of the signed video. The video may be stored when the video is pushed to the private Data Repository. The data may be stamped when the private key is used to sign the content and the transactions that stamped the content on chain. The data may be verified by third parties with access to the media who can hash the content, and verify that it matches a specific reference on-chain.

[00181] The keys (e.g., private keys) may be stored in various ways. For example, the keys may be stored in a hardware security module or using a trusted execution environment, multi-party computation, trusted platform modules, virtual HSMs, non-volatile FPGA with supporting System-on-Chip configurations, or the like. In addition, secure enclaves (e.g., a computing environment that provides isolation from an operating system) may be used.

[00182] FIG. 6B is a flowchart of an example arrangement of operations for a method 600b of object validation. The method 600b may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both, which processing logic may be included in any computer system or device. The software may be instructions or code capable of running on a virtualization environment and/or containerization environment such as bytecode and containerized program.

[00183] The method 600b, at operation 630, includes identifying a digital file. At operation 635, the method 600b may include verifying the digital file using metadata associated with the digital file. At operation 640, the method 600b may include minting a non-fungible token (NFT) using the digital file and the metadata associated with the digital file.

[00184] FIG. 6C is a flowchart of an example arrangement of operations for a method 600c of object validation. The method 600c may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both, which processing logic may be included in any computer system or device. The software may be instructions or code capable of running on a virtualization environment and/or containerization environment such as bytecode and containerized program.

[00185] The method 600c, at operation 650, includes identifying a block chain header and a public key. At operation 655, the method 600c may include capturing content using the block chain header and the public key. At operation 660, the method 600c may include generating attested content based on the content. At operation 665, the method may include signing the attested content using a unique device certificate to generate signed attested content. At operation 670, the method may include pushing a hash of the signed attested content onto a chain by signing with a user wallet.

[00186] For simplicity of explanation, methods described herein are depicted and described as a series of acts. However, acts in accordance with this disclosure may occur in various orders and/or concurrently, and with other acts not presented and described herein. Further, not all illustrated acts may be used to implement the methods in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the methods may alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, the methods disclosed in this specification are capable of being stored on an article of manufacture, such as a non-transitory computer-readable medium, to facilitate transporting and transferring such methods to computing devices. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

[00187] FIG. 7 is a schematic view illustrating a machine in the example form of a computing device 700 within which a set of instructions, for causing the machine to perform any one or more of the methods discussed herein, may be executed. The computing device 700 may include a mobile phone, a smart phone, a netbook computer, a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, or any computing device with at least one processor, etc., within which a set of instructions, for causing the machine to perform any one or more of the methods discussed herein, may be executed. In alternative implementations, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server machine in client-server network environment. The machine may include a personal computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” may also include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein.

[00188] The example computing device 700 includes a processing device (e.g., a processor) 702, a main memory 704 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM)), a static memory 706 (e.g., flash memory, static random access memory (SRAM)) and a data storage device 716, which communicate with each other via a bus 708.

[00189] Processing device 702 represents one or more general -purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 702 may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 702 may also include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 702 is configured to execute instructions 726 for performing the operations and steps discussed herein.

[00190] The computing device 700 may further include a network interface device 722 which may communicate with a network 718. The computing device 700 also may include a display device 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse) and a signal generation device 720 (e.g., a speaker). In at least one implementation, the display device 710, the alphanumeric input device 712, and the cursor control device 714 may be combined into a single component or device (e.g., an LCD touch screen). [00191] The data storage device 716 may include a computer-readable storage medium 724 on which is stored one or more sets of instructions 726 embodying any one or more of the methods or functions described herein. The instructions 726 may also reside, completely or at least partially, within the main memory 704 and/or within the processing device 702 during execution thereof by the computing device 700, the main memory 704 and the processing device 702 also constituting computer-readable media. The instructions may further be transmitted or received over a network 718 via the network interface device 722. [00192] While the computer-readable storage medium 724 is shown in an example implementation to be a single medium, the term “computer-readable storage medium” may include a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” may also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methods of the present disclosure. The term “computer-readable storage medium” may accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.

[00193] As illustrated in FIG. 8, a device 800 (e.g., an endpoint device or a user equipment or any other suitable device) may include a host application 810. The host application 810 may include an offline component 820 (e.g., a component that may not be connected to a network) and a connected component 830 (e.g., a component that may be connected to a network). The offline component 820 may include a content capture component 822. The connected component 830 may include a chain client 832. The chain client 832 may be operable to receive a block header 836 and may be operable to interface with a user wallet 834. The block header 836 may include information about a block and/or a blockchain 850. For example, the block header 836 may include a timestamp, a hash representation of block data, a hash of a previous block’s header, a cryptographic nonce, a randomly generated string, etc. The randomly generated string may be generated periodically, for example, every ten seconds. In some embodiments, the block header 836 itself may be regenerated periodically, such as every second, every ten seconds, every day, or any other suitable period of time, which may repeat at any interval, including non-equally spaced intervals. The block header 836 may be obtained from a blockchain network. Additionally or alternatively, the block header 836 may be generated using the operating system 840 and the blockchain 850.

[00194] The offline component 820 may not be connected to a network to maintain the authenticity of the content captured by the content capture component 822. A content component connected to a remote server may receive content that may not be captured at the device 800. For example, a content component that does not comprise an offline component 820 may receive a photo or video from a remote location, which may destroy the authenticity of the photo or video received at the offline component 820.

[00195] The offline component 820 may include a content capture component 822 which may capture the content (e.g., any suitable content that may be captured using sensor data from a suitable sensor), add attestations provided by the host app 810, and/or sign the content with a unique device certificate.

[00196] The attestation provided by the host app 810 may include any suitable attestation and/or attestation data as disclosed herein. For example, attestation for content may be added or verified. An attestation may be added (e.g., using a CAI standard, C2PA Standard or a different attestation standard) to non-attested content. The attestation standard (e.g., CAI standard or non-CAI standard) may be used to verify that content is authentic, to verify provenance for the content, or to verify a creator for the content. When a CAI standard has not been used, content may be uploaded that has been attested using a non-CAI standard. Specifically, the content may be attested using a block header 836 and/or user wallet 834. [00197] The content capture component 822 may sign the content with a unique device certificate. The unique device certificate may be any suitable certificate that may facilitate authentic and secure connections using public key infrastructure (PKI). The unique device certificate may be issued by a private certificate authority. The PKI may differ for each subsystem.

[00198] The connected component 830 may include a chain client 832 that may receive a block header 836 (e.g., from a blockchain 850) and may include a user wallet 834 including a private key and/or a public key. The chain client 832 may sign a hash of captured content received from the content capture component 822 and push the hash to the blockchain 850.

[00199] The chain client 832 may obtain data from the blockchain 850. That is, the chain client 832 may access the blockchain 850 to receive a block header 836. The block header 836 may be used to authenticate the date and/or time (e.g., using a timestamp from the block header 836). The connected component 830 may identify location data (e.g., using GPS from the operating system 840). The connected component 830 (e.g., the chain client 832) may send the timestamp (e.g., from the block header 836 to the content capture component 822. The connected component 830 may send the location (e.g., computed using GPS) to the content capture component 822. The chain client 832 may send a key (e.g., a public key) from the user wallet 834 to the content capture component 822.

[00200] The content capture component 822 may capture content and embed one or more parameters used to attest to the content, e.g., which may be generally attestation data or may be more specifically data from the block header 836 (e.g., a timestamp) and/or a key (e.g., a public key) from the user wallet 834. The resulting attested content may be signed by a unique device certificate. In some embodiments, mechanisms other than or in addition to the block header can be used for attesting to the time at which the content is created and/or is put through the attestation process. For example, the host application can be configured to contact a Timestamping Authority such as Entrust, DigiCert or Global Sign to prove capture/creation time of a particular piece of content.

[00201] In this way, the host application is able to attest and save attestation data to the block chain without needing to rely on an attestation server for content attestation. In some embodiments, the attestation process can also be enhanced by other locally situated endpoint devices running on a network architecture similar to network architecture 100, as depicted in FIG. 1. For example, in this use case one or more other endpoint devices can be leveraged to confirm capture and/or creation of the content being attested to and in some cases provide additional processing power to quickly and efficiently generate a content signature / attestation. In some embodiments, the other attestation devices can help confirm the metadata from the device that captured or created the content by utilizing on-board sensors of the attestation devices to confirm data such as location, time of day, weather, and the like. This data provided by on-board sensor from nearby end point devices can be used to provide additional verification of and/or to confirm one or more pieces of metadata associated with the content undergoing the attestation process.

[00202] The content capture component 822 in device 800 may receive attested content from a different device. For example, a different device may capture content such as a photo or video. The content may be attested using an attestation standard (e.g., CAI standard or non-CAI standard). The attested content may be sent to the content capture component 822. The attested content may be embedded with one or more parameters to provide an additional attestation to the content (e.g., using the block header 836 and/or a key) from the user wallet 834. The resulting content may be signed by a unique device certificate from the device 800. [00203] The content capture component 822 in device 800 may receive attested content from a different device in which the different device may use a different content capture component to embed the content with one or more parameters to provide attestation to the content (e.g., using a different block header and/or key from the different device).

[00204] The one or more parameters embedded with the content to provide attestation to the content may be any suitable parameters that may be identified without spoofing. For example, the blockchain header may provide a suitable random number that may not be predicted without access to the blockchain in a specific time window. The GPS location may provide a suitable parameter that may not be spoofed without having access to a device in the same location.

[00205] Other parameters may be used to provide attestation to the content when the parameters are combined with one or more attested parameters. For example, a medium access control (MAC) address, e.g., for a Bluetooth® device connected to the device 800 may be used to provide parameters to the chain client 832 and/or content capture component 822 when combined with one or more attested parameters (e.g., from a blockchain header and/or from a GPS location and/or an on-board sensor).

[00206] Multifactor authentication may be used to provide attestation to the content by combining the multi-factor authentication with the one or more attested parameters.

Examples of multi-factor authentication may include biometric data (e.g., fingerprints, facial, voice, iris, palm, or the like). Multifactor authentication may be used to verify the identity of a user of the device 800. The identity of the user of the device may be tied to a reputation of the user of the device.

[00207] The one or more parameters (e.g., the attested parameters) may be inserted into the content to generate resulting attested content. The resulting attested content may include the attested parameters as part of the content. For example, the block header and the public key may be present as metadata in the content. [00208] The content may be stored using any suitable file that may be combined with the attested parameters. For example, the video file may be any suitable file as disclosed herein and the image file may be any suitable file as disclosed herein. In some examples, the file may be in a portable document format (PDF).

[00209] The resulting attested content may be pushed onto the blockchain 850. The chain client 832 may push the content onto the blockchain 850 by signing a transaction using the user wallet. The content may be stored on an open infrastructure or a closed infrastructure. [00210] As illustrated in FIG. 9, a process flow is provided for content verification. This process flow may be performed on content previously captured by device 800 or attested to by other devices that are stored within the offline component 820 of the device 800 following a user request to attest one or more content files. As shown in operation 902, a block chain header may be identified. The block chain header may include a timestamp that may be used to provide a specific time window for attestation. As shown in operation 904, a public key may be identified. The public key may be used with the block chain header (e.g., a timestamp of the block chain header) for attestation. As shown in operation 906, content may be captured using the block chain header (e.g., a timestamp) and a public key. As shown in operation 908, attested content may be generated using the captured content, the block chain header (e.g., a timestamp) and a public key. As shown in operation 910, attested content may be signed using a unique device certificate. As shown in operation 912, a hash of the content may be pushed onto the blockchain by signing using a user wallet. Alternatively or in addition, a user’s signature may be used to push documents on-chain and e.g., for C2PA supported media, the device signature may be used for attestation.

[00211] The content may be captured using any suitable sensor. The sensor may be one or more of an accelerometer, a gyroscope, a barometer, a proximity sensor, an ultrasonic sensor, a magnetic sensor, a pressure sensor, a photoelectric sensor, a capacitive sensor, a position sensor, an image sensor, a photodetector, a thermistor, a motion detector, an infrared sensor, a geophone, a hydrophone, a microphone, a seismometer, a sound locator, a chemical sensor, a current sensor, an air pollution sensor, an electrochemical gas sensor, a gas meter, a mass flow sensor, a water meter, an air flow meter, a Geiger counter, an altimeter, light detection and ranging (LIDAR), a tactile sensor, a strain gauge, a heat sensor, a thermometer, a radar, a wireless sensor network, a speedometer, or the like.

[00212] The sensor may receive any suitable sensor data, e.g., acoustic data, sound data, vibration data, automotive data, chemical data, electric current data, electric potential data, magnetic data, radio data, environmental data, weather data, moisture data, humidity data, flow data, fluid velocity data, ionizing radiation data, subatomic particle data, position data, angular data, displacement data, distance data, motion data, speed data, acceleration data, optical data, light data, imaging data, photon data, pressure data, force data, density data, level data, thermal data, heat data, temperature data, proximity data, presence data, or the like.

[00213] The sensor may collect sensor data using any suitable device. The device may be offline (e.g., an offline component 820 as illustrated in FIG. 8). Using an offline device may maintain the provenance and attestation of the sensor data collected using the sensor of the device.

[00214] FIG. 10A shows an example electronic device 1000 having a touch screen 1002. Touch screen 1002 is illustrated displaying a user interface 1004-1. User interface 1004-1 can be one of many user interfaces displayed during operation of an application similar to previously described host application 810 running on electronic device 1000. User interface 1004-1 includes a viewing region 1006 configured to display a real-time representation of sensor data being collected by one or more sensors of electronic device 1000. In some embodiments, a sensor of electronic device 1000 associated with viewing region 1006 can take the form of an imaging sensor configured to record images and/or video data. User interface 1004-1 can include one or more affordances that allow a user of electronic device

1000 to change one or more operating modes of the sensor of electronic device 1000 associated with viewing region 1006 when interacting with a displayed affordance using touch screen 1002. For example, affordances 1008 and 1010 allow a user to request viewing region 1006 (and a later captured image) to switch back and forth between 4:3 and 16:9 aspect ratios.

[00215] User interface 1004-1 also includes a recording affordance 1012. Actuation of recording affordance 1012 causes electronic device 1000 to generate one or more files containing data collected by a sensor of electronic device 1000. In some embodiments, this file or files can be saved to local memory of electronic device 1000 in a manner similar to the one described in the context of offline component 820 above. User interface 1004-1 also includes a sensor switching affordance 1014 for interacting with and storing data generated by different sensors of electronic device 1000. In some embodiments, sensor switching affordance 1014 can be configured to switch between a primary imaging sensor and a secondary imaging sensor of electronic device 1000. Alternatively, multiple taps of sensor switching affordance 1014 can cause user interface 1004-1 to cycle through multiple different types of on-board sensors, including non-imaging sensors such as microphones and LIDAR sensors. In some embodiments, sensor switching affordance 1014 can allow a user to concurrently collect sensor data from multiple on-board sensors. User interface 1004-1 also includes a content selection affordance 1016 allowing a user to select a data file created by the application displaying user interface 1004-1.

[00216] It should be noted that while user interface 1004-1 shares many characteristics with a native camera or sensor controlling application, the tools differences described herein can in some embodiments be added to the native sensor controlling application. For example, installation of the host application 810 could be configured to add a toggle or button that automatically initiates an attestation to any images captured by a native camera application. The camera roll can also include one or more affordances allowing for attestation of particular images saved to the camera roll. For example, the share button on the camera roll application could have an option for image attestation and/or an option for sharing an attested image to one or more websites specifically compatible with attested images. Camera roll can also include a feature that allows a user to display images containing enough metadata to effect an attestation. This filter can also be applied in response to a user selecting the attestation affordance and/or the attested sharing affordance described above.

[00217] Selection of content selection affordance 1016 causes electronic device 1000 to display user interface 1004-2 as shown in FIG. 10B, which allows a user to select one or more of a number of content files represented by affordances 1018-1 to 1018-14. It should be appreciated that user interface 1004-2 can include a smaller or larger number of affordances 1018-1 to 1018-14. In some embodiments, user interface 1004-2 can include paging affordances allowing a user to peruse large numbers of affordances 1018 representing files captured using the application displaying user interface 1004-2. User interface 1004-2 can alternatively allow a user to use a swipe gesture to scroll through large numbers of affordances 1018-1 to 1018-14. It should be noted that while an upper region of user interface 1004-2 indicates affordances 1018-1 to 1018-14 represent local photos that affordances 1018-1 to 1018-14 can also represent many different types of content other than photos. Furthermore, in configurations where the application is in communication with other content repositories, user interface 1004-2 can be configured to display photos hosted on the cloud or on neighboring devices. When the content repositories accessed using user interface 1004-2 use their own attestation standard (e.g. CAI or C2PA standards) an attestation generated by the application for an already attested to content file can add on to the previously existing attestation. In some embodiments, the attestation added by the application can highlight any changes that have occurred since the content had last been attested to.

[00218] FIG. 10C shows user interface 1004-3, which is displayed following a user’s selection of one of affordances 1018-1 to 1018-14. User interface 1004-3 includes a selected content region 1020 in which a preview of the content is displayed. When the content is an image or video, selected content region 1020 would generally include a thumbnail or short video clip. In cases where multiple content files are selected in user interface 1004-2, selected content region 1020 can include representations of each of the selected content files. This allows a user to confirm they have selected the right content file or files prior to initiating an attestation event. In the event the selected content file is an audio file electronic device 1000 could be configured to play a short clip from the selected audio file. User interface 1004-3 also includes an information affordance 1022, which allows a user to bring up another user interface (see FIGS. 10F - 10G) showing saved metadata associated with the selected content file. User interface 1004-3 also includes a region 1024 in which a date and time of capture for the file represented in selected content region 1020 is displayed.

[00219] User interface 1004-3 also includes an attestation affordance 1026, which allows a user to request the application displaying user interface 1004-3 initiates an attestation operation on the file or files represented in selected content region 1020. In some embodiments, attestation affordance 1026 involves a swiping gesture be applied to attestation affordance 1026 using touch screen 1002 to avoid the file being attested unintentionally. Attestation affordance 1026 can be implemented in many ways and may include entry of some pin, signature or password known by the user to further assure the identity of the user signing the content file. In some embodiments, electronic device 1000 can be configured to capture one or more biometric features of the user when a content file authentication is requested. In some embodiments, when the biometric feature or features captured by the application do not match a current user of the application, the application can be configured to repeat the biometric feature capture or request the user switch the account to an account matching the user’s biometrics. Biometric features can be gathered in many ways including, e.g., by a biometric device log in sensor and/or by a front facing camera.

[00220] Attestation of the content file has been previously described in the text accompanying FIGS. 8 and 9 and generally involves multiple steps that can be performed using data supplied by both electronic device 1000 and/or other nearby or remote electronic devices. Following attestation, electronic device 1000 can initiate a transaction that includes an identification of the attested file and is signed with a private key that is subsequently transmitted to the different nodes of a block chain to prevent any subsequent manipulation of the attested content file.

[00221] FIG. 10D shows user interface 1004-4, which is displayed while the application showing user interface 1004-4 is displayed on electronic device 1000. In some specific embodiments, content sign indicia 1028 moves from a left side of attestation affordance 1026 to a right side of attestation affordance 1026 when a user swipes from left to right on attestation affordance 1026. User interface 1004-4 can also include an animated signature indicia 1030 that is drawn on to attestation affordance 1026 as the authentication is being performed. In some embodiments, signature indicia 1030 can correspond to a user’s actual signature when setup in the settings of the application. The unique signature indicia 1030 can be helpful to confirm to a user that the correct account is being used to attest / sign the selected content file.

[00222] FIG. 10E shows a user interface 1004-5, which is displayed following authentication of the selected content file. User interface 1004-5 shows an authenticated indicia 1032 in an upper region of user interface 1004-5. User interface 1004-5 also includes a download affordance 1034, which in response to being selected moves a copy of the authenticated content file outside of the application to a local storage location accessible by an other application, such as the camera roll on a smart phone. User interface 1004-5 also includes a publication affordance 1036, which allows a user to publish the authenticated file to a location online where similarly authenticated images can be viewed.

[00223] FIG. 10F shows a user interface 1004-6, which is displayed by the application in response to selection of information affordance 1022 or can alternatively be accessed when viewing the authenticated image after selecting publication affordance 1036. User interface 1004-6 displays metadata associated with the authenticated content file and also shows a visualization for the location in which the content was captured. The visualization of the capture location is illustrated as map 1038, which includes content creation indicia 1040 that graphically points out the content creation location. In some embodiments, map 1038 can also include other points of interest such as locations where the content file has previously been edited after being created. User interface 1004-6 also displays a user key that uniquely identifies the user of the application and details describing electronic device 1000 and components relevant to the capture of the content file.

[00224] Alternatively or in addition, more than one signature (e.g., two) may be combined. For example, a user signature and a device’s signature (as provided using attestation) may be combined. As illustrated in FIG. 10F, the signature may be signed 1042 using an app (e.g., Click App) and/or the signature may be signed 1044 by a user (e.g., as shown in user interface 1004-6).

[00225] FIG. 10G shows a portion of user interface 1004-6 revealed by scrolling down on user interface 1004-6 that includes additional metadata. In particular, the metadata includes the settings used by the sensor to create the attested to content file and settings describing the attested to content file. While user interface 1004-6 is shown providing a limited amount of metadata it should be appreciated that additional metadata could be displayed on user interface 1004-6. In some embodiments, a user could be presented the option to include a smaller or greater amount of metadata. Furthermore, additional metadata not listed on user interface 1004-6 could be used to help with authentication of a particular content file. While the application has been presented primarily in the form of an application running on a mobile device such as a smart phone, the attested to content could also be displayed on a traditional website. For example, a clickable indicia could be positioned in a periphery of a visual representation of the attested to content. Selection of the clickable indicia can result in user interface 1004-6 as show in FIGS. 10F - 10G being presented next to or overlapping with the visual representation. In this way, a viewer of the attested to content can conveniently be allowed to view metadata and an indicia verifying to the viewer of the authenticity of the content. In some embodiments, this user interface can also include additional functionality allowing the viewer to initiate a verification check to provide further assurances to the viewer of the authenticity of the content. This verification check can be performed by an API or web service able to reach out and verify the metadata information with one or more nodes of the associated block chain.

Examples

[00226] In one example, a computer implemented method may comprise: identifying a digital certificate for a material. The digital certificate may be operable to verify one or more properties of the material. In another example, the computer-implemented method may comprise linking the digital certificate for the material to one or more additional digital certificates used to verify one or more additional properties of the material. In another example, the computer-implemented method may comprise verifying the one or more additional properties of the material using the one or more additional digital certificates. [00227] In one example, the material may be a building material or a commodity. In another example, the commodity may be a shipment of gas or wood pellets. In another example, the one or more properties of the material may comprise a material production status. In another example, the one or more additional properties of the material may comprise a component material production status.

[00228] Terms used herein and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” may be interpreted as “including, but not limited to,” the term “having” may be interpreted as “having at least,” the term “includes” may be interpreted as “includes, but is not limited to,” etc.).

[00229] Additionally, if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases may not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” may be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations.

[00230] In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation may be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, means at least two recitations, or two or more recitations). Further, in those instances where a convention analogous to “at least one of A, B, and C, etc.” or “one or more of A, B, and C, etc.” is used, in general such a construction is intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc. For example, the use of the term “and/or” is intended to be construed in this manner.

[00231] Further, any disjunctive word or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, may be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” may be understood to include the possibilities of “A” or “B” or “A and B.” [00232] Implementations described herein may be implemented using computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computerexecutable instructions or data structures and which may be accessed by a general purpose or special purpose computer. Combinations of the above may also be included within the scope of computer-readable media.

[00233] Computer-executable instructions may include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[00234] As used herein, the terms “module” or “component” may refer to specific hardware implementations configured to perform the operations of the module or component and/or software objects or software routines that may be stored on and/or executed by general purpose hardware (e.g., computer-readable media, processing devices, etc.) of the computing system. In some implementations, the different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). While some of the system and methods described herein are generally described as being implemented in software (stored on and/or executed by general purpose hardware), specific hardware implementations or a combination of software and specific hardware implementations are also possible and contemplated. In this description, a “computing entity” may be any computing system as previously defined herein, or any module or combination of modulates running on a computing system.

[00235] All examples and conditional language recited herein are intended for pedagogical objects to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Although implementations of the present disclosure have been described in detail, it may be understood that the various changes, substitutions, and alterations may be made hereto without departing from the spirit and scope of the present disclosure.

Claims

WHAT IS CLAIMED IS:

1. A device for digital file verification, comprising: data processing hardware; and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that when executed on the data processing hardware cause the data processing hardware to perform operations comprising: computing, at the device, a hash of a digital file based on metadata and a proof; storing, using the device, the digital file on a data repository; signing, using the device, content of the digital file and one or more transactions stamping the content on a chain; and verifying, at the device, the digital file using the hash.

2. The device of claim 1, wherein the instructions, when executed on the data processing hardware, cause the data processing hardware to perform operations comprising: computing, at the device, the proof based on an object identifier, wherein the object identifier is associated with the digital file.

3. The device of claim 1, wherein the instructions, when executed on the data processing hardware, cause the data processing hardware to perform operations comprising: computing, at the device, a token proof based on an object identifier and token metadata, wherein the token metadata is associated with a token that is based on the digital file.

4. The device of claim 4, wherein the token is a non-fungible token and the object identifier is a content identifier (CID).

5. The device of claim 1, wherein the device comprises a cryptographically signed sensor.

6. The device of claim 1, wherein the device comprises one or more of: a decentralized network a decentralized storage, or a centralized storage comprising cloud storage.

7. The device of claim 1, wherein the device is a user equipment.

8. The device of claim 1, wherein the digital file is a digital certificate.

9. The device of claim 1, wherein the instructions, when executed on the data processing hardware, cause the data processing hardware to perform operations comprising: communicating with one or more other nearby devices to confirm the metadata associated with the digital file.

10. The device of claim 1, wherein the instructions, when executed on the data processing hardware, cause the data processing hardware to perform operations comprising: computing, at the device, the proof based on the metadata and a private key.

11. A computer-implemented method comprising: identifying a digital file; verifying the digital file using metadata associated with the digital file; and minting a non-fungible token (NFT) using the digital file and the metadata associated with the digital file.

12. The computer-implemented method of claim 11, further comprising: pushing the digital file to a distributed file system; and receiving a content identifier (CID) from the distributed file system.

13. The computer implemented method of claim 12, further comprising: pushing NFT metadata and the CID to the distributed file system; receiving an NFT CID from the distributed file system; and pushing the NFT CID to a blockchain.

14. The computer-implemented method of claim 11, wherein the digital file comprises a digital image file or a video file.

15. The computer implemented method of claim 11, wherein the computer-implemented method is executed on a user equipment.

16. A device, comprising: data processing hardware; and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that when executed on the data processing hardware cause the data processing hardware to perform operations comprising: identifying, at the device, a block chain header and a public key; capturing, at the device, content using the block chain header and the public key; generating, at the device, attested content based on the content; signing, at the device, the attested content using a unique device certificate to generate signed attested content; and pushing, at the device, a hash of the signed attested content onto a chain by signing with a user wallet.

17. The device of claim 16, wherein the block chain header comprises one or more of a timestamp or a location.

18. The device of claim 16, wherein the content comprises one or more of a digital image file or a digital video file.

19. The device of claim 16, wherein the device further comprises: an offline component including a content capture component; and a connected component including a chain client operable to receive a block header and operable to interface with the user wallet.

20. The device of claim 16, wherein the device further comprises a user interface operable to sign the attested content.