Cognitive systems for managing consent for user data

Abstract

Example operations may include one or more of the following: receiving a request for access to user data, the request including an identification of a requestor and an identification of the data; determining, via a cognitive engine, whether to provide access to the user's data based on a context associated with the user; in response to a determination to provide access to the user's data, invoking a chaincode that retrieves access to the user's data from a blockchain and provides access to the user's data to the requestor; and storing, via a blockchain, a result of the determination made by the cognitive engine.

Description

Background Art

[0002] A centralized database stores and maintains data in a single database (e.g., a database server) at one location. The location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored on a centralized database is typically accessible from multiple different points. Multiple users or client workstations can work on a centralized database simultaneously, for example, based on a client / server configuration. A centralized database is easy to manage, maintain, and control due to its single location, especially for security purposes. In addition, because a single storage placement for all data also implies that a given data set has only one master record, data redundancy is minimized.

[0003] However, centralized databases may suffer from significant disadvantages. Specifically, centralized databases have a single point of failure. If a failure occurs (e.g., a hardware, firmware, and / or software failure), all data within the database is lost and the work of all users is interrupted. In addition, centralized databases are highly dependent on network connectivity. Therefore, the slower the connection, the more time required for each database access increases. Another disadvantage is the occurrence of bottlenecks caused by its single location when the centralized database experiences high traffic. In addition, centralized databases provide restricted access to data because only one copy of the data is maintained by the database. Therefore, multiple devices cannot access the same piece of data at the same time without creating significant problems or risks of overwriting the stored data. In addition, because the data storage system has little to no data redundancy, accidentally lost data is difficult to retrieve except through manual operations from backup storage.

[0004] Recently, blockchain has become increasingly popular due to its advantages over traditional databases. However, access to blockchain data is limited to the participants of the blockchain. Therefore, external entities may not be able to access user data stored on the blockchain. Therefore, there is a need for a solution that can provide access to user data while overcoming the significant limitations of traditional blockchains. Summary of the invention

[0005] One or an example embodiment provides a system comprising one or more of the following: a network interface configured to receive a request for access to a user's data, wherein the request includes an identification of the requestor and an identification of the data; a processor configured to perform one or more of the following: determine, via a cognitive engine, based on a context associated with the user, whether to provide access to the user's data; and in response to a determination to provide access to the user's data, invoke a chaincode, the chaincode retrieving access to the user's data from a blockchain and providing access to the user's data to the requestor; and a storage device configured to store, via the blockchain, a result of the determination performed by the cognitive engine.

[0006] Another example embodiment provides a method that includes one or more of the following: receiving a request for access to data of a user, the request including an identification of the requestor and an identification of the data; determining, via a cognitive engine, whether to provide access to the data of the user based on a context associated with the user; in response to a determination to provide access to the data of the user, invoking a chaincode, the chaincode retrieving access to the data of the user from a blockchain and providing access to the data of the user to the requestor; and storing, via the blockchain, a result of the determination made by the cognitive engine.

[0007] Yet another example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following: receiving a request for access to data of a user, the request comprising an identification of the requestor and an identification of the data; determining, via a cognitive engine, based on a context associated with the user, whether to provide access to the data of the user; in response to a determination to provide access to the data of the user, invoking a chaincode that retrieves access to the data of the user from a blockchain and provides access to the data of the user to the requestor; and storing, via the blockchain, a result of the determination made by the cognitive engine. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a diagram illustrating a computing environment including a consent management platform for managing access to user data according to an example embodiment.

[0009] Figure 2A is a diagram illustrating an example blockchain architecture configuration according to an example embodiment.

[0010] Figure 2B is a diagram illustrating a blockchain transaction flow between nodes according to an example embodiment.

[0011] Figure 3A is a diagram illustrating a permissioned network according to an example embodiment.

[0012] Figure 3B is a diagram illustrating another permission-based network according to example embodiments.

[0013] Figure 3C is a diagram illustrating an unlicensed network according to an example embodiment.

[0014] Figure 4A is a diagram illustrating a process of providing consent for a request for user data according to an example embodiment.

[0015] Figure 4B is a diagram illustrating a process of providing explicit consent and implicit consent for user data according to an example embodiment.

[0016] Figure 5 is a diagram illustrating a method of managing consent for user data via a blockchain according to example embodiments.

[0017] Fig. 6A is a diagram illustrating an example system configured to perform one or more operations described herein according to an example embodiment.

[0018] Figure 6B is a diagram illustrating another example system configured to perform one or more operations described herein according to an example embodiment.

[0019] Figure 6C is a diagram illustrating another example system configured to utilize smart contracts according to example embodiments.

[0020] Fig.6D is a diagram illustrating yet another example system configured to utilize blockchain according to example embodiments.

[0021] Fig. 7A is a diagram illustrating a process in which a new block is added to a distributed ledger according to an example embodiment.

[0022] Figure 7B is a diagram illustrating data agreement of a new data block according to example embodiments.

[0023] Figure 7C is a diagram illustrating a blockchain for digital content according to example embodiments.

[0024] Fig.7D is a diagram illustrating a block that may represent a structure of a block in a blockchain according to example embodiments.

[0025] Fig. 8A is a diagram illustrating an example blockchain storing machine learning (artificial intelligence) data according to example embodiments.

[0026] Figure 8B is a diagram illustrating an example quantum-secure blockchain according to an example embodiment.

[0027] Fig. 9 is a diagram illustrating an example system that supports one or more of the example embodiments. DETAILED DESCRIPTION

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

[0029] In one or more embodiments, features, structures and characteristics as described in the entire specification may be combined or removed in any appropriate manner. For example, the use of the phrase "exemplary embodiment", "some embodiments", or other similar language throughout the specification refers to the fact that a specific feature, structure or characteristic described in conjunction with the embodiment may be included in at least one embodiment. Therefore, the appearance of the phrase "exemplary embodiment", "in some embodiments", "in other embodiments" or other similar language throughout the specification does not necessarily refer to the same set of embodiments, and the described features, structures or characteristics may be combined in one or more embodiments or removed in one or more embodiments in any appropriate manner. In addition, in the diagram, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the accompanying drawings may be a different device. For example, if a mobile device for sending information is shown, a wired device may also be used to send information.

[0030] In addition, although the term "message" may have been used in the description of the embodiment, the application can be applicable to many types of networks and data. In addition, although some types of connections, messages and signal transmissions can be depicted in exemplary embodiments, the application is not limited to specific types of connections, messages and signal transmissions.

[0031] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide a cognitive system for managing consent for user data stored on a blockchain.

[0032] In one embodiment, the present application utilizes a decentralized database (such as blockchain), which is a distributed storage system including multiple nodes communicating with each other. The decentralized database includes an immutable data structure that is only added, which is similar to a distributed ledger that can maintain records between mutually distrusted entities. Untrusted entities are referred to as peers or peer nodes in this article. Each peer maintains a copy of the database record, and no peer can modify the database record without reaching a consensus between distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build hash chains on these blocks. The process forms an account book by sorting storage transactions for consistency when necessary. In various embodiments, a permissioned blockchain and / or a permissionless blockchain can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can include native cryptocurrency and use consensus based on various protocols such as proof of work (PoW). On the other hand, a permissioned blockchain database provides secure interactions between a group of entities (such as businesses exchanging funds, goods, information, etc.) that share a common goal but do not fully trust each other.

[0033] The present application may utilize a blockchain that operates arbitrary programmable logic that is customized for a decentralized storage solution and is referred to as a "smart contract" or "chain code". In some cases, specialized chain codes may exist for management functions and parameters referred to as system chain codes. The present application may also utilize a smart contract, which is a trusted distributed application that utilizes the tamper-proof nature of the blockchain database and the underlying protocol between nodes, which is referred to as an endorsement or endorsement policy. Blockchain transactions associated with the present application may be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. An endorsement policy allows a chain code to specify endorsers for a transaction in the form of a set of peer nodes necessary for endorsement. When a client sends a transaction to a peer specified in an endorsement policy, the transaction is executed to verify the transaction. After verification, the transaction enters a sorting phase, in which a consent protocol is used to generate an ordered sequence of endorsed transactions, which are grouped into blocks.

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

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

[0036] The present application can utilize a chain as a transaction log, which is constructed as a hash-linked block, and each block contains a sequence of N transactions, where N is equal to or greater than one. The block header includes a hash of the transactions of the block and a hash of the header of the previous block. In this way, all transactions on the ledger can be serialized and linked together in an encrypted manner. Therefore, the ledger data cannot be tampered with without breaking the hash link. The hash of the most recently added blockchain block represents each transaction that has come before it on the chain, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage device, cloud, etc.), thereby effectively supporting the only add nature of blockchain workloads.

[0037] The current state of the immutable ledger represents the latest values ​​for all keys included in the chain transaction log. Since the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Chaincode invocations execute transactions against the current state data of the ledger. In order for these chaincode interactions to be effective, the latest values ​​of the keys can be stored in the state database. The state database can simply be an indexed view into the chain's transaction log, so it can be regenerated by the chain at any time. The state database can be automatically restored (or generated if needed) when the peer node starts and before the transaction is accepted.

[0038] Although digitalization has revolutionized and increased the amount of data generated about individuals, its overall management on a secure platform still has gaps to fill. The diversity of data sets can range from static data such as demographics to more dynamic data such as social network data, location data, etc. Technologies such as the Internet of Things (IoT) have driven the increase of sensors that can capture, monitor, process and measure data in real time. At the center of these types of data is an individual who fully owns the data and the use of any such data by interested entities in the ecosystem must be consented by him / her. Although the topic of data privacy is not new and regulations such as the General Data Protection Regulation (GDPR) are in place, traditional data access solutions often address consent in a siloed manner.

[0039] Currently, there is no consolidated customer consent profile that can be controlled, managed and accessed by the customer. Customers do not have the ability to assign rights to use or share this data as needed. Additionally, there is no record of consent update events that would enable auditability and transparency, thereby building additional confidence and minimizing disputes over consent (e.g., permission to update personal information (such as bank details) is limited to the individual themselves and statically identified individuals (e.g., family members, etc.)).

[0040] To address the concept of dynamic consent, example embodiments relate to a secure blockchain platform (i.e., a consent management platform) that is capable of managing consent for access to user data in both implicit and explicit scenarios. Here, the platform can provide a "consent as a service" capability that can be used whenever any entity (e.g., a data requester, such as a service provider, a medical office, an agent, etc.) requires data stored on the blockchain about an individual. According to various embodiments, a smart contract (chain code) can define and scope the user's data that can be shared / accessed. For example, health-related information can be subscribed to by relevant entities such as emergency service providers, etc. As another example, do not interfere (DND) related information may be useful for service providers (such as telecommunications service providers, advertisers, etc.).

[0041] Smart contracts can be managed or otherwise controlled by a cognitive engine that can receive a user's context, a user's situation, a weather event, a medical condition, etc., and make a decision about whether to provide consent (access) to user data to one or more other entities (such as a hospital, a service provider, an advertiser, etc.). The cognitive engine can determine to provide consent in some cases and not allow consent in other cases. For example, the cognitive engine can detect that the user has a specific condition, an event has occurred, the user is in a specific place, etc., and implicitly enable access to the data based on such context. As a non-limiting example, when it is determined that the user has been in a traffic accident or has a medical condition (e.g., a stroke, etc.), the cognitive engine can provide consent to share very necessary health statistics (heart rate, blood pressure) with a health care provider. For example, the cognitive engine can provide dynamic information to the smart contract that identifies which data of the user can be accessed based on the context, and the smart contract can obtain access information for such data.

[0042] Some advantages of the consent management platform described and depicted herein include the ability to provide access to data to a requester based on explicit or implicit consent. When there is evidence of consent that has been explicitly obtained, the system can generate identification logic that is necessary to allow the request to access which data and provide such access. However, when consent has not yet been given explicitly, but there is sufficient contextual reason for providing access to information about certain attributes of the user, the cognitive engine can decide and provide implicit consent. The consent management platform allows user data to be kept private, but at the same time provides access in various cognitive situations where the context of such access is determined to be necessary, important, etc. In addition, the reasons or evidence behind why such implicit consent is provided by the cognitive engine can be stored on the blockchain, thereby providing evidence for any subsequent disputes.

[0043] The consent management platform described in this article can take advantage of the native capabilities of blockchain. For example, each access request to data of interest (user data) can be agreed to based solely on a consensus mechanism between participants of the blockchain (without a single central authority). These participants are typically untrusted entities, meaning that consensus is not controlled by any single user. In addition, approved requests and failed requests can be recorded in a tamper-proof manner via blocks stored in a distributed ledger. Therefore, an audit trail of access requests to data can be used to be learned by a cognitive engine that identifies trends in successful and failed endorsements and their causes. Customers (data requesters) and producers (data owners) can be identified based on corresponding keys assigned by the blockchain. For the purpose of auditability and complaint resolution, the detailed origin of the data of interest can be used.

[0044] Example embodiments also improve computer functionality through blockchain. The consent management platform can store the customer's data in a selective manner, explicit consent information can be captured after a specific template, and the template can be mapped to a category. Therefore, if a user has given consent to a health care organization (which provides a certain type of service), the consent is captured with reference to a template that classifies consent into a category or a group (e.g., a medical provider). In the case where implicit consent is required, if the consent giver has given consent to an organization (which is mapped to the same / similar category), it is more likely to achieve a decision on consent. The role of the blockchain here is to ensure that neither the template data nor the consent data is under the control of an entity / participant, which allows them to tamper with the data according to their needs. Another advantage of storing data on a blockchain is that each access to the data of interest (not consent data) is achieved through consensus, and participating entities with explicit consent can endorse transactions based on implicit consent.

[0045] Thanks to the consent management platform, new data is stored on the blockchain. For example, consent data (evidence of consent) can be stored within block content such as transactions. In addition, as part of an example embodiment, new data fields for indicating implicit or explicit access to data can be included in the metadata section. For example, whether the stored consent data in a block is an explicit consent or an implicit consent can be stored within the metadata (such as the transaction filter section of the metadata). The transaction filter can indicate whether it is an implicit transaction or an explicit transaction, which can be used to quickly identify implicit transactions for post-analysis in the event of a complaint.

[0046] Figure 1 A computing environment 100 is illustrated according to an example embodiment, the computing environment including a consent management platform 120 for accessing user data stored on a blockchain 110. Figure 1 In the example of , blockchain 110 stores user data and may also store evidence of consent to access user data. User data may be uploaded or stored on blockchain 110 on a common channel with other entities 130 using data-level encryption. Entity 130 may gain access to data if they are on the same channel and they have obtained explicit consent to the data. In the case of an implicit consent scenario, an entity 130 requesting access may obtain access through another entity that has been granted explicit consent, and both entities provide the same kind of services, which are related to the template that has been used to obtain explicit consent. Examples of entity 130 include, but are not limited to, application providers (e.g., software, etc.), content providers such as utilities, IoT devices that have an association with a customer and interact with the customer to provide services, advertisers that send promotional communications, medical providers, insurance providers, and the like.

[0047] The blockchain 110 includes a distributed shared database system that ensures the integrity of the data. The blockchain 110 includes a database system 114 in which the status of entities, consents, preferences, complaints are stored in an immutable manner. The only way to update the data is to execute a smart contract 112, which is verified by consensus from the relevant parties. Smart contract 112 is a new smart contract that is used to provide access / consent to data and digital representations of consent (or encrypted identities) as a service and all components of the service.

[0048] The consent management platform 120 is the core of the environment 100 and is responsible for implementing the business logic and creating, validating and managing digital representations of the consent service and its components. The consent management platform 120 is connected to the entity 130 and each of its components on one side, and to the blockchain 110 on the other side through smart contracts 112. The registration, verification and management processes are further described below.

[0049] The system also includes a cognitive engine 140 (also referred to as a cognitive decision engine), which is a cognitive learning and feedback system. The cognitive engine 140 includes an artificial intelligence (AI) engine 142, which obtains input from entities 130, blockchain 110, and other sources 150 (e.g., protocol documents, original equipment manufacturer (OEM) documents, weather services, social media sites, etc.), and predicts whether to allow consent and access to user data based on context. Here, the cognitive engine 140 can create or dynamically control smart contracts 112 to retrieve data from the blockchain (database system 114) based on context. In addition, the cognitive engine 140 can suggest improvements to the smart contract 112 via an administrator blockchain node (not shown).

[0050] There are situations where implicit consent is required to access user data. In such scenarios, the smart contract 112 obtains input from the cognitive engine 140 to serve such situations. For example, the cognitive engine 140 can consider contextual information about the access request, such as the occurrence of accidents / incidents associated with the user, the user's medical condition, the user's geographic location, the user's past and / or similar experiences, etc. Here, the smart contract 112 can be authorized by a cognitive decision made by the cognitive engine 140, where the cognitive engine 140 dynamically learns and adapts to modify the smart contract 112 due to changes in the context that can be received from external sources 150, blockchain 110, entities 130, users themselves (not shown), etc. As an example, the cognitive engine 140 can provide health-related vital parameters to a hospital in an emergency. As another example, the cognitive engine 140 can provide personal data information to friends and family members in an accident / emergency.

[0051] The cognitive engine 140 can predict whether to give consent to the entity 130 (implied consent) based on the context surrounding a given situation. Predictions of data sharing can also be performed for new participants, thus enabling an intelligent guidance process that guides various participants to add new nodes and update the smart contract 112 accordingly. For example, based on parental controls set by the customer, ads that have not been explicitly blocked by children can be blocked so that only appropriate content is shared with children. The cognitive engine 140 can also include a feedback loop that obtains user feedback in the context of where implicit consent has been provided and there is some feedback (which has been provided by the user for the implicit consent).

[0052] For implicit consent scenarios, the requestor of consent (such as one of the entities 130) may be asked to prove their identity. Based on the contextual parameters and the verified identity of the requestor, data access to the user data of interest may be granted or not granted. The cognitive engine 140 may use naive Bayes classification to classify the authenticity of the access request and may also use a decision tree to determine a decision about which data segment (such as a subset of the user data stored on the blockchain 110) may be given access. Once the cognitive engine 140 is able to satisfy the following parameters for authorizing access to the requested data or a portion of the requested data, the cognitive engine 140 may call the smart contract 112 to drive the consensus on providing access and issue a token to the requestor's device for accessing data from the blockchain 110. The token may be used for temporary use.

[0053] The consent management platform 120 may include a service and integration component 124 for registering users, entities, etc. The consent management platform 120 may also include a business process component 126 for managing changes and updates to the business processes of the entity 130 (such as new services being offered, updates to existing services, etc.). The consent management platform 120 may also include a blockchain registry component 128 for tracking data stored on the blockchain 110.

[0054] During the registration process on the consent management platform 120, the customer may explicitly specify his / her consent. Consent may be given to other entities 130 in the ecosystem to access the user's data. Additionally, other entities 130 in the ecosystem may need to register on the consent management platform 120 with all relevant details. Here, there may be an extensive onboarding process for each business entity 130 based on the nature of their business. Smart contracts between entities may define details that may be shared between different parties.

[0055] Each entity and user may receive a digital identity generated during the registration process based on a multi-factor calculation. The digital representation may be stored on the blockchain 110 to identify each consent as a separate asset. Ownership and provenance are then managed by the blockchain 110. Any ownership / access changes may be managed by smart contracts 112, and events and updates may be recorded on the blockchain 110 to maintain the provenance of each consent.

[0056] During the life of an entity or service, some of the factors may change, such as entity updates, new services being offered, service changes, or any other changes that affect some of the factors included in the digital representation. When such changes occur, the consent management platform 120 can execute business logic to ensure a valid digital representation that is securely updated in the blockchain 110. For example, the process of updating may include: preparing and managing the authorizations necessary for the consented person or system to perform the update, and updating the digital representation stored in the blockchain 110 to reflect the latest calculated one. The update can be done by calling a transaction in a smart contract and verified by all peers. The platform can close the authorization associated with the change. In addition, the consent management platform 120 may include a complaint registration process that enables users to register complaints (distributed ledger complaints) in the event of any violation of the shared data that does not meet his / her requirements.

[0057] The consent management platform 120 can achieve secure acquisition without human intervention using two-way verification of consent. The consent management platform can provide intelligent attribution of consent in relevant areas of use of information. The consent management platform can allow different levels of consent for anonymous data and qualified data. The consent management platform 120 can provide context-based acquisition and revocation of consent. The consent management platform 120 can provide detailed provenance of modifications and access data points with implicit and explicit consent. The consent management platform 120 can provide an intelligent and lightweight clearing mechanism for consent to control access to information.

[0058] The consent system herein solves many challenges. It is difficult and unrealistic for an individual to manage consent for all entities that follow the individual, and it is even more complicated for an entity to manage consent for all individuals that the entity is interested in. Therefore, it is crucial to create a consent model for an individual based on the individual's explicit input and behavioral model. Inferred information that is verified by the individual in a periodic manner is also important. Another challenge is to manage a huge amount of data and transactions to the system (which manages consent). The consent management platform 120 can be pluggable into any data source of interest to verify consent before accessing any data source. For example, a user can choose to insert a consent management service on a social media profile, so the user can prevent any unauthorized use of the user's data.

[0059] The distributed ledger of blockchain 110 may support a deterministic consensus algorithm and an access model based on zero-knowledge evidence. Consensus is not built during the capture of consent, but rather while verifying consent. Based on the nature of consent (implicit / explicit), endorsement policies may vary.

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

[0061] The blockchain library 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 that may be used to receive and store new transactions and provide access to auditors who want to access data entries. The blockchain layer 216 may expose an interface that provides access to the virtual execution environment that is required to process program code and engage the physical infrastructure 214. Cryptographic trust services 218 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0062] Figure 2AThe blockchain architecture configuration of the blockchain platform 212 can process and execute program / application code 220 via one or more interfaces exposed and services provided by the blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transmit data, and can be executed by the nodes 204-210 in the form of smart contracts and associated chain codes (the chain codes have status or other code elements that undergo their execution). As a non-limiting example, smart contracts can be created to perform reminders, updates and / or other notifications of changes, updates, etc. The smart contracts themselves can be used to identify rules associated with authorization and access requests, and the use of the ledger. For example, cognitive data 226 can be provided from a cognitive engine and can indicate whether access to user data is allowed, which can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The results 228 may include information identifying the data to be accessed and for accessing the data. The physical infrastructure 214 can be used to retrieve any of the data or information described herein.

[0063] Smart contracts can be created via high-level applications and programming languages, and then written to blocks in a blockchain. A smart contract can include executable code that is registered, stored, and / or replicated with respect to a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which can be executed in response to a condition associated with the smart contract being satisfied. The execution of a smart contract can trigger (one or more) trusted modifications to the state of a digital blockchain ledger. (One or more) modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated in a distributed network of blockchain peers through one or more consensus protocols.

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

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

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

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

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

[0069] In response, the client 260 application checks / verifies the endorsed peer signature and compares the proposed response to determine if the proposed response is the same. If the chaincode only queries the ledger, then the application will check the query response and will generally not submit the transaction to the ordering node service 284. If the client's application is intended to submit a transaction to the ordering node service 284 to update the ledger, then the application determines whether the specified endorsement policy has been satisfied before submission (i.e., whether all peer nodes necessary for the transaction have endorsed the transaction). Here, the client can include only one of the multiple parties to the transaction. In this case, each client can have their own endorsement node, and each endorsement node will need to endorse the transaction. This architecture enables the endorsement policy to be enforced by peers and supported at the submission verification phase even if the application chooses not to check the response or otherwise forward unendorsed transactions.

[0070] After successful checks, in step 293, client 260 assembles endorsements into a transaction and broadcasts the transaction proposal and response within the transaction message to ordering node 284. The transaction may contain read sets / write sets, endorsement peer signatures, and channel IDs. Ordering node 284 does not need to check the entire contents of the transaction in order to perform its operations, instead, ordering node 284 can simply receive transactions from all channels in the network, sort them by channel in chronological order, and create a block of transactions for each channel.

[0071] The block of transactions is delivered from the ordering node 284 to all peer nodes 281-283 on the channel. Transactions 294 within the block are validated to ensure that any endorsement policies are satisfied and that no changes have been made to the state of the ledger for the read set variables since the read set was generated by the transaction execution. The transactions in the block are marked as valid or invalid. In addition, in step 295, each peer node 281-283 adds the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events are emitted to notify the client's application that the transaction (call) has been immutably added to the chain, and whether the transaction is verified or unverified.

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

[0073] Blockchain developers 310 can write chaincodes and client applications. Blockchain developers 310 can deploy chaincodes directly to the network through an interface. In order to include certificates from traditional data sources 312 in the chaincode, developers 310 can use out-of-band connections to access the data. In this example, blockchain users 302 connect to the permissioned blockchain 304 through peer nodes 314. Before proceeding with any transactions, peer nodes 314 retrieve the user's registration and transaction certificates from certificate authorities 316 (which manage user roles and permissions). In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain 304. At the same time, users who attempt to utilize chaincodes may be required to verify their certificates on traditional data sources 312. In order to confirm the user's authorization, the chaincode can use an out-of-band connection to the data through a traditional processing platform 318.

[0074] Figure 3BAnother example of a permissioned blockchain network 320 characterizing a distributed decentralized peer-to-peer architecture is illustrated. In this example, a blockchain user 322 can submit a transaction to a permissioned blockchain 324. In this example, the transaction can be a deployment, call, or query, and can be issued by a client application utilizing an SDK, directly through an API, or the like. The network can provide access to regulators 326 (such as auditors). The blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and registering blockchain users 322 as "clients." Auditors may be limited to querying the ledger only, while clients may be authorized to deploy, call, and query certain types of chaincodes.

[0075] Blockchain developers 330 write chaincodes and client applications. Blockchain developers 330 can deploy chaincodes directly to the network through an interface. To include certificates from traditional data sources 332 in chaincodes, developers 330 can use out-of-band connections to access data. In this example, blockchain users 322 connect to the network through peer nodes 334. Before proceeding with any transactions, peer nodes 334 retrieve the user's registration and transaction certificates from certificate authorities 336. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain 324. At the same time, users attempting to utilize chaincodes may be required to verify their certificates on traditional data sources 332. To confirm the user's authorization, chaincodes may use out-of-band connections to the data through traditional processing platforms 338.

[0076] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast 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 and thereby adding entries to the ledger. Additionally, all parties have the option of executing a node on the system and employing a mining protocol to help verify transactions.

[0077] Figure 3CThe process 350 of a transaction processed by a permissionless blockchain 352 including a plurality of nodes 354 is illustrated. A sender 356 desires to send a payment or some other form of value (e.g., a deed, medical record, contract, good, service, or any other asset that can be summarized 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 user interface control and display of transaction parameters. In response, the transaction is broadcasted to the nodes 354 via the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes verify 360 the transaction based on rules established by the permissionless blockchain 352 creator (which may be predefined or dynamically assigned). For example, this may include verifying the identities of the various entities involved, etc. The transaction may be verified immediately or it may be placed in a queue with other transactions, and the nodes 354 determine whether the transaction is valid based on a set of network rules.

[0078] In structure 362, valid transactions are formed into blocks and sealed with locks (hashes). This process can be performed by a mining node among nodes 354. The mining node can utilize additional software specifically for mining and creating blocks for permissionless blockchain 352. Each block can be identified by a hash (e.g., a 256-bit number, etc.) created using an algorithm agreed upon by the network. Each block can 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 chain of blocks.

[0079] Before a block can be added to the blockchain, it must be validated. Validation for the permissionless blockchain 352 may include proof-of-work (PoW), which is the solution to a puzzle derived from the header of the block. Although not shown in Figure 3C In the example of , however, another process for validating blocks is proof-of-stake. Unlike proof-of-work, in proof-of-stake the algorithm rewards miners who solve mathematical problems, depending on their property (also defined as "stake"), to select the creator of a new block in a deterministic way. Similar proofs are then performed by selected / elected nodes.

[0080] With mining 364, nodes attempt to solve a block by making incremental changes to a variable until the solution satisfies a network-wide goal. This creates a PoW, thereby ensuring the correct answer. In other words, a potential solution must prove that computing resources were exhausted in solving the problem. In some types of permissionless blockchains, miners can be rewarded with value (e.g., coins, etc.) for correctly mining a block.

[0081] Here, PoW is processed simultaneously with the chain of blocks, making modifications to the blockchain extremely difficult, as an attacker must modify all subsequent blocks in order for a modification to one block to be accepted. Additionally, as new blocks are mined, the difficulty of modifying a block increases, and the number of subsequent blocks increases. Using distribution 366, successfully validated blocks are distributed through the permissionless blockchain 352 and all nodes 354 add the block to the majority chain, which is an 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 illustrates a process 400A of providing consent for a request for user data according to an example embodiment, and Figure 4B A process 400B for providing explicit and implicit consent for user data is illustrated according to an example embodiment. Figure 4A In the example shown in FIG. 4 , a data requester 410 (e.g., via a user device, etc.) requests access to data of a data owner 430 (e.g., via a user device, etc.) that has been previously stored on a blockchain 424. Here, the blockchain 424 is managed by a consent management platform 420, which also receives a request from the data requester 410 to access the user's data. In this example, the consent management platform 420 also includes a cognitive engine 422 that dynamically controls access to the data of the data owner 430 based on whether explicit consent has been given to the data requester 410 or whether implicit consent is required. When consent is given to the data of the data owner 430, a token may be sent from the cloud platform 440 (or other system) to the data requester 410. The token may authorize an identified user to access another identified user's data in the absence of explicit consent. The token is generated by the cognitive engine 422 and trusted by the blockchain 424.

[0083] Reference now Figure 4B, showing two types of consent (explicit and implicit). During explicit consent, the cognitive engine 422 uses deterministic access through the blockchain. Here, the blockchain layer works like a key to access the data of interest. The link to the data of interest is a function of the consent data, the identity of the consent giver (data owner), and the identity of the consent acquirer (data requester). In 451, the data requester attempts to obtain the key to the data of interest by providing his / her identity and generating the public identity of the owner of the data of interest. In 452, the cognitive engine 422 verifies the authenticity of the data requester (e.g., verifies the public key of the data requester given during the registration process), and generates logic for accessing the explicitly consented data in 453. Here, the consent management system can mine the actual consent data and calculate the authorization logic. Logic for accessing the data of interest = function (identity of the data owner, identity of the data acquirer, consent data). This logic can be used to retrieve data from the blockchain 424.

[0084] For implicit consent, cognitive engine 422 can use uncertainty access made by cognitive decision. In this example, in 461, the requester needs to prove their identity and in 462, the cognitive engine verifies the identity. In 463, cognitive engine 422 can process or otherwise identify contextual parameters of the data owner of the data of interest to determine whether access will be granted or not. Here, the context can include one or more of the following items: the occurrence of a specific accident / incident, medical condition, geographic location, past experience, etc. For example, cognitive engine 422 can use naive Bayes classification to classify the authenticity of the access request, and can also use a decision tree to make a decision about which data segment can be given access. Once cognitive engine 422 is able to meet the following parameters, which are used to authorize access to the requested data or a portion of the data, cognitive engine 422 can call a smart contract in 464 to drive consensus on providing access and drive the final issuance of a token for access to data for temporary use.

[0085] The consent management platform can intelligently manage and provide transparency of an individual's data without exposing the individual, which enables improved trust and integrity for all consumers who plan to access the data. The consent management platform can be based on the Hyperledger architecture and can allow data access management at the component and service level. The blockchain can ensure the trust and integrity of the platform. The functionality of the blockchain around contract management can be extended to enhance access management so that contracts are automatically configured and updated as needed.

[0086] The platform can compute a digital representation, an encrypted identity, of a consent service consisting of various data attributes and access to be provided based on the individual's consent. Smart contracts can maintain the state of the consent profile (consuming entity, consuming identity, access validity, access level, etc.). The platform can manage the lifecycle of the consent service by managing who can modify the digital representation of the component / service in the blockchain, what changes can be made (update, delete, etc.), which factor(s) can be modified, and by verifying that the change is valid and causing the change to propagate through all affected systems. For example, adding a new sensor (which may have access to the data of an individual outside of its predefined geographic location) results in the generation of a new representation based on the smart contract details.

[0087] The platform can use the ledger to provide an audit registry that provides a verifiable history of all successful state changes (valid transactions) and unsuccessful attempts to change state (invalid transactions) that occurred during the operation of the system. The ledger is replicated across all participant nodes. Smart contracts can govern business processes and data that are shared across different participants collaborating in the blockchain network. The architecture layer can host smart contracts that will allow consent changes that comply with compliance rules defined in the contract (such as data privacy laws requiring compliance with regulations).

[0088] Smart contracts are empowered by cognitive decisions that dynamically learn and adapt to modify the contract due to changes in context / location / external factors. Examples include providing health-related vital parameters to hospitals in emergency situations and providing personal data information to legally valid family members in accidents / emergencies. The cognitive layer can enable intelligent guidance processes based on predictions of data sharing for new participants and also add new nodes for various participants and update smart contracts accordingly.

[0089] While the consensus building process for explicit consent is deterministic in nature, implicit consent is not. Making decisions in an autonomous manner is important for implicit consent. To ensure that the autonomous nature does not compromise privacy without reasonable demand, a suitable consensus process involving smart contracts and capabilities can be implemented. Gaining access to someone's data can therefore depend on a two-step check, whereby the data owner's explicit consent to the data consumer is verified through an on-chain clearing mechanism, and the implicit consent state is analyzed based on surrounding parameters and cognitive algorithms. Implicit consent can override explicit consent for specific contexts.

[0090] Figure 5 A method 500 of managing consent for user data via a blockchain is illustrated according to an example embodiment. Figure 5In 510, the method may include receiving a request for access to user data, wherein the request includes an identification of a requester (consent acquirer) and an identification of the data being requested. The request may also include an identification of a user whose private data is being requested (consent giver). The identification of the acquirer may include a key of the acquirer, which may be authenticated by a consent management platform. The key may be provided during a registration process, etc. The identification of the consent giver may be a key, a user name, an address, an email address, a phone number, etc.

[0091] At 520, the method may include determining, via a cognitive engine, whether to provide access to user data based on a context associated with the user. For example, the context may include an occurrence of an event (such as a physical event involving the user), a condition of the user such as a medical condition, a location such as a geographic location, past experiences of the user, and the like. The context is received from one or more of the following: the user, the requestor, the blockchain, and one or more external data sources. Examples of external sources include weather services, social networking sites of the user, and the like.

[0092] In response to determining to provide access to the user data, the method may include invoking a chaincode, which retrieves access to the user data from the blockchain and provides access to the user data to the requester, and in 540, the method may include: storing, via the blockchain, a result of the determination made by the cognitive engine. For example, the result may include evidence of the reason for the decision to grant or not grant consent determined by the cognitive engine. The storage may also include storing a metadata identifier indicating whether the consent is explicit or implicit.

[0093] In some embodiments, the determining may include predicting whether the requestor has implicit consent to access user data stored on the blockchain based on a context associated with the user. In some embodiments, the determining may include determining, via the cognitive engine, a subset of user data stored on the blockchain accessible to the requestor based on the context. In some embodiments, the invocation by the cognitive engine may include triggering execution of the chaincode with dynamic execution parameters based on an attribute of the user learned from the context. In some embodiments, the method may further include sending a token to the requestor, the token providing restricted access to the user data stored on the blockchain.

[0094] Fig. 6A An example system 600 is shown that includes a physical infrastructure 610 that is configured to perform various operations according to an example embodiment. Fig. 6A, the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which may perform any of the operation steps 608 (in the module 612) included in any of the example embodiments. Steps / operations 608 may include one or more of the described or depicted embodiments and may represent output information or written information written or read from one or more smart contracts 630 and / or blockchain 620. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, the module 612 and the module 614 may be the same module.

[0095] Figure 6B Another example system 640 is illustrated that is configured to perform various operations according to an example embodiment. Figure 6B , the system 640 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which may perform any of the operation steps 608 (in the module 612) included in any of the example embodiments. The step / operation 608 may include one or more of the described or depicted embodiments and may represent output or written information written or read from one or more smart contracts 630 and / or blockchain 620. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, the module 612 and the module 614 may be the same module.

[0096] Figure 6C An example system is illustrated, according to an example embodiment, configured to utilize a smart contract configuration between contract entities; and an intermediary server, configured to enforce the terms of the smart contract on a blockchain. Figure 6C , configuration 650 may represent a communication session, an asset transfer session, or a process or flow driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The operations and results of smart contract execution may be managed by server 654. The content of smart contract 630 may require digital signatures by one or more of entities 652 and 656 (which are the respective entities of the smart contract transaction). The results of smart contract execution may be written to blockchain 620 as blockchain transactions. Smart contract 630 resides on blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0097] Fig.6D A system 600 including a blockchain is illustrated according to an example embodiment. Fig.6D In the example of , an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 662 is a common interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the server 654 is a blockchain network peer component that maintains a copy of the world state and a distributed ledger that allows clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where, depending on the smart contract 630 and the endorsement policy, the endorsement peer will execute the smart contract 630.

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

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

[0100] Fig. 7A illustrates a process 700 of adding a new block to a distributed ledger 720 according to an example embodiment, and Figure 7B The content of a new data block structure 730 for a blockchain is illustrated according to an example embodiment. Fig. 7A, a client (not shown) may submit a transaction to a blockchain node 711, 712, and / or 713. A client may be an instruction received from any source to perform an activity on a blockchain 720. As an example, a client may be an application that acts on behalf of a requester such as a device, person, or entity to propose a transaction for a blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain the state of a blockchain network and a copy of a distributed ledger 720. Different types of blockchain nodes / peers may exist in a blockchain network including endorsement peers and submission peers, where endorsement peers simulate transactions proposed by clients and endorse transactions proposed by clients, and submission peers verify endorsements, validate transactions, and submit transactions to a distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may perform the roles of endorser nodes, submitter nodes, or both.

[0101] The distributed ledger 720 includes a blockchain, which stores immutable serialized records in blocks, and a state database 724, which maintains the current state of the blockchain 722 (the current world state). There can be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions. Blocks may include transactions such as Figure 7B The various components shown in . can be generated by adding the header of the previous block to the header of the current block (by Fig. 7A ) blocks. In this way, all transactions on blockchain 722 are serialized and cryptographically linked together to prevent tampering of blockchain data without breaking the hash-like links. In addition, due to the links, the latest block in blockchain 722 represents every transaction that has come before it. Blockchain 722 can be stored on a peer-to-peer file system (local or attached storage device) that supports workloads that only add blockchains.

[0102] The current state of the blockchain 722 and distributed ledger 722 may be stored in a state database 724. Here, the current state data represents the latest values ​​for all keys ever included in the chain transaction log of the blockchain 722. Chaincode invocations execute transactions against the current state in the state database 724. In order to make these chaincode interactions extremely efficient, the latest values ​​of all keys are stored in the state database 724. The state database 724 may include an indexed view into the transaction log of the blockchain 722, which may thus be regenerated by the chain at any time. The state database 724 may be automatically restored (or generated if needed) after peer initiation before a transaction is accepted.

[0103] The endorsing node receives the transaction from the client and endorses the transaction based on the results of the simulation. The endorsing node maintains a smart contract that simulates the transaction proposal. When the endorsing node endorses the transaction, the endorsing node creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing the transaction depends on the endorsement policy that can be specified within the chaincode. An example of an endorsement policy is "a majority of the endorsing peers must endorse the transaction". Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the sorting service 710.

[0104] The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers the blocks to commit peers. For example, the ordering service 710 may initiate a new block when a threshold of transactions has been reached, a timer has expired, or other conditions. Fig. 7A In the example of , blockchain node 712 is a commit peer that has received a new data block 730 for storage on blockchain 720. The first block in a blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, the data stored therein, and the like.

[0105] The sorting service 710 may consist of a cluster of sorters. The sorting service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the sorting service 710 may accept endorsed transactions and specify the order in which those transactions are submitted to the distributed ledger 720. The architecture of the blockchain network may be designed so that the implementation of "sorting" (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0106] Transactions are written to the distributed ledger 720 in a consistent order. The order of transactions is established to ensure that updates to the state database 724 are valid when they are submitted to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering occurs by solving cryptographic puzzles or mining, in this example, the various entities of the distributed ledger 720 can choose the ordering mechanism that best suits the network.

[0107] When the ordering service 710 initializes a new data block 730, the new data block may be broadcast to commit peers (e.g., blockchain nodes 711, 712, and 713). In response, each commit peer verifies the transaction within the new data block 730 by checking to ensure that the read set and write set still match the current world state in the state database 724. Specifically, the commit peer may ensure that the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 724. When the commit peer verifies the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set. If the transaction fails, that is, if the commit peer finds that the read-write set does not match the current world state in the state database 724, then the transaction ordered into the block will still be included in the block, but it will be marked as invalid, and the state database 724 will not be updated.

[0108] refer to Figure 7B , a new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be recognized that various depictions of blocks and their contents, such as the new data block 730 and its contents. Figure 7B The examples shown in FIG. 7 are merely examples and are not intended to limit the scope of the example embodiments. The new data block 730 may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000) transactions in the block data 750. The new data block 730 may also include (e.g., Fig. 7A The block header 740 may include a link to a previous block on the blockchain 722 in the block chain. Specifically, the block header 740 may include a hash of the header of the previous block. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, and the like. The block number of the new data block 730 may be unique and assigned in various orders, such as an incremental / serialized order starting from zero.

[0109] The block data 750 may store transaction information for each transaction recorded within the new data block 730. For example, the transaction data may include one or more of the following: type of transaction, timestamp, channel ID of the distributed ledger 720, epoch, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identity (such as public key and certificate), identity of endorsers, endorser signature, proposal hash, chaincode event, response status, namespace, read set (list of keys and versions read by the transaction, etc.), write set (list of keys and values, etc.), start key, end key, key list, Merkle tree query digest, etc. The transaction data may be stored for each of the N transactions.

[0110] In some embodiments, the block data 750 may also store a proof of consent 752 that adds additional information to the hash-linked chain of blocks in the blockchain 722. The proof of consent 752 may include information identifying why consent was or was not given, including rules, parameters, and the like used by the cognitive engine to make decisions (such as data from a decision tree). The additional information may also include one or more of the following: steps, features, processes, and / or actions described or depicted herein. Thus, the proof of consent 752 may be stored in an immutable log of blocks on the distributed ledger 720. Some advantages of storing such data are reflected in the various embodiments disclosed and depicted herein and include providing an immutable record of the proof of consent that may prevent subsequent arguments over why consent was given. The proof of consent 752 may provide proof of pre-agreed items agreed to by the user. Although in Figure 7B , the proof of consent 752 is depicted in the block data 750 and may also be located in the block header 740 or the block metadata 760.

[0111] Block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature on block creation, a reference to the last configuration block, a transaction filter identifying valid and invalid transactions within the block, a last offset maintained by the sorting service that sorted the block, and the like. The signature, last configuration block, and sorting metadata may be added by the sorting service 710. At the same time, the submitter of the block (such as blockchain node 712) may add validity / invalidity information based on endorsement policies, verification of read / write sets, and the like. The transaction filter may include: a byte array whose size is equal to the number of transactions in the block data 750; and a verification code that identifies whether the transaction is valid or invalid.

[0112] In addition, the block metadata 760 may include a new data field for consent data 762, which indicates whether the consent for accessing the user data is an implicit consent or an explicit consent to the data. For example, the consent data 762 may be stored in the transaction filter section of the block metadata 760, but the embodiment is not limited thereto. The transaction filter may indicate whether it is an implicit or explicit transaction, which may be used to quickly identify implicit transactions for post-analysis in the event of a complaint.

[0113] Figure 7C An embodiment of a blockchain 770 for digital content according to embodiments described herein is illustrated. Digital content may include one or more files and associated information. Files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspect of the blockchain serves as a safeguard that protects the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings or other settings where admissibility rules apply, where evidence is considered or the presentation and use of digital information is otherwise of interest. In such cases, the digital content may be referred to as digital evidence.

[0114] The blockchain can be formed in a variety of ways. In one embodiment, the digital content can be included in and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of reference information (e.g., header, value, etc.) and the associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing previous blocks. This can be illustrated as follows:

[0115]

[0116] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store a cryptographic hash of the contents of each block without any digital content. The digital content may be stored in other storage areas or in memory addresses associated with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain or may be a different storage area or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest and then looking up the value in the storage area (which is stored corresponding to the actual digital content). This operation may be performed, for example, by a database keeper. This may be illustrated as follows:

[0117]

[0118] exist Figure 7C In the example embodiment of FIG. 770 , blockchain 770 includes a number of blocks 778 1 , 778 2 , . . . 778 that are cryptographically linked in an ordered sequence. N , where N≥1. Used to convert blocks 7781, 7782, ...778 N The encryption of the link can be any of a number of keyed or non-keyed hash functions. In one embodiment, blocks 7781, 7782, ... 778 N Subjected to a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ... 778 N May be cryptographically linked by a function other than a hash function.For purposes of illustration, the following description is made with reference to a hash function (eg, SHA-2).

[0119] Blocks 7781, 7782, ... 778 in the blockchain N Each of the blocks includes a header, a version of the file, and a value. The header and value are different for each block due to the hash in the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the version of the file is the original file or a different version of the original file.

[0120] The first block 7781 in the blockchain is called the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme used in the genesis block and in fact in all subsequent blocks can vary. For example, all of the information in the first block 7781 can be hashed together at the same time, or each or a portion of the information in the first block 7781 can be hashed separately and then hashing of the separately hashed portions can be performed.

[0121] The header 7721 may include one or more initial parameters, which may include, for example, a version number, timestamp, nonce, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be automatically generated (e.g., by blockchain network management software) or manually generated by a blockchain participant. Unlike other blocks 7782 to 778 N Header 7721 in the genesis block does not reference a previous block, simply because there is no previous block.

[0122] The original file 7741 in the genesis block may be, for example, data captured by a device that processes or does not process the data before it is included in the blockchain. The original file 7741 is received from a device, a media source, or a node through an interface of the system. The original file 7741 is associated with metadata, which may be generated manually or automatically by a user, a device, and / or a system processor, for example. The metadata may be included in the first block 7781 in association with the original file 7741.

[0123] 7761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may include a hash value for the original file 7741, metadata for the original file 7741, and other information associated with the file. In one embodiment, the initial value 7761 may be based on the following unique attributes:

[0124] 1) SHA-2 hash value calculated against the original file

[0125] 2) Original device ID

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

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

[0128] 5) The blockchain network member ID for the software that currently controls the original file and associated metadata

[0129] Other blocks in the blockchain: 7782 to 778 N It also has a header, a file, and a value. However, unlike the first block 7721, the headers 7722 to 772 N Each of the remaining blocks includes the hash value of the immediately preceding block. The hash value of the immediately preceding block may just be the hash of the header of the previous block or may be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, as indicated by arrow 780, tracking from the Nth block back to the genesis block (and associated original file) can be performed on a block-by-block basis to establish an auditable and immutable chain of custody.

[0130] Headers 7722 to 772 in other blocks N Each of the may also include other information, such as a version number, timestamp, nonce, root information, difficulty level, consensus protocol, and / or other parameters or information associated with the corresponding file and / or the general blockchain.

[0131] Depending on, for example, the type of processing being performed, files 7742 to 774 in other blocks N It may be equal to the original file or may be a modified version of the original file in the genesis block. The type of processing performed may differ between different blocks. Processing may involve, for example, any modification of the file in the previous block, such as redacting information or otherwise changing the content, taking information away, or adding or appending information to the file.

[0132] Additionally or alternatively, processing may involve merely copying a file from one or more previous blocks, changing a storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage device or storage location to another, or performing an action related to a file of the blockchain and / or its associated metadata. Processing involving analyzing a file may include, for example, adding, including, or otherwise associating various analytical, statistical, or other information associated with the file.

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

[0134] For example, consider a situation where portions of a file in a previous block are redacted, blocked, or pixelated in order to protect the identity of the person shown in the file. In this case, the block that includes the redacted file will include metadata associated with the redacted file, e.g., how the redaction was performed, who performed the redaction, a timestamp when the redaction(s) occurred, etc. The metadata may be hashed to form a value. Because the metadata for a block is different from the information that was hashed to form the value in the previous block, the values ​​are different from each other and can be recovered upon decryption.

[0135] In one embodiment, the value of the previous block may 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 occurs. In this example embodiment, the new hash value may be calculated by hashing all or part of the information indicated below.

[0136] a) If the file has been processed in any way (for example, if the file has been edited, copied, changed, or some other action has been taken), the new SHA-2 calculated hash value

[0137] b) New storage location for files

[0138] c) New metadata associated with the file

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

[0140] Fig.7D An example of a block in a blockchain 790 that can represent the structure of a block according to one embodiment is shown. i Including header 772 i 、File 774 i and the value 776 i .

[0141] Head 772 i Including previous block Block i-1 The hash value of the previous block and additional reference information, which can be any type of information discussed in this article (e.g., header information including references, properties, parameters, etc.). All blocks reference the hash of the previous block, except for the genesis block. The hash value of the previous block can just be the hash of the header in the previous block or the hash of all or part of the information in the previous block, which includes files and metadata.

[0142] File 774 i Includes multiple data, such as data 1, data 2, ..., data N in a sequence. The data is marked with metadata Metadata 1, Metadata 2, ..., Metadata N, which describes the content and / or characteristics associated with the data. For example, the metadata for each data may include information indicating the following items: a timestamp for the data, processing data, keywords indicating people or other content depicted in the data, and / or other features, which other features can help establish the validity and content of the file as a whole (especially the file is used as digital evidence (for example, as described in conjunction with the embodiments discussed below)). In addition to the metadata, each data can be marked with a reference REF1, REF2, ..., REF N to the previous data. N To prevent tampering, gaps in the file, and sequential references through the file.

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

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

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

[0146] Decryption is performed based on the type of encryption that occurs in each block. This can involve the use of a private key, a public key, or a public-private key pair. For example, when asymmetric encryption is used, a blockchain participant or processor in the network can use a predetermined algorithm to generate a public-private key pair. The public key and the private key are associated with each other by a specific mathematical relationship. The public key can be publicly distributed to be used as an address (e.g., an IP address or a home address) for receiving messages from other users. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can determine that only the sender may have sent the message.

[0147] Generating a key pair can be similar to creating an account on the blockchain, but without actually having to register anywhere. Moreover, any transaction performed on the blockchain is signed by the sender using their private key. This signature ensures that only the owner of the account can track and process (if within the scope of permissions determined by the smart contract) the files on the blockchain.

[0148] Fig. 8A and Figure 8B Additional examples of use cases for blockchain that may be incorporated and used herein are illustrated. Fig. 8A An example 800 of a blockchain 810 is illustrated, which stores machine learning (artificial intelligence) data. Machine learning relies on huge amounts of historical data (or training data) to build predictive models for making accurate predictions about new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to discover non-intuitive patterns.

[0149] exist Fig. 8AIn the example of , host platform 820 builds and deploys a machine learning model for predictive monitoring of asset 830. Here, host platform 820 may be a cloud platform, an industrial server, a network server, a personal computer, a user device, etc. Asset 830 may be any type of asset (e.g., a machine or equipment, etc.), such as an airplane, a locomotive, a turbine, a medical machine and equipment, an oil and gas equipment, a ship, a vessel, a vehicle, etc. As another example, asset 830 may be a non-tangible asset, such as stock, cash, digital currency, insurance, etc.

[0150] Blockchain 810 can be used to significantly improve both the training process 802 of the machine learning model and the prediction process 804 based on the trained machine learning model. For example, in the host platform 802, instead of requiring data scientists / engineers or other users to collect data, historical data can be stored on the blockchain 810 by the asset 830 itself (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be directly and reliably transferred to the blockchain 810 directly from its original location. By using blockchain 810 to ensure the security and ownership of the collected data, the smart contract can send data from the asset directly to the individual who uses the data for building the machine learning model. This allows data to be shared between assets 830.

[0151] The collected data can be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism draws in (permitted nodes) to ensure that the recorded data is verified and accurate. The recorded data is time-stamped, cryptographically signed, and unchangeable. Therefore, the recorded data is auditable, transparent, and secure. Adding IoT devices (which write directly to the blockchain) can increase both the frequency and accuracy of the recorded data in certain situations (i.e., supply chain, health care, logistics, etc.).

[0152] In addition, the training of the machine learning model on the collected data can take several rounds of improvement and testing by the host platform 820. Each round can be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. In the host platform 802, the different training and testing steps (and the data associated therewith) can be stored on the blockchain 810 by the host platform 820. Each improvement of the machine learning model (e.g., changes in variables, changes in weights, etc.) can be stored on the blockchain 810. This provides a verifiable proof of how the model was trained and what data was used to train the model. In addition, when the host platform 820 has implemented the final trained model, the resulting model can be stored on the blockchain 810.

[0153] After the model has been trained, it can be deployed to a live environment where it makes predictions / decisions based on the execution of the final trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) for assets such as aircraft, wind turbines, health care machines, etc. In this example, data fed back from asset 830 can be input into the machine learning model and used to make event predictions, such as failure events, error codes, etc. The determination made by executing the machine learning model at the host platform 820 can be stored on the blockchain 810 to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict future crashes / failures of a portion of the asset 830 and create a warning or notification to replace the portion. The data behind the decision can be stored on the blockchain 810 by the host platform 820. In one embodiment, the features and / or actions described and / or depicted herein can occur on or with respect to the blockchain 810.

[0154] New transactions for a blockchain can be collected together into a new block and added to the existing hash value. This is then decrypted to create a new hash for the new block. This is added to the next transaction list as they were encrypted, and so on. The result is a chain of blocks where each block contains the hash values ​​of all the previous blocks. The computers storing these blocks periodically compare their hash values ​​to ensure they all agree. Any computer that does not agree ignores the record that caused the problem. This method is good for ensuring that the blockchain is tamper-proof, but it is not perfect.

[0155] One way to game the system is to have a dishonest user change the list of transactions to their preference, but in a way that keeps the hash unchanged. This can be done by brute force, in other words, by changing the record, encrypting the result and seeing if the hash value is the same. And if not, try again until it finds a matching hash. The security of the blockchain is based on the belief that ordinary computers can only perform such brute force attacks on completely unrealistic time scales (such as the age of the universe). In contrast, quantum computers are much faster (1000 times faster) and therefore pose a much greater threat.

[0156] Figure 8B An example 850 of a quantum-safe blockchain 852 is illustrated that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can use QKD to verify each other's identities. This uses quantum particles such as photons (which cannot be copied by an eavesdropper without destroying them) to send information. In this way, senders and receivers on the blockchain can determine each other's identities.

[0157] exist Figure 8B In the example of , there are four users 854, 856, 858, and 860. Each pair of users can share a secret key 862 between themselves (i.e., QKD). Since there are four nodes in this example, there are six pairs of nodes, and therefore six different secret keys 862 are used, including QKD AB , QKD AC , QKD AD , QKD BC , QKD BD and QKD CD Each pair can create QKD by sending information using quantum particles such as photons, which cannot be copied by an eavesdropper without destroying them. In this way, a pair of users can determine each other's identity.

[0158] The operation of blockchain 852 is based on the following two processes: (i) the creation of transactions, and (ii) the construction of blocks that aggregate new transactions. New transactions can be created similar to traditional blockchain networks. Each transaction can contain information about the following items: sender, receiver, creation time, amount (or value) to be transferred, reference transaction list (which proves that the sender has funds for operation), etc. The transaction record is then sent to all other nodes, where it is entered into the pool of unconfirmed transactions. Here. Two entities (i.e., a pair of users from 854-860) authenticate the transaction by providing their shared secret key 862 (QKD). The quantum signature can be attached to each transaction, making it extremely difficult to be tampered with. Each node checks their entity in terms of the local copy of blockchain 852 to verify that each transaction has sufficient funds. However, the transaction has not yet been confirmed.

[0159] Instead of performing a traditional mining process on a block, a broadcast protocol can be used to create blocks in a decentralized manner. In a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transaction, thereby achieving a Byzantine agreement (consensus) on the correct version of the transaction. For example, each node can have a private value (the transaction data of that particular node). In the first round, the nodes send their private values ​​to each other. In subsequent rounds, the nodes pass the information they received from other nodes in the previous round. Here, the most honest node is able to create a complete transaction set within the new block. The new block can be added to the blockchain 852. In one embodiment, the features and / or actions described and / or depicted herein can occur on the blockchain 852 or relative to the blockchain.

[0160] Fig. 9An example system 900 is illustrated that supports one or more of the example embodiments described and / or depicted herein. System 900 includes a computer system / server 902 that can operate using many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 902 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 electronic devices, network PCs, microcomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices.

[0161] The computer system / server 902 may be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. In general, program modules may include routines, programs, objects, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. The computer system / server 902 may be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may be located in both local computer system storage media and remote computer system storage media, including memory storage devices.

[0162] like Fig. 9 As shown in FIG. 1 , a computer system / server 902 in a cloud computing node 900 is shown in the form of a general-purpose computing device. The components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a bus that couples various system components including the system memory 906 to the processor 904.

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

[0164] The computer system / server 902 generally includes various computer system readable media. Such media can be any available media that can be accessed by the computer system / server 902, and it includes both volatile media and non-volatile media, removable media and non-removable media. System memory 906 implements the flow charts of other figures in one embodiment. System memory 906 may include computer system readable media in the form of volatile memory (e.g., random access memory (RAM) 910 and / or cache 912). The computer system / server 902 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage device 914 may be provided to read and write to non-removable, non-volatile magnetic media (not shown and commonly referred to as "hard drive"). Although not shown, a disk drive for reading and writing to a removable, non-volatile magnetic medium (e.g., a "floppy disk") and an optical drive for reading and writing to a removable, non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical medium) may be provided. In such an example, each may be connected to the bus via one or more data media interfaces. As will be further depicted and described below, memory 906 may include at least one program product having a collection (e.g., at least one) of program modules configured to implement the functionality of various embodiments of the present application.

[0165] A program / utility 916 having a set (at least one) of program modules 918 may be stored in memory 906, as well as an operating system, one or more application programs, other program modules, and program data, by way of example and not limitation. Each of the operating system, one or more application programs, other program modules, and program data, or a specific combination thereof, may include an implementation of a networked environment. Program modules 918 generally implement the functions and / or methods of various embodiments of the present application as described herein.

[0166] Those skilled in the art know that various aspects of the present application can be implemented as a system, method or computer program product. Therefore, various aspects of the present application can take a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.) or the following embodiment, which combines the software and hardware aspects that can be generally referred to as "circuit", "module" or "system" in this article. In addition, various aspects of the present application can take the form of a computer program product embodied in one or more computer-readable media, and the computer-readable medium has a computer-readable program code embodied therein.

[0167] The computer system / server 902 may also communicate with one or more external devices 920 such as a keyboard, pointing device, display 922, etc.; one or more devices that enable a user to interact with the computer system / server 902; and / or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communications may be performed via an I / O interface 924. Furthermore, the computer system / server 902 may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter 926. As depicted, the network adapter 926 communicates with other components of the computer system / server 902 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 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0168] Although exemplary embodiments of at least one of a system, a method, and a non-transient computer-readable medium have been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the present application is not limited to the disclosed embodiments and is capable of many rearrangements, modifications, and substitutions as set forth and defined by the following claims. For example, the capabilities of the systems of the various drawings can be performed by one or more of the modules or components described herein or adopt a distributed architecture and can include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by a personal module can be performed by one or more of these modules. In addition, the functions described herein can be performed at various times and are related to various events inside or outside the module or component. Moreover, the information sent between the various modules can be sent between the modules via at least one of the following items and / or sent between the modules via multiple protocols: data network, Internet, voice network, Internet protocol network, wireless device, wired device. Moreover, the message sent or received by any of the modules can be sent or received directly and / or via one or more of the other modules.

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

[0170] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically emphasize their implementation independence. For example, a module can be implemented as a hardware circuit, including custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors (such as logic chips, transistors, or other discrete components). A module can also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, and the like.

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

[0172] In fact, the module of executable code can be a single instruction, or many instructions, and can even be distributed on several different code segments, in different programs, and distributed across several memory devices. Similarly, operational data can be identified and illustrated in this article within the module and can be embodied and organized in any appropriate form within the data structure of any appropriate type. Operational data can be collected as a single data set or can be distributed in different locations (including being distributed on different storage devices), and can be at least partially present in a system or network as an electronic signal only.

[0173] It will be readily understood that the components of the present application as described and illustrated in the drawings herein may be arranged and designed in a 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 the present application.

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

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

Claims

1. A computing system comprising: a network interface configured to receive a request from a requestor different from a user for access to data of the user stored on a blockchain, wherein the request includes an identification of the requestor and an identification of the data; a processor configured to: in response to the request being received from the requestor different from the user, determine via a cognitive engine whether to provide access to the data of the user based on a context associated with the user, and in response to a determination to provide access to the data of the user, invoke a chaincode, the chaincode retrieving access to the data of the user from a blockchain and providing access to the data of the user to the requestor, wherein the context includes one or more of: an occurrence of an event, a condition, a location, and a past experience; as well as A storage device configured to store, via the blockchain, results of the determinations made by the cognitive engine.

2. The computing system of claim 1, wherein: The processor is configured to predict, based on the context associated with the user, whether the requestor has implicit consent to access the data of the user stored on the blockchain.

3. The computing system of claim 1, wherein: The processor is configured to, via the cognitive engine, determine a subset of user data stored on the blockchain accessible to the requestor based on the context.

4. The computing system of claim 1, wherein: The processor is configured to, via the cognitive engine, trigger execution of the chaincode with dynamic execution parameters based on attributes of the user learned from the context.

5. The computing system of claim 1, wherein: The processor is also configured to control the network interface to send a token to the requestor, the token providing restricted access to user data stored on the blockchain.

6. The computing system of claim 1, wherein: The processor is configured to determine, via the cognitive engine, whether to provide access to user data stored on the blockchain based on a context associated with the user.

7. The computing system of claim 1, wherein the context is received via the network interface from one or more of: the user, the requestor, the blockchain, and an external data source.

8. The computing system of claim 1 , wherein the storage device is configured to store an indicator in the blockchain indicating that the consent is an implicit consent.

9. A method comprising: receiving, from a requestor different from the user, a request for access to data of the user, the request including an identification of the requestor and an identification of the data; determining, via a cognitive engine, whether to provide access to the data of the user based on a context associated with the user in response to the request being received from the requestor different from the user, wherein the context includes one or more of: an occurrence of an event, a situation, a location, and a past experience; In response to a determination to provide access to the data of the user, invoking a chaincode, the chaincode retrieving access to the data of the user from a blockchain and providing access to the data of the user to the requestor; as well as Results of the determinations made by the cognitive engine are stored via the blockchain.

10. The method of claim 9, wherein the determining comprises: Based on the context associated with the user, predicting whether the requestor has implicit consent to access the data of the user stored on the blockchain.

11. The method of claim 9, wherein the determining comprises: and determining, via the cognitive engine, a subset of user data stored on the blockchain accessible to the requestor based on the context.

12. The method of claim 9, wherein the calling by the cognitive engine comprises: Based on the attributes of the user known from the context, triggering execution of the chaincode with dynamic execution parameters.

13. The method of claim 9, further comprising sending a token to the requestor, the token providing restricted access to user data stored on the blockchain.

14. The method of claim 9, wherein the determining via the cognitive engine comprises: Based on a context associated with the user, determining whether to provide access to user data stored on the blockchain.

15. The method of claim 9, wherein the context is received from one or more of: the user, the requestor, the blockchain, and an external data source.

16. The method of claim 9, wherein the storing comprises storing an indicator in the blockchain indicating that the consent is an implicit consent.

17. A non-transitory computer readable medium comprising instructions which, when read by a processor, cause the processor to perform a method comprising: receiving, from a requester different from the user, a request for access to data of the user, the request including an identification of the requester and an identification of the data; determining, via a cognitive engine, whether to provide access to the data of the user based on a context associated with the user in response to the request being received from the requestor different from the user, wherein the context includes one or more of: an occurrence of an event, a situation, a location, and a past experience; In response to a determination to provide access to the data of the user, invoking a chaincode, the chaincode retrieving access to the data of the user from a blockchain and providing access to the data of the user to the requestor; as well as Results of the determinations made by the cognitive engine are stored via the blockchain.

18. The non-transitory computer readable medium of claim 17, wherein the determining comprises: Based on the context associated with the user, predicting whether the requestor has implicit consent to access the data of the user stored on the blockchain.

19. The non-transitory computer readable medium of claim 17, wherein the determining comprises: and determining, via the cognitive engine, a subset of user data stored on the blockchain accessible to the requestor based on the context.

20. The non-transitory computer-readable medium of claim 17, wherein the calling by the cognitive engine comprises: Based on the attributes of the user learned from the context, triggering execution of the chaincode with dynamic execution parameters.

21. A computer system comprising modules respectively configured to execute the steps of the method according to any one of claims 9 to 16.

22. A computer program product comprising a computer-readable storage medium having program instructions embodied by the computer-readable storage medium, the program instructions being executable by a processor to cause the processor to perform the method according to any one of claims 9 to 16.

Images