Systems and methods involving aspects of media authentication, media management, verifying and / or validating user presence and / or other features

Abstract

Systems and methods associated with media authentication are disclosed. In one illustrative implementation, an exemplary method may comprise performing validation processing regarding a media capturing device, such as validation processing involving a key pair based on a device validation operation, generating a signed hash associated with data of a captured media file, associating the signed hash with the key pair, and transmitting the signed hash and the captured media file to an offline storage component for storage. In certain embodiments, exemplary methods may relate to topics such as cryptographic chains of trust, real user presence, device integrity, capturing media files, and / or managing media files.

Description

Systems and Methods Involving Aspects of Media Authentication, Media Management, Verifying and / or Validating User Presence and / or Other FeaturesCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is an Patent Cooperation Treaty (PCT) International Patent Application claiming benefit of and priority to U.S. provisional patent application No. 63 / 719,623, filed on November 12, 2024, and U.S. provisional application No. 63 / 847,431, filed on July 20, 2025, which are incorporated herein by reference in their entirety.BACKGROUNDField:

[0002] The present disclosure generally relates to media authentication. More specifically, the disclosed technology relates to and / or involves cryptographic chain(s) of trust for media capture.Description of Related Information and Drawbacks of Existing Solutions:

[0003] The task of authenticating a captured media file has useful applications in digital safety, deepfake detection, and the sharing of digital information. However, there is a need to improve the efficiency and security of media authentication systems, e.g., by overcoming various drawbacks such as those associated with overreliance on third-party certificates, implementing existing security mechanisms exposed to a wide variety of attack vectors, and excessive processing and memory overhead.OVERVIEW OF CERTAIN IMPLEMENTATIONS

[0004] The present disclosure generally relates to media authentication. More specifically, techniques are disclosed for establishing a cryptographic chain of trust for media capture. Various embodiments are described herein, including methods, systems, non-transitory computer-readable media storing programs, code, or instructions executable by one or more processors, and the like.

[0005] In certain embodiments, techniques are provided including a method that includes performing, by one or more processors, validation processing regarding at least one media capturing device, the validation processing involving a key pair, wherein the key pair is based at least in part on a device validation operation; generating, by the one or more processors, a signed hash associated with data of a captured media file; associating, by the one or more processors, the signed hash with the key pair; and transmitting, by the one or more processors, the signed hash and the captured media file to an offline storage component for storage.

[0006] Certain embodiments described in the present disclosure may be implemented to present one or more of the following technical solutions. Among other advantages, for example, establishing a cryptographic chain of trust consistent with the disclosed technology, e.g., before and at the time a media file is captured, etc., provides proof of device integrity before generation or post-capture processing of the media file. In some embodiments, a captured media file may be traced so as to indicate proof of a real user and trust in the underlying capture process.

[0007] In accordance with some embodiments, a computer system is provided that includes one or more processors and a non-transitory computer readable medium containing instructions which, when executed on the one or more processors, cause the one or more processors to perform all or part of the one or more methods disclosed herein.

[0008] In accordance with some embodiments, a computer-program product is provided that is tangibly embodied in a non-transitory machine-readable medium and that includes instructions configured to cause one or more processors to perform all or part of the one or more methods disclosed herein.

[0009] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only. Several example implementations are provided with reference to the following figures, as described below in more detail. However, further features and / or variations may be provided in addition to those set forth herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Additional understanding of the various features, embodiments and advantages of the present disclosure may be derived by referring to the description when considered in conjunction with the figures. In the figures, like reference numbers refer to like elements or acts.

[0011] FIG. 1 is a simplified flow diagram illustrating an example method for validating and configuring a media capturing device for secure media authentication, according to certain embodiments.

[0012] FIG. 2 is a simplified block diagram illustrating an architecture for a media capturing system configured for secure media authentication, according to certain embodiments.

[0013] FIG. 3 is a simplified block diagram illustrating an example method for the secure authentication and storage of a captured media file 340, according to certain embodiments.

[0014] FIG. 4 is a flow chart illustrating an example process for validating a media capturing device for secure media authentication, including validating a user’s physical presence, validatingdevice integrity and preparing a media capturing device for secure signing of captured media, according to certain embodiments.

[0015] FIG. 5 is a flowchart illustrating an example method related to media claiming, according to certain embodiments.

[0016] FIGS. 6A, 6B, 6C, and 6D illustrate example displays related to configuring a media capturing device for secure media authentication, according to certain embodiments.

[0017] FIGS. 7A, 7B, and 7C illustrate example displays related to the secure capture of media files, according to certain embodiments.

[0018] FIGS. 8A, 8B, 8C, 8D, and 8E illustrate example displays related to the curation and management of media files captured using a media authentication computer application, according to certain embodiments.

[0019] FIGS. 9A, 9B, and 9C illustrate example displays related to the authentication and claiming of captured media files, according to certain embodiments.

[0020] FIG. 10 illustrates an example display interface related to the claiming of captured media files, according to certain embodiments.

[0021] FIG. 11 is a block diagram illustrating an example computer system, according to at least one embodiment.

[0022] Elements and acts in the figures are illustrated for simplicity, may not be to scale, and have not been rendered according to any particular embodiment or example and arenot to depict any essential or required limitations.DETAILED DESCRIPTION OF ILLUSTRATIVE IMPLEMENTATIONS

[0023] In the following description, for purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments. It will be understood, however, by those skilled in the relevant arts, that the various embodiments may be practiced without these specific details. In other instances, known structures and devices are shown or discussed more generally so as to not unnecessarily obscure aspects of the embodiments.

[0024] Furthermore, in many cases, a description of the operation is sufficient to enable one to implement the various forms of the disclosed embodiments, particularly when the operation is to be implemented in software. It should be noted that there are many different and alternative configurations, devices and technologies to which the disclosed embodiments may be applied. The full scope of the innovations herein are not limited to the examples that are described below.

[0025] The present disclosure generally relates to media authentication. More specifically, but not by way of limitation, the present disclosure improves security in the media-authentication process by establishing a cryptographic chain of trust before media is ever captured. According to certain embodiments, during an onboarding process, a media authentication application may use a biometric validation process to confirm that a real user is physically present on the device before a secure enclave generates a hardware-bound private key. The secure enclave may then store that hardware-bound private key and use it to sign media hashes at capture time, thereby preventing key extraction or tampering. When a media file is later uploaded to a server, the server may match the signed hash to the file, proving that the media was created on a trusted device and has not been modified. Tying key creation to biometric proof of a real user reduces the potential attack surface of a media authentication system and provides a hardware-anchored, tamper-resistant method for authenticating media.

[0026] In certain embodiments, one or more techniques are described for verifying proof of user presence, configuring a system for secure media authentication, and / or other related aspects. By way of nonlimiting example, some aspects may combine hardware attestation, storing private keys in the device’s secure enclave, one or more push notification operations, and / or one or more biometric validation process to significantly enhance the trustworthiness and reliability of captured media in various media capture and management applications. Various implementations may involve a process that begins with a user-initiated request for media authentication during onboarding, wherein the media authentication computer application prompts the user for biometric validation. Biometric validation may involve techniques such as fingerprint scanning, facial recognition, or any other technique designed to securely verify the user's identity. Upon successful validation of biometric data, the device may generate a public / private key pair within the device’s secure enclave, an area of the hardware that protects sensitive information from unauthorized access. If the biometric data validation is successful, according to certain embodiments, the secure enclave generates and signs an attestation challenge, the attestation results are validated, and the public key and additional meta data are transmitted back to the server. The attestation challenge may encompass critical metadata and security parameters, which are securely stored within the server’s database alongside the relevant client information.In cases of unsuccessful validation of biometric data, the server may flag the originating device and any related media, signaling to a backend validation platform that the device may be compromised and cannot be trusted, thereby protecting the integrity of the authentication system. Once thechallenge and other related data is received, the server may send a push notification to the user's mobile device, alerting them to engage with the authentication request. Upon receiving the push notification, the application may display details about the ongoing authentication process, prompting the user to confirm their engagement. The device may sign the message with the stored private key and may send the result for verification to the server. Upon the successful verification, according to certain embodiments, the device is ready to sign any media captured within the context of the app and the server is ready to authenticate the uploaded media. The server may send more notifications randomly later to probe the device’s integrity on an ongoing basis.

[0027] According to certain embodiments, a device binding mechanism establishes a secure link between the user's biometric data and a device profile stored in the server's database. In some embodiments, the device profile may be associated with an authorized user of the device. Such a binding process not only enhances user privacy but also facilitates seamless media upload and management. When the user captures images or videos, the application may interface directly with the device's camera functionality. The captured media may then processed within the secure enclave, where it may undergo hashing and cryptographic signing to ensure authenticity and integrity. The signed hashes may be uploaded to the server and linked to the device profile, creating a secure and verifiable record of the media capture event that may be referenced for future validation.

[0028] The present disclosure may also relate to an interactive user interface, designed to engage users throughout the authentication and media management processes. The interface presents a series of intuitive UI components that guide users through the necessary permissions for optimal app functionality. These components may include options for enabling biometric verification methods, such as facial recognition or fingerprint scanning, notification access for push communications, multimedia capture permissions for camera and microphone access, and location tagging options that enhance context for media submissions. This structured permission request process ensures that users are informed of the necessary actions required for the app to function effectively.

[0029] According to certain embodiments, within the media management aspect, the interface may allow users to review and curate their captured media effortlessly. Users may be presented with a thumbnail grid of their images and videos, where they can easily select items for further processing. The application may provide filters to help users identify unwanted media and enable them to approve only the content they wish to publish. Once users confirm their selections, theapplication may upload the approved files to the server, where the uploaded media may be bound to the previously stored signed hashes. In certain embodiments, this binding process ensures that only verified and authenticated media is published, whether to a public or private cloud service.

[0030] According to certain embodiments, the present disclosure may involve media management features which may further include a sophisticated review system, thereby allowing users to manage their media effectively. For instance, users may initiate a curation process through an easily accessible interface, reviewing their media within a central area that highlights the most relevant content. Users may preview captured videos and access additional media through thumbnail previews, facilitating comparison and selection. Action buttons for keeping or discarding content marked with intuitive icons, e.g., such as hearts for retention and trash cans for deletionmay further streamline the decision-making process.

[0031] According to certain embodiments, in terms of user engagement and security, the interface may provide options for media claims. After the authentication process is completed, for example, users may be presented with distinct claim options according to various implementations herein, such as, though not limited to: Direct Claim, which may securely associate media with the user's account; Delegated Claim, which, by either using a QR code or a signed link may allow a third party to publish the media while the user remains anonymous; and No Claim, which may enable public sharing while maintaining user anonymity. In such embodiments, this flexibility empowers users to control how their media is used and shared while reinforcing trust in the authenticity of the content.

[0032] Various terminology used herein should be understood in the context of the embodiments to which it pertains. For example, the term validation, in certain implementations, relates to processes for confirming hardware is trusted or biometrics checks to ensure the presence of a real user. Additionally, the term verification, in certain implementation, relates to checking a message or response was transmitted from an expected source. Further, in certain exemplary implementations, push-notifications may be considered verified if a push notification response indicates the push notification was signed by a matching hardware-bound private key. Finally, the term authentication, in certain implementations, relates to proving a photograph or video originated from a trusted device and was neither modified after capture nor artificially created.

[0033] Turning to the drawings, FIG. 1 is a simplified flow diagram illustrating an example method for validating and configuring a media capturing device for secure media authentication, according to certain embodiments. Steps described in FIG. 1 help ensure a device is trusted beforemedia capture, thereby enhancing the security of the media-authentication process. Trusting a device may include, but is not limited to, validating the presence of a real device user (i.e., a natural person as opposed to an automated bot or computer script), validating the integrity of the media capturing device, and configuring the media capturing device to securely sign captured media.

[0034] Validation processing may begin with an onboarding process 110. In certain embodiments, the onboarding process 110 may involve prompting a user of the media capturing device to complete a biometric validation process 113. The biometric validation process 113 may identify if the user of the media capturing device is a real device user (i.e., a natural person) that is physically using the media capturing device.

[0035] A secure enclave of the media capturing device may generate a key pair 112, comprising a public key and a private key. The key pair 112 may be stored in the secure enclave to prevent key extraction or tampering. If the biometric validation process 113 successfully identifies the user as a real device user, the secure enclave generates and signs a hardware attestation challenge 114 using the private key, the attestation results 116 are validated, and the public key and additional meta data are transmitted to a backend service 130. The backend service 130 (e.g., a physical server, a cloudbased server, a second service on the media capturing device, etc.) may include a database to securely store the public key and additional metadata, the metadata comprising the attestation results 116. The backend service 130 may perform an attestation check 134 (“first validation check”) using the attestation results 116 from the hardware attestation challenge 114 and the public key that were uploaded to the backend service 130. The backend service 130 may communicate with an attestation service 132 to process the first validation check 134.

[0036] The backend service 130 may perform a second validation check 150 based on a push notification 140 to increase confidence in both the physical presence of a real device user and the integrity of the media capturing device. The backend service 130 sends a push notification 140 with a specific payload to the media capturing device. The push notification may require a user interaction (e.g., a button press, authentication slider, etc.) to prove physical presence. The secure enclave of the media capturing device may sign the message of the push notification 140 using the private key of the key pair 112 that was previously generated and stored in the secure enclave. The signed message is uploaded to the backend service 130 for verification. The second validation check 150 is successful if the signed message associated with the private key can be verified with the public key previously stored on the backend service 130.

[0037] Upon the successful verification, the media capturing device is properly configured to sign captured media (138) and the backend service 130 is ready to authenticate uploaded media. After the media capturing device is configured, the backend service 130 may send additional push notifications at random intervals in order to probe the media capturing device’s integrity on an ongoing basis.

[0038] If the second validation check 150 fails, however, the backend service 130 marks the private / private key pair as invalid (152) and flags the media capturing device and future media originating from the media capturing device as unreliable. An unsuccessful first validation check 134 or second validation check 150 indicates that the media capturing device may be compromised and cannot be trusted for secure capture and authentication of media files. Thus, identification of media captured on a compromised media capturing device protects the integrity of the authentication system.

[0039] FIG. 2 is a simplified block diagram illustrating an architecture for a media capturing system 200 configured for secure media authentication, according to certain embodiments. The media capturing system 200 includes a media capturing component 210, a computer application 232, and a server 260. In some embodiments, the media capturing system may further include a secure enclave 212, a cloud-based attestation service 272, and a cloud-based push notification service 274.

[0040] In certain embodiments, the computer application 232 is used to control and interface directly with the media capturing component 210. In some embodiments, the media capturing component 210 may be used, either individually or in tandem with biometric sensors, to validate the identity of or confirm the physical presence of a real user of the computer application 232.

[0041] In some embodiments, the media capturing system 200 may be configured to execute various computer instructions and operations designed to enhance secure media authentication. The computer application 232 requests the generation (223) of a key pair including a public key and a private key within the secure enclave 212. The secure enclave 212 then generates and signs (224) a device attestation challenge using the generated private key.

[0042] In certain embodiments, the media capturing system 200 may include a biometric validation operation. In such instances, the computer application 232 may prompt or otherwise request (221) the user to provide biometrics. The user may respond to the prompt 221 by providing (222) their biometric data, e.g., such as scanning by their fingerprint, facial characteristics, vocal pattern, or any other of their unique biological and / or behavioral characteristics that may helpidentify them. In certain embodiments, biometric data may be processed and validated in the secure enclave 212. If the biometric validation is successful, the secure enclave 212 may communicate this success to the computer application 232. In some embodiments, the computer application 232 may be configured to require a successful biometric validation operation for the secure enclave 212 to generate and sign (224) the device attestation challenge. In some embodiments where biometric data collection is not available, a media capturing device may be configured to interface with a two-factor authentication operation.

[0043] The attestation results and the public key are uploaded (226) to the server 260. The attestation results then may be linked to the public key on the server 260. Validation (225) of the attestation results on the server 260 is handled by the cloud-based attestation service 272. In some embodiments, the cloud-based attestation service 272 is validates (223) attestation results based on a hardware-bound key identifying a device executing computer application 232. The hardwarebound key may be stored in a trusted execution environment, e.g., such as the secure enclave 212.

[0044] The server 260 securely stores the public key in a server database 262. In some embodiments, the server database 262 also securely stores metadata associated with the device attestation challenge, security parameters, and other client-side information uploaded from the app 232 to the server relevant for identifying, validating, and / or verifying a media capturing device. The upload of the other relevant client-side information may occur with the upload (226) of the public key to the server 260. In some embodiments that include a biometric validation operation, uploaded information may include biometric data collected (232) or results from processing that biometric data. The media capturing system 200 may use all or a portion of the stored information to establish (227) one or more stored profiles which are stored in the server database 262. By way of example, a stored profile may be configured as a device profile for uniquely identifying a media capturing device and, in some embodiments, associating a captured media file with a specific user or device while protecting the originating capture user’s (i.e., the user who captured the media file) anonymity.

[0045] In some embodiments, the cloud-based push notification service 272 provides a secondary verification process 228 for verifying device integrity by providing proof of real user presence. For the secondary verification process 228, the push notification service 272 transmits a push notification 229 to the device of the computer application 232. A push notification prompt (“PN Prompt”) 235 is displayed by the device. The PN Prompt 235 may require interaction from by a real user through a swipe confirmation, a voice command, screen tap, etc. and is signed using theprivate key. The resulting signed message from signing PN Prompt 235 is pushed back to the server 260 where it is then verified (230) against the public key stored in the server database 262.

[0046] Once the devices in the media capturing system are validated and verified, the computer application 232 enables (233) camera functionality of the media capturing component 210. All related data (e.g., device data, attestation results, etc.) is saved and securely linked to the device profile, thereby establishing a cryptographic chain of trust before media files are ever captured.

[0047] FIG. 3 is a simplified block diagram illustrating an example method for the secure authentication and storage of a captured media file 340, according to certain embodiments. When a camera button 331 is pressed, a computer application 330 controls a media capturing component 310 to initiate the capture (310) of a photograph or a video. During this process, light 333 passes through the media capturing component 310, and the camera subsystem 344 converts the light into image binary data.

[0048] In certain embodiments, a media authentication system including computer application 330 may be configured to perform a biometric validation operation 381 to provide a proof of real user presence for the captured media file 340. The computer application 330 may be optionally configured to adjust the frequency in which a user is required to complete a biometric validation operation 381. In some embodiments, by way of example, requiring a biometric validation operation for every media file that the user captures may weigh more heavily in favor of proof of the physical presence of a real user, thereby increasing the security of the media authentication system. However, in other embodiments, requiring a biometric validation operation for some captured media files, but not all, may increase ease of use of the computer application 330 while still providing periodic proof of physical presence. By way of example, in some embodiments, a media authentication system using one or more other layers of validation and verification methods (e.g., push notifications, two-factor authentication, digital watermarking, post-capture analysis of media files, etc.) for each captured media file may only require a user to complete a biometric validation operation at random periodic intervals, e.g., such as, requiring a biometric validation operation based on a threshold of captured media files where validation is required a random captured media file in every twenty to fifty media files captured by the user. In some related embodiments, the threshold for when a biometric validation operation is required may be dynamically adjusted by the media authentication system based on how recently the user has captured a media file.

[0049] Once the photograph or video is captured, the binary data is sent to the device's secure enclave 312 for processing. The secure enclave hashes (334) and cryptographically signs (335) the binary data, ensuring its integrity and authenticity. The signed hash is then securely stored (336) within the device's offline storage 314, maintaining a link to the original photograph or video data. The captured media file 340 is also stored (336) in the device's offline storage 314, allowing for local access to the captured media file 340. In the background, the signed hashes are uploaded (301) to the server and linked with the device profile that was previously established during validation processing of the device. A server 360 stores the uploaded information in a server database 362, creating a secure and verifiable record of the image or video capture event.

[0050] In some embodiments, a captured media file 340 is reviewed through a curation process 338 on the computer application 330. The curation process 338 allows a user to review one or more captured media files 340 stored in the device’s offline storage 314 and select which of the captured media files 340 to approve for further processing. Unwanted or irrelevant media files are filtered out during the curation process 338 but may remain stored in the device’s offline storage 314. Curated media files 344 that are approved by the user are uploaded (339) to the server 360. The server 360 then binds (302) the uploaded curated media files 344 with the previously stored signed hashes, which were generated and uploaded (301) during the initial capture process. After the server 360 verifies the integrity of the uploaded media file and confirms the binding (302) with the signed hashes, the uploaded media file is approved and securely stored the server's database 362. In certain embodiments, the verified media files, along with proof of authenticity, are published to either a public or private cloud service. The proof of authenticity includes a public key used to sign the hashed binary strings, ensuring that the media can be verified as genuine and untampered.

[0051] FIG. 4 is a flow chart illustrating an example process for validating a media capturing device for secure media authentication, including validating a user’s physical presence, validating device integrity and preparing a media capturing device for secure signing of captured media, according to certain embodiments. After installation of a computer application at step 401, the device generates a hardware-bound key pair comprising public key and private key in the device’s secure enclave at step 402. At step 403, a unique string associated with device attestation is generated and signed using the hardware-bound private key in the secure enclave. At step 404, the device performs the device attestation to create a device attestation statement. In some embodiments, relevant data including the device attestation statement and the hardware-bound private key are securely stored within the secure enclave.

[0052] At steps 405 and 406, the attestation data is sent to the server and in turn to a cloudbased attention service. The cloud-based attestation service may be provided by a hardware provider or the hardware device manufacturer to verify the attestation data against the public key. In the next step, the public key is uploaded to the server and linked to the attestation challenge results which confirms the device’s integrity and creates a profile tied to that device. In steps 408, a push notification is sent to the user’s device to verify the presence of a real user. The user is required to interact with the message, at which point (step 409) the message is signed using the private key and the resulting signed message is pushed back to the server. All related data is saved and linked to the device profile and the device’s camera enabled.

[0053] In some embodiments, as illustrated in step 410, the verification process of steps 408 and 409 can fail. In such instances, the device key is purged from the device and marked as invalid on the server. Media originating from an invalid device is considered unreliable.

[0054] FIG. 5 is a flowchart illustrating an example method for media claiming, according to certain embodiments. At step 501, a computer application receives one or more instructions for claiming previously uploaded media files on a server database. Referring to FIG. 3, in some embodiments, prior to step 501, captured media files may be authenticated on, uploaded to, and stored on a server. As a result of the verifiable record created during the media authentication process in FIG. 3, each captured media file that is stored in a server database corresponds to a public key and a media cryptographic hash also stored in the server database.

[0055] In some embodiments, at step 501, the media claiming process starts with the user pressing a claim button displayed on a device of the computer application. The claim button may become available after the media has been uploaded and authenticated by the server.

[0056] The computer application then presents one or more claim options 502, which may include any combination of a Direct Claim option 503, a Delegated Claim option 504, and an Anonymous Contribution option 505.

[0057] The Direct Claim option 503 relates to claiming captured media files captured on an originating media capturing device. At step 506, if the Direct Claim option 503 is selected, a data payload, comprising a media cryptographic hash and a public key, is posted to the server. In some embodiments, the cryptographic hash is a SHA-256 hash. At step 509, the device is then redirected to a web page containing a sign up or a log in form. At step 512, the media is associated with a user account of a media capturing device which originally captured the media files. In someembodiments, at step 512, each media file captured by the originating media capturing device may be selectively claimed by the user account during the curation process.

[0058] The Delegated Claim option 504 relates to a captured media file claimed by a delegated third-party while maintaining the anonymity of the originating user. At step 507, if the Delegated claim option 504 is selected, a QR code, a shareable web link, or a combination of a QR code and a shareable web link is generated by the computer application. Both the QR code and the web link redirect to a form which allows a third party to log into or sign up for a user account. At step 510, the media then is linked to the third party’s user account, allowing the third-party user account to distribute the claimed media file without compromising the anonymity of the originating capturer’s identity. However, because the server stores a hash which connects the originating user’s device with the media file, the originating user can retain a proof of ownership. As such, the originating user account can revoke the access permission of the third-party user account for the media file. At step 511, a data payload, comprising a media cryptographic hash and a public key of the third-party user account is posted to the server. At step 512, the media cryptographic hash and the third-party’s public key are associated and recorded on the server.

[0059] The Anonymous Contribution option 505 (also referred to as a No Claim option) is suitable for whistleblowers or originating users located in conflict zones. At step 508, if the Anonymous Contribution option 505 is selected, a originating user account may grant an access permission of their captured media file to any third-party user account without publicly attributing the captured media file with the originating user. However, because the server stores a hash which connects the originating user’s device with the media file, the originating user can retain a proof of ownership. As such, the originating user account can revoke the access permission granted for the media file. In some embodiments, Anonymous Contribution option 505 does not require posting or storing the public key of any user account to the server.Description of Example Displays

[0060] Display and user interfaces discussed in some embodiments of the present disclosure are presented in the context of a secure media authentication application on a mobile device, although it is understood that displays, devices, systems, and features discussed herein are not necessarily limited to the form or function of a mobile device. Furthermore, for purposes of explanation and clarity, but not by way of limitation, example displays of FIGS. 6A through 6D are presented in the context of configuring a secure media authentication application (“app”) prior to enabling media capture on a media capturing device and example displays of FIGS. 7A through 10 are presented inthe context of capturing and handling one or more captured media files using the app. It should be understood that the logical flows depicted in the example displays do not require the particular order shown.

[0061] FIGS. 6A, 6B, 6C, and 6D illustrate example displays related to configuring a media capturing device for secure media authentication, according to certain embodiments. Displays 610, 620, 640, and 660 of FIG. 6A through FIG. 6D are presented on a mobile device 600. According to some embodiments, the app only presents displays 610, 620, 640, and 660 to a user during the initial onboarding process of the app on mobile device 600.

[0062] The display 610 of FIG. 6A is an example user interface which notifies a real user of the benefits of the app (i.e., the secure media authentication application). Display 610 includes one or more benefits patterns to a user upon first launching the secure media authentication application, including: a deepfake pattern 612, a ‘double check’ pattern 614, and a ‘let the world know’ pattern 616. The app may transition to display 620 of FIG. 6B upon user interaction with icon 611.

[0063] The display 620 of FIG. 6B is an example user interface which facilitates the onboarding process for a real user by showing permissions required for app functionality. The display 620 encompasses four primary UI patterns associated with enabling permissions on mobile device 600. First, a biometric pattern 622 is related to a biometric permission for allowing use of biometric verification methods (e.g., facial authentication, such fingerprint scanning, etc.). Second, a push notification pattern 624 is related to a push notification permission for allowing use of push notifications, which help confirm media capture is being utilized on a physical device. Third, a media capture pattern 626 is related to a media capture permission for enabling the use of one or more media capturing components, including a camera, microphone, etc. of mobile device 600. Functionality related to and described by media capture pattern 626 supports the app's function for media-based interactions, ensuring a real user can capture media files. Fourth, a location pattern 628 is related to a location permission for allowing the use of geolocation services for geotagging a capture media file. Permissions and device operations related to the biometric pattern 622, the push notification pattern 624, the media capture pattern 626, and the location pattern 628 can harden proof of a real user, proof of presence, proof of device integrity, and proof of ownership in the media authentication process. According to some embodiments, one or more of the four patterns and related functionality are optional in a media authentication application. A user of the media authentication application in those embodiments may selectively enable or disable certain app functions by interacting with (e.g., clicking, tapping, holding etc.) the respective pattern. In someembodiments, mobile device 600 may send the user an error message instead of allowing use of the camera of mobile device 600 if one or more of the permissions associated with patterns 622, 624, 626, and 628 is not granted.

[0064] The display 620 may further comprise a permissions explanations pattern 629 and permissions confirmation icon 621. The permissions confirmation icon 621 requires a user to confirm their understanding of permissions and functionality related to the app in order to proceed. In certain embodiments, upon registering a user interaction with the permissions confirmation icon 621, the app requests from mobile device 600 each of the permissions related to the each of the permissions related to with the biometric pattern 622, the push notification pattern 624, the media capture pattern 626, and / or the location pattern 628. The app may alternatively directly transition to display 640 of FIG. 6C upon registering a user interaction with the permissions confirmation icon 621.

[0065] The display 640 of FIG. 6C is an example user interface for configuring the secure media authentication application of FIGS. 6A through 6D. A live background 641 shows a real-time camera feed from mobile device 600. The live background 641 is subtly blurred and overlaid with a uniform pattern of dots. Positioned in the center of display 640 is an interactive authentication slider 642. Beneath the interactive authentication slider 642 is an authentication text box 644 titled "Authentication Slider" which provides context about the usage of interactive authentication slider 642. In some embodiments, the display 640 is linked to a permission mechanism, structured to facilitate a comprehensive permission request process such as a face or fingerprint verification related to the biometric pattern 622 in FIG. 6B. A user interaction with ‘Got It’ button 646 dismisses the authentication text box 644, hiding the authentication text box 644 from view. In some embodiments, the interactive authentication slider 642 may be replaced with a button, a check box, or any other interactive interface element that can provide proof of a real user or proof of presence. The app may transition to display 660 of FIG. 6D upon registering a user interaction with the interaction authentication slider 642.

[0066] The display 660 of FIG. 6D is an example user interface for collecting biometric information from a real user to confirm a real user’s physical presence. Display 660 includes a centrally positioned biometric pattern overlay 662 to show the status of biometric authentication. The app’s biometric recognition system activates when a real user places a unique biometrically identifiable feature (e.g., their finger, face, retina, etc.) in range of a biometric sensor of mobile device 600. The biometric recognition system then scans the user’s biometric information andcompares it against stored biometric data to confirm the user's identity. The biometric pattern overlay 662 changes shape to indicate acceptance of the user’s biometric information. In some embodiments, the biometric pattern overlay 662 may change into different shapes depending on whether a match between the user’s biometric information and the stored biometric data is found. In some embodiments, the app may capture and record a snapshot of the real-time camera feed opposite of the user to harden proof of presence. The media authentication system may be configured based on the user’s biometric information and the user may proceed to the next step. In some embodiments, media capture functionality of device 600 may be enabled after the user configures the mobile device 600 according to functionality in the displays of FIGS. 6A to 6D.

[0067] FIGS. 7A, 7B, and 7C represent example displays related to the secure capture of media files, according to certain embodiments. The display 702 includes a real-time camera feed from a mobile device 700 overlaid by an app interface designed to enable the user to capture photographs and video while enhancing the user’s engagement by integrating location tagging and photo management features. Positioned at the bottom of the interface are of display 702 includes a photo capturing pattern 712 and a video capturing pattern 714. Tapping on either pattern 712 or 714 causes the respective pattern to move to a center position of the selection interface, thus allowing the user to easily toggle between them by simply tapping the interface. Patterns 712 and 714 may change shape to indicate they are toggled and change color when actively capturing media from the real-time camera feed. For example, but not by way of limitation, the video capturing pattern 714 may appear as a green circular button 713 at the bottom center of the interface when the video is toggled and the camera is recording video feed. The green colorization of the recording button in this case helps notify a user that the recording is ready to start. Adjacent to the video capturing pattern 712, the photo capturing pattern 716 provides quick access for users to take still photographs. A camera direction pattern 716 allows users to toggle between different camera orientations (e g., front or back-facing camera) by utilizing intuitive gestures or interface buttons. As users change the camera direction, a live preview of the camera feed is displayed in the background of display 702.

[0068] Positioned at the top of the interface, a location pattern 740 allows a user to toggle the location settings on or off. The location pattern 740 can be in different colors while on and off. For example, when the location setting is on, the interactive location pattern 740 might display a green placemark icon, and a white icon might be shown when this pattern is off. In some embodiments,the interactive location pattern 740 may be hidden from view when the app does not have a location permission.

[0069] Below the location pattern is the session photos management pattern 720, which informs users about curating their media files captured during a session. Users are prompted to organize and select media files before saving them to their gallery. In some embodiments, the media files may be organized in a queue either based on their time of capture or the upload status of each media file. Pattern 720 may display the media files in an order based on those queuing parameters.

[0070] FIG 7A and FIG. 7B further illustrate various text boxes which inform users of the features users can toggle to enable for media authentication and / or the functionality of interactive patterns on the screen. For example, a location text box 742 corresponding to the location pattern 740 might inform users of geotagging functionality to promote “credibility.” A gallery text box 734 corresponding to a media review pattern 730 informs users of the existence of a media review gallery for quickly accessing stored media files that they captured. Users can hide a text box from view by interacting with a ‘Got It’ button 744 / 734 overlaid on the respective text box.

[0071] FIGS. 8A, 8B, 8C, 8D, and 8E represent example displays related to the curation and management of media files captured using a media authentication computer application, according to certain embodiments. The display 804 of FIG. 8A is an example user interface used in a media authentication computer application (“app”) for curating one or more media files that are part of a current media capturing session. A captured media file may be considered part of a current media capturing session before the user elects to either: (1) keep the media, thereby transferring the media to be stored on a mobile device 800 or (2) discard the media, saving only the signed hash associated with the captured media but not the capture media itself. A user may elect to keep the currently previewed media by interacting with a “Keep” pattern 808 or discard the media by interacting with a “Discard” pattern 806. In some embodiments, the “Keep” pattern 808 and “Discard” pattern are positioned near the top of display 804. If the currently previewed media is a video, a user may watch the video by interacting with a playback pattern 805 that is positioned centrally relative to the media file. At the bottom of the screen the user is presented with a thumbnail interface 802, allowing the user to scroll through the media captured during the current session. In certain embodiments, the media files may be ordered in the thumbnail interface 802 using a queue based on the timestamp of each captured media file.

[0072] The display of FIGS. 8B, 8C, and 8D is an example user interface used in viewing and managing a user’s captured media files in a media gallery (a gallery of pictures and videos capturedusing the application). A media file captured by a user on the mobile device 800 may become available in the media gallery after the captured media file is curated in a curation session. Once captured media files are curated, a media gallery may contain one or more media files, e.g., curated media files 820 and 830, which may be presented in a scrolling list of media. In some embodiments, interacting with a display mode pattern 850 allows a user to toggle the media gallery’s display mode between a scrolling list of media files (displayed as arrangements of 1x2, 2x1, 3x1, etc.) and a grid of media files (displayed as arrangements of 2x2, 2x3, etc.).

[0073] To enhance content management, users can utilize filtering options to organize the media gallery after interacting with the gallery filter pattern 660 located at the bottom of the interface. When interacted with, a gallery filter pattern 860 may present a popup with one or more options for filtering media files in the media gallery: an “All Media” filter 864, a “Local” media filter 866, and an “Uploaded” media filter 868. These options allow users to easily toggle between viewing modes. The "All Media" filter 864 allows users to view every media file captured during their previous capture sessions. The "Local" media filter 866 configures the app to display only captured media files stored on the device that have not yet been uploaded (i.e., not yet uploaded to a server, a cloud service, etc.), making it easier to manage local content. The "Uploaded" media filter 868 facilitates quick access to media that has been uploaded. To further enhance user experience, a filter description 862 is presented when the user interacts with the gallery filter pattern 660 for the first time. The filter description 862 may be dismissed and hidden via user interaction with button 863.

[0074] To enhance user experience, each media file 820, 830, etc. may be associated with either a detailed timestamp 821 or a simplified timestamp 831 that is overlaid the associated media file 820 or 830. In some embodiments, the precision displayed for a timestamp 821 or 831 may depend on the settings and configuration of the mobile device 800.

[0075] As further illustrated in FIGS. 8B and 8C, the app may present various descriptions, e.g., upload description 842 and / or gestures description 846, which notify users of additional app functionality. These various descriptions may be dismissed and hidden from view after user acknowledgment of the description’s information. In some embodiments, user acknowledgement may be indicated by user interaction with a corresponding buttons, e.g., 843 or 847.

[0076] As illustrated in the upload description 842, users may upload the curated media files 820 to a server, cloud service, etc. by interacting with an upload pattern 840 overlaid on the curated media file 820. In some embodiments, the app may be configured, via an option or a setting to:display a transparent upload pattern 832 instead of an opaque upload pattern 840 to enable clearer viewing of the underlying media file.

[0077] As illustrated in gestures description 846, a user may “swipe left” on a curated media file to access options for deleting and / or sharing the curated media file. For example, the user may “swipe left” on curated media file 820 to access deletion options illustrated in display 870 of FIG.8E. When a user interacts with delete pattern 874, the display 870 may present a deletion confirmation pattern 876 which includes a “Cancel” pattern and a “Delete” pattern enabling a user to delete the curated media file 820. In some embodiments, the display 870 may present a status notification 878 which indicates the present status of the curated media file 878 currently being previewed in the display 870.

[0078] In some embodiments, the sharing pattern 872 may change to a different color, such as green, to indicate that the media file 820 being previewed has already been uploaded to a server, cloud provider, etc. Alternatively, a gray-colored sharing pattern 872 may indicate the 820 has not yet been uploaded and thus allow initiate uploading of the file 820 and the related media authentication process. In some embodiments, the media authentication process when uploading the media file 820 is performed automatically to provide proof of device integrity, proof of media origin (i.e., the media file was captured on the device and / or using the app), and the physical presence of a real user who triggered the media capturing action.

[0079] FIGS. 9A, 9B, and 9C illustrate example displays related to the authentication and claiming of captured media files captured using a media authentication computer application, according to certain embodiments. In certain exemplary implementations such as shown here, the displays of FIGS 9A, 9B, and 9C may be provide features and functionality that are provided after or in the context of “swiping left” across the illustrative user interface of FIG. 8B, for example, though are not limited to just one such implementation. Referring to FIG. 8E, user interaction with a sharing pattern 872 may initiate a sharing process. As shown in FIG. 5, options for claiming a media file may enable a user to share the media file with others.

[0080] During the authenticated process for the previewed media file , a status notification may be presented at the top of the display. A user may interact with an icon pattern 912 overlaid on the status notification. As a result, the app may present a dropdown expansion that includes an authentication description 914 to facilitate user understanding of the media authentication process.

[0081] A claim pattern 922 may be overlaid on an updated status notification after the previewed media file is successfully authenticated. In some embodiments, the app may beconfigured to only present the claim pattern 922 after the authentication description 914 has been presented to and viewed by the user. A user may initiate a claim process for sharing the previewed media file by interacting with the claim pattern 922. In some embodiments, user interaction with the claim pattern 922 may present a claim explanation 924 and require user interaction with a claim confirmation pattern 925, thereby facilitating user understanding of the media claiming process.

[0082] FIG. 10 illustrates an example display files captured using a media authentication computer application, according to certain embodiments. A media authentication application (“app”) can display a claim selection interface 1010 for selecting media claim options once the media authentication process is completed. The claim selection interface 1010 is overlaid over a user interface for displaying a specific media file. In some embodiments, the claim selection interface 1010 may be displayed after a user initiates a claim process by first interacting with the claim pattern 922 in FIG. 9C.

[0083] Referring back to the method described in FIG. 5, a claim selection interface may include one or more patterns, each claim selection pattern associated with one or more claim options such as the direct claim option 503, the delegated claim option 504, and the no claim option (i.e., the anonymous contribution option) 505.

[0084] The example claim selection interface 1010 of FIG. 10 includes three claim selection patterns: (1) a direct claim selection pattern 1020 associated with the direct claim option, which allows users to associate the media with their account, ensuring that the media is securely linked to their profile; (2) a delegated claim selection pattern 1030 associated with the delegated claim option, which allows users to share a QR code and / or a sharing link with a third party while remaining anonymous; and (3) a ‘no claim’ selection pattern 1040 associated with a no claim option, which allows users to share their media with the world while maintaining anonymity. Each claim selection pattern 1020, 1030, and 1040 includes a title and a text description indicating how media will be processed. A media file under the overlaid claim selection interface 1010 is handled according to the specific claim selection pattern 1020, 1030, or 1040 selected by a user via a user interaction.

[0085] FIG. 11 is a block diagram illustrating an example computer system, according to at least one embodiment. The media capturing device 1100 shown in FIG. 11 includes one or more processors, memory, one or more media capturing components 1140, a secure enclave 1110, and a file storage 1124, and an operating system 1122.

[0086] In some embodiments, a computer application executed on the media capturing device 1100, may be implemented in software or firmware, or some combination thereof, or as instructions stored on a computer-readable medium executing on one or more processors 1101.

[0087] According to certain embodiments, machine-readable media may include any medium or mechanism, or combination of any medium and mechanism, for the transmission or storage of information in a machine-readable form. By way of nonlimiting example, a machine-readable media may include random access memory (RAM), read only memory (ROM),In some embodiments, memory of the media capturing device 1100 may include non-volatile storage 1120 and / or volatile memory 1160. By way of nonlimiting example, non-volatile storage 1120, in the context of non-volatile memory, may include one or more magnetic storage devices, flash memory devices, semiconductor storage media, optical storage media, or other non-volatile solid state storage devices.

[0088] In some embodiments, the media capturing device 1100 may include a camera image processor 1106. In some contexts, a camera image processor is also referred to as an image processor or an image processing engine. In some embodiments, the image processor is a specialized digital signal processor that may execute one or more computer instructions for processing raw visual data captured by one or more media capturing components or a sensors of a media capturing device.

[0089] In some embodiments, the media capturing device 1100 includes a network interface 1130 enabling the transmission of data, online communications, and / or virtual linking of one or more devices, based at least in part on one or more communication modes, e g., by way of nonlimiting example, 3G, 4G, 5G, WiFi™, Bluetooth™, 2.4 Ghz radio frequency, GSM™, CDMA, and any combination of one or more of these or similar communication modes.

[0090] In some embodiments, the media capturing component 210 includes one or more photographic cameras, one or more video cameras, and / or related devices that enable the capture of raw visual data, raw audio data, and the like.

[0091] In some embodiments, the media capturing device 1100 may include one or more electronic displays and / or touch sensors 1170 to enable viewing of user interfaces and user interaction related to a media authentication computer application. By way of nonlimiting example, electronic displays might relate to various technologies, such as include liquid-crystal displays, light-emitting diode displays, cathode ray displays, projection devices, touch screens, and other electronic displays that may convey textual, graphic, visual, and like information to a user. By wayof nonlimiting example, touch sensors may include one or more of various input devices, such as gesture recognition technology, capacitive touch sensors, resistive touch sensors, proximity sensors, eye tracking technology, and / or other input devices for enabling user interaction with a computer application.

[0092] In some embodiments, the media capturing device 1100 may include a local database 1128 and a file storage 1124. In some embodiments, a local database 1128 may isolate storage of files for each computer application. By way of nonlimiting example, a media authentication computer application may interface with a local database (e.g., SQLite, MongoDB™, and the like), for managing, store, and / or access structured data corresponding to the media authentication process. In some embodiments, the file storage 1124 may be used, for the offline storage and organization of media files on the media capturing device 1100. In some embodiments, the file storage 1124 may interface with a media authentication computer application to

[0093] In certain contexts, such as in the context of FIG. 11, the term “secure enclave” generally refers to a trusted execution environment (TEE) which provides hardware-based isolation of sensitive information, even if the primary system of a device is compromised. The secure enclave 1110 is an integrated digital circuit for processing sensitive information in isolation from the one or more central processing unit cores 1102, the memory, and other information storage or processing components of the media capturing device 1100. In certain implementations, the secure enclave 1110 may include processing capabilities and storage capabilities. The secure enclave 1110 includes a cryptography engine 1114, a device unique identifier 1116 (commonly implemented as a hardware-bound fused key), and storage capability for a private key 1118. By way of nonlimiting example, cryptography engine 1114, may be used to perform key generation, hashing, and / or authentication in relation to encryption, digital signatures, and / or any other cryptographic operations.

[0094] In some embodiments where biometric authentication, biometric validation, or other operations involving the processing of biometric data, the media capturing device 1100 may include a biometric sensor 1150, a biometric template 1113, and a biometric processing engine 1112. The biometric sensor 1150 collects biometric data for processing. By way of example, the biometric sensor 1150 may include technology for facial recognition, fingerprint scanning, iris and retina scanning, voice recognition, and any other suitable component or device used for identifying unique biological and / or behavioral characteristics of a human person. The biometric template 1113 is digital representation of biometric data associated with a human person, stored, in someembodiments, within the secure enclave 1110 of the media capturing device 1100. The biometric processing engine 1112 executing instructions in the secure enclave 1110 to extract biometric features and analyze biometric data.

[0095] In some embodiments, the media capturing device 1100 may include a password management system 1126, referred to a key chain and / or keyring, among other names, in some contexts, for the management, storage, and retrieval of passwords, passcodes, encryption keys, certificate keys, SSH accounts, and related types of sensitive data.

[0096] In embodiments where geolocation is used, the media capturing device 1100 may include one or more GNSS receivers 1172. By way of example, the one or more GNSS receivers 1172 may include a GLONASS receiver, a GPS sensor, or any other component for enabling precise global positioning. The media capturing device 1100 may include a clock and / or timing element 1174 for tracking time when the media capturing device 1100 is offline.

[0097] In some embodiments, the media capturing device 1100 may include one or more other sensors and / or input components 1178. By way of example, the one or more sensors and / or input components 1178 may include some accelerometers, gyroscopes, magnetometers, barometers, proximity sensors, physical buttons, additional microphones, or any other sensors and / or input component commonly used in devices for media capture, e.g., for purpose of nonlimiting example, a mobile phone, a webcam, a videorecorder, a camera, a camcorder, or music player.

[0098] In some embodiments, a media capturing device may include a plurality of hardware devices, each comprising a portion of the required hardware components, sensors, storage devices, or other required components in an implementation of the media capturing device 1100.Components in this context may be physically interfaced, electronically interfaced, and / or virtually linked via the network interface 1130.

[0099] The systems and methods disclosed herein may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine readable storage medium or element, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[0100] Unless the context clearly requires otherwise, throughout the description, the words "comprise," "comprising," “including,” and the like are to be construed in an inclusive sense as opposed to an exclusive or an exhaustive sense, i.e., these terms are to be construed in a sense of "including, but not limited to." Additionally, the words "herein," "hereunder," "above," "below," and words of similar import refer to this application as a whole and not to any particular portions of this application. Use of "or" or “and / or” that are used in reference to a list of two or more items are to be construed to covers all of the following interpretations: any of the items in the list, all of the items in the list and any combination of the items in the list.

[0101] In the foregoing description, numerous examples and details are set forth to provide a clear understanding of various aspects of various inventions together with a written description of the subject matter and to enable a person of ordinary skill in this field to make and use the same. It will also be understood, by those skilled in the relevant arts, that the present inventions may be practiced with or without various alternatives, modifications, and / or equivalents of various of these details. In other instances, structures and devices are omitted or shown or discussed more generally in order to avoid obscuring or unduly limiting the disclosed technology. In many cases, a description of operations is sufficient to enable one to implement the various forms of the disclosed technology. It should be noted that there are many different, alternative, or equivalent configurations, devices, and technologies to which the disclosed inventions may be applied. The full scope of the inventions is not limited to the illustrative implementations and examples that are described here

Claims

1. A method of processing media files, the method comprising:performing, by one or more processors, a validation processing regarding at least one media capturing device, the validation processing involving at least one operation to validate at least one device;generating a signature for and / or associated with a media file;associating the signature with the at least one device; andprocessing the signature and / or the captured media file for transmission to and / or storage with an offline storage component.

2. The method of claim 1 or the invention of any claim herein, wherein one or more of:the validation processing involving a key pair, wherein the key pair is based at least in part on a device validation operation;the signature comprises one or more of a secure signature, a secure electronic signature, a digital signature, an encrypted digital stamp / authentication, a signed hash and / or an other secure mark / watermark / delimiter; and / orthe media file comprises a file captured by the at least one media capturing device.

3. A method for media authentication, comprising:performing, by one or more processors, a validation processing regarding at least one media capturing device, the validation processing involving a key pair, wherein the key pair is based at least in part on a device validation operation;generating, by the one or more processors, a signed hash associated with a captured media file;associating, by the one or more processors, the signed hash with the key pair; and transmitting, by the one or more processors, the signed hash and the captured media file to an offline storage component for storage.

4. The method of claim 3 or the invention of any claim herein, further comprising:validating, via the device validation operation, a biometric data of a user of the at least one media capturing device.

5. The method of claim 3 or the invention of any claim herein, further comprising:receiving, via the device validation operation, a push notification based at least in part on a notification access permission, wherein the push notification hardens a proof of device integrity and a proof of user presence.

6. The method of claim 3 or the invention of any claim herein, further comprising:detecting, by the one or more processors, an opportunity to connect to a server; and transmitting, by the one or more processors, the signed hash to the server.

7. The method of claim 6 or the invention of any claim herein, further comprising a provisioning operation, wherein the provisioning operation comprises:transmitting, by the one or more processors, the captured media file to the server, wherein the captured media file is associated with a user profile based on a key pair information corresponding to the key pair of the at least one media capturing device.

8. The method of claim 6 or the invention of any claim herein, further comprising a provisioning operation, wherein the provisioning operation comprises:identifying, by the one or more processors, an originating profile and a sharing profile;transmitting, by the one or more processors, the captured media file to the server, wherein the captured media file is associated with a sharing link;associating, with the originating profile, a control right of the sharing link with the originating profile; andassociating, with the sharing profile, a public sharing right of the sharing link and the captured media file.

9. The method of claim 8 or the invention of any claim herein, wherein the public sharing right associated with the sharing profile may be withdrawn by the control right associated with the originating profile.

10. The method of claim 7 or claim 8 or the invention of any claim herein, wherein the provisioning operation is a user-directed operation.

11. The method of claim 8 or the invention of any claim herein, wherein the provisioning operation further comprises one or more of:receiving and displaying a QR code, wherein the QR code is generated on the at least one media capturing device and contains a signed link associated with the sharing profile; andreceiving an encrypted code that when decrypted, allows access, via receipt of a data packet for controlling an access permission or a sharing permission, for the sharing profile provided by the server.

12. The method of claim 3 or the invention of any claim herein, wherein the offline storage component is configured to securely save the key pair to at least one media capturing device.

13. The method of claim 6 or the invention of any claim herein, wherein transmission of signed hashes to the server is automatic.

14. The method of claim 4 or the invention of any claim herein, further comprising:enqueuing, by the one or more processors, a plurality of signed hashes into a queue, each signed hash of the plurality of signed hashes being stored for later transmission to a server.

15. The method of claim 14 or the invention of any claim herein, further comprising:displaying, by the one or more processors, a gallery of one or more media files, wherein each media file of the one or more media files corresponds to each signed hash of the plurality of signed hashes.

16. The method of claim 15 or the invention of any claim herein, wherein the gallery of one or media files comprises one or more local media files and one or more transmitted media files, wherein the one or more local media files do not correspond to a signed hash on the server.

17. The method of claim 16 or the invention of any claim herein, further comprising:identifying, by the one or more processors, one or more discard files from the one or more local media files based on a user-curation operation, wherein the one or more discard files are deleted before transmission to the server; andlocally storing, by the one or more processors, one or more signed hashes corresponding to the one or more discard files after a discard file is deleted.

18. The method of claim 16 or the invention of any claim herein, further comprising:identifying, by the one or more processors, one or more discard files from the one or more transmitted media files based on a user-curation operation; andtransmitting, by the one or more processors, a deletion instruction to the server for deleting media files corresponding to the one or more discard files.

19. The method of claim 3 or the invention of any claim herein, further comprising:detecting, by the one or more processors, a location tagging option is enabled; and associating, by the one or more processors, a location information with the captured media file.

20. The method of claim 3 or the invention of any claim herein, wherein the signed hash associated with the captured media file is based at least in part on a biometric data of a user of the at least one media capturing device.

21. A system comprising:one or more processors; andone or more computer readable media storing computer-executable instructions that, when executed by one or more processors, cause at least one processor associated with the system to:perform a validation processing regarding at least one media capturing device, the validation processing involving a key pair, wherein the key pair is based at least in part on a device validation operation;generate a signed hash associated with a captured media file;associate the signed hash with the key pair; andtransmit the signed hash and the captured media file to an offline storage component for storage.

22. The system of claim 21 or the invention of any claim herein, wherein the system is further caused to:validate, via the device validation operation, a biometric data of a user of the at least one media capturing device.

23. The system of claim 21 or the invention of any claim herein, wherein the system is further caused to:receive, via the device validation operation, a push notification based at least in part on a notification access permission, wherein the push notification hardens a proof of device integrity and a proof of user presence.

24. The system of claim 21 or the invention of any claim herein, wherein the system is further caused to:detect an opportunity to connect to a server; andtransmit the signed hash to the server.

25. The system of claim 24 or the invention of any claim herein, further comprising a provisioning operation, wherein the provisioning operation comprises:transmitting the captured media file to the server, wherein the captured media file is associated with a user profile based on a key pair information corresponding to the key pair of the at least one media capturing device.

26. The system of claim 24 or the invention of any claim herein, further comprising a provisioning operation, wherein the provisioning operation comprises:identifying, by the one or more processors, an originating profile and a sharing profile;transmitting, by the one or more processors, the captured media file to the server, wherein the captured media file is associated with a sharing link;associating, with the originating profile, a control right of the sharing link with the originating profile; andassociating, with the sharing profile, a public sharing right of the sharing link and the captured media file.

27. The system of claim 26 or the invention of any claim herein, wherein the public sharing right associated with the sharing profile may be withdrawn by the control right associated with the originating profile.

28. The system of claim 25 or claim 26 or the invention of any claim herein, wherein the provisioning operation is a user-directed operation.

29. The system of claim 26 or the invention of any claim herein, wherein the provisioning operation further comprises one or more of:receiving and displaying a QR code, wherein the QR code is generated on the at least one media capturing device and contains a signed link associated with the sharing profile; andreceiving an encrypted code that when decrypted, allows access, via receipt of a data packet for controlling an access permission or a sharing permission, for the sharing profile provided by the server.

30. The system of claim 21 or the invention of any claim herein, wherein the offline storage component is configured to securely save the key pair to at least one media capturing device.

31. The system of claim 24 or the invention of any claim herein, wherein transmission of signed hashes to the server is automatic.

32. The system of claim 22 or the invention of any claim herein, wherein the system is further caused to:enqueuing, by the one or more processors, a plurality of signed hashes into a queue, each signed hash of the plurality of signed hashes being stored for later transmission to a server.

33. The system of claim 32 or the invention of any claim herein, wherein the system is further caused to:display a gallery of one or more media files, wherein each media file of the one or more media files corresponds to each signed hash of the plurality of signed hashes.

34. The system of claim 33 or the invention of any claim herein, wherein the gallery of one or media files comprises one or more local media files and one or more transmitted media files, wherein the one or more local media files do not correspond to a signed hash on the server.

35. The system of claim 34 or the invention of any claim herein, wherein the system is further caused to:identify one or more discard files from the one or more local media files based on a user-curation operation, wherein the one or more discard files are deleted before transmission to the server; andlocally store one or more signed hashes corresponding to the one or more discard files after a discard file is deleted.

36. The system of claim 34 or the invention of any claim herein, wherein the system is further caused to:identify one or more discard files from the one or more transmitted media files based on a user-curation operation; andtransmit a deletion instruction to the server for deleting media files corresponding to the one or more discard files.

37. The system of claim 21 or the invention of any claim herein, wherein the system is further caused to:detect a location tagging option is enabled; andassociate a location information with the captured media file.

38. The system of claim 21 or the invention of any claim herein, wherein the signed hash associated with the captured media file is based at least in part on a biometric data of a user of the at least one media capturing device.

39. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:performing a validation processing regarding at least one media capturing device, the validation processing involving a key pair, wherein the key pair is based at least in part on a device validation operation;generating a signed hash associated with a captured media file;associating the signed hash with the key pair; andtransmitting the signed hash and the captured media file to an offline storage component for storage.

40. The non-transitory computer-readable medium of claim 39 or the invention of any claim herein, wherein the operations further comprise:validating, via the device validation operation, a biometric data of a user of the at least one media capturing device.

41. The non-transitory computer-readable medium of claim 39 or the invention of any claim herein, wherein the operations further comprise:receiving, via the device validation operation, a push notification based at least in part on a notification access permission, wherein the push notification hardens a proof of device integrity and a proof of user presence.

42. The non-transitory computer-readable medium of claim 39 or the invention of any claim herein, wherein the operations further comprise:detecting an opportunity to connect to a server; and / ortransmitting the signed hash to the server.

43. The non-transitory computer-readable medium of claim 42 or the invention of any claim herein, wherein the operations further comprise:executing a provisioning operation, wherein the provisioning operation inludes:transmitting the captured media file to the server, wherein the captured media file is associated with a user profile based on a key pair information corresponding to the key pair of the at least one media capturing device.

44. The non-transitory computer-readable medium of claim 42 or the invention of any claim herein, wherein the operations further comprise:executing a provisioning operation, wherein the provisioning operation includes:identifying an originating profile and a sharing profile;transmitting the captured media file to the server, wherein the captured media file is associated with a sharing link;associating, with the originating profile, a control right of the sharing link with the originating profile; and / orassociating, with the sharing profile, a public sharing right of the sharing link and the captured media file.

45. The non-transitory computer-readable medium of claim 44 or the invention of any claim herein, wherein the public sharing right associated with the sharing profile may be withdrawn by the control right associated with the originating profile.

46. The non-transitory computer-readable medium of claim 43 or claim 44 or the invention of any claim herein, wherein the provisioning operation includes, involves, or is a user-directed operation.

47. The non-transitory computer-readable medium of claim 44 or the invention of any claim herein, wherein the provisioning operation further comprises one or more of:receiving and displaying a QR code, wherein the QR code is generated on the at least one media capturing device and contains a signed link associated with the sharing profile; and / orreceiving an encrypted code that when decrypted, allows access, via receipt of a data packet for controlling an access permission or a sharing permission, for the sharing profile provided by the server.

48. The non-transitory computer-readable medium of claim 39 or the invention of any claim herein, wherein the operations further comprise:performing processing associated with and / or involving securely saving the key pair to at least one media capturing device and / or configuration of the offline storage component for said securely saving.

49. The non-transitory computer-readable medium of claim 42 or the invention of any claim herein, wherein the operations further comprise:automatically transmitting signed hashes to the server.

50. The non-transitory computer-readable medium of claim 40 or the invention of any claim herein, wherein the operations further comprise:enqueuing a plurality of signed hashes into a queue, each signed hash of the plurality of signed hashes being stored for later transmission to a server.

51. The non-transitory computer-readable medium of claim 50 or the invention of any claim herein, wherein the operations further comprise:performing processing associated with displaying a gallery of one or more media files, wherein each media file of the one or more media files corresponds to each signed hash of the plurality of signed hashes.

52. The non-transitory computer-readable medium of claim 51 or the invention of any claim herein, wherein the gallery of one or media files comprises one or more local media files and one or more transmitted media files, wherein the one or more local media files do not correspond to a signed hash on the server.

53. The non-transitory computer-readable medium of claim 52 or the invention of any claim herein, wherein the operations further comprise:identifying one or more discard files from the one or more local media files based on a user-curation operation, wherein the one or more discard files are deleted before transmission to the server; and / orlocally storing one or more signed hashes corresponding to the one or more discard files after a discard file is deleted.

54. The non-transitory computer-readable medium of claim 52 or the invention of any claim herein, wherein the operations further comprise:identifying one or more discard files from the one or more transmitted media files based on a user-curation operation; and / ortransmitting a deletion instruction to the server for deleting media files corresponding to the one or more discard files.

55. The non-transitory computer-readable medium of claim 39, or the invention of any claim herein, wherein the operations further comprise:detecting a location tagging option is enabled; and / orassociating, by the one or more processors, a location information with the captured media file.

56. The non-transitory computer-readable medium of claim 39 or the invention of any claim herein, wherein the signed hash associated with the captured media file is based at least in part on a biometric data of a user of the at least one media capturing device.

57. A method for configuring a media capturing device for media authentication, the method comprising one or more of:performing, by one or more processors, a device verification process comprising: generating a key pair in an offline storage component of a media capturing device, the key pair comprising a public key and a private key, wherein the offline storage component is a secure enclave;performing, by the one or more processors, an attestation challenge, the attestation challenge based at least in part on the private key of the key pair;transmitting, by the one or more processors, attestation information associated with a device attestation challenge to a server;receiving attestation results of the attestation challenge from the server; performing, by the one or more processors, a biometric data validation operation comprising:displaying a biometric pattern overlay;scanning one or more biometric features of a device user; and comparing the one or more biometric features of the device user to stored biometric data;receiving, by the one or more processors, a push notification based at least in part on a notification access permission to harden proof of device integrity and user presence; and / or transmitting, by the one or more processors, the public key of the key pair to the server, wherein the public key is used to generate an online user profile associated with the device user.

58. A system comprising:one or more computer processors;one or more non-transitory computer readable media, the non-transitory computer readable media including computer-readable program instructions that, upon execution by the one or more computer processors, cause the one or more computer processors to:perform one or more aspects, steps, features, and / or functionality recited in any claim herein and / or set forth elsewhere in the present disclosure.

59. One or more non-transitory computer readable media including computer-readable program instructions that, upon execution by one or more computer processors, cause the one or more computer processors to:perform one or more aspects, steps, features, and / or functionality recited in any claim herein and / or set forth elsewhere in the present disclosure.

Images