Intercommunication between IoT service layer systems and distributed ledger systems

Abstract

This paper describes a distributed ledger intercommunication architecture in which a distributed ledger agent interfaces with an IoT service layer system and a distributed ledger system. The service layer node can interact with the distributed ledger agent to utilize the functions provided by the distributed ledger system, for example, requesting the distributed ledger agent to insert some service layer information into the distributed ledger. The distributed ledger agent can support multiple service layer nodes and can interface to multiple different distributed ledger systems.

Description

Background Art

[0001] The oneM2M standard defines a service layer implemented in one or more network entities, each of which is called a "Common Service Entity" (CSE). The purpose of the service layer is to provide "horizontal" services that can be utilized by different "vertical" M2M systems and applications. The CSE supports four reference points. The Mca reference point interfaces with the Application Entity (AE). The Mcc reference point interfaces with another CSE within the same service provider domain, while the Mcc' reference point interfaces with another CSE within a different service provider domain. The Mcn reference point interfaces with the underlying network service entity (NSE). The NSE provides basic network services to the CSE, such as device management, location services, and device triggering. The CSE contains multiple logical functions called "Public Service Functions" (CSFs), such as "Discovery" and "Data Management and Repository". Summary of the invention

[0002] A method and system for intercommunication between an IoT service layer system and a distributed ledger system is disclosed. A distributed ledger intercommunication architecture is described in which a distributed ledger agent interfaces with the IoT service layer system and the distributed ledger system. The service layer node can interact with the distributed ledger agent to utilize the functions provided by the distributed ledger system, such as requesting the distributed ledger agent to insert some service layer information into the distributed ledger. The distributed ledger agent can support multiple service layer nodes and can interface to multiple different distributed ledger systems.

[0003] This summary is provided to introduce selected concepts in a simplified form, which are further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] In order to facilitate a more complete understanding of the present application, reference is now made to the accompanying drawings, in which like elements are represented by like reference numerals. These drawings should not be construed as limiting the present application, but are intended to be illustrative only.

[0005] Figure 1 An example block diagram of the oneM2M architecture is shown;

[0006] Figure 2 An example block diagram showing a distributed ledger system architecture;

[0007] Figure 3 A flow chart illustrating example operations performed at a distributed ledger node;

[0008] Figure 4 A flow chart illustrating an example distributed ledger structure in the Bitcoin system and related distributed ledger systems;

[0009] Figure 5 A block diagram showing an example distributed ledger structure in a Bitcoin system;

[0010] Figure 6 A flow chart showing an example transaction structure in the Bitcoin system;

[0011] Figure 7 A flow chart showing a separated IoT service layer system and a distributed layer system;

[0012] Figure 8 A first example distributed ledger intercommunication architecture is shown;

[0013] Fig. 9 A second example distributed ledger intercommunication architecture is shown;

[0014] Fig.10 A third example distributed ledger intercommunication architecture is shown;

[0015] Fig.11 A fourth example distributed ledger intercommunication architecture is shown;

[0016] Fig.12 A flow chart illustrating an example method of distributed ledger intercommunication using first and second intercommunication architectures;

[0017] Fig.13 A flow chart illustrating an example method of distributed ledger intercommunication using a third intercommunication architecture;

[0018] Fig.14 A flow chart illustrating an example method of distributed ledger intercommunication using a fourth intercommunication architecture;

[0019] Fig.15 A flowchart illustrating an example method for distributed ledger proxy and service layer node association;

[0020] Fig.16 A flow chart illustrating a first example method for adding service layer information to a distributed layer;

[0021] Fig.17 An example of a distributed layer system transaction is shown;

[0022] Fig.18 A flow chart illustrating a second example method for adding service layer information to a distributed layer;

[0023] Fig.19Aand 19B A flow chart illustrating a third example method for adding service layer information to a distributed layer;

[0024] Fig. 20 A flow chart illustrating an example method for querying transactions in a distributed ledger system;

[0025] Fig.21 A flow chart illustrating an example method for verifying a transaction in a distributed ledger system;

[0026] Fig. 22 A flow chart illustrating an example method for subscribing to transactions in a distributed ledger system;

[0027] Fig.23 shows a transaction template format for use in a distributed ledger system <dlstxtemplate>Example structure of resources;

[0028] Fig.24 Shows the operation <dlstxtemplate>Example methods for resources;

[0029] Fig.25 Illustration of an example of a transaction involving a distributed ledger system <dlstx>Example structure of resources;

[0030] Fig.26 Shows the operation <dlstx>Example methods for resources;

[0031] Fig. 27 An example user interface for a service layer node is shown;

[0032] Fig.28 An example user interface for a distributed ledger agent is shown;

[0033] Fig.29A An example system diagram illustrating an example machine-to-machine (M2M) or Internet of Things (IoT) communication system in which one or more disclosed embodiments may be implemented;

[0034] Fig.29B It shows that it can be Fig.29A An example system diagram of an example architecture used within an M2M / IoT communication system is shown;

[0035] Fig.29C It shows that it can be Fig.29A An example system diagram of an example M2M / IoT terminal or gateway device used within the communication system shown; and

[0036] Fig.29D It shows that it can be achieved Fig.29A An example block diagram of an example computing system that illustrates aspects of a communication system. DETAILED DESCRIPTION

[0037] The oneM2M architecture (see oneM2M-TS-0001 oneM2M functional architecture - V3.10.0, February 2018) implements the following types of nodes, such as Figure 1 As shown:

[0038] Application Service Node (ASN): A node that contains a CSE and includes at least one Application Entity (AE). Physical Mapping Example: ASN can reside in an M2M device;

[0039] Application Dedicated Node (ADN): A node that contains at least one AE and no CSE. There can be zero or more ADNs in the field of a oneM2M system. Physical mapping example: ADN can reside in a constrained M2M device;

[0040] Middle Node (MN): A node that contains a CSE and contains zero or more AEs. There can be zero or more MNs in the field of a oneM2M system. Example of physical mapping: A MN can reside in an M2M gateway;

[0041] Infrastructure Node (IN): A node that contains one CSE and contains zero or more AEs. There can be exactly one IN in the infrastructure domain of each oneM2M Service Provider. The CSE in an IN may contain CSE functionality that is not applicable to other node types. Physical Mapping Example: An IN may reside in an M2M Service Infrastructure; and

[0042] Non-oneM2M Node (NoDN): A node that does not contain a oneM2M entity (neither AE nor CSE). Such a node represents a device that is attached to the oneM2M system for interworking purposes (e.g., management).

[0043] Figure 2 An example instance of a distributed ledger (DL) transaction is shown, where DLN1 sends a transaction to a peer distributed ledger node (DLN). This figure also illustrates a general distributed ledger system (DLS) architecture, in which DLNs can be interconnected and participate in the system via an underlying peer-to-peer (P2P) network. There are some existing DLSs, such as the Bitcoin system and the Ethereum system. Depending on the underlying P2P network protocol, a DLN can have several other DLNs as its peer neighbors. A DLN can be a complete node or a lightweight node. A complete DLN node (e.g., a miner in a Bitcoin system) maintains a complete ledger, which is always growing due to transactions newly added to the ledger. A lightweight DLN node (e.g., a wallet client software in a Bitcoin system) does not maintain a complete ledger, but can only process transactions to and from the ledger. Typically, the following operations are performed independently at each DLN node, so that a complete and consistent ledger can be continuously formed and maintained at each complete DLN node. It should be understood that these operations are exemplary only, and some operations may not be required for lightweight DLN nodes.

[0044] In phase 1, after startup, the DLN discovers and selects some existing DLNs as its peer neighbors (e.g., via Domain Name System-based Service Discovery (DNS-SD)), and connects to the P2P network. It then synchronizes with its neighbor DLNs by downloading the current ledger from them, and may also exchange public keys or other similar credentials.

[0045] In phase 2, a DLN generates a new transaction and can sign it using its private key. This DLN can be the issuer of this transaction (e.g., the payer in the Bitcoin system). It then sends the signed transaction to its neighbor DLNs, which can also relay the transaction to their neighbors. Ultimately, the new transaction can be received by all DLNs in the system.

[0046] In phase 3, the DLN receives the new transaction and can verify the transaction using the public key of the sending DLN.

[0047] In phase 4, each complete DLN node independently executes a consensus protocol (e.g., proof of work (PoW) in the Bitcoin system) and generates a transaction set (e.g., a block in the Bitcoin system) containing a set of newly generated but unconfirmed transactions. The first DLN node that generates a transaction set that meets the requirements provided by the DLS is declared the winner. In other words, only the winner outside the consensus protocol can generate a new transaction set and send it to the P2P network for verification. Note that this transaction set usually contains a previous transaction reference to the last transaction set of the current ledger; the previous transaction reference helps to append this transaction set to the current ledger in phase 6.

[0048] In phase 5, the winner (e.g., DLN6 in this example) generates a transaction set and sends it to the P2P network.

[0049] In phase 6, the DLNs (e.g., DLN3, DLN4, and DLN5 in this example) receive the transaction set and validate it according to the same consensus protocol. At each DLN, the validated transaction set can be appended to the current ledger, which means that all transactions contained in the transaction set are now confirmed; thereby independently and automatically updating the DLS system state (e.g., unspent bitcoins in the Bitcoin system) at each DLN by merging changes from all transactions in the confirmed transaction set. Prior to this step, the entire DLS will reach a new state that will be updated by future transaction sets.

[0050] according to Figure 2 Example shown: 1) DLN1 and DLN2 are light nodes and may be involved only in phases 1, 2, and 3; 2) DLN1 generates a new transaction, which is received by all other DLNs; 3) DLN3-DLN6 are full nodes and execute the consensus protocol independently, and DLN6 is the winner; 4) Each full node maintains a separate ledger but has the same list of transaction sets (e.g., an increasing set of verified transactions).

[0051] Many DLSs (e.g., the Bitcoin system) are designed with the following features and advantages:

[0052] Protect the data integrity of each transaction by signing the transaction with the private key of the sending DLN;

[0053] Sending a DLN only discloses its public key or the hash of its public key, not its real identity. Therefore, privacy is preserved from an identity perspective;

[0054] Since each complete DLN maintains a separate and complete ledger, there is no single point of failure and tampering with the ledger is virtually impossible; and

[0055] DLNs do not require pre-established trust between them, but independently execute consensus protocols, which requires intensive computation in some DLs (e.g., PoW in the Bitcoin system) and the cost of attacking the ledger would be very high.

[0056] A DLS can be used by public users without any pre-established permission or trust and is referred to as a public ledger or permissionless ledger (e.g., the Bitcoin system). In contrast, a private ledger or permissioned ledger (e.g., the Hyperledger system) is a DLS that is only used by certain permitted users (e.g., users within an organization). Another difference between these two types of DLS is that private ledgers can use simple consensus protocols because users in a private ledger have already established a certain amount of trust.

[0057] based on Figure 2 The general architecture shown, Figure 3 Example operational details at a DLN are shown, which may include the following steps (although the details may vary for a particular DLS). It should be understood that each DLN may perform these steps independently.

[0058] In step 1, the DLN starts and discovers existing DLNs.

[0059] In step 2, the DLN relies on the underlying P2P protocol to connect to one or more discovered DLNs, and public keys or similar credentials may be exchanged with each other.

[0060] In step 3, the DLN retrieves the current ledger from one or more discovered DLNs.

[0061] In step 4, the DLN waits for an upcoming event or trigger (eg, generating a new transaction, receiving a new transaction set, or receiving a new transaction).

[0062] When a new transaction needs to be generated, both steps 5.1 and 5.2 may be triggered.

[0063] In step 5.1, the DLN assembles a new transaction. The DLN can sign the transaction using its private key. The transaction structure varies in different DLSs. For example, Figure 6 (discussed below) shows the transaction structure in the Bitcoin system.

[0064] In step 5.2, the DLN sends the transaction to its neighbor DLNs.

[0065] When the DLN receives a new transaction, steps 6.1-6.4 may be triggered.

[0066] In step 6.1, the DLN receives a new transaction from the P2P network.

[0067] In step 6.2, the DLN verifies the transaction, which can be a check whether the issuer of the transaction has enough unspent bitcoins in the ledger to support the transaction in the Bitcoin system. If the transaction is valid, the DLN can store it in a transaction pool waiting for the execution of the consensus protocol, or forward it to a neighbor DLN. In some systems (e.g., Ethereum), the transaction can be sent to a contract account in the ledger and can cause the execution of the contract code contained in the contract account. Note that the transaction may not be verified until the consensus protocol is completed.

[0068] In step 6.3, DLN executes the consensus protocol and generates a new set of transactions. Taking the Bitcoin system as an example, DLN assembles unconfirmed transactions (which have been cached in the transaction pool) into a block. The block may also contain a reference to the last block in the current ledger (e.g., hash (last block)) and a matching random number. The matching random number can be found after a large number of computational attempts so that the hash value of "this new block + matching random number" is less than the target value. The Bitcoin system is designed so that this process (e.g., finding a matching random number) takes an average of ten minutes. In other words, in the Bitcoin system, the average time required to generate a new block by executing the PoW protocol is ten minutes. Figure 5 An example block structure used in the Bitcoin system is shown in .

[0069] In step 6.4, the DLN sends the new transaction set (e.g., a new block in the Bitcoin system) to the P2P network.

[0070] When a DLN receives a new transaction set from its neighbor DLNs, steps 7.1-7.4 may be triggered.

[0071] In step 7.1, the DLN receives a new transaction set from the P2P network. If the DLN is still executing a consensus protocol on the transactions contained in the received transaction set, and if the received transaction set is valid, the DLN may stop the current consensus protocol execution and may move to executing a consensus protocol on other unconfirmed transactions buffered in the transaction pool.

[0072] In step 7.2, DLN verifies the received transaction set according to the consensus protocol. Note that the consensus protocol (e.g., PoW in the Bitcoin system) may require a lot of computation when generating a new transaction set (e.g., step 6.3), but it can usually verify the received transaction set faster without spending too much computation.

[0073] At step 7.3, once the transaction set is a valid transaction set, the DLN appends the transaction set to the ledger. Typically, the transaction set contains a reference to the last transaction set in the current ledger (e.g., its parent transaction set). In some DLSs, when a validated transaction set is appended to the ledger, it can be connected to multiple previous transaction sets. Figure 4 is shown in and discussed below.

[0074] In step 7.4, the DLN forwards the verified transaction set to its neighbor DLNs.

[0075] Figure 4 An example distributed ledger structure used in the Bitcoin system and other DLSs using blockchain technology similar to the Bitcoin system is shown. Note that the distributed ledger can be maintained independently by each full DLN node and can include the following three components:

[0076] Blockchain: A chain of verified blocks. The first block is the genesis block, with no reference to any previous blocks. Block #N is the last block that was recently generated and verified;

[0077] Transaction pool: A storage pool at the DLN that buffers all received but unconfirmed transactions. When a new block is received and verified, all transactions included in the new block can be removed from the transaction pool; and

[0078] Accounts and virtual machines: The Bitcoin system does not have this, but the Ethereum system uses this to support smart contracts and develop various vertical applications on top of the Ethereum system. There are two types of accounts in the Ethereum system: external accounts owned by users and contract accounts that contain contract code. External accounts can send transactions to empty addresses to create new contracts (e.g., contract accounts) and eventually deploy them to the system. Whenever a contract account receives a transaction from an external account or a message from another contract account, the contract code is automatically triggered and executed. Note that for consensus purposes, the Ethereum system uses the same PoW protocol as the Bitcoin system.

[0079] Figure 5 An example block structure used in the Bitcoin system is shown. The example block structure has the following fields:

[0080] Block size: indicates the size of the entire block;

[0081] Block header: contains information associated with the version, previous block hash, Merkle root, timestamp, difficulty target, and nonce;

[0082] Version: the version of Bitcoin system;

[0083] Previous block hash: The hash of the previous block (e.g., the last block on the ledger);

[0084] Merkle root: the hash of all included transactions according to a specific tree structure;

[0085] Timestamp: the time when the block was generated;

[0086] Difficulty target: used to adjust the difficulty of the PoW protocol so that a new block can be generated every ten minutes on average;

[0087] Nonce: An integer obtained from running the PoW protocol to ensure that hash(this block, nonce) will be less than the target value;

[0088] Transaction counter: Indicates the number of transactions included in the block; and

[0089] Transactions: Contains a set of transactions. The first transaction is a coinbase transaction (or generation transaction) created by a miner (e.g., the DLN that generated the block) to claim a reward that includes all transaction fees for the effort of running the PoW protocol and generating the block. Therefore, a coinbase transaction may not have an input part (see Figure 6 ).

[0090] Figure 6 The transaction structure in the Bitcoin system is shown, wherein two specific transaction instances (eg, TIDx and TIDy) are shown. The transaction instance TIDx may have been generated before the transaction instance TIDy.

[0091] Each transaction can have two main parts (e.g., "inputs" and "outputs") and some other fields not shown in the figure. The "inputs" part includes a list of unspent transaction outputs (UTXOs) that other payers have transferred or paid to the publisher of this transaction. The "outputs" part includes a list of UTXOs that the publisher of this transaction will pay to use all the UTXOs in the "inputs" part. The total amount of Bitcoin contained in the "inputs" part should not be less than the total amount of Bitcoin contained in the "outputs" part, and the surplus can be paid as an incentive for the miner DLN who runs the PoW protocol and first generates a new and valid block.

[0092] In TIDx issued by user 1, user 1 pays user 2 and user 4 (for example, 0.1 bitcoin to user 4 and 0.2 bitcoin to user 2). Therefore, there are two UTXOs in the "output" part of TIDx, one for user 4 and the other for user 2. Note that the "input" part of TIDx is omitted for convenience of explanation.

[0093] The "input" part of a transaction contains references to one or more UTXOs that have been included in previous transactions. For example, the "input" part of TIDy contains a UTXO that points to the UTXO with output index = 1 in transaction TIDx.

[0094] In TIDy issued by user 2, user 2 uses his Bitcoin (e.g., received from user 1 in TIDx) to pay user 3 (e.g., 0.15 Bitcoin); 0.04 of the change is returned to user 2, and the remaining 0.01 Bitcoin is used as a transaction fee.

[0095] Each user can have a pair of unique keys (private key, public key). The public key can be based on the private key.

[0096] The public key can be used to generate a unique Bitcoin address. A Bitcoin address is public and revealed to other users, and can be used as a receiving address (e.g., a payee) in the "output" portion of a transaction.

[0097] The private key can be used to generate a signature, which the payer can use together with the public key as an UnlockingScript(US) to unlock the UTXO based on its LockingScript(LS), and can also be used by other DLNs to verify that the payer is the owner of this UTXO.

[0098] like Figure 7 As shown, the existing Internet of Things (IoT) Service Layer System (SLS) can be used to maintain resource trees and store data in different SLNs. For example, in oneM2M, IN-CSE maintains the resource trees of IN-AE, MN-CSE, and ASN-CSE registered to IN-CSE; and MN-CSE hosts the resource trees for registered MN-AE, ADN-AE, and ASN-CSE. However, the way the existing SLS stores data and manages the entire system inherits the following limitations:

[0099] A SLN is usually a centralized node for storing data of all other SLNs registered to the SLN (e.g. Figure 7 Scenario 1 in the example above). This centralized node may cause a single point of failure. In addition, the centralized node may be attacked by risks such as denial of service, denial of access to records, and tampering of data;

[0100] Each SLN may maintain only a portion of the data for other registered SLNs. There is no guarantee that all data access history and the data itself in the entire system will always be maintained.

[0101] In some scenarios where SLNs are deployed in an ad hoc manner, for example, for public safety and disaster management (e.g. Figure 7 In scenario 2), it may not be feasible to pre-establish trust between these SLNs, and the security of data exchange between them may be at risk; and

[0102] Existing SLS, such as oneM2M, require SLNs to establish a registration relationship before they can communicate with each other. For some scenarios, such a SL registration process may be a burden or difficult to implement. For example, SLNs (e.g., vehicles on the move) may continue to move around, so existing SL registrations will be repeated, which will cause additional overhead. Similarly, for SLNs deployed in ad hoc mode, it may not be easy to establish SL registration. DLS can be used in these scenarios without the need for SL registration, while still guaranteeing the security and trust of the SLN.

[0103] DLS brings many advantages, such as an append-only, non-repudiable distributed ledger without the need for pre-established trust. As discussed above, DLS has good potential to overcome the limitations of SLS. However, the existing SLS and DLS have been developed as two separate systems. Several issues may need to be addressed before SLS can effectively leverage the advantages of DLS. For example: how can SLS effectively interoperate with different but appropriate DLSs, how can SLNs correctly indicate their capabilities and requirements to support / use DLSs, how can SLNs effectively interact with DLNs for ledger-related operations, and how can SLS information be effectively added (e.g., data access records) to the distributed ledger.

[0104] Disclosed herein are methods and systems for intercommunication between an IoT service layer system and a distributed ledger system.

[0105] A distributed ledger intercommunication architecture is described in which a distributed ledger agent interfaces with an IoT service layer system and a distributed ledger system. A service layer node can interact with the distributed ledger agent to utilize the functionality provided by the distributed ledger system. For example, a service layer node can request the distributed ledger agent to insert some service layer information into the distributed ledger. The distributed ledger agent can support multiple service layer nodes and can also interface to multiple different distributed ledger systems.

[0106] This document discloses the following example methods for interconnecting an IoT service layer system and a distributed ledger system:

[0107] A method for a service layer node to select an appropriate distributed ledger agent to intercommunicate with a distributed ledger system;

[0108] A method for a distributed ledger agent to select an appropriate distributed ledger system for a service layer node;

[0109] A method for a distributed ledger agent to associate with a service layer node, wherein the distributed ledger agent may first register with the service layer node, the service layer node may request approval for the distributed ledger agent to use its proxy functionality, and / or the distributed ledger agent may send its transaction format or template to the service layer node;

[0110] A method for a service layer node to trigger the addition of service layer information to a distributed ledger;

[0111] A method for one service layer node to indicate a distributed ledger requirement to another service layer node;

[0112] A method for a service layer node to assemble service layer information (e.g., service layer request primitives) into transactions based on a transaction format received from a distributed ledger agent. The service layer node can send the generated transactions to the distributed ledger agent, which can add them to the distributed ledger according to the distributed ledger system specification.

[0113] a method for a service layer node to simply send service layer information to a distributed ledger agent, which can convert the service layer information into transactions and add the transactions to the distributed ledger in accordance with the distributed ledger system specification;

[0114] A method for a service layer node to query and / or retrieve transactions from a distributed ledger proxy;

[0115] A method for a service layer node to verify the state of a transaction in a distributed ledger from a distributed ledger proxy; and

[0116] A method for a service layer node to subscribe to transactions in a distributed ledger from a distributed ledger proxy.

[0117] It should be understood that the methods and systems disclosed herein are not limited to the examples provided above.

[0118] In one embodiment, a distributed ledger agent for interworking a service layer system and a distributed ledger system may be configured to receive a message from a service layer entity (e.g., a service layer node) including data to be stored at a distributed ledger node in the distributed ledger system, generate a transaction based on the data according to one or more specifications of the distributed ledger system, send information associated with the transaction to the distributed ledger node, receive an indication from the distributed ledger node that the transaction has been confirmed by the distributed ledger node, and send an indication to the service layer entity that the transaction has been confirmed by the distributed ledger node. The distributed ledger system may include multiple distributed ledger nodes. The message may include an indication to store the data at a particular node in the distributed ledger nodes.

[0119] The distributed ledger agent may also be configured to generate a mapping between data received from a service layer entity (i.e., a service layer node and / or a service layer application entity) and the transaction. The indication that the transaction has been confirmed by the distributed ledger node may include at least one of: an identifier of the transaction, an identifier of the data received from the service layer entity, and a hash value of the data received from the service layer entity. The distributed ledger agent may also be configured to send a response to the service layer entity, and prior to receiving the indication that the transaction has been confirmed, the response including an indication that the transaction is awaiting confirmation by the distributed ledger node. The distributed ledger agent may also be configured to receive another message including other data from the service layer entity, wherein the transaction is generated based on the data and the other data.

[0120] The distributed ledger agent may also be configured to receive a request from a service layer entity (i.e., a service layer node and / or a service layer application entity) to retrieve one or more transactions from a distributed ledger node, retrieve information associated with the one or more transactions from the distributed ledger, and send information associated with the one or more transactions to the service layer entity. The distributed ledger agent may also be configured to receive a request from the service layer entity to verify that the one or more transactions have been confirmed by the distributed ledger node, send a request to the distributed ledger node to determine whether the one or more transactions have been confirmed by the distributed ledger node, receive an indication from the distributed ledger node that the one or more transactions have been confirmed by the distributed ledger node, and send an indication to the service layer entity that the one or more transactions have been confirmed by the distributed ledger node. The distributed ledger agent may also be configured to receive a request from the service layer entity to receive automatic notifications about transactions at distributed ledger nodes that meet specific notification criteria.

[0121] In another embodiment, the distributed ledger agent may also be configured to receive a request from a service layer entity (i.e., a service layer node and / or a service layer application entity) to use the distributed ledger agent for one or more functions of intercommunication with a distributed ledger node of a distributed ledger system, generate a public key and a private key pair, create an account associated with the service layer entity based on at least the public key, and send an indication to the service layer entity indicating that the account has been generated.

[0122] The distributed ledger agent may also be configured to send a request to a service layer entity (i.e., a service layer node and / or a service layer application entity) requesting registration with the service layer entity, the request including an indication that the distributed ledger agent supports one or more distributed ledger nodes, and receive a response including one or more parameters from the service layer entity, the one or more parameters including: an identifier of a distributed ledger node selected from the one or more distributed ledger nodes, one or more attributes of the distributed ledger node required by the service layer entity, and security and privacy requirements of the service layer entity. The request to use one or more functions of the distributed ledger agent may include information associated with the one or more parameters. The one or more attributes of the distributed ledger node may include one or more of the following: the type of distributed ledger node, the consensus protocol associated with the distributed ledger node, the transaction fee associated with the distributed ledger node, the delay for adding a new transaction at the distributed ledger node, and the number of complete distributed ledger nodes in the distributed ledger system. The service layer entity may maintain a list of distributed ledger agents registered with the service layer entity. The distributed ledger agent may also be configured to generate a mapping between an identifier of the service layer entity and one or more of a public key, a private key, and an identifier associated with the generated account. The first service layer entity may send some information related to the added transaction to the second service layer entity (e.g., if the transaction has been successfully added to the distributed ledger, this information is an identifier of the transaction, service layer information and / or its identifier that has been included in the transaction, etc.).

[0123] In another embodiment, a first service layer entity may be configured to receive a message from a second service layer entity, the message including data to be stored on a distributed ledger node of a distributed ledger system, determine a distributed ledger agent for intercommunication between the first service layer entity and the distributed ledger node based on the data, send the data to be added to the distributed ledger node to the distributed ledger agent, receive an indication from the distributed ledger agent that a transaction has been generated, and store information associated with the transaction at the first service layer entity. The distributed ledger agent may be configured to generate a transaction according to one or more specifications of the distributed ledger system based on the data.

[0124] The distributed ledger proxy may be configured to generate a mapping between the transaction and the information associated with the first service layer entity. The first service layer entity may also be configured to store the mapping between the transaction and the information associated with the first service layer entity. The message may include an indication indicating which service layer entity is to send the information to the distributed ledger proxy. The information may include an indication indicating when the data should be added to the distributed ledger node. The transaction may include an identifier of the first service layer entity.

[0125] The following terms are provided as context for describing methods for intercommunication between IoT service layer systems and distributed ledger systems.

[0126] Distributed Ledger: A distributed append-only database maintained by and located at different Distributed Ledger Nodes (DLNs). The ledger maintained at each DLN is identical. The ledger essentially contains transactions grouped together in various structures (e.g., blockchain in the Bitcoin system).

[0127] Distributed Ledger System: A system composed of DLNs that work together but in a distributed manner to create and maintain a distributed ledger. Typically, these DLNs are connected and communicate with each other through an underlying peer-to-peer (P2P) network. For example, the Bitcoin system is a distributed ledger system (DLS).

[0128] Distributed Ledger Node: A logical node that creates and maintains a ledger. A DLN has several other DLNs as its peers. Each DLN can generate new messages to its peer DLNs according to the underlying P2P network protocol, and can also forward any received messages to its peer DLNs (except the peer DLN from which it was received). There is no assumption that DLNs trust each other. A DLN can be a "full DLN" (e.g., a DLN that maintains a full ledger) or a "light DLN" (e.g., a DLN that does not maintain a full ledger).

[0129] Transaction: The smallest unit of message transmitted between DLNs in a DLS (also called a DLS transaction). A DLN (e.g., a payer in a Bitcoin system) can publish transactions to another DLN (e.g., a payee in a Bitcoin system). Each published transaction can be sent to and forwarded by the publisher's peer DLN based on the underlying P2P protocol, and eventually, all DLNs in the DLS will receive the transaction. Since DLNs work in a distributed manner, they may need to reach a consensus on all transactions sent through the DLS (e.g., via some consensus protocol) before the transactions are verified and stored in the distributed ledger. Transaction status can be generated by a DLN, sent to a DLS (or received by a DLN from a DLS), and / or appended to a distributed ledger and confirmed by a DLS (e.g., after a consensus protocol is run at each participating DLN).

[0130] Transaction set: A structure that groups several transactions together (e.g., a block in the Bitcoin system). In some DLSs, the consensus protocol is performed on each transaction set rather than on individual transactions to improve efficiency.

[0131] Consensus Protocol: The protocol that DLN uses to reach consensus on all transactions sent through the DLS before they are verified and stored in the distributed ledger. An example of a consensus protocol is the Proof of Work (PoW) used in the Bitcoin system and other DLS built on top of the Bitcoin system.

[0132] Distributed Ledger Proxy: A logical node that can interface with both SLS and DLS. Distributed Ledger Proxy (DLP) basically supports both service layer functions and distributed ledger functions. It can be a combination of SLN and full DLN.

[0133] This article combines Figure 8 , Fig. 9 , Fig.10 and Fig.11 Four distributed ledger interoperability architecture options are described. Based on these interoperability architecture options, the overall interoperability process is Fig.12 , 13 and 14. Then, the detailed process is presented in separate figures, e.g. Fig.15 For DLP and SLN association, Fig.16 , 17 and 18 for adding service layer information to the distributed ledger, Fig. 20 Used to query / retrieve transactions from a distributed ledger, Fig.21 used to verify the status of transactions in the distributed ledger, and Fig. 22 Used to subscribe to transactions in a distributed ledger.

[0134] This article describes four example distributed ledger intercommunication options.

[0135] DLP is proposed as a new logical node between SLS and DLS to make them interoperable. DLP has an interface to SLS as SLN, and another interface to DLS as DLN. DLP can support multiple different DLSs, so it can select the appropriate DLS for SLN or SLS. DLP can be registered with SLN and can send transaction formats to SLN. Before SLN is used to store transactions in DLS, SLN may need to request approval from DLP. As part of this request, if DLP approves the request, DLP can create a DLS account for SLN. DLP receives requests from SLN and in turn performs various tasks as requested by SLN. At the same time, SLN can be connected to multiple DLPs, and the appropriate DLP can be selected for different SL information. The unique identifier of SLN at SL can be reused in SLS as the publisher or recipient identifier of the transaction.

[0136] Figure 8 An interworking architecture option 1 for SLS utilizing DLS is shown. SLS can utilize DLS to store many types of service layer information and / or summaries thereof (e.g., service layer request / response history, service layer subscription notification record, service layer registration history, service layer resource history, service layer data access record, etc.). The service layer (SL) is located above the distributed ledger layer (DLL). The distributed ledger proxy (DLP) is proposed as an interworking functional entity for connecting the service layer and the distributed ledger layer together. The DLP has two interfaces: a service layer interface to a service layer node (SLN) and a distributed ledger interface to the DLN. In this interworking option, each SLN is connected to a different DLP, so that the SLN identifier or a variant thereof (e.g., hash (SLN identifier)) can be used directly in the base DLS. The DLP can be a full DLN node that maintains a ledger or a lightweight DLN node that does not maintain a ledger.

[0137] When a SLN needs to utilize the DLS (e.g., the SLN receives and approves a new SL registration, and it wants to store that SL registration to the DLS and the distributed ledger), the following operations may be performed at the SLN and the corresponding DLP:

[0138] In Phase 1, SLN first needs to find a suitable DLP and connect to it; then, SLN sends a SL message (which contains the service layer information to be stored in the distributed ledger) or a DLS transaction to the DLP.

[0139] In phase 2, at the DLP, one or more SL messages from the SLN will be translated into a DLS transaction according to the DLS specification, unless the SLN sent to the DLP in step 1 is a DLS transaction. One approach is to simply include those original SL messages in the body of the DLS transaction. Optionally, the DLP may first compress those original SL messages, for example by removing any redundant information or parameters in the SL messages. Note that one SL message from the SLN may trigger the DLP to generate a new DLS transaction; alternatively, the DLP may buffer several SL messages and include them in one DLS transaction. The DLP may maintain a mapping between DLS transactions and original SL messages or between DLS transactions and hash values ​​of the original SL messages.

[0140] In phase 3, the DLP, like a normal DLN, sends the generated DLS transaction to the DLS. At this point, the DLP may send a quick response to the SLN to inform it that several SL messages have been assembled into the DLS transaction and that the DLS transaction has been inserted into the DLS, but it is waiting for confirmation. The response message may contain an identifier of the DLS transaction, an identifier of the SL message contained in the DLS transaction, and other metadata about the DLS transaction.

[0141] In phase 4, after the DLS transaction is confirmed within the DLS and appended to the ledger, the DLP may send another SL response or notification back to the SLN. The SL response may contain an identifier of the DLS transaction, an identifier of the original SL message that has been translated into the DLS transaction, a hash value of the original SL message that has been translated into the DLS transaction, and the like.

[0142] Fig. 9 An alternative interworking architecture option 2 for SLS leveraging DLS is shown. The difference from option 1 is that DLP1 in option 2 can support multiple SLNs. In this case, DLP1 can still use the unique identifier of the SLN (e.g., SLN1 or SLN2) as the issuer of each DLS transaction to be generated at DLP1, so DLP1 may need to manage multiple DLS users or accounts (one for each SLN). Alternatively, DLP1 can use its own identifier as the issuer of each DLS transaction and may only need to manage one DLS account. However, DLP1 may need to add the identifier of each SLN to the generated transactions, or maintain a separate mapping between the identifier of each DLS transaction and the identifier of the corresponding SLN that has issued the SL message as included in the DLS transaction.

[0143] Fig.10 Another alternative interoperability architecture option 3 for SLS utilizing DLS is shown. The difference from option 1 is that the SLN in option 3 can be connected to multiple DLPs, but each DLP can still only support one type of SLS (e.g., oneM2M, Open Interconnect Foundation, One Dimensional Internet of Things, etc.), just like option 1. Since various DLPs can support different types of DLS (e.g., public ledger, private ledger, etc.), and each DLS can use different consensus protocols and transaction semantics, the SLN can select the most suitable DLP based on its needs. For example, some highly sensitive data access records can be stored in a private ledger (e.g., DLS A in the figure), while less sensitive service layer request history can be stored in a public ledger (e.g., DLS B in the figure).

[0144] Fig.11 Option 4 of an interworking architecture for SLS utilizing DLS is shown, where a single DLP can connect to and support multiple types of DLSs. In other words, the DLP maintains multiple ledgers, and each ledger corresponds to a different DLS. For this scenario, the SLN can perform the same way as option 1, but the DLP may need to select the most suitable DLS for the SLN connected to the DLP. The selected DLS may be transparent to the SLN. Alternatively, the DLP may inform the SLN of the types of DLSs it supports; the SLN itself can then select the appropriate DLS (similar to option 3).

[0145] This article discloses a process for distributed ledger intercommunication.

[0146] The interworking between SLS and DLS focuses on how SLN can leverage the functionality provided by DLS (e.g., building an append-only, non-repudiable, and tamper-proof distributed database). This is achieved by proposing new interactions between SLN and DLP (e.g., DLP and SLN association), adding SL information to the distributed ledger, querying / retrieving transactions in the distributed ledger, verifying transaction status in the distributed ledger, and subscribing to transactions in the distributed ledger.

[0147] Fig.12 An example overall process of adding SL information to a distributed ledger after the SLN has interacted with the SL is shown. The process shown in this figure is applicable to both Option 1 and Option 2 of interworking, and the details will be discussed in other figures. Either the initiating SLN or the receiving SLN can interact with its DLP to store SL information to the distributed ledger. For ease of description, SLN1 and DLP1 are used in the following description, which can be directly applied to SLN2 and DLP2.

[0148] At step 1, SLN1 and DLP1 are associated with each other. As part of this step, DLP1 may first register with SLN1; alternatively, DLP1 may register itself with a third-party repository (e.g., a DNS-SD server), and SLN1 may discover DLP1 from the third-party repository. SLN1 may then request approval from DLP1 to utilize its capabilities to interoperate with DLS.

[0149] In step 2, SLN1 and SLN2 exchange existing SL primitives as usual.

[0150] In step 3, after completing the SL interaction between SLN1 and SLN2 in step 2, either SLN1 or SLN2 may be triggered to utilize DLS to store some SL information about step 2 or any previous SL interaction.

[0151] In step 3.1, SLN1 sends a message to DLP1. The message may contain the SL information to be stored in the DLS. Alternatively, SLN1 may directly generate a DLS transaction and send it to DLP1 (if it knows the format of the DLS transaction), which can be sent from DLP1 to SLN1 in step 1.

[0152] In step 3.2, if DLP1 receives a DLS transaction in step 3.1, it can simply forward the DLS transaction to its peer DLN. Otherwise, DLP1 buffers the received SL information and generates a DLS transaction immediately or later.

[0153] At step 3.3, after adding the DLS transaction to the DLS (and optionally verified by the peer DLN), DLP1 sends a response back to SLN1.

[0154] At step 4, SLN1 may query and retrieve any DLS transactions that have been previously added to the DLS by DLP1.

[0155] In step 5, SLN1 may verify whether a piece of SL information or DLS transaction has been successfully added to and verified by the DLS.

[0156] At step 6, SLN1 may subscribe to DLP1 to receive automatic notifications about new DLS transactions received from the DLS and meeting certain notification criteria.

[0157] Fig.13 An example overall process for SLN to add SL information to the distributed ledger is shown. The process shown in this figure is applicable to interoperability architecture option 3, and the details will be discussed in other figures. Note that Fig.13 Similar to Fig.12 , except for step 3:

[0158] In step 3, the scenario in interworking architecture option 3, SLN1 (or SLN2) is connected to or associated with multiple DLPs (e.g., DLP1 and DLP2). Before SLN1 sends SL information to a DLP (or generates a DLS transaction), it first needs to select a suitable DLP. The selection criteria may be based on: the type of SL information to be added to the DLS, the initiator (or recipient) involved in the SL information to be added to the DLS, the level of security and / or privacy requirements, latency requirements for adding a DLS transaction to the DLS, the current time, the current location, the transaction fees required for different DLSs, and / or other contextual information about SLN1 or the DLS.

[0159] Fig.14 An example overall process for SLN to add SL information to a distributed ledger is shown. The process shown in this figure is applicable to Interworking Architecture Option 4, and the details will be discussed in other figures. Note that Fig.14 Similar to Fig.12 , except for step 3.2:

[0160] In step 3.2, for the scenario in interoperability architecture option 4, DLP1 maintains multiple distributed ledgers, each for a different DLS. The request from SLN1 to add SL information to the distributed ledger may not indicate the target DLS. Therefore, DLP1 may need to select a suitable DLS for SLN1. The selection criteria may be based on: some hints from SLN1 that may be communicated in step 3.1 (e.g., the type of target DLS), the type of SL information to be added to the DLS, the level of security and / or privacy requirements from SLN1, the latency of the DLS for adding DLS transactions, and / or other contextual information about SLN1 or the DLS. Note that in Fig.14 The DLP communicating with SLN2 may be another DLP2.

[0161] Disclosed herein are methods and systems for DLP and SLN association.

[0162] The DLP can register itself with the SLN, and thus the SLN can maintain a list of registered DLPs. Other SLNs can search and retrieve this list to find a suitable DLP for use. Before utilizing the functions provided by the DLP (e.g., building an append-only, non-repudiation, and non-tamperable distributed database), the SLN may need to request approval from the DLP; during this process, the SLN can notify the DLP of any target DLS, and the DLP can send the specified transaction format to the SLN. In addition, the DLP can create a DLS account for the SLN.

[0163] Fig.15 An example process for DLP and SLN association is shown and described in detail below:

[0164] In step 1, DLP registers with SLN1. DLP can notify SLN1 of the following information:

[0165] A list of DLSs supported by DLP (including their properties). The properties of a DLS may be, for example: the name or identifier of the DLS, its type (e.g., private, public), consensus protocol (e.g., PoW), transaction fees, latency for adding new transactions, number of complete DLN nodes in the DLS, etc.; and / or

[0166] An identifier (eg, account address or public key) of the DLP that is the DLN in each DLS.

[0167] In step 2, SLN1 sends a response to DLP. SLN1 may inform DLP of the following information:

[0168] targetDLS: target DLS ID selected from the DLS list sent in step 1;

[0169] ExpectedDLSProperty: If DLP did not send a DLS list in step 1, the expected property of the target DLS; and

[0170] spRequirement: Security and privacy requirements from SLN1.

[0171] In step 3, SLN1 maintains a list of registered DLPs and a list of possible corresponding DLSs if the DLPs provided them in step 1.

[0172] In step 4, SLN1 requests DLP to approve the use of its functions to interwork with DLS. This message may include the following information (for example, if not included in step 2):

[0173] targetDLS: target DLS ID selected from the DLS list sent in step 1;

[0174] ExpectedDLSProperties: expected properties of the target DLS if DLP did not send a DLS list in step 1; and

[0175] spRequirement: Security and privacy requirements from SLN1.

[0176] In step 5, a DLS account can be created for SLN1. The DLP can first generate a private key and a public key pair for SLN1. Alternatively, the public-private key can be obtained through a third-party certification authority for distributing security keys. Then, the DLP can create a DLS account for SLN1. The identifier of the DLS account (e.g., dlsAccountID) can be the generated public key or its hash value. The DLP can maintain a mapping table between the SL identifier of SLN1 and the generated private key, public key, and dlsAccountID of SLN1 (e.g., the second row in Table 1). Using this mapping, the DLP is able to find the dlsAccountID (and its private key / public key) of any SLN based on the identifier of the SLN, and the identifier of the SLN can be given by any other SLN.

[0177] In step 6, DLP sends a response to SLN1. The message may contain the following information:

[0178] targetDLS: target DLS ID selected and / or confirmed for SLN1;

[0179] txFormat: the transaction format (e.g., transaction template) used for the target DLS;

[0180] maxTxRate: the maximum transaction rate allowed by SLN1;

[0181] slnPubicKey: the public key generated for SLN1 in step 5;

[0182] slnPrivateKey: the private key generated for SLN1 in step 5. If there is no secure communication between SLN1 and DLP, this parameter will not be included in step 6; and

[0183] dlsAccountID: The identifier of the DLS account generated for SLN1 in step 5.

[0184] In step 7 , SLN2 discovers DLPs from SLN1 . The discovery criteria from SLN2 may include the type of DLS supported, the type of consensus protocol, etc. SLN1 searches the list of registered DLPs created and maintained in step 3 .

[0185] At step 8, SLN1 sends a response to SLN2. The response may contain a list of discovered DLPs, including their addresses and optionally other information (eg, a list of DLSs supported by each discovered DLP).

[0186] Step 9 may be similar to step 4.

[0187] Step 10 may be similar to step 5.

[0188] Step 11 may be similar to step 6.

[0189] Table 1: DLS accounts for SLN

[0190]

[0191] Disclosed herein are methods and systems for adding service layer information to a distributed ledger.

[0192] The SLN, as an initiator or receiver, may send SL information (e.g., service layer request primitives) to the DLP, which may translate the SL information into DLS transactions and add the DLS transactions to the distributed ledger according to the DLS specification. The DLP may maintain a mapping between the SL information and the corresponding DLS transactions, and may send the mapping to the SLN. Additionally or alternatively, the SLN may assemble the SL information into a DLS transaction based on a transaction format received from the DLP. The SLN may then send the generated transaction to the DLP, which may add it to the distributed ledger according to the DLS specification.

[0193] Fig.16 An example process for SLN to add SL information to DLS is shown. In this scenario, SLN1 and SLN2 exchange SL primitives. SLN2 may then decide to send some SL information to DLP. DLP may translate the received SL information into DLS transactions and add it to DLS. Note that SLN1 and SLN2 may not have any established trust or registration, for example, if both are deployed in ad hoc mode or both belong to different service providers. By utilizing this process to store the exchanged SL information to a distributed ledger, previous interactions between them can neither be denied nor forged.

[0194] In step 1, SLN1 sends a SL request primitive to SLN2. The request may include a "DL indication" to instruct SLN2 to add the request primitive (and / or the response message in step 2) to the DLS. As an example, the "DL indication" may include the following parameters:

[0195] dlAction: Indicates whether SLN1 or SLN2 needs to trigger adding SL information to DLS. For example:

[0196] dlAction=0: Neither SLN1 nor SLN2 needs to utilize DLS. In this case, no other parameters may be required.

[0197] dlAction=1: SLN1 is responsible for utilizing DLS. In this case, step 1 may not require targetDLP and typeOfTargetDLS.

[0198] dlAction=2: SLN2 is responsible for utilizing DLS.

[0199] dlScope: Indicates which SL information is to be added to the DLS. For example,

[0200] dlScope=1: Add the entire request primitive to the DLS.

[0201] dlScope=2: Add the entire response primitive to the DLS.

[0202] dlScope=3: Add both request and response primitives to the DLS.

[0203] dlScope=4: Add the header of the request primitive to the DLS.

[0204] dlScope=5: Add the header of the response primitive to DLS.

[0205] dlScope=6: Add headers of both request and response primitives to DLS.

[0206] dlScope=7: The next request primitive from SLN2 to another SLN is added to the DLS as indicated by dlScopeNode.

[0207] dlScope=8: The next request primitive from another SLN to SLN2 is added to the DLS as indicated by dlScopeNode.

[0208] dlScopeNode: indicates another SLN.

[0209] dlsAccountID: DLS account ID of SLN1.

[0210] targetDLP: Indicates the address of the target DLP. If this parameter is included, typeOfTargetDLS may not be required.

[0211] typeOfTargetDLS: indicates the type of target DLS of SLN2 that SLN1 requires or prefers to utilize. SLN2 can select an appropriate DLP based on this parameter.

[0212] In step 2, SLN2 receives the SL request primitive and processes the included "DL indication". If dlAction=2, SLN2 can determine the final targetDLP (for example, based on typeOfTargetDLS included in step 1). SLN2 generates a SL response primitive and sends it to SLN1. The response primitive may contain the final targetDLP and dlScope selected by SLN2, a hash value of the SL information to be included in the DLS transaction, and the dlsAccountID of SLN2. Alternatively, if dlAction is not equal to 1, SLN2 may send this response primitive to SLN1 after step 8. In this case, the identifier of the corresponding DLS transaction may be included in this response primitive (if a DLS transaction was sent through step 7).

[0213] In step 3, SLN2 sends specific SL information to DLP. The SL information included in this step may be determined based on the dlScope included in step 1; otherwise, SLN2 may be pre-configured by the application or provided with "dlScope". Additionally or alternatively, when SLN1 registers itself with SLN2, "dlScope" may be provided to SLN2. In this step, SLN2 may include the following parameters:

[0214] dlStart: indicates when the DLP should start adding SL information to the DLS. For example, dlStart = atOnce: start immediately.

[0215] dlStart=timePeriod: Start after the time period contained in dlStart.

[0216] dlStart=numOfSLInfo: start after receiving numOfSLInfo pieces of SL information from SLN2.

[0217] slInfoID: A unique identifier for the entire SL information contained in this step.

[0218] slInfoHashFlag: indicates that DLP needs to compress the received SL information (eg, using a hash function), for example, when slInfoHashFlag=TRUE.

[0219] recipientID: DLS account ID of the SLN that is the recipient of the DLS transaction generated in step 4. The recipient can be SLN1 or another SLN.

[0220] In step 4, the DLP receives SL information from SLN2. If dlStart=atOnce, if the DLP supports multiple DLSs, the DLP may first select a suitable DLS based on the information it exchanged with SLN2 during "DLP and SLN Association", and then generate a DLS transaction according to the transaction format used in the selected DLS and distribute it using SLN2's private key (assuming that SLN2 is the issuer of this DLS transaction). For example, the entire SL information received in step 3 may be included as the payload of the generated DLS transaction. If dlStart is not "atOnce", the DLP may buffer the received SL information and start a timer (or counter) with the value set to that contained in dlStart. The DLP may not generate a DLS transaction until the timer expires or the counter (which may be increased by 1 each time the DLP receives SL information from SLN2) exceeds numOfSLInfo. Optionally, the DLP may hash or compress the SL information into a value of shorter size, and may include only the hashed value in the generated DLS transaction (e.g., when the slInfoHashFlag contained in step 3 has a value of TRUE). Examples of transaction instances are in Fig.17 As shown in , the issuer of this transaction is SLN2 and the recipient is SLN1. The proposed transaction format may have the following fields:

[0221] issuerID: The dlsAccountID of the issuer. In this example, the issuer is SLN2.

[0222] recipientID: The DLS account ID of the recipient received from step 3. In this example, the recipient is SLN1.

[0223] otherFields: Other fields or parameters that are specific to DLS or that may be used for future extensions.

[0224] txTransaction: Take the transaction payload containing SL information as follows:

[0225] txPurpose: Indicates the purpose of this transaction (e.g., "intercommunication with SLS1").

[0226] slInfoType: Indicates the type of SL information contained in this transaction. It can be "raw (unhashed)" or "hashed".

[0227] numOfSLInfo: indicates the number of SL information included in the transaction.

[0228] slInfoSize: indicates the size of SL information.

[0229] slInfoContent: indicates the content of the SL information, which can be the original SL information or the hash value of the original SL information, depending on the value of slInfoType.

[0230] Signature: A hash of the transaction header plus the transaction payload for the publisher's private key, which is created by DLP during "DLP and SLN association".

[0231] In step 5, the DLP sends the generated DLS transaction to its peer DLN according to the DLS specification.

[0232] When the peer DLN receives the transaction, it can verify that the transaction is valid. As part of this process, it can wait for or contact another DLP serving SLN1 (referred to as DLP4SLN1) to further verify that the SL information in the transaction is really intended for SLN1. In this way, DLP4SLN1 can extract the included information from the transaction and send it to SLN1 for verification.

[0233] In step 6, DLP creates and maintains a mapping between the generated DLS transaction and the SL information or its hashed value. Note that step 6 can occur before step 5 but after step 4, or as part of step 4.

[0234] In step 7, the DLP sends a response back to SLN2. The response message may include, for example, an identifier of the DLS transaction generated in step 4 (if any), a hash value of each SL information included in the DLS transaction, and / or an slInfoID of each SL information included in the DLS transaction.

[0235] At step 8, SLN2 receives a response from the DLP and stores the information contained in the response (eg, to maintain a mapping between the SL information and the corresponding DLS transactions).

[0236] In step 9, at some later time, the DLS transaction sent in step 5 is successfully added to a new transaction set (e.g., a block in the Ethereum system) that has been verified by all DLNs in the DLS.

[0237] In step 10, DLP verifies the transaction set according to the consensus protocol used in DLS, and updates the status information of the DLS transaction sent in step 5. For example, its status may be changed to "confirmed" and the identifier of the transaction set may be added to it.

[0238] exist Fig.16 In the example, it should be understood that step 3 from SLN2 to DLP can also be from SLN1 to DLP (for example, if dlAction=1 in step 1, it means that SLN1 should be responsible for adding SL information to the distributed ledger). Then, step 7 can be from DLP to SLN1. It should also be understood that steps 1 and 2 are not mandatory. Some local events at SLN2 (for example, a new notification is sent to a subscriber or notification target, SLN2 just forwards a SL message sent from another SLN3 to another SLN4, etc.) can trigger SLN2 to start step 3 to communicate with DLP.

[0239] Fig.18 Shows the combination Fig.16 An example alternative process of the described method. In this alternative process, SLN2 (or SLN1) knows the format of the DLS transaction and generates a DLS transaction accordingly for the SL information to be stored in the distributed ledger. Therefore, what SLN2 (or SLN1) sends to the DLP is not the plain SL information, but the DLS transaction.

[0240] Step 1 can be done with Fig.16 Same as step 1 in .

[0241] Step 2 can be done with Fig.16 Same as step 2 in . However, Fig.18 Step 2 in may occur after step 3; in this case, the identifier of the generated DLS transaction may be included in the response primitive to SLN1.

[0242] In step 3, SLN2 generates a DLS transaction according to the transaction format obtained from DLP during "DLP and SLN association".

[0243] Step 4 can be done with Fig.16 Same as step 6 in .

[0244] In step 5, SLN2 sends the DLS transaction to DLP.

[0245] In step 6, the DLP forwards the DLS transaction to its peer DLN in the DLS.

[0246] In step 7, DLP sends a response to SLN2.

[0247] Step 8 can be done with Fig.16 Same as step 9 in .

[0248] In step 9, the DLP notifies SLN2 that the DLS transaction has been successfully added to the DLS and has been confirmed. In this message, the DLP may include the transaction set information received from the peer DLN in step 8.

[0249] exist Fig.18 In the figure, it should be understood that step 3 from SLN2 to DLP can also be from SLN1 to DLP (for example, if dlAction=1 in step 1, it means that SLN1 should be responsible for adding SL information to the distributed ledger). SLN1 can then process steps 3-9 as shown for SLN2 in the figure. In addition, steps 1 and 2 may not be mandatory. Certain local events at SLN2 (for example, sending a new notification to a subscriber or notification target) can trigger SLN2 to start step 3 to communicate with DLP.

[0250] Figure 19 shows another alternative process for adding service layer information to a distributed ledger. In this example, SLN1 and SLN2 are deployed in ad hoc mode, but they do not have a registration relationship. SLN1 and SLN2 utilize DLS to store their SL primitives, and each can be associated with a DLP (e.g., DLP1 for SLN1 and DLP2 for SLN2). In other words, the initiator SLN1 first adds the SL request primitive to the DLS via DLP1, and then it sends the SL request primitive to the recipient SLN2. Similarly, SLN2 may also need to add the SL response primitive to the DLS via DLP2, and then it sends the SL response primitive to SLN1. Note that DLP1 and DLP2 are two logical entities, and they can be the same DLP. The following example steps may be required:

[0251] In step 1, SLN1 prepares a SL request primitive.

[0252] In step 2, SLN1 sends the SL request primitive to DLP1. Alternatively, SLN1 may assemble the SL request primitive into a DLS transaction and send the DLS transaction to DLP1.

[0253] In step 3, DLP1 receives the message from step 2 and adds the corresponding SL information to DLS.

[0254] In step 4, DLP1 sends the DLS transaction ID to SLN1.

[0255] In step 5, after receiving the response from DLP1 and knowing that the SL request primitive has been successfully added to DLS, SLN1 sends the SL request primitive to SLN2 based on the SL protocol. In this step, SLN1 also attaches the DLS transaction ID1 from step 4.

[0256] At step 6, after receiving the SL request primitive from SLN1, SLN2 contacts DLP2 to verify whether the transaction with DLS transaction ID1 has been previously added to the distributed ledger.

[0257] In step 7, DLP2 sends a response to SLN2.

[0258] At step 8, if the transaction with DLS transaction ID 1 has been added to the distributed ledger as indicated in step 7, SLN 2 prepares a SL response primitive.

[0259] At step 9, SLN2 sends the SL response primitive to DLP2. Alternatively, SLN2 may assemble the SL response primitive into a DLS transaction and send the DLS transaction to DLP2.

[0260] In step 10, DLP2 receives the message from step 9 and adds the corresponding SL information to DLS.

[0261] In step 11, DLP2 sends the DLS transaction ID to SLN2.

[0262] In step 12, after receiving the response from DLP2 and knowing that the SL response primitive has been successfully added to DLS, SLN2 sends the SL response primitive to SLN1 based on the SL protocol. SLN2 can also attach the DLS transaction ID2 from step 11 in this step.

[0263] At step 13, after receiving the SL response primitive from SLN2, SLN1 contacts DLP1 to verify whether the transaction with DLS transaction ID2 has been previously added to the distributed ledger.

[0264] In step 14, DLP1 sends a response to SLN1.

[0265] At step 15, if the transaction with DLS transaction ID 2 has been added to the distributed ledger as indicated at step 14, SLN1 may additionally send a confirmation message to SLN2.

[0266] Disclosed herein are methods and systems for querying and / or retrieving transactions from a distributed ledger.

[0267] The SLN may send transaction filters to the DLP to query and possibly retrieve transactions in the distributed ledger. In response, the DLP may send a list of found transactions (e.g., their identifiers, their contents, or both) to the SLN. For example, after a receiving SLN requests the DLP to add SL information to the distributed ledger, the corresponding initiating SLN may use the transaction identifier (obtained from the notification of the initiating SLN) as a filter to retrieve the transaction content from the same DLP, for example, to verify whether the transaction contains the original SL information.

[0268] Fig. 20 A process for SLN to query / retrieve transactions from the DLP maintaining the distributed ledger is shown.

[0269] In step 1, SLN sends a query request to DLP. The request may contain a transaction filter (e.g., txFilter). txFilter may contain one or more transaction attributes (e.g., creation time, transaction identifier, hash value of SL information already included in the DLS transaction, etc.)

[0270] In step 2, the DLP discovers matching DLS transactions based on the txFilter included in step 1. The DLP may return identifiers of the discovered transactions or the content of each discovered transaction to the SLN.

[0271] In step 3, if step 2 only contains an identifier of the discovered transaction, the SLN may send the identifier to the DLP for retrieval of the transaction content.

[0272] In step 4, the DLP sends the transaction content to the SLN.

[0273] Disclosed herein are methods and systems for verifying the status of transactions in a distributed ledger.

[0274] The SLN may request the DLP to check or verify the current state of a DLS transaction that was previously created to contain SL information. The SLN may provide certain transaction attributes (e.g., a transaction identifier) ​​to the DLP so that the DLP can locate the correct transaction.

[0275] For example, after the receiving SLN requests the DLP to add the SL information to the distributed ledger, the corresponding initiating SLN can send the transaction identifier to the DLP to check the current transaction status.

[0276] In another example, if both SLNs (SLN1 and SLN2) are deployed in ad hoc mode or belong to different service providers, they may not have any service layer registration relationship. In this case, after both perform SL interaction, SLN1 (or SLN2) can use Fig.16 , to add its SL interaction information to the distributed ledger. SLN2 (or SLN1) can then use Fig.21 to verify that its previous interaction with SLN1 had indeed been added to the distributed ledger.

[0277] Fig.21 An example process for the SLN to verify whether a DLS transaction and / or a piece of SL information has been successfully added to and confirmed by the DLS is shown.

[0278] In step 1, SLN sends a message to DLP to verify the status of a DLS transaction or a SL message. The status can be, for example: buffered but not yet added to DLS, added but not yet confirmed by DLS, confirmed by DLS, etc. This message can contain the following parameters:

[0279] dlsTxID: The identifier of a DLS transaction, which can be generated by the SLN, DLP or other SLN / DLP. This parameter can contain a list of DLS transaction identifiers.

[0280] slInfoID: previously obtained from SLN (not necessarily Fig.21 same SLN on the Fig.21 The parameter specifies the identifier of a SL message (e.g., a SL request message) that is sent to a SL message server (the same SLN on the SLN). This parameter may contain a list of SL message identifiers.

[0281] slInfoHash: previously obtained from SLN (not necessarily Fig.21 same SLN on the Fig.21 The parameter specifies the hash value of a SL message (e.g., a SL request message) for the same SLN on the same SLN. This parameter may contain a list of SL message hash values.

[0282] previousStatus: The status of a DLS transaction or a piece of SL information that the SLN knows about and wants to verify. This parameter may be optional.

[0283] dlsAccountIDForIssuer: The DLS account ID of the issuer.

[0284] dlsAccountIDForRecipient: The DLS account ID of the recipient.

[0285] In step 2, the DLP searches the corresponding distributed ledger maintained locally or searches for a mapping between the maintained SL information and the corresponding DLS transaction according to the parameters included in step 1. The DLP finds the current status of the corresponding DLS transaction or SL information, as indicated in step 1. Then, if previousStatus has been included in step 1, the DLP sends the current status to the SLN or only sends the verification result (e.g., TRUE or FALSE) to the SLN.

[0286] Disclosed herein are methods and systems for subscribing to distributed correspondence transactions.

[0287] SLN can subscribe to DLP with the intention of receiving future automatic notifications from DLP for certain transaction-related events (e.g., when a new DLS transaction containing SL information is simply added to DLS). When the desired event occurs, DLP can send a notification to SLN. The notification can contain an identifier or the entire content of the DLS transaction related to the event.

[0288] For example, if two SLNs (SLN1 and SLN2) are deployed in ad hoc mode or belong to different service providers, they may not have any service layer registration relationship. In this case, after both perform SL interaction, SLN1 (or SLN2) can use Fig.16 , to add its SL interaction information to the distributed ledger. Then, SLN2 (or SLN1) can use Fig. 22 , to subscribe to any DLS transactions added by SLN1 (or SLN2). Then, when the DLP serving SLN2 receives the DLS transactions added by SLN1, the DLP can send an automatic notification to SLN2.

[0289] Fig. 22 A method is shown for a SLN to subscribe to a DLP to receive automatic notifications when new DLS transactions are generated, added and / or confirmed to the DLS.

[0290] In step 1, SLN sends a subscription request to DLP, which notifies DLP of notification conditions via parameter txCriteria. txCriteria can be based on, for example: the state of the DLS transaction (e.g., generated, added and / or confirmed), the publisher of the DLS transaction (e.g., from a specific SLN or DLP), the generation time of the DLS transaction, the size of the DLS transaction, the content type of the DLS transaction (e.g., SL request primitive, about SL response primitive, specific type of SL request / response primitive, etc.), and / or other DLS transaction attributes.

[0291] In step 2, DLP processes the subscription request and sends a response to SLN.

[0292] In step 3, a new transaction satisfying txCriteria has been generated (or received) by the DLP, added to the DLS by the DLP or other DLPs, and / or confirmed to the DLS.

[0293] In step 4, DLP sends a notification to SLN. The notification may contain the identifier or the entire content of the DLS transaction that satisfies txCriteria.

[0294] In step 5, the SLN sends a response to the DLP.

[0295] The interaction between SLN and DLP disclosed in this article can be implemented in the oneM2M service layer. Therefore, some new oneM2M resources, new oneM2M attributes, new oneM2M request parameters, new oneM2M response parameters and new oneM2MRESTful operations are proposed. In addition, the DLP functions involved in interacting with SLN can be implemented as oneM2M RESTful operations. For example, the oneM2M CSE (or even the AE) can use the process described in this article to create a DLS transaction at the DLP. In this case, the DLP maintains <dlstx>resources and acts as oneM2M managed CSE.

[0296] Based on the disclosed method and system, the CSE can store any oneM2M resource (e.g., <request>Resources, events regarding AE or CSE registration, and existing <subscription>The CSE may assemble the SL information in the DLS transaction (such as notification events related to resources, etc.) into a DLS transaction and send it to the DLP, or it may simply send the SL information to the DLP, where the DLS transaction will be generated based on the SL information. The DLP then helps add the DLS transaction to the distributed ledger. In both cases, the CSE may need to record the DLS transaction information in the original oneM2M resource, for example, using the new attributes proposed in Table 2.

[0297] For example, oneM2M will <request>Specified as a resource type, it can only be implicitly created by the receiving CSE due to a request from the initiating CSE that includes a response type parameter in the request message and where the response type parameter is set to "nonBlockingReqeustSynch" or "nonBlockingRequestAsynch". The receiving CSE can use DLP to <request>Resources are stored in a distributed ledger.

[0298] Table 2: New common attributes

[0299]

[0300]

[0301] In one example, the initiator CSE may include a "DL indication" in the oneM2M request primitive to inform the recipient CSE whether and how to add the SL information included in the request primitive to the distributed ledger. Accordingly, several new oneM2M request parameters are proposed, as shown in Table 3. These new request parameters can also be used as a oneM2M <request>New properties of resource types introduced.

[0302] Table 3: Summary of new request primitive parameters

[0303]

[0304]

[0305] In one example, the receiving CSE may include some final decision about "DL Indication" in the oneM2M response primitive to inform the initiating CSE whether and how to add the SL information included in the request and / or response primitives to the distributed ledger. Accordingly, several new oneM2M response parameters are proposed and described in Table 4, which the receiving CSE may include in the response primitive to send to the initiating CSE.

[0306] Table 4: Summary of new response primitive parameters

[0307]

[0308] dlsTxTemplate represents the transaction format used in DLS. A DLP can create a dlsTxTemplate at a CSE, which can be discovered and retrieved by other AEs / CSEs if other AEs / CSEs need to create a DLS transaction for specific SL information. Note that a DLP can be either a CSE or an AE. The structure of the dlsTxTemplate resource is in Fig.23 In the description. <dlstxtemplate>Resources can contain subresources as specified in Table 5.

[0309] Table 5: <dlstxtemplate>Subresources of a resource

[0310]

[0311] <dlstxtemplate>Resources can contain the attributes specified in Table 6.

[0312] Table 6: <dlstxtemplate>Resource properties

[0313]

[0314] Fig.24 Shows the operation <dlstxtemplate>Resources (e.g., create / retrieve / update / delete <dlstxtemplate>The initiator may be a CSE or an AE, and the receiver may be a CSE. Detailed descriptions are given in Table 7, Table 8, Table 9, and Table 10, respectively.

[0315] Fig.24 The process shown can be used to create <dlstxtemplate>Resources, as described in Table 7.

[0316] Table 7: <dlstxtemplate>create

[0317]

[0318] Fig.24 The process shown in can be used to retrieve existing <dlstxtemplate>The attributes of the resource are as described in Table 8.

[0319] Table 8: <dlstxtemplate>Search

[0320]

[0321] Fig.24 The process shown in can be used to update an existing <dlstxtemplate>Resources. As described in Table 9.

[0322] Table 9: <dlstxtemplate>renew

[0323]

[0324] Fig.24 The procedure shown in can be used to delete an existing <dlstxtemplate>Resources, as described in Table 10.

[0325] Table 10: <dlstxtemplate>delete

[0326]

[0327] dlsTx represents a DLS transaction that can be generated at a CSE or DLP. The structure of the dlsTx resource is Fig.25 Shown in. <dlstx>A resource may contain subresources as specified in Table 11.

[0328] Table 11: <dlstx>Subresources of a resource

[0329]

[0330] <dlstx>Resources can contain the attributes specified in Table 12.

[0331] Table 12: <dlstx>Resource properties

[0332]

[0333] Fig.26 Shows the operation <dlstx>Resources (e.g., create / retrieve / update / delete <dlstx>The initiator may be a CSE or an AE, and the receiver may be a CSE. Detailed descriptions are given in Table 13, Table 14, Table 15, and Table 16, respectively.

[0334] Fig.26 The process shown in can be used to create <dlstx>Resources, as described in Table 13.

[0335] Table 13: <dlstx>create

[0336]

[0337] Fig.26 The process shown in can be used to retrieve existing <dlstx>The attributes of the resource are as described in Table 14.

[0338] Table 14: <dlstx>Search

[0339]

[0340] Fig.26 The process shown can be used to update an existing <dlstx>Resources, as described in Table 15.

[0341] Table 15: <dlstx>renew

[0342]

[0343] Fig.26 The process shown can be used to delete an existing <dlstx>Resources, as described in Table 16.

[0344] Table 16: <dlstx>delete

[0345]

[0346] Fig. 27 An example user interface for configuring a DLP and displaying information about the configured DLP is shown. For example, the user interface may be used to configure addresses including a port number for the DLP; configure the type of SL information to be stored in the DLS; display addresses including a port number for the DLP; and / or display the consensus protocol used by the DLP

[0347] Fig.28 An example user interface for a DLP is shown that can display the following information: the address of the associated SLN; the last time the SLN sent SL information or a DLS transaction to the DLP; and / or ledger-related information (e.g., the number of DLS transactions generated from or for the SLN, the time elapsed since the last set of transactions, etc.).

[0348] implement Figure 1-22 Any entity of the steps shown in , 24 and 26, such as a service layer, a service layer device, a service layer application, an application entity, etc., can be a logical entity, which can be implemented in the form of software (i.e., computer executable instructions), which is stored in the memory of the following items and executed on the processor of the following items: a device or computer system configured for wireless and / or network communication, such as Fig.29C or Fig.29D Those shown. That is, Figure 1 , 3 , 6-18, 20 and 21 can be implemented in the form of software (ie, computer executable instructions) stored in a device (such as Fig.29C or Fig.29D The computer executable instructions, when executed by the processor of the device, execute Figure 1 , 3 , 6-18, 20 and 21. It should also be understood that Figure 1 , 3 Any of the sending and receiving steps shown in , 6-18, 20 and 21 can be performed by the communication circuitry of the device / entity under the control of the device's processor and computer-executable instructions (e.g., software) executed by it.

[0349] Fig.29A is a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or World Wide Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. In general, M2M technology provides building blocks for IoT / WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or means of IoT / WoT and an IoT / WoT service layer, etc. Figure 1-22 Any entity shown in any of 24 and 26 may include a network device of a communication system, such as Figures 29A-29D Those shown in .

[0350] The service layer may be a functional layer within a network service architecture. The service layer is typically located above the application protocol layer (e.g., HTTP, CoAP, or MQTT) and provides value-added services to client applications. The service layer also provides an interface to the core network of the lower resource layers (e.g., the control layer and the transport / access layer). The service layer supports multiple categories of (service) capabilities or functions, including service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standard bodies, such as oneM2M, have been developing the M2M service layer to address the challenges associated with integrating M2M-type devices and applications into deployments such as the Internet / Web, cellular, enterprise, and home networks. The M2M service layer may provide access to a combination or collection of the above capabilities or functions supported by the service layer to applications and / or various devices, and the service layer may be referred to as a CSE or SCL. Some examples include, but are not limited to, security, charging, data management, device management, discovery, provisioning, and connection management, which may be commonly used by various applications. These capabilities or functions may be available to various applications via APIs that utilize message formats, resource structures, and resource representations defined by the M2M service layer. CSE or SCL is a functional entity that may be implemented by hardware and / or software, and provides (service) capabilities or functions that are exposed to various applications and / or devices (ie, functional interfaces between these functional entities) so that they use such capabilities or functions.

[0351] like Fig.29A As shown, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN, cellular, etc.) or a network of heterogeneous networks. For example, the communication network 12 may include multiple access networks that provide content such as voice, data, video, messaging, broadcasting, etc. to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), etc. In addition, the communication network 12 may include other networks, such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a converged personal network, a satellite network, a home network, or an enterprise network.

[0352] like Fig.29A As shown, the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, while the field domain refers to the regional network, usually behind the M2M gateway. Both the field domain and the infrastructure domain may include various different network devices of the network (e.g., servers, gateways, devices, etc.). For example, the field domain may include an M2M gateway 14 and a device 18. It will be understood that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M / IoT / WoT communication system 10 as desired. Each of the M2M gateway device 14 and the M2M device 18 is configured to send and receive signals via the communication network 12 or a direct radio link using a communication circuit.

[0353] The M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate through an operator network such as the communication network 12 or a direct radio link. For example, the M2M device 18 can collect data and send the data to the M2M application 20 or other M2M devices 18 via the communication network 12 or a direct radio link. The M2M device 18 can also receive data from the M2M application 20 or the M2M device 18. In addition, data and signals can be sent to and received from the M2M application 20 via the M2M service layer 22, as described below. The M2M device 18 and the gateway 14 can communicate via various networks, including, for example, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio links, and telephone lines. Example M2M devices include, but are not limited to, tablets, smartphones, medical devices, temperature and weather monitors, connected cars, smart meters, gaming consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart sockets.

[0354] refer to Fig.29B , the M2M service layer 22 shown in the field provides services for the M2M applications 20, the M2M gateway 14, the M2M devices 18, and the communication network 12. It will be understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as needed. The M2M service layer 22 can be implemented by one or more network devices of the network, which may include servers, computers, devices, etc. The M2M service layer 22 provides service capabilities applicable to the M2M devices 18, the M2M gateway 14, and the M2M applications 20. The functions of the M2M service layer 22 can be implemented in a variety of ways, such as as a network server, in a cellular core network, in the cloud, etc.

[0355] Similar to the M2M service layer 22 shown, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for the M2M applications 20' and the basic communication network 12 in the infrastructure domain. The M2M service layer 22' also provides services for the M2M gateways 14 and the M2M devices 18 in the field domain. It will be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateways, and M2M devices. The M2M service layer 22' can interact with the service layer through different service providers. The M2M service layer 22' can be implemented by one or more network devices of the network, which may include servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.), etc.

[0356] Also refer to Fig.29B , the M2M service layers 22 and 22' provide a core set of service delivery capabilities that can be leveraged by a wide variety of applications and vertical industries. These service capabilities enable the M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service / device discovery, etc. In essence, these service capabilities relieve the application from the burden of implementing these functions, thereby simplifying application development and reducing costs and time to market. The service layers 22 and 22' also enable the M2M applications 20 and 20' to communicate over various networks such as the network 12 that are connected to the services provided by the service layers 22 and 22'.

[0357] The M2M applications 20 and 20' may include applications in various industries, such as, but not limited to, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As described above, the M2M service layer running across devices, gateways, servers, and other network devices of the system supports functions such as data collection, device management, security, billing, location tracking / geo-protection, device / service discovery, and legacy system integration, and provides these functions as services to the M2M applications 20 and 20'.

[0358] Typically, the service layer (e.g. Fig.29B The service layer 22 and 22' shown in the figure defines a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying network interfaces. Both the ETSIM2M and oneM2M architectures define a service layer. The service layer of ETSIM2M is called the service capability layer (SCL). The SCL can be implemented in various different nodes of the ETSIM2M architecture. For example, an instance of the service layer can be implemented in an M2M device (referred to herein as a device SCL (DSCL)), a gateway (referred to herein as a gateway SCL (GSCL)) and / or a network node (referred to herein as a network SCL (NSCL)). The oneM2M service layer supports a set of common service functions (CSFs) (i.e., service capabilities). An instance of a set of one or more specific types of CSFs is called a public service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, dedicated nodes). The Third Generation Partnership Project (3GPP) also defines an architecture for machine type communication (MTC). In this architecture, the service layer and the service capabilities it provides are implemented as part of a service capability server (SCS). Whether implemented in the DSCL, GSCL or NSCL of the ETSIM2M architecture, or in the service capability server (SCS) of the 3GPP MTC architecture, or in the CSF or CSE of the oneM2M architecture, or in some other node of the network, an instance of the service layer can be implemented as a logical entity (e.g., software, computer executable instructions, etc.) executed on one or more independent nodes (including servers, computers and other computing devices or nodes) in the network, or executed as part of one or more existing nodes. As an example, an instance of the service layer or its components can be implemented in the form of software, which is implemented in a manner having the following description Fig.29C or Fig.29D The general architecture shown is run on a network device (e.g., server, computer, gateway, appliance, etc.).

[0359] Furthermore, the methods and functions described herein may be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access services.

[0360] From a deployment perspective, the service layer can be deployed on various types of network nodes, including servers, gateways, and devices shown in the various figures herein. Any such node, server, gateway, device, apparatus, or other logical entity of a communication network that implements service layer functionality or otherwise incorporates an instance of a service layer may be referred to herein as a service layer entity.

[0361] Fig.29C Such as Figure 1-22 , 24 and 26, such as one of the entities shown in FIG. 24, which can operate as a network device / software architecture. Fig.29A and 29B The M2M server, gateway, device or other network device in the M2M network shown. Fig.29D As shown, the network device 30 may include a processor 32, non-removable memory 44, removable memory 46, a speaker / microphone 38, a keypad 40, a display, a touchpad and / or an indicator 42, a power supply 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The network device 30 may also include communication circuits, such as a transceiver 34 and a transmit / receive element 36. It will be understood that the network device 30 may include any sub-combination of the foregoing elements while remaining consistent with the embodiment. The network device may be a device that implements a method for intercommunication between a service layer system and a distributed ledger system, such as with respect to Figure 1-22 , 24 and 26 illustrate and describe the method operations.

[0362] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. In general, the processor 32 may execute computer executable instructions stored in a memory (e.g., memory 44 and / or memory 46) of the network device to perform various required functions of the network device. For example, the processor 32 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the network device 30 to operate in a wireless or wired environment. The processor 32 may run an application layer program (e.g., a browser) and / or a radio access layer (RAN) program and / or other communication programs. The processor 32 may also perform security operations such as authentication, security key protocols, and / or encryption operations, for example, at the access layer and / or application layer.

[0363] like Fig.29C As shown, the processor 32 is coupled to its communication circuit (e.g., transceiver 34 and transmit / receive element 36). By executing computer executable instructions, the processor 32 can control the communication circuit so that the network device 30 communicates with other network devices via the network to which it is connected. In particular, the processor 32 can control the communication circuit to execute the present invention (e.g., in Figure 1-22 , 24 and 26) and the sending and receiving steps described in the claims. Although Fig.29C The processor 32 and transceiver 34 are depicted as separate components, but it will be understood that the processor 32 and transceiver 34 may be integrated together in an electronic package or chip.

[0364] The send / receive element 36 can be configured to send signals to other network devices, or receive signals from other network devices, and other network devices include M2M servers, gateways, and equipment. For example, in an embodiment, the send / receive element 36 can be an antenna configured to send and / or receive RF signals. The send / receive element 36 can support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an embodiment, the send / receive element 36 can be a transmitter / detector configured to send and / or receive, for example, IR, UV or visible light signals. In another embodiment, the send / receive element 36 can be configured to send and receive both RF and optical signals. It will be understood that the send / receive element 36 can be configured to send and / or receive any combination of wireless or wired signals.

[0365] In addition, although the transmit / receive element 36 is Fig.29C Although shown as a single element in the figure, the network device 30 may include any number of transmit / receive elements 36. More specifically, the network device 30 may employ MIMO technology. Therefore, in an embodiment, the network device 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0366] The transceiver 34 may be configured to modulate signals to be transmitted by the transmit / receive element 36 and to demodulate signals received by the transmit / receive element 36. As described above, the network device 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the network device 30 to communicate via multiple RATs such as UTRA and IEEE 802.11.

[0367] The processor 32 may access information from and store data in any type of appropriate memory, such as the non-removable memory 44 and / or the removable memory 46. For example, the processor 32 may store a session context in its memory, as described above. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 32 may access information from and store data in a memory that is not physically located on the network device 30 (e.g., on a server or home computer). The processor 32 may be configured to control a lighting pattern, image, or color on the display or indicator 42 to reflect the state of the device or to configure the device, particularly an underlying network, application, or other service that communicates with the network device. In one embodiment, the display / indicator 42 may present Fig. 27 and 28 A graphical user interface is shown in and described herein.

[0368] Processor 32 may receive power from power source 48 and may be configured to distribute and / or control power to other components in network device 30. Power source 48 may be any suitable device for powering network device 30. For example, power source 48 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0369] Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (e.g., longitude and latitude) regarding the current location of network device 30. It will be appreciated that network device 30 may obtain location information by any suitable location determination method while remaining consistent with an embodiment.

[0370] The processor 32 may also be coupled to other peripheral devices 52, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 52 may include various sensors, such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, sensors, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0371] The network device 30 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices (e.g., smart watches or smart clothing), medical or electronic health equipment, robots, industrial equipment, drones, vehicles (e.g., cars, trucks, trains, or airplanes). The network device 30 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 52).

[0372] Fig.29C is a block diagram of an example computing system 90, which may also be used to implement one or more network devices of a network, such as Figure 1-22 , 24 and 26 and described herein, which may operate as an M2M server, gateway, device or other network apparatus in an M2M network, for example, Fig.29A and 29B Those shown.

[0373] The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, wherever and by whatever means such software is stored or accessed. Such computer-readable instructions may be executed within a processor such as a central processing unit (CPU) 91 to cause the computing system 90 to operate. In many known workstations, servers, and personal computers, the central processing unit 91 is implemented by a single-chip CPU known as a microprocessor. In other machines, the central processing unit 91 may include multiple processors. A coprocessor 81 is an optional processor different from the main CPU 91 that performs additional functions or assists the CPU 91. The CPU 91 and / or the coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods.

[0374] In operation, CPU 91 retrieves, decodes and executes instructions and transfers information to and from other resources via the computer's main data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0375] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been established, it cannot access memory within the virtual address space of another process.

[0376] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from the CPU 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0377] The display 86, controlled by the display controller 96, is used to display visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented as a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components necessary to generate the video signals to be sent to the display 86. The display 86, in conjunction with the computer executable instructions executed by the CPU 91, may generate and operate Fig.29D The graphical user interface shown and described in and its accompanying description.

[0378] In addition, the computing system 90 may include communication circuits, such as a network adapter 97, which may be used to connect the computing system 90 to an external communication network, such as Figures 29A-29D The network 12 enables the computing system 90 to communicate with other devices of the network. The communication circuitry alone or in combination with the CPU 91 may be used to perform the operations described herein (e.g., in Figure 1-22 , 24 and 26) and the sending and receiving steps described in the claims.

[0379] It should be understood that any or all of the systems, methods, and processes described herein may be implemented in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium, which, when executed by a machine such as an apparatus of an M2M network (including, for example, an M2M server, gateway, device, etc.), performs and / or implements the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described above may be implemented in the form of such computer executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transitory (i.e., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store the desired information and can be accessed by a computer.

[0380] The following is a list of acronyms related to service layer technology that may appear in the above description. Unless otherwise specified, the acronyms used in this article refer to the corresponding terms listed below:

[0381] AE Application Entity

[0382] BC Blockchain

[0383] CSE Public Service Entity

[0384] CSF Public Service Function

[0385] DL Distributed Ledger

[0386] DLN Distributed Ledger Node

[0387] DLP Distributed Ledger Agent

[0388] DLS Distributed Ledger System

[0389] DNS Domain Name System

[0390] DNS-SD DNS-based service discovery

[0391] ID Identifier

[0392] IoT

[0393] M2M Machine to Machine

[0394] P2P Peer

[0395] PoW Proof of Work

[0396] SL Service Layer

[0397] SLN Service Layer Node

[0398] SLS Service Layer System

[0399] URI Uniform Resource Identifier

[0400] UTXO Unspent Transaction Output

[0401] The following is a list of terms and definitions related to service layer technology that may appear in the above description. Unless otherwise specified, the terms and definitions used herein refer to the corresponding terms listed below:

[0402]

[0403]

[0404]

[0405] This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have elements that do not differ from the literal language of the claims, or if they include equivalent elements that do not differ substantially from the literal language of the claims.< / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstx> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / dlstxtemplate> < / request> < / request> < / request> < / subscription> < / request> < / dlstx> < / dlstx> < / dlstx> < / dlstxtemplate> < / dlstxtemplate>

Claims

1. A method for interworking a service layer system and a distributed ledger system, performed by a distributed ledger agent, the service layer system defining a software middleware layer, the software middleware layer supporting value-added service capabilities through a set of application programming interfaces (APIs), the method comprising: receiving a message from a service layer entity, the message comprising data to be stored in the distributed ledger system, the data being based on an interaction between the service layer entity and another service layer entity, the service layer entity and the other service layer entity not having established trust or registration in the service layer system; generating, at the distributed ledger proxy and based on the data, a transaction in accordance with one or more specifications of the distributed ledger system; sending information associated with the transaction to the distributed ledger system; receiving an indication from the distributed ledger system that the transaction has been confirmed by the distributed ledger system; as well as An indication is sent to the service layer entity that the transaction has been confirmed by the distributed ledger system.

2. The method according to claim 1, further comprising: A mapping between the data received from the service layer entity and the transaction is generated.

3. The method according to claim 1, wherein: The indication that the transaction has been confirmed by the distributed ledger system includes at least one of: an identifier of the transaction, an identifier of data received from the service layer entity, or a hash value of data received from the service layer entity.

4. The method according to claim 1, further comprising: A response is sent to the service layer entity and prior to receiving the indication that the transaction has been confirmed, the response including an indication that the transaction is awaiting confirmation by the distributed ledger system.

5. The method according to claim 1, further comprising: Another message including other data is received from the service layer entity, wherein the transaction is generated based on the data and the other data.

6. The method according to claim 1, further comprising: receiving, from the service layer entity, a request to retrieve one or more transactions from the distributed ledger system; retrieving information associated with the one or more transactions from the distributed ledger system; as well as Information associated with the one or more transactions is sent to the service layer entity.

7. The method according to claim 1, in, The distributed ledger system includes a plurality of distributed ledger nodes, and wherein the message includes an instruction to store the data at a specific node in the distributed ledger node.

8. An apparatus comprising a processor and a memory, the memory storing computer executable instructions that, when executed by the processor, implement a distributed ledger agent for intercommunication between a service layer system and a distributed ledger system, the service layer system defining a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs), and causing the distributed ledger agent to perform the following operations: receiving a message from a service layer entity, the message comprising data to be stored in the distributed ledger system, the data being based on an interaction between the service layer entity and another service layer entity, the service layer entity and the other service layer entity not having established trust or registration in the service layer system; generating, at the distributed ledger proxy and based on the data, a transaction in accordance with one or more specifications of the distributed ledger system; sending information associated with the transaction to the distributed ledger system; receiving an indication from the distributed ledger system that the transaction has been confirmed by the distributed ledger system; as well as An indication is sent to the service layer entity that the transaction has been confirmed by the distributed ledger system.

9. The device according to claim 8, wherein: The instructions, when executed, further cause the distributed ledger agent to generate a mapping between data received from the service layer entity and the transaction.

10. The device according to claim 8, wherein: The indication that the transaction has been confirmed by the distributed ledger system includes at least one of: an identifier of the transaction, an identifier of data received from the service layer entity, or a hash value of data received from the service layer entity.

11. The device according to claim 8, wherein: The instructions, when executed, further cause the distributed ledger agent to send a response to the service layer entity and prior to receiving an indication that the transaction has been confirmed, the response including an indication that the transaction is awaiting confirmation by the distributed ledger system.

12. The device according to claim 8, wherein: The instructions, when executed, further cause the distributed ledger agent to receive another message including other data from the service layer entity, wherein the transaction is generated based on the data and the other data.

13. The device according to claim 8, wherein: The instructions, when executed, further cause the distributed ledger agent to: receiving, from the service layer entity, a request to retrieve one or more transactions from the distributed ledger system; retrieving information associated with the one or more transactions from the distributed ledger system; as well as Information associated with the one or more transactions is sent to the service layer entity.

14. The device according to claim 8, in, The distributed ledger system includes a plurality of distributed ledger nodes, and wherein the message includes an instruction to store the data at a specific node in the distributed ledger node.

15. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement a distributed ledger agent for intercommunication between a service layer system and a distributed ledger system, wherein the service layer system defines a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs), and causes the distributed ledger agent to perform the following operations: receiving a message from a service layer entity, the message comprising data to be stored in the distributed ledger system, the data being based on an interaction between the service layer entity and another service layer entity, the service layer entity and the other service layer entity not having established trust or registration in the service layer system; generating, at the distributed ledger proxy and based on the data, a transaction in accordance with one or more specifications of the distributed ledger system; sending information associated with the transaction to the distributed ledger system; receiving an indication from the distributed ledger system that the transaction has been confirmed by the distributed ledger system; as well as An indication is sent to the service layer entity that the transaction has been confirmed by the distributed ledger system.

16. The computer-readable storage medium of claim 15, wherein: The instructions, when executed, further cause the distributed ledger agent to generate a mapping between data received from the service layer entity and the transaction.

17. The computer-readable storage medium of claim 15, wherein: The indication that the transaction has been confirmed by the distributed ledger system includes at least one of: an identifier of the transaction, an identifier of data received from the service layer entity, or a hash value of data received from the service layer entity.

18. The computer-readable storage medium of claim 15, wherein: The instructions, when executed, further cause the distributed ledger agent to send a response to the service layer entity and prior to receiving an indication that the transaction has been confirmed, the response including an indication that the transaction is awaiting confirmation by the distributed ledger system.

19. The computer-readable storage medium of claim 15, wherein: The instructions, when executed, further cause the distributed ledger agent to receive another message including other data from the service layer entity, wherein the transaction is generated based on the data and the other data.

20. The computer-readable storage medium of claim 15, in, The distributed ledger system includes a plurality of distributed ledger nodes, and wherein the message includes an instruction to store the data at a specific node in the distributed ledger node.

Images