Digital signature algorithm for verifying edited data

Abstract

Embodiments of this disclosure provide, but are not limited to, technical solutions for protecting, sharing, verifying, and / or generating data resources such as documents. In exemplary embodiments, a document is represented or defined as a plurality of hashed constituent segments. A Merkle tree representing the document is generated using the segment hashes as leaves. An edited version of the document can be shared, with one or more segments that the data controller wishes to keep confidential omitted. To verify the authenticity and / or completeness of the edited document, the verifier is provided with sufficient data to confirm the presence of non-segments in the tree and authorized signatures that signed the root.

Description

Technical Field

[0001] The present disclosure provides systems and methods for the secure distribution of data, verification of data authenticity and integrity, and maintenance of data security. Additionally or alternatively, embodiments provide improved digital signature algorithms for the sharing, provision, storage, protection, and / or processing of data resources. Embodiments utilize cryptographic techniques to enhance data security and access control, and are particularly suitable for use in, but not limited to, the redaction, anonymization, and / or sanitization of data shared with one or more parties.

[0002] Other technical effects include, but are not limited to, the scalability of data storage solutions, the provision of secure and verifiable documents with editable formats (e.g., templates, forms that can be input by users), the ability to represent the hierarchical structure of data in a verifiable storage resource without making the content itself public or available, etc. These solutions can further enhance the verification of data integrity and authenticity when combined with blockchain technology.

[0003] These aspects will be described and illustrated in more detail below.

Background Art

[0004] Throughout history, humanity has had the need and desire to keep some of the shared information secret, some public, and some not public. Simple and traditional methods include creating a document on a surface such as paper and then covering or masking it in some way, such as blotting out the confidential parts with thick ink, or pasting masking materials such as tape or paper over it.

[0005] However, such techniques are not easy to apply (especially with long documents), and in some cases, highly confidential content underneath may be unintentionally revealed. For example, the ink may not be dark enough to adequately conceal the content underneath, or the mask may be unintentionally moved during subsequent copying or transmission. Computer-based technologies have provided various mechanisms to facilitate the editing of electronic data resources, but technical challenges remain, especially with large datasets. These include methods for verifying the authenticity and integrity of shared data resources, such as when parts of a document are deleted.

[0006] Therefore, there is a need to provide an improved solution for verifying edited electronic data resources. Such an improved solution has been devised. [Overview of the project]

[0007] Features referred to in this specification in relation to one or more embodiments are not intended to be limiting. Features disclosed herein may be used interchangeably in various embodiments and configurations.

[0008] In one embodiment, the embodiment provides a solution for secure, cryptographically enhanced access or control of data transmitted or shared between a data administrator and at least one data recipient. In particular, preferred embodiments can provide techniques and systems for redacting one or more portions of a shared, processed, or stored data resource. As used herein, “redacting” includes concealing, masking, removing, deleting, and / or replacing one or more selected portions of a data resource.

[0009] In one representation, a preferred embodiment may include a method for applying a signature algorithm to a data resource using a Merkle tree such that editing one or more segments (i.e., parts) of the data resource does not result in a loss of the ability to verify the authenticity or completeness of that data resource. Advantageously, the embodiment can allow editing of selected parts of a data resource without affecting or invalidating the validity of the signature applied to the data resource by the data controller.

[0010] In such embodiments, data resources can be divided into multiple segments. The size, number, and other attributes of the segments can be determined based on criteria selected by the data administrator.

[0011] These segments can be used to construct a tree structure representing the data resources. This tree structure is preferably a hash tree (also called a Merkle tree), in which the leaf nodes at the bottom of the tree are hashed in pairs to generate a hash that acts as the parent node at the previous (i.e., immediately above) level of the tree. This hashing of pairs continues until the hash of the root of the tree is computed.

[0012] After the data segments of a data resource have been hashed to form a Merkle tree, the data administrator can cryptographically sign the root hash to prove (verify) the authenticity and / or completeness of the data contained in / represented in the tree. This signature provides proof that the data resource was approved, created, and / or processed by the data administrator.

[0013] Next, the data administrator can select one or more segments from the data resource that should be edited before storing, processing, accessing, and / or sharing the data resource.

[0014] Editing a selected segment may involve one or more actions such as hiding, modifying, masking, deleting, or replacing the original version of the selected segment from the data resource (or a copy thereof).

[0015] A data administrator may share or present one or more of the following to one or more recipients: - The Merkle tree of the entire original (pre-edited) data resource; - The public key corresponding to the private key used to sign the root hash, to facilitate signature verification; - Unedited segments of data resources.

[0016] The recipient can use the public key to verify whether the data resources represented in the Merkle tree were actually generated and / or authorized by the data controller who possesses the corresponding private key.

[0017] Therefore, the verifier, Construct a tree representing the unedited version of the data resource, Verify that the root of the constructed tree matches the root of the tree shared by the data administrator. Verify that the signature applied to the signed Merkle root provided by the data controller was generated / approved by the data controller. Verification can be performed by doing so. The construction of a tree representing the unedited version of a data resource can be performed by a verifier using the edited version of the data resource and the hash values ​​of the edited segments. Thus, the verifier can perform verification against the signed Merkle root of the Merkle tree instance that represents the unedited original version of the constructed data resource.

[0018] In some embodiments, the data administrator can retain the edited segments (e.g., in an encrypted form). Additionally or alternatively, the data administrator can discard / delete the original copies of one or more edited segments.

[0019] In accordance with one or more aspects, the present disclosure can provide a computer-implemented apparatus (e.g., a stand-alone device or system) that facilitates one or more of the steps shown above. The apparatus can comprise hardware, software, and / or firmware for performing one or more of the method steps disclosed herein.

[0020] In one embodiment, the apparatus - decomposes data resources into multiple segments, - generates a Merkle tree representing the multiple segments, - cryptographically signs the root hash of the tree, - selects one or more segments for editing from the data resource or a copy thereof, - shares, stores, or otherwise processes the signed hash root, the Merkle tree of the data resource, the original data resource, and / or the original segments selected for editing. It may comprise software, firmware, and / or hardware configured to facilitate or enable one or more of the above.

[0021] In another embodiment, the apparatus may comprise software and / or hardware for facilitating or enabling the display, playback, or presentation of the edited data resource by a recipient. Such an apparatus may comprise a browser, a wallet, word processor software, or other software application for processing (e.g., displaying, printing, audio playback, etc.) the data resource excluding the selected edited segments.

[0022] In some cases, it may be possible to do so by providing a predetermined flag (e.g., an audible sound, a visual symbol, a tactile vibration, or other signal) indicating that a part of the data is edited at a specific position within the data resource. In this case, when replicated by the recipient, this flag may replace the edited segment in the edited version of the data resource.

[0023] In contrast to prior art approaches that provide selective disclosure techniques involving the provision of Merkle proofs (paths) to specific data, embodiments of the present disclosure involve signing the root of the tree of the entire data resource. After signing, the verifying party can confirm that the entire document is legitimate, authentic, and unaltered despite the provision of an edited version of the original data resource.

[0024] Additional technical effects include, but are not limited to, scalability of data storage solutions, provision of secure and verifiable documents (e.g., templates, forms that can be input by users) formatted for editing, and the ability to represent the hierarchy of data in a verifiable storage resource without exposing or making the content itself available.

[0025] To assist in understanding the embodiments of the present disclosure and to show how such embodiments are implemented, reference is made by way of example to the accompanying drawings.

Brief Description of the Drawings

[0026] [Figure 1] It is a schematic block diagram of a system for implementing a blockchain. [Figure 2] It is a diagram schematically showing an example of a transaction that can be recorded on a blockchain. [Figure 3A] It is a schematic block diagram of a client application. [Figure 3B]Figure 3A is a schematic mockup of an example user interface that may be presented by the client application. [Figure 4] This is a schematic block diagram of a node software that processes transactions. [Figure 5] This figure illustrates an exemplary embodiment of the present disclosure, in which a data resource (in this example, a document) is created and divided into multiple segments. [Figure 6] This figure shows an exemplary embodiment of the present disclosure, which is used to hash the segments in Figure 5 and construct a Merkle tree representing multiple segments. [Figure 7] This figure shows an exemplary embodiment of the present disclosure in which the root of the Merkle tree is signed using an appropriate digital signature algorithm such as ECDSA, rather than a limited signature. [Figure 8] This figure illustrates an exemplary embodiment of the present disclosure, in which the necessary data is provided to the verifier (e.g., Bob), who then calculates the remaining data himself and can then verify whether the provided signed Merkle root matches what he calculated. [Figure 9] Figure 5 illustrates an exemplary embodiment of the present disclosure, and the validator uses the data provided in Figure 5 to perform the verification process. [Figure 10] This figure illustrates an exemplary embodiment of the present disclosure, in which a Merkle tree is used to verify a larger segment of the same file or a single copy of the entire file as separate segments. [Figure 11] This figure shows an exemplary embodiment of the present disclosure in which MerklePath is provided to optimize customized documents such as contracts. [Figure 12] This figure shows an exemplary embodiment of the present disclosure in which MerklePath is provided to optimize customized documents such as contracts. [Figure 13]This figure shows how a data administrator, such as a database administrator, can create and add a VAST file system using the embodiments disclosed herein. Figures 13 to 26 illustrate examples of use of various embodiments and how this disclosure applies to a VAST file system as an example. [Figure 14] This figure shows how a data administrator, for example, a database administrator, can create and add a VAST file system using the embodiments disclosed herein. [Figure 15] Figures 13 and 14 illustrate examples of embodiments in which the user generates a VAST file system record and assigns ownership of the file system to an identifier. [Figure 16] Figures 13, 14, and 15 illustrate how a user requests and receives files from the VAST file system shown. [Figure 17] Figures 13, 14, and 15 illustrate how a user requests and receives files from the VAST file system shown. [Figure 18] Figures 13, 14, and 15 illustrate how a user requests and receives files from the VAST file system shown. [Figure 19] These figures show how a user can request and retrieve files from the VAST file system shown in Figures 13 to 18, as implemented according to the embodiments of this disclosure, and how these files can be verified. [Figure 20] Figures 13 to 19 show how to modify the entries in the usage examples once or multiple times. [Figure 21] This figure shows how embodiments are used to perform scalable updates of information and data, such as data recorded and processed by the exemplary systems provided herein. [Figure 22] This figure shows how subtrees are used within Merkle trees in various embodiments disclosed herein. [Figure 23]Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Figure 24] Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Figure 25] Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Figure 26] Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Modes for carrying out the invention]

[0027] Material specific to the invention For illustrative purposes, examples of preferred embodiments of this disclosure are provided.

[0028] According to a preferred embodiment, the present disclosure provides a method and corresponding system for editing one or more portions of data from a data resource, the data resource being hereinafter referred to as “document” for ease of explanation and reference.

[0029] Embodiments of this disclosure provide solutions (methods and systems) for secure and verifiable editing of data resources 510, extension of data storage and / or data verification systems, and improvement of hierarchical data storage systems on computer-based storage resources. Referring to Figures 5 and 6, at least one data resource 510 is broken down into multiple segments 520 and represented in a tree structure having a root 610. The root 610 is then signed by an authorized party to certify the authenticity of the data contained in the tree. For convenience, the authorized party may be referred to as the administrator of the data resource. This signature can then be used by another party to verify the authenticity of document 510, even if one or more portions of document 510 have been edited from a version provided to that party. The advantage of the disclosed technology is that it does not impair or degrade the integrity of the digital signature applied to the entire content of the document.

[0030] A document 510 is created and can then be divided into smaller elements (segments) 520. Segments may be as small as the smallest division unit (e.g., a single character) or they may consist of larger data portions. In some cases, a segment may even be an entire file or a group of files. In other words, a segment is a part of a data entity / resource, whether logical or not.

[0031] A tree is created that has 620 internal nodes and often uses the hash of segment 520 as a leaf 630. In a preferred embodiment, this tree is a Merkle tree, and for convenience, we will refer to it as a Merkle tree below.

[0032] To approve document 510 and to prove its origin, authenticity, and / or completeness, one or more data controllers sign the Merkle tree root 610. The signature is generated using a cryptographic key and is sometimes called a digital signature or cryptographic signature. It is preferable that the signature be applied to the root of the Merkle tree that constitutes the document, rather than to the document itself. In a preferred embodiment, individual hashes 630 are not signed.

[0033] In some cases, the data controller may be the creator, agent, or other party with legitimate or control over the document. In some cases, “control” may include “ownership” of the document. The authenticity verifier (sometimes called the “verifier”) can calculate the root and verify the signature if the data controller provides (or on behalf of) the minimum necessary data.

[0034] In the following example, we will refer to the data controller as Alice and the other party (the one performing the legitimacy verification) as Bob. Bob may be an end-user / consumer who uses or views the edited version of the document, or Bob may only perform the verification process, confirm its legitimacy, and then deliver the edited data resource to the end-user. More specifically, a preferred embodiment may include at least one or more of the following steps. One or more of the following steps may be provided by a single party or group of parties, or by several separate parties. The process may be distributed.

[0035] Step 1: Referring to Figure 5, Alice creates a document 510 and divides it into multiple segments 520. This involves generating logical definitions of segments rather than physically dividing the data. How Alice divides the document is an implementation choice. The division is determined based on, or using, criteria selected or acquired by Alice (such as size, number, or other segment attributes). For example, Alice may decide to divide the document into the smallest possible division units, such as individual bits, individual characters (e.g., ASCII), single-byte / multi-byte segments, or according to other criteria selected by Alice.

[0036] A segment can consist of any part of a document, from a single character to an entire section or even an entire chapter. By dividing a document into small segments, Alice can have fine-grained control over which parts of the document she wants to edit.

[0037] Step 2: Referring to Figure 6, Alice hashes each of the individual segments 520 and uses them to represent document 510a in a tree structure. Alice inserts the hash 630 of each segment 520 into the Merkle tree as a leaf node 630 (sometimes called a leaf element, or simply a "leaf").

[0038] Segment 520 can be further broken down into subsegments 2610 (see, for example, Figure 26), but segment 630 is the smallest individual editable component of the document. In other words, after building the Merkle tree with segments as leaves in steps 2 and 3, it is not possible to edit any part of document 510 smaller than segment 630. Thus, the segment is also called the “smallest editable element” 630.

[0039] As can be seen from the explanation in Figure 6, the order and structure of segments, as well as the relationships between segments, are preserved and represented in the Merkle tree. This can be important when processing the data later. For example, the segments may be reorganized into a viewable / usable format so that a user can read an edited version of the document or process it in other ways. However, in other embodiments, depending on the requirements of the relevant implementation and use case, it may not be necessary to preserve the original order or structure of the segments, or they may be intentionally randomized during tree construction.

[0040] Step 4: Referring to Figure 7, Alice signs the hash of the tree's vertex (i.e., root). Signature 710 can be generated using the following steps: 1. The signer's private key (for example, Alice's private key) is associated with the public key. 2. K value - This is usually a random value. 3. Message Hash A hashed message has the advantage of being able to include other data elements. These can be hashes of other documents, data items, or other Merkle tree roots, allowing a single signature to be applied to multiple documents.

[0041] Step 5: Referring to Figure 8, Alice edits at least one segment from the document by selecting one or more segments to omit from the version of the document she provides to Bob. This may include the step of selecting at least one segment that is provided only in hash format, rather than the original pre-image version.

[0042] Step 6: Referring to Figure 8, Alice provides the tree root 610, the unedited segment, and the hash of the edited segment that Bob needs for verification.

[0043] In other words, Alice provides Bob with the non-confidential parts of the documents she shares with him, as well as the data Bob needs to perform the verification process (which he cannot calculate himself).

[0044] If Bob is both the validator and the end-user who consumes (uses, stores, and processes) the edited data, Alice can provide Bob with all the unedited segments. Alternatively, Bob may simply perform validation functions and not be an end-user. In this case, Alice can provide Bob with a sample for validation purposes only, rather than all the unedited segments.

[0045] In a simple case, Case 1, the document information provided to the verifying party (i.e., Bob) would be as follows, as shown in Figure 8. • Digital signature • Markle Route • At least one unedited document section • Markle path to the provided unedited document section

[0046] In the more complex Case 2, as mentioned above, Alice may provide additional data items in the signed message along with the signed Merkle root. As shown in Figure 8, in such a case, Alice provides Bob with the following information: • Your own digital signature • Markle Route • The hash of any additional data (e.g., metadata) within the signed message. You need to provide Bob with the entire pre-image so he can calculate the hash and perform any necessary checks. • At least one unedited document section • Markle path to unedited document sections provided to Bob

[0047] Figure 8 shows that Alice does not need to send Bob the entire Merkle tree. Alice only needs to provide Bob with the unedited portion of the document she is sharing and the data necessary to verify the signature attached to the signed data. The signed message 710 may contain only the Merkle root (Case 1), or the Merkle root with the additional data 720 added (Case 2).

[0048] Step 7: Referring to Figure 9, Bob verifies the authenticity / completeness of a document even if some or more parts of it have been edited. The verification process consists of at least the following steps, and Bob performs the following steps: 1. Verify that the key / digital signature / message matches. 2. Verify that the Merkle root matches the version provided in the message. 3. Access the single smallest editable segment 630. 4. Hash the smallest editable element. a. Calculate the route using the provided Merkle path elements. b. Hash the unedited document section. c. The Merkle path to an unedited document section (i.e., the minimum number of additional nodes in the tree required to calculate the root hash, starting from a specific leaf).

[0049] In the example in Figure 9, Bob performs the following calculation to execute the verification process: 1. Hash the document title to generate "16". 2. Hash 16 and 17 to calculate 8 (this involves concatenating 16 and 17 and hashing the result). 3. Hash 8 and 9 to calculate 4. 4. Hash Section 2 Clause 1 to calculate 19. 5. Hash 18 and 19 to calculate 10. 6. Hash 10 and 11 to calculate 5. 7. Hash 4 and 5 to calculate 2. 8. Hash Section 4 Clause 3 to calculate 21. 9. Hash 20 and 21 to calculate 13. 10. Hash 12 and 13 to calculate 6. 11. Hash "Name and Role 1" to calculate 23. 12. Hash 22 and 23 to calculate 14. 13. Hash 14 and 15 to calculate 7. 14. Hash 6 and 7 to calculate 3. 15. Hash 2 and 3 to find 1 (i.e., the root).

[0050] It should be noted that Bob does not need the entire Merkle tree or all the hashes of the edited segments. Once the Merkle root is computed (step 15), it can be checked whether the hash value used to generate the signature matches the one provided by Alice. If the hashes match and the signature is valid, it proves that the edited segments form part of the whole document and that the signature is applied to all items on the leaves of the tree. In other words, Bob can prove that Alice used her private key to generate a signature applied to the root of the Merkle tree representing the whole unedited document.

[0051] Step 8: The edited document may be provided by the end user / consumer (Bob or at least one other party, as described above) in some way, such as by being displayed or output. For convenience, we will assume here that this is Bob.

[0052] In some cases, Bob may use a browser, wallet, word processor, image display application, or other software application configured to output or process unedited data. The output of unedited data may be provided in a visual, auditory, or tactile format, or in an electronic format such as a storable or processable digital resource. For example, this might involve playing an audio or video file, displaying a document on a screen, printing to some output device, or outputting and storing at least one data file, or sending it to at least one recipient.

[0053] In some embodiments, one or more edited segments can be replaced with alternative markers or indicators. For example, an edited portion of a text file might be displayed on the screen as a blank box or an "X" instead of the edited data. In the case of an audio file, a sound such as a beep might be emitted. This allows the viewer / listener / end user to know that a portion of the data has been deleted at that location.

[0054] Variations and Use Cases Secure distributed storage technology In some embodiments, Alice can retain the edited segments. In addition, or alternatively, Alice can also discard / delete original copies of one or more edited segments.

[0055] In some cases, edited segments can be sent to different storage facilities for secure storage. It's also possible to encrypt one or more segments using different algorithms and keys. The advantage of this method is that anyone attempting to duplicate the entire document would need to access the individual edited segments from different (preferably secret) locations and know the multiple encryption algorithms and keys used. This makes accessing the entire document significantly more difficult, resulting in a more secure data storage solution with lower vulnerability to unauthorized access. Highly sensitive data, such as confidentiality, personal information, commercial value, or security-related data, can benefit from being stored in this manner.

[0056] Large-scale data resources Figure 10 shows that by extending the scope of the Merkle tree, larger segments of the same file, or even a single copy of the entire file, can be included as individual elements. For large items containing many small editable segments, this makes document sharing more efficient because it reduces the amount of Merkle path and data that Alice provides to Bob to share the larger, unedited section. There is no impact on any properties, except that the amount of Merkle path data that needs to be shared per segment may increase slightly.

[0057] Templates and forms: Referring to Figures 11 and 12, Merkle paths can be used to optimize customized documents. In such cases, the edited segments can be used as "empty" sections of the document that the user can fill in. For example, the document could be a contract, form, template, payment authorization form, or any other type of document that the user needs to fill in, perform, adapt, or modify in some way. For convenience, we will use the example of a widely known contract. In the case of a contract that is reused by different contracting parties on various occasions, the contract can be divided into sections to form a Merkle tree with 2AN leaves, as shown in Figure 11. The number of segments in the contract is 2N If there are fewer items, you can pad them using blank leaves, as shown in Figures 11 and 12. This Merkle branch can be reused multiple times to create individual contracts that use the same template contract. In this way, the contract creator (e.g., Alice) can add individual sections to the contract in a different branch without changing the hash in the template branch.

[0058] As shown in Figure 12, signing a copy of a document allows you to add names, roles, special conditions, etc., to the Merkle tree without changing the hashes of existing branches in the tree. In the example in Figure 12, a provisional employment document is created containing a standard set of sections and clauses. Anyone with the same contract can use the same Merkle path to match the static (unedited) sections of the document against the template, but user-customized sections will use different hashes and different Merkle paths, generating unique Merkle roots.

[0059] Accordingly, one or more embodiments provide an improved solution for obtaining or providing forms, templates, or other types of data resources that require or facilitate completion by one or more users. The act of completion may include providing at least one signature (digital, encrypted, or otherwise formed) and / or providing one or more pieces of data. An edited version of the data resource may be formed according to any embodiment disclosed herein and provided to one or more users. Users may provide responses or inputs to replace, supply, change, modify, or otherwise process at least one edited segment. Thus, the edited segment may function as a placeholder for inputs provided by one or more users.

[0060] In some embodiments, the user can complete the edited document (i.e., template) by entering missing data, and the completed template is verified by a previous verifier (Bob) or another party.

[0061] For example, consider a scenario where a data administrator, such as a passport office, a company employing one or more employees, or an airline wants to send a form to a user for them to fill out. In these examples, the user could be a passport applicant, an employee, or a passenger. For illustrative purposes, we will use the examples of a passport office and a passport applicant.

[0062] Passport offices have standard forms that applicants must complete. These forms are provided in various formats, including those for applicants with hearing or visual impairments. The forms consist of data segments that are output to the applicant via screen, paper, vibration, sound, etc. There are also blank sections that applicants must fill in by entering data in those locations on the document.

[0063] However, it has been found, or is suspected, that unauthorized entities are impersonating passport offices, soliciting completion of forged forms, and distributing fraudulent versions of these forms to potential victims of fraud with the aim of obtaining valuable personal information, financial data, and / or associated payments.

[0064] In such circumstances, the Passport Office may provide hardware-based and / or software-based verification components that applicants and / or the Passport Office can use to verify the authenticity of documents submitted by the applicant. These verification components may be provided in various forms, including internet-based resources such as websites and cloud-based facilities, installable applications, digital wallets, and other computer-based mechanisms.

[0065] The Passport Office may edit some or more segments of an application form for completion by the applicant when a valid application is submitted. It may also insert hidden codes, watermarks, verification identifiers, timestamps, etc., into some or more segments that have not been edited. This can be done using appropriate known methods that facilitate watermarking, such as steganography. Essentially, one or more segments may be arranged to (preferably) contain a hidden identifier or code, which can be verified using the verification processes described herein. Identifiers / codes / watermarks / timestamps / references, etc., may be chosen to uniquely identify an event, a party associated with a data resource, at least one blockchain transaction, a version number and / or data, a cryptographic key, or any other type or form of data that the data controller wishes to include in the data resource. The phrase “identifier” is used to include codes / watermarks / timestamps / references, etc. Identifiers are obtained using at least one random or pseudo-random operation, or as a result of a mathematical operation, but are obtained by selection / generation by one or more people or processor-based means.

[0066] When an identifier is associated with a blockchain transaction, it may include or provide the transaction ID, block ID, the transaction / block itself or a part thereof, and / or hashes thereof. The transaction may include data related to data resources and / or data controllers. In other cases, alternative locations such as the cloud, websites, or servers may be used to store this associated data, but storing it on the blockchain has the advantage of providing an immutable, timestamped, and cryptographically protected copy of the data.

[0067] In some cases, a verification identifier may be provided for one or more edited segments, as verification using a signed Merkle root proves that the edited segment is part of the entire original document. This has the advantage that data administrators can verify the returned copy, while the shared edited version received by the user does not include the verification identifier, thus preventing unauthorized third parties from forging it. In this way, the embodiment can provide a security measure that allows users to verify with data administrators whether the data resources they receive are indeed legitimate and up-to-date.

[0068] The Merkle Tree root is digitally signed by the Passport Office as described above, and the selected, unedited segments are made public to the end user as described above. When an applicant submits a form to the Passport Office through an authorized root, the completed form (or the signed Merkle root of that form) is attached to or provided with the user's completed data. This ensures that the application form used by the user is verified in accordance with the embodiments disclosed herein. If the form submitted by the user to the Passport Office is altered in any way compared to the authorized version, the hash and signature will not match the legitimate one. Therefore, the Passport Office may notify or warn applicants who submit a form to the Passport Office through electronic means, such as completing an online form or downloading an authorized “Application Submission” app, about the validity of the submitted data. The applicant may receive a verification notice indicating that the completed form received has been reviewed by the Passport Office and verified as legitimate.

[0069] Similarly, segments may include the form version number. If the law changes, the version number of the official passport form will be updated. If a user fills out an older version of an official application form, the verification software can identify this and be configured to send a warning or reject the application.

[0070] Therefore, the embodiments can provide not only verifiable forms and templates for user input, but also security methods and systems for data administrators to verify that such forms have not been tampered with, corrupted, or provided improperly upon receipt. Furthermore, they can also provide version control solutions for shared data such as documents, digital content, and executable code.

[0071] Example use case: VAST file system and database snapshots For illustrative purposes, use case examples illustrating how embodiments of this disclosure are performed are shown with particular reference to Figures 13 to 24. Files can be considered segments. Files can be added or modified within the system.

[0072] As an example, consider a scenario in which items are created (recorded) in a database. Files are created in one or more locations on one or more memory modules, and the file system is accessible from one or more devices and from one or more locations. A VAST file system is a file system consisting of files stored in a large number of locations. Using the techniques disclosed herein, the file system can be represented as a Merkle tree, and the Merkle tree may include each file as a leaf of the Merkle tree and may include information such as routing data and database memory locations to facilitate access to the files.

[0073] A leaf of a Merkle tree may also become the root of another Merkle tree representing an editable file according to one or more of the methods disclosed herein.

[0074] One or more signatures are generated by the data administrator and applied to the Merkle root of the VAST file system and the contents of the entire database. This provides a secure and verifiable snapshot of the file system at the time the signatures were generated. If a file and its Merkle root to its leaves are available, it is proven that the file was part of the VAST file system. If the file is in an editable format, both the Merkle path to the file's Merkle root and the Merkle path to the unedited file segment being shared must be provided to the recipient, to demonstrate that 1) the provided file or editable element of the file is correct, and 2) the file has been accepted into the VAST file system.

[0075] Figures 13 and 14 illustrate how a data administrator (e.g., database administrator Alice) creates a VAST file system and adds data to it using the embodiments disclosed herein. As shown in Figure 13, each entry / item has a unique location within the Merkle tree.

[0076] Figure 15 illustrates the process by which Alice generates VAST filesystem records and assigns or attributes ownership of the filesystem to identities such as owners, organizations, or departments. As shown in Figure 15, Alice can expose the Merkle root to a blockchain, which may, but is not limited to, a public blockchain such as the Bitcoin blockchain in some examples. In addition, or alternatively, Alice can expose the Merkle root to the public as a Metanet child of a Metanet node owned by the party managing the database (in accordance with one or more of International Publications 2020 / 109910, 202 / 110025, 2021 / 229334, 2022 / 200193, and 2020 / 109908, these are all incorporated herein). Advantages of exposing the Merkle root to a blockchain include the ability to provide a timestamped, immutable record for snapshot verification.

[0077] All files within the VAST file system can now be traced back to a publicly available Merkle root signed by the VAST file system owner. Furthermore, as shown in Figure 15, the Merkle root can be made public for Bob's verification purposes, while the actual content remains private. Therefore, Bob can verify the continued existence and integrity of the database content for security purposes without leaking sensitive information, personal information, valuable information, or other classified information (such as military-related or commercially valuable data).

[0078] Referring to Figures 16 to 18, examples of embodiments in which a user can request and retrieve files in multiple ways are shown. In Figure 16, when a file is requested, the illustrated service verifies the user's access rights to the information, and if valid, searches for the file in the memory storage unit where the information is stored and provides it to the user's device. The user can send user account information, device-specific identifiers, etc. In all cases, a gating function is applied that responds only to valid requests from parties with the appropriate level of permission.

[0079] In Figure 17, when a file is requested, the service provides the user with a hash of the file. The user and the database owner / administrator (Alice) work together to create a secret key pair using the service's known key (for example, one provided by the Metanet root node), the user's account key, and the file hash.

[0080] Figure 18 shows how files are delivered from Alice to Bob by providing the following two components: 1. Files. To transfer files, the service creates an HMAC (Hash-Based Authentication Code), known in this technology, and uses the generated secret key to encrypt and transfer the files. 2. The Merkle path from the file hash to the Merkle root of the public file system is also transferred. This makes the aforementioned verification possible.

[0081] Figure 19 illustrates the file verification process. The user (e.g., Bob) verifies the file using the following steps: 1. The entire contents of that leaf in the Merkle tree need to be transferred. 2. The recipient hashes the file. 3. The hash is matched against the provided Merkle path. 4. The Merkle path is cross-referenced with the Merkle root publicly available in the public ledger.

[0082] If the matching results are a match, the verification is successful; otherwise, it fails. This process allows Bob to verify that the file is exactly the same as the one added to the file system when the entry was created.

[0083] Figure 20 illustrates how entries in a VAST filesystem are processed (e.g., modified). An entry can be modified once or multiple times. Each modification requires the computation of a new N hash set, where N is the depth of the Merkle tree. To limit the number of modifications that can be performed within a block of N entries to N, a redirect can be issued. This pushes all modifications to the active side of the Merkle tree (i.e., the part where actions and modifications take place), limiting the complexity and resource costs associated with performing updates.

[0084] Scalable updates The embodiments of this disclosure demonstrate how to achieve scalable updates of information and data using the VAST file system shown in Figures 13 to 24. Referring particularly to Figure 21, to achieve effective scaling, each leaf can be limited to a single change to a new hash representing the updated information. Leaf updates may also include hashes of previous documents (i.e., the pre-update document, the previous document, and / or the original document).

[0085] When a file is modified, a new leaf is created with the new file hash and information. The Merkle path is recalculated up to the top of the relevant branch closest to the original location.

[0086] Then, a redirect is issued to the leaf location where the previous version was registered, and the Merkle path is recalculated to the root of the Merkle tree. After that, the root can be published.

[0087] subtree Referring particularly to Figures 22 to 26, subtrees can be added to implement, represent, and / or make functional subdirectory structures. This allows for the implementation of hierarchical data structures in an efficient and verifiable manner. In some embodiments, subtrees as a whole can represent separate databases. Subtrees can inherit the same functionality as the main tree and are created through entries in the main tree. Advantageously, one or more subtrees can be added, which are Merkle trees of documents formed into segments according to the embodiments described above.

[0088] Figures 23 to 26 illustrate examples of subtree usage. Consider a scenario in which an organization creates a tree of contract clauses within a contract document, as shown in the attached diagrams and described above. In this example, these contract clauses are stored in a subtree of an enterprise-wide on-chain ledger. The first N entries are a list of contract clauses that can be used to construct the entire contract. In some embodiments, this can be implemented in EBRL, FPML, or other suitable format.

[0089] The N+1th entry is the transaction identifier (TXID) of the blockchain transaction. This transaction consists of a contract generated from the higher-level tree, and a subtree (or Merkle root of the subtree) containing associated user data and signatures. The hash of the complete document is added to the Merkle tree and made public.

[0090] Advantageously, it is possible to provide logic code to automate the execution and use of contracts. For example, the software may include rules that prevent a contract containing clauses lower down in the Merkle tree from being used in a valid contract. This allows for updating the database and applying permissions to specific versions of the document. In some embodiments, contracts may be implemented on the blockchain as “smart contracts.” In certain embodiments, smart contracts may be associated with tokenized assets, which may be non-fungible tokens (NFTs) known in the art.

[0091] In some embodiments, a contract can be generated from segments that are hashed to leaf elements of a higher-level tree. The entire contract is delivered as a single contiguous part via HMAC, and the user can hash the entire document and verify that it matches the expected hash in the contract ledger. This ensures that the user is always referring to the correct version of the contract. As an example, as shown in Figure 26, a contract using the clause at position 13 is invalid in the subtree at position 10 but valid in the subtree at position 16. Thus, some embodiments may include steps of providing, obtaining, processing and / or using smart contracts to automate the execution of a contract configured substantially as disclosed in any of the embodiments provided herein.

[0092] As described above, the embodiments provide a solution for verifying electronic data resources even when a subset of the data has been edited / deleted. In preferred embodiments, the properties of Merkle trees are utilized to provide such a solution. While Merkle trees are known, the disclosed embodiments differ in important and original ways.

[0093] term It should be noted that the terms “editing,” “adaptive editing,” and “sanitizing” have been used in a somewhat fluid and inconsistent manner in the prior art. Here, for ease of reference, we will use the term “editing,” which is intended to include “adaptive editing” and “sanitizing,” and to encompass the “concealing,” “masking,” “deleting,” and “replacing” one or more selected portions of a data resource.

[0094] Furthermore, the following terms are used in this book as follows: "Sharing" includes any or more of displaying, transmitting, distributing, presenting, streaming, printing, making available, providing access, or providing from one or more other entities to at least one other entity. Entities mean any human being, machine-based resource, or group thereof. Preferably, "sharing" includes providing the contents of a segment to at least one other entity in a meaningful manner, for example, in a manner that a human or machine can read, process, perform, or understand for a particular purpose. • A “data resource” includes, but is not limited to, any portion of data (preferably electronic or digital), such as one or more files, documents, videos, or other electronically / digitally delivered content. This term may be used to include a single content item or multiple data items that can collectively be viewed as a single entity / resource. Furthermore, a single data resource may be owned and / or managed by one or more data administrators. • A “Data Controller” refers to any entity or group of entities that manages and / or authorizes a data resource. A Data Controller may be the creator or owner of the data resource or any part thereof, or may be authorized by such party or its agent to access and / or control access to the data resource. A Data Controller may consist of multiple entities or subordinate entities; for example, multiple organizations, individuals, or entities may share management / ownership of a data resource. In some cases, when multiple parties form a Data Controller, a signature threshold may apply. For example, an action may require, for example, n signatures or approvals out of m for it to be considered authorized by the Data Controller. For convenience, the Data Controller may be referred to as “Alice” here. "Acquisition" means any means of possessing any entity, including generating, calculating, selecting, or receiving from one or more sources. • In this book, the terms “validation” and “verification” (and the corresponding “validator / verifier”) may be used interchangeably. "Processing" includes, but is not limited to, one or more of the following: generation, storage, transmission (via electronic network), and transfer. "Blockchain" refers to any form of distributed ledger, regardless of the implementation, network, protocol, possible type of cryptocurrency, whether private or public, and whether it uses proof-of-work, proof-of-stake, or other types of consensus mechanisms. As used herein, “Bitcoin” is intended to include all protocols and implementations that are derived from or deviate from the original protocol defined by Satoshi Nakamoto in the Bitcoin white paper, “Bitcoin: A Peer-to-Peer Electronic Cash System” (2008). For convenience, the Bitcoin blockchain may be referred to as the most widely known. However, embodiments of this disclosure are not limited to this, and other blockchain protocols and implementations, whether derived from the original Bitcoin protocol or not, are also included in the scope of this disclosure.

[0095] Listed clauses of the illustrated embodiments It will be understood that the embodiments described above are illustrative only. More generally, methods, apparatus, or programs are provided according to one or more of the following descriptions.

[0096] The features provided in this section with respect to a particular set of clauses, embodiments, or aspects may be used or incorporated in respect to any other set of clauses, embodiments, or aspects, and are not limited thereto.

[0097] Embodiments of this disclosure provide computer implementation systems and methods. In addition, or alternatively, they can provide methods and systems for one or more of the following: data security, editing of electronic data, access control (by encryption) to (preferably digital) data resources or at least a portion thereof, editing of (preferably digital) data resources, secure communication / distribution of (preferably digital) data resources, and selective access control to (preferably digital) data resources.

[0098] In addition, or alternatively, embodiments of the present disclosure may provide one or more of the following: • Improved digital signature algorithm • Improvement of smart contract solutions • An improved solution for obtaining or providing forms, templates, or data resources for one or more users to fill out. Input may include providing a signature (digital, encrypted, or otherwise) and / or providing one or more pieces of data. An edited version of the data resource is provided, and users can replace, change, modify, or otherwise process the edited portion by providing answers or input. Thus, the edited portion may function as a placeholder for one or more users to fill out.

[0099] Embodiments are provided substantially with respect to the systems and methods described herein, in particular to the section “Templates and Forms”.

[0100] Technical benefits derived from the embodiments include, but are not limited to, protection or enhancement of privacy and / or anonymity, data security, improved selective sharing of data, and improved verification of the reliability and / or integrity of data resources.

[0101] In one form of expression, the embodiment can be described as including a computer implementation method that includes the following: Sharing and / or providing at least one segment of a data resource that includes multiple segments, To facilitate or perform validation of data resources using a Merkle tree that includes the hashes of each of multiple segments as leaf nodes.

[0102] Data resource validation may include validation of authenticity, ownership, origin, completeness, and / or provenance-related data regarding the data resource.

[0103] In addition, or alternatively, according to another form of expression, the embodiment is: To obtain (e.g., generate) a Merkle tree of the first version of a digital resource containing multiple segments, where the (leaf) nodes of the Merkle tree contain the hashes of each of the multiple segments. Signing the root of the Merkle tree, Verifying the first and / or second versions of a digital resource using the signed Merkle tree root. It can be described as including a computer implementation method that includes this.

[0104] Those skilled in the art will understand that all tree structures, including Merkle trees, consist of a root. Therefore, the term "root" in the above definition does not require any prior relationship.

[0105] The first version may be the unedited and / or original version of the data resource. The second version is an edited version of the data resource in which one or more parts / segments / elements of the first version are omitted, replaced, and / or modified in some way compared to the original state. The second version may be provided or obtained by selecting sub-parts of multiple segments (i.e., parts of multiple segments excluding at least one segment).

[0106] A digitally signed message may contain one or more additional data items. Digital signatures may be generated using keys owned, controlled, or operated by the administrator / owner of the data resource.

[0107] Signing a root may involve signing a message that contains the root or its hash. A root may be signed by one or more administrators / owners / managers of a data resource.

[0108] The verification of the first and / or second versions of a digital resource may include one or more of the “verification / validation” process steps disclosed herein. This may include one or more of the following: • Verify that the key, digital signature, and message match. • Verify that the calculated Merkle route matches the version and / or signed message provided by the data administrator. • Access one or more (minimum editable) segments / elements of a data resource. • Hash at least one minimum editable element (segment). • Calculate the route using the provided Merkle path elements. Provide or retrieve one or more Merkle paths to an unedited resource segment (i.e., the minimum number of additional nodes in the tree required to compute the root hash, starting from a specific leaf).

[0109] In addition, or alternatively, according to another form of expression, the embodiment is: A step of providing or obtaining the root of a Merkle tree representing at least one data resource, wherein each segment of the at least one data resource is provided as the respective leaf of the Merkle tree, Steps to easily verify or perform the verification of an edited version of at least one data resource using a signed message that includes the root of the Merkle tree. It can be described as including a computer implementation method that includes this.

[0110] In addition, or alternatively, according to another form of expression, the embodiment is: A step of providing a computer implementation configuration for verifying an edited subset of a data resource, and / or This includes steps to validate or facilitate validation of an edited subset of a data resource. It can be described as including a computer implementation method.

[0111] This method can be combined with one or more of the features / steps disclosed herein. "Part" may be replaced with "Segment."

[0112] In addition, or alternatively, according to another form of expression, the embodiment is transmitted from the sender (e.g., data controller) or its agent to the recipient (e.g., data verifier), An edited version of a data resource containing multiple segments (where the data resource has been edited relative to the original (first / initial) state of the data resource, in that at least one of the multiple segments has been edited), The edited segment or the hash of each segment, and / or The computer implementation method is described as including the step of providing the original version of the Merkle tree of the data resources, and the Merkle tree is i) (Leaf) nodes containing the hashes of each of the multiple segments of the original version of the data resource, and / or ii) Including roots signed by or on behalf of the data administrator.

[0113] Editing at least one segment may include omitting, replacing, or modifying that segment from the edited version.

[0114] In addition, or alternatively, according to another form of expression, the embodiment allows the recipient (e.g., a data verifier) ​​to receive from the sender (e.g., a data controller or a data controller's agent), An edited version of a data resource containing multiple segments, where the data resource has been edited relative to its original (initial / initial) state, in which at least one of the multiple segments has been edited. The edited segment or the hash of each segment, and / or Original version of the Merkle tree for data resources The computer implementation method is described as including the step of receiving, and the Merkle tree is i) (Leaf) nodes containing the hashes of each of the multiple segments of the original version of the data resource, and / or ii) Including roots signed by or on behalf of the data administrator.

[0115] This delicious, The steps include: constructing a new instance of the Merkle tree of the original version of the data resource using the edited version of the data resource and the hash of at least one edited segment, either by the recipient or on behalf of the recipient; The steps include comparing the root of the new instance of the Merkle tree in the original version of the data resource with the root of the Merkle tree provided by the sender, Steps to verify the digital signature of the Merkle tree root provided by the sender. The step of verifying the digital signature of the Merkle tree root provided by the sender may include one or more steps of determining whether the signature of the provided Merkle root was generated using or derived from an encryption key known to be associated with the data controller.

[0116] The step of constructing a new instance of the Merkle tree for the original version of a data resource can be performed by combining the edited version of the data resource with the edited segments or the hashes of each segment. The Merkle tree can be constructed using known techniques to hash pairs and derive the root of the entire data resource. This step involves inserting the hash values ​​of the edited segments, or each hash value, into the edited data resource, and / or replacing the edited segments in the edited data resource with the hash values ​​of the edited segments, or each hash value. In other words, a new instance of the Merkle tree can be constructed by replacing the edited segments with their respective hash values.

[0117] The edited version of the data resource is: - If it is confirmed or verified that the signed Merkle root digital signature was generated using or derived from an encryption key known to be associated with the data controller, and / or - If the root of a new instance of the Merkle tree (built by the recipient) matches the signed root of the Merkle tree (provided by the sender), Verified and / or considered legitimate.

[0118] In addition, or alternatively, according to another form of expression, the embodiment can be described as a method for verifying an edited version of a data resource from a source. A signed root of a Merkle tree representing the original version of a data resource containing multiple segments (each leaf in the tree contains the hash of its respective segment, and the signed root contains, or is associated with, a digital signature associated with the authorized entity of the data resource), The hash of at least one segment of multiple segments and This includes the step of obtaining [something].

[0119] This method further, Steps to obtain the Merkle path and / or edited version of the data resource from the source, Steps to verify the edited version of the data resource, Steps to display or identify one or more segments from multiple edited segments. It may include one or more of these steps.

[0120] In addition, or alternatively, according to another form of expression, the embodiment is: i) A Merkle tree representing at least one data resource, wherein each of the multiple segments of the at least one data resource is provided as a leaf of the Merkle tree, and the Merkle tree includes a signed Merkle root that is signed by or on behalf of at least one authoritative entity or managing entity, ii) An edited version of at least one data resource, wherein the edited version includes a subset of multiple segments, iii) The hash of each segment in a subset of multiple segments and This can be described as a computer implementation method that includes the step of providing or obtaining [something].

[0121] The steps of providing and / or receiving may be performed by nodes on a computer network. The providing step may be performed by at least one (first) sending node / computing resource, and the receiving step may be performed by at least one (second) receiving node / computing resource.

[0122] Clause Set 1: Clause 1.1. A step of providing or obtaining the root of a Merkle tree representing at least one data resource, wherein each of a plurality of segments of the at least one data resource is provided as the respective leaf of the Merkle tree. The steps include: verifying the edited version of at least one data resource using the Merkle root signed version; and Computer implementation methods including

[0123] Clause 1.2. Merkleroot must be signed by at least one authorized entity or managing entity, or by their proxy, and / or The method described in Clause 1, wherein the edited version of at least one data resource contains a subset of multiple segments.

[0124] Clause 1.3. Steps to select, specify, or define multiple and / or subsets of multiple segments of at least one data resource, Steps to select at least one segment for editing from a data resource and obtain a subset of multiple segments. The method described in Clause 2, which includes one or more of the following.

[0125] Clause 1.4. At least one recipient, i) An edited version of at least one data resource, ii) Digitally signed messages, ii) A digitally signed copy of Merkleroot, iii) Merkle proofs derived from Merkle trees, iv) The hash of at least one segment of the data resource, v) Additional data The method described in Clause 2 or 3, which includes the step of providing one or more of the following.

[0126] Clause 1.5. The method described in any of the preceding Clauses, wherein an edited version of at least one data resource includes or provides a template, form, or other resource for completion or input by one or more users.

[0127] Clause 1.6 i) The data resource includes a contract and / or, ii) A computer program is provided in relation to at least one data resource, and the computer program operates to control or influence the use of the data resource, and / or iii) At least one segment of at least one data resource includes, or functions as, a watermark, version identifier, authentication code, or security mechanism, configured to enable verification of the authenticity, completeness, origin, or legitimacy of the data resource. The method described in any of the preceding clauses.

[0128] Article 1.7. The steps include hashing one, some, or each of the segments within multiple segments, Steps to obtain a Merkle tree using multiple segments, Steps to perform or facilitate validation of an edited version of at least one data resource, and one or more of the following: a) A step of performing a comparison operation on one or more of the acquired encryption keys, digital signatures, and / or messages, or using them, to determine whether there is a match with the corresponding computed encryption key, digital signature, and / or message; b) A step to check whether the obtained Merkle root matches the calculated Merkle root, c) A step of accessing at least one segment of multiple segments, or processing at least one segment of multiple segments, d) The step of hashing at least one segment of multiple segments, e) A method of any of the preceding clauses, comprising the step of calculating a Merkle root using one or more Merkle path components.

[0129] Clause 1.8. The sender further provides at least one recipient with an edited version of at least one data resource, Optionally, the step of providing an edited version includes the method of any of the preceding clauses, which includes the step of generating a shared secret between the sender and at least one recipient.

[0130] Clause 1.9. A method comprising the step of providing a computer-based system that outputs an edited version of at least one data resource, wherein the system optionally... Cloud-based services or executable resources Internet-based services or resources Software applications configured to run on mobile, portable, or desktop-based systems. Digital wallet, browser, Word processing application or PDF / document viewer, Software for providing audio and / or video output, Electronic computer-based storage resources, Software for scanning, copying, or capturing images of resources. Software for generating digital signatures, and / or software for binding digital signatures to a portion of data. Software and / or hardware for executing or facilitating financial transactions and / or asset exchanges, Cryptocurrency platform A method of any of the preceding clauses, including one or more of the following.

[0131] Clause 1.10. From the source, the root of a Merkle tree representing a data resource containing multiple segments, where each leaf of the tree contains the hash of its respective segment, The hash of at least one segment among multiple segments, Merklepath and, Digital signature associated with an authorized entity of at least one data resource and A method for validating an edited document, including the steps to obtain it.

[0132] Article 1.11. Memory including one or more memory units, Apparatus including one or more processing units A computer system comprising: memory for storing or executing code configured to run on a processing unit; and code configured to run on the processing unit in any of the manner described in clauses 1 to 10.

[0133] Clause 1.12. Storage or file system, optionally, the file system is a VAST file system, database, Components that operate to interact with blockchain networks and / or blockchain ledgers. A computer system as described in Clause 1.11, further comprising one or more of the following:

[0134] Clause 1.13. A computer program implemented in computer-readable storage and configured to perform any of the methods described in Clauses 1.1 through 1.10 when executed on one or more processors.

[0135] Clause Set 2: Clause 2.1. According to the exemplary Clause Set 2, a method is provided, and the method is, A step of obtaining (e.g., generating) a Merkle tree of a first version of a digital resource containing multiple segments, wherein one, some, or all (leaf) nodes in the Merkle tree contain the hashes of each of the multiple segments, Steps to sign the root of the Merkle tree, This includes the step of verifying the first and / or second versions of a digital resource using a signed Merkle tree root. The second version may be called the edited version of the data resource. It may consist of at least one fewer segment than the first version.

[0136] Clause 2.2. i) A step of verifying the authenticity and / or completeness of the first or second version of the digital resource using a digitally signed Merkle tree, ii) The step of providing the recipient with a second version of the digital resource, which includes a subset of multiple segments, from the source. The method described in Clause 2.1, further including one or more of the following. The term "subset" can mean "one or more fewer" than the original set / number.

[0137] Clause 2.3. The method described in Clause 2.1 or 2.2, wherein the step of verifying the authenticity and / or completeness of a first or second version of a digital resource includes the step of verifying a digital signature applied to at least one or more hashes of the root and / or multiple segments of a Merkle tree (in a message containing them).

[0138] Clause 2.4. i) The step of hashing multiple segments to provide each node of the Merkle tree, ii) A method of any of the preceding clauses of Clause Set 2, comprising the step of selecting a subset of multiple segments.

[0139] A method according to either Clause Set 1 or 2, • The first (i.e., unedited / original) version of the data resource has N segments. • Multiple N segments are hashed to provide each (leaf) node in the Merkle tree. • The Merkle tree has a root signed by an authorized party, for example, at least one data controller / owner or their representative. • Signing is performed via any electronic / cryptographic means using a key generated with a common secret, at the discretion of the signatory. The step of providing a Merkle tree involves hashing each of the N segments to provide each (leaf) node in the Merkle tree. • Display or present an edited version of the data, i.e., output multiple segments excluding x selected edited segments (x=>=1). The (nx) segments to be shared each have a preimage of the hash of each (nx) segment. • Steps to share replacement segments for edited segments (from the same entity (e.g., Alice) or to the same entity (e.g., Bob)), Select x segments to exclude from the shared step. Verification involves hashing some or preferably all of the n segments and comparing each hash to the corresponding node in the Merkle tree.

[0140] "Sharing" refers to any method of making something available. This includes, but is not limited to, sending, transmitting, displaying, outputting, or providing access by means of download by a user.

[0141] Clause Set 3: Clause 3.1 A computer implementation method that includes inserting or providing at least one identifier / code / watermark / timestamp / reference in at least one segment within multiple segments of a data resource.

[0142] Multiple segments may be processed according to any of the disclosed embodiments. For example, this method may include one or more of the following: - Steps to define, select, calculate, or retrieve multiple segments of a data resource. - Steps to hash multiple segments, - A step of obtaining a Merkle tree representing a data resource, wherein the hash of a segment provides the leaves of the tree. - Steps to sign the root of the Merkle tree (and / or messages containing the root), - In the step of selecting one or more segments for editing, those segments are designated as "not shareable" and excluded from the sharing operation. - A step to share one or more unedited segments (i.e., segments designated as "permitted or allowed" to be shared) with at least one recipient from among multiple segments. - A step of sharing with at least one recipient one or more of the public key associated with the private key used to sign the root, the signed Merkle root, and the Merkle path / hash, to enable verification of an unedited segment by the calculation of one or more Merkle certificates by at least one recipient; and a step of comparing the calculated root with the retrieved / shared root and using the public key to verify that the signature and Merkle root calculated by the recipient match the Merkle root and signature retrieved from the sharer / sender.

[0143] Codes, identifiers, and / or watermarks may be inserted into one or more edited segments and / or unedited segments. Codes, identifiers, and / or watermarks may indicate or include data or other data that uniquely proves the authenticity, source, version, or ownership of a data resource.

[0144] In another aspect disclosed herein, a system is provided which comprises computer equipment claimed or described herein and / or capable of performing any method disclosed herein.

[0145] Example of a system overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0146] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0147] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0148] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0149] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0150] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0151] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0152] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0153] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool.” In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0154] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0155] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0156] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0157] Any given blockchain node can be configured to perform one or more of the following actions: verifying transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, nodes can specialize in specific actions. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0158] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0159] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0160] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0161] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0162] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0163] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it will be understood that this is not limited.

[0164] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0165] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by the nodes of that network and is constantly updated. In such a system, transactions are ordered using the account’s transaction execution record (also called a “position”). This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0166] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0167] 2. UTXO base model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0168] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0169] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0170] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0171] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

[0172] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it might include Bob's signature. The unlock script appears in transaction input 202.

[0173] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A ] is the public key P from Alice's public key-private key pair. AThe input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A > comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0174] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0175] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0176] Typically, the input to a transaction is the public key P. A This includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0177] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0178] Appendix Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0179] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0180] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the preferred Bitcoin network 106).

[0181] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0182] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104.

[0183] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator. References to “Bitcoin,” “cryptocurrency,” or specific cryptocurrency protocols in this specification and accompanying diagrams may be replaced with the terms “blockchain,” “blockchain network,” or “blockchain protocol,” depending on the specific context in which these terms are used.

[0184] Disclaimer Incorporation by reference of the above documents is limited so as not to include subject matter contrary to the express disclosure of this Spec. Incorporation by reference of the above documents is further limited so as not to include claims contained in such documents. Incorporation by reference of the above documents is further limited so as not to include definitions contained in such documents unless expressly stated herein. [Explanation of symbols]

[0185] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output

Claims

1. i) A Merkle tree representing at least one data resource, wherein each of a plurality of segments of the at least one data resource is provided as a leaf of the Merkle tree, ii) A signed Merkle root for the Merkle tree, wherein the Merkle root is signed by or on behalf of at least one authorized entity or managing entity, ii) An edited version of the at least one data resource, wherein the edited version includes a subset of the plurality of segments, iii) The hash of each segment within the subset of the plurality of segments and A method performed on a computer, comprising the steps of providing or obtaining.

2. The above method further, A step of using the signed Merkle root to perform or facilitate the verification of an edited version of the at least one data resource, and / or Steps to construct the original version of the Merkle tree of the at least one data resource, using the hash of each segment within the subset of the plurality of segments and the edited version of the at least one data resource. The method according to claim 1, comprising:

3. A step of selecting, specifying, or defining multiple and / or subsets of the multiple segments of the at least one data resource, To obtain the subset of the plurality of segments, the step of selecting at least one segment for editing from the data resource. The method according to claim 2, comprising one or more of the above.

4. To at least one recipient, i) The edited version of the at least one data resource, ii) Digitally signed messages, ii) A digitally signed copy of the aforementioned Merkleroot, iii) Merkle proof derived from the Merkle tree, iv) The hash of at least one segment of the plurality of segments of the data resource, v) Additional data The method according to claim 2 or 3, comprising the step of providing one or more of the following.

5. The method according to any one of claims 1 to 4, wherein the edited version of the at least one data resource includes or provides a template, form, or other resource for completion or input by one or more users.

6. i) The data resource includes a contract and / or ii) A computer program is provided in relation to the at least one data resource, and the computer program operates to control or influence the use of the data resource, and / or iii) At least one segment of the at least one data resource includes, or functions as, a watermark, a version identifier, an authentication code, or a security mechanism, configured to enable verification of the authenticity, completeness, origin, or legitimacy of the data resource. The method according to any one of claims 1 to 5.

7. The step of hashing one, some, or each of the segments within the plurality of segments, A step of obtaining the Merkle tree using the plurality of segments, and A step of performing or facilitating the verification of the edited version of the at least one data resource, a) A step of performing a comparison operation to determine whether there is a match between one or more of the obtained encryption keys, digital signatures, and / or messages, or using one or more of the obtained encryption keys, digital signatures, and / or messages, and the corresponding calculated encryption key, digital signature, and / or message. b) A step to check whether the obtained Merkle root matches the calculated Merkle root, c) Accessing or processing at least one segment of the plurality of segments, d) The step of hashing at least one segment of the plurality of segments, e) A step of calculating the Merkle route using one or more Merkle path components, Steps including one or more of the following: The method according to any one of claims 1 to 6, comprising one or more of the above.

8. The process further comprises the step of the sender providing the edited version of the at least one data resource to at least one recipient, The method according to any one of claims 1 to 7, wherein the step of providing the edited version optionally includes the step of generating a shared secret between the sender and the at least one recipient.

9. A method comprising the step of providing a computer-based system that outputs the edited version of the at least one data resource, Optionally, the system may be: Cloud-based services or executable resources Internet-based services or resources Software applications configured to run on mobile, portable, or desktop-based systems. Digital wallet, browser, Word processing application or PDF / document viewer, Software for providing audio and / or video output, Electronic computer-based storage resources, Software for scanning, copying, or capturing images of resources. Software for generating electronic signatures, and / or software for binding said electronic signatures to a portion of data, Software and / or hardware for executing or facilitating financial transactions and / or asset exchanges, Cryptocurrency platform The method according to any one of claims 1 to 8, comprising one or more of the above.

10. A method for verifying an edited version of a data resource, from the source, A signed root of a Merkle tree representing the original version of the data resource, which includes multiple segments, wherein each leaf in the Merkle tree includes a hash of its respective segment, and the signed root includes a digital signature associated with or associated with an authorized entity of the data resource, The hash of at least one segment of the plurality of segments and A method that includes the steps to obtain.

11. From the aforementioned information source, the step of obtaining the Merkle path and / or edited version of the data resource, A step of verifying the edited version of the data resource, Steps to obtain the display or identification of one or more segments from the edited plurality of segments. The method according to claim 10, further comprising one or more of the steps.

12. The method according to any one of claims 1 to 11, further comprising the step of providing at least one code, identifier, version data, key, timestamp, and / or watermark to at least one segment of the plurality of segments of the data resource.

13. A step of providing a computer implementation configuration for verifying an edited subset of a data resource, and / or A step to validate an edited subset of a data resource, or to facilitate validation. A computer implementation method comprising the above.

14. Memory including one or more memory units, A computer system comprising a processing unit including one or more processing units, A computer system wherein the memory stores or executes code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 12.

15. The aforementioned computer system A storage or file system, preferably the file system is a VAST file system, database, Components that operate to interact with blockchain networks and / or blockchain ledgers. The computer system according to claim 14, further comprising one or more of the above.

16. A computer program, which is implemented on computer-readable storage, and which, when executed on one or more processors, is configured to perform the method described in any one of claims 1 to 12.

Images