Context integrity preservation

Abstract

Example operations include one or more of receiving, by a data processing node, an inference data object from a multi-channel data server over a blockchain, ordering, by the data processing node, longitudinal records contained in the inference data object, linking, by the data processing node, transaction results and inference data from the inference data object to the ordered longitudinal records, and recording the linked data on a blockchain ledger. The data processing node acts as a validator of data from a robotic counseling using natural language (NL) processing to reduce bias and measure effectiveness of inferences from the robotic counseling.

Description

Background Technology

[0001] A centralized database stores and maintains data in a single location, such as a database server. This location is typically a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored on a centralized database is typically accessible from multiple different points. Multiple users or client workstations can work simultaneously on the centralized database, for example, based on a client / server configuration. Centralized databases are easy to manage, maintain, and control due to their single location, especially for security purposes. Within a centralized database, data redundancy is minimized because the single storage location of all data also means that a given dataset has only one primary record. Summary of the Invention

[0002] One example embodiment provides a system including a processor and memory, configured to perform one or more of the following: receiving an inferred data object from a multichannel data server via a blockchain; sorting the longitudinal records contained in the inferred data object; linking transaction results and inferred data from the inferred data object to the sorted longitudinal records; and recording the linked data on a blockchain ledger.

[0003] Another example embodiment provides a method comprising one or more of the following: receiving an inferred data object from a multichannel data server via a blockchain by a data processing node; sorting the vertical records contained in the inferred data object by the data processing node; linking transaction results and inferred data from the inferred data object to the sorted vertical records by the data processing node; and recording the linked data on a blockchain ledger.

[0004] Another example embodiment provides a non-transient computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving an inferred data object from a multichannel data server via a blockchain; sorting the vertical records contained in the inferred data object; linking transaction results from the inferred data object and the inferred data to the sorted vertical records; and recording the linked data on a blockchain ledger. Attached Figure Description

[0005] Figure 1 A network diagram of a system including a database according to an exemplary embodiment is shown.

[0006] Figure 2A An example blockchain architecture configuration is shown according to an example embodiment.

[0007] Figure 2B This illustrates a blockchain transaction process according to an example embodiment.

[0008] Figure 3A A licensed network is shown according to an example embodiment.

[0009] Figure 3B Another licensed network according to an example embodiment is shown.

[0010] Figure 3C An unlicensed network is shown according to an example embodiment.

[0011] Figure 4A A flowchart according to an example embodiment is shown.

[0012] Figure 4B Another flowchart according to an example embodiment is shown.

[0013] Figure 5A An example system configured to perform one or more operations described herein is shown according to an example embodiment.

[0014] Figure 5B Another example system is shown, configured to perform one or more operations described herein, according to an example embodiment.

[0015] Figure 5C Another example system configured to utilize smart contracts is shown according to an example embodiment.

[0016] Figure 5D This illustrates yet another example system configured to utilize blockchain according to an example embodiment.

[0017] Figure 6A This illustrates the process of adding a new block to a distributed ledger according to an example embodiment.

[0018] Figure 6B This shows the contents of a new data block according to an example embodiment.

[0019] Figure 6C This illustrates a blockchain for digital content according to an example embodiment.

[0020] Figure 6D A block is shown that can represent the structure of a block in a blockchain, according to an example embodiment.

[0021] Figure 7A An example blockchain for storing machine learning (artificial intelligence) data is shown according to an example embodiment.

[0022] Figure 7B An example quantum-safe blockchain is shown according to an example embodiment.

[0023] Figure 8 An exemplary system supporting one or more example embodiments is shown. Detailed Implementation

[0024] It will be readily understood that, as generally described and illustrated in the accompanying drawings, the components of the present invention can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the method, apparatus, non-transient computer-readable medium, and system illustrated in the drawings is not intended to limit the scope of the claims made herein, but merely represents selected embodiments.

[0025] In one or more embodiments, features, structures, or characteristics of the invention as described throughout this specification may be combined or removed in any suitable manner. For example, the phrases “exemplary embodiments,” “some embodiments,” or other similar language used throughout this specification actually refer to specific features, structures, or characteristics described in connection with embodiments that 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 refer to the same set of embodiments, and in one or more embodiments, the described features, structures, or characteristics may be combined or removed in any suitable manner. Furthermore, any connection between elements in the schematic diagrams may allow unidirectional and / or bidirectional communication, even if the connections shown are unidirectional or bidirectional arrows. Moreover, any device shown in the figures may be a different device. For example, if a mobile device is shown sending information, a wired device may also be used to send that information.

[0026] Furthermore, although the term "message" may be used in the description of the embodiments, this application can be applied to many types of networks and data. Moreover, although specific types of connections, messages, and signaling may be described in the exemplary embodiments, this application is not limited to specific types of connections, messages, and signaling.

[0027] Example embodiments provide methods, systems, components, non-transient computer-readable media, devices, and / or networks for maintaining the contextual integrity of multi-channel services in a blockchain network.

[0028] In one embodiment, this application utilizes a decentralized database (such as a blockchain) as a distributed storage system comprising multiple nodes communicating with each other. The decentralized database comprises an append-only immutable data structure similar to a distributed ledger capable of maintaining records among mutually distrustful parties. These mutually distrustful parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record without consensus among the distributed peers. For example, peers can execute consensus protocols to verify blockchain storage transactions, group storage transactions into blocks, and build hash chains on the blocks. For consensus, this process forms a ledger by ordering the storage transactions as needed. In various embodiments, permissioned blockchains and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains can involve native cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). On the other hand, permissioned blockchain databases provide secure interaction between a group of entities sharing common goals but not fully trusting each other, such as for exchanging funds, goods, or information.

[0029] This application can utilize blockchains with arbitrary, programmable logic, known as "smart contracts" or "chaincode," that operates on decentralized storage schemes. In some cases, there may be dedicated chaincode, called system chaincode, used to manage functions and parameters. This application can further utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof nature of blockchain databases and a foundational protocol between nodes called endorsement or endorsement policy. Blockchain transactions associated with this application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. The endorsement policy allows the chaincode to specify endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify it. After verification, the transaction enters a sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0030] This application utilizes nodes as communication entities in a blockchain system. A "node" can perform logical functions in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as client or commit-client nodes, which submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive transactions submitted by clients, submit those transactions, and maintain the state and copies of the ledger of blockchain transactions. Peers can also act as endorsers, although this is not a requirement. Ordering service nodes, or orderers, are nodes that run communication services for all nodes, implementing delivery guarantees such as broadcasting to every peer in the system when a transaction is submitted and the world state of the blockchain is modified. The world state of the blockchain is another name for the initial blockchain transaction, which typically includes control and setup information.

[0031] This application utilizes a ledger, which is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be triggered by chaincode calls (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorsing nodes, peer nodes, etc.). Each participant (such as a peer node) maintains a copy of the ledger. A transaction can result in a set of asset key-value pairs being submitted to the ledger as one or more operands such as create, update, or delete. The ledger comprises a blockchain (also called a chain) for storing immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0032] This application utilizes a chain of transaction logs constructed as hash-linked blocks, each block containing a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hashes of the transactions in that block and the hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, the ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added blockchain block represents every transaction that appeared on the chain before it, thus ensuring that all peer nodes are in a consensus and trusted state. The chain can be stored on peer node file systems (i.e., local, additional storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0033] The current state of an immutable ledger represents the latest value of all keys included in the chain's transaction log. Because the current state represents the latest key-value pairs known to the channel, it is sometimes referred to as the world state. Chain calls execute transactions targeting the ledger's current state data. To make these chaincode interactions valid, the latest values ​​of the keys can be stored in a state database. The state database can simply be an indexed view of the chain's transaction log, and therefore can be regenerated at any time based on the chain. The state database can be automatically restored (or generated as needed) before peers initiate and transactions are accepted.

[0034] Some benefits of the immediate solutions described and illustrated herein include a method and system for maintaining the contextual integrity of multi-channel services in a blockchain network. Exemplary embodiments address the issues of time and trust by extending database characteristics such as immutability, digital signatures, and acting as a single source of truth. Exemplary embodiments provide a solution for maintaining the contextual integrity of multi-channel services in a blockchain-based network. The blockchain network can be homogeneous, based on asset type and rules governing asset management through smart contracts.

[0035] The difference between blockchain and traditional databases lies in the fact that blockchain is not a central store, but a decentralized, immutable, and secure store where nodes must share changes to records within the store. Some inherent properties of blockchain that contribute to its implementation include, but are not limited to, the immutable ledger, smart contracts, security, privacy, centralization, consensus, endorsement, and accessibility described further herein. Depending on the specific aspects, blockchain's inherent and unique immutable accountability, security, privacy, permissioned decentralization, smart contract availability, endorsement, and accessibility enable the implementation of systems for maintaining the contextual integrity of multi-channel services within a blockchain network. Specifically, blockchain ledger data is immutable and provides an efficient method for maintaining the contextual integrity of multi-channel services within a blockchain network. Furthermore, the use of encryption in blockchain provides security and establishes trust. Smart contracts manage the state of assets to complete their lifecycle. Example blockchains are permissioned and decentralized. Therefore, each end-user can have their own copy of the ledger for access. Multiple organizations (and peers) can be bound together on a blockchain network. Key organizations can act as endorsing peers, verifying the results of smart contract executions, read sets, and write sets. In other words, the inherent characteristics of blockchain provide a way to effectively implement contextual integrity for multi-channel services in a blockchain network.

[0036] One of the benefits of the example implementation is that it improves the functionality of the computing system by implementing a method for maintaining the contextual integrity of multichannel services in a blockchain-based system.

[0037] In one embodiment, an integrity validator module (or node) can provide integrated checks on data interacting with different channels and their data in relation to corresponding transactions. The validator module can bridge and match requests / orders / fulfillments from interacting systems between enterprise financial transaction systems. The validator module can provide channel relevance for requests, conflicts, replications, etc., from other channels. The validator module can be implemented as a data processing blockchain node that provides links to different data elements, transaction confirmations from different channels, and links between different transaction requests. This data processing blockchain node can execute smart contracts to provide a pipeline for submitting fused information for verification to the blockchain system by creating inferred data objects or fused data assets representing the context.

[0038] Through the blockchain system described in this article, computing systems can perform functions to maintain the contextual integrity of multi-channel services within the blockchain network by providing access to capabilities such as distributed ledgers, peer-to-peer mechanisms, cryptography, MSPs, and event processing. Furthermore, blockchain enables the creation of business networks and the participation of any user or organization. Therefore, blockchain is more than just a database. It possesses the ability to create business networks where users and participating / off-board organizations collaborate and to execute service processes in the form of smart contracts.

[0039] Exemplary embodiments offer numerous benefits over traditional databases. For example, through blockchain, embodiments provide the inherent and unique immutability, accountability, security, privacy, permissioned decentralization, availability, endorsement, and accessibility of blockchain.

[0040] Furthermore, traditional databases cannot be used to implement the example embodiments because they do not bring all parties onto a commercial network, do not create trusted collaboration, and do not provide effective storage for digital assets. Traditional databases do not provide tamper-proof storage and do not provide preservation of the stored digital assets. Therefore, the proposed method for maintaining the contextual integrity of multi-channel services in a blockchain network cannot be implemented in a traditional database.

[0041] Furthermore, if traditional databases are used to implement the example embodiments, the embodiments will suffer from unnecessary drawbacks such as poor search capabilities, lack of security, and slow transaction speeds. In addition, automated methods for maintaining the contextual integrity of multi-channel services in a blockchain network would be simply impossible.

[0042] Centralized databases have a single point of failure. Specifically, if a failure occurs (e.g., hardware, firmware, and / or software failure), all data within the database may be lost, and all users' work may be interrupted. Furthermore, centralized databases are highly dependent on network connectivity. Consequently, the slower the connection, the more time is required for each database access. Due to their single location, centralized databases can become bottlenecks under high traffic. Additionally, centralized databases maintain only one copy of the data. Therefore, multiple devices cannot access the same data simultaneously without causing significant problems or risking overwriting the stored data. Moreover, because database storage systems have minimal or no data redundancy, it is difficult to retrieve data from backup storage through means other than manual intervention if data is accidentally lost.

[0043] Therefore, a blockchain-based solution is needed to record transactions and data related to multiple channels. Maintaining data integrity in multiple channels is difficult due to the bias and lack of complete longitudinal data when combining multiple omnichannels.

[0044] Therefore, the example embodiments provide one or more solutions for maintaining the contextual integrity of data in a blockchain network.

[0045] The example embodiments also change how data can be stored within the block structure of a blockchain. For example, digital asset data can be securely stored within a portion of a data block (i.e., within the header, data segments, or metadata). By storing digital asset data within data blocks of a blockchain, the digital asset data can be appended to the immutable blockchain ledger via a hash-linked blockchain. In some embodiments, data blocks can differ from traditional data blocks by ensuring that personal data associated with digital assets is not stored alongside assets within the blockchain's traditional block structure. By removing personal data associated with digital assets, blockchains can provide the benefits of anonymity based on immutability, accountability, and security.

[0046] According to exemplary embodiments, a method and system for maintaining the contextual integrity of multichannel services in a blockchain network are provided.

[0047] Multichannel services in the financial services industry represent a highly complex business process. Meeting customer preferences and the need to utilize various channels such as online, fax, telephone, and now mobile devices places a significant burden on the industry, requiring the amalgamation of often enormous amounts of cross-channel data. This problem can be further complicated by the introduction of chatbots and robo-advisory systems due to biases and a lack of complete longitudinal data.

[0048] According to one exemplary embodiment, maintaining data integrity can be achieved by using blockchain technology as an immutable system that provides a longitudinal record of data with links to transaction outcomes and inferences, ensuring data integrity, trust, and a clean organization. This can be effectively used, for example, in the case of bot consultations. This approach ensures minimal disruption to current siloed systems and provides a pathway to various systems that collectively provide a full-channel experience to customer nodes (e.g., financial services customers). By linking different data elements and transaction confirmations from different channels, the exemplary embodiment provides links between various transaction request fulfillments (with legal binding force) but can also help provide better client service with non-repudiation. In particular, with the application of Natural Language Processing (NLP) in chatbots and social media access points, providing longitudinal links is crucial not only as points of evidence but also for better understanding the context of customers (e.g., allowing for tailoring their needs and optimizing the combination of requirements for each individual client). In one exemplary embodiment, a method for deriving context and integrity from multi-channel (e.g., chatbot JIVR) client node services on a blockchain-powered commercial network can use blockchain to provide trust, data, and contextual integrity. The use of longitudinal records can extend blockchain technology to provide trusted bot consultation analytics that can reduce bias and provide clues of evidence. Furthermore, providing the integrity of links to data in various channel silos can create trusted data links that are impossible to alter (i.e., to commit fraud).

[0049] According to exemplary embodiments, artificial intelligence (AI) system nodes can be used as follows.

[0050] Combination of raw and inferred data: Raw data from different channels can be integrated, processed, and recorded as value-added inferred data / insights (e.g., voice interactions between customers and representatives / chatbots can be transcribed and stored in the system).

[0051] Multi-layered architecture for inferential data / insights: Insights can be constructed in multiple layers, where lower-level insights are used as building blocks for higher-level insights (e.g., identifying and recording the mapping of terms used by specific individuals or groups to standard financial terms, so that other predictive algorithms can operate on the “translated” transcription of individuals by representatives / chatbots).

[0052] Maintaining the relationship between predictive models and corresponding insights: Insights can be linked to the AI ​​models that generated them, facilitating a chain of evidence for predictions / recommendations made by the system.

[0053] Explicit modeling of user feedback: Similar to linking a model to its corresponding output, user feedback can be explicitly modeled as a link between users, the data they have provided, and the feedback. This allows for modeling advanced AI workflows that consist not only of data and models but also include human-in-the-loop paradigms.

[0054] Suggested Chain of Evidence: Storing the entire source of insights (i.e., data, models, and user feedback) can allow for the generation of a chain of evidence that explains how the insights or recommendations were generated. This can be used to provide explanatory services that can help (a) debug and improve the system, (b) build trust in the system (for developers and / or end users), and (c) meet reporting requirements for system predictions.

[0055] Improving predictions over time: Multi-layered origin information can also be used to propagate improvements from a single AI component to all inference data that may have already been generated from a particular component before the improvement occurred. For example, if a transcription component has been improved to better handle certain dialects, the system can use origin information to identify and update information generated from previous versions of the transcription component to improve the quality of the generated output and all other insights that depend on it.

[0056] Figure 1 A logical network diagram is shown according to an example embodiment for maintaining the context integrity of multi-channel services in a blockchain network.

[0057] refer to Figure 1 Example network 100 includes a data processing node 102 connected to a data collection server 105. Data processing node 102 can be connected to a blockchain 106, which has a ledger 108 for storing data links. While this example describes only one data processing node 102 in detail, multiple such nodes can be connected to the blockchain 106. It should be understood that data processing node 102 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of data processing node 102 disclosed herein. Data processing node 102 may be a computing device or server computer, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or another hardware device. Although a single processor 104 is shown, it should be understood that data processing node 102 may include multiple processors, multiple cores, etc., without departing from the scope of the data processing node 102 system.

[0058] Data processing node 102 may also include a non-transient computer-readable medium 112, which may have machine-readable instructions stored thereon that are executable by processor 104. Examples of machine-readable instructions are shown as 114-120 and discussed further below. Examples of non-transient computer-readable medium 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store the executable instructions. For example, non-transient computer-readable medium 112 may be random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), hard disk, optical disk, or other types of storage devices.

[0059] Processor 104 can execute machine-readable instructions 114 to receive inferred data objects from a multichannel data server via blockchain 106. As described above, blockchain ledger 108 can store links 110 of data. The blockchain 106 network can be configured to use one or more smart contracts that manage transactions of multiple participating nodes. Processor 104 can execute machine-readable instructions 116 to sort the vertical records contained in the inferred data objects. Processor 104 can execute machine-readable instructions 118 to link transaction results and inferred data from the inferred data objects to the sorted vertical records. Processor 104 can execute machine-readable instructions 120 to record the linked data onto blockchain ledger 108.

[0060] Figure 2A This illustrates a blockchain architecture configuration 200 according to an exemplary embodiment. (Refer to...) Figure 2A The blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain nodes 202. Blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are shown only as an example). These nodes participate in many activities, such as the blockchain transaction addition and confirmation process (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain nodes in the architecture 200. A blockchain node may initiate blockchain authentication and attempt to write to the immutable blockchain ledger stored in blockchain layer 216, and copies of which may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created and maintain its own state, control its own assets, and receive external information according to the customized configuration sought by the participants. This can be deployed as transactions and installed on all blockchain nodes 204-210 by attaching to the distributed ledger.

[0061] The blockchain infrastructure or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure for receiving and storing new transactions and providing access to auditors attempting to access data entries. The blockchain layer 216 may expose interfaces providing access to the processor code and the virtual execution environment necessary for participation in the physical infrastructure 214. The cryptographic trust service 218 can be used to verify transactions (such as asset exchange transactions) and maintain information privacy.

[0062] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. Code 220 can control blockchain assets. For example, code 220 can store and transfer data, and can be executed by nodes 204-210 in the form of smart contracts and associated chained code with conditions or other code elements affected by their execution. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or other notifications affected by changes, updates, etc. Smart contracts themselves can be used to identify rules associated with authorization and access requirements and use of the ledger. For example, inferred data 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. Result 228 may include links to the data. Physical infrastructure 214 can be used to retrieve any data or information described herein.

[0063] Smart contracts can be created using high-level applications and programming languages ​​and then written into blocks in a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated using 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 fulfillment of conditions associated with the smart contract. Execution of a smart contract can trigger trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution can be automatically replicated throughout the distributed network of blockchain peers via one or more consensus protocols.

[0064] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the outputs of different logical operations to the blockchain. The code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or encrypted and maintained as private. Temporary data used / generated by smart contracts is stored in memory by the provided execution environment and then deleted once the data needed by the blockchain is identified.

[0065] Chaincode can include a code interpretation of a smart contract with additional features. As described herein, chaincode can be program code deployed on a computing network, where it is executed and verified together by chain confirmers during the consensus process. Chaincode receives hashes and retrieves hashes from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. Chaincode can write data associated with cryptographic details to the blockchain.

[0066] Figure 2B An example of a blockchain transaction process 250 between nodes of a blockchain according to an exemplary embodiment is shown. (Reference) Figure 2B The transaction process may include a transaction proposal 291 sent by client node 260 to endorsing peer node 281. Endorsing peer 281 verifies the client's signature and executes a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read from the chaincode (read set), and a set of key / value versions written to the chaincode (write set). If approved, a proposal response 292, along with the endorsement signature, is sent back to client 260. Client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to ordering service node 284. Ordering service node 284 then delivers the ordered transactions as blocks to all peers 281-283 on the channel. Each peer 281-283 may verify the transaction before it is committed to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct allocation for the specified peer has been signed and verify the signature against the transaction payload 293.

[0067] Refer again Figure 2B Client node 260 initiates transaction 291 by constructing a request and sending it to peer node 281, which acts as the endorser. Client 260 may include an application utilizing a supported software development kit (SDK) that leverages available APIs to generate a transaction proposal. This proposal is a request to call a chaincode function to allow data to be read and / or written to the ledger (i.e., writing new asset key-value pairs). The SDK can act as a shim to encapsulate the transaction proposal into an appropriate architectural format (e.g., a protocol buffer over a remote procedure call (RPC)) and use the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0068] In response, endorsing peer 281 verifies that (a) the transaction proposal is well-formed, (b) the transaction has not been committed in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, client 260) is properly authorized to execute the proposed operation on the channel. Endorsing peer 281 can take the transaction proposal input as arguments to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including response values, a read set, and a write set. However, the ledger is not updated at this time. At 292, this set of values, along with the signature of endorsing peer 281, is passed back to client 260's SDK as a proposal response 292, and the SDK parses the payload for application consumption.

[0069] In response, client 260's application checks / verifies the endorser peer's signature and compares the proposed response to determine if they are identical. If the chaincode only queries the ledger, the application will check the query response and typically will not submit the transaction to the ordering node service 284. If the client application intends to submit the transaction to the ordering node service 284 to update the ledger, the application determines whether the endorsement policy specified before submission has been satisfied (i.e., whether all peers required for the transaction have endorsed it). Here, the client may include only one of the many parties to the transaction. In this case, each client may have its own endorser node, and each endorser node will be required to endorse the transaction. This architecture ensures that even if an application chooses not to check the response or otherwise forwards an unendorsed transaction, the endorsement policy will still be enforced by the peers and maintained during the submission verification phase.

[0070] After a successful check, in step 293, client 260 assembles the endorsements into a transaction and broadcasts the transaction proposal and response to sorting node 284 within the transaction message. The transaction may contain a read set / write set, endorser peer signatures, and a channel ID. Sorting node 284 does not need to check the entire contents of the transaction to perform its operation; instead, it can simply receive transactions from all channels in the network, sort them chronologically by channel, and create a transaction block for each channel.

[0071] The block of transactions is delivered from sorting node 284 to all peer nodes 281-283 on the channel. Transactions 294 within the block are verified to ensure the endorsement policy is satisfied and that the ledger state of the read set variables has not changed since the read set was generated by the transaction execution. Transactions within the block are marked as valid or invalid. Furthermore, in step 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. An event is emitted to notify the client application that the transaction (call) has been immutably appended to the chain, and to indicate whether the transaction has been verified or invalidated.

[0072] Figure 3A An example of a permissioned blockchain network 300 characterized by a distributed, decentralized peer-to-peer architecture is shown. In this example, blockchain user 302 can initiate transactions to permissioned blockchain 304. In this example, transactions can be deployments, invocations, or queries, and can be published via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 306, such as auditors. Blockchain network operator 308 manages member permissions, such as registering regulator 306 as an "auditor" and blockchain user 302 as a "client." Auditors may be limited to querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0073] Blockchain developer 310 can write chaincode and client-side applications. Blockchain developer 310 can deploy chaincode directly to the network via an interface. To include credentials from traditional data source 312 in the chaincode, developer 310 can use an out-of-band connection to access the data. In this example, blockchain user 302 connects to permissioned blockchain 304 via peer node 314. Before any transaction is made, peer node 314 retrieves the user's registration and transaction certificates from certificate authority 316, which manages user roles and permissions. In some cases, blockchain users must possess these digital certificates to transact on permissioned blockchain 304. Meanwhile, users attempting to utilize chaincode may need to verify their credentials on traditional data source 312. To confirm user authorization, the chaincode can use an out-of-band connection to this data via traditional processing platform 318.

[0074] Figure 3BAnother example of a permissioned blockchain network 320 characterized by a distributed, decentralized peer-to-peer architecture is shown. In this example, blockchain user 322 can submit transactions to permissioned blockchain 324. Transactions in this example can be deployments, invocations, or queries, and can be published via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 326, such as auditors. Blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and blockchain user 322 as "clients." Auditors may be limited to querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0075] Blockchain developer 330 writes chaincode and client-side applications. Blockchain developer 330 can deploy the chaincode directly to the network via an interface. To include credentials from a traditional data source 332 in the chaincode, developer 330 can use an out-of-band connection to access the data. In this example, blockchain user 322 connects to the network via peer node 334. Before any transaction is made, peer node 334 retrieves the user's registration and transaction certificates from a certificate authority 336. In some cases, blockchain users must possess these digital certificates to transact on the permissioned blockchain 324. Meanwhile, users attempting to utilize the chaincode may need to verify their credentials on the traditional data source 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to this data via a traditional processing platform 338.

[0076] In some embodiments, the blockchain described herein can be a permissionless blockchain. Compared to permissioned blockchains that require permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting transactions, thereby adding entries to the ledger. Furthermore, all parties can choose to run a node on the system and employ a mining protocol to help verify transactions.

[0077] Figure 3CThe process 350 of a transaction processed by a permissionless blockchain 352 comprising multiple nodes 354 is illustrated. A sender 356 wishes to send payment or some other form of value (e.g., contract, medical record, agreement, goods, services, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the receiver device 358 may have a digital wallet (associated with the blockchain 352) that provides a user interface control and displays transaction parameters. In response, the transaction is broadcast through the blockchain 352 to the nodes 354. Depending on the network parameters of the blockchain 352, the nodes verify the transaction 360 based on rules established by the creator of the permissionless blockchain 352 (which may be predefined or dynamically assigned). For example, this may include verifying the identities of the parties involved. The transaction may be verified immediately, or it may be queued with other transactions, and the nodes 354 determine whether the transaction is valid based on the network rule set.

[0078] In structure 362, valid transactions are formed into blocks and sealed with locks (hashes). This process can be performed by mining nodes in node 354. Mining nodes can utilize additional software specifically designed for mining and creating blocks in the permissionless blockchain 352. Each block can be identified by a hash (e.g., 256 bits) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header of the previous block in the chain, and a set of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure, independent blockchain.

[0079] Before a block can be added to the blockchain, it must be verified. Verification of a permissionless blockchain (352) may include proof-of-work (PoW), which is the solution to a puzzle derived from the block header. While in Figure 3C The example is not shown, but another process for verifying blocks is Proof-of-Stake. Unlike Proof-of-Work, where the algorithm rewards miners who solve mathematical problems, with Proof-of-Stake, the creator of a new block is chosen in a determined manner based on their wealth (also defined as "stake"). A similar proof is then performed by the selected / chosen node.

[0080] By mining 364 blocks, nodes attempt to solve a block by incrementally changing a variable until a solution satisfies the network's overall goal. This creates a Proof-of-Work (PoW) mechanism, ensuring a correct answer. In other words, a potential solution must prove that computational resources are exhausted while solving the problem. In some types of permissionless blockchains, miners are rewarded with value (e.g., coins) for correctly mining blocks.

[0081] Here, the PoW process, along with the chain of blocks, makes the blockchain extremely difficult to modify because an attacker would have to modify all subsequent blocks to make a modification to one block acceptable. Furthermore, as new blocks are mined, the difficulty of modifying a block increases, and the number of subsequent blocks also increases. Through distribution 366, successfully verified blocks are distributed through the permissionless blockchain 352, and all nodes 354 add the block to the majority chain of the auditable ledger of the permissionless blockchain 352. Additionally, the value in the transaction submitted by the sender 356 is stored or otherwise transferred to the digital wallet of the recipient device 358.

[0082] Figure 4A A flowchart 400 illustrates an example method for maintaining the contextual integrity of multi-channel services in a blockchain network according to an example embodiment. (Refer to...) Figure 4A Method 400 may include one or more steps as described below.

[0083] Figure 4A This shows the data processing node 102 (see Figure 1 The flowchart shows the example method being executed. It should be understood that... Figure 4A The method 400 shown may include additional operations, and some of the operations described herein may be removed and / or modified without departing from the scope of method 400. For illustrative purposes, the description of method 400 also refers to... Figure 1 The features described herein. Specifically, the processor 104 of data processing node 102 can perform some or all of the operations included in method 400.

[0084] refer to Figure 4A In box 412, processor 104 can receive inferred data objects from a multichannel data server via the blockchain. In box 414, processor 104 can sort the vertical records contained in the inferred data objects. In box 416, processor 104 can link transaction results and inferred data from the inferred data objects to the sorted vertical records. In box 418, processor 104 can record the linked data onto the blockchain ledger.

[0085] Figure 4B A flowchart 450 illustrates an example method according to an example embodiment. (See reference...) Figure 4BMethod 450 may further include one or more of the following steps. In box 452, processor 104 may derive longitudinal records from the inferred data object. Note that the inferred data may include robot consultation data, and the inferred data object may represent merged data from multiple full channels. In box 454, processor 104 may extract contextual integrity data from the inferred data object. In box 456, processor 104 may link the contextual integrity data to transaction results. In box 458, processor 104 may link the predictive model to corresponding insights generated by the AI ​​nodes.

[0086] Figure 5A An exemplary system 500 is shown, including physical infrastructure 510 configured to perform various operations according to an exemplary embodiment. References Figure 5A Physical infrastructure 510 includes modules 512 and 514. Module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which can perform any operational step 508 (in module 512) included in any exemplary embodiment. Step / operation 508 may include one or more of the described or illustrated embodiments and may represent output or write information written or read from one or more smart contracts 530 and / or blockchain 520. Physical infrastructure 510, module 512, and module 514 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, module 512 and module 514 may be the same module.

[0087] Figure 5B Another example system 540, configured to perform various operations according to an exemplary embodiment, is shown. (Reference) Figure 5B System 540 includes modules 512 and 514. Module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520). The smart contract 530 can perform any operational step 508 (in module 512) included in any exemplary embodiment. Step / operation 508 may include one or more of the described or illustrated embodiments and may represent output or write information written or read from one or more smart contracts 530 and / or blockchain 520. Physical infrastructure 510, modules 512, and 514 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, modules 512 and 514 may be the same module.

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

[0089] Figure 5D A system 560 including a blockchain is shown according to an exemplary embodiment. Reference Figure 5D As an example, Application Programming Interface (API) Gateway 562 provides a public interface for accessing blockchain logic (e.g., smart contract 530 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API Gateway 562 is a public interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 552 and 556 to the blockchain peer (i.e., server 554). Here, server 554 is a blockchain network peer component that holds a copy of the world state and the distributed ledger, allowing clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, whereby the endorsing peer will run smart contract 530 according to smart contract 530 and the endorsement policy.

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

[0091] An exemplary storage medium can be coupled to a processor, allowing the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be integrated with the processor. The processor and storage medium can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium can reside as discrete components.

[0092] Figure 6AThis illustrates a process 600 of adding a new block to a distributed ledger 620 according to an exemplary embodiment. Figure 6B This illustrates the contents of a new data block structure 630 of a blockchain according to an exemplary embodiment. (Reference) Figure 6A A client (not shown) may submit transactions to blockchain nodes 611, 612, and / or 613. The client can receive instructions from any source to formulate activities on blockchain 620. As an example, the client may be an application proposing transactions for the blockchain on behalf of a requester (such as a device, individual, or entity). Multiple blockchain peers (e.g., blockchain nodes 611, 612, and 613) may maintain the state of the blockchain network and copies of the distributed ledger 620. Different types of blockchain nodes / peers may exist in the blockchain network, including endorsing peers that simulate and endorse transactions proposed by clients, and submitting peers that verify endorsements, verify transactions, and submit transactions to the distributed ledger 620. In this example, blockchain nodes 611, 612, and 613 may act as endorsing nodes, submitting nodes, or both.

[0093] Distributed ledger 620 comprises a blockchain storing immutable, ordered records in blocks and a state database 624 (current world state) maintaining the current state of blockchain 622. Each channel can have its own distributed ledger 620, and each peer maintains its own copy of the distributed ledger 620 for each channel in which they are members. Blockchain 622 is a transaction log constructed as hash-linked blocks, where each block contains a sequence of N transactions. Blocks may include, for example, Figure 6B The various components shown. Links between blocks (by...) Figure 6A (As shown by the arrow in the diagram) can be generated by appending the hash of the previous block's header to the current block's header. In this way, all transactions on blockchain 622 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the latest block in blockchain 622 represents every transaction that occurred before it. Blockchain 622 can be stored on a peer-to-peer file system (local or attached storage) that supports only attached blockchain workloads.

[0094] The current state of blockchain 622 and the distributed ledger 622 can be stored in a state database 624. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of blockchain 622. Chaincode calls execute transactions by referring to the current state in state database 624. To make these chaincode interactions highly efficient, all the latest values ​​are stored in state database 624. State database 624 can include an indexed view of the transaction log of blockchain 622, and therefore can be regenerated from the chain at any time. State database 624 can be automatically restored (or generated when needed) before a transaction is accepted.

[0095] Endorsing nodes receive transactions from clients and endorse them based on the simulation results. The endorsing node holds a smart contract containing the simulated transaction proposal. When an endorsing node endorses a transaction, it creates a transaction endorsement, a signed response from the endorsing node 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 ordering service 610.

[0096] The ordering service 610 accepts endorsed transactions, orders them into blocks, and delivers the blocks to the committing peers. For example, the ordering service 610 can initiate a new block if a transaction threshold has been reached, a timer has expired, or another condition has been met. Figure 6A In the example, blockchain node 612 is a peer that has received a submission to store a new data block 630 on blockchain 620. The first block in a blockchain can be called the generating block, which includes information about the blockchain, its members, the data stored therein, etc.

[0097] The sorting service 610 can consist of a cluster of sorters. The sorting service 610 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the sorting service 610 can accept endorsed transactions and specify the order in which they are submitted to the distributed ledger 620. The architecture of the blockchain network can be designed such that the specific implementations of 'sorting' (e.g., Solo, Kafka, BFT, etc.) become pluggable components.

[0098] Transactions are written to the distributed ledger 620 in a consistent order. This ordering ensures that updates to the state database 624 are effective when transactions are submitted to the network. Unlike cryptocurrency blockchain systems where ordering occurs through solving cryptographic puzzles or mining (e.g., Bitcoin), in this example, the parties to the distributed ledger 620 can choose the ordering mechanism best suited to the network.

[0099] When the sorting service 610 initializes a new data block 630, it can broadcast the new data block 630 to commit peers (e.g., blockchain nodes 611, 612, and 613). In response, each commit peer verifies the transactions within the new data block 630 by checking to ensure that the read set and write set still match the current world state in the state database 624. Specifically, the commit peer can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 624. When the commit peer verifies the transaction, the transaction is written to blockchain 622 on the distributed ledger 620, and the state database 624 is updated with the write data from the read-write set. If the transaction fails, i.e., if the commit peer finds that the read-write set does not match the current world state in the state database 624, the transaction sorted 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.

[0100] refer to Figure 6B A new data block 630 (also called a data block) stored on 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 understood that the various blocks and their contents shown, such as... Figure 6B The new data block 630 and its contents shown 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 transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 650. The new data block 630 may also include (e.g., ...) information within the block header 640. Figure 6A The block header 622 (on the blockchain) is a link pointing to the previous block. Specifically, the block header 740 may include the hash of the previous block header. The block header 640 may also include a unique block number, the hash of the block data 650 of the new data block 630, and so on. The block number of the new data block 630 can be unique and assigned in various orders, such as starting from zero in an ascending / continuous order.

[0101] Block data 650 can store transaction information for each transaction recorded within new data block 630. For example, transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of distributed ledger 620, transaction ID, epoch, payload visibility, chaincode path (deployment transaction), chaincode name, chaincode version, chaincode type, inputs (chaincode and functions), client (creator) identifiers such as public keys and certificates, client signature, endorser identity, endorser signature, proposal hash, chaincode events, 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, key list, Merkel tree query digest, etc. Transaction data can be stored for each of N transactions.

[0102] In some embodiments, block data 650 may also store new data 662 of the hash-linked block chain that adds additional information to the block chain 622. The additional information includes one or more of the steps, features, processes, and / or actions described or illustrated herein. Therefore, new data 662 may be stored in the immutable log of the blocks on the distributed ledger 620. Some benefits of storing this new data 662 are reflected in the various embodiments disclosed and illustrated herein. Although new data 662 in Figure 6B This is shown in block data 650, but it could also be located in block header 640 or block metadata 660. New data 662 could include links between data between transaction results and inference data.

[0103] Block metadata 660 can store multiple fields of metadata (e.g., as a byte array). Metadata fields may include a signature about block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, the last offset of the sorting service that sorts the blocks, etc. The signature, the last configured block, and sorter metadata can be added by the sorting service 610. Meanwhile, the block submitter (such as blockchain node 612) can add valid / invalid information based on endorsement policies, verification of read / write sets, etc. Transaction filters may include a byte array of size equal to the number of transactions included in block data 650 and a verification code identifying whether a transaction is valid / invalid.

[0104] 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 associated information. Files may contain media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only nature of blockchain provides a guarantee for protecting the integrity, validity, and authenticity of digital content, thereby making it suitable for legal proceedings to which admissibility rules apply, or for other environments where evidence is considered, or for other environments of interest in the presentation and use of digital information. In this context, digital content can be referred to as digital evidence.

[0105] Blockchains can be formed in various ways. In one embodiment, digital content can be included within and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of referencing information (e.g., header, value, etc.) along with its 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 the basis for referencing the previous block. This can be illustrated as follows:

[0106] Block 1 Block 2 ... Block N

[0107] Hash value 1 Hash value 2 Hash value N

[0108] Digital content 1 Digital content 2 Digital content N

[0109] In one embodiment, digital content may not be included in the blockchain. For example, the blockchain could store a cryptographic hash of the content of each block without any digital content. The digital content could be stored in a separate storage area or memory address associated with the hash value of the original file. This other storage area could be the same storage device used to store the blockchain, or it could be a different storage area or even a separate relational database. By obtaining or querying the hash value of the block of interest, and then finding the hash value stored in the storage area corresponding to the actual digital content, the digital content of each block can be referenced or accessed. This operation can be performed, for example, by a database gatekeeper. This can be illustrated as follows:

[0110]

[0111]

[0112] exist Figure 6C In an exemplary embodiment, the blockchain 660 includes a plurality of blocks 6781, 6782, ..., 678 cryptographically linked in sorted order. N Where N≥1. Used to link blocks 6781, 6782, ..., 678 NThe encryption can be any function of multiple keyed or non-keyed hash functions. In one embodiment, blocks 6781, 6782, ..., 678... N The hash function obeys an input based on information in the block and produces an n-bit alphanumeric output (where n is 256 or another number). Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number-based algorithms, and collision-resistant PRF algorithms. In another embodiment, blocks 6781, 6782, ..., 678... N Cryptographic links can be created using functions other than hash functions. For illustrative purposes, the following description refers to hash functions (e.g., SHA-2).

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

[0114] The first block 6781 in the blockchain is called the generating block, and it includes a header 6721, the original file 6741, and an initial value 6761. The hashing scheme used to generate this block, and indeed in all subsequent blocks, may differ. For example, all the information in the first block 6781 can be hashed together at once, or each or part of the information in the first block 6781 can be hashed separately, and then the hashing of the separately hashed parts can be performed.

[0115] The header 6721 may include one or more initial parameters, which may include, for example, a version number, timestamp, random number, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 6741 and / or the blockchain. The header 6721 may be generated automatically (e.g., via blockchain network management software) or manually by blockchain participants. This is related to other blocks 6782 to 6783 in the blockchain. N Unlike the previous block, the header 6721 in the generated block does not reference the previous block because there is no previous block.

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

[0117] The value 6761 in the generated 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 the hash value of the original file 6741, the metadata of the original file 6741, and other information associated with the file. In one embodiment, the initial value 6761 may be based on the following unique attributes:

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

[0119] 2) Originating Device ID

[0120] 3) Start timestamp of the original file

[0121] 4) Initial storage location of the original file

[0122] 5) The blockchain network member ID that currently controls the original file and associated metadata of the software.

[0123] Other blocks 6782 to 678 in the blockchain N It also has a header, filename, and value. However, unlike the first block 6721, the headers 6722 to 672 in the other blocks are different. N Each of the remaining blocks includes the hash of the immediately preceding block. The hash of the preceding block can be either the hash of the header of the preceding block or the hash of the entire preceding block. By including the hash of the preceding block in each of the remaining blocks, a traceback from the Nth block back to the generating block (and the associated original file) can be performed block by block, as shown by arrow 680, to establish an auditable and immutable chain of custody.

[0124] The heads 6722 to 672 of the other blocks N Each of these may also include other information, such as version number, timestamp, random number, root information, difficulty level, consensus protocol and / or other parameters or information associated with the corresponding file and / or blockchain.

[0125] Files 6742 to 674 in other blocks NIt can be equal to the original file, or it can be a modified version of the original file in the generated block, depending on, for example, the type of processing performed. The type of processing performed can vary from block to block. For example, the processing can involve any modification to the file in a previous block, such as editing information or otherwise changing the contents of the file, removing information from the file, or adding or appending information to the file.

[0126] Alternatively or concurrently, the processing may involve copying a file only from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing actions relative to the file and / or its associated metadata on the blockchain. Processes involving file analysis may include, for example, appending, including, or otherwise associating different analyses, statistics, or other information associated with the file.

[0127] Other blocks 6762 to 676 in other blocks N Each value in a block is unique and distinct depending on the processing performed. For example, a value in any given block corresponds to an updated version of the value in the previous block. This update is reflected in the hash of the block to which the value was assigned. The block's value thus provides an indication of what processing was performed within the block and also allows for tracing back to the original file via the blockchain. This tracing confirms the file's chain of control throughout the blockchain.

[0128] For example, consider a scenario where portions of a file in a previous block were edited, masked, or pixelated to protect the identity of the person shown in the file. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the edit was performed, who performed the edit, and the timestamp of the edit. This metadata can be hashed to form values. Because the metadata of a block differs from the information hashed to form values ​​in the previous block, these values ​​are distinct from each other and can be recovered during decryption.

[0129] In one embodiment, 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 when any one or more of the following occur. In this exemplary embodiment, a new hash value can be calculated by hashing all or part of the information indicated below.

[0130] a) The hash value calculated using the new SHA-2 algorithm, if the file has been processed in any way (e.g., if the file has been edited, copied, altered, accessed, or subjected to some other action).

[0131] b) New storage location of the file

[0132] c) New metadata identified that is associated with the file

[0133] d) Transferring access to or control of files from one blockchain participant to another.

[0134] Figure 6D This illustration shows an embodiment of a block that, according to one embodiment, can represent the structure of a block in blockchain 690. The block... i Including the first 672 i Document 674 i Sum of 676 i .

[0135] Head 672 i Including the previous block i-1 The hash value and additional reference information are used, which can be, for example, any type of information discussed herein (e.g., header information including references, characteristics, parameters, etc.). All blocks (except, of course, the generating block) reference the hash of the previous block. The hash value of the previous block can be simply 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 file and metadata).

[0136] Document 674 i This includes multiple data sets, such as data 1, data 2, ..., data N in sequence. The data is tagged with metadata—metadata 1, metadata 2, ..., metadata N—describing the content and / or characteristics associated with the data. For example, the metadata for each data set may include a timestamp indicating the data, information about the data processing, keywords indicating the people or other content depicted in the data, and / or other characteristics that may help determine the validity and content of the overall document, particularly information about its use as digital evidence, such as as described in the embodiments discussed below. In addition to the metadata, each data set may be accompanied by references to previous data, REF1, REF2, ..., REF... N Mark the file to prevent tampering, gaps in the file, and sequential referencing.

[0137] Once metadata is assigned to data (e.g., via a smart contract), it cannot be altered without changing the hash, as this would easily be flagged as invalid. Therefore, metadata creates a data log of information that can be accessed and used by participants in the blockchain.

[0138] Value 676 i It is a hash value or another value calculated based on any type of information discussed earlier. For example, for any given block... iThe value of a block can be updated to reflect the processing performed for that 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 actions or information to be added. Although the value in each block is shown to be separate from the metadata and header of the file's data, in another embodiment, the value may be based partly or entirely on that metadata.

[0139] Once the blockchain is formed (670), at any point in time, the immutable custodian chain of a file can be obtained by querying the blockchain to retrieve the transaction history of values ​​across blocks. This query or tracing process can begin by decrypting the value of the currently included block (e.g., the last (Nth) block) and then continue decrypting the values ​​of other blocks until the generating block is reached and the original file is recovered. This decryption may also involve decrypting the header and filename of each block, as well as the associated metadata.

[0140] Decryption is performed based on the type of encryption that occurs within each block. This may involve using a private key, a public key, or a public-private key pair. For example, when using asymmetric encryption, blockchain participants or processors in the network can generate public and private key pairs using a pre-defined algorithm. The public and private keys are linked together through some mathematical relationship. The public key can be publicly distributed and used as an address to receive messages from other users, such as an IP address or home address. The private key is kept secret and 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. In this way, the recipient can be certain that only the sender could have sent the message.

[0141] Generating a key is similar to creating an account on the blockchain, but it doesn't require actual registration anywhere. Furthermore, every transaction executed 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 blockchain documents (if within the permitted scope determined by smart contracts).

[0142] Figure 7A and Figure 7B Additional examples of blockchain use cases that can be incorporated and used in this article are shown. Specifically, Figure 7A Example 700 of a blockchain 710 for storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can typically sift through millions of records to discover non-intuitive patterns.

[0143] exist Figure 7AIn the example, host platform 720 builds and deploys a machine learning model for predictive monitoring of asset 730. Here, host platform 720 can be a cloud platform, industrial server, web server, personal computer, user equipment, etc. Asset 730 can be any type of asset (e.g., machinery or equipment), such as aircraft, locomotives, turbines, medical machines and equipment, oil and gas equipment, ships, vessels, vehicles, etc. As another example, asset 730 can be an intangible asset, such as stocks, currency, digital currency, insurance, etc.

[0144] Blockchain 710 can be used to significantly improve the training process 702 of machine learning models and the prediction process 704 based on the trained machine learning models. For example, in 702, instead of requiring data scientists / engineers or other users to collect data, historical data can be stored on blockchain 710 by asset 730 itself (or through an intermediary, not shown). This can significantly reduce the collection time required by host platform 720 when performing predictive model training. For example, using smart contracts, data can be sent directly and reliably from its origin location to blockchain 710. By using blockchain 710 to ensure the security and ownership of the collected data, smart contracts can directly send data from assets to individuals using that data to build machine learning models. This allows data to be shared between assets 730.

[0145] The collected data can be stored in a consensus-based blockchain 710. The consensus mechanism pulls in (permissioned nodes) to ensure that the recorded data is verified and accurate. The recorded data is timestamped, cryptographically signed, and immutable. Therefore, it is auditable, transparent, and secure. In some cases (i.e., supply chains, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of the recorded data.

[0146] Furthermore, the training of the machine learning model on the collected data may require multiple rounds of fine-tuning and testing by the host platform 720. Each round can help expand the knowledge of the machine learning model based on additional or previously unconsidered data. In 702, the different training and testing steps (and the associated data) can be stored on the blockchain 710 by the host platform 720. Each fine-tuning of the machine learning model (e.g., changes to variables, weights, etc.) can be stored on the blockchain 710. This provides verifiable evidence of how the model was trained and what data was used to train it. Additionally, once the host platform 720 has achieved the final trained model, the resulting model can be stored on the blockchain 710.

[0147] After training, the model can be deployed to a field environment where predictions / decision-making can be made based on the execution of the finally trained machine learning model. For example, at 704, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and healthcare machines. In this example, data feedback from asset 730 can be fed into the machine learning model for event prediction, such as failure events and error codes. Decisions made by executing the machine learning model at host platform 720 can be stored on blockchain 710 to provide auditable / verifiable evidence. As a non-limiting example, the machine learning model can predict future damage / failure of a portion of asset 730 and create an alert or notification to replace that portion. The data behind this decision can be stored on blockchain 710 by host platform 720. In one embodiment, the features and / or actions described and / or illustrated herein can occur on or about blockchain 710.

[0148] New transactions on the blockchain can be aggregated into a new block and added to an existing hash. This is then encrypted to create a new hash for the new block. As transactions are encrypted, they are added to the next list of transactions, and so on. The result is a blockchain, each containing the hashes of all previous blocks. The computers storing these blocks periodically compare their hashes to ensure they are consistent. Any computer that disagrees discards the record that causes the problem. This method helps ensure the blockchain's resistance to tampering, but it is not perfect.

[0149] For dishonest users, one way to challenge such a system is to alter the transaction list in a way that benefits them while keeping the hash unchanged. This can be done through brute force—in other words, by changing the record, encrypting the result, and then checking if the hashes match. If they don't match, this process is repeated until a matching hash is found. The security of blockchains is based on the belief that ordinary computers can only perform such brute-force attacks on completely impractical timescales (such as the age of the universe). In contrast, quantum computers are much faster (thousands of times faster) and therefore pose a much greater threat.

[0150] Figure 7B Example 750 of a quantum-secure blockchain 752 implementing quantum key distribution (QKD) to prevent quantum computing attacks is shown. In this example, blockchain users can use QKD to verify each other's identities. This utilizes quantum particles such as photons to send information, which cannot be copied by an eavesdropper without destroying them. In this way, the sender and receiver can determine each other's identities through the blockchain.

[0151] exist Figure 7BIn the example, there are four users: 754, 756, 758, and 760. Each pair of users can share a key 762 (i.e., QKD) between them. Since there are four nodes in the example, there are six node pairs, thus using six different keys 762, including QKD. AB QKD AC QKD AD QKD BC QKD BD and QKD CD Each pair can create a QKD by sending information using quantum particles (such as photons) that cannot be copied by an eavesdropper without destroying them. In this way, a pair of users can identify each other.

[0152] Blockchain 752 operates based on two processes: (i) the creation of transactions and (ii) the construction of blocks that aggregate new transactions. Creating new transactions can be similar to traditional blockchain networks. Each transaction can contain information about the sender, receiver, creation time, amount (or value) to be transferred, a list of reference transactions proving the sender has the funds for the operation, etc. This transaction record is then sent to all other nodes, where it is entered into a pool of unconfirmed transactions. Here, the two parties (i.e., a pair of users in 754-760) authenticate the transaction by providing their shared key 762 (QKD). This quantum signature can be attached to each transaction, making it extremely difficult to tamper with. Each node checks its entries relative to a local copy of blockchain 752 to verify that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0153] Instead of performing a traditional mining process, blocks can be created in a decentralized manner using a broadcast protocol. Within a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transactions, thereby achieving a correct version of the Byzantine protocol (consensus) regarding the transactions. For example, each node can possess a private value (the transaction data of that particular node). In the first round, nodes transmit their private values ​​to each other. In subsequent rounds, nodes transmit the information they received from other nodes in the previous round. Here, honest nodes are able to create a complete set of transactions within a new block. This new block can be added to blockchain 752. In one embodiment, the features and / or actions described and / or illustrated herein may occur on or relative to blockchain 752.

[0154] Figure 8An exemplary system 800 supporting one or more exemplary embodiments described and / or illustrated herein is shown. System 800 includes a computer system / server 802 that can operate with many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 802 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0155] Computer system / server 802 can be described in the general context of computer system executable instructions such as program modules executed by the computer system. Generally, 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 802 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside in local and remote computer system storage media, including memory storage devices.

[0156] like Figure 8 As shown, the computer system / server 802 in the cloud computing node 800 is illustrated in the form of a general-purpose computing device. Components of the computer system / server 802 may include, but are not limited to, one or more processors or processing units 804, system memory 806, and buses that couple the various system components, including the system memory 806, to the processor 804.

[0157] A bus represents any one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses that use any of the various bus architectures. By way of example and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0158] Computer system / server 802 typically includes a variety of computer system readable media. Such media can be any available media accessible by computer system / server 802, and includes volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 806 implements a flowchart of other figures. System memory 806 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 810 and / or cache memory 812. Computer system / server 802 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 814 may be provided for reading and writing from non-removable non-volatile magnetic media (not shown, commonly referred to as a "hard disk drive"). Although not shown, disk drives may be provided for reading from or writing to removable non-volatile disks (e.g., "floppy disks"), and optical disk drives may be provided for reading from or writing to removable non-volatile optical disks (such as CD-ROMs, DVD-ROMs, or other optical media). In such a case, each may be connected to a bus via one or more data media interfaces. As will be further shown and described below, memory 806 may include at least one program product having a set (e.g., at least one) of program modules configured to perform different embodiments of the application.

[0159] A program / utility 816 having a set (at least one) of program modules 818, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 806 by way of example and not limitation. Each or some combination of the operating system, one or more applications, other program modules, and program data may include an implementation of a network environment. Program modules 818 typically perform functions and / or methods as described herein in different embodiments of the applications.

[0160] As those skilled in the art will understand, aspects of this application may be embodied as a system, method, or computer program product. Therefore, aspects of this application may take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, collectively referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of this application may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0161] The computer system / server 802 can also communicate with one or more external devices 820 (e.g., keyboard, pointing device, display 822, etc.); and / or any device that enables the computer system / server 802 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). Such communication can occur through I / O interface 824. Furthermore, the computer system / server 802 can 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 network adapter 826. As shown, network adapter 826 communicates with other components of the computer system / server 802 via a bus. It should be understood that, although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 802. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0162] While exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media have been shown in the accompanying drawings and described in the foregoing detailed description, it will be understood that this application is not limited to the disclosed embodiments, but is capable of having many rearrangements, modifications, and substitutions set forth and defined by the following claims. For example, the capabilities of the systems in the various figures may be performed by one or more modules or components in the distributed architecture described herein, and may include transmitters, receivers, or pairs of transmitters and receivers. For example, all or part of the functionality performed by a single module may be performed by one or more of these modules. Furthermore, the functionality described herein may be performed at different times and with regard to different events inside or outside the module or component. In addition, information transmitted between the various modules may be transmitted between modules via data networks, the Internet, voice networks, Internet Protocol networks, wireless devices, wired devices, and / or via at least one of multiple protocols. Moreover, messages sent or received by any module may be sent or received directly and / or through one or more other modules.

[0163] Those skilled in the art will understand that "system" can be embodied as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting the foregoing functionality as being performed by a "system" is not intended to limit the scope of this application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in local and distributed forms consistent with computing technologies.

[0164] It should be noted that some of the system features described in this specification have been presented as modules to more specifically emphasize their implementation independence. For example, a module can be implemented as hardware circuitry, including custom VLSI circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented as programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0165] Modules can also be implemented at least partially in software and executed by various types of processors. The identified executable code units may, for example, comprise one or more physical or logical blocks of computer instructions that can be organized, for example, as objects, procedures, or functions. However, the executable files of the identified modules do not need to be physically located together, but may comprise different instructions stored in different locations that, when logically combined, comprise the module and achieve the module's stated purpose. Furthermore, the module may be stored on a computer-readable medium, which may be, for example, a hard disk drive, flash memory, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0166] In practice, a module of executable code can be a single instruction or many instructions, and can even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, operational data can be identified and represented within this module, and can be embodied in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or it can be distributed across different locations, including different storage devices, and can exist at least in part simply as electronic signals within a system or network.

[0167] It will be readily understood that, as generally described and illustrated in the accompanying drawings, these components of this application can be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application.

[0168] It will be readily understood by those skilled in the art that the above content can be practiced with steps in a different order and / or with hardware components configured differently from the disclosed configuration. Therefore, while this 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 constructions will be readily apparent.

[0169] While preferred embodiments of this application have been described, it should be understood that the described embodiments are merely illustrative, and the scope of this application will be limited only by the appended claims, in view of various equivalents and modifications thereof (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A computer system, comprising: The processor of the data processing node; The memory stores machine-readable instructions that, when executed by the processor, cause the processor to: Data is received from multiple channels between the client and the data processing node, wherein the multiple channels include an interactive voice response (IVR) channel and a chatbot channel between the user associated with the client and the data processing node; Multiple predictive insights are generated from the received data using multiple machine learning models. These multiple predictive insights include a first-layer insight and a second-layer insight in a multi-layer architecture, with the generation of the second-layer insight based on the first-layer insight. Receive user feedback on the received data; Link the multiple predictive insights, the multiple machine learning models that generated the multiple predictive insights, and user feedback to generate a chain of evidence; Record the chain of evidence into the blockchain ledger; Based on the data in the evidence chain, the variables of the multiple machine learning models are modified to train the machine learning models in multiple rounds. During the multiple rounds of training, after each round of training, the updated evidence chain is recorded in the blockchain ledger. The updated evidence chain contains detailed information describing the training method of the multiple machine learning models.

2. The system according to claim 1, wherein, The instructions further enable the processor to link the received data with the user feedback.

3. The system according to claim 1, wherein, The data received includes robot consultation data.

4. The system according to claim 1, wherein, The received data includes merged data from multiple full channels.

5. The system according to claim 1, wherein, The instructions further enable the processor to link the plurality of predictive insights with the plurality of machine learning models that generated the plurality of predictive insights.

6. A computer-implemented method, comprising: The data processing node receives data from a multi-channel data server between the client and the data processing node, wherein the multi-channel includes an interactive voice response (IVR) channel and a chatbot channel between the user associated with the client and the data processing node; The data processing node generates multiple predictive insights from the received data using multiple machine learning models. The multiple predictive insights include a first-layer insight and a second-layer insight in a multi-layer architecture, and the generation of the second-layer insight is based on the first-layer insight. The data processing node receives user feedback on the received data; The data processing node links the multiple predictive insights, the multiple machine learning models that generate the multiple predictive insights, and user feedback to generate a chain of evidence. The data processing node records the chain of evidence onto the blockchain ledger, and The data processing node modifies the variables of the multiple machine learning models based on the data in the evidence chain to train the machine learning models in multiple rounds. During each round of training, the updated evidence is then transferred to the data processing node. according to The chain is recorded in the blockchain ledger, where the updated chain of evidence contains detailed information describing how the multiple machine learning models were trained.

7. The method of claim 6, further comprising linking the received data with the user feedback.

8. The method according to claim 6, wherein, The data received includes robot consultation data.

9. The method according to claim 6, wherein, The received data objects include merged data from multiple full channels.

10. The method of claim 6, further comprising linking the plurality of predictive insights to a plurality of machine learning models that generated the plurality of predictive insights.

11. A computer program product comprising instructions that, when read by a processor, cause the processor to execute: Inference data objects are received from a multi-channel data server between the client and the data processing node, where... The multi-channel system includes an interactive voice response (IVR) channel and a chatbot channel between the client-associated user and the data processing node. Multiple predictive insights are generated from the received data using multiple machine learning models. These multiple predictive insights include a first-layer insight and a second-layer insight in a multi-layer architecture, with the generation of the second-layer insight based on the first-layer insight. Receive user feedback on the received data; Link the multiple predictive insights, the multiple machine learning models that generated the multiple predictive insights, and user feedback to generate a chain of evidence; Record the chain of evidence into the blockchain ledger; as well as Based on the data in the evidence chain, the variables of the multiple machine learning models are modified to train the machine learning models in multiple rounds. During the multiple rounds of training, after each round of training, the updated evidence chain is recorded in the blockchain ledger. The updated evidence chain contains detailed information describing the training method of the multiple machine learning models.

12. The computer program product of claim 11, further comprising instructions to link the received data with the user feedback.

13. The computer program product according to claim 11, wherein, The data received includes robot consultation data.

14. The computer program product according to claim 11, wherein, The received data objects include merged data from multiple full channels.

15. The computer program product of claim 11, further comprising, when read by a processor, instructions that cause the processor to link the plurality of predictive insights with the plurality of machine learning models that generate the plurality of predictive insights.

Images