Systems, methods, and computer program products for providing immutable digital securities

Abstract

Methods, systems, and computer program products are provided for creating and retrieving immutable digital securities that involve activating a process on a device having a unique identifier; and authenticating a creator of the immutable digital witness using the unique user ID registered with the witness network. The apparatus activates the associated camera for generating the media stream. The frames are hashed using the selected scheme to create a stream hash, thereby forming a real-time stream hash, and metadata to be recorded on the blockchain is captured. Streaming media and hash schemes are communicated to a cloud server for storage, where cloud addresses or distributed file system (DFS) addresses are retrieved to determine where the media are saved. Real-time streaming media is encrypted and sent to the DFS, an encrypted media address is received, and the streaming media is saved locally on the device.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to U.S. Provisional Patent Application Serial No. 63 / 506,185, filed June 5, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0003] The example implementations described herein generally relate to signal processing and blockchain technologies, and more specifically, to performing signal processing on various signals to provide immutable digital testimony. Background Technology

[0004] There are many situations where it may be necessary to provide evidence of where witnesses say they are now or were in the place. For example, an alibi is generally defined as a claim or evidence that a person was elsewhere when an act such as a crime allegedly occurred. An alibi defense can allow witnesses to testify and present evidence to support the alibi defense at trial. Certain industry, government, and individual situations may also require such evidence outside of a criminal context.

[0005] However, evidence of someone's location or alleged behavior can be difficult to prove. One person's testimony is often insufficient. If visual evidence and location cannot be proven with a relatively high degree of certainty, it may not convince those who require proof of a person's whereabouts and behavior at a specific time and place (e.g., parents, spouses, employers, governments, courts, etc.).

[0006] The mere fact that those who claim to be on the move have evidence to support their claims does not automatically mean that the evidence they present will be accepted. For evidence to be considered admissible, it must meet the test of being true.

[0007] Authentication typically refers to a rule of evidence that requires evidence to be sufficient to support the finding that the matter under discussion is what its proponents claim. The "authenticity" rule relates to whether the subject matter (usually something tangible) presented by the evidence is what it supports. This is the legal way in which evidence must be proven authentic for a claim to be admissible.

[0008] Authentication of evidence can be achieved through technical means, such as presenting mobile device communication logs obtained from wireless network providers, or presenting photos or videos containing geolocation metadata. However, concerns about the authenticity of such evidence are significant. Technology even gives children the ability to alter the audiovisual content and associated metadata contained in digital files. More worryingly, recent advances in artificial intelligence are expected to lead to easier and more automated means of altering or computer-generated digital videos and photos.

[0009] Typical techniques for preventing the tampering of digital evidence attempt to detect clear indications of alteration, such as by detecting unusual artifacts and inconsistencies in digital files, or by embedding "invisible" data (e.g., watermarks, noise, etc.) into digital files (e.g., image or audio files). The playback device can then detect changes to the content or embedded data in the digital file to provide an indication that the evidence has been altered.

[0010] However, typical technologies still share a common concept: they modify content and thus alter the evidence. Other technologies may not modify content, but they also cannot verify that content has not been modified, and therefore cannot confidently authenticate evidence. Therefore, one technical problem involves using available technologies (e.g., image capture devices, microphones, GPS, or other types of sensors) to somehow authenticate content used as evidence without altering it. Another technical challenge involves creating a system that orchestrates the process of practically and efficiently capturing, storing, and transmitting immutable evidence across one or more networks.

[0011] At its core, a blockchain is a distributed ledger that records transactions. A public blockchain typically refers to a blockchain that serves as a distributed public ledger, while a private blockchain (which can also be called a managed blockchain) is a permissioned blockchain controlled by a single organization.

[0012] Blockchain technology has been used to prepare media content for authentication by adding blocks to media content files within the blockchain. Block identifiers from the blockchain network are generated and used as the watermark payload embedded in the content file. Therefore, similar to the example provided above, the evidence is modified.

[0013] NFTs, or non-fungible tokens, are crypto assets stored on a blockchain. Typically, an NFT serves as a unique digital certificate proving ownership or authenticity of a digital artwork or asset. An NFT is not the artwork or asset itself. However, neither NFTs nor the underlying artwork can be used as immutable evidence of a person's location at a specific point in time. Summary of the Invention

[0014] The exemplary implementations described herein address the identified needs by providing methods, systems, and computer program products for providing immutable digital testimonies.

[0015] In an implementation, a method for creating immutable digital testimony is provided. The method involves the following steps: activating an immutable digital testimony creation operation on a device having an immutable digital testimony device identifier (ID), wherein the immutable digital testimony device ID is a unique identifier for the device; authenticating the creator of the immutable digital testimony based on the immutable digital testimony creator ID, wherein the immutable digital testimony creator ID is a unique user identifier created when registering with an immutable digital testimony network; capturing the immutable digital testimony device ID of the device used to create the immutable digital testimony; and, after authentication of the creator, initiating an immutable digital testimony capture operation by the device, including: activating a device associated with the device. One or more camera devices are used, and the devices generate immutable digital testimony streaming media; one or more frames of the immutable digital testimony streaming media from one or more camera devices are hashed by applying an immutable digital testimony hashing scheme selected from multiple hashing schemes, thereby creating one or more immutable digital testimony stream hashes; a real-time stream hash is formed from one or more immutable digital testimony stream hashes; immutable digital testimony metadata to be recorded on the immutable digital testimony authentication blockchain is captured; and the device transmits the immutable digital testimony streaming media and the selected immutable digital testimony hashing scheme to a cloud server, thereby enabling the selected immutable digital testimony to be recorded on the blockchain. The testimony hashing scheme and immutable digital testimony streaming media are stored on a cloud server as immutable digital testimony cloud media. Retrieval of one or more immutable digital testimony addresses, each of which is: one or more cloud addresses on the cloud server; one or more DFS addresses on the Distributed File System (DFS); or a combination of i and ii, whereby each of the one or more immutable digital testimony addresses corresponds to a location where the immutable digital testimony cloud media is stored. The immutable digital testimony cloud media is at least a part of the immutable digital testimony streaming media, after transmission is complete: for immutable... The method involves encrypting a live stream of digital testimony to create an encrypted, immutable live stream of digital testimony, the encrypted, immutable live stream of digital testimony being at least a portion of the immutable live stream of digital testimony; sending the encrypted, immutable live stream of digital testimony to a DFS to store the encrypted, immutable live stream of digital testimony; receiving one or more immutable DFS addresses of digital testimony, each of which corresponds to a location where the encrypted, immutable live stream of digital testimony has been stored; and storing the immutable live stream of digital testimony on a device to create immutable local media of digital testimony.

[0016] In some implementations, the method involves: selecting one or more frames of immutable digital testimony local media corresponding to the same one or more frames of the immutable digital testimony streaming media; hashing one or more frames of the selected one or more frames of the immutable digital testimony local media using the selected immutable digital testimony hashing scheme to create one or more immutable digital testimony local hashes; forming local symbiotic hashes from one or more immutable digital testimony local hashes; sending the local symbiotic hashes to a smart contract by a device for verification against a live stream hash; and sending the live stream hashes, immutable digital testimony metadata, one or more immutable digital testimony DFS addresses, and one or more immutable digital testimony cloud addresses to the smart contract by the device.

[0017] In some implementations, the method involves: selecting one or more frames of immutable digital testimony cloud media corresponding to the same one or more frames of the immutable digital testimony streaming media; hashing one or more frames of the selected one or more frames of the immutable digital testimony cloud media using the selected immutable digital testimony hashing scheme to create one or more immutable digital testimony cloud hashes; forming a cloud media hash from one or more immutable digital testimony cloud hashes; and having a cloud server send the cloud media hash to a smart contract for verification against the live stream hash.

[0018] In some implementations, the method further involves: creating a creator token by a smart contract by combining an immutable digital testimony creator ID and an immutable digital testimony device ID; creating an immutable digital testimony identifier (ID) by a smart contract by hashing the creator token with a live streaming hash; and comparing the live streaming hash, the local symbiotic hash, and the cloud media hash by a smart contract, and if a) the live streaming hash reflects the local symbiotic hash, and b) the live streaming hash reflects the cloud media hash, then: creating an immutable digital testimony identifier (ID) by a smart contract by hashing the immutable digital testimony ID, one or more immutable digital testimony cloud addresses, immutable digital testimony metadata, one or more immutable digital testimony DFS addresses, and the live streaming hash. Testimony hash; a smart contract stores the immutable digital testimony ID, one or more immutable digital testimony cloud addresses, immutable digital testimony metadata, one or more immutable digital testimony DFS addresses, immutable digital testimony hash, and real-time stream hash on the immutable digital testimony authentication blockchain, and records user permissions on the immutable digital testimony authentication blockchain; the user permissions are sent to the immutable digital testimony orchestrator to create log entries based on the user permissions, which indicate whether the corresponding immutable digital testimony creator ID has any permissions to the immutable digital testimony cloud media associated with a specific immutable digital testimony ID; and the smart contract records the immutable digital testimony ID and immutable digital testimony hash on the public blockchain.

[0019] In some implementations, the method also involves: granting a requester permission by a smart contract to view an immutable digital testimony corresponding to an immutable digital testimony ID, and registering the viewing permission on the immutable digital testimony authentication blockchain and the immutable digital testimony orchestrator.

[0020] In some implementations, the method involves using immutable digital testimony hashes recorded on a public blockchain to periodically verify and authenticate the immutable digital testimony authentication blockchain.

[0021] In some implementations, the method involves: if a) the real-time stream hash and the local co-occurrence hash do not match, or b) the real-time stream hash and the cloud media hash do not match, then: creating an alternative immutable digital testimony by saving the immutable digital testimony local media to the DFS and the cloud server, and accordingly retrieving one or more alternative immutable digital testimony DFS addresses and one or more alternative immutable digital testimony cloud addresses; and providing notification by a smart contract that the immutable digital testimony streaming media is corrupted during transmission or storage.

[0022] In some implementations, the method involves a device sending immutable digital testimony metadata, a real-time streaming hash, a local co-occurrence hash, one or more alternative immutable digital testimony cloud addresses, and one or more alternative immutable digital testimony DFS addresses to a smart contract.

[0023] In some implementations, the method involves: receiving alternative immutable digital testimony metadata, a live streaming hash, a local symbiotic hash, and one or more alternative immutable digital testimony DFS addresses by a smart contract; creating an alternative creator token by the smart contract by combining the immutable digital testimony creator ID and the immutable digital testimony device ID; creating an immutable digital testimony alternative ID by the smart contract by hashing the alternative creator token with the live streaming hash and appending an ALT to the end of the immutable digital testimony alternative identifier (ID); and combining the immutable digital testimony alternative ID, the immutable digital testimony metadata, one or more alternative immutable digital testimony cloud addresses, one or more alternative immutable digital testimony DFS addresses, and the local symbiotic hash with... The smart contract creates alternative immutable digital testimony hashes by hashing real-time streaming hashes; the smart contract records the immutable digital testimony alternative ID, immutable digital testimony metadata, one or more alternative immutable digital testimony cloud addresses, one or more alternative immutable digital testimony DFS addresses, real-time streaming hashes, local symbiotic hashes, and alternative immutable digital testimony hashes to the immutable digital testimony authentication blockchain; the smart contract records the user permission corresponding to the immutable digital testimony alternative ID on the authentication blockchain and sends the user permission to the immutable digital testimony orchestrator to update the log entries of the immutable digital testimony orchestrator; and the smart contract records the alternative immutable digital testimony ID and the alternative immutable digital testimony hash on the public blockchain.

[0024] In some implementations, the method involves: receiving user viewing permission for an immutable digital testimony corresponding to an immutable digital testimony alternative ID by an immutable digital testimony orchestrator; and creating a local ledger of permission details by the immutable digital testimony orchestrator based on the user permission.

[0025] In some implementations, the method involves: authenticating a third-party immutable digital testimony requester; initiating a third-party request from the immutable digital testimony creator by the third-party immutable digital testimony requester, the third-party request being any one or more of the following: an immutable digital testimony request requesting the creation and sharing of a new immutable digital testimony; an immutable digital testimony viewing request requesting permission to view the creator's existing immutable digital testimony; or an immutable digital testimony sharing request requesting permission to share the creator's existing immutable digital testimony with another immutable digital testimony network user; creating the third-party request by the third-party immutable digital testimony requester's device by combining any one or a combination of the following: a third-party immutable digital testimony requester ID; the immutable digital testimony creator's telephone number; and an immutable digital testimony ID; and sending the third-party request to an immutable digital testimony orchestrator by the third-party immutable digital testimony requester.

[0026] In some implementations, the method also involves creating an immutable digital testimony trajectory for identifying immutable digital testimonies created along a path by: creating a map of the immutable digital testimony trajectory by an immutable digital testimony arranger by identifying: (i) one or more third-party immutable digital testimonies, (ii) one or more camera devices, or (iii) a combination of (i) and (ii), each along a path taken by the user during a user-predetermined period prior to the creation of the immutable digital testimonies; identifying and visually indicating the locations of (i) one or more third-party immutable digital testimonies, (ii) one or more camera devices, or (iii) a combination of (i) and (ii); and [the method further involves] ... A map of the immutable digital testimony trajectory is sent to the device of the creator of the immutable digital testimony, the map being associated with the local media of the immutable digital testimony stored on the creator's device; and accordingly, the immutable digital testimony orchestrator records the following on the immutable digital testimony authentication blockchain: the immutable digital testimony trajectory associated with (i) the immutable digital testimony identifier (ID) and (ii) the immutable digital testimony geographic data associated with the respective creator of the local media of the immutable digital testimony; and one or more immutable digital testimony identifiers associated with (i) one or more third-party immutable digital testimonies, (ii) one or more camera devices, or (iii) both (i) and (ii).

[0027] In some implementations, the method further involves: presenting a thumbnail of a specific immutable digital testimony ID on the immutable digital testimony library of the creator of the immutable digital testimony; and presenting the immutable digital testimony trajectory as part of the metadata of the local media of the immutable digital testimony in the immutable digital testimony library, wherein, accordingly, one or more icons identify (i) one or more third-party immutable digital testimonies and (ii) any one or a combination of one or more camera devices, each of which allows a request to view the immutable digital testimony; and initiating an immutable digital testimony viewing or immutable digital testimony sharing request by selecting any one of the one or more icons for the corresponding immutable digital testimony.

[0028] In some embodiments, a system is provided having one or more processors and nontransitory memories communicatively coupled to a plurality of sensors, the nontransitory memories storing instructions that, when executed by one or more processors, control the system to create and view immutable digital testimonies, the system comprising: a first layer, a second layer, and a third layer.

[0029] The first layer operates on a device with an immutable digital testimony device identifier (ID), where the immutable digital testimony device ID is a unique identifier for the creator device. The device is configured to: activate the immutable digital testimony creation operation; authenticate the creator of the immutable digital testimony based on the immutable digital testimony creator ID, which is a unique user identifier created during registration with the immutable digital testimony network; capture the immutable digital testimony device ID used to create the immutable digital testimony; and, after authenticating the creator, initiate an immutable digital testimony capture operation to: activate one or more camera devices associated with the device. And it enables the device to generate immutable digital testimony streaming media; to create one or more immutable digital testimony stream hashes by hashing one or more frames of the immutable digital testimony streaming media from one or more camera devices by applying an immutable digital testimony hashing scheme selected from multiple hashing schemes; to form a real-time stream hash from one or more immutable digital testimony stream hashes; to capture immutable digital testimony metadata to be recorded on the immutable digital testimony authentication blockchain; and to transmit the immutable digital testimony streaming media and the selected immutable digital testimony hashing scheme to a cloud server, thereby enabling the selected immutable digital testimony hashing scheme and the immutable digital testimony streaming media to be... The immutable digital testimony cloud media is stored on a cloud server; one or more immutable digital testimony addresses are retrieved, each of which is: one or more cloud addresses on a cloud server, one or more DFS addresses on a Distributed File System (DFS), or a combination of i and ii, wherein each of the one or more immutable digital testimony addresses corresponds to a location where the immutable digital testimony cloud media is stored, the immutable digital testimony cloud media being at least a portion of the immutable digital testimony streaming media; after transmission is complete: the immutable digital testimony live streaming media is encrypted, thereby creating an encrypted immutable digital testimony cloud media. The method includes: a live streaming of digital testimony, wherein the encrypted immutable digital testimony live streaming is at least a portion of the immutable digital testimony live streaming; sending the encrypted immutable digital testimony live streaming to a DFS to store the encrypted immutable digital testimony live streaming; receiving from the DFS one or more immutable digital testimony DFS addresses corresponding to locations on the DFS where the immutable digital testimony live streaming is stored, wherein each of the one or more immutable digital testimony DFS addresses corresponds to a location where the encrypted immutable digital testimony live streaming has been stored; and storing the immutable digital testimony live streaming on a device to create immutable digital testimony local media.

[0030] In some implementations, the device is further configured to: select one or more frames of immutable digital testimony local media corresponding to the same one or more frames of the immutable digital testimony streaming media; hash one or more frames of the selected one or more frames of the immutable digital testimony local media using the selected immutable digital testimony hashing scheme to create one or more immutable digital testimony local hashes; form local symbiotic hashes from one or more immutable digital testimony local hashes; send the local symbiotic hashes to a smart contract for verification against the live stream hashes; and send the live stream hashes, immutable digital testimony metadata, one or more immutable digital testimony DFS addresses, and one or more immutable digital testimony cloud addresses to the smart contract.

[0031] In some implementations, the system also involves a third layer configured to: select one or more frames of immutable digital testimony cloud media corresponding to the same one or more frames of the immutable digital testimony streaming media; hash one or more frames of the selected one or more frames of the immutable digital testimony cloud media using the selected immutable digital testimony hashing scheme to create one or more immutable digital testimony cloud hashes; form a cloud media hash from one or more immutable digital testimony cloud hashes; and send the cloud media hash from a cloud server to a smart contract for verification against the live stream hash.

[0032] In some implementations, the third layer is configured to: create a creator token by a smart contract by combining the immutable digital testimony creator ID and the immutable digital testimony device ID; create an immutable digital testimony identifier ID by a smart contract by hashing the creator token with a live streaming hash; and compare the live streaming hash, the local symbiotic hash, and the cloud media hash by a smart contract, and if a) the live streaming hash reflects the local symbiotic hash, and b) the live streaming hash reflects the cloud media hash, then: create an immutable digital testimony by a smart contract by hashing the immutable digital testimony ID, one or more immutable digital testimony cloud addresses, immutable digital testimony metadata, one or more immutable digital testimony DFS addresses, and the live streaming hash. The process involves: recording the immutable digital testimony ID, one or more immutable digital testimony cloud addresses, immutable digital testimony metadata, one or more immutable digital testimony DFS addresses, immutable digital testimony hashes, and real-time stream hashes on the immutable digital testimony authentication blockchain via a smart contract; recording user permissions on the immutable digital testimony authentication blockchain; sending user permissions to the immutable digital testimony orchestrator to create log entries based on user permissions, which indicate whether the corresponding immutable digital testimony creator ID has any permissions to the immutable digital testimony cloud media associated with a specific immutable digital testimony ID; and recording the immutable digital testimony ID and immutable digital testimony hashes on a public blockchain via a smart contract.

[0033] In some implementations, the third layer is also configured to: if a) the real-time stream hash and the local co-occurrence hash do not match, or b) the real-time stream hash and the cloud media hash do not match, then: create an alternative immutable digital testimony by saving the immutable digital testimony local media to the DFS and the cloud server and accordingly retrieving one or more alternative immutable digital testimony DFS addresses and one or more alternative immutable digital testimony cloud addresses; and provide notification by a smart contract that the immutable digital testimony streaming media is corrupted during transmission or storage.

[0034] In some implementations, the device is also configured to send immutable digital testimony metadata, real-time streaming hashes, local co-occurrence hashes, one or more alternative immutable digital testimony cloud addresses, and one or more alternative immutable digital testimony DFS addresses to a smart contract.

[0035] In some implementations, the smart contract is also configured to: receive alternative immutable digital testimony metadata, a live streaming hash, a local co-occurrence hash, and one or more alternative immutable digital testimony DFS addresses; create an alternative creator token by combining the immutable digital testimony creator ID and the immutable digital testimony device ID; create an immutable digital testimony alternative ID by hashing the alternative creator token with the live streaming hash and appending an ALT to the end of the immutable digital testimony alternative identifier (ID); and create an immutable digital testimony alternative ID by combining the immutable digital testimony alternative ID, immutable digital testimony metadata, one or more alternative immutable digital testimony cloud addresses, one or more alternative immutable digital testimony DFS addresses, and local co-occurrence hashes. The process involves hashing the live hash and the live streaming hash to create an alternative immutable digital testimony hash; recording the immutable digital testimony alternative ID, immutable digital testimony metadata, one or more alternative immutable digital testimony cloud addresses, one or more alternative immutable digital testimony DFS addresses, live streaming hash, local symbiotic hash, and alternative immutable digital testimony hash on the immutable digital testimony authentication blockchain; recording the user permission corresponding to the immutable digital testimony alternative ID on the authentication blockchain and sending the user permission to the immutable digital testimony orchestrator to update the immutable digital testimony orchestrator's log entries; and recording the alternative immutable digital testimony ID and alternative immutable digital testimony hash on the public blockchain.

[0036] In some implementations, the immutable digital testimony orchestrator is configured to: receive user viewing permissions for immutable digital testimonies corresponding to immutable digital testimony alternative IDs; and create a local ledger of permission details based on user permissions.

[0037] In some implementations, the system further includes: a requester device configured to: authenticate a third-party immutable digital testimony requester; initiate a third-party request from an immutable digital testimony creator, the third-party request being any one or more of the following: an immutable digital testimony request requesting the creation and sharing of a new immutable digital testimony; an immutable digital testimony viewing request requesting permission to view the creator's existing immutable digital testimony; or an immutable digital testimony sharing request requesting permission to share the creator's existing immutable digital testimony with another immutable digital testimony network user; create a third-party request by combining any one or a combination of the following: a third-party immutable digital testimony requester ID, an immutable digital testimony creator's telephone number, and an immutable digital testimony ID; and send the third-party request to an immutable digital testimony orchestrator. Attached Figure Description

[0038] The features and advantages of exemplary embodiments of the invention presented herein will become more apparent from the following detailed description set forth in conjunction with the accompanying drawings.

[0039] Figure 1 An example network for creating and viewing immutable digital testimonies, according to an example implementation, is shown.

[0040] Figure 2 An apparatus with a storage technology process according to an example embodiment is described, the storage technology process cooperating to operate as an immutable digital testimony application that can be executed by the apparatus.

[0041] Figure 3 A system flowchart of the immutable digital testimony creation process according to an example implementation is shown.

[0042] Figure 4 A third-party request process for requesting immutable digital testimony, according to an example implementation, is shown.

[0043] Figure 5 An immutable digital viewing process according to an example implementation is shown.

[0044] Figure 6 The process for creating an immutable digital testimony trajectory, according to an example implementation, is shown.

[0045] Figure 7 An immutable digital testimony authentication process according to an example implementation is shown. Detailed Implementation

[0046] The exemplary embodiments of the invention presented herein relate to methods, systems, and computer program products for performing signal processing on various signals to provide immutable digital testimony.

[0047] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will also be understood that terms such as those defined in common dictionaries shall be interpreted as having the same meaning as they have in the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein. For the sake of brevity or clarity, well-known functions or constructions may not be described in detail.

[0048] As used in this article, "immutable digital testimony," "IDT," "immutable digital witness," or "IDW" generally refers to digital evidence, testimony, or information that cannot be altered, changed, or tampered with. It ensures the integrity and authenticity of such evidence, testimony, or information by creating verifiable and immutable records using the techniques described herein.

[0049] Figure 1An example network 100 for creating and viewing immutable digital testimonies, according to an example implementation, is shown. Figure 1 As shown, in the example implementation, network 100 includes three technical layers that together implement the creation and viewing of immutable digital testimonies: Layer 1100 (also known as the Witness Layer 1100), Layer 1200 (also known as the Orchestrator Layer 1200), and Layer 1300 (also known as the Immutable Digital Testimony (IDT) Layer 1300). Layers 1100, 1200, and 1300 are each technical layers within a layered model that defines how data is transmitted and processed through network 100. The layers of network 100 work together to facilitate the seamless creation, storage, and streaming of immutable digital testimonies (IDTs).

[0050] In some implementations, the first layer 1100 operates on one or more devices 1110 capable of communicating over the network 100, wherein the devices 1110 have an application mounted on a non-transitory medium that, when executed by the devices 1110, causes the devices 1110 to perform one or more of the processes described herein. In example implementations, the device 1110 is a mobile device having one or more processors and non-transitory memory for storing the application. In some implementations, the device 1110 is a camera device capable of communicating over the network 100. In some implementations, the camera device includes one or more processors and non-transitory memory for storing the application. In some implementations, the camera device is communicatively coupled to another device (e.g., a computer, edge device, etc.) having one or more processors and non-transitory memory for storing the application. In some implementations, one or more devices 1110 include a network of camera devices capable of communicating over the network 100.

[0051] In some implementations, one or more devices 1110 capture media including audio and / or video content and transmit the media over network 100.

[0052] Layer 1200 includes an Immutable Digital Testimony (IDT) orchestrator 1210. Typically, the IDT orchestrator 1210 manages user licensing, user-to-user messaging, payment processing, and / or system administration. In some implementations, Layer 1200 runs on a cloud that delivers various services such as storage, processing power, databases, networking, software, and analytics via the internet. In some implementations, Layer 1200 runs on blockchain infrastructure (hereinafter referred to as "blockchain"). Advantageously, processes, data, or functions associated with the implementations described herein utilize blockchain, which provides benefits such as enhanced security, transparency, and immutability.

[0053] Layer 3 (1300) typically operates to protect authentication and verification keys, execute smart contracts, manage user licenses, host media content, and authorize the streaming of immutable digital testimonies. As used herein, "smart contract" generally refers to a self-executing contract, where protocol terms are written directly into the code. In some implementations, these contracts automatically implement and execute terms and conditions when predefined conditions are met, without the need for intermediaries. The smart contracts described herein run on a blockchain, thereby ensuring transparency, security, and immutability. This enables automated, reliable, and transparent transactions and protocols in the applications described herein. In some implementations, smart contracts reside in IDT layer 1300. As used herein, "Immutable Digital Testimonies (IDT) Authentication Blockchain" generally refers to a blockchain containing information related to immutable digital testimonies used for verifying and authenticating them, and providing immutable logs and audit trails related to the creation, viewing, and sharing of immutable digital testimonies. (See also...) Figure 1 In the example implementation, the smart contract resides on the IDT certified blockchain 1330 and operates to verify the integrity of the immutable digital testimonies (IDT) streaming media and record the immutable digital testimonies and related information to the applicable blockchain (e.g., IDT certified blockchain 1330 and public blockchain 1340).

[0054] As used herein, “Immutable Digital Testimony (IDT) streaming media” generally refers to media transmitted (e.g., streamed, downloaded, uploaded, or otherwise transmitted as appropriate) over network 100 by device 1110 (e.g., a mobile device or camera device). In the example implementation, the IDT streaming media is sent to IDT cloud 1310.

[0055] In some implementations, the Immutable Digital Testimony (IDT) Cloud 1310 is a cloud-based media storage system in which IDT streaming media and related information are received and stored. The IDT streaming media and related information received and stored in the IDT Cloud 1310 become Immutable Digital Testimony (IDT) Cloud Media. In other words, IDT Cloud Media is media stored on the IDT Cloud. It should be understood that the IDT Cloud and any blockchain described herein are non-transitory media.

[0056] As used herein, "Decentralized File System (DFS)" generally refers to a decentralized file system, including but not limited to the InterPlanetary File System, in which immutable digital testimony-related data can be stored for verification or media recovery. In some implementations, a DFS is a file system that allows client devices (sometimes simply referred to as "clients") to access file storage from multiple hosts over a computer network as if the client devices were accessing local storage. Files are distributed across multiple storage servers and in multiple locations, enabling client devices to share data and storage resources. A DFS can be decentralized.

[0057] As used in this article, “Immutable Digital Testimony (IDT) authentication” generally refers to the authentication of one of the immutable digital testimonies sent to a specific user (e.g., to a specific user’s device) by the creator or user of the immutable digital testimonies (referred to as the “Immutable Digital Testimony (IDT) Creator” or simply the “Creator”).

[0058] As used herein, “third-party immutable digital testimony (IDT)” generally refers to immutable digital testimony created by an entity other than the direct user or creator (including another user of IDT network 100 or other devices on IDT network 100 such as immutable digital testimony camera devices) along an immutable digital testimony trajectory (described below). Therefore, such third-party immutable digital testimony is created by an entity other than the direct user or creator.

[0059] Reference Figure 1 In some implementations, the third layer 1300 is deployed on a combination of IDT cloud 1310, DFS 1320, IDT certified blockchain 1330 and public blockchain 1340.

[0060] In the example implementation, device 1110 includes multiple camera devices interconnected with device 1110, such as front-facing cameras, rear-facing cameras, or any other camera devices, which are configured to capture audio and / or visual content to be used as IDT streaming media. IDT streaming media corresponds to the live media when it is transmitted to IDT cloud 1310, where the live media will be stored and become IDT cloud media.

[0061] Figure 2A device 1110 with a storage technology process 200 according to an example embodiment is depicted, which cooperates to operate as an immutable digital testimony application 120 executable by the device. In some embodiments, the device 1110 includes a user input device 106, a display device 108, a data communication device 110, a processing device 112, one or more media capture devices 116, and a memory device 118. Various aspects of the technology process 200 are executed locally at the device 1110 via the IDT application 120. See also... Figure 1 Certain related processes are performed on the second layer 1200 or the third layer 1300 of network 100. In some implementations, the IDT application 120 running on device 1110 communicates with the IDT cloud 1310, DFS 1320, IDT certified blockchain 1330 and / or public blockchain 1340 via network 100.

[0062] The user input device 106 of device 1110 operates to receive user input from a user to control device 1110. User input may include manual input and / or voice input, etc. In some embodiments, user input device 106 includes one or more buttons, keys, touch levers, switches, and / or other mechanical input devices for receiving input. User input device 106 may include a touchscreen or gesture input device. In some embodiments, user input device 106 may detect sounds including voice input, such as a user's voice (e.g., speech), to control various aspects of a technical process via device 1110.

[0063] In some embodiments, a display device 108 is provided that operates to display a graphical user interface (GUI) showing information for interacting with device 1110. Examples of such information include immutable digital testimony trajectories or immutable digital testimony libraries, which are described in more detail below. In some embodiments, display device 108 is configured as a touch-sensitive display and includes a user input device 106 for receiving input from a user-controlled selector (e.g., a finger, stylus, etc.). Thus, in some embodiments, display device 108 operates as both a display device and a user input device.

[0064] Data communication device 110 is configured to enable it to communicate with one or more computing devices via one or more networks (such as network 100). For example, data communication device 110 is configured to communicate with IDT cloud 1310, DFS 1320, IDT certified blockchain 1330, and / or public blockchain 1340 via network 100, and to receive notifications from IDT cloud 1310, DFS 1320, IDT certified blockchain 1330, and / or public blockchain 1340, and other components via network 100. Data communication device 110 can be various types of network interfaces that connect device 1110 to network 100.

[0065] In some embodiments, the processing device 112 includes one or more central processing units (CPUs). In other embodiments, the processing device 112 additionally or alternatively includes one or more digital signal processors, graphics processing units (GPUs), field-programmable gate arrays, or other electronic circuitry.

[0066] In some implementations, media capture device 116 is one or more camera devices integrated with device 1110. Media capture device 116 is configured to capture media such as audio and / or video. It should be understood that video may include one or more still images as part of the video content.

[0067] Memory device 118 includes at least some forms of nontransitory computer-readable media. Nontransitory computer-readable media includes any available media that can be accessed by device 1110, such as volatile and non-volatile, removable and non-removable media implemented in any device configured to store information (such as computer-readable instructions, data structures, program modules, or other data). Memory device 118 may also include, but is not limited to, random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory and other memory technologies, compact disk read-only memory, Blu-ray disc, digital versatile disk or other optical storage, magnetic storage devices, or any other medium that can be used to store desired information and can be accessed nontransitorily by device 1110.

[0068] Memory device 118 operates to store data and instructions. In some embodiments, memory device 118 stores instructions for IDT application 120. In some examples, one or more methods described herein can be implemented as instructions stored in one or more memory devices on one or more computers, which, when executed by one or more processors, cause the processors to perform one or more operations described herein.

[0069] In some examples, network 100 includes computer networks, corporate intranets, the Internet, LANs, wide area networks (WANs), wireless transmission media, wired transmission media, satellite transmission media, other networks, and combinations thereof. Although in Figure 1 Network 100 is shown as a single network, but this is shown as an example, and the various communications described herein can occur through the same network or multiple different networks.

[0070] The technical process 200 for collaborating as an Immutable Digital Testimony (IDT) application 120 includes an Immutable Digital Testimony (IDT) creation process 2100, an Immutable Digital Testimony (IDT) request process 2200, an Immutable Digital Testimony (IDT) viewer process 2300, an Immutable Digital Testimony (IDT) tracking process 2400, an Immutable Digital Testimony (IDT) authentication process 2500, an Immutable Digital Testimony (IDT) library process 2600, and an Immutable Digital Testimony (IDT) management function 2700.

[0071] In some embodiments, these technical processes 200 are in the form of instructions that, when executed by one or more processors of device 1110, cause device 1110 to perform applicable operations as described in more detail herein.

[0072] The IDT creation process 2100 is typically the process of creating immutable digital testimonies.

[0073] IDT request process 2200 is typically used to process requests for immutable digital testimonies. IDT request process 2200 can be executed according to the following different sub-processes, each for different purposes: Third-Party Immutable Digital Testimonies (IDT) Request Process 2210, Immutable Digital Testimonies (IDT) Viewing Process 2220, and Immutable Digital Testimonies (IDT) Sharing Request Process 2230.

[0074] The third-party IDT request process 2210 is a request process initiated by a first client (referred to as the Immutable Digital Testimony (IDT) requester or simply the requester) to a second client (referred to as the Immutable Digital Testimony (IDT) creator or simply the creator) to initiate a new immutable digital testimonies.

[0075] The IDT viewing process 2220 typically involves receiving a request from a requester (also known as an IDT requester or simply a requester) who initiates a request for an immutable digital testimonies from a person who has created one or more immutable digital testimonies (also known as an IDT creator or simply a creator), to grant permission to view at least one of the immutable digital testimonies created by the person who created the immutable digital testimonies.

[0076] The IDT sharing process 2230 typically involves a device operated by a person making the request (also known as an Immeasurable Digital Testimony (IDT) requester or simply the requester) requesting a creator of one or more immutable digital testimonies (also known as an Immeasurable Digital Testimony (IDT) creator or simply the creator) to grant another user of network 100 a license to share at least one of the immutable digital testimonies created by the creator of the immutable digital testimonies.

[0077] IDT viewer process 2300 is typically the following process, which performs operations for transmitting (e.g., streaming, downloading, uploading, or otherwise transmitting, as applicable) and viewing immutable digital testimonies.

[0078] The IDT tracing process 2400 is typically a process of providing (e.g., by presenting via a device's display) a map that identifies trajectories along paths followed by a person creating immutable digital testimonies via a device within a user-defined timeframe. In some implementations, all third-party immutable digital testimonies created by others using, for example, mobile devices, or captured by camera devices capable of continuous streaming to network 100 are also provided on the map. In an example implementation, each immutable digital testimonies has a unique corresponding immutable digital testimonies trajectory constructed using immutable digital testimonies geographic data. "Immutable Digital Testimonies (IDT) geographic data" generally refers to geolocation audit trajectories that identify the movements of a person creating immutable digital testimonies via one or more devices during a user-defined timeframe (e.g., a 60-minute period). In an example implementation, the immutable digital testimonies (IDT) geographic data may include immutable digital testimonies created via one or more devices during a user-defined timeframe prior to initiating immutable digital testimonies capture.

[0079] IDT Authentication Process 2500 is typically used for authenticating immutable digital testimonies.

[0080] IDT Library Process 2600 is typically a process for displaying one or more immutable digital testimonies, including any immutable digital testimonies created, for example, through a self-initiated immutable digital testimonies process or an IDT request process 2200 (e.g., via a third-party IDT request process 2210, an IDT viewing process 2220, or an IDT sharing request process 2230).

[0081] The IDT Management Function 2700 typically performs various operations related to the management of immutable digital testimonies.

[0082] Figure 3A system flowchart of an IDT creation process 2100 according to an example implementation is shown. In some implementations, the IDT creation process 2100 is performed by a witness layer 1100 (also referred to as the first layer 1100).

[0083] In the example implementation, as shown by activating IDT creation operation 2102, the IDT creation process 2100 begins when the immutable digital testimony creation function is activated on a device (such as device 1110). In some implementations, the IDT creation process 2100 is activated on the device by a user associated with an IDT creator identifier (ID). In some implementations, the IDT creator ID is a unique user identifier created when the IDT creator registers with network 100.

[0084] The device performs user authentication operation 3100 to authenticate the user. In an example implementation, user authentication operation 3100 captures the device ID and authenticates the user based on the device ID and the IDT creator ID associated with the user. In some implementations, the device ID is a unique device identification number, such as the International Mobile Equipment Identity (“IMEI”), or a similar unique identifier used to capture immutable digital credentials.

[0085] Following successful authentication, the device initiates an Immutable Digital Testimony (IDT) capture process 3110. The IDT capture process 3110 involves activating available camera devices (e.g., one or more camera devices) to create an IDT streaming media, as illustrated by the camera device activation operation 3120. Subsequently, the device performs a real-time stream hashing operation 3130. In the example implementation, the real-time stream hashing operation 3130 generates a real-time stream hash 3132 by hashing each frame of the relevant IDT streaming media for each available camera device using a selected immutable digital testimonies (IDT) frame hashing scheme 3131.

[0086] An IDT hashing scheme typically refers to any of the various schemes for hashing frames, including, for example, dividing the individual frames of a video into multiple segments (such as one equal segment, two equal segments, four equal segments, three unequal segments, or dividing into four triangles), hashing alternating frames instead of every frame, or hashing partial frames instead of complete frames. By assigning an IDT hashing scheme to be used to hash the IDT streaming media, reverse engineering the immutable digital testimony verification process and manipulating media stored in the IDT Cloud 1310 or DFS 1320 become more difficult for hackers. The chosen IDT hashing scheme becomes the IDT frame hashing scheme for that immutable digital testimony.

[0087] Once the live stream is complete, the IDT stream hashes from each camera device are combined or hashed to form the live stream hash 3133.

[0088] The device also performs an immutable digital testimonies (IDT) metadata capture operation 3140 to capture immutable digital testimonies (IDT) metadata. In some implementations, the IDT metadata includes various authenticity proof factors. In an example implementation, authenticity proof factors include one or more immutable digital testimonies (IDT) creator identifiers (IDs) 3141, one or more device identifiers (IDs) 3142, media metadata 3143, location metadata (3144), immutable digital testimonies (IDT) frame hash scheme 3145, and immutable digital testimonies (IDT) source code identifiers (IDs) 3146.

[0089] In the example implementation, the immutable digital testimonial creator identifier 3141 includes: the creator's immutable digital testimonial creator ID, the immutable digital testimonial ID method, the user's name, the user's email address, and one or more verification government identifiers (IDs) for the user. The IDT ID method, as used herein, generally refers to a method for capturing the IDT creator ID. In the example implementation, the IDT ID method obtains the IDT creator IDT by using biometric information. In another example implementation, the IDT ID method obtains the IDT creator IDT by using manual input via a device (e.g., user input device 106 of device 1110).

[0090] In the example implementation, device identifier 3142 includes: an immutable digital token (IDT) device identifier (ID), a telephone number (if applicable), a SIM card information (if applicable), the device's Internet Protocol (IP) address, a date and time as reported by the device, and a battery level as reported by the device.

[0091] In the example implementation, media metadata 3143 includes: light detection and ranging (LiDAR) data for each available camera device of the device.

[0092] In the example implementation, location metadata 3144 includes the device’s latitude, longitude, altitude and other location identifiers (including the specific IDT device ID used when initiating the IDT capture process 3110, IDT geographic data and the compass and heading of the device associated with the IDT device ID).

[0093] It should be understood that, in alternative implementations, other combinations of metadata may be within the scope of the implementations described herein.

[0094] In the example implementation, the immutable digital testimonies (IDT) frame hashing scheme 3145 is one or more corresponding immutable digital testimonies (IDT) frame hashing schemes associated with the IDT streaming media.

[0095] In the example implementation, the Immutable Digital Testimony (IDT) source code identifier 3146 is an identifier for the code used to create an immutable digital testimony with a specific Immutable Digital Testimony Identifier (IDT ID). In some implementations, the IDT source code used to create a specific immutable digital testimony is immutable. The immutability maintains a record of the source code, which can be reviewed in the future to ensure that no malicious software or manipulation exists at the time the immutable digital testimony is created.

[0096] In some implementations, the IDT ID is a unique identifier assigned to each immutable digital testimony, created by hashing the creator token using a live stream hash. In an example implementation, the live stream hash is a hash or combination of all IDT stream hashes used to ensure that the corresponding live stream is not altered or swapped during transmission.

[0097] While real-time stream hashing is being formed and immutable digital testimony metadata is being captured, the device operates to perform transmission and storage operations 3147 to transmit and store the IDT streaming media and a selected IDT frame hashing scheme to the immutable digital testimony cloud. In some embodiments, the selected IDT frame hashing scheme is an IDT hashing scheme used to select the hashing of the IDT streaming media before transmitting it to the IDT cloud 1310.

[0098] It should be understood that “simultaneous” can mean substantially simultaneous, and that the formation of real-time streaming hashes or the capture of immutable digital testimony metadata can occur in different orders, but still within the same scope of the implementation described herein.

[0099] The real-time stream is transmitted (e.g., as applicable, by a device (such as device 1110) through streaming, uploading, downloading, or otherwise transmitting) to or from a device (such as device 1110) to the IDT cloud 1310, as applicable, and as shown by communication operation 39100. In response, the IDT cloud 1310 responds to the device to retrieve the corresponding IDT cloud address, as shown by communication operation 39110. As used herein, the term "Immutable Digital Testimony (IDT) cloud address" generally refers to the address on the IDT cloud 1310 where IDT streaming media and related information are stored, thus becoming immutable digital testimony cloud media.

[0100] Real-time streaming media typically refers to multimedia content played in real time via the Internet or a network. This includes the real-time media feed (including real-time video and audio feeds) transmitted as it is recorded. After the immutable digital testimonies (IDTs) are transmitted, the live streaming media already cached on the device is encrypted via encryption operation 3148 and sent to the DFS 1320, as shown by communication operation 39105. In response, the DFS 1320 returns the corresponding IDT DFS address to the device, as shown by communication operation 39115. As used herein, "IDT DFS address" generally refers to the DFS address where the live streaming media is stored, as described herein.

[0101] As used herein, “Immutable Digital Testimony (IDT) Local Media” generally refers to IDT streaming media that is cached and stored locally on a device (such as device 1110). In some implementations, for each camera device, the IDT streaming media on the device is saved to create IDT local media, as shown by local media storage operation 3149.

[0102] As used in this article, “Immutable Digital Testimony (IDT) Local Hash” generally refers to the hash created for each frame of the IDT local media using the corresponding IDT frame hashing scheme.

[0103] As used herein, "local co-occurrence hash" generally refers to a hash or combination of IDT local hashes used to compare IDT streaming media and corresponding IDT local media. In some implementations, a device (e.g., device 1110) performs a local co-occurrence hash formation operation 3150 to create a so-called "Immutable Digital Testimony (IDT) local hash" 3152 by selecting frames of IDT local media 3151 and hashing each frame of IDT local media 3151 using the IDT frame hashing scheme used during the creation of the IDT streaming media, and to form an IDT media hash to create a local co-occurrence hash 3153. Furthermore, the device performs a combination or hash operation to combine or hash the IDT local hashes to form the local co-occurrence hash 3153.

[0104] Then, the local symbiotic hash is sent to the smart contract, as shown in communication operation 39020.

[0105] Then, device 1110 performs a sending operation 3160 in conjunction with communication operation 39030 to send IDT metadata, real-time stream hash, IDT DFS address and IDT cloud address to the smart contract.

[0106] In some implementations, the method for creating immutable digital testimonies involves activating an IDT creation operation 2102 to perform an immutable digital testimonies creation operation on a device 1110 having an immutable digital testimonies device identifier (ID), wherein the immutable digital testimonies device ID is a unique identifier for device 1110. The method also involves a user authentication operation 3100 to perform authentication of the creator of the immutable digital testimonies based on the immutable digital testimonies creator ID, wherein the immutable digital testimonies creator ID is a unique user identifier created when registering with the immutable digital testimonies network. Furthermore, the method performs an immutable digital testimonies (IDT) capture process 3110 to capture the immutable digital testimonies device ID of the device used to create the immutable digital testimonies, and after authentication of the creator, the device initiates the immutable digital testimonies capture operation.

[0107] In some implementations, IDT capture operation 3110 includes: activating camera device operation 3120, which performs the activation of one or more camera devices associated with the device and causes the device to generate an immutable digital testimony streaming media; forming a real-time stream hash operation 3130, which performs the hashing of one or more frames of the immutable digital testimony streaming media of one or more camera devices by applying an immutable digital testimony hashing scheme selected from a plurality of hashing schemes to form one or more immutable digital testimony stream hashes, and forming a real-time stream hash from one or more immutable digital testimony stream hashes.

[0108] The method also involves: an immutable digital testimonies (IDT) metadata capture operation 3140, which is used to capture immutable digital testimonies metadata to be recorded on the immutable digital testimonies authentication blockchain; and transmission and communication operations 3147 and 39100, which are used to transmit immutable digital testimonies streaming media and a selected immutable digital testimonies hash scheme to a cloud server via a device, so that the selected immutable digital testimonies hash scheme and the immutable digital testimonies streaming media are stored on the cloud server as immutable digital testimonies cloud media.

[0109] Furthermore, the method relates to communication operation 39110 for performing a retrieval of one or more immutable digital testimony addresses, each of the one or more immutable digital testimony addresses being: (i) one or more cloud addresses on a cloud server; (ii) one or more DFS addresses on a distributed file system (DFS); or (iii) a combination of (i) and (ii), wherein, correspondingly, each of the one or more immutable digital testimony addresses corresponds to: (i) a location storing immutable digital testimony cloud media, the immutable digital testimony cloud media being at least a portion of an immutable digital testimony streaming media; or (ii) an allocated location for storing immutable digital testimony cloud media, the immutable digital testimony cloud media being at least a portion of an immutable digital testimony streaming media. After transmission is complete, the method involves: an encryption operation 3148, which performs encryption on the immutable digital testimony live streaming media to create an encrypted immutable digital testimony live streaming media, the encrypted immutable digital testimony live streaming media being at least a portion of the immutable digital testimony live streaming media; and a communication operation 39105, which sends the encrypted immutable digital testimony live streaming media to the DFS to store the encrypted immutable digital testimony live streaming media. Furthermore, the method involves a receiving operation 39015, which receives one or more immutable digital testimony DFS addresses, each of which corresponds to a location where the encrypted immutable digital testimony live streaming media is stored. A local media storage operation 3149 then performs storage of the immutable digital testimony live streaming media on the device to create immutable digital testimony local media.

[0110] In some implementations, the immutable digital testimony metadata also includes any one or a combination of the following: biometric data of the immutable digital testimony creator, manually entered data of the immutable digital testimony creator, the name of the immutable digital testimony creator, the email address of the immutable digital testimony creator, the verification government identifier of the immutable digital testimony creator, the device's phone number, the device's SIM card information, such as the date and time reported by the device, such as the battery level reported by the device, LiDAR data of each of one or more camera devices associated with the device, the device's location identifier at the time the camera capture operation was initiated, and other data related to the user, device, location, and media used to create the immutable digital testimony.

[0111] In some implementations, forming a live streaming hash is performed by combining or hashing one or more immutable digital testimony stream hashes. In example implementations, a hash scheme (e.g., Merklegen) is used to perform the combination.

[0112] In some implementations, the method further involves a local co-occurrence hash formation operation 3150, which performs the following actions: selecting one or more frames of immutable digital testimony local media corresponding to the same one or more frames of the immutable digital testimony streaming media; hashing one or more frames of the selected one or more frames of the immutable digital testimony local media using the selected immutable digital testimony hashing scheme; thereby creating one or more immutable digital testimony local hashes. Furthermore, the local co-occurrence hash creation operation 3150 performs the formation of a local co-occurrence hash from one or more immutable digital testimony local hashes. A communication operation 39020 performs the sending of the local co-occurrence hash by the device to a smart contract for verification against the live stream hash. A sending operation 3160 and a communication operation 39030 perform the sending of the live stream hash, immutable digital testimony metadata, one or more immutable digital testimony DFS addresses, and one or more immutable digital testimony cloud addresses by the device to the smart contract.

[0113] In some implementations, forming a local co-occurring hash is performed by combining or hashing one or more immutable digital testimonies' local hashes. In example implementations, a hash scheme (e.g., Merklegen) is used to perform the combination.

[0114] Still refer to Figure 3 In some implementations, IDT cloud 1310 is used to compare received IDT streaming media with IDT cloud media stored on IDT cloud 1310 to ensure that the media streamed from the slave device is not altered or manipulated by performing cloud media hash formation operation 3310 for creating cloud media hashes. As described above, in some implementations, IDT cloud 1310 is on IDT layer 1300.

[0115] As used in this article, “cloud media hash” generally refers to a hash or combination of all immutable digital testimony cloud hashes used to compare IDT streaming media and immutable digital testimony cloud media.

[0116] "Immutable Digital Testimony (IDT) Cloud Hash" typically refers to the hash generated for each frame of IDT cloud media using the corresponding IDT frame hashing scheme.

[0117] The cloud media hashing operation 3310 selects one or more frames of IDT cloud media corresponding to the same one or more frames of the IDT streaming media. Then, the hashing operation uses the selected IDT frame hashing scheme to hash one or more of the selected frames of the IDT cloud media to create one or more IDT cloud hashes 3312. Then, the cloud media hashing operation 3310 forms a cloud media hash 3313 from one or more IDT cloud hashes 3312.

[0118] In some implementations, cloud media hashing is performed by combining or hashing one or more immutable digital testimony cloud hashes. In example implementations, a hashing scheme (e.g., Merklegen) is used to perform the combination.

[0119] Then, communication operation 39040 executes by having the cloud server send the cloud media hash to the smart contract for verification against the real-time streaming hash.

[0120] Creator tokens are typically a combination of an IDT user ID and an IDT device ID. Specifically, a smart contract on the IDT certified blockchain 1330 executes a token creation operation 3331 to create a creator token by combining the IDT creator ID and the IDT device ID.

[0121] Furthermore, the smart contract executes an Immutable Digital Testimony (IDT) Identifier (ID) creation operation 3332 to create an Immutable Digital Testimony (IDT) Identifier (ID) by hashing the creator token with a real-time streaming hash. In some implementations, the smart contract performs a verification operation 3333 to verify the IDT cloud media by verifying that there are no differences between the IDT streaming media, the IDT local media, and the IDT cloud media, to ensure that the IDT cloud media has not been corrupted during transmission or storage on the IDT cloud 1310 and / or DFS 1320. In an example implementation, this is performed by comparing the real-time streaming hash (corresponding to the IDT streaming media), the local co-occurrence hash (corresponding to the IDT local media), and the cloud media hash (corresponding to the IDT cloud media).

[0122] In some implementations, if a) the real-time stream hash reflects the local co-occurrence hash and b) the real-time stream hash reflects the cloud media hash, as shown by verification operation 3333, then the smart contract forms an IDT hash by hashing the IDT ID, IDT metadata, IDT cloud address, IDT DFS address, and real-time stream hash, as shown by forming IDT hash operation 3380.

[0123] Then, the smart contract executes record operation 3334 to record the IDT ID, IDT metadata, IDT cloud address, IDT DFS address, real-time stream hash, and IDT hash on the IDT certified blockchain 1330.

[0124] Furthermore, the smart contract executes blockchain recording operation 3335, which records the user permission on the IDT certification blockchain 1330 and sends the user permission to the IDT orchestrator 1210, as shown by communication operation 39300. In some embodiments, this causes the IDT orchestrator 1210 to update the permission management system 3210, as shown by update operation 3220. The permission management system 3210 then creates a log entry indicating a specific IDT creator ID that has full permissions (viewing and sharing) to the immutable digital testimony associated with a specific IDT ID.

[0125] If applicable, blockchain record operation 3335 also enables the smart contract to grant a third-party IDT requester (e.g., when initiating a third-party IDT request process 2210) viewing permission associated with a specific IDT ID. In some implementations, blockchain record operation 3335 also performs the registration of viewing permission on the IDT authentication blockchain 1330 and the permission management system 3210. It should be understood that in some implementations, the permission management system 3210 is included in the IDT orchestrator 1210.

[0126] In some implementations, the smart contract combines communication operation 39400 with recording operation 3336 to record the IDT ID and IDT hash on the public blockchain 1340.

[0127] The IDT hash recorded on the public blockchain 1340 can be used for the periodic verification and authentication of the IDT certification blockchain 1330. For example, the IDT hash, which is used as the record storage on the public blockchain 1340, can be used to verify the integrity of the private blockchain record.

[0128] In some implementations, the IDT DFS address and the corresponding media at that location can be used to recreate or rebuild immutable digital testimonies in the event of damage or alteration of the IDT cloud media.

[0129] If at verification operation 3333 it is determined that a) there is no exact match between the real-time stream hash and the local co-occurrence hash or b) the real-time stream hash and the cloud media hash, then the smart contract performs a notification operation to notify the immutable digital testimony application 120 that the immutable digital streaming media was corrupted during the upload or storage process, as shown by communication operation 39050.

[0130] On the other hand, a method is involved for creating cloud media hashes for verification against real-time stream hashes. The method involves a cloud media hash formation operation 3310 for selecting one or more frames of IDT cloud media corresponding to the same one or more frames of the IDT streaming media. The method also involves hashing one or more selected frames of the immutable digital testimony cloud media using a selected immutable digital testimony frame hashing scheme, thereby creating one or more IDT cloud hashes 3312. Furthermore, the method executes the formation of cloud media hashes from one or more immutable digital testimony cloud hashes 3313. Then, a communication operation 39040 is performed whereby the cloud server sends the cloud media hashes to a smart contract for verification against real-time stream hashes.

[0131] In some implementations, cloud media hash 3313 is formed by combining or hashing one or more immutable digital testimony cloud hashes.

[0132] In some implementations, the method involves a creation token operation 3331 for creating a creator token by a smart contract by combining an immutable digital testimony creator ID and an IDT device ID.

[0133] The creation of an immutable digital testimony identifier (ID) is performed by the smart contract by hashing the creator token using a live streaming hash. The verification operation 3333 is performed by the smart contract by comparing the live streaming hash, the local co-occurrence hash, and the cloud media hash. If the verification operation 3333 determines that a) the live streaming hash reflects the local co-occurrence hash, and b) the live streaming hash reflects the cloud media hash, then the method also involves the formation of an IDT hash operation 3380, which is performed by the smart contract by hashing the IDT ID, one or more IDT cloud addresses, IDT metadata, one or more IDT DFS addresses, and the live streaming hash.

[0134] Blockchain record operations 3334 and 3335 execute by smart contracts recording IDT ID, one or more IDT cloud addresses, IDT metadata, one or more IDT DFS addresses, IDT hash, and real-time stream hash on IDT certified blockchain 1330, and also recording user permissions on IDT certified blockchain 1330.

[0135] In some implementations, communication operation 39300 sends a user permission to IDT orchestrator 1210 to create a log entry based on the user permission. This log entry indicates whether the corresponding IDT creator ID has any permissions to the IDT cloud media associated with a specific IDT ID. Recording operation 3336, in conjunction with communication operation 39400, executes by a smart contract to record the immutable digital testimony ID and IDT hash on the public blockchain 1340.

[0136] In some implementations, the method also executes a smart contract granting the requester permission to view the immutable digital testimony corresponding to the IDT ID, and registers the viewing permission on the IDT certification blockchain 1330 and the IDT orchestrator 1210.

[0137] In some implementations, the method execution periodically verifies and authenticates the immutable digital testimony authentication blockchain by using immutable digital testimony hashes recorded on a public blockchain.

[0138] As used in this article, "alternative immutable digital testimony" generally refers to an alternative immutable digital testimony created using the local media of the immutable digital testimony to preserve a locally saved version when the smart contract determines that the immutable digital testimony has been changed or modified.

[0139] As used in this article, “alternative immutable digital testimony cloud address” usually refers to an immutable digital testimony cloud address that stores alternative immutable digital testimony.

[0140] As used in this article, "alternative immutable digital testimony DFS address" usually refers to the DFS address that stores alternative immutable digital testimony.

[0141] In some implementations, after a potential change to the immutable digital testimony media is alerted by a smart contract (as shown by verification determination operation 3170), device 1110 (i.e., on witness layer 1100) performs a create alternative immutable digital testimony (IDT) operation 3180 to create the alternative immutable digital testimony (IDT) by performing a save operation 3190 (as shown by communication operation 39500) to save the IDT local media to DFS 1320 and retrieving the corresponding alternative IDT DFS address (as shown by communication operation 39510). Furthermore, the save operation performs saving the IDT local media to IDT cloud 1310 (as shown by communication operation 39511), and the retrieval operation performs retrieving the corresponding alternative IDT cloud address (as shown by communication operation 39512). In some implementations, notification operation 39050 performs a notification provided by a smart contract that the IDT streaming media has been corrupted during transmission or storage.

[0142] The alternative IDT is recorded on DFS 1320 to ensure immutability. The alternative immutable digital testimony is also recorded on IDT cloud 1310 for future playback.

[0143] In some implementations, device 1110 performs an alternative immutable digital testimony transmission operation 3191, which transmits immutable digital testimony metadata, real-time streaming hash, local co-occurrence hash, alternative immutable digital testimony cloud address, and alternative immutable digital testimony DFS address to a smart contract via communication operation 39060.

[0144] In some implementations, the method performs a verification determination operation 3170 to determine whether a) the real-time stream hash and the local co-occurrence hash do not match, or b) the real-time stream hash and the cloud media hash do not match. If so, an alternative immutable digital testimony creation operation 3180 is performed to create an alternative immutable digital testimony, and a storage operation 3190 saves the IDT local media to the DFS via communication operation 39500, and saves the IDT local media to the cloud server via communication operation 39511, and retrieves one or more alternative immutable digital testimony DFS addresses via communication operation 39510, and correspondingly retrieves one or more alternative immutable digital testimony cloud addresses via communication operation 39512.

[0145] In some implementations, the method also involves an alternative immutable digital testimony sending operation 3191, which is used to perform the sending of IDT metadata, real-time streaming hash, local co-occurrence hash, one or more alternative IDT cloud addresses and one or more alternative IDT DFS addresses by the device via communication operation 39060 to a smart contract.

[0146] In another implementation, the method involves several steps performed by a smart contract (e.g., on IDT layer 1300). Communication operation 39060 is performed by the smart contract receiving alternative IDT metadata, live streaming hash, local co-occurrence hash, and one or more IDT testimony DFS addresses.

[0147] The Creator Token Creation Operation 3341 executes by combining the IDT Creator ID and the IDT Device ID to create an alternative Creator Token by the smart contract. Then, the Immutable Digital Testimony Alternate Identifier Creation Operation 3342 executes by hashing the alternative Creator Token using a live streaming hash and appending, for example, "ALT" to the end of the IDT Alternate Identifier (ID) to create an Immutable Digital Testimony (IDT) Alternate ID by the smart contract. As used herein, "Immutable Digital Testimony (IDT) Change Identifier (ID)" generally refers to a unique identifier assigned to the immutable digital testimonies being changed.

[0148] The alternative immutable digital testimonies (IDT) hashing operation 3349 is performed by creating an alternative IDT hash by hashing the IDT alternative ID, IDT metadata, one or more alternative IDT cloud addresses, one or more alternative IDT DFS addresses, local co-occurrence hash, and real-time streaming hash by a smart contract.

[0149] Then, the recording operation 3343 (also known as the “IDT Authentication Blockchain Recording Operation”) is executed by a smart contract to record the IDT alternative ID, IDT metadata, one or more alternative IDT cloud addresses, one or more alternative IDT DFS addresses, real-time streaming hash, local co-existence hash, and IDT testimony hash to the IDT Authentication Blockchain 1330.

[0150] Another recording operation 3344 executes by a smart contract to record the user permission corresponding to the IDT alternative ID on the IDT certification blockchain 1330, and a communication operation 39600 executes by sending the user permission to the IDT orchestrator 1210 to update the log entries of the IDT orchestrator 1210 (also known as the "IDT orchestrator recording operation"). Another recording operation 3345, combined with the communication operation 39700, executes by a smart contract to record the alternative immutable digital testimony ID and the alternative IDT hash on the public blockchain 1340 (also known as the "public blockchain recording operation").

[0151] In some implementations, IDT orchestrator 1210 (e.g., in orchestrator layer 1200) receives user licenses via communication operation 39600 and then performs update operation 3220 to update the license management system 3210 of the IDT orchestrator on orchestrator layer 1200, thereby creating a local ledger of license details. In some implementations, IDT orchestrator 1210 also performs creation operation 3230 to create an immutable digital testimony track, described in more detail below.

[0152] Figure 6 A process 600 for creating an immutable digital testimonies (IDT) trajectory 6200 according to an example implementation is shown. Typically, each immutable digital testimonies may have an associated IDT trajectory. To the extent applicable, each immutable digital testimonies may also have an IDT trajectory associated with associated third-party immutable digital testimonies. An IDT orchestrator 1210 is configured to identify all third-party immutable digital testimonies (IDTs) and devices (e.g., mobile devices, camera devices, etc.) along a path taken by the user within a user-defined time frame prior to the creation of the immutable digital testimonies. Figure 6 The Immutable Digital Testimony (IDT) path identification operation 6205 is shown in the diagram. As explained below, not all camera devices have the capability to execute the IDT request procedure 2200. Figure 2 (ability).

[0153] In some implementations, IDT orchestrator 1210 collects (e.g., using IDT geographic data) the information needed to create a map of IDT trajectory 6200, as illustrated by the creation of an immutable digital testimony (IDT) trajectory map operation 6210. Furthermore, IDT orchestrator 1210 identifies and visually indicates the locations of all third-party immutable digital testimony (IDTs) and immutable digital testimony (IDT) camera devices, as illustrated by the identification operation 6220. In some implementations, IDT orchestrator 1210 also performs a communication operation 69100 to send a visualization indicating the locations of all third-party IDTs and IDT camera devices to the device 1110 requesting the IDT trajectory.

[0154] IDT orchestrator 1210 then performs recording operation 6225 in conjunction with communication operation 69200 to record the IDT ID, IDT geographic data associated with the IDT trajectory, and all other immutable digital testimony identifiers that identify other third-party IDTs and IDT camera devices along the IDT trajectory or that are associated with other third-party IDTs and IDT camera devices on the IDT certification blockchain 1330.

[0155] In some implementations, the IDT trajectory identifies other immutable digital testimonies (IDTs) created along the path. This method involves creating a map of the immutable digital testimonies' trajectory using an IDT orchestrator 1210. Typically, IDT geographic data is used to identify third-party IDTs and camera devices along the user's path during a predetermined time period (e.g., 60 minutes) prior to the creation of the immutable digital testimonies. The method includes an identification operation 6220 that performs identification and visually indicates the locations of these third-party IDTs and camera devices. Subsequently, a communication operation 69100 sends the map of the immutable digital testimonies' trajectory to the device. The IDT orchestrator, in conjunction with the communication operation 69200, performs a recording operation 6225 to record the IDT ID, geographic data, and the IDs of the identified third-party IDTs and camera devices on the IDT authentication blockchain 1330.

[0156] Reference Figure 2 , Figure 3 and Figure 6 In some implementations, a thumbnail of a specific immutable digital testimony ID will appear in the witness creator's immutable digital testimony (IDT) repository (e.g., on witness layer 1100), and, where applicable, in the IDT repository of the witness requester who initiated the third-party immutable digital testimony (IDT) request process 2210, as shown by presentation operation 3195. Furthermore, where available, the IDT trace will be associated with the specific immutable digital testimony ID and will be accessible from the IDT repository.

[0157] All third-party IDTs and devices (e.g., mobile devices, camera devices, etc.) that allow requests to view immutable digital testimonies will be visually identifiable (e.g., by distinguishable device icons, such as by the color or size of the icons), as shown by device 6231.

[0158] Camera devices that do not provide the ability to request viewing of immutable digital testimonies and all third-party IDTs will be visually identifiable (e.g., by a distinguishable device icon, such as by the icon's color or size), as shown by device 6232. Furthermore, the user can select any of the devices (in this example, camera devices) (as shown by device 6232). Figure 6 The third-party selection operation 6110 (as shown) initiates such an IDT request viewing process 2220 or testimony sharing process 2230. Next, after selecting a device (e.g., a camera device) on the IDT track, the IDT request process 6120 is initiated to initiate the IDT request.

[0159] On the other hand, a process for generating IDT trajectories is provided. The method involves creating an immutable digital testimony trajectory that identifies immutable digital testimonies created along a path. This involves an IDT path identification operation 6205, which executes a map created by the IDT orchestrator 1210 by identifying: (i) one or more third-party immutable digital testimonies, (ii) one or more camera devices, or (iii) a combination of (i) and (ii), each along a path taken by the user during a predetermined time period prior to the creation of the immutable digital testimonies. Identification operation 6220 performs the identification and visual indication of the positions of (i) one or more third-party immutable digital testimonies, (ii) one or more camera devices, or (iii) a combination of (i) and (ii). Accordingly, recording operation 6225, in conjunction with communication operation 69200, executes the following recorded by IDT orchestrator 1210 on IDT authentication blockchain 1330: (i) IDT ID and (ii) IDT geographic data associated with the respective creators of IDT local media; and one or more IDT IDs associated with (i) one or more immutable digital testimonies of third parties, (ii) one or more video cameras, or (iii) one or more of the IDT IDs corresponding to both (i) and (ii).

[0160] Reference Figure 3In some implementations, the method further involves presentation operation 3195, which performs the presentation of a thumbnail corresponding to a specific IDT ID on the IDT library of the creator of the immutable digital testimony, and presentation operation 6100, which performs the presentation of the IDT track as part of the metadata of the IDT local media in the IDT library, wherein any one or a combination of the following is identified by one or more icons (correspondingly 6231, 6232): (i) one or more third-party immutable digital testimonies and (ii) one or more camera devices, each of which allows a request to view the immutable digital testimonies. IDT request initiation operation 6120 performs the initiation of IDT viewing procedure 2220 or IDT sharing request procedure 2230 corresponding to the immutable digital testimonies.

[0161] Figure 4 A third-party request process 400 for requesting immutable digital testimony, according to an example implementation, is shown.

[0162] In some implementations, the device (e.g., on witness layer 1100) executes instructions that cause the device to perform identification and authentication of a third-party immutable digital testimonies requester who has requested immutable digital testimonies via a third-party immutable digital testimonies device, as illustrated by user authentication operation 4100. In this example, the third-party IDT requester makes the request via a device on which the IDT application 120 is already installed; this third-party device is referred to as third-party IDT device 1110-2. The request for immutable digital testimonies causes the immutable digital testimonies (IDT) request process to capture the third-party immutable digital testimonies requester identifier (“Third-Party IDT ID”) and the device identifier (ID) of the third-party IDT device 1110-2 used to create the request for immutable digital testimonies.

[0163] Also refer to Figure 2 Furthermore, a third-party immutable digital testimonies requester can initiate any of a plurality of immutable digital testimonies requests, as illustrated by the IDT request initiation operation 4110. In some embodiments, the request is an IDT request initiation process 2210, which requests the IDT creator to initiate and share a new immutable digital testimonies. In some embodiments, the request is an IDT viewing process 2220, which requests permission from the IDT creator to view one or more of the IDT creator's existing immutable digital testimonies. In some embodiments, the request is an IDT sharing request process 2230, which requests permission from the IDT creator to share one or more of the IDT creator's existing immutable digital testimonies with another user or device on network 100.

[0164] In some implementations, the third-party IDT device 1110-2 creates an IDT request by combining the third-party IDT ID, the IDT creator's phone number, and the IDT ID (e.g., in the case of IDT viewing process 2220 and IDT sharing request process 2230), as shown by the creation of immutable digital testimony request operation 4120.

[0165] Then, the third-party IDT device 1110-2 sends the IDT request to the IDT orchestrator, as shown in communication operation 49100.

[0166] In an example implementation, a method for requesting an immutable digital testimonies is provided. The method involves identifying a user of a device (such as a third-party IDT device 1110-2) to authenticate a third-party immutable digital testimonies (IDT) requester by capturing the immutable digital testimonies creator ID of the third-party immutable digital testimonies requester and the immutable digital testimonies device ID of the third-party device used to create the immutable digital testimonies request, as shown in user authentication operation 4100. The method also involves the third-party immutable digital testimonies requester initiating any one or more of the following from the immutable digital testimonies creator: an immutable digital testimonies request requesting the initiation and sharing of a new immutable digital testimonies; an immutable digital testimonies viewing request requesting permission to view the existing immutable digital testimonies of the immutable digital testimonies creator; and an immutable digital testimonies sharing request requesting permission to share one of the existing immutable digital testimonies of the immutable digital testimonies creator with another immutable digital testimonies network user, as shown in initiating IDT request operation 4110. The method also involves using a device (e.g., by combining any one or a combination of the following) to... Figure 4 The third-party IDT device 1110-2 creates an immutable digital testimony request: the ID of the third-party immutable digital testimony requester, the telephone number of the immutable digital testimony creator, and the immutable digital testimony ID, as shown in the immutable digital testimony request creation operation 4120. Then, the method executes by having the third-party IDT device 1110-2 send the immutable digital testimony request to the immutable digital testimony orchestrator, as shown in the communication operation 49100.

[0167] In some implementations, authenticating a third-party IDT requester includes capturing the third-party IDT requester ID and the third-party IDT requester device ID corresponding to the device used by the third-party IDT requester to create the immutable digital testimony request, as shown in user authentication operation 4100.

[0168] In some use cases, IDT orchestrator 1210 (e.g., on orchestrator layer 1200) directs third-party IDT requests to users who are not IDT creators. If the user is not a member of network 100, then IDT orchestrator 1210 prompts the user (referred to as an "unregistered IDT creator") to download IDT application 120 and register to create one or more IDTs, as illustrated by communication operation 49200.

[0169] In some implementations, the device of the IDT creator or prospective IDT creator performs an incoming IDT request operation 4130 to present an alert to the IDT creator (or prospective IDT creator) regarding an incoming Immutable Digital Testimony (IDT) request. Here, the device is referred to as IDT creator device 1110-1 or simply creator device 1110-1, on which the IDT application 120 is also installed.

[0170] Then, the IDT creator (or prospective IDT creator) evaluates whether to grant the IDT request, as shown in evaluation operation 4140 for the IDT request.

[0171] If the IDT creator (or the intended IDT creator) rejects the IDT request, the device will notify the IDT orchestrator 1210 as shown by communication operation 41410, which in turn notifies the requester as shown by communication operation 41420.

[0172] If the IDT creator (or the expected IDT creator) approves the request for an IDT, as shown in operation 4150 for approving a third-party IDT request, then the IDT creator initiates the IDT creation process, as shown in operation 4151 for initiating an IDT creation.

[0173] If a third-party request is an approval request to view an IDT, and the IDT creator approves the request, as shown by the approval operation 4160 for viewing an IDT, then the creator device 1110-1 notifies the IDT orchestrator 1210 of the approval as shown by the communication operation 41610, and the IDT orchestrator 1210 updates the license management system 3210 on the orchestrator layer 1200, as shown by the update operation 4210, thereby granting the third-party requester viewing permission for the specific IDT ID included in the IDT viewing request based on the third-party requester ID.

[0174] Furthermore, as shown by communication operation 49300, the creator device 1110-1 records the viewing permission to the IDT authentication blockchain 1330 on the IDT layer 1300, thereby creating a log entry indicating that the third-party requester ID has viewing permission for a specific IDT ID included in the IDT viewing request.

[0175] If the IDT creator approves a request to share an immutable digital testimonies (e.g., IDT sharing request 2300), as shown by operation 4170, then the creator device 1110-1 will notify the IDT orchestrator 1210 of the approval, as shown by communication operation 41710, and the IDT orchestrator 1210 will perform update operation 4220 to update the license management system 3210 on the orchestrator layer 1200, thereby granting the third-party requester sharing rights to the specific IDT ID included in the IDT sharing request via the third-party requester ID associated with the third-party request.

[0176] Furthermore, as shown by communication operation 49400, the creator device 1110-1 records the sharing permission to the IDT certification blockchain 1330 on the IDT layer 1300, thereby creating a log entry indicating that the third-party requester associated with the third-party requester ID has sharing rights to a specific IDT ID included in the IDT sharing request.

[0177] In some implementations, a thumbnail of a specific IDT ID (which is included in the IDT request) is presented to the IDT creator (e.g., on witness layer 1100) via an immutable digital testimonies (IDT) library, as illustrated by presentation operation 4180, and presentation operation 4190 presents the thumbnail in the IDT library of the third-party requester who initiated the IDT request. In an example implementation, the thumbnail will have a badge of a first color (e.g., green) if a viewing license is granted, and a badge of a different color (e.g., yellow) if a sharing license is granted. Alternatively, other indication techniques may be used and remain within the scope of the implementations herein.

[0178] Figure 5 An immutable digital viewing process 500 according to an example implementation is shown.

[0179] In the example implementation, the user opens the IDT library feature via a device such as creator device 1110-1 or third-party IDT device 1110-2 (e.g., on witness layer 1100), as shown in the open IDT library operation 5100. To view the IDT, the user selects a specific thumbnail. The device receives the selection of the specific thumbnail, as shown in the user IDT selection operation 5110.

[0180] The device then sends a request to view the immutable digital testimony (for a specific IDT ID) to the IDT orchestrator 1210 (on the orchestrator layer 1200), as shown by communication operation 59100.

[0181] IDT orchestrator 1210 receives a request to view the IDT and, as shown in the communication, verifies on the IDT authentication blockchain 1330 that the user associated with the IDT viewing request has viewing permission, as shown in communication operation 59200. If the user associated with the request has viewing permission, the smart contract on the IDT authentication blockchain 1330 retrieves the IDT frame hash scheme from the IDT metadata recorded on the IDT authentication blockchain 1330, as shown in communication operation 59250. If the user has viewing permission, the smart contract on the IDT authentication blockchain 1330 notifies the IDT orchestrator 1210, and the IDT cloud address, real-time stream hash, and IDT frame hash scheme are sent to the device via the IDT orchestrator 1210, as shown in communication operations 59300 and 59400, respectively.

[0182] If the IDT-certified blockchain 1330 also has alternative immutable digital testimonies, then the IDT orchestrator 1210 will also send the corresponding information of the IDT ID and the alternative immutable digital testimonies ID to the device.

[0183] If a user is not authorized to view the immutable digital testimonies, the IDT authentication blockchain 1330 notifies the IDT orchestrator 1210 via communication operation 59300. The IDT orchestrator then notifies the IDT application 120 on the device via communication operation 59500 that no viewing permission is granted and issues an inquiry regarding whether the user wishes to send (e.g., by initiating the IDT viewing process 2220) a request to view the immutable digital testimonies.

[0184] Next, the authorization operation 5115 performs the authorization verification. Then, the device (e.g., on the witness layer 1100) performs the media request operation 5120 to request IDT cloud media from IDT cloud 1310.

[0185] Furthermore, IDT Cloud 1310 directly transmits (e.g., streams or downloads) IDT Cloud media from the IDT Cloud address on IDT Cloud 1310, as shown by communication operation 59600.

[0186] During media transmission, media verification operation 5130 performs verification of the incoming IDT cloud media by creating a view hash. As used herein, a "view hash" typically refers to a media hash used by a viewer during live playback to verify that the original media was not corrupted during transmission and has not been altered since the date its corresponding immutable digital testimony was created. In the example implementation, the view hash is created by hashing each frame of the streaming IDT cloud media (using, for example, an IDT frame hashing scheme from communication operation 59400, and then combining or hashing each frame together to form the view hash). Once the view hash is complete, it is compared with the live streaming hash.

[0187] In some implementations, if the viewed hash matches the live stream hash, then IDT display operation 5140 executes to present the IDT media on the IDT viewer, and the device records the viewing event (including IDT ID, IDT user ID, IDT device ID, and viewing date) on the IDT certification blockchain 1330 via communication operation 59700.

[0188] In some implementations, if an alternative IDT exists, the media corresponding to the alternative IDT will also be transmitted from the alternative IDT FS address, and a view hash is created by applying a hashing process to the alternative IDT media and comparing it with a local co-occurrence hash (which will be downloaded instead of the live stream hash).

[0189] If the hash displayed does not match the real-time streaming hash, the device will notify the user that the streaming IDT cloud media has been altered or corrupted during the download, thus requiring a re-initiation of the transmission as indicated by Re-initiation Operation 5150.

[0190] The IDT DFS address (and corresponding media) can potentially be used to recreate or rebuild the IDT in the event that the IDT cloud media is damaged or altered.

[0191] Figure 7 An immutable digital testimonies (IDT) authentication process 700 according to an example implementation is shown. Typically, for the benefit of a particular user, the IDT authentication process 700 enables a user on network 100 to request the sending and authentication of an immutable digital testimonies.

[0192] The method involves initiating operation 7110, which performs receiving an initiation request (e.g., via user input device 106 of device 1110), which, for the benefit of a particular user, requests the sending and authentication of an immutable digital testimony of the user issuing the request (e.g., the IDT creator). The user then selects a thumbnail from their photo library and selects an authentication button, as shown by selection operation 7111.

[0193] The recipient selection operation 7112 receives (e.g., via user input device 106 of device 1110) a selection of one or more people (e.g., from a list of contacts on the device) to whom the user wants to send immutable digital testimony. The recipient is referred to as the "intended recipient".

[0194] The Create Immutable Digital Testimony operation 7120 performs IDT authentication created by the device, and in the example implementation, sends the intended recipient's phone number and IDT ID to the IDT orchestrator 1210, as shown by the communication operation 79100.

[0195] After receiving the intended recipient's phone number and IDT ID, the IDT orchestrator 1210 proceeds to perform immutable digital signature authentication. In the example implementation, if the intended recipient is not a member of network 100 (e.g., the intended recipient has not yet registered to access network 100), then the IDT orchestrator 1210 will prompt the intended recipient to download IDT application 120 to their device and execute IDT application 120 on their device, as shown by communication operation 79200.

[0196] Then, the IDT orchestrator 1210 performs a recording operation to record the IDT authentication on the IDT authentication blockchain 1330, as shown by communication operation 79300. The recording operation also creates a log entry indicating that the intended recipient's IDT user ID has viewing rights to the specific shared IDT ID.

[0197] Then, the IDT orchestrator 1210 retrieves the IDT cloud address, real-time stream hash, and IDT frame hash scheme from the IDT certification blockchain 1330, as shown by communication operation 79400.

[0198] If the IDT-certified blockchain 1330 also has an alternative immutable digital testimony, then the IDT orchestrator 1210 will also send the corresponding information of the IDT ID and the IDT alternative ID to the intended recipient.

[0199] In some implementations, IDT orchestrator 1210 also performs update operation 7230 to update the license management system on orchestrator layer 1200, thereby granting the intended recipient viewing access to an immutable digital testimony user ID included in the IDT certification.

[0200] The IDT orchestrator 1210 also sends the IDT ID, IDT cloud address, real-time stream hash, and IDT frame hash scheme to the intended recipient's device via communication operation 79500.

[0201] Then, the intended recipient's device prompts the intended recipient for incoming IDT authentication, as shown by incoming authentication prompting operation 7130. Presentation operation 7140 performs the presentation of a thumbnail of a specific IDT ID (e.g., which is included in the IDT authentication) so that the thumbnail appears on the intended recipient's IDT library.

[0202] Then, IDT application 120 will (e.g., automatically) perform request operation 7150 to request IDT cloud media from the IDT cloud, and the media will be transmitted (e.g., streamed or downloaded), as shown by communication operation 79600.

[0203] When media is delivered (e.g., streaming or downloading), it is verified by verification operation 7160 by forming a verification hash. As used in this article, "verification hash" generally refers to a media hash that a viewer plays back in real time to verify that the original media has not been altered since the date its corresponding immutable digital testimony was created.

[0204] In the example implementation, the verification hash is formed by hashing each frame of the live streaming IDT cloud media, which is then combined or hashed together to form the verification hash (using the IDT frame hashing scheme received via communication operation 79500). Once the verification hash is complete, it is compared with the live streaming hash.

[0205] If the verification hash matches the live streaming hash, then the presentation operation 7170 displays the immutable digital testimony on the IDT viewer, and the device, in conjunction with the communication operation 79700, performs the recording operation 7171 to record the viewing event (including IDTID, IDT user ID, IDT device ID, and viewing date) on the IDT certification blockchain 1330.

[0206] If an alternative immutable digital testimony exists, the media corresponding to the alternative immutable digital testimony will also be delivered from the alternative IDT cloud address (e.g., streaming or downloading), and a verification hash will be created by applying a hashing process to the alternative IDT media and comparing it with a local co-occurrence hash (in the example implementation, which will be downloaded instead of the live streaming hash).

[0207] If the verification hash does not match the live stream hash, then IDT application 120 alerts the intended recipient that the IDT cloud media has been altered or corrupted during transmission, as shown by communication operation 71720, thus requiring a re-initiation of transmission (e.g., streaming or downloading), as shown by start operation 7180.

[0208] In some implementations, the IDT DFS address (and corresponding media) can also be used to recreate or rebuild immutable digital testimonies in the event that the IDT cloud media is damaged or altered.

[0209] In some implementations, a non-transitory computer-readable medium stores one or more sequences of instructions to cause one or more processors to perform any of the methods described herein.

[0210] The following are additional terms relating to this disclosure, which may be integrated with any combination of the embodiments described above or listed in the appended claims and / or otherwise.

[0211] Clause 1. A method for processing requests for immutable digital testimony media, comprising:

[0212] Transmit immutable digital testimony cloud media from one or more cloud addresses in the cloud (59600).

[0213] While the immutable digital testimony cloud media is being transmitted, verify the immutable digital testimony cloud media (5130) using the following:

[0214] Select one or more frames of the immutable digital testimony cloud media being transmitted.

[0215] The selected immutable digital testimony hashing scheme is used to hash one or more frames of the selected one or more frames transmitting the immutable digital testimony cloud media, thereby creating one or more immutable digital testimony transmission hashes.

[0216] Combining one or more immutable digital testimony transmission hashes to form a view hash; and

[0217] The view hash will be compared with the live streaming hash, where:

[0218] (a) If the viewed hash matches the live stream hash, then: the immutable digital testimony cloud media is played on the immutable digital testimony viewer (5140), and the viewing event (including the immutable digital testimony ID, the third-party requester's immutable digital testimony ID, the third-party requester's immutable digital testimony device ID, and the viewing date) is recorded by the device on the immutable digital testimony authentication blockchain (59700), and

[0219] (b) If the hash viewed does not match the live stream hash, then: generate an alert indicating that the immutable digital testimony cloud media has been altered or corrupted during transmission, thus requiring a re-initiation of the download of the immutable digital testimony cloud media (5150).

[0220] Clause 2. According to the method of Clause 1, whereby the real-time streaming hash (3130) is created by the following:

[0221] By applying an immutable digital testimony hashing scheme selected from multiple hashing schemes to hash one or more frames of immutable digital testimony streaming media from one or more camera devices, one or more immutable digital testimony stream hashes (3130, 3132) are created; and

[0222] Real-time stream hashes are formed from one or more immutable digital testimony stream hashes (3133).

[0223] Clause 3. The method according to claim 1 further includes:

[0224] Transmit (59600) immutable digital testimony cloud media, replacing immutable digital testimony, from one or more immutable digital testimony cloud addresses or one or more immutable digital testimony DFS addresses; and

[0225] Displays and replaces immutable digital testimonies in cloud media.

[0226] Clause 4. A method for verifying media stored on a cloud server, comprising:

[0227] Select one or more frames of the live stream and use the selected hashing scheme to hash one or more frames of the live stream to create one or more live stream hashes;

[0228] Combine one or more real-time streaming hashes to form a combined real-time streaming media hash;

[0229] Send the combined real-time streaming hash to the smart contract;

[0230] Select one or more frames of media stored on the first storage device, and hash the selected one or more frames of media stored on the first storage device using a selected immutable digital testimony hashing scheme, thereby creating one or more first storage device media hashes.

[0231] Combine one or more first storage device media hashes to form a combined first storage device media hash;

[0232] Select one or more frames of media stored on a second storage device, and hash one or more of the selected frames of media stored on the second storage device using a selected immutable digital testimony hashing scheme, thereby creating one or more second storage device media hashes.

[0233] Combine one or more second storage device media hashes to form a combined second storage device media hash;

[0234] The smart contract compares the combined real-time streaming media hash, the combined media hash of the first storage device, and the combined media hash of the second storage device.

[0235] If a) the combined real-time streaming hash reflects the combined media hash of the first storage device, and b) the combined real-time streaming hash reflects the combined media hash of the second storage device, then:

[0236] Notifications that the real-time streaming media provided by the smart contract, the media stored on the first storage device, and the media stored on the second storage device have been verified; and

[0237] If a) the combined real-time streaming hash and the combined first storage device media hash do not match, or b) the combined real-time streaming hash and the combined second storage device media hash do not match, then:

[0238] Notification that one or a combination of (i) live streaming media, (ii) media stored on a first storage device, and (iii) media stored on a second storage device has been corrupted, provided by a smart contract.

[0239] Clause 5. A system having one or more processors and nontransitory memories communicatively coupled to a plurality of sensors, the nontransitory memories storing instructions that, when executed by the processors, control the system to perform the methods of Clauses 1 to 4.

[0240] Clause 6. A non-transitory computer-readable medium having stored thereon one or more sequences of instructions to cause one or more processors to perform the methods of Clauses 1 to 4.

[0241] While various exemplary embodiments of the invention have been described above, it should be understood that they are presented by way of example and not as limitations. It will be apparent to those skilled in the art that various changes in form and detail may be made therein. Therefore, the invention should not be limited to any of the exemplary embodiments described above, but should be defined solely by the appended claims and their equivalents.

[0242] Furthermore, it should be understood that Figures 1 to 7 Presented for illustrative purposes only. The architecture of the example implementations presented herein is flexible and configurable enough to allow the architecture to be utilized (and navigated) in ways other than those shown in the accompanying drawings.

[0243] Furthermore, the purpose of the foregoing abstract is to enable the U.S. Patent and Trademark Office and the general public, especially scientists, engineers, and practitioners in the art who are generally unfamiliar with patent or legal terminology or wording, to quickly determine the nature and essence of the technical disclosure of this application from a cursory examination. The abstract is not intended to limit the scope of the exemplary embodiments presented herein in any way. It should also be understood that the processes recited in the claims need not be performed in the order presented.

Claims

1. A method for creating an immutable digital certificate, comprising the steps of: activating an immutable digital certificate creation operation on a device 1110 having an immutable digital certificate device identifier (ID) (2102), wherein the immutable digital certificate device ID is a unique identifier of the device; authenticating a creator of an immutable digital certificate based on an immutable digital certificate creator ID (3100), wherein the immutable digital certificate creator ID is a unique user identification created upon registration to an immutable digital certificate network; capturing the immutable digital certificate device ID of the device used to create the immutable digital certificate (3100); and initiating, by the device, an immutable digital certificate capture operation following authentication of the creator (3110), comprising: activating one or more cameras associated with the device and causing the device to generate immutable digital certificate stream media (3120), hashing one or more frames of the immutable digital certificate stream media of the one or more cameras by applying an immutable digital certificate hashing scheme selected from a plurality of hashing schemes, thereby creating one or more immutable digital certificate stream hashes (3130, 3132), forming a real-time stream hash from the one or more immutable digital certificate stream hashes (3130, 3133), capturing immutable digital certificate metadata to be recorded on an immutable digital certificate authentication blockchain (3140), transmitting, by the device, the immutable digital certificate stream media and the selected immutable digital certificate hashing scheme to a cloud server (3147, 39100), thereby causing the selected immutable digital certificate hashing scheme and the immutable digital certificate stream media to be stored on the cloud server as immutable digital certificate cloud media, retrieving one or more immutable digital certificate addresses (39110), each of the one or more immutable digital certificate addresses being: (i) one or more cloud addresses on the cloud server; (ii) one or more distributed file system (DFS) addresses on a DFS; or (iii) a combination of (i) and (ii), respectively, wherein each of the one or more immutable digital certificate addresses corresponds to: (i) a location where the immutable digital certificate cloud media, which is at least a portion of the immutable digital certificate stream media, is saved; or (ii) an assigned location for saving the immutable digital certificate cloud media, which is at least a portion of the immutable digital certificate stream media, following completion of the transmitting: encrypting the immutable digital certificate real-time stream media (3148), thereby creating encrypted immutable digital certificate real-time stream media, which is at least a portion of the immutable digital certificate stream media, sending (39010) the encrypted immutable digital witness live stream media to the DFS (39100) for saving the encrypted immutable digital witness live stream media, receiving (39015) one or more immutable digital witness DFS addresses, wherein each of the one or more immutable digital witness DFS addresses corresponds to a location where the encrypted immutable digital witness live stream media has been saved, and saving the immutable digital witness stream media on the device to create immutable digital witness local media (3149).

2. The method of claim 1, further comprising: selecting one or more frames of the immutable digital witness local media that correspond to the same one or more frames of the immutable digital witness stream media (3151); hashing one or more of the selected one or more frames of the immutable digital witness local media using the selected immutable digital witness hashing scheme, thereby creating one or more immutable digital witness local hashes (3152); forming a local coexistence hash from the one or more immutable digital witness local hashes (3150, 3153); sending (39020), by the device, the local coexistence hash to a smart contract for verification against the live stream hash; and sending (3160, 39030), by the device, the live stream hash, the immutable digital witness metadata, the one or more immutable digital witness DFS addresses, and the one or more immutable digital witness cloud addresses to the smart contract.

3. The method of claim 2, further comprising: selecting one or more frames of the immutable digital witness cloud media that correspond to the same one or more frames of the immutable digital witness stream media (3311); hashing one or more of the selected one or more frames of the immutable digital witness cloud media using the selected immutable digital witness hashing scheme, thereby creating one or more immutable digital witness cloud hashes (3312); forming a cloud media hash from the one or more immutable digital witness cloud hashes (3313); and sending (39040), by the cloud server, the cloud media hash to the smart contract for verification against the live stream hash.

4. The method of claim 3, further comprising: creating, by the smart contract, a creator token by combining the immutable digital witness creator ID and the immutable digital witness device ID (3331); creating, by the smart contract, an immutable digital witness identifier (ID) by hashing the creator token with the live stream hash (3332); and comparing, by the smart contract, the live stream hash, the local coexistence hash, and the cloud media hash, and if a) the live stream hash reflects the local coexistence hash, and b) the live stream hash reflects the cloud media hash (3333), then: ​ creating an immutable digital credential hash (3380) by the smart contract hashing the immutable digital credential ID, the one or more immutable digital credential cloud addresses, the immutable digital credential metadata, the one or more immutable digital credential DFS addresses, and the live stream hash, recording (3334) the immutable digital credential ID, the one or more immutable digital credential cloud addresses, the immutable digital credential metadata, the one or more immutable digital credential DFS addresses, the immutable digital credential hash, the live stream hash on the immutable digital credential authentication blockchain, and recording (3335) the user permissions on the immutable digital credential authentication blockchain by the smart contract, sending (39300) the user permissions to the immutable digital credential orchestrator (1210) to create a log entry based on the user permissions indicating whether the corresponding immutable digital credential creator ID has any rights to the immutable digital credential cloud media associated with a particular immutable digital credential ID, and recording (39400) (33360) the immutable digital credential ID and the immutable digital credential hash on a public blockchain by the smart contract.

5. The method of claim 4, further comprising: granting (3335) viewing permissions to a requester for an immutable digital credential corresponding to the immutable digital credential ID by the smart contract, and registering the viewing permissions on an immutable digital credential authentication blockchain and the immutable digital credential orchestrator (1210).

6. The method of any of claims 4-5, further comprising: periodically verifying and authenticating (39070) the immutable digital credential authentication blockchain using the immutable digital credential hash recorded on the public blockchain.

7. The method of any of claims 3-6, further comprising: if a) the live stream hash and the local symbiotic hash do not match, or b) the live stream hash and the cloud media hash do not match, then: creating (3180) an alternative immutable digital credential by saving (3190) the immutable digital credential local media to the DFS (39500) and the cloud server (39511), and retrieving one or more alternative immutable digital credential DFS addresses (39510) and one or more alternative immutable digital credential cloud addresses (39512) accordingly, and providing (39050) a notification by the smart contract that the immutable digital credential stream media was corrupted during transmission or storage.

8. The method of claim 7, further comprising: sending (3191, 39060) the immutable digital credential metadata, the live stream hash, the local symbiotic hash, the one or more alternative immutable digital credential cloud addresses, and the one or more alternative immutable digital credential DFS addresses to the smart contract by the device.

9. The method of any one of claims 7-8, further comprising: receiving, by the smart contract, the alternative immutable digital credential metadata, the live stream hash, the local symbiotic hash, and the one or more alternative immutable digital credential DFS addresses (39060); creating, by the smart contract, an alternative creator token by combining the immutable digital credential creator ID and the immutable digital credential device ID (33410); creating, by the smart contract, the immutable digital credential alternative ID by hashing the alternative creator token with the live stream hash and adding ALT at the end of the immutable digital credential alternative identifier (ID) (33420); creating, by the smart contract, the alternative immutable digital credential hash by hashing the immutable digital credential alternative ID, the immutable digital credential metadata, the one or more alternative immutable digital credential cloud addresses, the one or more alternative immutable digital credential DFS addresses, the local symbiotic hash, and the live stream hash (3349); recording, by the smart contract, the immutable digital credential alternative ID, the immutable digital credential metadata, the one or more alternative immutable digital credential cloud addresses, the one or more alternative immutable digital credential DFS addresses, the live stream hash, the local symbiotic hash, and the alternative immutable digital credential hash to the immutable digital credential attestation blockchain (33430); recording, by the smart contract, user permissions corresponding to the immutable digital credential alternative ID on the attestation blockchain (33440) and sending (39600) the user permissions to an immutable digital credential orchestrator (1210) to update a log entry of the immutable digital credential orchestrator (1210); and recording, by the smart contract, the alternative immutable digital credential ID and the alternative immutable digital credential hash on the public blockchain (33450, 39700).

10. The method of any one of claims 7-9, further comprising: receiving, by the immutable digital credential orchestrator (1210), user view permissions for an immutable digital credential corresponding to the immutable digital credential alternative ID (39600); and creating, by the immutable digital credential orchestrator (1210), a local ledger of permission details based on the user permissions.

11. The method of any one of claims 1-10, further comprising: authenticating a third party immutable digital credential requester; initiating, by the third party immutable digital credential requester, a third party request from an immutable digital credential creator (4110), the third party request being any one or more of: an immutable digital credential request (2210) requesting creation and sharing of a new immutable digital credential; an immutable digital credential view request (2220) requesting permission to view an existing immutable digital credential of the creator; or an immutable digital credential view request (2220) requesting permission to view an existing immutable digital credential of the creator. Immutable digital witness sharing request (2230) requesting permission to share the creator's existing immutable digital witness with another immutable digital witness network user; The third-party request (4120) is created by the third-party immutable digital witness requestor's device by combining any one or a combination of: third-party immutable digital witness requestor ID, immutable digital creator phone number, and immutable digital witness ID; And The third-party request is sent by the third-party immutable digital witness requestor to an immutable digital witness orchestrator (49100).

12. The method of any one of claims 4-11, further comprising: creating an immutable digital witness trail for identifying immutable digital witnesses created along a path by: creating, by an immutable digital witness orchestrator (1210), a map (3230) of (i) one or more third-party immutable digital witnesses, (ii) one or more cameras, or (iii) a combination of both (i) and (ii), each taken along a path (6205) taken by a user during a user predetermined time prior to creation of an immutable digital witness; identifying and visually indicating (6220) locations of (i) the one or more third-party immutable digital witnesses, (ii) the one or more cameras, or (iii) a combination of both (i) and (ii); sending the map of the immutable digital witness trail to a device of a creator of the immutable digital witness (69100, 6210), the map to be associated with the immutable digital witness local media stored on the creator's device; and correspondingly, recording by the immutable digital witness orchestrator on the immutable digital witness attestation blockchain (69200): an immutable digital witness trail associated with (i) an immutable digital witness identifier (ID) and (ii) immutable digital witness geolocation data each associated with a creator of the immutable digital witness local media, and one or more of the immutable digital witness identifiers corresponding to (i) the one or more third-party immutable digital witnesses, (ii) the one or more cameras, or (iii) both (i) and (ii).

13. The method of claim 12, further comprising: presenting (3190) a thumbnail of a particular immutable digital witness ID on the immutable digital witness library (2600) of the creator of the immutable digital witness; and presenting (6100) the immutable digital witness trail as part of metadata of the immutable digital witness local media in the immutable digital witness library, wherein correspondingly, any one or a combination of (i) the one or more third-party immutable digital witnesses, and (ii) the one or more cameras, each allowing a request for immutable digital witness viewing, is identified with one or more icons (6231). initiating an immutable digital witness viewing or immutable digital witness sharing request (2220, 2230) for the corresponding immutable digital witness by selecting any one of the one or more icons (6110, 6120).

14. A system having one or more processors and a non-transitory memory communicatively coupled to a plurality of sensors, the non-transitory memory storing instructions that, when executed by the processors, control the system to create and view immutable digital witnesses, the system comprising: a first layer (1100) operating on a device (1110) having an immutable digital witness device identifier (ID), wherein the immutable digital witness device ID is a unique identifier of a creator device, the device configured to: activate an immutable digital witness creation operation; authenticate a creator of an immutable digital witness based on an immutable digital witness creator ID (3100), wherein the immutable digital witness creator ID is a unique user identification created upon registration to an immutable digital witness network; capture the immutable digital witness device ID of the device used to create the immutable digital witness (3100); after authentication of the creator, initiate an immutable digital witness capture operation (3110) to: activate one or more cameras associated with the device and cause the device to generate immutable digital witness stream media (3120); hash one or more frames of the immutable digital witness stream media of the one or more cameras by applying an immutable digital witness hashing scheme selected from a plurality of hashing schemes, thereby creating one or more immutable digital witness stream hashes (3130, 3132); form a real-time stream hash from the one or more immutable digital witness stream hashes (3130, 3133); capture immutable digital witness metadata to be recorded on an immutable digital witness authentication blockchain (3140); communicate the immutable digital witness stream media and the selected immutable digital witness hashing scheme to a cloud server (3147, 39100), thereby causing the selected immutable digital witness hashing scheme and the immutable digital witness stream media to be stored on the cloud server as an immutable digital witness cloud media; retrieving one or more immutable digital certificate addresses (39110), each of the one or more immutable digital certificate addresses is one of: (i) one or more cloud addresses on the cloud server; (ii) one or more distributed file system (DFS) addresses on a DFS; or (iii) a combination of (i) and (ii), respectively, wherein each of the one or more immutable digital certificate addresses corresponds to one of: (i) a location where the immutable digital certificate cloud media is saved, the immutable digital certificate cloud media being at least a portion of the immutable digital certificate stream media; or (ii) an assigned location for saving the immutable digital certificate cloud media, the immutable digital certificate cloud media being at least a portion of the immutable digital certificate stream media; after the transfer is complete: encrypting (3148) the immutable digital certificate live stream media, thereby creating encrypted immutable digital certificate live stream media, the encrypted immutable digital certificate live stream media being at least a portion of the immutable digital certificate stream media, sending (39100) the encrypted immutable digital certificate live stream media to the DFS for saving the encrypted immutable digital certificate live stream media, and receiving (39015) from the DFS one or more immutable digital certificate DFS addresses corresponding to locations on the DFS where the immutable digital certificate stream media is saved, wherein each of the one or more immutable digital certificate DFS addresses corresponds to a location where the encrypted immutable digital certificate live stream media has been saved; and saving the immutable digital certificate stream media on the device to create immutable digital certificate local media (3149).

15. The system of claim 14, wherein, The device is further configured to: select one or more frames of the immutable digital certificate local media corresponding to the same one or more frames of the immutable digital certificate stream media (3151); hash one or more frames of the selected one or more frames of the immutable digital certificate local media using the selected immutable digital certificate hashing scheme, thereby creating one or more immutable digital certificate local hashes (3152); form a local co-occurrence hash from the one or more immutable digital certificate local hashes (3153); send (39020) the local co-occurrence hash to the smart contract for verification against the live stream hash; and send (3160, 39030) the live stream hash, the immutable digital certificate metadata, the one or more immutable digital certificate DFS addresses, and the one or more immutable digital certificate cloud addresses to the smart contract.

16. The system of claim 15, further comprising: a third tier (1300) configured to: select one or more frames of the immutable digital certificate cloud media corresponding to the same one or more frames of the immutable digital certificate stream media (3311); hashing one or more of the selected one or more frames of the immutable digital witness cloud media using the selected immutable digital witness hash scheme, thereby creating one or more immutable digital witness cloud hashes (3312); forming a cloud media hash from the one or more immutable digital witness cloud hashes (3313); and sending the cloud media hash from the cloud server to the smart contract for verification against the live stream hash (39040).

17. The system of claim 16, wherein, the third tier (1300) is configured to: create a creator token by the smart contract by combining the immutable digital witness creator ID and the immutable digital witness device ID (3331); create an immutable digital witness identifier (ID) by the smart contract by hashing the creator token with the live stream hash (3332); and and compare, by the smart contract, the live stream hash, the local symbiotic hash, and the cloud media hash (33330), and if a) the live stream hash reflects the local symbiotic hash, and b) the live stream hash reflects the cloud media hash, then: create an immutable digital witness hash by the smart contract by hashing the immutable digital witness ID, the one or more immutable digital witness cloud addresses, the immutable digital witness metadata, the one or more immutable digital witness DFS addresses, and the live stream hash (3380), record, by the smart contract, the immutable digital witness ID, the one or more immutable digital witness cloud addresses, the immutable digital witness metadata, the one or more immutable digital witness DFS addresses, the immutable digital witness hash, the live stream hash on the immutable digital witness certification blockchain (33340), and record the user permissions on the immutable digital witness certification blockchain (33350), send the user permissions to an immutable digital witness orchestrator (1210) (39300) to create a log entry based on the user permissions, the log entry indicating whether the corresponding immutable digital witness creator ID has any permissions for the immutable digital witness cloud media associated with a particular immutable digital witness ID, and record, by the smart contract, the immutable digital witness ID and the immutable digital witness hash on a public blockchain (39400, 33360).

18. The system of any one of claims 16-17, wherein, the third tier (1300) is further configured to: if a) the live stream hash and the local symbiotic hash do not match, or b) the live stream hash and cloud media hash do not match, then: creating an alternative immutable digital credential (3180) by saving (3190) the immutable digital credential local media to the DFS (39500) and the cloud server (39511), and correspondingly retrieving one or more alternative immutable digital credential DFS addresses (39510) and one or more alternative immutable digital credential cloud addresses (39512), and providing, by the smart contract, a notification (39050) that the immutable digital credential stream media was corrupted during transmission or storage.

19. The system of claim 18, wherein, The device is further configured to: send (3191, 39060) the immutable digital credential metadata, the live stream hash, the local symbiotic hash, the one or more alternative immutable digital credential cloud addresses, and the one or more alternative immutable digital credential DFS addresses to the smart contract.

20. The system of claim 19, wherein, The smart contract is further configured to: receive (39060) the alternative immutable digital credential metadata, the live stream hash, the local symbiotic hash, and the one or more alternative immutable digital credential DFS addresses; create an alternative creator token (3341) by combining the immutable digital credential creator ID and the immutable digital credential device ID; create the immutable digital credential alternative ID (3342) by hashing the alternative creator token with the live stream hash and adding ALT at the end of the immutable digital credential alternative identifier (ID); create the alternative immutable digital credential hash (3349) by hashing the immutable digital credential alternative ID, the immutable digital credential metadata, the one or more alternative immutable digital credential cloud addresses, the one or more alternative immutable digital credential DFS addresses, the local symbiotic hash, and the live stream hash; record the immutable digital credential alternative ID, the immutable digital credential metadata, the one or more alternative immutable digital credential cloud addresses, the one or more alternative immutable digital credential DFS addresses, the live stream hash, the local symbiotic hash, and the alternative immutable digital credential hash to the immutable digital credential authentication blockchain (3343); record user permissions corresponding to the immutable digital credential alternative ID on the authentication blockchain (3344) and send (39600) the user permissions to an immutable digital credential orchestrator (1210) to update a log entry of the immutable digital credential orchestrator (1210); and record the alternative immutable digital credential ID and the alternative immutable digital credential hash on the public blockchain (3345, 39700).

21. The system of any one of claims 18-20, wherein, The immutable digital credential orchestrator (1210) is configured to: receive user view permissions for the immutable digital credential corresponding to the immutable digital credential alternative ID (39600); and create a local ledger of permission details based on the user permissions.

22. The system of any of claims 14 to 21, further comprising: a requestor device (1100-2) configured to: authenticate a third-party immutable digital credential requestor; initiate a third-party request (4110) from an immutable digital credential creator, the third-party request being any one or more of: an immutable digital credential request (2210) requesting creation and sharing of a new immutable digital credential, an immutable digital credential view request (2220) requesting permission to view an existing immutable digital credential of the creator, or an immutable digital credential share request (2230) requesting permission to share an existing immutable digital credential of the creator with another immutable digital credential network user; create the third-party request (4120) by combining any one or a combination of: a third-party immutable digital credential requestor ID; a phone number of the immutable digital creator; and an immutable digital credential ID; and send the third-party request to an immutable digital credential orchestrator (49100). ​

Images