RU2792876C1 - Method for linking digital representation of actual event to its real time - Google Patents

Abstract

FIELD: digital technologies.

SUBSTANCE: invention relates to the field of linking the digital representation of the actual event to the real time of the actual event. The technical result is to ensure the determination of the exact time of occurrence of the actual event recorded as the event data, and ensure the reliability of the event data (to know that the specified actual event actually happened) without reference to human trust. The source event data S-ED of the actual source event SE are received and representations of the source data ED are sent to an immutable database for storage and creation of a real-time timestamp, the hash code HC is calculated using hash functions having data as input describing the state of the immutable database data, the original data SD, and the timestamp of the original data SD, the hash code HC is converted into a physical representation of the hash code HC, and includes the specified representation in the area of the original event SE to create a confirmation event CE, and receive the confirmation event data C-ED of the acknowledgment event CE and send representations of the CD acknowledgment data to an immutable database for storage and instant creation of the timestamp.

EFFECT: determination of the exact time of occurrence of the actual event recorded as the event data, and ensure the reliability of the event data.

29 cl, 7 dwg

Description

FIELD OF TECHNOLOGY

[0001] The present invention proposes a method of linking a digital representation of an actual event (such as, for example, a digital photograph or video) to the real time of its occurrence. This method does not require trust on the part of a person and is undeniable. In particular, the present invention relates to a method for generating a digital representation of an actual event linked to the real time of the occurrence of said actual event, as well as to an apparatus and a computer program product associated with said method. In addition, the present invention relates to a method for confirming the time certification of a digital representation of an actual event, linked to the real time of the occurrence of said actual event, as well as to an apparatus and a computer program product associated with the said method.

[0002] The present invention finds its application in any situation that requires reliable proof of any actual event with or without its real-time time stamp. It can be used, for example, to generate evidence of the occurrence of an actual event that will be used in legal proceedings, or to check whether an event depicted in a photograph posted, for example, on social networks, actually happened at a certain time.

[0003] Other examples include, but are not limited to, confirmation that a person is in a certain place at a certain time, confirmation of the completion of a task, confirmation of the real state of any object, such as, for example, a car, a yacht, a building, at a certain time, for example, for insurance purposes and rent.

BACKGROUND OF THE INVENTION

[0004] It is known in the art that an actual event can be captured by a digital device that is configured to record a digital representation of that event. The term "actual event AE" in the context of the present description means any event or any situation that exists in reality or as an actual circumstance that can be perceived by human senses or artificial intelligence (as opposed to, for example, purely abstract or virtual events such as calculations). The digital representation of the actual event is hereinafter referred to as event data. These events can be received either in a single mode (for example, as a photograph) or in a continuous mode (for example, as a video or sound recording). These events are usually used to confirm the occurrence of the actual events displayed in them, however, both the content of the event data and the time of their recording can be questioned. As a result, the event data is not sufficient to provide reliable evidence of the occurrence of the actual event or indicate the real time of its occurrence. Temporarily reliable confirmation of an actual event, as well as determining whether an event has occurred, requires credibility provided by a third party (for example, a human witness or some authoritative source), usually in the form of written confirmation, verbal confirmation, or both.

[0005] Theoretically, to obtain indisputable proof that a certain event actually happened at a certain time, at least three things are required: 1) reliable data of the event, 2) a reliable time stamp, and 3) a certain relationship between them to link to each other. Although little attention has been paid to this task, it is worth noting that it is these requirements that apply to all event data that are used as evidence in legal proceedings.

Reliable event data

[0006] Acquiring event data is generally a relatively simple process thanks to digital devices such as smartphone cameras. However, these events can be modified or even created. As a result, there is no certainty that these events are not faked.

Reliable Timestamp

[0007] A reliable timestamp is readily obtained from many sources, since the generation of a reliable timestamp is required for all network transactions, including banking transactions and network server related matters (such as data synchronization). However, event data may be timestamped from a highly unreliable source, such as the internal clock of the device used to collect the event data.

Relationship between reliable event data and reliable timestamps

[0008] Establishing a relationship between a timestamp and event data is very important for the purposes of confirming that an actual event occurred at a specific time.

[0009] Typically, this relationship should be provided with timestamps. All methods of generating timestamps are similar: after collecting the data that needs to be timestamped, the timestamp comes from some source and is attached to the data. This process does not guarantee the validity of timestamped data, nor any information about the real time it was created.

[0010] In the simplest solutions, which do not require the participation of third parties, the timestamp is generated and attached locally, for example, by the device receiving the event data (eg, a smartphone). This solution cannot be considered reliable because the data, both the event data and the timestamp data, can be modified.

[0011] In the most complex solutions, a trusted third party (eg, a trusted timestamping authority) stores a complete or abbreviated record of the data with a timestamp, but even in this case, nothing is known about the time of creation and the validity of the data.

[0012] As shown above, all known solutions that tie event data to a timestamp require human trust. Trust is usually applied to recognize something as trustworthy or not, in situations that cannot be proven in a mathematical or logical way. The main disadvantage of human trust is that it depends on the intentional or unintentional actions of a person and cannot be associated with any mathematical or logical proof. Therefore, it does not give absolute certainty about the subject to be trusted.

[0013] In the case where event data is used as evidence of an actual event, there is still no direct reliable way to determine the validity of the event data and the real time of the actual event displayed in them. Therefore, an indirect method is used to determine the approximate time of an event, such as, for example, eyewitness testimony. This process depends on the person: it depends, among other things, on the perceptual skills, memory and desire of the witness. The witness may be intentionally or unintentionally mistaken, or may not remember all the information necessary to confirm both the event itself and the time when the event occurred. Another disadvantage of having a human witness verify both the time of an event and the event itself is that the credibility of one witness can be perceived differently by different individuals or organizations. In complex court cases, multiple human witnesses are preferred or even required rather than just one witness.

[0014] To address the need for trust in authenticating data/documents and when they were created, there is a widely accepted concept of trusted third parties (such as timestamping authorities) whose role is to provide undeniable trust. Aside from the fact that this solution only grants "trust" to those who are deemed trustworthy, trusted third parties only provide information about the exact time of data transmission that existed previously, with no indication of when the data was created, and no guarantee of the validity of the timestamped data. Such illustrative known methods for creating timestamps are given below.

[0015] US Patent Application US 20060117182 discloses a document authentication system and method that combines digital and non-electronic (or visual) authentication methodologies in an integrated, unified manner. In addition to providing digital authentication features, the present invention creates a physical artifact that can be verified by the naked human eye. However, since the purpose of the present invention was to authenticate tamper-proof documents, it only attaches some data to an already transmitted (scanned) document and, at best, only allows confirmation of the exact time of transmission.

[0016] U.S. Patent Publication US 10313360 relates to cryptographic tamper detection, as well as time stamping and claimed document date. The description of the present invention discloses a computer-implemented method of using distributed registries to generate evidence for the subsequent confirmation of the integrity of a document, and this method is performed by a processor. A trusted timestamping authority (TTSA) may be involved, but even if the TTSA loses trust or the opponent refuses to validate the timestamp, the electronic document can still be dated. However, the described method does not provide reliable information either about the time of creation of the processed document, or about its reliability.

[0017] A reliable timestamping system that employs TTSA is also known in the art, in which the document author's computing resources communicate with the TTSA. The document is created and hashed using a hash function to obtain the hash value of the document, which is passed to TTSA. After receiving the hash value of the document, TTSA generates a timestamp, adds it to the hash value of the document, and hashes the combination with the hash function to obtain the sync hash value. The hash functions can be identical, but they don't have to be. Sync hashes encrypted with a public key encryption module use the TTSA private key to generate an encrypted hash value. The encrypted hash value and timestamp are passed back to the author's computing resources to be combined with the document in the document record. Thus, the document is timestamped and ready for date verification at a later time. It is important to note that the timestamp does not set the time the document was created, but only sets when the hash value of the document was received by TTSA. That is, if the document is many years old when the timestamp process began, the timestamp will not reflect the actual earlier creation date, but only the later date when the document's hash value was received by TTSA. Therefore, the discussed known system only allows documents to be authenticated (but without any reference to their authenticity) and only allows to determine the exact time of their transmission, and not the time of creation.

[0018] There is also a method disclosed in Korean Patent Application KR20330126815 to prevent forgery and protect media evidence by transmitting contextual information such as hash value, creation date, creation location (according to GPS), creation device tilt (by gyroscope), and identification. creation devices. This contextual information is generated when creating multimedia content such as a photograph, etc., using an external device such as a smartphone, smart tablet, etc., and sent to the Timestamp Service Agency, which is a trusted third party , via the network, and receiving the issued timestamp including the hash value of the context information.

[0019] However, even in this solution, there is no certainty that the downloaded media file displays a specific event that just happened. The timestamp is attached only to the transferred data and should be considered as an additional description of the transferred file, but obviously not as a real-time timestamp of the occurrence of the event.

[0020] Because good quality reliable event data and a reliable timestamp can be obtained relatively easily, communication between the two is still a problem.

[0021] In summary, if the data to be processed by modern reliable timestamping methods is event data (i.e., it displays a certain actual event), then there is no way to determine either the actual time of occurrence of the displayed event nor the validity of these event data. In all known solutions, trust is needed to determine the time of occurrence of the displayed event and validate the displayed content. Modern reliable methods of creating timestamps guarantee only one thing: the timestamped data existed before the exact point in time - the actual moment the timestamp was generated. In particular, there is no certainty that, prior to the timestamping process, the data itself was not tampered with or even created as false evidence of something that never happened.

[0022] A weak aspect of known solutions is that tying event data to a real-time timestamp requires human trust. This is because there is no definitive way to link reliable event data to a reliable real-time timestamp obtained at the time the "event data" was received.

THE TASK TO BE SOLVED

[0023] Thus, the purpose of the present invention is to provide an undeniable way to determine the exact time of occurrence of an actual event recorded as event data, as well as to ensure the validity of this event data (to know that said actual event actually happened) without reference to human trust.

SUMMARY OF THE INVENTION

[0024] According to a first aspect of the present invention, a method is provided for generating a digital representation of an actual event tied to a real time occurrence of said actual event. Said method includes receiving the source event data S-ED of the actual source event SE, which must be digitally documented, sending the source data S-D, which is a representation of the source event data S-ED, to an immutable database for registration and creation of timestamps, obtaining a real-time representation of the NS hash code calculated using a hash function having as input at least: initial data S-D, timestamp of initial data S-D, and data describing the state of said immutable database. The method further includes physically presenting said HC hash code representation to the senses to ensure that said HC hash code representation is included in the original SE event region to generate a CE confirmation event, further obtaining the CE confirmation event C-ED confirmation event data, and sending acknowledgment data C-D, which is a representation of acknowledgment event data C-ED, to an immutable database for registration and creation of timestamps.

[0025] Preferably, the original data S-D is the fingerprint of the original event data S-ED and/or the acknowledgment data C-D is the fingerprint of the acknowledgment event data C-ED. In such a case, S-ED initiating event data and/or C-ED acknowledgment event data should be stored in an immutable database or elsewhere, e.g. locally by the originator, preferably in the system to generate a digital representation of the actual event linked to the real time occurrence of the specified event. actual event.

[0026] Preferably, data largely indicative of the input of the hash function that calculates said fingerprint is stored along with the original data S-D and/or confirmation data C-D in an immutable database.

[0027] According to a second aspect of the present invention, a system is provided for generating a digital representation of an actual event tied to a real time occurrence of said actual event. It comprises digital recording means configured to receive initiating event data S-ED of an actual initiating event SE to be digitally documented, communication means configured to send initial data S-D, which is a representation of the initiating event data S-ED, to an immutable database for registering and creating timestamps and configured to obtain a real-time representation of the HC hash code calculated using a hash function having at least: initial data S-D, a timestamp of initial data S-D and data, describing the state of the specified immutable database. Said system further comprises presenter means for physically presenting said HC hash code representation for sensory perception to ensure that said HC hash code representation is included in the source event SE area to create a CE confirmation event, the digital recording means being further configured to receive event data acknowledgment C-ED of the acknowledgment event CE, wherein the communication means is further configured to send the acknowledgment data C-D to an immutable database to be registered and timestamped, the acknowledgment data C-D being a representation of the acknowledgment event data C-ED.

[0028] According to a third aspect of the present invention, a computer program product is provided. The computer program product comprises instructions that, when executed by a computer, cause the computer to execute a method for generating a digital representation of an actual event associated with the real time occurrence of said actual event, according to the present invention.

[0029] According to a fourth aspect of the present invention, a method is provided for providing temporal certification of a digital representation of an actual event tied to the real time occurrence of said actual event. It includes obtaining S-D source data which is a representation of the S-ED source data of the actual SE source to be digitally documented, storing the S-D source data in an immutable database, creating a real-time timestamp through the S-D source data with a timestamp obtained from a reliable source, storing the timestamp in an immutable database, determining the state of the immutable database at a specific time indicated by the specified timestamp, calculating the hash code of the HC using a hash function that has as input at least: data S-D, the timestamp of the original data S-D and data describing the state of the specified immutable database, sending real-time representation of the hash code HC to be included in the area of the actual initiating event SE, receiving confirmation data C-D, which is a representation of the data of the confirmation event C-ED confirmation event CE, wherein the confirmation event CE is the initial event SE, containing additionally physically included representation of the HC hash code in its area, storing confirmation data C-D in an immutable database, creating a real-time timestamp for confirmation data C-D with a timestamp obtained from a trusted source and storing the timestamp of the C-D confirmation data in an immutable database.

[0030] However, according to another aspect of the present invention, there is provided a computer program product comprising instructions that, when executed by a computer, cause the computer to execute a method for providing temporary certification of a digital representation of an actual event, linked to the real time occurrence of said actual event, according to the present invention.

[0031] However, according to another aspect of the present invention, a system is provided for providing temporal certification of a digital representation of an actual event tied to the real time occurrence of said actual event. Said system comprises at least one storage device containing an immutable database, at least one processor and a communication means, wherein said communication means is configured to receive and store initial data S-D, which is a representation of the initial event data S-ED of the actual initial event SE , which must be digitally documented, wherein said immutable database is configured to generate real-time timestamps of raw S-D data with a timestamp obtained from a reliable source, and is further configured to store said raw S-D data and timestamp of raw data. data S-D, wherein said at least one processor is configured to determine data describing the state of said immutable database at a specific time indicated by the timestamp obtained when creating the timestamp of the original data S-D, and is configured to calculate the HC hash code using a hash function having at least as input: data describing the state of the immutable database, the original data S-D, and the timestamp of the original data S-D, and the communication means is further configured to send a representation of the hash code HC and receive confirmation data C-D, which is a representation acknowledgment event data C-ED of the acknowledgment event CE, wherein the acknowledgment event CE is an initial event SE, containing additionally physically included representation of the hash code HC in its area, and the specified immutable database is additionally configured to receive and store the specified acknowledgment data C-D and real-time timestamping of C-D acknowledgment data with a timestamp obtained from a reliable clock source.

[0032] Advantageously, the immutable database is distributed ledgers.

[0033] According to another aspect of the present invention, there is provided a method of associating event data of an actual event with a time stamp of its receipt in real time without reference to human trust and in such a way that the validity of the event data (i.e., the occurrence of the actual event) cannot be subjected to doubt. This method includes the following steps: obtaining the source event data S-ED for the actual source event SE and sending the source data S-D, which is a representation of the source event data S-ED, to an immutable database for storage and creating timestamps in real time, calculating the hash code of the NS using hash functions having at least as input: data describing the state of the immutable database, the original data S-D and the timestamp of the original data S-D, converting the hash code of the NS into a representation of the hash code of the NS and saving the method used to perform the transformation, mapping a real-time representation of the HC hash code to include said representation in the region of the original SE event to create a CE confirmation event, wherein the CE confirmation event is the original SE event with the hash representation physically present in its region. HC code, receiving confirmation event data C-ED of the confirmation event CE, and sending confirmation data C-D, which is a representation of the confirmation event data C-ED, to an immutable database for storage and instant creation of a timestamp.

[0034] The method according to the present invention links these events to the actual time of occurrence of the actual event displayed in them. This creates irrefutable evidence that the event displayed in the event data occurred at the exact time and that the event data is valid (not tampered with). According to the present invention, the method provides such reliability of the created evidence that it can be used, for example, in court proceedings.

[0035] By applying an immutable database and instantly timestamping the actual event data, and by including a real-time representation of the HC hash code in the actual event area, both the validity of the event data and the real time of data creation are ensured. Since this method is based solely on mathematical calculations, it is undeniable.

[0036] The specified immutable database is a data structure that replaces any human witness or authoritative source (trusted authorities, notaries, eyewitnesses, etc.).

[0037] Due to the fact that the database is immutable in its structure (for example, distributed registries), it is not possible to change the data already stored in it. In addition, if the immutable database is distributed ledgers (or if the said database uses a similar technology), the reliability of its data is provided by the structure. The immutable database is configured to generate data defining its state, for example, by calculating a number that uniquely characterizes the data already stored in it, for example, a fingerprint of all data already stored in it.

[0038] The relationship between the event data and the timestamp is only established and confirmed by an immutable database and a system for generating a digital representation of the actual event, tied to the real time of occurrence of the specified actual event applied by the creator. Therefore, with the exception of the creator's system, no one else, such as a human witness, is required.

[0039] The relationship between the event data and the real-time timestamp is obtained by obtaining the event data of some actual event. Event data is collected twice: before and after inclusion of the HC hash code representation in the actual event area. Both types of event data are stored in an immutable database.

[0040] Due to the event data displaying the same actual event before and after the inclusion of the HC hash code representation, there is no doubt that the HC hash code representation was included in the actual event scope. The presence of an HC hash code representation in the actual event area is proof that the creator knew that HC hash code representation at least at the time it was included.

[0041] An undoubted relationship between the actual event displayed in the event data and the real time of occurrence of the actual event is achieved due to the fact that the source event data S-ED and the confirmation event data C-ED display the same actual event, with the only difference being that the confirmation event data C-ED contains in its scope an included representation of the hash code HC that was generated by the immutable database using as input at least the original data S-D, the timestamp of the original data S-D, and data describing the state of the specified immutable database. Therefore, there is no doubt that the originator knew this unique HC hash code, and therefore could have created the CE confirmation event by including the HC hash code representation in the scope of the original SE event.

[0042] Through the use of cryptographic hash functions in calculating the hash code, the hash code itself is indisputable proof of the simultaneous existence of all input values that were used to calculate it.

[0043] In addition, by selecting a hash function input type that includes at least: an event data representation (before the hash code is included), a real-time timestamp of said event data representation, and an immutable database state, an undeniable connection with the real time of occurrence of the documented actual event. These three input values are significant and necessary to confirm the simultaneous existence of three different datasets:

- event data ED, which represents a certain actual event AE before the hash code representation HC is included

- timestamp of event data received from a trusted source

- the state of an immutable database at a specific point in time, determined by the specified timestamp.

[0044] Due to this structure of the described invention, a hash code representation that is included in the actual event area is sufficient to prove that the actual event displayed in the event data occurred at a certain time and that the event data was not tampered with. By using hash functions to calculate the hash code of the HC, the resulting level of reliability of the present invention is the same as that of commonly used functions for the purpose of network operations such as logging, financial transactions, etc.

[0045] In the case of event data obtained in a single mode (in the form of a photograph), due to the double registration of the same scene, namely with and without the presentation of the HC hash code, proof of the occurrence of the event is obtained. This is because the second registration of this event contains a physically recognizable representation of the NN hash code in its physical context. The achievable accuracy of the method when collecting event data in a one-time "real-time" mode implies seconds.

[0046] In the case of event data received in a continuous mode (in the form of video or sound recordings), due to their continuity, the inclusion of the HC hash code representation is performed in real time. The achievable accuracy of the method when collecting event data in continuous mode means "real time" milliseconds.

BRIEF DESCRIPTION OF THE DRAWINGS

[0047] For a more complete understanding of the present invention, reference is made to the following description, taken in conjunction with the accompanying drawings, in which:

in FIG. 1 is a diagram illustrating a method for linking a digital representation of an actual event to the real time of its occurrence, according to the present invention;

in FIG. 2 is a schematic view of a system for generating a digital representation of an actual event linked to a real time occurrence of said actual event, according to the present invention;

in FIG. 3 is a flowchart of the steps performed by the system used by the creator 1;

in FIG. 4 is a schematic view of a system according to the present invention containing an immutable database;

in FIG. 5 is a flowchart of the steps performed by a system containing an immutable database according to the present invention;

in FIG. 6 is a flowchart of steps taken by a system containing an immutable database to enable verification of the indisputable time of occurrence of an actual event displayed in a digital representation;

in FIG. 7 is a flowchart of the steps taken by the end user 4 to verify the undeniable time of occurrence of the actual event displayed in the digital representation.

DETAILED DESCRIPTION OF EMBODIMENTS

[0048] The present technology is typically used to capture actual events in digital form as event data (photos, videos, etc.). As mentioned earlier, for all practical purposes, these given events, correctly represented, are subject to human sensory inspection - at least through visual perception [sight] and / or hearing (for example, actual events depicted in photographs, video recordings or sound recordings ). At present, among the various types of sense organs used by a person to perceive an event, only hearing and vision can be digitally captured and then read by human sensory inspection, however, the present invention is not limited in this respect in the future.

[0049] The term "actual event AE" in the context of this document means any event or any situation that exists in reality or in fact, which can be perceived by the human senses or artificial intelligence (as opposed to, for example, purely abstract or virtual events , such as calculations). In addition, event data ED means a digital record of the actual event AE. The ED event data can be obtained in two ways: in a single mode, in which case the ED event data is, for example, a photo, or in a continuous mode, in which case the ED event data is, for example, a video recording or an audio recording.

[0050] Next, with reference to FIG. 1-5, a method for linking a digital representation of an actual event to a real time occurrence of the actual event will be described. The method according to the present invention includes several steps performed in a common manner, namely, a system 100 used locally or remotely by the creator 1, as well as a remote system 200 belonging to a third party 2, and said remote system 200 contains an immutable database 203 (digital witness DW 203) and communication with a reliable clock source 300. In this document, the term "creator 1" means one or more people or one or more organizations, including artificial intelligence or similar algorithm(s) operating to create a link between a documented actual event and a timestamp in real time mode.

[0051] The implementation of FIG. 1 and 3 of the method according to the present invention starts from step 10 of obtaining data of the initiating event S-ED of the initiating event SE. In this document, the term "original event SE" means an actual event intended to be tied to the real time of its occurrence, in other words, the originating event SE is an actual event AE, which must be reliably recorded. The term "initiating event data S-ED" (as opposed to acknowledgment event data C-ED received later) means the ED event data of the initiating event SE (as opposed to acknowledgment event CE documented later). The proof of application of the technology according to the present invention will be the result of the process of creating/generating a digital representation of the actual event, which will be tied to the real time of its occurrence, as described below.

[0052] The step 10 of obtaining data of the initial event S-ED is performed by the system 100 (as shown in Fig. 2) to generate a digital representation of the actual event AE, tied to the real time of its occurrence. For example, step 10, as well as other steps depicted in FIG. 3 may be implemented by creator 1 using a smartphone 100, tablet 100, or drone 100. However, creator 1 may use any device or set of devices that includes all of the features described below with reference to FIG. 2. As mentioned earlier, S-ED initiating event data acquisition can be performed in a single or continuous mode. After completion of step 11 of data acquisition, a digital representation of the actual event is provided, which must be tied to the real time of the occurrence of said actual event.

[0053] Then, the execution of the method proceeds to step 12, in which the system 100 outputs and sends the original data S-D, which is a representation of the data of the original event S-ED, to the external system 300 for storing and creating timestamps (temporal certification). The purpose of sending the original data S-D to a specific remote location is to store them and create a timestamp in real time, and, based on this data, the ability to calculate a unique hash code of the HC using a hash function that also has data as input, describing the state of the specified immutable database. As will be described below with reference to FIG. 4, said remote system 200 contains a particular immutable database 203, which for the purposes of this description is referred to as digital witness DW 203. As will be described below with reference to FIG. 5, the digital witness DW 203 finally receives said raw data S-D for further processing and storage. In this document, the term "original data S-D", which is a representation of the original event data S-ED, means the complete data of the original event S-ED or its representation, for example, a fingerprint of the complete data of the original S-ED event, or encrypted data of the original S-ED event.

[0054] Preferably, the step 12 of sending the initial data S-D for external registration and external temporary certification, namely the creation of a timestamp by the immutable database 203, is preceded by the step 11 of calculating the data footprint of the initial event S-ED. The data footprint of the initiating event S-ED is computed using HF hash functions. Preferably, but not necessarily, if a fingerprint is used, the meaningful SHFID hash input is then sent along with the original data S-D to the immutable database 203. The term "Significant SHFID hash input" means in this document data that can be used to a unique characteristic of the input data of the hash function HF, which calculates the fingerprint. The assignment of meaningful inputs to the SHFID hash function is, for example:

- increasing resistance to forgery of reliable data used by the HF hash function to calculate the fingerprint,

- minimizing the risk of collision when calculating the fingerprint - a collision occurs if the HF hash function calculates the same fingerprint for different input data (the risk of collision is almost negligible),

- determining the size of the input data for the HF hash function,

- elimination of known or expected (possible) vulnerabilities associated with the HF hash function.

[0055] The meaningful input of the SHFID hash function can be any data characterizing the input of the HF hash function (e.g., the first or last few bytes of the input), however, if the HF hash function has any vulnerability, the meaningful input SHFID hash data must at least target this vulnerability in order to mitigate it. For example, if the HF hash function is susceptible to a "message lengthening attack" (although such an HF hash function is generally not recommended), the meaningful input to the SHFID hash function should contain at least the size of the HF hash input.

[0056] Regardless of whether the original data S-D is a fingerprint or not, the original event data S-ED may be stored outside the digital witness DW 203. Storing the complete original event data S-ED is mandatory when it does not exist in the digital witness, for example if only their fingerprint was sent to the digital witness DW 203.

[0057] Upon completion of the sending step 12, a digital representation of the actual initiating event is provided, which should be tied to the real time of the occurrence of said actual event. The method then proceeds to step 13 of receiving from the remote source, namely the system 200 (as described below with reference to FIG. 4), a representation of the HC hash code calculated based on at least: data describing the state of said immutable database 203 (digital witness DW 203), wherein the original data S-D and the timestamp of the original data S-D are the timestamp obtained at the time of receiving the original data S-D by the system 200 containing said immutable database 203. The Hash Code Representation HC is referred to herein as the Transmitted Hash Code THC, and its meaning will be given later in the present specification.

[0058] The next step is the output step 14 by means of a physical representation, a sensory presentation of the HC hash code. The sense perception of the representation of the hash code of the NN is required by the creator 1 to learn about the code that should be included in the scope of the documented actual event. Preferably, as already mentioned, the representation of the hash code HC is called the transmitted hash code THC. Hereinafter, the term "transmitted hash code THC" means a representation of the hash code HC, which is transmitted from the digital witness DW 203 to the creator 1, to be included in the area of the original event SE. The transmitted THC hash code may be, among other things:

- a full alphanumeric string equal to the HC hash code, or

- an abbreviated form of the NA hash code obtained using any mathematical function (such as, for example, RFC4226 developed by the Internet Engineering Task Force), or

- any other form perceived by the creators' sense representation, such as a word, graphic, number, gesture, action, including the action performed by the device that receives the event data, or

- a combination of one or more of the above.

[0059] In this case, it should be noted that the method according to the present invention is based on the physical inclusion of content (namely, the representation of the hash code of the HC), which depends on at least: (1) the presentation of the event data (before including the representation of the specified code), (2) the current time; and (3) the state of the digital witness DW 203 (immutable database 203). Said content must be included in the actual event domain, while the role of the digital witness DW 203 is to store a representation of the event data ED before and after said content is included in the actual event domain AE. It is very important to distinguish the "actual event area" from the binary content of the ED event data. From a logical point of view, the event data ED can be considered as a binary representation of a certain actual event AE with its area, which can be displayed and recognized in a sensible way (human processing), as well as a set of bytes, which is subject to machine processing. Hereinafter, the term "actual event area" means the physical layer (environment) of the recorded actual event, in contrast to the "binary content" of the ED event data. As a result, including the HC hash code representation in the actual event domain refers to all activities that will result in physical recognition of the included content at the physical layer of the displayed actual event. Inclusion in the scope of the actual event, in particular, does not imply any binary changes to the received ED event data.

[0060] The inclusion of the transmitted THC hash code in the scope of the original event SE is performed in such a way as to provide undeniable evidence that the representation of the hash code of the HC was known at the time of its inclusion. For example, if the inclusion was performed by writing a representation of the hash code HC (transmitted hash code THC) on a sheet of paper, and this sheet of paper was placed in the context of the original event SE, and the data of the confirmation event C-ED is a photograph, then the transmitted hash - the THC code written on a piece of paper must be legible in this photo.

[0061] An important issue is the inclusion of the transmitted THC hash code in the originating event SE area, if the physical presence of the creator 1 in the originating event SE area is not possible, for example, when receiving ED event data in continuous mode using the aircraft camera. In this case, the only possible interaction with the source event area can be performed by the ED event data collector, namely the system 100. The transmitted THC hash code in this case should be one or more actions that can be performed by the creator 1 using a remote event data acquisition device (e.g., a drone with a camera), including, but not limited to, changing the perspective, angle, or frame of the received event data to make the inclusion of the transmitted THC hash code recognizable in the context of the received C-ED confirmation event data.

[0062] Summarizing, it should be noted that the inclusion of a representation of the HC hash code, namely the transmitted hash code of the THC, in the area of the original event SE is the act of physically transferring the transmitted hash code of the THC by the creator 1 to the physical area of the original event SE (the area where the actual initiating event occurs) in any way possible to create a confirmation event CE (which links together the originating event SE and the transmitted THC hash code) to provide undeniable certainty that the creator 1 knew the transmitted THC hash code at the time its inclusion in the area of the initial event SE. The inclusion of the transmitted THC hash code in the physical area of the initiating event SE can occur, for example: for individual events - recording the transmitted THC hash code, preferably manually, on a sheet of paper and placing this sheet of paper in the context of the initiating event SE, for continuous events - video recording the process of writing the transmitted THC hash code in the context of the original event SE, preferably manually, or speaking the transmitted THC hash code, preferably by the creator, without interrupting the receipt of the event data.

[0063] The inclusion of the transmitted THC hash code in the source event area SE should not be performed without interaction between the event area and the creator 1 itself. Therefore, for example, if the event data is received remotely (for example, using a drone camera), and the creator 1 does not the ability to directly include the transmitted THC hash code in the scope of the original event SE, the inclusion must be performed by performing an action or actions corresponding to the content of the transmitted THC hash code (including, but not limited to, changing the aspect, scale or angle of the received event data).

[0064] The method then proceeds to step 15 of obtaining acknowledgment event data C-ED for the acknowledgment event CE, wherein the acknowledgment event CE is the original event SE, further comprising a representation of the received hash code HC, hereinafter also referred to as transmitted TNS hash code.

[0065] If ED event data is received in continuous mode, i.e. as a continuous video or audio recording, the C-ED acknowledgment event data may contain the S-ED source event (namely, the S-ED source event data may be part of the C-ED acknowledgment event data). In this case, the original data S-D is sent to the digital witness DW 203 without interrupting the receipt of the event data ED. Also in this case, the inclusion of the transmitted hash code THC in the area of the original event SE occurs in real time, and the acknowledgment data C-D, which is the acknowledgment event data C-ED, is sent to the digital witness DW 203 immediately after the completion of receipt of the acknowledgment event data C- ED.

[0066] If the continuity of the ED event data received in continuous mode is maintained, the real time of occurrence of all actual events contained in the initial event data S-ED and the confirmation event data C-ED can be determined. Maintaining the continuity of the ED event data that is received continuously means that it must be capable of perceptual (eg, visual and/or audible) verification of the event being displayed during the verification process. A negative example of continuous mode ED event data that does not preserve continuity would be video with little detail that is blurry, generally poorly lit, containing visual noise or noises instead of clear sounds.

[0067] If the S-ED initiating event data is only stored as part of the C-ED acknowledgment event data (for example, in the case of a continuous ED event data acquisition mode), storing information about the size of the S-ED initiating event data, preferably in the digital witness DW 203 , should be mandatory for the purposes of generating the HC hash code representation. If this information is missing, the data size of the original S-ED event can theoretically be determined using a time-consuming "brute-force" method. This method generates a hash code representation of the HC by using an incremental number of initial bytes of the C-ED confirmation event data as the data representation of the original event S-ED until the hash code representation matches the corresponding value stored in the digital witness 203. The "brute force" method ” is time consuming and could theoretically lead to ambiguity.

[0068] If the initial event SE is registered in a one-time mode (for example, in the form of a photograph), then for time accuracy, including the transmitted THC hash code in the area of the initial event SE, as well as receiving confirmation event data C-ED and sending confirmation data C-D, being data representation of the C-ED acknowledgment event, in the digital witness DW 203, should occur one after the other, preferably in the shortest possible time. (In this embodiment, the time of occurrence of the event can be set to within a few seconds or in near real time).

[0069] The next step is step 17 of outputting and sending confirmation data C-D, which is a representation of confirmation event data C-ED, to the external system 200 for storing and creating a timestamp (temporal certification) to provide confirmation of the inclusion of the transmitted THC hash code in source event SE.

[0070] As used herein, the term C-D acknowledgment data, which is a representation of C-ED acknowledgment event data, means the complete C-ED acknowledgment event data or a representation thereof, such as a fingerprint of the complete S-ED acknowledgment event data, or encrypted event data. confirmation of C-ED.

[0071] In order to provide the most accurate possible confirmation of the time of the actual event, and to provide the most reliable time stamping process possible, both the original S-D data and the CD confirmation data should be sent to the digital witness DW 203 as soon as possible after they are received:

- in the case of a continuous event data acquisition mode (e.g. video/sound recording), the raw data S-D must be sent to the digital witness DW 203 and recorded in it in real time, without interrupting the acquisition of the event data, while the confirmation data C- D must be sent to and recorded in the digital witness DW 203 immediately after the C-ED acknowledgment event data has been received;

- in the case of a single event data acquisition mode (eg photograph) - immediately after the completion of the acquisition of the initial S-ED event data and immediately after the completion of the acquisition of the C-ED confirmation event data.

[0072] Preferably, step 17 of outputting and sending confirmation data C-D for external registration and external temporary certification by immutable database 203 is preceded by step 16 of calculating the fingerprint of confirmation event data C-ED. The fingerprint is calculated using the HF hash function. Preferably, but not necessarily, the meaningful input of the SHFID hash function is then sent along with the confirmation data C-D to the immutable database 203. Regardless of whether the confirmation data C-D is a fingerprint of the confirmation event data C-ED or not, the confirmation event data The C-EDs may be stored locally by the creator 1. For example, the creator 1 may store them in the storage device of the system 100 or on a computer-readable storage medium (not shown). In this document, all provisions relating to the S-ED initiating event data footprints described previously apply.

[0073] It should be noted that applying the fingerprints (S-ED source event data fingerprint and/or C-ED acknowledgment event data fingerprint) in step 12 or step 17 is a convenient option, for example, if the S-ED source event data or acknowledgment event data C-ED is large if the bandwidth of the connection to the external immutable database, namely the digital witness DW 203, is too low to allow efficient data transmission, or if the complete event data must be kept confidential for some reason.

[0074] The complete event data used to calculate each fingerprint must be stored in any, not necessarily the same, location chosen by the creator 1 or in the digital witness DW 203, because during the verification process this is required both for recalculating the fingerprint, so for sensory inspection.

[0075] Once the step 17 of sending the received C-ED confirmation event data for external registration and temporary certification to the digital witness DW 203 is completed, a digital representation of the actual event is provided, linked to the real time occurrence of said actual event. Thus, a digital representation of an actual event, referenced to its real time, is created as a result of two separate physical acts of registration on the side of the creator.

[0076] Advantageously, as shown in FIG. 3, the method for generating a digital representation of an actual event, linked to the real time occurrence of said actual event, in accordance with the present invention and performed by the system 100, includes an additional step 18 of obtaining evidence of the occurrence of the POEO event. This optional step 18 includes obtaining, from the immutable database 203, a storage confirmation of the original data S-D and/or confirmation data C-D, preferably with the corresponding timestamps of the original data S-D and/or confirmation data C-D and hash code HC. Hereinafter, the term "evidence of the occurrence of the POEO event" is an optional final information received by the system 100, containing any data useful for the purposes of convenient and reliable verification of the relationship between the event displayed in the initial event data S-ED and its occurrence time. This data may include, for example: S-ED initial event data, S-ED initial event data timestamp, HC hash code, transmitted THC hash code with its generation method(s), C-ED acknowledgment event data, time acknowledgment event data stamp C-ED, C, acknowledgment hash of the SNA (computed, for example, by system 200 or immutable database 203 as explained below), data location information in digital witness DW 203, type and name of digital witness DW 203 , methods for calculating/generating each of the above values, information about the significant input data of the SHFID hash function, information about the source(s) of timestamps for the source event data S-ED and the confirmation event data C-ED, and other relevant information.

[0077] It should be noted that the event data received before (original event data S-ED) and after (confirmation event data C-ED) inclusion of the transmitted hash code (THC) in the original event (SE) area must display one and the same actual event AE.

[0078] Moreover, the source event data S-ED and the acknowledgment event data C-ED must represent the same actual event AE, however, they do not have to be received in the same mode (single or continuous). For example, S-ED initiating event data may be acquired in a single mode, such as a photograph, while C-ED confirmation event data may be acquired in a continuous mode, such as a video recording.

[0079] The method of the present invention may be repeated more than once for the same actual event. This can be important if you are using event data acquisition in a one-time (non-continuous) mode.

[0080] As shown in FIG. 2, a system 100 for generating a real-time digital representation of an actual event is any device or set of devices comprising a processor 103 and a memory 104 and further comprising means 105 for digitally recording the actual event AE. Said means 105 for digital recording of the actual event AE may be, for example, a camera, a microphone, or both. Preferably, but not necessarily, system 100 includes interfaces 106 to allow creator 1 to interact with system 100. These interfaces 106 are important in this case, the only possible interaction with the source event area can be with the ED event data collector, namely with system 100. The transmitted hash code of the THC in this case should represent any action that can be performed by the creator 1 using a remote event data acquisition device (for example, a drone), including, but not limited to, changing the perspective, angle or frame of the received event data to make them user recognizable 4.

[0081] System 100 is also configured to communicate with other systems via communication means 107. The system 100 also includes means 108 for outputting, by means of a physical representation, said HC hash code representation for the sense perception of creator 1. This may be a display 108, headphones 108 or a printer 108, a speaker 108, a loudspeaker 108, a light emitting device such as a diode 108, a vibration motor 108.

[0082] In other words, in order to link the received data of the ED event to the real time of its occurrence, the creator 1 must have the technical means to perform the method according to the present invention. Preferably, if creator 1 is a human, he or she, when performing the method in accordance with the present invention, should use a device/system 100 that receives ED event data and can access a digital witness DW 203. This system/device 100 should contain technical means for performing the steps of the method on the side of the creator. These tools should include a computer program 110, such as a mobile application 110, downloaded or built into the manufacturing process in the specified system 100/device 100.

[0083] As shown in FIG. 4, a system 200 for providing time certification of a digital representation of an actual event to be referenced to the real time of its occurrence according to the present invention comprises at least one processor 201 and at least one storage device 202. a database 203, referred to herein as previously referred to as digital witness DW 203. System 200 may be, for example, a server 200 or a collection of servers 200.

[0084] As used herein, the term "digital witness DW 203" refers to one or more data structures in which data is stored. The digital witness DW 203 acts as a replacement for the human witness in the present invention. The DW 203 digital witness must be immutable (i.e., its data cannot be deleted or modified). The digital witness DW 203 is preferably public, preferably open, and preferably decentralized. An example of a digital witness DW 203 is a distributed ledger.

[0085] The system 200 also includes functions for data operations, such as, for example, writing, storing, retrieving, displaying, and retrieving data, as well as checking the data integrity of the immutable database 203, determining the state of the immutable database 203, and hashing. All of these features are preferably open and publicly available. These functions allow you to perform operations such as:

- data processing (for example, recording, storage, retrieval, display, retrieval, application in calculations, etc.), including all calculated and generated data, as well as external (received and uploaded) data;

- obtaining a timestamp from at least one reliable source 300;

- determination of the state of the digital witness DW 203;

- the use of one or more identical or different HF hash functions to calculate the output to be applied, for example, such as:

- hash code of the National Assembly;

- hash code of SNS confirmation;

- state of digital witness DW 203;

- source or fingerprint of the confirmation (FP);

- generating meaningful input to the SHFID hash function.

- conversion of the NS hash code into its representation, namely, into the transmitted TNS hash code;

- transfer of TNS back to creator 1 or user 4.

[0086] For the greatest possible reliability, each fingerprint should be calculated by the system 200 after the corresponding event data has been transmitted. However, if this is not possible, for example, if the size of the ED event data is large, the corresponding fingerprint can also be calculated outside the system 200, for example, locally by the system 100, in accordance with the method stored in the system 200, for example, using the mobile device 100 containing the corresponding application 110.

[0087] The following information should be stored, preferably in the digital witness DW 203, in such a way that all of the above values can be accurately and unambiguously recalculated and verified:

- complete, detailed information about the methods used to calculate each of the above values (i.e., the NA hash code, the NA confirmation, the state of the immutable database, and the fingerprint(s) and / or significant input data of the SHFID hash function , if applicable, using methods used to generate said fingerprints and/or meaningful inputs to the SHFID hash function;

- full details of the source(s) 300 for each timestamp received;

- full details of the method used to generate the HC hash code representation (also called the transmitted THC hash code).

[0088] To ensure maximum reliability, all information contained in the digital witness DW 203 should be publicly available, including complete and detailed information about all the functions and methods used.

[0089] Any database that is immutable in structure can be a digital witness DW 203. Recently, however, a new technology called "blockchain" or "distributed registries" has emerged. This technology provides at very low cost not only the immutability of stored data, but also their reliability. In the literature, distributed ledger technologies are referred to as "unreliable" because the concept of "trust" known so far in human civilization is no longer needed for undeniable record reliability.

[0090] In order to provide a non-trustworthy, undeniable link between the initial event SE and its real time of occurrence, the digital witness DW 203 stores a record that contains at least the following data related to the initial event SE and the confirmation event CE: initial data S-D, which is a representation of the source event data S-ED, a timestamp of the original data S-D, a representation of the HC hash code (if it is not equal to the HC hash code), confirmation data C-D, a timestamp of confirmation data C-D.

[0091] The temporary certification system 200 also includes a communication means 209 for communicating with the system 100 as well as a reliable clock source 300.

[0092] To perform all the actions required by the present invention, the system 200 is provided with at least an application 210, namely a digital representation temporary certification software module 210 containing executable commands. However, one of ordinary skill in the art will recognize that various functions may be implemented as software in various hardware portions of system 200 (said software being, for example, firmware).

[0093] Next, with reference to FIG. 5, the temporary certification method will be described. Said method of providing temporary certification of a digital representation of an actual event, tied to the real time occurrence of said actual event, is used by a remote system 200 (depicted in Fig. 4) to process and store data received from the system 100 of creator 1. Said method is performed simultaneously with the method described with reference to FIG. 3. Execution of the method begins at step 20 of receiving raw data S-D from system 100 (as previously described).

[0094] As previously mentioned in step 20 of receiving S-D source data, system 200 may receive another type of data for this purpose, namely full S-ED source event data or a S-ED source event data fingerprint. To ensure the highest level of reliability of the event data, if a fingerprint is used, it is necessary to calculate and write the meaningful input of the fingerprint's SHFID hash function to the digital witness DW 203. must be written to the digital witness DW 203. The SHFID is particularly important if the complete event data used to calculate the fingerprint is stored outside the digital witness DW 203, for example locally.

[0095] Once the original data S-D is received by the system 200 containing the digital witness DW 203, the execution of the method proceeds to step 21 of storing said original data S-D in the digital witness DW 203.

[0096] Then, the execution of the method proceeds to step 22 of obtaining from a reliable source 300 a timestamp for the original data S-D. The system 200 acquires the timestamp of the raw data S-D via the communication means at the time the raw data S-D is received or immediately after it is written to the digital witness 203. More than one clock source can be used for the timestamp. Information about this source(s) is stored in the digital witness DW 203. The process of creating a timestamp of the raw data S-D refers to obtaining the timestamp of the raw data S-D from a trusted source and recording this timestamp in the digital witness DW 203.

[0097] Then, the execution of the method proceeds to step 23 of determining data describing the state of the immutable database 203 (digital witness DW 203) at a specific time indicated by the timestamp of the original data S-D. As used herein, the term "state of the immutable database 203" means any data that provides mathematical or logical proof that some other data existed in the digital witness DW 203 at a particular point in time. The specified state of the immutable database is calculated for the data existing in the digital witness DW 203 at the moment when the original data S-D is received from the system 100 of the creator 1 (before either the original data S-D or the timestamp of the original data S-D is written to the digital witness DW 203, whichever occurs first). Said data describing the state of the immutable database (digital witness DW 203) may be, for example, a fingerprint of the entire data or part of the data stored in the digital witness DW 203. Data describing the state of the preferably immutable database 203 (digital witness DW 203) , are computed by system 200 in accordance with the method stored in system 200 to enable them to be quickly and easily recalculated if necessary.

[0098] Then, the execution of the method proceeds to step 24 of calculating the hash code HC based on the data describing the state of the immutable database 203, the original data S-D, and the timestamp of the original data S-D. In this document, the term "HF hash function" means any publicly available (open) mathematical function that maps data of a certain arbitrary size into a fixed size bit string (hash). Due to its mathematical properties, the output of an HF hash function can be viewed in two ways: as a fingerprint or as a checksum. For the present invention, the cryptographic hash type HF is preferred. The cryptographic hash function HF is characterized in that it can withstand any type of known cryptanalytic attacks: it has at least the property of preimage resistance, second preimage resistance, and collision resistance. A hash function HF that is proven to be vulnerable (i.e., one that is susceptible to attack) should not be used unless that vulnerability can be ruled out, at best, through the structure of the system 200 and/or the structure of the digital witness DW 203. For example , the output of the cryptographic hash function HF, which directly applies the full output of the Merkle-Damgard construction, is vulnerable to a message length attack, so to minimize the risk associated with this type of attack, the digital witness DW 203 must store information about the size of the hash input. HF function (for example, as meaningful input to the SHFID hash function).

[0099] The system 200 may offer one or more of the same or different hash functions HF to calculate the fingerprint of the original data S-D, the confirmation data CD, to calculate the hash code HC, the state of the immutable database 203 (digital witness DW 203), and if applicable, the transmitted THC hash code.

[0100] System 200 may provide for the use of user-defined HF hash functions, however, the reliability of user-defined HF hash functions may be questionable, and therefore these HF hash functions are not recommended. For maximum reliability, each user-defined hash function HF that is used must be stored in the digital witness DW 203, including its complete algorithm.

[0101] The next step is step 25 of registering the HC hash code (calculated in step 24) in the digital witness DW 203. This step is optional, but it speeds up the computations in the verification process.

[0102] The method then proceeds to step 27 of sending the HC hash code representation to the system 100. As previously mentioned, the HC hash code representation is hereinafter referred to as the transmitted THC hash code. However, it should be noted that the transmitted THC hash code may also be a complete HHC hash code. 200, they must be stored in the digital witness 203 in such a way as to ensure that the HC hash code is reliably converted to the transmitted THC hash code. - for other factors. Therefore, the step of sending the HC hash code representation may be preceded by a step 26 of converting the HC hash code to its representation, namely the transmitted THC hash code.

[0103] These conversion methods include, but are not limited to: shortening the HC hash code using a reduction function, converting the HC hash code into some set of actions or gestures that must be performed (repeated) by the creator 1 (for example, speaking out loud the transmitted hash code of the THC, performing hand gestures, redisplaying the shape, moving/zooming the camera in a certain way to change the frame or angle of the received event data).

[0104] Each method that converts the hash code HC into its representation, namely the transmitted hash code THC, is sufficient as long as the user 4 can recognize it in the event displayed in the confirmation event data C-ED, without any doubt. It should be noted again that the transmitted hash code of the THC can also be the complete hash code of the HC.

[0105] The next step is step 28 of receiving acknowledgment data C-D of the CE acknowledgment event, wherein the acknowledgment event CE is the original event SE, further included in its area, the representation of the hash code HC, while the acknowledgment data C-D is the representation acknowledgment event data C-ED.

[0106] Then, the execution of the method proceeds to step 29 of registering said confirmation data C-D, which is a representation of confirmation event data C-ED, in the digital witness DW 203. All provisions regarding fingerprints and significant input data of the SHFID hash function apply herein. described earlier.

[0107] The next step is the step 30 of obtaining from a reliable source 300 timestamp clocks for confirmation data C-D and registering them in an immutable database 203 data.

[0108] The system 200 acquires the timestamp of confirmation data C-D by means of communication at the time of receipt of confirmation data C-D or immediately after it is registered in the digital witness 203. More than one clock source can be used for the timestamp. Information about this source(s) is preferably stored in the digital witness DW 203. The process of creating a C-D confirmation data timestamp refers to obtaining a C-D confirmation data timestamp from a trusted source and recording this timestamp in the DW 203 digital witness. .

[0109] Then, the execution of the method optionally proceeds to step 31 of calculating the hash code of the SNA confirmation using the hash function HF, which has at its input at least: confirmation data C-D, a timestamp of confirmation data C-D, and a hash - HC code. The HC confirmation hash code is registered in the digital witness DW 203. The HC verification hash code can be used to provide a quick and easy data integrity check when offline proof of the occurrence of an actual event is extracted from the digital witness 203, for example, for use during tests.

[0110] Optionally, the method of providing temporary certification performed by the system 200 includes the step 32 of preparing and sending proof of the occurrence of a POEO event. This is user-friendly information related to the actual event recorded and should preferably contain: the time of occurrence of the actual initiating event SE, the time of occurrence of the confirmation event CE, the HC hash code, the transmitted THC hash code (if applicable), the name of the digital witness DW 203 and the position of the entry in the digital witness DW 203.

[0111] Next, a method for providing data for checking a digital representation of an actual event linked to the real time of its occurrence, as well as a method for checking the digital representation of the actual event linked to the real time of its occurrence, will be described. In practice, these methods are also performed in at least two remotely located systems, namely the system 200 containing the digital witness DW 203 and the system 400 of the end user 4, respectively.

[0112] The actions performed by the system 200 during the execution of the verification method will be described with reference to FIG. 6, while the actions performed by the system 400 of the user 4 will be described with reference to FIG. 7. These actions are performed by the verification process software module 220 built into the system 200 and known tools or a dedicated software module built into the system 400.

[0113] As used herein, the term "user 4" means one or more people or one or more organizations, including artificial intelligence or similar algorithm(s), which(s) is(s) performed(s) with the ability and /or has(-s) technical means to check the relationship between the actual event AE and its real-time timestamp, created by the creator 1 using the system 100 and stored in the digital witness DW 203.

[0114] As mentioned earlier, the present invention applies event data representing the same actual event before and after including the transmitted THC hash code in the original SE event area. If the event displayed in the event data contains an appropriate amount of detail, the user 4 can determine whether the different event data (such as the original event data S-ED and the acknowledgment event data C-ED) represent the same actual event.

[0115] As a rule, this verification process requires complete data stored in the process of generating a digital representation of the actual event, tied to the real time of its occurrence. This complete data will hereinafter be referred to as VD verification data. The VD verification data is data stored in the digital witness 203 as well as data stored elsewhere than in the digital witness 203, including:

- S-ED source event data with its fingerprint and/or significant SHFID hash input data, if applicable;

- C-ED confirmation event data with its fingerprint and/or significant SHFID hash input data, if applicable;

- the timestamp of the source data S-D, which is a representation of the data of the source event S-ED;

- the state of the immutable database at the time specified in the timestamp of the source data S-D;

- confirmation data timestamp C-D, which is a representation of the confirmation event data C-ED;

- hash code of the NS and its representation (which is the transmitted hash code of the TNS);

- SNA confirmation hash code, if applicable;

- evidence of the occurrence of the POEO event, if applicable;

- methods used for:

- generating initial data S-D (which is a representation of the data of the initial event S-ED);

- generating acknowledgment data C-D (which is a representation of acknowledgment event data C-ED);

- generating fingerprints, if applicable;

- generating meaningful input data to the SHFID hash function, if applicable;

- generating a hash code and presenting the hash code (which is the transmitted THC hash code);

- generating a hash code of the SNA confirmation, if applicable;

- generating evidence of the occurrence of the POEO event, if applicable.

[0116] The verification process is carried out in several steps, however, their main purpose is to confirm the consistency of the VD verification data, and then extract the initial S-ED event data and the C-ED confirmation event data for verification performed by replacing human sense functions or through human senses.

[0117] The VD verification data consistency check consists of rebuilding and recomputing all values according to the stored information to prove mathematically that:

- the digital witness DW 203 at the time of receiving the timestamp for the original data S-D was in a certain specific state;

- initial data S-D is a representation of the data of the initial event S-ED;

- acknowledgment data C-D are event acknowledgment data

C-ED;

- the transmitted THC hash code is a representation of the HC hash code;

- the HC hash code stored in the digital witness 203 can be recalculated in accordance with the method described in the present invention;

Optionally, the SNA confirmation hash code stored in the digital witness 203 can be recalculated in accordance with the method described in the present invention.

If any of the steps above were not successful, the verification process has failed and cannot be continued.

[0118] For the verification process, the recalculation of the state of the digital witness DW 203 is always performed for the specific state of the digital witness DW 203 at the time indicated by the timestamp attached to the original data S-D.

[0119] In general, the data consistency check process is optional for the method and may be performed by system 200 and/or system 400.

[0120] In practice, the VD verification data required by the system 400 for consistency verification is retrieved in the steps of the method for providing verification data of a digital representation related to the real time of its occurrence held on the side of the system 200. Namely, the system 200 receives a request for verification data VD, i.e. about data relating to the actual event of interest, linked to the real time of its occurrence and generated in accordance with the present invention. The system 200 then checks whether data relating to the specified actual event of interest exists in the immutable database 203 that is being queried. Finally, the system 200 sends the requested data regarding the specified actual event of interest. At the same time, but not necessarily, the system 200 itself may check the consistency of the VD check data. As mentioned earlier, validating the consistency of the data stored in the DW 203 digital witness (despite its immutability) is only a desirable step in the validation process.

[0121] Once data consistency is confirmed, evidence is determined that the event mapped to the S-ED source event data can be tied to the S-D source data timestamp (which is a representation of the S-ED source event data) by a combination of:

- sensing or automated, without human intervention, comparing the actual event displayed in the S-ED initiating event data with the actual event displayed in the C-ED acknowledgment event data; And

- checking whether the transmitted THC hash code included in the initial event area SE recognized in the confirmation event data C-ED matches the transmitted THC hash code stored in the digital witness DW 203 in any order.

The verification may also be performed in a fully automated or semi-automated manner by the system 400, respectively, with or without AI algorithms (or similar).

[0122] In one embodiment, on the user side, the following steps of a method for checking a digital representation tied to the real time of its occurrence are performed. First, after the system 200 is requested for VD verification data in query step 50, the VD verification data is retrieved in step 51 from the system 200 containing the immutable database 203, said VD verification data being related to an event of interest generated by the method according to the present by the invention, said data being at least: a hash code representation HC, original data S-D, and confirmation data C-D. Then, optionally after a consistency check in step 52, and optionally after restoring the necessary data in step 53, restoring the original data S-D and confirmation data C-D, the system 400, in step 54, finds a representation of the hash code HC in the context of the actual event recorded as confirmation event data. C-ED with AI or similar algorithm. Finally, system 400 compares the registered source event SE, represented by source data S-D, and the acknowledgment event CE, represented by acknowledgment data C-D, using AI or a similar algorithm.

[0123] "Sense comparison" means that the confirmation is performed by the user 4 using human senses or means equal to human senses (as described with reference to this embodiment). If the user 4 is a human, confirmation can be performed, for example, visually or aurally. The user 4 who performs the verification may be a person who is provided with the system 400, but who, as mentioned earlier, can be completely replaced by said system 400 containing an electronic algorithm, including artificial intelligence, that is capable of performing the steps described herein.

[0124] Sense inspection is also sufficient to compare event data received in different modes, for example, if prior to including the HC hash code representation (namely, the transmitted HC hash code) in the SE region, the event data was received in a one-time mode (for example, as photo) and after switching on - in continuous mode (for example, as a video recording).

[0125] If the event data was received without interruption in a continuous mode (such as, for example, video recording), and the creator 1 kept the continuity of the event displayed in the received event data, there is an additional possibility to determine the exact time of occurrence of all actual events that occurred before and after the exact point in time indicated by the timestamp of the original data S-D and/or the confirmation data C-D. This function can also be used to confirm the transmission of media streams in real time.

[0126] Whilst the possibility of human sensory evaluation is preferable to conducting this evaluation by any electronic means, consider the potential applications of the present invention for the provision of evidence in litigation and take into account current standards of work that recognize the concept of a human witness.

[0127] As mentioned earlier, the verification process is performed in the user's system 400, which must be aware of the digital witness DW 203 (immutable database 203) that stores information about the event of interest. Since several embodiments may differ depending on what data was generated in order to link the actual event to its real time of occurrence, and depending on where said data was stored, there are also several corresponding embodiments of the verification process.

[0128] In an exemplary embodiment, if originator 1's system 100 applied S-D source data that was not equal to S-ED source event data, user 4's system 400 should have S-ED source event data. If creator 1 applied confirmation event data C-D that was not equal to confirmation event data C-ED, the system 400 of user 4 must have confirmation event data C-ED.

[0129] If the system 400 of the user 4 has only one file (i.e., when the receipt of the event data was continuous and the source event data S-ED is part of the acknowledgment event data C-ED), the system 400 should extract the source event data S-ED from the C-ED acknowledgment event data depending on the data size of the original S-ED event. If in this case there is no information about the size of the original S-ED event data, the user 4 system 400 could theoretically use a time-consuming "brute-force" method to determine the size of the original S-ED event data and to extract it from the C-ED acknowledge event data.

[0130] To simplify the verification process, the creator 1, using its system 100, can provide the user 4 with proof of the occurrence of a POEO event, for example, by communicating with the system 400, and said proof of the occurrence of the event contains the corresponding data in the verification process.

[0131] Referring to FIG. 6 and FIG. 7, it can be seen that in step 40 of receiving a request for data relating to an event of interest, the system 400 of user 4 queries the digital witness DW 203 for data relating to an event of interest and, of course, generated in accordance with the method for generating a digital representation of an actual event associated with to its real time of occurrence, according to the present invention:

- if the complete data of the initial event S-ED and the complete data of the confirmation event C-ED were stored in the digital witness DW 203, the time when the event of interest occurred, known to the creator 1 and/or the user, is sufficient to query for data relating to the event of interest ;

- in other cases (for example, if the time of occurrence of the event is not exactly known), the request should be based on any data associated with the event of interest, for example, the original S-D data, the C-D confirmation data, or the transmitted THC hash code.

[0132] At step 41 of checking the presence of the requested data, the presence of the requested data in the database is checked. If the requested data is found in the digital witness DW 203, the VD verification data is retrieved.

[0133] In step 42 checking the consistency of the requested data and optionally simultaneously the local consistency of the requested data, the HC hash code and the CHC confirmation hash code are recalculated (e.g., by the system 200 and/or locally by the user system 400) to check the consistency of the data. If any of the recalculated values do not match the corresponding value stored in the digital witness DW 203, the verification process has failed.

[0134] If either the source data S-D is not equal to the source event data S-ED and/or the acknowledgment data CD is not equal to the data of the acknowledgment event C-ED, confirmation must be obtained that both kinds of the above data are a representation of the source event data S-ED or acknowledgment event data C-ED, respectively.

a) If the original data S-D is not equal to the original event data S-ED and the corresponding original event data S-ED is stored in the digital witness DW 203, the original data S-D is recalculated (by the system 200 and/or locally by the user system 400) according to the information retrieved from system 200.

b) If the source data S-D is not equal to the source event data S-ED and the corresponding source event data S-ED is stored outside the digital witness DW 203, the user 4 system 400 must:

i) locally recompute, based on the source event data S-ED, the source data S-D according to the extracted information about the source data S-D;

ii) transmit the S-ED to the system 200 to enable the system 200 to perform said recalculation according to the extracted information about the original S-D data.

c) If the recomputed raw data S-D from the raw event data S-ED does not match the corresponding raw data S-D stored in the digital witness DW 203, the verification process has failed.

d) If acknowledgment data C-D is not equal to acknowledgment event data C-ED, the process is the same as when the original data S-D is not equal to the original event data S-ED.

[0135] After the data consistency is confirmed, the initial event data S-ED and the confirmation event data C-ED must be presented depending on their type, for example, displayed or reproduced, to ensure that they are sensed by the user 4. Due to the sense perception, the user 4 carries out sensory inspection and checks:

- whether the event mapped in the acknowledgment event data C-ED, which contains the transmitted THC hash code included, corresponds to the event mapped in the source event data S-ED,

- whether the transmitted THC hash code included in the area of the initial event SE (transmitted HCH code recognized in the physical context of the CE confirmation event) matches the transmitted THC hash code that was extracted from the digital witness DW 203.

[0136] The verification process is successfully completed if, according to the user's sensory inspection, the source event data S-ED and the confirmation event data C-ED display the same actual event AE, and if the transmitted hash code THC included in the area of the original event SE , matches the transmitted THC hash stored in the digital witness DW 203.

[0137] If the verification process succeeds, the association between the initiating event SE displayed in the initiating event data S-ED and the occurrence time of the initiating event SE is confirmed, with the time contained in the timestamp of the original data S-D.

[0138] The sense check of the event displayed in the S-ED and C-ED is performed by the system 400 of the user 4 due to his or her sense perception, but not necessarily. In another embodiment, a fully automated system 400 with AI algorithms (or similar) may be used. As previously mentioned, in the case of event data ED received in continuous mode, if the continuity of the recorded scene has been maintained, there is an additional possibility of determining the exact time of all events occurring before and after the inclusion of the transmitted THC hash code in the area of the original event SE.

[0139] To perform a method for checking the digital representation of the actual event, tied to the real time of its occurrence, requires the system 400 of the user 4 (as mentioned earlier). A system 400 (not shown) for verifying a digital representation of an actual event, linked to the real time of its occurrence, includes means configured to connect to a system 200 containing a digital witness DW 203 and retrieve VD verification data.

[0140] If only one file is retrieved (C-ED contains S-ED), user 4 system 400 should be able to extract S-ED source event data from C-ED acknowledgment event data depending on the size of S-ED source event data, which are stored in the digital witness DW 203 or elsewhere. If there is no information about the size of the source event data, the user 4 system 400 could theoretically use a time-consuming "brute-force" method to determine the size of the source event data S-ED and extract it from the acknowledgment event data C-ED.

[0141] If the original data S-D is not equal to the original event data S-ED and the corresponding original event data S-ED is stored elsewhere than in the digital witness DW 203, the user 4 system 400 should be configured to locally recalculate at based on the original event data S-ED of the original data S-D, according to the information contained in the verification data VD, or the transmission of the original event data S-ED to the system 200 to allow the system 200 to perform said recalculation of the original data S-D according to the information, contained in the VD verification data.

[0142] If the acknowledgment data C-D is not equal to the acknowledgment event data C-ED and the corresponding acknowledgment event data C-ED is stored elsewhere than in the digital witness DW 203, the process is carried out in the same manner as in the case of the original S-D data as described above.

[0143] Once the data retrieved from the system 200 is consistent, the next step of the verification process can be performed, said step being a sensory verification.

[0144] Using sense perception, the user 4 can sense compare the event displayed in the event data ED received before and after the inclusion of the transmitted THC hash code in the area of the original event SE. The same can be done automatically if the artificial intelligence algorithms are implemented in the system 400 on the user side. If the source event data S-ED and the acknowledgment event data C-ED represent the same actual event AE, and the transmitted hash code THC recognized in the acknowledgment event data C-ED matches that stored in the immutable database 203 (digital witness DW 203), there is confidence that the actual event AE displayed in the initiating event data S-ED occurred at the time indicated by the timestamp of the initiating event data S-D, which is a representation of the initiating event data S-ED.

[0145] The system 400 (not shown) of the user 4 should enable the user 4 to apply sensory perception (e.g., vision or hearing: to sensory (e.g., visual, auditory) comparison of the event displayed in the source event data S-ED with the event mapped in the C-ED acknowledgment event to determine their similarity, and further, in the case of ED event data received in continuous mode, their continuity, to check whether the transmitted THC hash code recognized in the event mapped in the data confirmation event C-ED (i.e., the transmitted hash of the THC included in the field of the original event SE) to the transmitted hash of the THC extracted from the digital witness DW 203; if the user 4 is a human, this process can be performed by the sense way (for example, visually or aurally).

[0146] If the user 4 is a human, the actions mentioned above, especially all interactions with the system 200 containing the digital witness DW 203, and all calculations/recalculations can be performed using a computer program, such as a mobile application 410 (not shown) .

[0147] The following will be a few examples of the use of methods and systems according to the present invention.

[0148] Example 1 - Single Mode Digital Logging Without Event Data Thumb Calculation event data. System 200 includes a digital witness DW 203. In this embodiment, the method includes the following steps:

(1) The person acting as creator 1 wants to confirm the actual time of occurrence of the actual event and chooses to use a public (open) system 200 that uses only one public (open) HF hash function, SHA-2, for all hashing purposes. The data describing the state of the digital witness DW 203 is a fingerprint of all data stored in the digital witness DW 203 until the initial data S-D is received. The system 200 uses the Internet service "actual time" available at the Internet address "http://time.is", which is trusted by a person, as a source 300 of clock signals for all purposes. The transmitted THC hash code generated by the system 200 is equal to the HC hash code.

(2) The person acquires the original event data S-ED of the initial event SE in the form of a photograph using the smartphone 100 .

(3) The initial data S-D, which is the initial event data S-ED, is sent to the system 200 by the application 110.

(4) The system 200 calculates the data describing its state using the SHA-2 hash function, writes the original data S-D to the digital witness DW 203, and immediately thereafter obtains and writes to the digital witness DW 203 the timestamp for the original data S-D.

(5) The system 200 uses the SHA-2 hash function to calculate the HC hash code using the following components: (1) data describing the state of the digital witness DW 203, (2) source data S-D, and (3) timestamp of source data S-D .

(6) The system 200 writes the HC hash code to the digital witness DW 203. The transmitted HC hash code, which is equal to the HC hash code, is transmitted back by the system 200 to the person's smartphone 100 and displayed on the screen of the smartphone 100.

(7) A person includes the transmitted THC hash code in the source event area SE by writing the transmitted THC hash code on a piece of paper, and then placing the piece of paper in the context of the original event to create a CE confirmation event.

(8) The person receives the C-ED confirmation event data of the CE confirmation event as a photo using the smartphone 100. This photo should be as similar as possible to the photo of the original SE event, and the sheet of paper containing the transmitted THC hash code should be recognizable, visible and readable within this photo.

(9) The acknowledgment data C-D, which is the acknowledgment event data C-ED, is sent to the system 200 by the application 110.

(10) The system 200 writes the acknowledgment data C-D to the digital witness DW 203, and immediately acquires and writes to the digital witness DW 203 the timestamp for the acknowledgment event data C-ED.

(11) System 200 uses the SHA-2 hash function to compute the hash code of the SNA acknowledgment using the following components: (1) acknowledgment data C-D, (2) timestamp of acknowledgment data C-D, and (3) hash code HC.

(12) System 200 writes the SNA Confirmation Hash Code to the digital witness DW 203.

(13) Proof of the occurrence of the POEO event, containing the timestamp of the data of the original event S-ED, the hash code HC, the timestamp of the data of the confirmation event C-ED, the hash code of the SNS confirmation, information on the applied hash functions HF (SHA-2) and the name of the digital witness DW 203 with the address of the record relating to the stored data is transmitted by the system 200 back to the person's smartphone application 110, displayed on the screen of the smartphone 100, and stored locally by the application 110.

[0149] The procedure for linking a real-time timestamp to the original event SE is completed.

[0150] Next, a corresponding example of the verification process for the first case with a digital representation in a single example will be described.

(1) The person acting as user 4 wants to check when an event occurred. It has received from the creator 1 a POEO event occurrence proof, which contains information about the exact time of the event occurrence (which is the timestamp of the data of the original S-ED event) and access information to the digital witness DW 203 (the web address of the system interface 200), in which information about the event of interest is stored. The system 200 containing the digital witness DW 203 uses a web interface for communication. The person acting as user 4 uses the system 400.

(2) The smartphone 400 connects the person to the web page of the system 200 and requests an event that occurred at the time indicated by the timestamp contained in the POEO event proof.

(3) If the request is found, the data describing the state of the digital witness DW 203, the HC hash code, and the SNA confirmation hash code are recomputed using the HF SHA-2 hash function by the system 200 to check the consistency of the data. If the consistency is maintained, the transmitted THC hash code, original data S-D, confirmation data C-D, and timestamp of original data S-D are displayed on the web page (Note: original data S-D and confirmation data C-D are photographs).

(4) A person should visually compare the event displayed in the original data S-D with the event displayed in the confirmation data C-D. If the person decides that the original data S-D and the confirmation data C-D represent the same actual event, the check continues.

(5) A person must check whether the transmitted THC hash code visible in the confirmation data area C-D matches the transmitted THC hash code displayed on the web page. If both transmitted THC hash codes match, the occurrence time of the event mapped in the original S-D data is contained in the timestamp of the original S-D data, and the verification succeeds.

[0151] Example 2 - Single mode digital registration with event data fingerprint calculation

[0152] In another of the possible embodiments of the present invention, the method of linking the digital representation of the actual event AE to the real time of its occurrence concerns an event registered in a one-time mode, and includes sending to the system 200 only the fingerprints of the complete event data (whereas the complete event data are stored locally by the creator 1). System 200 includes a digital witness DW 203. In this embodiment, the method includes the following steps:

(1) The person acting as creator 1 wants to confirm the actual time of occurrence of the actual event and chooses to use the public (open) system 200, which by default uses only one public (open) HF SHA-2 hash function for all hashing purposes, including fingerprint calculation. The data describing the state of the digital witness DW 203 is a fingerprint of all data stored in the digital witness DW 203 until the initial data S-D is received. The system 200 uses the Internet service "actual time" available at the Internet address "http://time.is", which is trusted by a person, as a source 300 of clock signals for all purposes. The transmitted hash code THC generated by system 200 is equal to the hash code HC. System 200 provides various HF hash functions for computing fingerprints. The person selects a non-standard HF SHA-3 hash function to compute the S-ED source event data footprint and the C-ED confirmation event data footprint. The person selects in the system 200 an option to store additional information, namely, the significant input of the SHFID hash function along with each calculated fingerprint, and the value of the indicated significant input of the SHFID hash function is equal to the size of the input of the HF hash function that calculates each fingerprint. A dedicated application 110 installed on the person's smartphone 100 communicates with the system 200 (containing the digital witness DW 203) and has an embedded HF SHA-3 hash function to perform local calculations.

(2) The person acquires the original event data S-ED of the initial event SE in the form of a photograph using the smartphone 100 . The initial event data S-ED is stored locally by the application 100.

(3) The original data S-D is equal to the fingerprint of the original event data S-ED, which is calculated locally on the smartphone 100 using the SHA-3 function built into the smartphone application 110. The meaningful input to the SHFID hash function is set to the data size of the original event S-ED. Information about the HF hash function used to calculate the specified fingerprint (with reference to the SHA-3 method), as well as information about the method used to generate meaningful input data of the SHFID hash function, are sent to the system 200 by the application 110, and stored by the system 200 in the digital witness DW 203.

(4) The original data S-D and the significant hash input data SHFID are sent to the system 200 by the application 110 of the smartphone 100.

(5) The system 200 writes the original S-D data and the meaningful hash input SHFID to the digital witness DW 203, and immediately thereafter acquires and writes to the digital witness DW 203 the timestamp for the original S-D data.

(6) The containing system 200 applies the HF SHA-2 hash function to calculate its state and the same function to calculate the HC hash code with the following components: (1) data describing the state of the digital witness DW 203, (2) the original S-D data; and (3) the timestamp of the original S-D data.

(7) The system 200 writes the HC hash code to the digital witness DW 203. The transmitted HC hash code, which is equal to the HC hash code, is transmitted back to the person's smartphone 100 and displayed on its screen.

(8) The person includes the transmitted THC hash in the SE source event area by writing the transmitted THC hash on a piece of paper and then placing it in the context of the SE source event to create a CE confirmation event.

(9) A person using the smartphone 100 acquires the CE confirmation event C-ED confirmation event data as a photograph. This photo should be as similar as possible to the original photo, and the sheet of paper containing the transmitted THC hash code should be recognizable, visible and readable within this photo. The C-ED acknowledgment event data is stored locally by the application 110.

(10) The confirmation data C-D is equal to the fingerprint of the confirmation event data C-ED, which is calculated locally on the smartphone 100 using the SHA-3 function built into the smartphone application 110. The meaningful input of the SHFID hash function is set to the data size of the confirmation event C-ED. Information about the HF hash function used to calculate the specified fingerprint (with reference to the SHA-3 method), as well as information about the method used to generate meaningful input data of the SHFID hash function, are sent to the system 200 by the application 110, and are additionally stored by the system 200 in digital witness DW 203.

(11) Confirmation data C-D and meaningful hash input data SHFID are sent to system 200 by application 110.

(12) The system 200 writes the confirmation data C-D and its SHFID to the digital witness DW 203 and immediately thereafter obtains and writes to the digital witness DW 203 the timestamp for the confirmation data C-D.

(13) System 200 uses the HF SHA-2 hash function to calculate the hash code of the SNA confirmation using the following components: (1) confirmation data C-D, (2) timestamp of the confirmation data C-D, and (3) hash code HC .

(14) The system 200 writes the SNA confirmation hash code into the digital witness DW 203. Proof of the occurrence of the POEO event, containing: the original data S-D with its significant SHFID hash inputs (note: the original S-D data is a fingerprint), the timestamp of the original S-D confirmation data, HC hash code, confirmation data C-D with their meaningful hash input data SHFID (note: confirmation data C-D is a fingerprint), timestamp of confirmation data C-D, confirmation hash code SNA, information about applied hash functions (namely, SHA-3 for both fingerprints and SHA-2 for the hash code of the HC, the hash code of the confirmation of the CHC and data describing the state of the digital witness DW 203), as well as the name of the digital witness DW 203 with the address of the record relating to the stored data is transmitted back to the person's smartphone application 110, displayed on the screen of the smartphone 100, and stored locally by the application software.

[0153] The procedure for linking a real-time timestamp to the original event is completed.

[0154] Next, a corresponding example of the verification process for the second case with digital representation in a single mode will be described.

(1) The person acting as the user, using the system 400, wants to check when an event has occurred. It received from the creator 1 the source event data S-ED, the confirmation event data C-ED, the proof of the occurrence of the event POEO, which contains information about the hash function HF used to calculate the initial data S-D and the confirmation data CD, which are fingerprints calculated from using the HF SHA-3 hash function, and information on how to access the digital witness DW 203, which stores information about the event. System 200 (comprising digital witness DW 203) uses a web interface for communication. The system 200 contains all information about the calculation of the original data S-D and confirmation data C-D, including the hash functions HF that the creator used. (It should be noted that the creator of 1 is not required to remember the exact time of the event). User 4 will use system 200 to perform any recalculations required in the verification process. The person acting as user 4 uses the system 400.

(2) A person should visually compare the event displayed in the S-ED initiating event data with the event displayed in the C-ED acknowledgment event data. If, according to this comparison, they represent the same actual event, the test continues.

(3) A person goes to the specified web page which is the interface of the system 200, uploads the S-ED source event data and the C-ED confirmation event data to the digital witness DW 203 with the smart phone 400 so that he can recalculate their fingerprints with their SHFID.

(4) The system 200 extracts information about the method used to compute the fingerprints, which in this example is the HF SHA-3 hash function, and extracts information about generating meaningful SHFID hash inputs, which in this example are generated by assigning them the size of the input data of each HF hash function used to compute the fingerprint.

(5) System 200 sets the significant input data of the hash function SHFID of the original data S-D to the length of the loaded data of the original event S-ED.

(6) The system 200 sets the significant input data of the hash function SHFID of the acknowledgment data C-D to the length of the loaded acknowledgment event data C-ED.

(7) Using the downloaded source event data S-ED and acknowledgment event data C-ED, the system 200 recalculates, using the HF SHA-3 hash function, the original data S-D and the acknowledgment data C-D, respectively (Note: original data S-D and acknowledgment data C-D are fingerprints of the complete corresponding event data).

(8) The system 200 searches the digital witness DW 203 for the recomputed original data S-D, the confirmation data C-D, and their corresponding meaningful hash input data SHFID. If the data is found (meaning that it is equal to the data already stored in the digital witness DW 203), the check continues.

(9) For the purpose of checking data consistency, the SHA-2 function is used by the system 200 to recalculate the data describing the state of the digital witness DW 203, the HC hash code, and the CHC confirmation hash code. If these data are consistent, the transmitted THC hash code and time the raw data mark S-D is retrieved from the digital witness DW 203 and displayed to user 4 on smartphone 400.

(10) If the transmitted THC hash code extracted by the system 200 from the digital witness DW 203 matches the transmitted THC hash code included in the SE area mapped in the confirmation event data C-ED, the user 4 can be sure that the original event , mapped in the source event data S-ED, occurred at the time indicated by the timestamp of the source data S-D. Verification is successful.

[0155] Example 3 - digital representation in continuous mode without computing the event data footprint

[0156] In another exemplary embodiment of the present invention, a method for linking a digital representation of an actual event to a real-time occurrence of the event relates to an event recorded on a continuous basis and includes sending complete event data to the system 200. System 200 includes a digital witness DW 203. In this embodiment, the method includes the following steps:

(1) The person acting as creator 1 wants to confirm the actual time of occurrence of the actual event and chooses to use a public (open) system 200 that uses only one public (open) hash function HF - SHA-2 for all hashing purposes. The data describing the state of the digital witness DW 203 is a fingerprint of all data stored in the digital witness DW 203 until the initial data S-D is received. The system 200 uses the Internet service "actual time" available at the Internet address "http://time.is", which is trusted by a person, as a source 300 of clock signals for all purposes. The HC hash code representation, namely the transmitted HTC hash code generated by system 200, is a fingerprint of the HC hash code obtained in accordance with the method described in RFC4226 (developed by the Internet Engineering Working Group). A dedicated application installed on the person's smartphone 100 communicates with the system 200. The application 110 operates in such a way that the event data received during the first five seconds of continuous event data acquisition is considered the initial event data S-ED. This S-ED initiating event data recording time in system 200 after five seconds of continuous recording is a general rule of system 200.

(2) The person starts recording video on the smartphone 100. After five seconds, the already received event data is considered as the initial event data S-ED. Reception of event data is not interrupted.

(3) Initial data S-D, which is the initial event data S-ED, is sent to the system 200 by the smartphone application 110.

(4) The system 200 calculates data describing the state of the digital witness DW 203 (using the HF SHA-2 hash function).

(5) The system 200 receives and writes to the digital witness DW 203 the timestamp of the original data S-D.

(6) Using the same HF hash function, the system 200 computes the HC hash code using the following components: (1) the previously computed data describing the state of the digital witness DW 203, (2) the original data S-D, and (3) the timestamp of the original S-D data.

(7) The system writes the HC hash code to the digital witness DW 203. The transmitted HC hash code, which is generated based on the method according to RFC4226, is transmitted back to the person's smart phone 100 and displayed on its screen.

(8) The person, without interrupting the receipt of the event data, includes the transmitted hash code of the THC in the area of the documented event by handwriting and reading the transmitted hash code aloud; the entire process of manually entering and aloud reading the transmitted THC hash code is recorded in the received event data.

(9) Once the person completes receiving the event data, all the recorded data creates the confirmation event data C-ED.

(10) The acknowledgment data C-D is the acknowledgment event data C-ED. The C-ED confirmation event data is sent to the system 200 by the smartphone application 110.

(11) The system 200 writes the confirmation data C-D to the digital witness DW 203, and immediately acquires and writes to the digital witness DW 203 the timestamp for the confirmation data C-D.

(12) The system 200 uses the HF SHA-2 hash function to calculate the hash code of the SNA confirmation using the following components: (1) confirmation data C-D, (2) timestamp of the confirmation data C-D, and (3) hash code HC .

(13) The system 200 writes the SNS acknowledgment hash to the digital witness DW 203. POEO event proof containing the timestamp of the original data S-D and acknowledgment data CD, S-TS, hash HC, C-TS, acknowledgment hash The SNA, the applied hash function information (SHA-2), and the name of the digital witness DW 203 with the address of the record relating to the stored data are transmitted by the system 200 back to the person's smartphone application 110, displayed on the screen of the smartphone 100, and stored locally by the specified application 110.

[0157] The procedure for linking the real time timestamp to the original event is completed.

[0158] Next, a corresponding example of the verification process for the first case with continuous digital representation will be described.

1) The person acting as user 4 wants to check when an event occurred. It received from the creator 1 a proof of occurrence of the event POEO, which contains the exact time of the occurrence of the event (contained in the timestamp of the original data S-D) and information on how to access the digital witness DW 203, which stores information about the event. System 200 (comprising digital witness DW 203) uses a web interface for communication. The person acting as user 4 uses the system 400.

2) A person using the system 400 accesses the web page of the system 200 and requests an event that occurred at the time contained in the timestamp of the original data S-D provided in the POEO event proof.

3) If the requested information is detected by the system 200, the event information, the system 200 recalculates with the SHA-2 hash function: DW 203 digital witness state, HC hash code, and CN confirmation hash code to check data consistency. If this data is matched, the transmitted THC hash code is calculated (using the method according to RFC4226) based on the HCH hash code. In addition, the transmitted THC hash code, the original data S-D, the confirmation data C-D, and the timestamp of the original data S-D are displayed on the website (Note: the C-D confirmation data is a continuous video recording, therefore, the original S-D data, according to the general rule of the system 200, is the first five seconds of the C-D confirmation data).

4) The person must sensory compare the event displayed in the original data S-D with the event displayed in the confirmation data C-D. For this purpose, it is sufficient to view only the confirmation data C-D (according to the general rule of the system 200, the original data S-D is the first five seconds of the confirmation data C-D). If, according to this comparison, they represent the same actual event, the person must compare the transmitted THC hash code transmitted to region S-E with the transmitted THC hash code retrieved from system 200. If both transmitted THC hash codes match, the time of occurrence of the event recorded in the source data S-D is indicated by the timestamp of the source data S-D. The verification process has been completed.

5) As long as record continuity is maintained, the real time of all events contained in the acknowledgment data C-D (including events that occurred before and after the transmitted hash code THC was included in the original event area SE) can be determined.

[0159] Example 4 - digital representation in continuous mode with calculation of the data footprint of the event. In another exemplary embodiment of the present invention, a method for linking a digital representation of an actual event to a real-time occurrence of an event is for an event recorded on a continuous basis, and includes sending only a fingerprint of the complete event data to the system 200. The system 200 includes a digital witness DW 203. The complete event data is stored locally in one file, being the acknowledgment event data C-ED, which contains the original event data S-ED. In this embodiment, the method includes the following steps:

1) The person acting as creator 1 wants to confirm the actual time of occurrence of the actual event and chooses to use the public (open) system 200, which by default uses only one public (open) HF SHA-2 hash function for all hash purposes, including fingerprint calculation. The state of the digital witness DW 203 is an exact fingerprint of all data stored in the digital witness DW 203 until the original data S-D is received. The system 200 uses the Internet service "actual time" available at the Internet address "http://time.is", which is trusted by a person, as a source 300 of clock signals for all purposes. The transmitted hash code THC generated by system 200 is equal to the hash code HC. System 200 provides various HF hash functions for computing fingerprints. The person selects the HF SHA-3 hash function for both fingerprints (for the source event data S-ED and the confirmation event data C-ED). The person chooses in system 200 to store the significant hash input SHFID along with each computed fingerprint, and the value of the significant hash input SHFID is determined as the size of the HF hash input that computes the fingerprint. A dedicated application 110 installed on a person's smartphone 100 communicates with the system 200 and has built-in HF hash functions to perform local calculations. Said application 110 operates such that event data, which is the original event data, is received on demand at the time of continuous event data acquisition.

2) The person starts recording the video of the initiating event using the smartphone 100. If necessary, the user, using the application, creates the initial S-D data on demand. Reception of event data is not interrupted.

3) Initial data S-D is equal to the footprint of the already recorded data of the initial event S-ED. The specified fingerprint is calculated locally on the smartphone 100 using the SHA-3 function built into the application. The meaningful input to the SHFID hash function is set to the data size of the original event S-ED. Information about the HF hash function used to calculate the data fingerprint of the original S-ED event (i.e., the HF SHA-3 hash function) and information about the method used to generate the SHFID are sent to the system 200 by the application 110 and further stored in digital witness DW 203.

4) The raw data S-D and its SHFID are sent to the system 200 by the application 110 of the smartphone 100.

5) The system 200 calculates data describing the state of the digital witness DW 203 using the HF SHA-2 hash function, and writes both the original data S-D and its SHFID to the digital witness DW 203.

6) Immediately thereafter, the system 200 receives and writes to the digital witness 203 the timestamp for the original data S-D.

7) System 200 uses the HF SHA-2 hash function to generate an HC hash code using the following components: (1) data describing the state of the digital witness DW 203, (2) source data S-D, and (3) timestamp of source data S-D .

8) The system 200 writes the HC hash to the digital witness DW 203. The transmitted HHC hash, which is equal to the HC hash, is transmitted back by the system 200 to the person's smartphone 100 and displayed on its screen.

9) The person, without interrupting the receipt of the event data, includes the transmitted TNS hash code in the area of the documented event, writing the transmitted TNS hash code on a sheet of paper and reading it out loud; the entire process of manually inputting and aloud reading the transmitted THC hash code is recorded by the smartphone 100 in the received event data.

10) Once the person completes receiving the event data, all the recorded data creates the confirmation event data C-ED. The confirmation event data C-ED is stored locally in the storage device of the smartphone 100.

11) The confirmation data C-D is a fingerprint of the confirmation event data C-ED, which it calculates locally on the smartphone 100 using the SHA-3 function built into the special application 110. The significant input data of the SHFID hash function is set to the size of the confirmation event data C-ED. Information about the HF hash function used to generate the fingerprint (i.e., the HF SHA-3 hash function) and information about the method used to generate the C-ED confirmation event data fingerprint are sent to the system 200 by the application 110 and further stored in the digital witness DW 203.

12) Confirmation data C-D and its SHFID are sent to system 200 by application 110.

13) The system 200 writes the confirmation data C-D and hxSHFID to the digital witness DW 203 and immediately thereafter acquires and writes to the digital witness DW 203 the timestamp for the confirmation data C-D.

14) System 200 uses the HF SHA-2 hash function to generate the hash code of the SNA acknowledgment using the following components: (1) acknowledgment data C-D (2) timestamp of acknowledgment data C-D, and (3) hash code HC.

15) The SNA confirmation hash code is written by the system 200 to the digital witness DW 203. Proof of the occurrence of the POEO event, containing the original data S-D with its timestamp and the significant input data of the SHFID hash function, the hash code HC, the confirmation data C-D with their timestamp and meaningful input to the SHFID hash function, information about the hash functions used (SHA-3 for initial data S-D and confirmation data C-D (both types of data are fingerprints), as well as SHA-2 for the hash code HC , the hash code of the SNA confirmation and data describing the state of the digital witness DW 203), as well as the name of the digital witness DW 203 with the address of the record related to the stored data, is transmitted back to the human smartphone application software, displayed on the screen of the smartphone 100 and stored locally by the application 110 smartphone.

[0160] The procedure for linking a real-time timestamp to the original event has been completed.

[0161] Next, a corresponding example of the verification process for the second case with continuous digital representation will be described.

1) The person acting as user 4 wants to check when an event occurred. It received from creator 1 the C-ED confirmation event data and the corresponding POEO event proof (generated according to the method described in this example). The user 4 also has access information to the system 200 (containing the digital witness DW 203) which stores information about the event. System 200 uses a web interface for communication. System 200 contains all HF hash functions that have been used by the creator. (It should be noted that the creator of 1 is not required to remember the exact time of the event). The person acting as user 4 uses the system 400.

2) The original event data S-ED is extracted by the smartphone 400 from the confirmation event data C-ED according to its size information stored in the significant input of the SHFID hash function of the original data S-D. The footprint of the original data S-D is locally recalculated based on the S-ED, and the acknowledgment data C-D is locally recalculated based on the acknowledgment event data C-ED. These local recalculations are performed by a dedicated smartphone application 400 which is configured to calculate hashes based on SHA-3.

3) The system 200 searches the digital witness DW 203 for the recalculated original data S-D and confirmation data C-D with their meaningful hash input data SHFID. If the requested data is found (ie, the recalculated data matches those stored in the digital witness DW 203), the check continues.

4) The system 200 recalculates the data describing the state of the digital witness DW 203, the HC hash code, and the SNA confirmation hash code using the HF SHA-2 hash function to check the consistency of the data. If this data is matched, the transmitted hash code THC and the timestamp of the original data S-D are retrieved from the digital witness DW 203 and displayed on the web page by the smartphone 400.

5) A person should visually compare the event displayed in the S-ED with the event displayed in the confirmation event data of the C-ED. If, according to this comparison, they represent the same actual event, the person should compare the transmitted THC hash code transmitted to the source event area SE with the transmitted THC hash code extracted from the digital witness DW 203. If both transmitted hash codes THC codes match, the time of occurrence of the event displayed in the source event data S-ED is indicated by the time contained in the timestamp of the source data S-D. Verification completed.

6) As long as record continuity is maintained, the real time of all events contained in the C-ED (including the time of events that occurred before and after the transmitted THC hash code was included in the original SE event area) can be determined.

7) It should be noted that the S-ED initiating event data and C-ED acknowledgment event data are a movie, so in the case where the S-ED initiating event data is part of the C-ED acknowledgment event data, it is sufficient to watch only one movie, and namely the C-ED acknowledgment event data.

[0162] The following will be the final comments on the present invention. The method of the present invention requires that event data (both S-ED initiating event data and C-ED acknowledgment event data) be reliable in order to be of practical use. These events must be considered reliable by at least both the creator 1 and the user.

[0163] "Event data reliability" refers to the three aspects described below.

1) Event data modification

[0164] Continuing technological development provides for a major modification of the event data, including specific changes to the received event data, such as adding backgrounds, adding changes to the face or head of the person displayed in the event data (for example, a top hat, puppy ears, etc.). Probably the most significant modification to these events is real-time video streaming with a digitally synchronized image of the face instead of the face of the mimic. However, none of these modifications are a problem for the reliability of event data if creator 1 wants reliable event data. This is because event data manipulations are only digital (virtual), so they do not change the scope of the actual event and do not have the physical interaction property.

[0165] Therefore, in order to prove that some detail of interest displayed in the event data is not the result of digital modification, it is sufficient to prove that this detail physically exists by performing physical interaction with this very detail. For example, if a person present in the area of the actual event represented by the event data is wearing a top hat that is supposedly digitally added, then to prove that the top hat does exist, he or she must show some physical interaction with that top hat at the time of receipt. event data.

[0166] The same applies if someone viewing event data displaying a speaking person suspects that the live stream being viewed is a face generated with digital lip-sync and not someone's real face. In this case, in order to prove that the person's face is real (not virtual, digitally generated), the person present in the area of the actual event must present some physical interaction with his or her face, such as touching the face with a finger or any other action, which will confirm the physical (not virtual) nature of the reality displayed in the event data.

[0167] Even in the case where the event data are photographs that are only snapshots of the actual event (as opposed to continuous video recordings) and which may be potential targets for simple and complex digital manipulations, it is possible to obtain reliable event data, for example , if you take several photos of the same event and/or show in these photos some physical interactions with the physical area displayed on them.

[0168] In view of the above, if the creator 1 wants to obtain reliable event data, he or she must take care of physically interacting with every detail of the event data, which can potentially be later questioned or disputed by the user. Another solution is to get multiple event data of the same actual event. This is especially important when receiving event data in a single mode (for example, in the form of a photograph) in order to avoid doubtful situations.

2) Event data quality

[0169] The technical parameters of the received event data should provide a quality that allows the actual event to be displayed with all the details that may be of interest to the creator 1 and/or the user. For example, if the event data is video, it should be of a quality, resolution, fps, and size to provide a satisfactory (sufficient) display of the actual event, preferably for both the creator 1 and the user.

[0170] Event data received in continuous mode must maintain continuity, i.e. the video must not contain subsequent underexposed or overexposed frames, must not be blurry, must not contain noise, etc.

[0171] Although in some situations even low quality event data may be of value to the creator 1 and/or user 4 (for example, photos or videos taken in low light conditions, but in some unique circumstances), if these event data are intended to be applied in legal proceedings (for example, as evidence in court), they must meet the highest and most modern quality standards.

3) Event data that does not contain enough information to represent the actual event

[0172] Some event data, despite being of high quality, is not sufficient to display the actual event.

[0173] This can happen if these events do not contain details that can be perceived by human senses. This can happen if someone is receiving event data from a flat, perfectly smooth surface illuminated by artificial light, or using such a surface as a background. However, even in this complex state, it is possible to obtain reliable event data. This can be achieved, for example, by: receiving the event data in a continuous manner while maintaining continuity and adding to the actual event some content that will be recognizable by human senses (such content could be, for example, the face of the creator), using a device with such a zoom, or resolution, which will allow you to see more recognizable details.

[0174] All of the requirements described above relating to the reliability of event data are similar to the requirements for event data that have generally been applied so far and have been considered to reliably represent actual events in everyday situations as well as during litigation or litigation (e.g., in as evidence in court proceedings).

Claims (70)

1. A method for generating a digital representation of an actual event, tied to the real time of the occurrence of the specified actual event, including: - receiving initiating event data S-ED of the actual initiating event SE, which is digitally documented; - sending the initial data S-D, which is a representation of the received data of the initial event S-ED, to an immutable database (203) for registration and creation of a real-time timestamp; - receiving a real-time representation of the hash code HC calculated using a hash function that had as input at least: the original data S-D, the real-time timestamp of the original data S-D and data describing the state of the specified immutable database (203) data ; - a physical representation of said hash code representation of the HC for sense perception, to ensure that the specified representation of the hash code of the HC is included in the area of the initial event SE to create a confirmation event CE; - receiving data of the confirmation event C-ED of the confirmation event CE; sending acknowledgment data C-D, which is a representation of the received acknowledgment event data C-ED, to an immutable database (203) for registration and creation of a timestamp. 2. The method of claim 1, wherein the source data S-D is equal to the source event data S-ED and the acknowledgment data C-D is equal to the acknowledgment event data C-ED. 3. The method of claim 1, wherein the source data S-D is not equal to the source event data S-ED and/or the acknowledgment data C-D is not equal to the acknowledgment event data C-ED, while the source event data S-ED and/or the acknowledgment data acknowledgment events C-ED corresponding to original data S-D and/or acknowledgment data C-D are sent for storage outside the immutable database (203). 4. The method of claim 3, wherein information about the generation process of initial data S-D and/or confirmation data C-D is sent for storage in an immutable database (203). 5. The method of claim 3, wherein information about the generation process of initial data S-D and/or confirmation data C-D is sent for storage outside the immutable database (203). 6. The method according to any one of paragraphs. 1-5, in which it further includes receiving from the immutable base (203) storage confirmation data of the original data S-D and/or confirmation data C-D, preferably with the corresponding timestamps of the original data S-D and/or confirmation data C-D and the hash code HC . 7. A memory device that stores commands that, when executed by a computer, cause the computer to execute the method according to any one of paragraphs. 1-6. 8. A system for generating a digital representation of an actual event, tied to the real time of the occurrence of the specified actual event, comprising: a digital recording means (105) configured to obtain initiating event data S-ED of an actual initiating event SE that is digitally documented; communication means (107) configured to send the initial data S-D, which is a representation of the received data of the initial event S-ED, to an immutable database for registration and creation of a real-time timestamp, and configured to receive a real-time representation of the hash code NS calculated using a hash function having at least as input: the original data S-D, the real time stamp of the original data S-D and data describing the state of the specified immutable database; presentation means (108) for physically representing said sensory representation of the HC hash code representation to cause said HC hash code representation to be included in the source event SE region to generate a CE confirmation event; digital recording means (105), further configured to receive confirmation event data C-ED of the confirmation event CE; communication means (107) further configured to send acknowledgment data C-D, which is a representation of the received acknowledgment event data C-ED, to an immutable database for registration and creation of a timestamp, the acknowledgment data C-D being a representation of acknowledgment event data C-ED. 9. The system according to claim 8, further comprising interface means (106) for interacting with the system. 10. A method for providing temporary certification of a digital representation of an actual event, tied to the real time of the occurrence of the specified actual event, including: receiving source data S-D, which is a representation of the source event data S-ED of the actual source event SE, which is digitally documented; storing the original data S-D in an immutable database (203) data; creating a real-time timestamp of the raw data S-D with a real-time timestamp obtained from a reliable clock source (300); storing a real time timestamp of the original data S-D in an immutable database (203) data; determining the state of the immutable database (203) data at a specific time indicated by the real time stamp of the original data S-D; calculating a hash code HC using a hash function having as input at least: the original data S-D, the real time stamp of the original data S-D and data describing the state of the specified immutable database (203) data; sending a real-time representation of the hash code HC for inclusion in the realm of the actual initiating event SE; receiving acknowledgment data C-D, which is a representation of acknowledgment event data S-ED of the acknowledgment event CE, wherein the acknowledgment event CE is the original event SE, further containing a physically included representation of the HC hash code in its area; storing confirmation data C-D in an immutable database (203) data; creating a real-time timestamp for the confirmation data C-D with a real-time timestamp obtained from a reliable clock source (300); storing a real time stamp of the confirmation data C-D in an immutable database (203) data. 11. The method of claim 10, further comprising storing in said immutable database (203) the HC hash code data. 12. The method of claim 10 or 11, wherein it further includes storing in said immutable database (203) the HC hash code representation data. 13. The method according to claim 10, or 11, or 12, wherein it further includes calculating and storing in immutable database (203) data a hash code of the SNA confirmation calculated using a hash function having confirmation data C-D as input , the real time stamp of the confirmation data C-D, and the hash code HC. 14. The method according to any one of paragraphs. 10-13, in which the original data S-D is equal to the original event data S-ED, and the acknowledgment data C-D is equal to the acknowledgment event data C-ED. 15. The method according to any one of paragraphs. 10-13, in which the original event data S-D is not equal to the original event data S-ED and/or the acknowledgment data C-D is not equal to the acknowledgment event data C-ED, while the original event data S-ED and/or the acknowledgment event data C- EDs corresponding to original data S-D and/or confirmation data C-D are received for storage outside the immutable database (203). 16. The method according to any one of paragraphs. 10-13, in which the original event data S-D is not equal to the original event data S-ED and/or the acknowledgment data C-D is not equal to the acknowledgment event data C-ED, while the original event data S-ED and/or the acknowledgment event data C- The EDs corresponding to the original data S-D and/or confirmation data C-D are received for storage in the immutable data base (203). 17. The method according to claim 15 or 16, wherein the process information for generating initial data S-D and/or confirmation data C-D is received for storage in an immutable database (203). 18. The method according to claim 15 or 16, wherein the process information for generating initial data S-D and/or confirmation data C-D is received for storage outside the immutable database (203). 19. The method according to any one of paragraphs. 10-18, wherein it further includes sending a storage acknowledgment of the original data S-D and/or acknowledgment data C-D, preferably with corresponding real time stamps of the original data S-D and/or acknowledgment data C-D and hash code HC. 20. The method according to any one of paragraphs. 10-19, in which the immutable database (203) is a distributed ledger. 21. A memory device that stores commands that, when executed by a computer, cause the computer to execute the method according to any one of paragraphs. 10-20. 22. A system for providing temporary certification of a digital representation of an actual event, tied to the real time of the occurrence of the specified actual event, containing: at least one storage device (202) containing an immutable database (203) data; at least one processor (201); communication means (204), wherein said communication means (204) is configured to receive and store source data S-D, which is a representation of the source event data S-ED of the actual source event SE, which is digitally documented, wherein said immutable database (203) is configured to generate real-time timestamps of the original S-D data with a real-time timestamp obtained from a reliable clock source (300), wherein said immutable data base (203) is additionally configured to store said original data S-D and store a real-time timestamp of the original data S-D, wherein said at least one processor (201) is configured to determine data describing the state of said immutable data base (203) at a specific time indicated by a real-time timestamp obtained when creating a timestamp of the original data S-D, and is configured to calculate a hash - HC code using a hash function having at least as input: data describing the state of the immutable database (203) of the data, the original data (S-D) and the real time stamp of the original data (S-D), wherein the communication means (204) is further configured to send the HC hash code representation and receive the CE confirmation event C-ED confirmation event data, wherein the CE confirmation event is an initial SE event containing an optionally physically included representation of the HC hash code in its area , wherein said immutable data base (203) is further configured to store said C-D confirmation data, which is a representation of C-ED confirmation event data, and create real-time timestamps of C-D confirmation data with a real-time timestamp obtained from a trusted source (300 ) clock signals. 23. The system of claim. 22, in which the specified at least one processor (201) is further configured to calculate the hash code of the SNA confirmation using a hash function having at least confirmation data C-D, a real-time timestamp acknowledgment data C-D and a hash code HC, said communication means (204) being further configured to send a hash code of the acknowledgment CHC. 24. The system of claim 22, wherein said immutable data base (203) is configured to store a hash code of the SNA confirmation. 25. A method for providing data to verify a digital representation tied to the real time of its occurrence, including: receiving a request for VD verification data relating to the actual event of interest, linked to the real time of its occurrence and generated by the method according to any one of paragraphs. 1-6; checking whether VD verification data relating to said actual event of interest exists in the immutable database (203) that is requested; sending the requested VD verification data regarding said actual event of interest. 26. The method of claim 25, further comprising verifying the consistency of said VD verification data regarding said actual event of interest by recomputing at least an HC hash code that undeniably certifies the time of occurrence of the event of interest. 27. A method for checking a digital representation tied to the real time of its occurrence, including: - extracting from the immutable database (203) the VD verification data regarding the actual event of interest, generated by the method according to paragraphs. 1-6, wherein said verification data VD is at least: a hash code representation HC, original data S-D, and confirmation data C-D; - detecting the representation of the hash code of the HC in the context of the actual event registered as the data of the confirmation event C-ED, using artificial intelligence (AI); - comparison of the registered initiating event SE, represented by the initial data S-D, and the confirmation event CE, represented by the confirmation data C-D, using AI. 28. A storage device that stores instructions that, when executed by a computer, cause the computer to execute the method according to claim 27. 29. The method of linking the digital representation of the actual event to the real time of the actual event, which includes the following steps performed in real time: receiving the source event data S-ED of the actual source event SE and sending the original data representation E-D to an immutable data base (203) for storing and creating a real-time timestamp; calculating the hash code HC using hash functions having at least as input: data describing the state of the immutable database (203) data, the original data S-D and the real time stamp of the original data S-D; converting the hash code HC into a representation of the hash code HC and storing the method used to perform the conversion; presenting a real-time representation of the HC hash code to include said representation in the scope of the initial SE event to create a CE confirmation event, wherein the CE confirmation event is the initial SE event with the HC hash representation physically present; receiving acknowledgment event data C-ED of acknowledgment event CE; and sending a representation of acknowledgment data C-D to an immutable data base (203) for storing and momentarily creating a timestamp.

Images