Technical Field

The present invention relates to systems and methods for verifying and recording transfer of objects in a supply chain. The invention has particular, but not exclusive, relevance to the tracking of pharmaceutical products in a supply chain.

Background

Supply chain information relating to the distribution of physical products has conventionally been recorded separately by each entity in a supply chain, with each entity only able to access information corresponding to transactions or events involving that entity. As supply chain systems have become digitised, and supply chain audits have become more commonplace, information sharing between entities has become more common. The GS1 standards organisation has introduced the Electronic Product Code Information Services (EPCIS) format for recording supply chain events. This allows different parties in a supply chain to record and exchange information in a standard format.

In conventional systems, EPCIS data is sent to a central aggregation server for an agreed portion of a supply chain. A group of supply chain participants agree on a trusted party to operate and control access to the aggregation server. The aggregation server is trusted not to reveal confidential commercial information to unauthorized parties. As such, the aggregation server in such a system represents a single point of failure, and is vulnerable to fraudulent activity as well as operational failure. In the context of pharmaceutical products, such failures in a conventional system allow the proliferation of counterfeit medication, which has significant detrimental effects on health and the economy.

Summary

According to a first aspect of the invention, there is provided a system for verifying and recording a transfer of an object from a first party to a second party in a supply chain. The system includes a plurality of nodes hosting a distributed ledger and a plurality of computing devices communicatively coupled to the nodes of the distributed ledger, the plurality of computing devices including a first computing device associated with the first party and a second computing device associated with the second party. The first computing device is operable to determine first data corresponding to a disposing event in which the object is disposed of by the first party, and to transmit the first data to the nodes of the distributed ledger. The second computing device is operable to determine second data corresponding to a receiving event in which the object is received by the second party, and to transmit the second data to the nodes of the distributed ledger. The distributed ledger comprises a transaction smart contract for verifying that the first data and the second data comply with a set of transaction rules, and conditional on verifying that the first data and the second data complying with the set of transaction rules, recording on the distributed ledger data indicative of the transfer.

In an embodiment, event data is store in a tree structure with each tree node indicating a parent tree node. In this way, only part of a tree structure need be checked in order to determine if any anomaly is present, thereby improving operational efficiency.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 is a schematic diagram of a system for tracking a physical objects in a supply chain.

Figure 2 is a schematic block diagram of an application server according to an example of the present invention.

Figure 3 is a schematic block diagram of a smart contract according to an example of the present invention.

Figure 4 is a flow diagram representing a routine for pairing serialised product keys with compliance tracking tokens.

Figure 5 is a schematic block diagram of a smart contract according to an example of the present invention. Figure 6 is a flow diagram representing a routine for tracking a physical object in a supply chain.

Figure 7 schematically shows an event tree structure for a second example of the present invention.

Detailed Description

Figure 1 shows an example of a system for verifying and recording transfer of objects in a supply chain in accordance with the present invention. The system includes a network 101. In this example, the network 101 is the Internet. The network 101 contains computing devices (not shown) acting as public nodes to host a public distributed ledger (referred to hereafter as the main blockchain 103). The main blockchain 103 in this example is the Ethereum main chain, which uses a proof of work (PoW) consensus mechanism to ensure integrity of transactions stored on the main blockchain 103. The system of Figure 1 further includes computing devices acting as nodes to host a further distributed ledger (referred to hereafter as the sidechain 105). The sidechain 105 is a sidechain of the main blockchain 103, and in this example is implemented using a third party permissioned blockchain network, which employs a proof-of-authority (PoA) consensus mechanism to ensure integrity of transactions. Several validator nodes 107, of which validator nodes l07a, l07b, and l07c are shown, validate blocks generated on the sidechain 105, thus implementing the PoA mechanism. Other examples of sidechains may use other consensus mechanisms, for example PoW, proof-of-stake (PoS), or Raft.

The system of Figure 1 includes an application server 109, which is arranged to communicate with nodes of the main blockchain 103 and with nodes of the sidechain 105. It will be appreciated that in some implementations, the application server 109 may be a cloud-hosted virtual application server. In other implementations, the application server 109 may be a physical server or local network of servers. In this example, the application server 109 communicates with the nodes of the sidechain 105 using a Web3j interface, which implements a Java-based communication protocol between the application server 109 and the nodes of the sidechain 105. The main blockchain 103 and the sidechain 105 each store a respective set of smart contracts. The application server 109 is arranged to deploy smart contracts during set-up of the system, and also to make transactional changes to the smart contracts as will be described in more detail hereafter.

As shown in Figure 2, the application server 109 stores a master control routine 201. The master control routine 201 is configured to call subroutines including identity management routines 203, transaction monitoring routines 205, and EPCIS file routines 207. The master control routine 201 calls the identity management routines 203 in order to manage Ethereum accounts and associated wallets on behalf of users of the system, and calls the transaction monitoring routines 205 in order to automatically monitor transactions on the main blockchain 103 and the sidechain 105. Automatic monitoring of transactions allows a rules engine (not shown) associated with the application server 109 to detect anomalous events such as unexpected diversions of objects, or apparent duplication of objects, in the supply chain automatically. The master control routine 201 calls EPCIS file routines to communicate with an EPCIS file server (not shown) that manages EPCIS data including EPCIS Extensible Markup Language (XML) batch files. The application server further provides Application Programming Interfaces (APIs) including a consumer API 207. The consumer API 209 is accessible to users via a mobile application interface 211 and a dashboard interface 213, as will be described in detail hereafter. The application server 109 further provides a Web3j interface 215 for communicating with nodes of the sidechain 105.

The application server 109 communicates with a number of user systems 111, of which user system 11 la and 11 lb are shown in Figure 1, and a number of mobile devices 113, of which mobile devices H3a and H3b are shown in Figure 1. In the present example, user system 11 la is operated by a manufacturer of pharmaceutical products, and user system 11 lb is operated by a wholesale distributor of pharmaceutical products. Mobile device 1 l3a is operated by an employee of an online pharmacy, and mobile device H3b is operated by an end-user or consumer of a pharmaceutical product. The application server 109 communicates with the user systems 111 and the mobile devices 113 using the consumer API 209. The consumer API 209 presents a dashboard interface 213 to the user systems 111. The dashboard interface 213 is a web application hosted by the application server 109, which allows users of the user systems 111 to upload and query data corresponding to supply chain events. For example, a manufacturer of a pharmaceutical product may upload an EPCIS XML batch file corresponding to a sequence of EPCIS events associated with a new batch of pharmaceutical products. Events may include, for example, one or more instances of packing and/or shipping the batch of pharmaceutical products. It will be appreciated that the manufacturer may have proprietary or legacy systems for recording such events. If the data captured during such events is combined into an EPCIS XML batch file, the application server 109 is able to receive the event data via the dashboard interface 213. As another example, a wholesale distributor may have a proprietary system for recording event data associated with supply chain events, and the proprietary system may interface with the dashboard interface 213 of the consumer API 209 in order to upload data to the sidechain 105.

The consumer API 209 includes a mobile application interface 211 for communicating with a proprietary mobile application stored on the mobile devices 113. The mobile application interface 211 allows users of the mobile devices 113 to upload and query data corresponding to supply chain events. For example, a user of a mobile device 113 may query data associated with a pharmaceutical product by scanning a quick response (QR) code corresponding to a serialised product key of a pharmaceutical product using a camera associated with the mobile device 113.

Figure 1 shows a batch 115 of a pharmaceutical product. The batch 115 includes several packets of the pharmaceutical product, each packet having a serialised product key. A serialised product key is an identification code assigned to an object, for example when the object is manufactured. In this example, the serialised product key is encoded as a quick response (QR) code on each packet, where the serialisation scheme conforms to the EPCIS serialisation standard maintained by the GS1 organisation. In other examples, a serialised product key may be encoded using, for example, a ld barcode or RFID chip, or may simply be printed on a packet as a serial number. The batch 115 is passed along a supply chain from the manufacturer, to the wholesale distributor, to the online pharmacy, to the end-user. It will be appreciated that this supply chain is an illustrative example and many other supply chain arrangements are possible. For example, a batch of a pharmaceutical product may pass through several distributors and/or logistic companies before reaching a pharmacy. In other examples, a pharmaceutical product may be sent to a hospital instead of a pharmacy. Furthermore, a batch provided by a manufacturer may be divided into smaller batches and/or repackaged at one or more stages of a supply chain.

Each user system 111 is associated with an account on the sidechain 105 and an account on the main blockchain 103. Each account on the main blockchain 103 has an associated wallet for public tokens, and each account on the sidechain 105 has an associated wallet for utility tokens. Public tokens are publicly tradable digital assets, and may be staked in a utility token staking smart contract on the main blockchain 103 to receive utility tokens. Utility tokens allow users to access information stored on the sidechain 105, and to request compliance tracking tokens, as will be described in more detail hereafter. Utility tokens may be bought and sold by users on a private token exchange.

As mentioned above, public tokens may be staked in a utility token staking contract on the main blockchain 105. Utility tokens may further be staked in a compliance tracking contract on the sidechain 105. As shown in Figure 3, the compliance tracking contract 117 includes contract code 301 and contract storage 303. The contract code 301 generates unique compliance tracking tokens, which are stored within the contract storage 303 as compliance tracking token data 305. The compliance tracking tokens are paired with serialised product keys according to pairing data 307, as discussed in detail hereafter.

Figure 4 shows an example of how a user, in this case a manufacturer of a pharmaceutical product, obtains a set of compliance tracking tokens. In this example, the user logs onto the application server 109 at S401 by accessing the dashboard interface 213 of the consumer API 209 from user system 11 la. On receiving a successful logon request, the application server 109 looks up, at S403, the private and main blockchain addresses of accounts associated with the user. Using the dashboard interface 213, the user sends, at S405, a staking request to the application server 109, requesting that a predetermined number of public tokens (for example, 100 public tokens) from a wallet associated with the user’s account on the main blockchain 103 are staked in the utility staking contract. The application server 109 passes, at S407, the staking request to the utility token staking contract using the Web3j interface 215. The staking request causes the utility staking contract to stake, at S409, the predetermined number of public tokens in the utility token staking contract, and to send a predetermined number of utility tokens (for example, 500 utility tokens) to the user account of the user on the sidechain 105.

The user sends, at S411, a token request to the application server 109, requesting that a predetermined number of utility tokens (for example, 500 public tokens) from the user’ s account on the sidechain 105 are staked in a compliance tracking contract. With the request, the user provides a set of serialised product keys for a batch of pharmaceutical products. The application server 109 passes, at S413, the token request to the compliance tracking contract using the Web3j interface 215. The compliance tracking contract pairs, at S415, each of the serialised product keys with a respective compliance tracking token and stores data corresponding to each pair as pairing data 307. Finally, the compliance tracking contract 117 sends, at S417, the compliance tracking tokens to the user’s account on the sidechain 105. Each compliance tracking token thus acts as a digital reference of a serialised product key.

Compliance tracking tokens are used to verify and record a product or object passing through a supply chain. As mentioned above, the EPCIS system has been developed for tracking such products or objects, and the EPCIS standard has been designed to satisfy strict compliance regulations, for example those imposed on pharmaceutical products in certain countries. EPCIS events are registered at various points in the supply chain, including each time a product passes from one entity in a supply chain to another. Each EPCIS event is associated with the following information:

• an identifiers of the object(s) that are the subject of the event;

• an identifier of the location at which an event occurred;

• a timestamp corresponding to a time at which the event occurred, including time zone offset; and

• information about the business context, including: an identifier indicating the business step taking place (e.g. shipping, receiving, etc.), an identifier that indicates the business state of the object(s) following the event (e.g., active, recalled, damaged, etc.), identifiers of the shipping and receiving parties (if the event is part of a process of transfer between parties), links to relevant business transaction documents (e.g., a purchase order, an invoice, etc.), and/or other information defined via user extensions.

The present system replaces conventional methods of recording and storing EPCIS event data. Event data is written to the sidechain 105 each time a user of the system uploads event data to the application server 109, and is stored on the sidechain 105 along with EPCIS-compliant information for each event such that certain users of the system, for example regulators and law enforcement agencies, may have access to a complete history of objects passing through a supply chain. At certain points in the supply chain, custody of an object is passed from one entity to another (for example, from a manufacturer to a wholesale distributor). Each event in which custody of an object is transferred from one entity to another is associated with a transaction in which a compliance tracking token is transferred between user accounts of the two entities between which the object is transferred.

The sidechain 105 stores a transaction smart contract 119. As shown in Figure 5, the transaction smart contract 119 includes contract code 501 and contract storage 503. The contract code 501 includes a set of transaction rules 505 that must be satisfied in order for a compliance tracking token to be transferred between two accounts. The contract storage 503 includes transaction data 507 recording transactions in which compliance tracking tokens are transferred between accounts, and event data 509 corresponding to events uploaded by users of the system. The event data 509 includes event data for each object associated with a compliance tracking token, along with EPCIS-compliant information for each event. Series of events relating to packets within the batch 115 (for example, a series of events corresponding to the passing of a packet from manufacturer to consumer in a supply chain) are further recorded on the main blockchain 103, which can be cross-referenced manually or automatically with the corresponding transaction on the sidechain 105. The immutability of data stored on the main blockchain 103 by virtue of the PoW consensus mechanism ensures that the events stored on the sidechain 105 (which is assumed to have a weaker consensus mechanism) can also be trusted to have occurred. The data stored on the main blockchain 103 is a subset of the data stored on the sidechain 105. In this way, scalability of the system can be achieved, allowing for high-throughput of data on the sidechain 105 without necessitating all of the data being transferred to the main blockchain 103.

Figure 6 shows an example in which the system of Figure 1 is used to track a pharmaceutical product moving through a supply chain. Prior to the routine of Figure 6 taking place, a user of user system 11 la initiates the routine of Figure 4 with the application server 109, thereby pairing a set of serialised product codes for packets of the pharmaceutical product in the batch 115 with a set of compliance tracking tokens. The compliance tracking tokens are transferred to the user’s account on the sidechain 105, as described above. As mentioned above, in this example, the user system 11 la is operated by a manufacturer of the pharmaceutical product. The manufacturer has a proprietary system for recording EPCIS events. At S601, an EPCIS event is recorded, corresponding to the commissioning of the batch 115. The EPCIS event data is stored by the user system 11 la. At S603, a further EPCIS event is recorded, corresponding to the packing of the batch 115 by the manufacturer. The manufacturer sends, at S605, an EPCIS XML batch file to the application server 109 via the dashboard interface 213, containing EPCIS event data corresponding to the events recorded at S601 and S603. The application server 109 processes the EPCIS event data at S607, which includes formatting the data for uploading to the sidechain 105 and encrypting the data.

The application server 109 sends, at S609, a request to the transaction contract 119 on the sidechain 105 using the Web3j interface 215, including the event data processed at S607. The request causes transaction contract 119 to store, at S611, the received data as event data 509. This causes a transactional change to the sidechain 105, and as a result will be permanently stored on the sidechain 105 the next time a block is mined on the sidechain 105.

At S613, the manufacturer records a further event, corresponding to the shipping of the batch 115. This event results in a transfer of custody of the batch 115 from the manufacturer to the wholesale distributor operating user system 11 lb. ETser device 11 la sends, at S615, event data to the application server 109 via the dashboard interface 213, corresponding to the shipping event recorded at S613. The application server 109 processes the event data at S617, which includes formatting the data for uploading to the sidechain 105 and encrypting the data. The application server 109 sends, at S619, a request to the transaction contract 119 on the sidechain 105 using the Web3j interface 215, including the EPCIS event data processed at S617, in addition to data indicative of the wholesale distributor operating user system 11 lb. The request causes transaction contract 119 to store, at S621, the received data as event data 509, and to initiate a transaction in which the compliance tracking tokens corresponding to the batch 115 are transferred from the user account of the manufacturer to the user account of the wholesale distributor. According to the transaction rules 505, the transaction will be completed only when the wholesale distributor records an event corresponding to receipt of the batch 115.

At S623, the wholesale distributor records an event corresponding to receipt of the batch 115 and uploads the event to user system 11 lb. User system 11 lb sends, at S625, event data to the application server 109 via the dashboard interface 213, corresponding to the event recorded at S623. The application server 109 processes the event data at S627, which includes formatting the data for uploading to the sidechain 105 and encrypting the data. The application server 109 sends, at S629, a request to the transaction contract 119 on the sidechain 105 using the Web3j interface 215, including the event data processed at S627. The request causes transaction contract 119 to store, at S631, the received data as event data 509, and to complete the transaction initiated at S621. In order for the transaction to be completed and the event data to be recorded, the transaction contract 119 checks that the sending party (in this case, the manufacturer that operates user system 11 la) has the right to transfer the associated compliance tracking token, and that the associated compliance tracking token has not been transferred elsewhere. By performing such checks each time custody of a packet is transferred from one entity to another in the supply chain, provenance of each packet is recorded on the sidechain 105. As mentioned above, data on the sidechain 105 is encrypted in order to protect sensitive data corresponding to events and transactions involving the pharmaceutical product. In order to check whether the sending party has the right to transfer the compliance tokens, zero-knowledge proofs are used, allowing the sending party (the prover) to convince the transaction smart contract 119 (the verifier) that an event occurred (for example, the shipping event recorded at S613), without the transaction smart contract 119 being required to decrypt data relating to the shipping event. The transaction contract 119 further sends a message to a public smart contract on the main blockchain 103, including a subset of the event data sent included in the request sent at S629. The public smart contract stores the subset of the event data on the main blockchain 103.

A similar routine to that described with reference to Figure 6 is performed in order to transfer the custody of the batch 115 (or, alternatively, some of the packets in the batch 115) from the wholesale distributor to the online pharmacy operating mobile device 11 lb. In order for an employee of the online pharmacy to capture an event corresponding to the receipt of the batch 115, or portion of the batch 115, the employee scans, for each packet of pharmaceutical product in the batch 115, a QR code corresponding to the serialised product key of the packet using a camera associated with the mobile device H3a. The proprietary mobile application running on the mobile device 1 l3a generates event data corresponding to the event, and transfers the generated event data to the application server 109 via the mobile application interface 211. At a later time, packets from the batch 115 are either sold by the online pharmacy, or are otherwise disposed of. At the point of disposal, a packet is scanned once again using the mobile device H3a, leading to further event data being generated and sent to the sidechain 105 via the application server 109. When the transaction smart contract 119 receives a request corresponding to the disposal of a packet, the transaction smart contract 119 causes the compliance tracking token for that packet to be burned (expunged from the sidechain 105). The transaction smart contract sends a message to the utility token staking contract, which returns the staked public tokens to the user account of the manufacturer, such that the released public tokens can be used again for another batch of products.

In this example, once the compliance tracking token for a given packet is burned, the transaction smart contract sends a message to a further smart contract on the main blockchain 103, including a subset of the event data stored on the sidechain 105. The subset of event data is stored on the main blockchain 103, and hence anchors the events to the main blockchain 103. It is noted that in other examples, anchoring to the main blockchain 103 may occur at different points, for example each time a packet is passed between transacting parties, or each time compliance tracking tokens for an entire batch is burned.

The system described above allows end-users of a pharmaceutical product to have confidence that a product is genuine, as opposed to counterfeit. For example, an end-user operating mobile device 113b is able to scan a packet at the point of purchase or delivery using a camera associated with the mobile device 113b, causing the proprietary mobile application to send a data request to the sidechain 105 via the application server 109. The end-user will be informed of whether a legitimate chain of custody exists, allowing the end-user to determine whether the product is genuine.

Furthermore, the system described above allows users, for example government departments, and customs and law enforcement agencies, to track genuine products in real time by sending requests for access to data stored on the sidechain 105. Data requests include, for example, histories of specific packets, compliance reports, and product audits. Utility tokens are required by users to pay for such data requests, and are circulated for re-use when used to pay for a data request (this is achieved using a utility token smart contract). In further examples, utility tokens may be used to pay for additional services such as supply chain analytics. Such services may be performed by a dedicated computing system and may include, for example, the application of machine learning algorithms to identify features associated with the movement of products in a supply chain. Such services may be used, for example, by a manufacturer to predict temporal and geographical demand of pharmaceutical products, and also to determine efficient routes to market.

As mentioned above, the application server 109 monitors transactions using a rules engine associated with the application server 109, to detect anomalous events such as unexpected diversion of objects, or apparent duplication of objects, in the supply chain. In one example, during an onboarding process, a manufacturer operating a user system 111 provides the application server 109 with details of distributors, logistic companies, and other entities expected to handle a batch of pharmaceutical products within a supply chain. If an event relating to a packet within the batch is recorded and uploaded by an entity other than the expected entities (for example, if the packet appears at an unexpected end point), the rules engine generates an alert, which may be sent to law enforcement or customs agencies. In such a case, the compliance tracking token corresponding to the packet may be burned so that no further events in relation to that packet may be uploaded to the system. In another example, an event is recorded relating to a packet with an unknown serialised product key (i.e. a serialised product key that has not yet been provided in a routine such as that of Figure 4). The rules engine again generates an alert, which may be sent to law enforcement or customs agencies.

As mentioned above, data stored on the sidechain 105 is only accessible to certain parties. For example, law enforcement agencies, regulatory bodies, and customs agencies may be allowed to access data corresponding to any event registered on the sidechain 105 (provided the law enforcement or customs agency provides utility tokens to pay for access to the data). Regulatory bodies are provided a dashboard interface via zero-knowledge proof with an overview of operations of pharmaceutical companies and pharmaceutical products supplied in relevant territories. By contrast, a manufacturer of a product may wish to protect sensitive information, e.g. pricing information, from competitors, customers, or other users of the system. In order to achieve this, data is encrypted on the sidechain 105, and may only be decrypted by users having a correct set of private cryptographic keys. As mentioned above, zero-knowledge proofs are used to ensure the validity of transactions, without revealing encrypted data to unauthorised entities in the supply chain.

In the above embodiment, the events proceed in a generally linear manner, reflecting the EPCIS format. A second example will now be described which adopts a tree structure for recording event data. Each node in the tree structure is assigned a parent node, and rules are designed to allow efficient checking of integrity.

The second example differs from the example given above in respect of the functionality of, and data stored by, the transaction smart contract, the functionaliry of the application server and the manner in which data in the sidechain is anchored on the main blockchain.

Figure 7 illustrates an example of an aggregation tree structure adopted in the present example. Each node of the tree structure corresponds to the recording of an event via the application server, and the tree structure is stored and updated by the transaction smart contract. As will be explained in more detail hereafter, each node of the tree structure is associated, either directly or indirectly, with a parent node.

The transaction starts, in a similar manner to the previous example, with a manufacturer assigning a plurality of compliance tracking tokens to a respective plurality of product keys. This is represented by node 1001 in Figure 7. The manufacturer then performs a packing operation, represented by the node 1003, in which groups of products are packed into container and each container is associated with a container key. The node 1001 is the parent node of the node 1003. The manufacturer then performs a second packing operation, represented by the node 1005, in which the containers are packed onto a pallet, having an associated SSCC code. The node 1001 is also the parent node of the node 1005. The manufacturer then performs a shipping operation, represented by the node 1007, in which the pallet is shipped to a wholesaler. The node 1001 is also the parent node of the node 1007.

The node 1009 represents the receipt of the pallet by the wholesaler. The shipping node 1007 is the parent of the receiving node 1009. The wholesaler then performs an unpacking operation, represented by the node 1011, in which the containers are unpacked from the pallet. The shipping node 1007 is the parent node of the node 1011. The wholesaler then sends a first batch of containers to the first retailer, represented by the node 1013, and a second batch of containers to the second retailer, represented by the node 1015. The shipping node 1007 is the parent node for each of the nodes 1013 and 1015.

The node 1017 represents the receipt of the first batch of containers by the first retailer, and the node 1019 represents the unpacking of the first batch of containers. The shipping node 1013 is the parent node for each of the nodes 1017 and 1019. Similarly, the node 1021 represents the receipt of the second batch of containers by the first retailer, and the node 1019 represents the unpacking of the second batch of containers. The shipping node 1015 is the parent node for each of the nodes 1021 and 1023.

As discussed above, a node that initiates a transfer of ownership (i.e. a transfer of compliance tracking tokens from one account to another account on the sidechain) can act as a parent node. In this way, an aggregation check (e.g. a check that a product at the second retailer can be tracked back to the manufacturer, can be performed by tracking though only the parent nodes. If the product is associated with one parent node but not the parent node for that one parent node, then an anomaly has been detected.

In this example, each time that an event is recorded via the application server, multiple checks are performed including:

• an on chain sequence consistency check • an on chain aggregation consistency check that the event matches with the hierarchical data structure as discussed above

• for a receiving event, an on chain pairwise shipping/receiving check

• a velocity consistency check to check timestamps for anomalies (e.g. timestamps indicate impossible speed of movement)

• a dwell-time consistency check (check that any requirements above maximum time product stays in one place is not exceeded)

Assuming that no anomalies are identified by the checks, the transaction smart contract updates the aggregation hierarchy tree and the revised data is anchored on the public blockchain. The anchoring can be done in a number of ways, for example the transaction smart contract writing the representative private chain data (e.g. a subset or hash of the private blockchain data) onto the public blockchain, or a tracker node using a lightweight process to poll at intervals the private network data, hashing the private network data and sending to the main blockchain. In particular, on the main blockchain, the representative private chain data is received and stored by a dedicated smart contract.

The application server and the Dapp co-operate to provide the following functionality:

• Store general event (EPCIS or otherwise)

• Retrieve event

• Retrieve full sequence

• Retrieve full aggregation hierarchy

• Specify parties for private transactions, (stipulated on transaction send) per data ingestion endpoint

• Grant view permissions, post transaction.

Revoke view permissions, post transaction. The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, in some embodiments, state information of smart contracts stored on a sidechain may be stored in distributed and secured storage. Instead of each state change message being broadcast to every node hosting the sidechain (as would be the case for a conventional blockchain protocol), only a reference address of that message would be transmitted to the nodes. The smart contract stores a list of authorised user accounts associated with users who are granted read permissions to the smart contract. Only authorised users are able to access the full history of the state changes to the smart contract. One such implementation uses Interplanetary File System (IPFS), modified with a security layer for controlling access to the smart contract state data.

It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.