Patent Publication Number: US-2023161898-A1

Title: Accessing information based on privileges

Description:
BACKGROUND 
     The proliferation of network-enabled electronic devices, and the availability of new communication and data exchange technologies, have made possible new methods of device-to-device, device-to-user, and device-to-application interactions. For example, information can be collected directly from individual electronic devices. Alternately, information can be obtained indirectly from other data sources about the electronic devices or users, products, programs, or other components associated with the electronic devices. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Some implementations of the present disclosure are described with respect to the following figures. 
         FIG.  1    is a block diagram of an arrangement that includes a constrained device, a client device, and various backend nodes according to some examples. 
         FIG.  2    is a block diagram of a storage medium storing machine-readable instructions according to some examples. 
         FIG.  3    is a block diagram of a data governance system according to further examples. 
         FIG.  4    is a block diagram of a client device according to other examples. 
     
    
    
     Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the example shown. Moreover, the drawings provide examples and/or implementations consistent with the description; however, the description is not limited to the examples and/or implementations provided in the drawings. 
     DETAILED DESCRIPTION 
     In the present disclosure, use of the term “a,” “an”, or “the” is intended to include the plural forms as well, unless the context clearly indicates otherwise. Also, the term “includes,” “including,” “comprises,” “comprising,” “have,” or “having” when used in this disclosure specifies the presence of the stated elements, but do not preclude the presence or addition of other elements. 
     A “constrained device” can refer to a device that has restricted computing resources (e.g., processing resources, storage resources, communication resources, etc.) and/or power available to the device. A constrained device is distinguished from more general purpose computing devices such as smartphones, tablet computers, notebook computers, desktop computers, server computers, and so forth. A constrained device may use wired communications (e.g., copper, coaxial cable, and/or optical fiber communications) and/or wireless communications (e.g., radio frequency, infrared, ultrasonic, infrasonic, and/or laser). 
     As discussed further below, in contexts where blockchain technologies are used, a constrained device can be constrained in the processing of a blockchain. The concept of a blockchain is explained further below. 
     Examples of constrained devices include sensors, actuators, cameras, radio frequency identification (RFID) tags, and so forth. In some examples, constrained devices can include devices that transmit information according to an advertisement protocol using Bluetooth Low Energy (BLE) or cellular technology or other wireless technology. Generally, an advertisement protocol allows a device, such as a constrained device, to advertise information that can be used for some specified purpose. 
     In some examples, electronic devices such as constrained devices can transmit data useable to initiate, automate, and/or augment interactions in a physical world among entities (e.g., users, machines, programs, etc.), where such data are known as a “beacon.” A beacon can be in the form of a data packet, multiple data packets, a signal, and so forth. 
     For example, the information in a transmitted beacon can be used in any of the following interactions: purchasing products, obtaining further information about a product or its attributes, tracking inventory, obtaining healthcare services, detecting theft, performing law enforcement activities (e.g., a law enforcement officer can obtain information of a driver based on information in a beacon), purchasing insurance policies, and so forth. 
     The authenticity of a beacon and the transmitted data from constrained devices have to be ascertained prior to using the data to prevent the ingestion of malicious, false, misleading, or otherwise untrustworthy data. For example, such untrustworthy data may be used by a malicious entity in an attempt to manipulate interactions and/or to obtain information that would not otherwise be provided. Additionally, information transmitted by constrained devices can be subject to copying, playback, and malicious use by hackers. 
     Moreover, depending on who or what (a “client entity”) is requesting information based on a beacon transmitted by a constrained device, it may not be desirable to transmit all available information to the client entity in response to a query that is based on the beacon. A “client entity” refers to an entity associated with a client device. A client entity can refer to any of the following: the client device itself, a user of the client device, a program or component in the client device, and so forth. 
     In accordance with some implementations of the present disclosure, a data governance system can filter information to transmit to a client entity based on a privilege level associated with the client entity. Different filtering can be applied for different privilege levels, such that client entities having different privilege levels would receive different filtered information. As a result, the data governance system is able to deliver different customized information to different client entities, based on respective privilege levels of the different client entities. A privilege level of a client entity can refer to an indication of a class of information that the client entity is entitled to receive or has been designated to receive. Privilege levels can be indicated using different classifications, such as in the form of numerical values, group names, need-to-know status, organizational affiliation, and so forth. 
     The information delivered by the data governance system may have been created at different points in time by different entities (referred to as “owners” of the information) and stored in distributed database, such as in blocks of a blockchain. As a result, a single malicious entity would not be able to forge the information delivered to a client entity. The data governance system has access to smart contracts that define the privilege levels of client entities. Using the smart contracts, the data governance system can collect and deliver the customized information that is interest to the client entities. Note that the delivered information is not created or manipulated by a constrained device that sends a beacon. 
     The privilege levels that are defined in smart contracts can correspond to roles of respective client entities, where a role of a client entity can be determined according to any or some combination of the following: by an authentication system that authenticates a client entity, by a business logic engine that implements services for client entities, based on proximity of a client entity to a location or another entity, and so forth. A “role” of an entity can refer to information indicating a responsibility of or task(s) to be performed by the entity. For example, a human user can have a role of a police officer, a dispatcher, a shopper, a patient, a healthcare provider, etc. As another example, a machine or program can have a role of tracking inventory, managing an information technology infrastructure, and so forth. 
     As a result, in cooperation with use of constrained devices, a blockchain network, smart contracts, and an authentication system, the data governance system is able to deliver customized information to client entities, where the delivered information is trustworthy and in some cases can include secure historic information. 
     A blockchain refers to a distributed collection of records (referred to as “blocks”) that are linked and secured cryptographically. A blockchain can also refer to a continuous and unbroken ledger of blocks. The blocks of the blockchain can be distributed across a large number of computing devices. Each block can include various information, including transaction data for a transaction represented by the block, a timestamp, and a reference to a previous block in the blockchain. As new transactions occur, new blocks are created for the new transactions and added to the blockchain. A blockchain (which form a distributed transaction ledger) records transactions among multiple entities in a verifiable and permanent way. Once a block is created and the data of the block recorded, the block cannot be altered without alteration of subsequent blocks. 
     Multiple entities can see the transaction ledger, but because of the decentralized nature of the distributed collection of blocks records are protected against hacking or corruption by a malicious entity. Validation of each block that gets added to the blockchain is done by every node by validating its hash by applying a hashing function. If the validation fails, then that node drops the block from the blockchain. 
     A blockchain network includes nodes (referred to as blockchain nodes, full nodes, or blockchain full nodes) that can process requests to access the information. 
     A smart contract provides logic and rules executed by computing device(s) for a blockchain to automate terms of a contract among multiple entities. A smart contract can include blockchain addresses of the parties of the smart contract, information relating to terms of the smart contract, and other information. A smart contract can be established among multiple entities. A smart contract manager implements enforcement of smart contracts. A smart contract manager can process payments for access of services, including access of information or other services. 
       FIG.  1    is a block diagram of an example arrangement that includes a constrained device  102  that has a transmitter  104  to transmit a beacon  106 . Although just one constrained device  102  is shown in  FIG.  1   , it is noted that in other examples, multiple constrained devices  102  can be present, where the constrained devices can be provided at different locations. 
     Although reference is made to a constrained device, it is noted that techniques or mechanisms according to the present disclosure can also be applied to other types of electronic devices that can transmit information. 
     The beacon  106  can be transmitted by the transmitter  104  of the constrained device  102  using any of various transmission technologies, including for wireless constrained devices, any or some combination of the following: Bluetooth, BLE, radio-frequency identification (RFID), cellular, 802.15.4, 802.11 Wi-Fi, Near-Field Communication (NFC), Lora, Sigfox, and so forth. Note that in examples where wired constrained devices are used, beacons can be transmitted over wired links. 
     The beacon  106  includes advertised information that can be received by nearby devices, including the client device  108 . “Nearby” devices can include devices within range (e.g., wireless range) of the constrained device  102 , devices that are part of a logical or physical group, devices within an organization, devices on a network (such as a mesh network in which a beacon can be repeated by intermediary devices to reach more distant client devices), and so forth. 
     The client device  108  can include any type of computing device that is able to wirelessly receive information from the constrained device  102 , or to receive information over a wired link from a wired electronic device, and that is able to communicate over a network  110 . Examples of the client device  108  can include any or some combination of the following: a smartphone, a tablet computer, a notebook computer, a desktop computer, a wearable device (e.g., smart eyeglasses, a head-mounted electronic device, a smart watch, etc.), a game appliance, a home appliance, a vehicle, or any other type of electronic device. 
     Although just one client device  108  is shown in  FIG.  1   , it is noted that in other examples, multiple client devices  108  can be present. The multiple client devices  108  can receive the beacon  106  from the constrained device  102 . For example, different client devices can be associated with different users. Alternatively, the client device  108  or multiple client devices  108  can receive beacons from multiple constrained devices  102 . 
     In some examples, the network  110  can include a wireless network that allows for the client device  108  to wirelessly communicate with other devices. In alternative examples, the network  110  can include a wired network to which the client device  108  has a wired connection. In further examples, the network  110  can include both a wireless network and a wired network. 
     In accordance with some implementations of the present disclosure, the beacon  106  contains blockchain information, including a blockchain address  103  of an entity associated with the constrained device  102 . 
     A blockchain address refers to an identifier. In some examples, a blockchain address is analogous to an account number. An entity (such as a user or a device) can include one blockchain address, or can have multiple blockchain addresses. In some examples, a blockchain address can be generated based on use of a pair of a public key and a private key associated with an entity. 
     As used here, the blockchain address of an entity associated with the constrained device can refer to the constrained device&#39;s blockchain address, or can refer to the blockchain address of a product, a machine, a program, a human user, or another entity related to the constrained device. More generally, a blockchain address of an entity associated with a device can refer to information that is used to identify the entity associated with a device. 
     More generally, a blockchain information can refer to any information that can be used in a blockchain process. A blockchain process can refer to a process that uses a blockchain to store transactions in blocks of the blockchain. A transaction can refer to any event (e.g., an activity, data storage, program execution, etc.). 
     The blockchain address  103  can be pre-configured in the constrained device  102 , such as when the constrained device  102  is initially set up with firmware and/or software (more generally, machine-readable instructions), and/or when the constrained device  102  is being initialized or provisioned. Alternately, the blockchain address  103  can be obtained by the constrained device  102  over a secure connection from an external local or remote source. 
     The blockchain address  103  can be stored in a storage medium of the constrained device  102  in a secure manner. For example, the blockchain address  103  can be stored in encrypted form in the constrained device  102 . 
     If a blockchain address (or other blockchain information) were included in the beacon  106  in the clear (e.g., no encryption or other obfuscation technique is applied to the blockchain information), then a hacker might obtain the blockchain information for unauthorized reuse of the blockchain address for malicious purposes. 
     In accordance with some implementations of the present disclosure, instead of sending the blockchain address of an entity associated with the constrained device  102  in the clear, the blockchain address can be secured by applying a cryptographic function on the blockchain address. Applying the cryptographic function on the blockchain address results in computation of a secret value that is included in the beacon  106 . More generally, the beacon  106  includes a secure representation of the blockchain address. 
     Although reference is made to a secure representation of a blockchain address, it is noted that techniques or mechanisms according to some implementations of the present disclosure can be applied to other blockchain information. 
     In some examples, the constrained device  102  includes a time-based cryptographic logic  105  (which can be implemented with a hardware processing circuit or machine-readable instructions) to apply a time-based cryptographic function on the blockchain address  103 . The inputs to the time-based cryptographic function includes a timestamp (indicating the time at which the cryptographic function is being applied) and the blockchain address  103 . 
     In operation, the time-based cryptographic logic  105  can retrieve an encrypted version of the blockchain information  103  from a storage medium of the constrained device  102 , decrypt the encrypted version of the blockchain information to obtain decrypted blockchain information, and apply the time-based cryptographic function to the decrypted blockchain information to produce the secure representation of the blockchain information. 
     The time-based cryptographic function can include a time-based one-time password (TOTP) technique in some examples, which computes a secret value (referred to as a one-time password) using the timestamp and an encryption key. TOTP is an example of a hash-based message authentication code (HMAC) technique. 
     In other examples, other types of cryptographic functions can be used. 
     In addition to the secure representation of the blockchain address of an entity associated with the constrained device  102 , the beacon  106  can further include other information, such as a description of the constrained device  102  or a description of an entity associated with the constrained device  102 , and so forth. 
     The client device  108  includes a blockchain query application  109  that can generate a query  112  based on the information in the beacon  106 . A “query” can refer to a message (or collection of messages), an information element (or collection of information elements), or any other type of information that is submitted to trigger a response from another device. 
     The query  112  seeks information about a physical item. Examples of physical items include products, inventory, healthcare services, vehicles, humans, insurance policies, and so forth. 
     In some examples, the client device  108  can include a data presenter  111 , such as a display or an audio output device. The data presenter  111  can present data for consumption by a user of the client device  108 . 
     Additionally, in some examples, the client device  108  can include a cryptographic currency wallet application  113 , which can be used to make payment for a transaction or to make payment for accessing data (such as by submitting the query  112 ) or to make payment for any other purpose. 
     The query  112  can be submitted by the client device  108  to the network  110 . In some examples, the network  110  can include an access point (AP)  114 , or multiple APs. An AP can refer to an access network node that can be used by an electronic device to gain access to a network. In some examples, the AP  114  can be part of a wireless network (e.g., a Wi-Fi network). In other examples, the AP  114  can refer to a Wide Area Network) WAN or Low Power Wide Area Network (LPWAN) base station or transmission system base station, another low power long range access network (e.g., LoRa and Sigfox) node, or an access node of a cellular network. 
     In examples where the network  110  is a wired network, the AP  114  can include a bridge, switch or router (or multiple switches/routers) to allow for communication of data with other nodes. 
     In some examples according to the present disclosure, the query  112  can be sent through the network  110  to a data governance system  115 , which can be implemented as a computing node or a distributed arrangement of computing nodes. Multiple data governance systems  115  are shown in  FIG.  1   . In some examples, a data governance system  115  can be part of a smart contract manager  116 , while in other examples a data governance system  115  can be external of the smart contract manager  116 . In the ensuing discussion, reference to “the governance system  115 ” can be to either the governance system in the smart contract manager  116 , or outside the smart contract manager  116 . 
     The smart contract manager  116 , which can be implemented using a computing node (or a distributed arrangement of computing nodes). The smart contract manager  116  implements enforcement of smart contracts. Although just one smart contract manager  116  is shown in  FIG.  1   , it is noted that in other examples, there can be multiple smart contract managers. 
     The smart contract manager  116  can also include blockchain nodes  130  (also referred to as full nodes) that are part of a blockchain network  128 . 
     In some examples, a smart contract can be established among the multiple entities, such as a client entity associated with the client device  108  and an entity associated with stored information that the client device  108  is seeking to access. 
     In an example, the client device  108  can include a computer in a police vehicle or a police department, the client entity can be a police officer or a dispatcher, and the information sought is the information that is maintained by the Department of Motor Vehicles (DMV) of a particular jurisdiction. The smart contract in this example would be between the police department and the DMV. The smart contract can govern whether or not users of the police department (including police officers, dispatchers, etc.) are allowed to access DMV information, and if so, what types of information are allowed to be accessed given a privilege level corresponding to a role of the client entity. The smart contract can also specify other terms and rules pertaining to access of the DMV information by users of the police department. 
     In other examples, a smart contract can be established between other types of entities, and can include terms governing access of other types of information. 
     In some examples, the information that is being sought by the client entity can include information stored in a blockchain (e.g., in blocks of the blockchain). For example, in the context of a DMV, the information stored in the blocks of a blockchain can include historical information about a driver, including traffic violation tickets, arrest warrants, information pertaining to whether payment has been made of the traffic violation tickets, and so forth. The issuance of a traffic violation ticket, the issuance of an arrest warrant, the payment of a traffic violation ticket, and so forth, each constitutes a distinct transaction that can be represented by a respective block of the blockchain. 
     In other examples where the client entity is a shopper at a retail store, and the information that is sought by the client entity is information that is maintained by a product manufacturer or by the retail store, the smart contract can be between the shopper and the retail store/product manufacturer. In such examples, information pertaining to different products can be maintained by the retail store/product manufacturer in the blocks of a blockchain. 
     The smart contract manager  116  is a central entity that provides centralized management for purposes of enforcing terms of a smart contract. Note that the smart contract manager  116  is a centralized entity that is used in the context of a distributed storage of information in the blocks of a blockchain. 
     The query  112  includes the secure representation of the blockchain address of an entity associated with the constrained device  102 . The query  112  further specifies an identifier of an entity associated with the client device  108 . As used here, an identifier of an entity associated with a client device can refer to an identifier that identifies the client device, or an identifier that identifies an entity associated with the client device, such as a program executing in the client device, the user of the client device, or any other entity that is related to the client device. 
     Since the query  112  includes a secure representation of the blockchain address of an entity associated with the constrained device  102 , the smart contract manager  116  interacts with a blockchain address mapping system  118  to obtain the clear version of the blockchain address. The blockchain address mapping system  118  includes a blockchain address database  117  of registered blockchain addresses, and a time-based cryptographic logic  119  that generates a representation of a blockchain address in the same manner as the time-based cryptographic logic  105  of the constrained device  102 . 
     The blockchain address database  117  stores clear versions of blockchain addresses that have been provisioned at respective constrained devices. 
     The constrained device  102  is provisioned with a blockchain address ( 103 ) and the time-based cryptographic logic ( 105 ) from the blockchain address mapping system  118 . Once provisioned and synchronized, respective dynamic addresses (computed respectively by the time-based cryptographic logic  105  in the constrained device  102  and by the time-based cryptographic logic  119  in the blockchain address mapping system  118 ) are the same in both the constrained device  102  and the blockchain address mapping system  118 . A “dynamic address” refers to a secure representation of a blockchain address as computed by the time-based cryptographic logic ( 105  or  119 ). 
     Due to the constrained device  102  and the blockchain address mapping system  118  not being exactly time synchronized, there may be a difference in time synchronization between the dynamic addresses in the constrained device  102  and the blockchain address mapping system  118 . For example, at time x, the constrained device  102  produces dynamic address  54367 , while the blockchain address mapping system  118  produces dynamic address  54367 . At time x+5, the constrained device  102  produces dynamic address  54367 , while the blockchain address mapping system  118  produces dynamic address  54368 . However, at time x+6, the constrained device produces dynamic address  54368 , while the blockchain address mapping system  118  produces dynamic address  54368 . Thus, in the foregoing example, at time x+5, the dynamic addresses at the constrained device  102  and the blockchain address mapping system  118  are not same due to time synchronization. To address this issue, the blockchain address mapping system  118  can configure a time offset period that represents the difference in time synchronization between the constrained device and the blockchain address mapping system  118 . 
     The blockchain address database  117  can include a lookup function that can map different secure representations of blockchain addresses to respective clear versions of the blockchain addresses. For example, the lookup function can be in the form of a lookup table (or other lookup data structure) having entries, each entry mapping between a corresponding secure representation of a blockchain address and a respective clear version of the blockchain address. The lookup function takes the secure representation of the blockchain address of the query  112  and retrieves the corresponding clear version of the blockchain address, which is returned to the smart contract manager  116 . By checking with the blockchain address mapping system, the smart contract manager  116  is able to determine the identity (in the form of a clear version of the blockchain address) of the constrained device  102  about which information is requested. 
     In some examples, the smart contract manager  116  can interact with a network-based identity server  120 , which can be implemented as a computing node or a distributed arrangement of computing nodes. In some examples, the network-based identity server  120  can include an authentication, authorization, and accounting (AAA) server. In other examples, the network-based identity server  120  can be any type of server that can perform authentication and authorization tasks, as well as possibly accounting tasks. 
     The smart contract manager  116  can provide the following information obtained based on the query  112  to the network-based identity server  120 : the identifier of the client entity associated with the client device  108 , and the blockchain address (the clear version) of an entity associated with the constrained device  102 . The network-based identity server  120 , can identify a role of the entity associated with the client device  108 . Based on the identified role and the blockchain address, the network-based identity server  120  is able to identify a corresponding smart contract. A “role” of an entity can refer to information indicating a responsibility of or task(s) to be performed by the entity. For example, a human user can have a role of a police officer, a dispatcher, a shopper, a patient, a healthcare provider, etc. As another example, a machine or program can have a role of tracking inventory, managing an information technology infrastructure, and so forth. 
     Note that the smart contract manager  116  can interact with the blockchain address mapping system  118  and the network-based identity server  120  in parallel, since the two processes are independent of one another. 
     In some examples, the smart contract manager  116  can maintain a data repository  122  (stored in a storage device or a distributed arrangement of storage devices) that includes mapping information to map various client entity roles and blockchain addresses to corresponding smart contracts  124  that can be stored in the data repository  122  or a different data repository. Using the blockchain address and the identifier of an entity associated with the client device  108  obtained from the query  112  by the smart contract manager  116 , the network-based identity server  120  is able to identify the corresponding smart contract  124  from the data repository  122  and provide the smart contract  124  to the smart contract manager  116 . 
     In other examples, instead of interacting with the network-based identity server  120  to identify a role of the entity associated with the client device  108  and a smart contract corresponding to the identified role and the blockchain address, the smart contract manager  116  can perform the foregoing tasks itself, and can access the data repository  122 . 
     The smart contract manager  116  can check the rules of the smart contract to determine a privilege level of the client entity based on the determined role. For example, the smart contract can map different client entity roles to different privilege levels. Based on the determined privilege level, the smart contract manager  116  can determine whether information sought by the query  112  can be shared with the client device  108  (e.g., whether the client device  108  has authorization to receive the information sought by the query  112 ). For example, the smart contract can specify that information associated with a specific blockchain address can only be shared with certain users or client devices or other entities. Also, the smart contract can specify what information is to be shared. 
     If the smart contract manager  116  determines that the requested information sought by the query  112  can be shared with the client device  108 , the smart contract manager  116  sends the clear version of the blockchain address ( 126 ) to a blockchain network  128 . The blockchain address  126  can be used to retrieve relevant records from a blockchain. 
     The blockchain network  128  can include the blockchain nodes  130  (also referred to as “full nodes”), which are distributed nodes that store respective blocks of the blockchain and perform processing relating to the blockchain. The blockchain nodes  130  can also be considered to be part of the smart contract manager  116 . 
     A smart contract can also specify payment information for access to a service such as information sought by the client device  102 . Using the corresponding smart contract, the smart contract manager  116  can cause collection of payment according to the smart contract for access of information by the client device  102 . 
     In some examples, rather than store actual data, a block of a blockchain may include a pointer to a storage location in a distributed storage system  132  (including a distributed arrangement of storage nodes, which can be referred to as a swarm in some examples) that stores the actual data corresponding to the block. 
     Blocks in the blockchain have some amount of information about each transaction, such as which accounts are involved, how much currency was transferred, some detail about the transaction, a timestamp representing a time of the transaction, some data and a reference to the external distributed storage system  132  that contains additional data. A full node  130  can retrieve and share the additional data from the distributed storage system  132 . The full node  130  can send a retrieve request to the appropriate distributed storage system (e.g.,  132 ) based on the blockchain address. The retrieve request is validated, and any charges for requesting and obtaining the requested data can be applied. Once validated and any charges collected, the requested data can be returned from the distributed decentralized storage system  132  to the full node  130 , which sends the requested data to the smart contract manager  116 . 
     Note that the information obtained from the blockchain network  128  is created or provided by a data owner (or multiple data owners) that is (are) different from the constrained device  102 . The constrained device  102  is not able to manipulate the information, which may have been provided at different points in time, and from different data owners. As a result, the client entity associated with the client device  108  can be sure that the returned information is trustworthy and secure. 
     The requested data relating to the blockchain address  126  is returned back to the smart contract manager  116  by the blockchain network  128 . The smart contract manager  116  can then decide, based on the smart contract, which selected information (which can include all of the relevant data or just a subset of the relevant data) is to be sent back to the client device  108  in response to the query  112 . 
     The selecting of the information to send back to the client device  108  is part of the filtering that can be applied on the information obtained from the blockchain network  128 . The filtering is based on the determined privilege level associated with the client entity, and produces customized information for the client entity in response to the query  112 . The filtering produces different filtered response information for different privilege levels, as specified by a smart contract. 
     The smart contract manager  116  sends a response ( 134 ) containing the filtered information back to client device  108 . 
     At the client device  108 , the filtered information in the response ( 134 ) can be used for the corresponding interaction, such as a user deciding whether or not to purchase a product based on the selected information, a user viewing further information about a product or its attributes, the client device  108  or a different device tracking inventory based on the selected information, a user (e.g., healthcare provider such as a doctor or nurse) providing a healthcare service to a patient based on the selected information, the client device  108  or a different device detecting theft based on the selected information, a law enforcement officer performing a law enforcement activity based on the selected information, a user purchasing an insurance policy or an insurance company setting a rate for an insurance policy based on the selected information, and so forth. 
     In some examples, the smart contract manager  116  includes an authorization request monitoring system (ARMS)  136  to detect unauthorized use of a secure representation of a blockchain address. The ability to detect unauthorized use of a secure representation of a blockchain address can have applications in law enforcement, security, anti-fraud efforts, and so forth. This ability also aids in securing the integrity of blockchain addresses and the integrity of interactions between entities represented in a blockchain network. 
     The authorization request monitoring system  136  can be part of the smart contract manager  116 , and can include a hardware processing circuit or a combination of machine-readable instructions and the hardware processing circuit of the smart contract manager  116 . In other examples, the authorization request monitoring system  136  can be separate from the smart contract manager  116 , and can be implemented on a computing node (or multiple computing nodes) separate from the computing node(s) of the smart contract manager  116 . 
     For example, the authorization request monitoring system  136  can check to ensure that a secure representation of a blockchain address that has already been used once (such as in the query  112  sent from the client device  108  to the smart contract manager  116 ) is not reused again. If the authorization request monitoring system  136  detects that a particular secure representation of a blockchain address has been used more than once, then the authorization request monitoring system  136  can take a security action. The security action can include any or some combination of the following: issuing an alert to a target entity (e.g., a network administrator or other entity), rejecting the query  112  by sending an error response back to the client device  108 , quarantining the client device  108 , backlisting the client device  108 , or another security action. 
     Additionally, in some examples, a particular secure representation of a blockchain address can be associated with a specific time range and/or a specific location. If the authorization request monitoring system  136  detects that the particular secure representation of a blockchain address is used outside the specific time range and/or away from the specific location (e.g., a specific geographic region, a specific location in a network, etc.), then the authorization request monitoring system  136  can issue an alert to a target entity and/or can reject the query  112  by sending an error response back to the client device  108 . 
     The alert that is issued to a target entity regarding an unauthorized use of a secure representation of a blockchain address can allow for identification of a security breach in a system (e.g., a security breach caused by a masquerading attack or other type of attack). 
     In addition to the foregoing tasks, the authorization request monitoring system  136  can track and log all requests, irrespective of success or failure of the requests. For example, the authorization request monitoring system  136  can log approval of access of the response information by a client entity, and log a respective privilege level of the response information. In addition, the authorization request monitoring system  136  can update a block of a blockchain for a transaction that includes the approval of access to the response information. 
       FIG.  2    is a block diagram of a non-transitory machine-readable or computer-readable storage medium  200  storing machine-readable instructions that upon execution cause a system to perform various tasks. The machine-readable instructions include query receiving instructions  202  to receive, from a client device, a query comprising a representation of blockchain information of an entity associated with an electronic device that advertised the representation. 
     The machine-readable instructions further include privilege determining instructions  204  to determine whether a client entity associated with the client device has a privilege to access response information that is responsive to the query. The machine-readable instructions additionally include blockchain network request sending instructions  206  to, in response to determining that the client entity has the privilege to access the response information, send, to a blockchain network, a request containing the blockchain information to obtain the response information. 
       FIG.  3    is a block diagram of a data governance system  300  that includes a network interface  302  to communicate with a client device, and a processor  304  to perform various tasks. A processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit. A processor performing a task can refer to one processor performing the task, or multiple processors performing the task. 
     The tasks include a query receiving task  306  to receive, from the client device, a query comprising a representation of blockchain information of an entity associated with a constrained device that transmitted the representation. The tasks further include a smart contract privilege determining task  308  to determine, based on a smart contract, a privilege level of a client entity associated with the client device. The tasks also include a blockchain information obtaining task  310  to obtain the blockchain information based on the representation of the blockchain information. 
     In addition, the tasks include a blockchain network request sending task  312  to send, to a blockchain network, a request containing the blockchain information to obtain response information. The tasks further include a response information filtering task  314  to filter the response information based on the privilege level of the client entity, and a filtered information sending task  316  to send, to the client device, the filtered information in response to the query. 
       FIG.  4    is a block diagram of a client device  400  that includes a receiver  402  to receive, from a constrained device, a representation of blockchain information of an entity associated with the constrained device. In addition, the client device  400  includes a processor  404  to perform various tasks. The tasks include a query sending task  406  to send, to a server (e.g., the data governance system  115  of  FIG.  1   ), a query containing the representation. The tasks further include a filtered information receiving task  408  to receive, from the server, filtered information responsive to the query, the filtered information derived by the server based on a privilege level of the client device, a smart contract, and the blockchain information. 
     The storage medium  200  of  FIG.  2    can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and programmable read-only memory (EEPROM) and flash memory; a magnetic disk such as a fixed, floppy and removable disk; another magnetic medium including tape; an optical medium such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Storage can be located on premise, off premise, at a managed service provider, in a private or public cloud, or any combination thereof. 
     Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution. 
     In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.