WO2020030936A1 - Suivi d'objets dans une chaîne logistique - Google Patents

Suivi d'objets dans une chaîne logistique Download PDF

Info

Publication number
WO2020030936A1
WO2020030936A1 PCT/GB2019/052267 GB2019052267W WO2020030936A1 WO 2020030936 A1 WO2020030936 A1 WO 2020030936A1 GB 2019052267 W GB2019052267 W GB 2019052267W WO 2020030936 A1 WO2020030936 A1 WO 2020030936A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
party
distributed ledger
event
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/GB2019/052267
Other languages
English (en)
Inventor
Raja SHARIF
Shahnawaz AZIZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Blockchain Ai Solutions Ltd
Original Assignee
Blockchain Ai Solutions Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Blockchain Ai Solutions Ltd filed Critical Blockchain Ai Solutions Ltd
Publication of WO2020030936A1 publication Critical patent/WO2020030936A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management

Definitions

  • 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.
  • 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.
  • the aggregation server in such a system represents a single point of failure, and is vulnerable to fraudulent activity as well as operational failure.
  • failures in a conventional system allow the proliferation of counterfeit medication, which has significant detrimental effects on health and the economy.
  • a system for verifying and recording a transfer of an object from a first party to a second party in a supply chain 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • PoA proof-of-authority
  • 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.
  • the application server 109 may be a cloud-hosted virtual application server.
  • the application server 109 may be a physical server or local network of servers.
  • 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.
  • 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.
  • user system 11 la is operated by a manufacturer of pharmaceutical products
  • 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
  • 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.
  • 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.
  • 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.
  • QR quick response
  • 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.
  • 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.
  • QR quick response
  • 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.
  • this supply chain is an illustrative example and many other supply chain arrangements are possible.
  • a batch of a pharmaceutical product may pass through several distributors and/or logistic companies before reaching a pharmacy.
  • a pharmaceutical product may be sent to a hospital instead of a pharmacy.
  • 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
  • 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.
  • 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.
  • 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.
  • the application server 109 looks up, at S403, the private and main blockchain addresses of accounts associated with the user.
  • 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.
  • a predetermined number of public tokens for example, 100 public tokens
  • 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.
  • a predetermined number of utility tokens for example, 500 public tokens
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • the user system 11 la is operated by a manufacturer of the pharmaceutical product.
  • the manufacturer has a proprietary system for recording EPCIS events.
  • 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.
  • 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.
  • 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.
  • the transaction rules 505 the transaction will be completed only when the wholesale distributor records an event corresponding to receipt of the batch 115.
  • 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.
  • 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.
  • 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.
  • 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.
  • packets from the batch 115 are either sold by the online pharmacy, or are otherwise disposed of.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • data stored on the sidechain 105 is only accessible to certain parties.
  • 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.
  • a manufacturer of a product may wish to protect sensitive information, e.g. pricing information, from competitors, customers, or other users of the system.
  • data is encrypted on the sidechain 105, and may only be decrypted by users having a correct set of private cryptographic keys.
  • zero-knowledge proofs are used to ensure the validity of transactions, without revealing encrypted data to unauthorised entities in the supply chain.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • a node that initiates a transfer of ownership can act as a parent node.
  • 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.
  • each time that an event is recorded via the application server multiple checks are performed including:
  • 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.
  • 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:
  • 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.
  • IPFS Interplanetary File System

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Human Resources & Organizations (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système de vérification et d'enregistrement du transfert d'un objet d'une première partie à une deuxième partie dans une chaîne logistique, qui comprend une pluralité de nœuds hébergeant un registre distribué et une pluralité de dispositifs informatiques couplés en communication aux nœuds du registre distribué, la pluralité de dispositifs informatiques comprenant un premier dispositif informatique associé à la première partie et un deuxième dispositif informatique associé à la deuxième partie. Le premier dispositif informatique est utilisable pour déterminer des premières données correspondant à un événement d'écoulement dans lequel l'objet est écoulé par la première partie, et pour transmettre les premières données aux nœuds du registre distribué. Le deuxième dispositif informatique est utilisable pour déterminer des deuxièmes données correspondant à un événement de réception dans lequel l'objet est reçu par la deuxième partie, et pour transmettre les deuxièmes données aux nœuds du registre distribué. Le registre distribué comprend un contrat intelligent de transaction pour vérifier que les premières données et les deuxièmes données sont conformes à un ensemble de règles de transaction, et à condition qu'il soit vérifié que les premières données et les deuxièmes données sont conformes à l'ensemble de règles de transaction, enregistrer, sur le registre distribué, des données indiquant le transfert.
PCT/GB2019/052267 2018-08-10 2019-08-12 Suivi d'objets dans une chaîne logistique Ceased WO2020030936A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB1813134.2 2018-08-10
GBGB1813134.2A GB201813134D0 (en) 2018-08-10 2018-08-10 Tracking objects in a supply chain
GB1818119.8 2018-11-06
GBGB1818119.8A GB201818119D0 (en) 2018-08-10 2018-11-06 Tracking objects in a supply chain

Publications (1)

Publication Number Publication Date
WO2020030936A1 true WO2020030936A1 (fr) 2020-02-13

Family

ID=63667251

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2019/052267 Ceased WO2020030936A1 (fr) 2018-08-10 2019-08-12 Suivi d'objets dans une chaîne logistique

Country Status (2)

Country Link
GB (2) GB201813134D0 (fr)
WO (1) WO2020030936A1 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020169122A2 (fr) 2020-06-08 2020-08-27 Alipay Labs (singapore) Pte. Ltd. Traitement de données de dédouanement d'importation basé sur une chaîne de blocs
WO2020169126A2 (fr) 2020-06-08 2020-08-27 Alipay Labs (singapore) Pte. Ltd. Gestion d'autorisations d'utilisateur pour des services de dédouanement basés sur une chaîne de blocs
EP3929742A1 (fr) * 2020-06-22 2021-12-29 UVUE Limited Système de calcul distribué et son procédé de fonctionnement
US11307775B2 (en) 2020-06-08 2022-04-19 Alipay Labs (singapore) Pte. Ltd. Distributed storage of custom clearance data
US11356270B2 (en) 2020-06-08 2022-06-07 Alipay Labs (singapore) Pte. Ltd. Blockchain-based smart contract pools
US11418511B2 (en) 2020-06-08 2022-08-16 Alipay Labs (singapore) Pte. Ltd. User management of blockchain-based custom clearance service platform
US11449911B2 (en) 2020-06-08 2022-09-20 Alipay Labs (singapore) Pte. Ltd. Blockchain-based document registration for custom clearance
WO2023034418A1 (fr) * 2021-08-31 2023-03-09 Advasur, LLC Système et procédé de sérialisation et de validation sécurisées de matières premières pour soins de santé
CN116113936A (zh) * 2020-06-30 2023-05-12 交互数字专利控股公司 针对启用区块链的无线系统中的交易管理的方法、架构、装置和系统
US11763248B2 (en) 2021-05-05 2023-09-19 Bank Of America Corporation Distributed ledger platform for improved return logistics
WO2024234113A1 (fr) * 2023-05-15 2024-11-21 Morales Anabalon Miguel Système de traçabilité et de gestion de conteneurs
CN120258672A (zh) * 2025-06-05 2025-07-04 贵州商学院 一种基于区块链的物流信息追踪系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160253622A1 (en) * 2015-02-26 2016-09-01 Skuchain, Inc. Tracking unitization occurring in a supply chain
US20170011460A1 (en) * 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
US20180189753A1 (en) * 2017-01-05 2018-07-05 Beskatta, LLC Infrastructure for obligation management and validation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160253622A1 (en) * 2015-02-26 2016-09-01 Skuchain, Inc. Tracking unitization occurring in a supply chain
US20170011460A1 (en) * 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
US20180189753A1 (en) * 2017-01-05 2018-07-05 Beskatta, LLC Infrastructure for obligation management and validation

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Blockchain: the solution for transparency in product supply chains", 21 November 2015 (2015-11-21), XP055392270, Retrieved from the Internet <URL:www.prvenance.org/whitepaper> [retrieved on 20170719] *
FARMATRUST: "FarmaTrust whitepaper v2.0", 14 March 2018 (2018-03-14), XP055637903, Retrieved from the Internet <URL:https://static.coinpaprika.com/storage/cdn/whitepapers/448437.pdf> [retrieved on 20191031] *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11416418B2 (en) 2020-06-08 2022-08-16 Alipay Labs (singapore) Pte. Ltd. Managing user authorizations for blockchain-based custom clearance services
WO2020169126A2 (fr) 2020-06-08 2020-08-27 Alipay Labs (singapore) Pte. Ltd. Gestion d'autorisations d'utilisateur pour des services de dédouanement basés sur une chaîne de blocs
EP3844699A4 (fr) * 2020-06-08 2021-08-18 Alipay Labs (Singapore) Pte. Ltd. Traitement de données de dédouanement d'importation basé sur une chaîne de blocs
EP3844655A4 (fr) * 2020-06-08 2021-10-27 Alipay Labs (Singapore) Pte. Ltd. Gestion d'autorisations d'utilisateur pour des services de dédouanement basés sur une chaîne de blocs
WO2020169122A2 (fr) 2020-06-08 2020-08-27 Alipay Labs (singapore) Pte. Ltd. Traitement de données de dédouanement d'importation basé sur une chaîne de blocs
US11449911B2 (en) 2020-06-08 2022-09-20 Alipay Labs (singapore) Pte. Ltd. Blockchain-based document registration for custom clearance
US11307775B2 (en) 2020-06-08 2022-04-19 Alipay Labs (singapore) Pte. Ltd. Distributed storage of custom clearance data
US11356270B2 (en) 2020-06-08 2022-06-07 Alipay Labs (singapore) Pte. Ltd. Blockchain-based smart contract pools
US11372695B2 (en) 2020-06-08 2022-06-28 Alipay Labs (singapore) Pte. Ltd. Blockchain-based import custom clearance data processing
US11418511B2 (en) 2020-06-08 2022-08-16 Alipay Labs (singapore) Pte. Ltd. User management of blockchain-based custom clearance service platform
EP3929742A1 (fr) * 2020-06-22 2021-12-29 UVUE Limited Système de calcul distribué et son procédé de fonctionnement
WO2021260517A1 (fr) * 2020-06-22 2021-12-30 Uvue Ltd Système informatique distribué et son procédé de fonctionnement
CN116113936A (zh) * 2020-06-30 2023-05-12 交互数字专利控股公司 针对启用区块链的无线系统中的交易管理的方法、架构、装置和系统
US11763248B2 (en) 2021-05-05 2023-09-19 Bank Of America Corporation Distributed ledger platform for improved return logistics
US12147937B2 (en) 2021-05-05 2024-11-19 Bank Of America Corporation Distributed ledger platform for improved return logistics
WO2023034418A1 (fr) * 2021-08-31 2023-03-09 Advasur, LLC Système et procédé de sérialisation et de validation sécurisées de matières premières pour soins de santé
WO2024234113A1 (fr) * 2023-05-15 2024-11-21 Morales Anabalon Miguel Système de traçabilité et de gestion de conteneurs
CN120258672A (zh) * 2025-06-05 2025-07-04 贵州商学院 一种基于区块链的物流信息追踪系统及方法

Also Published As

Publication number Publication date
GB201813134D0 (en) 2018-09-26
GB201818119D0 (en) 2018-12-19

Similar Documents

Publication Publication Date Title
WO2020030936A1 (fr) Suivi d&#39;objets dans une chaîne logistique
US10868676B2 (en) Computerized apparatus for secure serialization of supply chain product units
AU2021231439B2 (en) Storage and communication environment for cryptographic tags
CN110620810B (zh) 在区块链上的连续资产转移的非链接所有权
Benčić et al. DL-Tags: DLT and smart tags for decentralized, privacy-preserving, and verifiable supply chain management
US10192198B2 (en) Tracking code generation, application, and verification using blockchain technology
US20190258986A1 (en) Secure distributed supply chain transactional management system
US20190258991A1 (en) System and methods for querying the distribution path of product units within a supply chain
US9436923B1 (en) Tracking unitization occurring in a supply chain
JP2022504637A (ja) 暗号化デジタルｉｄのための分散型台帳
WO2023077794A1 (fr) Procédé de commande d&#39;autorisation d&#39;accès à une chaîne de blocs, système, dispositif, programme et support
EP3746968B1 (fr) Procédé de commande de distribution d&#39;un produit dans un réseau et système d&#39;ordinateur
WO2016090095A1 (fr) Vérification cryptographique de provenance dans une chaîne d&#39;alimentation
CN116777476A (zh) 基于公钥可搜索加密的药品可信溯源方法
CN113886883B (zh) 物联网数据管理方法及装置
Agarwal et al. Blockchain and homomorphic encryption based system for secure supply chain network against counterfeit drugs
Kalpana et al. Implementing a unique identification system for improved traceability and prevention of counterfeit drugs in the supply chain
Canbolat et al. Blockchain Track and Trace System (BTTS) for Pharmaceutical Supply Chain
Magar et al. Blockchain-based reliable supply chain management (SCM) for vaccine distribution and traceability using identity management approach
CN111833049A (zh) 针对物理特许权的基于密码逻辑区块链的保管和授权跟踪
WO2020050869A1 (fr) Génération, application et vérification de codes de suivi à l&#39;aide de la technologie des chaînes de blocs
CN114581027A (zh) 一种基于区块链的跨部门财物管理系统及方法
Finke et al. SPOQchain: Platform for Secure, Scalable, and Privacy-Preserving Supply Chain Tracing and Counterfeit Protection
Fahim et al. Secure and Transparent Supply Chain Management to Prevent Counterfeit Drugs
Silva et al. IPFS and Hyperledger Fabric: Integrity of Data in Healthcare

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19769552

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19769552

Country of ref document: EP

Kind code of ref document: A1