Method for proving existence of digital document, system therefor, and tag chain blockchain system
The method uses cryptographic hashes and timestamps to generate evidence keys, addressing blockchain scalability and document authenticity, offering secure and efficient proof of digital document existence with reduced energy consumption.
Patent Information
- Application Number
- JP2025167620
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2017-06-20
- Filing Date
- 2025-10-03
- Publication Date
- 2026-02-03
AI Technical Summary
Existing blockchain systems face scalability issues with increasing energy and time requirements for generating timestamps, making them inefficient for proving the existence and authenticity of digital documents, and there is a need for improved methods to securely timestamp and authenticate digital documents without exposing their content.
A computer-implemented method using cryptographic hashes and timestamps to generate evidence keys, which are stored across multiple storage media, ensuring the existence and integrity of digital documents, and a tag chain system to enhance blockchain scalability.
Provides secure, efficient, and reliable proof of digital document existence, suitable for legal contexts, with improved scalability and reduced energy consumption, while maintaining document integrity.
Smart Images

Figure 2026016429000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a method for proving the existence of a digital document and a time / date stamp therefor. The present invention also relates to a method and / or system for retrieval of evidence of a digital document. The present invention also relates to a blockchain system. [Background technology]
[0002] In today's knowledge economy, intellectual property (IP) is often an individual's or company's most valuable asset. IP law is intended to benefit society by fostering the creation of new and useful IP by recognizing creators, owners, and / or inventors and by providing them with legal and economic benefits. One of the critical prerequisites for all IP rights (IPR) is originality. That said, it is often important to know when IP was created and / or first used; and who the creator, owner, or inventor is.
[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 of 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, relying solely on the timestamp of the computer on which a digital document was created is often insufficient; thus, time / date stamps may be changed, forged, or simply inaccurate if relying solely on computer time.
[0004] Blockchain systems are known that utilize cryptographic hashes to record and create links, such as transactions and / or other data, that are then stored in a ledger, typically an open or closed ledger, although semi-open ledgers are also possible. However, a general problem with blockchain systems is that as their chains become longer and longer, they subsequently require more time, computing power, and energy to create the next virtual link in the chain. At a certain point, the law of diminishing returns dictates that generating the next link in the chain becomes too slow, energy-intensive, and / or otherwise unsustainable. Therefore, there is a need to improve the architecture of current blockchain systems.
[0005] It would therefore be desirable to be able to provide a method that can quickly and easily provide timestamps and datestamps, such as digital fingerprints, and digital certificates to prove the original 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 exposing the actual digital content in any way. It would also be desirable for such a record to be securely stored by a trusted organization and / or have a standardized timestamp. It would also be desirable to provide a unique digital fingerprint for each digital document. It would also be desirable to be able to detect whether a digital document has been altered or modified from the digital document indicated by its digital fingerprint. There is also a need for easier and more effective methods for authenticating digital documents, particularly in courts or other forums, in cases of trade secret theft, prior use defenses, copyright litigation, etc. Improved blockchain systems are also needed. Summary of the Invention
[0006] In view of the foregoing, it is an object of the present invention to provide an improved computer-implemented method and computer system for proving the existence of a digital document, i.e., for providing "proof of existence" for a digital document.
[0007] The present invention relates to a computer-implemented method for proving the existence of a digital document, the method including 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, and storing the evidence key to provide a stored evidence key.
[0008] The present invention also relates to a computer-implemented method for proving the existence of a digital document, the method including 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, and storing the evidence key to provide a stored evidence key.
[0009] The present invention also relates to a computer-implemented method for proving the existence of a digital document, the method including obtaining a timestamp 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, wherein the storage of the evidence key occurs on a plurality of storage media.
[0010] The present invention also includes a computer system for verifying the existence of a digital document that includes the methods described herein.
[0011] Without intending to be bound by theory, it is believed that the present invention may provide improved computer-implemented methods for proving the existence of a digital document, such as a photograph, a script, an essay, or the like, i.e., providing "proof of existence" for the digital document. Furthermore, by utilizing cryptographic hashes, timestamps, evidence keys, and / or storage media, the proving methods herein may have one or more benefits, such as improved security, speed, computing efficiency, safety, and the like. In some cases, it is believed that the evidence key and / or evidence provided by the methods herein may be used, for example, in a court of law, a lawsuit, arbitration, etc., as a presumption that the digital document existed at a particular time. It is also believed that the evidence key and / or evidence provided by the methods herein may be used, for example, in a court of law, a lawsuit, arbitration, etc., as a presumption that the digital document was owned by a particular individual and / or organization at a particular time.
[0012] It is also believed that such computer-implemented methods and computer systems may be useful for proving the existence of, for example, personal digital documents, legal digital documents, business digital documents, commercially available digital documents, etc., and combinations thereof. The present invention is believed to be particularly useful for proving the existence of digital documents, such as wills, trust deeds, business documents, websites, text or other electronic messages, contracts, deeds, assignments, purchase and sale agreements, receipts, advertisements, invention notes, laboratory data, data logs, phone logs, financial transactions, patents, trademarks, copyrights, trade secrets, insurance records, patient records, computer programs, computer software, photographs, videos, music, laboratory reports, etc., and / or changes and / or modifications thereof.
[0013] The present invention also relates to a computer-implemented tag chain system that includes a first chain and a second chain, the first chain and the second chain being mutually exclusive.
[0014] Without intending to be bound by theory, the tag chain system allows the blockchain system to scale itself to include additional checksums, transactions, etc. while maintaining the required speed, reducing time and overall energy requirements, etc. [Brief explanation of the drawings]
[0015] For a more complete understanding of the present invention, reference is made to the following detailed description and accompanying drawings. [Figure 1] 1 shows a schematic diagram of an embodiment of the present invention. [Figure 2] 1 shows a schematic diagram of an embodiment of the present invention including a search request. [Figure 3] 1 shows a flowchart of a method for proving the existence of a digital document according to an embodiment of the present invention; [Figure 4] 4 shows a detailed flow chart of step (54) of the method of the embodiment as shown in FIG. 3. [Figure 5] 1 illustrates an embodiment of a system of the present invention for proving the existence of a digital document. [Figure 6] 1 illustrates an embodiment of the present invention that describes a method for synchronizing clocks of storage servers. [Figure 7] 1 shows an algorithm structure according to an embodiment of the present invention. [Figure 8] A shows an embodiment of the present invention for generating a checksum, and B shows another embodiment of the present invention for generating a checksum. [Figure 9] 10 illustrates another embodiment of the present invention for generating a checksum. [Figure 10] 1 shows a schematic diagram of an embodiment of a tag chain of the present invention;
[0016] 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 INVENTION
[0017] As used herein, the term "comprising" means including the following elements, but not excluding others.
[0018] As used herein, the terms "couple" or "connect," unless expressly stated otherwise, refer to a direct or indirect electrical coupling or connection via one or more electrical or wireless methods.
[0019] As used herein, the phrase "digital document" refers to any document that is stored digitally rather than in physical form. However, those skilled in the art will understand that a digital document herein may be a digital representation of a physical document. Furthermore, it is recognized that a digital document itself may actually contain one or more digital files; for example, a digital document herein may be a database with many digital files in it, a folder with many digital files in it, an entire hard drive with many digital files in it, a server with many databases in it, etc.
[0020] As used herein, "time" refers to a time or date, or related value corresponding to a particular time and date.
[0021] The present invention relates to a computer-implemented method for proving the existence of a digital document, the method including 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, and storing the evidence key to provide a stored evidence key.
[0022] The present invention also relates to a computer-implemented method for proving the existence of a digital document, the method including 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, and storing the evidence key to provide a stored evidence key.
[0023] The present invention also relates to a computer-implemented method for proving the existence of a digital document, the method including obtaining a timestamp 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, wherein the storage of the evidence key occurs on a plurality of storage media.
[0024] Referring now to the drawings, Figure 1 shows a schematic diagram of an 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. Evidence key request 22 is 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. Evidence key generator 24 then obtains (e.g., generates) one or more timestamps 26 and obtains (e.g., generates) one or more cryptographic hashes 28, depending on the embodiment of the present invention.
[0025] The evidence key generator 24 can generate the evidence key 32 using a variety of methods and inputs 30. In one embodiment herein, the evidence key generator 24 then generates one or more evidence keys 32 based on the inputs 30 of a timestamp 26 and / or a cryptographic hash 28, or based on a timestamp 26 and a cryptographic hash 28. In one embodiment herein, the evidence key generator generates the evidence key 32 using multiple timestamps and cryptographic hashes 28, such as 26 and 26'. In an alternative embodiment, the evidence key generator 24 generates the evidence key 30 using a timestamp 26 and multiple cryptographic hashes 28 and 28'. In yet another embodiment, the evidence key generator 24 generates the evidence key 30 using multiple timestamps 26 and 26' as well as multiple cryptographic hashes 28. In yet another embodiment, evidence key generator 24 generates multiple evidence keys 32 and 32' using the same or different inputs 30.
[0026] The timestamps herein may come from a variety of sources and may be generated according to one or more events. In one embodiment herein, the timestamp belongs to the time when the digital document was first created. In one embodiment herein, the timestamp belongs to the time when the digital document was last saved. Thus, in one embodiment herein, the timestamp may be part of a version tracking program for the digital document.
[0027] In one embodiment herein, the timestamp belongs to the time when the request to generate the evidence key is received by the evidence key generator. In one embodiment herein, the timestamp belongs to the time when the evidence key generator derives the cryptographic hash. In another embodiment herein, the timestamp is obtained from a time source such as a time server, an independent clock, and combinations thereof; or a time server, an independent clock, and combinations thereof. In one embodiment herein, the independent clock is a Global Positioning System (GPS) clock.
[0028] In one embodiment herein, the timestamp is 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. In one embodiment herein, the plurality of timestamps are obtained from different time sources as described herein, or each of the plurality of timestamps is obtained from a different time source. Without intending to be bound by theory, it is believed that such a feature can provide greater confidence in the authenticity of the overall system, for example, when an evidence key is provided to a third party to prove the existence of a digital document at a particular time.
[0029] In one embodiment herein, the timestamps include multiple timestamps for multiple events; or multiple timestamps each belonging to a different event. In one embodiment herein, the timestamps belong to 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 is received by the evidence key generator, the time the evidence key generator obtains a cryptographic hash, and combinations thereof.
[0030] Furthermore, in one embodiment of the present invention, if the multiple timestamps are not all within the predetermined amount of time, the evidence key is subsequently flagged by the evidence key generator, other algorithm, or other process as a possible error. In one embodiment herein, the predetermined amount of time is 10 minutes; or 5 minutes; or 2 minutes.
[0031] A cryptographic hash, as used herein, 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 cryptographic hash specific to that particular document. A cryptographic hash function, as used herein, can be a keyed cryptographic hash function generated by a keyed cryptographic hash function, or an unkeyed cryptographic hash generated by an unkeyed cryptographic hash function. In one embodiment herein, the keyed cryptographic hash function is selected from the group consisting of VMAC, UMAC, BLAKE 2, Poly1305-AES, PMAC, SipHash, One-key MAC, MD6, HMAC (Hash-based Message Authentication Code), and combinations thereof; and / or combinations thereof; or BLAKE 2, MAC, HMAC, and combinations thereof.
[0032] In one embodiment herein, the keyless cryptographic hash function is 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 The unkeyed cryptographic hash function is selected from the group consisting of SWIFFT, Tiger, Whirlpool, and combinations thereof; or the unkeyed cryptographic hash function is selected from the group consisting of SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-3, and combinations thereof; or the unkeyed cryptographic hash function is selected from the group consisting of SHA2-256, SHA2-512, SHA3-256, SHA-3, and combinations thereof.
[0033] In one embodiment herein, the cryptographic hash or plurality of cryptographic hashes is 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 one embodiment herein, each of the cryptographic hashes is generated by a different cryptographic hash function. While not intending to be bound by theory, it is believed that the combination of multiple cryptographic hashes provides a higher degree of certainty that no mismatch will occur. One skilled in the art will understand that the more cryptographic hashes used, the greater the likelihood of a mismatch.
[0034] While not intending to be bound by theory, it is believed that the use of cryptographic hashes herein is particularly useful because, as opposed to other types of hashes, it is extremely difficult, if not impossible, to reconstruct (i.e., reverse engineer) a digital (i.e., electronic) document and / or the contents of the 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 an individual from a fingerprint. Thus, with such benefits, it is believed that the present invention may be useful in proving the existence of trade secrets while simultaneously reducing the risk of the trade secrets being compromised.
[0035] The evidence key may be generated from a cryptographic hash and a timestamp; or from a cryptographic hash, a timestamp, and additional input. The evidence key may be generated by associating these inputs or by further modifying / altering them as desired. For example, in one embodiment herein, the cryptographic hash, the timestamp, and any additional input are further fed into a further hash function to generate a further hash that is then used alone or together with further data as the evidence key.
[0036] While not intending to be bound by theory, it is believed that using both a cryptographic hash and a timestamp to generate the evidence key provides a higher degree of confidence that one or more of these inputs have not subsequently been altered.
[0037] 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') 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, or generated, 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.
[0038] The evidence key 32 and optional additional associated data 34 are later stored together in a storage device 36, which typically involves placing the evidence key and the additional associated data together on a storage medium. The additional associated data herein may be included with and / or associated with the evidence key to, for example, categorize the evidence key, describe the evidence key, assist in retrieving the evidence key at a later time, or assist in authenticating the evidence key. In one embodiment herein, the additional associated data includes data used to categorize the evidence key. In one embodiment herein, the additional associated data includes a software version number for the version of software used to generate the evidence key. In one embodiment herein, the additional associated data includes data used to search for the evidence key, typically at a later time after storage.
[0039] In one embodiment herein, the additional associated data includes non-sensitized information, such as information about the evidence key that helps describe the evidence key, its contents, etc., but does not substantially leak detailed content of the digital document itself. In one embodiment herein, the additional associated data enables retrieval of the evidence key using the non-sensitized information; or retrieval of the evidence key using only the non-sensitized 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.), filename, and combinations thereof; or a storage timestamp, email address, phone number, username, password, filename, and combinations thereof; or a storage timestamp, email address, phone number, username, filename, unique identifier, and combinations thereof.
[0040] In one embodiment herein, the additional associated data may be viewed, searched, organized, and categorized by entities such as a system administrator, a local administrator, registered users, and / or the public. In one embodiment herein, different levels and / or categories of entities have different levels of access rights with respect to the additional associated data and / or evidence keys. For example, a system administrator may have full access rights to view, search, organize, and categorize the additional associated data and evidence keys, while the public may have limited access rights so that they can only view the additional associated data.
[0041] In one embodiment herein, entities at any level do not have access that allows for additional associated data or modification of evidence keys.
[0042] In one embodiment herein, if changes are made to additional associated data and / or evidence keys, the changes are later indicated in a log or permanent log. In one embodiment herein, the log herein includes a record of the changes made as well as one or more indicators such as the entity making the change, the data and time the change was made, the location where the change was made (e.g., via IP address, either a physical location and / or a virtual location), the access rights required to make the change, etc.
[0043] A password useful herein can be any type of information for identifying and / or authenticating a particular user, server, or other entity, particularly one submitting a request for an evidence key for an original digital document. In one embodiment herein, the password is selected from the group of: an alphanumeric string, a personal authentication factor, a location, an image, an electronic file, and combinations thereof; or an alphanumeric string, a personal authentication factor, an image, and combinations thereof; or an alphanumeric string, a personal authentication factor, and combinations thereof. In one embodiment herein, the personal authentication factor is a fingerprint, a voiceprint, a facial recognition, other personal patterns, and combinations thereof; or a biometric factor such as a fingerprint, a voiceprint, a facial recognition, and combinations thereof. A biometric factor herein can include biometric information. In one embodiment herein, the personal authentication factor utilizes a facial recognition algorithm.
[0044] In one embodiment herein, additional relevant data useful herein is case sensitive. In one embodiment herein, additional relevant data useful herein is not case sensitive. In one embodiment herein, passwords, file names, IP addresses, etc. are case sensitive. In one embodiment herein, passwords, file names, IP addresses, etc. are not case sensitive.
[0045] 1, it can be seen that evidence key 23 and additional associated data 34 are combined and stored together in storage devices 36, 36', etc. to provide one or more stored evidence keys 38, 38', etc. Storage devices herein utilize 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 within storage devices 36, 36' and / or the storage medium herein.
[0046] Storage media useful herein include those selected from the group 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. In one embodiment herein, the storage drive is selected from the group of: 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.
[0047] In one embodiment herein, the methods and / or systems herein include multiple storage media.
[0048] In one embodiment herein, the plurality of storage media, or each of the plurality of storage media, is located at a different physical location. While not intending to be bound by theory, it is believed that such a distributed system provides business continuity and disaster recovery benefits in the event of events such as natural disasters, power outages, war, political unrest, etc. Furthermore, in one embodiment herein, one or more of the plurality of storage media 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 social enterprise. In one embodiment herein, the organization is selected from the group consisting of the Austrian Patent Office (APO), the China Council for the Promotion of International Trade (CCPIT), the European Patent Office (EPO), the Intellectual Property Office of Singapore (IPOS), the International Intellectual Property Commercialization Council (IIPCC), the State Intellectual Property Office (SIPO (also known as the China Intellectual Property Office)), the Swiss Federal Institute of Intellectual Property (FIIP), the United States Patent and Trademark Office (USPTO), the State Administration for Market Regulation (SMSA of China), the World Intellectual Property Office (WIPO), the Library of Congress of the United States, and combinations thereof; or the Intellectual Property Office of Singapore (IPOS), the International Intellectual Property Commercialization Council (IIPCC), the World Intellectual Property Office (WIPO), the Library of Congress of the United States, the State Administration for Market Regulation (SMSA of China), and combinations thereof. If an organization changes its name, merges, is absorbed, or is reorganized, the term "organization" as used herein thereafter includes its respective successors in subject matter.
[0049] In one embodiment herein, the multiple storage media herein are electronically and physically separated from one another. While not intending to be bound by theory, it is believed that such a system provides improved security and reliability compared to an internetworked system and / or a system having only a single physical location. Such a system that is distributed across multiple locations can also provide a reliable backup in the event that one of the locations is hacked, altered for ransom, or seized, for example.
[0050] Referring to FIG. 1 , in one embodiment herein, the method includes a delivery step (40)(40′) for forming a delivered evidence key (42)(42′), in which the evidence key (32) and / or additional associated data (43) are delivered to the party; or to the party, organization, server, account, etc. that originally made the evidence key request (22). In one embodiment 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 occur via channels such as email, text message, electronic messaging service, postal mail, transmission over the Internet, and combinations thereof; or via email, postal mail, text message, and combinations thereof. While not intending to be bound by theory, such delivery helps increase the likelihood that a requester will be able to provide sufficient information to successfully search the stored evidence key when a search is required.
[0051] In Figure 1, storage device 36' is shown parallel to storage device 36. However, in one embodiment of the present invention, storage device 36' is contiguous with storage device 36 (see, e.g., Figure 3).
[0052] FIG. 2 shows a schematic diagram of one embodiment of the present invention, in which the computer-implemented method herein includes a search request (44) that subsequently initiates search steps (44), (44'), etc. The search step (44) initiates a process in which the system searches for an evidence key and / or any additional associated data to form a retrieved evidence key (48), (48'), etc. This retrieved evidence key (48) is subsequently 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 one embodiment herein, the comparison step results in search request results (52), (52'), etc. In one embodiment herein, the comparison step (50) compares the delivered evidence key (42) (and any additional associated data (see (34) in FIG. 1)) with the retrieved evidence key (48) (and any respective additional associated data). The comparison step (50) can then highlight the search request results (52) even if there is any mismatch between the delivered evidence key (42) and the retrieved evidence key (48), or even if they match.
[0053] While not intending to be bound by theory, it is believed that the delivered evidence key (42) and the retrieved evidence key (48) may match and subsequently serve as proof; or a rebuttable presumption of proof; that the digital document existed and / or was in the possession of a party at a particular time, such as when the evidence key request was submitted.
[0054] Those skilled in the art will appreciate that, in Figure 2, stored evidence keys 38', as well as parallel processes for searching step 46', are contemplated for embodiments of the present invention. While not intending to be bound by theory, it is believed that performing such parallel searches 46', comparisons 50', etc., provides users with an added layer of security and assurance that the method and system is sound and data integrity is not compromised. Conversely, if different results are retrieved from the parallel processes, this indicates that data integrity has been compromised in some way. In one embodiment of the present invention, if different results are retrieved, a log is generated, an entity such as a system administrator is notified, or a combination thereof.
[0055] FIG. 3 shows a flowchart of a computer-implemented method for proving the existence of a digital document according to one embodiment of the present invention. Specifically, the flowchart shows a method (50) for proving the existence of a digital document (20), in which a first step (52) of the method (50) receives an evidence key request (22). As noted herein, the evidence key request is a request from a user to generate an evidence key for the digital document (see (20) in FIG. 1). The evidence key (32) is later generated by an evidence key generator (see (24) in FIG. 1) in step (54). Once the evidence key (32) is generated, it is stored in a first storage device (36) as shown in step (56), along with any additional associated data (see (34) in FIG. 1). In this embodiment, a second storage device (36') is created in step (58) based on the first storage device (see (36) in FIG. 1). Thus, the first storage device 36 and the second storage device 36' are arranged sequentially, not parallel, as seen in FIG. 1. In one embodiment herein, the first storage device 36 and the second storage device 36' reside on different, independent servers. For example, during a discussion regarding who originally created or copied a file, access may be granted to the user, owner, and / or any relevant third party to retrieve the evidence key 32 and any additional associated data (see 34 in FIG. 1) from the second storage device 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 a search engine running on the storage devices 36 and 36'.
[0056] FIG. 4 shows a detailed flowchart of step 54 of the computer-implemented method 50 according to an embodiment as shown in FIG. 3. In step 62, a 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 consisting 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 present 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'.
[0057] FIG. 5 illustrates another embodiment of the present invention, directed to a computer system 70 for verifying the existence of a digital document 20. The system 70 includes an evidence key generator 24 configured to generate an evidence key 32 for the digital document 20, for example, according to step 54 of 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, 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 a collective storage server 78. After receiving the database and server identification from each of the storage servers 76, 76', 76", the collective 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".
[0058] In one embodiment of the present invention, the new timestamp is the time at which the collective storage server 78 receives the particular evidence key 32. In one embodiment, the evidence key generator 24 is configured to send the evidence key (see (32) in FIG. 1) to the receiving server 74 and the receiving server 74' immediately after generating the evidence key (see (32) in FIG. 1). In another embodiment, the storage servers 76, 76', and 76" are configured to send their respective databases to the collective storage server 78 in batch mode.
[0059] The system 70 further includes an external storage server 80, which is a faithful replica of the collective storage server 78. In one embodiment, the external storage server 80 is not available to any users of the system 70 and serves as a disaster recovery backup. In yet another embodiment, a search engine (not shown in FIG. 5) is coupled to the collective storage server 78 and / or the external storage server 80, allowing a user or any interested third party to search for a particular digital document's evidence key 32 and any additional associated data (see (34) in FIG. 1) upon request.
[0060] According to one embodiment of the present invention, the database contains, for each evidence key, an entry as shown in Table 1.
[0061] [Table 1]
[0062] In Table 1, the evidence key is any combination of a timestamp, a cryptographic hash, and / or additional associated data.
[0063] In one embodiment herein, the second database includes a new timestamp and all entries of the (first) database. In yet another embodiment, the system (70) further includes a file property editor configured to obtain the digital file size and the digital file name.
[0064] 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.
[0065] FIG. 6 shows an embodiment of the invention illustrating a computer-implemented method for synchronizing clocks of storage servers 76, 76', 76" and the like. Each of storage servers 76, 76', 76" is independently coupled to time server 82, time server 82', and independent clock 84. Upon receiving an evidence key (see 32 in FIG. 1) from the evidence key generator (see 24 in FIG. 1), storage servers 76, 76', 76" request timestamps from time server 82, time server 82', and independent clock 84, respectively. Storage servers 76, 76', 76" are further configured to assign to a database, for example, the earliest timestamp received from time server 76, second time server 76', and independent clock 78 as the allowed time for additional associated data, i.e., a particular evidence key (see 32 in FIG. 1). In one embodiment, both time server 76 and time server 76' employ the Network Time Protocol, while independent clock 78 is a GPS clock.
[0066] FIG. 7 shows an algorithm structure (86) according to an embodiment of the present invention. The algorithm (86) is implemented in the collective storage server (see (78) in FIG. 5) to ensure data integrity. When the storage servers (76), (76'), (76"), etc. send evidence keys to the collective storage server (see (78) in FIG. 5) in step (88), the collective storage server (see (78) in FIG. 5) determines whether it receives corresponding evidence keys from all storage servers (76), (76'), (76"), etc. within a predetermined time (condition (90)). If the collective storage server (see (78) in FIG. 5) receives corresponding evidence keys from all storage servers (76), (76'), (76"), etc. within the predetermined time, then the evidence keys are stored in a database located in the collective storage server (see (78) in FIG. 5) in step (92).
[0067] 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 aggregation server (see 78 in FIG. 5) specifically requests the missing evidence key from the particular storage server whose corresponding evidence key is missing or delayed. In step 96, the aggregation server (see 78 in FIG. 5) checks to see if the particular storage server 76 is contactable. If the particular storage server 76, 76', 76" is not contactable, then in step 98, the aggregation server (see 78 in FIG. 5) sends an alert to the system administrator (see 70 in FIG. 5). Alternatively, the aggregation server may indicate this in an error log or otherwise indicate the discrepancy. However, if the storage servers 76, 76', and 76" are reachable, then the particular storage server 76 checks whether the missing evidence key 32 exists in its database, and if found (condition 100), the particular storage server 76 sends the missing evidence key 32 to the collective storage server (see (78) in Figure 5), which then proceeds to step 92 and stores the evidence key 32 in its database (step 92).
[0068] If the missing evidence key (32) cannot be found on a 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.
[0069] 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 multiple cryptographic hashes, or a single cryptographic hash, received during a first period of time. The first period of time ranges from about a few milliseconds to about one month. The shorter the first period of time, the faster the current checksum is generated (i.e., the shorter the time between checksum generation), and the greater the load placed on computing resources, the more checksums are generated and stored. The longer the first period of time, the slower the current checksum is generated (i.e., the longer the time between checksum generation), and the less the load placed on computing resources, the fewer checksums are generated and stored. Checksums are used to ensure the integrity of the stored cryptographic hashes. For example, to detect whether one or more of the cryptographic hashes stored in a database have been altered or tampered with, the cryptographic hashes are used to create a second checksum. 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 changed or tampered with.
[0070] Those skilled in the art will appreciate that there are numerous ways to generate a checksum. For example, a checksum can be generated using, for example, a cryptographic hash algorithm, a block parity function, a CRC, and combinations thereof. Preferably, a cryptographic hash function such as SHA2 and / or SHA3 is used to generate the checksum so that the likelihood of a hash mismatch is relatively low.
[0071] In one example, the first period is 1 minute.
[0072] For illustrative purposes only, there may be, for example, 100 cryptographic hashes received during a first time period. A string is first generated by concatenating the 100 cryptographic hashes in the chronological order in which they are received. A running 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 base 64 format.
[0073] In 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, such as years, or indefinitely. If the multiple cryptographic hashes and corresponding evidence keys are to be used as evidence in a court case years later, the checksum must be stored for years, or indefinitely, to further prove that none of the multiple cryptographic hashes and corresponding evidence keys have been altered or tampered with.
[0074] In step 803, a next checksum is generated based on the current hash and another plurality of cryptographic hashes received during a next period of time, which in one embodiment herein is one minute and begins at the end of the first period of time.
[0075] For illustrative purposes only, there may be, for example, 30 cryptographic hashes received during the following period: A string is first generated by concatenating the 3000 cryptographic hashes in the chronological order in which they were received, and the current checksum. The next checksum is generated by, for example, applying a SHA2-256 hash function on the string.
[0076] In step (804), the next checksum is stored similarly to 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 then used to generate another next checksum at the next future time period. In one embodiment herein, step (805) is performed before step (804), and the current checksum is instead stored in step (804).
[0077] If the next checksum is generated based in part on the current checksum, and the current checksum is also generated in part on the previous checksum, the next checksum is also generated in part on the previous checksum. Even if one or more of the previous checksums are lost or not stored, in one embodiment herein, the current checksum is still considered reproducible using all of the received cryptographic hashes. Those skilled in the art will understand that by comparing the regenerated checksum and the stored previous checksums, the integrity of the stored cryptographic hashes can be verified.
[0078] In one embodiment of the present invention, instead of generating the current and next checksums based on time in steps 801 and 803, the generation is based on a predetermined number of received cryptographic hashes, for example, checksums are generated for all 300 received cryptographic hashes.
[0079] FIG. 8B illustrates an embodiment of a computer-implemented method of the present invention for generating a checksum. The steps in FIG. 8B are similar to those in FIG. 8A. Steps (801) and (803) are replaced with steps (811) and (813), respectively. Compared to step (801), the current checksum is generated based on multiple evidence keys generated during a first period in step (811), instead of multiple cryptographic hashes as in FIG. 8A. Similarly, the next checksum is generated based on multiple evidence keys generated during a next period in step (813). When 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.
[0080] 9 illustrates another embodiment of a computer-implemented method of the present invention for generating checksums. Multiple current checksums, e.g., C1 and C2, are used to generate next checksums NC1 and NC2, respectively. In step 901, the current checksum C1 is generated based on multiple cryptographic hashes or a single cryptographic hash received during a first period of time. In step 902, the current checksum C1 is stored in a storage medium. In step 903, another current checksum C2 is generated based on multiple cryptographic hashes or a single cryptographic hash received during a second period of time. In step 904, the current checksum C2 is stored in the same manner as the current checksum stored in step 902.
[0081] The generation of the current checksum C2 is not based on the current checksum C1, the cryptographic hashes, or the 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 information from the current checksum C1, such as the cryptographic hashes or the cryptographic hash received during the first time period. When the current checksum C1 is processed in a processing unit of the system, such as a central processing unit, the cryptographic hash may have already arrived during the second time period, etc.
[0082] In one embodiment herein, 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. To allow for more time to calculate the current checksum, multiple current checksums are used. Therefore, those skilled in the art will understand that there is a practical limitation of only being able to use two current checksums, C1 and C2, but this embodiment is merely described for ease of understanding. More current checksums, such as 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, may be used to further extend the time available to calculate the current checksum.
[0083] In step 905, a next checksum NC1 is generated based on the current checksum C1 and another plurality of cryptographic hashes received during the next time period. The next checksum NC1 is generated without using information from the current checksum C2, the plurality of cryptographic hashes, or the single cryptographic hash received during the second time period. Therefore, the computing / processing unit of the system has more time to generate the current checksum C2.
[0084] In step 906, the next checksum NC1 is stored in the same manner as the current checksum 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.
[0085] In step 908, a next checksum NC2 is generated based on the current checksum C2 and another plurality of cryptographic hashes received during the next period. The next checksum NC2 is generated without using information from the current checksum NC1, such as the cryptographic hashes or single cryptographic hash received during steps 905-906. Therefore, the system's processor has more time to generate the current checksum NC1.
[0086] In step 909, another next checksum NC2 is stored similar to the current checksum 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.
[0087] If more time is required to generate the next checksum, steps 905-910 may be further extended to include, for example, the next checksums NC3, NC4, NC5, and so on.
[0088] In one embodiment herein, the methods herein, e.g., as described in Figures 8A, 8B, and 9, the steps of iterative checksum generation and replacement substantially outline the steps of a blockchain that function to authenticate the integrity of the database being formed.
[0089] In one embodiment 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, dogecoin, 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, etc. The generation of the next checksum (804) and the replacement of the current checksum (802) with the next checksum (804) are essentially treated as a transaction and recorded in a database, which is then stored, for example, on a storage server (e.g., (76), (778), (80) in Figure 5), or a ledger is stored on a server or computer system.
[0090] In one embodiment of FIG. 9 herein, the first period, second period, etc. are alternating predetermined periods and / or are arranged into a mutually exclusive alternating schedule.
[0091] The methods herein may be computer-implemented. Further, the systems herein may be computer systems.
[0092] FIG. 10 shows a schematic diagram of an embodiment of a tag (blockchain) of the present invention. In FIG. 10, a computer-implemented first blockchain (1000) is initiated when a first link C1 is created; typically, a checksum is generated via cryptographic hashing. A link herein may be a single checksum or multiple checksums. A link herein may be and / or represent, for example, a single transaction, multiple transactions, a transfer, multiple transfers, a period of time, a device (e.g., an electronic device) or multiple devices, and combinations thereof; or multiple transactions, for example, occurring over a period of time. A second blockchain (1002) is initiated when link C2 is created; typically, a checksum is generated via cryptographic hashing. Assuming that each link in this embodiment is a single checksum, in contrast to a typical blockchain, in the embodied tag chain, checksum C1 is not combined with checksum C2 to form the next link in the chain. Instead, checksum C1 is combined with checksum C3, then checksum C5, and so on. Similarly, checksum C2 combines with checksum C4, then 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 the first blockchain (1000) and second blockchain (1002) have already been established. In one embodiment herein, multiple blockchains are added to the Tag Chain system after multiple blockchains already exist in the Tag Chain system.
[0093] In the schematic diagram of FIG. 10, each checksum represents a single link in chain (1000), (1002), (1004), etc. Thus, all odd checksums C1 through C6 form chain (100), and all even checksums C1 through C6 form a separate, mutually exclusive chain (1002). This embodiment is therefore described as a "tag-chain" type of blockchain. Essentially, one chain (or all other chains) is "tag-out," while one chain is "tag-in," meaning that the chain is active and therefore eligible to connect to or receive new links in the chain. However, because these chains are mutually exclusive, only one chain can be "tag-in" at any given time. These chains (and potentially other chains as well) cycle between active (i.e., receiving new links) and inactive (i.e., waiting to receive new links). In FIG. 10, checksum C7 represents the first link in (and through) the new chain (1004).
[0094] In one embodiment herein, only a single chain is active at a given time.
[0095] Thus, a tag chain system includes at least a first chain and a second chain that are mutually exclusive. In one embodiment herein, the chains are mutually exclusive. However, in one embodiment herein, the first chain and the second chain (as well as any other chains) are linked within the same blockchain system. In one embodiment herein, checksums alternate between different chains, and one skilled in the art will understand that various patterns are possible, but not exclusive, as defined herein. In such an embodiment, the chains are mutually exclusive, meaning that the chains do not contain any common links between them.
[0096] In one embodiment herein, the checksums are not combined into odd and even checksums, but may be combined in different patterns; or in multiple separate chains. In one embodiment herein, the chains are separated using sequential logic, e.g., 1, 3, 5, 7, etc., which may be embodied in the checksums. In one embodiment herein, the separation of various links into different chains is done via a period of time, 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 predetermined period of time, a predetermined number of checksums, a predetermined 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.
[0097] For example, if the predetermined period is one hour, every hour represents a separate link in the chain (e.g., C1 in FIG. 10). After the one hour has expired, the next link (e.g., C2 in FIG. 10) begins and may be assigned to a different or the same chain, as desired. In another example, if the number of checksums (in each link) is 1,000; or if the predetermined number of checksums is 1,000, a different link is created for every 1,000 checksums. Typically, there may be a pool of links or checksums that are placed / assigned to a chain in first-in, first-out (FIFO) order. In yet another example, the chain selection for each link (or checksum) uses a modulo method (see https: / / en.wikipedia.org / wiki / Modulo_operation) to divide the link (or checksum) by a number, and a remainder is used to select which chain to assign the link to. In another example, a portion of the checksum, e.g., three alphanumeric digits (prefix, suffix, or middle), 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, which is a common technique for "random" + round-robin (chain) selection.
[0098] In one embodiment 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 can add the alphanumeric digit "E35" to the beginning, middle, or end of this link and assign this link to the "E35" chain.
[0099] In one embodiment 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 one embodiment herein, it is assumed that each device possesses a different address.
[0100] In one embodiment herein, the first chain and the second chain are stored on the same server. Without intending to be bound by theory, it is believed that this may be desirable from a system architecture perspective as it makes the Tag Chain system easier to manage. In one embodiment herein, the first chain and the second chain are stored on different servers. Without intending to be bound by theory, it is believed that this may be desirable from a system architecture perspective as it makes the Tag Chain system more secure.
[0101] In one embodiment 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 create the next link in the chain are too large or exceed a predetermined value. Alternatively, the Tag Chain system may add one or more additional chains upon reaching a predetermined criterion, such as a predetermined number of links in existing and / or recent chains, or a predetermined period of time.
[0102] For example, different links (and therefore chains) may be separated by a particular time period, or a group of checksums, a group of transactions, etc. In one embodiment herein, each link in a chain includes from about 1 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 to about 10,000 transactions; or from about 100 to about 1,000 transactions. In one embodiment herein, the links for each chain are defined by a fixed time interval, where all transactions and / or checksums occurring within that time interval form a link (for the appropriate chain) and / or may be aggregated into a single link (for the appropriate chain). In one embodiment 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 a computer-implemented tag chain system and / or server. Alternatively, the time interval may be measured by, for example, an internal computer clock, a process, or that of an external server.
[0103] While not intending to be bound by theory, it is believed that the tag chains herein can provide significant advantages over a single, unified blockchain. For example, it is believed that as blockchains become longer, the timing of checksums (e.g., the time required to generate a cryptographic hash) will increase over time, requiring more energy and / or more computation time. It is believed that by utilizing tag chains, and therefore multiple actual chains within a single blockchain system, the overall speed of the blockchain system may be accelerated and / or may even provide additional benefits, such as lower energy consumption and less computation time, since, for example, the length of each individual chain will increase more slowly.
[0104] In one embodiment herein, different chains in the tag chain system are implemented and / or stored on a common server. In one embodiment herein, each different chain in the tag chain system is implemented and / or stored on a different server. In one embodiment herein, each different chain in the tag chain system is implemented and / or stored on multiple servers.
[0105] In one embodiment herein, the collective storage server creates a replicated database of evidence keys and any additional associated data.
[0106] In yet another embodiment, the evidence key may also include a time-dependent key that is independent of the content or any characteristics of the digital document generated by the system.
[0107] 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, collective storage servers, etc. are not limited by the description herein. It will be understood that the actual number can be adjusted based on the actual implementation of the present invention. Furthermore, additional algorithms can be implemented at different levels in different systems to improve the reliability and security 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.
[0108] While the present invention has been described above with reference to specific embodiments, it should be understood that the foregoing embodiments are provided merely as examples and do not limit or define the scope of the present invention. Various other embodiments, including but not limited to the foregoing, 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.
[0109] Any of the functions disclosed herein may be performed using means for performing such functions, including, but not limited to, any of the components disclosed herein, such as the computer-related components described below.
[0110] 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 running on (or executable by) a programmable computer including any combination of: a processor, storage media readable and / or writable by the processor (e.g., including 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 device to perform the described functions and to generate output using the output device.
[0111] Embodiments of the present invention include features that are possible and / or feasible only for implementation using one or more computers, computer processors, and / or other elements of a computer system. Such features are impossible or impractical to implement by thought and / or manually. As a result, such features are inherently rooted in computer technology and solve problems inherently related to computer technology. For example, embodiments of the present invention can generate cryptographic hashes (such as cryptographic hash 28 and cryptographic hash 28') on amounts of data and within amounts of time that are impossible or impractical to implement manually. For example, embodiments of the present invention can generate cryptographic hashes on one megabyte of data in less than one second, which a person cannot perform manually. As another example, embodiments of the present invention can deliver data over the Internet and / or telecommunications networks (e.g., via delivery 40 or delivery 40'), which would otherwise require the use of telecommunications facilities and would not be possible for a person to perform manually.
[0112] Claims herein that categorically require a computer, processor, memory, or similar computer-related elements are intended to require such elements and should not be construed as if such elements were not present in or required by the claim. Such claims are not intended to, and should not be construed to, encompass methods and / or systems lacking the recited computer-related elements. For example, method claims herein that recite a claimed method performed by a computer, processor, memory, and / or similar computer-related elements are intended to, and should be construed as, encompassing methods performed by the recited computer-related elements. Such method claims should not, for example, be construed to encompass methods performed by thought or by hand (e.g., using pencil and paper). Similarly, product claims herein that recite a claimed product performed by a computer, processor, memory, and / or similar computer-related elements are intended to, and should be construed as, encompassing products that include the recited computer-related elements. Such product claims, for example, should not be construed to encompass products that do not include the recited computer-related elements.
[0113] 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, which may be, for example, a compiled or interpreted programming language.
[0114] 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 steps of the methods 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 input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Typically, a processor receives (reads) instructions and data from, and writes (stores) instructions and data to, a memory (such as a read-only memory and / or a random-access memory). Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, such as, for example, semiconductor storage devices, including EPROM, EEPROM, 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). The computer also typically receives (reads) and writes (stores) programs and data from a non-transitory computer-readable storage medium, such as an internal disk (not shown) or a removable disk. These elements are also found in conventional desktop or workstation computers, as well as other computers suitable for executing computer programs that implement the methods described herein, and may be used in combination with any digital print or marking engine, display monitor, or other raster output device capable of producing colored or grayscale pixels on paper, film, a display screen, or other medium.
[0115] The data disclosed herein may be embodied in one or more data structures tangibly stored, for example, on a non-transitory computer-readable medium. Embodiments of the present invention can store data in and read data from such data structures.
[0116] Non-limiting embodiments of the present invention include: 1. A computer-implemented method for proving the existence of a digital document, the method comprising: A. obtaining a timestamp of a digital document; B. obtaining multiple cryptographic hashes of the digital document; C. generating an evidence key based on a timestamp and multiple cryptographic hashes; and D. Storing the evidence key to provide the stored evidence key A method comprising: 2.E. Retrieving Evidence Keys to Provide Retrieved Evidence Keys 2. The method of embodiment 1, further comprising: 3.F. Comparing the stored evidence key with the retrieved evidence key 3. The method of embodiment 2, further comprising: 4. The method of embodiment 2, wherein retrieval of the evidence key is enabled by providing an identifier; or wherein the identifier is selected from the group consisting of a cryptographic hash, additional associated data, and combinations thereof. 5. The method of any one of embodiments 1 to 4, wherein the timestamp is a plurality of timestamps. 6. The method of any one of embodiments 1 to 5, wherein the plurality of cryptographic hashes is between about 2 and about 100 cryptographic hashes; or between about 2 and about 25 cryptographic hashes; or between about 3 and about 10 cryptographic hashes; or between about 4 and about 8 cryptographic hashes. 7. The method of any one of embodiments 1-6, wherein each of the plurality of cryptographic hashes is generated by a different cryptographic hash function. 8. At least one of the cryptographic hashes is an unkeyed 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 Hash, Streebog 8. The method of any one of embodiments 1 to 7, wherein the cryptographic hash value is generated by a cryptographic hash function selected from the group consisting of 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. 9. The timestamp is a plurality of timestamps; or from about 2 to about 10 timestamps; 9. The method of any one of embodiments 1 to 8, comprising: or about 2 to about 8 timestamps; or about 3 to about 6 timestamps. 10. A method according to any one of embodiments 1 to 9, characterized in that the evidence key is stored 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 magnetic disk, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a flash memory, and combinations thereof. 11. A computer-implemented method for proving the existence of a digital document, the method comprising: A. obtaining multiple timestamps of a digital document; B. Obtaining a cryptographic hash of the digital document; C. generating an evidence key based on a plurality of timestamps and a cryptographic hash; and D. Storing the evidence key to provide the stored evidence key A method comprising: 12.E. Retrieving Evidence Keys to Provide Retrieved Evidence Keys 12. The method of embodiment 11, further comprising: 13.F. Comparing the stored evidence key with the retrieved evidence key 13. The method of embodiment 12, further comprising: 14. 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. 15. The method of any one of embodiments 11 to 14, wherein the plurality of timestamps includes from about 2 to about 10 timestamps; or from about 2 to about 8 timestamps; or from about 3 to about 6 timestamps. 16. A method according to 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 a combination thereof; or a time server, an independent clock, and a combination thereof; or a Global Positioning System (GPS) clock. 17. The method of any one of embodiments 11 to 16, wherein the cryptographic hash is a plurality of cryptographic hashes; or the cryptographic hashes are 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. 18. The method of embodiment 17, wherein each of the plurality of cryptographic hashes is generated by a different cryptographic hash function. 19. Cryptographic hash is an unkeyed 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 Hash, Streebog 19. The method of any one of embodiments 11 to 18, wherein the cryptographic hash value is generated by an unkeyed cryptographic hash function selected from the group consisting of 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. 20. A method according to any one of embodiments 11 to 19, characterized in that the evidence key is stored 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, a magneto-optical disk, a flash memory, a magnetic tape, and combinations thereof; or a hard disk, a flash memory, and combinations thereof. 21. A computer-implemented method for proving the existence of a digital document, the method comprising: A. obtaining a timestamp of a digital document; B. Obtaining a cryptographic hash of the digital document; C. generating an evidence key based on the timestamp and the cryptographic hash; and D. storing the evidence key to provide a stored evidence key, wherein the storage of the evidence key occurs on a plurality of storage media; A method comprising: 22.E. The method of embodiment 21, further comprising retrieving an evidence key to provide a retrieved evidence key. 23.F. The method of embodiment 22, further comprising comparing the stored evidence key with the retrieved evidence key. 24. 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. 25. A method according to 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. 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. 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. 28. The method of any one of embodiments 21 to 27, wherein the cryptographic hash is a plurality of cryptographic hashes; or the cryptographic hashes are 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. 29. Cryptographic hash is an unkeyed 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 Hash, Streebog 29. The method of any one of embodiments 21 to 28, wherein the cryptographic hash value is generated by an unkeyed cryptographic hash function selected from the group consisting of 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. 30. A computer-implemented method for proving the existence of a plurality of digital documents, the method comprising: A. receiving a plurality of cryptographic hashes during a first period of time; B. generating a current checksum based on a plurality of cryptographic hashes received during a first 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 time period; F. storing the checksum in the storage medium; and G. Replacing the checksum in the storage medium with the following checksum: A method comprising: 31. The method of embodiment 30, further comprising repeating steps D through G. 32. A computer-implemented method for proving the existence of a plurality of digital documents, the method comprising: A. receiving a plurality of evidence keys during a first time period; B. generating a current checksum based on a plurality of evidence keys received during a first 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 the checksum in the storage medium; and G. Replacing the checksum in the storage medium with the following checksum: A method comprising: 33. The method of embodiment 32, further comprising repeating steps D-G. 34. A computer-implemented method for proving the existence of a plurality of digital documents, the method comprising: A. receiving a plurality of cryptographic hashes during a first period of time; B. generating a current checksum based on a plurality of cryptographic hashes received during a first 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; F. storing the current checksum on a storage medium; G. receiving a plurality of cryptographic hashes during a period of time: H. generating a next checksum based on the multiple cryptographic hashes received during a next period and the current checksum of step B; I. storing the following 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 multiple cryptographic hashes received during a next period and the current checksum of step E; M. storing the checksum in the storage medium; and N. replacing the current checksum stored in step F with the next checksum stored in step M. A method comprising: 35. The method of embodiment 34, further comprising repeating steps G through N. 36. A computer system for verifying the existence of a digital document, comprising the method of any one of embodiments 1 to 35. 37. A computer-implemented tag chain system comprising: A. The first chain; and B. A second chain, wherein the first chain and the second chain are mutually exclusive. 1. A computer-implemented tag chain system comprising: 38. The tag chain system of embodiment 15, wherein the first chain and the second chain are stored on the same server. 39. The tag chain system of embodiment 16, wherein the first chain and the second chain are stored on different servers.
[0117] It will be appreciated 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.
Claims
1. 1. A computer-implemented method for proving the existence of a digital document, the method comprising: A. Obtaining a timestamp of a digital document; B. Obtaining multiple cryptographic hashes of the digital document; C. Generating an evidence key based on a timestamp and multiple cryptographic hashes; and D. Storing the evidence key to provide a stored evidence key A method comprising:
2. E. The method of claim 1, further comprising the step of retrieving an evidence key to provide a retrieved evidence key.
3. F. The method of claim 2, further comprising the step of comparing the stored evidence key with the retrieved evidence key.
4. 1. A computer-implemented method for proving the existence of a digital document, the method comprising: A. Obtaining multiple timestamps of a digital document; B. Obtaining a cryptographic hash of the digital document; C. Generating an evidence key based on multiple timestamps and cryptographic hashes; and D. Storing the evidence key to provide a stored evidence key A method comprising:
5. E. The method of claim 4, further comprising the step of retrieving an evidence key to provide a retrieved evidence key.
6. 1. A computer-implemented method for proving the existence of a digital document, the method comprising: A. Obtaining a timestamp of a digital document; B. Obtaining a cryptographic hash of the digital document; C. Generating an evidence key based on the timestamp and the cryptographic hash; and D. storing the evidence key to provide a stored evidence key, wherein the storage of the evidence key occurs on multiple storage media; A method comprising:
7. E. The method of claim 6, further comprising the step of retrieving an evidence key to provide a retrieved evidence key.
8. 1. A computer-implemented method for proving the existence of a plurality of digital documents, the method comprising: A. receiving a plurality of cryptographic hashes during a first period of time; B. generating a current checksum based on a plurality of cryptographic hashes received during a first period of time; 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 time period; F. storing the checksum in the storage medium; and G. Replacing the checksum in the storage medium with the following checksum: A method comprising:
9. 9. The method of claim 8, further comprising repeating steps DG.
10. 1. A computer-implemented method for proving the existence of a plurality of digital documents, the method comprising: A. receiving a plurality of evidence keys during a first time period; B. generating a current checksum based on a plurality of evidence keys received during a first period; C. storing the current checksum on a storage medium; D. receiving a plurality of evidence keys during a second period of time; E. generating a next checksum based on the plurality of evidence keys received during the second time period; F. storing the checksum in the storage medium; and G. Replacing the checksum in the storage medium with the following checksum: A method comprising:
11. 11. The method of claim 10, further comprising repeating steps DG.
12. 1. A computer-implemented method for proving the existence of a plurality of digital documents, the method comprising: A. receiving a plurality of cryptographic hashes during a first period of time; B. generating a current checksum based on a plurality of cryptographic hashes received during a first period of time; 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; F. storing the current checksum on a storage medium; G. receiving a plurality of cryptographic hashes during the following period: H. generating a next checksum based on the multiple cryptographic hashes received during a next period and the current checksum of step B; I. storing the following checksums 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 multiple cryptographic hashes received during a next period and the current checksum of step E; M. storing the checksum in the storage medium; and N. Replacing the current checksum stored in step F with the next checksum stored in step M. A method comprising:
13. 13. The method of claim 12, further comprising repeating steps G through N.
14. A computer system for verifying the existence of a digital document, comprising a method according to any one of claims 1 to 13.
15. 1. A computer implemented tag chain system, comprising: A. A first chain; and B. A second chain, wherein the first chain and the second chain are mutually exclusive. A tag chain system characterized by:
16. 16. The tag chain system of claim 15, wherein the first chain and the second chain are stored on the same server.
17. 17. The tag chain system of claim 16, wherein the first chain and the second chain are stored on different servers.