Using Internet of Things (IoT) devices to facilitate blockchain transactions

Abstract

The present disclosure relates to facilitating blockchain transactions using Internet of Things (IOT) devices. A system and method for facilitating transactions between an Internet of Things (IoT) system and a blockchain peer without using a smart phone is disclosed. The system may have security, a channel manager, a message formatter, a parameter enumerator and formatter, a final formatter, a notifier, a monitor, and an integrator. The system may accept blockchain queries from IoT devices, and may reformat the blockchain queries and change the parameters to a format and parameter framework that can be operated by blockchain peers. The system may also accept responses from blockchain peers, and may reformat the responses and change the parameters to a format and parameter framework that can be operated by IoT devices. The system may send the reformatted response to the IoT device for display.

Description

Technical Field

[0001] The present disclosure relates to transactions utilizing Internet of Things (IoT) devices. Background Art

[0002] IoT is growing and will continue to grow as more smart devices enter the market. At the same time, the use of blockchain is also growing due to its highly secure nature and the wide variety of transactions that can be applied to blockchain technology. Currently, accessing blockchain ledgers with IoT devices such as smart watches requires the use of a smartphone. Summary of the invention

[0003] In general, the present disclosure describes the use of a system and method to facilitate blockchain transactions using IoT devices without the use of smartphones. The system and method can provide services such as security, channel management, message formatting, parameter enumeration and formatting, final formatting, notification, monitoring, integration, and event management. As used herein, the term "transaction" includes interactions, queries, responses, messages, or any other form of data communication.

[0004] In one example, various aspects of the technology of the present disclosure provide a system configured to facilitate transactions between an Internet of Things (IoT) device and a blockchain peer, the system comprising: a memory configured to store blockchain queries from the IoT device and blockchain responses from the blockchain peer; and one or more processors coupled to the memory and configured to: receive the blockchain query from the IoT device; reformat the blockchain query into a first defined format for the blockchain peer; send the reformatted blockchain query to the blockchain peer; receive a response from the blockchain peer; reformat the response into a second defined format for the IoT device; and send the reformatted response to the IoT device.

[0005] In another example, various aspects of the disclosed technology provide a method of facilitating transactions between an Internet of Things (IoT) device and a blockchain peer, including: receiving a blockchain query from the IoT device; and

[0006] reformatting the blockchain query into a first defined format for the blockchain peer; sending the blockchain query to the blockchain peer; receiving a response from the blockchain peer; reformatting the response into a second defined format for the IoT device; and sending the response to the IoT device.

[0007] In yet another example, various aspects of the technology of the present disclosure provide a computer-readable medium including instructions for causing one or more programmable processors to: receive a blockchain query from an Internet of Things (IoT) device; reformat the blockchain query into a first defined format for a blockchain peer; send the blockchain query to the blockchain peer; receive a response from the blockchain peer; reformat the response into a second defined format for the IoT device; and send the response to the IoT device.

[0008] The details of one or more examples are set forth in the accompanying drawings and the description below.Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a block diagram illustrating an example IoT device communicating with a blockchain data provider over a data bus according to the techniques of this disclosure.

[0010] Figure 2 is a block diagram of an example data bus in accordance with techniques of this disclosure.

[0011] Figure 3 is a block diagram of an example logical partition (LPAR) in accordance with the techniques of this disclosure.

[0012] Figure 4 is a block diagram of an example server capable of implementing a databus and / or LPAR in accordance with the techniques of this disclosure.

[0013] Figures 5A-5E is a flow diagram illustrating an example facilitation of a transaction between an IoT device and a blockchain ledger in accordance with techniques of this disclosure.

[0014] Figure 6 is a block diagram of an example of a smart watch according to the techniques of this disclosure.

[0015] Figures 7A-7C is a flow diagram illustrating facilitation of transactions between a smartwatch and a blockchain ledger in accordance with the techniques of this disclosure. DETAILED DESCRIPTION

[0016] Currently, IoT devices cannot perform blockchain transactions without utilizing a smartphone. This is true even in the case of smartwatches where there are sophisticated and well-defined APIs. With the proliferation of blockchain transactions and the proliferation of IoT devices, it is desirable to enable IoT devices (e.g., smartwatches) to access blockchain ledgers and perform blockchain transactions without having to connect through a smartphone. For example, if a smartphone is not within the communication range of the IoT device, or if the smartphone is powered off, the IoT device will not be able to access the blockchain ledger and will not be able to perform blockchain transactions. Therefore, it is desirable to utilize IoT devices to facilitate blockchain transactions without the need for a smartphone.

[0017] Figure 1 1 is a block diagram illustrating an IoT device that performs transactions with a blockchain ledger via a data bus. IoT device 100 is shown communicating with blockchain ledger 135 via data bus 120 and LPAR 140A. Several blockchain peers implemented in LPARs 140A, 140B, and 140C are depicted. While there are three peers in this example, there can be any number. Each peer maintains a copy of blockchain ledger 135 and smart contract 195.

[0018] The IoT device 100 is shown with multiple blockchain applications 110. In the example of a smartwatch, these applications are called widgets. A widget is any application other than displaying the time. Although a smartwatch is an example of an IoT device that can be used as described in the present disclosure, the systems and methods described herein can be used with any IoT device that is capable of making queries and receiving response data (e.g., materialized view data). As used herein, a query can include a request for data, a request for a transaction, or a request for any other blockchain operation.

[0019] By way of example, some of the applications 110 that may reside on an IoT device include supply chain management, financial transactions, event horizon displays, network status displays, web services, news feeds, and ticket purchases. There may be many other applications. The IoT device 100 may also include a display system 115. In one example, the display system 115 may display the applications 100 in a graphical user interface in a manner such that a user may touch a representation of a particular application in order to activate the application and transmit a query.

[0020] The data bus 120 may be, for example, a Hyperledger Fabric gateway that may be implemented on a server in the cloud. As such, the data bus may include a memory 130 and one or more processors 121. The memory 130 may contain software components that, when executed, cause the one or more processors 121 to facilitate transactions between the IoT device 100 and the blockchain ledger 135. These software components will be discussed further below.

[0021] To perform blockchain transactions, appropriate end-to-end security can exist between the IoT device 100 and the hyperledger fabric 150A. In some examples, role-based access control (RBAC) is used to provide end-to-end security. In some examples, roles are propagated from the IoT device 100 to the data bus 120 and packaged into blockchain queries. The blockchain peers (in LPARs 140A-140C) can then respond to the RBAC to allow permitted actions such as Read, ReadOnly, and Update to occur. In some examples, the IoT device 100, the data bus 120, and the hyperledger fabric 150A perform transactions using Java Web Tokens (JWT).

[0022] The data bus 120 dynamically configures the format and content for the supported hyperledger components. In some examples, the data bus 120 dynamically configures the hyperledger channels. In some examples, the data bus 120 dynamically configures the Rest API integration. Events can be propagated from the hyperledger fabric 150A to the connected IoT devices 100.

[0023] To facilitate transactions between the IoT device 100 and the blockchain ledger 135, the data bus 120 may receive queries from the IoT device 100, decrypt them, format them into an appropriate message format, satisfy the necessary protocols for performing transactions with the blockchain ledger 135 within the LPAR 140A, for example, and encrypt the message before sending it to the LPAR 140A. It may also receive responses from the distributed blockchain network 190, decrypt them, format them into an appropriate message format, satisfy the necessary protocols before sending them to the IoT device 100. In this way, the data bus 120 acts as a connector to facilitate transactions between the IoT device 100 and the blockchain ledger 135 without the need for a smartphone.

[0024] The data bus 120 can speak the same security language and can present appropriate security credentials in a continuous manner in order to access the blockchain ledger 135 and can perform blockchain transactions, such as adding additional records to the ledger.

[0025] In this example, LPAR 140A within blockchain network 190 is associated with IoT device 100 and is responsible for encryption / decryption, compression, and ensuring that all data bound to blockchain ledger 135 complies with the correct security regime. To assist data bus 120 in facilitating transactions between IoT device 100 and blockchain ledger 135, LPAR 140A may contain IoT domain 170A. IoT domain 170A may be a specialized application that includes search, analysis, summary statistics, aggregation applications for creating materialized views of ledger data filtered by input parameters received from data bus 120. The materialized view may then be sent back onto data bus 120 to drive IoT visual and interactive (transactive) elements for display on display system 115.

[0026] If classic blockchain peer-to-peer replication is involved, then the replicator (not shown) is responsible for ensuring that the replicated LPAR 140 contains the same data and security regime as the original LPAR 140. Connecting to or refreshing data from any original, distributed, or replicated LPAR 140 requires immediate peer synchronization as dictated by the security regime configured for the blockchain ledger 135. Therefore, the data bus 120 communicates with the LPAR 140A using the protocol specified by the security regime configured in the LPAR 140A. The data bus 120 can therefore be the primary agent within the security regime to ensure that the IoT device 100 data feed is properly formatted and encrypted in order to save new records to the blockchain ledger 135. The data bus 120 can also be the primary agent responsible for ensuring that the materialized view data it receives from the IoT domain 170A is compatible with the connected IoT device 100 for display on the display system 115.

[0027] Figure 2 1 is a block diagram of a data bus 120 according to the techniques of the present disclosure. Several components are shown as being stored in a memory 130. These components include security 122, a channel manager 123, a message formatter 124, a parameter enumerator and formatter 125, a final formatter 126, a notifier 127, a monitor 128, and an integrator 129. Although these are shown separately, they can be a single software program, or can be multiple programs. In one example, components 122-129 are JavaScript Object Notation (JSON) schema files.

[0028] Components 122-129, when executed, may cause one or more processors 121 to operate in a variety of ways. Security 122 may cause one or more processors 121 to encrypt messages sent by the data bus to IoT device 100 and messages sent to LPAR 140A. Security 122 may also cause one or more processors 121 to decrypt messages received by data bus 120 from IoT device 100 and from LPAR 140A. In addition, security 122 may cause one or more processors 121 to encrypt and decrypt messages to and from other external integrations (not shown).

[0029] The channel manager 123 can enable one or more processors 121 to provide a scaling mechanism for data transmission between the IoT device 100 and the LPAR 140A. For example, when a larger amount of data needs to be sent, the channel manager 123 can enable one or more processors 121 to open a larger bandwidth channel to facilitate the transmission. This larger bandwidth channel does not have to be a single channel, but can be a collection of channels or virtual channels.

[0030] The message formatter 124 may cause the one or more processors 121 to format messages received from the IoT device 100 using appropriate formats, data, and parameterizations that may be consumed by the LPAR 140A and the blockchain peers therein.

[0031] The parameter enumerator and formatter 125 may cause the one or more processors 121 to enumerate and format queries from the IoT device 100 for each required calling convention associated with a particular type of blockchain query.

[0032] The final formatter 126 may cause the one or more processors 121 to format the data sent by the data bus 120 to the IoT device 100 using the appropriate format, data, and parameterization that can be consumed by the IoT device 100 .

[0033] The notifier 127 may cause the one or more processors 121 to send a notification to the IoT device 100. In one example, the notifier 127 may cause the one or more processors 121 to send a notification to the IoT device 100 based on the one or more processors 121 detecting a state change of the blockchain ledger 135.

[0034] The monitor 128 may cause the one or more processors 121 to monitor each blockchain data feed associated with the blockchain application 110 on the IoT device 100 .

[0035] The integrator 129 may cause the one or more processors 121 to provide separate channels for each blockchain feed associated with the blockchain application 110 on the IoT device. For example, the one or more processors 121 may provide a financial channel for financial blockchain data feeds, a network state channel for network state data feeds, a blockchain news channel for blockchain news feeds, a web service API channel for web service API data feeds, an event horizon channel for event horizon data feeds, and a supply chain status channel for supply chain status data feeds.

[0036] Figure 3 1 is a block diagram of a blockchain peer implemented in an LPAR according to the technology of the present disclosure. LPAR 140A may contain a copy of blockchain ledger 135 and smart contract 195. LPAR 140A may also contain hyperledger fabric 150A. Hyperledger fabric 150A may include peers. Peers are network nodes that maintain the state of blockchain ledgers (in this case, blockchain ledger 135) and manage chaincodes. Hyperledger fabric 150A may also include an ordering service. The ordering service packages transactions into blocks to be delivered to peers. It also handles configuration transactions to set network policies. Hyperledger fabric 150A may also include a fabric certificate authority.

[0037] LPAR 140A may include a secure service container 160A and a secure execution context 180A. LPAR 140A may also include an IoT domain 170A. IoT domain 170A may be a specialized application that includes search, analysis, summary statistics, aggregation applications for creating materialized views of ledger data filtered by input parameters received from data bus 120. IoT domain 170A may be a secure area where business logic, blockchain create-read-update-delete (CRUD) queries occur, and where smart contract chaincode is loaded and executed to enable blockchain transactions to occur.

[0038] Although not shown for simplicity purposes, in one example, the IoT domain 170A can be located within the blockchain ledger 135 itself. The IoT domain 170A can be, for example, an application stored in a server or multiple servers in the cloud. The IoT domain 170A can be loaded and executed within the LPAR 140A or the virtual machine of the blockchain ledger 135.

[0039] LPAR 140A may also include security 175 and event manager 185. Security 175 may provide user authentication and data encryption and decryption, similar to security 122 in data bus 120. Security 175 may also include key management services and certificate authorities. Event manager 185 may monitor state changes of blockchain ledger 135. Some possible state changes include new transactions occurring, views being updated, or new blockchain peers being added or deleted. When a state change occurs, the event manager may report the state change to data bus 120. For example, event manager 185 may raise an event from a chaincode and propagate the event to data bus 120. In one example, this propagation is done through a Rest API.

[0040] Although not shown for purposes of simplicity, LPAR 140A may also contain membership information, consensus information, transaction information, chaincodes, governance information, blockchain management and operations services, and system integration services.

[0041] Although security 175 and event manager 185 are shown as being external to the hyperledger fabric 150A, they may be implemented in the hyperledger fabric 150A. In some examples, the blockchain ledger 135, smart contracts 195, and / or chaincodes (not shown) may be located in the IoT domain 170A.

[0042] Figure 4 is a block diagram illustrating an example server 205 that may be configured to implement the data bus 120. The server 205 may include a network interface 245 for communicating with the IoT device 100, the data bus 120, and / or the LPAR 140A. The network interface 245 may include a wireless interface such as Wi-Fi, Bluetooth, or a wireless telecommunications standard such as GSM, CDMA, W-CDMA, TS-CDMA, LTE, or a fifth generation wireless standard referred to as 5G. The network interface 245 may also include a wired interface such as Ethernet.

[0043] The server 205 may also include one or more processors 215 coupled to a memory 225. The memory 225 may contain an application 255. The application 255 may include code configured to cause the one or more processors 215 to perform each action of the data bus 120, for example, based on the security 122, the channel manager 123, the message formatter 124, the parameter enumerator and formatter 125, the final formatter 126, the notifier 127, the monitor 128, and the integrator 129. Although shown as a single application, the application 255 may be a plurality of different applications.

[0044] Since IoT devices may have different interfaces and require different data formats and protocols to communicate with them, the data bus 120 may be programmable. For example, when the data bus 120 is implemented on the server 205, the data bus 120 may include an application 155. The application 155 may contain templates that may be configured to facilitate specific blockchain transactions with specific IoT devices. Each of the security 122, channel manager 123, message formatter 124, parameter enumerator and formatter 125, final formatter 126, notifier 127, monitor 128, and integrator 129 may be a programmable template to facilitate such transactions. In one example, each of the security 122, channel manager 123, message formatter 124, parameter enumerator and formatter 125, final formatter 126, notifier 127, monitor 128, and integrator 129 is a JSON schema file.

[0045] The server 205 may also be configured to implement the LPAR 140A. For example, the application 255 may include code for causing the one or more processors 215 to implement the hyperledger fabric 150, the SSC 160, the IoT domain 170, the SEC 180, the security 175, and the event manager 185 and to read and write the blockchain ledger 135 to the memory 225.

[0046] Figures 5A-5E 1 is a flow chart illustrating a method 300 of a data bus 120 that facilitates blockchain transactions through IoT devices. In this example, the data bus 120, blockchain network 190, peers with working ledgers 135 and smart contracts 195 exist, and appropriate accounts, security elements, and membership services are in place. Figure 5A In the example, the user may select one of the blockchain applications 110 of the IoT device 100, for example, the event horizon of the cost-quantity-profit analysis chart that the user wishes to display for the supply chain (310). The IoT device 100 may then animate the event horizon blockchain application 100 in the display 115 to the event horizon feed display (320). The user may then attempt to query the blockchain ledger 135. The IoT device 100 may then respond and generate and encrypt the query using, for example, a private key stored in a memory within the IoT device 100 (325).

[0047] refer to Figure 5B , the data bus 120 receives the query from the IoT device 100 (340). The security 122 of the data bus 120 can then decrypt the query using, for example, a public key (345). For example, the public key can be stored in the memory 130.

[0048] The data bus 120 can then determine whether the message format is appropriate or correct (350). If not, the data bus 120 can send a message back to the IoT device indicating that the transaction will not occur (355).

[0049] If the message format is appropriate, the message formatter 124 of the data bus 120 may format the blockchain query and the protocol therein in a manner suitable for an event horizon transaction and as expected or consumable by the IoT domain 170A and the Hyperledger Fabric 150A within the LPAR 140A (360).

[0050] The security 122 of the data bus 120 may encrypt the reformatted query using a private key associated with the IoT device 100 so that it may perform a transaction with the blockchain ledger 135. The private key may be stored, for example, in the memory 130 (370).

[0051] The channel manager 123 of the data bus 120 may open a channel to the LPAR 140A, and the data bus 120 may then send the encrypted and reformatted query to the LPAR 140A containing the hyperledger fabric 150A associated with the IoT device 100 (380).

[0052] refer to Figure 5C , LPAR 140A receives the encrypted query from data bus 120 (390). Security 175 of LPAR 140A may decrypt the query using a public key, which may be stored in memory within the server on which it resides (400). Security 175 may determine whether the query is approved by the security authority (410). If not, LPAR 140A may send a message back to the data bus to deny the transaction (415). If approved, IoT domain 170 may process the query (420). This processing may include processing a search of blockchain ledger 135, creating a record request, accessing or generating a materialized view of data within blockchain ledger 135, and / or formatting response data, among other things. Security 175 of LPAR 140A may encrypt the response (423).

[0053] LPAR 140A may transmit encrypted response data to data bus 120 (425). This response data may be a materialized view of the data within blockchain ledger 135.

[0054] refer to Figure 5D, the data bus 120 may receive the response data from the LPAR 140A (430). The security 122 of the data bus 120 may then decrypt the response data using, for example, a public key stored in the memory 130 (435). The final formatter 126 of the data bus 120 may reformat the data and modify the protocol of the decrypted response data in a manner so that it can be consumed by the IoT device 100, such as to enable the IoT device 100 to display the data on the display 115 (440). In an example where the IoT device 100 is a smartwatch, it may be an Android 2.0 smartwatch with a well-defined API, and the response data may be reformatted to meet the specification of the API. The security 122 of the data bus 120 may then encrypt the reformatted response using, for example, a private key that may be stored in the memory 130 (445). The data bus may then transmit the reformatted response to the IoT device 100 (455).

[0055] refer to Figure 5E , the IoT device 100 may receive the encrypted and reformatted response (460). The IoT device 100 may then use, for example, the public key to decrypt the encrypted and reformatted response (465). The IoT device 100 may then display a materialized view of the data within the blockchain ledger 135 on the display 115.

[0056] In another example, a user may select a ticketing application on the IoT device 100 to purchase an airline ticket. Again, the data bus 120, blockchain network 190, peers with working ledgers 135 and smart contracts 195 should exist, and the appropriate accounts, security elements, and membership services are in place. This example will be similar to the example about Figures 5A-5E However, because the IoT device 100 may be accessing a different blockchain ledger, the LPAR, Hyperledger Fabric, SSC, IoT domain, SEC, blockchain ledger, smart contract, security, and / or event manager may be different.

[0057] The channel manager 123 of the data bus 120 may configure different channels to communicate with the LPAR. The message formatter 124, the parameter enumerator and formatter 125, and the final formatter 126 may format the data and parameters differently to facilitate communication between the ticket purchasing application and the LPAR.

[0058] In the ticket purchase example, refer to Figure 5A, the user may select the ticket purchase blockchain application (310). The IoT device 100 may then animate the event horizon blockchain application 100 in the display 115 to display the ticket purchase feed (320). For example, the user may then attempt to query the blockchain ledger 135 to purchase an airline ticket. The IoT device 100 may then respond and generate and encrypt the query using, for example, a private key stored in a memory within the IoT device 100 (325).

[0059] refer to Figure 5B , the data bus 120 receives the query from the IoT device 100 (340). The security 122 of the data bus 120 can then decrypt the query using, for example, a public key (345). For example, the public key can be stored in the memory 130.

[0060] The data bus 120 can then determine whether the message format is appropriate (350). If not, the data bus 120 can send a message back to the IoT device indicating that the transaction will not occur (355).

[0061] If the message schema is appropriate, the message formatter 124 of the data bus 120 may format the query and the protocol in a manner suitable for purchasing a ticket and expected and consumable by the IoT domain 170A and the Hyperledger Fabric 150A of the LPAR 140A (360).

[0062] The security 122 of the data bus 120 may use a private key associated with the IoT device 100 to encrypt the reformatted query so that it can be transacted with the blockchain ledger 135. For example, the private key may be stored in the memory 130 (370).

[0063] The channel manager 123 of the data bus 120 may open a channel to the LPAR 140A, and the data bus 120 may then send the encrypted and reformatted query to the LPAR 140A containing the hyperledger fabric 150A associated with the IoT device 100 (380).

[0064] refer to Figure 5C , LPAR 140A receives the encrypted query from data bus 120 (390).

[0065] The security 175 of LPAR 140A decrypts the query using a public key, which may be stored in memory within the server where it resides (400). The security 175 may determine whether the query is approved by the security authority (410). If not, then LPAR 140A may send a message back to the data bus to deny the transaction (415). If approved, then the IoT domain 170 may process the query (420). In this example, this may include searching the blockchain ledger 135 for available tickets, creating a record request to purchase the ticket, accessing or generating a materialized view of the data within the blockchain ledger 135, and / or formatting response data, etc. The security 175 of LPAR 140A may encrypt the response.

[0066] LPAR 140A may transmit encrypted response data to data bus 120 (425). This response data may be a materialized view of the data within blockchain ledger 135.

[0067] refer to Figure 5D , the data bus 120 may receive the response data from the LPAR 140A (430). The security 122 of the data bus 120 may then decrypt the response data using, for example, a public key stored in the memory 130 (435). The final formatter 126 of the data bus 120 and the parameter enumerator and formatter 125 may reformat the data and modify the protocol of the decrypted response data in a manner so that it can be consumed by the IoT device 100, such as to enable the IoT device 100 to display the data on the display 115 (440). In an example where the IoT device 100 is a smartwatch, it may be an Android 2.0 smartwatch with a well-defined API, and the response data may be reformatted to meet the specification of the API. The security 122 of the data bus 120 may then encrypt the reformatted response using, for example, a private key that may be stored in the memory 130 (445). The data bus may then transmit the reformatted response to the IoT device (455).

[0068] refer to Figure 5E , the IoT device 100 may receive the encrypted and reformatted response (460). For example, the IoT device may then decrypt the encrypted and reformatted response using the public key (465). The IoT device 100 may then display a materialized view of the data within the blockchain ledger 135 (such as the purchased ticket) on the display 115.

[0069] Figure 65 is a block diagram of a smart watch face. In one example, the display 115 of the IoT device can be a smart watch face 500. In some examples, the smart watch face 500 displays a graphical user interface of multiple widgets 510-570. In some examples, each of these widgets 510-570 can be activated by a user touching the icon of each widget. These widgets can include supply chain management 510, financial transactions 520, event horizon display 530, network status display 540, web services 550, news feed 560, and ticket purchase 570. For example, a user can conduct a transaction with a given application or widget through a finger gesture on the smart watch face 500. In some examples, the widget can display a menu from which the user can select an item. In other examples, the user can further conduct a transaction with a given widget through voice commands and / or by pressing a button.

[0070] Figures 7A-7C is a flow chart illustrating a smartwatch conducting transactions with a blockchain data provider via a data bus according to the technology of the present disclosure. Although reference is not discussed in this smartwatch example Figures 5A-5E Each of the techniques discussed, however Figures 5A-5E The technology of the example can also be used alone in a smart watch, or in combination with Figures 7A-7C Used in conjunction with examples.

[0071] exist Fig. 7A In the example, the smart watch 580 or the user ensures that the smart watch 580 has connectivity to the Internet (600). As discussed with respect to the IoT device 100, this can be through a wireless or wired connection. If the smart watch 580 does not have connectivity, then, for example, it can automatically turn on a wireless modem to connect to the Internet, or, for example, it can prompt the user to connect the smart watch 580 to the Internet.

[0072] The smart watch 580 or the user can then determine whether the appropriate blockchain user application (e.g., 510) is installed on the smart watch 580 (605). If not, the smart watch 580 or the user can search for the blockchain application (e.g., 510) on, for example, the Internet or in an application store, and download the blockchain application (e.g., 510) to the smart watch 580 (610). The smart watch 580 or the user can then install the blockchain application (e.g., 510) on the smart watch 580 (615).

[0073] Once the blockchain application (e.g., 510) is installed, the smart watch 580 or the user can activate the blockchain application (e.g., 510) on the smart watch face 500 (620). For example, the smart watch 580 can determine whether there is a user profile configured for the user of the blockchain application (625) through the blockchain application (510). If there is no user profile configured for the user of the blockchain application (e.g., 510), the smart watch 580 or the user can create a user profile (630). The user profile can be created through the blockchain application (e.g., 510). For example, the blockchain application (e.g., 510) can connect to the edge service to create a blockchain user profile.

[0074] Once the user profile exists, the smart watch 580 can determine whether the blockchain data feed for the blockchain application (e.g., 510) is configured (635). In some examples, the smart watch 580 can determine whether the blockchain data feed is configured by the blockchain application (e.g., 510). If they are not configured, the smart watch 580 can configure the data bus 120 for the blockchain data feed (640). In some examples, the smart watch 580 can configure the data bus 120 for the blockchain data feed by the blockchain application (e.g., 510). The blockchain application (e.g., 510) can request the edge service to configure the basic data bus channel configuration for the data feed. The data bus channel manager 123 can then allocate (one or more) channels for the data feed.

[0075] refer to Figure 7B , the data bus 120 may then query LPAR 140A, receive the data feed status from LPAR 140A, and send the data feed status back to the smart watch 580 (645). The smart watch 580 or the user may determine whether the data feed status is being actively displayed on the smart watch face 500 (650). If not, the smart watch may prompt the user to determine whether the user wants to retry the configuration of the data feed (665). For example, if the user indicates that they do not want to retry the configuration, the smart watch 580 may close the blockchain application (e.g., 510). In another example, if the user does not respond to the prompt after a predetermined time period, the smart watch 580 may close the blockchain application (e.g., 510). In yet another example, the smart watch 580 may keep the blockchain application (e.g., 510) open, but take no further action to obtain and / or display the data feed. If the user indicates that they want to retry the configuration of the data feed, the smart watch 580 may return to (A) and check whether the data feed is configured as described above ( Fig. 7AAlternatively, the smartwatch 580 may configure the data bus 120 for the blockchain data feed without first rechecking whether the data feed is configured ( Fig. 7A 640 in ).

[0076] Return to reference Figure 7B , if the data feed status is being actively displayed on the smart watch face 500, the blockchain application (e.g., 510) can respond to the user input (660). In some examples, the user input includes a gesture. In some examples, the user input includes a voice command. In some examples, the user input includes a button press. The smart watch 580 can monitor whether the user requests to exit the blockchain application (e.g., 510) (665). If the user requests to exit the blockchain application (e.g., 510), the smart watch 580 can close the blockchain application (e.g., 510). If the user has not requested to exit the application and has provided user input, the smart watch 580 can send a query to the data bus 120 through the blockchain application (e.g., 510) (670).

[0077] Reference now Figure 7C , for example, data bus 675 may receive the query as described above, reformat the query and parameters, and send the reformatted query to a blockchain data provider that may be within LPAR 140A (675). The blockchain data provider (e.g., LPAR 140A) may execute the reformatted query and provide a response to data bus 120 (680). Data bus 120 may then receive the response, format the response as described above, and send the reformatted response to smart watch 580 (685). Smart watch 580 may then render the data in a blockchain application (e.g., 510) on smart watch face 500.

[0078] At any possible technical detail combination level, various aspects of the present disclosure may be implemented as systems, methods and / or computer program products. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present invention.

[0079] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples of computer-readable storage media (a non-exhaustive list) include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a CD-ROM, a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure in a groove on which instructions are stored, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium is not to be interpreted as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

[0080] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0081] The computer program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be personalized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present invention.

[0082] Various aspects of the present invention are described herein with reference to the flow charts and / or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flow chart and / or block diagram and the combination of each box in the flow chart and / or block diagram can be implemented by computer-readable program instructions.

[0083] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0084] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0085] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuit systems. Thus, as used herein, the term "processor" may refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated in a combined codec. Moreover, the techniques may be fully implemented in one or more circuits or logic elements.

[0086] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to multiple aspects of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and the part of the module, program segment or instruction contains one or more executable instructions for realizing the specified logical function. In some alternative implementations, the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or action, or can be implemented with a combination of special hardware and computer instructions.

[0087] The embodiments of the present invention have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

[0088] It will be appreciated that, depending on the example, certain actions or events of any of the techniques described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., not all described actions or events are required to implement the techniques). Moreover, in some examples, actions or events may be performed concurrently rather than sequentially, such as through multithreading, interrupt handling, or multiple processors.

[0089] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for facilitating transactions between an IoT device and a blockchain peer, comprising: Receive blockchain queries from IoT devices; reformatting the blockchain query into a first defined format for the blockchain peer, wherein reformatting the blockchain query comprises modifying parameters in the blockchain query so that the parameters in the reformatted blockchain query are consumable by the blockchain peer; sending the blockchain query to the blockchain peer; receiving a response from the blockchain peer; reformatting the response into a second defined format for the IoT device, wherein reformatting the response comprises modifying parameters in the response so that the parameters in the reformatted response can be consumed by the IoT device; and The response is sent to the IoT device.

2. The method of claim 1 , further comprising decrypting the blockchain query, encrypting a reformatted blockchain query, decrypting the response, and encrypting a reformatted response.

3. The method of claim 1 , further comprising scaling channel bandwidth based on the amount of data in the blockchain query or response.

4. The method of claim 1 , further comprising monitoring state changes of the blockchain ledger.

5. The method of claim 1, further comprising sending a notification to the IoT device.

6. The method of claim 1, further comprising monitoring a plurality of blockchain feeds from the blockchain peers.

7. The method of claim 1 , further comprising providing a channel for each of a plurality of blockchain applications on the IoT device and each of a corresponding plurality of blockchain feeds from the blockchain peers.

8. The method of claim 1 , further comprising determining whether a message schema is correct for the blockchain query, and notifying the IoT device if the message schema is incorrect.

9. A computer program product comprising instructions for causing one or more programmable processors to perform the actions of the method of any one of claims 1 to 8.

10. A system configured to facilitate transactions between an Internet of Things (IoT) device and a blockchain peer, the system comprising: a memory configured to store blockchain queries from the IoT device and blockchain responses from blockchain peers; as well as One or more processors, coupled to the memory and configured to perform the actions of the method as claimed in any one of claims 1 to 8.

11. A computer system comprising modules for performing the steps of the method as claimed in any one of claims 1 to 8.

Images