Software And Hardware Based Resource Allocation ...

1

Software And Hardware Based Resource Allocation Using Distributed Consensus Network

Dr. Avtar Sehra

29 October 2015

5

ABSTRACT A computer-implemented method for managing an allocation of resources corresponding to assets using a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network is disclosed. The method comprises receiving a transaction record from the ledger,

10

the transaction record comprising an asset identifier which identifies an asset and an entity identifier which identifies an entity; identifying a resource corresponding to the asset; recording an association between the entity and the asset; and allocating at least a portion of the resource to the entity. [FIG. 1]

15

TECHNICAL FIELD [1]

The present invention relates to resource allocation, and particularly

time-based and event-based resource allocation using a distributed ledger in a distributed consensus network. BACKGROUND 20

[2]

There are many assets which grant the owner of the asset some kind of

resource. For example, a semaphore grants the owner exclusive access to a particular programming resource. Typically these are assigned ad hoc when the owner proves their ownership. Thus proof of ownership is an important precursor to resource allocation. 25

[3]

Conventionally, the ownership of assets could be entered into a

centralised register. The register then acts as the single point of authority for

2

ownership (and thus entitlement to resources). However, this approach has weaknesses. There is a requirement for every asset transfer to be recorded in the register. For a large number of transfers, it can be a very complicated task to ensure that these updates are performed correctly and in order. In addition, the 5

registrar may update the register inaccurately. Since the register is the single point of verification, it can be nearly impossible to correct such mistakes, without reconstructing the register anew from the initial transactions. [4]

One alternative to a centralised register is to rely on physical tokens

(such as a deed). The holder of the token is deemed to be the owner of the 10

asset. This provides an unambiguous method of proving the ownership of an asset. However, such physical objects are cumbersome and insecure, as they can be lost, stolen or duplicated. [5]

More recently, there have been efforts to establish a distributed register

approach which combines the benefits of a centralised register with the benefits 15

of a token. These can use a distributed consensus system such as Bitcoin, the technical background of which is described in Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System” (2008) which is incorporated by reference. [6]

20

For example, Colored Coins (and similar protocols) uses metadata in

Bitcoin transactions to associate an asset with an entity. Once such a transaction is entered into the blockchain, it is possible to independently verify that the transaction has taken place, and who the legitimate current owner of the asset is. Moreover, the nature of a distributed consensus system means that it is practically impossible to fraudulently transfer an asset without the consent of the

25

original owner, providing a secure and transparent method of asset transfer and ownership validation. [7]

However, all of these methods only allow for an asset to be transferred

from one entity to another. None of these address how resources can be efficiently and transparently allocated based on asset ownership. 30

SUMMARY OF INVENTION [8]

In an aspect, there is provided a computer-implemented method for

managing a time-based allocation of resources corresponding to assets using a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network, the method comprising: receiving a

3

transaction record from the ledger, the transaction record comprising an asset identifier which identifies an asset and an entity identifier which identifies an entity; identifying a time corresponding to the association; identifying a resource corresponding to the asset; recording an association between the entity and the 5

asset; and allocating at least a portion of the resource to the entity based on the identified time. [9]

In this manner, any resources can be efficiently allocated to the correct

entity based on a time of the association between the entity and the asset, rather than just the current entity associated with the asset. Moreover, this allocation 10

process is transparent, as all the information required is available in the distributed ledger, which is available from each of the devices in the distributed consensus network. [10]

The association can be recorded using any suitable mechanism.

However, in preferred embodiments, recording an association between an entity 15

and the asset based on the transaction record comprises: forming a mapping between the entity and the asset based on the entity identifier and the resource identifier; identifying a current node in a tree structure, the current node being a node that corresponds to a mapping between the asset and another entity; and appending a new leaf node to the current node based on the mapping.

20

[11]

A tree structure has been found to be particularly suitable for recording

the associations between the asset and different entities over the life of the asset. This is because associations inherently tend to form a tree structure with the initial genesis transaction being the root of the tree structure. [12] 25

A time corresponding to the association can be identified using any

suitable approach known to the skilled person. However, in preferred embodiments, identifying a time corresponding to the association comprises: retrieving a time from the transaction record; and recording the time as the start time of the association between the entity and the asset. In this manner, the transaction record tends to provide all the necessary detail to assessing when an

30

association began. [13]

In preferred embodiments, this further comprises: determining a second

association between the resource and a second entity based on the ledger, the second association having a start time earlier than the retrieved time; and recording the retrieved time as the end time of the second association. Since a

4

transaction tends to delimit an earlier association from a later association, it is beneficial to use the time of the transaction as the end time of the earlier association and the start time of the later association. This ensures that there is no intermediate time, which could complicate resource allocation. 5

[14]

Resources can be allocated using any suitable mechanism. However,

preferred embodiments, allocating at least a portion of the resource to the entity based on the identified time comprises: calculating a duration of the association based on the start time and one of an end time or a current time; and allocating at least a portion of the resource to the entity based on the calculated duration. 10

This reflects that resources are typically allocated based on the duration of the association. [15]

Assets may be unique such that they can only be transferred as a whole

in transactions. However, in cases, assets may be fungible, such that any number (or even fractions) can be transferred. Thus, in preferred embodiments, 15

the transaction record further comprises a quantity, the method further comprising: recording the retrieved quantity as the quantity of the asset in the association; and wherein allocating at least a portion of the resource to the entity based on the identified time is further based on the recorded quantity. This allows a single translation to relate to multiple (or fractions of) assets.

20

[16]

Allocating may take place at any point. However, in preferred

embodiments, allocating at least a portion of the resource to the entity is performed periodically, such as annually or monthly. [17]

Allocating resources may occur using any known technique. However, in

preferred embodiments, allocating at least a portion of the resource to the entity 25

comprises: identifying a recipient address associated with the entity; and transferring the portion of the resource to the recipient address. This allows the resource allocation process to occur automatically, improving efficiency. Preferably, the recipient address corresponds to an account maintained by a banking organisation and the resource is money. Additionally or alternatively, the

30

recipient address is the entity identifier or a hash of the entity identifier, and transferring the portion of the resource to the recipient address comprises: creating a transaction record comprising the entity identifier and a resource identifier which identifies the portion of the resource; and initiating the addition of the transaction record to the distributed ledger. By using the distributed ledger

35

for both assessing an asset association and allocating the resources, there is a

5

reduced overhead in needing to maintain multiple systems. Moreover, the distributed ledger is a secure and transparent approach. [18]

In a further aspect, there is provided a computer-implemented method

for managing an event-based allocation of resources corresponding to assets 5

using a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network, the method comprising: receiving a transaction record from the ledger, the transaction record comprising an asset identifier which identifies an asset, and a first entity identifier which identifies a first entity; identifying a resource corresponding to the asset; recording an

10

association between the first entity and the asset; monitoring for the receipt of a notification of a predetermined trigger event occurring; and if the notification is received, allocating at least a portion of the resource to the first entity. [19]

In this manner, any resources can be selectively allocated to the correct

entity based on whether the trigger event occurs. The existence of the event15

based allocation is freely provided in the distributed ledger, which is available from each of the devices in the distributed consensus network, which provides transparency and security. [20]

The association can be recorded using any suitable mechanism.

However, in preferred embodiments, recording an association between the first 20

entity and the asset based on the transaction record comprises: forming a mapping between the first entity and the asset based on the first entity identifier and the resource identifier; identifying a current node in a tree structure, the current node being a node that corresponds to a mapping between the asset and another entity; and appending a new leaf node to the current node based on

25

the mapping. [21]

A tree structure has been found to be particularly suitable for recording

the associations between the asset and different entities over the life of the asset. This is because associations inherently tend to form a tree structure with the initial genesis transaction being the root of the tree structure. 30

[22]

In preferred embodiments, the transaction record comprises an

authenticator identifier which identifies an authenticator, and receiving a notification of a predetermined trigger event occurring comprises: receiving a notification of a predetermined trigger event occurring from the authenticator. This is a convenient way in which to assess whether a trigger event occurs. By

6

predetermining the authenticator in the transaction record, it simplifies the assessment process. [23]

Allocating resources may occur using any known technique. However, in

preferred embodiments, allocating at least a portion of the resource to the entity 5

comprises: identifying a recipient address associated with the entity; and transferring the portion of the resource to the recipient address. This allows the resource allocation process to occur automatically, improving efficiency. Preferably, the recipient address corresponds to an account maintained by a banking organisation and the resource is money. Additionally or alternatively, the

10

recipient address is the entity identifier or a hash of the entity identifier, and transferring the portion of the resource to the recipient address comprises: creating a transaction record comprising the entity identifier and a resource identifier which identifies the portion of the resource; and initiating the addition of the transaction record to the distributed ledger. By using the distributed ledger

15

for both assessing an asset association and allocating the resources, there is a reduced overhead in needing to maintain multiple systems. Moreover, the distributed ledger is a secure and transparent approach. [24]

In preferred embodiments, the transaction record further comprises a

second entity identifier which identifies a second entity, and an expiration time, 20

the method further comprising: if no notification is received before the expiration time, allocating at least a portion of the resource to the second entity. This provides a fall-back recipient if the trigger event does not occur. This ensures that the resources will always be allocated eventually, thereby simplifying longterm management of the asset.

25

[25]

In a further aspect, there is provided a system comprising a processor

and memory in communication with the processor, the memory storing instructions which, when executed by the processor, cause the processor to perform any of the above methods. [26] 30

In a further aspect, there is provided a non-transitory computer-readable

medium comprising instructions which, when executed by a processor, cause the processor to perform any of the above methods [27]

In a third aspect, there is provided a device for use in asset

transactions, the device comprising: a processor; a first memory for storing a private key, the first memory being in communication with the processor; a

7

second memory for storing a public key, the second memory being in communication with the processor; a third memory for storing instructions for execution by the processor; and a network interface for communicating with one or more other devices via a network, the network interface being in 5

communication with the processor; wherein the first memory is secured such that, in use, data stored in the first memory is not output through the network interface. [28]

Such a device provides a useful and efficient mechanism for managing

public key cryptography. This can be beneficially attached or integrated into an 10

asset to handle any transactions related to that asset. This allows the existence and operation of the asset to be verified before the transaction is performed. [29]

The stored keys may be generated using any suitable approach.

However, in preferred embodiments, the device further comprises: a key generator configured to generate a private key and public key, the public key and 15

private key being complementary to each other, wherein the first memory stores the generated private key and the second memory stores the generated public key. Preferably, the key generator comprises an elliptic curve cryptography module. This allows the keys to be generated in the device, simplifying its use. Moreover, since the private key is generated in place, there is a significantly

20

reduced chance of another party obtaining the private key. [30]

In preferred embodiments, the device further comprises: a physical

communications interface for communication with one or more other devices via a physical link, the network interface being in communication with the processor; wherein, in use, data stored in the first memory can be output through the 25

physical communications interface. By limiting access to the private key to the physical communications interface, the private key can be secured simply by restricting physical access to the device. Thus conventional techniques (such as locks) can be used to secure the private key. [31]

30

In use, in response to the receipt of a show public key command at the

network interface, the processor can cause the network interface to output a public key stored in the second memory. This allows the public key to be freely and easily accessed. [32]

In use, in response to the receipt of a sign message command at the

network interface, the sign message command comprising a message, the

8

processor can cause the network interface to output a signature, the signature comprising the message signed by the private key stored in the first memory. This allows a message to be signed by the device (potentially as a proxy for the corresponding asset) simply. 5

[33]

In use, in response to the receipt of a verify signature command, a

signature, and a public key, the processor can decrypt the signature using the private key stored in the first memory to obtain a decrypted public key, compares the decrypted public key to the received public key, and can cause the network interface to output the result of the comparison. This makes it simple to verify 10

whether a particular signature came from the device. [34]

In use, in response to the receipt of verify transaction message

command at the network interface, the verify transaction message can comprise a raw transaction record comprising a signature generated by a first entity, a second entity identifier, and an asset identifier, the processor: determines that 15

the asset identifier corresponds to a device identifier of the device; obtains a current entity associated with the device based on at transaction record in a distributed ledger of transaction records; determines that the first entity identifier corresponds to the current entity; and signs the raw transaction record using the private key stored in the first memory. This allows the device to cosign a

20

transaction if it is otherwise valid, enhancing the security of the transactions. [35]

In use, the processor can periodically send an allocate resources

command to a server via the network interface, the allocate resources command comprising a device identifier. This allows resources corresponding to an asset for which the device handles its cryptography to be allocated at regular intervals. 25

[36]

Preferably, the allocate resources command further comprises an entity

identifier identifying an entity associated with the device. The association between the device and each entity can be determined based on at transaction record in a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network. This allows only those resources 30

corresponding to a particular entity to be allocated, and particularly in a transparent and easily accessible manner. [37]

In preferred embodiments, the second memory further comprises a

resource identifier, and the allocate resources command comprises the resource

9

identifier. This allows the device to store all the details needed for allocating a resource based on the asset. [38]

In preferred embodiments, the device further comprises a tamper

detector for determining if one or more of the processor, the first memory, the 5

second memory or the third memory have been tampered with. This further enhances the security of the device (and especially of the stored private key), since it becomes more difficult to get access to the internals of the device by force. [39]

10

The device may be formed in any suitable manner. However, in

preferred embodiments, the device is formed as an application-specific integrated circuit. This provides a small and efficient device. BRIEF DESCRIPTION OF FIGURES [40]

Examples of the present invention will now be described with reference

to the accompanying drawings, where: 15

[41]

Figure 1 shows a method for resource allocation according to a first

embodiment;

20

[42]

Figure 2 shows a preferred implementation of step 110;

[43]

Figure 3 shows a preferred implementation of step 120;

[44]

Figure 4 shows a preferred implementation of step 140;

[45]

Figure 5 shows a preferred implementation of step 170;

[46]

Figure 6 shows a method for resource allocation according to a second

embodiment; [47]

Figure 7

shows

an

exemplary

transaction

record

for

use

embodiments; 25

[48]

Figure 8 shows a system for performing the described methods; and

[49]

Figure 9 shows a device for use in in asset transactions.

DETAILED DESCRIPTION

in

10

[50]

Turning first to Figure 1, there is shown a computer-implemented

method for managing a time-based allocation of resources corresponding to assets using a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network. 5

[51]

At step 110, a transaction record is received from the ledger. The

transaction record comprises at least an asset identifier which identifies an asset and a first entity identifier which identifies a first entity. The effect of the transaction record is to form an association between the first entity and the asset. 10

[52]

Figure 2 shows a preferred implementation of step 110, using the Bitcoin

blockchain as the ledger. It will be appreciated that other ledgers are available. In this case, the preferred implementation typically takes place on a server running Bitcoin software, such that the server receives broadcasted blocks in the network. 15

[53]

At step 111, a block in the Bitcoin blockchain is received at the server. In

some cases, this can be as the result of the server initially creating the transaction, which is broadcast to the network and is eventually returned in a block (optionally along with other potentially unrelated transactions) once confirmed. In some cases, the entity and the asset must have been associated 20

for a threshold duration before the transaction is created. [54]

At step 112, the block is analysed to obtain a list of the transactions in

the block. This may occur only once the block has been confirmed (or has received a number of confirmations), to avoid the need to discard transactions if the block ends up being discarded. 25

[55]

At step 113, the transactions are filtered. This can be based on a

particular string in the metadata of each transaction (for example in an OP_CODE such as OP_RETURN) which indicates that the transaction is usable in the present invention. Additionally or alternatively, the filtering may be based on identifying an asset in the transaction which has previously been indicated as 30

needing to be monitored. Each of the transactions that pass through the filtering process can then be used as the transaction record. [56]

Returning to Figure 1, at step 120, a time corresponding to the

transaction record is identified. This time can be derived from a timestamp

11

included in the transaction record (or in a header of the block in which the transaction record is transmitted). [57]

Figure 3 shows a preferred implementation of step 120 where the

identified time is used to delimit the association period. 5

[58]

At step 121, a time is retrieved from the transaction record. Typically this

involves identifying a timestamp from the transaction record and parsing the timestamp into a suitable format for use as a time of the transaction record. In some cases, this may involve retrieving the time from the header of a block in which the transaction record is transmitted. 10

[59]

At step 122, the retrieved time is recorded as the start time of the

association between the entity and the asset. That is, the association is treated as starting at the time the transaction record was made. This can be stored in a temporary memory until step 140 is performed to store the start time with the record of the association. 15

[60]

At step 123, an earlier association is obtained. More precisely, a second

association between the resource and a second entity is determined based on the ledger, where the second association has a start time earlier than the time retrieved at step 121. [61] 20

At step 124, the retrieved time is recorded as the end time of the earlier

association. That is, the second associated is treated as ending at the time the transaction record was made. Since the same time is used as the start time at step 122 and the end time at 124, there should be no time at which the asset is not associated with any entity. [62]

25

Returning to Figure 1, at step 130, a resource corresponding to the

asset is identified. This may be performed according to one of three approaches (though a combination of the approaches is also suitable). [63]

In a first approach, the resource may be indicated in the metadata of the

transaction, by including a suitable string which can be parsed to identify the resource corresponding to the identified asset. 30

[64]

In a second approach, the resource can be identified from a second

entity which is identified in the metadata of the transaction using a second entity identifier.

12

[65]

In a third approach, the resource can be identified from the asset itself,

or from a device associated with the asset. [66]

At step 140, an association between the first entity and the asset is

recorded. This can be performed by storing, in a database, an entry which 5

includes the first entity identifier and the asset identifier, and preferably a reference to the transaction record which caused the association. A time (such as the start time) can also be included. In addition, in some cases the transaction may comprise a quantity indicator to indicate a quantity of the asset. For example, a single transaction may transfer multiple of the asset at once. In

10

such cases, a quantity can be retrieved from the transaction record, and recorded as the quantity of the asset, for example in the same database entry as the association. [67]

Figure 4 shows a preferred implementation of step 140 which makes

use of a tree structure for the transactions of an asset. Each node in the tree 15

corresponds to a transaction record, and indicates an entity associated with the asset, a start time of the association, and a quantity of the asset. Each node has one or more parents and may have one or more children. [68]

At its root node, the tree has the genesis transaction of the asset, where

the electronic representation of the asset in the ledger was created. Every other 20

node in the tree has a quantity which does not exceed the quantity of its parent (or the sum of the quantities of its parents). [69]

At step 141, a mapping between the entity and the asset is formed

based on the entity identifier and the resource identifier. The mapping typically comprises the entity identifier, the asset identifier, the start time, and the 25

transaction record which caused the association. [70]

At step 142, a current node in the tree which corresponds to the asset

and another entity is identified. Since each transaction record identifies a previous transaction record (or multiple previous transaction records) on which it is based, this can be performed by searching for the previous transaction record 30

among the nodes. A node in which the sum of the quantities of its child nodes is equal to the node’s own quantity need not be searched—such a node cannot form the basis of a further transaction. [71]

At step 143, a new leaf node is appended to the current node based on

the mapping. In other words, the leaf node comprises the mapping as the

13

payload with a header that indicates the parent node (or parent nodes, where there are multiple). [72]

In some cases, the association also links the first entity to one or more

other user accounts. For example, the first entity may be linked to a user 5

account in a social network, such as LinkedIn or Facebook. [73]

This can be used to assess the relative social closeness of the first

entity to another entity, which may be used in calculating a trust score. For example, two entities which are directly linked in a social network may have a relatively high trust score, and two users which are not even indirectly linked 10

may have a relatively low trust score. [74]

In addition, it may be used to assess whether a particular asset has

been within a user’s social network previously. An asset which has long been held by users who are directly linked or indirectly linked with a low degree (such as linked via a single intermediary) may have a relatively high trust score. 15

[75]

Such a trust score may be used when a user considers whether to enter

into a transaction, for example by the server calculating and displaying the trust score to the user in a graphical user interface. [76]

Returning to Figure 1, at step 150, an allocation request is received. The

allocation request indicates a first entity using an entity identifier, which may be 20

the same as the first entity identifier. The allocation request is typically sent electronically using a form on a website or using an application program interface (API). Step 150 may occur a substantial period after the preceding step. [77]

25

At step 160, the identity of the first entity indicated in the allocation

request is authenticated. Since the first entity identifier is typically public, it is possible for an unrelated entity to submit an allocation request identifies the first entity, which can lead to a misallocation. This authentication can occur by the allocation request (or a subsequent message) including the first entity’s private key which corresponds to the public key used in the first entity identifier.

30

Alternatively, rather than providing the private key itself, the allocation request (or a subsequent message) can include a signature of a known string encoded using the private key. This can then be decoded using the public key of the first entity identifier, thus authenticating the identity of the first entity.

14

[78]

At step 170, the resource (or at least a portion of the resource) is

allocated to the first entity based on the identified time. That is, a duration of the association is calculated using the identified time and either an end time (if one is present, for example because the asset has been subsequently transferred to 5

another entity) or a current time (for example, the time that the allocation request is received). The allocation may also be based on the quantity of the asset. For example a greater quantity of assets can mean a greater quantity of resources allocated. [79]

10

Step 170 might occur only following the receipt of an allocation request

in step 150 and a successful authentication in step 160 or may occur periodically (such as monthly or yearly) or both. [80]

Figure 5 shows a preferred implementation of step 170, the allocation

occurs using the same distributed consensus network as is used for the ledger. [81] 15

At step 171, a recipient address associated with the entity is identified.

The recipient address is generally the entity identifier (or a hash of the entity identifier). [82]

At step 172, a new transaction record is created, which comprises the

entity identifier, a resource identifier which identifies the resource and a quantity of the resource to be transferred. 20

[83]

At step 173, the addition of the transaction record to the distributed

ledger is initiated. This can occur by broadcasting the transaction to the other devices in the distributed consensus network. Once the transaction is confirmed, the allocation can be regarded as being complete. [84] 25

The method shown in Figure 1 (and optionally including the

embodiments of any of Figures 2 to 5) has applications in any field in which resources corresponding to assets are allocated according to a time, and particularly a duration in which the asset is associated with the entity. [85]

One such field is finance, where a resource (usually money, such as

that tied to dividends or interest payments) is allocated to the holder of an asset 30

(such as a stock or a bond) periodically (often annually). In practice, the assetholder is entitled to a portion of the resource based on the length of time they have held the asset. However, this payment typically does not account for transfers which occur part-way through a period. For example, if a stock which

15

has dividends paid out annually is transferred nine months through the year from a first owner to a second owner, the second owner will be paid the full dividend, even though they are only entitled to one-quarter of the dividend. Typically this has been addressed by adjusting the sale price of the stock based on the 5

expected dividend. However, since this is based on expectation, such adjustment can be inaccurate. [86]

However, by making use of the method of the first embodiment, this can

be overcome. Each transaction record provides a proof of ownership, with the duration of ownership being easily verifiable. Each owner can provide an 10

identifier (such as their private key) to the server (which acts as an escrow). The server can calculate what proportion of the dividend they are due based on their duration of ownership. This avoids the need to estimate the dividend in advance, and provides a transparent mechanism by which return-bearing financial instruments can be traded. In such cases, the resources (that is, money) can be

15

transferred to an account maintained by a banking organisation. [87]

In another example, wind farms generate power which is sold to the

grid. The amount of power generated is unpredictable, but can be estimated moderately accurately over an annual period to reduce the effect of seasonal changes. Such a wind farm can be seen financially as a number of assets which 20

generate resources. In this case, the resource may be the power that is generated, or may be the money that is generated when the power is sold. In this case, as the assets are sold across the year, the respective owners can, at the end of the year, reclaim their respective portion of the returns. This avoids the need to estimate the expected resource production for a part-year period,

25

where seasonal variation can make any such estimation inaccurate. [88]

Turning now to Figure 6, there is shown a computer-implemented

method for managing an event-based allocation of resources corresponding to assets using a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network. This contrasts with 30

the time-based approach of Figure 1, though a mixture of the two embodiments is equally possible. [89]

At step 210, a transaction record is received from the ledger. The

received transaction record comprises at least an asset identifier which identifies an asset, a first entity identifier which identifies a first entity, a second entity

16

identifier which identifies a second entity, and an expiration time. In this manner, step 210 may be basically identical to step 110. [90]

At step 220, a resource corresponding to the asset is identified. In this

manner, step 220 may be identical to step 130. 5

[91]

At step 230, an association between the first entity and the asset is

recorded. In this manner, step 230 may be identical to step 140. [92]

At step 240, the receipt of a notification of a predetermined trigger event

occurring is monitored for. Typically the notification is received by an authenticator identified by an authenticator identifier in the transaction record as 10

being a trusted party. Such a notification may be received through an API or by a message. This may involve verifying the identity of the authenticator using standard techniques. In some cases, the authenticator may be a further consensus-driven network. In such cases, a consensus among the devices in the consensus-driven network may be required before a subsequent step is

15

performed. [93]

At step 250, if the notification is received, at least a portion of the

resource is allocated to the first entity. The notification may function as an allocation request identifying the first entity, such as that received at step 150 and may involve the verification of step 160. The operation of the transfer may 20

occur in a substantially similar way to step 170. [94]

At step 260, if no notification is received before the expiration time, at

least a portion of the resource is allocated to the second entity. The operation of the transfer may occur in a substantially similar way to step 170. [95] 25

The method shown in Figure 6 has applications in any field in which

resources corresponding to assets are allocated based on a predetermined trigger event. Such an event may be clearly verifiable, or may be assessed by a suitable authenticator. [96]

Once such field in insurance, where a resource (usually money) is

allocated to the holder of an asset (such as an insurance policy) if a specific 30

event occurs (for example, a house fire). If the specific event does not occur by the expiration time of the policy, the money which would be paid to the policyholder can revert to the policy-issuer. In this manner, the process of policy-

17

issuing and policy-claiming can be substantially automated, with the policy itself becoming an easily tradable asset. Transaction records [97] 5

Figure 7 shows an exemplary format for a transaction record which may

be used in accordance with any described embodiment. It will be appreciated that some fields may be omitted in some cases. [98]

Transaction record 310 comprises a timestamp 311, an expiration time

312, an asset identifier 313, an asset quantity 314, a resource identifier 315, a first entity identifier 316, a second entity identifier 317, and an authenticator 10

identifier 318. [99]

The timestamp 311 indicates the time at which the transaction took

place. [100]

The expiration time 312 indicates the time at which the association

expires. Based on this expiration time, the resource may revert to another entity 15

(such as the second entity). [101]

The asset identifier 313 identifies the asset which the transaction relates

to. It can be a natural language string which describes the asset in a suitable manner, a unique id associated with the asset or a signature generated by a device associated with the asset. It can also be a reference to a previous 20

transaction record related to that asset. [102]

The asset quantity 314 identifies the number of assets that were

transferred in the transaction. [103]

The resource identifier 315 identifies the type of resource that is

allocatable to the entity. It may also identify other attributes of the resource. For 25

example, this may include one or more of a period at which the resources are allocated (such as every 12 months), a term across which resources are available (that is the life span of the asset), and an algorithm for calculating the quantity of the resource to be calculated (such as 80% of a profit figure). [104]

30

The first entity identifier 316 identifies the first entity who is associated

with the asset. It comprises a public key which corresponds to a private key held by the first entity, or a hash of the public key (such as a Bitcoin address).

18

[105]

The second entity identifier 317 identifies a second entity who is

associated with the asset. It may indicate an entity used to administer the resource, as an alternative or in addition to the resource identifier 314. It may alternatively indicate an entity which receives the resource if a trigger event does 5

not occur by the expiration time. The second entity identifier 317 may be in substantially the same form at the first entity identifier 316. [106]

The authenticator identifier 318 identifies an authenticator who

administers when a trigger event occurs. It comprises contact details (such as an email address) of the second entity. 10

[107]

In some cases, the transaction record 310 may be a Bitcoin transaction.

In such cases, one or more of the fields of transaction record 310 may be stored in the OP_RETURN field of the Bitcoin transaction. In addition, key elements from the block in which the transaction is transmitted can also be used. For example, the timestamp of the header of the block can be used as the time of 15

the transaction. Systems [108]

It will be appreciated that the described methods may be performed on

any suitable processing system, including hardware or firmware. In some cases, each step may be performed by a module in a system. 20

[109]

Additionally or alternatively, any of the described methods may be

embodied as instructions on a non-transitory computer-readable medium such that, when the instructions are executed by a suitable module within the system (such as a processor), cause the module to perform a described method. [110] 25

In a preferred embodiment, it will be appreciated that any of the

described methods may be performed by a computer, such as the example computer shown in Figure 8. [111]

Computer 10 comprises a processor 11 in communication with a

memory 12 and a network interface 13. The memory 12 typically comprises instructions which, when executed by the processor 11, cause the processor 11 30

to perform any of the methods described in the present description. The network interface 13 is configured to send and receive messages across a network 20, such as the internet. Computer 10 may be a server which runs distributed ledger software, such as Bitcoin software.

19

[112]

Transaction records in the chain, the chain itself and any other data

used in the described methods may be stored in the memory 12. Additionally or alternatively, the data may be stored in a database remote from the computer 10. The data may be accessed by the processor 11 by sending a message via 5

the network interface 13 across network 20 to the remote database, which, in response to the message, returns the data. [113]

The computer 10 may be in communication with a user device 30 using

network interface 13 across network 20. User device 30 comprises a processor 31 in communication with a memory 32, a network interface 33, a display 34 and 10

a user input device 35. [114]

In use, the user may be presented with a graphical user interface on the

display 34 of the user device 30 and may interact with the graphical user interface using the user input device 35. This may allow the user to issue an allocation request. This process may be achieved by processor 11 sending a 15

message to processor 31 via network interface 13, network 20 and network interface 33, instructing the processor 31 to display the graphical user interface. Likewise, the user input related to the allocation request may be transmitted to processor 11 by processor 31 via network interface 33, network 20 and network interface 13.

20

Asset-based transactions [115]

In some cases, it can be useful for the asset itself to be involved in

transactions, for example by identifying the asset or to cosign a transaction which transfers the asset from one entity to another (or transfers an allocation of resources associated with the device). This can have the effect of ensuring that 25

the asset is still available at the time of transfer. [116]

Figure 9 shows an example device for this use. Here, device 40 is an

application-specific integrated circuit (ASIC) which comprises a processor 41, a key generator 42, a random number generator 43, a first memory 44, a second memory 45, a third memory 46, a network interface 47, and a physical 30

communication interface 48 and a battery 49. Device 40 may be mounted in a suitable housing (not shown). [117]

Processor 41 is any suitable microprocessor or microcontroller which is

in communication with the various other elements of the device 40.

20

[118]

Key generator 42 is configured to generate a complementary key pair

consisting of a private key and public key. These can be generated in any known method of generating keys for use in public key cryptography, but is usefully an elliptic curve cryptography (ECC) module, which makes use of ECC to generate 5

pairs of keys. The key generator may additionally be able to sign messages using the public or private key and a suitable hash function, such as SHA256. [119]

Random number generator 43 is configured to generate truly random

number, for use by the key generator 42. [120] 10

First memory 44 stores the generated private key. It is a secure memory

which cannot be read easily and can be write-once. Preferably, it is not directly readable by the processor 41 at all, such that any data stored in the first memory 44 can be kept essentially secret. Alternatively, it may be such that the first memory is kept separate from the network interface 47 such that data stored in the first memory 44 cannot be transmitted over the network interface 47.

15

[121]

Second memory 45 stores the generated public key, and any other data

which is freely readable. For example, a resource identifier which identifies a resource corresponding to the device and other attributes related to the resource may be freely stored in the second memory 45.

20

[122]

Third memory 46 stores instructions for execution by the processor.

[123]

Network interface 47 allows the device 40 to transmit and receive

messages from other devices in a network using a suitable technology, such as WiFi, Bluetooth, near-field communication (NFC), or mobile network technology (such as 3G, 4G, or LTE). [124] 25

Physical communication interface 48 (such as a USB port) allows the

device 40 to transmit and receive messages to another device over a wired connection. In some cases, this can be used to output data stored in the first memory. This is more secure than transmitting such data over the network interface 47, since the physical communication interface requires a close proximity, and may have physical security features (such as a lock).

30

[125]

Battery 49 is provided to power the device. Battery 49 may be

rechargeable. Additionally or alternatively, the device 40 may be powered by a connection to mains power.

21

[126]

The device 40 may comprise a tamper detector for determining if one or

more of the elements of the device 40 have been tampered with (such as being removed, adjusted, or accessed). If such activities are detected, the tamper detector may lock the device or cause it to otherwise become inoperable. This 5

may be used in ensuring that the first memory cannot be directly read or its data output. [127]

In some cases, before irreversible action is taken by the tamper

detector, the private key may be broadcast to a trusted party, or any data secured by the private key may be released. This can ensure that such data is 10

not irretrievably lost. [128]

In some embodiments, the key generator 42 and the random number

generator 43 may be omitted. Instead, the private key and public key may be generated externally from the device 40 and written into the first memory and second memory respectively, for example during manufacture. Alternatively, the 15

private key may be stored, with the corresponding public key computed as needed. [129]

In use, the device 40 is configured to respond to the receipt of a number

of different commands, which are received through the network interface 47. The operations performed by the device may be encoded as computer-executable 20

instructions in the third memory 46 which, when executed by the processor, cause the processor to perform the operation. [130]

A “show public key” command may be received. In response, the

processor 41 causes the network interface 47 to output the public key stored in the second memory 45. This is transmitted to the sender of the command. 25

[131]

A “sign message” command may be received, which comprises a

message. Such a command requests the device 40 to generate a signature based on the received message and its private key. In response, the processor 41 causes a signature to be created by having the message signed using the private key stored in the first memory 44 and a suitable hash function (such as 30

SHA256). Since the processor 41 may not be able to directly read the private key, the signing process can occur at the key generator 42, which outputs the signature. The signature is then transmitted to the sender of the command. [132]

A “verify signature” command may be received, which comprises a

signature and a public key. Such a command requests the device 40 to verify

22

that a signature was generated by the device based on the received public key. In response, the processor 41 has the signature decrypted using the private key stored in the first memory 44 to generate a decrypted public key. Since the processor 41 may not be able to directly read the private key, the decrypting 5

process can occur at the key generator 42. The decrypted public key is then compared to the received public key. If these are identical, then the signature was originally generated using device 40. In this case, a positive response can be transmitted to the sender of the command. If these are not identical, then the signature was not generated using the device 40 or the signature was not

10

generated using the received public key (or both). In either case, a negative response can be transmitted to the sender of the command. [133]

A “verify transaction” command may be received, which comprises a

raw transaction record. The record comprises a signature generated by a first entity, a second entity identifier and an asset identifier. Such a command 15

requests the device 40 to verify that a raw transaction record (that is, an incomplete transaction) is legitimate and should be completed. Completing the transaction may cause the asset to transfer from the first entity to the second entity. [134]

20

First, the processor 41 determines that the asset identifier corresponds

to its own device identifier. Such a device identifier may be pregenerated and stored, for example, in the second memory 45. It may be a hash of the stored public key. By determining that the received asset identifier corresponds to the device identifier, it can be determined whether the transaction relates to the device itself. For example, the transaction may be transferring ownership of the

25

device, or transferring the right to receive an allocation of a resource associated with the device. [135]

Second, the processor 41 obtains a current entity associated with the

device. This is based on a transaction record in a distributed ledger of transaction records. As noted above, this may make use of known technology for 30

recording the ownership of an asset, such as Colored Coins. Alternatively, the current entity may be stored at the device 40, for example in the second memory 45. [136]

Third, the processor 41 determines that the first entity identifier

corresponds to the current entity. This can verify that the alleged current owner 35

of the asset in the transaction is the current owner of the asset in the ledger.

23

[137]

Fourth, the processor 41 has the raw transaction record signed using

the private key stored in the first memory 44 and a suitable hash function (such as SHA256). As noted above, the actual signature process may occur at the key generator 42. This generates a signature which can be forwarded to the 5

originally requesting party, or may be broadcast across a network (such as the distributed consensus network which manages the distributed ledger). [138]

Periodically (such as monthly or annually), the device 40 may issue an

“allocate resources” command. The command indicates a first entity, such as the current entity associated with the device in a distributed ledger of transaction 10

records. Additionally or alternatively, the command indicates the device 40, such as by including the device identifier. This command is sent to a server which manages resource allocation for the device 40. Such a command may be the allocation request noted above at step 150. Alternatively, in some cases, the device 40 itself may manage resource allocation without relying on a separate

15

server. [139]

In use, such a device may be physically integrated into assets or

permanently affixed using any approach known to the skilled person. For example, each wind turbine in a wind farm may have a separate device attached to it, so that that wind turbine can be bought and sold as an easily identified 20

asset. [140]

It will be appreciated that the order of performance of the steps in any of

the embodiments in the present description is not essential, unless required by context or otherwise specified. Thus most steps may be performed in any order. In addition, any of the embodiments may include more or fewer steps than those 25

disclosed. [141]

Additionally, it will be appreciated that the term “comprising” and its

grammatical variants must be interpreted inclusively, unless the context requires otherwise. That is, “comprising” should be interpreted as meaning “including but not limited to”. 30

[142]

Moreover, the invention has been described in terms of various specific

embodiments. However, it will be appreciated that these are only examples which are used to illustrate the invention without limitation to those specific embodiments. Consequently, modifications can be made to the described embodiments without departing from the spirit and scope of the invention.

1/14

CLAIMS 1.

A computer-implemented method for managing a time-based allocation of resources

corresponding to assets using a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network, the method comprising: receiving a transaction record from the ledger, the transaction record comprising an asset identifier which identifies an asset and an entity identifier which identifies an entity; identifying a time corresponding to the association; identifying a resource corresponding to the asset; recording an association between the entity and the asset; and allocating at least a portion of the resource to the entity based on the identified time. 2.

The method of claim 1, wherein recording an association between an entity and the

asset based on the transaction record comprises: forming a mapping between the entity and the asset based on the entity identifier and the resource identifier; identifying a current node in a tree structure, the current node being a node that corresponds to a mapping between the asset and another entity; and appending a new leaf node to the current node based on the mapping. 3.

The method of any preceding claim, wherein identifying a time corresponding to the

association comprises: retrieving a time from the transaction record; and recording the time as the start time of the association between the entity and the asset. 4.

The method of claim 3, wherein identifying a time corresponding to the association

comprises: determining a second association between the resource and a second entity based on the ledger, the second association having a start time earlier than the retrieved time; and recording the retrieved time as the end time of the second association. 5.

The method of claim 3 or 4, wherein allocating at least a portion of the resource to the

entity based on the identified time comprises: calculating a duration of the association based on the start time and one of an end time or a current time; and allocating at least a portion of the resource to the entity based on the calculated duration. 6.

The method of any preceding claim, wherein the transaction record further comprises a

quantity, the method further comprising: recording the retrieved quantity as the quantity of the asset in the association; and wherein allocating at least a portion of the resource to the entity based on the identified time is further based on the recorded quantity.

2/14

7.

The method of any preceding claim, wherein allocating at least a portion of the resource

to the entity is performed periodically. 8.

The method of any preceding claim, wherein allocating at least a portion of the resource

to the entity comprises: identifying a recipient address associated with the entity; and transferring the portion of the resource to the recipient address. 9.

The method of claim 8, wherein the recipient address corresponds to an account

maintained by a banking organisation and the resource is money. 10.

The method of claim 8, wherein the recipient address is the entity identifier or a hash of

the entity identifier. 11.

The method of claim 10, wherein transferring the portion of the resource to the recipient

address comprises: creating a transaction record comprising the entity identifier and a resource identifier which identifies the portion of the resource; and initiating the addition of the transaction record to the distributed ledger. 12.

A system, comprising: a processor; a memory in communication with the processor, the memory storing instructions which,

when executed by the processor, cause the processor to perform the method of any of claims 1 to 11. 13.

A computer-implemented method for managing an event-based allocation of resources

corresponding to assets using a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network, the method comprising: receiving a transaction record from the ledger, the transaction record comprising an asset identifier which identifies an asset, and a first entity identifier which identifies a first entity; identifying a resource corresponding to the asset; recording an association between the first entity and the asset; monitoring for the receipt of a notification of a predetermined trigger event occurring; and if the notification is received, allocating at least a portion of the resource to the first entity. 14.

The method of claim 13, wherein recording an association between the first entity and

the asset based on the transaction record comprises: forming a mapping between the first entity and the asset based on the first entity identifier and the resource identifier; identifying a current node in a tree structure, the current node being a node that corresponds to a mapping between the asset and another entity; and appending a new leaf node to the current node based on the mapping.

3/14

15.

The method of claim 13 or 14, wherein the transaction record comprises an authenticator

identifier which identifies an authenticator, and receiving a notification of a predetermined trigger event occurring comprises: receiving a notification of a predetermined trigger event occurring from the authenticator. 16.

The method of any of claims 13 to 15, wherein allocating at least a portion of the

resource to the first entity comprises: identifying a recipient address associated with the first entity; and transferring the portion of the resource to the recipient address. 17.

The method of claim 16, wherein the recipient address corresponds to an account

maintained by a banking organisation and the resource is money. 18.

The method of claim 16, wherein the recipient address is the first entity identifier or a

hash of the first entity identifier. 19.

The method of claim 18, wherein transferring the portion of the resource to the recipient

address comprises: creating a transaction record comprising the first entity identifier and a resource identifier which identifies the portion of the resource; and initiating the addition of the transaction record to the distributed ledger. 20.

The method of any of claims 13 to 19, wherein the transaction record further comprises a

second entity identifier which identifies a second entity, and an expiration time, the method further comprising: if no notification is received before the expiration time, allocating at least a portion of the resource to the second entity. 21.

A system, comprising: a processor; a memory in communication with the processor, the memory storing instructions which,

when executed by the processor, cause the processor to perform the method of any of claims 13 to 20. 22.

A device for use in asset transactions, the device comprising: a processor; a first memory for storing a private key, the first memory being in communication with the

processor; a second memory for storing a public key, the second memory being in communication with the processor; a third memory for storing instructions for execution by the processor; and a network interface for communicating with one or more other devices via a network, the network interface being in communication with the processor;

4/14

wherein the first memory is secured such that, in use, data stored in the first memory is not output through the network interface. 23.

The device of claim 22, further comprising: a key generator configured to generate a private key and public key, the public key and

private key being complementary to each other, wherein the first memory stores the generated private key and the second memory stores the generated public key. 24.

The device of claim 23, wherein the key generator comprises an elliptic curve

cryptography module. 25.

The device of any of claims 22 to 24, further comprising: a physical communications interface for communication with one or more other devices

via a physical link, the network interface being in communication with the processor; wherein, in use, data stored in the first memory can be output through the physical communications interface. 26.

The device of any of claims 22 to 25, wherein, in use, in response to the receipt of a

show public key command at the network interface, the processor causes the network interface to output a public key stored in the second memory. 27.

The device of any of claims 22 to 26, wherein, in use, in response to the receipt of a sign

message command at the network interface, the sign message command comprising a message, the processor causes the network interface to output a signature, the signature comprising the message signed by the private key stored in the first memory. 28.

The device of any of claims 22 to 27, wherein, in use, in response to the receipt of a

verify signature command, a signature, and a public key, the processor decrypts the signature using the private key stored in the first memory to obtain a decrypted public key, compares the decrypted public key to the received public key, and causes the network interface to output the result of the comparison. 29.

The device of any of claims 22 to 28, wherein, in use, in response to the receipt of verify

transaction message command at the network interface, the verify transaction message comprises a raw transaction record comprising a signature generated by a first entity, a second entity identifier, and an asset identifier, the processor: determines that the asset identifier corresponds to a device identifier of the device; obtains a current entity associated with the device based on at transaction record in a distributed ledger of transaction records; determines that the first entity identifier corresponds to the current entity; and signs the raw transaction record using the private key stored in the first memory. 30.

The device of any of claims 22 to 29, wherein, in use, the processor periodically sends

an allocate resources command to a server via the network interface, the allocate resources command comprising a device identifier.

5/14

31.

The device of claim 30, wherein the allocate resources command further comprises an

entity identifier identifying an entity associated with the device. 32.

The device of claim 31, wherein the association between the device and each entity is

determined based on at transaction record in a distributed ledger of transaction records, the ledger being maintained by devices in a distributed consensus network. 33.

The device of any of claims 30 to 32, wherein the second memory further comprises a

resource identifier, and the allocate resources command comprises the resource identifier. 34.

The device of any of claims 22 to 33, further comprising a tamper detector for

determining if one or more of the processor, the first memory, the second memory or the third memory have been tampered with. 35.

The device of any of claims 22 to 34, wherein the device is formed as an application-

specific integrated circuit.

6/14

7/14

8/14

9/14

10/14

11/14

12/14

13/14

14/14