Blockchain key generation

Abstract

1. A method and system for generating transactions, the method including: defining one or more conditions for a transaction; adding the one or more conditions to a block in a distributed ledger; generating, by a first device, an offer for a digital asset, where the offer is digitally signed by a secure applet executing within a UICC of the first device; generating, by a second device, a request for the digital asset, where the request is digitally signed by a secure applet executing within the UICC of the second device; authenticating the digital signature of the offer and the request; determining that the offer and request satisfy the one or more conditions added to the distributed ledger and if the one or more conditions are satisfied by the offer and request, digitally signing the digital asset by the secure applet executing within the UICC of the first device; transmitting the signed digital asset from the first device to the second device; authenticating the digital signature of the signed digital asset and adding a transaction to a block on the distributed ledger recording the transmission of the digital asset from the first device to the second device.

Description

Technical Field

[0005] ,

[0004] , ,

[0001] Field of the Invention The present invention relates to a system and method for recording transactions in a distributed ledger, particularly for securely generating such transactions by a device or object.

Background Art

[0002] Background of the Invention It is generally necessary for different entities to interact and transact with each other to exchange value. However, for this to be done in a safe and secure manner for each party to the transaction, there needs to be a level of trust between the transaction entities. Without such trust, enforceable contracts and other structures and procedures such as third-party institutions or intermediaries are required.

[0003] Cryptocurrencies are digital currencies in the form of alternative currencies (or private currencies). They typically provide non-centralized or distributed currencies and / or media of exchange, unlike centrally controlled government-issued currencies (e.g., fiat currencies). Digital currencies may be transacted or sent from one owner or entity to another and may be used for any purpose such as the purchase of goods, the purchase of services, or the acquisition of data. Thus, digital currencies represent an alternative means to traditional currencies.

[0004] An example of a cryptocurrency is Bitcoin, although many other cryptocurrency systems have been devised. Bitcoin was developed by Satoshi Nakamoto, and the original paper "Bitcoin: A Peer-to-Peer Electronic Cash System" that outlines the basics of Bitcoin technology and principles is described at https: / / bitcoin.org / bitcoin.pdf. <00000​​The underlying technologies of decentralized cryptocurrencies, such as distributed ledgers, can also be used to record other types of transactions, forming a verifiable history of exchanges or other forms of data without requiring trust between entities. Distributed ledgers, such as blockchains, enable transactions and exchanges of value in the absence of such trust. However, this requires the use of a public blockchain to form a consensus that is difficult to destroy or control by individual parties or entities. This usually takes the form of a competition to reach a consensus based on proof-of-work, which itself can consume very high levels of resources in the form of computation and power.

[0006] An alternative approach involves using a private blockchain, but this again raises the need to build trust between the parties involved and the owners and controllers of the private blockchain itself.

[0007] Trust can be built by determining and verifying the identity or other characteristics of an entity, but this effort introduces overhead and additional work, potentially leading to inefficiencies and additional load on computer or telecommunications networks. Furthermore, such verification or checking often relies on separate sources, each of which may also need to be verified and approved or trusted. This can require considerable bandwidth and processing resources. Therefore, this approach may only be suitable for specific entities trading beyond a certain value where the overhead is not a significant burden. This also hinders the exchange of new value between new entities or large-scale, temporary exchanges of low value. For small or numerous entities or devices, such as those forming the Internet of Things or other low-computational power devices, the overhead can far outweigh small value exchanges. Therefore, this limits the efficiency and scalability required to exchange value or data packages, especially for autonomous or unsupervised devices.

[0008] Therefore, methods and systems are needed to overcome these problems. [Overview of the project] [Means for solving the problem]

[0009] Summary of the Invention Transactions are generated by first pre-defining one or more conditions for those transactions as predetermined conditions. One or more of these conditions must be met for a transaction to proceed. In some exemplary implementations, some conditions themselves can be conditions for other conditions. For example, if a certain condition is met, one or more other conditions (even if they are not met) may be ignored, or other conditions may need to be met in order for the transaction to proceed. Preferably, these conditions are within a distributed ledger. No S Mart contract format While such conditions or requirements may be defined and stored in a variable, other techniques may be used to capture and implement them.

[0010] A first device or other entity creates an offer for a digital asset. The digital asset may represent a physical asset or server, or it may instead form an asset of actual value (e.g., data). The device has a UICC (e.g., SIM or eSIM) which includes a processor and memory (preferably both secure and within the secure area are of the UICC). The offer is digitally signed by the UICC, preferably within the secure area of ​​the UICC. In exemplary implementations, conditions may be set before any offer is generated. The conditions may be set, for example, by an external device, a server, or one or both of the entities.

[0011] Separately, a second device generates a request for the digital asset. This may occur before or after the offer for the digital asset is created. Here again, an applet in the UICC of the second device signs the request (or bid). Authentication of both the offer and the request takes place. This may be performed by the second device (authenticating the offer), the first device (authenticating the request), and / or a separate device or server, or preferably a node in a distributed ledger. The applet may be hosted on a secure element on the UICC to perform various steps, for example, one or more of the following: bidding, offering, digital signing, and / or authentication.

[0012] Offers and requests are checked against the transaction conditions. Again, this may be performed by any of the entities described above, but is preferably performed by a node in the distributed ledger. If one, two or more, or all conditions are met by both the offer and the request (or a specific defined combination of conditions are met) and authentication is successful, the transaction may proceed. Otherwise, the system may pause or wait until it determines that the offer and request match, are authenticated, and are valid (i.e., meet the conditions). The conditions may be, for example, time-based, entity-based (i.e., only certain entities, devices, types of devices, or groups of entities can trade with certain types or groups of other entities), location-specific, or satisfy other types of requirements.

[0013] If both the offer and the request are found to be valid (and preferably match each other as relating to the same digital asset or a specific requested type of digital asset), the transaction can proceed by the first device digitally signing the digital asset using its UICC. The signed digital asset is transferred from the first device to where it may be used (e.g., a second device). The digital signature of the digital asset is verified or authenticated. This can be done by a node in the distributed ledger and / or the second device. The transaction is preferably added to the distributed ledger after the successful receipt of the digital asset (e.g., as a new block or added to an existing block). However, in some exemplary implementations, other entries may be added to the distributed ledger (e.g., after each or any of the steps described above being performed). The transaction records the transfer of the digital asset from the first device to the second device. Optionally, the transaction represents, or may represent, the transfer of value made in exchange for the digital asset.

[0014] UICC is also trustworthy because it is issued by reliable sources such as telecommunications network providers. Data stores on UICC are cryptographically protected and tamper-proof (even by devices), which provides additional security and maintains trust.

[0015] According to a first aspect, a method for generating a transaction is provided, the method comprising: defining one or more conditions for a transaction; adding one or more conditions to a block in a distributed ledger; generating an offer for a digital asset by a first device, the offer being digitally signed by a secure applet running in the UICC of the first device; generating a request for the digital asset by a second device, the request being digitally signed by a secure applet running in the UICC of the second device; authenticating the digital signatures of the offer and the request; determining whether the offer and the request satisfy one or more conditions added to the distributed ledger, and if one or more conditions are satisfied by the offer and the request, digitally signing the digital asset by a secure applet running in the UICC of the first device; sending the signed digital asset from the first device to the second device; authenticating the digital signature of the signed digital asset; and adding a transaction to a block on the distributed ledger that records the transmission of the digital asset from the first device to the second device. Therefore, entities can pre-set conditions, and transactions will only proceed if these conditions are met, making them safer and more reliable. Furthermore, counterparty matching can be performed more efficiently. In addition, since offers, requests, and digital assets are all signed by a SIM that is itself secure and trusted, each party can verify who they are trading with in the event that there is no existing trust between them.

[0016] Preferably, the step of determining whether one or more conditions are met can be determined by one or more smart contracts stored in a distributed ledger. Other mechanisms may be used to determine these conditions. The implementation of smart contracts enables automated state determination.

[0017] Optionally, the first device, the second device, or a separate server may add blocks to a distributed ledger that records the transmission of digital assets from the first device to the second device. This may, in some cases, be organized by further or different entities.

[0018] Advantageously, signed digital assets can be transmitted directly from one device to another via a secure channel. Therefore, devices or entities unfamiliar with each other can trade directly, securely and efficiently, without the need for intermediaries.

[0019] Optionally, the method may further include the step of recording a transaction of value on a distributed ledger between a second device and a first device in response to the fulfillment of a condition. This may be monetary value, tokenized value (e.g., digital currency), or other transaction of value.

[0020] Optionally, the method may further include a step in which the first device authenticates the digitally signed request. Thus, the first device can be sure of who it is dealing with.

[0021] Advantageously, the method may further include a step of exchanging a digital asset for one or more goods or services. A digital asset can have several different use cases. For example, it may be consumed directly (e.g., to provide information or data), or it may be exchanged as a further step.

[0022] Optionally, the method may further include using digital assets to access the service. For example, this could be to obtain access to a location (e.g., a parking lot).

[0023] Advantageously, a digital asset may include a package of data. The package of data may include one or more data for one or more sources, including but not limited to transmitting on or within a first device.

[0024] Advantageously, the package of data may be derived from sensors on, in a part of, or within the first device.

[0025] According to a second aspect, a first device having a UICC, wherein the first device is configured to generate an offer of a digital asset and transmit the digital asset, and the UICC stores in memory a secure applet including program instructions for causing the processor to digitally sign the offer and the digital asset; a second device having a UICC, wherein the second device is configured to generate a request, receive the digital asset transmitted by the first device, and authenticate the digital signature of the digital asset, and the UICC stores in memory a secure applet including program instructions for causing the processor to digitally sign the request; and a distributed ledger having one or more nodes having one or more processors and a memory, wherein the memory includes program instructions for causing the one or more processors to add one or more conditions to one or more blocks in the distributed ledger, authenticate the digital signatures of the offer and the request, determine that the offer and the request satisfy one or more conditions added to the distributed ledger, and enable the digitally signed asset to be transmitted from the first device to the second device when it is determined that the digitally signed offer and request satisfy one or more conditions. The system may operate in a closed network or an open network (e.g., a public telecommunications network, the Internet, etc.).

[0026] Preferably, the UICCs of the first and second devices further comprise one or more secure storage locations configured to store cryptographic material for use in digital signatures. This can be within a secure element in the UICC or SIM. These can include, for example, hardware security or encryption components.

[0027] Optionally, the first device may further comprise one or more sensors configured to generate sensor data, and further, the digital assets are derived from those sensor data. As examples, the sensors can include any one or more of location, GPS, temperature, accelerometer, gyroscope, light level, audio level, microphone, camera, video, pressure, or other sensors.

[0028] Optionally, the system may further comprise one or more service providers configured to provide services (or goods) in exchange for digital assets. Thus, the system can include additional hardware or software for accepting digital assets (such as encrypted tokens) and providing goods or services in exchange.

[0029] Preferably, the distributed ledger can be further configured to store conditions as one or more smart contracts. Thus, the conditions can be automatically checked and offers and requests can be automatically executed under known or predetermined criteria.

[0030] The above method can be implemented as a computer program comprising program instructions for operating a computer. The computer program may be stored on a computer-readable medium.

[0031] A computer system may include one or more processors (e.g., local, virtual, or cloud-based), such as a central processing unit (CPU), and / or a single or aggregate of graphics processing units (GPUs). Processors may execute logic in the form of software programs. A computer system may include memory, including volatile and non-volatile storage media. Computer-readable media may be included for storing logic or program instructions. Different parts of the system may be connected using networks (e.g., wireless and wired networks). A computer system may include one or more interfaces. A computer system may include a suitable operating system, such as Java®, UNIX®, Windows® (RTM), or Linux®.

[0032] It should be noted that any of the above features may be used in any particular aspect or embodiment of the present invention.

[0033] Brief explanation of the drawing The present invention can be carried out in several ways, and embodiments are described here merely as examples with reference to the accompanying drawings. [Brief explanation of the drawing]

[0034] [Figure 1] This flowchart shows how to record transactions on a distributed ledger. [Figure 1a] This flowchart shows how to generate a transaction on a distributed ledger. [Figure 2] This diagram shows a schematic of a system for recording transactions on a distributed ledger, including devices with SIM cards. [Figure 2a] This diagram shows a schematic of a system for generating transactions on a distributed ledger, including a first device and a second device, both of which have SIM cards. [Figure 3]Figure 2 is a schematic diagram showing the high-level functions of the system. [Figure 4] Figure 2 shows schematic diagrams of some of the architectural components of the system. [Figure 5] Figure 2 shows a schematic diagram of an exemplary implementation of the system, including the device and SIM, proxy server and distributed ledger. [Figure 6] Figure 2 shows a schematic diagram illustrating a further exemplary implementation of the system. [Figure 7] Figure 5 shows a schematic diagram of the device system operating according to the system shown. [Figure 8] A more detailed schematic diagram of the device system operating according to the system shown in Figure 5 is provided. [Figure 9] Figure 6 shows a schematic diagram of an example implementation of the system. [Figure 10] A schematic diagram of a further exemplary implementation of the system in Figure 2, including one or more nodes, is shown. [Figure 11] Figure 10 shows a schematic diagram of the nodes. [Figure 12] Figure 10 shows a schematic diagram of the method steps performed by the system. [Figure 13] Figure 2 shows a schematic diagram of an example implementation of the system. [Figure 14] Figure 5 shows a schematic diagram of an example implementation of the SIM. [Figure 15] Figure 5 shows a schematic diagram of an example implementation of the device. [Figure 16] Figure 1 shows a flowchart illustrating the method for managing the keys used in the method described. [Figure 17] Figure 6 shows a schematic diagram of the components used in the example implementation. [Figure 18] Figure 6 shows a schematic diagram of the interaction between the components used in the example implementation. [Figure 19] Figure 6 is a schematic diagram showing the method steps used to generate a key in an exemplary implementation. [Figure 20]Figure 6 is a schematic diagram showing the method steps used to exchange data in an exemplary implementation. [Figure 21] Figure 2 shows a schematic diagram of the device architecture within the system. [Figure 22] Figure 2 shows a schematic diagram of the architectural middleware used to interact with the secure element within the SIM. [Figure 23] Figure 1 shows a sequence diagram of the steps for signing a transaction according to the method shown. [Figure 24] Figure 22 shows a schematic diagram of the method steps in the procedure for signing a transaction using the secure element of the SIM. [Figure 25] Figure 22 shows a schematic diagram of the TLS authentication process using PKI and the SIM. [Figure 26] Figure 2 shows a schematic diagram of an example implementation of a distributed ledger. [Figure 27] Figure 1 shows an example use case that implements the method. [Figure 28] This shows a sequence diagram of some of the methods for matching offers within data exchange. [Figure 29] Figure 28 shows a partial sequence diagram of the method. [Figure 30] Figure 2 shows a schematic diagram of the messaging system used within the system. [Figure 31] Figure 2 shows a schematic diagram of an example implementation of the system. [Figure 32] Figure 30 shows a sequence diagram of the method steps used within the messaging system. [Figure 33] Figure 30 shows a sequence diagram of further method steps used within the messaging system. [Figure 34] Figure 1 shows a sequence diagram of an exemplary implementation of the method. [Figure 35] This is a schematic diagram showing the method steps for provisioning a device for use in the method shown in Figure 1. [Figure 36]Figure 1 is a schematic diagram showing the method steps for setting up the device used in the method. [Figure 37] Figure 1 is a schematic diagram showing the method steps for setting up a device for use in the method described. [Figure 38] This is a schematic diagram illustrating the steps of a method for authenticating a user for use with the devices shown in Figures 36 and 37. [Figure 39] This is a schematic diagram illustrating the steps of a method for authenticating a user for use with the devices shown in Figures 36 and 37. [Figure 40] This is a schematic diagram showing the method steps of an exemplary implementation of the method shown in Figure 1. [Figure 41] This is a schematic diagram showing further method steps of an exemplary implementation of the method in Figure 1. [Figure 42] This is a schematic diagram showing further method steps of an exemplary implementation of the method in Figure 1. [Figure 43] This is a schematic diagram showing further method steps of an exemplary implementation of the method in Figure 1. [Figure 44] Figure 2 shows a schematic diagram of an example implementation of the system. [Figure 45] Figure 2 is a schematic diagram showing an example of the system's architectural components. [Figure 46] Figure 2 is a schematic diagram showing an exemplary implementation of part of the system. [Figure 47] Figure 2 is a schematic diagram showing an example of a device implementation within the system. [Figure 48] Figure 2 is a schematic diagram illustrating an exemplary implementation of interaction with the system. [Modes for carrying out the invention]

[0035] Please note that the drawings are for simplification purposes and are not necessarily drawn to scale. Similar features are given the same reference number.

[0036] Detailed description of preferred embodiments The Internet of Things (IoT) is growing and transitioning to the Economy of Things (EoT). The number of IoT devices is increasing, generating massive amounts of data. IoT devices and smart services offer the potential to interact and interoperate across ownership domains, automatically supporting data and smart service value transactions in near real-time. This can improve interoperability and functionality.

[0037] The "economy of things" requires devices / services to recognize and trust each other and to trade value automatically, either directly or using peer-to-peer functionality as needed. There are various technologies to support the transaction applications and services required for the IoT, including digital identity, federated security, and distributed ledgers, secure elements, cryptography, and device wallets, but they are fragmented, costly, and not sufficiently scalable.

[0038] Using a secure element on the SIM (which has a standardized interface and can perform actions defined according to the IoT SAFE standard - GSMA), one or more sets of asymmetric keys can be created within the HSM (PKI on the SIM) to provide the SIM (and the device with it) with a unique and immutable identity, enabling it to interact with a distributed ledger (e.g., blockchain) directly or via a proxy platform or server.

[0039] IoT SAFE can be used to create a secure channel ((D)TLS) between a device and an IoT backend. It uses a secure element on the SIM to hold the asymmetric key required for the (D)TLS connection.

[0040] Two exemplary implementations are described. A proxy server may be used (e.g., a digital asset broker, DAB, or platform). In this case, the device holding the UICC or SIM uses a key pair to authenticate against the DAB platform. That platform has an orchestration engine that maps device identities to services. Thus, with the help of the DAB platform, the set of key pairs is interpreted as a wallet that can be used to interact with different blockchains and can hold several tokens in parallel.

[0041] An alternative, exemplary implementation could involve a direct connection from the device to the blockchain. Without the need for a DAB platform, the device could interact directly with the blockchain. It could use a public key infrastructure (PKI) on the SIM to authenticate itself according to standard blockchain interactions, sign transactions, and so on. This would create a chain of trust directly from the device to the blockchain. The SIM could be considered an edge-trusted device, providing not only connectivity to all hardware but also identity.

[0042] Various components are used to implement such systems and methods. Figure 1 shows a flowchart of method 10 for recording transactions on a distributed ledger. Figure 2 shows a high-level schematic diagram of system 100 for implementing this method. In this exemplary implementation, the distributed ledger is a blockchain (generated by appropriate components) 150, and the device 110 is a mobile device such as a smartphone. However, many different devices may be used. Examples of appropriate blockchain technologies will be discussed later.

[0043] In step 20, a public key and private key pair is generated. This generation takes place within a UICC 120 (e.g., a SIM) in device 110. The UICC 120 includes storage 130 and, preferably, secure storage that prevents tampering or unauthorized access. Such secure storage already exists in many types of UICCs (including those already deployed in the device). In step 30, the key pair (or at least the private key of the key) is stored within the UICC 120. Thus, the key pair, or at least the private key, can be accessed and used at different times later.

[0044] In step 40, a transaction identifier is generated. This identifier is based on or derived from at least the public key of the generated key pair. In step 50, the transaction identifier is used to identify the transaction to be added to the distributed ledger 150. The transaction identifier may represent or incorporate the identifier of device 110, and / or the identifier of the transaction performed by device 110. Furthermore, a device identifier may be added to the distributed ledger 150 by submitting a transaction.

[0045] Transactions can be added to the distributed ledger 150 directly (i.e., by device 110 directly interacting with the distributed ledger 150 and adding a block onto the blockchain) or via an intermediary, server, or proxy server 140. This proxy server 140 may be described as a digital asset broker, DAB, or DAB service. In this exemplary implementation, the proxy server 140 adds transactions to the blockchain using an identifier that identifies the proxy server 140. The proxy server 140 can then maintain a datastore of transactions added for identifiers based on the public keys of one or more devices (the system may have one or more proxy servers 140), but more devices may each be associated with one or more proxy servers.

[0046] Therefore, the identifier of a transaction on the blockchain may include the public key stored in the UICC 120 of device 110, or be derived from the public key, or may be a transaction identifier mapped to an identifier derived from the public key. The identifier can also be derived using the unique identity of device 110 or the user. This may be, for example, IMSI. Other derivation methods may be used. Using the proxy server 140 simplifies the processing of the distributed ledger to the extent that less identification information is required.

[0047] Figure 1a shows a flowchart of method 200 for generating transactions in a distributed ledger. A system 400 that implements this method is shown in Figure 2a. This system is similar to system 100 shown in Figure 1, and the same or similar components have the same reference numbers.

[0048] In step 210, the transaction conditions are defined. In step 220, these conditions are added to the distributed ledger 150 (e.g., the blockchain). In step 230, the first device 110 generates an offer for digital assets. This may occur simultaneously with (or before or after) the second device 410 generates a request for the same (or similar) digital assets in step 240. The request may include, for example, a range of acceptable or required digital assets. The offer is digitally signed by a secure applet in the SIM 120 of the first device 110. This may occur within a secure area of ​​the SIM 120. The request is also digitally signed by a secure applet in the SIM 420 of the second device 410. This may also occur within a secure area of ​​the SIM 420.

[0049] In step 250, the offer and request are authenticated (e.g., by the distributed ledger 150 or the proxy server 140). In step 260, the conditions are checked by the distributed ledger 150 or the proxy server 140, and if they are met (and the offer and request match the same digital asset or a digital asset that falls within a specific requested property range), method 200 may proceed. Otherwise, the method may terminate or wait until a match is made and the conditions are met (e.g., by different combinations of offers and requests that may be added to the system by different devices or entities). In this way, many different offers and requests can be processed.

[0050] If the conditions are met, in step 270, the first device digitally signs the digital asset. Again, this is achieved using a secure applet within the SIM 120. In step 280, the first device 110 then sends the signed digital asset to the second device 410, as shown in Figure 2a as an arrow between the first device 110 and the second device 410.

[0051] In step 290, the digital asset is authenticated. This may be done by a second device 410 or another entity such as a proxy server 140 or a distributed ledger 150. In step 300, a block is added to the distributed ledger 150 to record the transaction. The second device 410 may then use or consume the digital asset. For example, it may be delivered in exchange for goods or services (not shown in this diagram). Within the distributed ledger 150, which records any one or more of these method steps, any one or more additional entries may be created.

[0052] Figure 3 schematically shows the high-level functions of the aforementioned system. UICC (SIM) Role within the system: Provides a secure entry point to the chain of trust (SIM as customer assets). Throughout this disclosure, the terms SIM and UICC may be used interchangeably, as may the terms application and applet.

[0053] variant: • Preferably a secure element on the SIM that supports the GSMA IoT SAFE applet, or Vodafone SIM Trust based on 3GPP® General-Purpose Bootstrapping Architecture (GBA).

[0054] Different implementations of the system exist. In one implementation, the SIM or UICC applet generates one or more cryptographic key pairs. In another implementation, the SIM or UICC may be provisioned with cryptographic material. For example, this could use 3GPP GBA. However, any of the features and implementation examples or combinations described throughout can be used with either or both implementations.

[0055] device Role within the system: Provides an integrator to the upper layers (Digital Asset Broker, DAB, Management Core) and harmonizes communications (including SIM and non-SIM devices from different telecommunications networks). Devices can take various forms, such as simple IoT devices (e.g., supply and demand meters) to vehicles.

[0056] Components • DAB middleware for IoT SAFE applets, or • DAB middleware for SIM trusts • Extraction of sensor data for detecting events that can be monetized. DAB Management Core Role within the ecosystem: Mediating interactions within the DAB system to utilize on-chain and off-chain functionalities.

[0057] Components • Flow orchestration engine Common API DAB Management Service Role within the ecosystem: Simplifying flows and customizing DABs for MVPs (MasterCard, VISA, PayPal).

[0058] Components • Customized off-chain processing (off-chain) • Customized API DAB Blockchain Service Role within the ecosystem: Provides a connector that translates DAB dialogues into blockchain language.

[0059] Components Ledger of Things DAB Exchange • Blockchain hub including smart contract engine Architectural Components Figure 4 schematically shows the various architectural components of the system and method.

[0060] While the IoT SAFE applet implementation offers convenient features, the use of GBA provisioning (e.g., Vodafone SIM Trust) allows for the use of legacy SIMs that may already be deployed within the system. Therefore, a combination of both implementation forms (which can function simultaneously or separately within the system) allows as many participants as possible to use the system. Device firmware can be updated over the radio for legacy devices, and thus the GBA implementation (e.g., SIM Trust) can be used without changing the UICC or SIM within the device.

[0061] Figures 5 and 6 illustrate the use of both implementation forms by System 100 at a high level. The mechanisms are independent but interchangeable and may be suitable for different use cases. In addition to providing flexibility for new and legacy SIMs, each implementation option has different advantages. For example, banks and public services may prefer to interact with the GBA implementation shown in Figure 6 (e.g., SIM Trust) because it supports symmetric keys. The SIM applet implementation shown in Figure 5 (e.g., IoT SAFE) provides improved blockchain interaction because it can directly sign transactions by UICC or SIM without requiring an intermediate or proxy server 140. Thus, both mechanisms are intended to complement each other and meet specific technical requirements.

[0062] At a high level, the main difference between these two mechanisms lies in the cryptographic method. The IoT SAFE applet primarily uses a secure element on the SIM to store and manage keys for asymmetric encryption (also known as PKI), where public and private key pairs are generated and stored. The GBA (e.g., SIM Trust) method uses mobile network functionality to establish symmetric encryption between the SIM and the endpoint (e.g., a server such as a DAB server).

[0063] Asymmetric encryption, or PKI, is a technology used by many IT infrastructures to secure HTTPS and other server-to-server connections using public / private key pairs.

[0064] Figures 7 and 8 schematically illustrate how a secure communication channel can be established between an IoT device and a server using the IoT Safe applet running with the SIM120. Figure 8 shows in more detail how a device initiates a secure connection with the server.

[0065] The device is pre-provisioned with a client PKI certificate (e.g., UICC or within the SIM). In the example shown in Figure 9, the device is a vehicle, but it could be a mobile or any other device. The client PKI certificate is preferably a public trust certificate procured and signed by a Certificate Authority. The server holds a similar server certificate. Once the communication channel is initiated by the client to the server, an exchange takes place in which both parties authenticate each other using a Certificate Authority (CA) to verify the legitimacy of the other party.

[0066] Mechanisms implemented using CAs utilize a pair of keys used together, one for encryption and the other for decryption. One key can be used to perform the first encryption function, and the other key can be used to perform the decryption operation. Due to the asymmetry of the two different keys that perform these functions, this is often called an "asymmetric" cryptography. One of these keys is public, and the other is secret. In a public cryptographic system, anyone can encrypt a message using the recipient's public key, but only the recipient can decrypt the message using their private key.

[0067] Apart from encryption methods, IoT SAFE-based solutions offer several additional features that facilitate further functionality that can be used in distributed ledger (e.g., blockchain) related environments.

[0068] Symmetric encryption algorithms use the same encryption key for both encryption and decryption. The key essentially represents a shared secret between two or more parties that can be used to maintain a link to personal information. The requirement that both parties have access to the same secret key is one of the main drawbacks of symmetric-key encryption compared to asymmetric encryption. In the mobile communications space, this solution is facilitated by devices containing mobile SIMs with connectivity to telecommunications network services. Mobile phones have many requirements that originally existed in the IoT device space, and they utilize standards-based solutions to these problems. These have been developed and scrutinized over a period of more than 20 years and can therefore be trusted by many entities and organizations.

[0069] When a telephone device connects to a mobile cellular network, the telephone device will • Authenticating with the mobile network, and • Agree to the key that can be used to encrypt communications with the mobile network. Perform at least two actions, including [specific action].

[0070] This is typically achieved using standards-based authentication and key agreement (AKA) protocols. Thus, AKA protocols create trust between a mobile device (roaming or otherwise) and a (potentially untrusted) cellular network, allowing the two parties to communicate securely.

[0071] This alternative technology uses the same AKA protocol, formalized as a generic bootstrapping architecture (GBA), such as Vodafone's SIM Trust implementation, but unlike traditional cellular use cases, trust is established between the device and the application platform under the direct control of the user or customer.

[0072] Figure 13 illustrates this GBA implementation. While UICC or SIM creates a standard mobile connection to the application server, the AKA protocol is used to create secure communication between the device and the visited mobile network. SIM trust (using the GBA protocol) adds another layer of trust by repeating the AKA flow to create symmetric encryption between the device and the application server. The result is a mutually authenticated secure channel for communication between the two endpoints.

[0073] Figure 10 shows an exemplary network configuration in which individual devices communicate with nodes in a distributed ledger network. This network configuration may be independent of a specific encryption method (e.g., symmetric or asymmetric encryption can be used). Figure 11 schematically shows the form of these individual nodes. One or more nodes may be present in the network.

[0074] More specifically, Figures 10 and 11 illustrate the following features: A secure applet (e.g., a DLT applet) on the SIM (within the device) or on a node securely generates and holds keys. These keys may be wallets, certificates, and / or other forms of digital trust representations used for secure value exchange (using blockchain). The secure applet may, logically, be an extension of the hardware secure module of the Home Subscriber Server (HSS) (an existing network element deep within the carrier's or operator's core network). The relationship of the HSS to the secure applet on the SIM may be managed by another existing network element (e.g., a wireless OTA server), which may be a machine used to create a secure communication channel directly with the SIM. The Telco node acts as a distributed ledger technology DLT notary, operating with the management of a decentralized authority on each DAB node, for example, to create and manage the certificates necessary to manage the lifecycle of secure application delivery, updates, authorization, and decommissioning activities.

[0075] The telco node also functions as a CA (Certificate Authority) for services provided by the system (e.g., DLT Secure Service). When the enhanced security of HSS is extended to SIM via DLT Secure Service, the DAB DLT uses the SIM and stored keys to create a new consensus protocol ("Proof of Secure SIM"), and the SIM is required to prove its validity on the system (DAB) at each transaction time without requiring expensive, high-processing proof-of-work / stake type processing across the network. This makes each DAB node lightweight and limits the computational requirements of the SIM (since PUB / PRV keys can be generated asynchronously and provided to the DAB DLT for verification at the start of a transaction).

[0076] Device owners or other entities can program or define smart contracts or other conditions to enable heterogeneous devices from different systems to interact with each other using a common root of trust (i.e., SIMs and secure applet or GBA-enabled devices). This provides mechanisms and protocols that enable devices to interact and trade. This can be done at scale with multiple devices (and their SIMs) interacting with one or more nodes. This protocol enables use cases that have traditionally been resolved using APIs, such as devices exchanging tokens for tokens and further exchanging tokens for data. Furthermore, devices thus enabled (DAB devices) may autonomously exchange tokens in their one or more wallets for value ranging from actions (e.g., access control) to data streams (e.g., device location of a first device or providing device), and a secondary "parent" node can recharge these wallets to manage and track service consumption, for example. This system provides micropayment and microbilling systems, as well as request / transmit / settle value exchanges that can be combined with decentralized ledger credit / debit.

[0077] The following describes the steps taken to operate the exemplary network configuration shown in Figure 10. Again, either encryption method (symmetric or asymmetric) may be used. The numbers below correspond to the numbers shown in Figure 12, which illustrate the method steps that occur between different components.

[0078] 0. Background: A and B are registered with DAB NW and are authorized to exchange value with each other.

[0079] 1. The owners of A and B have agreed to a smart contract (i.e., "If you give me data X, I will give you Y tokens").

[0080] 2. B requests data from A based on a predetermined smart contract (C). 3. The request in B is signed with DLT Secure B security and verified by Dapp C (Proof of Secure SIM).

[0081] 4. The "purchase" transaction is published on the DAB DLT network on behalf of B.

[0082] 5.A downloads the applicable requests for the transaction decision. 6. DLT Secure A verifies request (4).

[0083] 7. Device A signals to the DAB DLT that it wants to "sell" something. 8. Device A receives data A from sensor A and packages it.

[0084] 9. DLT Secure A signs package A. 10.A acknowledges the exchange on the DLT call on smart contract C that is to be invoked.

[0085] 11. A sends package A to B (either on-chain or off-chain).

[0086] 12. DLT Secure B updates the DLT and DLT records and initiates settlement using Smart Contract C.

[0087] 13. Device B satisfies C. 14. Device A confirms receipt of the token.

[0088] 15. DLT verifies the C closure. 16. Device B analyzes package A and decides to perform action A.

[0089] The following two sections provide details on how the two implementations work.

[0090] The UICC applet implementation uses a secure element within UICC (e.g., SIM). The SIM acts as a hardware wallet that protects cryptographic keys and communications. This implementation allows the SIM to provide the root of trust for IoT devices for easy and efficient implementation of critical security features. The SIM can securely store transaction signing keys and perform secure crypto asset transaction signing within a secure environment.

[0091] Figure 14 shows a schematic diagram of the SIM and OTA server architecture design. The SIM may have a GSMA IoT SAFE applet. In addition to holding a SIM cryptographic wallet for transaction signing, this enables mutually authenticated TLS connections bound to the root of trust of the SIM hardware, as defined in the GSMA specification https: / / www.gsma.com / iot / wp-content / uploads / 2019 / 12 / IoT.05-v1-IoT-Security-Applet-Interface-Description.pdf.

[0092] GSMA IoT SAFE-based solutions provide chip-to-cloud security for IoT deployments. Using hardware secure elements, or "root of trust," IoT SAFE-based solutions deliver end-to-end security. The use of GSMA standardized secure elements and IoT SAFE applets further ensures interoperability between different companies and consistent use by IoT device manufacturers.

[0093] For communication between the IoT SAFE applet located on the SIM and external sources (e.g., proxy servers, blockchains, etc.), cryptographic middleware libraries are also executed within the device, but not necessarily within the SIM itself.

[0094] In this implementation, standard authentication mechanisms arise between the SIM and the device, and between the SIM and the over-the-air (OTA) server. These mechanisms may also include secure elements on the SIM. This is combined with basic mechanisms for unlocking the application and / or SIM (e.g., by using PIN protection), SIM locking mechanisms, and mutual authentication between the SIM and device applications. Blockchain transactions are verified by blockchain nodes using a protocol that includes a digital signature sent as part of the transaction.

[0095] General-purpose smart SIM wallet By using the IoT SAFE applet, the SIM provides access to one or more key containers or storage within the SIM's secure element. These containers may be used for different use cases, or they may be used to provide multiple identities for the same use case or operation. Figure 15 schematically illustrates the storage of multiple identities within a SIM. Each identity can be used as a SIM wallet, enabling the user to authenticate and sign transactions within different applications. This is not limited to the blockchain and can also be used within off-chain mechanisms such as traditional payment rails (e.g., direct communication with other devices or companies). The SIM's over-the-air (OTA) update capability allows for the addition of new containers and key management capabilities for use in specific implementations.

[0096] SIMs can be personalized with additional key containers for signing keys for different blockchain networks. In a preferred implementation, a SIM has three key containers available by default: two containers hold SECP256 K1 ECDSA key pairs and one container holds SECP256 R1 ECDSA key pairs. However, any combination of different key pair types may be used.

[0097] Considering an end-to-end solution, a SIM crypto wallet within an IoT (or other) device, using the SIM as the hardware root of trust, could offer one or all of the following features:

[0098] • Hardware wallet (signature payment / digital asset transfer transactions) • Verification of signed transactions • Secure communication • Secure storage of confidential data Therefore, the SIM itself can provide one or all of the following functions:

[0099] • Additional encryption features • IoT device ID metadata storage • Secure backup / restore, key management Device-initiated bootstrap Using an encryption key vault within a SIM ensures the tamper-proof and secure nature of private keys and secrets. A SIM is typically tamper-proof hardware equipped with a dedicated cryptographic processor and a highly secure SIM OS, providing the necessary level of assurance to secure private keys. Keys thus stored in the SIM are generated on the SIM and, preferably, never leave the SIM.

[0100] Table 1 lists preferred cryptographic algorithms to be used. Other algorithms may be used.

[0101] [Table 1]

[0102] Blockchain and cryptocurrency networks typically rely on asymmetric cryptography because their transactions are peer-to-peer or within a group of participants. The list of participants in different transactions can differ. Given this peer-to-peer nature of blockchain transactions, the use of symmetric cryptography may be impractical. Furthermore, using asymmetric cryptography makes blockchain and DLT transactions auditable by third parties. Using PKI within current systems makes it possible to verify transactions without an entity or person having access to the private key.

[0103] EMV token EMV is an abbreviation for Eurocard (RTM), MasterCard (RTM), and Visa (RTM), representing a defined specification for payment applications, which is implemented in most bank card chips today. It works with symmetric cryptography by accessing authentication information securely stored on the bank card chip. In the current environment, payment transactions can be signed using EMV and sent to the existing payment rail to enable the transaction. Therefore, a SIM wallet is used to hold (symmetric) key values ​​for payment applications, which are then used by device middleware to facilitate EMV payments through this system.

[0104] This extended or optional feature (used with any of the implementation forms described) provides users with the option to choose to pay using either blockchain or existing payment rails via EMV. From a security standpoint, SIM cards can already pass bank card authentication.

[0105] Wallets within multiple wallets The SIM is used to provide the keys associated with the desired payment method. The wallet used for payment itself does not need to be stored in the SIM (but may be). The wallet used to interact directly with the distributed ledger may be provided by a separate entity, server or proxy server, or broker (e.g., DAB) and may be selected based on the preferred payment method for a particular use case.

[0106] Third-party documentation may be deployed over-the-air (OTA). The wallet application on the device securely interacts with the SIM portion of the application (applet) and establishes a binding (also via OTA). This is subject to the security and authentication processes of the security domain, as well as authorization for integration with external applications.

[0107] key management A clearly defined mechanism may be implemented to manage the lifecycle of keys used in transaction management. Cryptographic key lifecycle management may include key backup, restoration, key revocation, and renewal, and security policies may be implemented to handle lost, stolen, and / or compromised devices. Private keys are the most sensitive assets and are not backed up in a clean or unprotected environment. Several different mechanisms can be used for backing up and restoring blockchain transaction signing keys.

[0108] For example, Bitcoin defines deterministic key generation based on a human-readable sequence of words to generate a seed and then use that seed to generate a key pair, based on the BIP39 / BIP32 specifications. The BIP39 implementation specifies that keys are derived from mnemonics that can be stored and re-entered to recover them. BIP32 defines a hierarchical deterministic wallet that derives keys based on a seed and index value. Such mechanisms can be used in this system and are schematically shown in Figure 16.

[0109] In another exemplary implementation, a SIM backup vault service transparently backs up components or parts of a private key onto other SIMs so that no single SIM has the complete value. Restoring the key may be a coordinated effort involving collecting the components of the backed-up value (k out of N) from a cluster of SIMs used in the backup process.

[0110] In further exemplary implementations, blockchain smart contract-based solutions reduce the complexity of backup and restore processes. For example, a smart contract account holds digital assets similar to an escrow mechanism until specified conditions are met. Accounts associated with IoT devices handle only micropayments and do not independently hold digital values ​​or cryptocurrencies. A smart contract account can define rules for resolving scenarios where some devices fail, and how to send the account to other devices.

[0111] General-Purpose Bootstrapping Architecture (GBA) The Vodafone SIM trust architecture is based on the technical specification (3GPP TS 33 220), also known as the General Purpose Bootstrapping Architecture (GBA). Similar to certificates, GBA is used to establish trust between parties. Certificates, on the other hand, rely on asymmetric cryptography to create different key pairs that can be used in combination to support cryptographic functions. GBA uses a hardware-based trusted execution environment (TEE) to store symmetric keys and provides the ability to use these symmetric keys to derive temporary keys that can be used to support at least three functions: authentication, confidentiality, and integrity protection. Further details on the GBA standard can be found in ETSI Technical Specification TS 33.221 V14.0 (2017-05).

[0112] In an IoT environment, the GBA TEE is provided by a SIM. The SIM is used to store credentials to support authentication key derivation and key agreement functions.

[0113] Symmetric encryption has the drawback that keys must be distributed and shared among all parties that need to communicate with each other. This is called the key distribution problem. The telecommunications industry relies on symmetric encryption where keys are distributed during the SIM manufacturing process and symmetric keys are stored in two locations.

[0114] 1. A subscriber identification module (SIM), which is a hardware token device stored in a user device (UE), which may be a mobile phone or an IoT device, and 2. It is located in the center of the operator core network on the Authentication Center (AuC) and is accessed via the Home Location Register (HLR).

[0115] The security of this distribution process relies on the secure processes followed by SIM manufacturers and mobile carriers in managing this key information.

[0116] However, many entities are known to target the processes and individuals involved in the distribution of these key materials. Industries that rely on SIMs to protect their assets have countered this key distribution attack problem by using rigorous security processes and vendor selection. However, this can be costly.

[0117] Communication flow The SIM card is used as the root of trust to derive a shared key that can be used to enable end-to-end authentication and encryption at the application layer at scale. Generally, this process relies on the 3G AKA process (AKA = Authentication and Key Agreement). The AKA process is used when any mobile device connects to a mobile network (>2G) and performs mutual authentication and key agreement. Figures 17 and 18 show the communication flow used in the GBA's SIM trust implementation at a high level.

[0118] The steps for establishing a secure channel between a device and a backend application consist of two steps: generating a key and using the key to exchange data over the secure channel.

[0119] Key generation process The key generation process is schematically shown in Figure 19. The SIM interacts with the device API within the device, and the device obtains a symmetric key from the SIM trust server, which communicates with the core network. The device communicates with the SIM trust server via HTTP to derive a shared secret in the form of a symmetric key. This symmetric key is authenticated and stored within the SIM.

[0120] Data is exchanged via a secure channel using keys. Once a shared secret (symmetric key) is derived, it can be used to secure the channel for communicating data. This is schematically illustrated in Figure 20.

[0121] The communication flow through each network entity is described below. The device management (DM) client queries the General-Purpose Authentication Architecture (GAA) server for the key.

[0122] The GAA server establishes the identity of the SIM (AT+CSIM). Meanwhile, the GAA server notifies the DM client to wait.

[0123] DM clients can perform other tasks while waiting. The GAA server uses the identity to request an authentication vector from UbProxy.

[0124] UbProxy validates the request and routes it to the correct Bootstrapping Server Function (BSF).

[0125] BSF requests AV from HLR. HLR returns AV to BSF.

[0126] BSF stores the credentials and returns a vector version to UbProxy with a 401 code.

[0127] UbProxy returns the same message and error code to the GAA server. This requires authentication from the SIM card.

[0128] A valid response (initial DB) allows the valid response to be extracted and sent to UbProxy.

[0129] It then sends it to BSF. It first verifies the response contained in the message received from the HLR and sends a 200 response.

[0130] UbProxy returns a 200 response to the GAA server. The GAA server calculates the key and returns it to the DM client.

[0131] The DM client uses the key as needed and passes its ID to the server. When the DM server needs a key, it uses the ID to query UbProxy via NAF.

[0132] UbProxy sends the key request to the appropriate BSF. It calculates the key and returns it.

[0133] UbProxy returns the key to the DM server. The DM server uses keys as needed.

[0134] Starting with SIM Trust (e.g., Vodafone), device-side middleware enables the device to send messages between SIMs in the network and the SIM Trust platform (bootstrapping server function, BSF). The device supports the SIM Trust device library and has an integrated software library (DDK). On the backend side, the application obtains a shared key from the SIM Trust platform using Application Processing Interface (API) calls via the API hub.

[0135] Certain Global Data Services Platforms (GSDPs) may enable GBA (e.g., SIM Trust) for specific SIM cards or IMSI ranges.

[0136] device General-purpose architecture To use the device as an integrator layer between the SIM and the DAB, four interconnected components can be provided as an example.

[0137] SIM core: SIM card (including a secure element and hardware components that store cryptographic keys and can authenticate and sign transactions and data).

[0138] Libraries provided by the SIM manufacturer: A set of libraries that expose the functionality of the SIM for use by connected applications (e.g., the cryptographic middleware mentioned).

[0139] Middleware: Middleware components that expose the infrastructure functionality of SIM applets for applications that cannot directly incorporate the SIM manufacturer's libraries, or for applications and devices that run outside the device (e.g., data collection networks).

[0140] Event Detection: An application / algorithm for detecting and trading events with the rest of the DAB service, or directly with either the blockchain and / or the marketplace and / or exchange.

[0141] These components are schematically shown in Figure 21. With the use of this service and existing features such as GDSP (Vodafone's Global Data Services Platform for Managed IoT Connectivity), SIM Trust, or IoT SAFE, devices can be considered edge integration points that perform the functions of a blockchain wallet and a trusted certifier. They also open up the ability to provide secure autonomous events, or to be used as a simple hardware secure module (HSM).

[0142] Middleware enables devices to seamlessly participate in the transaction ecosystem, allowing applications to incorporate manufacturer libraries and consume SIM functionality for key provisioning and transaction signing. Applications running outside of the connected device can also leverage these capabilities and access the middleware via its API.

[0143] The device processes or collects data ranging from direct reading to computational analysis (e.g., cargo occupancy valuation), which is encrypted (using PKI in the case of a SIM), signed with the SIM card's private key, and can then be tokenized on any blockchain or stored elsewhere within the platform for cross-platform use.

[0144] middleware for secure elements on SIM cards A typical IoT deployment, as shown in Figure 22, can directly benefit from GSMA IoT SAFE, which provides secure transmission of sensitive data and device authentication. Nevertheless, the aforementioned middleware on the device is required to facilitate communication between the SIM applet and the application side.

[0145] architecture The middleware for secure elements on the SIM abstracts heterogeneous applet management through modular applications, enabling integration between devices and the Digital Asset Broker (DAB) service platform. It provides a unified, single RESTful API (SIM Service API) for applet management, regardless of the manufacturer.

[0146] To expose SIM functionality to a device, the cryptographic middleware library provides and interfaces with an applet execution platform. The library can include OS-level C libraries and / or framework-enabled modules for Java®, Android, or Swift, providing methods for managing the applet itself (such as deployment, deletion, and updating), as well as the behaviors made available by each. An overview of the DAB middleware components is shown in Figure 22.

[0147] The SIM service API is a set of base endpoints that expose the aforementioned unified behavior, and for each incoming request, the cryptographic core plays the role of organizing the steps necessary to interact with third-party vendor integration options, whether external or embedded Java libraries, for example. Each of these has its own logic flow for applet management and utilization, so individual adapter components can be interfaced by the DAB middleware provider commons layer. This makes the behavior provided by different manufacturers available.

[0148] implementation In an exemplary implementation, a two-device configuration is provided, with an IoT SAFE applet running within the secure element of the SIM card and aligned with it.

[0149] 1. A DAB application running on a mobile phone directly accesses its SIM card via an embedded Android library to sign and verify the dataset as instructed by the DAB service.

[0150] A 2.4G-connected automotive M2M router (simulated in the test using a Raspberry Pi and a Vodafone USB Connect 4G v2 dongle, but other suitable hardware may be used) includes a SIM card but exposes its encryption capabilities to other applications via DAB middleware.

[0151] The implemented DAB middleware uses the following exemplary technologies: Spring Boot; OpenAPI; Java Native Interface (JNI); and iot-safe-middleware. Other technologies may be used.

[0152] In one exemplary implementation, Java Spring Boot covers numerous possible integration scenarios with manufacturer libraries. This also opens up the possibility of including it in several types of devices, including smart devices or IoT gateways, as long as they can run the JVM. For low-end devices where CPU and memory may be constrained, using the JVM is not the most efficient implementation, but it abstracts away hardware differences.

[0153] This is a technique to provide easier integration of the integration method by dividing it into configurable modules that can be extended for each library provided, either by directly importing code modules or by interacting with OS-level libraries (for example, if a C library provided by a SIM manufacturer needs to be interfaced via a JNI external functionality interface). This may be instantiated as a standalone application running on the same device connected to the communication unit, or it may be embedded in event detection software (e.g., Java-based).

[0154] Four exemplary SIM service behaviors can be defined regarding the encryption functionality made available by the IoT SAFE applet installed on the SIM. These behaviors mirror very similar signatures of API methods made available by the Thales cryptographic middleware C++ library (see also https: / / github.com / ThalesGroup / iot-safe-middleware). The cryptographic middleware library provided by Thales can be used in two ways: as a Java Android library for direct applet communication from within a regular Android app, or as a C++ build suitable for the middleware techniques described above.

[0155] DAB Middleware API In an exemplary implementation, SIM service operations related to cryptographic functionality, made available by the IoT SAFE applet installed on the SIM, are invoked by the application depending on the need to obtain a public key or sign a message. They all follow a "container"-based approach (where a "container" is a secure memory space, each holding a client certificate and key pair), and each deployed DAB use case can know what key type or digital signature algorithm it requires. Thus, it can also know which parameters / containers to use when invoking the DAB middleware.

[0156] In an exemplary implementation, SIM service operations related to cryptographic functionality, made available by the IoT SAFE applet installed on the SIM, are invoked by the application depending on the need to obtain a public key or sign a message. They all follow a "container"-based approach (where a "container" is a secure memory space, each holding a client certificate and key pair), and each deployed DAB use case can know what key type or digital signature algorithm it requires. Thus, it can also know which parameters / containers to use when invoking the DAB middleware.

[0157] For example, an API can be summarized simply as follows: / Container: Lists information about the containers in the SIM. / Certificate: Obtain the client certificate for a specific container. / Public key: Read the public key of a specific client certificate / container, and / Signing: Signs the message using a specific client certificate / container.

[0158] This business logic is shown in Figure 23. application Transaction signing using a SIM wallet Blockchain, cryptocurrency networks, and other micropayment solutions rely on the ability of nodes to sign transactions. Due to the peer-to-peer nature of these transactions, it is crucial that nodes can prove their participation in the transaction to ensure it cannot be denied. Therefore, it is essential to store the private key associated with the blockchain address in a secure location (ideally, a tamper-proof cryptographic module).

[0159] Transactions prepared by the DAB middleware are signed using a private key securely stored in the SIM. This example is schematically shown in Figure 24.

[0160] TLS Authentication Client keys and server root certificates securely stored on a SIM (e.g., an IoT SAFE SIM) can be used not only to support DAB blockchain applications but also to establish mutually authenticated TLS sessions between the device and services running in the cloud. This is schematically illustrated in Figure 25.

[0161] DAB middleware can also distribute control over key generation, wallet management, and administration (installation, removal, etc.) of applets installed on the SIM. This may involve exposing control over IoT SAFE applets, for example, to generate new key pairs or modify digital signature algorithms.

[0162] Due to the diversity of SIM and device manufacturers, DAB middleware is available as a software development kit (SDK) for multiple languages ​​and operating systems, allowing OEMs to seamlessly integrate it into their own devices. Given its Java-based nature, another option would be to port it to Java card technology and deliver a single application that could be pre-installed on all SIMs for out-of-the-box DAB accessibility.

[0163] The SIM service API is available in the DAB API inventory for direct device management by application accelerators or third-party applications connected to the DAB platform (if permitted). Preferably, this can be consumed by each DAB service instance to control the devices it is trading in its own use case.

[0164] Sensor data extraction for event detection In an exemplary implementation, IoT deployments can use devices with various functionalities as end nodes. These may include the following:

[0165] Transfer sensor data directly to a higher layer (cloud or server), or It communicates with a gateway that performs the same function.

[0166] Sensor data can be generated, for example, within a device. As smart devices and secure elements become increasingly prevalent, the ability to extract knowledge and generate actions based on the resulting data is becoming key to the autonomy of the IoT. The ability to authenticate datasets, applications running discovery algorithms, can either directly incorporate compatible libraries for accessing SIM encryption applets or use DAB middleware to sign information with selectable secret keys, resulting in immutable datasets.

[0167] DAB devices can also serve as control points for deploying device-side functions that can function in DAB-driven use cases (e.g., discovery algorithm deployment, wallet management, etc.). DAB-driven devices may be accessible to DAB services for managing their discovery software and SIM applets.

[0168] DAB Framework In an exemplary implementation, a DAB service is an instantiated component of the DAB stack and functions as the transaction and authentication platform for the DAB ecosystem. It provides the capability for IoT devices to trade the value of services / data and handles connectivity between mobile IoT devices, multiple types of blockchain technologies, and any third-party external systems. To this end, a DAB service can provide a REST-based API for setting up use case orchestrations for transaction committal, digital identity management, and third-party service access.

[0169] Preferably, the system uses the Java Spring Boot framework. This enables modularity, allowing it to run on most on-premises or cloud-based machines. It also provides a flexible environment for interconnecting with different types of software and hardware applications, including libraries, drivers, and communication stacks. However, other frameworks may be used.

[0170] In the example implementation, the DAB service can utilize the following technologies: Spring Boot, Web3J, OpenAPI, Firebase Java SDK, Spring Quartz, Liquibase, Failsafe SDK, JJWT lib, Paho MQTT, PostgreSQL 10, and / or Spring Reactor.

[0171] Roles within the ecosystem The DAB service is the engine for the ecosystem, managed devices, use cases, flows, and entities. In addition to all the functionality exposed through the API, the DAB service integrates external systems from third-party marketplaces, other telecommunications components, or additional blockchain networks.

[0172] In addition to network connectivity, devices are managed and accessed, and the DAB service is used for device connectivity, management, authentication, and certification. If an external entity (e.g., a company) wants to participate in the ecosystem, it may use the DAB service "as a service." If another entity wants to gain more control over the devices, instances of the DAB service can be deployed for their specific use on their own devices and control their own part of the ecosystem.

[0173] IoT devices can function as low-computational-power sensors or low-energy devices. Furthermore, devices don't need to connect every time, and they don't necessarily need to be constantly connected to distributed ledgers (e.g., blockchain) or other types of networks. To reduce the computational load on devices, DAB services can act as proxies (or proxy servers) for connecting devices to any type of network. This reduces the burden of processing data from devices, allowing less powerful devices to be part of the ecosystem.

[0174] DAB Management Core The DAB management core functions as the primary communication layer between all parties, consisting of a flow orchestration engine and API components. The flow orchestration engine consists of three components, each accessible via an API.

[0175] Flow orchestration engine The provisioning engine handles both the setup and management of use cases instantiated in each DAB service instance, and is responsible for abstracting the link-up of use cases with specific implementations or technologies. Furthermore, the provisioning engine handles the configuration of these technologies and third-party services. It delivers the access layer for managing devices participating in the DAB stack for deploying algorithms and key management (via the SIM service API). This component handles the following functions:

[0176] Business Rules: A set of rules that define the interactions each device can have with a specific network or marketplace / exchange.

[0177] Use Case Management: Manages (creates, edits, and deletes) the available use cases for each DAB instance. It also provisions available use cases that devices can trigger to devices.

[0178] Connectivity: Integration with other platforms such as GDSPs for SIM management, location services, etc.

[0179] Algorithms: Leveraging the SIM service API, this function manages, catalogs, and deploys algorithms to DAB-driven devices. This functionality preferably provides a high level of customization and capability on wirelessly upgraded devices, resulting in the discovery of new events based on their own data without data loss from the devices.

[0180] Authentication engine The authentication engine is responsible for handling all digital identity logic for connected devices and created smart services. Entities ranging from devices to partners or services have digital identities that can be used to pair and connect businesses (managing what is accessible to each other at a given time). Thus, this engine provides the ability to create IoT device entities within an external backend network and authenticate against their respective registries. Therefore, the authentication engine uniquely asserts identity across the DAB ecosystem, preferably by a unique identifier. Devices that hold provisioned keys and provide context regarding identity and transaction authenticity are permitted to plug in and provide verifiable origins for data.

[0181] Transaction engine Depending on the use case, different functions can be activated, and this customization is an additional advantage of the DAB platform. By authenticating the device in this way, it is guaranteed that incoming transactions are encrypted and signed from a trusted device, i.e., via the private key of the SIM card, thus guaranteeing their origin and identity. Therefore, transactions can be executed immediately across multiple marketplaces / exchanges (each typically focusing on a specific domain).

[0182] Thus, the transaction engine can be responsible for handling logic that tends to process incoming device transactions and API calls. This requires redirecting information across the DAB service layer and making inter-component requests. For example, this could include accessing databases, external systems, or blockchain integrations. Upon receiving a candidate event, the DAB service may decide which use case to apply, depending on more than the data contained, and may check the algorithm selected by the device or insights generated on that data.

[0183] If a transaction requires "long" processing or a marketplace-type offer / demand matching procedure, the transaction engine provides an interface to an off-chain processing component of a DAB management service that provides services for executing special algorithms within a secure CPU enclave. This may include a DAB service or a service controlled by a third party.

[0184] The transaction engine provides ingress endpoints into which datasets enter the DAB stack. These may be delivered to the DAB (or other communication protocols) via synchronous HTTP POST, where they are parsed, routed to applicable use cases, and the associated (configured) organized flows are initiated.

[0185] A typical value transaction process can follow three steps. These are applicable to most use cases and illustrate how use case implementations are approached.

[0186] The received message triggers the start of a value transaction process. For example, this could be a transaction sent by a DAB-driven device (see Transaction Engine), or a specific message received on a custom API deployed by a DAB service for consumption by a third party.

[0187] The producer's identity is verified, and the activated use case is identified. The resulting action is generated, such as deploying the transaction to the blockchain or delivering a message or signal to an external system or DAB device.

[0188] The application can cover several types of use cases beyond simple token transfers, such as session logging and dataset matching concepts, which arise as viable, actionable applications for commercial use. To generalize the many types of data that can be traded, the transaction engine can implement an API message format outlined to be as general as possible, containing all the information necessary to indicate which use case flow to activate.

[0189] In an exemplary implementation, the following is an example of JSON code. The message properties can be as follows:

[0190] transactionId - A unique UUID generated by the device for each message. usecaseType - This must uniquely identify both the blockchain technology used and the operating mode of the use case (e.g., Ethereum, session-based, etc.). transactionType - Used in all use cases, but limited to keywords necessary to describe each step of its operating mode (e.g., start session, open session, payment). fromDevice-SSID-Globally unique identification code for each SIM-Used for device identification, creationDate-Device generated timestamp, transactionObject - Contains data to be inserted into the blockchain (blockchainObject), along with the "locationObject" property which carries GPS data transmitted by the device indicating the current location. dataType - Used to indicate the type of data being inserted into the blockchain (the data contained within the "blockchainObject"). This can be used to distinguish its JSON format.

[0191] { “transactionId”:“{{v4uuid}}”, “transactionType”:“newdata”, “fromDevice”:“8981300999090900006F”, “creationDate”:“2020-04-27T17:32:47.020154Z”, “useCaseType”:“service”, “dataType”:“generaldata”, “transactionObject”:{ “blockchainObject”:“{\“borrower\”:\“Daimler\”,…}”, “locationObject”:“{\“location_data\”:{\“lat\”:51…}}”} } Support features such as data persistence services The data persistence service handles all the database connectivity required by the DAB service to store information describing use case orchestration, device configuration, device service-related data, and dataset hashes. This can be used particularly when timing is critical.

[0192] The functionality of the DAB management core may be supported by a platform GUI. This may be implemented by INVENT, but other technologies may also be used.

[0193] Common API Flow orchestration engines may require a common set of core APIs to provide suitable endpoints for building and managing use cases, authentication, and transactions.

[0194] DAB Management Service The DAB management service functionality serves as a place where customized data processing related to a specific industry vertical or use case can be performed. It may be independent of the DAB management core and may have its own API that can be defined and developed whenever the need arises to integrate third-party services for DAB interactions. To improve scalability, core elements may be independent of customized elements.

[0195] Customized off-chain processing When transactions require matching (e.g., track capacity) or micropayment aggregation (e.g., fee collection services), the algorithm can be run in Python and a Software Guard Extension (SGX) enclave.

[0196] Customized API If a use case requires specific integration to be triggered by an external system, endpoints exposed by the DAB service can be organized into this component. These use cases generally rely on data already present in the DAB stack, such as querying the DAB for the identity of a digital device, requesting a signature, or triggering a blockchain transaction. These bespoke control points can be made available beyond REST using any other Java-supported technology such as SOAP or MQTT.

[0197] DAB Blockchain Service Ledger of items The Ledger of Things provides the ability to create, maintain, and use digital identities based on, for example, the Corda network (other distributed ledger technologies may also be used). This is then consumed by the DAB management core for authentication and transaction signing. Bulk provisioning of devices on the Ledger of Things allows enterprises to easily and simultaneously create digital twins of a large number of devices. DAB exchange includes event detection, which is a key differentiator for automatically mapping devices and use cases to each other.

[0198] Blockchain hub and smart contract engine Blockchain Hub The blockchain hub manages the different integration mechanisms selected by the blockchain implementation and provides interoperability to the DAB core services. These mechanisms can range from the use of embedded Java libraries to system-level interactions with external applications running alongside the DAB services themselves. Thus, the layers provide different classes that isolate all the logic required for their use by technology or partners. When building use cases (via the provisioning engine), programmers expect to easily select one of these connectors, configure it to use a specific node, server, or credentials, and be provided with a simple way to manage transactions.

[0199] Different types of distributed ledgers may be used. For example, the following three different blockchains can be used:

[0200] In the Corda network, transactions are conducted via a RESTful API with several nodes in the DLT network. While it is also possible to use RPC connectors, the RESTful API offers low-friction and easy integration.

[0201] In the iExec network, a sequence of operating system processes are executed, and an ordered set of commands (as described in the partner's documentation) are issued to a NodeJS client (iExec SDK) installed alongside the DAB instance, which then synchronously executes and returns text JSON output that needs to be processed and interpreted by the DAB.

[0202] EWF has built a system that uses the Ethereum blockchain as a data marketplace, but it takes into consideration that device participation is limited to dumb devices that only receive MQTT messages and have no data processing capabilities. Therefore, in order to integrate those EWFs into the DAB service, the MQTT client / connector manages all EWF flows for all devices allowed by the DAB service.

[0203] Given the complexity of existing blockchain implementations, it is possible to integrate additional connectors based on libraries such as Geth and Web3 to enhance granular connectivity options.

[0204] Exemplary dog ​​case Use case: "Payment for services" This use case demonstrates how token exchange can be used to use and pay for services such as parking or tolls (for cars). The R3 Corda technology implements a token SDK framework to create one-time token / payment transactions. The five nodes in the network include one notary acting as an authority node, two nodes for services, and two nodes for consumers. Each node on the R3 Corda blockchain represents a primary entity such as a service company (e.g., a parking, toll collection company, or EV charging provider) and a consumer company such as an automobile company. Each device can trigger a transaction, but its identity is not necessarily mirrored on the blockchain itself, but may be represented on the smart contract that triggers it. This is schematically illustrated in Figure 26.

[0205] Regarding smart contracts (flows on Corda), in addition to all flows for managing the network, there is a main flow for creating and recording transactions performed by each device of each entity (including viewing all transactions, collecting information, or performing calculations). CoinTokenTypeContract represents a CreateEvolvableTokenFlow object. When triggering that flow, there are several required fields, such as the identity of the device initiating the flow, and that entity represents the device that is a consumer of the service. The API manages and triggers transactions on the network and integrates them with external portals and applications.

[0206] The network can be deployed in an AWS (or other) environment, separated by entities with a structure defined based on access and network-available ports and APIs. Each node has its own web server, providing its own API and capable of operating independently of the rest of the available network.

[0207] Functionality integration takes place within a smartphone or other device (e.g., an Android phone). The platform can monitor the network and manually trigger actions. This solution uses REST and SSH to interface directly with an R3 Corda instance on the node, providing managed functions such as monitoring network transactions, triggering new transactions, and controlling the node via Node-CLI. The following image illustrates its functionality in detail.

[0208] In automotive scenarios, R3 Corda blockchain functionality can be used to automatically process payments for services.

[0209] Interface / Dependency Various interfaces enable the control and triggering of transactions on nodes via RESTful (or other) APIs. Other interfaces, including RPC and SSH, may also be used (see Figure 26).

[0210] The following provides a list of example APIs that may be used, along with descriptions of their functions. These APIs may be used internally or accessed by external entities.

[0211] Name Description The getMe node retrieves information about who it is.

[0212] getPeers retrieves information about other nodes on the network. getNetworkMap: Retrieves the network map of the connection.

[0213] getNetworkFeed retrieves the network feed for a transaction.

[0214] getNetworkParameters retrieves network implementation parameters.

[0215] getRegisteredFlows retrieves a list of executable flows for that node.

[0216] The getTransactionsID node retrieves a list of transaction IDs that it was involved in.

[0217] getTransactionsInfoByID: Retrieves transaction information using the ID.

[0218] getNumberOfTransactions: Retrieves the number of transactions in the network.

[0219] The getTransactionsInvolved obtains a list of transaction information in which the node is involved.

[0220] The getNumberOfTransactionsInvolved obtains the number of transactions in which the node is involved.

[0221] The getNodeInfo obtains information about the node itself. The getNodeTime obtains the current time of the node.

[0222] The getTransactions obtains a list of information on all transactions.

[0223] The getVodacoins obtains the figure of the balance of "Vodacoins". The postCreateTx creates a transaction on the network. Described in the Business Logic section For each node in the distributed ledger (e.g., blockchain network), the API is replicable and can execute the same type of flow to interact with the rest of the network.

[0224] Business Logic The interaction with DLT (e.g., Corda) is performed via a set of established REST endpoints and SSH connections, so the DAB blockchain service connector coordinates the call flow required for inserting and retrieving data from the ledger. To trigger these scenarios, the set of user layouts within the DAB application constructs transactions according to the message format described in the public layer.

[0225] For this feature, the service payment scenario (useCaseType "service") requires only the "newdata" transaction type. For example, it is possible to manually trigger some use cases and scenarios using an application (DAB application).

[0226] To pay for services such as congestion charges, one-time parking, or any other service, the user selects the menu entry "New Monetizable Data," the "Services" tab, and fills in the fields on the DAB app.

[0227] Borrower - The party to whom you want to transfer tokens / value (service provider) Value - Number of Tokens type: MIN - Duration (e.g., minutes) CC - Congestion charges in monetary value Payment - Any other payment in monetary value Sub-value - A numerical value corresponding to the selected payment type (e.g., 3 minutes, 3 euros, 3 Vodafone coins) VIN - Vehicle Vin Slot ID - An optional field that can be used to specify, for example, a parking slot or toll booth. Location - An optional field that can be used to specify, for example, an entrance point to a congested area or a parking location. ICCID-SIM card ICCID or UICC This can be converted into a JSON object.

[0228] Automated triggers and integrations (e.g., automotive integration) provide improved direct interaction with the blockchain. Furthermore, settlements between network parties can be facilitated. Because the blockchain can register all transactions made between consumers or parties, services can be traded on the same network while settlements are made between them. Smart contracts / flows can determine specific debts and automatically transfer funds from one party to another. Alternatively, an external billing system can aggregate all single transactions existing on the network.

[0229] Use case: "Event-driven fleet" This use case can be directly used to generate data and provide a blockchain-based marketplace / exchange. This can be implemented in different situations and scenarios. In an exemplary embodiment, a logistics company may not fully utilize its cargo transport capacity. Sensor-generated data can be processed using edge secure computing units and shared on a marketplace or exchange to build an "offer" dataset that can be searched, bid on, or purchased by other parties or entities. In this example, the iExec platform was used to match jobs that were queued by a DAB service and executed by a custom off-chain algorithm scripted using iExec, which runs using Intel SGX Engraving. This is schematically shown in Figure 27.

[0230] Whenever a seller wants to sell a route, they manually or automatically enter it into the DAB app's UI and request the DAB service to insert it into other exchanges on the iExec marketplace. Another entity may describe their needs using a similar process or layout within the application. They may search and match compatible offers (both past and future). The DAB service receives these queries, deploys matching jobs, and notifies both parties when matches are found.

[0231] Automatic expansion of the dataset generated by the detection algorithm may be used. Interface / Dependency In the test system, a set of user interfaces has been created in a DAB app (Android or iOS based) to build offer and demand transactions and send them to the transaction engine of the DAB service.

[0232] To use the marketplace / exchange, the DAB service interacts with the iExec SDK. This application is a command-line NodeJS tool that wraps its own Ethereum transaction logic and a separate blockchain integration layer connector for coordinating data insertion and retrieval. Each of these operations involves several OS calls to be executed, an ordered set of commands is issued to the SDK, which synchronously executes and returns text JSON output to be processed and interpreted by the DAB service. All iExec off-chain algorithms run in a secure enclave so that the datasets they use are not directly inserted into their blockchains. Instead, they are encrypted with a secret generated by the SDK and deployed to a public IPFS network (or other file system). This secret, along with the IPFS hash of the dataset, is pushed to iExec each during the insertion flow, the secret is sent to a secret management service and the hash is sent to the blockchain. For IPFS pinning services, Pinata may be used. This implementation also uses an API.

[0233] iExec SDK v4.0.3 was installed along with a DAB service instance on the same machine and required a configuration of NodeJS 8.10.0 and Docker 19.03.6.

[0234] DAB applications are used to create a set of user interfaces that construct transactions sent to the DAB service. This simulates offer and demand capacities. However, such a process is automated in a generation system where offers and acceptances are generated by different entities and processes. Similar message formats are used for two different types of transactions.

[0235] If 「transactionType」 is equal to 「newdata」, an offer data set is included and the DAB service is triggered to deploy it to the blockchain / marketplace / exchange; If it is equal to 「lookingfordata」, it conveys a demand data set that includes the desired trip parameters.

[0236] The matching algorithm prepared by iExec handles a JSON structure that characterizes a test scenario where both offers and demands have a strict data set format similar to each other, and the shipping company sells the available truck space for hire at a specific price, date, and route. Therefore, both data sets are within the property 「transactionObject」.

[0237] Transaction information To manually create a data set that describes the space provided for a truck trip, the user selects the menu entry 「New monetizable data」, tab 「Truck capacity」 on the DAB app and enters the fields. In the generation system, the data set is created by individual trucks that have sensors capable of indicating capacity. The data set includes the following.

[0238] Service provider - The name of the service provider, Space provided - The quantity of available cargo units, Origin point - The trip origin point, Destination - The trip destination, Date - The trip date, Price - The desired price, To manually create a data set that describes the requirements for a truck trip, the user selects the menu entry 「Look for data」 on the DAB app and enters the fields.

[0239] <OO00984>Service provider - The name of the entity looking for cargo space, Required space - The required cargo units, Origin point - The trip origin point, Final destination - Trip destination, Date - Trip date, Price - Bid price.

[0240] Here too, the generation system can automatically generate bids for cargo space for entities that require such services.

[0241] Upon receiving "newdata" or "lookingfordata," the DAB service initiates a series of system-level interactions with the iExec SDK. What is inserted into the iExec blockchain is not the offer dataset itself, but its IPFS hash (along with other relevant iExec data).

[0242] When the "newdata" transaction identifies the dataset to be inserted into the marketplace / exchange, "lookingfordata" triggers a DAB-side flow, which requires it to loop through the previously inserted "newdata" dataset and sequentially deploy and poll off-chain matching tasks (executed in an Intel SGX enclave worker pool managed by iExec). This process is schematically illustrated in Figure 28.

[0243] The matching process involves the DAB service selecting hashes of offer and demand datasets that do not have a corresponding counterpart and inserting them into “tasks” within the iExec worker pool. These tasks are picked up and executed by the iExec worker pool and repeatedly polled by the DAB service until results are computed. The DAB service maintains an updated list containing all dataset hashes in its database. This process is schematically illustrated in Figure 29.

[0244] Since these off-chain tasks cannot perform multiple comparisons simultaneously, the DAB service is responsible for issuing an execution for each dataset. If a match is found between the offer and the demand, the hashes of those datasets are registered in the DAB service database and the purchaser's device is notified.

[0245] The Firebase Cloud Messaging Platform can be used to communicate matches to devices that have both offer and demand datasets inserted, and is a cross-platform cloud solution, particularly for messaging and push notifications in Android applications. The component handles Firebase messaging for DAB-driven devices, and all devices are made to register their Firebase connection tokens at startup (sent along with the device registration message posted to the DAB service). Thus, they are ready to start. Again, the generating system may process messages in different ways.

[0246] The automated supply of data to marketplaces / exchanges may be achieved using different mechanisms. For example, AI and sensor networks can be set up in automated market negotiations. Off-the-shelf matching algorithms may be deployed to protect the worker pool.

[0247] Alternative implementations include: Replacing IPFS with a faster distributed storage solution, To develop a matching algorithm that can handle multiple datasets simultaneously, This includes setting up a dedicated worker pool where the DAB service unloads demand datasets and provides dataset hashes for continuous analysis, which then provide asynchronous notifications when matches are found.

[0248] Use case: "Energy identity and payment" This allows "DAB-enabled devices" (which have a SIM and secure elements on their respective middleware) to be integrated into the Energy Web Foundation smart energy platform and become active participants.

[0249] Connected devices exclusively read and digitally sign messages from the Flexhub MQTT broker (all encoded in JWT strings). Asset owners program offer allocations (for buying and selling power), which are managed and processed by the FlexHub platform. The DAB platform adds domain interconnects, requiring DAB services to be aware of and manipulate transactional data. Thus, the integrated architecture uses a DAB service broker for devices, handling messaging with FlexHub nodes on their behalf. The EWF device-side code (originally written in Python) is ported to a Spring Boot component now running on the DAB core serving multiple devices, without affecting any FlexHub functionality. A schematic diagram of this system is shown in Figure 30.

[0250] The relevant users / parties / roles as defined by EWF include the following: The TSO (Transmission System Operator) submits flexibility requests, defines constraints and limitations, and activates approved assets.

[0251] Asset owners define offer parameters so that each of their individual assets can submit offers that match those parameters.

[0252] The installer approves the asset owner's registration of the asset. The competent authority approves the registration of the roles of other parties participating in the market.

[0253] The TSO submits its energy flexibility requirements and constraints to the system, the asset owner submits their offers (either by themselves or through a third-party intelligence provider), and the Flex system determines the lowest-cost way to meet the requirements.

[0254] Other enhancements may include the following: Automating registration, provisioning, and offer creation.

[0255] Devices other than those using Android or Java. The device is requested to sign the transaction and notified of the offer activation. These are triggered by the DAB service. This avoids the device having to poll its own FlexHub MQTT queue for commands from each device. The DAB app provides functionality including:

[0256] The device receives a message containing the EWF transaction for signing, which is then posted to a custom endpoint on the DAB Core service API, triggering DAB Core to complete the respective EWF business flow.

[0257] Whenever an activation message is received, the DAB app displays a user notification, which may be replaced by a useful and actual action (e.g., turning a device reachable from the mobile application on or off). This is schematically illustrated in Figure 31.

[0258] Business Logic The flow begins with inputs made by various EWF actors within the Flex WebApp. The DAB service is the only component that implements the EWF business logic (and any kind of flow state observability), and therefore requests the device to sign the various JWTs required by FlexHub.

[0259] After signing the requested message, the device returns it to the DAB service with enough information to determine what flow was running for the device that sent the signed message. The device may need to sign other JWTs that are different from those related to its current use case (one of the DAB stack goals). Therefore, the Firebase Data Message format allows for rapid adaptation to other scenarios. The inventors felt it appropriate to include an additional "useCaseAction" property that allows the server to distinguish additional courses of action within that particular use case in order to identify the DAB use case for which the signature is requested and to identify the action to be triggered in the DAB service upon submission. Figures 32 and 33 show sequence diagrams of this process.

[0260] For this integration, the property "useCase" was tagged as "ewf," and the "useCaseAction" field was used to indicate the specific EWF business flow that initially required device signing.

[0261] Asset owners can also use Flex WebApp to view activation charts for a given offer executed by a specific asset. Through the dashboard, users can access a list of created offers and select the "Datasheet" icon for the offer they want to chart.

[0262] The device becomes part of the EWF network, which can be extended to further practical operations such as turning generators, batteries, etc. on / off. The same can be applied to other marketplaces besides FlexGrid, including electric vehicle charging (EVC) or simple smart meter data monetization.

[0263] Use case: "Corporate and consumer parking" In this use case, we will use digital IDs (for people, services, and things) to create a complete end-to-end experience where a car can be paired with a service, regardless of whether payment is involved.

[0264] 1. Performed by either of the drivers (consumer B2C scenario - using the driver's digital identification information and associated personal account within the banking platform), 2. Charges are applied to the vehicle itself if its use is maintained on DLT for subsequent processing (corporate B2B scenario - when the vehicle belongs to a third party, e.g., a rental company). The DAB service manages and organizes flows (and hosts Corda DLT for use in B2B payments). Vehicles may include an internal router running DAB middleware applications and customized versions of DAB apps (e.g., tablet apps). This can be installed on an embedded (e.g., iOS or Android-based) dashboard computer.

[0265] Interface / Dependency The SPOT parking system can be installed in the same location and with Corda Ledger, similar to the "service payment" use case.

[0266] SIM protection To sign the transaction, a SIM protected by the aforementioned SIM method may be used, consuming PKI on the SIM. The SIM is added to a USB dongle plugged into a processor or other device (e.g., a vehicle). DAB middleware runs on the device and exposes the DAB middleware API for signing, as described above.

[0267] The SPOT parking system, installed in the parking infrastructure, works with the DAB service by detecting vehicles crossing its gate and calling an endpoint with a custom set of APIs (see above). This customization is used by SPOT to send license plate and gate information to the DAB service, which then expects a return code in the following cases:

[0268] Upon entry: The barrier can be opened because the activated payment has been set up. Upon departure: Once payment is complete, the vehicle can be removed from the parking lot.

[0269] FINN To manage the B2C scenario, we used FINN(RTM), which specializes in monetizing IoT solutions built on a commercial platform that includes a toolkit for adding IoT payments to smart devices. In summary, A "product" defines the various actions that provide a service and interact with it, and assigns a usage price to each of them.

[0270] The device registers to use the "product," and the action is charged to the payment method set up by the device owner, such as a credit card.

[0271] Whenever a device triggers a "product" action, a micropayment is registered in the FINN ecosystem.

[0272] In the case of FINN, a “product” can be an abstract entity representing any real system operating in the real world (integrating with the FINN IOT SDK to connect “product” actions with any automated activities) or an offline service. All usage logic within the SPOT is controlled by the DAB service component. The configured behavior for this “product” includes gate entry and exit, where a parking fee is charged based on the length of stay, and 0 respectively.

[0273] A sequence diagram of the parking session is shown in Figure 34. To trigger these scenarios, a collection of user layouts within the DAB app constructs transactions according to the message format specified in the DAB management core. In the parking scenario (use case type "Parking"), session start and end are distinguished by their "transactionType" values ​​("newdata" and "endcordasession") and the content of "transactionObject". This last field carries information about both the buyer (car) and supplier (parking lot) committed to the DLT. Along with geographical information, the DAB service acts as a proxy server for each device (used to verify the device's location as needed).

[0274] To start a simulated parking session, the user selects the menu entry "New Monetizable Data," the "Parking" tab, and fills in the following fields on the DAB app.

[0275] Initiator - The device that starts the parking session (the device's SIM ID is automatically entered). Target - The Corda node where the vehicle is registered. Target UUID - Code identifier (UUID) of the initiator vehicle, Source UUID - The code identifier (UUID) of the parking slot selected for parking the vehicle. GPS options: MOCK_HAPPY_PATH - Start a parking session using GPS location: The result will always be a successful action. REAL_GPS - Starts a parking session using the actual GPS location as read by the Android OS. For a successful parking session to start using this option, the initiator device and parking slot must be at least 6 meters apart from each other.

[0276] To enter a parking session, the user must: Open the session in the "Transactions" menu entry and fill in the following fields.

[0277] The amount / value unit charged on the blockchain GPS options: MOCK_HAPPY_PATH - Stops the parking session using GPS location; this action is considered successful. REAL_GPS - Ends the parking session using the device's actual GPS location. MOCK_END_SESSION_CAR_STILL_PARKE D - A test flag that instructs the Corda DApp to behave as if the car has not left its parking spot.

[0278] Business Logic In this use case, the device using the "product" is a vehicle. However, its "action" may also be activated in a B2C scenario. Thus, the concept of "smart services" is used, which is the association between the user's digital identity and the services provided by the DAB stack.

[0279] DAB associates the device (car) with the SIM: Because this is a FINN-based smart service, the DAB service needs to know all the FINN data related to the SPOT parking "product" in order to pass it on to the device that wants to use it. This is done every time the vehicle tablet app (or any other processor in the vehicle or device) is launched and installed along with it is the FINN-provided app (which incorporates the FINN IoT SDK), which contains code to register with the FINN core backend and automatically set up that vehicle so that it is ready to use the SPOT parking "product" whenever needed. This provisioning flow is shown in Figure 35 and includes the following:

[0280] Step Description Trigger 1. Manufacturer adds new car to SCB-DAB system. 2. DAB deploys a new smart contract for its car's identity to the DDI blockchain network. DAB 3. The DDI blockchain network responds with the corresponding did. DDI blockchain 4. DAB associates it with the car's license plate. 5. DAB sends the car's didid to the corresponding car. 6. A car saves its own did in its own database. Smart Service Onboarding: Whenever a user wants to onboard a "smart service," they do so using a specially developed Android application (hereinafter referred to as the "smart service application"). The application works with the DID application to select a digital identity and associate the selected smart service with it from its UI. This is schematically illustrated in Figure 36.

[0281] At this point, if the user is onboarding to use the "SPOT Parking Smart Service," the DAB service has responded with enough data (data initially sent by the tablet app) to configure the user's FINN payment method. For this purpose, the smart service app automatically communicates via intent with another FINN supply application (incorporating the FINN Mobile SDK), which first requests a valid payment credit card from the user and then registers it as a consumer of the SPOT Parking product. This is schematically illustrated in Figure 37. In this exemplary implementation, the following steps can be taken:

[0282] Onboarding for B2C services (Figure 37) Step Description Trigger 1. The smart service app triggers the DAB to create a new service for the user. 2. DAB checks the profile type (for individuals) and saves the user data. 3. DAB responds with the data necessary for user-side initialization: user profile data + service data. 4. The smart service app triggers the Finn mobile app to create a new service (via an intent). 5. The Finn mobile app forwards requests to the FINN core. (FINN mobile application) 6. The FINN core responds with success or an error message. 7. The Finn mobile app responds with success or error message (via intent return). 9. The Smart Services app posts Finn's onboarding confirmation to / services / confirmation Smart Service App Device identification (e.g., a car): A login mechanism is established on the DAB platform that leverages digital identity capabilities to create a session between the user and the object, in order to determine which car the user is driving (and to understand that the vehicle will trigger the FINN SPOT parking "product" action). In this way, whenever a car crosses the entrance gate, the DAB service knows who is driving it. This flow is triggered when the driver enters the car's license plate number into the DAB app (pre-installed on the car's in-car tablet), and the subsequent activity can be divided into two stages.

[0283] QR Code (Registered Trademark) Generation: The DAB app generates a QR code on the tablet for the driver to scan in order to proceed with the authentication process, and Driver Authentication: The driver scans a QR code, triggering and opening the DDI app. From there, the driver allows (or does not allow) personal information they wish to share with the vehicle. Some of this data is mandatory, while others are optional, and this is a design decision comprised of the DAB (which acts as a proxy for all vehicles). All permitted information shared by the user can be stored in the DAB. This is schematically illustrated in Figure 38.

[0284] Driver-vehicle login via QR code (Figure 38) Step Description Trigger 1. The driver enters the license plate number into the car's tablet app. 2. The tablet app sends a login request to the DAB. 3. DAB generates a random topic UUID that identifies the login "session". 4. DAB requests a nonce + authorization ID from GCL. 5 GCL response: nonce + authID GCL 6. DAB associates a topic with nonce + authID + step 2 data. 7. DAB sends the data necessary to generate the QR code to the tablet app. 8. The tablet app generates an authentication QR code. Driver-vehicle login via decentralized digital ID (DDI) (Figure 39) Step Description Trigger 1. The driver scans the QR code with their phone (including topic + vehicle DID identity). 2. The DDI app opens, and the driver selects and / or allows the data they want to share about themselves. 3. The DDI app shares that information with GCL. 4. GCL requests the DAB return URL stored in the provided car identity from the blockchain. 5. GCL posts to its endpoint and checks for the existence of the topic. If the topic exists, DAB stores the specified userDid related to the user attempting to log in. 6. DAB sends an OK or error response to GCL. 7. GCL sends login results to the DDI app. 8. If the login is successful, the DDI app posts the user profile + profile type to the DAB. 9. DAB saves the user profile + profile type for this user / vehicle session. 10. DAB sends login results to the tablet app. 11. The tablet app displays a success message. DAB Service: The DAB service is triggered whenever SPOT posts information about detected vehicle license plates to a custom REST endpoint of a custom API (implemented according to the specifications of the existing SPOT infrastructure). The following logic required additional components to be integrated within the DAB core to manage the SPOT business flow, which can be summarized as follows:

[0285] When a vehicle enters the parking lot, If a B2B profile is onboarded to the smart service, the DAB service will use the Corda connector in the blockchain integration layer to open a session for that vehicle on Corda DLT (mirroring the "parking and tolls" use case). If a B2C profile is onboarded to the smart service, a Firebase message is pushed to the vehicle's tablet app, triggering product activation in the Finn backend for the SPOT product identifier.

[0286] When a vehicle leaves the parking lot, If the B2B profile is onboard for smart services, the DAB service will close any previously opened DLT sessions for that vehicle. If a B2C profile is onboarded to the smart service, a Firebase message is pushed to the vehicle's tablet app, triggering product deactivation in the Finn backend for the SPOT product identifier.

[0287] B2B begins with details of the parking flow (Figure 40). Step Description Trigger 1. The camera at the entrance gate scans the license plate. 2. The parking gate requests the DAB to initiate a new parking session for that license plate. 3. DAB checks the user's DID profile type used for onboarding parking services (for enterprises) DAB 4. DAB triggers a new parking session within the Corda parking blockchain. 5. Response from Blockchain to DAB - Success or Error Parking Blockchain 6. DAB sends a Firebase notification to the tablet app notifying it of a new parking session, returns step 2 with the appropriate message, and then triggers and opens the gate. 7. The tablet app displays information about the new parking session on the screen. B2C begins with details of the parking flow (Figure 41). Step Description Trigger 1. The camera at the parking gate scans the license plate. 2. The parking gate requests the DAB to initiate a parking session for that license plate. 3. DAB checks the user's DID profile type used for onboarding the parking service (for individuals). 4. DAB sends a Firebase notification to the tablet app, triggering a Finn action (inventory receipt). 5. The tablet app triggers an inbound action in the FINN IoT SDK via an intent. 6. The FINN IoT SDK uses DAB middleware to sign transactions with the corresponding key pair. 7. The FINN IoT SDK triggers inbound actions within the FINN core. 8. Response from FINN Core to FINN IoT SDK - Success or Error FINN Core 9. The FINN IoT SDK signals the result of an operation via an intent return, and the tablet app displays a notification popup. 10. DAB returns from the post made in step 2 and triggers the gate to open (tablet app) The B2B section concludes with details of the parking flow (Figure 42).

[0288] Step Description Trigger 1. The camera at the exit gate scans the license plate. 2. The gate requests the DAB to terminate the parking session for that license plate. 3. DAB checks the user's DID profile type used for onboarding parking services (for enterprises) DAB 4. DAB triggers the closing of a parking session within the Corda parking blockchain. 5. Response from Blockchain to DAB - Success or Error Parking Blockchain 6. DAB sends a Firebase notification to the tablet app including the price and duration of the parking session, returns step 2 with the appropriate message, and then triggers and opens the gate. 7. The tablet app displays information about the new parking session on the screen. The B2B section concludes with details of the parking flow (Figure 43).

[0289] Step Description Trigger 1. The camera at the exit gate scans the license plate. 2. The gate requests the DAB to terminate the parking session for that license plate. 3. DAB checks the user's DID profile type used for onboarding the parking service (for individuals). 4. DAB sends a Firebase notification to the tablet application containing the price and duration of the parking session, triggering a Finn action (exit). 5. The tablet app triggers an outbound action in the FINN IoT SDK via an intent. 6. The FINN IoT SDK uses DAB middleware to sign transactions with the corresponding key pair. 7. The FINN IoT SDK triggers outbound actions within the FINN core. 8. Response from FINN Core to FINN IoT SDK - Success or Error FINN Core 9. The FINN IoT SDK signals the result of an operation via an intent return, and the tablet app displays a notification popup. 10. DAB returns from the post made in step 2 and triggers the gate to open (tablet app) Similar solutions can be applied to different parking solutions, and also to different domains in smart cities where, for example, EV charging and payment can follow the same flow. Improvements are being made to the end-to-end experience with regard to consumer digital IDs and payments.

[0290] DAB User Interface The test environment has the following two main user interfaces (UI):

[0291] DAB APP: Android (or other) mobile application DAB AEP: A Thingworx extension for connecting the DAB Corda blockchain. The UI is crucial not only for ensuring customers have access to all features, but also for enabling operations and maintenance teams to manage the ecosystem and solutions, and to monitor and extract information.

[0292] Figures 44–48 show an exemplary platform environment. Other server types and services may be used.

[0293] This describes a test scenario, but actual parking sessions may be handled in a similar but application-independent way. All messages can be initiated by sensors inside or around the vehicle (or parking location) and detected events.

[0294] As those skilled in the art will understand, the details of the above embodiments can be modified without departing from the scope of the invention as defined by the appended claims.

[0295] For example, different distributed ledger or ledger technologies can be used. UICC may be, for example, an embedded SIM. Many different types of devices may be used, for example, including mobile, portable, fixed, monitored, unmonitored, home, commercial, or industrial devices.

[0296] Many combinations, modifications, or changes to the features of the embodiments described above will be readily apparent to those skilled in the art and are intended to form part of the present invention. Any feature described in relation to one embodiment or example may be used in any other embodiment by appropriate modifications.

Claims

1. A method for generating a transaction in a system including a first device, a second device, and a node in a distributed ledger, wherein the method is The aforementioned system includes the steps of defining one or more conditions for a transaction, The system includes the steps of adding one or more conditions to a block in the distributed ledger, A step of generating an offer for a digital asset using the first device, wherein the offer is digitally signed by a secure applet executed within the UICC of the first device. A step of generating a request for the digital asset by the second device, wherein the request is digitally signed by a secure applet executed within the UICC of the second device, The system includes the steps of authenticating the digital signatures of the offer and the request, It is determined that the offer and the request satisfy one or more conditions added to the distributed ledger, If one or more of the above conditions are met by the offer and the request, The secure applet executed within the UICC of the first device digitally signs the digital asset, The signed digital asset is transmitted from the first device to the second device. Authenticate the digital signature of the signed digital asset, A method comprising the steps of adding a transaction to a block on the distributed ledger, which records the transmission of the digital asset from the first device to the second device.

2. The method according to claim 1, wherein the step of determining whether the conditions are met by the system is determined by one or more smart contracts stored in the distributed ledger.

3. The method according to claim 1 or 2, wherein the first device, the second device, or a separate server adds the block to the distributed ledger that records the transmission of the digital asset from the first device to the second device.

4. The signed digital asset is transmitted to the first device via a secure channel. The method according to claim 1 or 2, wherein the data is transmitted directly from the second device.

5. The method according to claim 1 or 2, further comprising the step of recording a transaction of value on the distributed ledger between the second device and the first device in response to the condition being met by the system.

6. The method according to claim 1 or 2, further comprising the step of the first device authenticating the digitally signed request.

7. The method according to claim 1 or 2, further comprising the step of exchanging the digital asset for one or more goods or services using the system.

8. The method according to claim 1 or 2, further comprising using the digital assets to access the service.

9. The method according to claim 1 or 2, wherein the digital asset includes a data package.

10. The method according to claim 9, wherein the data package is derived from a sensor on the first device.

11. A first device having a UICC, wherein the first device is configured to generate an offer for a digital asset and to transmit the digital asset, and the UICC is configured to a processor, To digitally sign the aforementioned offer, and Digitally signing the aforementioned digital assets A first device stores in memory a secure applet containing program instructions that perform the following actions, A second device having a UICC, wherein the second device is configured to generate a request, receive the digital asset transmitted by the first device, and authenticate the digital signature of the digital asset, and the UICC stores in memory a secure applet containing program instructions for causing a processor to digitally sign the request. A distributed ledger having one or more nodes, each having one or more processors and memory, wherein the memory is connected to the one or more processors, Adding one or more conditions to one or more blocks in the distributed ledger, Authenticating the digital signature of the offer and the request, Determining that the offer and the request satisfy one or more conditions added to the distributed ledger, If it is determined that the digitally signed offer and request meet one or more of the conditions, the digitally signed asset will be transmitted from the first device to the second device. A distributed ledger and a program instruction that causes the following to occur. A system equipped with these features.

12. The system according to claim 11, wherein the UICC of the first and second devices further comprises one or more secure storage locations configured to store cryptographic material for use in digital signatures.

13. The first device comprises one or more sensors configured to generate sensor data. The system according to claim 11 or 12, further comprising, wherein the digital assets are derived from their sensor data.

14. The system according to claim 11 or 12, further comprising one or more service providers configured to provide services in exchange for the digital assets.

15. The system according to claim 11 or 12, wherein the distributed ledger is further configured to store the conditions as one or more smart contracts.

Images