Document editing and coordination

Abstract

The present invention relates to document redaction and coordination. Exemplary operations may include one or more of the following: receiving, by a document server, a document from a document owner node, the document containing restricted access fragments; segmenting, by the document server, the document into a plurality of ledger entries to be stored on a blockchain, updating, by the document server, a ledger entry of the plurality of ledger entries based on proposed changes to the document made by authorized participant nodes, submitting, by the document server, the ledger entry to the blockchain based on votes collected from a plurality of participant nodes, and sending a notification to a set of participant nodes of the plurality of participant nodes that are authorized to view the document.

Description

Technical Field

[0001] The present application relates generally to systems for database storage and, more particularly, to redaction and coordination. Background Art

[0002] A centralized database stores and maintains data in a single database in one location, such as a database server. This location is usually a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe. Information stored in a centralized database can usually be accessed from multiple different points. For example, multiple users or client workstations can work simultaneously on a centralized database based on a client / server configuration. Centralized databases are easy to manage, maintain, and control due to their single location, and are particularly suitable for security needs. In a centralized database, data redundancy is minimized because the single storage location for all data also means that there is only one master record for a given data set.

[0003] However, centralized databases have significant drawbacks. For example, centralized databases have a single point of failure. In particular, if fault tolerance is not considered and a hardware failure occurs (e.g., hardware, firmware, and / or software failure), all data in the database will be lost and the work of all users will be interrupted. In addition, centralized databases are highly dependent on network connections. Therefore, the slower the connection, the longer each database access takes. Another disadvantage is that bottlenecks occur when centralized databases experience high traffic due to a single location. In addition, centralized databases provide limited access to data because the database maintains only one copy of the data. Therefore, multiple devices cannot access the same data block at the same time without causing serious problems or risking overwriting the stored data. In addition, because the database storage system has minimal or even no data redundancy, accidentally lost data is difficult to retrieve unless it is retrieved from backup storage through manual operations.

[0004] Therefore, there is a need for a blockchain-based solution that overcomes these shortcomings and limitations. Blockchain can be used for secure document sharing. Sometimes only a portion of a document needs to be securely shared for editing or review, while other portions of the document must remain confidential because they contain sensitive information. In addition, sometimes it may be necessary to redact certain portions of a shared document. For example, there are regulations such as HIPPA, GDPR, PCI, where certain information (such as social security numbers, credit card numbers, and other personally identifiable data) may need to be redacted to comply with standards. This complicates daily business transactions because it limits the exchange of documents. For example, an electronic document may contain PHI (personal health information) and may need to be sent to a contracted vendor to extract billing codes (or other processing). An organization may not want to disclose PHI to contractors. Therefore, a redacted version of a document can be shared for determining / annotating billing codes without disclosing PHI.

[0005] While existing solutions can create a version of the original document for sharing, changes to the derived document may not be easily reconciled with the original document. Existing solutions often encrypt file contents as an afterthought or additional security measure, which makes the files vulnerable to human error. Encryption is built-in as part of the blockchain design. And, in the blockchain network, only encrypted content is stored.

[0006] Therefore, it is desirable to have a blockchain-based solution for the redaction and reconciliation of documents. Summary of the invention

[0007] An exemplary embodiment provides a system including a processor and a memory, wherein the processor is configured to perform one or more of the following: receiving a document from a document owner node, the document including a restricted-access segment, segmenting the document into a plurality of ledger entries to be stored on a blockchain, updating a ledger entry of the plurality of ledger entries based on a proposed change to the document made by an authorized participant node, submitting the ledger entry to the blockchain based on votes collected from the plurality of participant nodes, and sending a notification to a set of participant nodes of the plurality of participant nodes that are authorized to view the document.

[0008] Another exemplary embodiment provides a system including a processor and a memory, wherein the processor is configured to perform one or more of the following: segmenting a document provided by a document owner node into a plurality of fragments to be stored on a ledger of a blockchain, detecting changes made to the document by authorized participant nodes, updating a fragment of the plurality of fragments stored on the ledger based on the changes to the document, collecting votes on the changes to the document from a plurality of participant nodes, and submitting the updated fragment to the blockchain based on the votes.

[0009] Another example embodiment provides a method comprising one or more of: receiving, by a document server from a document owner node, a document, the document comprising restricted-access fragments, segmenting, by the document server, the document into a plurality of ledger entries to be stored on a blockchain, updating, by the document server, a ledger entry of the plurality of ledger entries based on a proposed change to the document made by an authorized participant node, submitting, by the document server, the ledger entry to the blockchain based on votes collected from the plurality of participant nodes, and sending a notification to a set of participant nodes of the plurality of participant nodes that are authorized to view the document.

[0010] Another exemplary embodiment provides a method comprising one or more of: segmenting, by a document server, a document provided by a document owner node into a plurality of fragments to be stored on a ledger of a blockchain, detecting, by the document server, changes made to the document by authorized participant nodes, updating, by the document server, a fragment of the plurality of fragments stored on the ledger based on the changes to the document, collecting, by the document server, votes on the document changes from a plurality of participant nodes, and submitting, based on the votes, the updated fragment to the blockchain.

[0011] Another exemplary embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving a document from a document owner node, the document comprising a restricted access segment; segmenting the document into a plurality of ledger entries to be stored on a blockchain, updating a ledger entry of the plurality of ledger entries based on a proposed change to the document made by an authorized participant node, submitting the ledger entry to the blockchain based on votes collected from the plurality of participant nodes, and sending a notification to a set of participant nodes of the plurality of participant nodes that are authorized to view the document.

[0012] Another exemplary embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following: segmenting a document provided by a document owner node into a plurality of fragments to be stored on a ledger of a blockchain, detecting changes to the document made by authorized participant nodes, updating a fragment of the plurality of fragments stored on the ledger based on the changes to the document, collecting votes on the changes to the document from a plurality of participant nodes, and submitting the updated fragment to the blockchain based on the votes. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A A network diagram showing a system including a database according to an exemplary embodiment;

[0014] Figure 1B A network diagram showing a system including a database according to an exemplary embodiment;

[0015] Figure 2A An example blockchain architecture configuration is shown in accordance with an exemplary embodiment;

[0016] Figure 2B illustrates a blockchain transaction flow according to an exemplary embodiment;

[0017] Figure 3A illustrates a permission network according to an exemplary embodiment;

[0018] Figure 3B Another permission network according to an exemplary embodiment is shown;

[0019] Figure 4A A flow chart according to an exemplary embodiment is shown;

[0020] Figure 4B Another flow chart according to an exemplary embodiment is shown;

[0021] Figure 4C A flow chart according to an exemplary embodiment is shown;

[0022] Figure 4D Another flow chart according to an exemplary embodiment is shown;

[0023] Figure 5A An example system configured to perform one or more operations described herein is shown in accordance with an embodiment;

[0024] Figure 5B Another example system configured to perform one or more operations described herein is shown in accordance with an embodiment;

[0025] Figure 5C Another example system configured to use smart contracts according to an embodiment is shown;

[0026] Figure 5D Another example system configured to use blockchain according to an exemplary embodiment is shown;

[0027] Fig. 6A illustrates a process of adding a new block to a distributed ledger according to an exemplary embodiment;

[0028] Figure 6B showing the contents of a new data block according to an exemplary embodiment;

[0029] Figure 6C A blockchain illustrating digital content according to an exemplary embodiment;

[0030] Fig.6D A block showing a structure that may represent a block in a blockchain according to an exemplary embodiment; and

[0031] Figure 7 An example system is shown that supports one or more exemplary embodiments. DETAILED DESCRIPTION

[0032] It is readily understood that the components generally described and illustrated in the figures herein may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, devices, non-transitory computer-readable media, and systems as shown in the figures is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0033] The features, structures, or characteristics described throughout the specification may be combined or removed in any suitable manner in one or more embodiments. For example, the use of the phrases "exemplary embodiments," "some embodiments," or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment. Therefore, the phrases "exemplary embodiments," "in some embodiments," "in other embodiments," or other similar language appearing throughout this specification do not necessarily all refer to the same set of embodiments, and the described features, structures, and characteristics may be combined or removed in any suitable manner in one or more embodiments.

[0034] In addition, although the term "message" may have been used in the description of the embodiment, the application can be applied to many types of networks and data. In addition, although certain types of connections, messages and signaling can be described in exemplary embodiments, the application is not limited to certain types of connections, messages and signaling.

[0035] Exemplary embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks for redaction and coordination of documents.

[0036] In one embodiment of the present application, a decentralized database (such as blockchain) is used, which is a distributed storage system including multiple nodes that communicate with each other. The decentralized database includes a data structure that can only be appended but not changed, similar to a distributed ledger that can maintain records between untrusted parties. Untrusted parties are referred to as peers or peer nodes in this article. Each peer maintains a copy of the database record, and a single peer cannot modify the database record without reaching a consensus between distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. The process forms a ledger by sorting storage transactions as needed to maintain consistency. In various embodiments, a licensed and / or unlicensed blockchain can be used. In a public or unlicensed blockchain, anyone can participate without a specific identity. Public blockchains typically involve local cryptocurrencies, using consensus based on various protocols such as proof of work (PoW). On the other hand, permissioned blockchain databases provide secure interactions between a group of entities that have a common goal but do not fully trust each other - such as businesses exchanging funds, goods, information, etc.

[0037] The present application can utilize a blockchain that operates arbitrary programmable logic called "smart contracts" or "chaincodes" customized for decentralized storage solutions. In some cases, there may be dedicated chaincodes for managing functions and parameters, called system chaincodes. The present application can further utilize such smart contracts: they are trusted distributed applications that utilize the tamper-proof properties of the blockchain database and the underlying protocol between nodes called endorsements or endorsement policies. Blockchain transactions associated with the present application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are not considered. The endorsement policy allows the chaincode to specify endorsers in the form of a set of peer nodes required for endorsement for the transaction. When the client sends a transaction to the peer specified in the endorsement policy, the transaction is executed to verify the transaction. After verification, the transaction enters the sorting phase, in which a consensus protocol is used to generate a series of endorsed transactions arranged in order, and these endorsed transactions are grouped into blocks.

[0038] The present application may utilize nodes that are communication entities of a blockchain system. A "node" may perform a logical function, i.e., multiple nodes of different types may run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes may include different types, such as client or submitting-client nodes, which submit transaction invocations to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node that can receive transactions submitted by clients, submit transactions, and maintain the state and copy of the blockchain transaction ledger. Peers may also play the role of endorsers, although this is not required. An ordering service node or orderer is a node that runs a communication service for all nodes, which implements delivery guarantees, such as broadcasts to each peer node in the system when submitting transactions and modifying the world state of the blockchain, which is another name for the initial blockchain transaction that typically includes control and setup information.

[0039] The present application may utilize a ledger that is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions may be generated by chaincode invocations (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (e.g., peer node) may maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) for storing unchangeable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0040] The present application may use a chain of transaction logs, which is structured as hash-linked blocks, each of which contains a series of N transactions, where N is equal to or greater than 1. The block header includes the hash of the transactions of the block, as well as the hash of the header of the previous block. In this way, all transactions on the ledger can be arranged in sequence and linked together in a cryptographic manner. Therefore, it is impossible to tamper with the ledger data without destroying the hash links. The hash of the most recently added blockchain block represents every transaction on the chain that has arrived before it, which makes it possible to ensure that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0041] The current state of the immutable ledger represents the latest values ​​of all keys contained in the chain transaction log. The current state represents the latest key values ​​known to a channel, and is therefore sometimes called the world state. Chaincode invocations execute transactions against the current state data of the ledger. In order to make these chaincode interactions efficient, the latest values ​​of keys can be stored in a state database. The state database can be just an indexed view of the chain transaction log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated on demand) at peer startup and before accepting transactions.

[0042] Benefits of the solutions described and represented herein include methods and systems for redacting and reconciling documents in a blockchain network. Exemplary embodiments address time and trust issues by extending the properties of a database such as immutability, digital signatures, and being a single source of truth. Exemplary embodiments provide a solution for redacting and reconciling documents in a blockchain-based network. The blockchain network can be homogenous based on asset types and rules for managing assets based on smart contracts.

[0043] Blockchain differs from traditional databases in that it is not a central storage, but a decentralized, immutable, secure storage, and nodes must share changes recorded in the storage. Some properties inherent in blockchain that contribute to the realization of blockchain include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc., which will be further described in this article. According to various aspects, due to the inherent and unique immutable accountability, security, privacy, permissioned decentralization, availability of smart contracts, endorsement, and accessibility of blockchain, a redaction and coordination system for documents in a blockchain network is achieved. In particular, the blockchain ledger data is immutable, which provides an effective method for redaction and coordination of documents in a blockchain network. In addition, the use of encryption in blockchain can provide security and establish trust. Smart contracts manage the status of assets to complete the life cycle. The example blockchain is permissioned and decentralized. Therefore, each end user can access his own copy of the ledger. Multiple organizations (and peers) can join the blockchain network. Key organizations can act as endorsing peers to verify smart contract execution results, read sets, and write sets. In other words, the inherent characteristics of blockchain provide conditions for the effective implementation of document editing and coordination methods.

[0044] One of the benefits of the exemplary embodiment is that it improves the functionality of a computing system by implementing a method for redaction and coordination of documents in a blockchain-based system. Through the blockchain system described herein, a computing system can also perform redaction and coordination functions of documents in a blockchain network by providing access to functions such as distributed ledgers, peers, encryption technology, MSP, event processing, etc. Blockchain also enables the creation of a business network and enables any user or organization to participate. Therefore, blockchain is more than just a database. Blockchain is able to create a business network of users and on / off-board organizations and can collaborate and execute service processes in the form of smart contracts.

[0045] Compared to traditional databases, example embodiments provide many advantages. For example, through blockchain, these embodiments provide blockchain's inherent and unique immutable accountability, security, privacy, permissioned decentralization, availability, endorsement, and accessibility of smart contracts.

[0046] At the same time, a traditional database cannot be used to implement the example embodiments because it does not bring all parties onto the business network, it does not create trusted collaboration, and it does not provide efficient storage of digital assets. Traditional databases do not provide tamper-proof storage, nor do they provide retention of stored digital assets. Therefore, the proposed method of redaction and coordination of documents in a blockchain network cannot be implemented in a traditional database.

[0047] Meanwhile, if the exemplary embodiment is implemented using a traditional database, the exemplary embodiment will suffer from unnecessary disadvantages such as search capabilities, lack of security, and slow transaction speeds. In addition, the automatic redaction and coordination method of documents in the blockchain network is simply impossible to implement.

[0048] Thus, the exemplary embodiments provide certain solutions to problems in the prior art / art of asset access management in blockchain networks.

[0049] Exemplary embodiments also change how data is stored in the block structure of the blockchain. For example, digital asset data can be securely stored in a specific part of the data block (i.e., in the header, data segment, or metadata). By storing digital asset data in the data blocks of the blockchain, the digital asset data can be attached to the immutable blockchain ledger through a hash-linked chain of blocks. In some embodiments, the data block can be different from a traditional data block in that it does not store personal data associated with the digital asset with the asset in the traditional block structure of the blockchain. By removing personal data associated with digital assets, the blockchain can provide the benefits of anonymity based on immutable accountability and security.

[0050] According to an exemplary embodiment, a system and method for processing electronic documents containing protected information are provided. The exemplary embodiment allows for secure redaction, distribution, and coordination of documents for complex situations involving multiple parties. In some cases, each party can apply different privilege levels to certain document fragments. The exemplary embodiment can create a fast and secure coordination flow. The system (i.e., the document server) according to the exemplary embodiment can accept edits from authorized users, and then the proposed changes can be sent to an approval flow (if set up by the owner). The document server can record the voting results to obtain consensus and then coordinate the differences back to the original document. Finally, the document server provides real-time update notifications to all users, including viewers of the redacted version of the document. In short, everyone works from the master document, even the redacted viewer.

[0051] In sensitive documents that require restricted access control levels (ACLs), owners can define who has access to which parts of the document and specify view (read) or edit (write) access rights for each part / segment of the document (word, sentence, paragraph, spreadsheet cell, column, row, etc.). Document owners can also define the consensus method for coordinating document edits. For example, the owner can choose the consensus to be "all voters must agree" or "a majority of voters must agree." Finally, the owner can specify voters who may accept or reject the proposed edits. After this initial setup, the owner can publish their changes to a document server (such as a cloud server). The document server then parses the document, splitting it into multiple ledger entries for blockchain storage. From this point, the blockchain enforces access to each document part so that only authorized users can gain view or edit access to the document, or can vote on each segment, as defined by the owner through an application (such as a word processing application or similar application). When an authorized editor performs a change to the document, the ledger entry for that segment is updated with the proposed change. Voters must then vote for or against the change. After voting is complete, the votes are aggregated and, when consensus is reached, the update is marked as proposed. Updates must be voted on according to the rules set by the block before the editor's changes can take effect.

[0052] In an exemplary embodiment, when the voting is complete, the results are recorded and if there are changes to the original document, all viewer nodes are notified in real time of document updates. For example, the update may be provided by a word processing application or another special application. If there is no consensus on the proposed changes, a new ledger entry is generated to reflect the rejection of the changes proposed by the editor.

[0053] According to an exemplary embodiment, security is strictly enforced using smart contracts running on a blockchain structure. In other words, security is not something to be "added" as an option to existing documents, because security is built into the entire blockchain process. The document server marks the document as fragments and stores the fragments in a blockchain ledger entry that provides a fine-grained access control level. The document server creates a single source of truth, regardless of the user's access control level, thus eliminating multiple copies of the same document. Unauthorized users do not have to see the entire document to make changes to a certain part. The configuration of consensus rules can be implemented at the fragment level. Consensus is reached through smart contracts on the blockchain structure. The document server connected to the blockchain provides an end-to-end solution, that is, the redaction, distribution, and coordination of documents can be seamlessly performed entirely within the encrypted space defined by the smart contract on the blockchain structure. According to an exemplary embodiment, CRUD (Create, Read, Update, and Delete) operations can be enabled for documents that are completely within the encrypted space, so that the unencrypted version of the document is never stored on the client's disk. The document server can provide real-time update notifications to all users, including viewers of the redacted version of the document.

[0054] According to an exemplary embodiment, a user can create a new document in a word processing application. This user becomes the document owner. The initial file can be called a seed file and is the source of truth. The owner is given full rights to write and restrict access to the seed document. The word processing application (or other applications that can generate seed documents) can be connected to a document server (such as a cloud server) using CRUD-based calls. The document server can manage the document life cycle, such as rendering, editing, and voting on changes. The document owner can decide to safely allow others to view or edit parts (i.e., fragments) of the document. The owner can then select a part of the document and can assign access levels to the part together with authorized users. For example, the document owner can highlight the fragment "dolor sit amet" to the user Mary text and restrict access to the fragment. The result can be the fragment that the user John wants to edit. The owner can then highlight the word "labore" to authorize the editing access rights of the user Mary. The document owner can (optionally) define and select a method for reaching consensus at this time and can specify which participants are to vote to approve Mary's changes. In addition, viewing, editing or voting permissions may have an expiration date. The document owner can publish their changes (i.e. either create a new document or modify an existing one) to the document server. The document server can split the document into separate transactions in a way that is compatible with the chosen blockchain technology in the implementation (Hyperledger, Ethereum, etc.). The document server can then submit the transaction that updates the blockchain ledger.

[0055] In one embodiment, parsing and splitting of seed documents may be accomplished using a parent-child data model that defines master components and subcomponents. The following three ledger entry categories may be used:

[0056] (1) Master Document Record (MDR);

[0057] (2) sub-records; and

[0058] (3) Access Control List (ACL).

[0059] The concepts of participants, assets, and transactions can be used. The MDR contains references to sub-records and access control lists (ACLs). These components are based on specifications generated by the document server. Each sub-record represents a fragment edited for a different participant. The ACL document contains permissions for each sub-document specified. For example, a transaction may indicate that only Oscar and Mary can write to the sub-record with a document identifier (id) of "z". The MDR may also contain information about how to assemble sub-elements so that a word processing application (or similar client application) can present the final document view. This allows the user to recreate a version of the seed document that contains user-specific viewing, editing, and voting privileges. For example, the MDR may display the following sub-elements: [['x', 0], ['y', 0], ['x', 1], ['z', 0], ['x', 2]], where the first value pair (['x', 0]) decodes as follows: 'x' is the sub-document id, and the second value "0" is the value index of the sub-document. The value pair (['x', 0]) indicates which fragment of the subdocument to render. Note that there may be multiple fragments stored in a subrecord. The MDR may contain document rendering logic. For example, an MDR subdocument may be rendered by first retrieving a pair ['x', 0], where the subdocument is 'x' and the value index is 0. The document server may evaluate the ACL (sent in a transaction) and then retrieve document X (sent in another transaction). Documents may be retrieved by directly retrieving the corresponding block or by reading a world state database. For example, document 'x', index 0 has the value "Lorem ipsum". Therefore, that fragment needs to be rendered first. The next element to be rendered is ['y', 0]. The above process may be repeated until all subelements listed in the MDR have been evaluated.

[0060] In one example, a sub-record 'z' may require approval from the document owner or from Paul and Peter for the proposed changes. Once approved, the changes can be reflected to subscribing users. In one embodiment, each ledger entry may include a creation and update timestamp and a version number. The sub-record may include other metadata, such as PCI-type data. A sub-record may reference another sub-record and / or an object located at another source (e.g., off-blockchain storage). This can be used to embed large data such as video files. A client application (e.g., a word processing application) can subscribe to a document server (e.g., a cloud server) to receive real-time updates about document changes. In one embodiment, a read-only user may not receive notifications about proposed changes, but may only receive notifications about submitted / voted changes. The subscription mechanism may be implemented using WebSockets and queues (RabbitMQ, Kafka) or other equivalent technologies. This may allow simultaneous editing of documents and instant notification of conflicting changes made by two users to a certain text fragment. In another embodiment, the document may be, for example, an MS-EXCEL spreadsheet, an MS-Visio or MS-EXCEL document, a vector graphic, or a layer-based computer-aided design (CAD) document. This could, for example, allow the blueprints of a building (or city) to be shared with contractors as needed without revealing sensitive information about the entire infrastructure. In another embodiment, a Hyperledger Composer solution could be used.

[0061] In an exemplary embodiment, the client application can accept an ID card as input. The client application can use the REST API exposed for the contract and can aggregate documents for each participant accordingly based on the roles and access controls defined for the participants. Additional security can be achieved through mechanisms such as forcing the ID card to be logged into the application before the ID card is allowed to be imported, and associating the ID card with the login credentials. The storage and management of assets on the blockchain can be done in a variety of ways. If the size of the asset / asset fragment is not a concern, the asset can be converted into a blob and stored directly on the blockchain if the network participants are willing and the cost is acceptable. The important thing to note is that transactions are replicated in blockchain solutions, so if storage is an issue, other off-chain solutions can be used. Other reasons for off-chain storage can be that the owner does not want the document / fragment to be distributed on the network, but wants to store it in a secure trusted location (or there are legal / government requirements that require centralized storage of specific types). In the case of off-chain storage, the actual document fragment / sub-document may not be stored, but the hash of the referenced asset (i.e. document) may be stored on the blockchain.

[0062] Figure 1A A logical network diagram for redacting and reconciling documents in a blockchain network is shown according to an exemplary embodiment.

[0063] refer to Figure 1A , the example network 100 includes a document server 102 connected to a document owner node 105 and other participant nodes 107. The document server 102 can be connected to a blockchain 106 having a ledger 108 for storing ledger entries 110. Although this example only describes one document server 102 in detail, multiple such nodes can be connected to the blockchain 106. It should be understood that the document server 102 can include additional components, and some of the components described herein can be removed and / or modified without departing from the scope of the document server 102 disclosed herein. The document server 102 can be a computing device or server computer, etc., and can include a processor 104, which can be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or other hardware devices. Although a single processor 104 is depicted, it should be understood that the document server 102 can include multiple processors, multiple cores, etc. without departing from the scope of the document server node 102 system.

[0064] The document server 102 may also include a non-transitory computer-readable medium 112 on which machine-readable instructions executable by the processor 104 may be stored. Examples of machine-readable instructions are shown as 114-122 and are discussed further below. Examples of non-transitory computer-readable medium 112 may include an electrical, magnetic, optical, or other physical storage device containing or storing executable instructions. For example, the non-transitory computer-readable medium 112 may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

[0065] Processor 104 can retrieve, decode and execute machine-readable instructions 114 to receive a document from document owner node 105. The document may contain restricted access fragments. As described above, blockchain ledger 108 can store fragments of the seed document in the form of ledger entries 110. The blockchain 106 network can be configured to use one or more smart contracts to manage transactions for multiple participant nodes. Document server 102 can provide real-time notifications to nodes 105 and 107.

[0066] The processor 104 may retrieve, decode, and execute machine-readable instructions 116 to segment the document into a plurality of ledger entries 110 to be stored on the blockchain 106. The processor 104 may retrieve, decode, and execute machine-readable instructions 118 to update a ledger entry of the plurality of ledger entries based on the proposed changes made to the document by the authorized participant nodes. The processor 104 may retrieve, decode, and execute machine-readable instructions 120 to submit the ledger entry to the blockchain based on votes collected from the plurality of participant nodes 107. The processor 104 may retrieve, decode, and execute machine-readable instructions 122 to send a notification to a set of participant nodes of the plurality of participant nodes 107 that are authorized to view the document.

[0067] Figure 1B A logical network diagram for redacting and reconciling documents in a blockchain network is shown according to an exemplary embodiment.

[0068] refer to Figure 1B , the example network 101 includes a document server 102 connected to a document owner node 105 and other participant nodes 107. The document server 102 can be connected to a blockchain 106 having a ledger 108 for storing ledger entries 110. Although this example only describes one document server 102 in detail, multiple such nodes can be connected to the blockchain 106. It should be understood that the document server 102 can include additional components, and some of the components described herein can be removed and / or modified without departing from the scope of the document server 102 disclosed herein. The document server 102 can be a computing device or server computer, etc., and can include a processor 104, which can be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or other hardware devices. Although a single processor 104 is depicted, it should be understood that the document server 102 can include multiple processors, multiple cores, etc. without departing from the scope of the document server node 102 system.

[0069] The document server 102 may also include a non-transitory computer-readable medium 112 on which machine-readable instructions executable by the processor 104 may be stored. Examples of machine-readable instructions are shown as 113-121 and are discussed further below. Examples of non-transitory computer-readable medium 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transitory computer-readable medium 112 may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

[0070] Processor 104 may retrieve, decode, and execute machine-readable instructions 113 to segment a document provided by document owner node 105 into multiple segments to be stored on a ledger of blockchain 106. As described above, blockchain ledger 108 may store the segments of the seed document in the form of ledger entries 110. The blockchain 106 network may be configured to manage transactions of multiple participant nodes using one or more smart contracts. Document server 102 may provide real-time notifications to nodes 105 and 107.

[0071] Processor 104 may retrieve, decode, and execute machine-readable instructions 115 to detect changes to a document made by an authorized participant node 107. Processor 104 may retrieve, decode, and execute machine-readable instructions 117 to update a fragment of a plurality of fragments stored on ledger 108 based on the changes to the document. Processor 104 may retrieve, decode, and execute machine-readable instructions 119 to collect votes on the changes to the document from a plurality of participant nodes 107. Processor 104 may retrieve, decode, and execute machine-readable instructions 121 to submit the updated fragment to blockchain 106 based on the votes.

[0072] Figure 2A The blockchain architecture configuration 200 according to an embodiment is illustrated. Figure 2A , the blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are merely illustrative). These nodes participate in many activities, such as blockchain transaction addition and verification processes (consensus). One or more blockchain nodes 204-210 may endorse transactions according to endorsement policies and may provide ordering services for all blockchain nodes in the architecture 200. The blockchain node may initiate blockchain verification and seek to write to the blockchain immutable ledger stored in the blockchain layer 216, a copy of which may also be stored on the basic physical facility 214. The blockchain configuration may include one or more applications 224 that are linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chain code, smart contracts, etc.), which may be created according to the custom configuration sought by the participants and may maintain their own state, control their own assets, and receive external information. This may be deployed as a transaction and installed on all blockchain nodes 204-210 by attaching to the distributed ledger.

[0073] The blockchain foundation or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 216 may expose an interface to provide the required access to the virtual execution environment for processing program code and participating in the underlying physical infrastructure 214. Cryptographic trust services 218 may be used to verify transactions such as asset exchange transactions and keep the information confidential.

[0074] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 and the services provided through one or more interfaces opened by the blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transmit data and can be executed by the nodes 204-210 in the form of smart contracts, and associate chain codes with conditions or other code elements subject to their execution. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications (depending on changes, updates, etc.). The smart contracts themselves can be used to identify rules related to authorization, access requirements, and ledger usage. For example, the information 226 can include a transaction proposal 226, which can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The results 228 can include composite endorsements 228. The basic physical infrastructure 214 can be used to retrieve any data or information described herein.

[0075] Smart contracts can be created through high-level applications and programming languages ​​and then written to blocks in the blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated to a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which can be performed in response to the satisfaction of conditions associated with the smart contract. The execution of a smart contract can trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of a smart contract can be automatically replicated across a distributed network of blockchain peers through one or more consensus protocols.

[0076] Smart contracts can write data to the blockchain in the form of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or encrypted and maintained as private data. Temporary data used / generated by smart contracts is kept in memory by the provided execution environment and is deleted once the data required by the blockchain is identified.

[0077] Chaincode may include a code interpretation of a smart contract, with additional functionality. As described herein, chaincode may be program code deployed on a computing network, executed and validated together by chain validators during a consensus process. Chaincode receives a hash and retrieves from the blockchain a hash associated with a data template created using a previously stored functionality extractor. If the hash of the hashed identifier matches the hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. Chaincode may write data associated with cryptographic details to the blockchain.

[0078] Figure 2B An example of a blockchain transaction flow 250 between blockchain nodes according to an embodiment is illustrated. Figure 2B , the transaction flow may include a transaction proposal 291 sent by the application client node 260 to the endorsing peer node 281. The endorsing peer node 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values ​​written in the chaincode (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the sorting service node 284. The sorting service node 284 then delivers the sorted transaction as a block to all peers 281-283 on the channel. Each peer 281-283 may validate the transaction before committing to the blockchain. For example, the peer may check the endorsement policy to ensure the correct distribution of the signed result to the specified peer and verify the signature against the transaction payload 293.

[0079] Reference again Figure 2B , the client node 260 initiates a transaction 291 by constructing and sending a request to a peer node 281 (endorser). The client 260 may include an application that utilizes a supported software development kit (SDK) that utilizes an available API to generate a transaction proposal. A transaction proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger (i.e., a new key-value pair of an asset is written). The SDK may act as a shim to package the transaction proposal into a format that is appropriately architected (e.g., protocol buffers over remote procedure calls (RPCs)) and obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0080] In response, the endorsing peer 281 can verify that: (a) the transaction proposal is well-formed, (b) the transaction has not been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 can take the transaction proposal input as a parameter to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no updates are made to the ledger at this time. In 292, this set of values ​​is passed back to the SDK of the client 260 along with the signature of the endorsing peer 281 as a proposal response 292, which parses the payload for use by the application.

[0081] In response, the client 260 application checks / validates the endorsed peer signatures and compares the proposed responses to determine if the proposed responses are the same. If the chaincode only queried the ledger, the application will check the query response and typically will not submit the transaction to the ordering service node 284. If the client application intends to submit the transaction to the ordering service node 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (i.e., all peer nodes required for the transaction support the transaction) before submission. Here, the client can include only one of the multiple parties to the transaction. In this case, each client can have its own endorsement node, and each endorsement node is required to endorse the transaction. The architecture is such that even if an application chooses not to check the response or otherwise forward an unendorsed transaction, the endorsement policy will still be implemented by the peers and supported during the commit validation phase.

[0082] After successful checks, in step 293, client 260 assembles the endorsement into a transaction and broadcasts the transaction proposal and response within a transaction message to ordering node 284. A transaction may contain a read / write set, an endorsing peer signature, and a channel ID. Ordering service node 284 does not need to examine the entire contents of a transaction in order to perform its operations, but can simply receive transactions from all channels in the network, sort them by channel in time, and create blocks of transactions by channel.

[0083] Deliver the block of transactions from the ordering service node 284 to all peer nodes 281-283 on the channel. Verify the transactions 294 within the block to ensure that any endorsement policies are satisfied and that the ledger state of the read set variables has not changed since the read set was generated by the transaction execution. Mark the transactions in the block as valid or invalid. In addition, in step 295, each peer node 281-283 appends the block to the channel's chain and, for each valid transaction, commits the write set to the current state database. Emit an event to notify the client application that the transaction (call) has been immutably appended to the chain and that the transaction verification is valid or invalid.

[0084] Figure 3A An example of a permissioned blockchain network 300 is illustrated, which has a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 302 can initiate a transaction to a permissioned blockchain 304. In this example, the transaction can be a deployment, call, or query, and can be issued through a client-side application using an SDK, directly through an API, etc. The network can provide access to regulators 306 such as auditors. The blockchain network operator 308 manages member permissions, such as registering regulators 306 as "auditors" and blockchain users 302 as "clients." Auditors can be restricted to querying the ledger, while clients can be authorized to deploy, call, and query certain types of chaincodes.

[0085] Blockchain developers 310 can write chaincodes and client applications. Blockchain developers 310 can deploy chaincodes directly to the network through an interface. In order to include credentials from traditional data sources 312 in the chaincode, developers 310 can use out-of-band connections to access the data. In this example, blockchain users 302 connect to the permissioned blockchain 304 through peer nodes 314. Before conducting any transactions, peer nodes 314 retrieve the user's registration and transaction certificates from the certification authority 316 that manages user roles and permissions. In some cases, blockchain users must have these digital certificates to conduct transactions on the permissioned blockchain 304. At the same time, users trying to use chaincodes may need to verify their credentials on traditional data sources 312. To confirm the user's authorization, the chaincode can use an out-of-band connection to the data through a traditional processing platform 318.

[0086] Figure 3BAnother example of a permissioned blockchain network 320 is shown, which has a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 322 can submit a transaction to a permissioned blockchain 324. In this example, a transaction can be a deployment, call, or query, and can be issued through a client-side application using an SDK, directly through an API, etc. The blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and blockchain users 322 as "clients." Auditors can be restricted to querying the ledger, while clients can be authorized to deploy, call, and query certain types of chaincodes.

[0087] Blockchain developers 330 write chaincodes and client applications. Blockchain developers 330 can deploy chaincodes directly onto the network through an interface. To include credentials from traditional data sources 332 in chaincodes, developers 330 can use out-of-band connections to access the data. In this example, blockchain user 322 connects to the network through peer node 334. Before proceeding with any transactions, peer node 334 retrieves the user's registration and transaction certificates from certification authority 336. In some cases, blockchain users must have these digital certificates to conduct transactions on the permissioned blockchain 324. At the same time, users attempting to use chaincodes may need to verify their credentials on traditional data sources 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to that data through a traditional processing platform 338.

[0088] Figure 4A A flowchart 400 of an exemplary method for redacting and reconciling documents in a blockchain network is shown according to an exemplary embodiment. Figure 4A , method 400 may include one or more of the following steps.

[0089] Figure 4A 1 shows a flow chart of an example method performed by document server 102 (see FIG. 1 ). It should be understood that Figure 4A The method 400 depicted in the foregoing may include additional operations, and some of the operations described therein may be removed and / or modified without departing from the scope of the method 400. For illustrative purposes, the method 400 is also described with reference to the features shown in FIG. 1. In particular, the processor 104 of the document server 102 may perform some or all of the operations included in the method 400.

[0090] Reference Figure 4A, at box 412, the processor 104 may receive a document from a document owner node. The document may contain restricted access fragments. At box 414, the processor 104 may split the document into a plurality of ledger entries to be stored on the blockchain. At box 416, the processor 104 may update a ledger entry of the plurality of ledger entries based on a proposed change to the document made by an authorized participant node. At box 418, the processor 104 may submit the ledger entry to the blockchain based on votes collected from the plurality of participant nodes. At box 420, the processor 104 may send a notification to a set of participant nodes of the plurality of participant nodes that are authorized to view the document.

[0091] Figure 4B A flowchart 450 of an exemplary method for redacting and reconciling documents in a blockchain network is shown according to an exemplary embodiment. Figure 4B , method 450 may also include one or more of the following steps. In box 452, the processor 104 may determine a consensus method for negotiating changes to the document based on instructions received from the document owner. In box 454, the processor 104 may determine viewing and editing access for each of the restricted access fragments of the document for the multiple participant nodes. In box 456, the processor 104 may assign participant nodes from the multiple participant nodes to vote on the proposed changes defined by the document owner. In box 458, if the participant nodes assigned to vote do not reach a consensus, the processor 104 may generate a ledger entry indicating that the proposed change was rejected. In box 460, the processor 104 may execute a smart contract to limit access to the document fragments. In box 462, the processor 104 may convert the ledger entry into a blob before storing it on the blockchain.

[0092] Figure 4C A flowchart 410 of an exemplary method for redacting and reconciling documents in a blockchain network is shown according to an exemplary embodiment. Figure 4C , method 410 may include one or more of the following steps.

[0093] Figure 4C The document server 102 (see Figure 1A ) is a flowchart of an example method performed. It should be understood that Figure 4C The method 410 depicted in FIG. 4 may include additional operations, and some of the operations described therein may be removed and / or modified without departing from the scope of the method 410. For illustrative purposes, reference is also made to FIG. Figure 1A In particular, the processor 104 of the document server 102 may perform some or all of the operations included in the method 410.

[0094] Reference Figure 4C , in box 413, the processor 104 may split the document provided by the document owner node into multiple fragments to be stored on the ledger of the blockchain. In box 415, the processor 104 may detect changes to the document made by the authorized participant node. In box 417, the processor 104 may update one of the multiple fragments stored on the ledger based on the changes to the document. In box 419, the processor 104 may collect votes on the changes to the document from the multiple participant nodes. In box 421, the processor 104 may submit the updated fragment to the blockchain based on the votes.

[0095] Figure 4D A flowchart 470 of an exemplary method for redacting and reconciling documents in a blockchain network is shown according to an exemplary embodiment. Figure 4D , method 470 may also include one or more of the following steps. In box 472, the processor 104 may send a document change notification to a group of participant nodes among the multiple participant nodes that are authorized to view the document. In box 474, the processor 104 may determine viewing and editing access for each fragment of the document for the multiple participant nodes. In box 476, the processor 104 may receive instructions from the document owner regarding a consensus method for coordinating changes to the document. In box 478, the processor 104 may assign a participant node selected by the document owner from the multiple participant nodes to vote on the document change. In box 480, if the participant nodes assigned to vote do not reach a consensus on the document change, the processor 104 may record a ledger entry on the blockchain. In box 482, the processor 104 may execute a smart contract to limit access to the document fragment identified by the document owner.

[0096] Figure 5A An example system 510 is illustrated that includes an infrastructure 510 configured to perform various operations according to example embodiments. Figure 5A , the basic physical facility 510 includes a module 512 and a module 514. Module 514 includes a blockchain 520 and a smart contract 530 (which may be located on the blockchain 520), which can perform any operation step 508 (in module 512) included in any exemplary embodiment. Step / operation 508 may include one or more embodiments illustrated or described, and may represent output or written information written or read from one or more smart contracts 530 and / or blockchain 520. The basic physical facility 510, module 512, and module 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, module 512 and module 514 may be the same module.

[0097] Figure 5BAnother example system 540 is illustrated, which is configured to perform various operations according to the exemplary embodiments. Figure 5B , system 540 includes module 512 and module 514. Module 514 includes blockchain 520 and smart contract 530 (which can be located on blockchain 520), which can perform any operation step 508 (in module 512) included in any exemplary embodiment. Step / operation 508 may include one or more embodiments illustrated or described, and may represent output or written information written or read from one or more smart contracts 530 and / or blockchain 520. Infrastructure 510, module 512, and module 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, module 512 and module 514 may be the same module.

[0098] Figure 5C An example system configured to utilize a smart contract configuration between contracting parties and an intermediary server configured to implement smart contract terms on a blockchain is illustrated in accordance with an exemplary embodiment. Figure 5C , configuration 550 can represent a communication session, asset transfer session, or process driven by a smart contract 530 that explicitly identifies one or more user devices 552 and / or 556. The execution, operation, and results of the smart contract execution can be managed by a server 554. The content of the smart contract 530 can require digital signatures by one or more entities 552 and 556 that are parties to the smart contract transaction. The results of the smart contract execution can be written to the blockchain 520 as a blockchain transaction. The smart contract 530 resides on the blockchain 520, which can reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0099] Figure 5D A system 660 including a blockchain according to an exemplary embodiment is illustrated. Referring to the example of FIG. 6 , an application programming interface (API) gateway 562 provides a public interface for accessing blockchain logic (e.g., smart contracts 530 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 562 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 552 and 556 to blockchain peers (i.e., servers 554). Here, the server 554 is a blockchain network peer component that maintains a copy of the world state and a distributed ledger, thereby allowing clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, where, depending on the smart contract 530 and the endorsement policy, the endorsement peer will run the smart contract 530.

[0100] The above embodiments may be implemented in the form of hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program may be embodied in a computer-readable medium, such as a storage medium. For example, the computer program may reside in a random access memory ("RAM"), a flash memory, a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM"), an electrically erasable programmable read-only memory ("EEPROM"), a register, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0101] An exemplary storage medium may be coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium may be an integral part of the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In an alternative, the processor and the storage medium may reside as discrete components.

[0102] Fig. 6A Illustrating a process 600 of adding a new block to a distributed ledger 620 according to an exemplary embodiment, Figure 6B The content of a new data block structure 630 for a blockchain according to an exemplary embodiment is illustrated. Fig. 6A , a client (not shown) may submit a transaction to blockchain nodes 611, 612, and / or 613. A client may be an instruction received from any source to perform an activity on blockchain 520. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, to propose a transaction for a blockchain. Multiple blockchain peers, such as blockchain nodes 611, 612, and 613, may maintain the state of the blockchain network and a copy of the distributed ledger 620. Different types of blockchain nodes / peers may exist in the blockchain network, including an endorsing peer that simulates and endorses transactions submitted by a client, and a submitting peer that verifies endorsements, verifies transactions, and submits transactions to the distributed ledger 620. In this example, blockchain nodes 611, 612, and 613 may perform the role of an endorser node, a submitter node, or both.

[0103] The distributed ledger 620 includes a blockchain that stores immutable sequential records in blocks, and a state database 624 (current world state) that maintains the current state of the blockchain 722. There can be one distributed ledger 620 for each channel, and each peer maintains its own copy of the distributed ledger 620 for each channel it belongs to. The blockchain 622 is a transaction log structured as hash-linked blocks, where each block contains a series of N transactions. Blocks may include transactions such as Figure 6BThe various components shown in . A link to a block can be generated by adding the hash of the previous block's header to the current block's header (by Fig. 6A ). In this way, all transactions on blockchain 622 are ordered and cryptographically linked together, preventing tampering of blockchain data without breaking the hash link. In addition, due to the link, the latest block in blockchain 622 represents every transaction that came before it. Blockchain 622 can be stored on a peer-to-peer file system (local or attached storage), which supports append-only blockchain workloads.

[0104] The current state of the blockchain 622 and distributed ledger 622 can be stored in the state database 624. Here, the current state data represents the latest values ​​of all keys contained in the chain transaction log of the blockchain 622. Chaincode invocations execute transactions against the current state in the state database 624. In order to make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database 624. The state database 624 can contain an indexed view of the transaction log of the blockchain 622, so the indexed view can be regenerated from the blockchain at any time. Before accepting a transaction, the state database 624 can be automatically restored (or generated as needed) at the start of the peer.

[0105] An endorsing peer receives a transaction from a client and endorses the transaction based on the simulation results. An endorsing peer holds the smart contract proposed by the simulated transaction. When an endorsing peer endorses a transaction, the endorsing peer creates a transaction endorsement, which is a signed response from the endorsing peer to the client application indicating the endorsement of the simulated transaction. The method of endorsing a transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction". Different channels can have different endorsement policies. Endorsed transactions are forwarded by the client application to the sorting service 610.

[0106] The ordering service 610 receives endorsed transactions, orders them into a block, and delivers the blocks to commit peers. For example, when a transaction threshold is reached, a timer times out, or other conditions, the ordering service 610 can start a new block. Fig. 6A In the example of , blockchain node 612 is a commit peer that has received a new data block 630 for storage on blockchain 620. The first block in a blockchain can be called a genesis block, which includes information about the blockchain and its members, data stored therein, etc.

[0107] The sorting service 610 may consist of a group of sorters. The sorting service 610 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the sorting service 610 may accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 620. The architecture of the blockchain network may be designed so that the specific implementation of "sorting" (such as Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0108] Transactions are written to the distributed ledger 620 in a consensus order. The order of transactions is established to ensure that updates to the state database 624 are valid when submitted to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin, etc.) where ordering is performed by solving cryptographic puzzles or mining, in this case, the parties to the distributed ledger 620 can choose the ordering mechanism that best suits the network.

[0109] When the ordering service 610 initializes a new data block 630, the new data block 630 may be broadcast to committing peers (e.g., blockchain nodes 611, 612, and 613). In response, each committing peer verifies the transaction in the new data block 630 by checking to ensure that the read set and the write set still match the current world state in the state database 624. Specifically, the committing peer may determine whether the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 624. When the committing peer confirms the transaction, the transaction is written to the blockchain 622 on the distributed ledger 620, and the state database 624 is updated with the write data in the read-write set. If the transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 624, the transaction ordered into the block will still be included in the block, but it will be marked as invalid, and the state database 624 will not be updated.

[0110] refer to Figure 6B , a new data block 630 (also referred to as a data block) stored on the blockchain 622 of the distributed ledger 620 may include multiple data segments, such as a block header 640, block data 650, and block metadata 660. It should be appreciated that Figure 6B The various described blocks and their contents shown in the block header 640, such as the new data block 630 and its contents, are merely examples and are not intended to limit the scope of the exemplary embodiments. The new data block 630 may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions in the block data 650. The new data block 630 may also include a pointer to (e.g., Figure 6BIn particular, the block header 640 may include a hash of the header of the previous block. The block header 640 may also include a unique block number, a hash of the block data 650 of the new data block 630, etc. The block number of the new data block 630 may be unique and assigned in various orders, such as in an increasing / sequential order starting from zero.

[0111] The block data 650 may store transaction information for each transaction recorded in the new data block 630. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 620, transaction ID, epoch, payload visibility, chaincode path (deployment transaction), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identity - such as public key and certificate, client signature, endorser identity, endorser signature, proposal hash, chaincode event, response status, namespace, read set (a list of keys and versions read by the transaction, etc.), write set (a list of keys and values, etc.), start key, end key, a list of keys, Merkel tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0112] In some embodiments, block data 650 may also store new data 662 that adds additional information to the chain of hash links of blocks in blockchain 622. The additional information includes one or more of the steps, features, processes, and / or operations illustrated or described herein. Thus, new data 662 may be stored in an immutable block log on distributed ledger 620. Some of the benefits of storing such new data 662 are reflected in the various embodiments disclosed and described herein. Although in Figure 6B The new data 662 is shown as being in the block data 650 , but may also be located in the block header 640 or the block metadata 660 .

[0113] The block metadata 660 may store a plurality of metadata fields (e.g., in the form of a byte array, etc.). The metadata fields may include a signature when the block was created, a reference to the last configuration block, a transaction filter identifying valid and invalid transactions within the block, the last offset of the sorting service that sorted the block, etc. The sorting service 610 may add a signature, the last configuration block, and sorter metadata. At the same time, the submitter of the block (e.g., blockchain node 612) may add validity / invalidity information based on the endorsement policy, verification of the read / write set, etc. The transaction filter may include a byte array of a size equal to the number of transactions in the block data 650 and a verification code identifying whether the transaction is valid or invalid.

[0114] Figure 6CAn embodiment of a blockchain 670 for digital content according to embodiments described herein is illustrated. Digital content may include one or more files and related information. These files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only nature of the blockchain plays a role in protecting the integrity, validity, and authenticity of the digital content, making the digital content suitable for legal proceedings in which admissibility rules apply, or for other scenarios in which it is important to take into account evidence or submit and use digital information. In this case, the digital content may be referred to as digital evidence.

[0115] There are many different ways to form a blockchain. In one embodiment, digital content can be incorporated into the blockchain and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of reference information (such as block headers, values, etc.) along with the associated digital content. The hash value and the associated digital content can then be encrypted together. Therefore, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing the previous block. This can be illustrated as follows:

[0116]

[0117]

[0118] In one embodiment, the digital content may not be contained in the blockchain. For example, the blockchain may store a cryptographic hash of the content of each block without storing any digital content. The digital content may be stored in another storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device as the one storing the blockchain, or a different storage area, or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest, and then looking up the hash value stored in the storage area corresponding to the actual digital content. This operation may be performed by, for example, a database gateway manager. This may be illustrated as follows:

[0119]

[0120] exist Figure 6C In an exemplary embodiment of the present invention, the blockchain 670 includes a number of blocks 6781, 6782, ... 678 that are cryptographically linked in sequence. N , where N ≥ 1. Used to link blocks 6781, 6782, ... 678 N The encryption can be any one of a number of keyed or non-keyed hash functions. In one embodiment, blocks 6781, 6772, ... 678 NSubject to a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA (Secure Hash Algorithm) type algorithms, Merkle-Damagard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number based algorithms, and non-collision resistant PRF algorithms. In another embodiment, blocks 6781, 6782, ... 678 N Cryptographic linking may be performed by functions other than hash functions. For ease of explanation, the following description refers to a hash function, such as SHA-2.

[0121] Each block in the blockchain is 6781, 6782, ..., 678 N Each block contains a header, a file version, and a value. Due to the hashing in the blockchain, the header and value are different for each block. In one embodiment, the value can be included in the header. As described in more detail below, the file version can be the original file, or a different version of the original file.

[0122] The first block 6781 in the blockchain is called the starting block and includes a header 6721, an original file 6741, and an initial value 6761. The hashing scheme used for the starting block, as well as the hashing schemes for all subsequent blocks, may be different. For example, all of the information in the first block 6781 may be hashed together at once, or each or a portion of the information in the first block 6781 may be hashed separately and then the separately hashed portions hashed together.

[0123] The header 6721 may include one or more initial parameters, such as a version number, timestamp, random number, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information related to the original file 6741 and / or the blockchain. The header 6721 may be automatically generated (e.g., by blockchain network management software) or manually generated by a blockchain participant. N Unlike the header in , header 6721 in the genesis block does not reference a previous block, simply because there is no previous block.

[0124] For example, the original file 6741 in the starting block can be, for example, data captured by the device, processed or unprocessed before being included in the blockchain. The original file 6741 is received from the device, media source, or node through the system interface. The original file 6741 is associated with metadata that can be manually or automatically generated by a user, device, and / or system processor. The metadata can be included in the first block 6781 together with the original file 6741.

[0125] The value 6761 in the start block is an initial value generated based on one or more unique attributes of the original file 6741. In one embodiment, the one or more unique attributes may include a hash value of the original file 6741, metadata of the original file 6741, and other information related to the file. In one implementation, the initial value 6761 may be based on the following unique attributes:

[0126] 1) The SHA-2 calculated hash value of the original file

[0127] 2) Initiating device ID

[0128] 3) The start timestamp of the original file

[0129] 4) The original storage location of the original file

[0130] 5) Blockchain network member ID for the software that currently controls the original file and associated metadata

[0131] Other blocks in the blockchain: 6782 to 678 N It also has a header, file, and value. However, unlike the header 6721 of the first block, the headers 6722 to 772 in the other blocks are N Each contains the hash value of the previous block. The hash value of the previous block may be just the hash of the header of the previous block, or it may be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, it is possible to trace back from the Nth block to the starting block (and the related original file) block by block, as shown by arrow 680, to establish an auditable and immutable chain of custody.

[0132] Each header 6722 to 672 in other blocks N Other information may also be included, such as version numbers, timestamps, random numbers, root information, difficulty levels, consensus protocols, and / or other parameters or information related to the corresponding file and / or blockchain.

[0133] Files 6742 to 674 in other blocks N Can be equal to the original file or a modified version of the original file in the starting block, depending on the type of processing performed. The type of processing performed may vary from block to block. For example, the processing may involve any modification of the file in the previous block, such as revising information or otherwise changing the contents of the file, removing information from the file, or adding or appending information to the file.

[0134] Additionally, or alternatively, processing may simply involve copying a file from a previous block, changing a storage location of a file, analyzing one or more files in a previous block, moving a file from one storage or memory location to another storage or memory location, or performing operations relative to the blockchain file and / or its associated metadata. Processing involving analyzing a file may include, for example, appending, including, or otherwise associating various analytical, statistical, or other information associated with the file.

[0135] Other blocks 6762 to 676 N The value of each other block in the chain is unique and different due to the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value is assigned. Therefore, the value of the block provides an indication of what processing was performed in the block and allows tracking back to the original file through the blockchain. This tracking confirms the chain of custody of the file throughout the blockchain.

[0136] For example, consider a situation where a portion of a file in a previous block is redacted, chunked, or pixelated in order to protect the identity of the person shown in the file. In this case, the block that includes the redacted file will include metadata associated with the redacted file, such as how the redaction was performed, who performed the redaction, a timestamp of when the redaction occurred, etc. The metadata can be hashed to form a value. Because the metadata for the block is different from the information in the previous block that was hashed to form a value, the values ​​are different from each other and can be recovered when decrypted.

[0137] In one embodiment, when any one or more of the following situations occur, the value of the previous block can be updated (e.g., a new hash value is calculated) to form the value of the current block. In this embodiment, the new hash value can be calculated by hashing all or part of the information described below.

[0138] a) The new SHA-2 calculated hash value if the file has been manipulated in any way (e.g. if the file has been revised, copied, changed, accessed, or some other action has been taken)

[0139] b) New storage location for the file

[0140] c) Identify new metadata associated with the file

[0141] d) Transferring access to or control of a file from one blockchain participant to another

[0142] Fig.6D An example of a block that can represent the structure of a block in a blockchain 690 according to one embodiment. i Including header 672 i、File 674 i Total value 676 i .

[0143] Head 672 i Including the previous block i-1 The hash value of the previous block and additional reference information, which can be any type of information discussed in this article (such as header information including references, features, parameters, etc.). All blocks reference the hash value of the previous block, of course, except for the starting block. The hash value of the previous block can be just the hash of the header in the previous block, or it can be the hash of all or part of the information in the previous block - including files and metadata.

[0144] File 674 i Includes multiple data, such as Data 1, Data 2, ..., Data N in sequence. These data are marked with metadata Metadata 1, Metadata 2, ..., Metadata N that describe the content and / or characteristics related to the data. For example, the metadata of each data may include information indicating the timestamp of the data, processing data, keywords indicating the person or other content described in the data, and / or other features that help determine the validity and content of the file as a whole - especially its use as digital evidence, such as described in the embodiments discussed below. In addition to the metadata, each data can also be marked with a reference REF 1, REF 2, ..., REF N to the previous data to prevent tampering, gaps in the file, and sequential references through the file.

[0145] Once metadata is assigned to data (e.g., by a smart contract), it cannot be changed without changing the hash, which can be easily identified as invalid. Metadata thus creates a data log of information that can be accessed for use by blockchain participants.

[0146] Value 676 i A hash or other value calculated based on any of the types of information discussed above. For example, for any given block i , the value of the block can be updated to reflect the processing performed for the block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other operations or information to be added. Although the value in each block is shown as being separate from the metadata and header of the file's data, in another embodiment the value can be based in part or in whole on the metadata.

[0147] Once blockchain 670 is formed, at any point in time, an immutable chain of custody of a file can be obtained by querying the blockchain for the transaction history of values ​​across blocks. This query or tracking process can begin by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continue to decrypt the values ​​of other blocks until the starting block is reached and the original file is restored. Decryption may also involve decrypting the header and file and related metadata on each block.

[0148] Decryption is performed based on the type of encryption that occurred in each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, when asymmetric encryption is used, a blockchain participant or processor in the network can generate a public and private key pair using a predetermined algorithm. The public and private keys are related to each other through some mathematical relationship. The public key can be publicly distributed to be used as an address (such as an IP address or home address) to receive messages from other users. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. This way, the recipient can be sure that only the sender could have sent the message.

[0149] Generating a key pair can be similar to creating an account on the blockchain without actually registering anywhere. In addition, each transaction performed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and process the blockchain's files (if within the scope of permissions determined by the smart contract).

[0150] Figure 7 An example system 700 is illustrated to support one or more embodiments described herein. The system 700 includes a computer system / server 702 that operates with many other general or special computing system environments or configurations. Examples of computing systems, environments, and / or configurations suitable for the computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or notebook devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices.

[0151] Computer system / server 702 may be described in the general context of computer system executable instructions (e.g., program modules) executed by a computer system. In general, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 702 may be used in a distributed cloud computing environment, where tasks are performed by remote processing devices connected through a communication network. In a distributed cloud computing environment, program modules may be located in local and remote computer system storage media including memory storage devices.

[0152] like Figure 7 As shown in FIG. 7 , a computer system / server 702 in a cloud computing node 700 is shown in the form of a general-purpose computing device. Components of the computer system / server 702 may include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the system memory 706 to the processor 704.

[0153] The bus represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0154] Computer system / server 702 typically includes various computer system readable media. Such media can be any available media accessible to computer system / server 702, including volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 706 implements the flowcharts in other figures. System memory 706 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 710 and / or cache memory 712. Computer system / server 702 can also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 714 can be provided for reading and writing data to a non-removable non-volatile magnetic medium (not shown, usually referred to as a "hard drive"). Although not shown, a disk drive for reading and writing a removable non-volatile disk (e.g., a "floppy disk") can be provided, as well as an optical disk drive for reading or writing a removable non-volatile optical device, such as a CD-ROM, DVD-ROM, or other optical media disk. In this case, each can be connected to the bus via one or more data media interfaces. As will be further depicted and described below, the memory 706 may include at least one program product having a set (eg, at least one) of program modules configured to perform the functions of various embodiments of the present application.

[0155] A program / utility 816 having a set (at least one) of program modules 818 may be stored in memory 706 by way of example and not limitation, as may an operating system, one or more application programs, other program modules, and program data. Each or some combination of the operating system, one or more application programs, other program modules, and program data may include an implementation of a network environment. Program modules 818 generally perform the functions and / or methods of various embodiments of the present application as described herein.

[0156] It should be understood by those skilled in the art that various aspects of the present application may be embodied as a system, method or computer program product. Therefore, various aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or a combination of software and hardware embodiments, which may generally be referred to herein as a "circuit", "module" or "system". Various aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having a computer-readable program code contained thereon.

[0157] The computer system / server 702 may also communicate with one or more external devices 720, such as a keyboard, a pointing device, a display 722; one or more devices that enable a user to interact with the computer system / server 702; and / or any device that enables the computer system / server 702 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may be performed via an I / O interface 724. In addition, the computer system / server 702 may also communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter 726. As shown, the network adapter 726 communicates with other components of the computer system / server 702 via a bus. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems.

[0158] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media are shown in the accompanying drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as set forth and defined in the claims described below. For example, the functions of the systems of the accompanying drawings may be performed by one or more modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver, or a transmitter-receiver pair. For example, all or part of the functions performed by each module may be performed by one or more of these modules. In addition, the functions described herein may be performed at different times and in association with various events inside or outside the module or component. In addition, information sent between modules may be sent between modules via multiple protocols and / or via at least one of the following: data network, Internet, voice network, Internet protocol network, wireless device, wired device. Moreover, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

[0159] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide examples of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0160] It should be noted that some of the system features described in this specification are presented as modules in order to more specifically emphasize their implementation independence. For example, a module can be implemented as a hardware circuit including a custom very large scale integration (VLSI) circuit or gate array, an off-the-shelf semiconductor such as a logic chip, a transistor or other discrete component. A module can also be implemented in a programmable hardware device such as a field programmable gate array, a programmable array logic, a programmable logic device, a graphics processing unit, etc.

[0161] Module can also be implemented at least in part with software, to be performed by various types of processors. The executable code unit identified can for example include one or more physical or logical blocks of computer instructions, which can for example be organized as objects, processes or functions. However, the executable file of the module identified does not need to be physically located together, but can include different instructions stored in different locations, which, when logically connected together, include modules and realize the described purpose of modules. In addition, module can be stored on a computer-readable medium, which can be for example a hard disk drive, a storage device, a random access memory (RAM), a magnetic tape or any other such medium for storing data.

[0162] In practice, a module of executable code may be a single instruction or multiple instructions, and may even be distributed over several different code segments, different programs, and several memory devices. Similarly, operational data may be identified and shown herein within a module, and may be embodied in any suitable form and organized in any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including different memory devices, and may exist at least in part only as electronic signals on a system or network.

[0163] It is easy to understand that the components of the present application can be arranged and designed in a variety of different configurations as generally described and illustrated in the drawings herein. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but only represents the selected embodiments of the present application.

[0164] Those skilled in the art will readily appreciate that the above may be implemented in different orders of steps and / or using hardware elements in configurations different from the disclosed configurations. Therefore, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent.

[0165] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and the scope of the present application is limited solely by the appended claims taking into account the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A computer-implemented method comprising: A document server of a blockchain network receives a document from a document owner node of the blockchain network; The document server divides the document into a plurality of segments and submits the plurality of segments to a blockchain ledger of the blockchain network; detecting a portion of a fragment of the document, the portion of the fragment of the document being selected by the document owner node by highlighting the portion of the fragment of the document; while highlighting the portion of the segment, detecting a selection of a blockchain consensus method for the portion of the segment from a plurality of blockchain consensus methods from the document owner node, wherein the selected blockchain consensus method defines how many peers must agree; updating the portion of the segment of the document based on proposed changes made to the document by an authorized participant node of the blockchain network to generate an updated segment; executing a selected blockchain consensus process on the proposed change through a plurality of blockchain nodes of the blockchain ledger; Determining, based on execution of the selected blockchain consensus process, that sufficient votes have been received to approve the proposed change; and The updated segment of the document is submitted to the blockchain ledger.

2. The method according to claim 1, further comprising: View access and edit access to the updated segment is determined for a plurality of participant nodes.

3. The method according to claim 1, further comprising: The selected blockchain consensus method is received from the document owner node via a software application.

4. The method according to claim 3, further comprising: Assign two or more authorized participant nodes to vote on the proposed changes.

5. The method according to claim 4, further comprising: When the two or more authorized participant nodes do not reach consensus on the proposed change, a ledger entry is recorded on the blockchain ledger.

6. The method according to claim 1, further comprising: A smart contract is executed to restrict access to the updated fragment.

7. The method according to claim 1, further comprising: The updated segments are converted into blobs before being submitted to the blockchain ledger.

8. A system comprising: The document server's processor; A memory having machine-readable instructions stored thereon, which, when executed by a processor, causes the processor to execute the steps in the method according to any one of claims 1 to 7.

9. A non-transitory computer-readable medium comprising machine-readable instructions, which, when read by a processor, cause the processor to execute the steps of the method according to any one of claims 1 to 7.

10. An apparatus comprising corresponding means configured to implement all the steps of the method as claimed in any one of claims 1 to 7.

Images