WO2018115567A1

WO2018115567A1 - Method and apparatus for private data transfer between parties

Info

Publication number: WO2018115567A1
Application number: PCT/FI2016/050896
Authority: WO
Inventors: Troels Roennow; Karina PALYUTINA; Enrique MARTÍN LÓPEZ
Original assignee: Nokia Technologies Oy
Priority date: 2016-12-19
Filing date: 2016-12-19
Publication date: 2018-06-28

Abstract

A computer-implemented method configure to receive an account request from a first user device, the account request comprising a public key of the first user and a public key of the first trusted service provider; generate a first account key (A) using a first random number generator; hash the first account key (A) to generate a first hashed account key (hash-A); record the first hashed account key (hash-A) associated with the public key of the first user as an account key transaction in a block to a blockchain representing a public ledger; transmit, the first account key (A) to the first user device in a private manner; receive a transfer request from the first user device, the transfer request comprising a transfer value and an identifier for a second user; record in response to and based on the transfer request, updated balance information within a balance transaction in a block to the blockchain, the balance transaction further comprising a transaction identifier and encrypted using the first account key (A); generate a first one-time key (OTK1 ); record a balance update transaction in a block to the blockchain, the balance update transaction comprising: a first part comprising balance update information corresponding to the transfer value, an identifier of the second user and the transaction identifier, the first part is encrypted with the first one-time key (OTK1 ); and the second part comprising the first one-time key (OTK1 ) encrypted with a shared key (SK_S1-S2) of the first trusted service provider and a second trusted service provider.

Description

METHOD AND APPARATUS FOR PRIVATE DATA TRANSFER BETWEEN

PARTIES

TECHNICAL FIELD

[0001] The present application generally relates to blockchains, distributed databases, distributed ledgers, and cryptographic protocols. Furthermore, the present application relates to generating and storing transactions for private data transfers between trusted service providers.

BACKGROUND

[0002] This section illustrates useful background information without admission of any technique described herein representative of the state of the art.

[0003] Currently, schemes such as Bankers' Automated Clearing Services (BACS) and Society for Worldwide Interbank Financial Telecommunication (SWIFT) are known as protocols used by trusted service providers, such as banks, to transact and keep accounts consistent. In case two banks, for example, have a direct relationship with each other (they keep mutual accounts), a transfer is settled by one-to-one messaging. In more complex case, when two banks desiring to transact do not have a direct relationship, a transfer is routed via one or more correspondent banks (causing delay and costs). In the latter case audit can be complicated, as it requires tracing the transfer along its route and an involvement of all correspondent banks to verify such transaction. In addition, transactions are not globally ordered.

[0004] SWIFT provides a network that enables financial institutions worldwide to send and receive information about financial transactions in a secure, standardized and reliable environment. SWIFT also provides software and services to service providers, much of it for use on the SWIFT Net Network, and ISO 9362. Business Identifier Codes (BICs, previously Bank Identifier Codes) are popularly known as "SWIFT codes".

[0005] SWIFT does not facilitate funds transfer: rather, it sends payment orders, which must be settled by correspondent accounts that the institutions have with each other. Each financial institution, to exchange banking transactions, must have a banking relationship by either being a bank or affiliating itself with one (or more) so as to enjoy those particular business features. [0006] SWIFT means several things in the financial world:

a secure network for transmitting messages between financial institutions;

a set of syntax standards for financial messages (for transmission over SWIFT

Net or any other network); and

a set of connection software and services allowing financial institutions to transmit messages over SWIFT network.

[0007] Currently available solutions have a few drawbacks. The problem is distilled as a combination of several desirable properties or needs of bank transfers, such as following: The need for banks to transact over an existing blockchain infrastructure in a private manner, so that only parties with the need to know can decrypt the contents of transfers. The need for faster international transfers without the involvement of a centralized authority (such as SWIFT). The need to verify the transactions, for example, in an audit or dispute scenario. The need to keep all transactions totally ordered, wherein the order is agreed upon by all the relevant parties and achieved by distributed consensus. The need to implement services such as recurrent payments in a transparent and automated manner.

[0008] Concerning Bitcoin, blockchain has morphed the financial industries with numerous applications involving payments. An example of a recent technology that attempts to solve the above problems and needs with the aid of blockchain includes Ripple. Ripple provides a distributed solution for transfers between banks. Ripple can be seen as a faster and cheaper alternative to the SWIFT network. Ripple removes the need for a central party or a correspondent bank but does not solve all other needs disclosed above.

[0009] Thus, a technical solution is needed to solve problems of how to satisfy needs disclosed above simultaneously with an efficient and secure solution that can be performed over any type of open or closed network.

SUMMARY

[0010] Various aspects of examples of the invention are set out in the claims.

[0011] According to a first example aspect of the present invention, there is provided a computer-implemented method for secure transaction transfer between trusted service provider apparatuses, the method comprising: receiving, by a first trusted service provider apparatus, an account request from a first user device, the account request comprising a public key of the first user and a public key of the first trusted service provider;

generating a first account key (A), by the first trusted service provider apparatus, using a first random number generator;

hashing, by the first trusted service provider apparatus, the first account key (A) to generate a first hashed account key (hash-A);

recording, by the first trusted service provider apparatus, the first hashed account key (hash-A) associated with the public key of the first user as an account key transaction in a block to a blockchain representing a public ledger;

transmitting, by the first trusted service provider apparatus, the first account key (A) to the first user device in a private manner;

receiving, by the first trusted service provider apparatus, a transfer request from the first user device, the transfer request comprising a transfer value and an identifier for a second user;

recording, by the first trusted service provider apparatus, in response to and based on the transfer request, updated balance information within a balance transaction in a block to the blockchain, the balance transaction further comprising a transaction identifier and encrypted using the first account key (A);

generating a first one-time key (OTK1 ), by the first trusted service provider apparatus;

recording, by the first trusted service provider apparatus, a balance update transaction in a block to the blockchain, the balance update transaction comprising:

a first part comprising balance update information corresponding to the transfer value, an identifier of the second user and the transaction identifier, the first part is encrypted with the first one-time key (OTK1 ); and

the second part comprising the first one-time key (OTK1 ) encrypted with a shared key (SK_S1-S2) of the first trusted service provider and a second trusted service provider.

[0012] In an embodiment, the transfer request is received from the first user device via the blockchain, wherein the first user device has recorded the transfer request to the blockchain as a transaction in a block, the transaction comprising: a first part comprising a transfer message of the transfer value and a second user account identifier, and the transaction identifier, the first part is encrypted with a first one-time key (OTK1 ); and

the second part comprising the first one-time key (OTK1 ) encrypted with a shared key (SK_A-S1 ) of the first user and the first trusted service provider.

[0013] In an embodiment, the transaction identifier is configured to link a following transaction to the transfer request.

[0014] In an embodiment, the method further comprises signing the transfer request with a private key of the first user for verifying that the transfer request originates from the first user.

[0015] In an embodiment, the transfer request is received from the first user device directly via a secure channel.

[0016] In an embodiment, the secure channel comprising an online communication interface provided by the first trusted service provider.

[0017] In an embodiment, the transfer request is received from the first user device directly via an encrypted point-to-point (P2P) message over a public data network.

[0018] In an embodiment, the method further comprises:

generating a second account key (B), by a second trusted service provider apparatus, using a second random number generator;

recording, by the second trusted service provider apparatus, a balance update transaction in a block to the blockchain, the balance update transaction comprising:

a first part comprising balance update information corresponding to the transfer value, the identifier of the second user and the transaction identifier, the first part is encrypted with the second account key (B).

[0019] In an embodiment, the method further comprises:

recording, by the second trusted service provider apparatus, in response to the balance update transaction, a confirmation transaction in a block to the blockchain, the confirmation transaction comprising:

a first part comprising confirmation and the transaction identifier, the first part is encrypted with a second one-time key (OTK2); and

a second part comprising the second one-time key (OTK2), the second part is encrypted with a shared key (SK_S1 -S2) of the first and the second trusted service provider.

[0020] In an embodiment, the balance update transaction and the confirmation transaction are arranged to be linked within the same block to the blockchain. [0021] In an embodiment, the method further comprises:

rejecting the balance update information of the balance update transaction by the second trusted service provider apparatus;

recording, by the second trusted service provider apparatus, in response to the rejected balance update information, a reject transaction in a block to the blockchain, the reject transaction comprising:

a first part comprising reject information and the transaction identifier, the first part is encrypted with a third one-time key (OTK3); and

a second part comprising the third one-time key (OTK3), the second part is encrypted with a shared key (SK_S1 -S2) of the first and the second trusted service provider.

[0022] In an embodiment, the method further comprises:

recording, by the first trusted service provider apparatus, a second balance update transaction in a block to the blockchain, the second balance update transaction comprising:

a first part comprising balance update information corresponding to the transfer value reverted and an identifier of the first user and the transaction identifier, the first part is encrypted with a fourth one-time key (OTK4); and

the second part comprising the fourth one-time key (OTK4) encrypted with the shared key (SK) of the first trusted service provider and the second trusted service provider.

[0023] In an embodiment, the method further comprises:

recording, by the first trusted service provider apparatus, in response to and based on the second balance update transaction, updated balance information within the second balance transaction in a block to the blockchain, the second balance transaction further comprising the first account key (A) and the transaction identifier.

[0024] In an embodiment, the method further comprises:

recording, by the first trusted service provider apparatus, a new balance transaction in a block to the blockchain, the new balance transaction comprising new balance information of the first user, encrypted with the first account key (A).

[0025] In an embodiment, the method further comprises:

recording, by the second trusted service provider apparatus, a new balance transaction in a block to the blockchain, the new balance transaction comprising new balance information of the second user, encrypted with the second account key (B). [0026] In an embodiment, the method further comprises:

recording, by the first trusted service provider apparatus, an account change transaction in a block to the blockchain, the account change transaction comprising the first account key (A) encrypted with a shared key (SK_A-S2) of the first user and the second trusted service provider.

[0027] In an embodiment, the method further comprises:

defining a blockchain record comprising certified first users; and a blockchain record comprising certified second users.

[0028] In an embodiment, the method further comprises:

defining a blockchain record comprising certified first trusted service providers and a blockchain record comprising certified second trusted service providers.

[0029] In an embodiment, the method further comprises:

signing, by the second trusted service provider, a previous blockchain record issued by the first trusted service provider to verify identity of the second trusted service provider.

[0030] In an embodiment, the method further comprises:

signing, by the first trusted service provider, a previous blockchain record issued by the second trusted service provider user to verify identity of the first trusted service provider.

[0031] In an embodiment, the method further comprises:

generating a further transaction, by at least one of the second user, the first trusted service provider, and the second trusted service provider to invalidate at least part of an earlier transaction item issued by the first user.

[0032] In an embodiment, the method further comprises:

signing the further transaction by the third user and the second user by at least one of the second user, the first trusted service provider, and the second trusted service provider.

[0033] In an embodiment, at least one transaction is added as part of a subsequent block to the blockchain according to a consensus algorithm.

[0034] In an embodiment, the method further comprises:

assigning a node identifier to each node of the first user, the second user, the first trusted service provider and the second trusted service provider.

[0035] In an embodiment, the node identifier comprises a public key.

[0036] In an embodiment, the first user device, the second user device, the first trusted service provider apparatus and the second trusted service provider apparatus are connected to a wide area communication interface.

[0037] In an embodiment, the blockchain is configured to be protected by a proof algorithm comprising at least one of a proof-of-work, proof-of-stake and majority- voting algorithm.

[0038] In an embodiment, the method further comprises:

generating a first account key (A), by a first trusted service provider apparatus, using a first random number generator;

hashing, by the second trusted service provider apparatus, the second account key (B) to generate a second hashed account key (hash-B);

generating a one-time key (OTK) by a user device, a first or a second trusted service provider apparatus;

generating a shared key (SK_S1 -S2) of the first trusted service provider and the second trusted service provider;

generating a shared key (SK_A-S2) of a user and at least one of the first and the second trusted service provider;

wherein an account key is configured define a first secrecy level, a hashed account key is configured define a second secrecy level, a one-time key is configured define a third secrecy level, a shared key is configured define a fourth secrecy level; and

generating selective audit information of transactions of the blockchain based on at least one of the secrecy levels.

[0039] According to a second example aspect of the present invention, there is provided an apparatus comprising:

a communication interface for transceiving information;

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to: receive an account request from a first user device, the account request comprising a public key of the first user and a public key of the first trusted service provider;

generate a first account key (A) using a first random number generator; hash the first account key (A) to generate a first hashed account key (hash-A);

record the first hashed account key (hash-A) associated with the public key of the first user as an account key transaction in a block to a blockchain representing a public ledger;

transmit, the first account key (A) to the first user device in a private manner;

receive a transfer request from the first user device, the transfer request comprising a transfer value and an identifier for a second user;

record in response to and based on the transfer request, updated balance information within a balance transaction in a block to the blockchain, the balance transaction further comprising a transaction identifier and encrypted using the first account key (A);

generate a first one-time key (OTK1 );

record a balance update transaction in a block to the blockchain, the balance update transaction comprising:

a first part comprising balance update information corresponding to the transfer value, an identifier of the second user and the transaction identifier, the first part is encrypted with the first one-time key (OTK1); and the second part comprising the first one-time key (OTK1 ) encrypted with a shared key (SK_S1-S2) of the first trusted service provider and a second trusted service provider.

[0040] In an embodiment, the apparatus comprises at least one user device or a plurality of user devices.

[0041] According to a third example aspect of the present invention, there is provided a computer program embodied on a computer readable non-transitory medium comprising computer executable program code, which when executed by at least one processor of a apparatus, causes the apparatus to: receive an account request from a first user device, the account request comprising a public key of the first user and a public key of the first trusted service provider;

generate a first account key (A) using a first random number generator;

hash the first account key (A) to generate a first hashed account key (hash-A); record the first hashed account key (hash-A) associated with the public key of the first user as an account key transaction in a block to a blockchain representing a public ledger;

transmit, the first account key (A) to the first user device in a private manner; receive a transfer request from the first user device, the transfer request comprising a transfer value and an identifier for a second user;

generate a first one-time key (OTK1 );

the second part comprising the first one-time key (OTK1 ) encrypted with a shared key (SK_S1 -S2) of the first trusted service provider and a second trusted service provider.

[0042] Different non-binding example aspects and embodiments of the present invention have been illustrated in the foregoing. The embodiments in the foregoing are used merely to explain selected aspects or steps that may be utilized in implementations of the present invention. Some embodiments may be presented only with reference to certain example aspects of the invention. It should be appreciated that corresponding embodiments may apply to other example aspects as well.

BRIEF DESCRIPTION OF THE DRAWINGS

[0043] For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

[0044] Fig. 1 shows a schematic drawing of a system of an example embodiment;

[0045] Fig. 2 shows another schematic drawing of a system of an example embodiment;

[0046] Fig. 3 shows a flow diagram illustrating a method according to an example embodiment of the invention;

[0047] Fig. 4 shows a block diagram of a device or apparatus of an example embodiment; and

[0048] Fig. 5 shows a block diagram of a server apparatus of an example embodiment.

DETAILED DESCRIPTON OF THE DRAWINGS

[0049] Example embodiments of the present invention and its potential advantages are understood by referring to Figs. 1 through 5 of the drawings. In this document, like reference signs denote like parts or steps.

[0050] In this document, the terms couple and connect may refer to direct contact between components or to coupling through some intervening component(s).

[0051] This application is related to distributed ledgers, blockchains and databases. It is further related storing transfer transaction records, accounts and cloud security. It is also related to cryptocurrencies. Blockchains are technology that enables tamper-proof timestamped distributed databases. Cryptographic signatures and data encryption enable the level of security required for transfer transaction data.

[0052] A blockchain is a distributed database that maintains a continuously growing list of data records hardened against tampering and revision. It consists of data structure blocks, which hold exclusively data in initial blockchain implementations, and both data and programs in some implementations, with each block holding batches of individual transactions and the results of any blockchain executables. Each block contains a timestamp and information linking it to a previous block.

[0053] The blockchain is seen as the main technical innovation of bitcoin, where it serves as the public ledger of all bitcoin transactions. Bitcoin is peer-to-peer, every user is allowed to connect to the network, send new transactions to it, verify transactions, and create new blocks, which is why it is called permissionless. This original design has been the inspiration for other cryptocurrencies and distributed databases.

[0054] In relation to transactions between trusted service providers, Ripple protocol is disclosed. At its core, Ripple protocol is based around a shared, public database or ledger that uses a consensus process that allows for payments, exchanges and remittance in a distributed process. From trusted service provider perspective, distributed ledgers like the Ripple protocol system have a number of advantages over cryptocurrencies like bitcoin, including price and security.

[0055] In Ripple protocol, users make payments between each other by using cryptographically signed transactions denominated in either fiat currencies or Ripple's internal currency (XRP). For XRP-denominated transactions Ripple protocol can make use of its internal ledger, while for payments denominated in other assets, the Ripple ledger only records the amounts owed, with assets represented as debt obligations. Users have to specify which other users they trust and to what amount. When a non-XRP payment is made between two users that trust each other, the balance of the mutual credit line is adjusted, subject to limits set by each user. In order to send assets between users that have not directly established a trust relationship, the system tries to find a path between the two users such that each link of the path is between two users that do have a trust relationship. All balances along the path are then adjusted simultaneously and atomically. This mechanism of making payments through a network of trusted associates is named 'rippling'.

[0056] However, Ripple protocol does not have the ability to run on any type of open or closed network. In contrast, Ripple protocol runs on a dedicated closed network that does not enable the user for an opportunity to verify bank's actions.

[0057] Encryption methods alluded to in different embodiments disclosed are exchangeable.

[0058] Fig. 1 shows a schematic drawing of a system (100) of an example embodiment.

[0059] At the minimum, the system (100) comprises at least one node (110, 120, 140, 160) for transceiving data within the system (100). The node (1 10, 120, 140, 160) may comprise a user device, an loT (Internet of Things) device, a trusted service provider apparatus (such as an enterprise computer system), an integrated device or home electronics device, for example. The user device may comprise a portable electronic device, a smartphone, a PDA, a tablet, a laptop computer, a wrist-based device, a belt device, or a clothing-integrated device, for example. The trusted service provider apparatus may comprise a portable electronic device, a smartphone, a PDA, a tablet, a laptop computer, a desktop computer, a server, or a networked computer, for example.

[0060] In an embodiment, a blockchain infrastructure may be utilized to define a trusted circle (114) comprising at least two nodes (110, 1 13) of a plurality of nodes.

[0061] The system (100) illustrates nodes (110, 120, 140, 160) in a secure transaction network that are configured or programmed to manage secure transactions in the form of a blockchain (170). Each block in the blockchain (170) includes one or more transactions that further incorporate information representing transaction information by nodes (110, 120, 140, 160). In some embodiments, the nodes operate collectively in a peer-to-peer network. Further a node (1 13) can exist within a trusted circle (114) of nodes, such as a trusted service provider apparatus ecosystem (e.g. financial service provider's data system) or a user home ecosystem, for example.

[0062] In an embodiment, a node represents an entity that has a stake in a secure transaction process. The node could correspond to a first user (e.g. payer), a second user (e.g. a payee), a first trusted service provider (e.g. payer's bank) and a second trusted service provider (e.g. payee's bank). Further, the node could also include other types of entities including a company, an affiliation, a shop, an organization, a demographic, a community, or other type of entity related to transactions.

[0063] In an embodiment, a blockchain (170) represents a chronicle or ledger (public ledger, private ledger, protected ledger, for example) of transactions. With respect to a first user, the blockchain (170) may start with an initial block or genesis block created when registering as a client within the first trusted service provider system that includes information associated with the first user. Alternatively, the initial block may be created when the first user opens an account within first trusted service provider system for the first time. Each subsequent transaction for the first user can be combined with the blockchain (170) as a new block, possibly until the blockchain (170) becomes eventually terminated when the first user exits the system or ceases to exist. [0064] In an embodiment, a blockchain (170) represents a chronicle or ledger (public ledger, private ledger, protected ledger, for example) of transactions of a plurality of users and a plurality of trusted service provider systems.

[0065] In an embodiment, a blockchain (170) could comprise any number of blocks. The blockchain (170) may increase in size depending on activity of the user or the service provider, for example.

[0066] In an embodiment, there is provided a computer-implemented method for secure transaction transfer between trusted service provider apparatuses (110, 120), the method comprising:

receiving, by a first trusted service provider apparatus (110), an account request from a first user device (140), the account request comprising a public key of the first user and a public key of the first trusted service provider apparatus (1 10); generating a first account key (A), by the first trusted service provider apparatus (110), using a first random number generator;

hashing, by the first trusted service provider apparatus (110), the first account key (A) to generate a first hashed account key (hash-A);

recording, by the first trusted service provider apparatus (110), the first hashed account key (hash-A) associated with the public key of the first user (140) as an account key transaction in a block to a blockchain (170) representing a public ledger; transmitting, by the first trusted service provider apparatus (110), the first account key (A) to the first user device (140) in a private manner;

receiving, by the first trusted service provider apparatus (110), a transfer request from the first user device (140), the transfer request comprising a transfer value and an identifier for a second user (160);

recording, by the first trusted service provider apparatus (110), in response to and based on the transfer request, updated balance information within a balance transaction in a block to the blockchain (170), the balance transaction further comprising a transaction identifier and encrypted using the first account key (A); generating a first one-time key (OTK1 ), by the first trusted service provider apparatus (110);

recording, by the first trusted service provider apparatus (1 10), a balance update transaction in a block to the blockchain (170), the balance update transaction comprising: a first part comprising balance update information corresponding to the transfer value, an identifier of the second user (160) and the transaction identifier, the first part is encrypted with the first one-time key (OTK1 ); and

the second part comprising the first one-time key (OTK1 ) encrypted with a shared key (SK_S1 -S2) of the first trusted service provider (1 10) and a second trusted service provider (120),

[0067] A plurality of nodes (110, 120, 140, 160) may generate account keys, hashes, one-time-keys and other transaction related data items (151). The data items (151 ) may be associated to transactions. The transactions may be recorded to a blockchain (170). The data items (151 ) may be placed to the network (150) for illustrative purposes only. In practice the data items (151 ) are transceived within the system (100) nodes.

[0068] In an embodiment, a trusted service provider apparatus (1 10, 120) is configured to generate or maintain shared keys (SK_A-S1 , SK_A-S2, SK_S1-S2) of relevant nodes for data encryption between nodes. No matter not all possible shared keys are illustrated in Fig. 1 , shared keys may be maintained within any node of the system (100) configured to communicate securely with another node with corresponding shred key.

[0069] All participants or nodes of the protocol have the ability to generate and share a one-time key (OTK) or a nonce for data encryption, for example. A one-time key (OTK) may be configured to be used, at a later time, to an audit without compromising the permanent shared key SK(user A, bank A). The transaction identifier is used to link the following relevant transaction back to the original user request. Transaction is signed with the first user's (user A) private key (PR-A), so every node can verify it originates from user A.

[0070] In an embodiment, a node (110) may receive a notification information identifying a trusted user circle (114) comprising the first node (110) and a second node (1 13), wherein the first node ( 10) and the second node (1 13) are configured to define a private blockchain (170). Private blockchain data is maintained within the trusted user circle (1 14) according to pre-defined settings, wherein the private blockchain data is divided between nodes (110, 113) of the trusted user circle (114) based on the pre-defined settings.

[0071] In an embodiment, nodes correspond to devices. Thus, devices may be paired and in response to pairing the devices collaborate on storing and securing the contents of a distributed ledger. This technique enables, for example, home devices with little storage (such as general loT nodes) to collaborate on forming one "super" node corresponding to the trusted user circle with capacity similar to that of an ordinary node hosted on a PC or in a cloud. Furthermore also other resources may be shared within the trusted user circle, such as hashing power, or listing of peers, for example.

[0072] Any node (1 10, 120, 140, 160) may generate transaction data relating to the node and hash the data using a cryptographic hashing function, to create a cryptographic hash block.

[0073] In an embodiment, the trusted user circle (114) may comprise a gateway node (1 10) configured to control access of other nodes within the trusted user circle (114) to external network (150) outside the trusted user circle (1 14). Node (110) may be for example a first trusted service provider (e.g. a bank) responsible for a bank account of the first user (140), for example.

[0074] In an embodiment, the gateway node may receive data without hashing from other nodes within the trusted user circle and carry out the data hashing using a cryptographic hashing function, to create a cryptographic hash block.

[0075] Nodes (110, 120, 140, 160) may communicate with other nodes within the system (100). The node may be connected to a public network (150) over connection (111 , 121 , 141 , 161).

[0076] In an embodiment, the nodes are integrated as a single device. Alternatively, the gateway node (110) and another node (113) are separate entities and connected via a local short-range communication interface (112), and the gateway node (110) and a remote node (140) are connected via a wide area communication interface (150), for example. It is also possible to arrange the nodes to be releasably connectable to each other so that in one operating mode they are integrated together and in second operating mode they are separate entities.

[0077] After hashing, the node (110, 120, 140, 160) is configured to record the cryptographic hash block associated with a digital signature to a block of a blockchain (170).

[0078] In an embodiment, transaction data may be encrypted before hashing. For example, asymmetrical encrypting of the data may be carried out by the node ( 10, 120, 140, 160). The encrypted data may be stored to at least one of the nodes (110, 120, 140, 160), to the blockchain (170), to a central database server (130) or a cloud (131 ), to a distributed database, or other parts of the system (100).

[0079] An owner of blockchain nodes ( 10, 120, 140, 160) may have many nodes (as for instance could be the case in loT). While the owner may not trust any device he does not own, he may trust his own devices. Thus a trusted circle of nodes (1 4) may be established.

[0080] In an embodiment, the nodes (110, 120, 140, 160) are configured to generate transaction data and further take care of encrypting the data if needed, as well as hashing the data using a cryptographic hashing function, to create a cryptographic hash block, to record the cryptographic hash block associated with a digital signature of a node (1 10, 120, 140, 160) to a block of a digital blockchain (170) and to transmit the data item to a peer node, for example.

[0081] The local short-range communication interface (111 , 1 12, 121 , 141 , 161 ) may comprise wired or wireless interface. The wide area communication interface may comprise a public network ( 50), such as Internet.

[0082] In an embodiment, the first node (1 10) and the second node (113) may be implemented as separate devices communicating with each other over a local connection (112). The local connection (112) may comprise also other wireless non- cellular connection. The wireless non-cellular connection may comprise industrial, scientific and medical (ISM) radio bands that are radio bands (portions of the radio spectrum) reserved internationally for the use of radio frequency (RF) energy for industrial, scientific and medical purposes, for example. Alternatively, the first node (110) may be comprised by the second node (1 13). The trusted circle (114) may also correspond to a system within user's home, wherein the first node and the second node communicate with each other over a local connection (1 12).

[0083] In an embodiment, a communication interface module of at least one of the nodes (1 10, 120, 140, 160) may comprise location modules for tracking location information of the node. Such location modules may comprise a module for providing a connection to satellite based global positioning system (e.g. GPS), a module for cellular based positioning system, a module for indoor positioning, a module for wireless non-cellular positioning system (e.g. Wi-Fi) or a module for hybrid positioning system, for example.

[0084] In an embodiment, a node may be connected over a wireless or wired connection to a wide area network (150), such as Internet. Router apparatuses (not shown) may be used for providing the access to a wide area network (150). The access may comprise cellular or non-cellular connection.

[0085] In an embodiment, the system (100) comprises a server apparatus (130), which comprises a storage device for example for storing and providing user data, service data and subscriber information, over data connection (132). The service data may comprise configuration data, account creation data, account key data, financial data, transaction data of the nodes, and digital blockchain data, for example.

[0086] In an embodiment, a proprietary application in the node (110, 120, 140, 160) may be a client application of a service whose server application is running on the server apparatus (130) of the system (100). The proprietary application may capture or process transaction data for the service and provide the transaction data hashing, blockchain recording and transceiving for the service. In an embodiment, information between nodes (1 10, 120, 140, 160) and/or the server (130) is transceived via the connections ( 1 , 121, 132, 141 , 150, 161 ) automatically. Thus the user of the nodes may not need to do any control for the service. The system server (130) may also maintain account creation process details for the service, such as attaching new nodes to the system (100) as well as maintaining authorized users and devices.

[0087] In an embodiment, history data of earlier transaction data, user profiles, settings, agreements, account data, financial limit information, and blockchains may be maintained at the server (130), for example.

[0088] The server (130) may also provide a cloud service (131 ) for the data of devices (1 10, 120, 140, 160). Optionally, further devices may be added, such as peripheral devices for maintaining, providing or processing node (110, 120, 140, 160) data and communication devices for connecting the peripheral devices to the system (100).

[0089] The node (1 10, 120, 140, 160) may operate as an Internet of Things device (loT), such as a gaming console, a home electronics device, a user personal device, a car computer, or such.

[0090] The node (110, 120, 140, 160) is capable of locally executing software program code. The software program code may be a client application of a service whose server application is running on a server (130) of the system (100).

[0091] Embodiments of this invention describe how to implement a system (100) where nodes (110, 120, 140, 160) can store sensitive information in such a way that a remote device later on can confirm the authenticity of the data. The embodiments may use an open distributed ledger to keep a record of hashes of encrypted user data. The data may be encrypted asymmetrically such that anyone can redo the encryption of the raw data. After encryption the data is hashed and the result is added onto a ledger. Additionally a trusted circle (114) for certain nodes can be created and blockchain data divided between the nodes within the trusted circle.

[0092] In an embodiment, a node (140) may be located on the user or on the user household device, on the user's personal smart device, or such, and may collect and encrypt data from the user. The data may be encrypted asymmetrically, a hash of the asymmetrically encrypted data may be computed by the node and added to a blockchain (170). The blockchain is protected by a proof algorithm, such as proof-of-work, proof-of-stake or the like. The user can now at any time decrypt the data and send it to a third party node (110, 120, 160) (in practice this may be automated, and the user simply chooses which third parties may access which types of data on a continuous basis). The third party can then verify that this was indeed the o ginal data that was collected by the node (140), by first asymmetrically encrypting it, computing the hash and verifying its presence on the blockchain (170).

[0093] In an embodiment, the nodes may not trust other nodes. Hence, the nodes may store the full blockchain and corresponding data. The owner of the devices can dictate that how the devices utilize shared storage, but nodes cannot have distributed storage outside of the owner's devices. That is to say, if one owner has a couple of nodes and another owner has a couple of nodes, the first owner can make his/her nodes collaborate, but cannot get them to share storage with the second owner's nodes. In some implementations it may be possible for two owners to express mutual consent for their devices to collaborate.

[0094] In an embodiment, a distributed database as disclosed, contains identifiers for certified users (devices) and service providers (apparatuses).

[0095] The solution may require that all trusted service providers (e.g. banks) that wish to execute inter-bank transfers to participate in the protocol and maintain a blockchain node.

[0096] Furthermore, the solution may also require a trusted party to certify the trusted service provider apparatuses (e.g. bank data systems/apparatuses), so that the trusted service provider nodes can be distinguished from other nodes. This ensures that only certified nodes are allowed to perform the bank operations, for example.

[0097] Fig. 2 shows another schematic drawing of a system (200) of an example embodiment.

[0098] A system comprises a plurality of nodes. The data may be divided between the nodes in various ways. The data may comprise blockchain and corresponding transaction data.

[0099] In an embodiment, a distributed ledger can be considered a general database where each table may implement, for example, the ability to add, remove or modify records. In the example implementation of Fig. 2, every request to modify the database may be collected into a Merkle tree (230) (In Fig. 2 there are two Merkle trees) that is then used to generate a blockchain (170).

[00100] In an embodiment, transactions may be chained directly, leaving out the Merkle tree(s). This may be the preferred in certain circumstances. The order in which events occur is typically agreed upon using a consensus mechanism, such as proof-of-work, proof-of-stake, majority voting or preselected validation nodes.

[00101] In an embodiment, a solution of conducting inter-bank asset transfer over a public blockchain network is disclosed. The disclosed solution present at least following features. First, all transfers are private (a transfer can be read only by the participating parties with the need to know) and simultaneously publicly verifiable in the case of an inspection. Second, all transfers are totally ordered and the order is agreed upon by the relevant parties. Third, transfers are administered over a public or private ledger. Transfers over a public ledger have no adverse effect on the privacy of the transactions. Fourth, the privacy is maintained by use of widely used encryption schemes via a protocol described in Fig. 3.

[00102] In an embodiment as shown in Fig. 2, a blockchain (170) is used to establish a public record (240, 250) of certified users, certified service providers, transactions and devices. To store transfers and transactions, the system may implement a massively replicated distributed file system. In an example implementation, the ledger contains at least one table that keeps track of certified users (240) and another keeping track of certified trusted service provider apparatuses (in re banks, for example). Additionally, it contains a ledger that has at least a hash entry, a pointer to a file, a service provider (e.g. bank) ID and a user's ID. The hash entry is the hash of a file on a file system accessible to both the users and service providers (e.g. banks). The IDs are used to represent actors in the system, such as banks, users and business entities. In the preferred implementation the IDs are public keys, each of which has a corresponding private key. The person in possession of the private key is the sole owner of the ID, thus making them the only person capable of signing transactions involving that ID.

[00103] In an embodiment, a variant of majority voting that is preferred due to its low deployment cost, may be utilized.

[00104] In an embodiment, a block (210) is processed by combining previous block information (e.g., a hash of a block header) from blockchain (170) with additional information, thereby linking the block (210) with the blockchain (170). The additional transaction information can include time stamp, transfer or account related data, a digital signature, and a token, for example. A peer node can re-calculate a value for the block, typically a hash of the block's header along with hash information from the transactions, until the resulting value satisfies the validity requirement. For example, in embodiments where block (210) is processed via a hash function (e.g., SHA256, Scrypt, etc.), peer can increment a nonce value until a hash is generated having the desired proof-of-work characteristics, perhaps a number of leading zero bits among other factors, for example.

[00105] Once validity block (210) has been properly calculated and/or validated by the peers, it can be sent to other peers in the system so that the validity block (210) will be appended to the blockchain (170). Thus, validity block (210) becomes part of the chronicled transaction history of stakeholder, such as a patient. Validity block (210) can be considered accepted as part of the blockchain (170) once other peers pickup and integrate it into their own copies of the blockchain (170).

[00106] In an embodiment, a previous block (210) and a current block (220) are illustrated in Fig. 2, and illustrating how combined hash of the previous block (210) is used for generation of current block (220) in the blockchain (170).

[00107] In an embodiment, different uses of public-key cryptography may be utilized. To ensure confidentiality, public-key encryption may be used, in which a message is encrypted with a recipient's public key. The message cannot be decrypted by anyone who does not possess the matching private key, who is thus presumed to be the owner of that key and the person associated with the public key.

[00108] In an embodiment, apublic-private key pair used for encryption may be different from the one employed for signing. For instance, Digital Signature Authentication may employ a pair of keys based on Elliptic Curve Cryptography, whereas Asymmetric Encryption may use a pair of keys based on the RSA Cryptography.

[00109] To ensure tamper-proof, digital signatures (signing) may be utilized, in which a message is signed with the sender's private key and can be verified by anyone who has access to the sender's public key. This verification proves that the sender had access to the private key, and therefore is likely to be the person associated with the public key. This also ensures that the message has not been tampered with, as any manipulation of the message will result in changes to the encoded message digest, which otherwise remains unchanged between the sender and receiver.

[00110] Fig. 2 further illustrates a transaction record (240) for adding a certified bank to the distributed file system, a transaction record (250) for removing a certified bank from the distributed file system, and a transaction record (260) for adding a certified user or device to the distributed file system.

[00111] At the time where a proof-of-work (POW) should be found, the nodes may combine the hashes from the transactions to form a Merkle tree (230), or simply keep a hash of the state of the full storage system, which will enter the next block. In some implementations it may be feasible to do both as this allows to implement a fast-forward mechanism that makes new nodes catch up with the network in much less time than what they would need if only the Merkle hash of the transactions are stored in the blocks.

[00112] In addition to distributing the storage, the nodes may also distribute hash power. This may happen within a trusted circle and it may be done across subsets of the networks by making pools, for example. Unlike the storage, distribution of the hash power does not require trust and can therefore easily be implemented in many various scenarios.

[00113] In an embodiment, transaction data may be generated by a first node, such as a trusted service provider node. The transaction data is hashed using a cryptographic hashing function, to create a cryptographic hash block, the cryptographic hash block is associated with a digital signature of the trusted service provider node and may be transmitted to a public blockchain.

[00114] In an embodiment, a node identifier is assigned to each node, wherein the node identifier may comprise a public key.

[00115] Furthermore, a trusted user circle identifier may be assigned to the trusted user circle. Routing transactions from nodes external to the trusted user circle may base on the trusted user circle identifier.

[00116] The transaction data, such as a transfer data item, may be stored at a node.

[00117] In an embodiment, the node may add a node specific hash of an asymmetric encryption on the transfer data item to generate a hash block (210, 220). In some embodiments, the data may be stored directly on the node without node specific hashing.

[00118] The hash block (210, 220) of the asymmetrically encrypted data (or unencrypted data) may be computed and added to a blockchain (170). The blockchain (170) may be protected by a proof algorithm, such as proof-of-work (POW), proof-of-stake or the like. The user can now at any time decrypt the data and send it to a third party within a network system (100, 200) (this may also be automated, and the user simply chooses which third parties may access which types of data on a continuous basis). The third party can then verify that this was indeed the original data that was collected by the node, by first asymmetrically encrypting it, computing the hash and verifying its presence in the blockchain 170. Nodes may be nodes in a network of nodes, such as a network for Internet of Things (loT).

[00119] In an embodiment, the blockchain (170) is implemented using Merkle trees (230). Aggregating hash values of the exchanged data in a Merkle tree (230) is efficient, since the "root" (210, 220) of the Merkle tree (230) provides a compressed digest of all individual hash values, so that the Merkle tree (230) reduces storage requirements.

[00120] A distributed ledger is a database that can securely record user transaction data for sharing across a network through entirely transparent updates of information.

[00121] The blockchain data structure (170) is an ordered, back-linked list of blocks of transactions. The blockchain (170) can be stored as a flat file, or in a simple database. Blocks (210, 220) are linked "back" each referring to the previous block in the chain. The blockchain (170) is often visualized as a vertical stack, with blocks layered on top of each other and the first block serving as the foundation of the stack. The visualization of blocks stacked on top of each other results in the use of terms such as "height" to refer to the distance from the first block, and "top" or "tip" to refer to the most recently added block. [00122] Although a block has just one parent, it can temporarily have multiple children. Each of the children refers to the same block as its parent and contains the same (parent) hash in the "previous block hash" field. Eventually, only one child block becomes part of the blockchain (170). Even though a block may have more than one child, each block (210, 220) can have only one parent. This is because a block has one single "previous block hash" field referencing its single parent.

[00123] Each block within the blockchain (170) may be identified by a hash, generated e.g. using a SHA256 cryptographic hash algorithm on the header of the block. Each block also references a previous block, known as the parent block, through the "previous block hash" field in the block header. In other words, each block contains the hash of its parent inside its own header. The sequence of hashes linking each block to its parent creates a chain going back all the way to the first block ever created, known as the genesis block.

[00124] In an embodiment, each block in the blockchain (170) contains a summary of all the transactions in the block, using a Merkle tree (230). The Merkle tree (230), also known as a binary hash tree, is a data structure used for efficiently summarizing and verifying the integrity of large sets of data. Merkle trees are binary trees containing cryptographic hashes. The term "tree" is used in computer science to describe a branching data structure, but these trees are usually displayed upside down with the "root" at the top and the "leaves" at the bottom of a diagram.

[00125] In an embodiment, the Merkle tree is omitted and blocks of "transactions" are linked directly together in the private blockchain (170).

[00126] The digital blockchain (170) corresponds to a distributed cryptographic ledger shared amongst certified and trusted nodes, over which every successfully performed transaction is recorded.

[00127] In an embodiment, a private blockchain of a trusted circle may be integrated to a public blockchain.

[00128] In an embodiment, received transaction data from a first node (e.g. first or second bank) at a remote device (e.g. first or second user) can be verified by the remote device. The remote device may be a computer, a smart device, a server, an embedded device or special purpose circuit, for example.

[00129] In an embodiment, one may want to store the data unencrypted in which case the asymmetric encryption can be omitted in both cases. In some embodiments the transaction data may be encrypted and hashed by the node itself and only accepted onto the ledger (230), if a node public key is verified as a certified device.

[00130] In an embodiment, each device, including loT (Internet of Things) devices, or node, may comprise a private key for asymmetric cryptography. The asymmetric cryptographic system uses pairs of keys: public keys that may be disseminated widely paired with private keys, which are known only to the owner. There are two functions that can be achieved: using a public key to authenticate that a transfer transaction or message originated with a holder of the paired private key; or encrypting a message or transfer transaction data item with a public key to ensure that only the holder of the paired private key can decrypt it. The key pairs for signing and encrypting may be different as disclosed earlier.

[00131] The private key may be configured to the node by the manufacturer or reseller of the node. Then, when joining e.g. a trusted circle, the node may update its public key to a gateway node of the trusted circle. Alternatively, a node may receive a private key from the gateway node when joining the trusted circle and the corresponding public key made available by the gateway node.

[00132] In an embodiment, a trusted service provider apparatus node (1 10, 120) (Fig. 1 ) receives transaction data from a user device (140, 160). The user device (140, 160) hashes the transaction data using a cryptographic hashing function, to create a cryptographic hash block and fetches a reference cryptographic hash block from blockchain (170). The device (140, 160) may then compare the cryptographic hash block to the fetched block from the blockchain (170). The transaction data may be verified in response to finding a matching cryptographic hash block in a blockchain (170) based on the comparing step.

[00133] In an embodiment, governmental majority consensus may be provided. Thus, an additional record keeping track of official government nodes may be present in the system (200). The genesis block is minted with one or more governments public keys registered into this block. Upon reaching the end of a block period, everyone who holds a government private key votes about which block is the next valid block. This effectively solves the high energy consumption with proof-of- work (POW), but yet remains secure as multiple nodes across a large geographical area makes it hard to make a single attack.

[00134] New government keys can be added or removed by majority voting, where each vote is cast by signing a transaction for, or against adding a new government role. In this manner, the network can be expanded. This allows deployment to start with one country, and addition of countries later on.

[00135] In an embodiment, different certification schemes can be used in order to establish certificates for trusted service providers, for example.

[00136] In one scheme, government keys may be used directly to certify trusted service providers. However, given that the number of banks is rather large and that the number of government keys is expected to be low, this may become inefficient and cumbersome. Instead, one may add an additional certification record onto the ledger registering "banks" or financial authorities. These local authorities are then given the right to certify banks and other trusted service providers. In principle, this hierarchy can be arbitrarily deep, but in practice is good to limit the depth as much as possible for security and bureaucracy reasons. Trusted circles may be utilized, for example.

[00137] In the lack of authority roles on the system, an alternative method to certify banks, corporations, and transaction related devices is by plain majority voting. While this could work for small local communities, it is possible to break down if scaled up. In addition, this method would have to rely on proof-of-work (POW) as the system in nature is entirely untrusted.

[00138] In an embodiment, reoccurring transfers may be utilized. It may also include the ability to authorize a person to carry out a transfer on behalf of the user of the actual transfer.

[00139] In an embodiment, it is possible to have different degrees of authorization for different types of end users. This may involve granting limited transfer and/or payment rights to different end users and service providers. These details are allowed to vary from country to country.

[00140] Embodiments of the invention, may have certain prerequisites.

[00141] In relation of certification of banks (110, 120), following may apply.

[00142] At the time of joining the blockchain (170), bank nodes must be certified by a trusted third party.

[00143] When a bank (110, 120) is certified successfully, its reserved name is linked to a public key on the blockchain (170). This map is public on the blockchain (170) (or elsewhere maintained by a trusted party, such as the server (130)).

[00144] The map can be read by any node (120, 140, 160) on the blockchain (170), but can only be edited by dedicated nodes (e.g. the certification body). This can be implemented in a smart contract as part of the protocol. [00145] Some transactions are reserved for banks (1 10, 120) only.

[00146] Certified banks (110, 120) participate in a public ledger, for instance

Ethereum.

[00147] The system (100, 200) does not need to be an open or existing network but the solution can work equally well on a closed network, or a dedicated open network.

[00148] Every bank (1 10, 120) has an associated private key that identifies the bank on the blockchain (170).

[00149] Every bank (1 10, 120) is responsible for keeping a record of balances of all the accounts it holds. This information is privately held and the banks (110, 120) are trusted to maintain up-to-date records.

[00150] Each user (140, 160) has a shared key with their bank (1 10, 120) that is distributed between the bank (1 10, 120) and the user (140, 160) at the start and is valid for the lifetime of the relationship. SK(user A, bank A) is the shared key for a pair (user A, bank A), for example. Each bank (110, 120) also has a shared key with every other bank (1 10, 120). These shared keys establish a permanent secure channel between the parties, and they are used only to encrypt more temporary, random passwords. Since these shared keys only encrypt random plaintext, they are minimally exposed to correlation attacks that could aim to unveil them.

[00151] All participants of the protocol must have the ability to generate and share a one-time key (OTK) or a nonce (the implementation will elaborate on how a onetime key might be used, but using a nonce is a viable alternative implementation that is conceptually equivalent).

[00152] Fig. 3 shows a flow diagram (300) illustrating a computer-implemented method for secure transaction transfer between trusted service provider apparatuses. The method starts in step (310).

[00153] In step (315), an account request is received by a first trusted service provider apparatus from a first user device, the account request comprising a public key of the first user and a public key of the first trusted service provider.

[00154] In an embodiment, an inter-bank transfer example scenario is explained. As an initial step, setting up a banking account is needed.

[00155] To enroll with a trusted service provider, such as a bank, a first user device transmits a public request consisting of her public key and the trusted service provider's, such as a bank's, public key. In order to create a new banking account for a first user (user A), the bank generates a first account key (A) using a random number generator.

[00156] In step (320) of Fig. 3, it is illustrated that a first account key (A) is generated by the first trusted service provider apparatus using a first random number generator, and a second account key (B) is generated by a second trusted service provider apparatus using a second random number generator. These account keys (A, B) may be generated any time by the trusted service providers when establishing new accounts or when changing account keys for existing accounts due to, for example, security reasons.

[00157] In step (325), the first account key (A) is hashed by the first trusted service provider apparatus (e.g. a first bank apparatus) to generate a first hashed account key (hash-A).

[00158] In step (330), the first hashed account key (hash-A) is recorded by the first trusted service provider apparatus associated with the public key (PK-A) of the first user as an account key transaction in a block to a blockchain representing a public ledger. This states, for example, the bank's intention of approving the first user as their customer.

[00159] In an embodiment, the first trusted service provider generates and records a transaction (TX0) to the blockchain of the distributed ledger. The transaction (TX0) is encrypted with the first account key (A) and comprising identifier of the first user (user A) and some additional account information, such as initial fund information, for example.

TX0 = {encrypt(account_key_A, "update(initial_funds, user A)")}

[00160] In step (335), the first account key (A) is transmitted by the first trusted service provider apparatus, to the first user device.

[00161] The first account key (A) is communicated in private to the first user. Such account keys for different users are meant to be less permanent than shared keys, such as a shared key SK(user A, bank A) between the first user and the first trusted service provider (e.g. first bank). Account keys (such as the first account key (A)) may be renewed and even given to a third party, such as in the case of the first user wanting to change the trusted service providers.

[00162] As a next step, a transfer request is received.

[00163] In an embodiment, the first user (user A) notifies her first trusted service provider (e.g. bank A) of her intent to transfer asset of value information (e.g. $100) to a second user (user B) who holds an account with a second trusted service provider (e.g. bank B). Information on the first user's (user A) transfer intent may be communicated in a number of ways.

[00164] In an embodiment, a blockchain may be used for sending the transfer request. In such case, the first user (user A) may record a transaction, wherein the transfer request is received from the first user device via the blockchain, wherein the first user device has recorded the transfer request to the blockchain as a transaction in a block, the transaction comprising:

a first part comprising a transfer message of the transfer value and a second user account identifier, and the transaction identifier, the first part is encrypted with a first one-time key (OTK); and

the second part comprising the first one-time key (OTK) encrypted with a shared key (SK) of the first user and the first trusted service provider.

[00165] For example, the transaction (TX1 ) for the transfer request may comprise something like following:

TX1 = {encrypt(OTK, "transfer($100, user B)" + id); encrypt(SK(user A, bank A), OTK)}

[00166] In an embodiment, as a result, both the first user (user A) and the first trusted service provider (bank A) may disclose the one-time key (OTK) at a later time to an audit without compromising the permanent shared key SK(user A, bank A). The transaction identifier (id) is used to link the following relevant transaction back to the original user request. Transaction (TX1 ) is signed with the first user's (user A) private key (PR-A), so every node can verify it originates from user A.

[00167] In an embodiment, the blockchain approach may be preferred for transfer request transmission, but other viable implementations of the transfer request include transmitting:

a) directly via a secure channel (e.g. an online interface provided by the trusted service provider), or

b) as an encrypted point-to-point (P2P) message.

The blockchain approach described allows the trusted service provider to prove that its further actions were in response to the user instruction and allows the user to prove her original intent in case the trusted service provider has made an error.

[00168] Eventually, the first trusted service provider (e.g. bank A) has received the first user's (user A) intent to transfer asset information (e.g. $100) to a second user (user B).

[00169] In step (340) of Fig. 3, a transfer request is received by the first trusted service provider apparatus from the first user device, the transfer request comprising a transfer value and an identifier for a second user.

[00170] As a next step, a transfer is generated and recorded.

[00171] As disclosed, the first trusted service provider (e.g. bank A) is notified of the transaction. The first trusted service provider may follow for transactions involving it or the first user (user A) may use a side channel to alert the first trusted service provider (bank A), for example. If the first user (user A) has sufficient funds to execute the requested transaction, the first trusted service provider (e.g. bank A) performs the following steps:

1. Update first user (user A) account

2. Inform a second trusted service provider (E.g. bank B) to update a second user (user B) account

3. Publish a record of the transaction on the blockchain such that only parties with a right to disclose can decrypt the transaction. In this example, the first trusted service provider (Bank A), the second trusted service provider (Bank B), the first user (user A) and the second user (user B) are the only parties who have a right to disclose the content of this transaction to an audit, for example, at a later date. No other nodes can infer the contents of the transaction.

[00172] To achieve the above objectives the first trusted service provider (bank A) executes a batch of transactions:

TX2 = {encrypt(account_key_A, "update(user A, new_balance*)" + id);

^*new_balance = userA_balance - $100 - transaction_fee (the fee is optional)

[00173] Following the identical logic as seen in transaction (TX1 ), only the trusted service provider and the user can read the transaction (TX2) message and verify the transaction when prompted.

TX3 = {encrypt(OTK1 , "add_funds(user B, $100)" + id); encrypt(SK(bank A, bank B), OTK1 )}

[00174] In the same manner, transaction (TX3) is intended between the first trusted service provider (e.g. bank A) and the second trusted service provider (e.g. bank B) only and prompts the second trusted service provider (e.g. bank B) to update the balance of the second user (user B). Concurrency of updates is of concern: transactions (TX2) and (TX3) must happen as one atomic transaction. This can be done by executing transactions (TX2) and (TX3) as one transaction or at node end by looking at transaction id's and ordering updates according to the order in which transaction id's are first seen.

[00175] In step (345) of Fig. 3, updated balance information is recorded (TX2) by the first trusted service provider apparatus in response to and based on the transfer request, within a balance transaction in a block to the blockchain, the balance transaction further comprising the first account key (A) and a transaction identifier;

[00176] In step (350), a balance update transaction (TX3) is recorded by the first trusted service provider apparatus, of a block to the blockchain, the balance update transaction comprising a first part comprising balance update information corresponding to the transfer value, an identifier of the second user and the transaction identifier, the first part is encrypted with a first one-time key (OTK); and the second part comprising the first one-time key (OTK) encrypted with a shared key (SK) of the first trusted service provider and a second trusted service provider.

[00177] Finally, the second trusted service provider (e.g. bank B) is notified of the transaction and updates the second user (user B) balance or reject the transaction in response.

[00178] Further in step (350), a balance update transaction (TX4) is recorded by the second trusted service provider apparatus, of a block to the blockchain, the balance update transaction comprising a first part comprising balance update information corresponding to the transfer value, the identifier of the second user and the transaction identifier, the first part is encrypted with the second account key (B).

[00179] In an embodiment, the transaction may be accepted or rejected in step 355 of Fig. 3.

[00180] In an embodiment, when accepting the transaction, the second trusted service provider (e.g. bank B) executes the transactions (TX4) and (TX5):

TX4 = {encrypt(account_key_B, "update(user B, balance_B + $ 00)" + id } TX5 = {encrypt(OTK2, "accept" + id), encrypt(SK(bank A, bank B), OTK2)}

[00181] The transactions (TX4) and (TX5) may be linked into one transaction.

[00182] In step (355), a confirmation transaction (TX4) is recorded by the second trusted service provider apparatus in response to the balance update transaction (TX3), of a block to the blockchain, the confirmation transaction (TX4) comprising a first part comprising confirmation and the transaction identifier, the first part is encrypted with a second one-time key (OTK2); and a second part comprising the second one-time key (OTK2), the second part is encrypted with a shared key (SK) of the first and the second trusted service provider.

[00183] In an embodiment, the balance update transaction and the confirmation transaction are arranged to be linked within the same block to the blockchain.

[00184] In an embodiment, when rejecting the transaction, the second trusted service provider (e.g. bank B) executes the transaction (TX6):

TX6 = {encrypt(OTK3, "reject" + id), encrypt(SK(bank A, bank B), OTK3)}

[00185] In this case the first trusted service provider (e.g. bank A) is forced to revert (TX2) and (TX3) by issuing a new transaction to re-credit the first user (user A).

[00186] The blockchain's purpose for this is step is to ensure the order of transactions are agreed upon between all involved parties as well as to make the data verifiable. In one embodiment it is preferable to use a single (OTK) through transactions (TX1 -TX6) such that every party involved in the transaction (trusted service providers and users) can review the transaction stream. This ensures that the second user (user B) can deliver goods (in case of a sale) to the first user (user A) already after recording (TX3) if she feels sure that the second trusted service provider (e.g. bank B) will not reject the transaction.

[00187] In step (355), as disclosed, the second trusted service provider apparatus may alternatively reject the balance update information of the balance update transaction. Then, a reject transaction (TX6) is recorded by the second trusted service provider apparatus in response to the rejected balance update information, of a block to the blockchain, the reject transaction comprising a first part comprising reject information and the transaction identifier, the first part is encrypted with a third one-time key (OTK3); and a second part comprising the third one-time key (OTK3), the second part is encrypted with a shared key (SK_S1 -S2) of the first and the second trusted service provider.

[00188] In an embodiment, in step (360), the first trusted service provider apparatus may record a second balance update transaction in a block to the blockchain, the second balance update transaction comprising a first part comprising balance update information corresponding to the transfer value reverted and an identifier of the first user and the transaction identifier, the first part is encrypted with a fourth one-time key (OTK4); and the second part comprising the fourth one-time key (OTK4) encrypted with the shared key (SK) of the first trusted service provider and the second trusted service provider.

[00189] As a next step, accounts may be updated within different trusted service providers.

[00190] In addition to keeping the order of transactions on the ledger, the trusted service providers may provide a mechanism to make it publicly verifiable the fund information a user have on her account. This can be done by the first trusted service provider (e.g. bank A) by recording a transaction:

TX7 = {encrypt(account_key_A, new_balance) }

[00191] This transaction (TX7) may be achieved by means of a first user account key (A) that may be given to a relevant party (e.g. auditors) without compromising shared key SK(bankA, userA).

[00192] Likewise the second trusted service provider (e.g. bank B) may publish another transaction updating the funds available for the second user (user B). Anybody who is given access to the corresponding second user account key (B) can then verify that the trusted service provider confirmed that new balance is available.

[00193] Contrary to the shared keys SK(bankX, userX), account keys (A, B) can be renewed after a public disclosure or in response to pre-defined security procedure, for example.

[00194] In an embodiment, the method may comprise recording, by the first trusted service provider apparatus, in response to and based on the second balance update transaction, updated balance information within the second balance transaction in a block to the blockchain, the second balance transaction further comprising the transaction identifier and encrypted using the first account key (A).

[00195] In step (365), In an embodiment, the method may further comprise recording, by the first trusted service provider apparatus, a new balance transaction in a block to the blockchain, the new balance transaction comprising new balance information of the first user, encrypted with the first account key (A).

[00196] In an embodiment, the method may further comprise recording, by the second trusted service provider apparatus, a new balance transaction in a block to the blockchain, the new balance transaction comprising new balance information of the second user, encrypted with the second account key (B).

[00197] Due to previous step, it is easy for anybody to verify the contents of a banking account given the appropriate information. Therefore, in order for a user to switch from the first trusted service provider (e.g. bank A) to the second trusted service provider (e.g. bank B), all the user needs to do is make her current bank publish a message (either on or off blockchain), that he or she wants to change bank and send the account_key (A, B) privately.

TX8 = {encrypt(SK(user A, bank B), account_key)}

[00198] Thus, the second trusted service provider (e.g. bank B) can easily verify the contents of the first user (user A) banking account. The second trusted service provider (e.g. bank B) can now follow the steps disclosed earlier to set up a banking account for the first user (user A).

[00199] In step (370), the method may further comprise recording, by the first trusted service provider apparatus, an account change transaction (TX8) of a block to the blockchain, the account change transaction comprising the first account key (A) encrypted with a shared key (SK_A-S2) of the first user and the second trusted service provider.

[00200] In an embodiment, the method may further comprise defining a blockchain record comprising certified first users; and a blockchain record comprising certified second users.

[00201] In an embodiment, the method may further comprise defining a blockchain record comprising certified first trusted service providers and a blockchain record comprising certified second trusted service providers.

[00202] In an embodiment, at least one transaction is added as part of a subsequent block to the blockchain according to a consensus algorithm.

[00203] In an embodiment, the method may further comprise assigning a node identifier to each node of the first user, the second user, the first trusted service provider and the second trusted service provider.

[00204] In an embodiment, the node identifier comprising a public key.

[00205] In an embodiment, the first user device, the second user device, the first trusted service provider apparatus and the second trusted service provider apparatus are connected to a wide area communication interface.

[00206] In an embodiment, the blockchain is configured to be protected by a proof algorithm comprising at least one of a proof-of-work, proof-of-stake and majority- voting algorithm. The method ends at step (380).

[00207] Fig. 4 presents an example block diagram of a node of device or apparatus (1 10, 120, 140, 160) in which various embodiments of the invention may be applied. The device or apparatus (110, 120, 140, 160) may be a smart device, a computer device, a user device, a user wearable device, an Intemet-of-Things (loT) device or a hub device. All elements described in Fig. 4 are not necessary to be implemented in the same device.

[00208] In an embodiment, the user interface (440) may be implemented also in another device connected via a communication interface (450) to the device (110, 120, 140, 160). Such device may comprise a mobile phone, a smart phone, or a tablet, for example. In an embodiment, the device (110, 120, 140, 160) may communicate with a plurality of users.

[00209] The general structure of the device (110, 120, 140, 160) comprises a user interface (440), a communication interface (450), a processor (410), and a memory (420) coupled to the processor (410). The device (110, 120, 140, 160) further comprises software (430) stored in the memory (420) and operable to be loaded into and executed in the processor (410). The software (430) may comprise one or more software modules and can be in the form of a computer program product. Not all elements of Fig. 4 are necessary but optional for the device ( 10, 120, 140, 160).

[00210] The processor (410) may be, e.g., a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a graphics processing unit, or the like. Fig. 4 shows one processor (410), but the device (110, 120, 140, 160) may comprise a plurality of processors.

[00211] The memory (420) may be for example a non-volatile or a volatile memory, such as a read-only memory (ROM), a programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), a random-access memory (RAM), a flash memory, a data disk, an optical storage, a magnetic storage, a smart card, or the like. The device (110, 120, 140, 160) may comprise a plurality of memories. The memory (420) may be constructed as a part of the device (110, 120, 140, 160) or it may be inserted into a slot, port, or the like of the device (110, 120, 140, 160) by a user. The memory (420) may serve the sole purpose of storing data, or it may be constructed as a part of an apparatus serving other purposes, such as processing data.

[00212] The user interface (440) may comprise circuitry for receiving input from a user of the device (1 10, 120, 140, 160), e.g., via a keyboard, a touchpad, a motion sensor, a touch-screen of the device (110, 120, 140, 160) speech recognition circuitry, gesture recognition circuitry or an accessory device, such as a headset or a remote controller, for example. Furthermore, the user interface (440) may comprise circuitry for providing output for the user via a display, a speaker, a touch-sensitive display or a tactile feedback device, for example.

[00213] The communication interface module (450) implements at least part of data transmission. The communication interface module (450) may comprise, e.g., a wireless or a wired interface module. The wireless interface may comprise such as a WLAN, Bluetooth, infrared (IR), radio frequency identification (RF ID), NFC, GSM/GPRS, CDMA, WCDMA, or LTE (Long Term Evolution) radio module. The wired interface may comprise such as universal serial bus (USB), HDMI, SCART or RCA, for example. The communication interface module (450) may be integrated into the device (1 10, 120, 140, 160) or into an adapter, card or the like that may be inserted into a suitable slot or port of the device (1 10, 120, 140, 160). The communication interface module (450) may support one radio interface technology or a plurality of technologies. The communication interface module (450) may support one wired interface technology or a plurality of technologies. The device (110, 120, 140, 160) may comprise a plurality of communication interface modules (450).

[00214] In an embodiment, the communication interface module (450) may comprise location modules for tracking location of the device (110, 120, 140, 160). Such location modules may comprise a module for satellite based global positioning system (e.g. GPS), a module for cellular based positioning system, a module for wireless non-cellular positioning system (e.g. Wi-Fi) or a module for hybrid positioning system, for example.

[00215] A skilled person appreciates that in addition to the elements shown in Fig. 4, the device (1 10, 120, 140, 160) may comprise other elements, such as microphones, speakers, sensors, cameras, as well as additional circuitry such as input/output (I/O) circuitry, memory chips, application-specific integrated circuits (ASIC), processing circuitry for specific purposes such as source coding/decoding circuitry, channel coding/decoding circuitry, ciphering/deciphering circuitry, and the like. Additionally, the device (1 10, 120, 140, 160) may comprise a disposable or rechargeable battery (not shown) for powering when external power if external power supply is not available.

[00216] In an embodiment, the device (110, 120, 140, 160) may comprise a sensor (not shown) for providing metadata associated to the transaction data (e.g. biometric information). The metadata may comprise at least one of the following: temperature information; pressure information; fingerprint information; retinal scan information; movement information; location information; and humidity information.

[00217] In an embodiment, the device (110, 120, 140, 160) comprises speech or gesture recognition means. Using these means, a pre-defined phrase or a gesture may be recognized from the speech or the gesture and translated into control information for the device (1 10, 120, 140, 160).

[00218] User wearable devices and sensors thereof provided in various may be used for example in fingerprint detection and retinal scan detection, for example.

[00219] Fig. 5 shows a block diagram of a server apparatus (130) of an example embodiment. The general structure of the server apparatus (130) comprises a processor (510), and a memory (520) coupled to the processor (510). The server apparatus (130) further comprises software (530) stored in the memory (520) and operable to be loaded into and executed in the processor (510). The software (530) may comprise one or more software modules and can be in the form of a computer program product.

[00220] The processor (510) may be, e.g., a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a graphics processing unit, or the like. Fig. 5 shows one processor (510), but the server apparatus (130) may comprise a plurality of processors.

[00221] The memory (520) may be for example a non-volatile or a volatile memory, such as a read-only memory (ROM), a programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), a random-access memory (RAM), a flash memory, a data disk, an optical storage, a magnetic storage, a smart card, or the like. The server apparatus (130) may comprise a plurality of memories. The memory (520) may be constructed as a part of the server apparatus (130) or it may be inserted into a slot, port, or the like of the server apparatus (130) by a user. The memory (520) may serve the sole purpose of storing data, or it may be constructed as a part of an apparatus serving other purposes, such as processing data.

[00222] The communication interface module (550) implements at least part of data transmission. The communication interface module (550) may comprise, e.g., a wireless or a wired interface module. The wireless interface may comprise such as a WLAN, Bluetooth, infrared (IR), radio frequency identification (RF ID), GSM/GPRS, CDMA, WCDMA, or LTE (Long Term Evolution) radio module. The wired interface may comprise such as Ethernet or universal serial bus (USB), for example. The communication interface module (550) may be integrated into the server apparatus (130), or into an adapter, card or the like that may be inserted into a suitable slot or port of the server apparatus (130). The communication interface module (550) may support one radio interface technology or a plurality of technologies. Configuration information between the nodes (1 10, 120, 140, 160) and the system server (130) may be transceived using the communication interface (550). Similarly, account creation information between the system server (130) and a service provider may be transceived using the communication interface (550).

[00223] An application server (540) provides application services e.g. relating to the user accounts stored in a user database (570) and to the service information stored in a service database (560). The service information may comprise content information, content management information or metrics information, for example. The service information may also comprise information relating to transaction data, account data, history data of earlier transaction data, or blockchains, for example.

[00224] A skilled person appreciates that in addition to the elements shown in Fig. 5, the server apparatus (130) may comprise other elements, such as microphones, displays, as well as additional circuitry such as input/output (I/O) circuitry, memory chips, application-specific integrated circuits (ASIC), processing circuitry for specific purposes such as source coding/decoding circuitry, channel coding/decoding circuitry, ciphering/deciphering circuitry, and the like.

[00225] In an embodiment, in case of a trusted circle, a trusted circle may be initially setup by any trusted node within the system according to pre-defined settings. Hashing and encrypting may be balanced for nodes having better processing power, security, memory capacity and/or powering. Hashing and encryption may also be user changeable based on the user settings or based on the local system administrator, for example.

[00226] Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that an improved construction and storage of transaction data of blockchain is provided that allows transfer transaction data item secure processing in a blockchain network.

[00227] Another technical effect of one or more of the example embodiments disclosed herein is that security of sensitive transaction data transmission between different devices and stakeholders is improved. Another technical effect of one or more of the example embodiments disclosed herein is that reliability of transaction data, relating to a plurality of nodes, is improved.

[00228] Another technical effect of one or more of the example embodiments disclosed herein for privacy is that only trusted service (banks) know the current balances while all nodes can participate in verification. The protocol can run over any type of open or closed network while maintaining the privacy.

[00229] Another technical effect of one or more of the example embodiments disclosed herein for infrastructure reuse is that the use of this protocol does not need a dedicated network. While only nodes with the need to know can see the content of the transaction, all blockchain nodes are responsible for maintaining the network.

[00230] Another technical effect of one or more of the example embodiments disclosed herein for total order is that while only nodes with the need to know can see the content of the transaction, all blockchain nodes ensure the ledger is consistent and the majority consensus is used to establish an indisputable order of the transactions.

[00231] Another technical effect of one or more of the example embodiments disclosed herein for verifiability is that while only nodes with the need to know can see the content of the transaction, any transaction can be verified in the case of dispute. Verification requires the involvement of any party with the right to disclose (in the above example only the parties directly involved in a transaction).

[00232] Another technical effect of one or more of the example embodiments disclosed herein for provenance is that the existence of a consistent record of all transactions affords a trivial implementation of services such as recurring payments via minimizing the opportunity for dispute.

[00233] Another technical effect of one or more of the example embodiments disclosed herein for speed is that the solution potentially improves on the speed of certain transfers that require use of a correspondent bank (traditionally accomplished with SWIFT).

[00234] Another technical effect of one or more of the example embodiments disclosed herein for error resilience is that the solution makes it easy to correct any errors that may occur due to trusted service provider's (e.g. bank) actions (outside of the blockchain). This is achieved by keeping a transparent log of all transactions.

[00235] Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that an improved transaction data service system is provided.

[00236] If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the before-described functions may be optional or may be combined.

[00237] Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

[00238] It is also noted herein that while the foregoing describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications, which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. A computer-implemented method for secure transaction transfer between trusted service provider apparatuses, the method comprising:

receiving, by a first trusted service provider apparatus, an account request from a first user device, the account request comprising a public key of the first user and a public key of the first trusted service provider;

2. The method of claim 1 , wherein the transfer request is received from the first user device via the blockchain, wherein the first user device has recorded the transfer request to the blockchain as a transaction in a block, the transaction comprising:

a first part comprising a transfer message of the transfer value and a second user account identifier, and the transaction identifier, the first part is encrypted with a first one-time key (OTK1 '); and

the second part comprising the first one-time key (OTKV) encrypted with a shared key (SK_A-S2) of the first user and the first trusted service provider.

3. The method of claim 2, wherein the transaction identifier is configured to link a following transaction to the transfer request.

4. The method of any of claims 1 to 3, further comprising:

signing the transfer request with a private key of the first user for verifying that the transfer request originates from the first user.

5. The method of claim 1 , wherein the transfer request is received from the first user device directly via a secure channel.

6. The method of claim 5, wherein secure channel comprising an online communication interface provided by the first trusted service provider.

7. The method of claim 1 , wherein the transfer request is received from the first user device directly via an encrypted point-to-point (P2P) message over a public data network.

8. The method of any of claims 1 to 7, further comprising:

recording, by the second trusted service provider apparatus, a balance update transaction in a block to the blockchain, the balance update transaction comprising: a first part comprising balance update information corresponding to the transfer value, the identifier of the second user and the transaction identifier, the first part is encrypted with the second account key (B).

9. The method of claim 8, further comprising:

10. The method of claim 9, wherein the balance update transaction and the confirmation transaction are arranged to be linked within the same block to the blockchain.

1 1. The method of any of claims 1 to 7, further comprising:

12. The method of claim 1 1 , further comprising:

recording, by the first trusted service provider apparatus, a second balance update transaction in a block to the blockchain, the second balance update transaction comprising: a first part comprising balance update information corresponding to the transfer value reverted and an identifier of the first user and the transaction identifier, the first part is encrypted with a fourth one-time key (OTK4); and

the second part comprising the fourth one-time key (OTK4) encrypted with the shared key (SK_S1 -S2) of the first trusted service provider and the second trusted service provider.

13. The method of claim 12, further comprising:

recording, by the first trusted service provider apparatus, in response to and based on the second balance update transaction, updated balance information within the second balance transaction in a block to the blockchain, the second balance transaction further comprising a transaction identifier and encrypted using the first account key (A).

14. The method of any of claims 1 to 13, further comprising:

15. The method of any of claims 1 to 14, further comprising:

recording, by the second trusted service provider apparatus, a new balance transaction in a block to the blockchain, the new balance transaction comprising new balance information of the second user, encrypted with the second account key (B).

16. The method of any of claims 1 to 5, further comprising:

17. The method of any of claims 1 to 16, further comprising:

18. The method of any of claims 1 to 17, further comprising:

19. The method of any of the claims 1 to 18, wherein at least one transaction is added as part of a subsequent block to the blockchain according to a consensus algorithm.

20. The method of any of claims 1 to 19, further comprising:

21. The method of claim 20, wherein the node identifier comprising a public key.

22. The method of any of claims 1 to 21 , wherein the first user device, the second user device, the first trusted service provider apparatus and the second trusted service provider apparatus are connected to a wide area communication interface.

23. The method of any of claims 1 to 22, wherein the blockchain is configured to be protected by a proof algorithm comprising at least one of a proof-of-work, proof-of- stake and majority-voting algorithm.

24. The method of any of claims 1 to 23, comprising:

generating a one-time key (OTK) by a user device, a first or a second trusted service provider apparatus; generating a shared key (SK_S1 -S2) of the first trusted service provider and the second trusted service provider;

25. An apparatus comprising:

a communication interface for transceiving information;

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to:

receive an account request from a first user device, the account request comprising a public key of the first user and a public key of the first trusted service provider;

record in response to and based on the transfer request, updated balance information within a balance transaction in a block to the blockchain, the balance transaction further comprising a transaction identifier and encrypted using the first account key (A); generate a first one-time key (OTK1 );

a first part comprising balance update information corresponding to the transfer value, an identifier of the second user and the transaction identifier, the first part is encrypted with the first one-time key (OTK1 ); and the second part comprising the first one-time key (OTK1 ) encrypted with a shared key (SK_S1-S2) of the first trusted service provider and a second trusted service provider.

26. The apparatus of claim 25 comprising a plurality of user devices.

27. A computer program embodied on a computer readable non-transitory medium comprising computer executable program code, which when executed by at least one processor of an apparatus, causes the apparatus to:

generate a first account key (A) using a first random number generator;

generate a first one-time key (OTK1 );

record a balance update transaction in a block to the blockchain, the balance update transaction comprising: a first part comprising balance update information corresponding to the transfer value, an identifier of the second user and the transaction identifier, the first part is encrypted with the first one-time key (OTK1 ); and