Computer-implemented methods for evidencing the existence of a digital document, anonymously evidencing the existence of a digital document, and verifying data integrity of a digital document - Patents.com

Abstract

Improved computer-implemented methods for evidencing the existence of a digital document and anonymously evidencing the existence of a digital document, data management for evidencing the existence of a digital document and verifying data integrity of a digital document, increasing reliability, security and enhancing trust from users and third parties.

Description

[Technical field]

[0001] The present invention relates to a method for proving the existence of a digital document, a method for anonymously proving the existence of a digital document, and a method for verifying data integrity of a digital document. In particular, the present invention relates to a method for proving the existence of a digital document, a method for anonymously proving the existence of a digital document, and a method for verifying data integrity of a digital document. [Background technology]

[0002] In the digital knowledge economy, intellectual property (IP) is often a person's or company's most valuable asset. Intellectual property law is designed to benefit society by encouraging the creation of new and valuable intellectual property by recognizing creators, owners and / or inventors and providing them with legal and economic benefits. One of the key prerequisites for all intellectual property rights (IPR) is originality. That being said, it is often important to know when the IP was created and / or first used and who the creator, owner or inventor is, as this often determines the ownership of the relevant IPR.

[0003] One way to prove originality and / or creation is through a digital "birth certificate." As soon as a creator, owner, or inventor creates and digitally stores a new digital work (whether as an image, video, document, song, etc.), a new trade secret, a new copyrighted work, a new design for a new trademark logo, and / or the creation of a new invention, a digital birth certificate consisting of and / or associated with a timestamp can be provided. However, simply relying on the timestamp of the computer on which the digital document was created is often insufficient as such time / date stamps can be altered, forged, or simply inaccurate when relying solely on the computer's time.

[0004] The increased incidence of hacks like Solar Wind exposed in 2021 further indicates that there is an existing and increasing need to verify that data, software, and especially software installation packages remain untouched and untampered with before being transferred to or installed on a user's system.

[0005] Blockchain systems are known that use cryptographic hashes to record and create links, such as transactions and / or other data, that are then stored in a ledger, typically either an open or closed ledger, although semi-open ledgers are also possible. However, a common problem with blockchain systems is that as the chain gets longer and longer, the system requires more and more time, computing power, and energy to generate the next virtual link in the chain. At some point, the law of diminishing returns dictates that generating the next link in the chain becomes too slow, too energy intensive, and / or otherwise unsustainable. Thus, there is a need to improve current blockchain system architectures to reduce the incidence of hacking. Summary of the Invention [Problem to be solved by the invention]

[0006] It would therefore be desirable to provide a method that can quickly and easily provide digital credentials, such as irrefutable date / time stamps and digital fingerprints, to evidence the new creation, ownership, and / or origin of a digital document. Preferably, such a method would provide a temporal record that uniquely identifies a digital file without ever disclosing the actual digital content. Also, such a record would preferably be securely stored by a trusted organization and / or have a standardized timestamp. Also, it would be desirable to provide a unique digital fingerprint for each digital document. Also, it would be desirable to be able to detect from the digital document, as indicated by the digital fingerprint, whether the digital document has been altered or modified. Also, there is a need for easier and more efficient methods of authenticating digital documents, particularly in courts or other forums, in cases of trade secret theft, prior use defense, copyright actions, and the like. Thus, there is a need for additional methods of evidence of the existence of digital documents and understanding metadata associated with digital documents. Also, there is a need for improved methods of anonymously evidence of the existence of digital documents without sacrificing privacy or revealing excessive personal information. Also, there is a need for improved database management for systems that evidence the existence of digital documents. There is also a need for verification of the integrity of digital documents in the user's system by users and / or third parties. Improved blockchain systems are also needed. [Means for solving the problem]

[0007] The present invention relates to a computer-implemented method for evidencing the existence of a digital document, the method comprising the steps of: obtaining metadata of the digital document at a user's system; obtaining a cryptographic hash of the digital document via the user's system; transmitting the metadata and the cryptographic hash from the user's system to a remote device; receiving the metadata and the cryptographic hash at the remote device; requesting a timestamp from a time source; receiving the timestamp from the time source at the remote device; combining the metadata, the cryptographic hash, and the timestamp in an evidence key generator to generate an evidence key; storing the evidence key to provide a stored evidence key; and, optionally, generating a further cryptographic hash of the evidence key in a further evidence key generator to form a further evidence key; and storing the further evidence key to form a stored further evidence key. The remote device does not include a time source, and the timestamp is based on the time the remote device receives the metadata and the cryptographic hash. During the method for evidencing the existence of the digital document, the digital document remains in the user's system.

[0008] One embodiment of the present invention relates to a computer-implemented method for anonymously evidenceing the existence of a digital document, the method including the steps of obtaining metadata for the digital document in a user's system, obtaining a cryptographic hash of the digital document, transmitting the metadata and the cryptographic hash to a remote device, receiving the metadata and the cryptographic hash at the remote device, requesting user identity data from an identity source, obtaining a cryptographic hash of the user's identity data to form an identity hash, receiving the identity hash at the remote device, combining the metadata, the cryptographic hash, and the identity hash in an evidence key generator at the remote device to generate an evidence key, storing the evidence key and providing the stored evidence key, generating a reference code for the stored evidence key, and transmitting the reference code to the user. In this method, the digital document never leaves the user's system, the identity data never leaves the identity source, the reference code allows a third party to access the evidence key or allows a third party limited access to the evidence key, and optionally the digital document contains information selected from the group consisting of biometric information, business information, financial information, health information, historical information, identity information, legal information, personal information, and combinations thereof.

[0009] In one embodiment of the present application, the invention includes a computer-implemented method for evidencing the existence of a digital document, the method including obtaining a log of prior cryptographic hashes from a user's system, obtaining a cryptographic hash of the digital document, checking the log to see if the cryptographic hash matches any of the prior cryptographic hashes, and if the cryptographic hash does not match any of the prior cryptographic hashes, transmitting the cryptographic hash to a remote device.

[0010] In one embodiment of the method of the present application, a computer-implemented method for evidencing the existence of a digital document includes the steps of obtaining metadata for the digital document on a user's system, obtaining a cryptographic hash of the digital document, transmitting the metadata and the cryptographic hash from the user's system to a remote device, receiving the metadata and the cryptographic hash at the remote device, requesting a timestamp from a time source, receiving the timestamp from the time source at the remote device, combining the metadata, the cryptographic hash, and the timestamp at an evidence key generator at the remote device to generate an evidence key, combining a plurality of evidence keys to form a composite evidence key, optionally the plurality of evidence keys comprises about 2 to about 1000 evidence keys, or about 5 to about 100 evidence keys, storing the composite evidence key to provide a stored composite evidence key, generating further cryptographic hashes of the composite evidence key to form further evidence keys, and storing the further evidence keys to form a stored further evidence key. The remote device does not include a time source, and the timestamp is based on the time the remote device receives the metadata and the cryptographic hash.

[0011] An embodiment of the present invention relates to a method for verifying data integrity of a digital document, the method including the steps of storing the digital document in a user's system, obtaining metadata of the digital document, typically from the user's system, obtaining a cryptographic hash of the digital document, transmitting the metadata and the cryptographic hash to a remote device, receiving the metadata and the cryptographic hash at the remote device, requesting a timestamp from a time source, receiving the timestamp at the remote device from the time source, combining the metadata, the cryptographic hash, and the timestamp in an evidence key generator at the remote device to generate an evidence key, storing the evidence key, and providing a stored evidence key. Typically, the remote device does not include a time source. In the method, a third-party user obtains a second cryptographic hash of the digital document and compares the second cryptographic hash with the cryptographic hash in the stored evidence key to generate a comparison result, and the third-party user is optionally notified of the comparison result if the third-party user is different from the user. During the method, the digital document remains in the user's system, the third-party user's system, or both.

[0012] Without intending to be limited by theory, it is believed that the methods and systems embodied by the present invention provide improved methods for evidencing the existence of digital documents, verifying data integrity of digital documents, and / or managing digital databases to achieve these goals. It is believed that the methods and systems herein can be minimally energy intensive, operable on virtually any computing device, and user friendly. It is further believed that the methods and systems herein can increase trust in digital documents and their management between users and third parties. [Brief description of the drawings]

[0013] For a more complete understanding of the present invention, reference is made to the following detailed description and accompanying drawings.

[0014] [Figure 1] 1 shows a diagram of an embodiment of the present invention.

[0015] [Diagram 2] 1 shows a diagram of an embodiment of the present invention including a search request.

[0016] [Diagram 3] 1 shows a flow diagram of a method for evidencing the existence of a digital document according to an embodiment of the present invention.

[0017] [Figure 4] 4 shows a detailed flow diagram of step 54 of the method according to the embodiment shown in FIG.

[0018] [Diagram 5] 1 illustrates an embodiment of a system of the present invention for evidencing the existence of a digital document.

[0019] [Figure 6] 1 illustrates an embodiment of the present invention that describes a method for synchronizing clocks of storage servers.

[0020] [Figure 7] 1 illustrates an algorithm structure according to an embodiment of the present invention.

[0021] [Figure 8] A shows an embodiment of the present invention for generating a checksum.B shows another embodiment of the present invention for generating a checksum.

[0022] [Figure 9] 4 illustrates another embodiment of the present invention for generating a checksum.

[0023] [Figure 10] 1 shows a schematic diagram of a tag chain embodiment of the present invention.

[0024] [Figure 11] FIG. 1 shows a schematic flow diagram of an embodiment of the present invention.

[0025] [Figure 12] 1 shows a schematic flow diagram of an embodiment of the present invention for anonymously evidencing the existence of a digital document.

[0026] [Figure 13] 1 shows a schematic flow diagram of an embodiment of the present invention for evidencing the existence of a digital document;

[0027] [Figure 14] FIG. 1 shows a schematic flow diagram of an embodiment of the present invention.

[0028] [Figure 15] 1 shows a schematic flow diagram of an embodiment of the present invention for verifying the integrity of a digital document.

[0029] The diagrams herein are for illustrative purposes only and do not necessarily show all necessary or optional steps, components, and / or other details. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] As used herein, the term "comprising" means the inclusion of the listed elements but not excluding other elements.

[0031] As used herein, unless otherwise specified, the terms "couple" or "connect" refer to being directly or indirectly electrically coupled or connected through one or more electrical or wireless means.

[0032] As used herein, the term "document" when used alone refers to a digital document and refers to any document stored digitally rather than in physical (e.g., printed or written) form, including, but not limited to, letters, presentations, CAD files, audio, video, photographs, images, spreadsheets, software, algorithms, programs, digitally synthesized scents, digitized feel / touch, digitized taste profiles, digitized visual elements, blockchains, cryptocurrencies, smart contracts, ledgers, distributed ledgers, non-fungible tokens, virtual reality elements, wireframes, augmented reality elements, digital avatars, and the like, and combinations thereof. It is recognized that a digital document herein may be a partial or entire digital representation of a physical document and may include additional elements not present in the physical document. Additionally, it is recognized that a digital document itself may actually include one or more digital files, for example, a digital document herein may be a database with multiple digital files, a folder with multiple digital files, an entire hard drive with multiple digital files, a server with multiple databases, and the like. Those skilled in the art will further appreciate that the digital documents herein may be in any format, including, but not limited to, .pdf, .doc, .docx, .xls, .xlsx, .ppt, .pptx, .msg, .xlsm, .jpg, .png, .bmp, .mp3, .gif, .easm, .stp, .pst, .zip, .dat, .txt, .mov, .midi, .rtf, .log, .csv, .exe, .dmg, and variations thereof.

[0033] As used herein, "location" refers to, for example, a geographic location, e.g., a physical location indicated by a set of map coordinates, a set of GPS coordinates, a street address, and / or other recognized physical location indicator, a digital / virtual location, e.g., an Internet Protocol address, a MAC address, a system or network identifier, an indicator corresponding to a combination of a particular physical location and a digital / virtual location, or a combination thereof.

[0034] As used herein, "time" refers to a time and date, or an associated value that corresponds to a particular time and date.

[0035] As used herein, "user" refers to someone using the methods herein and may be an individual, an institution, a government, a corporate or non-corporate entity, a computer, a computer system, etc. As used herein, the term "user" includes a user's system, which may include a computerized device, a computer server, a computer network, an entire computer system, etc.

[0036] A "user's system" herein is non-specific and generally indicates that the user controls the system and / or has influence, ownership, and / or otherwise controls who and what (e.g., other systems) can access the system ("access control"), as well as the data and information flowing out of the system. This term includes physical control (e.g., ownership of physical computer assets), as well as associated "cloud computing" accounts, etc., over which the user exercises a level of access control.

[0037] As used herein, the phrase "within a user's system" refers to a digital document being located either permanently or temporarily within a user's system.

[0038] The present invention relates to a computer-implemented method for evidence of existence of a digital document, comprising the steps of obtaining a timestamp of the digital document, obtaining multiple cryptographic hashes of the digital document, generating an evidence key based on the timestamp and the multiple cryptographic hashes, storing the evidence key, and providing the stored evidence key.

[0039] The present invention also relates to a computer-implemented method for evidence of existence of a digital document, the method comprising the steps of obtaining a plurality of timestamps of the digital document, obtaining a cryptographic hash of the digital document, generating an evidence key based on the plurality of timestamps and the cryptographic hash, storing the evidence key, and providing the stored evidence key.

[0040] The present invention also relates to a computer-implemented method for evidencing the existence of a digital document, comprising the steps of obtaining a timestamp, optionally with permission-based and / or non-permission-based metadata, of the digital document, obtaining a cryptographic hash of the digital document, generating an evidence key based on the timestamp and the cryptographic hash, and storing the evidence key to provide a stored evidence key, the storage of the evidence key being stored in a plurality of storage media.

[0041] The present invention relates to a computer-implemented method for evidencing the existence of a digital document, comprising the steps of: obtaining metadata of the digital document at a user's system; obtaining a cryptographic hash of the digital document via the user's system; transmitting the metadata and the cryptographic hash from the user's system to a remote device; receiving the metadata and the cryptographic hash at the remote device; requesting a timestamp from a time source; receiving the timestamp from the time source at the remote device; combining the metadata, the cryptographic hash, and the timestamp in an evidence key generator to generate an evidence key; storing the evidence key to provide a stored evidence key; generating a further cryptographic hash of the evidence key in a further evidence key generator to form a further evidence key; and storing the further evidence key to form a stored further evidence key. The remote device does not include a time source, i.e., the time source is separate from the remote device, and typically the time source is also separate from the evidence key generator. The timestamp is based on the time the remote device received the metadata and the cryptographic hash. During the method herein for evidencing the existence of a digital document, the digital document remains in the user's system. It will be appreciated that the evidence key generator and the further evidence key generator may be the same or different.

[0042] In the method herein, the digital document originates at or within the user's system and always remains within the user's system, i.e., is not transmitted to a remote device during the method. Isolating the time source from the remote device (and the evidence key generator) is believed to increase security and reliability and to increase trust in the system by reducing the likelihood that an erroneous timestamp will be associated with the metadata, cryptographic hash, evidence key, etc. The timestamp is based on the time the remote device receives the metadata and cryptographic hash. For example, upon receiving the metadata and cryptographic hash, the remote device may execute instructions to obtain the current time from a time source, which becomes the timestamp. In another embodiment herein, the timestamp is obtained from a time source, such as a time server, an international clock, a network protocol time, an independent clock, an atomic clock, and combinations thereof, or a time server, an atomic clock, an independent clock, a dedicated time server, and combinations thereof. In one embodiment herein, the independent clock is a Global Positioning System (GPS) clock, a GPS master clock, an Internet server time, a data value time, UTC time, and combinations thereof. It is recognized that the systems and methods herein are highly dependent on receiving accurate timestamps, and thus, in certain embodiments herein, the time sources have a stratum of about 1 to about 8, or about 1 to about 5, or about 1 to about 3, or about 1 to about 2, or about 1. In certain embodiments herein, the remote device, evidence key generator, and / or storage server receive timestamps from multiple time sources.

[0043] In certain embodiments herein, the timestamp may be associated with time source metadata (see 209 in FIG. 1 ), such as, for example, metadata about the time source, metadata about the remote device, or other metadata related to the timestamp, the time source, and / or instructions for requesting / receiving the timestamp, such as a machine ID, MAC ID, etc.

[0044] Metadata herein is data, typically structured data, that relates to or describes other data, in this case digital documents, a user's system, etc. The metadata may be selected from the group of digital document metadata, user metadata, system metadata, miscellaneous metadata, and combinations thereof. In certain embodiments herein, the metadata relates to or includes metadata about digital documents, cryptographic hashes, evidence key generators, evidence keys, timestamps, etc., and / or metadata about how the digital documents, cryptographic hashes, evidence key generators, evidence keys, timestamps, etc., were processed, transformed, constructed, modified, combined, amended, etc.

[0045] In some embodiments herein, the metadata relates to the existence and / or location of a digital document on or within a blockchain or other distributed ledger system. In some embodiments herein, the metadata relates to a smart contract, the term of a smart contract, a transaction, etc. In some embodiments herein, the metadata relates to a partial or complete ownership interest in a digital document, a security interest in a digital document, etc. In some embodiments herein, the metadata includes a combination of metadata, or even the same metadata.

[0046] Additionally, metadata herein may be collected automatically by the user or another user's system, or may be specifically entered by the user and / or the user's system, as desired. Digital document metadata may include, for example, author, version number or identifier, file name, file properties, abstract, synopsis, keywords, location of the digital document in the user's system (e.g., folder location), digital document file history, and combinations thereof. File properties may include metadata selected from the group of file size, creation date, revision number, modification date or last modification date, geotag, author / creator name or reference, project name, hardware and / or software used to create the digital document, hardware and / or software used to modify the digital document, file format identifier, structure identifier, relationship to another digital document, and combinations thereof. User metadata may include metadata selected from the group of user name, user location, user position, user project, user computer / system details (e.g., user computer make and model, operating system, etc.), user management structure, user group, user department, user company, user account information, user device IP address, user device MAC address, user password, user encryption key (e.g., public / private key), user contact information, and combinations thereof. System metadata is metadata related to the user's computer system and may include metadata selected from the group of system IP address, system MAC address, system owner, system location, system statistics, system account information, system structure, system resources, system, operating system version, and combinations thereof.Miscellaneous metadata is metadata associated with other types of data and may include metadata selected from the group of legal metadata, statistical metadata, resource metadata, permission metadata, transaction metadata, smart contract metadata, and combinations thereof.

[0047] The transmission of the metadata and cryptographic hashes from the user's system to the remote device may occur via any method or system as desired, such as transmission, or wired transmission, wireless transmission, direct transmission, indirect transmission, etc., as desired. In one embodiment herein, the transmission of the metadata and cryptographic hashes from the user's system to the remote device occurs over the Internet.

[0048] In certain embodiments herein, the method includes obtaining further metadata, or further metadata of the digital document, from a source selected from the group of a user, a system of the user, and combinations thereof. The further metadata may be metadata regarding changes to the (original) digital document, metadata, cryptographic hashes, timestamps, evidence keys, evidence key generators, remote devices, etc. that link the (original) digital document, metadata, cryptographic hashes, timestamps, evidence keys, etc. to subsequent revisions and / or versions. In certain embodiments, the further metadata is related to transformations, transactions, ownership, pledges, obligations, etc. In certain embodiments herein, the further metadata is manually entered by a user. In certain embodiments herein, the further metadata is collected by and / or obtained from a user or a third-party user. In certain embodiments herein, the further metadata includes further metadata, the same further metadata, and / or a combination of metadata.

[0049] In some embodiments herein, the method includes providing the additional metadata to a third party, or providing the additional metadata to a third party, where the additional metadata is not provided to a remote device. The additional metadata may be provided to the third party directly, for example, by a user, a user's system, and combinations thereof. In such cases, the user will typically consent to providing the additional metadata, and thus in some embodiments herein, the method includes obtaining user consent to transmitting the additional metadata to the third party, where obtaining user consent occurs prior to transmitting the additional metadata to the third party.

[0050] In an embodiment herein, to improve the security of the system by preventing dissemination of the digital document, the user's system does not transmit the digital document to the remote device, or transmits only the metadata, the cryptographic hash, the further metadata, the further cryptographic hash, and a combination thereof, or the metadata, the cryptographic hash, and a combination thereof, to the remote device. In such a case, the digital document is considered to be better protected since it never leaves the user's system and ownership and control are maintained. Thus, even if the remote device is hacked or otherwise compromised, an attacker may still not gain access to the original digital document, but only the metadata and the cryptographic hash. In an embodiment, any data transmitted to / from the user's system or to / from the remote device is encrypted, e.g., encrypted with private / public key encryption.

[0051] In an embodiment herein, a further cryptographic hash is generated in a further evidence key generator from the evidence key and the metadata, or from the evidence key and the further metadata, or from the evidence key, the metadata, and the further metadata. In an embodiment herein, a further evidence key is generated in a further evidence key generator from the evidence key, the timestamp, and the metadata, or from the evidence key, the timestamp, and the further metadata, or from the evidence key, the timestamp, the metadata, and the further metadata.

[0052] Without intending to be limited by theory, it is believed that such a method may, for example, allow a third party to receive, manipulate, and / or analyze the further evidence key while providing security, or an additional level of security, for the digital document. Thus, in certain embodiments herein, the method further includes providing or transmitting the further cryptographic hash to the third party. Since obtaining user consent is again very important and may be required, the method herein may further include obtaining user consent to transmit the further cryptographic hash to the third party, which is done prior to transmitting the further cryptographic hash to the third party. An embodiment of the present invention relates to a computer-implemented method for anonymously evidencing the existence of a digital document, the method including obtaining metadata of the digital document in a user's system, obtaining a cryptographic hash of the digital document, transmitting the metadata and the cryptographic hash to a remote device, receiving the metadata and the cryptographic hash at the remote device, requesting identity data of the user from an identity source, obtaining a cryptographic hash of the user's identity data to form an identity hash, generating an evidence key at the remote device by combining the metadata, the cryptographic hash, and the identity hash in an evidence key generator, storing the evidence key and providing the stored evidence key, generating a reference code for the stored evidence key, and transmitting the reference code to the user. The digital document never leaves the user's system, the identity document never leaves the user's system, and the reference code, e.g., a web link, bar code, QR code, etc., allows a third party to access the evidence key or allows a third party to have limited access to, or to view, or to view but not modify, the evidence key.In certain embodiments herein, the user's identity data is in the form of an identity hash which further enhances the security and privacy of the methods and systems.

[0053] Such a system would allow a balance between anonymity and verifiability for records such as Covid-19 vaccination records / vaccination status, age verification, e.g., for entry into a bar or other venue, voting registration status, and other situations where facts need to be verified but the user may not want to reveal other information such as their name, address, etc. In such cases, for example, when a third party has access to the reference code, the third party's device may show a photograph of the user, as well as confirmation that the user has been fully vaccinated, is over 21, etc., while typically omitting other information or other personally identifiable information that is not necessary for the third party's purposes.

[0054] In certain embodiments herein, the identity source is selected from the group of identity documents, identity databases, and combinations thereof. The identity document may be selected from the group of, for example, government identification information, private identification information, and combinations thereof, or the government identification information may be selected from the group of, for example, driver's license, passport, tax identification information, citizenship (and / or other legal status) identification information, residence identification information, voter registration identification information, biometric identification information, and combinations thereof. The private identification information may be selected from the group of, for example, membership identification information, group identification information, institution identification information, affiliation identification information, company identification information, and combinations thereof.

[0055] In certain embodiments herein, the civilian identity and / or government identity may be a surrogate identity intended to provide a limited or unlimited level of anonymity, e.g., a virtual avatar rather than an actual photo linked to the user's actual identity, a number rather than a name, etc. However, others who view the surrogate identity are only allowed to penetrate the anonymity of the surrogate identity if certain criteria are met, e.g., the user gives specific permission, a court order is issued, etc.

[0056] An identity database in this specification may be, for example, a public identity database, a private identity database, a government identity database, a voter registration database, a medical database, a credit database, a financial database, and combinations thereof, which typically include multiple identity documents.

[0057] The remote device may generate and send a reference code for the stored evidence key to the user, allowing the user to reference the stored evidence key. The user may then share the reference code with a third party to allow the third party to view and / or receive the evidence key, a limited amount of data about the user, the user's identity data, digital documents, and the like. In certain embodiments herein, the reference code may also be sent directly to the third party. In certain embodiments herein, the reference code may direct the third party to a website selected from a website, a standard statement, a digital address, a communication device, and combinations thereof; or a public website, a private website, a government website, and combinations thereof. The reference code may be, for example, a QR code, a URL address, a shortened URL link, a UPC code, and combinations thereof.

[0058] In certain embodiments herein, the digital document is a ballot and the identity document is voter registration identification information, such as a voter registration certificate, which may be obtained, for example, from a voter registration database. The methods herein may then be used to verify that the user has voted and / or even to track the progress of the user's vote through the voting system, for example, to assure the user that the vote was counted correctly and / or that the vote has not been tampered with.

[0059] In certain embodiments herein, the remote device receives the timestamp from a time source, and the remote device does not include a time source, i.e., the time source is separate from the remote device, and typically the time source is also separate from the evidence key generator. Again, it is believed that receiving a timestamp from a time source or time server improves data integrity of the systems and methods herein.

[0060] In one embodiment herein, the invention includes a computer-implemented method for proving the existence of a digital document, the method including the steps of obtaining a log of previous cryptographic hashes from a user's system, obtaining a cryptographic hash of the digital document, checking the log to see if the cryptographic hash matches any of the previous cryptographic hashes, and if the cryptographic hash does not match any of the previous cryptographic hashes, sending the cryptographic hash to a remote device.

[0061] It is contemplated that the user's system may contain within it a log of previous cryptographic hashes, and by checking the cryptographic hash of a digital document against the cryptographic hashes listed in the log, the user's system may be ensured to send only new cryptographic hashes to a remote device, which in turn may prevent the remote device from receiving multiple identical cryptographic hashes.

[0062] In one embodiment of the method herein, a computer-implemented method for evidencing the existence of a digital document includes obtaining metadata for the digital document on a user's system, obtaining a cryptographic hash of the digital document, transmitting the metadata and the cryptographic hash from the user's system to a remote device, receiving the metadata and the cryptographic hash at the remote device, requesting a timestamp from a time source, receiving the timestamp from the time source at the remote device, combining the metadata, the cryptographic hash, and the timestamp at the remote device in an evidence key generator to generate an evidence key, combining the evidence keys to form a composite evidence key, storing the composite evidence key to provide a stored composite evidence key, generating further cryptographic hashes of the composite evidence key to form further evidence keys, and storing the further evidence keys to form further evidence keys. The metadata and cryptographic hash may be sent to the remote device over the Internet. Also, the remote device does not include a time source; i.e., the time source is separate from the remote device, and typically separate from the evidence key generator, and the timestamp is based on the time the remote device receives the metadata and cryptographic hash. In such methods, multiple evidence keys are also typically generated by the remote device by repeating the steps of generating evidence keys that are combined into a composite evidence key.

[0063] Without intending to be limited by theory, it is believed that such methods and generation and / or use of the further evidence keys may allow for more efficient storage of the evidence keys as the further evidence keys, and may also allow, for example, increased granularity and tracking for data analysis and manipulation, verification of data integrity of the evidence keys and / or the further evidence keys (i.e., that one or both of them have not been tampered with), and the like. In certain embodiments herein, the plurality of evidence keys is about 2 to about 1000 evidence keys, or about 5 to about 100 evidence keys. Thus, in certain embodiments herein, the plurality of evidence keys may be determined by the accumulation of a predetermined number of evidence keys to form the plurality of evidence keys. In certain embodiments herein, the plurality of evidence keys is determined by the passage of a predetermined time period, for example, about 0.01 minutes to about 1 hour, or about 0.05 minutes to about 30 minutes, or about 0.1 minutes to about 10 minutes. The predetermined time period may also be calculated according to computer cycles or other time measurement methods, as desired. Thus, all evidence keys generated within this predetermined time period are combined into multiple evidence keys that form a composite evidence key.

[0064] In an embodiment herein, the method may further include storing composite metadata associated with the multiple evidence keys to form a composite evidence key. The composite metadata may be, for example, metadata from each individual evidence key in the multiple evidence keys and / or metadata regarding relationships between the multiple evidence keys, an order of the multiple evidence keys, etc.

[0065] An embodiment of the invention is a method of verifying data integrity of a digital document, comprising the steps of storing the digital document on a user's system, obtaining metadata for the digital document, typically from the user's system, obtaining a cryptographic hash of the digital document, transmitting the metadata and the cryptographic hash to a remote device, receiving the metadata and the cryptographic hash at the remote device, requesting a timestamp from a time source, receiving the timestamp at the remote device from the time source, combining the metadata, the cryptographic hash, and the timestamp to generate an evidence key at an evidence key generator at the remote device, storing the evidence key, and providing the stored evidence key. Typically, the remote device does not include a time source, i.e., the time source is separate from the remote device and typically separate from the evidence key generator.

[0066] In this method, in order for the third-party user to verify data integrity of the digital document, the third-party user can obtain a second cryptographic hash of the digital document, and optionally the second metadata, compare the second cryptographic hash to the cryptographic hash to generate a comparison result, e.g., comparing the cryptographic hash to the second cryptographic hash to see whether they match, and communicate the comparison result to the third-party user. The comparison result can include not only the cryptographic hash to the second cryptographic hash, but also, e.g., a comparison of the metadata to the second metadata, as well as other information.

[0067] The digital document that receives the second cryptographic hash may be the same digital document located on the user's system, a copy located on a third-party user's system, or both. The third-party user may obtain the second cryptographic hash within his or her third-party user's system. During the methods herein, the digital document remains within a group selected from the user's system, the user's control, the third-party user's system, the third-party user's control, and combinations thereof. Without intending to be limited by theory, it is believed that such a configuration may provide improved trust by the third party.

[0068] Without intending to be limited by theory, it is believed that such a method verifies the data integrity of the digital document because if the cryptographic hash and the second cryptographic hash have been tampered with or otherwise altered between the times they are generated, the second cryptographic hash should differ from the (first) cryptographic hash. However, if the digital document has not been tampered with, the cryptographic hash and the second cryptographic hash should be identical.

[0069] In some embodiments herein, the third-party user is different from the user. This may be important, for example, when a third party is downloading software for installation on its own third-party system and wants to ensure that the software is pristine and has not been tampered with. In some embodiments herein, the third-party user is the same as the user. Such a case may occur, for example, when a user suspects that they have suffered a data leak or attack and wants to check their electronic documents to ensure that they have not been tampered with.

[0070] In some embodiments herein, the method herein includes the steps of a third-party user obtaining second metadata from the digital document, comparing the second metadata to the metadata, and informing the third-party user whether the second metadata matches the metadata. This may act as a double check for the method herein to verify data integrity. It is recognized that the second metadata does not have to be from the digital document, and thus, in some embodiments herein, the second metadata may be obtained from a user, a user's system, an evidence key generator, an evidence key, a stored evidence key, a third-party user, and combinations thereof.

[0071] In certain embodiments herein, the methods herein may further include making the evidence key, or the cryptographic hash, or both the evidence key and the cryptographic hash, publicly available, directly or indirectly, and / or simultaneously with or after storing the cryptographic hash and / or the evidence key. The cryptographic hash and / or the evidence key may be made publicly available, for example, by posting it on a publicly available website, database, etc. By doing so, it is believed that anyone can easily check the data integrity of the digital document. For example, if the digital document is a software installation package and the user is a software distributor or software distribution platform, the user may want to make the cryptographic hash or evidence key publicly available, so that a third-party user who wants to install the software can obtain a second cryptographic hash of the digital document and compare it to the (first) published cryptographic hash to check the data integrity of the software, either before or after the third party downloads the software. Thus, the third party can be assured that the software package has not been tampered with before installation on the third party's system and / or behind its firewall.

[0072] In an embodiment herein, the method herein may further include generating an additional evidence key from the stored evidence key in an additional evidence key generator, and storing the additional evidence key to form a stored additional evidence key. Such additional steps are useful, for example, when a third-party user wants to verify the data integrity of a digital document, but the user does not want to provide the third-party user with access to the digital document at that time (yet). In that case, the user may provide the evidence key to the third-party user instead of the digital document itself, and the third-party user may check the data integrity while assuming that the evidence key represents the digital document, its metadata, timestamp, etc.

[0073] It is also recognized herein that a remote device may include multiple remote devices.

[0074] Referring now to the drawings, Figure 1 shows a diagram of one embodiment of the present invention. In Figure 1, method 10 begins with a document 20 for which an evidence key request 22 is submitted, e.g., by a user, computer, system, etc. The evidence key request 22 may be sent to an evidence key generator 24, which is typically a computer program and / or algorithm housed, e.g., on a server, browser, application, etc. Then, depending on the embodiment of the present invention, evidence key generator 24 obtains (e.g., generates) one or more timestamps 26 and obtains (e.g., generates) one or more cryptographic hashes 28.

[0075] Evidence key generator 24 may use a variety of methods and inputs 30 to generate evidence key 32. In certain embodiments herein, evidence key generator 24 generates one or more evidence keys 32 based on inputs 30 of timestamp 26 and / or cryptographic hash 28, or based on timestamp 26 and cryptographic hash 28. In certain embodiments herein, evidence key generator 24 generates evidence key 32 using multiple timestamps, such as 26 and 26', and cryptographic hash 28. In alternative embodiments, evidence key generator 24 generates evidence key 30 using timestamp 26 and multiple cryptographic hashes 28 and 28'. In yet other embodiments, evidence key generator 24 generates evidence key 30 using multiple timestamps 26 and 26', and multiple cryptographic hashes 28. In yet other embodiments, evidence key generator 24 generates multiple evidence keys 32 and 32' using the same input 30 or different inputs 30.

[0076] The timestamp here may come from a variety of sources and may be generated according to one or more events. In some embodiments herein, the timestamp relates to the time the digital document was originally created. In some embodiments herein, the timestamp relates to the time the digital document was last saved. Thus, in some embodiments herein, the timestamp may be part of a version tracking program for the digital document.

[0077] In some embodiments herein, the timestamp relates to the time when the request to generate the evidence key was received by the evidence key generator. In some embodiments herein, the timestamp relates to the time when the evidence key generator obtained the cryptographic hash.

[0078] In certain embodiments herein, the timestamp is a plurality of timestamps, or from about 2 timestamps to about 10 timestamps, or from about 2 timestamps to about 8 timestamps, or from about 3 timestamps to about 6 timestamps. In certain embodiments herein, the plurality of timestamps are obtained from different time sources, or each of the plurality of timestamps is obtained from a different time source, as described herein. Without intending to be limited by theory, it is believed that such a feature allows greater confidence in the authenticity of the overall system, for example, when an evidence key is presented to a third party to evidence the existence of a digital document at a particular time.

[0079] In some embodiments herein, the timestamps include multiple timestamps for multiple events or multiple timestamps each for a different event, in some embodiments herein, the timestamps are for multiple different events such as the time the digital document was originally created, the time the digital document was last saved, the time a request to generate an evidence key was received by an evidence key generator, the time the evidence key generator obtained a cryptographic hash, and combinations thereof.

[0080] Furthermore, in an embodiment of the present invention, if the multiple timestamps do not all fall within a predetermined length of time, the evidence key is flagged as possibly erroneous by the evidence key generator, another algorithm, or another process. In an embodiment herein, the predetermined length of time is 10 minutes, or 5 minutes, or 2 minutes.

[0081] Here, a cryptographic hash is a code, or alphanumeric code string, that represents data in a digital document. A cryptographic hash function maps data in a digital document to provide a specific cryptographic hash for that particular document. A cryptographic hash function herein can be a keyed cryptographic hash generated by a keyed cryptographic hash function, or an unkeyed cryptographic hash generated by an unkeyed cryptographic hash function. In certain embodiments herein, the keyed cryptographic hash function is selected from the group of VMAC, UMAC, BLAKE 2, Poly1305-AES, PMAC, SipHash, One-Key MAC, MD6, HMAC (Hash-Based Message Authentication Code), and combinations thereof, or combinations thereof, or BLAKE 2, MAC, HMAC, and combinations thereof.

[0082] In certain embodiments herein, the keyless cryptographic hash functions are BLAKE-256, BLAKE-512, BLAKE2b, BLAKE2s, ECOH, GOST, Grostl, HAS-160, HAVAL, JH, MD2, MD4, MD5, MD6, RadioGatun, RIPEMD, RIPEMD-128, RIPEMD-160, RIPEMD-320, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, Skein, Snefru, Spectral Hash, Streebog, SWIFFT, Tiger, Whirlpool, and combinations thereof; or an unkeyed cryptographic hash function selected from the group consisting of SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, and combinations thereof; or an unkeyed cryptographic hash function selected from the group consisting of SHA2-256, SHA2-512, SHA3-256, SHA-3, and combinations thereof.

[0083] In certain embodiments herein, the cryptographic hash or hashes are about 2 to about 100 cryptographic hashes, or about 2 to about 25 cryptographic hashes, or about 3 to about 10 cryptographic hashes, or about 4 to about 8 cryptographic hashes. In certain embodiments herein, each of the cryptographic hashes is generated by a different cryptographic hash function. Without intending to be limited by theory, it is believed that the combination of multiple cryptographic hashes provides greater assurance that a collision does not or will not occur. One skilled in the art will appreciate that when multiple cryptographic hashes are used, the likelihood of a collision decreases exponentially.

[0084] Without intending to be limited by theory, it is believed that the use of cryptographic hashes herein, as opposed to other types of hashes, is particularly useful because it is extremely difficult, if not impossible, to reconstruct (i.e., reverse engineer) a digital (i.e., electronic) document and / or the contents of a digital document from the cryptographic hash itself. Thus, it is impossible to reverse engineer a digital document from a digital fingerprint, just as it is impossible to reverse engineer a person from a fingerprint. Thus, because of these advantages, it is believed that the present invention may be useful in evidencing the existence of trade secrets while at the same time reducing the risk of the trade secrets being exposed.

[0085] The evidence key may be generated using the cryptographic hash(s) and timestamp(s), or using the cryptographic hash(s), timestamp(s), and additional input(s). The evidence key may be generated by associating these inputs together, or by further modifying / altering them as desired. For example, in an embodiment herein, the cryptographic hash, timestamp, and any additional inputs are further fed into a further hash function to generate a further hash, which is then used as the evidence key, either alone or together with further data.

[0086] Without intending to be bound by theory, it is believed that the use of both cryptographic hash(s) and timestamp(s) to generate the evidence key provides greater confidence that one or more of these inputs have not been modified at a later point in time.

[0087] As can be seen in Figure 1, only two timestamps 26 and 26', two cryptographic hashes 28 and 28', and two evidence keys 32 and 32', etc. are specifically shown, but the dotted lines and boxes on the right side of Figure 1 indicate that additional timestamps, cryptographic hashes, evidence keys, etc. may also be provided, obtained, generated, etc., and such additional features are considered to be within the scope of the present invention. Thus, it is apparent from Figure 1 that a single digital document may result in the generation of multiple timestamps, multiple cryptographic hashes, multiple evidence keys, multiple stored evidence keys, etc.

[0088] The evidence key 32 and optional additional associated data 34, if any, are then stored together in storage device 36, which typically includes placing the evidence key and the additional associated data together in a storage medium. The additional associated data herein may be included with and / or associated with the evidence key, for example, to categorize the evidence key, describe the evidence key, aid in retrieving the evidence key at a later time, aid in authenticating the evidence key, etc. In certain embodiments herein, the additional associated data includes data used to categorize the evidence key. In certain embodiments herein, the additional associated data includes a software version number for a version of software used to generate the evidence key. In certain embodiments herein, the additional associated data includes data typically used to retrieve the evidence key at a time subsequent to its storage.

[0089] In some embodiments herein, the additional associated data includes non-sensitive information. For example, information about the evidence key that helps to explain the evidence key, its contents, etc., but does not actually reveal detailed contents of the digital document itself. In some embodiments herein, the additional associated data allows retrieval of the evidence key using the non-sensitive information, or retrieval of the evidence key using only the non-sensitive information. The additional associated data may be, for example, a storage timestamp (indicating the time the evidence key was stored), a unique identifier (e.g., email address, phone number, username, password, server address, IP address, device address, etc.), file name, and combinations thereof; or a storage timestamp, email address, phone number, username, password, file name, and combinations thereof; or a storage timestamp, email address, phone number, username, file name, unique identifier, and combinations thereof.

[0090] In certain embodiments herein, the additional associated data includes metadata.

[0091] In certain embodiments herein, the additional relevant data may be viewed, searched, organized, categorized, etc., by entities such as, for example, a system administrator, a local administrator, registered users, and / or the public. In certain embodiments herein, different levels and / or categories of entities possess different levels of access permissions with respect to the additional relevant data and / or evidence keys. For example, a system administrator may have full access permissions to view, search, organize, categorized, etc., the additional relevant data and evidence keys, whereas the public may only have limited access permissions to view the additional relevant data.

[0092] In some embodiments herein, no entity at any level has access that allows them to modify the additional associated data or the evidence key.

[0093] In some embodiments herein, if any changes are made to the additional associated data and / or evidence key, it is indicated in a log or persistent log. In some embodiments herein, the log herein includes a record of the changes made, as well as one or more indications, such as the entity making the change, the date and time the change was made, the location where the change was made (e.g., either a physical location via an IP address and / or a virtual location), the access permissions required to make the change, etc.

[0094] A password useful herein may be any type of information for identifying and / or authenticating a particular user, server, or other entity, particularly an entity submitting an evidence key request for an original digital document. In certain embodiments herein, the password is selected from the group of: alphanumeric string, personal identification factor, location, photo, electronic file, and combinations thereof; or alphanumeric string, personal identification factor, photo, and combinations thereof; or alphanumeric string, personal identification factor, and combinations thereof. In certain embodiments herein, the personal identification factor is a biometric factor, such as a fingerprint, a voiceprint, facial recognition authentication, other personalization patterns, and combinations thereof; or a fingerprint, a voiceprint, facial recognition authentication, and combinations thereof. The biometric factor herein may include biometric information. In certain embodiments herein, the personal identification factor uses a facial recognition algorithm.

[0095] In some embodiments herein, additional associated data useful herein is case sensitive. In some embodiments herein, additional associated data useful herein is case insensitive. In some embodiments herein, passwords, file names, IP addresses, etc. are case sensitive. In some embodiments herein, passwords, file names, IP addresses, etc. are case insensitive.

[0096] 1, it can be seen that evidence key 23 and additional associated data 34 are combined and stored together in storage device 36, 36', etc. to provide one or more stored evidence keys 38, 38', etc. The storage devices herein use a storage medium or multiple storage media to store the stored evidence keys. Information such as evidence key 32 and additional associated data 34 is typically stored in a database in storage 36, 36', etc. and / or in the storage medium herein.

[0097] Storage media useful herein include those selected from the group of servers, storage drives, paper, CD-ROMs, DVDs, disposable storage media, and combinations thereof; or servers, storage drives, CD-ROMs, DVDs, disposable storage media, and combinations thereof; or servers, storage drives, CD-ROMs, DVDs, and combinations thereof. In certain embodiments herein, the storage drives include those selected from the group of disk drives, flash memory, magnetic tape, and combinations thereof; or hard disks, floppy disks, magneto-optical disks, flash memory, magnetic tape, optical storage media, solid storage media, 5D data storage devices, waterproof glass "disks", and combinations thereof; or hard disks, flash memory, and combinations thereof.

[0098] In certain embodiments herein, the methods and / or systems herein include a plurality of storage media.

[0099] In certain embodiments herein, the multiple storage media, or each of the multiple storage media, is located at a different physical location. Without intending to be limited by theory, it is believed that such a distributed system provides business continuity and disaster management benefits in the event of events such as, for example, natural disasters, power outages, war, political unrest, etc. Furthermore, in certain embodiments herein, one or more of the multiple storage media and / or their data is held by an organization such as a trusted organization, or a trusted international organization, or a non-partisan organization, or a non-profit organization, or a national patent office, or a social enterprise. In certain embodiments herein, the organization is selected from the group consisting of the Austrian Patent Office (APO), China Council for the Promotion of International Trade (CCPIT), European Patent Office (EPO), Intellectual Property Office of Singapore (IPOS), International Intellectual Property Commercialization Council (IIPCC), China National Intellectual Property Administration (CNIPA, also known as China Intellectual Property Office), Swiss Federal Institute of Intellectual Property (FIIP), United States Patent and Trademark Office (USPTO), State Administration for Market Supervision (SMSA in China), World Intellectual Property Organization (WIPO), Library of Congress, and combinations thereof; or the Intellectual Property Office of Singapore (IPOS), International Intellectual Property Commercialization Council (IIPCC), World Intellectual Property Organization (WIPO), State Administration for Market Supervision (SMSA in China), and combinations thereof. In the event that an organization changes its name upon merger, acquisition, sale, etc., the term "organization" as used herein includes the successor in interest.

[0100] In certain embodiments herein, the multiple storage media herein are electronically and physically isolated from one another. Without intending to be limited by theory, it is believed that such a system provides improved security and reliability compared to a comparable inter-networked system and / or a system having only a single physical location. Such a system distributed across multiple locations can also provide a reliable backup, for example, if one of the locations is hacked, altered, held hostage for ransom, etc.

[0101] In FIG. 1, it can be seen that in certain embodiments herein, the method may include a delivery step 40, 40', etc., where the evidence key 32 and / or additional associated data 43 are delivered to a party or to a party, organization, server, account, etc. that originally made the evidence key request 22 to form a delivered evidence key 42, 42', etc. In certain embodiments herein, the delivery step 40 includes delivery of the evidence key 32 and additional associated data 34 to the account that originally made the evidence key request 22. Such delivery may be via channels such as, for example, email, text message, electronic message service, mail, transmission over the Internet, and combinations thereof; or via email, mail, text message, and combinations thereof. Without intending to be limited by theory, it is believed that such delivery helps to increase the likelihood that a requester will be able to provide sufficient information to be able to successfully retrieve the stored evidence key when retrieval is requested.

[0102] In Figure 1, memory 36' is shown in parallel with memory 36. However, in some embodiments of the invention, memory 36' is in series with memory 36 (see, for example, Figure 3).

[0103] FIG. 2 shows a diagram of an embodiment of the invention herein. Here, the computer-implemented method herein includes a retrieval request 44, which then initiates a retrieval step 44, 44', etc. The retrieval step 44 initiates a process in which the system retrieves the evidence key and / or any additional associated data to form a retrieved evidence key 48, 48', etc. The retrieved evidence key 48 is then subjected to a comparison step 50, 50', etc., in which the retrieved evidence key 48 is compared with the stored evidence key 38 and / or the delivered evidence key 42. In an embodiment herein, the comparison step results in a retrieval request result 52, 52', etc. In an embodiment herein, the comparison step 50 compares the delivered evidence key 42 (and additional associated data, if any (see 34 in FIG. 1)) with the retrieved evidence key 48 (and the respective additional associated data, if any). The comparison step 50 can then highlight in the retrieval request result 52 whether there was any mismatch between the delivered evidence key 42 and the retrieved evidence key 48 or whether they match.

[0104] Without intending to be limited by theory, it is believed that if the delivered evidence key 42 and the retrieved evidence key 48 match, they may serve as proof, or a rebuttable presumption of proof, that the digital document existed and / or was in the possession of the party at a point in time, such as when the evidence key request was submitted.

[0105] Those skilled in the art will appreciate that similar parallel processes for retrieval step 46' and stored evidence key 38' in FIG. 2 are contemplated for embodiments of the invention herein. Without intending to be limited by theory, it is believed that having such parallel retrieval 46', comparison 50', etc. provides an additional layer of security and assurance to the user that the method and system are sound and data integrity is intact. Conversely, if different results are retrieved from those parallel processes, that may indicate that data integrity has been compromised in some way. In some embodiments of the invention, when different results are retrieved, a log is generated, an entity such as a system administrator is notified, or a combination thereof.

[0106] FIG. 3 shows a flow diagram of a computer-implemented method for evidencing the existence of a digital document according to an embodiment of the present invention. Specifically, it is a flow diagram of a method 50 for evidencing the existence of a digital document 20, in which in a first step 52, an evidence key request 22 is received. As described herein, an evidence key request is a request from a user to generate an evidence key for the digital document (see 20 in FIG. 1). Then, in step 54, an evidence key 32 is generated by an evidence key generator (see 24 in FIG. 1). Once the evidence key 32 is generated, it is stored in a first storage 36, as shown in step 56, together with any additional associated data (see 34 in FIG. 1). In this embodiment, a second storage 36' is created in step 58 based on the first storage (see 36 in FIG. 1). Thus, the first storage 36 and the second storage 36' are arranged sequentially, not in parallel as shown in FIG. 1. In an embodiment herein, the first storage 36 and the second storage 36' are located on different independent servers. For example, during a dispute that arises about who originally created a file or who copied whom, the user, the owner, and / or any relevant third party may be granted access to retrieve the evidence key 32 and any additional associated data (see 34 in FIG. 1) from the second storage 36'. Retrieval of the evidence key 32 and any additional associated data (see 34 in FIG. 1) may be performed by methods and algorithms known in the art, such as, for example, a search engine running on the storage device 36, 36', etc.

[0107] FIG. 4 is a detailed flow diagram of step 54 of the computer-implemented method 50 according to the embodiment shown in FIG. 3. In step 62, the timestamp 26 of the digital document 20 is obtained. Then, in step 64, a cryptographic hash 28 is generated based on a cryptographic hash function. In a particular embodiment, the cryptographic hash function is a keyless cryptographic hash function selected from the group of SHA2-256, SHA2-512, and SHA3-256. In step 66, a cryptographic hash 28' is generated based on a (second) cryptographic hash function that is different from the (first) cryptographic hash function that generated the cryptographic hash 28. In one embodiment of the invention, the (second) cryptographic hash function is a hash function selected from the group consisting of SHA2-256, SHA2-512, and SHA3-256. In step 68, after obtaining the timestamp 26, the cryptographic hash 28, and the cryptographic hash 28', an evidence key 32 is generated based on the timestamp 26, the cryptographic hash 28, and the cryptographic hash 28'.

[0108] FIG. 5 shows another embodiment of the invention directed to a computer system 70 for evidencing the existence of a digital document 20. The system 70 includes an evidence key generator 24 at a user's system 72 configured to generate an evidence key 32 for the digital document 20, for example according to step 54 of the method 50 of FIG. 3. The system 70 further includes a (first) receiving server 74 and a (second) receiving server 74' configured to receive the evidence key (see 32 in FIG. 1) once generated by the evidence key generator 24. Each receiving server 74 and 74' is independently coupled to a (first) storage server 76, a (second) storage server 76', and a (third) storage server 76". Each storage server 76, 76', 76" stores the evidence key (see 32 in FIG. 1) in its own database. Each storage server 76, 76', 76" is independently coupled to an aggregated storage server 78. After receiving database and server identification information from each storage server 76, 76', 76", the aggregated storage server 78 is configured to create a second database based on the new timestamp and the information received from the storage servers 76, 76', 76".

[0109] In one embodiment of the invention, the new timestamp is the time that the aggregated storage server 78 receives the particular evidence key 32. In one embodiment, evidence key generator 24 is configured to send the evidence key (see 32 in FIG. 1) to receiving server 74 and receiving server 74' immediately after the evidence key (see 32 in FIG. 1) is generated. In another embodiment, storage servers 76, 76', and 76'' are configured to send their respective databases to the aggregated storage server 78 in batch mode.

[0110] System 70 further includes an external storage server 80 that is a mirror of central storage server 78. In one embodiment, external storage server 80 is not accessible to any users of system 70 and serves as a disaster recovery backup. In yet another embodiment, a search engine (not shown in FIG. 5) is coupled to central storage server 78 and / or external storage server 80, thereby allowing a user or any interested third party to retrieve, upon request, evidence key 32 for a particular digital document and any additional associated data (see 34 in FIG. 1).

[0111] According to one embodiment of the present invention, the database contains, for each evidence key, an entry as shown in Table 1. [Table 1]

[0112] In Table 1, the evidence key is any combination of a timestamp, a cryptographic hash, and / or additional associated data.

[0113] In one embodiment herein, the second database includes the new timestamp and all of the entries in the (first) database. In yet another embodiment, the system 70 further includes a file properties editor configured to obtain the digital file size and the digital file name.

[0114] In another embodiment, the system 70 further includes a biometric sensor configured to capture at least one biometric factor of the user for authentication purposes.

[0115] FIG. 6 shows an embodiment of the invention describing a computer-implemented method for synchronizing the clocks of storage servers 76, 76', 76", etc. Each of storage servers 76, 76', 76" is independently coupled to a time server 82, a time server 82', and an independent clock 84. When storage server 76, 76', 76" receives an evidence key (see 32 in FIG. 1) from an evidence key generator (see 24 in FIG. 1), the storage server requests timestamps from time server 82, time server 82', and independent clock 84, respectively. Storage server 76, 76', 76" is further configured to assign the earliest timestamps received from time server 76, second time server 76', and independent clock 78 as the receipt time of that particular evidence key (see 32 in FIG. 1) in a database, e.g., as additional associated data. In one embodiment, both time server 76 and time server 76' employ a network time protocol, while independent clock 78 is a GPS clock.

[0116] FIG. 7 shows an algorithm structure 86 according to an embodiment of the present invention. The algorithm 86 is implemented in the aggregate storage server (see 78 in FIG. 5) to ensure data integrity. In step 88, when the storage servers 76, 76', 76" etc. send evidence keys to the aggregate storage server (see 78 in FIG. 5), the aggregate storage server (see 78 in FIG. 5) determines (condition 90) whether it has received corresponding evidence keys from all storage servers 76, 76', 76" etc. within a predefined time period. If the aggregate storage server (see 78 in FIG. 5) has received corresponding evidence keys from all storage servers 76, 76', 76" etc. within the predefined time period, in step 92 the evidence keys are stored in a database located at the aggregate storage server (see 78 in FIG. 5).

[0117] On the other hand, if the aggregation server (see 78 in FIG. 5) does not receive the corresponding evidence key from any one of the storage servers 76, 76', 76", etc. within a predetermined time, then in step 94 the aggregate storage server (see 78 in FIG. 5) specifically requests the missing evidence key from the particular storage server(s) whose corresponding evidence key is missing or delayed. In step 96 the aggregate storage server (see 78 in FIG. 5) checks to see if that particular storage server 76 is reachable. If the particular storage server 76, 76', 76", etc. is not reachable, then in step 98 the aggregate storage server (see 78 in FIG. 5) alerts the administrator of the system (see 70 in FIG. 5). Alternatively, the aggregate storage server may record this in an error log or otherwise record the discrepancy. However, if a storage server 76, 76', 76", etc. is reachable, that particular storage server 76 checks whether the missing evidence key 32 is present in its own database, and if found (condition 100), the particular storage server 76 sends the missing evidence key 32 to the aggregate storage server (see 78 in FIG. 5). The aggregate storage server (see 78 in FIG. 5) then stores the evidence key 32 in its database (step 92).

[0118] If the missing evidence key 32 is not found within that particular storage server 76 (condition 100), then in step 102 a log regarding the missing evidence key 32 is saved, for example in an error log.

[0119] FIG. 8A illustrates an embodiment of a computer-implemented method of the present invention for generating a checksum. In step 801, a current checksum is generated based on a plurality of cryptographic hashes or a cryptographic hash received during a first time period. The first time period is in a range of about a few milliseconds to about one month. The shorter the first time period, the sooner the current checksum is generated (i.e., the shorter the time between checksum generation), and the more checksums are generated and stored, the greater the load on the computing resources required. The longer the first time period, the slower the current checksum is generated (i.e., the longer the time between checksum generation), and the less checksums are generated and stored, the lower the load on the computing resources required. The checksum is used to ensure the integrity of the plurality of stored cryptographic hashes. For example, a second checksum is created using the cryptographic hash to detect whether one or more of the cryptographic hashes stored in a database, etc., have been altered or tampered with. If the original checksum does not match the second checksum, this indicates that at least one of the cryptographic hashes stored in the database has been altered or tampered with.

[0120] Those skilled in the art will appreciate that there are a myriad of ways to generate a checksum. For example, a checksum can be generated using, for example, a cryptographic hash algorithm, a block parity function, a cyclic redundancy check (CRC), and combinations thereof. It is preferable to use a cryptographic hash function, such as SHA2 and / or SHA3, to generate the checksum so that the probability of a hash collision is relatively low.

[0121] In one example, the first time period is one minute.

[0122] For illustrative purposes only, there may be, for example, 100 cryptographic hashes received during a first time period. First, a string is generated by concatenating the 100 cryptographic hashes in the order in which they were received. A current checksum is then generated by applying, for example, a SHA2-256 hash function to the string. In one example, the string is in hexadecimal format. In another example, the string is in 64-base format.

[0123] At step 802, the current checksum is stored in a storage medium as described herein. The checksum is typically stored in a non-volatile storage medium (i.e., a non-volatile computer-readable storage medium) and is preferably maintained for a period of time, e.g., for years, or even indefinitely. Because the multiple cryptographic hashes and corresponding evidence keys may be used as court evidence years later, the checksum should also be stored for years, or even indefinitely, to further prove that none of the multiple cryptographic hashes and corresponding evidence keys have been altered or tweaked.

[0124] In step 803, a next checksum is generated based on the current hash and another plurality of cryptographic hashes received during the next time period. In one embodiment herein, the next time period is one minute and begins at the end of the first time period.

[0125] For example purposes only, there may be, for example, 30 cryptographic hashes received during the following time period: First, a string is generated by concatenating the 30 100 cryptographic hashes in the order in which they were received and the current checksum. The next checksum is generated by applying, for example, a SHA2-256 hash function to the string.

[0126] In step 804, the next checksum is stored in the same manner as the current checksum stored in step 802. In step 805, the value of the current checksum is updated and replaced with the value of the next checksum. The updated current checksum is used to generate another next checksum at the next time period in the future. In some embodiments herein, step 805 is performed before step 804, where the current checksum is stored instead.

[0127] The next checksum is generated based in part on the current checksum, which is in turn generated in part on the past checksums, and so the next checksum is generated in part on the past checksums. Even if one or more of the past checksums are lost or not stored, it is contemplated in certain embodiments herein that the current checksum can still be regenerated using all of the received cryptographic hashes. Those skilled in the art will appreciate that by comparing the regenerated checksum with the stored past checksums, the integrity of the stored cryptographic hashes can be verified.

[0128] In one embodiment of the invention, instead of generating the current and next checksums on a time basis in steps 801 and 803, the generation is based on a predetermined number of cryptographic hashes received, for example, a checksum is generated every 300 cryptographic hashes received.

[0129] FIG. 8B illustrates an embodiment of a computer-implemented method for generating a checksum of the present invention. The steps of FIG. 8B are similar to those of FIG. 8A. Steps 801 and 803 are replaced by steps 811 and 813, respectively. Compared with step 801, a current checksum is generated based on multiple evidence keys generated during a first time period in step 811, instead of based on multiple cryptographic hashes as in FIG. 8A. Similarly, in step 813, a next checksum is generated based on multiple evidence keys generated during a next time period. Since the evidence key is based on a timestamp and multiple cryptographic hashes or a single cryptographic hash, the checksum can be further used to verify that the timestamp, multiple cryptographic hashes, and / or additional associated data stored in the evidence key have not been modified and / or tampered with.

[0130] 9 illustrates another embodiment of the computer-implemented method of the present invention for generating checksums. A number of current checksums, for example C1 and C2, are used to generate next checksums NC1 and NC2, respectively. In step 901, a current checksum C1 is generated based on a number of cryptographic hashes or a single cryptographic hash received during a first time period. In step 902, the current checksum C1 is stored in a storage medium. In step 903, another current checksum C2 is generated based on a number of cryptographic hashes or a single cryptographic hash received during a second time period. In step 904, the current checksum C2 is stored in the same manner as the current checksum stored in step 902.

[0131] The generation of the current checksum C2 is not based on the current checksum C1 and the cryptographic hashes or one cryptographic hash received during the first time period. Thus, while the current checksum C1 is calculated in 901 and stored in step 902, the current checksum C2 is generated independently without using any information of the current checksum C1, such as the cryptographic hashes or one cryptographic hash received during the first time period. When the current checksum C1 is being processed by a processor of the system, such as a central processor, the cryptographic hash may have already arrived during the second time period, and so on.

[0132] In an embodiment of the present specification, by the time the current checksum C1 is generated, the second time period may have ended and the third time period may have already begun. In order to allow more time to calculate the current checksum, multiple current checksums are used. Thus, those skilled in the art will understand that there is no actual limitation that only two current checksums C1 and C2 may be used, but this embodiment is described as such simply for ease of understanding. In order to allow even more time to calculate the current checksum, more current checksums may be used, for example, about 5 current checksums, or about 7 current checksums, or about 10 current checksums, or about 25 current checksums, or about 50 current checksums, or about 100 current checksums.

[0133] In step 905, a next checksum NC1 is generated based on another plurality of cryptographic hashes received during the next time period and the current checksum C1. The next checksum NC1 is generated without using information of the current checksum C2, the plurality of cryptographic hashes received during the second time period or a cryptographic hash. Thus, the computing / processing unit of the system has more time to generate the current checksum C2.

[0134] In step 906, the next checksum NC1 is stored in the same manner as the current checksum was stored in step 902. In step 907, the value of the current checksum C1 is updated and replaced with the value of the next checksum NC1.

[0135] In step 908, a next checksum NC2 is generated based on another plurality of cryptographic hashes received during the next time period and the current checksum C2. The next checksum NC2 is generated without using any information from the current checksum NC1, such as the plurality of cryptographic hashes or a cryptographic hash received during the time period of steps 905-906. Thus, the processing unit of the system has more time to generate the current checksum NC1.

[0136] In step 909, another next checksum NC2 is stored in the same manner that the current checksum was stored in steps 902 and 904. In step 910, the value of the current checksum C2 is updated and replaced with the value of the next checksum NC2.

[0137] If more time is needed to generate the next checksum, steps 905-910 can be further expanded to have, for example, the next checksums NC3, NC4, NC5, and so on.

[0138] In certain embodiments of the methods herein, e.g., as described in Figures 8A, 8B, and 9, the iterative checksum generation and replacement steps essentially outline the steps of a blockchain that function to authenticate the integrity of the database formed thereby.

[0139] In certain embodiments herein, the current checksum 802 is an initial coin offering (ICO); or the ICO is a cryptocurrency; or the cryptocurrency is Bitcoin, Litecoin, Namecoin, SwiftCoin, bytecoin, peercoin, dogecoi, Emercoin, Feathercoin, Gridcoin, Primecoin, Ripple, Next, Auroracoin, Dash, NEO, MazaCoin, Monero, NEM, PotCoin, Synero AMP, Titcoin, Verge, Stellar, Vercoin, Ethereum, Ethereum Classic, Tether, Decred, Waves Platform, Zcash, BitConnect, Bitcoin Cash, EOS IO, Cadano, Petro, Petro Gold, Inu Shiba, etc. The generation of the next checksum 804 and the replacement of the current checksum 802 with the next checksum 804 is essentially treated as a transaction and recorded in a database. The database may be stored, for example, in a storage server (see, for example, 76, 778, 80, etc. in FIG. 5) or in a ledger stored on a server or computer system.

[0140] In certain embodiments of FIG. 9 herein, the first time period, the second time period, etc. are alternating predetermined time periods and / or are arranged on a mutually exclusive alternating schedule.

[0141] The methods herein may be implemented by a computer. Further, the systems herein may be computer systems.

[0142] FIG. 10 shows a schematic diagram of an embodiment of the tag (block) chain of the present invention. In FIG. 10, a computer-implemented first blockchain 1000 is initiated when a first link C1 is generated, typically with a checksum generated via a cryptographic hash. A link here can be a single checksum or multiple checksums. A link herein can be and / or represent, for example, a single transaction, multiple transactions, transfers, multiple transfers, a time period, a device (e.g., an electronic device) or multiple devices, and combinations thereof; or, for example, multiple transactions occurring during a time period. A second blockchain 1002 is initiated when a link C2 is generated, typically with a checksum generated via a cryptographic hash. For this embodiment, assuming each link is a single checksum, in contrast to a typical blockchain, in the embodied tag chain, checksum C1 does not link to checksum C2 to form the next link in the chain. Instead, checksum C1 links to checksum C3, which then links to checksum C5, and so on. Similarly, checksum C2 links to checksum C4, which then links to checksum C6, etc. In the embodiment of Figure 10, a third blockchain 1004, whose first block is checksum C7, is added to the tag chain system after a first blockchain 1000 and a second blockchain 1002 have already been established. In some embodiments herein, multiple blockchains are added to the tag chain system after multiple blockchains already exist in the tag chain system.

[0143] In the schematic representation of FIG. 10, each checksum represents a single link in a chain 1000, 1002, 1004, etc. Thus, all of the odd checksums from C1 through C6 form chain 1000, and all of the even checksums from C1 through C6 form a separate, mutually exclusive chain 1002. Thus, this embodiment is described as a “tag-chain” type of blockchain. In essence, one chain (or all other chains) is “tag-out” while one chain is “tag-in,” meaning that it is active and therefore eligible to be connected to or otherwise eligible to receive new links in the chain. However, these chains are mutually exclusive, and thus only a single chain can be “tag-in” at any given point. These chains (and potentially other chains) alternate between active (i.e., receiving new links) and inactive (waiting to receive new links). In FIG. 10, checksum C7 represents the first link (and the start) of the new chain 1004.

[0144] In some embodiments herein, only a single chain is active at any given time.

[0145] Thus, the tag chain system includes at least a first chain and a second chain that are mutually exclusive. In some embodiments herein, each chain is mutually exclusive. However, in some embodiments herein, the first chain and the second chain (and any other chains) are intertwined within the same blockchain system. In some embodiments herein, the checksums alternate between different chains, and one of ordinary skill in the art can appreciate that various patterns are possible, including but not limited to those defined herein. In such embodiments, the chains being mutually exclusive may mean that they do not contain any common links between them.

[0146] In some embodiments herein, the checksums are not linked into odd and even checksums, but may be linked in different patterns or in multiple separate chains. In some embodiments herein, the chains are separated using a sequence logic, for example 1, 3, 5, 7, etc., which may be embedded within the checksums. In some embodiments herein, the separation of the various links into different chains is via a time period, a number of checksums, a portion of the checksum, a modification to each checksum, a modulo method, one or more devices, an address, a unique identifier, and combinations thereof; or a predefined time period, a predefined number of checksums, a predefined portion of the checksum (or each checksum), a prefix modification to each checksum, a suffix modification to each checksum, a modulo method, one or more devices, an address, a unique identifier, and combinations thereof.

[0147] For example, if the predefined time period is one hour, then each hour represents a separate link in the chain (e.g., C1 in FIG. 10). Upon reaching the expiration of the one hour, the next link (e.g., C2 in FIG. 10) is initiated and may be assigned to a different chain or the same chain, as desired. In another example, if the number of checksums (in each link) is 1000, or if the predefined number of checksums is 1000, then a different link is created for every 1000 checksums. There may be a pool of links or checksums that are typically placed / assigned to chains in a first-in, first-out (FIFO) order. In yet another example, the selection of the chain for each link (or checksum) may be done using a modulo operation (see https: / / en.wikipedia.org / wiki / Modulo_operation) by dividing the link (or checksum) by a number and using the remainder to select the chain to which to assign the link. In another example, a portion of the checksum, e.g., three alphanumeric digits (prefix, suffix, or middle portion), is used to assign the checksum to the appropriate chain. In such an embodiment, for example, if the checksum is "12313393990A381F10" and the link is determined by the suffix, the system will recognize "F10" as the suffix and assign this link to the "F10" chain. This is a common technique for "random" + round-robin (chain) selection.

[0148] In certain embodiments herein, a modification to each checksum is used, for example, three or more alphanumeric digits (prefix, suffix, or middle) are added to each link and used to assign the link to the appropriate chain. In such an embodiment, for example, if a link (or checksum) is "12313393990A381F10," the system may add the alphanumeric digits "E35" to the beginning, middle, or end of this link, and then assign this link to the "E35" chain.

[0149] In some embodiments herein, the checksums, links, and / or chains may be divided according to different devices and / or by identifying different addresses, or IP addresses, machine addresses, email identifiers, account identifiers, etc. In some embodiments herein, each device is assumed to possess a different address.

[0150] In certain embodiments herein, the first chain and the second chain are stored on the same server. Without intending to be limited by theory, it is believed that this may be desirable from a system architecture perspective as it may make the tag chain system easier to manage. In certain embodiments herein, the first chain and the second chain are stored on different servers. Without intending to be limited by theory, it is believed that this may be desirable from a system architecture perspective as it may make the tag chain system more secure.

[0151] In certain embodiments herein, additional chains may be added when determined by an administrator or when the tag chain system recognizes that the current time, energy requirements, etc. to generate the next link in the chain is excessive or above a predetermined value. Alternatively, the tag chain system may add one or more additional chains when a predetermined criterion is reached, such as a predetermined number of links in the existing chain and / or most recent chain, a predetermined time period, etc.

[0152] For example, different links (and thus chains) may be separated by a particular time period, or a group of checksums, a group of transactions, etc. In certain embodiments herein, each link in a chain includes from about 1 transaction to about 1,000,000 transactions, or from about 1 to about 10,000 transactions, or from about 1 to about 1,000 transactions, or from about 2 transactions to about 10,000 transactions, or from about 100 transactions to about 1,000 transactions. In certain embodiments herein, the links for each chain are defined by a time interval, and all transactions and / or checksums occurring within the time interval may form a link (for the appropriate chain) and / or be aggregated into a single link (for the appropriate chain). In certain embodiments herein, the time interval is from about 1 millisecond to about 1 month, or from about 1 second to about 1 week, or from about 1 minute to about 1 day, as measured by the computer-implemented tag chain system and / or server(s). Alternatively, the time interval may be measured by, for example, an internal computer clock, a process, or that of an external server.

[0153] Without intending to be limited by theory, it is believed that the tag chains herein may provide significant advantages over a single, unified blockchain. For example, it is believed that as blockchains become increasingly longer, checksum timing (e.g., the time it takes to generate a cryptographic hash) also increases over time, requiring more energy, and / or requiring more computing time. It is believed that by employing tag chains, and thus multiple actual chains within a single blockchain system, the overall speed of the blockchain system may be accelerated and / or may even have additional advantages, such as lower energy consumption, shorter computation time, etc., since the length of each of the individual chains increases more slowly.

[0154] In some embodiments herein, the different chains in the tag chain system are implemented and / or stored in one or more common servers. In some embodiments herein, each of the different chains in the tag chain system is implemented and / or stored on a different server or different servers. In some embodiments herein, each of the different chains in the tag chain system is implemented and / or stored on multiple servers.

[0155] FIG. 11 illustrates a schematic flow diagram of one embodiment of the method 10 of the present invention, where a document 20, here a digital document, is located within a user's system 72 and / or within the control of a user 72. The user's system 72 obtains metadata 200 for the digital document 20. The user also provides user consent 202 for various actions and processes, which typically includes permissions and restrictions for sharing information, data, etc. with and / or between other systems, such as the user's system, remote devices, third party users, third party user's systems, etc. The user consent 202 may be transmitted to remote devices, third party users, third party user's systems, etc., as appropriate.

[0156] In FIG. 11 , the user provides the user agreement 202, typically while within the user's own system 72. However, it will be appreciated that in alternative embodiments, the user may provide the user agreement 202 at a third-party user's system, etc. The user's system 72 generates a cryptographic hash 28 from the digital document 20 and optionally from the metadata 200 or a portion thereof. The user's system 72 transmits the metadata 200, the cryptographic hash, and optionally the user agreement 202, typically over the Internet, to a remote device 204, which receives the metadata 200, the cryptographic hash, and optionally the user agreement 202.

[0157] As used in the figures, lines between features of the invention indicate that the features may be transmitted and / or received between the features.

[0158] The remote device 204 requests a timestamp (see 26 in FIG. 1) from a time source 206, which sends the timestamp to the evidence key generator 24. In the embodiment of FIG. 11, the time source 206 is a time source system 207 separate from the remote device 204. The evidence key generator 24 then generates an evidence key 32, which is sent to storage 36. The evidence key 32 may optionally be sent to and received by the user 72 and / or the user's system 72.

[0159] 11, it can be seen that the additional metadata 210 can be obtained from sources such as the user, the user's system, and combinations thereof. The additional metadata 210 can be sent to and received by the remote device 204, the additional evidence generator 208, the third party 212, and combinations thereof. In certain embodiments herein to further improve security, the additional metadata 210 is sent to the third party 212 and received by the third party 120, but not sent to the remote device 204 or only to the third party 212.

[0160] 11, further evidence key generator 208 generates a further cryptographic hash 214 of evidence key 32 to form further evidence key 216. Further evidence key generator 208 generates a further cryptographic hash from the evidence key. The further timestamp may be requested, for example, by further evidence key generator 208 from the same or a different time source 206 as timestamp 26.

[0161] The timestamp may further include time source metadata 209 associated with and / or embedded in the timestamp.

[0162] Further evidence key generator 208 generates a further cryptographic hash 212 from the evidence key, and optionally from the cryptographic hash, the metadata, the timestamp, the further timestamp, the further metadata, and combinations thereof. The further cryptographic hash then forms a further evidence key 216, which is stored in storage 36 to form a stored further evidence key 218. Further evidence key 216 may also optionally be transmitted to and received by user 72 and / or user's system 72.

[0163] FIG. 12 shows a schematic flow diagram of one embodiment of the method 10 of the present invention for anonymously evidencing the existence of a digital document 20, which is useful, for example, in verifying age, vaccination status, etc., while keeping name and personal details private. The user obtains metadata 200 and cryptographic hash 28 from the digital document 20, such as a vaccination status certificate, within the user's control / system. The user also provides user consent 202 associated with the digital document, regarding who may access the digital document and under what conditions. The user may also provide further metadata 210 regarding the digital document, and / or terms of use of the metadata, cryptographic hash, user consent, etc. In the embodiment of FIG. 12, all of this is transmitted to a remote device 204, which then transmits a request for identity data 224 to an identity source 220, such as a government agency and / or government website. To further protect the user's privacy, the identity source 220 generates a cryptographic hash of the identity data 222 to form the identity hash 224. The identity source 220 then transmits the identity hash 224 to the remote device 204. The identity source may optionally further provide identity metadata 226 to the remote device 204, which may relate to, for example, the identity server identity, the identity data, the user, the identity hash, the cryptographic hash algorithm and / or protocol used, etc.

[0164] In FIG. 12, the remote device 204 also simultaneously requests a timestamp (see 26 in FIG. 1) from the time source 206, which sends the timestamp to the remote device 204. However, in some embodiments, when the evidence key generator 24 is separate from the remote device 204, the time source 206 may send the timestamp (see 26 in FIG. 1) directly to the evidence key generator 24. The remote device 204 combines the identity hash 224, the metadata 200, and the cryptographic hash 28 in the evidence key generator 24 to provide the evidence key 32. The remote device 204 may further include additional features in the evidence key 32, such as further metadata 210, a timestamp (see 26 in FIG. 1), identity metadata 226, user consent 202, etc., as desired. The user also provides user consent 202 for various actions and processes, which typically includes permissions and restrictions for sharing information, data, etc. with and / or between other systems, such as the user's system, remote devices, third party users, third party user's systems, etc., and the user consent 202 may be transmitted to remote devices, third party users, third party user's systems, etc. as needed.

[0165] Evidence key 32 is then typically stored by sending it to a storage device 36 to form a stored evidence key 38 .

[0166] The evidence key may also optionally be transmitted to, for example, the user / user's system 72, third party 212, etc., according to instructions / permissions therefor that are typically found in the user agreement 202. The evidence key 32 may also be used to generate a reference code 228 that may then be transmitted to, for example, the user / user's system 72, third party 212, etc., according to instructions / permissions therefor that are typically found in the user agreement 202.

[0167] A third party 212 or user 72 in possession of the reference code 228 is then allowed access to the evidence key 32 and / or the stored evidence key 38. For example, if the reference code is a QR code, the digital document is a vaccination record, the user consent allows the category of "restaurant" to access the evidence key, and a restaurant requires proof of vaccination status for entry, the user can show the QR code to the restaurant upon entry. The restaurant may scan the QR code and be directed to a government or health provider website / database that shows the user's photo and confirmation or denial of vaccination status. The restaurant can then be confident that the user has been vaccinated. The user does not need to disclose other personal information such as address, name, date of birth, other health information, etc.

[0168] In another example similar to the above, except that the digital document is a driver's license or passport, the user's consent allows a category of "bars" to access the evidence key. The bar is required to check proof of age upon entry. The user may present a QR code to the bar upon entry, which may then scan the QR code and be directed to a government or other official website that confirms or denies that the user is of legal age to enter the bar. This ensures the bar that the user is of age, and the user does not need to show or disclose to the bar any additional information, such as name, address, blood type, etc., that is typically present on a driver's license, for example.

[0169] It will be appreciated that storage 36 may be, for example, a private storage device, a government / public storage device, or combinations thereof, such as by a trusted organization, etc. Without intending to be limited by theory, it is believed that such configurations may be useful to balance the privacy concerns of the user with the privacy concerns of the government, society, etc.

[0170] 13 shows a schematic flow diagram of one embodiment of the method 10 of the present invention for evidencing the existence of a digital document 20. The digital document 20, the cryptographic hash 28, and other non-hashed user data 230 are provided / generated as described herein for a user / user's system. Non-hashed user data herein includes, for example, metadata 200, further metadata 201, user consent 202, and combinations thereof.

[0171] The log 230 contains a record of previous cryptographic hashes generated by the user / user's system. The log organization is not important and can be by cryptographic hash, by the user's system's time clock, or in any manner so long as the cryptographic hash is retrievable. In step 234, the user's system receives the cryptographic hash 28 and queries the log 232 to see if the same cryptographic hash 28 is already present in the log 232. If the same cryptographic hash 28 is not already present in the log 232, the cryptographic hash (and other information) is transmitted to the remote device 204, third party user, etc., in accordance with the invention herein, whereas if the cryptographic hash 28 is already present in the log 232, the cryptographic hash and unhashed user data 230 are not transmitted to the remote device 204, third party user, etc. It is recognized that within the system described herein, the database may potentially capture millions, if not billions, of evidence keys. It is further recognized that the same digital document may have cryptographic hashes generated for that digital document multiple times. However, a user may wish to have a complete record of their digital documents, but it is inefficient for the same cryptographic hash to be sent to a remote device multiple times by the same user. Thus, this embodiment seeks to reduce unnecessary duplicate cryptographic hashes being sent to remote devices, thereby reducing unnecessary generation of evidence keys.

[0172] In another embodiment herein, step 234 checks the cryptographic hash 28, as well as the non-hashed user data 230, to see if it matches the data in the log 232. If step 234 detects an exact match of the cryptographic hash 28 and the non-hashed user data 230, the user's system 72 does not transmit the cryptographic hash and non-hashed user data 230 to the remote device 204, third party user, etc. However, if the user's system 72 does not detect an exact match of the cryptographic hash 28 and the non-hashed user data 230, the user's system 72 transmits the cryptographic hash and non-hashed user data 230 to the remote device 204, third party user, etc. It will be appreciated that an advantage of this embodiment is that it allows the user to, for example, update a user agreement and send it to the remote device to be updated in the system.

[0173] 13, if cryptographic hashes and non-hashed user data are sent to the remote device 204, then in step 236 the user's system 72 typically also updates the log 232 to include the cryptographic hash 28 and / or the non-hashed user data 230. This step helps keep the log 232 updated and current.

[0174] Fig. 14 shows a schematic flow diagram of one embodiment of the method 10 of the present invention for evidencing the existence of a digital document 20, in which the user / user system 72 obtains the metadata 200, the cryptographic hash 28, the further metadata 210, and the user consent 202 as described herein and transmits them to the remote device 204, which receives them. The remote device 204 requests a timestamp (see 26 in Fig. 1) from a time source 206, which transmits the timestamp (see 26 in Fig. 1) to the remote device 204, which in Fig. 14 is the evidence key generator 24. The evidence key generator 24 generates the evidence key 32 and transmits it to the user / user system 72 and the storage device 36, which in turn forms the stored evidence key 38, as usual.

[0175] 14, remote device 204 collects multiple evidence keys 32, 32′, etc. and combines them to form composite evidence key 232. The composite evidence key may or may not be subjected to a cryptographic hash step, as desired. The composite evidence key may be further associated with composite metadata 240, which may include, for example, how the multiple evidence keys are combined to form the composite evidence key and / or interrelationships between the evidence keys 32, 32′, etc., metadata 200, further metadata 210, user consent 202, and combinations thereof. The composite evidence key 232 is stored in storage device 38 to provide stored composite evidence key 242.

[0176] The composite evidence key 232, and optionally the composite metadata 240, the user consent 202, the further metadata 210, etc., are then provided to a further evidence key generator 208, which generates a further evidence key 216. The further evidence key 216 is stored in storage device 38 to provide a stored further evidence key 218.

[0177] Fig. 15 shows a schematic flow diagram of one embodiment of the method 10 of the present invention for verifying the integrity of a digital document 20, in which a user / user system 72 obtains the metadata 200, the cryptographic hash 28, the further metadata 210, and the user consent 202 as described herein and transmits them to a remote device 204, which receives them. The remote device 204 requests a timestamp (see 26 in Fig. 1) from a time source 206, which transmits the timestamp (see 26 in Fig. 1) to the remote device 204, which in Fig. 15 is the evidence key generator 24. The evidence key generator 24 generates an evidence key 32 and transmits it to the user / user system 72 and the storage device 36, which in turn forms the stored evidence key 38, as usual.

[0178] The third party 212 may use its third party system 248 to obtain the second cryptographic hash 250 (using the same cryptographic hash algorithm used to create the cryptographic hash 28) and optional second metadata 252. In step 254, the third party 212, user 72, remote device 204, etc. may then compare the cryptographic hash 28 in the evidence key 24 with the second cryptographic hash 250 to generate a comparison result 256. Alternatively, in step 254, the third party 212, user 72, remote device 204, etc. may then compare the entire evidence key 72 with the second metadata 252 and second cryptographic hash 250 to generate a comparison result. The comparison result may be very simple, simply a verification confirmation sent to the third party 212 that is very detailed, showing every single difference between the second metadata 252 and second cryptographic hash 250 and the stored evidence key 38, or anything in between. The comparison results may also be sent to the user / user system 72. The comparison results 256 may further include comparison metadata 258, which is metadata related to the comparison, such as a cryptographic hash, an evidence key, metadata, further metadata, a user agreement, second metadata, a second cryptographic hash, etc.

[0179] The user / user's system 72 and / or the remote device 204 may publish 246 the evidence key 32, for example, by posting it on a public website.

[0180] During the method of FIG. 15, the digital document remains in the user's system, the third party's system, or both. However, the digital document is not transmitted or otherwise provided to a remote device. As described herein, such a method is believed to engender trust, for example, by a third party intending to install the user's software package on the third party's system. By using such a method, if the third party receives a positive comparison result, the third party is assured that the software package has not been tampered with between the time the user generated the (first) cryptographic hash and the time the user generated the second cryptographic hash. Alternatively, if the software package has been tampered with, the cryptographic hash and the second cryptographic hash will not match, and this will be highlighted in the comparison result. The third party user would be wise to seek additional information and / or not install the software package on the third party system. If the comparison result is also sent to the user, the user may also investigate how and / or when the software package was modified.

[0181] In an embodiment herein, the central storage server creates a duplicate database of evidence keys and any additional associated data.

[0182] In yet another embodiment, the evidence key may also include a time-dependent key that is independent of the content or any properties of the digital document generated by the system.

[0183] In certain embodiments herein, the cryptographic hash is a quantum hash intended to be calculated by a quantum computer.

[0184] In certain embodiments herein, the cryptographic hash is a neural hash that uses a convolutional neural network to compute the hash and is therefore insensitive to small changes in the digital document or image.

[0185] In certain embodiments herein, the sending and / or receiving step, or multiple sending and / or multiple receiving steps, are accomplished using a form of public / private key encryption (e.g., asymmetric cryptography, asymmetric encryption, etc.), such as, for example, the SSL / TLS protocol. Such keys may be created using, for example, RSA, DSA, and / or ECC algorithms.

[0186] In some embodiments herein, the user's computer, or the user's server, or the user's web browser, for example, creates a cryptographic hash of the digital document. The user's computer, or the user's server, or the user's web browser may also transmit the cryptographic hash to a remote device, or an evidence key generator, or a storage device. In some embodiments herein, the user's computer, or the user's server, or the user's web browser collects metadata from the digital document and / or the user and transmits the metadata to a remote device, or an evidence key generator, or a storage device. In some embodiments herein, the user's computer, or the user's server, or the user's web browser collects additional metadata from the digital document and / or the user and transmits the additional metadata to a remote device, or an evidence key generator, or a storage device.

[0187] In some embodiments of the methods herein, a user uses a web browser to access a website, the user uses the web browser to select a digital document, and the web browser accesses an algorithm from the website to generate a cryptographic hash of the digital document. In some embodiments of the methods herein, a user uses a web browser to access a website, the user uses a user interface, such as a mouse pointer, to select the digital document, or the user drags and drops an image of the digital document onto a graphical user interface of the web browser, and the web browser accesses an algorithm from the website to generate a cryptographic hash of the digital document.

[0188] In some embodiments herein, the user's computer, or the user's server, or the user's web browser is behind a firewall, or is behind the user's firewall.

[0189] In certain embodiments herein, the methods and / or systems use two-factor identification, three-factor identification, and / or multi-factor identification in one or more steps to increase the security of the methods and / or systems.

[0190] In certain embodiments herein, a cryptographic hash is derived from the digital document and the metadata. In such a system, the metadata encapsulated by the cryptographic hash is transmitted from the user's system to the remote device. Such a feature is believed to further enhance the security of the system.

[0191] In certain embodiments herein, the digital document may include information selected from the group consisting of, for example, biometric information, financial information, health information, historical information, identity information, legal information, ownership information, personal information, relationship information, and combinations thereof. Biometric information may include, for example, facial recognition information, anatomical information, gait analysis information, eye information, fingerprint information, odor information, genetic information, hand geometry information, blood / vein information, typing rhythm information, signature information, voice information, behavior measurement information, etc., and corporate information may include, for example, information about a company, such as founding date, dissolution date, incorporation status, legal status, shareholders, allocated shares, assets, liabilities, meeting records, etc. Financial information may include, for example, bank information, brokerage information, loan information, portfolio information, etc. Health information may include, for example, health / medical history, blood type, major histocompatibility complex information, hospital records, vaccination information, etc. Historical information may include, for example, genealogy information, correlation with historical events and individuals, ancestry information, descendant information, etc. Identity information may include, for example, government and other identity documents, e.g., driver's license information, passport information, etc. Legal information may include, for example, contract information, estate information, will information, ownership information, chain of title information, transaction information, etc. Personal information may include, for example, relationship information, address information, marital information, dependency information, tax information, password information, etc.

[0192] In some embodiments of the methods herein, metadata other than the digital document itself, cryptographic hashes, timestamps, further cryptographic hashes, further metadata, evidence keys, further evidence keys, reference codes, etc. may be transmitted and / or received over the Internet, an intranet, and combinations thereof.

[0193] In certain embodiments herein, digital documents are never transmitted to a remote device and always remain within the user's control and / or system.

[0194] In some embodiments herein, the cryptographic hash is a distributable, interoperable cryptographic hash.

[0195] Certain embodiments of the present invention are specifically directed to one or more systems for carrying out the methods described herein.

[0196] For example, it will be understood by those skilled in the art that the number of timestamps, cryptographic hashes, cryptographic hash functions, evidence key generators, associated data, storage devices, receiving servers, storage servers, aggregate storage servers, etc. are not limited by the description herein. It will be understood that the actual number may be adjusted based on the actual implementation of the invention. Furthermore, additional algorithms may be implemented at different levels of the system to improve the reliability and integrity of the system. In one embodiment, if a duplicate evidence key is detected in any of the databases, a warning notification is provided to the system administrator and the earliest creator of such evidence key.

[0197] Although the present invention has been described above with reference to specific embodiments, it should be understood that the foregoing embodiments are provided by way of example only and do not limit or define the scope of the present invention. Various other embodiments, including but not limited to the following, are also within the scope of the claims. For example, the elements and components described herein may be further divided into additional components or combined together to form fewer components for performing the same functions.

[0198] Any of the functions disclosed herein may be implemented using means for performing those functions, including but not limited to any of the components disclosed herein, such as computer-related components described below.

[0199] The techniques described above may be implemented, for example, in hardware, one or more computer programs tangibly stored on one or more computer readable media, firmware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on (or executable by) a programmable computer including a processor, a processor-readable and / or writeable storage medium (including, for example, volatile and non-volatile memory and / or storage elements), input devices, and output devices. The program code may be applied to input entered using the input devices to perform the described functions and to generate output using the output devices.

[0200] Embodiments of the present invention include features that are possible and / or practical to implement only using one or more computers, computer processors, and / or other elements of a computer system. Such features are impossible or impractical to realize through mental activity and / or manually. As a result, such features are inherently rooted in computer technology and solve problems inherently associated with computer technology. For example, embodiments of the present invention may generate cryptographic hashes (such as cryptographic hash 28 and cryptographic hash 28') for amounts of data in a time that is impossible or impractical to perform manually. For example, embodiments of the present invention may generate cryptographic hashes in less than one second for one megabyte of data, which is impossible for a human to perform manually. As another example, embodiments of the present invention may transmit data over the Internet and / or other electronic communications networks (e.g., via transmission 40 or transmission 40') that inherently require the use of communications equipment and cannot be performed manually by a human.

[0201] Any claim herein that affirmatively requires a computer, processor, memory, or similar computer-related element is intended to require such element and should not be construed as if such element is not present in or required by such claim. Such claims are not intended to encompass, and should not be construed as, methods and / or systems lacking the recited computer-related element. For example, any method claim herein that recites that the claimed method is performed by a computer, processor, memory, and / or similar computer-related element is intended to encompass, and should be construed as, a method performed by the recited computer-related element. Such method claims should not be construed as encompassing, for example, a method performed by mental acts or by hand (e.g., using pencil and paper). Similarly, any product claim herein that recites that the claimed product includes a computer, processor, memory, and / or similar computer-related element is intended to encompass, and should be construed as, a product that includes the recited computer-related element. Such product claims should not be construed as encompassing, for example, a product that does not include the recited computer-related element.

[0202] Each computer program within the scope of the claims below may be implemented in any programming language, such as assembly language, machine language, a high-level procedural programming language, or an object-oriented programming language, for example, a compiled or interpreted programming language.

[0203] Each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. The method steps of the present invention may be performed by one or more computer processors executing a program tangibly embodied on a computer-readable medium to perform the functions of the present invention by operating on inputs to generate outputs. Suitable processors include, by way of example, both general purpose and special purpose microprocessors. In general, a processor receives (reads) instructions and data from a memory (such as a read-only memory and / or a random access memory) and writes (stores) instructions and data in a memory. Suitable storage devices for tangibly embodying computer program instructions and data include, for example, all forms of non-volatile memory, such as semiconductor memory devices including EPROMs, EEPROMs, and flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, and CD-ROMs. Any of the foregoing may be supplemented by, or incorporated in, specially designed ASICs (Application Specific Integrated Circuits) or FPGAs (Field Programmable Gate Arrays). A computer can also typically receive (read) and write (store) programs and data to a non-transitory computer-readable storage medium, such as an internal disk (not shown) or a removable disk. These elements may be found in conventional desktop or workstation computers, as well as other computers suitable for executing computer programs implementing the methods described herein, and they may be used with any digital printing or marking engine, display monitor, or other raster output device capable of producing color or grayscale pixels on paper, film, a display screen, or other output medium.

[0204] Any data disclosed herein may be implemented in one or more data structures tangibly stored on a non-transitory computer-readable medium, for example. Embodiments of the invention may store such data in such data structures and read such data from such data structures.

[0205] Non-limiting embodiments of the present invention include the following. [Embodiment 1] 1. A computer-implemented method for evidencing the existence of a digital document, comprising: A. obtaining a timestamp of the digital document; B. obtaining a plurality of cryptographic hashes of the digital document; C. generating an evidence key based on the timestamp and the plurality of cryptographic hashes; D. storing the evidence key and providing a stored evidence key; method. [Embodiment 2] E. retrieving the evidence key and providing a retrieved evidence key; 2. The method of embodiment 1. [Embodiment 3] F. further comprising the step of comparing the stored evidence key with the retrieved evidence key; 3. The method of embodiment 2. [Embodiment 4] 3. The method of embodiment 2, wherein retrieval of the evidence key is enabled by providing an identifier, or the identifier is selected from the group consisting of a cryptographic hash, additional associated data, and combinations thereof. [Embodiment 5] 5. The method of any one of embodiments 1 to 4, wherein the timestamp is a plurality of timestamps. [Embodiment 6] 6. The method of any one of the preceding claims, wherein the plurality of cryptographic hashes is from about 2 to about 100 cryptographic hashes, or from about 2 to about 25 cryptographic hashes, or from about 3 to about 10 cryptographic hashes, or from about 4 to about 8 cryptographic hashes. [Embodiment 7] 7. The method of any one of embodiments 1 to 6, wherein each of the plurality of cryptographic hashes is generated by a different cryptographic hash function. [Embodiment 8] At least one of the cryptographic hashes is a keyless cryptographic hash function; or BLAKE-256, BLAKE-512, BLAKE2b, BLAKE2s, ECOH, GOST, Grostl, HAS-160, HAVAL, JH, MD2, MD4, MD5, MD6, RadioGatun, RIPEMD, RIPEMD-128, RIPEMD-160, RIPEMD-320, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, Skein, Snefru, Spectral 8. The method of any one of embodiments 1 to 7, wherein the cryptographic hash function is generated by a cryptographic hash function selected from the group consisting of Hash, Streebog, SWIFFT, Tiger, Whirlpool, and combinations thereof; or a cryptographic hash function selected from the group consisting of SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, and combinations thereof; or a cryptographic hash function selected from the group consisting of SHA2-256, SHA2-512, SHA3-256, SHA-3, and combinations thereof. [Embodiment 9] 9. The method of any one of the preceding claims, wherein the timestamps comprise a plurality of timestamps; or from about 2 to about 10 timestamps; or from about 2 to about 8 timestamps; or from about 3 to about 6 timestamps. [Embodiment 10] The method of any one of embodiments 1 to 9, wherein storing the evidence key is performed on a storage medium selected from the group consisting of a server, a storage drive, paper, a CD-ROM, a DVD, a disposable storage medium, and combinations thereof; or a server, a storage drive, a CD-ROM, a DVD, a disposable storage medium, and combinations thereof; or a server, a storage drive, a CD-ROM, a DVD, and combinations thereof; or a disk drive, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a floppy disk, an optical disk, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a flash memory, and combinations thereof. [Embodiment 11] 1. A computer-implemented method for evidencing the existence of a digital document, comprising: A. obtaining a number of timestamps for the digital document; B. obtaining a cryptographic hash of the digital document; C. generating an evidence key based on the plurality of timestamps and the cryptographic hash; D. storing the evidence key and providing a stored evidence key; method. [Embodiment 12] E. retrieving the evidence key and providing a retrieved evidence key; 12. The method of embodiment 11. [Embodiment 13] F. further comprising the step of comparing the stored evidence key with the retrieved evidence key; 13. The method of embodiment 12. [Embodiment 14] 13. The method of embodiment 12, wherein retrieval of the evidence key is enabled by providing an identifier; or the identifier is selected from the group consisting of a cryptographic hash, additional associated data, and combinations thereof. [Embodiment 15] 15. The method of any one of embodiments 11 to 14, wherein the plurality of timestamps is about 2 to about 10 timestamps, or about 2 to about 8 timestamps, or about 3 to about 6 timestamps. [Embodiment 16] 16. The method of any one of embodiments 11 to 15, wherein each of the multiple timestamps is generated by a different time source selected from the group consisting of a time server, an independent clock, and combinations thereof; or a time server, an independent clock, and combinations thereof; or a Global Positioning System (GPS) clock. [Embodiment 17] 17. The method of any one of embodiments 11 to 16, wherein the cryptographic hash is a plurality of cryptographic hashes; or the cryptographic hash is from about 2 to about 100 cryptographic hashes, or from about 2 to about 25 cryptographic hashes, or from about 3 to about 10 cryptographic hashes, or from about 4 to about 8 cryptographic hashes. [Embodiment 18] 18. The method of embodiment 17, wherein each of the plurality of cryptographic hashes is generated by a different cryptographic hash function. [Embodiment 19] The cryptographic hash is a keyless cryptographic hash function; or BLAKE-256, BLAKE-512, BLAKE2b, BLAKE2s, ECOH, GOST, Grostl, HAS-160, HAVAL, JH, MD2, MD4, MD5, MD6, RadioGatun, RIPEMD, RIPEMD-128, RIPEMD-160, RIPEMD-320, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, Skein, Snefru, Spectral 19. The method of any one of embodiments 11 to 18, wherein the cryptographic hash function is generated by a cryptographic hash function selected from the group consisting of Hash, Streebog, SWIFFT, Tiger, Whirlpool, and combinations thereof; or a cryptographic hash function selected from the group consisting of SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, and combinations thereof; or a cryptographic hash function selected from the group consisting of SHA2-256, SHA2-512, SHA3-256, SHA-3, and combinations thereof. [Embodiment 20] The method of any one of embodiments 11 to 19, wherein storing the evidence key is performed on a storage medium selected from the group consisting of a server, a storage drive, paper, a CD-ROM, a DVD, a disposable storage medium, and combinations thereof; or a server, a storage drive, a CD-ROM, a DVD, a disposable storage medium, and combinations thereof; or a server, a storage drive, a CD-ROM, a DVD, and combinations thereof; or a disk drive, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a floppy disk, an optical disk, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a flash memory, and combinations thereof. [Embodiment 21] 1. A computer-implemented method for evidencing the existence of a digital document, comprising: A. obtaining a timestamp of the digital document; B. obtaining a cryptographic hash of the digital document; C. generating an evidence key based on the timestamp and the cryptographic hash; D. storing the evidence key to provide a stored evidence key, the storage of the evidence key being stored on a plurality of storage media; method. [Embodiment 22] E. retrieving the evidence key and providing a retrieved evidence key; 22. The method of embodiment 21. [Embodiment 23] F. further comprising the step of comparing the stored evidence key with the retrieved evidence key; 23. The method of embodiment 22. [Embodiment 24] 23. The method of embodiment 22, wherein retrieval of the evidence key is enabled by providing an identifier, or the identifier is selected from the group consisting of a cryptographic hash, additional associated data, and combinations thereof. [Embodiment 25] 25. The method of any one of embodiments 21 to 24, wherein each of the plurality of storage media is selected from the group consisting of a server, a storage drive, paper, a CD-ROM, a DVD, a disposable storage medium, and combinations thereof; or a server, a storage drive, a CD-ROM, a DVD, a disposable storage medium, and combinations thereof; or a server, a storage drive, a CD-ROM, a DVD, and combinations thereof; or a disk drive, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a floppy disk, a magneto-optical disk, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a flash memory, and combinations thereof. [Embodiment 26] 26. The method of any one of embodiments 21 to 25, wherein the multiple storage media are located in multiple physical locations; or multiple different physical locations; or from about 2 to about 20 different physical locations; or from about 2 to about 15 different physical locations; or from about 3 to about 10 different physical locations. [Embodiment 27] 27. The method of any one of embodiments 21 to 26, wherein the timestamps include a plurality of timestamps; or about 2 to about 10 timestamps; or about 2 to about 8 timestamps; or about 3 to about 6 timestamps. [Embodiment 28] 28. The method of any one of embodiments 21 to 27, wherein the cryptographic hash is a plurality of cryptographic hashes; or the cryptographic hash is from about 2 to about 100 cryptographic hashes, or from about 2 to about 25 cryptographic hashes, or from about 3 to about 10 cryptographic hashes, or from about 4 to about 8 cryptographic hashes. [Embodiment 29] The cryptographic hash is a keyless cryptographic hash function; or BLAKE-256, BLAKE-512, BLAKE2b, BLAKE2s, ECOH, GOST, Grostl, HAS-160, HAVAL, JH, MD2, MD4, MD5, MD6, RadioGatun, RIPEMD, RIPEMD-128, RIPEMD-160, RIPEMD-320, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, Skein, Snefru, Spectral 29. The method of any one of embodiments 21 to 28, wherein the cryptographic hash function is generated by a cryptographic hash function selected from the group consisting of Hash, Streebog, SWIFFT, Tiger, Whirlpool, and combinations thereof; or a cryptographic hash function selected from the group consisting of SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, and combinations thereof; or a cryptographic hash function selected from the group consisting of SHA2-256, SHA2-512, SHA3-256, SHA-3, and combinations thereof. [Embodiment 30] 1. A computer-implemented method for evidence of existence of a plurality of digital documents, comprising: A. receiving a plurality of cryptographic hashes during a first period of time; B. generating a current checksum based on the plurality of cryptographic hashes received during the first time period; C. storing the current checksum on a storage medium; D. receiving a plurality of cryptographic hashes during a second period of time; E. generating a next checksum based on the plurality of cryptographic hashes received during the second period of time; F. storing said next checksum on said storage medium; G. replacing the checksum in the storage medium with the next checksum; method. [Embodiment 31] 31. The method of embodiment 30, further comprising repeating steps D through G. [Embodiment 32] 1. A computer-implemented method for evidence of existence of a plurality of digital documents, comprising: A. receiving a plurality of evidence keys during a first time period; B. generating a current checksum based on the plurality of evidence keys received during the first time period; C. storing the current checksum on a storage medium; D. receiving a plurality of evidence keys during a second time period; E. generating a next checksum based on the plurality of evidence keys received during the second time period; F. storing said next checksum on said storage medium; G. replacing the checksum in the storage medium with the next checksum; method. [Embodiment 33] 33. The method of embodiment 32, further comprising repeating steps D through G. [Embodiment 34] 1. A computer-implemented method for evidence of existence of a plurality of digital documents, comprising: A. receiving a plurality of cryptographic hashes during a first period of time; B. generating a current checksum based on the plurality of cryptographic hashes received during the first time period; C. storing the current checksum on a storage medium; D. receiving a plurality of cryptographic hashes during a second period of time; E. generating a current checksum based on the plurality of cryptographic hashes received during the second period of time; F. storing the current checksum on the storage medium; G. receiving a plurality of cryptographic hashes during a period of time; H. generating a next checksum based on the plurality of cryptographic hashes received during the next period and the current checksum from step B; I. storing the next checksum on a storage medium; J. replacing the current checksum stored in step C with the next checksum stored in step I; K. receiving a plurality of cryptographic hashes during a period of time; L. generating a next checksum based on the plurality of cryptographic hashes received during the next period and the current checksum from step E; M. storing the next checksum on a storage medium; N. replacing the current checksum stored in step F with the next checksum stored in step M; method. [Embodiment 35] 35. The method of embodiment 34, further comprising repeating steps G through N. [Embodiment 36] 13. A computer system for evidencing the existence of a digital document, said system comprising a method according to any one of the preceding embodiments. [Embodiment 37] A computer-implemented tag chain system, A. First chain and B. a second chain; A tag chain system, wherein the first chain and the second chain are mutually exclusive. [Embodiment 38] The first chain and the second chain are stored on the same server. A tag chain system as described in embodiment 37. [Embodiment 39] The first chain and the second chain are stored on different servers. A tag chain system as described in embodiment 38.

[0206] It is also to be understood that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination.

[0207] All references specifically cited herein are incorporated herein by reference in their entirety. However, citation or incorporation of such a reference is not necessarily an admission as to its pertinence, citation eligibility, and / or availability as prior art to / with respect to the present invention.

Claims

1. 1. A computer-implemented method for evidencing the existence of a digital document, comprising: A. obtaining metadata for a digital document in a user's system; B. obtaining a cryptographic hash of the digital document via the user's system; C. transmitting the metadata and the cryptographic hash from the user's system to a remote device; or transmitting the metadata and the cryptographic hash to the remote device over the Internet; D. receiving the metadata and the cryptographic hash at the remote device; E. requesting a timestamp from a time source; F. receiving the timestamp from the time source at the remote device, wherein the remote device does not include the time source and the timestamp is based on a time the remote device receives the metadata and the cryptographic hash; E. combining the metadata, the cryptographic hash, and the timestamp in an evidence key generator to generate an evidence key; F. storing the evidence key to provide a stored evidence key; G. Optionally, generating a further cryptographic hash of the evidence key in a further evidence key generator to form a further evidence key; H. storing said further evidence key to form a stored further evidence key; During the method, the digital document remains on the user's system. method.

2. obtaining additional metadata from a source selected from the group consisting of the user, the user's system, and combinations thereof; Optionally, in the further evidence key generator, the further cryptographic hash is generated from the evidence key and the further metadata. The method of claim 1.

3. combining the further cryptographic hash and the further metadata in the further evidence key generator to form the further evidence key. The method of claim 2.

4. providing the further metadata to a third party, or providing the further metadata to the third party, where the further metadata is not provided to the remote device; and optionally obtaining the user's consent to transmitting the further metadata to a third party; obtaining the user's consent prior to transmitting the additional metadata to the third party; The method of claim 2.

5. The method of claim 1 , wherein in step C, the user's system only transmits the metadata and the cryptographic hash to the remote device.

6. The step of transmitting the further cryptographic hash to a third party comprises: Optionally, obtaining consent from the user to transmitting the further cryptographic hash to a third party; obtaining the user's consent prior to transmitting the further cryptographic hash to the third party; The method of claim 1.

7. The method of claim 1 , wherein the cryptographic hash is obtained from the digital document and the metadata.

8. 1. A computer-implemented method for anonymously evidencing the existence of a digital document, comprising: A. obtaining metadata for a digital document in a user's system; B. obtaining a cryptographic hash of the digital document; C. transmitting the metadata and the cryptographic hash to a remote device; D. receiving the metadata and the cryptographic hash at the remote device; E. requesting identity data for the user from an identity source; F. obtaining a cryptographic hash of the user's identity data to form an identity hash; G. receiving the identity hash at the remote device; H. combining the metadata, the cryptographic hash, and the identity hash in an evidence key generator in the remote device to generate an evidence key; I. storing the evidence key to provide a stored evidence key; J. generating a reference code for the stored evidence key, or the reference code is a QR code; K. transmitting said reference code to said user; the digital document never leaves the user's system, the identity data never leaves the identity source, the reference code allows a third party to access the evidence key or allows a third party limited access to the evidence key, and optionally the digital document contains information selected from the group consisting of biometric information, business information, financial information, health information, history information, identity information, legal information, personal information, and combinations thereof; method.

9. requesting a timestamp from a time source by the remote device; receiving the timestamp from the time source at the remote device; The remote device does not include the time source. The method according to claim 8.

10. 1. A computer-implemented method for evidencing the existence of a digital document, comprising: A. obtaining a log of previous cryptographic hashes from a user's system; B. obtaining a cryptographic hash of the digital document; C. checking the log to see if the cryptographic hash matches any of the previous cryptographic hashes; D. if the cryptographic hash does not match any of the previous cryptographic hashes, transmitting the cryptographic hash to a remote device; method.

11. 1. A computer-implemented method for evidencing the existence of a digital document, comprising: A. obtaining metadata for a digital document on a user's system; B. obtaining a cryptographic hash of the digital document; C. transmitting the metadata and the cryptographic hash from the user's system to a remote device or transmitting the metadata and the cryptographic hash to the remote device over the Internet; D. receiving the metadata and the cryptographic hash at the remote device; E. requesting a timestamp from a time source; F. receiving the timestamp from the time source at the remote device, wherein the remote device does not include the time source and the timestamp is based on a time the remote device receives the metadata and the cryptographic hash; G. combining the metadata, the cryptographic hash, and the timestamp in an evidence key generator at the remote device to generate an evidence key; H. combining a plurality of evidence keys to form a composite evidence key, optionally wherein the plurality of evidence keys comprises from about 2 to about 1000 evidence keys, or from about 5 to about 100 evidence keys; I. storing the composite evidence key to provide a stored composite evidence key; J. generating a further cryptographic hash of the composite evidence key to form a further evidence key; K. storing the further evidence key to form a stored further evidence key; method.

12. 12. The method of claim 11, further comprising storing composite metadata with the plurality of evidence keys forming the composite evidence key, optionally a predetermined period of time determining which evidence keys of the plurality of evidence keys are combined into the composite evidence key.

13. A. storing a digital document on a user's system; B. obtaining metadata for the digital document; C. obtaining a cryptographic hash of the digital document; D. transmitting the metadata and the cryptographic hash to a remote device; E. receiving the metadata and the cryptographic hash at the remote device; F. requesting a timestamp from a time source; G. receiving the timestamp from the time source at the remote device, the remote device not including the time source; H. combining the metadata, the cryptographic hash, and the timestamp in an evidence key generator at the remote device to generate an evidence key; I. storing the evidence key to provide a stored evidence key; J. obtaining a second cryptographic hash of the digital document by a third-party user; K. comparing the second cryptographic hash to the cryptographic hash in the stored evidence key to generate a comparison result; L. notifying said third party user of said comparison result, optionally said third party user being different from said user; During the method, the digital document remains in the user's system, the third-party user's system, or both. A method for verifying data integrity of a digital document.

14. the third-party user obtaining second metadata from the digital document; and comparing the second metadata to the metadata to generate the comparison result. A method for verifying data integrity of a digital document according to claim 13.

15. making the evidence key or the cryptographic hash publicly available. A method for verifying data integrity of a digital document according to claim 13 or 14.

Images